Page Complete

The formatting of this page is now complete. I will be adding content as time permits and filling in sections that are sparse -- check back for updates.

Last Updated 1/24/09

Sections Updated:

To download this complete document in plain/text formatt, use the link below:

Feedback Wanted

I would like your feedback on the site and its content. That's the only way I can improve the information. Let me know what you like, hate, or would like to see added -- and most probably, it will be. Feedback to:

drankinatty <at> suddenlinkmail <dot> com

openSuSE Server Setup

Intended Audience: The collection of information for setting up an openSuSE server is intended as a "quick reference" arranged in logical order, start to finish, for setting up a basic functional server based on the openSuSE distribution. Most of the topics are distribution independent. This information comes from my notes, etc. from setting up servers on Mandrake and SuSE for the past nine years. The topics are arranged in, and should be approached in, sequential order.

This document was prepared mainly for me as a quick reference to rebuild a solid server in the event of disaster after two lightning strikes destroyed 2 servers in a 3 month period of time. It has come in handy on many new boxes as well. There is little background provided. This is a bare-bones "do X, Y, Z, restart, done" server setup document that assumes you have the server packages installed on your computer. (if you don't, then install them as we go along) Of course, nearly all configuration files will require root access, so if you do not have that available, you are not going to get very far.

Table of Contents

  1. Preliminary Post Install Cleanup
  2. BIND 9 DNS (primary & backup)
  3. dhcpd (with dynamic updates to DNS)
  4. MySQL - Securing Your Server
  5. Samba (stand-alone server, pdf-gen script included)
  6. ntp - Network Time Protocol
  7. Postfix, Dovecot & SpamAssassin
  8. Apache2 Web Server with SSL
  9. VPN - Virtual Private Network

Of course, use at your own RISK. I have made a sincere effort to make sure everything is correct but as always, make sure you "know what you are doing" and that "what you are doing makes sense" before you do it.

You are free to copy, hack (not my copy), and do whatever you want with this reference. All information on my site, except as provided in my copyright (in the footer) is released under GPL2 only. Just don't plagiarize it as your own. That's not honorable or courteous. Have fun. You will be amazed at what Linux can do as a server with just a little bit of effort.

NOTE: throughout this document I will use this format as a Note: to point out gotchas or often overlooked information, so PAY ATTENTION.

back to top

1. Preliminary Post Install Cleanup

To prevent unnecessary load - KILL BEAGLE!

Standard clean-up on every install:

(1) Shoot the "dreaded dog" in the head. (remove beagle) You can use yast to remove it or simply cut and paste the following into konsole or an xterm as root:

rpm -e $(rpm -qa | grep beagle | sed -e '/^lib/d') \
$(rpm -qa | grep kerry) \
&& rm -r ~/.beagle

(2) Note: For openSuSE 10.3 Only

On first login to kde or gnome, right-click the openSuSE Updater icon in the task-bar and uncheck "start on login", then click quit. This is due to the 10.3 update scheme taking well over 10 minutes to generate its cache. This problem was solved with the zypp backend rewrite in 11.0. Just remember to run updates manually or schedule them automatically at a certain time.

DONE - No more slowness, crisp performance from boot-to-"end current-session" Now on to the rest of the server setup.

KDE4 - Nepomuk Services (strigi Indexer)

Just a note. Up through KDE 4.3.0, I had problems with the nepomukservices process eating 100% of my CPU at times. So far with KDE 4.3.1, it seems better. Strigi is KDE 4's Beagle like index service. I still haven't found any use for it, but the KDE developers keep promising it will be good. So as long as it isn't causing problems, I just leave it. If you are experiencing problems with it, simply move the startup file for nepomukserver file out of /usr/share/autostart and kill the process or restart KDE. The following will disable it:

mv /usr/share/autostart/nepomukserver.desktop /tmp

(then kill the process or restart KDE)

Gnome - tracker/libtracker - nuke it!

Gnome has a “mee too” indexing service called ‘Tracker’ in 11.3+ that is as bad, or worse, than beagle. It literally brings gnome to its knees and for the better part of an hour and on each desktop restart it slows things to a crawl. Save yourself the torment, just nuke it:

rpm -e libtracker-miner-0_10-0 libtracker-client-0_10-0 gnome-panel-applet-tracker \
       tracker tracker-miner-files libtracker-extract-0_10-0 tracker-gui \
       libtracker-sparql-0_10-0 nautilus-extension-tracker-tags tracker-miner-evolution \

If You Notice High CPU Use With Avahi - SHOOT IT TOO!

According to Novell: Avahi is an implementation of the DNS Service Discovery and Multicast DNS specifications for Zeroconf Computing. It uses D-BUS for communication between user applications and a system daemon. The daemon is used to coordinate application efforts in caching replies, necessary to minimize the traffic imposed on networks.

According to openSuSE users: "I just noted that avahi-daemon is taking 50% of my cpu." In other words, if you see high cpu loads from Avahi on 11.1 -- it is another process to shoot in the head. Personally, on 10.3 and 11.0, I haven't had any problems with avahi and I leave it running. So if you are one of the lucky ones having problems, I'll show how you don't actually have to remove it to stop it from running, you can simply turn it off and confirm you can live without it. We will simply stop both parts of avahi (dnsconfd and daemon) and then use 'chkconfig' to stop them from running at boot. From the konsole window or an xterm:

rcavahi-dnsconfd stop
rcavahi-daemon stop

chkconfig avahi-dnsconfd off
chkconfig avahi-daemon off

I have run with it both enabled and disabled, and I can't tell any difference in CPU load or in network discoverability issues. Since I haven't experienced any problems, I just leave it running.

chkconfig is the primary tool for controlling what services are started at boot. Get familiar with it. To see the list of processes that you can turn on or off, use 'chkconfig --list'. NOTE: never turn the 'kbd' (keyboard) service off!

Other Preliminary Matters

users - You know how to set them up, and of course do this first.

groups - When setting up machines that will be present on the same local network, make an effort to keep your user and group IDs the same across multiple machines. The OS can handle small UID and GID map changes, but wild changes in UID or GID from machine to machine isn't advisable. For instance the RedHat flavors normal UIDs start at 500 while SuSE normal user UIDs start at 1000. Just something to keep in mind to minimize the amount of mapping headaches for local backups, etc.

Setting Up sudo - Make Life Easier

To make setup and subsequent configuration easier, I recommend setting up sudo access for yourself to allow you to execute commands as the super-user (thus 'su' 'do' or 'sudo') without having to type the full root password every time. You must use the command 'visudo' to edit the /etc/sudoers file, you can't edit the file directly (I don't know why). After making the following changes, then simply add yourself to the 'wheel' group in /etc/group and you will then be able to execute commands as root simply by preceding the command with 'sudo'. (Example: sudo rcntp start). Make the following changes with visudo:

visudo   # this will start vi and open the /etc/sudoers file
         # then simply uncomment the following line

# Same thing without a password

Now simply edit /etc/group or use yast and add yourself to the wheel group:

11:24 ecstasy:~> cat /etc/group

If you are using KDE as your interface, then due to kdesu bugs 400903 and 446947[1] you must enter the following 'on one line' as your regular user in either konsole or with Alt+F2 to patch kdesu:

kwriteconfig --file kdesurc --group super-user-command \
--key super-user-command sudo
back to top

2. BIND 9 DNS (primary & backup)

The named daemon. One of the most fundamental server functions that any server must do, and do well, is to provide name resolution for the local network. Meaning that it has the ability to tell all the computers on the network what address each of the other computers can be reached at. It is what provides the link that tells all computers that is at address It isn't enough to simply provide the address book for the local network, it also has to be able to let all computers know that is at and so on.

There are a number of different ways to do this. You can configure all computers with fixed IP addresses and then manually provide a name-address lookup in the /etc/hosts of each machine. You can let your router hand out addresses and likewise use /etc/hosts to keep track. All work, but you rapidly run into limitation and updating individual files if you have more than a handful of computers is a pain. Not to mention the situation where someone brings a laptop to your office or home and you can't provide internet access or access to your file server without having to setup configuration files on their laptop first.

The following setup is an elegant solution that will provide a full caching nameserver with the BIND 9 DNS "Berkley Internet Nameservice Daemon" that is capable of providing name resolution to all computers on your lan and capable of receiving dynamic client host updates from dhcpd when your co-worker opens their laptop for the first time. (see: /usr/share/doc/packages/dhcp-server/DDNS-howto.txt for the basics.) Let's get started.

Generate The Required dhcp_updater Keys

First we will generate the DHCP_UPDATER keys (TSIG keys) that will provide secure dynamic updates to the DNS zone files by dhcpd when a new computer joins the network. openSuSE provides a script that automates the process. The script is nothing more than a wrapper to the dnssec-keygen call shown below:

cd /etc
sh /usr/share/doc/packages/dhcp-server/
  (or manually)
dnssec-keygen -a HMAC-MD5 -b 512 -r /dev/random -n user $HOSTNAME

The genDDNSkey script is in /usr/share/doc/packages/dhcp-server/ and in releases prior to 11.0 all that was required was to issue the command 'genDDNSkey'. In 11.0 there is a conflict with /usr/bin/genDDNSkey requiring you to specify the actual script name and location.

Confirm the dhcp_updater keys were created

david@nemesis:~> l /etc/Kdhcp_updater*
-rw-------  1 root root 119 2005-12-08 23:35 /etc/Kdhcp_updater.+157+02929.key
-rw-------  1 root root 145 2005-12-08 23:35 /etc/Kdhcp_updater.+157+02929.private

Confirm named.keys and rndc.key exist and the permissions and ownership are correct

root@bonza:/home/david # l /etc/*.key*
-rw-r----- 1 root named 211 2008-01-04 23:09 /etc/named.keys
-rw-r----- 1 root named 141 2008-01-02 21:11 /etc/rndc.key

Confirm /etc/sysconfig/named includes named.keys

If you do not have the named.keys file, you can simply create it:

# touch /etc/named.keys
# chown root:named /etc/named.keys
# chmod 0640 /etc/named.keys

(edit and add the key from the Kdhcp_updater...private file)

key hostname {
    algorithm HMAC-MD5;
    secret "thefullkey==";

You have two options here. Either use yast sysconfig editor to make the change (recommended) or simply edit /etc/sysconfig/named and confirm or add, if necessary, /etc/named.keys as an include file. The advantage to using yast is that in the past, if you edited the /etc/sysconfig files manually, SuSE Config would exclude those files from update based on your edits. If you use yast, the setting is Yast - System - /etc/sysconfig Editor - Network - DNS - NAMED_CONF_INCLUDE_FILES. The line should read:


Note for openSuSE 11.1: There is a bug in Yast /etc/sysconfig Editor that prevents certain setting from being made.[2] (cron DAILY_TIME, etc.) If you cannot make the change with yast, simply edit /etc/sysconfig/named directly.

Create PRIMARY /etc/named.conf

The easiest way to explain the config files is just to provide you with a working example and have you modify it to suit your needs. You can simply cut and paste these into you config files. I recommend making a backup of your original config files first. Some of the original files do contain further explanation. Simply cp /etc/named.conf /etc/named.conf.orig and proceed.

include "/etc/rndc.key";

controls {
        inet allow { localhost; } keys { rndc-key; };

options {

        directory "/var/lib/named";
        dump-file "/var/log/named_dump.db";
        statistics-file "/var/log/named.stats";
        forwarders {;;; }; # your ISP dns boxes
        forward first;
        allow-transfer {; }; # only allow backup DNS server to copy zones
        #listen-on port 53 {; };
        listen-on-v6 { none; };
        notify yes; # Only set to no if no backup DNS to prevent notify messages being sent

zone "." in {
        type hint;
        file "root.hint";

zone "localhost" in {
        type master;
        file "";

zone "" in {
        type master;
        file "";

zone "" in {
        file "dyn/";
        type master;
        allow-update{ key DHCP_UPDATER; };

zone "" in {
        file "dyn/";
        type master;
        allow-update{ key DHCP_UPDATER; };

include "/etc/named.conf.include";
logging {
        category default { log_syslog; };
        channel log_syslog { syslog; };

Create the domain specific zone files specified above ( "dyn/" and "dyn/" ) in the /var/lib/named/dyn directory making sure to set the correct ownership and permissions on both the directories and files.

Configuring a Backup DNS Server

For BACKUP DNS named.conf, just change the zone statements for the zones that the server is a backup for to:

zone "" in {
        file "dyn/";
        type slave;
        masters {

zone "" in {
        file "dyn/";
        type slave;
        masters {

where the masters IP address ("") is the IP for the server for which this machine serves as a backup for. This will allow the backup to pull copies of the zone files from the primary DNS server when the backup is started or when changes are made to the primary.

Note: if named complains on start about failure or errors with journal (.jnl) files created with dhcpd dynamic update, stop named, rm /var/lib/named/dyn/*.jnl and restart named. The files will be recreated as needed.

File and directory ownership and permissions (CRITICAL)

root@bonza:/home/david # l /var/lib/named
total 48
drwxr-xr-x  9 root  root  4096 2007-09-21 18:56 ./
drwxr-xr-x 44 root  root  4096 2008-01-05 22:01 ../
-rw-r--r--  1 root  root   192 2001-07-04 02:27
drwxr-xr-x  2 root  root  4096 2008-01-04 15:37 dev/
drwxr-xr-x  2 named named 4096 2008-01-05 05:09 dyn/
drwxr-xr-x  3 root  root  4096 2008-01-04 23:45 etc/
-rw-r--r--  1 root  root   158 2001-07-04 02:27
drwxr-xr-x  2 named named 4096 2007-09-21 19:12 log/
drwxr-xr-x  2 root  root  4096 2007-09-21 19:12 master/
-rw-r--r--  1 root  root  2517 2007-09-21 19:13 root.hint
drwxr-xr-x  2 named named 4096 2007-09-21 19:12 slave/
drwxr-xr-x  4 root  root  4096 2008-01-02 21:10 var/

root@bonza:/srv/http/htdocs # l /var/lib/named/dyn
drwxr-xr-x 9 root  root  4096 2007-09-21 18:56 ../
-rw-r--r-- 1 named named  820 2008-01-04 23:36
-rw-r--r-- 1 named named  812 2008-01-04 23:31

Create the "Forward" zone file

NOTE if you are also setting up a backup DNS server, include a second NS entry for the backup DNS. Additionally each time YOU edit a zone file, you must increment the "serial" by +1 or +whateveryouline. Never -1 that causes real problems.

The primary server zone file (pay attention to the trailing "."s)  Also, delete my **notes in the text below that are just there as temporary comments

root@bonza:/srv/http/htdocs # cat /var/lib/named/dyn/
$TTL 172800     ; 2 days              IN SOA (
                                2008010400 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                        NS ; ** The backup server
                        MX      0
gw                      A
fax                     A
bonza                   A
ftp                     CNAME   bonza
mail                    CNAME   bonza
www                     CNAME   bonza
providence              A

Create the primary server "Reverse" zone file

root@bonza:/srv/http/htdocs # cat /var/lib/named/dyn/
$TTL 172800     ; 2 days  IN SOA (
                                2008010400 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                        NS ; ** The backup server
13                      PTR
14                      PTR
15                      PTR
16                      PTR

For backup server zone files, just start the server and the primary zone files will automatically be copied from the primary server and put in place on the backup.

Configure Your DNS to Start at Boot

As with all services, you must configure the service to start at boot. From the command line a service is configured to start at boot with "chkconfig <service name> on" (You can use a GUI config tool like Yast on SuSE or MCC on Mandriva, etc..). You can check the status of all services and whether they are 'on' or 'off' at boot with "chkconfig --list". To confirm that a specific service has been configured to start at boot, just pipe the output of the --list option to grep <service name> such as "chkconfig --list | grep named". To activate and confirm that configuration was successful with one command line simply use the conditional '&&' or separate the commands with a semicolon ';'. For BIND DNS where <service name> = named:

chkconfig named on && chkconfig --list | grep named

If successful, you will see something similar to:

21:12 nirvana/srv # chkconfig named on; chkconfig --list | grep named
named                     0:off  1:off  2:off  3:on   4:off  5:on   6:off

where 0: 1: 2: 3: 4: 5: 6: denote the "runlevel" and off/on the status.

back to top

3. dhcpd "Dynamic Host Control Protocol"

For a bit of background see: /usr/share/doc/packages/dhcp-server/DDNS-howto.txt. Just as with named above make sure to edit /etc/sysconfig/dhcpd with either yast or your favorite editor and add/confirm /etc/named.keys is set as an include file. The line should look like this:


Create dhcpd.conf

root@bonza:/srv/http/htdocs # cat /etc/dhcpd.conf
# dhcpd.conf
# option definitions common to all supported networks...

        option domain-name "";
        option domain-name-servers;
        option routers;
        option ntp-servers;
        option netbios-name-servers;
        default-lease-time 28800;
        ddns-update-style interim;
        ddns-updates on;
        ignore client-updates;
        include "/etc/named.keys";

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.


subnet netmask {
        option domain-name "";
        ddns-domainname "";
        option subnet-mask;
        range dynamic-bootp; #range of IPs to hand out
        default-lease-time 28800;
        max-lease-time 172800;
        zone {primary; key DHCP_UPDATER; }
        zone { primary; key DHCP_UPDATER; }
        # We want Rankin-P35a to appear at the same fixed address
        # regardless of which OS is booted to prevent multiple dhcp leases
        # belonging to the same hardware address
        host {
               hardware ethernet 00:11:f5:15:2d:83;

        # we want the copier/scanner to appear at a fixed address
        host SC1FC09D {
                hardware ethernet 08:00:1F:1F:C0:9D;
back to top

4. MySQL - Securing Your Server

For additional detail, the mysql site has fantastic documentation. see: MySQL Default Privileges The following should be entered at the command line. Root privileges are not required and the MySQL root account is not the same as the system root account and should NOT be the same. When first started MySQL is wide open and has no root password. You will correct that by creating a root password and granting privileges to another admin user (yourself). If mysql is not running, start it with "rcmysql start". Also, as above, configure mysql to start at boot "chkconfig mysql on". Now secure the server:

mysql -u root
use mysql
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpwd');
SET PASSWORD FOR 'root'@'hostname' = PASSWORD('newpwd');
SET PASSWORD FOR 'root'@'hostname.domain' = PASSWORD('newpwd');
SET PASSWORD FOR 'root'@'' = PASSWORD('newpwd');

hostname statements are optional

Confirm by:

mysql> select host, user, password from user;

Setting up users

GRANT ALL PRIVILEGES ON *.* TO 'user'@'hostname.domain' IDENTIFIED BY 'some_pass' WITH GRANT OPTION;

Updating password for existing users

mysql> UPDATE mysql.user SET Password = PASSWORD('newpwd') WHERE User = 'root';

Prevent MySQL Logrotate Errors

Since your server is now secured, you will need to create the /root/.my.cnf file to provide logrote access to mysql to prevent errors on logrotate of mysql logs caused by logrotate attempting to access mysql without a password. It is a simple fix. Create/edit: /root/.my.cnf with the following three lines:

password = <your_mysql_root_password>
user = root
back to top

5. Samba - Share Your Data

Samba provides the smb protocol to linux systems that allow access to data on 'shares' you define in the /etc/samba/smb.conf file. The smb protocol is how windows machines talk to share data. Since samba does that for linux, windows and linux machines can access common data on a share hosted either on a windows box or a linux box.

The following will get your linux box sharing data with your other windows boxes or other linux boxes in a 'standalone' configuration but this is not a substitute for or specifically

Creating/Selecting your Share Directories

Means exactly what it says. Just create or select the directories that you will 'share' data on. Create the physical directories and set the appropriate permissions. Here:


The permissions on the directories must be 0755 (that's drwxr-xr-x) Remember the x or execute bit controls your ability to 'descend' into that directory. (the files permissions can be adjusted to tailor security, but that's beyond this discussion)

Edit/Create The smb.conf File

Note: Before proceeding, make a copy of your original smb.conf. It contains additional comments about the parameters and their use that you will find useful. Simply: 'cp /etc/samba/smb.conf /etc/samba/'

Create the /etc/samba/smb.conf file (Stand Alone samba server - no ldap or winbind). The smb.conf file has two primary sections (1) the 'global' section, and (2) your shares. You will have one share for each resource you are sharing, whether that be a directory or a printer. Samba considers them both shares.

To get started, you can simply cut and paste the following and make the obvious changes to 'workgroup', 'wins server' IP address (if needed) and the user and group information within the shares. You will also need to select either 'wins support' making your samba box the wins server for your local network, or, you will need to comment out 'wins support' and uncomment the 'wins server' parameter and specify the IP address of your wins server. (comments in smb.conf can either be the '#' or ';' characters, blank lines are ignored)

Obviously, since all of the directories you will be sharing in this example are under /home/samba, you could just use one share, [samba] below, but that would glaze over the fact that you can tailor your shares, even if under the same director, to allow access to only those that need access to the data within each share.

  use sendfile = No
  workgroup = rb_law
  server string = Samba Server %v
  printcap name = cups
  load printers = yes
  printing = cups
  show add printer wizard = No
  log file = /var/log/samba/log.%m
  max log size = 500
  log level = 03
  time server = yes
  smb ports = 139         ; Limit smb ports to 139 to eliminate repetitive log messages
  domain logons = yes
  map to guest = bad user
  security = user
  encrypt passwords = yes
  smb passwd file = /etc/samba/smbpasswd
  local master = yes
  os level = 80
  domain master = yes
  preferred master = yes
  name resolve order = wins lmhosts bcast
  dns proxy = no

; Choose one or the other of the following

  wins support = yes
;  WINS Server - Tells the NMBD components of Samba to be a WINS Client
;       Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
;  wins server =

   comment = Home Directories
   browseable = no
   writable = yes

##  Use the Config share with caution or not at all!
##  It will provide root access for the valid users of the share
##  to everything under the '/' directory -- Yes, everything!

        comment = Admin Config Share
        path = /
        valid users = yourself
        force user = root
        force group = root
        admin users = yourself
        browseable = no
        writeable = Yes

        comment = Base Samba Share
        path = /home/samba
        valid users = @groupnameforusers  ;Can be user1,user2,@group1,@group2,etc...
        force user = TheUserYouWantOwningTheFiles
        force group = TheGroupYouWantOwningTheFiles ;note: no @ sign
        admin users = yourself
        browseable = Yes
        writeable = Yes
        inherit permissions = yes

        comment = Accounting Share
        path = /home/samba/accounting
        valid users = @groupnameforaccountingusers
        force group = accountinggrouptoownthefiles
        admin users = yourself
        writeable = Yes
        inherit permissions = Yes

        comment = File Share for the Programmers
        path = /home/samba/sourcefiles
        guest ok = Yes
        force group = codemonkeys
        admin users = yourself
        writeable = Yes

   comment = All Printers
   path = /var/spool/samba
   browseable = no
   guest ok = yes
   writable = no
   printable = yes
   create mode = 0700

   path = /var/lib/samba/printers
   browseable = yes
   write list = @adm,sys,root
   guest ok = yes
   inherit permissions = yes
   ; Settings suitable for Winbind:
   ; write list = @"Domain Admins" root
   ; force group = +@"Domain Admins"

;  A useful application of samba is to make a PDF-generation service
;  To streamline this, install windows postscript drivers (preferably color)
;  on the samba server, so that clients can automatically install them.
;  Note that this only works if 'printing' is *not* set to 'cups'

   path = /var/tmp
   guest ok = No
   printable = Yes
   comment = PDF Generator (only valid users)
   printing = bsd
   printcap name = cups
   ;print command = /usr/share/samba/scripts/print-pdf file path win_path recipient IP &
   print command = /usr/share/samba/scripts/print-pdf "%s" "%H/pdf" "//%L/%u" "%m" "%I" "%J" &
   lpq command = /bin/true

NOTE: the config share above is very useful but VERY DANGEROUS. Limit access to only yourself. It will provide root access to the entire filesystem on remote machines. It is very useful for editing configurations of the remote machines from your computer as a normal user locally but with root privileges remotely. WARNING: one slip or a stray mouse click or imprudent recursive command and you could very well be reinstalling the entire OS on a remote host!! If you don't need it -- DELETE IT.

General Note: Samba will complain about the global 'bsd' print definition within a share, but it's just a complaint, not an error. Don't forget to put the print-pdf script in /usr/share/samba and make sure it is world executable. You can get the script at the link below. Also create or modify /var/spool/samba and make sure it is world writable with "chmod 0777 /var/spool/samba".

Download: print-pdf script Just place the script in /usr/samba/scripts (with 0755 permissions) and then create a printer for it on your linux and windows machines using a good color laserjet postscript driver like the HP 8500 Color Laserjet PPD file. (That's what I use, some like the Apple postscript printer) All resulting pdfs end up in the users home directory under /pdf.

Note: After printing to pdf, you may need to rename the resulting pdf before printing another. Some applications just use the generic name "Remote Downlevel Document.pdf" for the resulting pdf. If you don't, there is a good chance you will overwrite a prior pdf. (If you modify the script to fix that -- please send me a copy)

Testing Your Configuration with 'testparm'

Before starting the samba and nameservice daemons, it is a good idea to test your configuration file. Samba provides the 'testparm' utility that checks your configuration and then prints out a list of your shares. Usage: testparm <configfile>. However, if your config file is in the /etc/samba directory (the directory specified as the --private-dir at compile time) you can simply type testparm. Recall, if you are using the [pdf-gen] share, you can expect to receive the 'Global parameter printcap name found in service section!', but you can safely ignore it.

Creating Your smbusers With 'smbpasswd'

Before anyone can access the shares, they will need a smb username and password. If you are setting up a samba server for windows clients to access, I recommend making the samba username and password the same as username/password combinations that they use to log in to windows. It's not required, you can use something different, but be aware your users will be prompted for a username and password to access the samba shares (Which usually creates panic on the spot). To create the samba username and passwords:

smbpasswd -a username

(your will be prompted for a password)

Note: Samba supports roaming profiles, and a number of different backends for large deployments. However, if you were looking for something like that -- you would be and wouldn't be looking here ;-)

Starting the 'nmbd' and 'smbd' daemons

Finally, to bring Samba to life and make sure it starts a boot time, start the daemons and then use chkconfig to configure the services to start at boot. In a terminal window:


chkconfig smb on
chkconfig nmb on

Note: openSuSE splits the startup scripts (nmbd/smbd) while most distributions have a singly smbd startup. Just part of openSuSE's personality

Testing Samba and Listing Your Shares

For basic testing of your server to make sure it thinks it is running and it knows what it is supposed to be sharing, the smbclient utility provides a quick check. The syntax is 'smbclient -Uuser -Lhost'. For testing from localhost for shares with public access you can use -U%. If everything is going OK, you should see something like the following:

00:45 bonza~> smbclient -U% -Llocalhost
Domain=[RB_LAW] OS=[Unix] Server=[Samba 3.2.4-0.1.130-1906-SUSE-SL10.3]

        Sharename       Type      Comment
        ---------       ----      -------
        samba           Disk      Base Samba Share
        office          Disk      Shared Office Files
        rankin          Disk      Rankin Law Firm PLLC
        scans           Disk      Scanned Images from Copier
        allen           Disk      T Stefan Allen
        bertin          Disk      Darren Bertin
        guillory        Disk      David Guillory
        jointcases      Disk      Joint Client Files
        lawtools        Disk      Case Development - Summation
        forms           Disk      Shared Forms and Briefs
        computer        Disk      Computer Drivers and Software
        closed          Disk      Closed Case Files
        print$          Disk
        pdf-gen         Printer   PDF Generator (only valid users)
        IPC$            IPC       IPC Service (Samba Server 3.2.4-0.1.130-1906-SUSE-SL10.3)
        SHARP_AR-M355N_192.168.7.20 Printer   SHARP AR-M355N
        hplj_4200       Printer   HP LaserJet 4200
        dcr_lj4100n     Printer   HP LaserJet 4100n
Domain=[RB_LAW] OS=[Unix] Server=[Samba 3.2.4-0.1.130-1906-SUSE-SL10.3]

        Server               Comment
        ---------            -------
        PROVIDENCE           Samba 3.2.7-0.1.135-2042-SUSE-SL10.3
        DARREN-XP            Darren-XP
        LISHA                Lisha
        CW-DESK              cynthia desktop
        GUILLORY2            Guillory Sempron
        RECEPTION            Dell 2400 2.6 GHz
        BONZA                Samba Server 3.2.4-0.1.130-1906-SUSE-SL10.3

        Workgroup            Master
        ---------            -------
        RB_LAW               BONZA

Note: You will not see any shares that are not browseable (set with browseable = no) in the share like your home share, etc. To see your home share, use -Uyourusername and you will be prompted for a password. The same applies to querying a remote host. Example: I can get the status of the remote host providence while I'm on host bonza with: smbclient -Udavid -Lprovidence


If your system has shut down hard due to a power outage or the cat jumping on the off button on the power strip and you get an error like: 'Warning: /var/run/samba/ exists' then don't panic. What you can do is check to make sure smbd, and/or nmbd are really dead, if they're not kill them, delete the pid files and then restart your server. A quick example would be:

ps ax | grep mbd   # Usually you see 1 nmbd process and many smbd processes

killall smbd       # if there are any smbd running (same for nmbd)

rm /var/run/samba/
rm /var/run/samba/

rcnmb start
rcsmb start

If that doesn't cure the problem, then it is time for your to visit Diagnosing Samba which is part of the Samba bible Samba-HOWTO-Collection. Regardless of the problem, you will find your answer there.

back to top

6. ntp - Keeping Exact Time

Using ntp will keep your system clock synchronized with the National Institute of Standards atomic clock. ntp is generally installed by default on all systems and the only thing required to get things running is to add an external source of synchronized time to your /etc/ntp.conf. There are two basic sources of external time servers. You can either research and find the time servers nearest to you and add their IP address, or you can make use of that organizes servers by region and then assigns servers for you.

Making Use of The ntp Pool segregates ntp servers by country or region and then makes the specific collection available for use. Basically, the ntp pool makes use of a dns round-robin to pass the time information keeping the servers in sync. When using the pool for time synchronization, the pool will randomly assign a server for use within your selected region.

To use the pool, simply visit the site and it will provide you with a pool list of servers based on your region which you will simply add to your ntp.conf replacing any specific time servers you have specified. For example, in the United States, you would add the following as your outside source of synchronized time in /etc/ntp.conf:


After adding the servers to your ntp.conf, then you simply need to start ntpd and configure it to start at boot. Before you start the server for the first time, make sure your computer's clock is set to something reasonable.[3] Then use the familiar:

rcntp start

chkconfig ntp on

The initial sync may take up to 30 minutes. To check to see if the client connects, issue the following:

ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
 LOCAL(0)        LOCAL(0)        10 l   12   64    1    0.000    0.000   0.002    3 u   11   64    1   20.757    1.785   0.002
 nyse.cox.smu.ed .INIT.          16 u    -   64    0    0.000    0.000 4000.00   .INIT.          16 u    -   64    0    0.000    0.000 4000.00

Using helps decrease load on the official time servers, with the only drawback being that you might not always get the server closest to you and there is always the possibility of getting a wonky server. Millions make use of the pool including a number of linux distributions.

Using a NIST Stratum 2 Time Server

Here the only thing required is to select one or two ntp servers close to your location from the lists commonly available on the net. A saved copy of a server list is available here: Stratum Two Time Servers Then edit /etc/ntp.conf and put the IP address or hostname of the ntp servers in as the outside source of synchronized time. Everything else is exactly the same as above.

Note: If you have your network interface configured for user control (i.e. Network Manager), you can expect a 'Failed' status during the boot process because your network interface is not yet active when ntp attempts to connect with the external server. You can safely ignore the failure as ntp will sync up once the network interface is present.

back to top

7. mail (Postfix, UW or Dovecot IMAPS & SpamAssassin)

The first step in setting up your secure IMAP server is to create SSL certificates in /etc/ssl/certs to allow secure authentication for IMAPS on port 993.

UW imap (I recommend dovecot)

UW works fine as a mail package, but you run into problems when you need to configure your server to use secure IMAP for access from the internet but you have web applications running on the server that access the mail system as "localhost". UW isn't flexible enough to handle that situation without a few hacks that are NOT recommended. Certificate generation for UW is done as follows:

openssl req -new -x509 -nodes -out imapd.pem -keyout imapd.pem -days 365
openssl req -new -x509 -nodes -out imapsd.pem -keyout imapsd.pem -days 365

More information in the text file at:


Dovecot handles access from the internet securely and access by web applications running on the server just fine. It is by far the simplist and most flexible mail package I have found. To generate the dovecot certs, do the following:

cd /usr/share/doc/packages/dovecot
vi dovecot-openssl.cnf # set the defaults as you like

NOTE: the certs created are /etc/ssl/certs/dovecot.pem and /etc/ssl/private/dovecot.pem, and are only good for 365 days by default. When you need to regenerate or change the certs, remove the old ones before running the script or it will refuse to overwrite them. (or you can comment out the last two 'if' statements in, create the certs, and then uncomment the 'if' statements. (they are a security measure to prevent someone for overwriting your certs)

Check your certificates with:

openssl s_client -connect -showcerts
ctrl+c exit

Dovecot imap configuration: /etc/dovecot/dovecot.conf

disable_plaintext_auth = yes
ssl_disable = no
mail_location = mbox:~/Mail:INBOX=/var/spool/mail/%u

Next, configure Postfix to be relatively secure. Use procmail as the mailbox command for use with spamassassin and set postfix restrictions to bounce most spam based on common blacklists:

root@bonza:/home/david # postconf -n
inet_interfaces = all
inet_protocols = all
mailbox_command = /usr/bin/procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 10240000
mydestination = $myhostname, localhost.$mydomain, $mydomain,,,,
myhostname =
mynetworks_style = subnet
myorigin = $mydomain
smtpd_client_restrictions = check_client_access cidr:/etc/postfix/client_check.cidr, reject_rbl_client, reject_rbl_client, reject_rbl_client
smtpd_hard_error_limit = 3
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_check.pcre
unknown_client_reject_code = 550
unknown_local_recipient_reject_code = 550

NOTE: After modifying any of the referenced hash: files referenced by you must create an appropriate accompanying hash database (.db) file by executing "postmap hash:/etc/postfix/filename" AND execute "rcpostfix reload" (/etc/init.d/postfix reload) to cause postfix to reload (re-read) the configuration files each time a referenced hash file is created/modified OR each time a configuration change is made in /etc/postfix/

Configure Specific Relay Authentication

How can I configure postfix to allow this user to send mail outbound from my server?

smtpd_recipient_restrictions =
  check_client_access hash:/etc/postfix/clients_relay_allowed
#These clients are allowed to relay!        OK

Review postfix sasl authentication

How do I configure an off-site backup mail host?

Configuring a backup mail server will provide a secondary mail server that will accept mail for your primary server in the event your primary server goes down or is otherwise unavailable on the internet. The backup server accepts the mail and then relays the messages to the primary server when the primary server comes back online. Configuring a backup mail server is a simple matter and presumes you already have another server with postfix running that is reachable through a separate IP address.

You will need to add the following two lines to your backup mail server's /etc/postfix/

relay_domains =,,,,
relay_recipient_maps = hash:/etc/postfix/relay_recipients

Just list the domains that the backup server is to be the BACKUP FOR under relay_domain. I have the six above. Next, include in the /etc/postfix/relay_recipients file the email addresses that the backup server will allow. Make sure you include an address for each_USER@each_DOMAIN. I just do it explicitly rather than some other fancy way like using regular expressions (RE's). The format for the file is:                x         x         x              x              x                x         x           x                x              x

Of course run: "postmap hash:/etc/postfix/relay_recipients && rcpostfix reload" to create the new hash table and reload postfix.

The last step to making your backup mail server active is to add a new mx record to your DOMAIN PROVIDER DNS so that the world will know that is the backup mail server to Basically, if IP is and it includes a mx record of:

MX      10

and is, you will add the entry under your DNS as follows:

MX      10
MX      20

The numbers 10 and 20 in the mx record entries, just set the mail server priority. So if 10 is unreachable, then mail will be delivered to the next higher number mail host, 20. The numbers just a well could have been 12 and 13, just so the priority is what you need.


There are probably 100 different ways to configure spamassassin to filter mail on your server. Of all the ways I have looked at, the follow method is by far the simplist and most reliable I have found to be able to utilize secure imap (IMAPS) and be able to:

  • easily control level of spam identification (in ~/.procmailrc)
  • filter known spam into a separate mail folder for review and deletion (folder: spam)
  • filter mail that is probably spam into a separate folder for review and either addition to spamassassin's spam filter or have spamassassin "un-learn" the message characteristics so it isn't flagged as spam next time (folder: spam-probably)
  • have spamassassin automatically learn what is spam from reading the messages in a folder and then deleting them for me (folder: spam-learn)
  • have spamassassin automatically "un-learn" what is NOT spam from reading the messages copied to a folder and then deleting the copies for me (folder: spam-unlearn)
  • have the learn and un-learn filtering done automatically by cron so my involvement in the process is limited to deleting messages in (spam) after review, moving messages to (spam-learn) that I want spamassassin to learn and copying messages to (spam-unlearn) that I want spamassassin to not flag as spam again; and finally
  • have a setup that requires no maintenance other than having to regenerate the IMAP certificates once a year after they expire

Save your old ~/.spamassassin directory and recopy to your new install to save the spamassassin filter training you have accomplished to date.

The following method accomplishes all of the requirements I have for spam filtering. To begin with, create 4 imap mail folders under your (or each user's) mail root, ( usually ~/Mail or ~/mail ). From your home directory, simply issuing "touch Mail/{spam,spam-learn,spam-probably,spam-unlearn}" will do the trick. Then don't forget to "chmod 0600 Mail/{spam,spam-learn,spam-probably,spam-unlearn}". You should then have the following mailboxes created:


Create your ~/.procmailrc

Create your promail recipe in ~/.procmailrc setting spamc as the handler, your spam level and setting the mailbox for suspected spam. This allows postfix to pass incoming messages to procmail which then invokes spamassassin for filtering the mail (just copy and paste into the user's ~/.procmailrc file):

:0fw: spamc.lock
* < 128000
| spamc

* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

* ^X-Spam-Status: Yes

* ^^rom[ ]
  LOG="*** Dropped F off From_ header! Fixing up. "

  :0 fhw
  | sed -e '1s/^/F/'

Create a script to run spamassassin's sa-learn to memorize new spam messages and to unlearn messages marked as spam that are actually not spam (ham). For the remainder of this example, the script name is "Learn_as_spam.cron". The script simply calls fetchmail twice. Once to scan the (spam-learn) folder and learn the messages as spam. The next call does the opposite telling spamassassin to read the (spam-unlearn) folder and learn the message characteristics of the contents are NOT spam. The script is:

For UW imap (prefix folder with Mail/)

/usr/bin/fetchmail -a -s -n --folder Mail/spam-learn -m '/usr/bin/sa-learn --spam'
sleep 2
/usr/bin/fetchmail -a -s -n --folder Mail/spam-unlearn -m '/usr/bin/sa-learn --ham'

For Dovecot

Note: no prefix is required with mail_location = mbox:~/Mail:INBOX=/var/spool/mail/%u

/usr/bin/fetchmail -a -s -n --folder spam-learn -m '/usr/bin/sa-learn --spam'
sleep 2
/usr/bin/fetchmail -a -s -n --folder spam-unlearn -m '/usr/bin/sa-learn --ham'

A good location for the learn_as_spam.cron script is /usr/local/bin. (remember to use the full path to the script when you create the cron entry or insure that the script location is in the users PATH)

Create your ~/.fetchmailrc

In order to automate retrieval and processing by fetchmail when using secure IMAP, you must specify the IMAP fingerprint in the users ~/.fetchmailrc file. The IMAP fingerprint is NOT the same as the x509 certificate fingerprint.

To get the correct IMAP fingerprint to use in the ~/.fetchmailrc file, simply run fetchmail to check the mail in any user's inbox with the verbose option for fetchmail specified. It will fail due to a mismatch in the fingerprint but it will return the correct fingerprint it expected. A simple way to get the correct fingerprint is:

/usr/bin/fetchmail -c -v | grep fingerprint

	(you will be prompted for the password)


nirvana:~> /usr/bin/fetchmail -c -v | grep fingerprint
Enter password for
fetchmail: Server certificate verification error: self signed certificate
fetchmail: key fingerprint: AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99

Create a ~/.fetchmailrc file for each user so that fetchmail can retrieve messages for filtering automatically when called from cron. The ~/.fetchmailrc file goes in the user's home directory and simply tells fetchmail which mailhost to poll and provides the username, password and IMAP fingerprint to securely access the mail server. In order to maintain security make sure the ~/.fetchmailrc file can only be accessed by the user. You can accomplish this by setting the file permissions to 0600. You may specify more than one mail host in the .fetchmailrc file (one per line). I use the following:

poll <> protocol IMAP : user <yourusername> with password <yourpassword> ssl sslfingerprint <"AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99">

(the fetchmailrc line above is a single line or text)

chmod 0600 .fetchmailrc

Finally install the crontab to run Learn_as_spam_cron hourly with "crontab -e" and enter the following for the cron entry:

0 * * * * /usr/local/bin/Learn_as_spam_cron
back to top

8. apache2 Web Server

Create your webserver directories and then create httpd.conf.local to provide access. Don't forget to modify /etc/sysconfig/apache2 and include your new config file. The line should read:


The basic directory structure I would recommend putting in place under /srv/http/ (or whatever your server root happens to be) for holding your web content would be something similar to the following. There is nothing magic here, it simply provides a convenient way to separate your css from your js from your content, etc.:


For https:// setup utilizing mod_ssl, see: Configuring Apache2 SSL for https
Further apache pages can be found at: The Apache Download Directory

Getting Essential Web Applications

(a.) squirrelmail - svn install from

1.5.x Tree (current devel)
svn checkout

1.4.x Tree (current stable)
svn checkout

Upgrading SM:

cp -Rp squirrelmail squirrelmail.bak 	# backup old SM
install new SM
cp squirrelmail.bak/data/* squirrelmail/data
cp squirrelmail.bak/config/config.php squirrelmail/config
chown -R wwwrun:www squirrelmail/data

Configure or re-check (if upgrade) SM configuration


(b.) eGroupWare svn (notice the trailing "." below)

svn checkout"branch"/aliases/default .

for Version 1.6

svn checkout .

for individual components cd ../egroupware

svn checkout"package"

This assumes you have already installed mysql and egroupware on the new machine and set a root password for mysql. If you haven't installed egw yet, I recommend pulling the svn snapshot for 1.6. I have used the trunk version since, but with the 1.6 release, it was recommended to stay with the svn version for 1.6. I have had no problems with the svn version and you benefit from bugfixes with each 'svn update *'. To checkout the svn version for 1.6

cd to your document root

svn checkout .

Note the (.) period at the end, it is not a typo

For the development version you have to use:

svn checkout .

Moving eGroupWare from One Computer to Another

(1) dump your mysql data from egroupware to a file that can be reloaded into mysql. This is better than attempting to simply load a backup due to mysql version changes.

To dump all databases in mysql to reinstall

#mysqldump --all-databases -u root -p > all_databases.sql

To dump only egroupware database:

#mysqldump --databases egroupware -u root -p > egroupware.sql

(2) reload the mysql data into your new mysql installation

#mysql -u root -p < all_databases.sql
(if you dumped all databases)

#mysql -u root -p egroupware < egroupware.sql
(if you only dumped the egroupware database)

(3) If you loaded only the egroupware database, then you will need to set the permissions, username and password for the egroupware user in mysql:

#mysql -u root -p >mysql GRANT ALL ON egroupware.* TO 'egwuser'@'localhost' > IDENTIFIED BY 'some_pass';

(4) Create the directories where egw will store its files and backups and make sure your web server has write permission.

Also, you can copy your old to /egroupware before running setup, but *make sure* to confirm each entry matches your new server by running header config during setup. Don't just assume your document root is the same on the new server as it was on the old server.

Note: if you are using an eGroupWare version prior to 1.6, I would recommend recreating the as there have been some changes lately.

(5) Start egw with

Fix any errors and load any need php or pear modules. Run /setup "Header config" and confirm you documents root, etc..

(6) Login, your done, all your records, calendars, alarms, links, etc. will be just where you left them when your dumped mysql.

back to top

9. pptp VPN server

Note: Requires port 1723 open in firewall/router for remote access. For openSuSE 10.3 you will have to create /etc/pptpd.conf

option /etc/ppp/options.pptp
debug (comment out after testing)
pidfile /var/run/

lcp-echo-failure 10
lcp-echo-interval 10

lcp-echo-interval 30
lcp-echo-failure 4
lcp-max-configure 60
lcp-restart 2
idle 600
file /etc/ppp/filters

david   *   password
david   password  *

##/etc/ppp/chap-secrets (even though you are requiring pap)
david           *               password          *

Note: Do NOT forget to open port 1723 in your firewall for remote access. If you have an earlier version of pptpd, you may need to enable "bcrelay" to improve windows client name resolution.

Tweaks for a good server

First, one of the beneficial scheduling items to take care of is to schedule the dailey system cron scripts (mandb, updatedb, etc.) to run when nobody is using the server (0400 sounds good). Use Yast to set the run time to your desired time. If you have a number of cron scripts running on the hour, then set the time on a few in the middle of the hour. (e.g. 0420). (yes, I know it doesn't matter, but why have them all start at 00 when you can spread the load out)

That's it for my nuts and bolts reference for setting up a server, have fun and enjoy. If there are any errors or changes, feel free to contact me at drankinatty <at> suddenlinkmail <dot> com.

  1. See the following bugzilla.novell bugs related to sudo and kdesu.
  2. Yast Ncurses - Unable to set sysconfig/System/Cron/DAILEY_TIME
  3. There are a number of ways to set your system time: Yast -> System -> Date&Time; in KDE right-click on the clock; or my favorite, just use the date command. The formatt is: date [MMDDhhmmYYYY]. For example, for January 24, 2009 at 1:30 am, you would simply enter: 'date 012401302009'

Developed in KDE3:

Quanta+ from KDE3 KDE3 now developed as Trinity Desktop