Linux Solutions

Welcome to the tutorial guide. This tutorial will provide a user with guidance and instructions on KateOS.

KateOS 3.6 is the latest KateOS release and it is considered to be the best KateOS release. The important additions to the KateOS are provide below:
• Software-driven system hibernation
• Graphical installator of the LIVE edition
• A new version of update-notifier
• All startup scripts now have a ’status’ function, and can be run with the ’service’ command
• Better support for HP printers (via the hplip application)
• Easy internationalization of the entire system (gettext is also supported in scripts, via the ‘_’ function)
• French translation of the CORE installer and many other parts of the system
• Graphical network configuration tool
• The CORE installer now makes it even easier to install the system
• New packages, such as Audacious and Pidgin
• Migration from initrd to initramfs (allows f.ex. for our own DSDT ACPI tables)
Please note that the system is bug-free and more user-friendly. KateOS can address the needs of multiple user groups. Advanced users can choose the Miniiso and only install the packages they will be using in the future. Medium users can choose the CORE version, providing a full control over the installation process, and beginners can limit themselves to the graphical installer, which only requires a couple of clicks to get the system up and running from the hard disk.
The versions of the most important system components
• Linux kernel 2.6.21.4 (with appropriate patches)
• Glibc 2.5
• Xorg 7.2
• KDE 3.5.7
• Xfce 4.4.1
• Gnome 2.18.2
• OpenOffice.org 2.2
As always, Firefox, Thunderbird and OpenOffice.org are available with language packs.
Minimal requirements
• i486 class processor
• 32 MB RAM
• 300 MB space on the hard disk
• VGA video card
• sound card (optional)
• CDROM, floppy drive (if CDROM is not bootable)
Recommended requirements
• i686 class processor, 600 mHz
• 256 MB RAM
• 4 GB space on the hard disk
• SVGA video card
• sound card (optional)
• CDROM, floppy drive (if CDROM is not bootable)
List of packages in KateOS 3.6
A user can choose the ISO images that he/she wants to download, and the mirror that he/she wants to download from. Please note that both KDE and GNOME are available as individual packages from the KateOS repositories. .

Please note that KateOS is available in three versions:
CORE KateOS
• 3 CD’s or one DVD
• for intermediate and advanced users
• lets the user choose the software
• text-mode dialog-based installer
• for server, workstation, desktop

KateOS CORE is the traditional version, on three CDs or one DVD. It contains all the applications which are essential for the desktop, workstation and server. It is targetted toward intermediate and advanced users who want to have full control over the system beginning with the installation. The CORE version lets the user choose the software for installation and system services. Also, it can create an initramfs startup image. It contains a text-mode dialog-based installer which works especially well on older machines. This version is good for those users who know what they want and how they want it.

KateOS LIVE
• one CD
• for newbies and intermediate users
• works directly from the CD
• graphical installer
• for desktop
KateOS LIVE is a full system which works directly from the CD. A user can insert the disc into the CD-ROM drive and boot the computer from it. A fully functional KateOS system will run directly from the disc. KateOS LIVE contains a common set of desktop software. It is a great solution if a user
has no experience with KateOS.

KateOS Miniiso
• one small CD
• for advanced users
• only basic software
• the rest of the system can be installed from network
KateOS MiniISO is a minimial edition containing nothing but the essentials. The installation disc is very small, and the set of software will let a user run the system with access to basic tools. It is meant for advanced users who want to assemble their system and software on their own. A user can easily install all the software that he/she requires from remote repositories.

About Kate OS
Kate OS is a multitasking operating system which provides all that is necessary for programmers, webmasters, administrators and home users. The most important Kate OS features are high efficiency, safety, reliability and low system requirements. Kate OS provides full support for generally used multimedia. Kate OS is a perfect combination of Linux power and utility. The complexity of installed software makes using the system comfortable, immediately after the installation process. Looking for a perfect solution for the experienced UNIX user? Kate OS is perhaps the best one.

KateOS 3.6 Beta 2 has been released
The second beta of KateOS 3.6 is now available. It contains many changes, both important and purely cosmetic ones, such as: new update notifier; new 2.6.21.4 kernel; X.Org 7.2; the newest versions of KDE 3.5.7, GNOME 2.18.2 and Xfce 4.4.1, OpenOffice.org 2.2.0, and many more. The CORE edition also includes a partial French translation of the installer. The second beta also has a lot of bugs eliminated (including some in the KateOS LIVE installer). Everyone is invited to test and share the experience on the KateOS project forum.
New added

1. Glibc 2.5
2. Kernel 2.6.21.4
3. Xorg 7.2
4. Xfce 4.4.1
5. Gnome 2.18.2
6. KDE 3.5.7
7. OpenOffice.org 2.2

KateOS 3.6 Beta has been released

With 3.6 a user can have better control over system services, and a simplified installation. Also, Software Suspend 2 - the system hibernator - is now supported by default. A user can configure the firewall more easily, ssh is secured by default, and support for Hewlett-Packard products is now even better. There are new graphical configuration tools, including the network configurer. KateOS 3.6 will also be the first release with a LIVE version equipped in the graphical installer.

Please note that KateOS 3.6beta contains following:

1. Glibc 2.5
2. Kernel 2.6.19.3
3. Xorg 7.1
4. Xfce 4.4.1
5. Gnome 2.18.1
6. KDE 3.5.6
7. OpenOffice.org 2.2

Kate OS 3.2 is available
KateOS 3.2 is the third edition of the III series. It brings, as usual, many fixes, updates, and novelties the community has been waiting for. It includes a new graphical package management tool, KatePKG, which allows for easy and intuitive installation, removal, and updating of packages. KatePKG can handle any number of repositories, including user-created ones on the local drive.

Kate OS 3.1
Kate OS 3.1 is the second edition of the III series. It fixes many bugs, but also introduces many important changes. Kate OS 3.1 is the first Kate to use the GTK+ 2.10.x library. This is a very substantial change for the entire system, which will let us deliver various new applications. Also, the GNOME desktop environment has been updated to its newest 2.16.0 version. This is the first edition of GNOME especially adjusted to Kate OS. Apart from those, Kate OS 3.1 also features the 2.6.17.13 kernel, XFce 4.4rc1 and numerous updates.

KateOS is a Polish lightweight distribution. Its first version was based o¬n Slackware Linux ( currently KateOS is NO LONGER based on Slackware ). Please note that the servers (WWW, FTP, DHCP) can be set up on KateOS with low overhead. KateOS is fast, efficient and safe.

Important Features

1. low hardware requirements mean KateOS can still be used on i486 machines

2. integration with PAM system, providing a homogeneous authorization environment

3. packages are in TGZex format, easy to build, don’t have any dependencies between the packages, ready to update

4. BSD type, every user can understand and adapt them to meet his own needs

5. easy construction helps to take care of security

6. lightweight and effective desktop XFCE, which provides comfortable environment in graphical mode without hogging computer resources

7. preferred library GTK+, used by almost all applications in graphical mode

8. limited amount of applications in CORE KateOS, programs are integrated with themselves and libraries package of applications/tools, programming libraries

9. multimedia applications allow user to enjoy modern audio/video file formats

10.noncommercial distribution, doesn’t depend on any institution, always FREE

Kate OS 3.0 LIVE
Kate OS is a multitasking operating system which provides all that is necessary for programmers, webmasters, administrators and home users. The most important Kate OS features are high efficiency, safety, reliability and low system requirements. Kate OS provides full support for generally used multimedia. Kate OS is a perfect combination of Linux power and utility. The complexity of installed software makes using the system comfortable, immediately after the installation process.

Kate OS has got following advantages:
1. desktop- aimed mainly at home users, often with low efficiency, doubtful safety and high system requirements.

2. server- focused on safety and efficiency, but with no multimedia programs.

3. general purpose- distributions that contain hundreds of packages with wide dependencies. They often have great system requirements.

Kate OS combines advantages of all these system types. The installation and configuration process of Kate OS is not as simple as in desktop distributions, but the stability and efficiency are incomparably higher.

Kate OS 3.0 Beta (Live)
KateOS LIVE 3.0beta includes most of desktop applications and features Xfce as the graphical environment. The LIVE edition is a complete operating system with automatic hardware detection and auto-mount of all accessible partitions.
Kate OS 3.0 Beta 1
Kate OS 3.0 has subprojects which are: libsmarttools (basic classes/functions used in updateos2 ), libupdateos (provides simple API for remote operations on TGZex packages), and updateos2 (CLI interface for libupdateos).

Kate OS is a multitasking operating system which provides all that is necessary for programmers, webmasters, administrators and home users. The most important Kate OS features are high efficiency, safety, reliability and low system requirements. Kate OS provides full support for generally used multimedia.

Kate OS 3.0 Alpha (Live)
Kate OS 3.0 alpha live edition contains 2.2 GB of data, compressed on a single CD. The system automatically detects hardware, mounts system partitions and enables the user to write directly to NTFS file systems.

Kate OS provides all that is necessary for programmers, webmasters, administrators and home users. The most important Kate OS features are high efficiency, safety, reliability and low system requirements. Kate OS provides full support for generally used multimedia. Kate OS is a perfect combination of Linux power and utility.

If you followed the tutorial guide then you would have learnt bout KateOS.

Welcome to the tutorial guide. The tutorial will provide a user with advise and guidance on Kate linux distribution.

Please note that KateOS III is a modern Linux distribution. It is based on the latest technologies used in production systems, giving it a wide range of supported hardware, security, and efficiency.

KateOS tools
Some of the Kate Operating System tools are provided below:
• PKG - a base tool for managing TGZex packages; it lets the user install, update, and remove packages locally. PKG has replaced the old package management scripts, adding dependencies support and multilingual package descriptions.
• libsmarttools - a C++ library containing a set of base classes and functions helping in the development of system tools. Updateos2 and libupdateos have been created using libsmarttools.
• libupdateos - a C++ library containing classes and functions for remote TGZex packages management. It is the base of the updateos2 tool.
• updateos2 - a tool for remotly installing and updating TGZex packages; a text interface for the libupdateos library.

The aim is to make KateOS user-friendly while maintaining the simplicity of the system structure. Unix users can use KateOS as it meets their needs of an efficient, secure, and practical system.

Let’s see what is good about the KateOS 3.0. KateOS 3.0 fulfills all the resolutions of the new III series. It has been created from scratch, and independently of the previous versions. It has been built with the newest components, and with no obsolete solutions. It does not use the libtercamp or slang1 libraries.

The base system components have been updated, such as the readline libraries, ncurses and the bash shell. The most crucial elements have been chosen in a way which makes the system stay current for as long as two years, provided an appropriate configuration is used. All packages have been compiled with GCC 4.0.X thanks to which possible future problems connected with a shift to GCC 4.1 have already been eliminated. A greater part of the system can work on i486-class processors, but multimedia applications and heavy graphical environments like GNOME and KDE have been optimised for i686 (Pentium 2-class or higher).

Please note that KateOS 3.0 has got read and write support for NTFS partitions. This means that a big part of our users will be able to use the data amassed on Windows boxes, with no problem. During the creation of the system, much attention has been paid to internationalisation. All of the most popular programs (like Firefox and Thunderbird) are equipped with extra language packs which makes it much easier for German, French, Spanish, and Polish native speakers to enjoy KateOS. Another very important feature is the dependencies support, available already at the system installer level. It is certainly good news for intermediate Linux users who had problems using systems without dependency tracking.

There is an addition of the OpenOffice office suite, along with many language packs and dictionaries. Also, a user can begin office work immediately after the installation. KateOS 3.0 also has many more packages than the previous versions. It makes the entire system more complete, and gives the user a wide choice of tools for any given task. KateOS supports ruby programmes.
KateOS 3.0 takes full advantage of Udev, DBus and Hal. It features splendid hardware auto-detection and mobile data storage device (USB keys, CD/DVDs etc.) management. The default desktop is XFCE version 4.4.X featuring among other things desktop icons and multiple desktops. We have paid much attention to the look and feel of the dekstop. A well-chosen theme and wallpaper, along with the Tango icons, make it look nice and clean. There are thousands of changes in the system compared to the previous version, but would be impossible to list them all here; so let’s just leave off with that, having enumerated the most important ones.

What is new in KateOS 3.1?

KateOS 3.1 is the second edition of the III series. It fixes many bugs, like e.g. #0000019 or #0000027 (http://kateos.org/bugs), but also introduces many important changes. KateOS 3.1 is the first Kate to use the GTK 2.10.X library. This is a very substantial change for the entire system, which will let us deliver various new applications. Also, the Gnome desktop environment has been updated to its newest 2.16.0 version. This is the first edition of Gnome especially adjusted to KateOS. Apart from those, KateOS 3.1 also features the 2.6.17.13 kernel, Xfce 4.4rc1 and numerous updates. An interesting novelty is Update-notifier, a task bar applet designed for KateOS which automatically checks for available updates, and allows for easy package selection and update. It is based on the libupdateos library, and ONLY supports the KateOS packages/repositories.

What about the newest version?

KateOS 3.2 is the third edition of the III series. It brings, as usual, many fixes, updates, and novelties the community has been waiting for. It includes a new graphical package management tool, KatePKG, which allows for easy and intuitive installation, removal, and updating of packages. KatePKG can handle any number of repositories, including user-created ones on the local drive. It is the first KateOS graphical package manager but not the last one. Katepkg has been written in PHP using the PHP-GTK2 library. We have chosen this language due to its maturity and the usefulness of PHP-GTK2. Thanks to it we have managed to create a fully functional package manager in a relatively short time. We hope that it will help many people rediscover the power of PHP 5 and PHP-GTK2. The development of the libpkg library is approaching its final phase which means it will soon be ready to become the base of new applications, also for KDE. We hope that thanks to libpkg, libupdateos and libsmarttools, the number of applications written for KateOS will soon grow considerably. We would also like to mention that the libsmarttools library has undergone a major overhaul and optimization, thanks to which applications based on it (including updateos2) will now work up to 60% faster! Another important change is the shift to a new bootloader. We are migrating from LILO to GRUB. We hope it will better meet the needs of our users and make the kernel update process easier. The new version of our distro features the 2.6.18.4 kernel to guarantee stability, efficiency, and support for modern hardware. KateOS 3.2 uses Glibc library 2.5 which ensures binary compatibility with future editions. It also includes the Xfce environment version 4.4RC2, Gnome 2.16.2, KDE 3.5.5, OpenOffice 2.0.4, Firefox 2.0, and many other current applications.

KateOS 3.2 includes following:
• Linux kernel 2.6.18.4
• GCC 4.0.2
• Python 2.4.3
• Perl 5.8.8
• Ruby 1.8.5p2
• Firefox 2.0
• Thunderbird 1.5.0.8
• OpenOffice.org 2.0.4
• Xfce 4.4RC2
• Xorg 7.1

KateOS Requirements:
• i486
• 32 MB RAM
• 300 MB HD (Na ROOT i SWAP)
• VGA card
• karta dźwiękowa (opcjonalnie)
• CDROM (bootowalny), floppy

If a user followed advise and guidance as provided in this tutorial guide then he/she would have learnt about KateOS.

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on how to schedule jobs with uschedule.

Annvix uses the uschedule suite of programs to handle periodic task scheduling, similar to what at would do. According to the uschedule website, uschedule is not cron and uschedule is not at - it does offer similar functionality, but is not intended to be a drop-in replacement. It works differently. It’s designed to be different.

Before we go ahead, it is good to have a brief background.
Background
The reason uschedule is used in Annvix as opposed to at is quite simple. With at, the user-space scheduling tool had to be suid root in order to allow users access to create their own jobs. Likewise, access control was goverened by the /etc/at.allow and /etc/at.deny files.
uschedule, on the other hand, is never run by root. Each user can have their own uschedule daemon, which is run as that user, and only executes commands as that user. root is never involved except to initially setup the uschedule service. This means that we don’t have to ever worry about using access controls to add or remove users from being able to schedule their own jobs. Likewise, users have full control over seeing how their jobs are handled by being able to observe logfiles. If a user should no longer be using uschedule, the service is simply stopped and/or removed. To give a user the ability to use uschedule, root must create the service for them.

How to set up uschedule?
If a user wants to set up uschedule then please follow the guidance and instructions as provided below:
In order to give user ’shafkat’ his own uschedule daemon, root must execute:
# uscheduleconf /var/service/schedule-shafkat shafkat shafkat
# srv –add schedule-shafkat
The uscheduleconf program will create the appropriate directories and run files to be run. This consists of the traditional /var/service/schedule-user run directory and a ~/.uschedule directory in the user’s home directory.

The /var/service/schedule-user/run script looks as follows:
#!/bin/execlineb

/bin/fdmove -c 2 1
/bin/cd /home/user/.uschedule
/sbin/chpst -u user ./run
Essentially, the script is starting /home/user/.uschedule/run as that particular user. The user is perfectly capable of executing ./run on their own, but it won’t be supervised. Keep in mind that this isn’t really a security issue; the user can have their own scheduler running but it won’t be supervised (so no restart if it’s killed) and it can never do anything that the user wouldn’t already be able to do. The user’s ./run script is simply:
#!/bin/execlineb

/bin/fdmove -c 2 1
/sbin/chpst -e ./env /usr/bin/uscheduled -d /home/user/.uschedule
Scheduling tasks with uschedule
Scheduling tasks with uschedule is similar in concept to scheduling tasks with at. The uschedule(1) manpage provides a lot of information on the various options of using and manipulating uschedule jobs, and the uschedulecmd(1) manpage provides information on the uschedulecmd program, which does the actual scheduling.

For example:
$ uschedulecmd -e -i myjob ${HOME}/bin/myjob.sh

This command adds the job titled “myjob” to uschedule. “myjob” is the name of the job; the contents of the job are the ${HOME}/bin/myjob.sh file. Now that the job has been added, it must be scheduled:
$ uschedule -c 1 myjob +03:00:00

This does the actual scheduling of “myjob”. This command tells uschedule to execute “myjob” in exactly 3 hours.

With uschedulecmd there are a few options available for a user to use, notably the -e option. This option instructs uschedulecmd to make an exact copy of the current environment (variables and all) for the new job. The -i option gives the job a name (in the above case, “myjob”). This name must be unique, and must not contain colons, slashes, or dots. If that option is not used, a unique numerical ID will be assigned and printed to standard output.

Beyond that, uschedulecmd does no scheduling. All it does is create new jobs for uschedule to schedule. If a user does not use uschedule to schedule the job, it will remain until it is removed and will never be executed.

uschedule is the “driver” of the system, in that it sets up the job to be run. It has a variety of options, some of which will be noted here; the rest are covered in the manpage. The -c option tells uschedule how often to run the job; in the above it will be executed exactly one time. If a user does not specify a count, it will assume a value of “0″ and will be repeated forever (i.e. if we omitted the count in the above command, “myjob” will be executed every 3 hours).

The final option to provide is the TIMESPEC which tells uschedule when the job needs to be executed. The TIMESPEC is not the same as what is used by at. Here are a few examples:
• +03:00:00 - execute in 3 hours from now
• *-*-7 00:00:00 - execute the job at midnight on the seventh of each month
• Monday *-12-* 12:00:00 - execute the job every monday in December at 12:00
• mon,fri *-1/2-1,3 *:30:45 - execute the job 30 minutes and 45 secions after each full hour on every monday and friday if that day is the first or third day of the month in January, March, May, July, September, and November.

The format of the TIMESPEC consists of two or three words. The first (optional) words specify a day-of-week, the next specify the year, month, and day-of-month, and the last specifies the hour, minutes, and seconds. Words must be separated by one space. Proceeding the TIMESPEC with the “+” character indicates to execute the job at now+TIMESPEC.

Job logging
Job execution information can be viewed by examining ~/.uschedule/log/current; this is the log that uscheduled outputs to about job exectution:
2007-02-09_14:35:15.07130 uscheduled[1472]: started pid 13576 for job @0000000000000000:myjob:3600:1:
Y2007M1D9h14m35s15:::::0
2007-02-09_14:35:15.09255 uscheduled[1472]: deleted job myjob
2007-02-09_14:35:22.79926 uscheduled[1472]: processs 13576 terminated with code 0

Listing jobs in the queue
A user can see what jobs are scheduled by using uschedulelist. Any pending jobs will be printed out. If a user wants to view all of the registered commands that uschedule knows of, use uschedulelist -c:
$ uschedulelist -c
myjob
size: 46
links: 1
modification: 2007-02-08 14:48:13

Removing finished jobs
Jobs are never removed once they are completed. In order to remove a job that will not be executed again, use uschedulerm. There are two modes for uschedulerm:
• uschedulerm myjob - deletes all jobs with the identifier “myjob”
• uschedulerm -c myjob - deletes registered commands instead of jobs
In other words, to entirely get rid of a job, a user must use the -c option. If a user wants to delete a job that has not been completed yet, or a job that is persistent, the first invocation will delete any pending jobs scheduled. The second invocation deletes the actual job itself:
$ uschedulerm -c myjob

Configuring services with ipsvd
Ipsvd default environment variables
Ipsvd uses the following default environment variables:
• IP - IP address of service (default = 0)
• PORT - Port of the service
• MAX_CONN - Maximum number of connections (default = 20)
• MAX_PER_HOST - Maximum number of connections per ip (default = 5), a user can also add a suffix of :msg for an error message to be displayed.
• MAX_BACKLOG - number of backlog of TCP SYNs (default = 20)
• HOSTNAME - name of the host.
Sample run script
#!/bin/execlineb

/bin/fdmove -c 2 1

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

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

/sbin/tcpsvd -v -l $HOSTNAME -x peers.cdb -c $MAX_CONN -C “$MAX_PER_HOST” -b $MAX_BACKLOG $IP $PORT
…

If you followed the tutorial guide then you would have learnt about how to schedule jobs with uschedule.

Welcome to the tutorial guide. The tutorial will provide a user with advise and guidance on system logging with socklog.

As of Annvix 1.1-RELEASE the socklog program has been provided as an alternative to syslogd and klogd. As of 2.0-RELEASE, socklog is the default logger installed and the sysklogd package has been removed.

A user should note that socklog is an alternative secure system logger with a lot of features. It uses the default svlogd program to handle the actual logging; socklog itself just listens to sockets, be they UNIX sockets, TCP ports, or UDP ports. Because of this, socklog is very extensible and offers features that syslogd can’t, including:

remote logging via TCP
receiving remote logs via TCP
automatic log rotation

Let’s have a look at log directories versus log files.

Log directories vs. log files
The socklog package in Annvix comes with three default services: socklog-unix, socklog-klog, and socklog-rklog. The first service listens to the standard /dev/log socket that is used by applications to send messages to the syslog. The second receives messages from /proc/kmsg (normally klogd would receive these messages and relay them to the syslog); the socklog-klog service does not relay these messages to the system logger but manages the logs itself. Likewise, socklog-rklog receives messages from /proc/rsbac-info/rmsg which are RSBAC-related kernel messages (NOTE, as of RSBAC 1.2.5.1 it does not look like the configuration option CONFIG_RSBAC_RMSG_EXCL works so messages from RSBAC still end up being sent via /proc/kmsg in addition to /proc/rsbac-info/rkmsg).
As a result, instead of kernel logs ending up in /var/log/kernel (and in /var/log/messages, the kernel logs end up in the /var/log/system/kmsg directory, with the current file being the most recent logfile. The RSBAC kernel logs end up in /var/log/system/rkmsg.

A user should note that normal logfiles that would normally populate /var/log (such as auth.log, boot.log, messages, and so forth are no longer used and can be safely removed from the system once socklog is installed. Instead, the default socklog configuration is to log the following facilities to the following log directories:

all logs: /var/log/system/all
auth.* and authpriv.*: /var/log/system/auth
local7.*: /var/log/system/boot
cron.*: /var/log/system/cron
daemon.*: /var/log/system/daemon
*.debug: /var/log/system/debug
ftp.*: /var/log/system/ftp
kern.*: /var/log/system/kern
local.*: /var/log/system/local
mail.*: /var/log/system/mail
*.info (excluding mail.info, news.info, authpriv.info and kern.info): /var/log/system/messages
news.*: /var/log/system/news
syslog.*: /var/log/system/syslog
user.*: /var/log/system/user

Within each directory is the current file which is the latest log and other files using a TAI64 timestamp that indicate the date of rotation (i.e. @4000000043ed4a8b03f03b6c.s). Also, within each file is a config file which tells svlogd what to log; for instance the /var/log/system/messages/config file looks like:
-*.*
+*.info*
-mail.*
-news.*
-authpriv.*
-kern.*

Order is important; here everything is deselected first, then all *.info priorities are added and finally, selectively, various facilities are removed that are not desired to be logged there.

Customizing socklog
The default socklog configuration is adequate for most people with a single-log system (i.e. not receiving remote logs nor sending them). However, it is desirable to be able to send (and receive) logs to other systems. Even adding new facilities or manipulating logging on a single system may be desirable.

Configuring svlogd
svlogd is told what directories to read config files from via the logging runscript for a service, so for socklog-unix this would be in the file /var/service/socklog-unix/log/run. This file contains, by default:
#!/bin/execlineb

/bin/cd /var/log/system
/sbin/chpst -u syslogd /sbin/svlogd
/var/log/system/all
/var/log/system/auth
/var/log/system/boot
/var/log/system/cron
/var/log/system/daemon
/var/log/system/debug
/var/log/system/ftp
/var/log/system/kern
/var/log/system/local
/var/log/system/mail
/var/log/system/messages
/var/log/system/news
/var/log/system/syslog
/var/log/system/user

As can be seen here, arguments to svlogd are the full paths to directories containing config files (which will also in turn contain log files). To, for instance, log openldap messages (which, when the openldap-server package is installed modifies /etc/syslog.conf to send local0.* logs to /var/log/ldap/ldap.log), a user would add /var/log/system/ldap to the end of the directory list in the run script.

A user can now create the /var/log/system/ldap directory:
# mkdir /var/log/system/ldap
# chmod 770 /var/log/system/ldap
# chown root:syslogd /var/log/system/ldap
Then create the /var/log/system/ldap/config file, which would contain:
-*
+local0.*

If user wants to restart svlogd, then he/she needs to send it a HUP using runsvctrl: (/sbin/runsvctrl h /service/socklog-unix/log). Now svlogd has been restarted and will begin to log the newly added ldap configuration.

Logging to a remote server using UDP
It should be noted that while socklog supports receiving logs via UDP, using UDP as a transmission medium should be avoided if at all possible because UDP is both unreliable and insecure. If at all possible, use TCP to transmit log data (if the sending/receiving servers support it, i.e. using socklog or syslog-ng or another system logger than can send/receive logs via TCP).

If a user wnats to instruct svlogd to log to a remote server over UDP (for instance, to a remote syslogd server), then he/she has to create a new configuration directory and file as indicated above but use the directory /var/log/system/remote with the contens of /var/log/system/remote/config being:
+*.*
s9999
n2
U192.168.1.2:514

Then a user has to restart svlogd . This will instruct svlogd to send what it receives to the remote system (192.168.1.2) on port 514 using the UDP protocol. This also tells svlogd to rotate the log every 10KB (triggering the sending of the log to the remote host) and tells svlogd to maintain a maximum number of 2 old log files (in the case of transmission failure).

Please note that using “U” here tells svlogd not to maintain a local copy of the logs (although any errors are logged to current); instead it will send the log files as soon as it receives them. A user can send UDP logs onto another logging directory (say all), by using “u” instead of “U” (read the svlogd(8) manpage for more info). For ease of configuration, having a separate logging directory designated as the “to-remote” log may be a better idea than modifying other configurations.

Receiving logs from a remote server using UDP
Install the socklog-remote package; this package comes with default run scripts to receive TCP- and UDP-based log messages. Before starting socklog-udp, edit the /var/service/socklog-unix/log/run as by default it receives all logs to /var/log/system/remote/all-udp and it is sometimes a good idea to further split the logs based on the sender’s IP address. The resulting run script may look like:
#!/bin/execlineb

/bin/cd /var/log/system/remote
/sbin/chpst -u syslogd /sbin/svlogd
/var/log/system/remote/all-udp
/var/log/system/remote/192.168.1.12
The first run script tells socklog to listen to port 514 on all hosts with the inet protocol UDP.
By default, socklog-udp listens on UDP port 514 (the default syslog port) which can be modified by changing /var/service/socklog-udp/env/PORT. A user can also specify what IP address to bind by creating /var/service/socklog-udp/env/IP with the IP address a user wants the service to bind to (the default is all).

The received logs are printed to STDOUT (prefixed with the sender’s IP address), so the log/run script handles the actual logging. In this case, it will log all received UDP syslog messages to /var/log/system/remote/all and will log messages from the sender IP 192.168.1.12 to /var/log/system/remote/192.168.1.12 via the following config files:
The /var/log/system/remote/all-udp/config file, by default, looks like:
+*.*
and the /var/log/system/remote/192.168.1.12/config file should look like:
-*
+192.168.1.12:*

A user can add subsequent IP-based directories (i.e. perhaps a /var/log/system/remote/192.168.1.13 directory) to handle logging for more than one sending IP. If separating logs per host is not a concern, do away with the IP-based logging directories. The rationale behind an “all” directory and IP-based directories is to ease separation of logs per host (something syslog cannot easily do) and also provide a “master” log that can be used by tools such as swatch.

If a user wants to add this new service, then he/she can use srv –add socklog-udp (if a user can make the appropriate changes in /var/service/socklog-udp before adding the service, a user can save himself/herself a restart). A user should remember to send the socklog-udp/log service a KILL signal if configuration changes are made; this can be accomplished with either runsvctrl k /service/socklog-udp/log or srv -f –restart socklog-udp/log.

Logging to a remote server using TCP
When logging to a remote server, a user can choose to send the logs to the remote server instead of keeping them on the system, or a user can log both to the system and to the remote server. Note that this will not pick up kernel logs (which the socklog-klog service monitors), although a user can do a similar type of configuration for socklog-klog or a duplicate service to handle it.
If a user wants to log to a remote system via TCP instead of logging locally, change /service/socklog-unix/log/run to look like:
#!/bin/execlineb

/bin/cd /var/log/system
/sbin/chpst -u syslogd /sbin/svlogd
/var/log/system/all
Next, edit the /var/log/system/all/config file which should look similar to:
+*.*
s2048
n20
!tryto -pv nc -q 1 192.168.1.2 12000

This instructs svlog to set the log size to 2KB and to keep a maximum of 20 log files. The “!tryto” indicates using the tryto program as a pre-processor; svlogd will run tryto with the specified arguments before rotating the log. The “-pv” option tells tryto that it is being used as a svlogd pre-processor and to be verbose about what it is doing. The next option tells tryto to execute nc (netcat); what it does is feed it’s STDIN to nc as STDIN. In this case, nc is told to send it’s STDIN to the IP address 192.168.1.2 on port 12000. Change the IP address and port number to suit a user configuration. A user will need to install the nc package. The “-q 1″ option to nc tells it to wait 1 second after an EOF is detected; if a user doesn’t include this option nc will continue to hang around long after it should.

Please note that depending on the system, 2KB chunks may be too fast or too slow so a user should determine how often they’re sent to the remote system before settling on a particular size. What happens here is that on every rotation, nc is being used to send the contents of current; in other words if it takes three weeks to fill up 4KB of content, it will be three weeks before the log is transmitted.

If a user wants to mantain system logs and log remotely, change /service/socklog-unix/log/run and add another directory to the end of the directory list, perhaps /var/log/system/toremote, then create the directory (making sure it is owned root:syslogd and mode 0770) with a config file with contents identical to what was previously noted:
+*.*
s2048
n20
!tryto -pv nc 192.168.1.2 12000

This acts the same as the previous configuration, however here we are adding another logging directory who’s sole job is to feed received logs to the remote system, without interfering with what is locally logged.

Receiving logs from a remote server using TCP
As with receiving logs over UDP, install the socklog-remote package to get the default run scripts, for this service we’re interested in socklog-tcp. By default the service uses tcpsvd to listen to the local TCP port (5140 by default but this can be changed by modifying /var/service/socklog-tcp/env/PORT). When connections are received on this port, the connection is passed off to socklog which is using the ucspi connection method. A user can also specify what IP address to bind to (if a user wants to be explicit) by creating /var/service/socklog-tcp/env/IP with the IP address a user wants the service to bind to (the default is all).

Handling the logs is very similar to handling incoming UDP logs. Modify the /var/service/socklog-tcp/log/run script to look like the following (to again allow for per-IP directory logging; the default simply logs all TCP-based logs to /var/log/system/remote/all-tcp):
#!/bin/execlineb

/bin/cd /var/log/system/remote
/sbin/chpst -u syslogd /sbin/svlogd
/var/log/system/remote/all-tcp
/var/log/system/remote/192.168.1.12

The received logs are printed to STDOUT (via socklog and prefixed with the sender’s IP address), so the log/run script handles the actual logging. In this case, it will log all received TCP syslog messages to /var/log/system/remote/all-tcp and will log messages from the sender IP 192.168.1.12 to /var/log/system/remote/192.168.1.12 via the following config files:
The /var/log/system/remote/all-tcp/config file looks like:
+*.*
and the /var/log/system/remote/192.168.1.12/config file should look like:
-*
+192.168.1.12:*

Add subsequent IP-based directories (i.e. perhaps a /var/log/system/remote/192.168.1.13 directory) to handle logging for more than one sending IP. If separating logs per host is not a concern, do away with the IP-based logging directories. The rationale behind an “all” directory and IP-based directories is to ease separation of logs per host (something syslog cannot easily do) and also provide a “master” log that can be used by tools such as swatch.

If a user wants to add this new service, then he/she should use srv –add socklog-tcp (if a user can make the appropriate changes in /var/service/socklog-tcp before adding the service, a user can save himself/herself a restart).

A user should remember to send the socklog-tcp/log service a KILL signal if configuration changes are made; this can be accomplished with either runsvctrl k /service/socklog-tcp/log or srv -f –restart socklog-tcp/log.

If a user has followed this tutorial guide then he/she would have learnt about system logging with socklog.

Welcome to the tutorial guide. The tutorial will provide a user with guidance and instructions on using the tcb shadow alternative. Please note that the tcb package is a replacement for the traditional method of storing encrypted passwords in the /etc/shadow file.

There are benefits of using tcb. These are provided below:
By using tcb, each user gains access to their shadow password, and their shadow password only. There is no need for a setuid root passwd program.
Also, by using tcb, it uses blowfish passwords by default, rather than the more insecure md5 password.
Please note that for new users who install Annvix 2.0 do not require anything to begin using tcb; as of 2.0-CURRENT, tcb and blowfish passwords are the default. Users upgrading from a previous version of Annvix will transparently be using tcb after executing the upgrade script that upgrades 1.2 to 2.0.

Before the Upgrade
Before a user upgrades to 2.0, it is recommended to know if there are two consoles or ssh sessions open to the system that a user is upgrading. These two consoles are:
a regular user,
the other as root.
If a user doesn’t do this then there is a risk for a user to completely lock himself/herself out of the system until the upgrade is complete.
Another way of upgrading the system is by using the upgrade script.
Converting /etc/shadow to the tcb format
A user should note that there are various steps to conver /etc/shadow to the tcb format.
A user has to to convert the existing shadow password entries into individual tcb entries. Please note that the tcb structure for storing passwords does not use a single file, like /etc/shadow but instead a directory structure like /etc/tcb/joe where joe is the user and joe’s shadow password is stored in the file /etc/tcb/joe/shadow. A user can do this by executing the /sbin/tcb_convert program as root.
The resulting directory structure of /etc/tcb will look like this:
# ls -dl /etc/tcb
drwx–x— 30 root shadow 4096 Jul 6 21:23 /etc/tcb/
# ls -l /etc/tcb/
total 0
drwx–s— 2 adm auth 19 Jul 6 21:23 adm/
drwx–s— 2 apache auth 19 Jul 6 21:23 apache/
drwx–s— 2 bin auth 19 Jul 6 21:23 bin/
drwx–s— 2 builder auth 19 Jul 6 21:23 builder/
drwx–s— 2 daemon auth 19 Jul 6 21:23 daemon/
drwx–s— 2 halt auth 19 Jul 6 21:23 halt/
drwx–s— 2 joe auth 19 Jul 6 21:23 joe/
drwx–s— 2 logger auth 19 Jul 6 21:23 logger/
drwx–s— 2 lp auth 19 Jul 6 21:23 lp/
drwx–s— 2 mail auth 19 Jul 6 21:23 mail/
drwx–s— 2 mysql auth 19 Jul 6 21:23 mysql/
drwx–s— 2 news auth 19 Jul 6 21:23 news/
drwx–s— 2 nobody auth 19 Jul 6 21:23 nobody/
drwx–s— 2 operator auth 19 Jul 6 21:23 operator/
drwx–s— 2 postfix auth 19 Jul 6 21:23 postfix/
drwx–s— 2 root auth 19 Jul 6 21:23 root/
drwx–s— 2 rpm auth 19 Jul 6 21:23 rpm/
drwx–s— 2 rsbadmin auth 19 Jul 6 21:23 rsbadmin/
drwx–s— 2 rsbdata auth 19 Jul 6 21:23 rsbdata/
drwx–s— 2 rsbtpmgr auth 19 Jul 6 21:23 rsbtpmgr/
drwx–s— 2 shutdown auth 19 Jul 6 21:23 shutdown/
drwx–s— 2 snort auth 19 Jul 6 21:23 snort/
drwx–s— 2 sshd auth 19 Jul 6 21:23 sshd/
drwx–s— 2 svn auth 19 Jul 6 21:23 svn/
drwx–s— 2 sync auth 19 Jul 6 21:23 sync/
drwx–s— 2 syslogd auth 19 Jul 6 21:23 syslogd/
drwx–s— 2 vcsa auth 19 Jul 6 21:23 vcsa/
# ls -l /etc/tcb/joe/
total 4
-rw-r—– 1 joe auth 58 Jul 6 21:23 shadow
# cat /etc/tcb/joe/shadow
joe:$2a$08$abcdefghijklmnopqrstuuz29TNT43FrbrkSgusq0SUVtGQkhH2mm:13112:0:99999:7:::

Lookups with tcb (/etc/nsswitch.conf)
When the new glibc package was installed, it either modified the existing nsswitch.conf file to use tcb shadow entries or, if a user modified it (i.e. to use LDAP) then it created a new file: /etc/nsswitch.conf.rpmnew. This file contains the default entry of using tcb for shadow passwords. A user will need to copy this file over the previous file or a user will need to manually edit /etc/nsswitch.conf by changing:
shadow: files nisplus nis
to:
shadow: tcb nisplus nis
After a user has made this change, the system will use nss_tcb to do lookups for shadow passwords via the tcb files.
If a user is using LDAP for lookups, then he/she can simply replace “files” with “tcb” on the shadow line, be it before or after the “ldap” entry. A user can then test it by executing, as root getent shadow. In this way, a user will be able to get a list of all the shadow entries for all the users on the system. When a user verifies that this works, a user should rename /etc/shadow to /etc/shadow.bk and test it again. If this continues to work, a user should delete the moved file and the /etc/shadow- backup file.

Authenticating with tcb (/etc/pam.d/system-auth)
If a user wants to actually authenticate against tcb, then a user should pam_tcb installed; the upgrade will have done this for the user. As with nsswitch.conf, if a user has made no changes to the default /etc/pam.d/system-auth file, the new pam will replace the file with calls to pam_tcb instead of pam_unix. Regardless of this change, because pam_tcb understands shadow passwords, if a user chooses not to convet to tcb, the existing shadow entries will continue to be read. If a user has followed the instructions up to this point and has deleted the old shadow files, then the system will be using tcb immediately.

If a user has made changes to system-auth, then he/she will need to merge back the changes from the newly-created system-auth.rpmnew file. A user should note that the changes were to switch from pam_unix to pam_tcb, and also switch from pam_cracklib to pam_passwdqc. A user should change the pam_cracklib entries because pam_cracklib is no longer shipped with Annvix. A user should leave pam_unix as is, because a symlink for compatibility was created, but it is not advised.
The new system-auth file is displayed below:

#%PAM-1.0
# $Id: system-auth.pamd 5743 2006-07-04 04:49:31Z vdanen $

auth required pam_env.so
auth required pam_tcb.so shadow fork nullok prefix=$2a$ count=8

account required pam_tcb.so shadow fork

password required pam_passwdqc.so min=disabled,12,8,6,5 max=40 passphrase=3 match=4 similar=deny \
random=42 enforce=everyone retry=3
password required pam_tcb.so use_authtok shadow write_to=tcb fork nullok prefix=$2a$ count=8

session required pam_limits.so
session required pam_tcb.so
Some good points to note are provided below:
If a user wants to continue using md5 passwords then he/she can do it bymodifying the password entry to remove “prefix=$2a$ count=8″ and replace it with “md5″
If a user wants to continue using /etc/shadow instead of tcb files, then he/she should remove the “write_to=tcb” portion of the password entry
After a user has comleted the pam modification, then he/she should attempt to use sudo from the unprivileged account to become root.

A user should use the passwd program to change his/her password. This will test to if pam_tcb is properly reading from and writing to the tcb files and also ensure that the password is stored as a blowcrypt-based password rather than the undesirable md5-based password.

tcb and LDAP together
A user can use a /etc/pam.d/system-auth file like the following to use both tcb and LDAP-based logins together. If the system is setup correctly to permit users to change their LDAP password with the passwd command, then he/she can continue to permit password changes. It is good to note that passwords will be stored in the LDAP database with the pre-existing settings. LDAP does not understand or use blowfish passwords.
#%PAM-1.0
# $Id: system-auth.pamd 5743 2006-07-04 04:49:31Z vdanen $

auth required pam_env.so
auth sufficient pam_tcb.so shadow fork nullok prefix=$2a$ count=8
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

account sufficient pam_tcb.so shadow fork
account sufficient pam_ldap.so
account required pam_deny.so

password required pam_passwdqc.so min=disabled,12,8,6,5 max=40 passphrase=3 match=4 similar=deny \
random=42 enforce=everyone retry=3
password sufficient pam_tcb.so use_authtok shadow write_to=tcb fork nullok prefix=$2a$ count=8
password sufficient pam_ldap.so use_authtok
password required pam_deny.so

session required pam_limits.so
session sufficient pam_tcb.so
session sufficient pam_ldap.so
session required pam_deny.so
As well, /etc/nsswitch.conf will look like:
passwd: files ldap nisplus nis
shadow: tcb ldap nisplus nis
group: files ldap nisplus nis
A user should set “tcb” before “ldap” on the shadow entry.
Tweaking /etc/login.defs
If a user has changed /etc/login.defs then he/she will need to manually merge in the changes from the login.defs.rpmnew file. Some new options are provided below:
#
# The password hashing method and iteration count to use for group
# passwords that may be set with gpasswd(1).
#
CRYPT_PREFIX $2a$
CRYPT_ROUNDS 8

#
# Whether to use tcb password shadowing scheme.
#
USE_TCB yes

#
# Whether newly created tcb-style shadow files should be readable by
# group “auth”.
#
TCB_AUTH_GROUP yes

#
# Whether useradd should create symlinks rather than directories under
# /etc/tcb for newly created accounts with UIDs over 1000. See tcb(5)
# for information on why this may be needed.
#
TCB_SYMLINKS no
If a user doesn’t want tcb support and has not enabled it then he/she will need to disable USE_TCB and if a user doesn’t want blowcrypt passwords, then he/she should change CRYPT_PREFIX to “$1$” and comment outCRYPT_ROUNDS.

If a user followed this tutorial guide then he/she would have learnt about using the tcb shadow alternative.

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

Before we start the process of configuring AppArmor, we will have a look at what is AppArmor.
AppArmor
AppArmor is a user friendly, easy to use and effective Linux security system that makes use of the Linux 2.6 kernel’s Linux Security Modules (LSM) interface. AppArmor protects the system and applications from other applications that may be exploited by an attacker. AppArmor does not require extensive policies that affect every running system. AppArmor can easily be configured to contain only specific applications. Annvix also includes RSBAC for full Mandatory Access Control if required, however AppArmor makes an excellent stop-gap for a number of network-facing applications and services that require additional protection without impeding those applications that do not.

How to start AppArmor?
Annvix installs AppArmor including apparmor-profiles, apparmor-utils, and apparmor-parser. There is an initscript that starts and stops AppArmor support on Annvix. This initscript can be enabled or disabled by using following command:
# service apparmor start
and
# service apparmor stop
A user will note that on the first boot of Annvix, AppArmor is started, using the default profiles, and ready to begin protecting users system.

AppArmor Configuration Files
The AppArmor’s configuration files can be found in the /etc/apparmor.d directory. The files contained here take the form of full system path names, so /usr/bin/exim would have a profile named /etc/apparmor.d/usr.bin.exim.
Configuration files for the operation of AppArmor itself are contained in the /etc/apparmor directory. In the /etc/apparmor/profiles/extras directory are a number of profile files that can be experimented with and/or used but are not enabled by default for various reasons.

AppArmor Profile
An AppArmor profile consists of a file in the /etc/apparmor.d directory with a filename similar to the application’s path name, such as /usr/bin/exim would become /etc/apparmor.d/usr.bin.exim.
An example profile for /sbin/klogd would be named /etc/apparmor.d/sbin.klogd and contain:
# $Id: sbin.klogd 12 2006-04-12 21:35:41Z steve-beattie $
# ——————————————————————
#
# Copyright (C) 2002-2005 Novell/SUSE
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public
# License published by the Free Software Foundation.
#
# ——————————————————————

#include

/sbin/klogd {
#include

capability sys_admin,

/boot/System.map* r,
/proc/kmsg r,
/sbin/klogd rix,
/var/log/boot.msg rwl,
/var/run/klogd.pid rwl,
}
A user can see that the lines beginning with ‘#’ are comments, the exception being #include statements.

The application’s profile begins with the full name and path of the program to contain. Please note that this is one fundamental difference between AppArmor and other solutions like RSBAC and SELinux. AppArmor performs path-based operations on programs where as RSBAC and SELinux are inode-based. If a user has a hardlink copy of the file, the hardlink would not be protected without it’s own profile.

The curly braces ({}) serve as a container for include statements to other profiles and also for path and capability entries. The capability entry statements enable each of the 29 POSIX.1e draft capabilities. Please note that the path-based entries indicate access rights for the program being contained. In this case, the /boot/System.map* files are available for reading, /proc/kmsg is available for reading, /sbin/klogd (the program itself) is available for reading and executing, /var/log/boot.msg is available for reading, writing and linking, and /var/run/klogd.pid is also available for reading, writing, and linking. Path entries take the form “/path/to/file [mode]”. The path entry can be the full path and filename or can be a path using regular expression globbing.

When an application has a profile, only those files, modes, and POSIX capabilities specified can be used by the application. These restrictions are in addition to native ACLs (so, for instance, if a program does not have access to /etc/passwd, permitting access in the profile will not magically grant access to the file).

File Permission Access Modes
The following is a list of file permission access modes that AppArmor uses:
r - read mode
w - write mode
px - discrete profile execute mode
ux - unconstrained execute mode
ix - inherit execute mode
l - link mode
Read mode allows the program to have read access to the resource. Read access is required for shell scripts and other interpreted content and determines if an executing process can core dump or be attached to with ptrace(2). Write mode allows the program to have write access to the resource. This must be available for files to be unlinked (removed).

Discrete profile execute mode is a mode that requires that a discrete security profile is defined for a resource executed at an AppArmor domain transition. If no profile is defined, access is denied. This mode is incompatible with inherit and unconstrained execute entries. Unconstrained execute mode is a mode that allows the program to execute a resource without any AppArmor profile being applied to the executed resource. This mode is incompatible with inherit and discrete execute entries.
The unconstrained execute mode is useful when a confined program needs to be able to perform a privileged operation, such as rebooting the machine.

Inherit execute mode is a mode that prevents the normal AppArmor domain transition on execve(2) when the profiled application executes the resource. Instead, the executed resource inherits the constraints of the current profile. This mode is incompatible with the discrete and unconstrained execute entries.
The inherit execute mode is useful when a confined program needs to call another confined program without gaining the permissions of the target’s profile or losing the permissions of the current profile.
Link mode is a mode that grants access to symlinks and hardlinks the privileges to unlink (or delete) files. When a link is created, the file that is linked to must have the same access permissions as the link created (with the exception that the destination does not have to have link access).

Using genprof to Profile an Application
A user will note that genprof is the utility used to generate profiles for applictions. Genprof is the scan /var/log/system/audit/current for events, which is provided below:

type=APPARMOR msg=audit(1182207408.754:34): PERMITTING access to capability ’setgid’ (ntpd(18040) profile /usr/sbin/ntpd active /usr/sbin/ntpd)
type=APPARMOR msg=audit(1182207408.754:35): PERMITTING access to capability ’setuid’ (ntpd(18040) profile /usr/sbin/ntpd active /usr/sbin/ntpd)
type=APPARMOR msg=audit(1182207408.754:36): PERMITTING r access to /etc/hosts (ntpd(18039) profile /usr/sbin/ntpd active /usr/sbin/ntpd).

If a capability is requested but not available for the program, the audit log will note this. genprof takes these and allows a user to build profiles based on this information. For instance, to profile /usr/sbin/ntpd, a user can use following:
# genprof /usr/sbin/ntpd

A user can in another terminal, execute /usr/sbin/ntpd and let it run. When it has run sufficiently long enough for it to do most of what it would do, press S in genprof to scan the audit log for events. It will notify user as to what events took place, and a user can determine whether or not to allow the events. This can be done by creating a new profile and placing it into “complain” mode. After a user has done this, he/she can then press F to finish, and the new profile is written and placed into “enforce” mode.

If a user has followed this tutorial guide then he would have learnt about Configuring AppArmor.

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.