Linux Solutions

Welcome to the tutorial guide. The tutorial will provide advise and guidance on system configuration with environment directories and files.

Environment Directories
It is good to understand what are environment directories. The environment directories are special directories that contain configuration items for particular services. An environment directory is particularly useful with the chpst tool to set environment variables for run scripts and other scripts. Please note that the environment directories are more secure than sysconfig files as, usually, a sysconfig file is sourced from a shell script. Sysconfig files are supposed to be configuration files that set variables for a script to use. An example is provide below:
$ cat test.sh
#!/bin/sh

echo “pre”
. ./test.sysconfig
echo $FOO
echo “post”
$ cat test.sysconfig
# some comment
FOO=”hello”
echo test
$ sh test.sh
pre
test
hello
post
By using environment directories where a single file corresponds to a variable name and the contents of the file are the contents of the variable is much safer and prevents these problems. For example:
$ cat test.sh
#!/bin/sh

echo “pre”
FOO=`cat FOO|head -1`
echo $FOO
echo “post”
$ cat FOO
hello
echo foo
$ sh test.sh
pre
hello
post
A user will note that there is no unexpected code execution and the code is much cleaner. Annvix is slowly starting to move away from sysconfig files to the much-preferred environment directory format for configuration. A number of services already utilize environment directories.
A user should note that an environment file can contain only one line. This line is the sole content of the variable. Any lines beyond the first line are completely ignored.
runit
The /etc/sysconfig/env/runit directory controls some aspects of runit shutdowns and contains the following files:
• CTRLALTDEL_TIMEOUT: the number of seconds to wait after receiving the keycode CTRL-ALT-DEL to initiate the system reboot (default: 14)
• GETTY_TIMEOUT: the number of seconds to wait for getties to exit during a shutdown or reboot before killing them (default: 14)
• STAGE_3_TIMEOUT: the number of seconds to wait for all supervised services to exit during a shutdown or reboot before killing them (default: 180)
tcpsvd
The /etc/sysconfig/env/tcpsvd directory contains files that are the default settings for tcpsvd-controlled services (such as sshd or rsync):
• HOSTNAME: the hostname of the system (default: the system hostname; this file is automatically generated each boot)
• IP: the IP address to bind to (default: 0; bind to all available IP addresses)
• MAX_BACKLOG: the number TCP SYNs allowed to be backlogged (default: 20)
• MAX_CONN: the number of connections to handle simultaneously (default: 20)
• MAX_PER_HOST:the number of connections to handle simultaneously from the same IP address (default: 5)
Note that these are system-wide defaults. Services that use tcpsvd can be individually configured via local environment directories (ie. /service/sshd/env).
network
The /etc/sysconfig/env/network directory contains files that impact networking defaults. These were originally defined in /etc/sysconfig/networking:
• HOSTNAME: the system hostname to set at each boot
• GATEWAY: the IP address of the system’s gateway
clock
The /etc/sysconfig/env/clock directory contains files that impact the system clock settings. These were originally defined in /etc/sysconfig/clock:
• UTC: whether or not the computer clock is set to UTC time; if yes (or true) then the system is set to UTCl if no (or false) then the hardware clock is set to local time (default: no)
• ZONE: the timezone the computer is in (i.e. MST7MDT or America/Edmonton)
USB
The /etc/sysconfig/env/usb directory contains files that impact what the usb initscript will load (if anything). These were originally defined in /etc/sysconfig/usb:
• USB: whether or not to enable USB support (yes or no; default: yes)
• MOUSE: whether or not to enable USB mouse support (default: no)
• KEYBOARD: whether or not to enable USB keyboard support (default: no)
• STORAGE: whether or not to enable USB mass storage support (default: no)
• PRINTER: whether or not to enable USB printer support (default: no)
ulimits
The /etc/sysconfig/env/ulimits directory contains files that impact the default ulimit settings. These were originally defined in /etc/sysconfig/ulimits:
• MAX_USER_PROCS: the maximum number of processes per user (default: 100)
• MAX_DATASEG_SIZE: the maximum data segment size in bytes (default: 12288)
• MAX_OPEN_FILES: the maximum number of open files per user (default: 256)
kudzu
The /etc/sysconfig/env/kudzu directory contains files pertaining to kudzu settings. These were originally defined in /etc/sysconfig/kudzu:
• SAFE: whether or not to to run kudzu in “safe” mode which disables serial port probing, DDC monitor probing, and PS/2 probing (default: no)
hdparm
The /etc/sysconfig/env/hdparm directory contains sub-directories named after a device, such as /etc/sysconfig/hdparm/hda in which are defined the hdparm options to be passed at boot for that particular device. This replaces the /etc/sysconfig/harddiskhdX files.
• OPTS: the hdparm options to use for the device
By default, this directory is empty so there are no optimizations being done on hard drives. If a user wants to enable hdparm optimizations on a particular device, then he/she can run following code:
# mkdir /etc/sysconfig/env/hdparm/hde
# echo “-d1 -m16 -X67″ >/etc/sysconfig/env/hdparm/hde/OPTS
For all of the options you can pass to hdparm, check the hdparm(8) manpage.
nfs
There are a number of NFS-related services and they share the same environment directory. For this reason, the environment directory is located at /etc/sysconfig/env/nfs rather than in an ./env subdirectory of any given service. These were originally defined in /etc/sysconfig/nfs:
• MOUNTD_OPTS: any additional options to pass to mountd
• MOUNTD_PORT: force mountd to use a given port rather than a random one assigned by portmapper (i.e. 4002)
• MOUNTD_TCP: whether or not to advertise TCP for mount (yes/no)
• MOUNTD_NFS_V3: whether or not to use NFSv3 (yes/no/auto)
• MOUNTD_NFS_V2: whether or not to use NFSv2 (yes/no/auto)
• MOUNTD_OPEN_FILES: the number of open file descriptors to use (default: 128)
• RPCNFSDCOUNT: the number of instances of rpc.nfsd to spawn (default: 8; 16 or more may be required to handle heavy client traffic)
• RPCNFSDOPTIONS: additional options to pass to rpc.nfsd
• LOCKD_TCPPORT: force lockd to use a given TCP port (i.e. 4001)
• LOCKD_UDPPORT: force lockd to use a given UDP port (i.e. 4001)
• STATD_PORT: force statd to use a given port (i.e. 4000)
• STATD_OUTPORT: force statd to use a given outbound port (i.e. 4000)
• STATD_HOSTNAME: set the hostname for statd
• SECURE_NFS: whether or not to use secure NFSv4 (yes/no; default: no)
• SECURE_NFS_MODS: modules to use with secure NFSv4 (default: “des rpcsec_gss_krb5″)
• RPCGSSD_OPTS: additional options to pass to gssd
• RPCIDMAPD_OPTS: additional options to pass to idmapd
• RPCSVCGSSD_OPTS: additional options to pass to svcgssd
If a user wants to use the rpc.rquotad daemon to export quota information, you can use the following additional option:
• RQUOTAD_PORT: set the fixed port for a remote quota server
It is recommended that a user should install the quota package and also add the service (i.e. srv –add rpc.rquotad) for it to be used. NFS runs fine with or without rpc.rquotad so if a user wants to export that information then he/she should install quota and add the service.
Application Environment Directories
Environment directories are also used by some applications to setup how they are executed. These applications are typically daemon services.
amd
The environment directory /var/service/amd/env contains the following files:
• MOUNTPTS: defines alternate mount locations (the -a option to amd) (default: -a /net)
• AMD_OPTS: additional options to pass to amd
mysqld
The enviroment directory /var/service/mysqld/env contains the following files:
• MYSQLD_OPTS: Optional arguments to pass to mysqld (default: –skip-networking)
• DATADIR: The data directory for mysqld’s databases (default: /var/lib/mysql)
• LOG: The filename for the log file that mysqld will log all connections and received SQL statements to. If this is empty, no extra logging will be done (default: empty)
portmap
The environment directory /var/service/portmap/env contains the following files:
• BIND_HOST: The host to which portmap should explicitly listen to; this can be an IP address or hostname. If this is empty, the default is for portmapper to listen to everything (default: empty)
dhcpd
The environment directory /var/service/dhcpd/env contains the following files:
• CONFIGFILE: The configuration file to use (default: /etc/dhcpd.conf
• LEASEFILE: The lease file to use (default: /var/lib/dhcp/dhcpd.leases
• OPTIONS: extra options to pass to dhcpd (default: empty)
• INTERFACES: the interface (i.e. eth0) for dhcpd to bind to; if empty, listen to them all (default: empty)
By default, dhcpd is executed via the run script as:
/usr/sbin/dhcpd -d -user dhcp -group dhcp -cf ${CONFIGFILE} -lf ${LEASEFILE} ${OPTIONS} ${INTERFACES}
System Configuration with /etc/sysconfig
A user should note that the /etc directory is home to many configuration files. For example, the /etc/sysconfig directory contains a number of miscellaneous files that are sourced by various run and init scripts.
If a user wants to edit configuration files, then a user can use vim or any other text editor that a user has installed by running following command:
# cd /etc/sysconfig
# vim installkernel
Sysconfig Files
hwconf
This file is created by kudzu and lists all of the devices installed on the system, including moule information (the driver keyword), a description, vendor idenfication information, etc. This file is not meant to be user-modified.
i18n
This file sets the locale information on the system. Since Annvix only uses the english locale as of 2.0-RELEASE, this file should not be altered (i.e. changing the LANG option to something other than “en_US” probably will not accomplish what you want since all non-english locale files are removed at build).
installkernel
This file controls some aspects of how the installkernel helper script works. The defaults are sufficient for most and the file is heavily commented to show what each option does.
Configuring Networking
If a user wants to configure networking then he/she should note that there are no tool available to ease the configuration.
Please note that the site-wide configuration that impacts all interfaces is done via the /etc/sysconfig/env/network environment directory. This directory contains exactly two files: HOSTNAME and GATEWAY. Per-device configuration uses traditional configuration files, similar to Mandriva and other Linux distributions.
The configuration files that manage network configuration for specific devices (such as eth0) are located in /etc/sysconfig/network-scripts. Each device and IP alias has it’s own configuration file, such as ifcfg-eth0 for configuration of eth0, and ifcfg-eth0:0 for the first IP alias of eth0 (or eth0:0).

Dynamic IP Configuration
Dynamic IP-assigned devices are those that use protocols like DHCP. An example ifcfg-eth0 file for a dynamically-assigned IP on eth0 is provided below:
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
MII_NOT_SUPPORTED=yes
This indicates that the device is eth0, the boot protocol is DHCP, that the interface is to start at boot, and does not try to use ifstatus to see if the network link is up.
Static IP Configuration
A static IP-assigned device is one that will retain it’s IP address constantly. With a static IP, unlike a dynamic one, a use will need to provide more information, such as the netmask, broadcast address, etc. An example ifcfg-eth1 file for a statically-assigned IP on eth1 is provided below:
DEVICE=eth1
BOOTPROTO=static
IPADDR=10.0.10.100
NETMASK=255.0.0.0
NETWORK=10.0.0.0
BROADCAST=10.255.255.255
ONBOOT=yes
MII_NOT_SUPPORTED=yes
By looking at the code, it can be seen that the device is eth1, the boot protocol is static, the IP address is 10.0.10.100, the netmask is 255.0.0.0, the network address is 10.0.0.0, the broadcast address is 10.255.255.255, the device is to start at boot, and does not try to use ifstatus to see if the network link is up.
IP Aliases
If a user wants to have eth1:0 assigned a static IP address of 10.0.10.101 with ifcfg-eth1, the ifcfg-eth1:0 file would contain following:
DEVICE=eth1:0
IPADDR=10.0.10.101
If a user wants have eth0:1 have a static IP address, and eth0 is dynamic, then he/she would need to indicate the appropriate information. Please note that if the netmask, network address, etc. settings are the same they can be omitted, but for that a user will have to indicate that eth0:1 is static, as opposed to eth0 (which is dynamic). In order to do this, a user will run following command:
DEVICE=eth0:1
BOOTPROTO=static
IPADDR=192.168.4.100
This would statically-assign the IP address 192.168.4.100 to eth0:1, while eth0 itself remains dynamic.
The network configuration also uses some envdir settings from /etc/sysconfig/env/network/ that will need to be aware of, such as setting the default gateway address, gateway device, hostname, and whether or not networking is to be enabled automatically.
Network Options for ifcfg Files
The following keyword options are available for use in ifcfg-ethX files:
• DEVICE: the name of the physical device, or in the case of IP alias devices, the logical name (i.e. eth0 or eth1:0)
• IPADDR: the IP address (if statically assigned)
• NETMASK: the netmask
• ONBOOT: whether or not to start the device at boot (’yes’ or ‘no’)
• BOOTPROTO: the boot protocol to use (’dhcp’ or ’static’)
• MTU: the default MTU for this device
• WINDOW: the default window for routes from this device
• SRCADDR: use the specified source address for outgoing packets on this device
• MII_NOT_SUPPORTED: if set, do not try to use ifstatus to detect if the link is up
• METRIC: if set, assign the route associated with this interface to this metric, using ifmetric
• HWADDR: the ethernet hardware address for this device
The following keyword options are only valid for IP aliases:
• ONPARENT: whether or not to bring up the device when the parent device is brought up (’yes’ (default) or ‘no’)
If a user followed advise and guidance as provided in this tutorial guide then he/she would have learnt about Environment directories and Application Environment directories.

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on installing packages. Annvix uses apt-get to install RPM packages available in the Annvix repositories. When a user wants to first install Annvix, he/she is given the choice of which mirror site to use to download package updates from.

Apt Repository Setup
Please note that a typical sources.list file will look like:
rpm ftp://ftp.ibiblio.org/pub/linux/distributions/annvix/releases x86_64 2_0_RELEASE 2_0_RELEASE-doc
This tells apt that a user has an “rpm” repository defined, with the URL and path of the repository being ftp://ftp.ibiblio.org/pub/linux/distributions/annvix/releases. The next bit identifies the architecture of the repository which can be either “i586″ or “x86_64″.

Repository names can be versioned, as in the above example, or can be “current” (for the latest -CURRENT release) or “release” (for the latest -RELEASE release). Using a versioned repository, however, ensures that once a new -RELEASE version comes out, that a user is not automatically upgrading to it.

Apt Basics
In order to update the package index, a user can use:
$ sudo apt-get update

This assumes that a user will provide apt privileges via sudo; if not, these commands will need to be executed as the root user. If a user wants to upgrade new packages, then he/she can use:
$ sudo apt-get upgrade

This will only install new packages that already exist on the system, but will not install any new packages. This is a safe way to update. If a user wants to install packages that pull in new packages (such as when upgrading the kernel), then he/she can use:
$ sudo apt-get dist-upgrade

This will do an upgrade, and will also install any updates that require new packages to satisfy dependencies. Using dist-upgrade is the only way that packages currently installed that require packages that are not currently installed will be upgraded.

In order to install new packages, a user can use:
$ sudo apt-get install [package]

This will install package “package” any any dependencies it requires and if a user wants to install exim-db then he/she should use:
$ sudo apt-get install exim-db

Please note that a user can provide as many package names as many as he/she likes to the install command; apt-get will install each one and their associated dependencies.
If a user wants to remove a package then he/she can use following command:
$ sudo apt-get remove [package]

Documentation Packages
All documentation is provided in “-doc” sub-packages. If a user wants to install a package, say exim on any other distribution, then he/she can get documentation associated with that package in /usr/share/doc/exim-4.66 (or whatever the version number happens to be). With Annvix, binary packages come with no documentation.
In order to install documentation, a user should specifically install the “-doc” package, which also implies that a user has the “-doc” repository available. To install the exim documentation, a user can use:
$ sudo apt-get install exim-doc

The documentation ends up in /usr/share/doc/[package]-[version].

Packages Available in Annvix
If a user wants to know what packages are provided in Annvix then he she can do so by browsing the FTP mirrors or looking at the Release Notes for a specific version, and then looking at the package list. For example, if a user wants to view the 2.0-RELEASE package list to see what packages are available for that version to install.

Creating Packages Via Ports
Similar to FreeBSD’s ports, Mandriva’s contribs, and other similar repositories, Annvix’s ports collection is a (slowly growing) collection of packages that are not part of the default Annvix main package base. These are “third-party” additions that extend the functionality of Annvix but also don’t burden the development team with maintenance. Annvix ports are packages that may be of interest to very few and may also be maintained by individuals who are not necessarily part of the development team. Examples of ports packages include the joe, various DJB programs such as djbdns, and other small utilities like pine and tree.

Ports are source-based; the only thing provided are a manifest (md5sum list) of source files, patches, and an RPM spec file. The ports builder program is a script that downloads the appropriate source files and, using the included patches and RPM spec, builds an RPM file that is in turn placed in an apt repository which can then be installed from. The concept is similar to that of Gentoo’s portage.

The builder script is fairly basic and attempts to be moderately smart and install packages required to properly build a package, but it is not yet intelligent enough to build another package (or set of packages) that may be required to build the requested package. For instance if package “bar” requires package “libfoo” (which is not in main, but is in ports), it will just error out and a user will need to manually build “libfoo” first. Then a user can proceed to build “bar”. builder needs to be extended at some point to do this for a user. It also needs to be able to provide RPM signatures on generated files for integrity purposes; it does not yet do this.

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about how to install packages in Annvix.

Welcome to the tutorial guide. The tutorial will provide guidance and instructions about the system startup and shutdown and also the bootscripts and how to manage the scripts. Annvix uses “init” to startup and shutdown. The “init” system is a hybrid system which is based on Gentoo’s init system. Annvix uses runit to manage things.

Please note that Linux system uses SysVinit, which is based on the SysV scheme and is made up of a set of scripts that setup the system, mount filesystems, and in turn call a number of other scripts which are known as initscripts that start services. These initscripts can be called independently to start and stop individual services. At system shutdown, these scripts shutdown all running services, unmount filesystems, and then halt or reboot the system.

Annvix, using runit, starts and stops services with run scripts, rather than initscripts. Initscripts are still used for one-time services and non-daemon services, such as setting up the firewall, calling kudzu to detect hardware, starting the network, etc. The SysV init scheme calls for the use of “runlevels”. When the Linux kernel boots, it mounts the root filesystem and then typically executes a script called rc.sysinit which sets up the basic system configuration and usually checks the filesystems. It then calls a script called rc with an argument; this argument is the runlevel to execute. Different Linux distributions may use a variation of the following, but this is by-and-large a typical runlevel scheme:
• 0: complete machine stop
• 1: single-user mode
• 2: multi-user mode
• 3: multi-user mode, with networking
• 4: unused
• 5: similar to runlevel 3, but starts the graphical login interface, for use with X
• 6: restart

Annvix does not use numbered runlevels, but it uses named runlevels which allow for much more customisation, although it shouldn’t really be necessary to change the defaults. Please note that Annvix comes with the following named runlevels:

• default: multi-user mode, with networking
• single: multi-user mode, without networking and no services starting (other than cron, mingetty, and socklog)

When the bootloader executes the kernel to load, it also uncompresses a ramdisk image, which contains modules to load in order to mount the root filesystem and a script called linuxrc which creates some temporary partitions, mounts required filesystems, and so forth. Once this script is done, and the root filesystem is mounted, it executes /sbin/init, which is provided by the runit package. init is the first process of any Linux system, and with runit, if init is the first process, it replaces itself with /sbin/runit(8) which then executes the script /etc/runit/1 to start “stage 1″. Runit operates in three stages:
• 1: one-time startup tasks
• 2: the normal operating system; if this stage exits abnormally it will be restarted
• 3: halt/reboot

One stage 1 is started by executing /etc/runit/1, that script then executes /sbin/rc with a single argument: 1. This argument tells rc that the system is starting; an argument of 0 would tell rc that the system is shutting down. The rc script does all the heavy lifting of mounting other filesystems, performing filesystem checks, loading kernel modules to interact with different hardware devices, and so forth. The rc script also calls the traditional “initscripts” found in the runlevel’s definition directory: /etc/runlevels/default for the “default” runlevel. When rc exits and control is passed back to the stage 1 script, stage 1 completes and stage 2 begins.

Stage 2, which is executed by /etc/runit/2, starts the supervised services found in the runlevel’s service directory: /etc/runlevels/default/service for the “default” runlevel. Each runlevel has it’s own service directory; the rc script sets /service as a symlink to the runlevels service directory at boot.
Stage 3 is called when a superuser calls the halt(8), reboot(8), or shutdown(8) commands. This will exit stage 2 and call /etc/runit/3, which signals runit to shutdown all supervised services and then calls the rc script with the single argument ‘0′.

Managing Initscripts with rc-update
Traditional Linux distributions will use programs like service to start/stop and otherwise manage services (Annvix uses srv(8)), and chkconfig to add or remove services from a particular runlevel. Annvix does not use chkconfig because chkconfig is very much tied to number-based runlevels. Instead, Annvix uses a modified version of Gentoo’s rc-update script.
If a user wants to see what initscripts are called for each runlevel, then he/she can look in /etc/runlevels/[runlevel] or use rc-update:
# rc-update -s
apparmor | default
iptables | default
keytable | default
kheader | default
kudzu | default
netfs | default
network | default
rc.local | default single

This will show a user that the initscript /etc/init.d/rc.local is called in both runlevels “default” and “single” and the rest of the supplied initscripts are executed only in the “default” runlevel.
If a user wants to add an initscript to a runlevel, then he/she can use the “add” command, which is provided below:

# rc-update add iptables single
iptables added to runlevel single

After a user runs this command, it will add the /etc/init.d/iptables initscript to the “single” runlevel. A user can also view this by looking in /etc/runlevels/single/:
# ls -al /etc/runlevels/single/
total 4
drwxr-x— 3 root admin 54 Mar 5 23:47 .
drwxr-xr-x 4 root root 33 Mar 30 2007 ..
lrwxrwxrwx 1 root root 20 Mar 5 23:43 03iptables -> /etc/init.d/iptables
lrwxrwxrwx 1 root root 20 Mar 5 23:47 99rc.local -> /etc/init.d/rc.local
drwxr-x— 2 root admin 4096 Dec 29 21:32 service

If a user wants to remove an initscript from some runlevel, then he/she can use the “del” command which is provided below:

# rc-update del iptables single
‘iptables’ removed from the following runlevels: single

Looking at the runlevel directory, a user will note the symlink with a numbered prefix. This is similar to SysVinit, Annvix uses this to order which scripts are executed. If a user views the SysV system then he/she will be able to view following:
$ ls -l /etc/rc.d/rc3.d/
total 0
lrwxrwxrwx 1 root root 20 Jan 2 2007 K66messagebus -> ../init.d/messagebus*
lrwxrwxrwx 1 root root 19 Jan 2 2007 K68rpcidmapd -> ../init.d/rpcidmapd*
lrwxrwxrwx 1 root root 17 Jan 2 2007 K69rpcgssd -> ../init.d/rpcgssd*
lrwxrwxrwx 1 root root 20 Jan 2 2007 K69rpcsvcgssd -> ../init.d/rpcsvcgssd*
lrwxrwxrwx 1 root root 16 Jan 2 2007 K72autofs -> ../init.d/autofs*
lrwxrwxrwx 1 root root 19 Jan 2 2007 K95harddrake -> ../init.d/harddrake*
lrwxrwxrwx 1 root root 18 Jan 2 2007 S03iptables -> ../init.d/iptables*
lrwxrwxrwx 1 root root 14 Jan 2 2007 S04acpi -> ../init.d/acpi*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S10network -> ../init.d/network*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S11portmap -> ../init.d/portmap*
lrwxrwxrwx 1 root root 16 Jan 2 2007 S12syslog -> ../init.d/syslog*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S13partmon -> ../init.d/partmon*
lrwxrwxrwx 1 root root 15 Jan 2 2007 S14acpid -> ../init.d/acpid*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S14nfslock -> ../init.d/nfslock*
lrwxrwxrwx 1 root root 15 Jan 2 2007 S25netfs -> ../init.d/netfs*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S29numlock -> ../init.d/numlock*
lrwxrwxrwx 1 root root 14 Sep 12 23:01 S30nscd -> ../init.d/nscd*
lrwxrwxrwx 1 root root 13 Jan 2 2007 S40atd -> ../init.d/atd*
lrwxrwxrwx 1 root root 16 Jan 2 2007 S40smartd -> ../init.d/smartd*
lrwxrwxrwx 1 root root 14 Dec 19 10:45 S55sshd -> ../init.d/sshd*
lrwxrwxrwx 1 root root 14 Jan 2 2007 S56ntpd -> ../init.d/ntpd*
lrwxrwxrwx 1 root root 20 Jan 2 2007 S56rawdevices -> ../init.d/rawdevices*
lrwxrwxrwx 1 root root 13 Jan 2 2007 S60nfs -> ../init.d/nfs*
lrwxrwxrwx 1 root root 18 Jan 2 2007 S75keytable -> ../init.d/keytable*
lrwxrwxrwx 1 root root 17 Mar 10 2007 S80postfix -> ../init.d/postfix*
lrwxrwxrwx 1 root root 17 Sep 6 18:25 S85proftpd -> ../init.d/proftpd*
lrwxrwxrwx 1 root root 15 Jan 2 2007 S90crond -> ../init.d/crond*
lrwxrwxrwx 1 root root 17 Jan 2 2007 S95kheader -> ../init.d/kheader*
lrwxrwxrwx 1 root root 11 Jan 2 2007 S99local -> ../rc.local*

A user will notice that each script can have a different prefix; for example, the S prefix is for Start and the K prefix is for Kill — in relation to the service. In this way, services are ordered in how the start and stop. Annvix only concerns itself with how services are started, and calls stop for the initscripts in alphabetical order. Because Annvix does not handle or support changing runlevels “on the fly” there is no need to be concerned with ordered stops, so Annvix does not use a lettered/numeric prefix as other Linux distributions.

One thing to note is that if the special “stop” initscript exists, it will be executed before any other initscripts are called. This script is called /etc/init.d/rc.local-stop, and is a counterpart to /etc/init.d/rc.local which is only executed on start (and never executed on stop). Therefore, if a user wants to start something in rc.local and wants to ensure a clean shutdown, then he/she can use rc.local-stop to stop it or do whatever cleanup is required.

Package Management
Annvix uses the RPM package management system to handle binary packages, and also uses RPM packages as the resulting package format for the ports system. RPM is a robust packaging format, and with good frontends such as apt and urpmi, the stigma attached to RPM packages is largely moot.

If you followed the tutorial guide then you would have learnt about the the system startup and shutdown for Annvix.

Welcome to the tutorial guide. The tutorial will provide guidance and instructions on file system organisation which will include the function of major filesystem/directory on the system and also how they are organised.

A user will be aware that the Annvix filesystem is largely similar to other UNIX-based and Linux systems. This topic describes the function of each major filesystem or directory on the system and how they are organized.
/
The root directory (/) is the top-level directory of any Linux filesystem. Everything falls below root. Don’t confused the root directory with the root user’s directory. The root user has his own home directory, much like regular user accounts, in /root.
Think of / as the tree, and each directory and sub-directory below it are branches and leaves. / is the trunk of the tree, the single most important directory below which everything else lives.
/bin
The /bin directory is where essential binary files (programs) live. The /bin directory should be on the same partition as the / filesystem because most of the tools in /bin are required to boot the system and will be needed before other filesystems may be mounted during boot. The /bin directory is largely static and should never change except when packages are upgraded. This directory should not be shared to other systems (via samba, NFS, etc.).
/boot
The /boot directory is where kernels, ramdisks (initrd files), and grub’s configuration file lives. This directory can be on the / root filesystem, but it is recommended to make this directory it’s own partition (typically the first partition on the first hard drive installed on the system).
/dev
The /dev directory is a special directory that should not be changed by hand. This directory contains system device files that allow you to interact with physical hardware via a filename. Files that it contains include /dev/hda (access to the master IDE drive on the primary IDE controller), /dev/null, and so forth.
/etc
The /etc directory contains configuration files related to the system and the applications installed. More often than not, to configure something about a particular application of service, the configuration file(s) will be found here. This directory must also be on the / root filesystem.
/home
The /home directory is typically where all user accounts will have their home directory, such as /home/shafkat. It is recommended to make /home it’s own partition.
/lib
The /lib directory is where shared libraries are installed that are often-used and/or used by programs in /bin. This directory should be on the / root filesystem. It also contains the kernel modules; such as /lib/modules/2.4.32-5205avx.
/media
The /media directory is used as a top-level mount point for removable media. A user should mount a USB disk here as, say, /media/usbdisk, or a CD-ROM as /media/cdrom, a floppy disk as /media/floppy, and so forth. A user should note that by default, Annvix will place entries in /etc/fstab to mount the CD-ROM and/or floppy devices here.
/root
The root user’s home directory.
/sbin
The /sbin directory contains administration files for the system and must be a part of the / root filesystem. These are files that typically are executed only by root and not regular users.
/srv
The Annvix operating system imposes almost nothing on users, including the location of where to place web files or files served by FTP. A user will know that web data would be stored in /srv/www (rather than /var/www, FTP data would be stored in /srv/ftp (rather than /var/ftp, and mail storage would be stored in /srv/mail. This can further be broken down by domain to keep things clean, consistent, and logical. An example is provided below which shows that on a system serving up “any.org” a user will have:
• /srv/www/any.org/html
• /srv/ftp/any.org
• /srv/mail/any.org/shafkat
Please note that the first directory is the webroot for the any.org website and the second directory is the root directory of FTP files served by any.org, and the last directory for storing the virtual mail for shafkat@any.org.
/tmp
Temporary files for any user are stored in /tmp. This directory is special in that, while it is writable by any user, no user can overwrite or delete another user’s files.
/usr
The /usr directory is a top-level directory for many other directories with different functions.
/usr/bin
The /usr/bin directory contains the bulk of the system’s binary files. This directory contains the files that are not essential to the startup of the system, or are administrative in nature, belong here. The major exception is binaries installed as part of a ports package or that you compile on your own.
/usr/lib
This directory contains library files, but these are library files not required by applications involved in bringing the system up to a useable state.
/usr/sbin
The /usr/sbin directory contains system administration binaries that are not needed to boot the system.
/usr/share
This directory contains read-only architecture independent data that is required by applications in /usr.
/usr/local
The /usr/local directory contains directories such as /usr/local/bin, /usr/local/sbin, /usr/local/etc, /usr/local/lib, etc. These directories serve the same function as their top-level counterparts.
/usr/local/ports
An exceptional directory is /usr/local/ports which contains all the ports-related information. The /usr/local/ports/ports directory contains the build information for ports packages, including patches, source files, and spec files. The /usr/local/ports/packages directory contains the actual builder-built ports RPM packages that can be installed via urpmi.
/var
The /var directory is used to store variable data, such as database files, process accounting files, logs, mail spools, etc.
/var/log/system
The /var/log/system directory is used to store all the system’s syslog files.

If you followed this tutorial guide, then you would have learnt about the file system organisation which included the functionality of major filesystem/directory on the system and also how they were organised.