'OTY Internal:Linux Installation/23Nov2009'

Archive

Version of 17 Nov 2006

Version of 20 Sept 2007

Version of 09 Jan 2008

Version of 02 Jul 2008

Notes

1. Linux Installation is ALSO described in the Linux_installation_guide in the general access documents.
2. The instructions here are kept for admin access only. Some instructions will slowly move from the general document to this document in order to protect access to our services.
3. The Linux_installation_guide will, eventually, be restructured to provide instructions for the general population.
4. Sections marked in red like this
   Obsolete section
   will be removed from this document on the next version.

A. Linux General Policy and Installation instructions

This document contains guidelines in setting up/configuring and updating of Linux systems. If you need to operate the system differently then a clear argument must be made and the decisions taken documented. In any case an accurate account of what has been done for each server machine or computing lab MUST be made in the respective files in this wiki. Lab and other clients do not need an entry in this folder but it is nice to have a group config file e.g. linux-rackables or a description in the lab documentation.

For Linux:

   * We have standardized on the Fedora distribution of Linux. We are also currently 
     experimenting with CentOS as a primarily server platform. Fedora and CentOS 
     belong to the same family of Linux Distributions. Differences are noted where applicable.
   * Our current release suite is Fedora Core 5, 6, 8 (older machines on 5 new machines on 8) 
     and CentOS 5.1.
   * We operate our own update service for doing updates for Linux on the FTP server (Eris)
   * Each machine installed MUST operate with these parameters and the following 
     guidelines unless it is strictly for evaluation purposes. Deviation for specific reasons 
     should be documented.

B. Installing Linux

During installation follow the guidelines below. Remember these are guidelines NOT RULES. But not following the guidelines means there is some specific reason which should be recorded. You should:

1. Read this document entirely before starting an installation
2. Preferably, based on the information in this document, prepare an installation template before starting the installation. An example template is provided at the end of this install guide.
3. Based on the template you can answer questions and provide input during the actual installation.
4. YOu can save your Template in the Machine's own wiki page. Record in the wiki page of each machine you install the reason and how you have deviated from this document.

B.1 Servers and Clients

In general Linux installs are separated into two categories: servers and clients. This refers to the functionality of the machine not the software you install on it.

Definition.
Servers: machines not usually directly accessible (console)
Clients: machines directly accessible by the user usually running a graphical desktop system

B.2 File Systems

Fedora and CentOS systems are capable of using various file systems for the OS or the data. Our preferred choices are ext3 
and XFS. While XFS provides better performance than ext3 it is not always well supported. 
CentOS does not yet have a complete, out of the box, support for XFS. Both file systems can be expanded at will with lvm 
utilities WITHOUT dismounting the file system. XFS has been tested in various environments with Fedora and seems to 
function well. 

There is one exception: the /boot partition (see below) MUST be on an ext3 system AND OUTSIDE the LVM control ie
on a physical partition by itself.

B.2.1 Filesystem structure

   * Filesystem configuration
     We always use LVM version 2 and up for setting up Fedora file systems
   * Physical partitions and volume groups set up
         o One physical partition for /boot with 100MB (MUST be outside of LVM set up)
         o One physical partition, large enough, to contain the LVM Volume group for
           OS install (usually named VolGroup00).
           Suggested size is 15GB. This gives enough space for installing and 
           expanding later if required.
         o One LVM Volume group (VolGroup01 or DataVG01 etc) for DATA (if required). 
           This is prepared only if a very large volume of data is anticipated or if 
           we determine that a separate volume group is necessary or desirable. 
           Otherwise we can create a file system within the OS volume group (VolGroup00)
           expanding it as necessary. It can also be constrained onto one physical 
           drive if required or expanded to several drives.
         o The rest of the disk space remains unallocated for future expansions.  
   * File Systems created:
         o Within the OS volume group (VolGroup00) we have:
           (root) / 	2048MB (2GB)
           /usr 	4096MB (3GB) for server machines
                       5120MB (5GB) for client machines
                       (can be increased or decreased if requirements demand it)
           /var 	2048MB (2GB)
           /tmp 	1024MB (1GB)
           /usr/local 	512MB
           /opt 	512MB
           /home 	512MB (before mounts)
           swap space 	
             this depends on what the system will be doing. If physical memory is 
             large enough >= 1GB then swap=memory. Swap space can also be moved to different
             volume group/physical partition depending on the requirements of the system
           /sys-data (this is where the data are and is optional, see below)
           
           Remaining of disk space.
           Data file-system (in case VolGroup00 will not be used for data storage).
         o Within the data volume group (VolGroup01), if it exists, create a file system 
           for data and mount it to a suitable directory node (prefer /sys-data). This 
           file system can be any format of ext3, xfs, jfs or reiserfs. XFS provides better 
           performance and has been tested and it works well on Fedora.
      
         o If your installing CentOS 5.X and you need the XFS filesystem then you need to install a special kernel module from the  
           extras repository, after finishing with os installation.  If your going to use XFS filesystem you should also install 
           the XFS programs that go with it. There is an easy way to see what XFS kernel modules are available for your kernel. 
           Make sure the extras repo is turned on in /etc/yum.repos.d/CentOS-Base.repo. Then try the following command to list the 
           XFS packages available for your running kernel:
           yum list available kmod-xfs\*
           Then pick the kernel module based on the kernel your running (uname -a). If your running an smp kernel then you would   choose kmod-xfs-smp.i686 for i686 class processor. For example to install the smp XFS module and the xfs programs try 
           the following:
           yum install kmod-xfs-smp.i686 xfsdump xfsprogs

B.3 Services and Applications

A list of the most important services and applications that the machine is being used for must be maintained. This is quite important for server type machines since they are dedicated to unique functionality. Also any deviation from defaults should be pointed out. More information about services and daemons on Fedora systems can be found here. For examples see kalliopi server or Eris server or Linux Lab.

1. Install shells you plan to use (tcsh, or ksh). Some of these are not installed by default. Check. 
   Our users used to have shells paths of the form /usr/bin/<shell>. Make sure that links exist from 
   /usr/bin to /bin style shells.

B.3.1 Client machines

1. Only the following services must be running: acpid, arptables_jf, auditd, autofs, cpuspeed (notebooks only), 
   crond, cups, cups-config-daemon, gpm, haldaemon, hplip (if support for hp printers is required), iptables, 
   irqbalance (only for multiple/multi-core CPUs), kudzu, lm_sensors, messagebus, netfs, network, portmap, 
   readahead, readahead_early, smartd, sshd, syslog, sysstat, xfs, xinetd, ypbind.
2. Enable printing and setup printers

B.3.2 Server machines

1. Install only services absolutely required for the specific server to function. See the sections that follow what needs to be installed and how to configure.
2. Server machines (web, mail, db etc) preferably install also X-Window system, Gnome desktop and all administration utilities. This helps in managing the system. If it is preferred to disable the X-Window interface on the machine (in order to conserver memory or to make it more difficult to access) then do so in /etc/inittab.
3. On each server machine we create one additional user to be used in case the authorizations system (NIS) becomes inoperative. The user is named xsystem where x is the first letter of the server name. Password follows the pattern at the time of creation and updated accordingly. (Ex. iolaos gets a isystem account). This account should have a home directory of /<name> to allow it to log in even when NFS system mounts are down. DO not use /home/<name> since it conflicts with the autofs procedures. (Note that this account should ONLY be used for troubleshooting purposes. Absolutely no data in this users' home area.
4. On each server machine (this is required only on server machines) install the postfix mail server in send mode only. See the details on how to do this below in C.7.
5. Enable printing and configure at least one general purpose printer convenient to the users ie administrators.

C. Configuration of Linux systems

C.1 Services, Daemons, Applications

1. During installation the default install usually includes many unnecessary options and services. Carefully remove any unneeded options. This is based on the purpose of each machine.
2. Install any shells you plan to use (if not installed). Our users have shells as /usr/bin/tcsh BUT Linux likes /bin/tcsh. Make any necessary links.

C.2 Network

We prefer a DHCP assigned network configuration.

Note: The majority of the Linux clients do not send their hostname to the DHCP server when they obtaining IP address. As a result dynamic DNS updates do not work. This can be resolved by adding the following line in the configuration file of dhclient, usually /etc/dhclient-eth(x).conf. If the file does not exist, i.e FC4, create it.

 send host-name "hostname";

Only enter the hostname and not the FQHN and don't forget the ";".

Also for machines in the in.cs.ucy.ac.cy domain don't forget to add the following line in the file mentioned above. --kekkos 14:46, 24 January 2007 (EET)

 prepend domain-name "cs.ucy.ac.cy ";

Note: Between .cy and the " character there is a space.

C.3 DNS

Client and server configuration (except DHCP clients)

resolv.conf

search cs.ucy.ac.cy in.cs.ucy.ac.cy
nameserver 194.42.16.11
nameserver 194.42.16.20
nameserver 194.42.16.58
options rotate

C.4 NTP

   * the following minimum configuration must be made in /etc/ntp.conf
    keys            /etc/ntp/keys
    server 127.127.1.0
    fudge   127.127.1.0 stratum 10
    server ntp1.cs.ucy.ac.cy 
    restrict ntp1.cs.ucy.ac.cy mask 255.255.255.255 nomodify notrap noquery

NOTE:

1. delete (or comment out) any other server xx.xx.xx.xx lines
2. for every server line you delete or comment out, do the same for the corresponding restrict line nsc 09:54, 7 December 2006 (EET)

C.5 User Authentication

Currently (January 2008) we have both LDAP and NIS operating for authetication. NIS is scheduled to phased out some time in 2008. ANy new installations of Linux should be configured to use the LDAP services. See Project LDAP for details on the LDAP setup. Here we give a brief summary of the client configuration.

C.5.1 LDAP Clients (NO TLS)

To enable authentication on Fedora following things are required:

• On the client make sure that the packages listed below are installed
  1. openldap
  2. openldap-clients
  3. openldap-devel
  4. nss_ldap

• /etc/ldap.conf contains

host ds.cs.ucy.ac.cy ds1.cs.ucy.ac.cy ds2.cs.ucy.ac.cy
base dc=cs,dc=ucy,dc=ac,dc=cy

nss_base_passwd         ou=People,dc=cs,dc=ucy,dc=ac,dc=cy
nss_base_shadow         ou=People,dc=cs,dc=ucy,dc=ac,dc=cy
nss_base_group          ou=Group,dc=cs,dc=ucy,dc=ac,dc=cy
nss_base_netgroup       ou=Netgroup,dc=cs,dc=ucy,dc=ac,dc=cy

nss_initgroups_ignoreusers root,?system  Where ?system is the local system account on the machine
 on nireas and proteas the ldap user must also be present

pam_password crypt

• /etc/openldap/ldap.conf contains

HOST ds.cs.ucy.ac.cy ds1.cs.ucy.ac.cy ds2.cs.ucy.ac.cy
BASE dc=cs,dc=ucy,dc=ac,dc=cy

• /etc/nsswitch.conf has the ldap method listed. At the very least we need:

 passwd:     files ldap
 shadow:     files ldap
 group:      files ldap

 protocols:  files ldap
 services:   files ldap
 netgroup:   files ldap
 automount:  files ldap

which enables authentications from local files and ldap.

• Make sure that /etc/pam.d/system-auth contains the followings (order is very important!). Other entries are usually necessary in this file:

auth        requisite     pam_succeed_if.so uid >= 200 quiet
auth        sufficient    pam_ldap.so use_first_pass

account     sufficient    pam_succeed_if.so uid < 200 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so

password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok

session     required      pam_unix.so
session     optional      pam_ldap.so

Note the 200 above. Not 500, since we have users with UIDs starting at 200 and above!!

• Here is a complete working system-auth file from CentOS 5.2

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
#######auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        requisite     pam_succeed_if.so uid >= 200 quiet
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so
account     required      pam_unix.so
#######account     sufficient    pam_succeed_if.so uid < 500 quiet
account     sufficient    pam_succeed_if.so uid < 200 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so
password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authok
password    required      pam_deny.so
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

C.5.2 LDAP clients (with TLS)

Having tested that the client can authenticate against Fedora Directory Server without TLS, we can proceed configure it to use TLS as describe below:

• Copy the certificate of the Certification Authority that has signed the certificate of Fedora Directory Server

cd /etc/openldap/cacerts
wget ftp://ftp.cs.ucy.ac.cy/pub/linux/files/csca.crt

• Add the followings to /etc/ldap.conf

 tls_cacertdir /etc/openldap/cacerts
 ssl start_tls

• Add the followings to /etc/openldap/ldap.conf

TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT   allow

C.5.3 NIS Clients

This is obsolete information! All new Linux installs should use LDAP authentication.

NIS works best if the client does an autodiscover of available server when needed. If for some reason the auto-discover mode (broadcast) does not work then we prefer to have at least two servers for each client in the yp.conf file and the option to auto-discover (broadcast) if both fail. Minimum example of a /etc/yp.conf file:

# /etc/yp.conf - ypbind configuration file
# Valid entries are
#
# domain NISDOMAIN server HOSTNAME
#       Use server HOSTNAME for the domain NISDOMAIN.
#
#   domain NISDOMAIN broadcast
#       Use  broadcast  on  the local net for domain NISDOMAIN
#
# domain NISDOMAIN slp
#       Query local SLP server for ypserver supporting NISDOMAIN
#
# ypserver HOSTNAME
#       Use server HOSTNAME for the  local  domain.  The
#       IP-address of server must be listed in /etc/hosts.
#
# broadcast
#       If no server for the default domain is specified or
#       none of them is rechable, try a broadcast call to
#       find a server.
#
domain csnis server nis1.cs.ucy.ac.cy
domain csnis server nis2.cs.ucy.ac.cy
broadcast

Note 1: If you are using dynamic IP address assignment through a DHCP server then the file /etc/yp.conf is controlled by the dhcp client procedure and will be overwritten by it. Make sure that the DHCP server assigns proper NIS domain and server values.

Note 2: If you are using static IP, check yp after rebooting the machine, especially when the service "IP tables" is enabled. If the ypbind fails to start, the you have to add in /etc/sysconfig/network the line NISDOMAIN=csnis

C.6 Automounting with autofs

Autofs controls the operation of the automount daemons. The automount daemons automatically mount filesystems when you use them and unmount them after a period of inactivity. To configure autofs we have to edit the file /etc/auto.master.

 # This is an automounter map and it has the following format
 # key [ -mount-options-separated-by-comma ] location
 # For details of the format look at autofs(5).
 /home   /etc/auto.home --timeout=3600 --ghost

This specifies that any attempt to access folders within /home triggers a reference to the /etc/auto.home file. Each of the items in the first field serves as a root for mounting. As such, it should exist in the file system as an empty directory, the automounter will handle the creation of whatever subdirectories are needed. The --ghost option directs the automounter to create empty directories of all the mount points listed in the configuration file, regardless of whether any of the file systems is actually mounted or not. The mount points are then defined in the configuration file, in our case, /etc/auto.home.

 faculty         -rw     csfs1.cs.ucy.ac.cy:/faculty
 support         -rw     csfs3.cs.ucy.ac.cy:/home/support
 research        -rw     csfs4.cs.ucy.ac.cy:/research
 projects        -rw     csfs5.cs.ucy.ac.cy:/projects
 courses         -rw     csfs6.cs.ucy.ac.cy:/courses
 students/cs     -rw     csfs7.cs.ucy.ac.cy:/home/students/cs

The last step is to configure autofs to run each time the system is started.

 chkconfig autofs on

C.6.1 Automounting through LDAP service

Client Configuration Make sure that the file /etc/nsswitch.conf contains a line that looks like:

  automount: files ldap

At the end of the file /etc/sysconfig/autofs append the followings:

 # Other common LDAP nameing 

 # 

   DEFAULT_MAP_OBJECT_CLASS="automountMap" 

   DEFAULT_ENTRY_OBJECT_CLASS="automount" 

   DEFAULT_MAP_ATTRIBUTE="ou" 

   DEFAULT_ENTRY_ATTRIBUTE="cn" 

   DEFAULT_VALUE_ATTRIBUTE="automountInformation" 

Note 1: If you follow the filesystem structure, as in 2.1 above, you have to comment out the /home mount point in /etc/fstab, so as the /home is not mounted. Ensure also that the /home dir exists. You also need to execute the command from the / as follow: ln -s /home /u, since the setup for home dirs for some users is /u/faculty/<username>

Note 2: For FC7 you need to add the following to the /etc/auto.master /- yp:auto.master /home yp:auto.home and comment out all other entries

C.7 Security

See the page Linux Security on how to configure Linux clients and servers. This is a requirement NOT an option! See also Security for more in depth instructions.

1. Firewall must be running on all systems.
   • Only services and ports that are necessary for the operation of the server must be open on the local FW
2. All systems must have remote root access disabled (including ssh)
   • Edit /etc/ssh/sshd_config and change the line #PermitRootLogin yes to PermitRootLogin no or to PermitRootLogin without-password in case you want to login as root using a key. --kekkos 16:03, 24 January 2007 (EET)

• Also add the following lines in /etc/ssh/sshd_config which disable all logins except from the users authorized. Add any other users very carefully and document why in the server wiki page.

####
####
# Only these can login
###
## root@uls is needed so that uls can scp the primarygroups files to /etc/mailaliases
AllowUsers ank savvasn kekkos tmaria andrim

1. All systems must have telnet disabled (ssh is enabled)

On systems that ssh access does not need to be open for public access then disable such access.

Example: For mostly closed systems (servers) then do the following

File /etc/hosts.deny have the following line:

ALL: ALL

File /etc/hosts.allow have the following line (or something similar depending on what you want to allow)

ALL: .cs.ucy.ac.cy, .in.cs.ucy.ac.cy

Recent versions of sshd daemon, deny login if the name of the machine that initiates the connection is not present in dns' database. This may cause problems in case where machines need to be accessible from anywhere and not only from the domains that have been mentioned above. To avoid this put the following line in file /etc/hosts.allow --kekkos 16:06, 7 February 2007 (EET)

sshd: ALL

Restart sshd by

service sshd restart

C.8 NFS

1. Create the file "/etc/sysconfig/nfs" and add the following contents:
   • STATD_PORT=4001
   • LOCKD_TCPPORT=4002
   • LOCKD_UDPPORT=4002
   • MOUNTD_PORT=4003
2. Append the following to the file "/etc/services":
   • rquotad 4004/tcp # rpc.rquotad tcp port
   • rquotad 4004/udp # rpc.rquotad udp port
3. Restart the nfs services:
   • service nfs restart
4. Re-run /usr/sbin/rpcinfo -p and make sure all the ports above have changed.
5. Open up the following ports (tcp and udp) on the Fedora firewall. Do this either using the "Security Level" app in "System Settings" or using the command line iptables command (think it's in /sbin/):

111:tcp, 111:udp, 2049:tcp, 2049:udp, 4001:tcp, 4001:udp, 4002:tcp, 4002:udp, 4003:tcp, 4003:udp, 4004:tcp, 4004:udp

(You can copy and paste the above text into the "Other ports: (1029:tcp)" section of the "Security Level Configuration").

C.9 Anti Virus

• All Linux systems must have the ClamAV anti virus installed. This is even more important if the system will have local user data of any type (ex. student data, mail data etc). ClamAV is included in the Fedora distribution but NOT in the CentOS distributions. Get CentOS compatible ClamAV from the Dag Wieers RPM repository. See OTY_Internal:ClamAV for details on installing and configuring the anti virus software.

• install the clamav and clamav-db RPMS (if required)
• Anti virus scanning should be run on LOCAL DATA only (not NFS or SAMBA etc) every night.
• ClamAV updates should be enabled for automatic update on all Linux systems. See OTY_Internal:ClamAV on how to do this.

C.10 Install Postfix in send only mode

This is required only on server type machines since it allows the server to report its status or errors that come up via email.

1. Stop and remove any sendmail software

service sendmail stop
yum remove sendmail

(this will usually remove also dependency software, hopefully nothing we need)

2. Install postfix (or make sure is available)

yum info postfix
yum install postfix

3. Configure the postfix mail server

• Edit file /etc/postfix/main.cf and change the following parameters to the new values provided here

myhostname = <hostname>.cs.ucy.ac.cy OR <hostname>.in.cs.ucy.ac.cy (ex. myhostname = eris.cs.ucy.ac.cy)
myorigin = $mydomain
relayhost = $mydomain
inet_interfaces = 127.0.0.1 (or inet_interfaces = localhost)
local_transport = error:local delivery is disabled

• Edit file /etc/postfix/master.cf. Comment out the local delivery agent entry. Example:

### local     unix  -       n       n       -       -       local

This setup will do the following:

1. send mail from any user on the machine (ie From:user@cs.ucy.ac.cy)
2. forwards mail to server responsible for cs.ucy.ac.cy
3. does not accept mail from the network
4. does not deliver mail locally (all mail is sent)

4. Make sure postfix restarts on boot (chkconfig --list)

C.11 Logging, Monitoring and Management

Syslog configuration is an important part of Linux configuration. Special attention should be payed to server machines since misconfiguring syslogd will likely disable the servers due to logging system overflow (on /var usually). See the syslog pages for details on how to properly set up the syslog facility. There is also a central syslog server on system Triton that keeps track of log activity in various forms.

There is a systems monitoring facility on Triton. This monitoring facility uses Nagios to record and alert us of various events around the Department. See also OTY Internal:Monitoring and Management on more details on how monitoring works.

Instructions below give the basics on how to configure the logging facilities and how to allow Nagios to monitor a Linux system.

C.11.1 Logging (/var/log, syslogd and logrotate)

• Each system (client or server) should have its own logging facility enabled (writing to /var/log files). This is usually on be default. Make sure that service syslog is on.
• Server machines that should be monitored MUST log their syslog data to the central syslog server - Triton. Add the following line at the END of the /etc/syslog.conf file:

## Log all activity to the central syslog server
*.*     @10.16.0.1

• Attention should be payed so that /var/log/ files are properly rotated so that the /var file system does not run the risk of overflowing. See the Logging configuration instructions on how to properly do this.

C.11.2. Monitoring (Nagios and SNMP)

• We are using the Nagios system to monitor our systems. Monitoring with Nagios is an involved issue. What follows are minimal instructions to get a system monitored.

While basic monitoring a Linux system can be done without installing anything on it (via the Nagios plugins) more extensive (and more secure) monitoring requires the installation of the following RPMs:

• The NRPE (Nagios Remote Process Execution) system RPM
• The Nagios Plug-ins RPM

To install these do the following after you set up the systems for correct updating as described in Section D below:

yum install nagios-nrpe
yum install nagios-plugins

• Notes:

• These two packages are not part of CentOS (at least unitl 5.1) but are available from the Dag Wieers site
• For CentOS: You may have to install additional RPMs ex. fping, Perl::SNMP, Pearl::CryptDES as prerequisites. These are usually in the CS-LocalExtras YUM repository but get them from above site if not available.

C.11.3 Configuring the NRPE environment

In order to allow the NRPE to work properly with our monitoring system do the following:

• Edit the /etc/nagios/nrpe.cfg file as follows:

     allowed_hosts=triton.cs.ucy.ac.cy

• Check that the port chosen in /etc/nrpe.cfg (default 5666) has access to this machine. The iptables configuration will likely need to be changed. Use system-config-securitylevel and add 5666:tcp 5666:udp to the other ports to enable.

• Make sure that the nrpe service will start on reboot (chkconfig nrpe on).

It must be emphasized that this is a minimal configuration and any special monitoring cases must be coordinated between the Nagios admin the the Linux machine admin. You may now want to configure monitoring from the server site (triton) and check that some monitoring takes place. See /etc/nagios/servers/eris.cfg or iolaos.cfg to see how we configure NRPE to do the monitoring.

C.11.4 Configuring the SNMP environment

SNMP is an involved subject. To get SNMP minimally configured for our purposes do the following:

• Save the /etc/snmp/snmpd.conf file to snmpd.conf.orig
• Replace the /etc/snmp/snmpd.conf file with the following contents only (three lines):

rocommunity cs123

view systemview included .1.3.6.1.2.1.1

view systemview included .1.3.6.1.2.1.25.1.1

This configuration will allow browsing of a small set of the SNMP variables.

• Open ports 161:tcp and 161:udp on the server for traffic ONLY from triton (10.16.0.1)

The above can be done by inserting the following lines in /etc/sysconfig/iptables:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 161 -s 10.16.0.1 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 161 -s 10.16.0.1 -j ACCEPT

You cannot do this from the system-config-securitylevel.

• Restart the iptables firewall service
• Start the snmpd daemon. Make sure it will restart on reboot (chkconfig).

C.12 Backup setup

If you are installing a server type machine then you MUST arrange for its automatic backup. Backup is done according to the OTY_Internal:Backup Policy

If you are installing a client that will have local data then you can also arrange for its automatic backup.

D. Updating Linux

All Linux machines MUST follow these configurations and procedures.

ALL Linux machines should use this YUM system and no external update sources.

The CS dept operates its own yum server for upgrading all Linux machines. Above all this provides for a consistent repository of software on which to work from. We hope that this provides for a better stability (instead of getting software from all over the places). This also provides better and faster access to the install and update repositories allowing machines to update in a timely manner. It also conserves our network bandwidth. Since we already operate a large number of Linux machines this is important. If you want to learn more about the YUM repositories and how to configure new applications in them then visit YUM repositories description.

Updates are currently maintained for all CentOS supported versions for i386 and x86_64 architectures and the latest 3-4 Fedora Releases. Updates are downloaded/refreshed at least daily. Some are updated several times a day.

In order for a Linux Fedora/CentOS machine to access the YUM server it must be configured to do so.

There is a problem with the gpg key import.Disabling gpgkey=0 in yum.conf fixes it but...

D.1 Configure CentOS

Configure CentOS Version 5

1. Make sure you disable the original configuration by moving all the original repo files in /etc/yum.repos.d into a temp directory under /etc/yum.repos.d (e.x. /etc/yum.repos.d/original).
2. For CentOS 5 there are three files that enable access to the YUM repos: Centos-CS-Base.repo, Centos-CS-LocalExtras.repo and CentOS-Media.repo. The CentOS-Media.repo allows you to install software from the original CDs using YUM. It comes by default on every CentOS system so you can copy it from the original files if you want to. It is usually not needed and therefore is disabled by default.
3. Install the new repo files in the /etc/yum.repos.d directory by either transferring them or creating new files.
4. Check that updating works. Try "yum check-update" and see if any errors come up. You should be getting something similar to the following:

# yum check-update
Loading "priorities" plugin
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
* CS-addons: yum.cs.ucy.ac.cy
* CS-LocalExtras: yum.cs.ucy.ac.cy
* CS-updates: yum.cs.ucy.ac.cy
* CS-base: yum.cs.ucy.ac.cy
* CS-extras: yum.cs.ucy.ac.cy
0 packages excluded due to repository priority protections

NetworkManager.i386                      1:0.7.0-4.el5_3        CS-updates
NetworkManager-glib.i386                 1:0.7.0-4.el5_3        CS-updates
NetworkManager-gnome.i386                1:0.7.0-4.el5_3        CS-updates
ORBit2.i386                              2.14.3-5.el5           CS-base
SysVinit.i386                            2.86-15.el5            CS-base
acpid.i386                               1.0.4-7.el5_3.1        CS-updates
alsa-lib.i386                            1.0.17-1.el5           CS-base
alsa-utils.i386                          1.0.17-1.el5           CS-base
...........................................................................

No external repositories should appear in the lists (i.e. ALL repositories should start with CS-. If you insist on mixing outside and inside repositories you are actually asking for trouble since each repository may be at a different update point.

Notes:

• The CentOS CS-extras repository is enabled by the files above. This repository contains application/updates NOT in the official RedHat release but which have been tested by the CentOS team.
• The CentOS CS-centosplus repository is disabled by the files above. Keep this repository disabled unless you know what you are doing since it contains packaged which BREAK the compatibility with official RedHat releases and built differently than the standard packages.
• The Centos-CS-LocalExtras repository contains applications that WE have downloaded and tested and is enabled by default. Make sure you really want to install anything that comes from this repository.

D.2 For Fedora Release 8, 9, 10, 11

- make sure that the reposdir parameter is NOT defined in /etc/yum.conf.
- in the file /etc/yum.conf add the lines
[base]
name=Fedora Core $releasever-$basearch - Base on CS-UCY Yum server
baseurl=ftp://yum.cs.ucy.ac.cy/pub/linux/fedora/releases/$releasever/Fedora/$basearch/os

[updates-released]
name=Fedora Core $releasever-$basearch - Released Updates on CS-UCY Yum server
baseurl=ftp://yum.cs.ucy.ac.cy/pub/linux/fedora/updates/$releasever/$basearch

If you don't want to edit /etc/yum.conf you can download the following files and place them in /etc/yum.repos.d/.

fedora-core-cs-ucy-mirror.repo

fedora-extras-cs-ucy-mirror.repo

fedora-updates-cs-ucy-mirror.repo

cs-extras.repo

Please remember to delete or rename the files fedora-core.repo, fedora-extras.repo and fedora-updates.repo. Failure to do so will result in downloading updates from the Internet.

A YUM-HOWTO is found here.

D.3 Update Policy

The following policy MUST be adhered to in upgrading all Linux machines managed by Support: Downloading of upgades is done every night.

D.3.1. Client Machines

Client machines should be updated weekly with all the updates available (kernel included). Particular attention is payed to security updates.

* It is advisable that NOT all machines are upgraded the same day so that in case of 
  error in the updates only a small number of clients will be affected. One possible 
  way to do this is to have all machines with system number ending to 1 or 2 
  (ex CS101, CS102) make an upgrade on Monday, number 3,4 on Tuesday etc.

* It is advisable that critical software not be allowed to update automatically unless we 
  have determined (by doing a manual update) that updates actually work. Critical software
  are:
       --- kernel (see also below)
       --- applications software that MUST be available 
           (ex. C compiler in teaching labs)

D.3.2 Server Machines

D.3.3 Things to watch for

When upgrading Linux systems watch for the following:
  1. when upgrading kernels the /root partition tends to become full. 
     This is mainly because the /lib directory grows for ever since upgrading the kernel
     does not remove the old ones and /lib/modules and other directories get large.
     To remove a kernel do something like:
              yum remove kernel-2.6.11-1.14_FC3
        or    rpm -e kernel-2.6.11-1.14_FC3
     The best practice should be to leave around 2-3 generations of kernels in case 
     we need them.
   2. This has been fixed on the later versions of fedora and centos. The system now
      automatically deletes all except the last two versions.

E. Miscellaneous Options

E.1 Automatic Installation using kickstart

Linux enables administrator to prepare a configuration file,named ks.cfg in order to prepare multiple clients, with minimal effort. Kickstart file, can be placed on a floppy drive, on bootable cd, or on ftp, http server.

Click here to find out how this can be done.

E.2 Bug with the anaconda installer for FC4 (at least)

There is a bug with the anaconda installer for FC4 (it may appear on other releases also) which gives partly the following error immediately before filesystems are ready to be formatted:

   The kernel was unable to re-read the partition table on /dev/hda .......... (Device or          
   resource busy).

This error appears only on pre-partitioned systems that need to be reinstalled with a different partiiton scheme. To resolve this issue:

1. boot from the install CD
2. go into rescue mode (F5)
3. when you are at the promp type

  dd if=/dev/zero of=/dev/hda bs=512 count=1

1. reboot and continue as usual

F. Troubleshooting

See Also

• Linux Lab
• Linux how to

Installation Template

1. Hostname