This document is based on K12LTSP for Schools, and was prepared by JITM under the auspices of the “Computing for the Masses” project mentioned below.

A historical document can be found here:: Enabling Mass Computing http://myseeds.home.comcast.net/projects/Terminal_computing.htm

Contents

  1. What is K12LTSP?
  2. Why LTSP?
  3. Where we can get K12LTSP?
  4. How to setup K12LTSP?
  5. Maintaining K12LTSP.
  6. Upgrading K12LTSP.

 

 

What is K12LTSP?

K12LTSP is a modification to the standard Fedora Core Linux distribution with the Linux Terminal Server Project (LTSP) packages integrated into it. It's easy to install and configure and is distributed under the GNU General Public License. That means it's free and it's based on Open Source software. K12LTSP is an off-shoot of the Linux in School Project.

Linux Terminal Server Project (LTSP) is an add-on package for Linux that allows many people to simultaneously use the same computer. Applications run on the server with a terminal known as a thin client handling input and output. These thin clients are also known as X Terminals. Generally, they are low-powered, lack a hard disk and are quieter than desktop computers.

This technology is becoming popular in schools as it allows pupils access to computers without purchasing expensive desktop machines.

Why LTSP?

 

The following points give substantial reasons for K12LTSP.

  • Open source, no licensing worries
  • Supporting low-maintenance
  • Centralized management!!
  • Seamless network file share structure!!!
  • Reliable, stable
  • Inexpensive (free actually)
  • Fast! Terminals run at the speed of the server
  • Remote administration capabilities
  • Relatively secure
  • Possible to run legacy & Windows® apps

Where we can get K12LTSP

 

K12LTSP is based on RedHat Fedora Linux and the LTSP terminal server packages. It's easy to install and configure. It's distributed under the GNU General Public License. That means it's free and it's based on Open Source software. It can be downloaded directly from http://www.k12ltsp.org. You can also purchase with mere 15 US dolor. 

How to setup K12LTSP

 

To setup K12LTSP for five thin clients and a sever the requirements are.

1. A server with following configuration

  • Pentium IV 2.4 Ghz
  • 1 GB RAM
  • 40 GB  HDD
  • 2 Ethernet 100 NICs
  • CD ROM / floppy
  • Modem.

2. Five thin clients.

·         PI/486. 133 Mhz

·         16 Mb RAM

·         Ethernet 100 Mbps with Etherboot Boot ROM

3. Eight port switch.

4. UTP Cat 5 Cables.

5. UPS for the Server.

6. Internet connection.

 

Installing K12LTSP on the Server.

 

K12LTSP Version 4.4.1 comes with 5 CDs.

  1. Boot form the 1st CD. The Fedora installer program will start and automatically detect all the hardware connected to the machine. The first few steps are quite obvious as they will ask for keyboard, mouse, language of installation etc. The major step is selecting the installation type.
  • LTSP - Creates a terminal server for thin-client workstations. Server defaults to an IP gateway/firewall when 2 ethernet cards are present.
  • Workstation - Installs all the workstation applications and a stand-alone, workstation version of Red Hat 8.
  • Server - Installs common server applications and skips the graphical goodies. Use this option for file, print and web servers. Note that you will only have a command line interface with the server option.
  • Custom - This option lets you pick and choose. You can mix and match applications. Don't use this option if you're a newbie.  ;-)  

    For our LTSP install select "LTSP."
  1. Disk Partitioning:-
    The installer can create partitions automatically. But they do not give the required flexibility of later customizations. Therefore it is recommended to create the following partitions.

Mount point             Size

·         /                         1,024 Mb

·         /usr                   10,000 Mb

·         /var                     4,000 Mb

·         /opt                     4,000 Mb

·         /tmp                    1,024 Mb

·         <swap>               2,048 Mb

·         /home               the rest of the space.

  1. Ntwork configuration.

    eth0     is the interface on the thin-client side of your LTSP server. You will connect this network card to your terminal hub. The 192.168.0.x address is designated as a "private" IP address for internal networks. IP traffic from you clients are routed to the Internet and the rest of your network through eth1.

    Note that the server has the last available address in this range, 192.168.0.254. The first client will be assigned an IP # of 192.168.0.253.

    You won't have to enter hostname info or any of the information in the lower half of the window. These settings will come from eth1.

    The default for eth1 is "Configure using DHCP." If you are using custom settings then you'll need to click on the "eth1" tab and configure the card.

    If you're only using one Ethernet card then go ahead and enter the information in the bottom part of this form

    Remember that all of this information can be edited later with the standard Red Hat network configuration tools.

  2. Security Configuration
    The default security configuration for Fedora Core protects your system without restricting any of the functions of a desktop or laptop computer. If you are installing a web server or mail server, you may need to alter these settings so others can access the system. Just click next to proceed to the next step.

For the rest of the installation Fedora Installation Guide can be referred.

5. After the installation is over configure the modem using Internet Configuration Wizard. Fill in appropriate parameters to setup the ISP dial up account.

 

 

 

 

 

 

 

 

 

Thin Client Setup

            The thin client  must have NIC’s with either PXE boot ROM or Etherboot boot ROM. Connect all the thin clients to the switch. The eth0 interface of Server must be connected to the switch. The above diagram illustrates the setup.

 

Server Package Configuration:

Your new K12LTSP server has packages from the Linux Terminal Server Project (www. ltsp.org ) and packages from the Fedora Core 4 Linux distribution. That means that in addition to using it as a terminal server you can run hundreds of packages for Red Hat and Fedora Linux.

We'll provide pointers to configuring some of these other packages but this page will focus on configuring the LTSP packages that are required for booting diskless workstations. See Fedora documentation for other packages.

Understanding the diskless boot process:  (More detailed description from www.ltsp.org docs... )

There are several ways diskless workstations can connect to your server. You can have bootp enabled boot roms on your ethernet card, boot rom code that loads from a floppy or you can use the PXE boot protocol from a PXE enabled motherboard or floppy. In all of these the process is the same:

  1. The client boots and requests an IP number from the server.
  2. The server looks first in the /etc/dhcpd.conf file to see if there is a static address that matches the mac address of the client. If there is no match then an IP number is issued from within the ip range specified in the dhcpd.conf file. Note that the dynamic range starts at 192.168.0.100. This means that numbers under 100 are good choices for other servers, printers and workstations with static addresses.

shared-network WORKSTATIONS {
  subnet 192.168.0.0 netmask 255.255.255.0 {
     range dynamic-bootp 192.168.0.100 192.168.0.253;
     use-host-decl-names       on;
     option log-servers        192.168.0.254;

     # trick from Peter Rundle <[email protected]>
     if substring (option vendor-class-identifier, 0, 9) = "PXEClient"
     {
        filename      "/lts/pxe/pxelinux.bin";
          # NOTE: kernels are specified in /tftpboot/lts/pxe/pxelinux.cfg/
     }
     else
     {
        filename    "/lts/vmlinuz-2.4.9-ltsp";
     }
  }
}
  1.  
  2. The first step in trouble shooting is to make sure your client is getting an IP number. You can watch this process by tailing the messages file on the server while the client boots: tail -f /var/log/messages

    Once the client has an ip number it will then continue booting and ask for its operating system from the server. There are two protocols for doing this, bootp and PXE. The dhcpd.conf file is configured to answer both kinds of requests.
  3. The server gives out boot kernels through a program called tftpboot. All kernels are in the tftpboot dir. PXE booting is configured in a file called /tftpboot/lts/pxe/pxelinux.cfg/default . The actual PXE kernels are in /tftpboot/lts/pxe/
    /tftpboot/lts/pxe/vmlinuz-2.4.9-13-k12ltsp  << Default kernel...
    /tftpboot/lts/pxe/vmlinuz-2.4.9-1-kitchen-sink       << kernel with many options compiled in... Use this one if you're having trouble with the default kernel.

    We'll cover how to make boot floppies again when we discuss configuring clients. We do supply many floppy boot images in /tftpboot/lts/boot/bootroms. These boot images are handy for testing. Just put a formatted floppy disk in your computer and type cat /tftpboot/lts/boot/bootroms/eepro100.lzdsk > /dev/fd0 to create a boot floppy for any of the cards listed. We used the Intel eepro100 card in the example above.
  4. You can list specific clients in the dhcpd.conf file. This helps when some need a special kernel or workstation specific settings are required for different video drivers, mice or sound settings. Clients not specifically listed in dhcpd.conf will boot with default settings as supplied in the lts.conf . Examples are included in the default dhpcd.conf file. Note that the IP numbers here are below 192.168.0.100.
host ws002 {

        hardware ethernet     00:D0:09:30:6A:1C;

        fixed-address         192.168.0.2;

        filename              "/lts/vmlinuz-2.4.9-ltsp";

       }

  1. After adding an entry for the workstation in  dhpcd.conf you can add options in the     lts.conf file found in /opt/ltsp/i386/etc/. This is an important file as it also contains the default settings for all your workstations. We've included a sample in the box below. 

#
# Config file for the Linux Terminal Server Project (www.ltsp.org)
#

[Default]
        SERVER             = 192.168.0.254
        XSERVER            = auto
        X_MOUSE_PROTOCOL   = "PS/2"
#        X_MOUSE_PROTOCOL   = "IMPS/2"  << for wheel mice
        X_MOUSE_DEVICE     = "/dev/psaux"
        X_MOUSE_RESOLUTION = 400
        X_MOUSE_BUTTONS    = 3
        X_USBMOUSE_PROTOCOL= "PS/2"
        X_USBMOUSE_DEVICE  = "/dev/input/mice"
        X_USBMOUSE_RESOLUTION = 400
        X_USBMOUSE_BUTTONS = 3
        USE_XFS            = N
        LOCAL_APPS         = N
        RUNLEVEL           = 5

 

        # enable sound by default, set the default volume to 75

        SOUND              = Y

        VOLUME             = 75

  

        # ISA sound cards require you to manually load the proper module:

        # for example:

        #SMODULE_01       = sb io=0x220 irq=5 dma=1


#------------------------------------------------------------------------------
#
# Example of specifying X settings for a workstation

#[ws001]
#        XSERVER            = auto
#        LOCAL_APPS         = N
#        USE_NFS_SWAP       = Y
#        SWAPFILE_SIZE      = 48m
#        RUNLEVEL           = 5
  1.  
  2. If you're having trouble at this point a good resource is the LTSP documentation. They have a step by step description of the boot process and troubleshooting tips that are much more detailed than what we've provided here. If your client is getting its IP number and kernel image you should be up and running. 


NFS Mount for /home:  (more NFS info from the Red Hat Customization Guide )
We have several LTSP servers in one building. All of them share the same /home directory via NFS. We have one server that acts as the home folder file server for the school. We sync the passwd, group and shadow files to each LTSP server from this server. This means that any user can sit down at any terminal regardless of the host LTSP server and still have access to his/her settings and files. Setting up NFS is very easy to do.

  1. Configure the /home folder server by adding a line to /etc/exports:
    /home   192.168.0.0/255.255.255.0 (rw)
  2. Make sure that /home is an empty directory on the LTSP server. We'll use it as the mount point for the NFS mount by adding one line to /etc/fstab:
    server:/home/     /home     nfs     defaults,rsize=8192,wsize=8192     0 0
    In this example we are mounting from a computer called "server." Make sure the NFS host and IP number are listed in your /etc/hosts file and adjust as needed for your network.
  3. We don't add users often so simply copying passwd, group and shadow files from the home server to /etc on the LTSP servers works well for us to keep user logins synched.  I'm sure there are better ways of doing it. Share yours with me and we'll put your howto's on this page!  ;-)

Printing:
There are two ways to add printers. Adding printers to the LTSP server makes them available to all the clients as well. This is the easiest way to do it. Just run the printtool utility and add printers as you would for any other Linux box. You will need to run the spadmin utility as root to configure printers for OpenOfice. This utility is copied to /root/OpenOffice when root runs OpenOffice for the first time. See the Red Hat Customization Guide for more printtool info.

 

Note: For our good every thing comes preconfigured after installation.

 

 

Maintaining K12LTSP

 

We've tried to select the most important and most useful tasks with a goal of learning basic unix skills in context. As you move from task to task your unix skills will grow and you will learn more about the Linux operating system.

Task List:

1.      Network Configuration

2.      RPM Package Manager, Webserver/Proxy Configuration

3.      Backup

4.      Firewalls & Security

5.      User Management

6.      Updates

7.      Online Q&A

Network Configuration

Prerequisites:
You must have a working installation of Linux.  You don't have to know Unix to take this course. You do have to know some computer basics like what a directory is and a little bit about TCP/IP. All the Unix commands you need to know for this lesson are listed on the right side of this page. If you get lost, head for the Q&A section. The best thing about Linux is the support from other users. If asking for help is the first thing you learn, you're off to a good start.

Is the network up?

Login as root. You will need to be root to perform system management tasks. You should not usually login as root unless you are going to perform administration tasks. But, hey, that's what this course is all about right? ;-) The reason you don't want to form a habit of logging in as root is that with just a few keystrokes you can do terrible things to your server. It's a better practice to login as yourself and "su -" to root only when you need to.

Use the ifconfig command to see the networking configuration. If you're logged in as root you can just type ifocnfig. If you su'd to root you'll need to type the whole path /sbin/ifconfig . [Tip: use "su -" and you won't have to type the /sbin...]

Here's what my ifconfig looked like. Let's take a look and see what this shows us. There are three network interfaces listed; eth0 [ethernet card #1], lo [loopback device], and ppp0 [my active ppp conection via my modem to my isp.].


Just because you can see the network devices does not mean you are on-line though. Try a ping to see if you're live. [Did you remember to plug in your ethernet cable? ;-) ]

Ping www.k12linux.org if you get a ping back then you're live.

How can I turn networking off and on? How do I change network settings?

There are three ways to do this.

Fom the command line: ifdown eth0 This takes down interface 0. (Remember in Unix we start counting from 0.) ifup eth0 Will bring it back up again.

You can also use two GUI programs to do the same thing. It's not unusual in Unix to end up with several ways of doing things. This should serve as a good introduction to two handy utilities though, control panel and Linuxconf. Linuxconf is a great, do almost everything control interface to many features of your Linux box. The older network control panel is a simpler interface that works just as well. You can also edit a few text files and accomplish the same thing. No matter how slick the interface is, it is still just editing the text based configuration files. You don't need an interface to do that. Here's a list of the network files that control your Linux box:

/etc/hosts - a mini list of known hosts
/etc/resolv.conf - a list of your name servers
/etc/lmhosts - a list of smb servers for netbios identification
/etc/sysconfig/network-scripts/ifcfg-eth0 - information for your first ethernet card
/etc/sysconfig/network - info on your network configuration and hostname

Let's take a look at each one:

/etc/hosts
10.0.0.1      homepc.riverdale.k12.or.us     homepc
127.0.0.1      homepc localhost.localdomain      localhost

/etc/hosts: This is where you can create a lists of known hosts. Your Linux box will use the IP# listed here instead of doing a DNS (domain name service) lookup. This can be handy if you want to list the names of your computers on a private network that don't have DNS entries. There are <tabs> in between each field.

/etc/resolv.conf 
search riverdale.k12.or.us
nameserver 192.108.254.11
nameserver 192.108.254.26

/etc/resolv.conf: The first line is the search domain. This tells your Linux box to search in this domain if no other domain information is supplied. This let's you connect to boxes in your own domain by simply typing their short names. i.e. falcon vs. falcon.riverdale.k12.or.us

/etc/lmhosts
198.236.126.16 server
198.236.126.11 falcon
198.236.126.5 cdtower

/etc/lmhosts: This is an import file if you are running SAMBA, the Windows file server package. This file lists the smb names of file servers on your network.

/etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=static
ONBOOT=no
BROADCAST=10.127.255.255
IPADDR=10.127.90.10
NETMASK=255.255.0.0
NETWORK=10.127.0.0
ONBOOT=yes
USERCTL=no
GATEWAY=10.127.1.1
GATEWAYDEV=eth0

/etc/sysconfig/network-scripts/ifcfg-eth0:This is the actual configuration for ethernet card #0. Notice that it has a static ip address. Compare it with the configuration for my second card (eth1). To change from a dhcp address to a static address, you really only have to change one line. [  BOOTPROTO=dhcp ]
In the example below the listed ip address of 10.0.0.100 (and other listed ip information) will be ignored and the card will query the network and get its IP number and information via dhcp.  (DHCP=Dynamic Host Configuration
Protocol)

/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
ONBOOT=no
BOOTPROTO=dhcp
BROADCAST=10.0.255.255
NETWORK=10.0.0.0
NETMASK=255.255.0.0
IPADDR=10.0.0.100
USERCTL=no

 

/etc/sysconfig/network
NETWORKING=yes
HOSTNAME=server
GATEWAY=198.236.126.1
GATEWAYDEV=eth0

/etc/sysconfig/network: Here we see importing settings like HOSTNAME (the name of your computer) and gateway device settings.

These text files control your network settings. Now we'll take a look at a graphical tool that will help you make changes but remember, you are really only editing these text files.

Control Panel:
This is the network configuration utility called from /usr/bin/neat
It gives you point and click control over your network settings. You'll find this utility in the Red Hat >>> System Tools menu linked as "Network Device Control."

 

You should explore the sites in the Links section and then test your knowledge of Linux networking!

Use it or lose it:

1.      Take your Linux box offline using ifdown.

2.      Check the networking status with ifconfig

3.      Change your ip address and then bring your Linux box back on-line with ifup.

4.      Change your netmask settings from 255.255.255.0 to 255.255.0.0. Remember to take your network card off-line before making these changes.

5.      Use Ping to see if you can reach the box next to yours. Change your ip range and netmask and try again. i.e. machine #1 10.0.0.20 w/netmask 255.255.255.0, can you see machine #2 10.0.10.20 w/netmask 255.255.0.0 ?

6.      Try to make at least some of the changes above using a text editor like pico.

7.       

8.       

RPM Package Manager, Webserver/Proxy Configuration

What is an RPM file and where are they found?

RPM stands for RedHat Package Manager. The RedHat package manager is a tool that makes it easy to install, update and remove programs from your Linux box. Before RPM came along, Linux users had to compile programs on their machines before they would run. Packaged binaries are ready to install and run on your machine. The package manager copies the necessary files to the correct locations and installs default configuration files and documentation. You can still compile your own binaries but using RPM's will save you time and is often a more reliable way to install programs. Another plus with RPM's is that you will find software repositories full of rpm versions of the most popular packages. Good examples are www.gnome.org , www.helixcode.com , www.rpmfind.net , rpm.pbone.net , rpmfind.net .

There is of course more than one way to use RPM. There is a simple, command line mode and a GUI interface. We'll learn how to use RPM from the command line first.

Run man rpm for a complete list of rpm tags and documentation. "man" will display the man(ual) page for most unix commands and utilities.

We will learn to use 5 of the most commonly used tags.

rpm -i INSTALL a package
rpm -e UNINSTALL a package
rpm -q QUERY a package to see if it is installed and display the version.
rpm -U UPDATE a package, also installs the package if not already installed
rpm -F FRESHEN updates a package only if already installed

Two more handy tags are the "v" for verbose and "h" for hash marks to show progress.

First let's see if Apache is already installed on your Linux box:

[root@homepc /root]# rpm -q httpd
httpd-2.0.40-21.3

Here we use the "q" tag and see that Apache version 1.3.22-2 is currently installed. (You may have a different version. Let's use ncftp to go to the Riverdale ftp site and see if there is a newer version. (We may not have the newest version. The goal here is to learn to use ncftp and rpm. Check the www.rpmfind.net site for most current rpms.)

ncftp k12linux.mesd.k12.or.us

cd pub/K12LTSP/3.1.1/i386/RedHat/RPMS

Do an " ls" to see a list of what we have in the unix_files directory. If you want to see only the httpd files use "ls httpd*" Is there a one newer web server? Probably not. Let's grab it anyway. 

 " get httpd-2.0.40-21.3.i386.rpm " will download the rpm to your current directory. Forget where you are? Try " lpwd". You've seen pwd before but in ncftp the "l " means to give you the local machine information. You can also lcd and lls. The ncftp program lets you manage and naivgate local directories when the " l" is prefixed to commands. Normal commands like ls, cd .. and pwd all work for  the directories on the remote ftp site.

Once you have the file just type "exit". You don't need to save a bookmark.

Let's practice with rpm by removing the current install of Apache(httpd).

rpm -e httpd

You should see hash marks and it should tell you what it's doing. Now let's install a fresh version using the copy we just downloaded. Be sure you're in the directory where you saved your httpd rpm. The "v" option stands for verbose. The "h" option stands for hash marks.

rpm -ivh httpd-2.0.40-21.3.i386.rpm

This should install a nice fresh copy of Apache(Httpd) on your machine. Sometimes after I've messed things up a bit, I find it's good to start all over again. RPM makes this pretty easy. rpm -e removes all the files installed with an rpm package including configuration files. rpm -ivh reinstalls the package with all the default settings.

Backup

 

One of the most important things you need to do is make backups of important files on your server. You'll need to consider two kinds of backup scenarios: 
1. Backing up files locally for easy retrieval and fast restoration. 
2. Remote backups for restoration in case of total system failure.

Consider the fact that you are experimenting with configuration files on your test server as you learn how to use your Linux box. You should always make a backup copy of a file before you start editing it.

cp is the basic unix command to copy files.

cp /etc/smb.conf /etc/smb.bak would make a backup copy of your SAMBA file. If you really get lost and need to start over again, it's always there waiting.

If you look at the man page for cp, you'll see that it has lots of options. Several make it a great tool for making backups of whole directories on your server.

cp -R /etc/ /root/safe/etc would recursively copy the whole directory /etc and all the directories under it. To be sure you keep all the attributes the same, consider using the -a option which includes -R as well as -dpR (preserves links, attributes and recursive). 

A good example of using cp -a to perform backups would be backing up /home to a second hard drive. You could create a cron script to backup /home every night.

cp -a /home /mnt/backup_drive/ would place a copy of your /home directory on a second drive mounted on /mnt/backup_drive. This might take a long time so if your doing it by hand you should learn how to run jobs in the background. The same command above with a & after it forces the job to run in the background. You can use the ps command to see the pid of your job. You can also see it if you run top. You'll get a notification when the job is done.

To have a backup run automatically you should include it in a cron job. To do this you'll have to edit your crontab entry using "vi". vi is the most common editor found in basically all Unix  operating systems. We've used "pico" for most editing tasks in this course as it is much easier to learn. You should be familar with "vi" though.

Let's dig right in and use "vi" to create a crontab entry. Open this webpage and use it as a reference for using "vi": http://www.mcsr.olemiss.edu/unixhelp/vi/index.html We'll us it to have the backup command run every Friday night.

First let's take a look at your current crontab list:

crontab -l The "-l" option simply lists your current crontab. If you're working with a new RedHat install you may not have an entry.

[root@homepc /root]# crontab -l
no crontab for root

We need this command to run every Friday night at 10:00

cp -a /home /mnt/backup_drive/

The command part is easy. We'll have to understand how cron scripts use dates to get the timing right. The crontab file uses 5 fields repsenting minutes, hours, day of month, month and day of week to run jobs at the right time. 

          minute (0-59),
          hour (0-23),
          day of the month (1-31),
          month of the year (1-12),
          day of the week (0-6 with 0=Sunday)

Friday night at 10:00 would be:
0 22 * * 5
Note: minute = 0, hour = 22, day = * (which means all legal values or any day of the month), month = *, day of week = 5

Now we'll use "vi" to add a crontab entry that looks like this:
0 22 * * 5 cp -a /home /mnt/backup_drive/

crontab -e edits the crontab file. You will automatically open the file with vi. vi has a viewing and saving mode and an editing mode. You will start in the viewing mode. To enter text you'll have to type a letter to enter an editing mode:

Insert text after the cursor                   a
Insert text before the cursor                  i
Append text at the end of the current line     A
Insert text at the start of the current line   I
Open a new line below the current line         o
Open a new line above the current line         O

Note that it makes a big difference where your curser is when you enter the editing mode. To get  back to the viewing mode just hit the <esc> key. When in this mode you'll need to know at least two commands. <:Q> quit, and <:W> save. Once you've saved your file, this script will run. That's all there is to it. Now, "vi" wasn't so hard was it?  ;-)

With enough hard drive space, the cp command might be all you need to know but we all know how easy it is to fill those big drives. The next tool we'll use is TAR (tape archive utilitly). tar lets us create archive files that can be compressed. There are many options when using tar so we'll just cover a few here. Browse the tar man page for more info.

To create a tar file of my whole /etc directory:

cd /
tar -cvf etc.tar etc

The -cvf options are: c = create, v = verbose - shows us what's happening, f - creates a file.

You may now safely store the etc.tar file on another server, floppy or tape for safe keeping. The advantage of tar files is that they can be compressed. Here's how the file sizes compare for /etc tarred on my home pc:

[root@homepc /root]# ls -l
total 3684
drwxr-xr-x   46 root     root         4096 Jul 28 21:11 etc
-rw-rw-r--    1 root     root      3758080 Jul 29 05:44 etc.tar
[root@homepc /root]# compress etc.tar
[root@homepc /root]# ls -l
total 1244
drwxr-xr-x   46 root     root         4096 Jul 28 21:11 etc
-rw-rw-r--    1 root     root      1257623 Jul 29 05:44 etc.tar.Z

Note that I used the "-l" option to "ls" to get the file size. Compress reduced the size of etc.tar by more than 1/2. You can add the "Z" option to the tar to compress the file all with one command. tar cvfZ etc.tar.Z etc Note that the capital Z is used. A lower case "z" tells tar to use the gzip compression which makes the file even smaller.

Tar is a nice backup utility because it keeps the attributes and path information for files and directories intact. You can adjust all of this though with tar's many command line options.

Tar Tricks: tar cvf - * | ( cd dest_dir ; tar xvf - )
This will copy the contents of your current directory to an destination directory, recursively, keeping all attributes and links. Note the use of the pipe to in essence, tar in and then tar out.

Another really cool backup tool: scp - secure copy This nifty tool lets you copy files from remote servers using an encrypted, (secure) connection. You should use this method to copy files from other servers instead of the older, non-secure rcp (remote copy).

scp [email protected]:/etc/passwd /tmp/passwd 

 

Questions on rsync...
Note in the example that we supply a user@server and then : /file name. Before you start using this to make regular backups of your /home directories, we should learn about rsync. When we make backups we don't need to copy files that have not changed, only the newer ones. rsync lets us do just that.

Here is an example of the rsync command we use at RHS to backup our home folders:
rsync -azv --delete -e ssh /home root@veronica:/backup/home

Note that this synchs the home directory TO the backup server. For practice sessions I'd suggest using rsync to sync to a different directory on the same server.

 

 

 

 

 

Secutiry

 

What is security?

Security is minimizing the risk of damage, theft of resources, and fraudulent activities.

Security is not a solution; it is a way of life.


What is required to make a computer "perfectly secure"?

Grind your computers into a fine dust, spread the dust into the wind, and hope that entropy does its thing.

Rule #1: your systems will never be perfectly secure. Never.


Why should you care about security?

$$$$$

It can take many hours to clean up a damaged system. Valuable data can be lost. Valuable data can be altered. Your network/computers can be made inaccessible


Who do you need to protect your systems from?

  1. the administrator!
  2. insiders (adventurous/malicious students, disgruntled teachers)
  3. external tampering (viruses, crackers, denial of service)
  4. physical failures, natural disasters


Fundamental concepts

  • Backups
  • Defense in depth
  • Least privilege
  • Segregation
  • Encryption
  • Updates
  • Keep users off the servers
  • Vigilance
  • Ignorance is the enemy

 

Types of Abuses

Physical access attacks

Console access:

    • type linux single at the LILO prompt
    • Control-Alt-Delete
    • Pull the power plug


Theft:

    • If you don't have it, you can't use it


Vandalism:

    • If it's broke, you can't use it

 


Protocol layer attacks

Denial of service:

    • Causing your server or application to crash, using up all of your bandwidth, or any other activity that makes your system slow or inaccessible


Sniffing:

    • Many applications, such as telnet and ftp, are clear-text protocols. A sniffer is a utility that can passively read clear-text network traffic -> including your username/password when you log in!


Spoofing:

    • Someone pretends to be someone else. Used to exploit trust. For example, if your firewall blindly permits all traffic from the host www.open.k12.or.us, an attacker can manipulate their network traffic to make it look like it came from www.open.k12.or.us


Session hijacking:

    • A very sophisticated attack where someone literally hijacks your connection after you have logged in.

Application layer attacks

Buffer overflows:

    • Input into a program that is too long for the space allocated for it. In specific circumstances, if the too-long input is carefully crafted, the attacker can get the computer to execute arbitrary commands on your computer

Viruses:

    • Microsoft macro viruses. Do I need to say any more?

Misconfigurations:

    • Securely designed programs can be configured to be insecure.


Inadequate user-input validation:

    • A common problem with web-based and database applications.

 


Resource theft

Open mail relays:

    • Spammers can "bounce" mail off your mail server, making it look the junk mail came from you.


Open proxies:

    • Crackers can attack another system, the attacked system will see that the attack came from you. Also used for fraud


Unauthorized bandwidth usage:

    • If you have a publicly writable FTP folder or file share, you may unwittingly find yourself hosting a warez/porn distribution site.


Spam:

    • Many consider unsolicited bulk email to be theft of resources, since it takes up bandwidth, diskspace, and time

 

 

Prevention

Restrict physical access

Step #1 is to restrict physical access. If someone has physical access to your system, they can compromise it


Firewalls

Firewalls are gatekeepers. They control who can enter and exit. They do not control one's actions after they are permitted to enter! The very name firewall indicates that they are designed to slow attackers down, not to stop them completely.


Ingress/egress filtering

Prevents IP spoofing.

Ingress: IP traffic with your internal IP range should not be permitted to enter your network from an external source. This is not possible, it is not to be permitted: it is most likely an attempt to betray trust within your network

Egress: prevents someone from within your network from sending out IP traffic with an origination address that is outside your IP range. This is not possible, it is not to be permitted: it is most likely an attempt by someone within your network to betray the trust of a computer on another network


Prevent direct access

  • Proxies: MESD forces all in-bound web traffic through an array of proxies. Outside users cannot directly attack web servers, they must compromise a system within the network before they can directly attack a web server
  • Relays: MESD forces all in-bound email through a central gateway. Outside users cannot directly attack mail servers, they must compromise a system within the network before they can directly attack a mail server. Mail relay also filters all mail for obvious Spam and known email-bourne attacks
  • DMZ's: MESD proxies and relays are in a de-militarized zone, meaning that they are segregated from the rest of the network and are explicitly not trusted. If one of these systems is compromised, the damage is contained as much as possible.


Use well designed and tested applications

  • Don't use applications with weak virus resistance. This includes everything made by Microsoft
  • Don't use applications which make dumb assumptions. The old unix "r" utilities, such as rsh and rlogin, grant access according by hostname. As noted earlier, it is trivial to spoof a hostname/IP address in order to exploit this trust between two systems
  • Do use applications which have been thoroughly audited under peer-review. OpenBSD is a shining example
  • Do use software that is uses secure settings by default and is difficult to misconfigure in an insecure way.


Use encryption!

Encrypted protocols prevent sniffing, spoofing, and session hijacking

Use SSH in place of telnet and ftp

Use SSL for everything else


Backups, backups, backups

Always have backups!


Training for administrators

Administrators have destroyed more systems than all other factors combined. Training can help prevent costly mistakes


Keep up to date on all vendor patches

More than 90% of all compromises exploit weakness for which the vendor has published a patch. Simply keeping up with the vendor patches, in a timely manner, will greatly increase the security of your systems

When choosing a vendor, be sure to account for how quickly they patch known-exploits against their products, how well they notify the public that the patch is available, and how easy they make it to find and apply the patch


Read the documentation

Read The Fine Manual: at least glance through the documentation when installing a new application. Often you will find a list of things it tells you not to do and known issues


Have a decent password policy

Note: the "perfect" password won't help you if someone can simply sniff it from a clear-text protocol. Use encryption

Don't allow absurdly easy passwords that are susceptible to guessing or dictionary attacks. On the other hand, too hard of a password will cause users to write it down which is also a problem.

 

Detecting Compromises

System logs

  • Take a look around /var/log/, there is all sorts of interesting information about the health of your system
  • /var/log/security lists security related information
  • /var/log/messages lists general messages
  • The utility last will show you who logged in and when

Set up a remote logging host, so that logs are more difficult to erase:

  • On the log server, edit /etc/rc.d/init.d/syslog and add -r to the daemon syslogd line. It should look like this: daemon syslogd -r -m 0. Then restart syslog: /etc/rc.d/init.d/syslogd restart
  • On each server, add *.* @123.123.123.123 where 123.123.123.123 is the IP address of your log server. Then restart syslog
  • Now, all log information from your servers will be duplicated on the log server


Note odd behavior

Sometimes odd behavior of your system will tip you off that you have been compromised. Examples include locate causing seg faults, the top command failing to run, and ps suddenly looking different


Tripwire

Tripwire is a file integrity checker. Tripwire will tell you if any of your files have been altered. Tripwire's database is encrypted, to prevent tampering with the integrity checker itself


RPM

RPM can be used to verfiy files in much the same manner as Tripwire. rpm -Va &> /tmp/rpm.log will list all deviations from the RPM database into the file /tmp/rpm.log

Note: the RPM database is not protected, an attacker can alter your RPM database to match the malicious files they have installed


md5sum

While your RPM database may be compromised, you can take a cryptographic checksum of your files and compare them to known good copies. For example, run the command md5sum /bin/login and compare it to the md5sum of /bin/login on a system with the same version of the package.

You can check the package version of a file using rpm as well: rpm -qf /bin/login

Idealistically, you will want to get your known-to-be-good checksums from your install CD, rpm -qp --dump ./packagename.i386.rpm will dump all of information about an uninstalled package - including its original MD5 checksum


Spotting rootkits, traces of buffer overflows

Rootkits are trojaned programs which are intended to hide the cracker's presence on your system. The following files are often trojaned:

    • /bin/login
    • /bin/ps
    • /usr/bin/top
    • /bin/netstat
    • /usr/bin/who
    • /usr/bin/telnet

Rootkits often patch the hole the cracker used to get in!

Rootkits often do not strip, or remove the symbol tables within a compiled program, from the files they install. Almost all vendor supplied software will be stripped. You can check this using the file command and looking for "not stripped": file /bin/* | grep "not stripped"

Buffer overflows will sometimes leave suspicious looking files, such as extremely long filenames in /tmp. These long filenames sometimes cause the locate utility to crash


Post mortem, now what?

If you have been compromised, how do you recover?

  • You have backups, right?
  • Clean reinstall

 

Advanced Topics and Configurations

What services do you have running?

This command will show you all the applications accepting connections, all currently established connections, who is connected, and all of the process IDs:

netstat -a -p


What does each service do?

find a url that explains this?


Restricting access

tcp wrappers control access to applications executed in /etc/inetd.conf or compiled against the libwrapper library

    • /etc/hosts.deny:
      ALL:ALL
    • /etc/hosts.allow:
      sshd, simap, imaps: ALL
      ALL: 198.236.66., .mesd.k12.or.us, 127.0.0.1, localhost


Remote vs local vulnerabilities

  • It's much easier to exploit a system from a local shell than it is to exploit a system using a network attack
  • But, the smallest weakness in the network services can be used to leverage a local weakness
  • Many documented system compromises involved exploiting both network and local vulnerabilities

User Management

 

Users can be added by simple command line tool - useradd.

 

[root@myserver ~]# useradd –c “My Full Name” myuserid

 

Or one can user the Fedora GUI tool ‘Users and Groups’ to create, delete and disable users.

 

User passwords can be managed by command line tool – passwd

 

[root@myserver ~]# passwd username.

 

A user can be deleted by userdel command

 

[root@myserver ~]#userdel username.

 

A user can be locked to login by passwd –l command.

 

[root@myserver ~]#passwd –l username.