Linux Solutions

Welcome to the tutorial guide. The tutorial will provide a user with advise and guidance on how to manage supervised services. Please note that Annvix uses a different means of managing daemons and services. Initscripts is a means of starting and stopping of system services. They are called as:
# /etc/init.d/script start
Or:
# service script start

There are some weaknesses associated with these initscripts. The initscripts are big and bulky and, more often than not, unnecessarily bloated. This makes them slow to start services. The problems can occur if the administrators restarts services. This will inherit variables from the current user’s shell environment. If a service stops then the service stays down. This may be good if a particular service is being configured, but can be very problematic on systems that require high availability.
Please note that a wrapper was written to handle talking to services. The wrapper script is called srv.

How to use srv?
It is good to know more about srv. srv controls services in a same way as service. If a user installs a daemon service on Annvix, it does not automatically start for a user. A user needs to explicitly enable the service before it will ever start. By default, openssh-server is installed on Annvix but, as with all daemon services, it is not started by default or even made available by default. If a user wants to obtain a list of available services, then he/she should execute following:
# srv –list

service status pid started
————————————————————-
crond up 3397 02/02/2007 12:03:45 AM
crond/log up 3366 02/02/2007 12:03:45 AM
mingetty-tty1 up 5785 02/02/2007 12:10:41 AM
mingetty-tty2 up 3302 02/02/2007 12:03:44 AM
mingetty-tty3 up 3399 02/02/2007 12:03:45 AM
mingetty-tty4 up 3332 02/02/2007 12:03:44 AM
mingetty-tty5 up 3331 02/02/2007 12:03:44 AM
mingetty-tty6 up 3362 02/02/2007 12:03:46 AM
socklog-klog up 3409 02/02/2007 12:03:45 AM
socklog-klog/log up 3408 02/02/2007 12:03:45 AM
socklog-rklog - - -
socklog-rklog/log - - -
socklog-unix up 3444 02/02/2007 12:03:45 AM
socklog-unix/log up 3443 02/02/2007 12:03:45 AM
sshd - - -
sshd/log - - -

Please note that only crond, socklog-klog, socklog-unix, and the mingetty services are available and running. These services are the only ones to start “out of the box”. A user will also be able to view that sshd is installed, but is not available. If a user wants to enable sshd, then he/she should execute following code:
# srv –add sshd
Adding service ’sshd’: …….done
# srv –list

service status pid started
————————————————————-
crond up 3397 02/02/2007 12:03:45 AM
crond/log up 3366 02/02/2007 12:03:45 AM
mingetty-tty1 up 5785 02/02/2007 12:10:41 AM
mingetty-tty2 up 3302 02/02/2007 12:03:44 AM
mingetty-tty3 up 3399 02/02/2007 12:03:45 AM
mingetty-tty4 up 3332 02/02/2007 12:03:44 AM
mingetty-tty5 up 3331 02/02/2007 12:03:44 AM
mingetty-tty6 up 3362 02/02/2007 12:03:46 AM
socklog-klog up 3409 02/02/2007 12:03:45 AM
socklog-klog/log up 3408 02/02/2007 12:03:45 AM
socklog-rklog - - -
socklog-rklog/log - - -
socklog-unix up 3444 02/02/2007 12:03:45 AM
socklog-unix/log up 3443 02/02/2007 12:03:45 AM
sshd up 5644 02/10/2007 10:25:02 AM
sshd/log up 9177 02/10/2007 10:25:55 AM
A user can note that sshd is available and running.
Retaining Status Across Reboots
If a user wants to turn down by using following code:
# srv –down sshd
then on the next reboot, sshd will stay down.
srv Options
The best source of information on srv is the manpage. Following options will summarise all the command that a user can pass to srv:
–help - lists all available commands
–list | -l ([service]) / - lists all available services or just the named service
–info | -i [service] - displays verbose information on a single service
–add | -a [service] - adds a service to /service and starts it
–del | -z [service] - removes a service from /service, stopping it first
–up | -u [service] - starts the named service
–down | -d [service] - stops the named service; on a reboot it will remain down
–restart | -r [service] - stops then starts the named service
–reload | -h [service] - restarts a service by sending it a HUP signal
The –add and –del commands are similar to those from chkconfig. The –list command is similar to chkconfig –list.
The –up and –down commands work similar to the service commands “start” and “stop” for initscripts.
The –list command will show what services are installed, which are available to be started, and what their status is by showing a “-” (available but not in /service), “up” (running), or “down” (not running).
The –info command gives extended status information on a particular service. If a user wants to check the status of sshd, then a user should use:
# srv –info sshd
Service: sshd
————————————————
Installed: Thu 01 Feb 2007 11:19:45 PM MST
RPM: openssh-server-4.5p1-6584avx
RPM Desc: OpenSSH Secure Shell protocol server (sshd)
————————————————
Managed: Yes
Status: Up
Pid: 3376
Processes:
tcpsvd(3376)-+-sshd(24424)—sshd(24426)—sh(24427)—screen(24428)—zsh(24429)
`-sshd(8785)—sshd(8787)—zsh(8788)—su(8803)—bash(8813)
Started: 729012 seconds ago
When: 02/02/2007 12:03:46 AM
Is Logged: Yes
Log Dir: /var/log/service/sshd
Log Status: Up
Log Pid: 3375
Log Started: 729013 seconds ago
Log When: 02/02/2007 12:03:45 AM

Dependencies: sshd
————————————————
Requires:
Needed By:
By using runit, the srv wrapper script makes it very easy to manage system daemons. Please note that every daemon shipped with Annvix uses srv.
Peers

srv also handles a concept called “peers”, which is an access control mechanism similar to using /etc/hosts.allow and /etc/hosts.deny. Services that use tcpsvd make use of peers to allow or deny access to those services. tcpsvd is another “super-server” similar to xinetd. It answers any connection requests, determines if the connecting system is permitted to use the service, and if so, hands it off to the appropriate program.
For example the sshd service uses tcpsvd in exactly this way. It’s run script looks like as following:
#!/bin/execlineb

/bin/fdmove -c 2 1

/bin/export PATH “/sbin:/bin:/usr/sbin:/usr/bin”

/sbin/chpst -e /etc/sysconfig/env/tcpsvd/
/sbin/chpst -e ./env/

/bin/multisubstitute {
import -D “localhost” HOSTNAME
import -D 0 IP
import -D 22 PORT
import -D 20 MAX_CONN
import -D 5 MAX_PER_HOST
import -D 20 MAX_BACKLOG
import OPTIONS
}

/sbin/tcpsvd -v -l ${HOSTNAME} -x peers.cdb -c ${MAX_CONN} -C ${MAX_PER_HOST} -b ${MAX_BACKLOG} ${IP} ${PORT}
/usr/sbin/sshd -i ${OPTIONS}

Essentially what happens here is that a number of variables are imported first from the global /etc/sysconfig/env/tcpsvd environment directory, then the service’s own ./env environment directory. The important thing to note here is the -x peers.cdb argument to tcpsvd.
This argument instructs tcpsvd to use peers information for ACLs as found in the peers.cdb file for this service. This file is a CDB copy of the contents of the ./peers directory for this service. This file is constructed every time srv is used to manage peers information for the service, by first writing the peers information to ./peers and then creating the CDB file by using the ipsvd-cdb tool.

Structure of ./peers

The peers directory is a regular directory that contains IP addresses, partial IP addresses, or hostnames with certain permissions that tell tcpsvd whether or not that IP (or hostname) is allowed to connect to the service. The catch-all file is ./peers/0, and it’s default permissions determine the default access type. This directory is essentially an ipsvd instructions directory; as such you can get more details from the ipsvd-instruct(5) manpage.

The file’s permissions determines the access to the service for that IP or hostname:
If neither the user’s read permission, nor the user’s execute permission is set for the file, the connection is closed immediately
If the file has the user’s execute permission set, ipsvd reads the contents of the file and runs /bin/sh -c ” instead of the default program given att he command line for this connection (i.e. the service itself)
If the file has the user’s read permission set, ipsvd reads the contents of the file and interprets each line as an instruction for this connection; thus allowing the connection
Essentially, to deny access to a connection, chmod 0 the file. To allow access to a connection, chmod 0644 the file. If you want to get fancy, you can have the file contain an alternate program to execute as it’s contents and chmod 0755 the file.

For instance, to disallow all connections to the sshd service, but allow connections from the 10.0.5.0 network and a single remote IP address (say 12.34.56.78), the ./peers directory would look thus:
# ls -l
total 4
———- 1 root admin 0 Dec 29 16:09 0
-rw-r–r– 1 root root 0 Feb 4 17:43 10.0.5
-rw-r–r– 1 root root 2 Nov 18 07:28 12.34.56.78

How srv handles peers

Manually manipulating ./peers is fine, but srv makes it simple to do basic ACLs. It doesn’t do things such as executing alternate programs based on the connection, but it will manipulate the peers information to the point that you can allow and deny access based on IP or hostname or network, and you can also set per-peer environment pair values, as well as the number of concurrent connections to the service.
The related srv commands are:
–peers | -p [service] - set peer information for the service (see below), or rebuild the peer instructions for the service if no peer control options are given
–env | -e [service] - set global environment pair values for the service
Along with the –peers command, a user can use the following peer control options:
–grant | -g - grant access to this service to the specified hosts, IPs, or networks
–exclude | -x - deny access to this service to the specified hosts, IPs, or networks
–remove | -y - remove peer information for the specified hosts, IPs, or networks
–env | -e - set per-peer environment pair values
–max | -m - set the number of concurrent connections for the specifies hosts, IPs, or networks to this service

An example will help towards gaining more understanding:
# srv –peers rsync -g 192.168.0.12 -e TRUSTED=yes -m 5
This command sets up peer information for the rsync service. It grants access to the IP 192.168.0.12, sets the environment variable $TRUSTED to “yes” (this is made available to the service), and sets the maximum concurrent connections to 5.

This command also explains that a user can have default “accept” to a service, a user can also override certain configuration options based on connecting IP or hostname. In this case, if access to the rsync service was globally permitted, the maximum number of concurrent connections per IP might be 2 for every IP other than that specified, which would permit 5. The environment variable $TRUSTED is set when this IP connects where it is not set for all others
By looking at this, it can be said that peers management is simple and powerful. This because a user can completely change how a service responds based on the connecting system.

Let’s have a look at another example:
# chmod 0 ./peers/0
# srv –env sshd MAX_PER_HOST=1
# srv –peers sshd -g secure.host.com -e OPTIONS=’-o “PermitRootLogin yes”‘-m 10
# srv –peers sshd -g host.com -m 3
A user will note that this series of commands will carry out following:
- disable all connections to sshd by default.
- set the maximum concurrency for all hosts to one connection per IP.
- grant access to sshd to secure.host.com with the environment variable $OPTIONS set to ‘-o “PermitRootLogin yes”‘ and a concurrency of 10 connections.
- raise the concurrency to three connections per IP to any *.host.com connections.

The third command is interesting. This is because the sshd service passes the value of $OPTIONS directly to sshd itself, a user can directly manipulate the server based on the incoming connection. A user can note that “PermitRootLogin” is set to “No” in sshd_config. All connections this will be the case, however, if a connection comes from secure.host.com, all of a sudden sshd will allow root logins because that option is passed to it.
The resulting ./peers/secure.host.com file would look like:
C10
+ OPTIONS=-o “PermitRootLogin yes”
The use of host names is fine, but it is recommended that a user should look up via DNS first. This means that if the IP 12.34.56.78 does not have a reverse DNS entry to secure.host.com, access will be granted based on the IP address and not the hostname.
Please note that in order to make use of this, a user will need to add -h to the tcpsvd command in the ./run script. By default, no services will attempt to do DNS lookups on incoming connections as it can get expensive in terms of connection speeds. If a user wants to enable this then he/she can change ./run so that instead of looking like:

/sbin/tcpsvd -v -l ${HOSTNAME} -x peers.cdb -c ${MAX_CONN} -C ${MAX_PER_HOST} -b ${MAX_BACKLOG} ${IP} ${PORT}
/usr/sbin/sshd -i ${OPTIONS}
it looks like:
/sbin/tcpsvd -v -h -l ${HOSTNAME} -x peers.cdb -c ${MAX_CONN} -C ${MAX_PER_HOST} -b ${MAX_BACKLOG} ${IP} ${PORT}
/usr/sbin/sshd -i ${OPTIONS}

If a user can change a run script, then he/she should keep in mind that upgrades to that package will never overwrite the changes. However, the new script will be named run.rpmnew and a user will examine the file for changes that may have been made and merge them in manually.

The way it works
At boot, Annvix uses runit rather than init to start the system. In runit’s stage 2 process, runsvdir is started to manage everything under /service. All that is in the /service directory are symlinks to directories in /var/service which is where rpm packages place directories and information in order to run supervised services. These directories are named after the service they start. Unlike initscripts that can (and often do) start more than one daemon, each service starts one and only one service. So, for instance, when running LDAP you would use service ldap start on most Linux distributions, but on Annvix you would use srv –up slapd; srv –up slurpd. In this case there are two daemons, thus two services: slapd and slurpd.

Inside each directory is a single file called run. run is the equivalent of an initscript’s start() function; all it does is start the service. The run script of spamd, for instance looks like this:
#!/bin/sh
PATH=”/sbin:/usr/sbin:/bin:/usr/bin”

# this runs spamd supervised

OPTIONS=”-c -m5 -H”

if [ -f ./env/OPTIONS ]; then
OPTIONS=`head -1 ./env/OPTIONS`
fi

exec /usr/bin/spamd $OPTIONS 2>&1
Like an initscript, it sources certain configuration files to get options for the daemon (in this case, the /var/service/spamd/env/OPTIONS file). You also see that the daemon is started with exec and that STDERR is redirected to STDOUT. This is not always desirable, however, and needs to be dealt with on a case-by-case basis. In the case of spamd, a sub-service is also started that writes all of spamd’s output to a logfile.

The logging service is another service that supervise handles, tied specifically to that particular service. This is done by using a log/ subdirectory of the service; so spamd’s logging service run script is /service/spamd/log/run. The contents of this file are:
#!/bin/execlineb

# logging for the spamd service

/bin/foreground { /usr/bin/install -m 0700 -d -o logger -g logger /var/log/service/spamd }
/bin/cd /var/log/service
/sbin/chpst -u logger /sbin/svlogd -tt /var/log/service/spamd

This script basically takes STDOUT from spamd and writes it, through the svlogd tool (which handles the naming and automatic rotation of log files) to the directory /var/log/service/spamd. In this directory you will find a few files, some with odd names that are rotated logfiles, and one of interest, particularly current. The current logfile is the latest output of the service.
If a user wants to debug a service or figure out why it isn’t starting. Often errors from a service will be written to STDERR, which, if you remember, we are redirecting to STDOUT, which is then being written to the logfiles that svlogd is handling.
If a user browses through the /var/log/service directory, then he/she will view a number of subdirectories. These subdirectories are log directories for other services, although not all services uses logging services (socklog is a notable exceptions). More often than not, the log files will be 0 bytes unless the program (like snort) is fairly verbose. As well, in many cases, services need to be started with debugging enabled in order to prevent them from forking into the background. In order for runsvdir to be able to control a service, it must not fork into the background.

If a user follows this tutorial guide then he/she would have learnt about managing supervised services.

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.

Welcome to the tutorial guide. The tutorial will provide guidance and instructions to users about Linux Filesystems for Annvix.

A filesystem on Linux, or another operating system, is a low-level application that manages the storage and access of files on the system. A filesystem provides users and applications the ability to create files and directories, read and write to files and directories, delete files and directories, and provide access controls (called ACLs) on files and directories. In short, the filesystem is the “middle-layer” between user-land processes and applications and physical devices such as a hard disk or CD.

Filesystems available for Annvix
Annvix comes with the ability to use several different filesystem types. There are typically two types of filesystems available for Linux: journaled filesystems and non-journaled filesystems. Annvix makes no assumptions and thus provides no “default” filesystem. Each filesystem has it’s advantages and drawbacks compared with others. Which filesystem to use largely depends upon the application — a /boot partition does not necessarily require a journaled filesystem and because it is typically small, a filesystem such as ext2 is probably the best fit.

Journaled filesystems include additional record-keeping functionality that greatly increase the ability of the filesystem to recover data in the event of a system crash. With this type of filesystem, data is kept as changes are made to the files, even before the change is complete (thus keeping a “journal”) of activities. In theory, this means that data that was not completely written to its final state can be recovered, and data that is not complete can be safely discarded without losing other data. In practice, this means that it takes far less time to keep the system in a healthy state than a non-journaled filesystem.

ext2
ext2 is one of the oldest filesystems available for Linux, and as a result one of the most stable. It is a high performance non-journaled filesystem. Despite the lack of a journal, many people continue to use it for many applications due to it’s speed and reliability. ext2 keeps track of filesystem state, which makes recovery possible in the event of a system crash.

ext3
The ext3 filesystem is a journaled filesystem built upon ext2; in essence it is the ext2 filesystem with journaling extensions. As a result, it is quite stable and reliable.

XFS
XFS is a filesystem that was created by SGI for the IRIX operating system. XFS is a high-performance journaled filesystem that is typically considered to be much faster than ext3. On the downside, XFS makes heavy use of data caching, which means that power failures are more likely to result in data loss. As a result, using a UPS and good backups are definite safety precautions that should be observed when using XFS. It also does not have tools for shrinking filesystems.

ReiserFS
ReiserFS is another journaled filesystem. ReiserFS v3 support is included in Annvix, but it’s use is discouraged as no further development is taking place on v3 and development remains unsure of the next-generation ReiserFS v4 filesystem.

JFS
Annvix provides in-kernel support for JFS, the journaled filesystem created by IBM, but does not yet ship the userland tools to make use of it.

Fat32/NTFS
Annvix supports reading and writing to Fat32 filesystems, and supports reading from NTFS filesystems. Their use as filesystems on an Annvix system is discouraged due to poor performance, in the case of Fat32, and experimental write support, in the case of NTFS.

Network Filesystems
Annvix provides support for using network filesystems, using NFS and CIFS protocols.

Filesystem Maintenance
Filesystems generally work exceptionally well on their own and require very little intervention or pampering. However, there are times when new filesystems need to be created or re-formatted, partitions need to be resized, and so forth so knowing the basics of filesystem maintenance is generally a good idea.

Creating Filesystems
Each filesystem provides its own tools to create new filesystems. Generally speaking, the /sbin/mkfs(8) tool will create filesystems; it is a front-end to other tools that actually create the filesystems.
• ext2: /sbin/mkfs.ext2(8) or /sbin/mke2fs(8)
• ext3: /sbin/mkfs.ext3(8) or /sbin/mke2fs(8) with the ‘-j’ option
• XFS: /sbin/mkfs.xfs(8)
• ReiserFS: /sbin/mkfs.reiserfs(8) or /sbin/mkreiserfs(8)
• Fat32: /sbin/mkfs.dos(8), /sbin/mkfs.vfat(8), or /sbin/mkdosfs(8)

Repairing Filesystems
Occasionally a filesystem may need repair. More often than not, the system will detect anomalies in the filesystem at boot and attempt to make the repairs then, however these tools offer more sophisticated and specific usage options than what Annvix attempts to do at boot (largely to avoid tampering too heavily with the filesystems). Each filesystem makes use of it’s own tools for repairs. Generally speaking, the /sbin/fsck(8) tool will check and repair filesystems; it is a front-end to other tools that do the actual checking and repairing.
• ext2: /sbin/fsck.ext2(8) or /sbin/e2fsck(8)
• ext3: /sbin/fsck.ext3(8) or /sbin/e2fsck(8)
• XFS: /sbin/fsck.xfs(8)
• ReiserFS: /sbin/fsck.reiserfs(8) or /sbin/reiserfsck(8)
• Fat32: /sbin/dosfsck(8)}

Modifying Filesystems
Some filesystems offer the ability to resize and otherwise modify filesystems.
• ext2: /sbin/resize2fs(8)
• ext3: /sbin/resize2fs(8)
• ReiserFS: /sbin/resize_reiserfs(8)

If you followed this tutorial guide then you would have learnt about Linux Filesystems for Annvix.

Welcome to the tutorial guide. The tutorial will provided guidance and instructions to users about Annvix disks and partitions.

As we are aware that Linux supports a variety of media as disks including hard drives, floppy drives, zip drives, and USB thumb drives. Each of those drives is referenced by a filename. Typically IDE drives are referenced as /dev/hda and SATA and SCSI drives are referenced as /dev/sda. In a machine with two IDE drives and one SATA drive, they would (most likely) be listed as:
/dev/hda
/dev/hdb
/dev/sda

Hard drives are ordered in the order that they are seen by the BUS and given a two letter designation for their type and a third letter for their order, so hd is an IDE drive and hda is the first IDE drive with hdb the second. The third device could be SATA or SCSI (maybe SAS) but is listed as the only one of this type in this example. CDROM and DVD drives may appear in the same list with a similar designation, but are often also shown with an alias like /dev/cdrom for convenience.

Partitions
Partitions within a drive are also listed in the /dev directory. Typical designations will append a number for each partition within the drive. For instance:
/dev/hda1
/dev/hda2
/dev/hda3
/dev/hda5
/dev/hda6
In this example, the drive has three partitions. Note that they will be displayed this way whether they contain a file system or not. Extended partitions will have a similar designation and so may also appear in the same list, which might lead to confusion for someone who hadn’t read this introduction.
Please note that grub doesn’t show drives the same way.

In the example above, it is likely that /dev/hda1 and /dev/hda2 are normal partitions, while /dev/hda3 is an extended partition that allows the creation and use of /dev/hda5 and /dev/hda6. As an extended partition, it cannot be formatted or mounted, but is still necessary to exist. It is also possible that they are all normal partitions and the slot for {file|/dev/hda4}} is somehow removed.

fdisk
The fdisk is a tool used for managing partitions. This tool allows users to create, delete, relabel and otherwise manipulate their partition table. For most users there are only a couple uses that they need to know. Typically, {prog|fdisk}} should not be used on an installed system while it is booted as a user may remove or modify partitions that are currently mounted and in use. It is possible, however, to manipulate a drive that is not currently in use or to manipulate drives when booted from the Annvix installation CD.
# fdisk -l

Disk /dev/hda: 10.2 GB, 10239860736 bytes
16 heads, 63 sectors/track, 19841 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 13563 6835720+ b W95 FAT32
/dev/hda2 13579 14934 682762+ c W95 FAT32 (LBA)
/dev/hda3 14935 19841 2473128 83 Linux
/dev/hda4 13564 13578 7560 5 Extended
/dev/hda5 13564 13578 7528+ 83 Linux

Please note that the partition table entries are not in disk order

Disk /dev/hdb: 20.0 GB, 20020396032 bytes
255 heads, 63 sectors/track, 2434 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdb1 1 13 104391 83 Linux
/dev/hdb2 * 14 2434 19446682+ 8e Linux LVM

In the example above, the command fdisk -l is given from the shell and shows the partition tables on all accessible drives. In this example, the first two partitions of the first IDE drive are FAT32 partitions such as those used by some Windows systems.

The third partition is a typical Linux partition, the fourth is an extended partition. The fourth partitions is necessary if a user wants to have more than four partitions. The fifth is another typical Linux partition. This partition warns a user with a notice that the entries are not in disk order, which is a typical for most systems, but can happen if a user rearranges partitions. Notice also the asterisk next to /dev/hda1 and /dev/hdb2. The asterisk indicates that a partition is the default boot partition, which means it will be used to start the boot process.

On the second IDE drive the first partition is a typical Linux partition and the second one is one labeled for use by LVM. Please note that LVM is not typically used for Annvix systems.
A user will also notice the starting and ending sectors used for the partitions as well as the number of blocks each contains.
# fdisk /dev/hda

The number of cylinders for this disk is set to 19841.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)

Command (m for help): p

Disk /dev/hda: 10.2 GB, 10239860736 bytes
16 heads, 63 sectors/track, 19841 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 13563 6835720+ b W95 FAT32
/dev/hda2 13579 14934 682762+ c W95 FAT32 (LBA)
/dev/hda3 14935 19841 2473128 83 Linux
/dev/hda4 13564 13578 7560 5 Extended

Please note that the partition table entries are not in disk order

Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition’s system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)

Command (m for help):
Typically a user will need to tell fdisk which disk he/she wants to access as the first argument. This will take a user into a command shell where he/she will be able to issue commands to display and manipulate the system. In this example,the first command issued was p, which simply displays the existing partition table information. When the command completes, the user is returned to a prompt where another command can be entered.

The second command entered in this example is m, which as indicated by the helpful tip, shows more commands that are available. Normal use of fdisk is to create new partitions, label partitions and remove them.

Creating a partition is initiated with the n command. When a user presses n at the prompt, they are given an additional prompt for where to start the first cylinder. The allowable range is displayed along with the default, typically the first cylinder not already in use by another partition as shown here:
Command (m for help): n

First cylinder (13564-13578, default 13564):
If a user needs to leave space between partitions for other allocation or due to damage to the disks then they might use something other than the default, but most users can just hit Enter to accept the default. The next prompt will give the option of how to size the partition:
Using default value 13564
Last cylinder or +size or +sizeM or +sizeK (13564-13578, default 13578):
At this prompt the user can specify the cylinder to end the partition or specify a size and have fdisk approximate the location to accommodate the desired content. Examples of allowable entries for this prompt would be: 13570 for “end the partition on cylinder 13570″ or +30M for a 30MB partition (approximately), or +500K for a very small partition. Gigabytes can be specified as G on most systems as well. The default is to use all contiguous cylinders for the new partition, so pressing Enter will use the rest of the available space on the drive.

After the partition table is created to the desired specifications, the user must use w to save the partition table to the drive. q will leave fdisk without saving changes. d will give prompts to delete a partition. When someone is partitioning a new system, the command to make a partition bootable is b.
If you followed guidance and instructions as provided in this tutorial guide then you would have learnt about the disks and partitions.

Welcome to the tutorial guide. The tutorial will provide guidance and instructions to users on upgrading strategies for Annvix. Please note that Annvix is an operating system designed to be upgraded “live”.

The main purpose is to provide a straight-forward upgrade path from one version to the next. This is usually accomplished by executing apt-get dist-upgrade for simple updates and using fabricated upgrade scripts for upgrades that require more complex work (such as upgrading from 1.2-RELEASE to 2.0-RELEASE).

Please note that the software upgrades such as MySQL 4.1.x upgrading to MySQL 5.0.x requires attention as rpm package cannot provide any assistance to a user. Also, a user should be careful to backup, upgrade or to migrate date on his/her own.

This tutorial guide presents upgrading strategies that can be used to tailor specific upgrade techniques to use when upgrading software.

Upgrading MySQL
Let’s learn how to upgrade a MySQL database. The MSQL database is easy to backup.
A user should note that the first step to create a backup of your existing data. A user has to run the following command in order to dump the database:
# mysqldump \
-u root -p \
–all-databases \
–add-drop-database \
–opt \
–allow-keywords \
–flush-logs \
–hex-blob \
–max_allowed_packet=16M \
–quote-names \
–result-file=BACKUP_MYSQL_4.1.SQL

This assumes the currently installed version of MySQL is 4.1 as the backup file name. The BACKUP_MYSQL_4.1.SQL file can now be used to recreate the data. Before assuming that this file is valid, a user should import the data on a spare system and check that everything is there.

A user could also make a binary backup of his/her database:
# srv –down mysqld
# tar cvjf ~/mysql-backup.tar.bz2 /var/lib/mysql
# srv –up mysqld
Finally, to restore his/her data via the SQL export (BACKUP_MYSQL_4.1.SQL), a user would use:
# mysql \
-u root -p \
–max_allowed_packet=16M < BACKUP_MYSQL_4.1.SQL
# mysqlcheck -u root -p –all-databases

A user should run mysqlcheck after the upgrade as it checks the databases for incompatibilities with the new version of MySQL; it will check and repair any tables that require it. It is important to note that mysqld must be running in order to import the data via the SQL file.

Upgrading OpenLDAP
OpenLDAP is a directory service that acts quite a bit like a database. An easy way to backup OpenLDAP is to make an LDIF file using slapcat. This can be done by running following command:
# srv –down slapd
# slapcat >~/ldap-backup.ldif
# srv –up slapd

The slapd daemon shouldn’t be running when a user executes slapcat to make sure no changes are made to the directory while it is creating the LDIF file. A user can also create an LDIF of a particular base DN by running following command:

# slapcat -b “dc=example,dc=com” >~/ldap-backup-example.com.ldif

Once OpenLDAP is upgraded, a user can restore the data by running following command:

# slapadd -cv -l ~/ldap-backup.ldif

or a user can use the -b option as noted above if the LDIF file is for a particular base DN.

How to perform a remote upgrade
A user should be able to upgrade Annvix entirely by remote. In order to perform a remote upgrade, a user can go through following:
• open 3 ssh sessions to the remote host; one to run the upgrade script, one to watch the upgrade log (/tmp/upgrade/upgrade.*), and another to do any “emergency” work that a user might need to do
• a user can run the system for some time once the upgrade is done, although a user should reboot as soon as possible…. take that time to look at /root/.upgrade.log.[date] and make sure there were no critical errors
• double-check /etc/mdadm.conf if a user is using RAID
• double-check /etc/fstab just in case
• execute find /etc -name ‘*.rpmnew’ and merge in any configuration changes that may be required; do the same for *.rpmsave also
• if a users server provides it’s own DNS, a user will get an error from apt; a user can re-try the apt command with the script, however, using the third terminal, bring back up the DNS server service (named or dnscache, etc.) so that DNS resolution will work
• for 2.0-RELEASE, if a users server relies on LDAP for authentication, be aware that slapd will not properly restart until the system is restarted (it requires the 2.6 kernel to run); to have it come up automatically, be sure to execute rm /service/slapd/down prior to rebooting.

A number of upgrade tests with the upgrade script have been done via remote, and live upgrades have been done as well.

If a user followed this tutorial guide then he/she would have learnt about Annvix - upgrading Strategies

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on modules configuration.

If a user wants any modules or drivers to be loaded on the system at boot, then as user should note that /etc/modprobe.conf file is the place to put them. Please note that the installer does create this file for a user, but if a user wants to use other devices that may be a little non-standard, or that kudzu did not detect, then a user will need to modify the file.

An example /etc/modprobe.conf may look like this:
alias eth0 forcedeth
alias eth1 tg3
alias scsi_hostadapter sata_nv
alias ieee1394-controller ohci1394
install scsi_hostadapter /sbin/modprobe sata_nv; /bin/true
install usb-interface /sbin/modprobe ehci-hcd; /sbin/modprobe usb-ohci; /bin/true
install ide-controller /sbin/modprobe amd74xx; /bin/true

It can be seen that the system has dual ethernet interfaces, the first using the forcedeth module and the second using the tg3 module. The system also contains a SATA nvidia controller, thus the sata_nv module is called. The system also contains two USB interfaces and a firewire interface.

How to create more users
If a user wants to add more users to the system before rebooting, then he/she can do so by using the standard groupadd and useradd commands. In order to create a group for a new user (let’s name the user account as “shafkat”), use:

# groupadd -g 1002 shafkat

This creates a new group called shafkat with a gid of 1002. If a user omits the gid assignment option (-g), then groupadd will take the first freely available gid over 500.

In order to create the user “shafkat”, who’s primary group will be “shafkat”, let’s use:

# useradd -u 1002 -g 1002 -d /home/shafkat -s /bin/bash -c “shafkat” -m shafkat

This will create the user “shafkat” with a uid of 1002, with a home directory of /home/shafkat and with an assigned shell of /bin/bash. The user’s comment (which usually contains their real name) is “Shafkat”. The -m option tells useradd to copy the contents of
/etc/skel as the user’s home directory (otherwise the home directory is not created).

If a user wants to have user “shafkat” added to the “users” group as a supplementary group, then he/she should use the -G option. As this is the primary user or administrative user, so a user should add Shafkat to group “admin”. If this is the case then the above command would end up looking like the following:

# useradd -u 1002 -g 1002 -d /home/shafkat -s /bin/bash -c “Shafkat” \
-G users,admin -m shafkat

Shafkat now belongs to his own primary group (”shafkat”) as well as to the “users” group and the “admin” group. Finally, be sure to give Shafkat a password by running following command:
# passwd shafkat

How to configure the GRUB Bootloader
Annvix uses GRUB as a bootloader, which is the program that sits in the computer’s MBR, or Master Boot Record. MBR tells the computer what kernel to load, what options to pass to it, where the kernel lives on the system, and where the initrd image lives. Without a bootloader, unless a user plans to boot from a floppy or CD, a user will be unable to boot the system.

The Annvix kernel is built with framebuffer support, which allows a user to boot the system with a higher resolution than the default 80×25 character display. The following table lists the available vga values that as user can use when configuring the bootloader (the values are bootloader-independent):
640×480 800×600 1024×768 1280×1024
8 bpp 769 771 773 775
16 bpp 785 788 791 794
32 bpp 786 789 792 795

Please note that GRUB, or GRand Unified Bootloader, is a bootloader with some powerful options. It is different than LILO in that it does not reference devices as /dev/xyz. In other words, /dev/hda1 is referred to as (hd0,0) in GRUB, rather than /dev/hda1 as it would be in LILO. This only refers to hard drives; ATAPI-IDE devices are ignored. Hard drives start with “0″ rather than “a” and partitions also start with “0″ rather than “1″.

For instance, if a user had a hard drive as /dev/hda, a CDROM as /dev/hdb, and another hard drive on /dev/hdc, the device Template:/dev/hda2 would be (hd0,1) and the device /dev/hdc6 would be (hd1,5).

If a user wants to install GRUB into the MBR, then he/she will need to use the grub shell by running following command:
# grub –device-map=/boot/grub/device.map

At this point a user will need to tell GRUB where to install. Typically, a user will want to install GRUB in the MBR, and tell it where his/her /boot partition resides, let’s assume the /boot partition is /dev/hda1. Please note that it is it is strongly recommended to create a separate /boot partition)
A user can use TAB completion in GRUB as well. For instance, if a user were to type root (hd0,[TAB] then he/she would receive a list of available partitions to choose from.

If a user is going to install GRUB in the MBR, and his/her oot partition is /dev/hda1, then he/she would type the following in the grub shell:
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

GRUB is now installed in the users’ MBR, but a user has to setup the GRUB configuration file: /boot/grub/grub.conf. A user can use vim to create and edit this file. The following is a sample configuration file:
default 0 # the default to boot; 0 is the first entry, 1 the second, etc.
timeout 10 # boot the default after 10 seconds
fallback 1 # fallback to the second entry if the first can’t boot
background 000000
foreground 34d1c0
color cyan/black yellow/black
splashimage (hd0,0)/grub/annvix-splash.xpm.gz

title=Annvix
kernel (hd0,0)/vmlinuz ro root=/dev/hda3 vga=788
initrd (hd0,0)/initrd.img
title 262215-8354avxsmp
kernel (hd0,0)/vmlinuz-2.6.22.15-8354avxsmp vga=788 root=/dev/hda3
initrd (hd0,0)/initrd-2.6.22.15-8354avxsmp.img

If a user needs to pass any further arguments to the kernel then a user just has to add it to the end of the kernel line in the configuration file; i.e:
kernel (hd0,0)/vmlinuz-2.6.22.15-8354avxsmp vga=788 root=/dev/hda3 hdc=ide-scsi

If a user wants to opt to have /boot a part of the / filesystem (ie. it isn’t it’s own partition), a user will have to specify the kernel and initrd relative to /, so /boot/vmlinuz-[…] and /boot/initrd-[…]. In the above example, (hd0,0) is /boot, so the kernel and initrd are relative, thus just using /vmlinuz-[…] and /initrd-[…].

Once a user has to save the file, GRUB is ready to use. GRUB is unique in that it reads it’s configuration file on-the-fly; unlike LILO, a user doesn’t need to re-run the grub program in order to make changes to the configuration file.

How to finalise the installation
The Annvix system is now installed with enough configuration data for it to boot up on it’s own. There is still the obligatory post-install configuration of any services is a user wishes to use, however a user can now do that within Annvix itself.

When a user feels that he/she is ready to reboot, then he/she can exit the chroot by typing exit on the command-line. The installer will then confirm that a user has finished the installation, then reboot the system. A user has to remember to remove the CD from the CD-ROM drive and/or change the boot order in the BIOS to boot from the hard disk that a user installed his/her boot loader on (typically /dev/hda).

If you followed the tutorial guide then you would have learnt about the Annvix’s modules configuration.

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on installing the Annvix by using RPM packages to handle package management. RPM is frontend for installing files and handling package dependencies.

In Debian, apt is the useable frontend for dpkg; in Annvix, apt-get is the useable frontend for RPM. Please note that previous versions of Annvix uses urpmi exclusively; this is no longer the case. Annvix now uses apt by default.

In order to install Annvix, a user will need to use install-pkgs to install all required packages in order to eventually reboot and have a fully functional Annvix system.
After a user has mounted all the partitions under /mnt/annvix, a use can then run the install-pkgs command. This program is the Annvix installer: it will ask a user many questions on how to setup the system, install required packages, and eventually allow a user to reboot the system into the new Annvix install.
# install-pkgs

How to configure the network?
A user has to understand that the first step is to configure the network settings. If the system is being installed on a network with a DHCP server available, eth0 will be pre-configured for DHCP.
A user can either elect to keep it set that way, or he/she can reconfigure it — either to set it to a static IP or to continue using DHCP and also be able to set the hostname. Even if the network is pre configured, a user should set it up again to verify the settings and give net-setup an opportunity to write the configuration files. After a user has configured the network, a user will be shown the results of the configuration with ifconfig output for that interface. If a user has more than one network interface, then install-pkgs will iterate through all available network interfaces, and call net-setup for each one.

The next install-pkgs will setup the apt repository found on the install ISO and prepare the installation. A user has an opportunity to either continue or cancel the install.

How to select the Timezone?
If a user wants to select the timezone, then he/she should follow the steps as mentioned below:
• Please select the system’s hardware clock and set it to UTC time or local time.
• After this, a user can select a timezone from the provided menu;
• Now a user can choose the timezone code for his/her location (i.e. “MST7MDT”),
• or select the country code (i.e. “England”),
• and then select the appropriate region from the next menu (i.e. “England/Lancashire”).

How to select the Boot Device?
A user will be asked to select the device on which to install the boot loader (GRUB). The installer attempts to detect which device to install to based on the filesystem layout and which devices are mounted. In situations where RAID or LVM are used and / or /boot partitions are not on a physical device (i.e. /dev/md0, etc.) it can’t determine which device to use and a user must provide that information.

Filesystem Construction
install-pkgs now installs packages from the local CD using apt. As it may take sometime so be patient. The installer uses two stages to do the RPM package installation.
After this is complete, it does some post-installation tasks, and then installs extra required packages. For example if the network uses DHCP, it will install dhcpcd; if a user has installed an XFS filesystem it will install xfsprogs; if a user has setup RAID devices, it will install mdadm.
Then the installer sets up a few services to start at boot: mingetty services (for tty1 through tty6), crond, and socklog are all started at boot. No other service starts at the first boot.
Finally, the installer creates the /etc/fstab file and the /boot/grub/grub.conf configuration files. If a user had to specify the boot device before (due to using RAID or LVM), make a note to double-check this file. A user will have to configure GRUB manually once the installation is complete.
After the installer sets up the time configuration, it sets the system locale to English. Annvix does not support other languages other than English for locale settings. This is simply due to the fact that number of localized programs is very low compared to the effort and size of the each locale; it was felt that removing all locales other than English would not only save space (and developer effort), but keep the system consistent (instead of having the system 80% English and 20% Russian, for instance, it is now consistently 100% English).

Respository Setup
The next step is to choose a repository from which a user will obtain further packages to install and upgrade. A user can also select one of the available mirrors or provide his/her own (a local copy of the repository, another copy on the local network, etc.).

Initial User Setup
In order to do an initial setup, a user has to provide root a password. As of 2.0-RELEASE, Annvix enforces strong passwords with the pam_passwdqc module. This means that passwords now must adhere to certain rules. An example will clear this, as there are four character classes: upper case letters, lower case letters, digits, and other characters. By default, passwords must be 6 characters long with characters from three out of the four character classes, or may be 5 characters long with characters from each of the four character classes. Using an upper case letter at the beginning of the password and a digit at the end of the password do not count towards the number of character classes used.

pam_passwdqc also offers a passphrase that such as “draft!coarse&bought”.
Once a user has provided root’s password, a user will have the opportunity to setup the first administrative account. This user will be added to the “admin”, “ctools”, and “users” groups. This means the user will have access to all the commands allowed to users in the admin group via sudo. A user should take the opportunity to setup this administrative user.
A user will be required to provide the user’s numeric ID (uid); this same number is also used for their numeric group ID (gid). A user must also provide a username (their login name), and their real name.
The administrative user will have their own gid (i.e. if a user setup up as “shafkat” with a uid of 1001, he will belong to group “shafkat” as well (with a gid of 1001), and also groups “admin”, “users”, and “ctools”).
A user will also need to select a starting range for the users. Most Linux distributions reserve uid and gid 0-99 for system accounts, and Annvix is no exception. Annvix reserves gid 100 for group “users”; it’s entirely up to a user whether he/she wishes to use it or not. The range of user and group ID’s 100-499 are likewise reserved for system accounts. For user accounts, a user should use uid/gid 500 or higher; some may prefer to use a uid/gid pair of 1000 or higher for users and groups. Note that user and group 65534 is also reserved for the unprivileged “nobody” and “nogroup” accounts.
Before selecting a range (either 500+ or 1000+), consider the environment that a users Annvix machine will be in. If there are other machines on the system already using uid/gid 1000+, a user may wish to use that for the users baseline. If the other machines use 500+, choosing that may be appropriate. This is especially true if a user is using NIS or LDAP for distributed authentication and uid/gid lookups.

Finishing the Install
Users Annvix install is complete other than double-checking some configuration files and installing any optional packages. The installer will now start a chroot session inside the newly installed system; when a user will see the [chroot /]$ prompt, user will know that he/she is working inside the new system as if he/she had booted it.
A user should note that following steps should be taken before exiting the chroot:
• double-check /etc/fstab to make sure everything is correct (it should be)
• double-check /boot/grub/grub.conf to make sure everything is correct.
• If a user did not do an install using RAID or LVM, GRUB will already be installed and should be properly configured; if a user did use RAID or LVM.
A user may also choose to install more packages, as the system is quite spartan at this moment. If a user wishes to use Apache and PHP, then he/she will want to install httpd-mod_php and it’s associated dependencies. For an email server, a user will want to install exim or postfix.

If a user followed this tutorial guide then he/she learnt about installing the base lines.