Configuration

AddUser-NG, has a flexible configuration, that enables to automate the process of adding new system users accounts. Lets take a look into its capabilities.

adduser-ng.conf

This file is a configuration file for a program itself, it states where files (documentation, group catalog, etc) are located, it doesn't configure plugins (“group files” are used for this purpose, we will talk about them in the next chapter)

Caution

After installing the program, the only option that user should change is the User Interface, other opions should be left unchanged, unless you know what you are doing.

The file has a “dosini” syntax, so:

[GroupOfTheOptions]

# comment
option_1 = value
...
option_N = value

...
                    

Important

[GroupOfTheOptions] in this file appears only one and is called [adduser], it should not be changed.

Available options

  • groups_dir - this option tells where the groups' configuration files are

  • default_ui - using this option you can choose what user interface, should be used to comunicate with user.

  • documentation_dir - this option defines where the documentation files for every plugin are stored

Group files (plugins configuration)

In the *nix systems, natural is that a user belongs to a system group/groups. AddUser-NG has a simmilar philosophy, using “group files” as its main configuration. Group AddUser-NG can be treated as group of plugins that are executed while adding a new user, or as a system group, for which the account is being created. The best way to understand what the group files are, is by an example, so lets go on.

Group files directory is set by the groups_dir option in the main configuration file. Usually it is the /etc/AddUser-NG/groups/ directory. The group file name can be custom, as long as user remembers it. It is one of the parameters required for program execution (name of the group file that user belongs to must be specified).

Group files also have the “dosini” syntax, although there is a difference in the syntax between group files and the main configuration file. Group file looks like this:


[Name_of_the_plugin_to_be_loaded_by_program]

# comment
some_example_option = value

# this option has a keyword assigned
other_option_login_for_instance = %(main.login)

# this option is commented out so the program will ask for it.
# option = value

# this option has an empty value, program will not ask for it
# it will stay empty, assuming that this option has no value
option =

[Plugin_that_should_be_loaded_as_second]

example_option_for_second_plugin = value

[Third]

option = %(Plugin_that_should_be_loaded_as_second.example_option_for_second_plugin)
...
                    

Lets analyse this example. [PluginName] makes AddUser-NG load plugin called“[PluginName]”. Next, plugin is being configured, like this:

  • option = value - no comment is required here

  • option = %(KEYWORD) - AddUser-NG supports special keywords, which will be described later

  • # comment - everything that follows “#” is interpreted as comment and is skipped

Important

The order of the “[PluginName]” tags is important! The order in which the plugins will be configurated and loaded depends on the [PluginName] tags order in the groups' files.

Keywords

As mentioned above, AddUser-NG supports keywords, that can be used as values for plugins' options, like this:

  • %(PluginName.Option) - means: get the “Option” option of “PluginName” plugin and switch it, so the keyword %(PluginName.Option) will be replaced with desired value, for instance:

    Example 3.1.  Keyword example

    %(UserAdd.home_dir)

    will be replaced with the home directory of added user


  • %(PluginName.Option-numericvalue) - means: get “numericvalue” of chars from the beggining of “PluginName” plugin's “Option” option and replace it. for example:

    Example 3.2.  Example of a keyword (that picks chars from beggining )

    %(UserAdd.comment-1)

    will be replaced with the first comment char (Gecos)


  • %(PluginName.Option+numericvalue) - means: get “numericvalue” of chars from the end of “PluginName” plugin's “Option” option and replace it. for example:

    Example 3.3.  Example of a keyword (that picks chars from the end)

    %(GroupAdd.group_name+3)

    will be replaced with three last chars from newly created user group


There are two additional keywords, that are not a part of any plugin:

  • %(main.group) - this keyword is replaced with value of the group file name (or just the group name), to which the user was added. In other words - it is a value of the first parameter used in program execution.

  • %(main.login) - this keyword is the login name of the user we are creating (it is the second parameter used in program execution.

Note

Of course there is also a possibility of using “-” and “+” operators.

Example 3.4.  Other keywords usage

[UserAdd]
# this is usefull for people who are adding many user accounts and want
# them sorted alphabethically

home_dir = %(main.login-1)


Important

It is crutial to understand that a value have to be previously specified by program, for a keyword to allow its usage. Let's take a look on an example configuration file:

Example 3.5.  An example of valid keyword usage.

[UserAdd]
# %(main.login) keyword is automaticaly defined after program startup
# so we can use it at any time we want
home_dir = /home/%(main.login)

# 'home_dir' option is used above, so %(UserAdd,home_dir) is already defined
# this means we can use it:
comment = %(UserAdd.home_dir)
                            


According to comments the configuration file used in the exmple is valid. Although it is not a useful configuration, becouse it sets the user's home directory as value of user comment, it is only an example. Now lets take a look on the invalid configuration file:

Example 3.6.  Example of invalid keywords usage

# first the system group adding plugin will be configurated (and executed)
[GroupAdd]

# the name of newly added group, is using as a keyword the value of 'comment'
# option from 'UserAdd' plugin, which is wrong, because this option has yet
# no value, as 'UserAdd' plugin will be configurated later (after this plugin)
group_name = %(UserAdd.comment)

# load the UserAdd plugin, now notice that this plugin will be configured
# after configuring the GroupAdd plugin, because of the plugins order in this
# file.
[UserAdd]

# now the value for 'comment' is being defined, but it is already too late,
# and it is an invalid group file configuration.
comment = User %(main.login), group %(main.group)
                            


I suppose that comments used in this file make it clear why this file configure is invalid.

Few advices concerning group files configuration

By now you should already know how to configure AddUser-NG, you can go on and make your own group files now, but before you do, we have got some advices for you.

Despite the fact that each plugin can be loaded at any time you want (as you already seen, you decide in what order the plugins are loaded),it would be wise to:

  • when there is a new group set for every new user (as adduser command does), you should always load the GroupAdd plugin first (becouse group must already exist when we add new user),and then load UserAdd plugin.

  • Even if you don't add separate group for every new user (GroupAdd plugin is not needed), you should always place UserAdd plugin first in the configuraion file (it will be loaded first: configured and “executed”). It will prevent you from possible configuration mistakes, as setting quota byQuota plugin for non-existing user.