View source for 'OTY Internal:Linux Installation/23Nov2009'

{| align="right" style="background:lightyellow; margin: 0 0 0.5em 1em;" id="toc" width=220
|-
|style="background:#e1ecf7" colspan="2" align="center"|<big>'''Archive'''</big> <br> 
|-
| [[OTY_Internal:Linux Installation/17Nov2006|Version of 17 Nov 2006]]
|-
| [[OTY_Internal:Linux Installation/20Sept2007|Version of 20 Sept 2007]]
|-
| [[OTY_Internal:Linux Installation/09January2008|Version of 09 Jan 2008]]
|-
| [[OTY_Internal:Linux Installation/02July2008|Version of 02 Jul 2008]]
|-
|}

<div style="background: #FFFFFF;">'''Notes'''
#'''Linux Installation is ALSO described in the [[Linux_installation_guide]] in the general access documents.'''
#'''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.'''
#'''The [[Linux_installation_guide]] will, eventually, be restructured to provide instructions for the general population.'''
#'''Sections marked in red like this <div style="background: #FF0000;"> Obsolete section</div> will be removed from this document on the next version.</div>'''

==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.

<div style="background: #e1ecf7;">

==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:
# Read this document entirely before starting an installation
# 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.
# Based on the template you can answer questions and provide input during the actual installation.
# 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 [http://oss.sgi.com/projects/xfs/ 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 [http://sources.redhat.com/lvm2/ 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.

===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 [http://www.mjmwired.net/resources here]. For examples see [[OTY_Internal:Kalliopi|kalliopi server]] or [[OTY_Internal:Eris|Eris server]] or [[OTY_Internal:Linux Lab|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====
<div style="background: #FFFFFF;">
#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.
#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.
# On each server machine we create one additional user to be used in case the authorizations system (NIS) becomes inoperative. The user is named '''x'''system 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'''.
# 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.
# Enable printing and configure at least one general purpose printer convenient to the users ie administrators.
</div>



<div style="background: #FFFFCC;">

==C. Configuration of Linux systems==
===C.1 Services, Daemons, Applications===
#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.
#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.

{{red|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 ";

{{red|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 ntp1.cs.ucy.ac.cy 
     restrict ntp1.cs.ucy.ac.cy mask 255.255.255.255 nomodify notrap noquery

{{red|'''NOTE:''' 
# delete (or comment out) any other '''server xx.xx.xx.xx''' lines
# for every server line you delete or comment out, do the same for the corresponding restrict line [[User:Savvasn|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 [[OTY_Internal:Project LDAP|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
*#openldap
*#openldap-clients
*#openldap-devel
*#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''''' {{red | Where ''?system'' is the local system account on the machine}}
 {{red | 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

<div style="background: #FF0000;">
====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
</div>

===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 <br>
  # <br>
    DEFAULT_MAP_OBJECT_CLASS="automountMap" <br>
    DEFAULT_ENTRY_OBJECT_CLASS="automount" <br>
    DEFAULT_MAP_ATTRIBUTE="ou" <br>
    DEFAULT_ENTRY_ATTRIBUTE="cn" <br>
    DEFAULT_VALUE_ATTRIBUTE="automountInformation" <br>


{{red|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>

{{red|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 [[OTY_Internal:Linux Security|Linux Security]] on how to configure Linux clients and servers.'''
This is a requirement NOT an option!
See also [[OTY_Internal:Security|Security]] for more in depth instructions.

# 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
# 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.
<div style="background: #FFFFFF;">
<pre>
####
####
# 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
</pre>
</div>
# 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 ===
# Create the file "/etc/sysconfig/nfs" and add the following contents:
#*STATD_PORT=4001
#*LOCKD_TCPPORT=4002
#*LOCKD_UDPPORT=4002
#*MOUNTD_PORT=4003
# Append the following to the file "/etc/services":
#*rquotad 4004/tcp # rpc.rquotad tcp port
#*rquotad 4004/udp # rpc.rquotad udp port
# Restart the nfs services:
#* service nfs restart
# Re-run /usr/sbin/rpcinfo -p and make sure all the ports above have changed.
# 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 [http://dag.wieers.com/rpm/packages/clamav/ 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 stop sendmail
 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:
# send mail from any user on the machine (ie From:user@cs.ucy.ac.cy)
# forwards mail to server responsible for cs.ucy.ac.cy
# '''does not''' accept mail from the network 
# '''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  [[OTY_Internal:Monitoring_and_Management#Syslog_setup| 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 [[OTY Internal:Monitoring and Mgmt#Logrotate setup|Logging configuration instructions]] on how to properly do this.

====C.11.2. Monitoring (Nagios and SNMP) ====
* We are using the [http://www.nagios.or 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 [http://dag.wieers.com/rpm/ 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 follwoing:

*'''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.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.

</div>

==D. Updating Linux==

The CS dept operates its own yum server for upgrading all Linux machines. This provides better and faster access to the update repositories allowing machines to update in a timely manner. If you are not familiar with the YUM setup then read the [[yum-repos-config|YUM repositories description]]

Updates are currently maintained for FC5, FC6, FC7, Releases 8, 9 and all CentOS supported versions for i386 and x86_64 architectures. This list changes gradually according to the active releases we are using (see above). It is expected that we will maintain at least three releases at all times for each Linux distribution we use. Updates are downloaded/refreshed at least daily. Some are updated several times a day. Each machine should use this system and not external update sources to minimize network traffic.

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

{{red|There is a problem with the gpg key import.Disabling gpgkey<nowiki>=</nowiki>0 in yum.conf fixes it but...}}

===D.1 For Fedora Release 7, 8, 9 ===

<pre>
- 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

</pre>

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

[ftp://ftp.cs.ucy.ac.cy/pub/linux/files/fedora-core-cs-ucy-mirror.repo fedora-core-cs-ucy-mirror.repo]

[ftp://ftp.cs.ucy.ac.cy/pub/linux/files/fedora-extras-cs-ucy-mirror.repo fedora-extras-cs-ucy-mirror.repo]

[ftp://ftp.cs.ucy.ac.cy/pub/linux/files/fedora-updates-cs-ucy-mirror.repo fedora-updates-cs-ucy-mirror.repo]

[ftp://ftp.cs.ucy.ac.cy/pub/linux/files/cs-extras.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.

[ftp://ftp.cs.ucy.ac.cy/pub/linux/cs-doc-extras/PDF/yum_HOWTO.a4.pdf A YUM-HOWTO is found here.]

===D.2 CentOS v. 5===
For CentOS 5 there are three files that enable access to the YUM repos: [http://ftp.cs.ucy.ac.cy/pub/linux/files/CentOS-CS-Base.repo Centos-CS-Base.repo], [http://ftp.cs.ucy.ac.cy/pub/linux/files/CentOS-CS-LocalExtras.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 is installed and disabled by default. Install the new repo files by:

# Make sure you disable the original configuration by moving all the original ''repo'' files into a temp directory under /etc/yum.repos.d (e.x. /etc/yum.repos.d/orig).
# Save the repo files above in /etc/yum.repos.d 
# Check that updating works. Try "yum check-update" and see if any errors come up.

'''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 repo.'''
* '''You have been warned.'''

===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.

<div style="background: #FFFFCC;">

==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:
# boot from the install CD
# go into rescue mode (F5)
# when you are at the promp type
   dd if=/dev/zero of=/dev/hda bs=512 count=1
# reboot and continue as usual


</div>

==F. Troubleshooting==

==See Also==
*[[Linux Lab]]
*[[Linux how to]]

==Installation Template==
1. Hostname