Linuxconf 1.9r3(test release)
- Linuxconf now manage keymaps (console) at boot time. There is an entry in
the features menu with a choice list.
dropins is a major concept allowing linuxconf extensibility. This is a
technology that compete with the sysv init scripts and Provide a greater level
of control and user friendlyness. Many people have expressed major concern
about the lack of such a technology in linuxconf. So here it is
- Dropins are now implemented and functionnal. A dropin is a small
configuration file one can "drop" "in"
/etc/linuxconf/control. This file tells linuxconf how to start, stop, restart
a system. Further it tells when it should be start (which linuxconf runlevel)
and when it should be stopped (Maybe never). It tells also which configuration
files should be monitored by linuxconf to tell if a system must be start or
restart or stopped (missing config files).
- There is now a menu in the control panel showing all the dropins. It
allows one to disable a system. At any time, a dropin may be in 3 possible state
- temporary disabled
- A temporary disabled dropin will be automaticly enabled at next boot. This
feature should let administrator do experiment and will avoid some costly
errors (forget about enabling a service and even forget that the service was
disabled). Some gadget will be add to remind the admin that some services are
- There is two ways to edit a dropin configuration. One is to directly
change it (affecting the content of the file in /etc/linuxconf/control. The
other is to do site specific changes. Both share exactly the same user
interface but save the result in different place. The site specific changes
will shadow the original features. Note that the changes are saved in the site
specific area topic per topic. This means that if you change a single line of
a dropin dialog, you still inherit from the original file for all other field.
If you upgrade the package the new features you are not shadowing will take effect.
- dropins are created and maintain in the following menu.
"control files and systems/linuxconf' addons" menu.
- action done at boot time only may also be specified for a dropin.
- While dropin are very easy to do, I have built some for redhat systems. I
am distributing them in a separate file linuxconf-dropins-1.9.tar.gz.
- A file root.cache is distributed with linuxconf. If linuxconf finds that
your DNS configuration is lacking a root.cache file, it will propose to copy
its own and will tell you how to get the latest from internic.
- A bug was fixed in the management of reverse mappings. The NS records were
not written at all. This was causing minor inconveniences especially for
secondaries. Edit your reverse mapping definition, fix the DNS advertising
fields and accept. This will repair the file.
- It was not possible to manage reverse mappings unless you were also
managing the name domain. It is fixed. Now, if you enter a machine name which
is not part of any domain names managed by this DNS, a simpler dialog appears.
It lets you enter a bunch of IP numbers. Those numbers are then used to update
the different corresponding reverse mapping files. If one number fit nowhere,
you will be told.
- User aliases menus have been duplicated in the user account menu. They are
more available this way.
- Creating virtual user account on system with shadow was breaking linuxconf Fixed!
- The vpop3d daemon may be recompile to support shadow password. Check in
the Makefile. This is unlike linuxconf which support both dynamicly without recompiling.
- Support for user aliases is now implemented for virtual email domain. For
each virtual domain, there is one implicit (you can't rename it)
/etc/vmail/aliases.virtual_domain file. The format (and capabilities) of this
file is the same as /etc/aliases, so it is easy to move an email server into a
virtual setup (back and forth) since the passwd file is also standard.
- For each domain, you can define up to 2 more aliases files. You must give
the path in the virtual domain configuration dialog. They are optionnal. The
implicit aliase file has precedence over those two, and the first optionnal
one has precedence over the next.
It is believed that the second one will be a server specific one, defining
aliases such as postmaster and hostmaster, while the first one will used to
share some alias definitions between related domains.
- Alias expansion are fully recursive. As a recap, an alias may expand to
- a list of names. A name may be itself an alias.
- A list of email addresses.
- A file holding a list of names and email addresses.
- When looking for an alias, the 3 alias files are search. Every recursion
start looking in the first and go to the 2 others until a match is found.
- A privileged user who can manage POP accounts of a virtual domain may also
manage the implicit alias file. To manage the two others, root privilege is required.
- filter programs (An alias may point to a filter) are executed with UID and
GID == -1.
- Alias for virtual domain (domain alias) are now implemented. You define
them straight in the virtual domain definition dialog. This allows two (or
more) virtual email domain to point at the same user pool.
- The dialog is now easier. NFS option are now checkboxs, making it more
obvious what is available.
- PPP dialout configuration were stored in a single /etc/ppp/conf.ppp file.
this is changed. Now one file per configuration is generated. The extension is
dconf. This was done so it become possible to distribute working setup to
linux users. For example, an ISP may build a configuration and simply give the
file to a customer. The customer has only to select the I/O port and enter the
username and password.
- A sample script below lets you extract your current configurations in /etc/ppp/conf.ppp.
CONFIGS=`grep .channel /etc/ppp/conf.ppp | cut -f 2 '-d '`
for i in $CONFIGS
grep $i. /etc/ppp/conf.ppp >/etc/ppp/$i.dconf
chmod 600 /etc/ppp/*.dconf
- One privilege is created for each PPP dialout configuration. You can tell
who is allowed to do a PPP dialout on your system using the normal privilege
system of linuxconf.
- All file of the UUCP system (HNB) can be moved (path) using the normal
mecanism of linuxconf's configuration files. For very odd reasons, RedHat
still continue to distribute its uucp with configuration files in
/usr/lib/uucp instead of /var/lib/uucp or /etc/uucp. This is not compliant
with the FSSTND as the usr/ directory should not contain site dependant
administration files. Anyway, it is possible to use linuxconf to configure
uucp on a RedHat system.
- A lot of validation were lacking. Many have been added...
- Firewalling rules have been generalised. Nothing is apparent yet, but it
will be possible in a near future to specify firewalling rule on a dialout per
dialout config basis. Those rules will be activated at connection time. The
dialin feature, combined with new packet accounting rules will be very useful
for ISPs. Stay tuned...