There are various possible usages:
Linuxconf is a system administration utility. As such, it takes care of "root" stuff and does not deal with user preferences. Some modules could be useful to end user as well as system administrator. For example, the fetchmailconf module may be use by root to configure the system wide fetchmail configuration, while one user may use it to configure his personal .fetchmailrc.
Having the ability to reuse a module this way, may expand the usefulness of some module. The LINUXCONF_MODULE::execmain function was modified to pass an extra "standalone" flag, so a module may adjust itself potentially changing some options.
Linuxconf is a fairly large project and so far, little attempts has been made to port it to different Unices. It touches so many aspect of system configuration, well...
Porting linuxconf-wrapper and linuxconf-devel to other Unices is fairly easy. Then porting various modules should be straight forward.
The end result would be module reusing various abilities of Linuxconf engine and sharing a common look and feel. The module would also work both in text and graphical mode as well.
Run this way, module are truly stand-alone. They do not talk with each others. They are on par with other legacy admin tools...
Nevertheless, this might be an interesting avenue for developer seeking one toolkit to produce an admin component for all the unices out there.
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).
Moving to VIEWITEM simplified the module to no end. Further, it has enhanced its abilities:
The Linuxconf gurus are different in various areas. First, because of the virtual registry, the gurus do not have to duplicate any parsing/file update capabilities found in other Linuxconf modules. They can use it just by reading and writing variables. Pretty cool.
Gurus are focusing (or will) on global validations, much more verbose dialog introduction.
The interesting aspect of the gurus module is the framework controlling which dialog is presented. The framework is controlling the path, probing each dialog to know if it is requested or meaningful based on the previous input.
Gurus are not only good for initial configuration. They can walk over and already configured system. They are useful to review configuration step by step.
But the gurus framework stands a bit apart because of one key feature. The "path" to follow is hi-lighted graphically. Think of it as a train station map. While you advance in the dialog,s you move to other station along the map. If a dialog make a path impossible, you will see it (lines become red). If you have not yet visited (information not filled) a dialog, the "station" is presented as an empty circle. If the information was filled, the circle is filled (all blue). If the information is not valid, the "station" is presented as a broken red circle. For example, in the network gurus, if the default gateway is not reachable on the local network, a red station is presented.
This graphical representation might become a key to trouble shoot problems. Gurus may become "the" place to enter as much validation as possible.
You can check some screen shots of the gurus module at http://www.solucorp.qc.ca/tests
So if you try to update Linuxconf (using RPM), it will complain if you are using modules such as userinfo, usersbygroup and so on. The only way to upgrade to 1.21 is to either fix the modules, or un-install them.
The change is really minor. The LINUXCONF_MODULE::execmain function has an extra parameter: bool standalone. It tells if the module is run using linuxconf-wrapper or Linuxconf itself (standalone == true means linuxconf-wrapper).