Problem: How is it possible to clone the incoming stream of packets at HOST A and forward one copy into HOST A’s userspace (for accounting applications) and the other copy to HOST B’s userspace (for testing purposes)?
The specific challenge is that I do not want a simple FORWARD to HOST B, but a FORWARD of a copy, so that I can work with the data on both machines. This leads to the next problem: Packets arriving at HOST B have the Destination IP address of HOST A in their IP header. We need to rewrite this IP at HOST B so that userspace applications are able to process these packets (which they are not, if the packets are not destined to HOST B’s address).

Note in advance: Despite all efforts this tutorial only works for connectionless udp traffic. A successful 3-way-handshake on HOST A prevents HOST B (despite IP-address rewriting) from accepting the packets in userspace. It just does not work, I appreciate any comments on that. Remember that tee is normally used to clone traffic to another host for passive sniffing and traffic analysis. Note as well, that even if you might want to keep this approach centralized and rewrite the packet’s IP addresses already at HOST A in the POSTROUTING chain, this will not work: Teed packets do not yet show up anywhere within the iptables structures to avoid interfering with the original packet’s table traversal. This is subject to change, though. Thanks to Jan Engelhardt for this information.

So here is how we achieve this goal (tested on Debian Etch stable):
History: There used to be a tee option for an experimental ROUTE target, patchable into iptables with patch-o-matic (pom). This will not work on recent kernels and is deprecated!

This is what we will do on HOST A: Get xtables-addons from http://dev.computergmbh.de:
wget http://dev.computergmbh.de/files/xtables/xtables-combined-1.5.4.1.tar.bz2
This includes a current snapshot of iptables.

Xtables-addons is the proclaimed successor to patch-o-matic(-ng). It
contains extensions that were not accepted in the main Xtables
package.
Xtables-addons is different from patch-o-matic in that you do not have
to patch or recompile either kernel or Xtables(iptables).

Untar, configure, make and make install. Should you run into problems of the kind
warning: #warning You need either CONFIG_NF_CONNTRACK or CONFIG_IP_NF_CONNTRACK
change into your kernel source directory and adapt your kernel. Therefore, look for the Networking option, find the Netfilter (formerly know as ipchains) framework entry and enable the appropriate options. I also ran into problems saying
warning: #warning You have CONFIG_IP_NF_CONNTRACK enabled, but CONFIG_IP_NF_CONNTRACK_MARK or CONFIG_IP_NF_CONNTRACK_SECMARK are not (please enable)
so be sure to enable these options as well in the IP: Netfilter Configuration section.
Save your config and build a new kernel. However, this is not topic of this tutorial.
Should there be other errors because of a special addon, deactivate it in the xtables-addons directory using the mconfig file. Be sure not to deactivate the TEE target, as this is the one we need. The installation success of the xtables-addons may largely depend on the kernel that is being used. If it just won’t work for you with your existing kernel, try another one. I had successful setups on 2.6.23.16 and 2.6.18.6

After successful installation fire the command
iptables -t mangle -A PREROUTING -p udp --dport 9996 -j TEE --gateway <IP of HOST B>.
This command will clone all incoming udp-packets to port 9996 in kernelspace and copy them to HOST B, where we will rewrite the IP addresses. Confirm by typing
iptables -t mangle -L
This will list your rules in the mangle table.
Should there be an error about an unknown table/target/chain, then xtables-addons did not build/install successful, probably because of some missing kernel options.

On HOST B: You do not need xtables-addons here, but only some standard iptables version, as you only need the default DNAT target (Your kernel needs to support it however. Therefore, make sure to have the IPv4 connection tracking support (required for NAT) option enabled in the IP: Netfilter Configuration section of your netfilter kernel category).
iptables -t nat -A PREROUTING -p udp -d <IP of HOST A> --dport 9996 -j DNAT --to-destination <IP of HOST B>:<Port>

That should be it. Now test your setup. You will need three hosts: HOST A and B and another HOST C where you will generate (UDP-) packets. Get a packet generator (I used IP-Packet) and download it to HOST C. Read its documentation, create a config file and fire up your packets to HOST A port 9996. But first, make sure you have a listening process on both, HOST A and B running and waiting for your packets on that specific port. The easiest way will be to use netcat in udp-mode:
nc -ulp9996 on HOST A and on HOST B respective with the port used there. Fire your packets and both netcat instances should receive the UDP payload data. If only HOST A gets them, your tee or DNAT is not working. Debug yourself That’s what I need to do now, as well, because teeing seems to work perfectly fine from one host, but not from the other… Same settings, though, this is just not fair :’(

Computer systems and -networks connected to the Internet are exposed to a large array of malicious activities. Computers throughout the world are continuously being scanned for vulnerabilities, exploited and finally compromised by humans or by autonomously spreading malicious software, called malware. To stem this thread, the University of Karlsruhe has deployed an Intrusion Detection System (IDS) consisting of the Intrusion Prevention module ”IntruShield” and some other quarantine automation modules. The purpose of this study thesis is to ensure deeper security by extending this IDS according to the ”Defense in Depth” strategy. Therefore, several sensors have been deployed into the core- and user network to extend the current setup to a distributed Intrusion Detection System. The heterogeneity of these sensors aid to cover different kinds of attacks: Sniffers for network traffic examination, honeypots for network-host specific operations and host-based IDSs (HIDS) for hostspecific activities. As this heterogeneity leads to a large amount of different data to be analyzed, it has been decided to implement a hybrid Intrusion Detection framework, which enables all the different security applications, i.e. sensors, to report to a centralized console which performs automatic aggregation of the distributed data and correlation between the various events, presented to the security analyst through a web interface.
This work gives an introduction to the basic principles, approaches and securityrelated software technologies used throughout this study thesis. Moreover, it describes the current security concept of the University of Karlsruhe as well its proposed enhancements. In detail, this thesis evinces the campus-wide implementation of the previously mentioned distributed Intrusion Detection architecture and concludes with its evaluation and a future outlook. The thesis shows that the commissioning of this approach results not only in a better automated, but also in a more structured, more unified and a more accelerated security process.

Link: Intrusion Detection with Heterogenous Sensors, 86 pages, 3.5 MB.


fprintf( stdout, "%.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f ",
mfcc(0), mfcc(1), mfcc(2), mfcc(3), mfcc(4), mfcc(5), mfcc(6),
mfcc(7), mfcc(8), mfcc(9), mfcc(10), mfcc(11), mfcc(12) );
fprintf( stdout, "\n" );


dieser hier wird


fprintf( stdout, "%.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f ",
mfcc(0), mfcc(1), mfcc(2), mfcc(3), mfcc(4), mfcc(5), mfcc(6),
mfcc(7), mfcc(8), mfcc(9), mfcc(10), mfcc(11), mfcc(12) );
fprintf( stdout, "\n" );
fflush(stdout);


Ein make linux-alsa im Verzeichnis /src/sndpeek und ein anschließendes make install installiert die gepatchte Software. Es sind auch andere Optionen möglich, bspw: make linux-jack, make linux-oss, make osx, or make win32, je nach OS und Soundsystem. Jetzt kann man sich das Perl-Script os-whistle besorgen, das entpackt wird und nun zum Konfigurieren wie folgt aufgerufen wird:

sndpeek --print --nodisplay | perl cmdWhistle.pl -c Dies lässt sndpeek am Mikrophon lauschen und den Output an das Perl-Script übergeben. Lässt man --nodisplay weg, hat man dazu noch eine nette 3D-Ausgabe. Man kann nun beginnen, ins Mikrofon zu pfeifen und den Output zu beobachten. Ein Timeout erfolgt nach 4 sec Stille. Die Ausgabe sieht ähnlich der folgenden aus:

25.00 25.00 _#_ 0 500000 _#_ <command here> _#_ <comment here>. Jetzt kopiert man, wie vorgeschlagen, diesen Output in die Datei .toneFile ins Home Verzeichnis, wobei man <command here> durch ein beliebiges Kommando ersetzt, bspw. mozilla-thunderbird. Ein erneuter Start des Programms mit
sndpeek --print --nodisplay | perl cmdWhistle.pl (optional mit -v für verbose Output) startet den Daemon. Pfeift man nun nochmal die gleiche Tonsequenz, startet sich das eMailprogramm und checkt die Mails… nur durch Pfeifen gesteuert, weeeeeeeh

Mehr Infos und Details gibt es bei IBM.

First of all, I wanna thank Richard for his in-depth tutorial, which I unfortunately found in a quite late state of my efforts. Anyhow, his tutorial is based on a RedHat Enterprise 4 System, but most of it is usable on other systems, too. It did not fit completely on Debian, though. I copied part of his text for simplicity. So let’s get it on:

• Remove libpcap* via apt-get or aptitude and all other software that depends on it (you gotta rebuild it later with the new pfring-enabled libpcap)
• Rebuild your kernel:
  cd /usr/src
export CVSROOT=:pserver:anonymous@cvs.ntop.org:/export/home/ntop
mkdir pf_ring && cd pf_ring
cvs login
  which should produce the following output:

  Logging in to :pserver:anonymous@cvs.ntop.org:2401/export/home/ntop
CVS password:

  At the prompt, type “ntop” (no quotes), and hit Enter. (Note: ntop will not appear on the screen.) Next type the following:

  cvs checkout PF_RING which will download the needed source.

• Now etner the directory and edit the file mkpatch.sh. Therefore, check which kernel you currently have installed or which kernel you want to have after the update. Check by uname -a which should give you something like Linux rz-sniff 2.6.17.11 #1 SMP Wed Dec 20 13:06:04 CET 2006 i686 GNU/Linux. Open mkpatch.sh, scroll to the first variable declarations and change into your wishes:
  VERSION=${VERSION:-2}
PATCHLEVEL=${PATCHLEVEL:-6}
SUBLEVEL=${SUBLEVEL:-17.11}
and run the script via sh ./mkpatch.sh, which should give you some output and stop with the location of your patchfile.
• Apply the patchfile:
  cd /usr/src
zcat /usr/src/pf_ring/PF_RING/workspace/linux-2.6.*patch.gz | patch --dry-run -p0 If it runs without any error, run again without the –dry-run option
• Now you gotta build your custom kernel. This may vary on different systems, a 2.6 kernel under Debain Sarge can be build as followed:
  cd /usr/src/linux
apt-get install kernel-package libncurses5-dev fakeroot wget bzip2 build-essential
make menuconfig
  It is normally a good idea to take the configuration of your existing (working!) kernel 2.6 as a starting point for the configuration of your new kernel. Usually the current kernel configuration is saved in a file under /boot, e.g. /boot/config-2.6.17.11. Load it using the arrow keys and selection the option at the bottom.
  Now for Intel Network Cards, select Device Driver – Network Service Support – Ethernet (1000Mbit) and enable NAPI-Support by selecting ‘y’ on Use Rx Polling. Go back (3x ESC) and select Networking and Networking Options. Make sure that PF_RING sockets are enabled. Leave and save the settings. Now build the kernel and install it:
  make-kpkg clean
fakeroot make-kpkg --initrd --revision=pfring.1.0 kernel_image
cd ../
dpkg -i linux-image-2.6.17.11_pfring.1.0_i386.deb

  This will install your new kernel (including a ramdisk) and also update grub. You can now reboot your system, and you should then have a new kernel. You can check that by running uname -r.
• Compile libpfring, and test that it works.
  First off, start with doing the following:

  cp /usr/src/linux/include/linux/ring.h /usr/include/linux

  which will add the neccessary header file, ring.h, to the standard include directory.

  Next, run the following:

  cd /usr/src/pf_ring/PF_RING/userland/libpfring
make

  which should give you a short output.
  Now, we are going to generate a .so from these files, by running the following:

  gcc -shared -Wl,-soname -Wl,libpfring.so.0.9.4 -o libpfring.so.0.9.4 *.o -lc

  We copy the files we just created to a common system directory:

  cp libpfring.a libpfring.so.0.9.4 /usr/local/lib
cp pfring.h /usr/local/include
ln -s /usr/local/lib/libpfring.so.0.9.4 /usr/local/lib/libpfring.so


  Next, we need to add /usr/local/lib to the list of directories the dynamic loader will search:
  
echo "/usr/local/lib" >> /etc/ld.so.conf
ldconfig

  To check that the dynamic loader sees the libraries, run the following:

  ldconfig -v |grep pfring

  which should produce the following output:

  libpfring.so.0.9.4 -> libpfring.so.0.9.4

  You can test the installation with

  ./pfcount -v -i ethx with x being your interface number. Be carefull, the thing can hang on a very busy interface (e.g. > 100Mbit)

  Now, run the following:

  dmesg

  and the last few lines of output should look similar to the following:

  RING: succesfully allocated 128 KB [tot_mem=26509372][order=5]
RING: allocated 80 slots [slot_len=1618][tot_mem=131072]
device eth1 entered promiscuous mode

• Next step is to build libpcap to use the PF_RING interface to the kernel.
  First, run the following:

  cd /usr/src/pf_ring/PF_RING/userland/
ls |grep pcap

  The output should be something similar to:

  libpcap-0.9.4-ring

  which indicates that this version of PF_RING was built to work with a patched version of libpcap-0.9.4, so we need to download that version.

  The simplest way to download that version is to run the following:
  
wget http://www.tcpdump.org/release/libpcap-0.9.4.tar.gz Now do:

  tar -zxvf libpcap-0.9.4.tar.gz
cd libpcap-0.9.4
mv pcap-int.h pcap-int.h.orig
mv pcap-linux.c pcap-linux.c.orig
cp ../libpcap-0.9.4-ring/pcap* .
./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"


  If the ./configure command completes without any errors, run the following:

  make && gcc -shared -Wl,-soname -Wl,libpcap.so.`cat VERSION` -o libpcap.so.`cat VERSION` *.o -lc

  Now, run the following:

  make install && cp libpcap.so.0.9.4 /usr/local/lib

  Next, make sure the dynamic loader sees this new library:

  ldconfig -v |grep pcap

  the output should look similar to:

  libpcap.so.0.9.4 -> libpcap.so.0.9.4

• Compile your software using the new libpcap and pfring, e.g. ntop. If you are getting ntop from CVS also (like PF_RING), change into the ntop directory and compile it, using the following commands. These can be used with other software, too (i.e. the compile options)./autogen.sh --noconfig
./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib -lpfring -lpcap"
make && make install

  Now check if your setup was successful:

  ldd /usr/local/bin/ntop

  should produce output similar to:

  linux-gate.so.1 => (0xffffe000)
libpfring.so.0.9.4 => /usr/local/lib/libpfring.so.0.9.4 (0xb7f8c000)
libntopreport-3.2.4.so => /usr/local/lib/libntopreport-3.2.4.so (0xb7ee6000)
libntop-3.2.4.so => /usr/local/lib/libntop-3.2.4.so (0xb78f9000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb78e7000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb78e3000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb78b5000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7784000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7771000)
libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb775a000)
libpcap.so.0.9.4 => /usr/local/lib/libpcap.so.0.9.4 (0xb772f000)
libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0xb7729000)
libgd.so.1 => /usr/lib/libgd.so.1 (0xb76f7000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb76d4000)
libz.so.1 => /usr/lib/libz.so.1 (0xb76c0000)
librrd_th.so.2 => /usr/lib/librrd_th.so.2 (0xb7679000)
/lib/ld-linux.so.2 (0xb7f99000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7654000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7634000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb75ca000)
libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0xb75b4000)

  where the line containing libpfring and libpcap are of particular importance.

  At this point, you have a version of ntop that will use the PF_RING ring module in the kernel. Congrats.

• Some Statistics:cat /proc/net/pf_ring/info
  will give you some output like this:

  Version : 3.2.1
Bucket length : 128 bytes
Ring slots : 4096
Sample rate : 1 [1=no sampling]
Capture TX : No [RX only]
Total rings : 0


  Now there is one drawback: libpcap will not report accurate drop statistics when linked with pfring, so the 0 dropped packets, that ntop reports, are definately wrong.

  cat /proc/net/pf_ring/20 (where 20 is some random number) shows the actual stats:

  Bound Device : eth0
Version : 6
Sampling Rate : 0
Cluster Id : 0
Tot Slots : 7181
Slot Len : 146
Data Len : 128
Tot Memory : 1048576
Tot Packets : 62206634
Tot Pkt Lost : 14292126
Tot Insert : 47914508
Tot Read : 47914434


  Do the math (and wisely distinguish between capture- and drop-rate): 14292126 out of 62206634 is a drop-rate of about 23%. Sounds high? Well, it isn’t, regarding the fact, that my network has peaks up to and over 600Mbps and a current average of about 150Mbps after a 30min runtime. Viewing table 3 in the PDF mentioned in the introduction, you can see, that the performance highly depends on the packet size.
  Now 55% of my traffic has sizes between 60 and 256 bytes (i.e. small packets), for which the table promises a capture-rate of 75%. Another 35% of my traffic is above 1025 bytes, where a Linux 2.6 with NAPI + PF_RING and extended libpcap performs best (93% capture-rate). It is quite poor in between (47% capture-rate), but still the best of its competitors. Anyhow, regarding the fact, that most of my packets are big or small, it was a wise choice to use this specific polling strategy, and a 23% drop-rate is about the result I have expected. Tests with standard kernel and libpcap had drop-rates of up to 40%.
  In my study thesis “Intrusion Detection with heterogenous Sensors” you can find detailed long-term statistics in the Evaluation Chapter (Chapter 5), “Sniffing Performance” featuring nice graphs that illustrate the work of the ringbuffer.

  /var/log/messages should have some stats, too, upon every application using pf_ring
  
Welcome to PF_RING 3.2.1
(C) 2004-06 L.Deri
NET: Registered protocol family 27
PF_RING: bucket length 128 bytes
PF_RING: ring slots 4096
PF_RING: sample rate 1 [1=no sampling]
PF_RING: capture TX No [RX only]
PF_RING: transparent mode Yes
PF_RING initialized correctly.
PF_RING: registered /proc/net/pf_ring/
RING: succesfully allocated 1024 KB [tot_mem=598076][order=8]
RING: allocated 7181 slots [slot_len=146][tot_mem=1048576]


  Now it is possible to manually remove and insert the kernelmodule into the kernel.
  lsmod shows if ring.ko is loaded and used, rmmod removes it and it can be loaded with configurable parameters via

  
insmod /lib/modules/2.6.17.11/kernel/net/ring/ring.ko bucket_len=64 num_slots=4096 sample_rate=1 transparent_mode=0

  bucket_len: Specifies the maximum packet length captured by PF_RING. This is equivalent to snaplen of libpcap. If you are doing something like ntop where you only want to look at the packet headers, then a bucket_len of 64 works. But if you want to inspect the entire packet, then you will have to make sure that the bucket_len is at least as big as the MTU
  of the network.
  num_slots: Number of slots in the ring. The bigger the better is the performance the more memory you use. 4096 should be fine, you can tweak it though.
  sample_rate: 1 means regard every packet (no sampling), 2 means every second and so on…
  transparent_mode: By default a packet that is handled by at least a ring is not forwarded to the upper Linux layers. This will result in faster capture speeds but will prevent legacy applications (not recompiled with the new libpcap-ring) from operating. If you set it to 1 it reverts the ring to the old behaviour (i.e. packets are forwarded to upper layers) but this will decrease the benefits of the ring as it will result in worse results.

  Tweak it according to your purpsose.

  To conclude: I don’t know if it makes any difference, but by checking your NIC via

  ethtool -g eth0 you can see the internal ringbuffer settings. You can change it to a greater value using
  
ethtool -G eth0 rx 4096

————

Top-Schnäppchen & Gutscheine: DealDoktor – Der einzige Schnäppchen-Blog mit Doktortitel

Hier gibt es viele Gutscheine, Gratis-Artikel und täglich die besten Spar-Angebote aus dem Internet, z.B. Möglichkeiten, kostenlos ins Kino zu kommen und mehr…

Nachdem also getmail und dovecot (wie im Tutorial beschrieben) zusammenarbeiten, machen wir uns an die Installation von Spamassassin:

cd /usr/ports/mail/p5-Mail-SpamAssassin && make install clean

Unter /usr/local/etc/mail/spamassassin gibt es nun eine local.cf.sample, die man in local.cf umbenennt. Diese Datei steuert das Verhalten von spamassassin. Sie kann nun angepasst werden (wenn man weiß, was man tut) oder mit Hilfe eines selbsterklärenden Webinterfaces erstellt werden: http://www.yrex.com/spam/spamconfig.php. Es ist noch anzumerken, dass in dem genannten Verzeichnis die globale Config-File von Spamassassin liegt. Wird spamassassin mit Hilfe des -u Flags im Kontext eines bestimmten Users ausgeführt, so ist die Konfigurationsdatei für diesen User so anzulegen: ~/.spamassassin/user_prefs (mit gleichem Inhalt).

Der Inhalt meiner Datei sieht so aus:
# SpamAssassin config file for version 3.x
# NOTE: NOT COMPATIBLE WITH VERSIONS 2.5 or 2.6
# See http://www.yrex.com/spam/spamconfig25.php for earlier versions
# Generated by http://www.yrex.com/spam/spamconfig.php (version 1.50)

# Mail using locales used in these country codes will not be marked
# as being possibly spam in a foreign language.
ok_locales en


Der Score Treshold kann beliebig gewählt werden, ich habe ihn zunächst hoch gesetzt, um das System zu testen und werde ihn nach weiteren Analysen der eingehenden eMails noch weiter anpassen. Mittlerweile arbeite ich sehr gut mit einem Score von 8.6. Diesen Wert habe ich gewählt, da ich einen Newsletter beziehe, der leider mit 8.5 Spam-Punkten bewertet wird.

Jetzt machen wir uns an die Bearbeitung einer geeigneten .procmailrc Datei, die procmail steuert und so die Mails je nach Spameinstufung in Mailverzeichnisse sortieren kann. Dazu erstellen wir im HOME-Verzeichnis des Users, unter dem getmail läuft (hier: bjoumail), eine Datei namens .procmailrc mit folgendem Inhalt:
# SpamAssassin sample procmailrc
# ==============================

#:0 c
#| /usr/bin/vacation your_loginname


Anmerkungen: Den Workaround habe ich nicht getestet, sondern einfach so aus einer Vorlage übernommen. Den Folder "Spam" müssen wir in unserem eMailprogramm, welches auf den dovecot IMAP-Server zugreift, natürlich noch erstellen. Da dovecot nicht mit mboxes, sondern mit Maildirs arbeitet, ist der trailing slash bei /home/bjoumail/mail/.Spam/ besonders wichtig.

Nun muss noch die /usr/local/etc/postfix/master.cf angepasst werden. Dazu ändert mann die Zeile

smtp inet n - n - - smtpd

in

smtp inet n - n - - smtpd -o content_filter=spamassassin

Man fügt also einen content_filter hinzu. Am Ende der Datei muss man postfix nun mittweilen, was dieser Filter tun soll:

spamassassin
         unix - n n - - pipe
     user=nobody argv=/usr/local/bin/spamc -e /usr/local/sbin/postfix -oi -f ${sender} ${recipient}

Dabei ist sichrzustellen, dass die drei obigen zeilen entweder in einer Zeile in der Datei stehen, oder die zwei unteren Zeilen mit Leerzeichen eingeleitet werden. Der Uer 'nobody' ist ggf. anzupassen.
Jetzt kann man das System testen. Eingehende Mails sollten im Header nun stehen haben, dass sie erfolgreich durch spamassassin gepiped und analysiert wurden und je nachdem als Spam oder Ham eingestuft wurden:

Ham:
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
my-server.domain
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=10.0 tests=BAYES_00 autolearn=ham
version=3.1.1

Spam:

X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
my-server.domain
X-Spam-Level: ********************************
X-Spam-Status: Yes, score=32.9 required=10.0 tests=BAYES_99,
DATE_IN_FUTURE_03_06,FROM_ENDS_IN_NUMS,FUZZY_PHARMACY,
HTML_IMAGE_ONLY_24,HTML_MESSAGE,INFO_TLD,RCVD_NUMERIC_HELO,
UPPERCASE_25_50,URIBL_AB_SURBL,URIBL_JP_SURBL,URIBL_OB_SURBL,
URIBL_SBL,URIBL_SC_SURBL autolearn=spam version=3.1.1


Hat man noch einen Ordner voll mit Spam, so kann (und sollte) man Spamassassin trainieren, um Mails besser klassifizieren zu können. Das geht mit sa-learn, bspw
sa-learn --progress --spam /home/bjoumail/mail/.Spam/cur/
Der Unterordner cur ist der Ordner, wo dovecot die (gelesenen) Mails speichert. Mit dem Trigger --ham kann man spamassassin natürlich auch auf gewollte Mails trainieren. Mehr dazu über man sa-learn.

• So what is MRTS anyway?
• Website: http://apt-get.dk/mrts
• Description: MRTS is short for “MRTG RRDtool Total Statistics”. It is a PHP script written by Thor Dreier that uses “MRTG and RRDtool to sum up total traffic monthly and yearly”. But why making words, if you can see the full power of MRTS in some examples: http://mrts.domainnet.dk Just click on any device and MRTS will show you the traffic-graphs and some statistics on how much traffic you have made during the actual/last months/year.

OK, now we know what MRTS does, but…

• What is MRTG?
• Website: http://oss.oetiker.ch/mrtg/
• Description: “The Multi Router Traffic Grapher (MRTG) is a tool to monitor the traffic load on network-links. MRTG generates HTML pages containing graphical images which provide a LIVE visual representation of this traffic. [...] MRTG is based on Perl and C and works under UNIX and Windows NT.” Again, we want to see some results on that, to see its power. So just take a look at http://www.stat.ee.ethz.ch/mrtg and pick a device. I think you’ll be satisfied. MRTG goes along alone very well, so if the examples, you have just seen, is everything you want, just install MRTG and you are free to go. (Note: You must NOT use the mrtg.cfg we will configure below. Just skip the Logformat: rrdtool command for MRTG standalone setup). I, for my part, was not fully satisfied with MRTG, because I wanted my router/server to show me detailed traffic summaries over the last months/year. And that’s where MRTS comes into play, because MRTS sums up this traffic using MRTG and RRDtool.

• What is RRDtool?
• Website: http://oss.oetiker.ch/rrdtool/
• Description: “If you know MRTG, you can think of RRDtool as a reimplementation of MRTGs graphing and logging features. Magnitudes faster and more flexible than you ever thought possible. RRD is the Acronym for Round Robin Database. RRD is a system to store and display time-series data (i.e. network bandwidth, machine-room temperature, server load average). It stores the data in a very compact way that will not expand over time, and it presents useful graphs by processing the data to enforce a certain data density. It can be used either via simple wrapper scripts (from shell or Perl) or via frontends that poll network devices and put a friendly user interface on it.” RRDtool allows you to almost log everything and convert it into nice impressive graphs. Take a look at http://oss.oetiker.ch/rrdtool/gallery/index.en.html for some examples.

As MRTG needs the Simple Network Management Protocol (SNMP) to work properly, we will take a short look on what this does:

• What is SNMP?
• Website: http://net-snmp.sourceforge.net/
• Description: “SNMP is an application-layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth.” For our plans, we need to install net-SNMP (formerly known as ucd-SNMP) that consists of various tools relating to SNMP.

So, enough explanations, let’s get to work!

First thing to do is to check, which of the above mentioned packages you already have installed. No idea? Well, then you should do a simple
ls /var/db/pkg or pkg_info
which lists the packages, you have installed using the FreeBSD ports. If you don’t know what the FreeBSD ports are, then you probably won’t have to read on, as some basics really are required in this tutorial Anyway, i’m trying to explain step by step. After you have checked your installed packages, install the packages you still need.


Net-SNMP: /usr/ports/net-mgmt/net-snmp
MRTG: /usr/ports/net-mgmt/mrtg
RRDtool: /usr/ports/net/rrdtool


Some of these programs depend on various libraries (e.g. zlib, libpng, GD), but that’s the good thing: The port-install-mechanism will automatically check, if you have them or not and it will install them, if needed. Do a

make && make install && make clean

in the corresponding port directories to install that specific port.
Now it could take a while until all ports are compiled.

Alright, as far as I see, we are done compiling So let’s get it on, this is the harder part:
• Configuration of net-SNMP

Create a snmpd.conf with

snmpconf -i -g basic_setup

This will start a walktrough asking you some questions about your system. The book “Absolute BSD” (“FreeBSD de Luxe” in Germany) explains in detail, how to properly set up net-SNMP. I’m gonna make it short:

• Type y for configuring “the information returned in the system MIB group”
• syslocation is a string of the location of your server, e.g. “my room”, syscontact is you.
• Type y for setting “the value of the sysServices.0 OID”
• The following questions should be answered with “1″ (yes) or “0″ (no). Commonly it is “0″ for repeater and bridge and “1″ for IP, TCP, SMTP
• Type y for configuring “the agent’s access control”. Then answer the following three questions (read-write user based access, read-only user based access, read-write community access) with n. Answer the next one (read-only community access) with y. You will be asked for a community name. Invent one or take the default: public (NOT RECOMMENDED!) The network to accept this community from should be the loopback (127.0.0.1) or something like 192.168.100.0/24 for example. 0.0.0.0/0 will give anyone access. Don’t use this! Hit [return] for “no restriction” in the next question. Then you are finished, don’t do another community line. The rest can all be answered with n.
• Finally send the SNMPdeamon a Hangup Signal for re-reading the configuration, if SNMP was running while configuring: ps faux | grep snmpd tells you the PID to send kill -HUP theSnmpdPid to.

The snmpd.conf is now stored in /usr/local/share/snmp/. Move it to /usr/local/etc/snmp/snmp.conf (Note: This Setup was very basic and does by far not show the power of net-SNMP. But for our purpose that is all we need right now. You should probably read some literature about it and do a better configuration afterwards. Read http://net-snmp.sourceforge.net/tutorial/tutorial-5/mrtg/index.html for more information on how to set up MRTG to monitor disk-space, CPU-load and so on…)

OK, next step is to start the services, i.e. snmp and mrtg. You can do this via the start scripts in

/usr/local/etc/rc.d/

Speaking of start-scripts, make one for MRTG (mrtg.sh) if there is non in the directory, we’ll need it later. Of course, you only have to do this step, if the installation of MRTG does not have put an autostart script itsself into /usr/local/etc/rc.d/. When I installed it, this was not the case so I had to make my own.

#!/bin/sh
/usr/local/bin/mrtg --logging=/var/log/mrtg.log --pid-file=/var/run/mrtg.pid /etc/mrtg.cfg

Now start snmpd (e.g. ‘/usr/local/etc/rc.d/snmpd.sh start’). Check if the processess are running!
PS: If you are using one of the lastest FreeBSD Releases (5.x and up) you are advised to start the deamons via /etc/rc.conf at boot-time. Consult some other Information source on how to use the rc-scripts.

• Configuration of MRTG

OK, snmpd is running, let’s configure MRTG. The binaries should be localted in /usr/local/bin. The “\” in the following command means, that this should be one line. Type

cfgmaker --global 'WorkDir: /usr/home/www/stats' --global 'Options[_]: growright' \
--output /etc/mrtg.cfg community@router.abc.xyz

where WorkDir is the directory, where the images and html pages should be placed (Note: Later on we will have no images and htmlpages in that directory, but one php-script (MRTS) and some *.rrd files containing the RRDtool data). It has to be visible to a webbrowser, of course. You can play with the arguments, this one should be the best for the first time, for detailed documentation check the website or your man-pages. output is the directory, where your config file will be placed. Replace community@router.abc.xyz with your specification, i.e. public@localhost. This should test your devices and have an output like this:

--base: Get Device Info on public@localhost:
--base: Vendor Id:
--base: Populating confcache
--snpo: confcache public@localhost: Descr rl0 --> 1
--snpo: confcache public@localhost: Descr lp0 --> 2
--snpo: confcache public@localhost: Descr ed1 --> 3
--snpo: confcache public@localhost: Descr lo0 --> 4
--snpo: confcache public@localhost: Descr tun0 --> 5
--snpo: confcache public@localhost: Ip 127.0.0.1 --> 4
--snpo: confcache public@localhost: Ip 192.168.100.100 --> 1
--snpo: confcache public@localhost: Ip 213.23.58.244 --> 5 [It's a dynamic IP, just for your notice ]
--snpo: confcache public@localhost: Type 6 --> 1
--snpo: confcache public@localhost: Type 34 --> 2
--snpo: confcache public@localhost: Type 6 --> 3 (duplicate)
--snpo: confcache public@localhost: Type 24 --> 4
--snpo: confcache public@localhost: Type 23 --> 5
--base: Get Interface Info
--base: Walking ifIndex
--base: Walking ifType
--base: Walking ifSpeed
--base: Walking ifAdminStatus
--base: Walking ifOperStatus
--base: Writing /etc/mrtg.cfg

If it does not do something similar like this, you did something wrong in configuring snmpd or snmpd is not running. So take a look at the output. What do you want to log? I wanted to log my internet-traffic, so i had to take device number 5 (device 4, i.e., is software-loopback, device 1 is internal traffic in your LAN). Open your newly configured /etc/mrtg.cfg and check it out. It needs some reconfiguration for our needs. First lines without a comment should be

WorkDir: /usr/home/www/stats/
Options[_]: growright
Logformat: rrdtool
RunAsDaemon: Yes
Interval: 5
PathAdd: /usr/local/bin/
IconDir: http://my.url.com/stats/icons/

I really suggest to read http://people.ee.ethz.ch/~oetiker/webtools/mrtg/reference.html for more and detailed information, though i am going to explain the commands above.
You already know the first two lines. The third one is very important. Without it, MRTG would create the images itsself without using RRDtool. But i like RRDtool images better Furthermore you would have to do a cronjob for MRTG AND indexmaker, to create your corresponding html-files as well. With the Logformat command MRTG will save all its data in one file called ##device##.rrd where ##device## is i.e. localhost. Thanks to that file, we can use RRDtool to evaluate our graphs. RunAsDaemon is a very nice feature for avoiding a cronjob. After starting MRTG, it is being daemonized and not launched repeatedly (as it would have been with cron). MRTG will be active every 5 minutes. PathAdd is not always needed, but it can’t harm. It’s the path to your RRDtool binary and IconDir is the directory the icons are in, that came with the installation of MRTG (look for the icons in /usr/local/share/mrtg/) After these commands your devices are being listet. Comment those out that you do not want to log. I just wanted to log device #5. Should look something like this:

### Interface 5 >> Descr: 'tun0' | Name: '' | Ip: '213.23.58.171' | Eth: '' ###

Target[localhost_5]: 5:public@localhost:
SetEnv[localhost_5]: MRTG_INT_IP="213.23.58.171" MRTG_INT_DESCR="tun0"
MaxBytes[localhost_5]: 750000
Title[localhost_5]: Traffic Analysis
PageTop[localhost_5]: <H1>Internet Traffic Analysis</H1>
<TABLE>
<TR><TD>System:</TD> <TD>FreeBSD 6-STABLE in Bjou's Home in Karlsruhe City</TD></TR>
<TR><TD>Max Speed:</TD> <TD>Arcor-DSL 6 MBit</TD></TR>
</TABLE>


You are free to alter some values, I deleted some of them within the <TABLE></TABLE> because I didn’t find them very interesting. It will not affect your MRTS appearance anyway, but your MRTG output, if you want to make a standalone MRTG installation or if you want to use an “on-the-fly”-script as mrtg-rrd or 14all.cgi (which I also advise to take a look at, though you don’t need it). Maybe don’t alter anything before really getting started, you will know what you want to alter later, when you see the results (Note again: You won’t actually see the above strings in your MRTS output!). First line is the most important one: 5:public@localhost: 5 is your interface number mentioned above followed by community@router.abc.xyz. Thor Dreier explains on his MRTS website how to get the value for MaxBytes:

“In “MaxBytes” we have set how many bytes the device maximum can transfer:
(100Mbit * 1000000bit/Mbit / 8byte/bit = 12500000byte).”
So as I have a 1.5 MBit bandwidth, we’ll have to set: (6Mbit * 1000000bit/Mbit / 8byte/bit = 750000 byte)

Be sure to read Thor’s MRTS site properly for some additional information I did not mention here (especially if your are a Debian User).
What, you are still here? READ IT NOW!
OK, looks like we configured the mrtg.cfg well, so let’s start MRTG using our script above. You are getting error messages? No problem, this is normal the first time(s) you start MRTG. You maybe want to run MRTG under a certain user (running processes under root is not always the wisest decision) therefore you will need the --user=mrtg_user --group=mrtg_group switches in your mrtg.sh startscript. It could be that there are some problems then, if mrtg_user does not have the rights it needs to access/write certain files. Try yourself, I won’t explain that here.
Having started MRTG, it should say “Daemonizing MRTG …” as a result. Check your logfile and your processes if it was successful.

• Configuration of RRDtool

RRDtool does not really need any further configuration, so I would say, we are almost done. Anyway, check if RRDtool
at least works. You can do this by taking a look at http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/tutorial/rrdtutorial.html
and doing this lesson at least until you got the first results and you are sure, RRDtool works.

• Configuration of MRTS itsself

Now comes the best part, the wonderful MRTS. Download from http://apt-get.dk/mrts/download/

(same files with different extension) and rename to *.php. Open the file and configure the following:


/* The directory where the rrd files are located */
$dir = ‘/usr/home/www/stats’;

/* List all devices that MRTS should’n display, */
$exclude = array(’secret’, ‘topsecret’);

/* RRDtool path – where is the the executable located */
$rrdcommand = ‘/usr/local/bin/rrdtool’;


The first path is exactly the MRTG WorkDir, second one explains itsself, last one is the path to your rrdtool executable. (Note:
rrdtool in the path listed above in not a folder, but the rrdtool binary!)
Well, that’s it. If your Apache is properly configured, give it a try. But first check, that you do not run your script in “safe mode php”.
If you server does this as standard, you have to put something like this in your httpd.conf:


<Directory “/path/to/mrts”>
php_admin_value safe_mode 0
<Directory>




Put the MRTS php script in /usr/home/www/stats/ and surf on it. And….. whoo-hoo, you are done!

[code]
# run the ticketwatcher every 15 minutes
*/15 * * * * cd /path/to/ticketwatch && bash /path/to/ticketwatch/ticketwatch.sh > /dev/null 2>&1
[/code]

erledigt dann die Automatisierung.

[code lang="bash"]
#!/usr/local/bin/bash
# Ticketwatch.sh by Bjoern Weiland

URL="http://tickets.fifaworldcup.com/cgi-bin/ds_wmd?fun=pksbyeventreihe&doc=ds_einzel1&affiliate=wmd&key=0"
MAILTO="mail1@mail.com"
COPYTO="mail2@mail.com, mail3@mail.com"  # comma separated list

function init ()
{
        lynx -nolist -dump $URL > lynxdump.old
        md5 lynxdump.old > md5sum.old
}

if ! [ -f lynxdump.old ]; then
        init
fi

lynx -nolist -dump $URL > lynxdump.now
md5 lynxdump.now > md5sum.now

SUMOLD=`tail -c 33 md5sum.old`
SUMNOW=`tail -c 33 md5sum.now`

if [ "$SUMOLD" != "$SUMNOW" ]
        then
                echo Changes!
                diff lynxdump.now lynxdump.old | mail -s Ticketwatch -c $COPYTO $MAILTO
                rm lynxdump.* md5sum.*
                init
        else
                echo No Changes
fi
[/code]

Vorab-Info: Wer nicht direkt vom Server aus drucken möchte, kann darauf verzichten, Turboprint auf diesem zu installieren, dann reicht es, eine RAW-Queue über CUPS einzurichten und die Treiber auf den Clients zu installieren.

Allein die Installation von Turboprint (TP) gestaltete sich auf FreeBSD allerdings als nicht intuitiv.

• Vorbereitung: Linux Emulation und CUPS installieren. Da der Pixma IP4200 ein USB Drucker ist, müssen außerdem folgende Einträge im Kernel vorhanden sein (gegebenenfalls neu bauen):
  
device scbus
device da
device pass
device uhci # USB Hub, (kann auch ohci sein) siehe unten!
device usb
device umass
device ulpt # USB Printer device


  Note: To determine whether you need device uhci or device ohci try checking dmesg:

  hivemind# dmesg | grep uhub
  uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1

• Turboprint Installationsskripte anpassen: Setupfehler der Art

  Begin installation now (y/n)? y
setup: lib/install-static: not found
setup: lib/install-post: not found
setup: lib/install-info: not found

  habe ich behoben, indem ich in den genannten Dateien folgende Änderung vorgenommen habe:
  #!/bin/bash --> #!/usr/local/bin/bash (#!/bin/sh sollte es auch tun). Diese Ersetzungen kann man am besten gleich bei allen Dateien machen, die die Shell brauchen, insbesondere auch bei lib/pstoturboprint.

• Sollten Fehler über illegal arguments von install erscheinen, dann folgende Ersetzungen in der lib/install-static vornehmen:
  install --mode=644 --> install -m 644
• Da bei mir weder ein ‘lp’ user noch eine ‘lp’ Gruppe existierte, musste ich diese Zeilen
chown lp "$TPPATH_LOG/turboprint_lpr.log"
chown lp "$TPPATH_LOG/turboprint_cups.log"
chgrp lp "$TPPATH_LOG/turboprint_lpr.log"
chgrp lp "$TPPATH_LOG/turboprint_cups.log"
  in der install-post noch entsprechend umändern.

Danach funzte die Installation mit sh setup einwandfrei. Die Erst-Konfiguration konnte ich nun mit tpsetup vornehmen, da mir für xtpsetup ja das nötige X-Paket (bzw die gtk-libs) fehlen. Bei der Installation sollte CUPS erkannt werden (“Installation for CUPS printing system (TP_CUPS=1)”). Das war allerdings nicht der Fall (“TP_CUPS=0″), also musste ich folgende Einträge in der system.cfg von Turboprint anpassen. Dies sind die angepassten Pfade:

TPPATH_CUPSDRIVER=/usr/local/share/cups/model
TPPATH_CUPSSETTINGS=/usr/local/etc/cups/ppd
TPPATH_CUPSFILTER=/usr/local/libexec/cups/filter


Gegebenenfalls nochmals setup ausführen. Die Installation solte jetzt ohne weitere (Fehler-)meldungen ablaufen (so war’s zumindest bei mir).

• Turboprint ist nun installiert und kann angepasst werden: tpsetup ausführen für initiale Konfiguration, den Canon Drucker hinzufügen. Am Ende sollte das Ganze z.B. so aussehen:
  
=============================================
Turboprint Setup - Printer Setup =============================================
# Print Jobs : 0
S - Short Name : PixmaIP4200
L - Long Name : Canon_PIXMA_iP4200
C - Connection : Local Printer
N - Device Name : usb:/dev/ulpt0
...snip...
• Wenn nicht schon geschehen, sollte man nun die Datei /usr/local/etc/cups/cupsd.conf anpassen. Dies ist sehr wichtig und muss fehlerfrei geschehen. Ich habe Ewigkeiten gebraucht, rauszufinden, warum der Drucker korrekt erkannt wird, aber einfach nicht drucken will. Es lag ein kleiner Fehler in der cupsd.conf vor, was schwer in der Logfile einzusehen war und den Druck verhinderte. Ich habe die Datei fast so gelassen wie sie kam, habe nur Logfiles, Servername und -admin gesetzt, jedoch die Security Options-Sektion detailliert bearbeitet, hierfür sollte man sich Zeit lassen.
• Über das CUPS Webinterface kann man nun auf die CUPS Drucker zugreifen:
  http://server-ip:631
  Als nächstes sollte der neue Drucker hinzugefügt werden. Da sich Turboprint mittlerweile sehr gut in CUPS integriert, sollten die TP-Treiber hier nun verfügbar sein. Zunächst trägt man einen Namen und eine Beschreibung ein. Unter ‘Device for PixmaIP4200′ wählt man nun ‘USB Printer #1′. Dieser Eintrag ist allerdings nur verfügbar, wenn das nötige device /dev/ulpt0 existiert, was wiederum nur mit der oben genannten Kerneloption der Fall ist. Nun wählt man den ‘Canon Turboprint’ Treiber und das entsprechende Modell. Der Drucker sollte nun erkannt werden.
• Um die Installation zu testen, können wir nun Testseiten drucken. Ganz intuitiv unter http://server-ip:631/printers/PixmaIP4200 und/oder direkt mit tpconfig: Drucker auswählen, in die Toolbox wechseln (T) und eine Testpage (T) auswählen und drucken (0 – 2). Bemerkung: PixmaIP4200 ist der gewählte Druckername.
• Sollte alles funktionieren, kann der Drucker freigegeben werden für das lokale Netz. Das geht z.b. per IPP/CUPS oder Samba. Dabei helfen:
  Drucken über Samba
  Drucken über IPP
  Ich habe das ganze über IPP gelöst, geht einwandfrei schnell und ohne Probleme beim ersten Mal (bei Windows!!)
• Dazu sei noch folgendes zu sagen: Will man in heterogener Umgebung (d.h. einem LAN mit Win und Linux/*BSD Rechnern) drucken, kann der Drucker als RAW-Printer eingerichtet werden, d.h. ohne Treiber. Nachteil: Vom Server direkt aus ist das Drucken unmöglich. Die Treiber werden dann auf jedem Client einzeln installiert, bei einem “nur-Windows-LAN” ist das auch kein Problem, da der Pixma mit Windows-Treibern kommt. Windows ist es allerdings egal, ob der Drucker auf dem Server dazu als RAW-Printer eingerichtet ist oder nicht. Wir haben den Drucker auf dem Server nicht als RAW-Printer installiert, sondern mit den TP-Treibern. Vorteil: Man kann vom Server aus drucken und von allen Win-Clients. Nachteil: Man kann nicht von Linux-Rechnern drucken, die auch noch im Netz hängen. Dazu muss man den Drucker wie erwähnt zu nem RAW machen. Das Ganze geschieht wieder über das CUPS-Webinterface, Drucker modifizieren und bei ‘Hersteller/Modell’ den Eintrag ‘RAW’ auswählen. Jetzt kann man nicht mehr vom Server aus, dafür von allen Clients drucken, ob Win oder Linux/*BSD. Ich habe noch einen ubuntu-Rechner, auf dem nun also das Drucken über den Server ermöglicht werden soll.
• Das hat auch eine Weile gedauert, weil es zuerst nicht so funktionierte wie es sollte. Das ubuntu Wiki sagt z.B., in der client.conf solle der ServerName Eintrag angepasst werden. Das hat bei mir allerdings nicht geklappt, weil dann der Eintrag unter System – Systemverwaltung – Drucker den Drucker zwar erkannte, aber immer die Einstellungen des Servers übernahm, also auch, dass der Drucker am lokalen USB-Port hängt, was für den ubuntu Rechner ja nicht zutrifft. Man konnte es zwar in einen IPP Eintrag ändern, jedoch wurde das beim Beenden nicht gespeichert. Der Eintrag in der client.conf blieb bei mir deshalb auskommentiert, ebenso wie das Polling in der cupsd.conf. Die Vorgehensweise war also folgende: TP auf ubuntu installieren, Drucker unter System – Systemverwaltung – Drucker hinzufügen (die TP Treiber sollten in das Treiber-Auswahl-Menü nun integriert sein), Pixma4200 Treiber von Canon (Turboprint) installieren und wie bei den Win Rechnern den gleichen IPP-Pfad. Nun sollte alles funktionieren!
• Fehlersuche: Sollte etwas nicht klappen, ist die Fehlersuche hier recht schwierig. Es sei zu sagen, dass evtl ein paar zusätzliche Pakete (z.B. für Epson oder HP Drucker) installiert werden müssen/sollten. Auch das Paket a2ps kann nicht schaden, ob man es braucht entzieht sich meiner Kenntnis, ich bin erstmal froh dass alles läuft.