Start See Generic Linux installation procedure first!
Caveats

• These reflect my preferences
• They're mostly based on etch (Debian 4.0), but should work for other derivatives and earlier versions.
• They're mostly here for my benefit, particularly when installing VServer s, VMware VMs, or Xen domUs.

Software installation

• Change /etc/apt/sources.list to comment unneeded repositories (i don't use deb-src on most machines) and add contrib & non-free (if necessary).
• Add the following to /etc/apt/apt.conf :
  Aptitude::Recommends-Important "false"; This ensures that aptitude doesn't enforce "soft" (recommends) dependencies, only "hard" (requires) dependencies. It doesn't seem to be necessary on new vservers, since this file is copied from the host.
• (sarge only) Reduce the noise of package installs:
  dpkg-reconfigure debconf (Choose high when prompted for the priority.) This step isn't necessary any more on etch, since high is the default.
• Install latest OS updates that didn't get added during the install process:
  aptitude update
  aptitude upgrade
• Set ftp_proxy , http_proxy , and https_proxy environment variables.
• Remove non-preferred apps in base install:
  aptitude purge vim-tiny nvi nano
• Install preferred software.
  • Core set for all machines:
    aptitude install acct apt-show-versions at bc bind9-host bzip2 deborphan \
    debsums file ftp isag less logwatch lsof lsscsi ltrace make openssl patch \
    perl postfix psmisc rsync ssh strace sysstat subversion sysvconfig telnet \
    time vim
  • Additional packages for physical hosts (i.e. not VMs):
    aptitude install bind9 pciutils

• (I usually share one bind9 instance across all VMs on one physical host.)

• Purge unneeded library dependencies:
  while [ `deborphan | wc -l` -gt 0 ]; do
  aptitude purge `deborphan`
  done

Other things to do after a fresh install

• Set up /etc/resolv.conf with appropriate name servers & domains. (The installer only allows one domain and one name server.)
• (VMs only) Edit the mess that debootstrap/xen-create-image makes of /etc/hosts .
• Add your ssh public key to /root/.ssh/authorized_keys2 .
• Edit /etc/syslog.conf to put syslog messages on tty12. Add this line:
  *.debug /dev/tty12
• Verify contents of /etc/network/interfaces
• Change sysstat config.
• (VServers only) It seems necessary to change the following line in /etc/postfix/main.cf :
  inet_interfaces = all to
  inet_interfaces = $myhostname

System planning Disk design

• RAID
  In general, Linux software RAID is preferable for OS disks.
• file system layouts
  In general, the fewer file systems present, the easier a system is to manage. For most servers, separate volumes for the following file systems should be configured:
  • / (root)
  • /boot
  • /tmp
  • /var

• Additional file systems should be added when applications need isolation. For small server disks (anything under 72 GB or so), this may not be feasible.

• location of data
  In general, unless there is a good reason to do otherwise, application data should be stored under /srv/APPNAME for system-provided applications, or /var/opt/APPNAME for 3rd-party applications which comply with the FHS standard for optional packages.
• Commonly used disk-related commands

Network design

• Determine trust models for network services.
• Determine location in network topology.

Distribution-specific Installation Notes

• General Debian installation notes
• SLES 10 installation notes

Configuration As a simple way of maintaining configuration history on a system, i prefer to set up subversion for maintaining local configuration on all systems.
Services Host services As far as possible, all hosts should have some basic accounting and performance collection configured, and store it for at least one month, preferably more. Packages that should be configured are:

• acct - process accounting
• sysstat - sar & iostat gathering

Network services

• Host naming
  • Local
    /etc/hosts needs to be edited post-install on most distributions. The exception to this is dynamic IP servers on modern distributions such as openSUSE 10.2 or Ubuntu 6.10.
  • DNS
    • server
      • Basic steps to secure a public bind9 server
    • DNS Stuff is a useful site for testing your DNS server & configuration.
    • client
• Remote access
  • Basic steps to secure ssh
• Firewall
  Shoreline Firewall is a policy-based firewall that provides great flexibility and does not require the manual construction of iptables commands.
• Time synchronisation: NTP
• Intrusion detection/prevention
• Virus scanning
• Spam filtering
• Email
  • server
  • client

Notes on specific packages Packages that will be needed on most systems that are possibly not installed on some distributions:

• acct (a.k.a. psacct) - Process accounting (logs CPU/disk/memory usage of particular processes).
• chkrootkit - intrusion detection
• clamav - virus scanner
• findutils-locate - locate files on the system
• ethereal - protocol analyser
• ltrace - library call trace (ltrace-32bit also for 64-bit systems)
• net-snmp - allows monitoring of various aspects of the system
• nmap - network diagnostics tool
• ntp (a.k.a. xntp) - Network Time Protocol. This package ensures that the system's clock is kept in sync.
• rcs - revision control system
• rsync
• sensors (a.k.a. lm-sensors) - motherboard health monitoring
• snort - Intrusion detection system
• strace - system call trace
• sysstat - Collects system performance statistics that can be viewed later with sar or isag.

Other packages you might want:

• aide - intrusion detection
• amanda - backup
• bind - DNS server
• iptraf - IP traffic monitor
• linux-iscsi/open-iscsi - for network storage via iSCSI
• multipath d - disk load balancing & failover
• rsnapshot - rsync-based backup tool that saves time and disk space
• webalizer - gather web server statistics from logs
• xpdf - For reading system documentation in PDF.

Notes on specific packages that are usually installed by default:

• logrotate

Troubleshooting
The best ever NTP documentation can be found at Sun blueprints in three parts:

• http://www.sun.com/blueprints/0701/NTP.pdf
• http://www.sun.com/blueprints/0801/NTPpt2.pdf
• http://www.sun.com/blueprints/0901/NTPpt3.pdf

Most NTP documentation that i have read from OS vendors is misleading, or even wrong. Sun's documentation is written by folks who really know NTP, and it shows! If you read nothing else about NTP, read the diagram and associated explanation on page 9 of part 3 above.

Initial configuration

• For Internet-connected hosts, following is a workable sample /etc/ntp.conf . Your distribution may have slightly different settings for the first few entries already. Many major distributions ship with a reasonable default configuration nowadays, and you should not change them unless there is good reason, as they may break some of the management tools.

driftfile /etc/ntp/drift
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10 13 # mark it as non-preferred
authenticate no

server 0.YOURREGION.pool.ntp.org maxpoll 16 iburst
server 1.YOURREGION.pool.ntp.org maxpoll 16 iburst
server 2.YOURREGION.pool.ntp.org maxpoll 16 iburst
#peer (add local hosts as peers where appropriate)

Debian GNU/Linux is the premiere (only viable?) community-driven Linux project (i.e. that is not managed or sponsored by any company). It has a reputation for rock-solid stability (sometimes at the expense of lagging behind on major versions of new software), a massive software library, and best-in-breed software management tools. It is the basis of a number of distributions, including Ubuntu .

I use Debian stable (etch) as my primary workstation and server platform, and use VMware Server to access other operating systems that i need. recommend it as the first choice for Linux server tasks.

Sysstat is the package to enable collection of system statistics. The main command used to view these is sar (system activity reporter).

Debian On Debian , the following must be done to enable sysstat:

1. Set ENABLED="true" in /etc/default/sysstat
2. Set HISTORY=nn in /etc/sysstat/config , where nn is the number of days for which to keep statistics. I recommend setting it to the maximum of 28.

NOTE
This material is now somewhat obsolete, and more up-to-date information can be found in the pages General Debian installation notes and Generic Linux installation procedure .

Background
This page is what i'm using to document building a file/print/proxy server for a small nonprofit office. The server's DNS name (or IP address before DNS is set up) is shown below as SERVER, and the domain name is shown as YOUR.DOMAIN.NAME.

See also General Debian installation notes .

Network design
Here's a diagram of the network setup used in this example (drawn with dia ):

This document details the installation of the file/proxy/firewall server.

Software
For this project i'm using Debian 3.1 (sarge) which is the current stable release of Debian. The main advantages of using Debian are:

• stable in both reliability and level of churn
• uses only free software in the base operating system

Hardware
The hardware used for this project was:

• AMD Sempron 2200
• ASUS A7V400-MX motherboard
• 512M PC2100 Kingmax DDR RAM
• 2 x Western Digital Caviar 200G 7200rpm HDD

Installation

• Boot from Debian sarge netinst CD
• Configure disks as follows:
  • 2 disks - both masters on their controllers (assuming ATA)
  • 1 Gb ext3 /boot RAID1
  • The rest of the disks as a single RAID1 partition given to LVM
  • Create a volume group called vg00
  • Create logical volumes:
    • 4 Gb swap
    • 3 Gb reiserfs /
    • 8 Gb reiserfs /var
    • any additional space should be allocated to appropriate data volumes like /home
• When you install the system, don't choose any software sets.

Software selection
After the system boots, install a workable minimal system:

• Add non-free to the end of each deb repository line in /etc/apt/sources.list - this enables lha and unrar (see below) to be installed.
• apt-get update && apt-get dist-upgrade
• apt-get remove --purge nano nvi
• apt-get install acct apt-show-versions arj bc bind9-host bzip2 chkrootkit clamav cvs debian-keyring deborphan debsums ftp gnupg hddtemp isag less lha lsof ltrace make mdadm ntp ntp-server ntpdate pciutils postfix powermgmt-base psmisc rcs rsync smartmontools ssh strace sysstat sysvconfig time traceroute unrar unzip unzoo vim wget whois xpdf zip

?? lsb uudeview

• Other possible package sets to install:
  • administration: apt-get install webmin
  • CD burning: apt-get install cdrecord mkisofs
  • database server: apt-get install postgresql or apt-get install mysql
  • DHCP server: apt-get install dhcp webmin-dhcpd
  • DNS server: apt-get install bind9
  • firewall: apt-get install aide ethereal logwatch oinkmaster shorewall snort tethereal tripwire webmin-snort
  • dynamic IP server: apt-get install ddclient
  • monitoring: apt-get install mrtg snmp snmpd
  • printing: apt-get install cupsys magicfilter printconf
  • proxy server: apt-get install dansguardian sarg squid squidguard webmin-sarg webmin-squid
  • web browsing: apt-get install mozilla

apt setup
Sometimes, you need to get more recent software than is provided by Debian stable. Here's a sample apt preferences file which will allow us to pull in packages from testing or unstable without ever allowing them to become the default. You can read more about this at http://www.argon.org/%7Eroderick/apt-pinning.html .

Security setup

• Add your public key (~/.ssh/id_dsa.pub) to SERVER:~root/.ssh/authorized_keys2
• Disable password authentication and PAM in /etc/ssh/sshd_config; restart ssh (service ssh restart)

Network setup

• Set up webmin on http://SERVER:10000/ - turn on SSL redirection
• Set up DNS using webmin. Add a YOUR.DOMAIN.NAME zone and a reverse lookup zone for your chosen IP address range. (In my case i've used 192.168.0.0/24 for my DMZ (see below) and 192.168.1.0/24 for my LAN.)
• Set up DHCP using webmin:
  • I recommend using static addresses for all client PCs - this requires gathering and maintaining MAC addresses, but if the network is relatively stable, it is well worth the effort, as it simplifies troubleshooting enormously. Or, to put it more strongly, dynamic addressing should only be used if you have more clients than IP addresses. It is useful for dialup ISPs and not much else.
  • Use a nice long lease time (i use 40 days), so that if you have a problem with your DHCP server, at least network access is still available to the clients.
  • Set the following client options for the subnet:
    • subnet mask
    • domain name
    • NTP servers - use SERVER's internal IP address
    • default gateway (router) - use SERVER's internal IP address
    • DNS servers - use SERVER's internal IP address
    • log server - use SERVER's internal IP address. The main reason for this is that HP JetDirect print servers use it to send syslog messages to the server, which helps with troubleshooting.

Firewall

• Shorewall is the only packet filtering configuration utility i recommend. See PPPPPPS for some quick tips.

Proxy server

• Set up an apache2 virtual host for serving local LAN functions - here's a sample virtual host config
• Add /var/www/wpad.dat - here's a sample wpad.dat . This is used to let web browsers (those which support it - Mozilla is a notable exception) automatically find and use your proxy server.
• Modifications to /etc/squid/squid.conf (here's a squid.conf patch to do all of the following steps):
  • Uncomment and adjust the cache_dir line - i usually start with a 1000 Mb cache
  • Add Safe_ports and SSL_ports entries for webmin and usermin.
  • Add appropriate ACLs to allow access for DMZ NIC and the local LAN.
• Configure Dan's Guardian. All of these are matters of judgement and your requirements may be different. The main thing we're trying to achieve here is stopping PCs that are open to public access from being used to display porn. Make the following changes to files in /etc/dansguardian:
  • Comment out "UNCONFIGURED" line in dansguardian.conf
  • Change accessdeniedaddress to use SERVER address in the URL (also in dansguardian.conf)
  • Change naughtynesslimit in dansguardianf1.conf to your preferred level - i usually start it somewhere around 120 and adjust as necessary.
  • Remove the contents of bannedextensionlist - all this will do is get in the way of legitimate browsing.
  • Set ICRAchat = 1 in pics

Monitoring
When you're troubleshooting a problem, it's essential to know how your systems are performing in various aspects.

• sysstat: Enable it in /etc/default/sysstat and run service sysstat restart
• snmp:
  echo "rocommunity public SERVER_INTERNAL_IP" > /etc/snmp/snmpd.conf
  This gives us a simple setup that allows use by the local system. Then run
  • service snmpd restart

• to activate the new configuration.

• mrtg: Run the following commands:

cd /etc
rm -f mrtg.cfg
mkdir mrtg
ln -s mrtg/mrtg.cfg .
cd mrtg
vi Makefile
make
Create /etc/mrtg/Makefile from the sample mrtg makefile . Running make will access the SNMP daemon on SERVER and create an mrtg configuration.

Other miscellaneous changes

• /etc/crontab : If you're an early riser like me, you don't want the cron.daily, .weekly, and .monthly jobs running while you're working on the system. I move them back from after 6 am to 1, 2, & 3 am respectively.

Setup procedure

1. Set up the repository
   mkdir -p /srv/svn/localhost
   svnadmin create /srv/svn/localhost
2. Check out a working copy
   cd /tmp
   svn co file:///srv/svn/localhost
3. Make the root filesystem the working copy
   mv localhost/.svn /
4. Now make /etc/ a working copy
   cd /
   svn add -N etc
   svn ci -mcheckpoint
5. Add directories in /etc/ as appropriate.

Debian notes Here's a list of common subdirectories of /etc that should be kept in svn:
svn add \
aliases apt cron* default environment fstab group gshadow host* \
inetd.conf init.d initramfs-tools inittab kernel-img.conf \
localtime logrotate.* logwatch mailname modprobe.d modules motd.tail \
network nsswitch.conf pam.d passwd popularity-contest.conf postfix \
profile rc.local resolv.conf resolvconf services shadow shells ssh \
sysctl.conf syslog.conf sysstat X11
Regular jobs You can keep a history of all these files by simply putting the following in /etc/cron.daily/00-checkpoint-configuration :
#!/bin/sh
cd /etc
svn -q ci -m'Daily checkpoint' Note that this will not automatically add new files to subversion. If you want to be sure that this is done, it is best to simply add /etc/ in its entirety to svn by omitting the -N in the svn add above, then add svn stat to the above script to find out which files and directories have not been added when they are created.

Table of Contents Introduction Table Notes
Introduction Unix-based operating systems (including Linux, on which this page is focused) use a very flexible scheme of block devices to achieve useful and interesting combinations of functionality depending on the desired characteristics of the system. Having a pictorial understanding of these layers can help a lot in troubleshooting and creating procedures - this is shown in the table below.

Table Layer
Example 1
2
3
4
5
Display command
Expand command
scenario
Boot filesystem on a typical server with software RAID 1
root filesystem on a server with software RAID 1 and LVM
SATA DVD-RW drive on my laptop
Boot filesystem on my laptop
Root filesystem on my laptop (encrypted LVM)


mount point
/boot
/
/media/cdrom
/boot
/
df; mount
resize2fs -p (note 1)
(filesystem type)
(ext3)
(ext3)
(iso9660/udf)
(ext3)
(ext3)


LVM LV

/dev/vg00/lv_root


/dev/vg00/lv_root
vgdisplay -v
lvextend
LVM PV
(note 2)

/dev/md1


/dev/mapper/sda5_crypt
vgdisplay -v
pvresize
encryption




/dev/mapper/sda5_crypt
cryptsetup status

RAID
/dev/md0
/dev/md1



mdadm --query --detail
mdadm --grow --size=max
partition
/dev/hda1
/dev/hdc2

/dev/sda1
/dev/sda5
fdisk -l
fdisk
physical
/dev/hda
/dev/hdc
/dev/scd0
/dev/sda
/dev/sda
hdparm -I
lsscsi


Notes

1. fsck.ext3 -f may be required prior to a resize, in which case the filesystem must be unmounted. If it is the root filesystem, then the system must be booted from other media such as a rescue CD or USB hard disk in order to do this.
2. LVM PVs always have the same name as their underlying block device. The LVM information is stored in a header at the front of this device.
3. Filesystem operations such as fsck and mount use the underlying block device name (e.g. fsck /dev/md0 or mount /dev/vg00/lv_home /home ). One exception to this is online resizes and filesystems defined in /etc/fstab , which may also use the mount point (e.g. mount /var , resize2fs /home ).

Table of Contents Network UPS Tools Basic setup UPS monitoring machine (master) UPS client machines (slaves) UPS monitoring web interface Non-default shutdown Network UPS Tools
This documentation was compiled from a CentOS 5 system using RHEL NUT packages. (For some reason CentOS doesn't supply NUT.) The UPS used was an APC SmartUPS 1400 XL connected via serial port, and it is called "apcsmart" in ups.conf (here the name appears as UPSNAME).

Basic setup A good place to start is NUT's documentation

UPS monitoring machine (master) (i.e. The one actually connected to the UPS via serial, USB, etc.)

1. Install the "nut" and "nut-client" RPMs.
2. Add a driver to ups.conf . (All configuration files are in /etc/ups on CentOS / RHEL and /etc/nut on Debian ). For our case it's:
   [UPSNAME]
   driver = apcsmart
   port = /dev/ttyS0
   desc = "APC SmartUPS 1400XL"
   sdtype = 0
3. Run upsdrvctl start to run the UPS driver.
4. To allow upsd to start correctly, add the following to upsd.users :
   [monmaster]
   password = PASSWORD
   allowfrom = localhost
   upsmon master
5. Then add the following to upsmon.conf :
   MONITOR UPSNAME@localhost 1 monmaster PASSWORD master
   This allows the local system to monitor the UPS power and shut down when appropriate.
6. Now the ups service should start: service ups start
7. Run upsc UPSNAME to see full status for the UPS. This often includes the model, serial number, and input & output voltages (but this is UPS-dependent).
8. The UPS is normally configured to allow localhost connections by default. If you have other machines running from this UPS, they need to access our upsd remotely, so you'll need to edit upsd.conf to allow additional hosts:
   ACL myserver 192.168.1.1/32
   ACCEPT myserver

UPS client machines (slaves) This section is applicable to all the systems actually connected to the UPS output, not just the one controlling it.

• On the master:
  1. Add an ACL for the slaves to upsd.conf :
     ACL slaves 192.168.2.0/24
     ACCEPT slaves
  2. Add a username/password entry for the slaves to upsd.users :
     [monslave]
     password = SLAVEPASSWORD
     allowfrom = slaves
     upsmon slave
• On each slave:
  1. Install the "nut-client" RPM
  2. Add the following to upsmon.conf :
     MONITOR UPSNAME@REMOTEHOST 1 monslave SLAVEPASSWORD slave

UPS monitoring web interface This only needs to be done once for each machine you wish to be a web server for the UPS systems. Sometimes you'll want one per UPS (e.g. if you're managing a lot of remote, unconnected clients), but mostly you'll want one system which monitors all the UPSes in your organisation.

1. Install the "nut-cgi" RPM.
2. You may need to add nut.conf to your Apache installation's conf.d/ . Here is a possible template (you'll need to check the exact values against your NUT package):
   ScriptAlias /nut "/var/www/nut-cgi-bin"
   
   
   AllowOverride None
   Options None
   Order allow,deny
   Allow from all
   Allow from 127.0.0.1
   
3. If you haven't already, add the cgi system to upsd.conf on all systems that need to be monitored as per the last part of the master section above.
4. On the web server itself, add each host to hosts.conf as follows:
   MONITOR UPSNAME@REMOTEHOST "UPS description"

Non-default shutdown By default, NUT only shuts down systems when there are two minutes of battery life remaining. Many machines (especially those hosting virtual machines) take longer than this to shut down, and i feel that this is not enough margin for battery life mis-estimates. Unfortunately, there doesn't seem to be an easy way to just adjust NUT to shut down with a different interval, like 5 or 7 minutes.

The solution to this is to use NUT's "upssched" support, which allows timed shutdown from the beginning of the battery run time instead of the end. To set up upssched, make these modifications on the master:

1. In upsmon.conf :
   # Tell NUT to use upssched:
   # (This command might live somewhere else on your system.)
   NOTIFYCMD /usr/sbin/upssched
   
   # Make sure NUT calls upssched at all the right points:
   NOTIFYFLAG ONLINE SYSLOG+EXEC
   NOTIFYFLAG ONBATT SYSLOG+EXEC
   NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC
2. In upssched.conf :
   # Define your custom command script:
   CMDSCRIPT /usr/local/bin/upssched-cmd
   
   # Make sure upssched can communicate with with any running instances:
   PIPEFN /var/run/upssched/upssched.pipe
   LOCKFN /var/run/upssched/upssched.lock
   
   # When we lose mains power, start a two minute timer:
   AT ONBATT * START-TIMER onbattwarn 120
   
   # when we return to mains power, stop the timer:
   AT ONLINE * CANCEL-TIMER onbattwarn
3. mkdir /var/run/upssched
   chown nut:nut /var/run/upssched
4. Then add the following as /usr/local/bin/upssched-cmd (there is usually a template in /usr/bin/upssched-cmd ):
   #! /bin/sh
   #
   # This script should be called by upssched via the CMDSCRIPT directive.
   # ...
   # The first argument passed to your CMDSCRIPT is the name of the timer
   # from your AT lines.
   #
   # In the configuration described here, this script is only called when
   # the onbattwarn timer expires (i.e. if mains power has been gone for
   # two minutes).
   #
   
   case $1 in
   upsgone)
   logger -t upssched-cmd "The UPS has been gone for a while"
   ;;
   onbattwarn)
   logger -t upssched-cmd "Shutting down using: upsmon -c fsd"
   upsmon -c fsd
   ;;
   *)
   logger -t upssched-cmd "Unrecognized command: $1"
   ;;
   esac

A file system is the pattern or structure of data as it resides on a disk. Normally, file systems can live in one of a few places:

• on an ATA, SATA, or SCSI disk partition (typically named /dev/sda1 or /dev/hdc2 or similar)
• on a RAID device (typically named /dev/md0 or similar)
• on an LVM Logical Volume (LV) (typically named /dev/vg00/lv01 or similar)
• on a raw device (typically named /dev/sda or similar) - this usually only occurs when the device is on a hardware RAID controller, or an off-board disk array.

(Many of these disk devices can appear under the /dev/disk/ hierarchy as /dev/disk/by-id/* or /dev/disk/by-label/* or various other methods.)

When you resize any of these underlying devices, you also need to resize the file system on them, using the appropriate utility for that filesystem, like resize2fs , resize_reiserfs , or xfs_growfs .

1. Home
2. A quick thanks to Wikispaces
3. About this wiki

[[rss url="http://pipes.yahoo.com/pipes/pipe.run?_id=eGrA_34O3RGvHvhmLO2fWQ&_render=rss" title="Recent changes" title="Latest pages" number="25"]]

This page describes how i built an appropriate NUT 2.2.2 RPM for CentOS 5.

1. Get sources:
   wget http://www.networkupstools.org/source/2.2/nut-2.2.2.tar.gz \
   http://www.networkupstools.org/source/2.2/nut-2.2.2.tar.gz.sig \
   http://www.networkupstools.org/source/nut-key.gpg \
   http://download.fedora.redhat.com/pub/epel/5/SRPMS/nut-2.2.0-5.1.el5.src.rpm
2. Verify sources:
   gpg --import nut-key.gpg
   gpg nut-2.2.2.tar.gz.sig
3. Set up development:
   rpm -ivh nut-2.2.0-5.1.el5.src.rpm
   mv nut-2.2.2.tar.gz /usr/src/redhat/SOURCES
   cd /usr/src/redhat/SOURCES
4. Edit the package specification to ensure it matches. Change versions as necessary.
5. Now comes the trickiest part: we must ensure that the patches in the previous version apply cleanly to the current version.
   1. Extract the source twice:
      tar -xzvf nut-2.2.2.tar.gz
      mv nut-2.2.2 nut-2.2.2-orig
      tar -xzvf nut-2.2.2.tar.gz
   2. Apply the patches to the new version:
      cd nut-2.2.2
      patch -p1 > ../nut-SOME-PATCH-NAME.patch < ../nut-SOME-PATCH-NAME.patch
      # this will likely result in errors
      There's no way to explain what needs to happen here in a generic way. Sometimes a file might still need patching, sometimes the patch will no longer be necessary because the code has changed, sometimes the patch might need applying to a different file. Unless you know a little bit about a lot of different Linux languages and development tools, this will be very hit and miss. In the event that you don't know what to do with the patch, the best thing to do would be to post on the mailing list for the original product (in this case, NUT), explain what you're doing, and show the errors. In the case of updating this NUT 2.2.0 RPM to 2.2.2, i found two patches were still needed:
      • nut-2.2.0-conf.patch
      • nut-2.2.0-multilib.patch
   3. Recreate the patches:
      cd ..
      diff -u nut-2.2.2-orig/conf nut-2.2.2/conf > > nut-2.2.2-conf.patch
      diff -u nut-2.2.2-orig/lib nut-2.2.2/lib > > nut-2.2.2-lib.patch
   4. Edit the spec file to correct the patch references. Here's a file showing the things i changed:  nut.spec.patch . (This is the finalised version, including the patch i added below.)
6. Build the new package:
   rpmbuild -ba SPEC/nut.spec
   You may still get errors at this point. I found the following in this case:
   • The neon-devel package must be installed in order to build the HTTP server portion of NUT.
   • The executable would not link due to a missing symbol: g_timeout_add_seconds . I found through some web searches that this was due to the function not being present in the CentOS 5 version of glibc, so i created my own patch to fix it:  nut.drivers.patch . I added this patch to the spec file and rebuilt.
   • The spec file used /sbin as the directory for the specific models of UPS, whereas the Makefile seemed to use /usr/lib/nut . This required changing modeldir to the correct value.
   • The file upsconfig-client is no longer created by the Makefile. This may be an error in my patch application, but because i don't care about the nut-devel RPM, i just commented it out.
   • Three files were added that were not included in the spec file:
     • /etc/hotplug/usb/libhid.usermap
     • /etc/hotplug/usb/libhidups
     • /usr/share/man/man8/netxml-ups.8.gz

• Resolving errors in this process is a pain, because every change requires a complete rebuild. No wonder i don't program in C any more! :-)

Introduction Linux virtualization (or virtualisation, if you prefer) is a murky area at the moment. There are a lot of products competing for the market, and their feature mix is a little confusing. Only solutions that are available for zero cost and provide near-native performance are considered here.
Summary Product Unmodified host kernel Unmodified guest kernels Pros Cons OpenVZ, VServer
No
No
- Best performance
- Minimal overhead per additional VM
- Guests must run the same OS as the host
VMware Server, VirtualBox
No
Yes
- Good tools for managing guests
- Non-free license (VMware only)
- Requires driver recompile every time host or guest kernel updated
Xen
No
Yes with VT/SVM, no otherwise.

- No support for third-party drivers in host (incl. various 3D graphics cards like NVIDIA)
KVM
Yes
Yes (requires VT/SVM)
- Built into Linux kernel
- A little flaky still (works OK on OpenSUSE 10.3)
- Requires more memory per VM than Xen
- Requires an X11 console window?
Bottom line

• For desktops or laptops which require X11 support and multiple guest OSes, there's not really much option but to use VMware or VirtualBox.
• For servers which must support multiple guest OSes, Xen seems the best choice at the moment, although KVM may be catching up rapidly.
• KVM is a project to watch closely.

References

• http://en.wikipedia.org/wiki/Comparison_of_virtual_machines
• http://www.shorewall.net/Linuxfest-2008.pdf
• http://virt.kernelnewbies.org/TechComparison

Xen is a virtualization solution that allows the use of either paravirtualization (slightly modified guest OSes) or full virtualization (hardware-supported virtualization with no guest OS modifications).

Linux VServer is a virtualization solution for Linux that comes pre-built for Debian and allows creating of multiple virtual servers with very low overhead, and within the same file system on the server.

Basic VServer on Debian See General Debian installation notes for a list of non-default packages to add to VServers.

OTRS Here are the packages i added to get an OTRS 2.0.4p01-18 installation working:

• libdbd-pg-perl
• libxml-parser-perl
• otrs2
• postgresql-client

(This was using a PostgreSQL 7.4 server on another system.)

Some LDAP admin tools

• http://phpldapadmin.sourceforge.net/
• http://sourceforge.net/projects/ldap-abook
• http://www.yolinux.com/TUTORIALS/LinuxTutorialaWebDap.html
• http://sourceforge.net/projects/labe/

Other

• http://www.claros.org/web/home.do

(This is another one of those "so i don't have to remember it" pages.)
Authentication & filtering

• http://surftrackr.org/blog/view/40/screenshots-how-use-surftrackr/
• http://squidguard.org/
• http://www.mcmilk.de/projects/squidwall/
• http://www.papercut.com/kb/Main/ConfiguringSquidProxyToAuthenticateWithActiveDirectory
• http://www.ledge.co.za/software/squint/squish/

Logging & graphing

• http://www.itefix.no/phpws/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=21&MMN_position=21:21
• http://cord.de/tools/squid/calamaris/
• http://yaala.org/
• http://sourceforge.net/project/showfiles.php?group_id=178128
• http://sarg.sourceforge.net/sarg.php
• http://giannis.stoilis.gr/software/mysar/
• http://squid-graph.sourceforge.net/files/stable/

Miscellany

• http://www.khelekore.org/rabbit/

This page explains the steps for replacing a failed drive in a software RAID set with a new one. In this example, /dev/hdc is the good drive, and /dev/hda is the replacement for the failed drive.

1. Gather initial information to make sure you understand your existing disk layout:
   cat /proc/mdstat
   fdisk -l /dev/hdc
   swapon -s
   df
   vgdisplay -v # if applicable Make special note of the heads, sectors, cylinders, block counts, and partition types in fdisk . These instructions are the same regardless of whether LVM is used on the RAID set or not.
2. Set up partitions on the new drive using fdisk :
   fdisk /dev/hda
   1. Check that the total number of bytes is greater than or equal to the other drive in the mirror. If it is not, you must find a larger drive. Different models of the same sized drive from the same manufacturer can be a few KB different in size, and if your new drive smaller than your other drive in the RAID 1 set, you will not be able to use it.
   2. If the drives are different in geometry, change the geometry of the new drive to match the old one using fdisk expert mode. Usually the number of sectors will be the same, and only the heads and cylinders will be different. Even if the new drive is larger than the old one, you may still be able to change it to match (i have not tested this).
   3. Create the new partitions:
      n # new partition
      p # type primary
      1 # partition number 1
      xxx # must match the starting cylinder of the same partition on the old drive
      yyy # must match the ending cylinder of the same partition on the old drive
   4. Set the type of each partition to FD (Linux RAID autodetect)
   5. Set the partition which contains /boot (usually partition 1) active
3. Remirror each partition (assumes 2 RAID devices on successive partitions of /dev/hda ):
   mdadm --add /dev/md0 /dev/hda1
   mdadm --add /dev/md1 /dev/hda2
4. Recreate the boot sector: see GRUB cheat sheet