Practical Internet Server Configuration

Remarks for teachers

Obviously, every teacher has his or her own style of teaching, and it is by no means my intention to leave my mark on this. Nevertheless, here are a few tips that I think can contribute to the effective training of beginning and future system administrators. Feel free to integrate them as you please.

• Software updates
  
  It is advisable to start each lesson (or each school day) with an update of the installed software. Windows administrators tend to wait for the system to initiate this; in the Unix world it works the other way around: the system waits for the administrator to initiate updates. Making sure the installed software is up to date is one of the most important tasks the system administrator has, and it's important that the (future) system administrator adopts the habit of regularly checking for updates.
  
  FreeBSD

  # freebsd-update fetch
  # freebsd-update install
  # portsnap fetch update
  # portmaster -ya
  # pkg autoremove
  

  
  Debian

  # apt update
  # apt dist-upgrade
  # apt-get autoremove
  

  
  CentOS

  # yum update
  # yum autoremove
  

  
  Obviously, this is useful only after the management of software has been treated.
• Bad habits
  
  Once bad habits have been adopted, it is difficult to unlearn them again. It is therefore important to not adopt them at all.
  These are the most important pitfalls to avoid:
  • Reboot
    In class (and at home) the server is often restarted too easily. Clearly, this is an effective way of assuring that all services are restarted and all configuration files are reloaded. However, if the future system administrator does this at their first job, it might well be punished with a dismissal, or at least a severe reprimand. After all, a server may serve hundreds of websites, or thousands of email addresses. If such a server is rebooted, all these websites or email addresses will be offline for a few minutes, and after the reboot it must be verified that they have all come back up again; what's more, in the case of a few hundred websites, it is not unthinkable that a few dozen content managers lose their modifications and are required to restart from the beginning.
    
    So:
    • Configuration changed?
      Restart concerned service.
    • Daemon installed or updated?
      (Re)start daemon.
    • Installed or updated other software?
      No action required, or potentially stop and restart running instances.
    • Changed group membership for a user?
      Relogin user.
    • Et cetera.
    The only valid reason for a reboot, apart from hardware trouble, is the installation of a new kernel. And such a reboot is normally planned a few weeks ahead, at a quiet time, and customers are informed and reminded multiple times.
  • Login as root
    If an administrator logs in directly as root, it is impossible to find out which user has used the root account. For a home server, this is not a problem, as it will usually only have a single administrator. But if a team of administrators collectively handles an entire server park, and a problem occurs, it is important to be able to find out who acted as root and when. It is therefore important that the future system administrator is taught from the beginning to use sudo, and never to login directly as root or use su.
    The best way to achieve this, is to install and configure sudo in one of the first lessons, and to configure sshd to reject root logins.
    
    The -E flag for the sudo command ensures that a large part of the user's environment stays intact in the SUDO environment:

    $ whoami
    rob
    $ sudo -E bash
    # env
    USER=root
    LOGNAME=root
    SUDO_USER=rob
    HOME=/home/rob
    MAIL=/var/mail/rob
    PATH=/home/rob/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
    …
    

    This also means that the user still uses his or her own .bashrc, .vimrc, etc.
• Upper case and lower case
  
  Unix systems are largely case sensitive. To avoid confusion about this, the convention is to use lower case letters for user and file names, unless there is a compelling reason to do it differently. Even though the DNS is not case sensitive, lower case is also normally used for host and domain names.
• /etc/passwd and /etc/group
  
  Several commands exist for the manipulation of user and group data. The administrator who still wants to edit the files /etc/passwd and /etc/group directly, should not use a regular text editor, but instead respectively the commands vipw and vigr. These commands verify the syntax of the concerned files before saving them, and assure that the shadow password files remain synchronized.
  
  If the variable EDITOR has been defined in ~/.bashrc, these commands use this editor; otherwise, vim is used.

  export EDITOR=nano
  

• Vim
  
  The vim text editor is not treated in this book; on the one hand, it's a rather complex subject, and on the other hand, the use of vim is learned largely by experience. However, no system administrator will be able to avoid running into vim sooner or later. It is therefore advisable to plan half a day to get acquainted with vim at a certain moment. This prevents the administrator from feeling lost when he or she finds an internship or a job with a company where the use of nano is looked down upon.
  
  A good moment for this introduction might be after the first chapter about the web server. This is where the level of information changes to advanced, and the administrator should now feel sufficiently at ease with the command line and text files.
• Theme for hostnames
  
  Just like hostnames are easier to retain than IP addresses, hostnames with a meaning are easier to retain than random ones. This is why system administrators often pick a theme for the hostnames in the zone that is assigned to them. Obviously, the administrator is free in the choice of the theme, but inspirations could be characters from comics, books, movies or tv series; plant or animal species (peach.example.com, mango.example.com; shepherd.example.com, poodle.example.com); musical instruments; etc. It's not only fun, but also useful to make students think about this: it stimulates the creation of a 'bond' between the system administrator and his or her network.
  It is important to select a theme that can provide enough names to allow the network to grow.