Debian (here 4.0 called Etch)

Index

• General
• MAN (All the information you need)
• Debian in a Virtual Machine
• APT / APTITUDE (Keeping your installation up-to-date)
• CRON / ANACRON
• SSH
• User in chroot jail (for SSH, su, direct login, etc.)
• NTP (Set time/date over the Internet)
• IPTables (Firewall)
• Resolv (Local Domain Names)
• Automatic password generation
• WebMin
• Webserver Apache 2 with SSL
• ProFTPd / SSL
• Teamspeak
• Subversion -plus- How to add a Daemon to the SysVInit system
• Other packages
• Wake-On-LAN / Wake-On-PCI (PME)
• ShutDown On Idle

General

• All Debian releases have names, and there is always an upcoming release called "testing" and the generation after this is called "unstable".
  The information here are for Debian 4.0 called Etch, but should also mostly apply to older versions like 3.1 Sarge, 3.0 Woody or newer versions like 4.1 Lenny/Sid.
• Debian Homepage and Install Manual (4.0 "Etch")
• Deutsches Debian Anwenderhandbuch
• Deutsche Debian HowTos and Deutsches Debian Forum
• Deutsches Linux Wiki
• The Linux Documentation Project
• The Perfect Setup on HowTo Forge
• German OpenBooks from Galileo Computing, especially the Linux book is a good introduction for newbies.
• "Graphical" Editor is nano, call: nano <filename>
• Display system load: top
• Services of the SysVInit system are controlled via invoke-rc.d (see man invoke-rc.d and here).
  To check if a service is running use: ps xa -f | grep <servicename>
• Switching consoles: ALT + Fn
• Finding pathes of a command: whereis <command>
• The language for the system is defined in /etc/default/locale, but you can also define another language in your profile at ~/.profile by setting the environment variable like this LANG="en_US.UTF-8", LANG="en_GB.UTF-8" or LANG="de_DE.UTF-8"
  If a locale is missing, then have a look at the man pages of locale-gen and read here.
• To reconfigure the keyboard settings just use dpkg-reconfigure console-data → "Select keymap from arch list" (here arch means PC, Amiga, Mac, etc.). Info found here.

MAN (All the information you need)

• The manuals for all the tools of Debian/Linux are organised in pages, called man pages.
  The command man will display these pages, to find out more about it call man man.
• Sometimes you will find the following notation: something(8).
  The value in parenthesis is the section. Sometimes there can be several man pages with the same name, but in different sections (e.g. crontab in 1 and 5).
  To see the man page of a specific section use man section something.

Debian in a Virtual Machine

• When cloning a Debian machine, the new MAC addresses cause problems as they are assigned to a new interface, e.g. eth1 instead of eth0.
  This happens as Debian stores the interface assignments for each network card. See Debian bug #431190 and VirtualBox ticket #660.

APT / APTITUDE (Keeping your installation up-to-date)

• APT is the package manager to install, remove or update/upgrade your debian packages. See man pages for apt, apt-get and sources.list.
• Recommendation: Use aptitude instead of apt for your package handling.
  It keeps track of automatically installed packages along with the explicitly stated ones, so it can also remove these when you deinstall the explicitly installed ones.
  The Debian maintainer's recommend it, because of its more smart decisions especially when updating to a new release.
• To update your packages to the latest version, first update the package list, then upgrade:
  

  aptitude update aptitude upgrade

• As you should regulary update your packages, it would be great if most of these tasks were done automatically.
  There is already a daily cron job in Debian ("/etc/cron.daily/apt") which updates the package list and downloads the latest packages according to your APT configuration.
  Use "apt-config dump" to see your complete APT config.
  It is wise to define the default release for APT too, so you do not accidentally upgrade to a new release.
  Define additional values for the cron job in "/etc/apt/apt.conf" like this: (see man apt.conf and here)
  

  APT { Default-Release "etch"; // Options for /etc/cron.daily/apt Periodic { // same as defining APT::Periodic::xyz Update-Package-Lists 1 ; Download-Upgradeable-Packages 1 ; Autoclean 1 ; }; };

  This will daily clean up your package cache, update your package list and download the latest packages. You still have to do the upgrade yourself, but all packages are already downloaded avoiding to wait for the downloads to finish.
  It is not recommended to do the upgrade itself automatically. This way you would not see important hints or questions asked.
  To test the new configuration just execute "/etc/cron.daily/apt" (or start all daily cron jobs via "run-parts --report /etc/cron.daily").
  The time stamp files for the APT tasks can be seen in the directory "/var/lib/apt/periodic".
• If your server is not running all the time, then check out the paragraph about CRON / ANACRON.

CRON / ANACRON

• CRON is a tool that checks every minute, if a scheduled script or program has to be executed. See man pages for cron and crontab(5).
• Unfortunately CRON doesn't care if it missed the schedule for the daily, weekly and/or monthly jobs.
  These jobs are normally scheduled for 6 o'clock in the morning (see "/etc/crontab"). If your computer is not running at these time points, then the cron jobs will not be executed.
• To fix this install the ANACRON package, which is intended to handle daily, weekly and monthly jobs for computers that are not running all the time (see here).
  

  aptitude install anacron

SSH

• OpenSSH Homepage and Debian package homepage.
• Just install the "openssh-server" package:
  

  aptitude install openssh-server

• Configuration locations:
  /etc/ssh/sshd_config (Server)
• Start/Stop:
  invoke-rc.d ssh start|stop|restart
• My german SSH HowTo incl. Putty-Config.
• Setup public authentication.
  Create a .ssh folder in root's home:
  

  mkdir ~/.ssh touch ~/.ssh/authorized_keys chmod go-w ~ ~/.ssh ~/.ssh/authorized_keys

  Then enter all valid public keys for root login into ~/.ssh/authorized_keys.
  Use the same technique for every user you want to login with.
• Then disable password logins and rhosts logins in /etc/ssh/sshd_config:
  

  RSAAuthentication no PasswordAuthentication no

• If a user gets the error "No supported authentication methods available", then check the following:
  
  • Check the corresponding log, which is normally /var/log/auth.log (otherwise look up in /etc/syslog.conf).
    
  • Passwords are disabled and user is not using his (correct) private key for login.
  • Passwords are disabled and user has no ~/.ssh/authorized_keys file or wrong/no pub keys in it.
  • StrictModes is enabled and the user's home and ~/.ssh directory are writable either by group or world. Note that you have to check the user's home directory itself too!!!
    Log message for this is "bad ownership or modes for directory ..."

User in chroot jail (for SSH, su, direct login, etc.)

• A chroot jail locks up a user to a single directory (and its subdirectories), mostly to their own home directory. This is another part in security concepts as the users can not access anything outside of this directory, so they can not effect the system itself.
• If a user is put inside a chroot jail, then they do not have access to the normal programs and files too. Therefore you have to create a new environment inside the jail, with all the necessary files (/etc & co.) and the programs you want to allow the user to use (e.g. ls, cat, echo, etc.).
  Don't forget to create a duplicate of the user's home directory inside the jail too.
• You can put several users into the same jail or have a jail for each user (e.g. their home directory).
• The easiest way to enable chroot jails is to extend PAM with the libpam-chroot package (see Debian manual for chrooting the ssh users):
  

  aptitude install libpam-chroot

  Then enable chroot jails for all direct shells by placing the following line at the end of /etc/pam.d/login, /etc/pam.d/ssh and /etc/pam.d/su. It is also possible to place it only inside /etc/pam.d/common-session, but then this may affect other services and could cause unwanted side effects.
  

  session required pam_chroot.so

  Note: "UsePrivilegeSeparation No" is not necessary for SSH in a recent Debian, works well for me with openssh-server 4.3p2-9.
• The more difficult part is to create a working jail. There are lots of scripts floating around the internet, but there are several good packages inside the Debian repository.
  With the packages debootstrap and cdebootstrap you can create a complete Debian installation inside a directory, which is normally way too much for chroot jail users.
  That's where makejail comes in handy, as it allows to install Debian packages into the jail, can copy single commands with their dependencies and can filter files for the user:
  

  aptitude install makejail

• Now create a config for makejail according to its man page.
  Try to install packages and only state single commands if necessary (e.g. just a single command from a package is needed). If you don't know in which package a command is included, then use dkpg -S /path/to/command (capital S!) to find out. As packages can have dependencies it is recommended to let makejail install these too.
  For a minimum jail you need the packages base-files and base-passwd, the files /etc/passwd and /etc/group plus a shell and the user's home directory.
  For the files /etc/passwd and /etc/group define user/group filters for the jailed users and their primary groups. Always include root into these filters too.
  For the bash shell use the package bash. Bash uses sed for its welcome message, so install the package sed too.
  Another recommended package is coreutils with the most common commands (cat, cp, echo, ls, uname, etc.).
  To provide a "graphical" editor like nano the packages ncurses-base and ncurses-bin are necessary too.
  To allow the jailed user to use WinSCP's edit functionality the command /usr/bin/scp must be inside the jail.
  If the jailed user is maintaining a web site, then maybe /usr/bin/htpasswd is necessary to create web users for the web site.
  A minimum jail configuration file for a user "dumbuser" could look like this:
  

  chroot="/home/jail01" packages=["base-files","base-passwd","bash","sed","coreutils","ncurses-base","ncurses-bin","nano"] useDepends=1 users=["root","dumbuser"] groups=["root","dumbuser"] forceCopy=["/etc/group","/etc/passwd","/home/dumbuser","/usr/bin/scp","/usr/bin/htpasswd"]

  Call makejail with the configuration file to build the jail.
• To complete the jail you have to create the device links inside its dev directory:

  cd /home/jail01/dev MAKEDEV generic

• The proc directory inside the jail is normally not needed, so you can unmount it and even delete it:

  umount /home/jail01/proc rmdir /home/jail01/proc

  If proc is necessary for the jailed users, then add a corresponding mount in /etc/fstab for the next reboot as mentioned by makejail.
• After you set up the jail test it with the chroot command.
• Finally put the user in his jail by adding him to cat /etc/security/chroot.conf with a line like this:
  

  dumbuser /home/jail01

• Don't forget to update the jails from time to time to apply security updates to them.

NTP (Set time/date over the Internet)

• Just install the "ntpdate" package, this will also update the clock every time you connect to the network:
  

  aptitude install ntpdate

• If your clock is going way wrong after some time or your server is running 24/7, then update the clock via a cron job as described in a Linux Reviews' HowTo:
  

  echo 'ntpdate -b <your ptb server>' > /etc/cron.hourly/time.cron chmod a+x /etc/cron.hourly/time.cron

IPTables (Firewall)

• IPTables seems to be the package that always provides two ways to do something.
• Define your firewalls either by running a shell script with multiple iptables commands, or by using iptables-save/restore to save/load configuration files.
  Configuration files are useful when you have fixed rule sets that you want to load/add.
• Start the firewall either by creating a System V init script or a script for the network's pre-up directory.
  An init script is preferable for servers as these normally run in the same configuration for a long time.
  Using scripts in the pre-up directory is more flexible for desktop systems and laptops, as interfaces are opened and closed all the time (e.g. internet connection, VPN).
• If you are looking for the old Debian System V init script, then you can download oldinitdscript.gz here.
  Place it in /etc/init.d/, make it executable and activate it with update-rc.d. Typically "update-rc.d iptables start 45 S . start 31 0 6 ." (=start before/stop after network).
  Infos about init scripts and runlevels are available here. In Etch Networking is S/S40 plus 06/S35, and IfUpDown is S/S39 plus 06/S36.
• Some useful links:
  IPTABLES quick HOWTO by Silviu
  Iptables Tutorial 1.2.2 by Oskar Andreasson
  Basic Iptables - Debian
  Setting up a simple Debian gateway
  
• Typical extract of an iptables configuration for a non-routing server:
  

  *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # Punch holes for... # --> Established connections -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # --> Loopback -A INPUT -i lo -j ACCEPT # --> ICMP -A INPUT -p icmp -j ACCEPT # Punch holes for the following services... # --> SSH -A INPUT -p tcp --dport 22 -j ACCEPT ... more services ... # As we are polite reject all other packets -A INPUT -j REJECT -A FORWARD -j REJECT COMMIT

• To find out almost all open ports on your server:
  

  netstat -tupan

Resolv (Local Domain Names)

• DNS chapter in Debian manual.
• The domains of a computer are maintained /etc/resolv.conf under "search".
• To see the full qualified name of a computer use:
  

  hostname -f

• For a more flexible way of handling domains use the package "resolvconf", where you can define all DNS specfications for each network adapter in /etc/network/interfaces.
  For more information about the package use:
  

  zcat /usr/share/doc/resolvconf/README.gz

Automatic password generation

• I use pwgen (Debian package) to generate passwords.
• To install:
  

  aptitude pwgen

• To use:
  

  pwgen -c -n -y

• If you have problems to remember all your passwords, then use a password tresor like Keepass.

WebMin

• WebMin Homepage
• The author himself provides the WebMin package for Debian to keep it always up-to-date.
  To install with ease, create the file "/root/webmin_install":
  

  #!/bin/sh ## Info taken from http://www.webmin.com/deb.html grep "deb http://download.webmin.com/download/repository sarge contrib" /etc/apt/sources.list >/dev/null || echo "deb http://download.webmin.com/download/repository sarge contrib" >>/etc/apt/sources.list aptitude update aptitude install webmin

  Make it executable via "chmod u+x /root/webmin_install"
  At last execute it via "/root/webmin_install"
• If you want your own configuration instead of the automatic one, then create the file "/root/webmin_reconfigure":
  

  #!/bin/sh ## Use this script if you don't want Webmin's automatic setup and start from scratch /etc/webmin/stop echo "Deleting /etc/webmin..." rm -rf "/etc/webmin" /usr/share/webmin/setup.sh

  Make it executable via "chmod u+x /root/webmin_reconfigure"
  At last execute it via "/root/webmin_reconfigure"
• Configuration locations:
  /etc/webmin/* (Server)
• Start/Stop:
  /etc/webmin/start
  /etc/webmin/stop

Webserver Apache 2 with SSL

• Apache HTTP server manuals and Debian package homepage.
• To install the Apache 2 HTTP server with PHP support, plus OpenSSL with the most common CAs:
  

  aptitude install apache2 php5 openssl ca-certificates

• When doing bigger changes then you have to stop and start Apache as restart doesn't work as expected.
  

  invoke-rc.d apache2 stop invoke-rc.d apache2 start

• Enable the Apache module "mod_ssl" (mod_ssl chapter in Apache manual):
  

  a2enmod ssl

  Similar commands are a2dismod, a2ensite, a2dissite.
  Note: mod_ssl is not the same as Apache-SSL.
• To use SSL in Apache 2 for HTTPS read the mod_ssl docs and the Apache mod_ssl HowTo and FAQ.
  Enable Apache 2 listening on port 443 in /etc/apache2/ports.conf:
  

  grep "^Listen 443$" /etc/apache2/ports.conf >/dev/null || echo "Listen 443" >>/etc/apache2/ports.conf

  Copy your private key and certificate to the corresponding directories in /etc/ssl/ and make sure the private keys are only readable by root:
  

  find /etc/ssl/private/ -type f -exec chmod u=r,go= '{}' \;

  Finally add SSL to your server or virtual host configuration on port 443:
  

  SSLEngine On SSLCertificateFile /etc/ssl/certs/server.crt SSLCertificateKeyFile /etc/ssl/private/server.key

• If your key is certified with an intermediate certificate, then it is recommended to provide a chain file for the clients (or at least the intermediate certificate only).
  Create a file with all certificates of the chain by concatenating all of them, here for CACert.org:
  

  cat /etc/ssl/certs/root.pem /etc/ssl/certs/class3.pem >/etc/ssl/certs/CAcert_chain.pem

  Then add it to your server or virtual host configuration:
  

  SSLCertificateChainFile /etc/ssl/certs/CAcert_chain.pem

• Test configuration before restarting:
  

  apache2 -t

• You can also use certificates to allow only certified users to special URLs, see SSL HowTo Client Access Control.
• Keys and certifcate requests are created with OpenSSL (Debian package homepage), see Apache SSL FAQ about Certificates.
  Create a private key with OpenSSL's genrsa command, for a password-protected key use parameters -des/-des3/-idea:
  

  openssl genrsa -out /etc/ssl/private/server.key 4096

  Create a certificate request with OpenSSL's req command, fill the common name (CN) with your domain name:
  

  openssl req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr

  Create a self-signed certificate from your request with OpenSSL's x509 command for testing or as temporary implementation:
  

  openssl x509 -req -days 3650 -signkey /etc/ssl/private/server.key -in /etc/ssl/private/server.csr -out /etc/ssl/certs/server.crt

• Another useful resource for SSL with Debian is this german SysCP.org wiki aricle (Apache, Courier, Postfix).
• Note that you can use only one SSL certifcate per IP address and port, as the SSL handshake is done before the requested host name is submitted. You can workaround this problem with a multi-domain certificate.
• If you are interessted in multi-domain certificates, then check out the CACert wiki articles CSRGenerator and VhostTaskForce.
• To create multi-domain certificate requests for CACert I copied /etc/ssl/openssl.cnf to /etc/ssl/cacert.cnf. As CACert only keeps the Common Name of these I disabled everything else in the [req_distinguished_name] paragraph except for the email address, then added a line for Subject Alternative Name to the same section:
  

  [ req_distinguished_name ] #countryName = Country Name (2 letter code) ... #organizationalUnitName_default = commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 subjectAltName = Alternative Names (e.g. DNS:www.abc.com)

  Don't forget to add "-config /etc/ssl/cacert.cnf" to your OpenSSL calls.

Setup Tips

• If you use .htpasswd files (or databases) to create protected areas on your web space and want to create/verify them with PHP, Perl & Co., then it is recommended to use SHA encryption for the passwords. It is a standard encryption used by Apache unlike Apache's custom MD5 algorithm, therefore password entries can be accessed by scripts. To create SHA passwords with htpasswd use the "-s" parameter.
• A potential security risk is the option FollowSymLinks, because one of your users could create a symbol link within the DocumentRoot folder to any directory or file (e.g. to .htpasswd), which would expose this vital information to everyone on the internet. Additionally the target of the symbolic link will be handled as if it belongs to the path where the link resides in. Hence any Directory directives for the target are not evaluated. You may try to workaround this with a Location directive, but take care of how the different sections are merged.
  Best is to use the module mod_alias and its Alias directive in conjunction with a fitting Directory directive.
  Here's an example of how you could configure Apache:
  

  # --> Global server configuration ServerSignature EMail ServerTokens Prod <Directory /> # ONLY use FollowSymLinks HERE so everything can be accessed with Alias # But NEVER use FollowSymLinks where a domain user can create symbolic links Options FollowSymLinks MultiViews AllowOverride None Order deny,allow Deny from all ... </Directory> # preparation for Alias /webmail /usr/share/squirrelmail <Directory /usr/share/squirrelmail> ... Order allow,deny Allow from all ... </Directory> # --> Domain configuration <VirtualHost 123.45.678.90:80> ... DocumentRoot /var/www/domain/httpdocs ... <Directory /> # --> Define password and group file for all directories AuthUserFile /var/www/domain/.htpasswd AuthGroupFile /var/www/domain/.htgroup </Directory> <Directory /var/www/domain> Options -FollowSymLinks </Directory> <Directory /var/www/domain/httpdocs> Options MultiViews AllowOverride AuthConfig Options=Indexes Order allow,deny Allow from all </Directory> Alias /webmail /usr/share/squirrelmail <Location /webmail> AuthName "Protected Area" AuthType Basic require user require group Mail SSLRequireSSL </Location> ... </VirtualHost>

ProFTPd

• ProFTPd homepage, Deutsche ProFTPd homepage and Debian package homepage.
  Deutsches ProFTPd Debian HowTo (TLS für 3.1 Sarge funktioniert aber auch mit 4.0 Etch)
  Avoid slow logins
• AllowStoreRestart to allow resuming uploads
• aptitude install proftpd openssl (openssl für TLS)
• /etc/proftpd/*
• invoke-rc.d proftpd restart
• MFMT/MFCT/MFF support on its way, see here.
• Test configuration before restarting:

  proftpd -t /etc/proftpd/proftpd.conf

Teamspeak

• TeamSpeak Homepage
• There's already a TeamSpeak Server package for Debian in development for the next release ("testing" as of 2007-08 called Lenny), which you can easily create for Etch too.
  First create a directory for your self-build packages or packages pre-build by others:

  mkdir /root/packages chown -R root:root /root/packages chmod -R u=rwx,go= /root/packages

  Then create the file "/root/setup_tss2":
  

  #!/bin/sh # TSS2 package homepage at http://packages.qa.debian.org/t/teamspeak-server.html # Prepare access to newer Lenny releases grep '^deb-src http://ftp.debian.org/debian/ lenny non-free$' /etc/apt/sources.list >/dev/null || echo 'deb-src http://ftp.debian.org/debian/ lenny non-free' >>/etc/apt/sources.list aptitude update # Get build-essential (to handle the package sources), then the teamspeak-server package source and its dependencies cd /root/packages gpg --keyserver hkp://pgpkeys.pca.dfn.de --recv-keys C1F24EA4 aptitude install build-essential apt-get -t lenny source teamspeak-server apt-get -t lenny build-dep teamspeak-server # Build the package cd teamspeak-server-2.0.23.19 RC=$? if [ ${RC} -ne 0 ]; then exit 1; fi # dpkg-buildpackage echo The signing error at the end of the "dh_builddeb" step can be ignored. cd .. # Install the package dpkg --install teamspeak-server_2.0.23.19-1_i386.deb aptitude install teamspeak-server # Print out the generated passwords cat /etc/teamspeak-server/passwords

  Make it executable via "chmod u+x /root/setup_tss2"
  Make sure that all prerequisites mentioned in the header are met.
  At last execute it via "/root/setup_tss2".
• Configuration locations:
  /etc/teamspeak-server/* (Server)
  /etc/default/teamspeak-server (Daemon)
• Start/Stop:
  invoke-rc.d teamspeak-server start|stop|restart
• If you want to do everything by hand take a look at TeamSpeak's Linux Tutorial.
  And if you want to start the TeamSpeak server on boot, then read these forum threads A and B. Also have a look at the man pages of "update-rc.d".
  Good luck.
• Firewall ports:
  8767/udp (Server), 14534/tcp (WebGui), 51234/tcp (WebPost)

Subversion -plus- How to add a Daemon to the SysVInit system

• Information about Subversion:
  Subversion homepage and Debian package homepage.
  Book "Version Control with Subversion" (recommended!)
  Presentations of Brian William Fitzpatrick
  Subversion's own repository
  
• GUI clients: pysvn Workbench, RapidSVN
  Windows-only GUI client: TortoiseSVN
• Project revision inside source files: TortoiseSVN's SubWCRev (Download), svnrev
• Just install the "subversion" package:
  

  aptitude install subversion

• Create a directory to hold your repositories. Make sure that all SVN users can read/write this directory, e.g. by creating an extra group for them. And that new files get the same group too. Read Chapters 5 + 6 for more info.
  

  mkdir /var/svn chown -R :svn /var/svn chmod -R ug+ws /var/svn

• To create a Subversion repository in the empty folder use svnadmin. I use su to change the umask temporary for the command:
  

  mkdir /var/svn/TestRepo chown -R :svn /var/svn/TestRepo chmod -R ug+ws /var/svn/TestRepo su -c "umask 002; svnadmin create /var/svn/TestRepo"

  Then edit the files in the "conf" folder of your new repository to fit your needs.
  Now you can already access your repository with svn through a file: URL.
• To share your repositories on the network you can either go with HTTP/WebDAV via Apache or use Subversion's small server called svnserve.
  svnserve normally runs on TCP port 3690 and you can also limit its actions to a special folder (chrooted). Just start it manually:
  

  svnserve --daemon --root=/var/svn/

  Now you can access your repository with svn through svn://<your server>/<repository name>.
• For a repository on the internet it would be better to have encrypted access via SSH. Check out chapter 6 of the Red-Bean online book to setup svn+ssh on the server.
  Also check out my short documentation to setup svn+ssh access on the client side correctly.
• Use hook scripts to check a commit before it goes into the repository or send notification mails after a commit. Hook scripts should reside in /usr/share/subversion/hook-scripts.
  Just install the typical Subversion hook scripts:

  aptitude install subversion-tools

  Don't forget to make the scripts you need executable:
  cd /usr/share/subversion/hook-scripts
  chmod a+x *.py *.pl
• On a LAN it would be easier if svnserve would start on every system start, so read on to add it to Debian's init scripts. Information for adding a daemon to the SysVInit system (=Init System introduced with Unix Version 5, V is a roman number):
  man pages: update-rc.d, invoke-rc.d
  readmes: /usr/share/doc/sysv-rc
  template: /etc/init.d/skeleton
  DebianHelp.org Info
• To add svnserve as a daemon to the SysVInit system copy /etc/init.d/skeleton as /etc/init.d/svnserve.
  Then edit it as following, assuming your repositories are in "/var/svn" and using user "svn" and group "svn" (my changes are in orange):
  

  #! /bin/sh ### BEGIN INIT INFO # Provides: Subversion Repository Server Daemon # Required-Start: $local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # # Requirements: /var/run/svnserve/ with "svn:svn" # # Short-Description: Initscript for Subversion Repository Server Daemon # Description: Written for Debian 4.0 (Etch) to start/stop Subversion Repository Server Daemon # Used skeleton script of 4.0 (Etch). # # There are some specialities: # 1. A special SVN user and group is used and stated with # "--chuid svn:svn" (start-stop-daemon). # Plus a fitting "--umask 002" (start-stop-daemon). # 2. Make sure that the SVN user can write the pid file to # the folder "/var/run/svnserve/" by setting it to "svn:svn". # Otherwise svnserve will not start. # 3. The variable definition of PIDFILE has been moved before # DAEMON_ARGS, as it is used as an argument for svnserve. ### END INIT INFO # Author: Maddes - http://www.maddes.net/ # # Do NOT "set -e" # PATH should only include /usr/* if it runs after the mountnfs.sh script PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="Subversion Repository Server Daemon" NAME=svnserve PIDFILE=/var/run/svnserve/$NAME.pid DAEMON=/usr/bin/$NAME DAEMON_ARGS="--daemon --pid-file ${PIDFILE} --root=/var/svn/" SCRIPTNAME=/etc/init.d/$NAME # Exit if the package is not installed [ -x "$DAEMON" ] || exit 0 # Read configuration variable file if it is present [ -r /etc/default/$NAME ] && . /etc/default/$NAME # Load the VERBOSE setting and other rcS variables . /lib/init/vars.sh # Define LSB log_* functions. # Depend on lsb-base (>= 3.0-6) to ensure that this file is present. . /lib/lsb/init-functions # # Function that starts the daemon/service # do_start() { # Return # 0 if daemon has been started # 1 if daemon was already running # 2 if daemon could not be started start-stop-daemon --chuid svn:svn --umask 002 --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \ || return 1 start-stop-daemon --chuid svn:svn --umask 002 --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \ $DAEMON_ARGS \ || return 2 # Add code here, if necessary, that waits for the process to be ready # to handle requests from services started subsequently which depend # on this one. As a last resort, sleep for some time. } ... the rest is unchanged ...

  The script uses the undocumented parameter "--pid-file", which is only mentioned on the Development Mailing List.
  Make it executable via chmod a+x /etc/init.d/svnserve
  Then implement it into the startup routines with update-rc.d svnserve defaults.
  Don't forget to create the directory /var/run/svnserve and change its owner/group via chown svn:svn /var/run/svnserve.
• Start/Stop:
  invoke-rc.d svnserve start|stop|restart

Other packages

• FireFly / mt-daapd (Debian package) in development for the next release ("testing" as of 2007-08 called Lenny). Supports M3U playlists when they are UTF-8 encoded, otherwise files with special characters (e.g. german Umlauts) are ignored.
• mldonkey (Debian package) as BitTorrent client with web interface.

Wake-On-LAN / Wake-On-PCI (PME)

(If you used my previous approach, please delete the init.d file and deactivate it with "update-rc.d -f wake_on_pci remove". It was working but not correctly implemented.)

• First check that your BIOS supports Wake-On-LAN or Wake-On-PCI (PME) and make sure it is enabled.
• As WoL functionality is always disabled in current kernels/drivers (2.x) we need a tool to re-enable them after boot. Just install the "ethtool" package for this:
  

  aptitude install ethtool

• The easiest way to enable WoL on all started NICs automatically, is to create a batch file in /etc/network/if-up.d (see man interfaces).
  Create the file "/etc/network/if-up.d/enable_wol":
  

  #!/bin/sh if [ ! -x /usr/sbin/ethtool ] then exit 0 fi if [ "${METHOD}" = loopback ] then exit 0 fi /usr/sbin/ethtool -s $IFACE wol g

  Make it executable via "chmod a+x /etc/network/if-up.d/enable_wol"
• Most current mainboards and NICs do not support the original WoL wakeup anymore, instead they use a PM Event (Wake-On-PCI) to start the computer. Similar to the WoL functionality of NICs these PMEs are always disabled after Debian boot. You can check the state with "cat /proc/acpi/wakeup" and searching for PCI0.
  To enable it on every boot create the file "/etc/init.d/acpi_wakeup_pci":
  

  #!/bin/sh # Enable ACPI Power Management Events (PME) for Wake-on-LAN if they are disabled # for info see # http://www.intel.com/support/network/sb/CS-000084.htm # http://www.vdr-wiki.de/wiki/index.php/WAKE_ON_LAN # http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit if (grep PCI0 /proc/acpi/wakeup | grep disabled 2>&1 >> /dev/null) then echo -n PCI0 > /proc/acpi/wakeup fi

  Make it executable via "chmod a+x /etc/init.d/acpi_wakeup_pci"
  Then implement it into the startup routines for startup and shutdown/reboot, just before and after the networking with "update-rc.d acpi_wakeup_pci start 38 S . start 37 0 6 ."
• Here are some links with good information:
  José Pedro Oliveira's Wake on LAN mini HOWTO (Linux Tool und FAQ)
  wol (Linux Tool und FAQ)
  VDR Wiki (Debian FAQ) → MC-WOL.EXE (Windows Tool)
  Brueck Computer
  Alte Linux Mailinglist
  

ShutDown On Idle

• With Wake-On-LAN you and others in your network can start the Debian computer and use the services it provides.
  But how it will be shut down again? Especially if the others do not have root access or even shell access?
  And you don't want that someone shuts down the server, although someone else is still working with it.
• The solution is to monitor the TCP/IP ports of the provided services. If there's no traffic for quite some time on the monitored ports, then you can assume that the server is not used anymore and can be shut down safely. Monitoring ports and protocolling packets can be done via "tcpdump".
  Additionally the solution should check for active console users, to avoid that a user directly logged in (e.g. root) is not interrupted during his work. Active users are reported by "who".
• The solution can be splitted in two parts:
  
  1. Setting up "tcpdump" to watch the ports in the background via the SysVInit system. And taking care that "tcpdump" does not consume to much CPU cycles and harddisk space (log), when the server is heavily used.
  2. A reoccurring script via a CRON job, that checks the result of "tcpdump", watches for active users and shuts down the server when appropriate.
  Both parts have to care of each other (activate, check, restart, etc.).
• Here are the scripts of my solution, which was developed with help from some guys in the German Debian Forum. To avoid typos download the scripts right here.
  0. Install tcpdump:
  

  aptitude install tcpdump

  1. "/etc/shutdown_on_idle/shutdown_on_idle_tcpdump" with some general definitions: (chmod a+r)
  

  TCPDUMPLOGPATH=/var/log TCPDUMPLOGNAME=shutdown_on_idle_tcpdump.log TCPDUMPLOG=${TCPDUMPLOGPATH}/${TCPDUMPLOGNAME}

  2. "/usr/local/bin/shutdown_on_idle_tcpdump" with the call of "tcpdump": (chmod u+x)
  

  #! /bin/sh # Prerequisites: # a) TCPDUMP package # aptitude install tcpdump # # Small script needed, because redirection can not be stated as an "argument" with start-stop-daemon # # First parameter: packet filter # Second parameter: log file # # The paramter "-c 1" is used, to avoid logging everything and bringing down the machine's performance. # This script will be restarted by the CRON job, if it doesn't run anymore. exec /usr/sbin/tcpdump -l -i any -f -n -q -tttt -c 1 "$1" > "$2"

  3. "/etc/init.d/shutdown_on_idle_tcpdump" to start "tcpdump" via the SysVInit system (chmod a+rx).
  Copy "/etc/init.d/skeleton" as "/etc/init.d/shutdown_on_idle_tcpdump".
  Then edit it as following (my changes are in orange) and implement it into the startup routines with "update-rc.d shutdown_on_idle_tcpdump defaults".
  

  #! /bin/sh ### BEGIN INIT INFO # Provides: tcpdump logging network traffic on the defined ports # Required-Start: $local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Initscript for tcpdump logging for "shutdown on idle" system # Description: Starts tcpdump in the background to log network traffic # on specified port. The log can be used to find out # if the server's services are in use or have been idle # for a long time. # tcpdump is started via a script to allow for redirecting its standard output. # # Differences to the normal Debian 4.0 "Etch" skeleton: # - configuration variable file must be there and is read after LBS log_* functions # - check if all needed variables where set in the configuration variable file # - the tcpdump log file is deleted when starting and stopping # - a symbolic link in /etc/cron.d to the cron definition in /etc/shutdown_on_idle is created/deleted on start/stop # - on starting the parameter passing has been slighlty modified, quotes where added to give the # daemon args as one parameter and a second parameter was added for the log file ### END INIT INFO # Author: Maddes - http://www.maddes.net/ # # Do NOT "set -e" # PATH should only include /usr/* if it runs after the mountnfs.sh script PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="tcpdump logging for \"shutdown on idle\" system" NAME=shutdown_on_idle_tcpdump DAEMON=/usr/local/bin/${NAME} # Logging packets for the server's IP and the ports of FTP, SSH (for SFTP/SCP), HTTP/HTTPS, Subversion DAEMON_ARGS="dst host 10.0.0.253 and ( dst port 21 or dst port 22 or dst port 80 or dst port 443 or dst port 3690 )" PIDNAME=tcpdump PIDFILE=/var/run/${NAME}.pid SCRIPTNAME=/etc/init.d/${NAME} # To check: ps xa -f | grep tcpdump # Exit if the package is not installed [ -x "$DAEMON" ] || exit 0 # Load the VERBOSE setting and other rcS variables . /lib/init/vars.sh # Define LSB log_* functions. # Depend on lsb-base (>= 3.0-6) to ensure that this file is present. . /lib/lsb/init-functions # Maddes: Always read shared configuration variable file, exit with error if it is not present or if not all needed variables are set RC=0 [ ! -r "/etc/shutdown_on_idle/${NAME}" ] && RC=1 [ ${RC} -gt 0 ] && log_daemon_msg "Missing or unreadable /etc/shutdown_on_idle/${NAME}, check the setup" $NAME [ ${RC} -gt 0 ] && [ "$VERBOSE" != no ] && log_end_msg 1 [ ${RC} -gt 0 ] && exit 1 . /etc/shutdown_on_idle/${NAME} RC=0 [ -z ${TCPDUMPLOGPATH} ] && RC=1 [ -z ${TCPDUMPLOGNAME} ] && RC=1 [ -z ${TCPDUMPLOG} ] && RC=1 [ ${RC} -gt 0 ] && log_daemon_msg "TCPDUMP Variables not set in /etc/shutdown_on_idle/${NAME}, check the setup" $NAME [ ${RC} -gt 0 ] && [ "$VERBOSE" != no ] && log_end_msg 1 [ ${RC} -gt 0 ] && exit 1 # # Function that starts the daemon/service # do_start() { # Return # 0 if daemon has been started # 1 if daemon was already running # 2 if daemon could not be started start-stop-daemon --make-pidfile --background --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \ || return 1 rm -f "${TCPDUMPLOG}" start-stop-daemon --make-pidfile --background --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \ "$DAEMON_ARGS" "${TCPDUMPLOG}"\ || return 2 # Add code here, if necessary, that waits for the process to be ready # to handle requests from services started subsequently which depend # on this one. As a last resort, sleep for some time. ln -s -f /etc/shutdown_on_idle/shutdown_on_idle_cron.conf /etc/cron.d/shutdown_on_idle } # # Function that stops the daemon/service # do_stop() { rm -f /etc/cron.d/shutdown_on_idle rm -f "${TCPDUMPLOG}" # Return # 0 if daemon has been stopped # 1 if daemon was already stopped # 2 if daemon could not be stopped # other if a failure occurred start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $PIDNAME RETVAL="$?" [ "$RETVAL" = 2 ] && return 2 # Wait for children to finish too if this is a daemon that forks # and if the daemon is only ever run from this initscript. # If the above conditions are not satisfied then add some other code # that waits for the process to drop all resources that could be # needed by services started subsequently. A last resort is to # sleep for some time. start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON [ "$?" = 2 ] && return 2 # Many daemons don't delete their pidfiles when they exit. rm -f $PIDFILE return "$RETVAL" } # # Function that sends a SIGHUP to the daemon/service # do_reload() { # # If the daemon can reload its configuration without # restarting (for example, when it is sent a SIGHUP), # then implement that here. # start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $PIDNAME return 0 } ... the rest is unchanged ...

  4. "/usr/local/bin/shutdown_on_idle" to check from time to time if the computer can be shut down: (chmod u+x)
  

  #! /bin/sh # # This script checks if the server was idle for a specified time # and if so shuts it down. # # A veto file will be created if a test protests against a shutdown. # This way you can concatenate several tests (network traffic, # logged in users, etc.) and if one says "NO shutdown", then the script # just stops. If no test complains, then the shutdown is executed. # Author: Maddes - http://www.maddes.net/ # ## ## Script Functions ## function do_rm_vetofile() { rm -f ${VETOFILE} } function do_log() { echo `date +"%x %T"` $* >> ${LOGFILE} } function do_no_shutdown() { do_log "Not idle because of" $* do_rm_vetofile exit 0 } function do_shutdown() { do_log "ShutDown" $* /sbin/poweroff exit 0 } function do_check_vetofile() { [ -f ${VETOFILE} ] && do_no_shutdown $* } function do_break() { do_log "BREAK:" $* exit 1 } ## ## Script Variables ## # General name used for files, etc. (=script name) NAME=shutdown_on_idle # The veto file VETOFILE=/var/run/${NAME}.veto # Log file for errors and/or for testing protocol LOGFILE=/var/log/${NAME}.log # The tcpdump log file variables are read from a shared configuration variable file, exit with error if it is not present or if not all needed variables are set TCPDUMPNAME=${NAME}_tcpdump PIDFILE=/var/run/${TCPDUMPNAME}.pid [ ! -r "/etc/shutdown_on_idle/${TCPDUMPNAME}" ] && do_break "Missing or unreadable /etc/shutdown_on_idle/${TCPDUMPNAME}, check the setup" . /etc/shutdown_on_idle/${TCPDUMPNAME} [ -z ${TCPDUMPLOGPATH} ] && do_break "TCPDUMP Variables not set in /etc/shutdown_on_idle/${TCPDUMPNAME}, check the setup" [ -z ${TCPDUMPLOGNAME} ] && do_break "TCPDUMP Variables not set in /etc/shutdown_on_idle/${TCPDUMPNAME}, check the setup" [ -z ${TCPDUMPLOG} ] && do_break "TCPDUMP Variables not set in /etc/shutdown_on_idle/${TCPDUMPNAME}, check the setup" ## ## Main Script ## ## 1. Preparations # Remove any old veto file first do_rm_vetofile # Handle tcpdump # a.) Reactivate tcpdump if it has stopped since last check if [ ! -f "${PIDFILE}" ] then /usr/sbin/invoke-rc.d ${TCPDUMPNAME} start else ps -p `cat "${PIDFILE}"` 1>/dev/null 2>&1 RC=$? [ ${RC} -gt 0 ] && /usr/sbin/invoke-rc.d ${TCPDUMPNAME} restart; fi # b.) Check tcpdump log [ ! -f "${TCPDUMPLOG}" ] && do_break "Missing ${TCPDUMPLOG}, check that corresponding init script is invoked" ## 2. Tests # Check active users RC=`who | wc -l` [ ${RC} -gt 0 ] && touch ${VETOFILE} do_check_vetofile "Active Users" # Check network traffic find "${TCPDUMPLOGPATH}" -name "${TCPDUMPLOGNAME}" -type f -mmin -60 -exec touch ${VETOFILE} \; do_check_vetofile "Network Traffic" ## 3. ShutDown do_shutdown

  5. "/etc/shutdown_on_idle/shutdown_on_idle_cron.conf" to start the checking script every 5 minutes: (chmod a+r)
  

  # crontab fragment for "shutdown on idle" system # Check for idle every 5 minutes starting from the first minute of the hour 1-59/5 * * * * root /usr/local/bin/shutdown_on_idle