Linuxconf's add-ons Introduction The standard way to add custom startup procedures on a system is gen- erally 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. 11.. SSyyssvv iinniitt ssccrriipptt oorr LLiinnuuxxccoonnff''ss aadddd--oonnss 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: http://www.solucorp.qc.ca/linuxconf/tech/enhsysv 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 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. 22.. ttaasskkss 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). 33.. FFiieellddss ooff tthhee ddiiaalloogg 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. 33..11.. PPaacckkaaggee nnaammee Simply provide a name. Each dropin has a unique name. All dropins are stored as 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''ss 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 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. 33..77..11.. PPrroobbee ffuunnccttiioonnnnaalliittyy oonn 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 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. 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 the 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 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. 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 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. 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 package. Linuxconf will start or probe the current package after the one you have entered here. 33..1111..22.. SSttaarrtt aatt rruunnlleevveell Linuxconf defines 3 level of networking activity: +o No networking +o Client networking +o Server networking 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). 33..1111..33.. SSttoopp aatt rruunn--lleevveell 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. 33..1122.. CCoonnffiigg ffiilleess 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". 33..1122..11.. CCoonnffiigg ffiilleess wwiitthh SSyyssvv ssccrriipptt 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 # config: /etc/foo.conf [ autoreload ] 33..1133.. CCoommmmeennttss You can enter few comments about this package. This is only as reference. Linuxconf does not use those, nor show them anywhere else. 44.. WWhhyy aarree tthheerree ttwwoo eennttrriieess ttoo eeddiitt tthhee aaddddoonnss 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 /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 addon directly. If you do not intend to distribute any dropins, the difference is mooth. Always use the "Create" menu.