Installing SuSE 8.2

I wrote this more for my reference than anything else. After Red Hat screwed everything up, I migrated to SuSE 8.2 after a very long and thorough evaluation of all the other major distributions out there, and I was determined to ride out the two years of support they provide. I have been enormously happy with my decision, even before the fantastic news of SuSE and Ximian’s acquisition by Novell, and their subsequent encouraging press releases. I’ve been using 9.0 with Ximian Desktop on the desktop, and I really don’t know how it could be better. I’m on pins and needles waiting for 9.1, and I can’t wait to see what will happen when Novell has had a chance to fully integrate SuSE and Ximian with their stated soup-to-nuts philosophy of taking over the enterprise.

Important! This material assumes that you are already familiar with Linux in general, of course, but also with SuSE Linux, at least in passing. If you need help in getting up to speed on the general aspects of how SuSE works (which is really quite different that any other distro), you should check out Togan Muftuoglu’s excellent (albeit unofficial) SuSE FAQ.

Also, there are several very good SuSE email lists. In my experience, they differ from Red Hat’s in a significant way. Most messages in a Red Hat list are something like, “This is broken. When will it be fixed?” To which the answer will be “wait until the next beta.” Most messages in the SuSE list are to the effect of, “I want to do thus and so. How do I do it?” There usually follow several viable answers. You can find descriptions of the lists and instructions on how to subscribe here. One thing to note is that they also have an unlisted “off-topic” list at “suse-ot”. (It was interesting, but ultimately too political for me. I mean, I expect suse-ot to be off-topic, but still about SuSE or at least Linux in general, NOT about how George Bush is a “big, fat liar.” Gimme a break.)

Automatic Updating

The heart of the SuSE system is Yast, so it pays to play nicely with it. I like to setup a local mirror of the official updates to the distro, and then configure all of my machines to hit the local mirror. This saves the duplicated bandwidth consumption of having all the machines independently retreive the patches, and it even saves the wear an tear to even have to process the update queries (i.e., even if you don’t need any updates). Good for you, and good for SuSE!

First, I set up a local directory and populate it from a SuSE mirror with the a cron job, like so (which is all one line):

lftp -c 'mirror -e -vvv ftp://<mirror.of.your.choice>/<path/to/i386>/i386/update/8.2/ /data/suse/updates/i386/update/'

OR, if you want to use rsync, which is faster…

rsync -rltv --delete rsync://<mirror.of.your.choice>/<path/to/i386>/i386/update/8.2/ /data/suse/updates/i386/update/8.2/

Then I share that directory with the rest of the network by adding a line like this to the /etc/exports file:

/data           *(ro)

You can start the NFS service with an `rcnfsd start’, but remember to make the service start at boot time with `insserv nfsd’. Once this is configured, you can mount your directory on your client machines, and add the mount points to their /etc/fstab files, like this:

excelsior:/data      /mnt/excelsior/data  nfs        defaults              0 0

Next, you need to edit /etc/youservers and point the update process to your local directory. I have one (uncommented) line in the file:

dir:///mnt/excelsior/data/suse/updates

You won’t need to visit the official update servers, so you can tell online_update to not query them. You need to edit /etc/sysconfig/onlineupdate for this, as well as to have it get the updates you want. Possible examples (from `online_update -help’) are security, recommended, document, and optional. Note that each successive option includes the previous ones. I set mine to “recommended.”

YAST2_LOADFTPSERVER="no" CMDLINE_OPTIONS="recommended"

Finally, you need to tell YaST to setup an automatic update job. You can do this through the GUI, or, if you’re handy with crontabs, you can do it by hand. The YaST GUI will simply create a file in /etc/cron.d named “yast2-online-update” with the following contents:

0 3 * * * root online_update

Note, for those playing along at home, that this is a slightly different format than other crontabs. There’s an extra user argument in there that crontabs, as run from this directory, need.

That should be it! If you’ve got a proper “admin” mail alias, you should see a couple update reports every day, one for the ftp sync, and one for each client that attempts to update. To configure an alias to get the reports, simply add a line in /etc/aliases for root, like this:

root:     user@someplace.org

Then run `newaliases’.

Living with SuSEfirewall2

A lot can be said in this portion, because the SuSEfirewall2 script can do an amazing number of things. In /usr/share/doc/packages/SuSEfirewall2/README, the author makes the claim that this program is the best of its kind anywhere. I was skeptical at first, but now I believe him. So far, there isn’t anything I have wanted to do with a firewall that it can’t do… once you understand how the system works. (It’s especially nice in that it does lots of the fancier things with ICMP and such that are a painfully repetitive to code by hand with raw iptables commands.) The main thing to understand is that the program /sbin/SuSEfirewall2 is a script that reads the file /etc/sysconfig/SuSEfirewall2. All of your configuration should go into the sysconfig file. Read it.

No, really. Go read it. Now. I’ll wait…

The documentation for /etc/sysconfig/SuSEfirewall2 is right there in the file itself. However, due to the fact that this documentation consists, after all, only of comments, and due to the fact that it sometimes shows its German origins, it can be tough to understand. For instance, it can be difficult to understand the difference between the “FW_FORWARD” and the “FW_FORWARD_MASQ” parameters the first time around. Actually configuring the config file is sort of beyond the scope of my intent here. My point is only to demonstrate a few basic necessities.

  • After making a change to the /etc/sysconfig/SuSEfirewall2 file, simply run `SuSEfirewall2′ to get these changes made. Don’t mess about with the /etc/init.d/SuSEfirewall_* files. If you haven’t already, do an `insserv SuSEfirewall_<mode>’ for each and be done with them.
  • If you are used to looking at standard iptables rulesets (as you need to be with other distros), you can look at what /sbin/SuSEfirewall2 is producing by running `SuSEfirewall2 debug’.
  • For a semi-human-readable output of the current ruleset, you can do `SuSEfirewall2 status’. It’s about as good as you’re going to get. In any case, it sure beats doing an `iptables -L’.
  • Be sure to familiarize yourself with the other options to SuSEfirewall2. There are modes of operation for emptying the ruleset (to check to see if your rules are getting in the way of something), closing off the firewall to external traffic (while sorting out what you really wanted to do), and pure panic (while you browse the messages log to find out what damage was done).

Setting up Postfix

I use Postfix for my mail server. It receives mail for davidkrider.com, and it acts as a mail relay for me, no matter where I am, by requiring authentication. I use it to send personal mail even when I’m at work. Furthermore, I encrypt all external communication to and from my server through SSL to keep things personal. On top of all of this, I use some built-in spam prevention in Postfix and add SpamAssassin into the mix as well.

The good part about this configuration task is that the relevant portions can be done with YaST, with the sysconfig file editor, under Network, Mail, Postfix. Then `SuSEconfig –module postfix’ sorts it all out and creates /etc/postfix/main.cf. If you look at that file, you will see a few lines and options that get generated by SuSEconfig over and above the options you explicitly set. It took me a couple tries and a lot of reading before I trusted that SuSEconfig was doing everything it needed to, but it is…

  • Set POSTFIX_LOCALDOMAINS to localhost (default), <your.domain.com>, mail.<your.domain.com>, and any local FQDN’s you might have.
  • Set POSTFIX_RBL_HOSTS to some set of goofball eliminators. I currently use elays.ordb.org, bl.spamcop.net, sbl.spamhaus.org, and proxies.relays.monkeys.com.
  • Set POSTFIX_BASIC_SPAM_PREVENTION to medium. (Hard is a nice idea, but it will drop more mail than you’re likely to want. If you need that much protection, you’re probably not going to be fooling with these automated methods anyway.)
  • Set POSTFIX_MDA to procmail.
  • Set POSTFIX_SMTP_AUTH_SERVER to yes.
  • Set POSTFIX_SMTP_TLS_SERVER to yes.
  • Set POSTFIX_ADD_SMTPD_RECIPIENT_RESTRICTIONS to permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination.
  • Set POSTFIX_ADD_SMTPD_TLS_AUTH_ONLY to yes.

After setting these things, you’ll need to run `SuSEconfig –module postfix’, or, at least `SuSEconfig’. Also, if you use smtpd with authentication, as I’m doing, you’ll need to `rcsaslauthd start’ and `insserv saslauthd’.

Also, after setting this up, and if you decided to use SSL to secure your communications with the email server, you’ll need to generate an SSL certificate to use with it. Just run `mkpostfixcert’, and it will walk you through this.

Update: Since the onslaught of the “Swen” virus, I have instituted a policy of blocking email with most types of attachments. This is doubly good, because SpamAssassin was having a hard time learning them, and I get to stop wasting the bandwidth while 200 150 KB messages per day (or so) spool up on my disk to be deleted. To do this, I finally discovered this tutorial at SAGE, specifically, this page. All you need to do is create a /etc/postfix/maps directory, and place this file in there. Then add a line to /etc/sysconfig/postfix like `POSTFIX_ADD_MIME_HEADER_CHECKS=”regexp:/etc/postfix/maps/mime_header_checks”‘, and then do the `SuSEconfig –module postfix’ and `rcpostfix reload’ thing.

NOTE BENE!!! If you run your email server on your firewall, you might have a problem. Please, please, listen carefully before emailing me about this, because you must understand the accumulation of circumstances here in order to know if you are affected by it. The default config for postfix, as shipped by SuSE will configure your email server as an open relay for all of your network interfaces. Normally, you would have an email server sitting behind a firewall, and this would not be a problem, as you probably want to relay mail for your local network. However, if you have your email daemon running, again, on your firewall, and you have a broadband connection with a shared subnet, this will leave you running as an open relay to everyone on your subnet! If you fall into this category, don’t panic. The answer to this is simple. You merely need to add a parameter to /etc/sysconfig/postfix like so, remembering to change “192.168.0.0/24″ to something appropriate for your internal network:

POSTFIX_ADD_MYNETWORKS="192.168.0.0/24, 127.0.0.1/32"

Configuring SpamAssassin

There are only a couple things you need to do to start getting SpamAssassin working. First, after you’ve setup your MTA to use procmail as your MDA, you need to edit /etc/procmailrc. Mine utilizes the much quicker spamc/spamd setup over the direct /usr/bin/spamassassin method. (Don’t forget to `rcspamd start’ and `insserv spamd’!) It looks like this:

:0 hbfw | /usr/bin/spamc

Now you can edit /etc/mail/spamassassin/local.cf. I especially like how they’ve included the “defang mime” option in this version. Again, it looks like this:

rewrite_subject 0 report_header 1 use_terse_report 1 defang_mime 1

Finally, you’ll probably want to do something with the tagged mail in your local ~/.procmailrc file. Once more, mine looks like this:

:0: * ^X-Spam-Status: Yes /dev/null

You’ll note that I’m just throwing away my SpamAssassin-tagged mail. I have come to trust it well enough that I can do this. You may want to do something else, like collect them in a separate folder for later review. With all these filters in place, you’d think I’d never see spam, but that’s — unfortunately — not the case. I still get one every day or so. On the other hand, I’m catching about 100 a day!

Setting up IMAP

This has become a Frequently Asked Question on the SuSE mailing list. (Subscribe here if you’re not already a subscriber.) It’s a bit convoluted, so you’ll have to bear with the long-winded explanation.

The problem lies with the fact that SuSE has compiled the imap-2002 package so that it won’t accept plaintext passwords. You have two options with the stock package. You can either make a CRAM-MD5 password database, or you can enable SSL authentication. Or, as a third, overarching option, you can recompile the package to support plaintext authentication again. I will describe all 3 ways and let the reader determine for himself which best suits his needs.

Making a CRAM-MD5 password database

By default, the uw-imap package will perform authentication of CRAM-MD5-encrypted passwords. Unfortunately (or fortunately), this requires a separate password database to be created. This is unfortunate if you just want the regular users of the machine to be able to retrieve their mail with IMAP or POP. On the other hand, this is fortunate if you want to setup a system where the main mail users don’t necessarily have shell accounts. For example, this might work well for a Samba server. The bottom line is that it’s just a pain to keep track of two different databases. Once you’ve installed the imap-2002 package, the instructions for setting up this secondary password database are clearly described in /usr/share/doc/packages/imap/md5.txt, and I won’t rehash them here. If you set up IMAP to work like this, just remember to set your email client to do CRAM-MD5 passwords.

Enabling IMAP over SSL

This is sort of the “right” way of doing this. By “right,” I mean “the way that best fits the ‘SuSE way’ of doing things.” And by that, I mean that this way will ensure that if and when SuSE releases a security update for any of these packages, the automatic update I’ve described elsewhere can just be allowed to perform the updates, and everything should continue to work, no recompiling required, no extra maintenance work.

Installing the imap-2002 package will require an inetd service, and I think you should install the xinetd package to satisfy this requirement. The following instructions apply to this particular package. If you want to run the older inetd package, you probably have your reasons, and can alter these instructions to your taste.

First, edit the /etc/xinetd.d/imap file, and add a stanza like so:

# imaps - SSL-encrypted imap mail daemon
# service imaps {
   disable         = no
   socket_type     = stream
   protocol        = tcp
   wait            = no
   user            = root
   server          = /usr/sbin/imapd
   server_args     = -s
   flags           = IPv4
}

Note the addition of the “s” on the service name and the extra “server_args” line. (Also don’t forget to change the “disable” line to “no” if you copy and paste the existing imap service config. I forget this a lot of the time.) Now you can do an `rcxinetd reload’ to reread the config, and you should be able to see a service called “imaps” running when you do a `netstat -a –inet’. You should now be able to use IMAP over SSL (port 993) with your existing account passwords. One last thing: be sure to do a `insserv xinetd’ after setting this up so that it will start after a reboot.

Next, you’ll need an SSL certificate in order to encrypt the transmission of data from the server to the client. However, the very first thing you need to do is update the openssl package that gets installed by default. An update was released for this package not long after the distro itself was released. The original version looks for certificates in a different place than the update, and you may as well get this out of the way lest you break your system down the road. To actually create the certificate, you can follow the instructions listed in this SuSE database article, which basically is:

cd /etc/ssl/certs openssl req -new -x509 -nodes -out imapd.pem -keyout imapd.pem -days 365

Recompiling the imap-2002 package to accept plaintext passwords

If you’ve never recompiled an RPM, don’t be discouraged. There’s not much to it, if you have a source RPM to work from. This works a lot like my HOWTO for installing the Microsoft FrontPage extensions on Red Hat. Just switch to the root account and follow these steps:

  • Install the imap-2002 source RPM. Note that this package has been updated since the 8.2 release, and you’ll need to get it from an updates FTP mirror. 
    rpm -ivh imap-2002-45.src.rpm
  • Switch to the /usr/src/packages/SPECS directory. Edit the imap.spec file to change “SSLTYPE=nopwd” to “SSLTYPE=unix”. This is found on line 83 of the version of the file that I’m documenting here. 
    make lnp MYCFLAGS="$CFLAGS" SSLTYPE=unix
  • Issue the following command: 
    rpm -bb imap.spec

  • PLEASE NOTE!!!

    If you are trying to address the situation by using this method, and you are on SuSE 9.0 or newer, you’ll need to change the way you rebuild the package. Instead, do `rpmbuild –rebuild imap.spec’. (This page is supposed to be about 8.2, but I keep getting email about this…)

  • You will now find 3 new RPM’s in /usr/src/packages/RPMS/i386. You’ll need to install the imap-2002-45.i386.rpm and imap-lib-2002-45.i386.rpm packages in order to use IMAP. (You would install the “-devel” RPM if you needed to compile some program that was dependent on imap functionality, but I don’t know of a good example.) Simply (in case you’re only used to YaST for installing packages): 
    rpm -ivh imap-2002-45.i386.rpm imap-lib-2002-45.i386.rpm

After installing these packages, you will need to edit the “imap” stanza in /etc/xinetd.d/imap and set the “disable” line to “no”. Then, start or reload xinetd, and you should be able to accept plaintext authentication for IMAP over port 143. I would hope that you are doing this for only entirely-internal traffic…

Installing Apache

I’ll just state for the record that I had a devil of a time getting this back together again. After getting it all configured on my main server at home, I’ve had to reinvent the wheel on how to get SSL going again. I suppose it’s just a lesson on how I ought to be better at documenting everything I do with computers. I’m too old to keep reinventing the wheel any more.

First of all, I don’t like how SuSE puts the web root at /srv/www. I suppose it doesn’t matter that I always change it from the Red Hat default of /var/www anyway, it’s just that even if you left it alone, it still wouldn’t be in what is probably a secondary mountable partition. (At least, I like to keep /var in a different partition, in case the logs go haywire.) So, the first thing I do is make a directory called /home/wwwrun, and put all the web content underneath that, each virtual web in its own directory.

Now then, this is where YaST is going to factor into your efforts in a very significant way. Use it to edit the sysconfig file for apache, and turn on all the modules you want to use, like PHP, SSL, and, for instance FrontPage. You should also create a separate file into which you place all your customizations, and use YaST to include this in your configuration. (I, surprisingly enough, call mine “custom.conf.”) The variable for this is called “HTTPD_CONF_INCLUDE_FILES”. Override any configuration directives from the main, httpd.conf file in this custom one, and leave the main alone. Otherwise, YaST won’t upgrade it along with bug fixes.

Adding FrontPage Extensions

After installing the mod_frontpage RPM, you’ll need to make a symbolic link. (At least, you will as of the time of this writing. They may fix this like the CUPS links.) Just do `ln -s /usr/lib/frontpage /usr/local’.

Next, you’ll need to create a user account to act as the FrontPage administrator. I don’t know if you’ll find this in any of the documentation, but the account will need a user id greater than 500, and a group id greater than 100.

Next, `chown’ the directories in which you will install the extensions to the user and group of the FrontPage administrator account you created.

Be sure to edit your apache configuration file to include the “AllowOverride All” directory.

Last, use the fpsrvadm.exe program actually install the extension stubs into the driectory containing the virtual web.

Configuring Squirrelmail

Because of the convolutions of working with the imap-2002 package, you’ll need to jump through a hoop or two to get Squirrelmail running. Now, as I understand it, Squirrelmail can do CRAM-MD5 passwords, so if you’ve chosen that route with IMAP, you can still use it. However, I’ve not tried this. I’ve chosen to use IMAP over SSL. Unfortunately, Squirrelmail doesn’t support this yet. The good news is that you can “fool” Squirrelmail with stunnel.

This procedure will configure a service that will listen at the normal, non-SSL IMAP port (143) and relay the connection attempts it gets there to the SSL-enabled port (993). Along the way, it will encrypt the traffic with SSL. The end result is that Squirrelmail can connect to the server the way it wants to, and it will be connected to the IMAP daemon the way it wants to be connected to. It’s acting as a middleman to get them to work together.

Note bene (note very well): If I had Squirrelmail working on a separate box from my web / email server, I would not be doing it this way. The logins from Squirrelmail are still hitting the server in clear text. If this authentication traffic needed to go through an untrusted network, then you would need to do something about this. In my situation, Squirrelmail sits on my web and email server, so the traffic never hits the wire, and therefore cannot be sniffed. (If my box was “rooted,” then someone could supplant the process and capture passwords, but, then, if you’re root, you could just read peoples’ mail anyway.)

You’ll need to edit the /etc/stunnel/stunnel.conf file. Change the “client” line to “yes” at the top of the file. Then make a stanza like so:

[imap] accept  = 143 connect = 993

Note that the “[imap]” line is not optional. (At first, I thought this was just for decoration, because all the examples are commented out of the default file. Not so.)

Now you’ll need to whip up an SSL certificate. I simply used the example command shown in /usr/share/doc/packages/stunnel/README.SuSE.

(umask 077; /usr/bin/openssl req -new -x509 -days 365 -nodes -config /usr/share/doc/packages/stunnel/stunnel.cnf -out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem)

This will place the certificate in the same directory as the conf file, and that’s where the conf file is looking for it anyway. Once this is in place, you can start the stunnel service with `/etc/init.d/stunnel start’. You can double check to see if it’s running with `netstat -a –inet’. You should see a line like this:

tcp        0      0 *:imap         *:*            LISTEN

As always: don’t forget to set the service to start at boot time with `insserv stunnel’.

On top of all the SSL stuff required to get the actual Squirrelmail process to communicate with the IMAP daemon, I like to use SSL to encrypt the web traffic to and from Squirrelmail over potentially insecure networks. Like, say, the internet. To do this, you’ll actually be securing Apache. You can make an SSL key for it by running these two commands:

openssl genrsa -out server.key 1024 openssl req -new -x509 -days 365 -key server.key -out server.crt

Then you’ll need to put the key and the certificate in the appropriate subdirectories in /etc/httpd. After that, I create another virtual web server to operate over SSL in my (previously discussed) custom.conf. I probably shouldn’t be doing this, but setting this up for the first time can be a real pain. Note that “your.webserver.com” and “/some/other/directory” are, obviously, going to have to be changed to whatever is appropriate for your setup.

<VirtualHost *:443>
    ServerName <your.webserver.com>
    SSLEngine On
    SSLCertificateFile /etc/httpd/ssl.crt/server.crt
    SSLCertificateKeyFile /etc/httpd/ssl.key/server.key
    DocumentRoot </some/other/directory>
    Alias /mail "/srv/www/htdocs/squirrelmail"
    <Directory /srv/www/htdocs/squirrelmail>
        Options Indexes Includes FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

NVidia Performance Tweaks

If you have an NVidia video card, and you want OpenGL acceleration for video gaming, you’ll need to download the Linux driver at NVidia’s site. If you don’t care about 3D graphics, then it’s fine to stick with the default, generic NVidia video card driver that comes with XFree86. Apparently, you can “install” the driver by using the “Download NVIDIA© Graphics Driver” from YOU (YaST Online Update), but this is an extra layer that I don’t need, and so I’ve not tried it. The raw driver from NVidia has been made into a single shell script that handles everything, including the ability to both update and uninstall itself.

The only trick here is that after installing the driver, you’ll still need to run `sax2′ as root. This is yet another X configurator, but it works pretty well. I need it especially to set my monitor timings. After installing the NVidia driver (by hand or by YaST), you can choose to enable “3D Acceleration” during the configuration with SaX2. This will set the /etc/XF86Config file to use the “nvidia” driver instead of the “nv” driver. (You can make this change by hand as well.) The NVidia driver installation process causes a line to be written into /etc/modules.conf that will load the kernel module at boot time.

Up to this this point, this process will allow you to run OpenGL-accelerated programs, but you can go further to get the best performance out of your equipment. By default, the NVidia driver won’t take advantage of AGP, let alone a couple advanced features of AGP. It avoids this to err on the side of caution, as using these capabilities can apparently lead to system instability, lockups and such. I have enabled these features on my system and found no such problems. Your mileage may vary.

First, you’ll need to load another kernel module: “agpgart.” If this whole process works, you’ll want to add it to your bootup process by editing /etc/sysconfig/kernel. Simply add “agpgart” to the line labelled “MODULES_LOADED_ON_BOOT.”

Next, you’ll need to add another line to the /etc/X11/XF86Config file. It should go in the “Device” section (along with the NVidia card info) and look like this:

Option       "NvAgp" "3"

The documentation for this option can be found in /usr/share/doc/NVIDIA_GLX-1.0/README. Basically, the “3″ allows the NVidia driver to try using the better agpgart interface to the card before trying the default (but still NVidia) agp interface.

At this point, you may want to make sure that the NVidia kernel module is loaded and try starting X. While this is a good start, there are a couple of tweaks you can perform to make your NVidia card run even better. Unfortunately, this isn’t documented in the README file. I stumbled upon it through Google.

Once all the basic setup is running correctly, have a look at the output from the following command: `cat /proc/driver/nvidia/agp/*’. The first 4 lines will show facts about your video card, the next 5, your motherboard, and the rest, your current status. My output, after setting everything up, looks like this:

Fast Writes:     Supported
SBA:             Supported
AGP Rates:       4x 2x 1x
Registers:       0x1f000217:0x0f000314
Host Bridge:     Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller
Fast Writes:     Supported
SBA:             Supported
AGP Rates:       4x 2x 1x
Registers:       0x0f000217:0x00000314
Status:          Enabled
Driver:          AGPGART
AGP Rate:        4x
Fast Writes:     Enabled
SBA:             Enabled

The important things to note are what AGP port speed multiplier your card and your motherboard support, and whether both your card and your motherboard support “Fast Writes” and “Side Band Addressing.” Your AGP rate should automatically be set to the best rate possible on both your video card and your motherboard. Unfortunately, FW and SBA will not be. You’ll need to add the following line to your /etc/modules.conf.local.

options nvidia NVreg_EnableAGPFW=1 NVreg_EnableAGPSBA=1

You can test the results of this by either dropping out of X (perhaps going to the console and taking the system to runlevel 3) and reloading the nvidia kernel module, or simply rebooting. If you aren’t getting the best AGP rate supported by both your video card and your motherboard, you can also add “NVreg_ReqAGPRate=X” to the line above, where X is, obviously, 2, 4, or 8.

I wish I could say that this process yielded a huge improvement in my framerates while playing certain FPS games (notably Unreal Tournament 2003), but I still get the exact same benchmark scores after these tweaks as I did before. During my testing, I was sure that the gameplay was much more smooth due to these changes, but the framerates don’t lie. I must have changed something else that makes the game perform a little better. Again, YMMV.

Samba and CUPS

In case you’re totally new to CUPS, you can configure the majority of the options through a web browser pointed at http://<cups_server>:631/. However, the first thing you may notice after installing CUPS and visiting that page is that the pages on the server don’t look quite right. The problem is some missing links to a couple cascading style sheets. I originally stubbed this section to detail how to fix this, but SuSE fixed it with cups-1.1.18-77.i586.rpm, so be sure to update.

All I need to do with Samba is expose the CUPS printers I use on the Linux client side to “legacy” Windows clients. I had been running Windows 98 for it’s “gaming” capabilities, but, frankly, I find that Windows 2000 does just as well with all the updates available for it. Note that while 98 doesn’t understand the native CUPS protocol (IPP), 2000 does. So if you want to use CUPS printers with that OS (or later versions) natively, you can. (And I should try it and post my results here.)

The only things I needed to do to get Windows clients printing to my CUPS server was to change a few options with SWAT. If you didn’t install this, you ought to do so now. I’ll wait… Yes, yes. I know that you will need to pass your root password over the intranet, but you trust everyone on your local intranet, right? Anyway. Hit http://<samba_server>:901/ and change “Security” to “SHARE,” “printcap name” to “CUPS,” and “printing” to “cups.” I also set “workgroup” to the same thing as my internal domain name, but that’s just for fun.

In situations where it’s time to use a real domain, you will probably want to at least also change “PAM password change” and “unix password sync” to “Yes” so that users can update their passwords on their own. With so many ways to configure Samba with so many different OS’s, I just thought a note here on how to do that with SuSE would be in order (so I can look it up when I forget).

Squid and SquidGuard

I set this up to protect myself from unsightly things on the net. It’s not quite as good as Dan’s Guardian, as it doesn’t do blocking based on actual content, but I wanted to try it out anyway, and I’ll tell you why. First, it makes for an interesting experiment. Second, I have a daughter who’s about four and a half at the time of this writing, and she’s going to want to start browsing the internet in a couple years. I’ll want much more than this then.

To summarize, I want a filtering web proxy that will run on my firewall. With this arrangement, I hope to create a non-bypassable facility to keep my family from seeing a lot of stuff they shouldn’t. (I was going to write a short explanation about all of this, but I saw that it was going to spiral out of control very quickly. I’ll leave that for another page.) With this setup, I’ll be able to block all outgoing web traffic except from the proxy at the firewall. Unless my kids hack my firewall and get root. Which would actually make me really proud, but anyway. Other services will eventually be blocked altogether.

Unfortunately, on SuSE, the default install isn’t going to get you very far.

  • Install both the squid and squidGuard packages.
  • Download the latest blacklist tarball from the squid web site, extract it in /var/lib/squidGuard/db, and set the owner on all the files in this heirarchy to be squid if they aren’t already.
  • Edit /etc/squid/squid.conf to have a line like this: 
    redirect_program /usr/sbin/squidGuard
  • Make another edit to the squid.conf file to allow your internal networks to access the proxy like this. (Note that this won’t be necessary if you are just installing squid on your local machine for various reasons.) 
    acl local_internal_network src 192.168.4.0/24 http_access allow local_internal_network
  • Edit your /etc/squidguard.conf file. Very useful instructions start here.
  • Start the squid service.
  • Make the squid service start at boot time.
  • Edit your firewall config to allow the internal network to access your proxy.
  • Additionally, make sure your firewall can “do” tcp ports 80, 443, and 23.
  • Set your browser’s proxy configuration to point at your firewall, on port 3128.

Sometime down the road, I want to set this up so that I can use a password to bypass it when I need to, but this will do for now.

Nagios

“Nagios” is a web application that monitors servers and services. It can email you when problems arise. It can even dial a modem with an add-on. I use it where I work, and it works quite well. Just about anything you can imagine wanting from something like this, it does. Just to make a note about it, I’m documenting a few notes about how to get it running. Probably the most significant part of what I’ve done to get Nagios running (for my workplace) is that I found a script that checked on the status of FlexLM license managers, and hacked it up both for how I wanted it to work, and made a new version for checking IBM iFor license managers as well. Since the original was open source, they are included below. (I should document them better or something.)

  • Change user daemon to have a home directory, say, /home/daemon, and setup ssh keys for that account there.
  • Edit /etc/nagios/nagios.cfg.
  • Install the flexlm binaries and the check_flexlm nagios script.
  • Install the LUM for Linux RPM and configure it to look at the iFor server. Then install the check_ifor script.
  • Install the check_nt binary.

“Split-Brained” DNS

I finally needed to do this for a project, and I just wanted to make a note about it here for future reference. When splitting my DNS server, I chose to make two instances, one for handling each side of the serving. I simply made two copies of /etc/named.conf, one called named-internal.conf, and you can guess the other. Then I created the directory /var/run/named, and chowned it to named:named. In the named-*.conf files, I included lines like the following:

listen-on port 53 { 127.0.0.1; 192.168.0.1; };  pid-file "/var/run/named/named-internal.pid";

Note that this sort of gets out of YaST’s ability to handle. Rather than trying to graft this sort of thing into the standard rc script sort of arrangement, I took the weasley way out and simply added two lines to /etc/init.d/boot.local, like so:

/usr/sbin/named -u named -c /etc/named-external.conf /usr/sbin/named -u named -c /etc/named-internal.conf

You’ll lose some control this way (no `rcnamed reload’ now), but I felt the tradeoff was worth it.

  • #1 written by David  8 years ago

    I finally got around to adding a few words about SuSEfirewall2, and made an important note about the default OoTB config for postfix.

    Reply Quote
  • #2 written by David  8 years ago

    Update of the postfix config section due to the onerous and annoying “Swen” virus that’s sweeping the nation!

    Reply Quote
  • #3 written by David  8 years ago

    Added a note about “split-braining” DNS and using rsync to get updates.

    Reply Quote
  • You may use these HTML tags: <a> <abbr> <acronym> <b> <blockquote> <cite> <code> <del> <em> <i> <q> <strike> <strong>

  • Comment Feed for this Post
Go to Top