This setup describes a DSPAM installation on a Redhat Enterprise Linux 4 machine running PLESK and qmail as MTA. However, most of it should be applicable to other systems, too. This setup is in use on my own mail server and is not more than a condensed step-by-step guide.

Install DSPAM

If you're on Debian, use aptitude to install it. For RH EL4, there's a repo on pramberger.at from where you should download the libdspam and dspam RPMs. After that, installation is just the usual rpm -i routine.

To configure it, do the following:

1. Edit the configuration in /etc/dspam/dspam.conf as follows:

    Preference "signatureLocation=headers" #to put the DSPAM signature into the header Trust popuser #this is the user qmail runs with 

2. Make sure that you use popuser instead of dspam user for dspam daemon: Edit /etc/init.d/dspam and change the line

   initlog -q -c "$SU - dspam -c \"/usr/sbin/$DSPAM --daemon ${OPTIONS} &\""

   into

   initlog -q -c "sudo -u popuser sh -c \" /usr/sbin/$DSPAM --daemon ${OPTIONS} & \" "

   This is necessary because we cannot su with popuser, since popuser has no shell in RHEL4.
3. Make sure that popuser can execute and use dspam. To test, try what "sudo -u popuser dspam --help" is doing. If it plays dirty, chmod +x the DSPAM executable.

Setting up Plesk Qmail with DSPAM

First, create the directory /opt/dspam-scripts to hold some helper scripts we're going to create in the following.

Create /opt/dspam-scripts/dspam-checkmail.sh with this content:

 #!/bin/sh DSPAM=/usr/bin/dspam #p="${HOME%/*}" # THIS DOES NOT YET WORK #MAILNAME="${HOME##*/}@${p##*/}" "$DSPAM" --client --stdout --deliver=innocent,spam --mode=teft --feature=noise,whitelist --user popuser@qmail check=$? exit $check 

This script performs the actual DSPAM spam check. DSPAM can handle user-based filtering, but in our setup we'll just use one DSPAM user for all mail users. To keep it simple, we called this user popuser@qmail as well (see above).

Next, add a file procmail.log to each qmail user's Maildir and make popuser its owner. This file will be useful for promail logging.

We can now start using the filter. To do so, create the directories .Junk and .Junk/cur in each user's Maildir. Then, change the .qmail files in the qmail user directories as follows:

 | true |preline /usr/bin/procmail -m -o .procmailrc 

and the users .procmail file as follows:

 DEFAULT=./Maildir/ SPAMDIR=${DEFAULT}/.Junk/ LOGFILE=${DEFAULT}/procmail.log LOG="--- Logging ${LOGFILE} for ${LOGNAME} " # Begin spam treatment. :0fw | /opt/dspam-scripts/dspam-checkmail.sh :0 *^X-DSPAM-Result: Spam ${SPAMDIR} # End spam treatment. 

The .qmail file just tells Qmail to call procmail at the last stage. Note that whatever you do in Plesk, it won't overwrite this setting, so it is safe to do it this way...
The .procmail file calls the dspam-checkamil.sh script and then filters the message either into the user's Maildir/Junk/cur directory or, as usual, into the Inbox.

As you can see from the scripts above, we use DSPAM in the client mode. Therefore, you have to start the DSPAM daemon via the /etc/init.d/dspam script now.

Training day

At this point, DSPAM is filtering your mail, but it is not yet trained to do it really well. Let us change that. We shall train DSPAM with some old ham and spam:

1. Add two temporary directories to hold training ham and spam (we'll use /tmp/train-ham and /tmp/train-spam).
2. If you used Spamassassin previously, you have to remove the SA headers from existing mails before you should train them. You can do so by executing

    for i in /var/qmail/mailnames/stoop.net/norbert/Maildir/cur/*; \ do (spamassassin -d < $i > /tmp/ham-train/cur/`basename $i`); done & 

   This places a clean copy of all mails in your inbox in /tmp/ham-train. Do the same for existing SPAM, which we assume to be stored in a .Old_Junk subfolder:

    for i in /var/qmail/mailnames/stoop.net/norbert/Maildir/.Old_Junk/cur/*; \ do (spamassassin -d < $i > /tmp/spam-train/cur/`basename $i`); done & 

3. Now you can train DSPAM using dspam_train USER SPAMDIR HAMDIR, ie.:

    dspam_train popuser@qmail /tmp/spam-train/cur/ /tmp/ham-train/cur/ 

User-assisted training using IMAP directories

The following steps describe how you can let your users train DSPAM by placing wrongly classified mails into special IMAP folders. Assuming that your users put undetected spam in their .Junk/Junk-Learn IMAP folder and ham wrongly classified as spam in .Junk/Innocent-Learn, save the following script as /opt/dspam-scripts/junk_training_script.sh to retrain these mails

 #!/bin/sh # (c) 2005 Casey Allen Shobe  # Released under BSD license. See http://opensource.org/licenses/bsd-license.php # Bail if already running (in case we are slammed with spam to train from): processes=$(ps ax) if [ `echo "${processes}" | grep junk_training_script.sh | wc -l` -gt 1 ]; then echo "ERROR: junk_training_script is already running!" exit 1 fi # Subscripts: cutscript=/opt/dspam-scripts/dspam-antispam_update-cut filterscript=/opt/dspam-scripts/dspam-antispam_update-filter dspamuser=popuser@qmail mailroot=/var/qmail/mailnames for domain in `find "${mailroot}" -type d -maxdepth 1 -mindepth 1 | cut -d '/' -f 5 | sort`; do if [ `find "${mailroot}/${domain}/" -type d -name ".Junk.Junk-Learn" | wc -l` -gt 0 ]; then echo "Running for domain ${domain}" for user in `find "${mailroot}/${domain}/" -type d -maxdepth 1 -mindepth 1 | cut -d '/' -f 6 | sort`; do maildir="${mailroot}/${domain}/${user}/Maildir" if [ `find "${mailroot}/${domain}/${user}/" -type d -name ".Junk.Junk-Learn" | wc -l` -gt 0 ]; then echo " - ${user}@${domain}" if [ -d "${maildir}/.Junk.Junk-Learn/cur/" ]; then find "${maildir}/.Junk.Junk-Learn/cur/" -type f \ -exec ${cutscript} {} Spam \; \ -exec ${filterscript} "${dspamuser}" spam error {} \; \ -exec mv {} "${maildir}/.Junk/cur/" \; fi if [ -d "${maildir}/.Junk.Innocent-Learn/cur" ]; then find "${maildir}/.Junk.Innocent-Learn/cur/" -type f \ -exec ${cutscript} {} Innocent \; \ -exec ${filterscript} "${dspamuser}" innocent error {} \; \ -exec mv {} "${maildir}/cur/" \; #TODO: Should call maildrop? fi fi done fi done 

Note: This scripts checks all your server's domains at once. It moves learned spam to Junk and learned ham to the user's inbox.

The script also needs two helper scripts:
/opt/dspam-scripts/dspam-antispam_update-cut (just formats an output for logging etc):

 #!/bin/sh output=`echo "${1}" | cut -d '/' -f 10` echo " ${2} - ${output}" 

/opt/dspam-scripts/dspam-antispam_update-filter (the actual DSPAM training):

 #!/bin/sh signature=`grep -h X-DSPAM-Signature ${4} | awk {'print $2'}` echo " ...retraining signature ${signature}" /usr/bin/dspam --client --user ${1} --class=${2} --source=${3} --signature=${signature} echo " using DSPAM --client --user ${1} --class=${2} --source=${3} --signature=${signature}" 

To train automatically, make a cron job for /opt/dspam-scripts/junk_training_script.sh which runs every 30 minutes or so.

I spent most of this Sunday trying to migrate a MySQL 4.x databse to MySQL 5.x. What is easy in theory was impossible in practice: Using the standard mysqldump and import way always produced wrong character encodings in my DB. In fact, the old DB was in latin1, and I wanted the new (5.x) also to be in latin1. But importing the data always produced encodings in utf8 (although MySQL thought it was having latin1). So, I tried almost all but nothing worked but this trick:

1. Dump the table definition and import into the new DB. You only need the tables, not the data!
2. Convert all tables in the new DB to utf8 as default character encoding: alter table BLAH convert to character set utf8;. When done, also change the encoding for the entire DB: alter database MYDB character set = utf8;.
3. Export the table data from the old DB without table creation statements (-t): mysqldump -t --default-character-set=utf8 MYDB > MYDB.sql.
4. Import the sql dump as usual.

If you are using PHP to connect to the DB, make sure to tell the database connection it should use utf8 als encoding. With ADODB, this can be done like this:

 $db_charset = $db->Execute( "SHOW VARIABLES LIKE 'character_set_database'" ); $db->Execute( "SET NAMES '" . $db_charset->fields['Value'] . "'" ); 

These are just some quick and dirty installation instructions for collective.tin, collective.lead, collective.mercury etc. What I really want to do is to use SQL content types within Plone 3.0 in a Zope3-ish way.

Unfortunately, I could not find information on how to install the collective.* packages, so here's my hack:

1. Install SQLAlchemy 0.4.x. Straightforward, since it's an egg. Just remember to use the same python that is used to run Zope/Plone. If you're on a Mac, for example, set the $PATH variable so it finds your Plone package's python executable first (on OSX, Plone3, that is: /Applications/Plone-3.x/Python-2.4.x/python2.4)
   The package is then installed in Python-2.4.x/lib/site-packages of your Plone directory.
2. Start with the SVN version of collective.lead. It's a Python egg, so just do python setup.py install. Again, remember to use the correct python execs.
3. Now, checkout collective.mercury and collective.tin from SVN. Put the directories trunk/collective/tin and trunk/collective/mercury to the collective.lead-directory that was created by the python egg installation. It's important to put it there, otherwise my python could not find it. Not sure how to do this in a proper way...
4. Then, basically follow the steps in the tutorial. Important:
5. Create the products directory (eg. Timesheets). Then, change into the Plone instance directory, that is, the directory just above Products.
6. Start the Zope debug server from within the very same directory and import codegen from collective.mercury, like described in the tutorial. If you're on MySQL, use Annotate=False, as it only works in PostgreSQL.

ALL DONE! Easy if you know how. Not so easy without any documentation...

Are you one of the lost souls trying to compile an C++ application that includes the GNU libstdc++ complex header file?

If so, you might have come across a really nasty error message like the one below:

 /usr/include/c++/4.1.2/complex(754): error: identifier "__builtin_clogf" is undefined __complex_log(__complex__ float __z) { return __builtin_clogf(__z); } ^ /usr/include/c++/4.1.2/complex(757): error: identifier "__builtin_clog" is undefined __complex_log(__complex__ double __z) { return __builtin_clog(__z); } ^ /usr/include/c++/4.1.2/complex(761): error: identifier "__builtin_clogl" is undefined { return __builtin_clogl(__z); } 

Looks really bad, doesn't it? To keep it simple, I have no idea what exactly is going wrong here, but for me it helped installing version 9.1.046 of the Intel compiler as opposed to using 9.1.038. They mention something in the changelog, although it is filed under bug fixes for Itanium (whereas I'm using EM64T).

Update: Version 9.1.042 is also known to work.

I recently (November 2005) bought a Canon EOS 20D camera. It's a superb camera, at least for someone like me. I was first favouring the EOS 350D for it has a much lower price, but, believe me: if you don't have small hands, the 350D will probably be too small to hold securely.

So, despite the fact that it has features I'll probably not need too soon, I decided in favour of the EOS 20D - and I guess it was right. The 20D is absolutely fantastic. It has almost every feature a pro camera needs, has a very solid body and gives excellent image quality with very low noise levels. Alltogether, a stunning product! Now, since this is not going to be a EOS 20D review (and I'm not paid by Canon), I'll stop praising it now. If you're interested, I've included some sample shots at the bottom of this page.

Accessing the camera via Linux

As with every (digital) camera, there are two distinct ways of accessing your images under Linux: Often, it is easiest just to insert the CF card into a card reader connected to your PC. This is bullet-proof, works always and everywhere and, in fact, is the only possibility to copy RAW images.

But sometimes you don't have a card reader at hand. When connecting the EOS 20D directly, I observed that the so-called "Normal mode" did not work. In normal mode, the camera does not operate as a mass storage device but uses a proprietary Canon protocol, which is not (yet) available for Linux.

The standard PTP mode, on the other hand, is supported by Linux and the EOS 20D, so you should go for it. To use it, first make sure you switch the camera into PTP mode from within the camera menu.
Next, get a recent version of gphoto2 (>=2.1.6) if not already installed. gphoto2 is a general purpose library for accessing digital still cameras. You'll need a recent version because EOS 20D support was not fully implemented in earlier releases.

Last but not least you'll certainly want a nice interface. My choice is Digikam of the KDE project, but there exist various other similar applications (gtkam etc.). It is very likely that one or more of them are already installed on your computer.

To finally access the camera, connect it via USB and switch it on. Now, start Digikam (or whatever GUI you use) and in the Camera menu, add a new camera. Self-detection should work fine. Then, access the images on your camera by clicking on Camera -> Canon EOS 20D (PTP mode). Two screenshots of Digikam in action is shown below.

Troubleshooting

There's not much to say here, since it should work out of the box under normal circumstances. With modern distributions, you probably don't have to do anything at all.

In case that auto-detection does not work, make sure you have the newest gphoto2 version isntalled. Furthermore, check if it works as user root. If it does, it's very likely that the system does only allow root to access the camera. Modern Linux distribution normally take care of these permissions by granting access to the camera to some special user group (for example, this group is called camera in Debian). If not done automatically, add your user account to this special group and re-login. If your user authentication is done by LDAP, add the camera group into the LDAP DB and modify your own account to be a member of this group.

This is a short tutorial describing how to setup a Debian client to use an existing LDAP server for user authentication.

Right, so I assume you're using Debian sarge (aka stable) on the client machines. I'll further suppose that the LDAP server is already configured and running correctly.

On the client side, let's start with the installation of the needed packages:

 apt-get install libnss-ldap libpam-ldap 

The Debian Configuration screen will ask you about the following things:

• LDAP server - This is just the IP address of the LDAP server you want to use
• Distinguished name of search base - In our example, this is dc=stoop,dc=home
• LDAP version - We're using version 3.
• Database requires login? - Can be answered no in our case
• Make configuration readable/writable by owner only? - Since we do not store any security relevant info, it is safe to no here.

The contents of /etc/pam_ldap.conf and /etc/libnss-ldap.conf can be obtained here (pam_ldap.conf) and here (libnss-ldap.conf).

Please note: I did not make too many changes to these files. In fact, all I did was to make sure that the host and the base entries in both files are pointing to my LDAP server and to the correct base DC, respectively.

Important: As far as I know, these two files must be world-readable. Don't store any passwords in them. If you can't bind to your LDAP server anonymously, use the file /etc/ldap.secret (probably a Debian thing only) to store the password and chmod it 700.

NSS & PAM configuration

You should change the first three configuration directives in /etc/nsswitch.conf according to:

 passwd: compat ldap group: compat ldap shadow: compat ldap 

You can leave the rest as is. The lines above tell your system it should ask the LDAP server for the contents of the files /etc/passwd, /etc/group and /etc/shadow. You can test if this works by issuing, for example

 getent passwd 

You should get a list of all user accounts, including those from the LDAP server. If you can only see local accounts, check your configuration and, especially, check the system logs on the client.

Okay, let's care about PAM authentication. My version of the files looks as follows:

 # /etc/pam.d/common-account: account sufficient pam_ldap.so account required pam_unix.so try_first_pass 

 # /etc/pam.d/common-auth: auth sufficient pam_ldap.so auth required pam_unix.so nullok_secure try_first_pass 

 # /etc/pam.d/common-password: password sufficient pam_ldap.so password required pam_unix.so nullok obscure min=4 max=8 md5 try_first_pass 

 # /etc/pam.d/common-session: session required pam_ldap.so use_first_pass session sufficient pam_unix.so 

This configures PAM to ask the LDAP server first and then fall back to the plain files (/etc/shadow etc.) when the LDAP server is not available.

I did not change any of the other files around in /etc/pam.d/. They all somewhere include the four files above using @include <filename>.

IMPORTANT: Once LDAP/PAM is working, you have to make sure that you do not have the same username(s) and group(s) in /etc/passwd, /etc/shadow and /etc/group. Otherwise, strange behaviour may occur. One very weird, but common result is that you can login successfully (ie. the password authentification works), but when you try to list/see your own files (ls -l etc.), you get a

 ls .: Permission denied 

This document describes the setup needed to run Apache with SSL encryption. It is based on a Debian woody/sarge installation, but should work with other Linux/Unix systems as well. The approach shown here is using the command line only. You can use graphical tools such as TinyCA if you like that better.

Requirements

Under Debian, the following packages have to be installed via apt-get:

• apache-ssl
• openssl
• libapache-mod-ssl (will automatically be installed by apache-ssl)

The SSL certification process consists of three basic steps:

• If not done already, create a certificate authority (CA), which we will use to sign our own certificate.
• Create a new certificate request
• Sign the request with our CA to obtain a valid certificate.

Create a certificate authority

The OpenSSL package comes with a default openssl.cnf file under /usr/lib/ssl/openssl.cnf. We will edit the default values slightly, ie. we change the default path from demoCA to ourCA. To do so, copy /usr/lib/ssl/openssl.cnf to /etc/ssl/openssl.cnf and change the line

 dir = ./demoCA 

to

 dir = /etc/ssl/ourCA 

For security reasons, you will have to create the necessary file and directory structure manually. In particular, you have to create the following folders and files:

• /etc/ssl/ourCA/
• /etc/ssl/ourCA/index.txt (empty file)
• /etc/ssl/ourCA/newcerts/
• /etc/ssl/ourCA/private/
• /etc/ssl/ourCA/serial (file containing "01" as the first and only line)

We can now tell openssl to create a new certification authority for us:

 openssl req -new -x509 -keyout /etc/ssl/ourCA/private/cakey.pem \ -out /etc/ssl/ourCA/cacert.pem -config /etc/ssl/openssl.cnf 

You will be asked a few questions about the new CA. Just enter information that makes sense and is valid. Also, choose a good passphrase, since you'll have to remember it every time you want to validate and sign a new certificate request.

Issue a certificate request

We are now ready for the interesting part of this tutorial. To create a certificate request, execute

 openssl req -new -keyout newkey.pem -out newreq.pem -days 365 

OpenSSL will again ask you a few questions. Make sure that you enter the hostname of your SSL server as "Common Name". This is very important and things will break if you don't do it.

If everything went fine, this will give you two new files in the directory where you ran this command. The first is our certificate private key and the second file (newreq.pem) is the certificate request for the CA.

There is one obstacle with the private key in the current form: It requires a passphrase to be used. That means, if you want Apache to use this SSL key, you'll have to supply the passphrase at Apache's startup. This is not very handy, for sure. We can however, remove the passphrase by running:

 openssl rsa -in newkey.pem -out nopwkey.pem 

You will be asked for the private's key passphrase. If things went right, you will have a new private key called nopwkey.pem, which is not passphrase protected anymore.

To let a CA sign a certificate request, they need both, our private key and the certificate request. We can combine both into one file by cat'ing them together:

 cat newreq.pem nopwkey.pem > new.pem 

Signing the certificate

The last step consists of the actual signing process. Just issue

 openssl ca -policy policy_anything -out newcert.pem \ -config /etc/ssl/openssl.cnf -infiles new.pem 

in the same directory where your certification request files are stored. You will first be asked for the CA passphrase (now you know why it is important to remember it!) and you can then either sign or reject the certificate.

You should now copy newcert.pem and nopwkey.pem to some convenient place, since Apache will only need those two files to operate in SSL mode.

Apache-SSL configuration

Under Debian, the SSL enabled Apache version has its own configuration file, available under /etc/apache-ssl/httpd.conf. Edit and change or add the following lines:

 SLCertificateFile /path/to/newcert.pem //This is our signed certificate SSLCertificateKeyFile /path/to/nopwkey.pem //This is our unencrypted private key. 

Start Apache-SSL by executing

 /etc/init.d/apache-ssl start 

Mailing lists have been around for a long time, and there's an established way of participating in them. Not only does the discussion in mailing lists tend to be more focused than in other media, but it's also more personal.

There's a vital reason why you should follow mailing list netiquette. The list owner has supreme power over the list. If a subscriber insists on violating list guidelines or flagrantly violates mailing list netiquette, it's a simple matter for the list owner to ban the violator.

That might seem a bit harsh, but a mailing list depends on the cooperation of its subscribers. Getting involved in a mailing list can be a little intimidating at first. But there'll be no problem as long as you follow a few simple points of mailing list netiquette.

DOs

• The Primary Rule: You send your commands to the list server and your messages to the mailing list. You don't want to send a message that only says "SUBSCRIBE" to hundreds of people.
• Save the welcome message you receive. It will give you basic list server commands for subscribing and unsubscribing to that mailing list.
• Always include a descriptive subject line in your message. Avoid non-ASCII characters in subject lines, like german Umlaute etc.
• Always post with your real name. Mailing lists are already anonymous enough...
• Only post in text format.
• If you need to communicate other data (images, documents), ask who's interested in and send it to their personal email adresses.
• Separate your signature using "--". This is a common way and many mail clients rely on this behaviour to identify text as signature.
• Learn to quote: Only include relevant parts of the message you're replying to. Shorten the text you're refering to to a minimum. If necessary, try to summarize and use brackets ( '[ summarized text ]'). Always reply below quoted text, allowing chronological reading.
• If you want to mark passages or words, use '*' signs or underscores '_'. Words in capital letters are interpreted as SCREAMING.
• Text lines should be wrapped after not longer than 65 characters.

DON'Ts

• Don't spam the list. Specific mailing list guidelines may vary. But as a rule, commercial announcements, advertisements, chain letters, test messages, and other low-value messages should not be sent to the list.
• Don't bounce: If you're going on vacation, suspend your subscription until you get back - especially if you think your e-mail box might fill up. If you're canceling or changing your e-mail account, change your subscription or let the list owner know what's going on. If mail can't get to you, it will "bounce" back to the list owner, who has to deal with it.
• Never attach binary data (images, .doc etc). It generates unnecessary amounts of traffic and is an annoyance for people to download.
• Don't send HTML mails, most people won't read it. Additionally, it generates way too much traffic and HTML postings can't be archived.
• Don't include signatures longer than 4 lines. This does not only apply for mailing list postings but for email in general.
• No full-text quotes! The worst things you can do is TOFU ("Text oben, Fullquote unten": Text above, full quote below).
• Only use 'Re:' as prefix for replies, never use Outlook's german 'AW:' or other funny inventions. Otherwise, list members are not able to use message threading.
• The quote sign is '>'. Don't use anything different unless you want to be hated by everyone.

Source: AOL, LUGS, me

You probably know that you can completely administrate a Unix/Linux machine by logging in to it via SSH. But what would you do if you needed to access a Windows machine? Right, use VNC, you say. That's fine, I admit. VNC is freely available (see below for software links), it's easy to play with and fast enough to be used even over a slow dial-up line. However, the VNC protocol is rather insecure. Although passwords are transmitted in encrypted form, the actual data is not. That might again be fine if you use it in your LAN only, but I for my part would definitely not use it over the Internet.

Commercial products exist to overcome the issue of (in)security by custom encryption methods. But, since the VNC protocol does not (yet) specify exactly how data encryption has to be implemented, every product uses its own encryption technique(s). In other words, if you want encryption, your VNC server and client probably need to be from the same manufacturer. Apart from that fact that you will have to pay for such software, the high chance of incompatible server/client implementations is not satisfying at all.

SSH to the rescue?

It is very common to overcome the security problems of VNC by just tunneling the VNC connection through a highly secure SSH tunnel. To do so, we need to open an SSH connection (a tunnel) between the two hosts and can then run the VNC applications without further modifications through the secure line, even over the Internet. This is a very general approach and is not restricted to the VNC protocol.

However, under Windows, things look different: Windows is not equipped with the necessary SSH server software. Worse, there is no freely available SSH server for Windows. To put it simply, if you want to securely administrate a Windows machine via VNC, you best buy a commercial SSH server.

Moreover, if the machine you want to administrate is behind an NAT firewall, you loose: First of all, the firewall most probably blocks incoming VNC connections and, second, NAT prevents direct access to the machines behind the firewall. Okay, you can forward the firewall ports to the internal machine, but that requires root priviledges on the remote firewall...

SSH to the rescue!

I wouldn't be writing this tutorial if there wasn't a way to overcome the various troubles. Look at the following figure to get an idea of the setup I'm going to talk about:

That is, we want to administrate a machine in LAN 2 from a client in LAN 1 via an SSH tunnel (blue line) through the internet. We will do so by creating an SSH tunnel from the firewall in LAN 1 to the firewall in LAN 2. The latter will forward the VNC connection to the internal VNC server.

We first have to check that the following things work:

• You have to make sure that you can login to the firewall in LAN 2 ("firewall 2") via SSH. I assume the default SSH port number 22 is used. If you can't connect, this either means that no SSH server is running on the firewall 2 or that the firewall blocks incoming SSH connections.
• The firewall in LAN 2 has to be able access the VNC server, ie. make sure that no additional personal firewall application is running on the VNC server machine. If so, open port 5900 on the VNC server.
• Make sure you have root access to the firewall in LAN 1 ("firewall 1"). This is required to create SSH tunnels for the priviledged ports 590x.

The rest is easy:

Be root on firewall 1. Then, issue

 ssh -v -p 22 -g -l fw2user -C -L 5901:vncserverip:5900 firewall2ip 

where fw2user is the account used to login to firewall 2, vncserverip is the (internal) IP address of the VNC server machine and firewall2ip is the IP address of firewall 2.

You will be prompted for a password for user fw2user. If the authentication was successfull, you will get - as usual - a shell in firewall 2.

However, we did not only log in to firewall 2, but we also told firewall 1 to tunnel port 5901 via SSH to firewall 2. Simultaneously, we let firewall 2 forward that connection to port 5900 on the VNC server machine. Got it?

If not, don't care, but instead, fire up your VNC client software on the workstation in LAN 1. Now, connect to port 5901 on firewall 1 (since this will be tunneled and forwarded accordingly). After supplying the VNC password, you will be presented with the desktop of the VNC server machine.

Troubleshooting

If things don't work as expected, check the following:

• Are those IP addresses all correct? The tunneling format is rather awkward, so double check whether you wrote the right IPs at the right place.
• Make sure the VNC server software is running before you create the SSH tunnel. If not, you will most certainly get a "Connect refused" error.
• If you get a "Connection closed" or "Connection to VNC server lost" right after the authentication dialog, make sure that you do have appropriate graphics drivers installed on the Windows machine. The default 640x480 VGA drivers that come with Windows won't do it!

VNC software

• RealVNC (originated from the AT&T reference implementation). The free version will do for our purpose.
• TightVNC: A very nice VNC client/server implementation, particularly on Windows.
• Ultr@VNC

If you're using a recent version of KDE (3.2 or higher), you most probably already have a nice VNC client installed. It is called "Remote desktop connection" (krdc).

As the title says, this howto will help you using your DVD burner under Debian Linux. In fact, the howto should also work for other distributions, too. I for my part have a cheap LiteOn burning device, but again, it shouldn't mather if you want to use a different one.

Requirements

Before using your DVD burning device, make sure that your Linux installation knows about it. dmesg should show you some output similar to this one:

 hdh: LITE-ON DVDRW SOHW-832S, ATAPI CD/DVD-ROM drive 

That line just means that my DVD burner is accessible via the /dev/hdh device name.

If no DVD burning device shows up in dmesg's output, you probably need to load the ide-cd module manually. Execute lsmod to find out if ide-cd is already loaded. If not, do so by executing (as root, of course)

 modprobe ide-cd 

On the software side, we need the following packages (your distro probably already installed all or some of them):

• dvd+rwtools (>= 5.12.x)
• dvdrtools

When using Debian, you would just call apt-get install to install the required packages.

After installing any necessary software, make sure that the following commands are available:

• mkisofs
• growisofs

Burn that thing!

Well, the easiest thing is to put all the files you want to burn into a separate directory. Having done so, insert a blank DVD into your device and start burning by

 growisofs -Z /dev/hdh -R -J /path/to/burndir 

Of course you have to replace hdh with your device name, as shown in dmesg's output (see above). If you do not like the command line, K3B is an excellent CD and DVD burning tool for KDE. A screenshot is shown below.