Linux Solutions

In this article a user will learn about securing Linux production systems. It will cover areas such as physical Security, verifying security action items, retiring linux servers with sensitive data, backups, removing unnecessary software packages, patching linux systems and closing network ports and disabling runlevel system services and Xinetd services.

Now, let’s look at following areas of cover:
Physical Security
A user should consider physical security as of high importance and for that Linux production servers should be in locked datacenters where only people with passed security checks have access. Another useful thing regarding security is to take boot loader passwords.

Verifying Security Action Items
A user should also look into scripts that can verify that all the security action items have been executed. Please note that even the best sysadmins can make mistakes and miss steps. If a user has a larger Linux environment, it would be a good investment to write scripts for checking Linux security action items.

Retiring Linux Servers with Sensitive Data
If a user is interested in retiring Linux servers with sensitive data then he/she should understand that data cannot be recovered from the hard disks. In order to verify that all traces of data are removed, the DiskSanitizer tool can be used. This tool can be operated from a floppy disk and it removes data.

Backups
If a users system gets compromised, then the backups become invaluable. Backups are of high importance as in cases like bugs, accidents etc. backups can be used to compare the current system against the backed-up system. Backups hold importance for production systems and the backups should be taken offsite for cases like disasters.

Disk Partitions
A user should be aware that servers should have separate partitions for at least /, /boot, /usr, /var, /tmp, and /home. A user shouldn’t have logging and temporary space under /var and /tmp fill up the root partition. Third party applications should be on separate filesystems as well, e.g. under /opt.

Firewall (iptables)
A user should note that firewalls can be used to protect the servers in a production network.

SELinux
Please note that SELinux is an advanced technology for securing Linux systems. Hardening Linux using SELinux technology, on its own, warrants it’s own security. The SELinux technology is recommended for securing Linux systems and this is why a user should consider using SELinux.
FTP, telnet, and rlogin (rsh)

FTP, telnet, and rlogin (rsh) are vulnerable to eavesdropping, which is one of the reasons why SSH/SCP/SFTP should be used instead. It is highly recommended not to run these services. Due to the high risk, this guide does not cover these services. It would also be a good idea not to have FTP and Telnet server RPMs installed on the system.

How to remove unecessary Software Packages (RPMs)?
It is a good idea to establish the software packages that are not necessary. This is because some of the software packages that are not necessary might not comply with the security policy. After removing the unnecessary software packages, it will be easy for a user to update nad maintain when security alerts and patches are released. A good example is of packages such as Apache or Samba installed on the system which a user doesn’t use them. Another useful advise is not to have development packages and desktop software packages (such as X Server) etc. installed on production servers. Also, packages such as FTP and Telnet daemons should not be installed as well unless there is a justified business reason for it (SSH/SCP/SFTP should be used instead).

The first step is to create a Linux image that only contains RPMs needed by the applications, and needed for maintenance and troubleshooting purposes. A good approach is to start with a minimum list of RPMs and then add packages as needed. It may be time-consuming but worth the efforts.

Useful commands
A list of useful commands that a user can note are provided below:
- If a user wants to get a list of all installed RPMs then he/she can use the following command:
rpm –qa
- If a user wants to know more about a particular RPM, then he/she can run:
rpm -qi
- If a user wants to check for and report potential conflicts and dependencies for deleting a RPM, then he/she can run:
rpm -e –test
Patching Linux Systems
A user should also note that in order to secure Linux production environments, it is a good idea to build an infrastructure for patch management. It is recommended to have a written security policy and procedure to handle Linux security updates and issues.

For example, a security policy should detail the timeframe for assessment, testing, and rollout of patches. Network related security vulnerabilities should get the highest priority and should be addressed immediately within a short timeframe.

For example, a security procedure should detail the process for assesment, testing, and rollout of patches. The assessment phase should occur within a testing lab, and initial rollout should occur on development systems first.

A separate security log should detail what Linux security notices have been received, when patches have been researched and assessed, when patches have been applied etc. For Red Hat systems, it is recommended to use Red Hat Network (RHN) for patch management. In fact, for secure environments a user can also take into account the Red Hat’s Satellite solution.

Detecting Listening Network Ports
One of the most important tasks is to detect and close network ports that are not needed.
In order to obtain a list of listening network ports (TCP and UDP sockets), a user can run the following command:
# netstat -tulp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 *:auth *:* LISTEN 2328/xinetd
tcp 0 0 localhost.localdomain:smtp *:* LISTEN 2360/sendmail: acce
tcp 0 0 *:ssh *:* LISTEN 2317/sshd

A user can easily see from the output that xinetd, sendmail, and sshd are listening.

On all newer Red Hat Linux distributions sendmail is configured to listen for local connections only. Sendmail should not listen for incoming network connections unless the server is a mail or relay server. If a user wants to confirm that then he/she should run a port scan from another server. In order to run a port scan from another server a user can run following command:
# nmap -sTU

Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2004-12-10 22:51 CST
Interesting ports on jupitor (172.16.0.1):
(The 3131 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
113/tcp open auth

Nmap run completed — 1 IP address (1 host up) scanned in 221.669 seconds
#
Please note that the mentioned nmap command can take a while. If a user wants to remove the UDP port scan (without the option “-U”), then nmap will finish the port scan immediately. If a user runs it on the local machine it will also complete very fast. A user should also note that nmap might not show all listening network sockets if a firewall is being used to block ports.

From the output above a user can see that the xinetd daemon is listening on port auth (port 113) for IDENT. A user can also see that sendmail is not listening for remote incoming network connections.

There is another method to list all of the TCP and UDP sockets to which programs are listening is lsof:
# lsof -i -n | egrep ‘COMMAND|LISTEN|UDP’
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 2317 root 3u IPv6 6579 TCP *:ssh (LISTEN)
xinetd 2328 root 5u IPv4 6698 TCP *:auth (LISTEN)
sendmail 2360 root 3u IPv4 6729 TCP 127.0.0.1:smtp (LISTEN)
#

Closing Network Ports and Disabling Runlevel System Services
One of the most important tasks is to remove any network services from the system startup process that are not required.

On Red Hat systems if a user wants a list of all services that are started at bootup then he/she can run following command:
chkconfig –list |grep on

A user will also notice that there are quite a lot of services enabled on the system. But many runlevel services (Stand-Alone Services) are not network related services like kudzu which is responsible for detecting and configuring new and/or changed hardware on your system. This service is only run during the boot process. It is important to know that a user should not disable runlevel services that are required by the system to run smoothly.

Red Hat Runlevel System services
There are a number of Red Hat Runlevel Systerm servies that a user can enable if he/she wants to depending on his needs and requirements:
gpm needed if you want to use the mouse at the console
kudzu important for detecting new hardware
syslog important for syslog services
netfs needed only if there are NFS shares that should be mounted at boot time
network important for starting network interfaces (e.g. eth0, eth1, bonding,…)
random used for the system entropy pool
atd needed if the at(1) service is used instead of cron
apmd Advanced Power Management (APM) daemon is used for laptops and some desktops
isdn needed if ISDN is being used
iptables needed if Netfilter (iptables) Firewall is being used
ip6tables needed if ip6tables Firewall is being used
pcmcia not needed on servers - needed for laptops
irqbalance important for distributing interrupts across all CPUs
sendmail needed if Sendmail is used - Procmail should be used which is more secure
autofs needed if automounter is used - production applications should not be dependent on automounter
sshd important for logins via SSH
portmap needed if e.g. NFS is being used
nfslock needed if NFS shares are mounted
nfs needed if server runs the NFS server
mdmonitor needed only if software RAID is being used
crond important for running cron jobs
xinetd needed if xinetd services are being used, see /etc/xinetd.d/ for list of services
cups needed if CUPS is used for the printing system
rhnsd needed if server should connect to RHN to check for software updates etc.
sysstat needed to reset system statistics logs
audit needed only if Linux Audit Subsystem (LAuS) should run for collecting system call audit records
psacct needed only if kernel process accounting information is needed
smartd important for monitoring disk problems if hard disks support SMART technology
netdump important if kernel oops data and memory dumps should be sent to a Netdump server for server crashes

Please note that the start/stop scripts of all runlevel services can be found in the /etc/init.d directory. For example, if a user doesn’t know what the atd service does, then he/she can go to /etc/init.d and open the file atd. And in the script look for lines that start programs. In the atd script the “daemon /usr/sbin/atd” line starts the binary atd. Now having the name of the program that is started by this service, a user can check the online pages of atd by running man atd. This will help a user to find out more about a system service.

If a user wants to disable a service (such as the runlevel service nfs) on a permanent basis then he/she can run following command:
chkconfig nfs off

If a user wants to disable the runlevel service nfs immediately then he/she can run following command:
/etc/init.d/nfs stop

Closing Network Ports and Disabling Xinetd Services
The xinetd daemon is a replacement for inetd, the internet services daemon. It monitors the ports for all network services configured in /etc/xinetd.d, and starts the services in response to incoming connections.

If a user want to check if xinetd is enabled and running, then he/she can execute following command:
# chkconfig –list xinetd
xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
# /etc/init.d/xinetd status
xinetd (pid 2619) is running…
#

If xinetd is active, it is important to check which Unix services are active and controlled by xinetd. A command is provided below that shows all the services configured in /etc/xinetd.d and wheter xinetd monitors the ports for these services:
# chkconfig –list | awk ‘/xinetd based services/,/”"/’
xinetd based services:
krb5-telnet: off
rsync: off
eklogin: off
gssftp: off
klogin: off
chargen-udp: off
kshell: off
auth: on
chargen: off
daytime-udp: off
daytime: off
echo-udp: off
echo: off
services: off
time: off
time-udp: off
cups-lpd: off
#

If a user wants to get a list of only active services for which xinetd monitors the ports, then he/she should run following command:
# chkconfig –list | awk ‘/xinetd based services/,/”"/’ | grep -v off
xinetd based services:
auth: on
#
This shows that the telnet-server RPM is not installed on the system. If the Telnet Server package telnet-server would be installed, it would show up on the list whether it’s active or not.

If a user wants to disable a service such as telnet and also wants to view how the telnet service entries are being update then a user can run following command
# chkconfig –list telnet
telnet on
# cat /etc/xinetd.d/telnet | grep disable
disable = no
# chkconfig telnet off
# chkconfig –list telnet
telnet off
# cat /etc/xinetd.d/telnet | grep disable
disable = yes
#

Please note that for the telnet service it would be better to remove the package from the system since SSH should be used instead:
# rpm -e telnet-server

It is important to investigate all active xinetd services and to disable them if they are not needed.

Here is an example how to find out what a service does. This example is based on the assumption that a user doesn’t know what the auth service does?. This can be done by running following command:
# grep ” server” /etc/xinetd.d/auth
server = /usr/sbin/in.authd
server_args = -t60 –xerror –os -E
# man in.auth
No manual entry for in.auth
# rpm -qf /usr/sbin/in.authd
authd-1.4.1-1.rhel3
# rpm -qi authd-1.4.1-1.rhel3 | awk ‘/Description/,/”"/’
Description :
authd is a small and fast RFC 1413 ident protocol daemon
with both xinetd server and interactive modes that
supports IPv6 and IPv4 as well as the more popular features
of pidentd.
# rpm -ql authd-1.4.1-1.rhel3
/etc/ident.key
/etc/xinetd.d/auth
/usr/sbin/in.authd
/usr/share/doc/authd-1.4.1
/usr/share/doc/authd-1.4.1/COPYING
/usr/share/doc/authd-1.4.1/README.html
/usr/share/doc/authd-1.4.1/rfc1413.txt
/usr/share/locale/ja/LC_MESSAGES/authd.mo
#
This example shows what can be done if there exists no online manuals for the binary in.authd that is started by xinetd. The steps above should be helpful for finding out more about services.

The auth service (aka IDENT, see RFC 1413) allows remote daemons to query information about users establishing TCP connections on the local server. In a trusted environment it helps a server to identify who is trying to use it. For example, it can provide vital information for troubleshooting and who has done what. IDENT requests are needed by some applications like IRC. A user should note that IDENT can be a security risk.

If a user wants to disable the auth service, then he/she should run the following command:
# chkconfig auth off

The xinetd daemon is quite flexible and has many features. Here are just a few functionalities of Xinetd:
- Acces control for TCP, UDP, and RPC services
- Acess limitations based on time
- Provides mechanisms to prevent DoS attacks

If a user has read this article then he/she would have learnt about physical Security, verifying security action items, retiring linux servers with sensitive data, backups, removing unnecessary software packages, patching linux systems and closing network ports and disabling runlevel system services and Xinetd services.

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.