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
- Preliminary Post Install Cleanup
- BIND 9 DNS (primary & backup)
- dhcpd (with dynamic updates to DNS)
- MySQL - Securing Your Server
- Samba (stand-alone server, pdf-gen script included)
- ntp - Network Time Protocol
- Postfix, Dovecot & SpamAssassin
- Apache2 Web Server with SSL
- 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 \
totem-plugins
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
%wheel ALL=(ALL) NOPASSWD: ALL
Now simply edit /etc/group or use yast and add yourself to the wheel group:
11:24 ecstasy:~> cat /etc/group <snip> wheel:x:10:david
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 mybox.mydomain.com is at address 192.168.1.23. 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 yahoo.com is at 206.190.60.37 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/genDDNSKey.sh (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:
NAMED_CONF_INCLUDE_FILES="/etc/named.keys"
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 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
options {
directory "/var/lib/named";
dump-file "/var/log/named_dump.db";
statistics-file "/var/log/named.stats";
forwarders { 208.180.42.68; 208.180.42.100; 68.1.208.30; }; # your ISP dns boxes
forward first;
allow-transfer { 192.168.7.14; }; # only allow backup DNS server to copy zones
#listen-on port 53 { 127.0.0.1; };
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 "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone "rbpllc.com" in {
file "dyn/rbpllc.com";
type master;
allow-update{ key DHCP_UPDATER; };
};
zone "7.168.192.in-addr.arpa" in {
file "dyn/192.168.7.zone";
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/rbpllc.com" and "dyn/192.168.7.zone" ) 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 "rbpllc.com" in {
file "dyn/rbpllc.com.zone";
type slave;
masters {
192.168.7.15;
};
};
zone "7.168.192.in-addr.arpa" in {
file "dyn/192.168.7.zone";
type slave;
masters {
192.168.7.15;
};
};
where the masters IP address ("192.168.7.15") 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 127.0.0.zone 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 localhost.zone 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 192.168.7.zone -rw-r--r-- 1 named named 812 2008-01-04 23:31 rbpllc.com.zone
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/rbpllc.com.zone
$ORIGIN .
$TTL 172800 ; 2 days
rbpllc.com IN SOA bonza.rbpllc.com. root.bonza.rbpllc.com. (
2008010400 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS bonza.rbpllc.com.
NS fax.rbpllc.com. ; ** The backup server
MX 0 bonza.rbpllc.com.
$ORIGIN rbpllc.com.
gw A 192.168.7.13
fax A 192.168.7.14
bonza A 192.168.7.15
ftp CNAME bonza
mail CNAME bonza
www CNAME bonza
providence A 192.168.7.16
Create the primary server "Reverse" zone file
root@bonza:/srv/http/htdocs # cat /var/lib/named/dyn/192.168.7.zone
$ORIGIN .
$TTL 172800 ; 2 days
7.168.192.in-addr.arpa IN SOA bonza.rbpllc.com. root.bonza.rbpllc.com. (
2008010400 ; serial
10800 ; refresh (3 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS bonza.rbpllc.com.
NS fax.rbpllc.com. ; ** The backup server
$ORIGIN 7.168.192.in-addr.arpa.
13 PTR gw.rbpllc.com.
14 PTR fax.rbpllc.com.
15 PTR ftp.rbpllc.com.
PTR www.rbpllc.com.
PTR mail.rbpllc.com.
PTR bonza.rbpllc.com.
16 PTR providence.rbpllc.com.
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:
DHCPD_CONF_INCLUDE_FILES="/etc/named.keys"
Create dhcpd.conf
root@bonza:/srv/http/htdocs # cat /etc/dhcpd.conf
# dhcpd.conf
#
# option definitions common to all supported networks...
option domain-name "rbpllc.com";
option domain-name-servers 192.168.7.15;
option routers 192.168.7.13;
option ntp-servers 192.168.7.15;
option netbios-name-servers 192.168.7.15;
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.
authoritative;
subnet 192.168.7.0 netmask 255.255.255.0 {
option domain-name "rbpllc.com";
ddns-domainname "rbpllc.com";
option subnet-mask 255.255.255.0;
range dynamic-bootp 192.168.7.110 192.168.7.150; #range of IPs to hand out
default-lease-time 28800;
max-lease-time 172800;
zone rbpllc.com. {primary 127.0.0.1; key DHCP_UPDATER; }
zone 7.168.192.in-addr.arpa. { primary 127.0.0.1; 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 Rankin-P35a.rbpllc.com {
hardware ethernet 00:11:f5:15:2d:83;
fixed-address 192.168.7.101;
}
# we want the copier/scanner to appear at a fixed address
host SC1FC09D {
hardware ethernet 08:00:1F:1F:C0:9D;
fixed-address 192.168.7.20;
}
}
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'@'127.0.0.1' = PASSWORD('newpwd');
hostname statements are optional
Confirm by:
mysql> select host, user, password from user;
Setting up users
GRANT ALL PRIVILEGES ON *.* TO 'user'@'localhost' IDENTIFIED BY 'some_pass' WITH GRANT OPTION; GRANT ALL PRIVILEGES ON *.* TO 'user'@'hostname' IDENTIFIED BY 'some_pass' WITH GRANT OPTION; GRANT ALL PRIVILEGES ON *.* TO 'user'@'hostname.domain' IDENTIFIED BY 'some_pass' WITH GRANT OPTION; GRANT ALL PRIVILEGES ON *.* TO 'user'@'127.0.0.1' IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
Updating password for existing users
mysql> UPDATE mysql.user SET Password = PASSWORD('newpwd') WHERE User = 'root';
mysql> FLUSH PRIVILEGES;
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:
[mysqladmin] 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 Samba.org or specifically www.samba.org/samba/docs/.
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:
/home/samba /home/samba/accounting /home/samba/sourcefiles
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/smb.conf.save'
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.
[global]
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 = 192.168.7.14
[homes]
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!
##
[config]
comment = Admin Config Share
path = /
valid users = yourself
force user = root
force group = root
admin users = yourself
browseable = no
writeable = Yes
[samba]
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
[accounting]
comment = Accounting Share
path = /home/samba/accounting
valid users = @groupnameforaccountingusers
force group = accountinggrouptoownthefiles
admin users = yourself
writeable = Yes
inherit permissions = Yes
[sourcefiles]
comment = File Share for the Programmers
path = /home/samba/sourcefiles
guest ok = Yes
force group = codemonkeys
admin users = yourself
writeable = Yes
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
guest ok = yes
writable = no
printable = yes
create mode = 0700
[print$]
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'
[pdf-gen]
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 Samba.org 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:
rcnmb rcsmb 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
Troubleshooting
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/smbd.pid 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/smbd.pid rm /var/run/samba/nmbd.pid 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 pool.ntp.org that organizes servers by region and then assigns servers for you.
Making Use of The ntp Pool
pool.ntp.org 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:
server 0.us.pool.ntp.org server 1.us.pool.ntp.org server 2.us.pool.ntp.org server 3.us.pool.ntp.org
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
ntp3.tamu.edu 128.194.254.7 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
207.55.146.19 .INIT. 16 u - 64 0 0.000 0.000 4000.00
Using pool.ntp.org 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: http://www.3111skyline.com/download/linux/howto/UW_IMAP_SSL-setup.txt
Dovecot
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 sh makecrt.sh
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 mkcert.sh script or it will refuse to overwrite them. (or you can comment out the last two 'if' statements in mkcert.sh, 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 yourmailhost.yourdomain.com:993 -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, rankinlawfirm.com, drrankin.com, txuovercharges.com, guillorylaw.com myhostname = bonza.rbpllc.com mynetworks_style = subnet myorigin = $mydomain smtpd_client_restrictions = check_client_access cidr:/etc/postfix/client_check.cidr, reject_rbl_client relays.ordb.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org 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 main.cf 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/main.cf.
Configure Specific Relay Authentication
How can I configure postfix to allow this user to send mail outbound from my server?
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/clients_relay_allowed reject_unauth_destination,
/etc/postfix/clients_relay_allowed: #These clients are allowed to relay! 1.2.3.4 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/main.cf:
relay_domains = rbpllc.com, rankinfirm.com rankinlawfirm.com, guillorylaw.com, drrankin.com, txuovercharges.com 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:
user1@rbpllc.com x user1@rankinlawfirm.com x user2@rankinlawfirm.com x user3@guillory.com x user4@guillory.com x user5@rbpllc.com x user5@rankinlawfirm.com x user5@guillorylaw.com x user6@rbpllc.com x user7@drrankin.com 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 yourbackupdomain.com is the backup mail server to yourprimarydomain.com. Basically, if yourprimarydomain.com IP is 86.58.27.70 and it includes a mx record of:
MX 10 mail.yourprimarydomain.com.
and yourbackupdomain.com is 86.58.27.159, you will add the entry under your yourprimarydomain.com DNS as follows:
MX 10 mail.yourprimarydomain.com. MX 20 mail.yourbackupdomain.com.
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.
SpamAssassin
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:
~/Mail spam spam-learn spam-probably spam-unlearn
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
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
Mail/spam
:0:
* ^X-Spam-Status: Yes
Mail/spam-probably
:0
* ^^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/)
#!/bin/bash /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
#!/bin/bash /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 yourmailhost.yourdomain.com | grep fingerprint (you will be prompted for the password)
Example:
nirvana:~> /usr/bin/fetchmail -c -v yourmailhost.yourdomain.com | grep fingerprint Enter password for user@yourmailhost.yourdomain.com: fetchmail: Server certificate verification error: self signed certificate fetchmail: yourmailhost.yourdomain.com 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 <yourmailhost.yourdomain.com> 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:
APACHE_CONF_INCLUDE_FILES="/etc/apache2/httpd.conf.local"
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.:
cgi-bin css download gd htdocs icons images js vhosts
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 http://www.squirrelmail.org/download.php
1.5.x Tree (current devel) svn checkout http://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail/trunk/squirrelmail 1.4.x Tree (current stable) svn checkout http://squirrelmail.svn.sourceforge.net/svnroot/squirrelmail/branches/SM-1_4-STABLE/squirrelmail
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
squirrelmail/config/conf.pl
(b.) eGroupWare svn (notice the trailing "." below)
svn checkout http://svn.egroupware.org/egroupware/branches/"branch"/aliases/default .
for Version 1.6
svn checkout http://svn.egroupware.org/egroupware/branches/1.6/aliases/default .
for individual components cd ../egroupware
svn checkout http://svn.egroupware.org/egroupware/branches/1.6/"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 1.0.0.6, 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 http://svn.egroupware.org/egroupware/branches/1.6/aliases/default .
Note the (.) period at the end, it is not a typo
For the development version you have to use:
svn checkout http://svn.egroupware.org/egroupware/trunk/aliases/default .
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 header.inc.php 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 header.inc.php as there have been some changes lately.
(5) Start egw with www.yourdomain.com/egroupware/setup
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
##/etc/pptpd.conf option /etc/ppp/options.pptp debug (comment out after testing) localip 192.168.7.12 remoteip 192.168.7.2-5 pidfile /var/run/pptpd.pid ##/etc/ppp/options.pptp lock noauth nobsdcomp lcp-echo-failure 10 lcp-echo-interval 10 ##/etc/ppp/options name bonza.rbpllc.com noipdefault noauth lock local lcp-echo-interval 30 lcp-echo-failure 4 lcp-max-configure 60 lcp-restart 2 idle 600 noipx file /etc/ppp/filters proxyarp ms-dns 192.168.7.15 ms-wins 192.168.7.15 refuse-chap refuse-mschap ##/etc/ppp/pap-secrets david * password 192.168.6.20 or david nirvana.3111skyline.com 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.
- See the following bugzilla.novell bugs related to sudo and kdesu.
https://bugzilla.novell.com/show_bug.cgi?id=446947
https://bugzilla.novell.com/show_bug.cgi?id=400903 - Yast Ncurses - Unable to set sysconfig/System/Cron/DAILEY_TIME
https://bugzilla.novell.com/show_bug.cgi?id=461868 - 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'
