Now we can use file names or sub-system names. File names are always specified using an absolute path (starting with a /). This is how linuxconf tells apart request for a sub-system or a file.
The affected linuxconf command line options are:
Give it a look. You may learn a few things...
One modification to the protocol is solving the off-screen appearance of Linuxconf in treemenu mode. It now pops up full size instead of appearing in several steps.
To learn more about the guruengine, check out http://www.solucorp.qc.ca/linuxconf/tech/api/guruengine . This document provide many examples.
The libmodule concept solves this. A libmodule is just a bunch of subroutine and classes bundle together as a shared object. They are located in the libmodules sub-directory of linuxconf source distribution. Once a libmodule is create, it can be used fairly easily by any other module. It simply has to
For now, the only libmodule available is the guruengine module. More on this in the change log.
dhcp2dns.sh --domain another.domain.com --leasefile a_file
The module was written by Daniel Mealha Cabrita firstname.lastname@example.org from Conectiva Linux.
The module can configure the various files in /etc/pam.d. Further is also configures the parameter files for the following PAM modules:
The module was written by Daniel Mealha Cabrita email@example.com from Conectiva Linux.
The module was written by Cristiano Otto Von Trompczynski firstname.lastname@example.org from Conectiva Linux.
It consists of two components for now:
With updatemon, every time Linuxconf updates one configuration file one line is added to the "update files" window, at the bottom of the treemenu framework. The line shows the time and the path of the file. This way, you know which files are modified by Linuxconf.
But it does not stop there :-)
You can click on files in the "update files" window and you get a popup menu. It contains the following options:
Every time Linuxconf update a configuration file, it preserves the original version in an archive, using the RCS system, if available. Linuxconf has been doing that for some time now. This is the basis for "system profile versioning" btw.
This menu option request the list of all versions for this file in the archive. Version are presented with the most recent on top. A version is presented with a revision number (allocated by RCS) and a date.
Clicking on a version allows you to compare it (using diff) with the current file or to edit it. If you edit it and save, it will replace the current copy.
A popup presents the difference, using the diff utility between the new version of the file and the previous (The last one archived).
Using this, you will have a good idea of the modifications Linuxconf has made to a file.
This picks the last version in the archive and overwrite the current one. This can be seen as a glocal undo.
The current version of the file is presented in a text editor.
You are on your own.
The current version of the file is presented in a text editor. You are on your own.
While experimenting with a new module or a tricky configuration you may want to control step by step the configuration file updates. When you turn on the "interactive updates", a large popup shows. It has the following fields:
This is the path of the file being update.
This is the path of a temporary file containing the new version of the file.
This buttons let you edit the temporary file.
This presents the differences (using the diff command) between the temporary file and the current configuration file.
At the bottom, you have two buttons: Accept changes and reject changes. The first tells Linuxconf to continue the update. The original file (which has already been archived) is renamed with a .OLD extension and the temporary file is moved in place.
Selecting "reject changes" aborts the update operation. The temporary file is left in place if you want to review it later.
The id of this menu is MENU_HARDWARE. The setupmod.sh and shellmod utilities have been modified accordingly.
There is a problem with source rpms though. Just recompiling the source rpm is not enough. Inside the rpm SPEC file, the dependency for LINUXCONFAPIREVXX is hard coded. So while recompiling the source rpm with a inuxconf-devel 1.23 will produce a compatible module, rpm will continue to claim that it is incompatible.
This was caused by a bug in the way the SPEC file was created. The solution is simply to pick the source (module-x.n.src.tar.gz, untar it, cd in the source directory and do
This will create an RPM file and the new source RPM will only have to be recompile to match binary compatibility with any linuxconf version. It can even be recompiled against an older linuxconf-devel if needed.