Howto/FAQ project linuxconf

1: booting

1.1: sysv init script

1.1.1: misc

May I modify sysv init script ?

Will this confuse Linuxconf ?

No. Linuxconf never writes in those files. It reads the beginning. It parses the first comment section. These comments are tags and this tells Linuxconf how to restart (in fact why) a service. Check out the document to learn more about those tags.

2: Distributions

2.1: fedora

2.1.1: 3


The binary for Fedora Core 3 is compiled on a fedora 1 system. You need compat-libstdc++ to install. It may not have been installed by default.

2.1.2: upgrading

Upgrading a system with Linuxconf installed may hang

Fedora core delete any Linuxconf package it finds. It does this because back in rh8.0, Linuxconf was deprecated. Now, removing Linuxconf is not a problem, but some users may have installed additional modules depending on Linuxconf. In that case, the following command:

	rpm -e linuxconf

performed by the anaconda upgrade process will fail, since other packaged need Linuxconf. Unfortunately, if this fails, anaconda hangs or exits.

The solution is to remove Linuxconf before the upgrade and install a new version immediately after. No configuration will be lost.

2.2: redhat

2.2.1: dhcp

Starting the DHCP service

On distributions using system V start-up scripts, Linuxconf relies on those scripts to start, stop and restart services. One exception is the dhcpd server. If the service is not already running, Linuxconf will start it "by hand". In some cases, the simple start-up script supplied by RedHat will fail to start the dhcpd service properly. The simple case works: One network interface with the default route pointing to it. If you have several interfaces and you wish to serve DHCP on the interfaces not pointing to the default gateway, dhcpd won't start, or it will start, but won't serve properly. In this case, you must tell explicitly to the dhcpd server which network to serve and you must add special routes to let the DHCP replies goes out.

Computing the proper dhcpd arguments and setting, if needed, the special route is a little beyond the abilities of a start-up script. So we wrote a helper system in Linuxconf dhcpd module, allowing the script to act properly. Unfortunately, no distribution ships this solution. So for now we have elected to let Linuxconf starts the dhcpd daemon itself if it is not already running. So for simple cases, Linuxconf has nothing to do. For complex case, where the script failed (silently I must add), Linuxconf tries to help.

This has one side effect. If you want to disable the dhcpd service, just turning off the system V dhcp service is not enough. Seeing that dhcpd is not running, Linuxconf will try to "fix this". So if you want to turn off the dhcpd service completely, you have two options:

A replacement for the RedHat 7.0 dhcpd startup script is available here

The change is in the start() section and look like this

start() {
        # Start daemons.
        # Unless you have a basic network setup (one interface, default
        # route pointing to it), just starting dhcpd won't work.
        # We use linuxconf to learn on which network the dhcpd server
        # must run and which special routes must be added
        if [ -x /sbin/linuxconf ] ; then
                eval `/sbin/linuxconf --hint dhcpd 2>/dev/null`
                if [ "$DEVICES" != "" ] ; then
                        for dev in $DEVICES
                                ROUTE=`echo $ROUTES | ( read a rest; echo $a)`
                                ROUTES=`echo $ROUTES | ( read a rest; echo $rest)`
                                if [ "$ROUTE" = "missing" ] ; then
                                        /sbin/route add -host dev $dev
        echo -n "Starting dhcpd: "
        daemon /usr/sbin/dhcpd $DEVICES
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/dhcpd
        return $RETVAL

2.3: RedHat 6.1

IP aliases do not work

Check out the updates for the initscripts package. Note that initscripts 4.63 still has some problems as it does not set the default net-mask properly. You may want to use the script ifup-aliases available from Place it in /etc/sysconfig/network-scripts

2.4: RedHat 6.2

2.4.1: Services

Why does Linuxconf always want to reload the network

There is a bug in redhat 6.2, in the file /etc/rc.d/init.d/network. Go at the end and locate the section

		echo reload
	exit 0

And change it to

		echo reload
	exit 0
Notice the && at the end of the second line.

2.5: redhat 7.0

Web mode

The HTTP mode on port 98 does not work with redhat 7.0. There are two issues. First, the service is disabled in /etc/xinetd.d/linuxconf-web. Edit this file and change the "disable=yes" to "disable=no"

The other problem is that the xinetd package is buggy. it does not handle a TCP service of type WAIT properly. A fix is available at . Pick the file xinetd-

This update is based on RedHat own update. If you find something newer on RedHat site, pick it.

Then after installing the update, restart the service

	rpm -Uvh xinetd-
	/etc/rc.d/init.d/xinetd restart

2.5.1: virtual email domain

How to install vpop3d on redhat 7.0

RedHat 7.0 has xinetd instead of inetd. So there is no inetd.conf anymore. To install vpop3d in xinetd, do

Note that xinetd package is buggy on RedHat 7.0. You may want to upgrade to the one found on

2.6: redhat 7.1

Linuxconf is missing on 7.1 ?

RedHat are not installing Linuxconf by default.. It is on the second CD. Don't waste your time with their RPM. Pick the one at . It has been tested on RedHat 7.1.

Web mode

The HTTP mode on port 98 does not work with redhat 7.1 (And 7.0). There are two issues. First, the service is disabled in /etc/xinetd.d/linuxconf-web. Edit this file and change the "disable=yes" to "disable=no". This follows the logic that unless you know you need a network service, you probably don't need it, so it it off by default.

The other problem is that the xinetd package is buggy. it does not handle a TCP service of type WAIT properly. A fix is available at . Pick the file xinetd-

This update is based on RedHat own update. If you find something newer on RedHat site, pick it.

Then after installing the update, restart the service

	rpm -Uvh xinetd-
	/etc/rc.d/init.d/xinetd restart

2.7: redhat 8.0

Linuxconf is missing in redhat 8.0

Linuxconf is not included on rh distros since 7.3. You can pick a working Linuxconf at

2.7.1: services

Error reported when probing the network services

Linuxconf is not supported in RedHat Linux since 7.3. Although they have discontinued Linuxconf itself, many RedHat package still carry some Linuxconf specific information. But they are kind of buggy.

The /etc/init.d/network script is one of those. The line

    # probe: true

tells Linuxconf there that we are allowed to run the network script with the option probe to learn about its state. Unfortunately, this option is not implemented anymore in the script, so Linuxconf produces an error every time it probes the network script.

The simple solution is to edit the /etc/init.d/script and remove the above line (# probe: true).

Now, if you update the network configuration and you want to enable the change you will have to either reboot or perform the following command.

    /etc/init.d/network restart

2.8: redhat 9.0

Linuxconf is missing in redhat 9.0

Linuxconf is not included on rh distros since 7.3. You can pick a working Linuxconf at

2.8.1: Services

Error reported when probing the network services

Same issue as RedHat-8.0 (see the other FAQ entry). Just edit the file /etc/init.d/network and remove the line

    # probe: true

Error reported when probing the NFS services

Linuxconf is using the NFS service to probe the NFS configuration. It issues the following command:

    /etc/init.d/nfs probe

And it reports the action to perform the load the new configuration (if needed) in the running NFS server. Generally, this script reports nothing, but it may report strings like start, restart, or reload.

Unfortunately, RedHat have localized (translated) their init scripts. The programmer who did this job just walked over every string in the NFS script and changed them to gettext version. So reload became $"reload" for example.

This breaks the probing mechanism. "/etc/init.d/nfs probe" must report valid "action" usable on the nfs script itself. To solve the problem change the "probe)" section in the script and change the following strings

	$"start" -> start
	$"restart" -> restart
	$"reload" -> reload

3: dns

3.1: setup

How to setup a DNS from scratch

This is less complicate than it appears. Here are the steps

4: firewalling

4.1: general

How to enable the firewalling menus

Firewalling is handled by a module. It is deliver with the main Linuxconf package, but you may have to enable it (it is enabled by default during the installation). Visit the following menu:

    control/control files and systems/linuxconf modules

and enable the firewall module. Restart linuxconf and you will find the related menu entries in the networking menu.

4.2: tricks

4.2.1: masquerading

How to setup basic masquerading with Linuxconf

Try Networking->Firewalling defaults... ->(Check) Forwarding rules and all the special modules.

Now go back to Forward fire-walling (option on the previous menu) Add a new rule. Check Do masquerading and enter the following:

    from       : your-internal-network
    netmask : the netmask

     to          :

And leave the other fields untouched.

Do not forget to enable routing in networking/routing & gateways/default

4.2.2: port redirection

How to redirect a TCP port to a machine inside the firewall

We have a machine on the Internet, and potentially several machines inside the firewall on the Intranet. We may want to make some services on those machine available on the Internet, leaving the machine protected behind the firewall.

This is achieved by the redir utility. You can find a package for this utility at

By default, redir will redirect all TCP traffic hitting a port on the firewall machine. This might not be what you want. For example, you may have several web server hidden behind the firewall and you want to make several of them available on the net. You will do this by configuring some IP aliases, one for each internal server, and then using some firewall rules, you will redirect the traffic for each one separately to one redir configuration.

Here are the steps:

4.2.3: proxy

Transparent proxy with squid

You must enable blocking rules. Then you need at least two rules. One used to intercept HTTP request and another to let the rest of the network traffic pass through. Enabling the blocking rules turn everything off by default.

Once done, you create the redirection rules like this

protocol: tcp

from: internal-network
Interface: Internal network interface

other ports: 80
interface: any

               [x] redirect to local port
redirection port: 3128

3128 is the default port in squid. You also need a rules that let everything goes. Well, you may not want that. You may want a rule that does some fire-walling, but just to make it work, you need at least something like that

protocol: all
from: internal network
netmask: internal network netmask
interface: internal network interface
interface: external network interface

Use the linuxconf module squid to edit /etc/squid/squid.conf. Turn on transparent proxying. The rest is fine. Use Linuxconf 1.17r2 to handle squid though. Older version did not support squid 2.x properly.

5: general

5.1: documentation

5.1.1: other

Are there any other location providing help for Linuxconf

There are other FAQs available. One offers general information. It is located at

The other is aimed at Linuxconf developers. It also contain general informations about linuxconf. It is located at

5.2: services

5.2.1: probing

How does Linuxconf know a service must be restart ?

Linuxconf is using two strategies. One for distribution which are Linuxconf aware and one for the others.

The network script (/etc/rc.d/init.d) is a little special. For the network script, it uses the tag "probe: true". This tells Linuxconf to let the script finds out by itself if it needs a restart or not (restart of whatever). When probe is true, Linuxconf calls the script with the probe argument

        /etc/rc.d/init.d/network probe

this normally prints nothing when everything is up to date. If something is not right, the script output simply "reload". Linuxconf picks this string and if you choose to activate the changes, it calls the script with this string.

Now, finding out if something has to reconfigured is not trivial, so the network script is using specials Linuxconf command lines to find out. They are:

  • linuxconf --hint netdev [ interface ]
  • linuxconf --hint routing
  • linuxconf --hint ipalias [ interface ]

Samba is not restarted as needed

The samba service generally reload its configuration when a new user connects. So in general, you seldom need to restart it. But if you fiddle in the global section (default parameters), then you probably need to restart it. Unfortunately, init script delivered with most distribution are not helping. Linuxconf can't help, unless the init script are fixed.

Here is a simple modification you do do to /etc/rc.d/init.d/smb script (/etc/init.d/smb on some distro) to make Linuxconf probing reliable. This relies on Linuxconf 1.24r6 and a small helper program called /usr/lib/linuxconf/lib/samba-check.

Edit the script and do the following modifications:

  • Place the following statement at the end of the first comment section of the script.

    	# probe: true

  • At the end of the start) section, before the ;; characters, insert the following paragraph.

    	test -x /usr/lib/linuxconf/lib/samba-check &&
    		/usr/lib/linuxconf/lib/samba-check --logstart

  • Add the following paragraph at the end of the case statement

    	# Make sure it is running
    	PIDSMBD=`/sbin/pidof -s smbd`
    	PIDNMBD=`/sbin/pidof -s nmbd`
    	if [ "$PIDSMBD" = "" -a "$PIDNMBD" = "" ]  ;then
    		echo start
    	elif [ "$PIDSMBD" = "" -o "$PIDNMBD" = "" ]  ;then
    		echo restart
    		test -x /usr/lib/linuxconf/lib/samba-check &&
    			/usr/lib/linuxconf/lib/samba-check --test

Once done, Linuxconf will be able to assist you properly for the samba service.

sendmail is not restarted as needed

Linuxconf relies on the sendmail init script to tell if the service has to be restarted after a configuration change. Unfortunately, the sendmail init script on most distribution is incomplete. Linuxconf can't reliably tell if sendmail has to be restarted.

A helper program /usr/lib/linuxconf/lib/sendmail-check (Linuxconf 1.24r.6) was created to solve this. To use this, you have to edit the init script /etc/rc.d/init.d/sendmail like this:

  • Add the following line at the end of the first comment section.

    	# probe: true

  • At the end of the case statement, add the following paragraph

    	test -x /usr/lib/linuxconf/lib/sendmail-check &&
    		/etc/ /var/run/

6: networking

6.1: ppp

6.1.1: dialin server

How to turn you Linux server into a PPP server

To configure a dialin server, you may want to enable the pppdialin module ("linuxconf --setmod pppdialin" will do that)

The new default for the PPP login script is /usr/lib/linuxconf/lib/ppplogin, which is supplied. /etc/ppp/ppplogin was a suggested value before the pppdialin module became available. Newer linuxconfs default to this path.

To change the default ppp login script, you go in the user account/policies menu and pick "Available PPP shells". Creating a suitable PPP login script requires some understanding of the pppd utility though. Using the pppdialin module will help. You may want to check the supplied ppplogin script anyway.

Once you have enabled the pppdialin module, you will see a new entry in the user accounts/policies menu. Select it and read the help screen

Note that you must also enable the serial port. You do this with the mgetty+sendfax package (included in most distribution). You may want to install the mgettyconf module found at to help configure that.

Once done, you create PPP accounts.

7: Programming

7.1: modules

7.1.1: Introduction

How to build Linuxconf modules

At this time, there are two ways: Using C++ or using the shell.

You can find information about C++ module here.

You can create Linuxconf modules using either bash (the shell), Perl or Python. Bash and Perl are handled by the shellmod module. Here is the help screen describing how it works. Shellmod is intended for fairly simple module. It is possible to create something useful in 10-20 lines of shell scripts. Check it out!

The Python support is handled by the pythonmod introduced in Linuxconf 1.23r1. The module is part of the core distribution. Unlike shellmod, pythonmod is a complete binding. It provides access to many functionalities of Linuxconf APIs, including CONFIG_FILE, PRIVILEGES and the user interface.

7.1.2: Other information

Is there other source of documentation about Linuxconf modules<

Beside, you can find other tips about Linuxconf modules (programming). They are

7.2: user interface

7.2.1: GUI

Using passthrough to produce more complex dialogs

The user interface in Linuxconf is limited. The goal is to provide a uniform user interface so that dialogs looks the same everywhere.

The 3 user interfaces concept also limited the feature we can put in a dialog. It is possible to produce a dialog that will take advantage of the GUI. By putting conditional like

    if (dlalog_mode == DIALOG_GUI){
       GUI specific code
       html and text

one can produce sharp dialog (or different dialog) in GUI. To achieve this one must have some understanding of the GUI protocol used to talk with the GUI front-end and the layout strategy it is using. All this is described in the following document: http::// .

Here is a small example and the screenshot of the resulting dialog. Note the usage of the functions DIALOG::newline() and DIALOG::gui_passthrough().

    DIALOG dia;
    dia.gui_passthrough (P_Group,"g1 "%s"",MSG_U(F_CATEG,"Catégories"));
    for (int i=0; i<4; i++){
        glocal.comb = dia.newf_combo ("",it.categ[i]);
        if (i==0) dia.last_noempty();
        <call sql_query>("select distinct categ%d from todoitems"
             " where project = '%s'"
             " order by categ%d"
             <f onerow>
                 glocal.comb->addopt (row[0]);
    dia.gui_passthrough (P_End,"");
    dia.gui_passthrough (P_Groupfit,"g2 "%s"",MSG_U(F_SPECS,"Spécifications"));
    dia.newf_str (MSG_U(F_START,"Démarre"),it.start);
    dia.newf_str (MSG_U(F_DONE,"Terminé"),it.done);
    dia.gui_passthrough (P_End,"");
    dia.gui_passthrough (P_Form,"f1");
    dia.newf_str (MSG_U(F_TITLE,"Titre"),it.title,70);
    dia.newf_textarea (MSG_U(F_DESCRIP,"Description"),it.descrip,70,15);
    dia.gui_passthrough (P_End,"");
    dia.gui_passthrough (P_Dispolast,"l 2 t 1");
    dia.setbutinfo (MENU_USR1,MSG_U(B_SPELL,"Épellation"),MSG_R(B_SPELL));

Here is the screen shot.

7.2.2: HTML

Some details to know about the HTML mode

The Linuxconf UI toolkit supports Text, Graphical and HTML mode. It is all transparent to the programmer. While the programmer is allowed to use passthrough and tailor his dialogs to take advantage of one specific user interface, in general, the same code behave properly in all mode.

The HTML mode is somewhat special. One has to understand the web and HTTP to better figure out the trickery behind the HTML mode in Linuxconf.

Linuxconf use a programming model called "modal programming" (or sometime called classical programming). This model is illustrate by this sample code

	DIALOG dia;
	SSTRING name,phone;
	dia.newf_str ("Your name",name);
	dia.newf_str ("Your phone",phone);
	int nof=0;
	while (1){
		MENU_STATUS code = dia.edit ("title","",help_nil,nof);
		if (code == MENU_CANCEL || code == MENU_ESCAPE){
		}else if (code == MENU_ACCEPT){
			if (some_validation){
				// process the result
				xconf_error ("Some errors");

8: sendmail

8.1: general

8.1.1: init script

Restart sendmail sometime fails

On many distribution, Linuxconf is using the system V init script to start, stop and restart sendmail. This script is normally found in /etc/rc.d/init.d/sendmail.

This script is not always reliable and sometime will fail to restart sendmail. This generally happen when sendmail is delivering mails to other systems (There are several sendmail process running).

After this failed restart, sendmail is not accepting email anymore. The solution is to stop the service and start it.

Some people have changed the script with a "killall sendmail" in the restart section to make sure the restart is always successful.

Note that restarting sendmail is not something we do often.

8.2: sample config

How to configure sendmail for on-demand link (PPP)

It is possible to configure sendmail so it behaves correctly for on demand link (PPP using diald for example). You can do this with Linuxconf.

Basic configuration dialog

Other fiddling

You must setup things so that email are processed once in a while. For example, you may want to trigger the Internet link every hour to deliver mail and retrieve the other mail. You may want to check fetchmail for mail retrieval. If the PPP config was done with Linuxconf and its dialout module, you can put the following script the /etc/cron.hourly script for example, or use the "root scheduled task" of Linuxconf control panel to fine tune the the call schedule:

     if netconf --connect dialout-config-name
          /usr/sbin/sendmail -q &
          fetchmail config &
          netconf --disconnect dialout-config-name

Switching sendmail config while connected

Here is a trick RedHat user can use to switch the behavior of sendmail when they are connected. When "not connected", you do not want Sendmail to run its queue. When connected, you want sendmail to run its queue often enough so that email starts as soon as possible.

So you need 2 sendmail configuration file (/etc/sysconfig/sendmail). Use Linuxconf to disable queuing. This will update the config file above. Copy it in /etc/sysconfig/sendmail.offline.

Then enable queuing every minute. Copy the config file in /etc/sysconfig/

then in your dialout configuration, put this as your post-connect script

      cp /etc/sysconfig/ /etc/sysconfig/sendmail; /etc/rc.d/init.d/sendmail restart

And in the post-disconnect script

      cp /etc/sysconfig/sendmail.offline /etc/sysconfig/sendmail ; /etc/rc.d/init.d/sendmail restart

8.3: virtual domains

IP-less virtual domains and vpop3d

Generally, you need one IP per virtual email domain. You need that to retrieve messages. You do not need any IP for receive messages. The SMTP protocol carries enough information, allowing sendmail, then vdeliver, to distribute the messages properly.

If you want to achieve IP less with vpop3d, you need at one single IP for all virtual domains. vpop3d can tell apart which domain it is by looking at the login ID supplied by the user. So if a user supplies user@some_domain, vpop3d with select some_domain.

The pop-3 protocol has no provision to support vhost unlike HTTP which carry domain information in the request header. So we are using this trick with the user ID. Your vdomain users have to supply user@vdomain instead of just user. Most mail program handle that without noticing.

There is a catch with vpop3d: It does not manage the main domain at all. So it chains to the native pop-3 daemon to let it manage the main domain. To do so, it has to decide early at connect time if the native pop-3 server is handling the request or not. It has to decide this without reading a single line from the socket. The native pop-3 server expect to read everything from the socket.

So vpop3d has to decide if the request is for a virtual domain or the main domain based on the IP. It does a reverse look-up on the target IP. If it matches any vdomain, it handles the request itself. If it does not match any vdomain it chains to the native pop-3 server.

So to go IP Less with vpop3d, you need one IP for the server and one IP for all vdomains.

Now, a simpler solution is to use the vimap package available from, at least on red-hat system. The vimap package is a replacement for the standard imap package found on red-hat. You just upgrade to it. It does everything vpop3d does and more. Because the vimap package handles the main and virtual domains, it does not have to "decide early". It also supports the user@vdomain trick above.

Is there an IMAP server supporting Linuxconf virtual email domains

Yes, check out

Moving virtual domains from one server to another

One goal of the virtual domain for email is to have independent configuration files for each domains. Domains become movable from one server to another to spread the load. This has no impact (when done properly :-) ) on users.

Here are the steps to move a domain from an old server to a new one::

8.3.1: procmail

Using procmail and spam-assassin with virtual email domains

It is possible to use procmail to process email for virtual email. You either place a .procmailrc in the user home directory or you write one file for the whole domain (all users without a .procmailrc) in /etc/vmail. You name the file procmailrc.THE-DOMAIN (ex: /etc/vmail/

8.3.2: spam-assassin

Using spam-assasin in virtual email domains with procmail

When calling spamc from a procmailrc file, you must supply the USER id on the command line. spamc normally check in the system password database to grab the user id from the numeric ID. Since virtual email users are not stored in this database, spamc is confused.

Here is a recipe to solve this:

| /usr/bin/spamc -u $USER

9: sources

9.1: compilation

9.1.1: building packages

How to build RPMs from sources

To rebuild a source RPM, you just do

    rpm --rebuild linuxconf-1.16r4-1.src.rpm

and you will get binary RPMS in /usr/src/redhat/RPMS/architecture. On SuSE you get those in /usr/src/packages/RPMS/architecture. Architecture is i386 on a PC, alpha on a alpha and sparc on Sun workstations for example.

If you have modified linuxconf sources and wish to produce RPMs out ot it, you simply do:

    make RPMREV=1 buildrpm

and you will get source and binary package in the appropriate places (/usr/src/redhat/RPMS/... and /usr/src/redhat/SRPMS).

Note that this applies to modules developped as indenpendant packages as well.

Which packages are produced

Here are the RPM packages produced:

When you fire linuxconf, it detects if it is running in a graphical environment (X is running). If so, it starts the GUI front-end. It starts the /bin/remadmin program. this is a shell script. This script will try to locate an available front-end. If one is found, the connection is made and Linuxconf performs like a normal GUI application. If none is found, Linuxconf runs in text mode.

11.2.2: tricks

How to do remote administration using the GUI

You can run the GUI locally and Linuxconf remotely. The command line is

    remadmin --exec link_command linuxconf --guiproto

Ideally, you will want encryption between the two machines. The best solution is to use ssh. So you will do

    remadmin --exec ssh -l account linuxconf --guiproto

This is very efficient and will allow you to use the GUI to administer boxes running on very slow (or congested links). All this fully encrypted.

11.3: HTML

How to enable HTML mode

You access Linuxconf using a web browser by using the following URL


Before you can access, you must enable the HTML mode and grant access. Visit the dialog networking/misc/linuxconf network access and check out the help screen.

11.3.1: Custom look

Is it possible to change the look of the user password change dialog

Most dialogs in Linuxconf are generated from a algorithm, so they all look the same. There is an exception. The user password change dialog allows some tuning. Here are the specs.

11.3.2: Errors

What does "500 dialog mismatch" mean

The HTML mode is some sort of disconnected protocol. When you request a dialog from Linuxconf, you may decide to do some change and "accept" them, or do nothing and jump to another area in Linuxconf.

So when Linuxconf draws an HTML dialog, it does not wait for an answer. The answer may come in a few minutes or never. Or it may come in a few hours.

Now imagine the following scenario:

Because of the disconnected nature of HTML, the changes done by your co-worker will be lost, overwritten by your own changes. This is not a good thing.

Linuxconf solves this problem by encoding in the HTML form, the original values of each fields. They are stored as hidden field. When you hit accept, Linuxconf compares the current values (the ones stored in the various configuration files) with the hidden field. If they match, this means no one else has modified the information in between.

The "dialog mismatch" error is presented otherwise.

Some bugs were uncovered in Linuxconf leading erroneously to this error message. The last was uncovered and fixed in 1.17r7.

11.3.3: look

Changing the look of the HTML interface

The HTML interface is not generated using any templates. All the HTML pages are generated on the fly in dialog/ Linuxconf is made of hundreds of dialogs, so creating one web page for each would be problematic. Some details: