user-id group user-name shell passwordEach field is separated by a tab. The module accept also the output of a command. From there, you can either add or delete accounts. Accounts found in the file, but not in /etc/passwd will be added. Account already in /etc/passwd won't be affected. Account in /etc/passwd and not present in the file will be deleted. When using deletion, you must specify on which groups the module is authoritative. It won't delete all account not found in the file: Only accounts member of specific group, or with a group id higher than a specified value.
The module has a test button, so you can safely try it and do nothing. Once you have process the file, you can use the module again and it won't do anything, since everything is in sync.
The module allows you to keep several configuration and replay them later (which file or command authoritative on which groups and so on).
The module has now a progress dialog, with up to three gauges. One shows the creation process (new accounts), another the deletion and the last one, the password update process.
The option --update has been added and it has many sub-options.
--update [--test] [--silent] [--file path] [--group groupname ] [--grouplow gid ] [--add ] [--del ] [--mod ] [--archive ] [--delfiles ]
A section has been added to the dialog and for each field, we can specify the column in the input file. Or we can say it is missing in the file and supply the default value.
For the password field, we can request auto-generation of the passwords. If selected, the passwords are generated using random values and the report is produced at the end to collect the passwords generated.
A new button "preview" was added to preview the file content after applying the proper parsing. So you can tell if the module properly understand your file and supplies the proper defaults.
The module is doing more validations prior to performing the task: Check if all groups exists for one.
The module accountbatch is able to parse the input file and assigns the extra fields to LDAP using the API.
It can also be used to combine two fields. For example, you may have the name and the surname as different fields in the input file and used them to setup the gecos field.
Further, the module was not able to update existing account under control. Now you can specify field by field, which one will be updated.
But it was only affecting accountbatch...
when deleting accounts, the module may execute a command ( authorization command) to learn the list of account it is allowed to delete. Normally, the module will delete/disable accounts on which it is authoritative (member of some groups only). But many tests accounts are created manually and the module can't tell them apart. Now you can write a script reading its standard input and producing on standard output the list of account ok for deletion.
When filling the "operate only on groups" field, you can enter simply a start ("*"). This means accountbatch is authoritative on all groups appearing in the input file. This is useful when the input file contains lots of users in different groups.
The dialog was a bit confusing. You had the test button to run a simulation and get the list of account added,updated, deleted or disabled. And you had the accept button performing the task for real. This button was replace with a "run" button place near the "test" button.
When using the command line to perform account creations or updates you can use the --config option to load one configuration. So you inherit all the parsing information stored with the configuration. Later you can still use the --file or --group (or any other option) to override the stored configuration settings.
Now, it collects all errors and presents a single message at the end of the add/update sequence. If there is one error found, the deletion/disable task is skipped.