Difference between revisions of "Linux installation guide"

From CSWiki
Jump to navigation Jump to search
Line 2: Line 2:
 
This document contains guidelines in setting up/configuring and updating of Linux systems. It contains instructions in setting up a system to closely resemble the systems that exist at the Computer Science department. It is therefore appropritate for those that want to set up their own system to behave like the department systems.
 
This document contains guidelines in setting up/configuring and updating of Linux systems. It contains instructions in setting up a system to closely resemble the systems that exist at the Computer Science department. It is therefore appropritate for those that want to set up their own system to behave like the department systems.
  
The department has standardized on the [http://centos.org/wiki CentOS Linux distribution]. Our most recent installs use CentOS versions 6 and 7.
+
The department has standardized on the [http://centos.org CentOS Linux distribution]. Our most recent installs use CentOS versions 6 and 7.
  
 
__TOC__
 
__TOC__

Revision as of 12:29, 23 October 2015

Linux Installation Instructions

This document contains guidelines in setting up/configuring and updating of Linux systems. It contains instructions in setting up a system to closely resemble the systems that exist at the Computer Science department. It is therefore appropritate for those that want to set up their own system to behave like the department systems.

The department has standardized on the CentOS Linux distribution. Our most recent installs use CentOS versions 6 and 7.

Installing Linux

Get and read the Installations Guide for your version of Fedora. This document DOES NOT cover all the details of an installation. It simply makes susggestions on how to make better decisions during installation.

Filesystem choices and structure

   * Filesystem configuration
     We always use LVM version 2 and up for setting up Fedora filesystems
   * 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 (VolGroup00).
           Suggested size is 15,000MB. This gives enough space for installing and 
           expanding later if required.
         o One LVM Volume group (VolGroup00) for OS. See above.
         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 separete volume group is necessary or desirable. 
           Otherwise we can create a filesystem within the OS volume group. It can 
           also be constrained into a physical drive if required.
   * Filesystems
         o Within the VolGroup00 we have:
           (root) / 	1024MB (1GB)
           /usr 	4096MB (3GB) for server machines
                       5120MB (5GB) for client machines
                       (can be increased or decreased if requirements demand it)
           /var 	1024MB (1GB)
           /tmp 	512MB
           /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.
           /sys-data (optional, see above)
           
           Remaining of disk space.
           Data file-system (in case VolGroup00 will not be used for data storage).
         o Within VolGroup01, if it exists, create a filesystem 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. If extra speed is required prefer xfs
           or reiserfs.

Security

  • The IPtables system should be installed and operational on ALL client and server machines

Services and Applications installed

A list of services and applications that the machine is being used for must be maintained. More information about servives can be found here.

Client machines

Only the following services must be running: acpid, autofs, 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, nasd, netfs, network, nfslock, ntpd, portmap, readahead, readahead_early, smartd, sshd, syslog, xfs, ypbind.

Server machines

  1. Install only services absolutely required for the server functions.
  2. Server machines (web, mail, db etc) 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 then do so in /etc/inittab.
  3. New. 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.

C. Configuration of Linux systems

C.1 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 ";".

C.2 NTP

   * the following minimum configuration must be made in /etc/ntp.conf
    keys            /etc/ntp/keys
    server 194.42.16.20
    restrict 194.42.16.20 mask 255.255.255.0 nomodify notrap
   * delete (or comment out) any other server xx.xx.xx.xx lines

C.3 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

Notes: 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>

C.4 Authentication

C.4.1 NIS

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.4.2 LDAP

To authenticate against an LDAP server do the following:

Logging and monitoring (/var/log, Nagios, syslogd, snmp)

  • Each system should have its own logging facility enabled (writing to /var/log files).
  • Attention should be payed so that /var/log/ files are properly rotated so that the /var filesystem does not run the risk of overflowing.
  • We are using the Nagios system to monitor our systems. In order to allow proper monitoring of Linux systems the following RPMs must be installed:
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 nrpe
yum install nagios-plugins

This is applicable to Fedora Core 4. Do not try it on earlier systems. Upgrade!

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=194.42.16.17
     dont_blame_nrpe=1
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.       

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.

C.6 Security

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/ssd_config and change the line #PermitRootLogin yes to PermitRootLogin no
  3. 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

Restart sshd by

service sshd restart

C.6.1 Enable NFS on FC firewall

  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.6.2. Antivirus

  • All Linux systems must have the ClamAV antivirus installed.

C.7 Install Postfix in send only mode

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

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


5. Configure /etc/syslogd.conf Append at the end of the file the value

  • .* <IP address of the central managment machine>

reload syslogd service

D. Updating Linux

The CS dept operates its own yum server for upgrading all Linux machines. Updates are currently maintained for FC2, FC3, FC4 and FC5. This list will gradually change according to the active releases we are using (see above). It is expected that we will maintain at least three releases at all times. Updates are downloaded/refreshed every Sunday at 2:00 am. Each machine should use this system and not external update sources to minimize network traffic.

In order for a Linux Fedora machine to access the YUM server it must be configured to do so. A working configuration is available on system eris (also the yum server machine). There is a problem with the gpg key import.Disabling gpgkey=0 in yum.conf fixes it but...

D.1 For Fedora Core2

in the file /etc/yum.conf replace the following lines:

name=Fedora Core $releasever - $basearch - Base
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/$releasever/$basearch/os/

[updates-released]
name=Fedora Core $releasever - $basearch - Released Updates
baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/updates/$releasever/$basearch/

with

[base]
name=Fedora Core $releasever-$basearch - Base on CS-UCY Yum server
baseurl=ftp://yum.cs.ucy.ac.cy/pub/linux/fedora/core/$releasever/$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/core/updates/$releasever/$basearch

D.2 For Fedora Core3 and later

- 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/core/$releasever/$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/core/updates/$releasever/$basearch

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

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

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 RedHat's up2date

If we like to be able to use also the up2date tool provided by RedHat and the up2date applet on our desktop then the following configuration should be made in /etc/sysconfig/rhn/sources:

   * comment out the default yum configuration
   * insert the following lines:
         o yum fedora-core ftp://yum.cs.ucy.ac.cy/pub/linux/fedora/core/3/$ARCH/os
         o yum updates-released ftp://yum.cs.ucy.ac.cy/pub/linux/fedora/core/updates/3/$ARCH
         o yum extras ftp://yum.cs.ucy.ac.cy/pub/linux/fedora/extras/3/$ARCH 
         o yum cs-extras ftp://yum.cs.ucy.ac.cy/pub/linux/cs-extras/fedora/3 

Unfortunately up2date cannot detect the release level installed and therefore it must be configured for the correct release version of Fedora. Above we have it for Fedora Core3.

D.4 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.4.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.4.2 Server Machines

D.4.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.
Update
This is automatically enabled for FC5 and newer versions. The install system removes older 
kernels leaving two generations available.

D.5 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.

D.6 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

See Also