Linuxconf's add-ons The standard way to add custom startup procedures on a system is by editing a script or batch file. In UNIX, this is done by adding com- mands in the rc.local script. Unfortunately, this has many limita- tions. The Linuxconf add-ons, as well as the enhanced SysV init scripts, provide a better alternative. The add-ons are also called dropins. 11.. SSyyssVV iinniitt ssccrriipptt oorr LLiinnuuxxccoonnff''ss aadddd--oonnss Both offer the same functionality, but setting up a dropin is easier (somce there is a user interface for it). Be aware that at this time, the SysV init script (UNIX System V style) shipped by all distributions is very limited in functionality. The following document shows how you can enhance the current script you have: http://dns.solucorp.qc.ca/linuxconf/tech/sysvenh 11..11.. AAnn aadddd--oonn wwiitthh tthhee ssaammee nnaammee aass aa SSyyssVV ssccrriipptt 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 commands by calling the SysV script. This is an easy way to enhance a SysV script without touching it, and also keeping it compatible in case of an upgrade. 22.. ttaasskkss A dropin simply enumerates how to start, stop and restart a package. It also provides information so Linuxconf can effectively decide the action to execute (start, stop, or restart). 33.. FFiieellddss ooff tthhee ddiiaalloogg Many fields 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 scripts are supported by the same engine in Linuxconf. 33..11.. PPaacckkaaggee nnaammee Simply provide a name. Each dropin has a unique name. All dropins are stored as an ASCII file in /etc/linuxconf/control. The name is used as a key for various other services such as +o System profile versioning +o Multiple machine management +o Control service activity 33..22.. DDrrooppiinn rreevviissiioonn Currently unused, enter a 1 there. 33..33.. PPaacckkaaggee ddeessccrriippttiioonn 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. 33..44.. SSttaarrtt ccoommmmaanndd Provide the complete command (with argument) required to start the package or initialize it. 33..55.. SSttoopp ccoommmmaanndd 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. 33..66.. RReellooaadd ccoommmmaanndd 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. 33..77.. PPrroobbee ccoommmmaanndd This field is optional and is only required for complex packages. Linuxconf does various tests, by comparing the age of the processes, associated with a package, against the revision date of the configuration files. If the configuration files are newer, Linuxconf triggers a reload command (or a stop/start sequence) on the package. Some packages have complex configuration files and they can't be enumerated in the dropin, or their state is influenced by other factors. The probe command lets a package decide if it must be restarted, stopped, or started. The probe command is only the path of the command. Linuxconf will call it with a single argument "probe". The command reacts to this argument by printing lines, or does nothing if nothing has to be done. Each line corresponds to a specific action. The standard actions "start," "stop" and "restart" will be interpreted by Linuxconf, and it will use the supplied start, stop and reload commands to perform the action. The probe command may also return an "unknown" (to Linuxconf) action. In that case, the probe command itself will be called to perform those actions. 33..77..11.. PPrroobbee ffuunnccttiioonnaalliittyy oonn aa SSyyssVV ssccrriipptt 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. # probe: true 33..88.. BBoooott ttiimmee cclleeaannuupp This field is optional. You enter a complete command with arguments. Linuxconf will execute this command at boot time (just before popping the runlevel selector menu). The output of this command will be logged in the "tasks before booting" section of the Linuxconf's logs. 33..99.. PPrroocceessss nnaammeess 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 each process from the start command itself. For example, if the start command is /usr/sbin/foo -a -b the process name is foo. When supplying several process names, Linuxconf will look at all those process names to find out if the package is up-to-date when compared with its configuration files. 33..99..11.. PPrroocceessss nnaammeess wwiitthh SSyyssVV ssccrriipptt The following tag lets you specify the process names started by the SysV script. You can specify the tag multiple times. # processname: foo 33..1100.. PPIIDD ffiilleess This section is optional. Some packages start multiple instances of a daemon. Linuxconf must know which one is the master and must be monitored. Most packages 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. 33..1100..11.. PPIIDD ffiilleess wwiitthh SSyyssVV ssccrriipptt The following tag lets you specify the PID files associated with the SysV script. You can specify the tag multiple times. # pidfile: /var/run/foo.pid 33..1111.. AAccttiivvaattiioonn ccoonnttrrooll This section tells Linuxconf when the package must be started. 33..1111..11.. SSttaarrtt aafftteerr ppaacckkaaggee This field is optional. You can specify a package here. There is a help list showing all available packages. Linuxconf will start or probe the current package after the one you have entered. 33..1111..22.. SSttaarrtt aatt rruunnlleevveell Linuxconf defines three levels of networking activity: +o No networking +o Client networking +o Server networking Here you're defining at which runlevel the package must be started. A package started in a given runlevel will be available in the following ones. For example, if you decide to enable your package in the "client networking" runlevel, it will also be available in "server networking." You have control over the networking runlevel at boot time and from the control panel menu (switch network runlevel). 33..1111..33.. SSttoopp aatt rruunnlleevveell In the preceding field, you decided at which runlevel you started the package. Here, you decide at which runlevel it should go away. You may also select that a package should never be killed once it is started. 33..1122.. CCoonnffiigg ffiilleess In this section, you must enumerate all configuration files (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 the file. Auto-reloaded config files won't participate in the probing Linuxconf is normally doing to decide if a package must be restarted. As such, the auto-reloaded files 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." 33..1122..11.. CCoonnffiigg ffiilleess wwiitthh SSyyssVV ssccrriipptt The following tag lets you specify the configuration files which affect the state of a package. You can specify the tag multiple times. Optionally, each configuration file is followed by the keyword autoreload: # config: /etc/foo.conf [ autoreload ] 33..1133.. CCoommmmeennttss You can enter few comments about the package. This is only for reference. Linuxconf does not use or display them. 44.. WWhhyy aarree tthheerree ttwwoo eennttrriieess ttoo eeddiitt tthhee aadddd--oonnss?? One menu is called "Override Linuxconf's addons," while the other is called "Create Linuxconf's addons." Both seem to point to the same menu. There is a very small but important difference: The "Create" menu is used to edit the add-on file in /etc/linuxconf/control. The "Override" menu is used to edit the same file, but the changes are not stored in the file itself, but in the /etc/conf.linuxconf file. So the "Override" menu is used to do local changes. The "Create" menu is used to manipulate the add-on directly. If you do not intend to distribute any dropins, the difference is moot. Always use the "Create" menu.