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.

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.

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions for installing Annvix, booting the install CD.

A user will note that there is no pretty GUI to guide a user through the installation process.
How to boot the install CD?
Let’s go through the process of booting the install CD. Please note that the Annvix installation CD is what a user needs to install Annvix.
• A user can download the ISO image, which will require a user to do a network install to install packages that are not part of the base operating system.
• In order to have a faster install, a user can download the RPM packages and store them on a local hard drive or somewhere on the network.
• After a user has written the ISO to CD, he/she can insert the CD and boot from it. At the prompt, a user will be able to select which kernel that he needs to use. A user can choose from install and install-nofb
• The CD will boot a small image into memory and then try to detect the CD-ROM device and load the actual Live image as a loopback filesystem, which will then boot the actual useable system.
• A user can now access a number of tools to gain help with the installation process.
• A user will be automatically logged into consoles one and two as the root user when the system has completed booting.
• Before a user progresses any further, he/she should assign root a new password. Please note that by default, the root user’s password is “root”!.
How to modify the keyboard layout
If a user is using a non-English keyboard, then a user can use the loadkeys command to load the keymap for the keyboard. If a user wants to find out what keymaps are available, then he/she can look in /usr/lib/kbd/keymaps/. An example will help us understand this:
# /bin/loadkeys be2-latin1

How to load additional modules
A user can load additional modules for the system. The system executed kudzu during boot, which detected what hardware was installed and made a file called /etc/sysconfig/hwconf which contains this information. Please note that Kudzu makes a note of what modules are required for certain devices in this file as well. A user will notice an entry like this as provided below:
-
class: NETWORK
bus: PCI
detached: 0
device: eth0
driver: pcnet32
desc: “Advanced Micro Devices [AMD]|79c970 [PCnet32 LANCE]”
network.hwaddr: 00:0C:29:B3:3B:D9
vendorId: 1022
deviceId: 2000
subVendorId: 1022
subDeviceId: 2000
pciType: 1
pcidom: 0
pcibus: 0
pcidev: 10
pcifn: 0
The information lets a user know which network card is installed on the system, and also tells a user what module (or driver) is required to operate it. In this case, a user will need to load the pcnet32 module. A user can do this by simply executing:
# /sbin/modprobe pcnet32
A user can use lsmod in order to verify that the module has been loaded. Please note that a user does not have to manually load network drivers. The install-pkgs script helps a user with this. A user can also use hdparm to tweak IDE hard disk performance.
How to configure a proxy
If a user is planning to connect to the internet through a proxy, then a user will have to define some environment variables. An example will help in understanding this. If a user is connecting to proxy.annvix.org on port 8080, then he/she will type following:
# export http_proxy=”http://proxy.annvix.org:8080″
# export ftp_proxy=”http://proxy.annvix.org:8080″
# export RSYNC_PROXY=”http://proxy.annvix.org:8080″
If a users proxy requires him/her to login (provide authentication), then please use the format “http://username:password@proxyserver”.
How to prepare the disks
A user can now start working on the actual system. A user can now start creating the filesystems that a user wants to use on the hard drive. The process of preparing the disks involves the steps of partitioning, formatting, and mounting the drives.
Partitioning Schemes
A user has got a number of ways in which he/she can partition the drive, and it all depends upon personal preference and on users requirements. A basic partition scheme is presented below:
Partition Filesystem Size Description
/dev/hda1 ext2 50M Boot partition (/boot)
/dev/hda2 swap 512M Swap partition
/dev/hda3 XFS 800M Root partition (/)
/dev/hda4 XFS rest of disk Home partition (/home)
This partition scheme makes the assumption that large volumes of data will be stored on the /home partition (i.e. web data, user mailboxes, etc.). A user can change this to /srv or /var according to his/her preference or make /dev/hda3 one large root partition.
There are a number of arguments to using more, or less, partitions. By segmenting parts of the disk to different mount points (i.e. a separate partition for /usr, one for /var, another for /tmp, etc.) a user can secure the system a little more by issuing mount options such as noexec or nosuid for various filesystems.
A user can mount /tmp with noexec and nosuid, likewise for /var, and possibly likewise for /home. Another argument is that if a rogue program is filling up logfiles, then only the /var partition would get stuffed; it wouldn’t impact the amount of space used on other partitions.
A user should note that a proper planning is important as a poor planning can lead to problems such as a user can end up with either too little space in some places, or wasted space in others.
A user should note that there is another important point to note which is about paying attention to upgrades. If a users system is a large root partition, when a user upgrades the system, then he/she will have to take pains to make sure that /home is not overwritten or otherwise tampered with. If a user has an existing system and wish to re-format the drives, /home will be lost with all of it’s data unless a user can make a backup. With /home on a separate partition, a user can freely format the root partition without touching the data stored on /home whatsoever.
Using RAID
If a user doesn’t want to use RAID, then he/she can skip ahead. As by using Linux software RAID is entirely optional and can be done during the installation with a few manual steps.
The first step is to ensure that the two drives are physically identical, and ideally placed on different controllers. Here we have the first drive as /dev/hda and the second as /dev/hde.
By using fdisk, a user can create partitions. Please view following partitions as below:
Device Mount point RAID device Size
/dev/hd?1 /boot /dev/md0 100M
/dev/hd?2 swap n/a 256M
/dev/hd?3 / /dev/md1 5G
/dev/hd?5 /usr/local /dev/md2 10G
/dev/hd?6 /var /dev/md3 10G
/dev/hd?7 /home /dev/md4 10G
/dev/hd?8 /srv /dev/md5 45G
The sizes are, of course, approximate. When a user is creating each partition, then he/she should pay attention to how many sectors are being used. Please view partitions on this drive and they are as following:
/dev/hda1 1-13
/dev/hda2 14-45
/dev/hda3 46-411
/dev/hda4 411-9729 (extended partition)
/dev/hda5 411-1628
/dev/hda6 1629-2845
/dev/hda7 2846-4062
/dev/hda8 4063-9729
When a user has completed the process of creating the partitions, then a user can change the partition types. For /dev/hda2, a user needs to change the type to “82″ for Linux swap. For the rest, with the exception of the extended partition, of course, a user will need to change them to type “fd” or Linux raid autodetect. This can be done by typing t to change type and then the partition number, and then the code of the type to change to (82 or fd).
When a user completes this then he/she can do the exact same thing on the second drive. Whereas on the first drive a user has specified partitions by size in fdisk (i.e. “+100M” to create the 100M /dev/hda1 partition), a user will need to specify by sector on the second drive. So, when creating the first partition, using starting sector “1″ and ending sector “13″. A user can do this for each partition. Then change the partition types as a user did for the first drive by changing the partition types. When a user has done then please check following work:
# fdisk -l /dev/hda

Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 13 104391 fd Linux raid autodetect
/dev/hda2 14 45 257040 82 Linux swap
/dev/hda3 46 411 2939895 fd Linux raid autodetect
/dev/hda4 412 9729 74846835 5 Extended
/dev/hda5 412 1628 9775521 fd Linux raid autodetect
/dev/hda6 1629 2845 9775521 fd Linux raid autodetect
/dev/hda7 2846 4062 9775521 fd Linux raid autodetect
/dev/hda8 4063 9729 45520146 fd Linux raid autodetect
# fdisk -l /dev/hde

Disk /dev/hde: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hde1 1 13 104391 fd Linux raid autodetect
/dev/hde2 14 45 257040 82 Linux swap
/dev/hde3 46 411 2939895 fd Linux raid autodetect
/dev/hde4 412 9729 74846835 5 Extended
/dev/hde5 412 1628 9775521 fd Linux raid autodetect
/dev/hde6 1629 2845 9775521 fd Linux raid autodetect
/dev/hde7 2846 4062 9775521 fd Linux raid autodetect
/dev/hde8 4063 9729 45520146 fd Linux raid autodetect
A user has to create every RAID device using the mdadm program. This is actually very simple. For each RAID device, a user will be executing mdadm somewhat like this:
# mdadm –create –verbose /dev/md0 –level=1 –raid-devices=2 /dev/hda1 /dev/hde1
Essentially, this is constructing a new array assigned to the device /dev/md0. It is a RAID1 array with two devices: /dev/hda1 and /dev/hde1. The mdadm manpage contains a lot of information, and if a user intends to do things like RAID1 or RAID5, etc.
A user can tailor the mdadm command to work with all of the devices, in this scenario a user would end up with md0 (hda1 and hde1), md1 (hda3 and hde3), md2 (hda5 and hde5), md3 (hda6 and hde6), md4 (hda7 and hde7), and md5 (hda8 and hde8).
If a user already has pre-existing RAID devices a user would like to use, the installer assembles them for a user during boot and they should be available for a user to use immediately without doing any kind of reconfiguration. If, for some reason, they are not available, a user can reconstruct the arrays using:
# mdadm -A /dev/md0 /dev/hda1 /dev/hdb1
Please note that the above would reassemble /dev/md0 with the /dev/hda1 and /dev/hdb1 devices.
When a user has completed this, a user can check the progress of the array construction:
# cat /proc/mdstat
This will indicate the status of the array construction, and will indicate which array it’s working on, how far it has left to go, the estimated finish time, etc. If a user wants to wait for the arrays to finish re-syncing before progressing with the install-pkgs command, a user can format and mount the partitions:
# mke2fs /dev/md0
# mkfs.xfs /dev/md1
# mkfs.xfs /dev/md2
# mkfs.xfs /dev/md3
# mkfs.xfs /dev/md4
# mkfs.xfs /dev/md5
# mount /dev/md1 /mnt/annvix
# mkdir -p /mnt/annvix/{boot,usr/local,home,var,srv}
# mkswap /dev/hda2
# mkswap /dev/hde2
# swapon /dev/hda2
# swapon /dev/hde2
# mount /dev/md0 /mnt/annvix/boot
# mount /dev/md2 /mnt/annvix/usr/local
# mount /dev/md3 /mnt/annvix/var
# mount /dev/md4 /mnt/annvix/home
# mount /dev/md5 /mnt/annvix/srv
After a user has done this, a user should check /proc/mdstat to see if it’s done everything. If everything is sorted then a user can go ahead with the process of install-pkgs command. The installer will make sure that the mdadm package is installed for a user. It is a good idea that a user runs the mdadm monitoring daemon so that to make sure to configure /etc/mdadm.conf and start the mdadm service (srv –add mdadm once installation is complete and a user has booted into the new system).
Continue on to Installing the base files.
Using fdisk to Partition
The program of choice to partition drives is fdisk. The sole argument to fdisk is the device to partition:
# fdisk /dev/hda
Once fdisk is started, a user will be at a command prompt that gives him/her a number of options (press m for help). In order to display the disk’s current partition configuration, a user can press p. If this is a fresh disk, there will be nothing to show. If the disk has previously been used, then a user will be able to view what partitions exist, how many blocks they are, what type of partition they are, etc.
If a user wants to remove the partitions to create new ones, then he/she can simply press d and give fdisk the corresponding partition number (ie. 1 for /dev/hda1, 6 for /dev/hda6, etc.) to delete. If a user makes a mistake, then he/she can press q to exit without writing the changes to disk; fdisk does not write any changes to disk until a user tell it to.
In order to create a first partition, let’s assume /boot,
- a user can press n to create a new partition.
- Then a user can select p for a primary partition, then give it the primary partition number (1 in this case). Please note that fdisk will ask a user for the first cylinder to use (just press enter),
- and then it will ask a user for the last cylinder or a size to use for the partition.
- Please enter the size of the partition; a user wants (say 50MB /boot partition so enter +50M).
- When this is done, if a user can press p to view the partitions, a user will see the new partition listed. Because the /boot partition needs to be bootable, press a to toggle the bootable flag for this partition.
The second partition is to be a 512MB swap partition.
- A user can press n again to create a new partition, and create it.
- When a user has created the partition, please press t to change the partition type.
- type the code 82, which is the code for Linux swap (press L to obtain a full list of partition codes).
- now if a user presses p to view the partitions, a user will see /dev/hda1 listed with a “*” in the bootable column and /dev/hda2 listed with a System type of Linux swap (/dev/hda1 should have a System type of Linux). For instance, it should look somewhat similar to:
Command (m for help): p

Disk /dev/hda: 255 heads, 63 sectors, 4866 cylinders
Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 27 216846 83 Linux
/dev/hda2 28 81 433755 82 Linux swap
- If a user is creating one more partition, when asked for the last cylinder, then a user will just have to press enter and a user will get the maximum size of the disk.
- If a user is going to have more than four partitions, then he/she can only use the first three as primary partitions; the rest need to be extended partitions. For instance, a user may have /dev/hda1 as /boot, /dev/hda2 as swap, /dev/hda3 as /, /dev/hda5 as /usr, and /dev/hda6 as /var. /dev/hda4 in this configuration is a large partition that contains the extended partitions. For instance:
Command (m for help): p

Disk /dev/hda: 255 heads, 63 sectors, 4866 cylinders
Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 27 216846 83 Linux
/dev/hda2 28 81 433755 82 Linux swap
/dev/hda3 82 742 5309482+ 83 Linux
/dev/hda4 743 4866 33126030 5 Extended
/dev/hda5 743 997 2048256 83 Linux
/dev/hda6 998 2272 10241406 83 Linux
/dev/hda7 2273 4866 20836273+ 83 Linux
Please note that /dev/hda4 has a System type of Extended; this just means that /dev/hda4 contains the other extended partitions (/dev/hda5 and higher).
- if a user is satisfied then he/she should press w to write the partition information to disk and exit fdisk.

Creating the Filesystems
When the partition creation is done, a user can place a filesystem on each device prior to being able to mount or use them. A user has a choice of filesystems, however, as Annvix supports ext2, ext3, ReiserFS, and XFS. All of these filesystems are journaling filesystems, with the exception of ext2.
- Please note that ext3 is ext2 with journaling capabilities. It is more reliable than ext2 due to the journaling support. It also includes a hashed b-tree indexing option that gives it more of a performance boost. Both ext2 and ext3 also support user quotas. The mke2fs program also is used to create these filesystems, however it is recommended that a user must pass the -j option to mke2fs in order to turn the journaling capabilities on.
- XFS is SGI’s powerful filesystem that is optimized for scalability and handling huge files and amounts of data. XFS provides extended ACLs which allow administrators and users to assign even finer user/group controls to files and directories. XFS also supports quotas. XFS filesystems are created with the mkfs.xfs program.
The use of ReiserFS as a filesystem on Annvix is highly discouraged. Due to support issues, lack of development for ReiserFS v3 and lack of acceptance by the Linux kernel maintainers regarding ReiserFS v4, we highly recommend not using ReiserFS at all.
IF a user wanted to make /boot (/dev/hda1) an ext2 filesystem, / (/dev/hda3) an ext3 filesystem, /var (/dev/hda5) an ext3 filesystem, and /home (/dev/hda6) an XFS filesystem, then as user should use something like:
# mke2fs /dev/hda1
# mke2fs -j /dev/hda3
# mke2fs -j /dev/hda5
# mkfs.xfs /dev/hda6
In this instance, /dev/hda2 would be a users swap partition. It is created using the mkswap program:
# mkswap /dev/hda2
Once the swap partition is created, a user can turn it on by using the swapon command:
# swapon /dev/hda2
Mounting the Filesystems
After the partitions have been created and formatted, a user can mount them. A special mount point, /mnt/annvix, exists to be the “root” of the new system. By using the above example, to mount the four partitions under /mnt/annvix, a user would use:
# mount /dev/hda3 /mnt/annvix
# mkdir /mnt/annvix/{boot,home,var}
# mount /dev/hda1 /mnt/annvix/boot
# mount /dev/hda5 /mnt/annvix/var
# mount /dev/hda6 /mnt/annvix/home

If you followed this tutorial guide then you would have learnt about installing Annvix which covers booting the installing the CD and preparing the disks.