Only in linuxconf-1.10r3/help.files/sources/apache: FILE_LIST Only in linuxconf-1.10r3/help.files/sources/dhcpd: FILE_LIST diff -rc2P -x *.bak -x *~ -x *.help -x *.html -x Makefile linuxconf-1.10r3/help.files/sources/dnsconf/conflict.sgml /tmp/linuxconf-1.10r4/help.files/sources/dnsconf/conflict.sgml *** linuxconf-1.10r3/help.files/sources/dnsconf/conflict.sgml Wed Jul 23 09:32:11 1997 --- /tmp/linuxconf-1.10r4/help.files/sources/dnsconf/conflict.sgml Sat Feb 14 16:24:32 1998 *************** *** 8,12 **** Normally in a DNS, only a single name is associated to a given IP. Further, the reverse search is possible allowing one to find ! the name from the IP. It is sometime convenient (necessary ?) to have more than one name sharing a given IP number. The common case is the default IP associated with a domain. This default IP --- 8,12 ---- Normally in a DNS, only a single name is associated to a given IP. Further, the reverse search is possible allowing one to find ! the name from the IP. It is sometime convenient (or even necessary) to have more than one name sharing a given IP number. The common case is the default IP associated with a domain. This default IP diff -rc2P -x *.bak -x *~ -x *.help -x *.html -x Makefile linuxconf-1.10r3/help.files/sources/dnsconf/conflict.sgml.orig /tmp/linuxconf-1.10r4/help.files/sources/dnsconf/conflict.sgml.orig *** linuxconf-1.10r3/help.files/sources/dnsconf/conflict.sgml.orig Wed Dec 31 19:00:00 1969 --- /tmp/linuxconf-1.10r4/help.files/sources/dnsconf/conflict.sgml.orig Wed Jul 23 09:32:11 1997 *************** *** 0 **** --- 1,80 ---- + +
+ IP allocation conflict resolution + <author>Introduction + + <abstract> + + Normally in a DNS, only a single name is associated to a given + IP. Further, the reverse search is possible allowing one to find + the name from the IP. It is sometime convenient (necessary ?) + to have more than one name sharing a given IP number. The common + case is the default IP associated with a domain. This default IP + is generally the IP number of the web server, making it convenient + for web users. <em/Linuxconf/ is trying to flag duplicate usage + and help you manage properly your DNS. + + </abstract> + + <sect>Normal operation + <p> + When updating a definition for a host name in a domain, Linuxconf + checks if the IPs allocated are not already in use by another host + in any of the domain managed by this DNS. If there is no other + host using that (those) IP, linuxconf will updates the various + records, including the reverse mappings (PTR records). + + If there is a conflict, a dialog is presented allowing full + control on Linuxconf's behavior. + + <sect>So there is a conflict + <p> + What are your options when there are such a conflict ? When more than + one host are sharing one IP number, one is known as the official + host and the reverse mapping points to it. So mostly you + have this DNS relation. + + <tscreen><verb> + host.domain -> IP number + IP number -> host.domain + </verb></tscreen> + + All other host names sharing the IP will only have the first line of + this relation. Linuxconf enforces this. So when there is a conflict + your options are: + + <itemize> + <item>Cancel the dialog and pick another IP number + <item>Tell linuxconf that this host is the "main" one so linuxconf + will use this host name to do the reverse mapping (and will + delete any previous reverse mapping on this IP number). + <item>Tell linuxconf that this host is not the "main" one. Linuxconf + won't update the reverse mapping. + </itemize> + + <sect>The <em/IP allocation conflict resolution/ dialog + <p> + You are allowed to enter up to 4 IP numbers per host name. If there is + a conflict on at least one IP number, linuxconf will present you + a dialog showing you each IP number and the suggested update + mode. Mostly, linuxconf may or may not update the reverse mapping + associated with each IP number. + + The dialog appears with a check box for each IP number. Those with + a conflict have the check box in the "unchecked" state. This mean + that if you simply "accept" the dialog as is, linuxconf won't update + the reverse mapping of the IP numbers where there is a conflict. + + By switching the state of the check box, you effectivly tell + linuxconf to update or leave unchanged the reverse lookup for + the given IP. + + <sect>Entering an IP number for a domain + <p> + Since this is common practice and a reverse mapping pointing to a + domain is a bad practice (It must point to a host of the domain), + linuxconf does not signal any conflict when entering IP numbers + for a domain. (There should be a conflict indeed) + + </article> + diff -rc2P -x *.bak -x *~ -x *.help -x *.html -x Makefile linuxconf-1.10r3/help.files/sources/main/intro.sgml /tmp/linuxconf-1.10r4/help.files/sources/main/intro.sgml *** linuxconf-1.10r3/help.files/sources/main/intro.sgml Thu Nov 27 02:13:30 1997 --- /tmp/linuxconf-1.10r4/help.files/sources/main/intro.sgml Fri Feb 13 11:50:16 1998 *************** *** 302,305 **** --- 302,323 ---- It gets you directly in the user configuration menu. + Here are the command line options: + + <itemize> + <item><verb/userconf --adduser userid group username shell/ + + This creates a user account and update (if available) the + various disk quota records from defaults. There is no + defaults. The HOME (using default base directory) directory + is created with proper /etc/skel handling. + + You may use the passwd command with the -P to set the + password for the new account. + + <item><verb/userconf --deluser userid/ + + This deletes an account + + </itemize> </itemize> diff -rc2P -x *.bak -x *~ -x *.help -x *.html -x Makefile linuxconf-1.10r3/help.files/sources/mrtg/FILE_LIST /tmp/linuxconf-1.10r4/help.files/sources/mrtg/FILE_LIST *** linuxconf-1.10r3/help.files/sources/mrtg/FILE_LIST Wed Dec 31 19:00:00 1969 --- /tmp/linuxconf-1.10r4/help.files/sources/mrtg/FILE_LIST Sat Feb 14 15:12:36 1998 *************** *** 0 **** --- 1 ---- + mrtg diff -rc2P -x *.bak -x *~ -x *.help -x *.html -x Makefile linuxconf-1.10r3/help.files/sources/netconf/FILE_LIST /tmp/linuxconf-1.10r4/help.files/sources/netconf/FILE_LIST *** linuxconf-1.10r3/help.files/sources/netconf/FILE_LIST Fri Dec 12 01:18:05 1997 --- /tmp/linuxconf-1.10r4/help.files/sources/netconf/FILE_LIST Sat Feb 14 15:12:41 1998 *************** *** 29,32 **** --- 29,33 ---- sysv missing + restartdb toolong devlist diff -rc2P -x *.bak -x *~ -x *.help -x *.html -x Makefile linuxconf-1.10r3/help.files/sources/netconf/dropin.sgml /tmp/linuxconf-1.10r4/help.files/sources/netconf/dropin.sgml *** linuxconf-1.10r3/help.files/sources/netconf/dropin.sgml Wed Dec 31 19:00:00 1969 --- /tmp/linuxconf-1.10r4/help.files/sources/netconf/dropin.sgml Sat Feb 14 15:13:56 1998 *************** *** 0 **** --- 1,260 ---- + <!doctype linuxdoc system> + <article> + <title>Linuxconf's add-ons + <author>Introduction + + <abstract> + The standard way to add custom startup procedures on a system is + generally by editing a script or batch file. In Unix, this is + done by adding commands in the rc.local script. Unfortunately + this has many limitations. The Linuxconf's add-ons as well + as the enhanced Sysv init scripts provide a better alternative. + The add-ons are also called dropins. + </abstract> + + <sect>Sysv init script or Linuxconf's add-ons + <p> + Both offer the same functionalities, but setting up a dropin + is easier (there is a user interface for it). Beware that at this + time, Sysv init script (Unix System V style) shipped by + all distribution are very limited in functionality. The + following document show you how you can enhance the current script + you have: + + <htmlurl + url="http://www.solucorp.qc.ca/linuxconf/tech/enhsysv" + name="http://www.solucorp.qc.ca/linuxconf/tech/enhsysv" + > + + <sect1>An add-on with the same name as a Sysv script + <p> + If you give an add-on the same name as a Sysv init script, the + add-on will have precedence. The script won't be called anymore. + Quite often, one will create a dropin and will simply define + the start, stop and reload command by calling the sysv script. + This is an easy way to enhance a sysv script without touching it + yet keeping compatibility in case of an upgrade. + + <sect>tasks + <p> + A dropin simply enumerate how to start, stop and restart of package. + It also provide information so Linuxconf can effectively decide + the action to execute (start,stop,restart). + + <sect>Fields of the dialog + <p> + Many field are optional in the dialog. Here is an explanation for + them. For each, we will also present the corresponding tag + needed to enhance a given Sysv script. Both dropins and + Sysv init script are supported by the same engine in Linuxconf. + + <sect1>Package name + <p> + + Simply provide a name. Each dropin has a unique name. All dropins + are stored as ASCII file in <tt>/etc/linuxconf/control</tt>. + The name is used as a key for various other services such as + + <itemize> + <item>System profile versioning + <item>Multiple machine management + <item>Control service activity + </itemize> + + + <sect1>Dropin revision + <p> + Currently unused, enter a 1 there. + + <sect1>Package's description + <p> + Enter one short line of text explaining what this package is doing. + Keep it short, as it will be used to build menus and dialogs. + + <sect1>start command + <p> + Provide the complete command (with argument required to start the + package or initialize it. + + <sect1>Stop command + <p> + This field is optional. Supply the complete command and argument + required to stop the package. If this field is empty, Linuxconf + will use the process name and kill that process. See below + + <sect1>Reload command + <p> + This field is optional. Supply the complete command and argument + required to restart or reinitialize a package. If this field is empty + Linuxconf will generate a stop and a start command. + + <sect1>Probe command + <p> + This field is optional and only required for complex packages. + Linuxconf does various test, comparing the age of the processes + associated with a package against the revision date of the + configuration files. If the configuration file are newer, Linuxconf + trigger a reload command (or a stop/start sequence) on the package. + + Some package have complex configuration file and they can't be + enumerate in the dropin. Or their state is influenced by other factor. + The probe command let a package decide if it must be restart, stop, + or started. + + The probe command is only the path of the command. Linuxconf will call + it with a single argument "probe". The command react to this argument + by printing lines or nothing if nothing has to be done. + Each lines correspond to a specific action. The standard action + "start", "stop" and "restart" will be interpreted by Linuxconf and + it will use the supplied start, stop and reload command to perform + the action. + + The probe command may also return "unknown" (to Linuxconf) action. In + that case, the probe command itself will be called to perform + those actions. + + <sect2>Probe functionnality on Sysv script + <p> + Adding the following line to a Sysv script directs Linuxconf to + execute the script with the "probe" argument. The output + is used like the dropin. + + <tscreen><verb> + # probe: true + </verb></tscreen> + + <sect1>Boot time cleanup + <p> + This field is optional. You enter here a complete command with argument. + This command will be executed by Linuxconf at boot time, just before + poping the runlevel selector menu. The output of this command will + be logged in the "tasks before booting" section of the Linuxconf's logs. + + <sect1>Process names + <p> + This section is optional. You must enter the name of the various + processes started by the start command (persistent daemons). If you + leave this section empty, Linuxconf will compute the name of + the process from the start command itself. For example, if the start + command is + + <tscreen><verb> + /usr/sbin/foo -a -b + </verb></tscreen> + + the process name is foo. + + When supplying several process name, Linuxconf will look at all those + process names to find out if the package is up to date when compared + with its configuration files. + + <sect2>Process names with Sysv script + <p> + The following tag lets you specify the process names started by + the Sysv script. You can specify the tag multiple times. + + <tscreen><verb> + # processname: foo + </verb></tscreen> + + <sect1>PID files + <p> + This section is optional. Some package starts multiple instance of a + daemon. Linuxconf must know which one is the master and must be + monitored. Most package produce a small text file containing + the process ID of the main process of the package. This file is + generally stored in /var/run, with the extension .pid. + + A package starting several processes may have several PID files. + + <sect2>PID files with Sysv script + <p> + The following tag lets you specify the PID files associated + with the Sysv script. You can specify the tag multiple times. + + <tscreen><verb> + # pidfile: /var/run/foo.pid + </verb></tscreen> + + <sect1>Activation control + <p> + This section tells Linuxconf when the package must be started. + + <sect2>Start after package + <p> + This field is optional. You can specify a package here. There is a + help list showing all available package. Linuxconf will start or probe + the current package after the one you have entered here. + + <sect2>Start at runlevel + <p> + Linuxconf defines 3 level of networking activity: + + <itemize> + <item>No networking + <item>Client networking + <item>Server networking + </itemize> + + You define here at which run-level the package must be started. A package + started in a given run-level will be available in the following ones. + For example, if you decide to enable you package in the "client networking" + run-level, it will also be available in "server networking". + + You have control over the networking run-level at boot time and from + the control panel menu (switch network run-level). + + <sect2>Stop at run-level + <p> + In the preceding field, you decide at which run-level you start the + package. Here, you decide at which run-level it should go away. + You may also select that a package should never be killed once + it is started. + + <sect1>Config files + <p> + In that section, you must enumerate all configuration (if possible) + that affect the state of a package. For each configuration file + you may specify if the package has the ability to auto-reload it. + Auto-reloaded config files won't participate in the probing Linuxconf + is normally doing to decide if a package must be restarted. As such + auto-reloaded file may be omitted. It is a good idea nevertheless + to enumerate them here as they automatically + participate in "system profile versioning" + and "multiple machine management". + + <sect2>Config files with Sysv script + <p> + The following tag lets you specify the configuration files + which affect the stat of a package. You can specify the tag + multiple times. Optionally, each configuration file is followed + by the keyword autoreload + + <tscreen><verb> + # config: /etc/foo.conf [ autoreload ] + </verb></tscreen> + + + <sect1>Comments + <p> + You can enter few comments about this package. This is only as reference. + Linuxconf does not use those, nor show them anywhere else. + + <sect>Why are they two entries to edit the addons + <p> + There is one menu called "Override Linuxconf's addons", while the + other is called "Create Linuxconf's addons". Both seems to point + to the same menu. There is a very small but important difference: + + The "Create" menu is used to edit the addon file in + <tt>/etc/linuxconf/control</tt>. The "Override" menu is used to + edit the same file, but the changes are not stored in the file + itself, but in the <tt>/etc/conf.linuxconf</tt> file. So the + "Override" menu is used to do local changes. The "Create" menu + is used to manipulate the addon directly. + + If you do not intend to distribute any dropins, the difference is + mooth. Always use the "Create" menu. + + </article> + diff -rc2P -x *.bak -x *~ -x *.help -x *.html -x Makefile linuxconf-1.10r3/help.files/sources/redhat/FILE_LIST /tmp/linuxconf-1.10r4/help.files/sources/redhat/FILE_LIST *** linuxconf-1.10r3/help.files/sources/redhat/FILE_LIST Wed Dec 31 19:00:00 1969 --- /tmp/linuxconf-1.10r4/help.files/sources/redhat/FILE_LIST Sat Feb 14 15:12:36 1998 *************** *** 0 **** --- 1,3 ---- + network + keyboard + clock Only in linuxconf-1.10r3/help.files/sources/samba: FILE_LIST diff -rc2P -x *.bak -x *~ -x *.help -x *.html -x Makefile linuxconf-1.10r3/help.files/sources/wuftpd/FILE_LIST /tmp/linuxconf-1.10r4/help.files/sources/wuftpd/FILE_LIST *** linuxconf-1.10r3/help.files/sources/wuftpd/FILE_LIST Wed Dec 31 19:00:00 1969 --- /tmp/linuxconf-1.10r4/help.files/sources/wuftpd/FILE_LIST Sat Feb 14 15:12:36 1998 *************** *** 0 **** --- 1,3 ---- + rootdir + virtual + wuftpd