Ein sehr nützliches Tool um die Temperaturen der Hardwarekomponenten auf einem Linux-Rechner anzuzeigen ist Psensor.
Es kann ja immer mal sein, dass ein Kühler ausfällt oder Staub seine Wirkung verringert. Mit Psensor kann man auch Grenzwerte einstellen, deren Überschreitung einen Alarm auslöst.
Eine Installationsbeschreibung kann ich mir hier schenken, die gibt es unter:
https://pinguin.gws2.de/ubuntu-temperaturen-des-systems-anzeigen-diagnosetool/
https://wiki.ubuntuusers.de/Psensor/
Für den Austausch von Medien nutzt Talk das Protokoll WebRTC (Web Real-Time Communication), einen offenen Standard zur direkten Kommunikation zwischen Rechnern. Die aktuellen Browser unterstützen dieses Protokoll, sodass damit Videokonferenzen problemlos möglich sind, zumindest innerhalb eines lokalen Netzes.
Sind die beteiligten Rechner in verschiedenen Netzen, so taucht ein Problem auf. Die Browser müssen ihre eigene IP-Adresse und die IP-Adresse der Gegenstelle wissen. Dies ist leider oft nicht der Fall, wenn sie hinter einem NAT-Router sitzen, z.B. einer Fritzbox. Hier kennen die Geräte nur ihre netzinterne IP-Adresse, z.B. 192.168.1.52, aber nicht die offizielle IP-Adresse, die nur der Router kennt.
Dieses Problem lässt sich mit einem STUN-Server (Session Traversal Utilities for NAT) lösen. Bei dem STUN-Server melden sich die beteiligten Rechner, dabei lernt er ihre öffentlichen IP-Adressen kennen und kann sie an die Gesprächspartner weitergeben. Mit diesen Informationen können die Geräte dann direkt miteinander kommunizieren.
Der Betrieb eines STUN-Servers ist relativ problemlos, da nur sehr geringe Datenmengen anfallen. Es gibt daher auch öffentliche STUN-Server, z.B. bei Nextcloud stun.nextcloud.com:443 (Voreinstellung in Talk).
Leider langt der STUN-Server heutzutage nicht mehr. Ein Router, wie die Fritz!Box, macht nämlich nicht nur NAT, sondern stellt auch eine Firewall zur Verfügung. Verbindungen von außen, aus dem Internet, auf die Rechner innerhalb des lokalen Netzes sind so nicht möglich, ohne auf dem Router Ports freizugeben und auf den Zielrechner weiterzuleiten. Das wäre eine recht aufwändige Vorgehensweise. Es sind nur Verbindungen aus dem Inneren des jeweiligen Netzes zu öffentlich zugänglichen Rechnern möglich.
Hier kommt der TURN-Server ins Spiel (Traversal Using Relays around NAT), er ermöglicht es den Clients Daten ohne eine direkte Verbindung auszutauschen (Relay Server). Sämtlicher Datenverkehr läuft dann durch diesen Server.
Öffentliche TURN-Server wird man in der Regel nicht finden, da rechte hohe Datenvolumina anfallen. Für eine ordentliche Videoqualität werden 500 kbit/s angegeben. Bei 3600 Sekunden in einer Stunde macht das dann 500×3.600 = 1.800.000 kbit etwa 1.800 mbit, also schon ein erhebliches Datenvolumen.
Da der Zugriff auf das Mailsystem auch immer häufiger mobil erfolgt scheint mir eine Verschlüsselung der Verbindung unvermeidlich. Dazu muss man in die Konfiguration von Postfix und Dovecot eingreifen. Ausgangspunkt für meine Konfiguration ist die Server-Beschreibung unter http://www.debacher.de/wiki/Root-Server_mit_OpenSuSE_13.2 .
Da mir das System von letsencrypt sehr zusagt möchte ich die zugehörigen Zertifikate auch für das Mailsystem nutzen. Dazu habe ich mir einen virtuellen Apache-Server eingerichtet, der auf http://imap.meine-domain.de hört und ansonsten keinen Inhalt zur Verfügung stellt. Der virtuelle Server ist nur für die Erstellung und Verlängerung der Zertifikate wichtig.
Hierfür habe ich mir eine letsencrypt.ini angelegt:
# Wir nutzen 4096 bit RSA key statt 2048 rsa-key-size = 4096 # allgemeine Angaben email = <name>@<domain> authenticator = webroot # Domains fuer die wir Zertifikate beantragen, die erste in # der liste legt den Hauptnamen fest. Alle Domains müssen beim # Aufruf erreichbar sein domains = imap.debacher.de, smtp.debacher.de # Dies ist das Verzeichnis zur Domain, wo letsencrypt seinen Hash in # /.well-known/acme-challenge schreiben will. Der Pfad muss auf / enden webroot-path = /srv/www/vhosts/imap.debacher.de/httpdocs/
Dann mittels
/root/letsencrypt/letsencrypt-auto certonly --config /srv/www/vhosts/imap.debacher.de/letsencrypt.ini
das Zertifikat erzeugt.
Für Dovecot müssen dann folgende Informationen in der Konfigurationsdatei stehen:
protocols = imap pop3 lmtp sieve ssl = yes ssl_cert = </etc/letsencrypt/live/imap.debacher.de/fullchain.pem ssl_key = </etc/letsencrypt/live/imap.debacher.de/privkey.pem
Nach einem Neustart greift Dovecot dann auf das Zertifikat zu.
Abfragen kann man das Zertifikat dann mittels:
openssl s_client -connect imap.debacher.de:pop3s
oder
openssl s_client -connect imap.debacher.de:imaps
oder
openssl s_client -connect imap.debacher.de:smtp -starttls smtp
Für Postfix muss etwas mehr gemacht werden. Wir haben ja zwei Richtungen zu beachten, Postix kann als Client und als Server dienen. Wenn er Mails an andere Rechner abliefert, dann ist er Client (smtp_…), ansonsten Server (smtpd_…).
Ich habe an die Konfigurationsdatei /etc/postfix/main.cf folgende Zeilen angehängt:
# tls config smtp_tls_note_starttls_offer = yes # eingehende Verbindungen smtpd_use_tls = yes smtpd_enforce_tls = no # Obiges kann zusammengefasst werden zu smtpd_tls_security_level=may smtpd_tls_key_file = /etc/letsencrypt/live/imap.debacher.de/privkey.pem smtpd_tls_cert_file = /etc/letsencrypt/live/imap.debacher.de/fullchain.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3 #tls_random_source = dev:/dev/urandom #tls_random_prng_update_period = 3600s # ausgehende Verbindungen smtp_use_tls = yes smtp_enforce_tls = no # Obiges kann zusammengefasst werden zu smtp_tls_security_level=may smtp_tls_key_file = /etc/letsencrypt/live/imap.debacher.de/privkey.pem smtp_tls_cert_file = /etc/letsencrypt/live/imap.debacher.de/fullchain.pem smtp_tls_loglevel = 1 smtp_tls_mandatory_protocols=!SSLv2, !SSLv3
Nun muss noch in der Datei /etc/postfix/master.cf eine Zeile auskommentiert werden:
tlsmgr unix - - n 1000? 1 tlsmgr
Etwas mehr Aufwand bedeutet es den Nutzern der eMail-Domain die Konfiguration ihrer Mail-Clients zu beschreiben. Zumindest für Thunderbird gibt es eine genial einfache Lösung dafür, Danke an Lukas Thiel für den Hinweis.
Thunderbird unterstützt eine Autokonfiguration. Für die großen Anbieter greift es dazu auf eine eigene Datenbank zu, als kleiner Anbieter kann man die notwendigen Informationen nach folgender Anleitung erstellen: https://developer.mozilla.org/de/docs/Mozilla/Thunderbird/Autokonfiguration.
Der Anleitung folgend habe ich mir im Webserververzeichnis httpdocs meiner Domain eine Datei .well-known/autoconfig/mail/config-v1.1.xml angelegt mit folgendem Inhalt:
Thunderbird sucht beim Anlegen einer neuen Mailadresse nach dieser Datei in der zugehörigen Domain. Wenn die Datei gefunden wird, dann konfiguriert sich das Mailprogramm ganz automatisch nach diesen Einstellungen.
Für den Fall, dass die automatische Konfiguration nicht möglich ist findet sich eine Konfigurationsbeschreibung unter http://www.debacher.de/ublog/2016/10/thunderbird-konfigurieren/.
In der Logdatei /var/log/mail kann man erkennen, wenn die Mails verschlüsselt abgerufen werden:
2016-10-22T16:21:45.874680+02:00 h2366010 dovecot: imap-login: Login: user=<xxx@debacher.de>, method=PLAIN, rip=85.176.x.y, lip=81.169.xx.yy, mpid=30944, TLS, session=<vv7q4HQ/xABVsIAH>
Hier taucht dann TLS in der Zeile auf. Entsprechend für das Abliefern der Mails:
2016-10-22T18:17:17.327190+02:00 h2366010 postfix/smtpd[32315]: Anonymous TLS connection established from x5b087001.dyn.telefonica.de[85.176.x.y]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Mit letsencrypt soll es für alle Webseiten einfach und erschwinglich werden eine Verschlüsselung zu ermöglichen.
Eine schöne Beschreibung findet sich unter https://lukasthiel.de/wiki/SSL-Zertifikate_mit_Let%27s_Encrypt
Die Installation erfolgt mittels:
cd /root git clone https://github.com/letsencrypt/letsencrypt
Das Script lädt notwendige Pakete und Aktualisierungen beim ersten Aufruf nach, hier z.B. über den Aufruf der Hilfefunktion:
/root/letsencrypt/letsencrypt-auto -h
Dabei werden einige Pakete über die Paketverwaltung der Distribution ergänzt und zusätzlich einiger Python-Code nach /root/.local/share/letsencrypt/ gebracht.
Bootstrapping dependencies for openSUSE-based OSes... The following 8 NEW packages are going to be installed: dialog libdialog11 libffi48-devel python-devel python-pip python-setuptools python-virtualenv python-xml The following package is suggested, but will not be installed: terminfo 8 neue Pakete zu installieren. Gesamtgröße des Downloads: 5,8 MiB. Nach der Operation werden zusätzlich 26,8 MiB belegt. Fortfahren? [j/n/? zeigt alle Optionen] (j): j Creating virtual environment... Installing Python packages... ...
Am Ende wird der Hilfe-Text ausgegeben.
Das Tool legt an einer Reihe von Stellen Dateien ab:
Der Aufruf von
/root/letsencrypt/letsencrypt-auto --rsa-key-size 4096 certonly
erzeugt dann im Prinzip das Zertifikat. Bei mit (OpenSUSE) wollte das nicht funktionieren, weil das Tool das Verzeichnis /etc/apache2/sites-enabled vermisste. Nachdem ich das Verzeichnis angelegt hatte (das Verzeichnis selber kann leer bleiben) ließ sich das Zertifikat erzeugen.
Es startet ein fensterbasiertes Tool an der Konsole. Im ersten Schritt gibt man an, wie sich der Webserver gegenüber dem Zertifikats-Aussteller authentifizieren soll. Die einfachste Version besteht darin das Script eine Datei im Webroot der Seite plazieren zu lassen. Dazu muss das Script die Pfade kennen:
Wenn die Datei über den Webserver erreichbar war, dann kommt die Erfolgsmeldung:
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/elearn-server.de/fullchain.pem. Your cert will expire on 2016-09-14. To obtain a new or tweaked version of this certificate in the future, simply run letsencrypt-auto again. To non-interactively renew *all* of your certificates, run "letsencrypt-auto renew" - If you lose your account credentials, you can recover through e-mails sent to <admin>@<domain>. - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
Man kann sich den Ablauf auch etwas einfacher machen, vor allem, wenn man mehrere Domains betreut, indem man statt der Dialog orientierten Variante eine Parameter orientierte Variante benutzt (alles in einer Zeile):
/root/letsencrypt/letsencrypt-auto --rsa-key-size 4096 certonly --webroot -w /srv/www/vhosts/elearn-server.de/httpdocs/ -d elearn-server.de -d www.elearn-server.de
Für umfangreiche Nutzung kann es noch geschickter sein sich für jede Domain eine Konfigurationsdatei, z.B. letsencrypt.ini, anzulegen
# Wir nutzen 4096 bit RSA key statt 2048 rsa-key-size = 4096 # allgemeine Angaben email = <admin>@<domain> authenticator = webroot # Domains fuer die wir Zertifikate beantragen, die erste in # der liste legt den Hauptnamen fest. Alle Domains müssen beim # Aufruf erreichbar sein domains = elearn-server.de, www.elearn-server.de # Dies ist das Verzeichnis zur Domain, wo letsencrypt seinen Hash in # /.well-known/acme-challenge schreiben will. Der Pfad muss auf / enden webroot-path = /srv/www/vhosts/elearn-server.de/httpdocs/
Aufgerufen wird letsencrypt-auto dann mittels (alles in einer Zeile):
/root/letsencrypt/letsencrypt-auto certonly --config /srv/www/vhosts/elearn-server.de/letsencrypt.ini
Aufpassen muss man aber unbedingt mit Subdomains. Letsencrypt lässt nämlich nur etwa 5 Aufrufe pro Domain und Woche zu. In dem Beispiel sind dann schon zwei Aufrufe verbraucht. Mehr als 5 Subdomains im gleichen Zertifikat sind wohl nicht möglich.
Im Laufe der Erzeugung legt letsencrypt in der Wurzel des angegebenen Servers ein Verzeichnis .well-known an. Das Zertifikat selber wird unter /etc/letsencrypt/live/<domain>/ abgelegt und besteht aus den vier Dateien
dies sind Links auf die Dateien
Diese Verlinkung soll vermutlich die Aktualisierung der Zertifikate vereinfachen.
Jetzt muss nur noch der Apache-Webserver von den neuen Möglichkeiten wissen. Die notwendigen Einstellungen für den Host sind in der Datei /etc/letsencrypt/options-ssl-apache.conf zu finden:
# Baseline setting to Include for SSL sites
SSLEngine on
# Intermediate configuration, tweak to your needs
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLHonorCipherOrder on
SSLCompression off
SSLOptions +StrictRequire
# Add vhost name to log entries:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" vhost_combined
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
#CustomLog /var/log/apache2/access.log vhost_combined
#LogLevel warn
#ErrorLog /var/log/apache2/error.log
# Always ensure Cookies have "Secure" set (JAH 2012/1)
#Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"
Testen kann man das Zertifikat dann unter https://www.ssllabs.com/ssltest/
Möchte man sein Zertifikat um weitere Subdomains erweitern, so ist das kein Problem. Hat man z.b. nur für <domain> und www.<domain> ein Zertifikat erstellt und möchte jetzt auch blog.<domain> mit aufnehmen, so erweitert man einfach die Liste der Domains entsprechend und löst die Erstellung des Zertifikats erneut aus. Es erscheint jetzt ein Dialog, der nachfragt, ob man das Zertifikat erweitern möchte. Hier klickt man auf Expand und wenn die Subdomain erreichbar ist, dann wir das Zertifikat neu erzeugt.
Laut https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769 gilt hierfür nicht das Limit von 5 pro Woche.
Unter /etc/letsencrypt/csr/ findet man die Key-signing-requests, ein Hinweis darauf, dass das Schlüsselpaar auf dem eigenen Server erzeugt wurde und der private Schlüssel auch letsencrypt nicht bekannt ist.
Bei owncloud gibt es einen Abschnitt in der .htacess, der die Überprüfung durch letsencrypt verhindert:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
RewriteRule ^\.well-known/carddav /remote.php/carddav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/caldav/ [R=301,L]
RewriteRule ^apps/calendar/caldav\.php remote.php/caldav/ [QSA,L]
RewriteRule ^apps/contacts/carddav\.php remote.php/carddav/ [QSA,L]
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>
Das Einfügen der Zeile
RewriteRule ^\.well-known/acme-challenge - [L]
löst das Problem. Mal sehen, ob es Seiteneffekte gibt.
Mit
/root/letsencrypt/certbot-auto certificates
kann man abfragen, wie die Zertifikate auf dem Server genau heißen und die zugehörigen Dateien dann mittels
/root/letsencrypt/certbot-auto delete --cert-name <gefundener Name>
vom eigenen Server entfernen.
Mit folgendem Kommando kann man abfragen, welche Domains im Zertifikat eingetragen sind:
openssl x509 -in /etc/letsencrypt/live/<domain-bezeichnung>/cert.pem -text -noout | grep DNS
Mit den Schritten ist das Zertifikat selber aber nicht gelöscht, das wäre dann erst nach einigen Tagen automatisch der Fall. Noch nicht getestet habe ich die Schritte:
certbot revoke --cert-path /PATH/TO/cert.pem --key-path /PATH/TO/key.pem
das müsste natürlich vor dem Löschen der lokalen Dateien erfolgen.
Will man eine Domain aus einem Zertifikat für mehrere Domains entfernen, so soll das mit folgendem Parameter klappen:
$ certbot renew --allow-subset-of-names
Das aktuelle Heft (1/2014) der Zeitschrift c’t hat sich mal wieder gelohnt. Auf Seite 59 findet sich ein kleine Beitrag über die Software OCRMyPDF. Damit ist man in der Lage einfache PDF-Dokumente mit einer Textebene per OCR zu versehen.
Die Software selber gibt es unter https://github.com/fritz-hh/OCRmyPDF zum Download. Ich musste noch das Pakt tesseract nachinstallieren, welches die eigentlich OCR-Arbeit übernimmt.
Das Tool, eine Sammlung von Scripten für sowieso vorhandene Programmpakete, muss nicht weiter installiert werden. Direkt nach dem Entpacken ist es per
sh OCRmyPDF.sh -l deu quelle.pdf ziel.pdf
ausführbar.
Beim Aktualisieren von moneyplex 09 auf moneyplex 12 unter Ubuntu 12.04 hatte ich das Problem, dass die neue Software-Version nicht auf das Internet zugreifen konnte. Damit waren weder Software-Updates noch Konto-Aktualisierungen möglich.
Nach einem hilfreichen Hinweis vom Matrica-Support habe ich dann das Problem in der resolf.conf gefunden.
Mein Arbeitsplatzrechner hat eine feste IP-Adresse (er vergibt auch die IP-Adressen im Netz). Außerdem läuft auf dem Rechner auch der Nameserver für das Netz. Bisher hat das allen Programmen gelangt. Die 12 moneyplex fragt nun wohl irgendwo die resolv.conf ab, was die Version 09 anscheinend nicht machte. Das erklärt auch, warum moneyplex 12 auf anderen Rechnern im Netz problemlos lief, nur auf meinem Hauptrechner nicht. Die anderen Rechner haben ihre Daten per DHCP bezogen und dabei wird automatisch die resolv.conf aktualisiert.
Ich habe auf meinem Hauptrechner jetzt also die Datei /etc/network/interfaces etwas erweitert:
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.1.1 netmask 255.255.255.0 gateway 192.168.1.254 dns-domain debacher.local dns-search debacher.local dns-nameservers 192.168.1.1 192.168.1.254
Die ersten 7 Zeilen waren schon vorhanden, ich habe jetzt die drei letzten Zeilen ergänzt. Nach einem /etc/networking/restart wurden die Informationen dann in die /etc/resolv.conf bzw. genaugenommen /run/resolvconf/resolv.conf übernommen.
Schön, dass es Firmen gibt, die sich darum bemühen ihren Kunden bei Problemen zu helfen.
Zum Ausfüllen von PDF-Formularen benutze ich schon seit Jahren die Software CABAReT Stage von http://www.cabaret-solutions.com/ und möchte die auch nicht mehr missen. Die Software ist zwar nicht frei, aber für Privatanwender kostenlos.
Nach der Neuinstallation meines Rechner mit Ubuntu 12.04 wollte die Installation von CABAReT Stage 4.2.1 in meinem Homeverzeichnis nicht mehr funktionieren. Es erschien zwar die Oberfläche, aber nicht die geöffneten Dokumente. Auch die neuere Version 5.2.1 lief nicht, hier erscheint die Oberfläche erst gar nicht.
Die Hoempage liefert nur den Hinweis, die Software würde nur mit dem Original Java von SUN/Oracle laufen. Die Installation brachte aber keine Veränderung. Den Logdateien der Software, bzw. den Startmeldungen an der Konsole war aber zu entnehmen, dass Freetype und Ghostscipt irgendwie benötigt werden. Die Software war zwar installiert, nicht aber die Entwicklerdateien. Nun läuft jedenfalls die 4.2.1-Version einwandfrei.
Seit einiger Zeit bin ich dabei mir Webfonts zu experimentieren. Damit kann man endlich die Gestaltung von Webseiten unabhängig vom Betriebssystem des Betrachters halten. Wie so oft ist auch hier Google dabei kostenlos Unterstützung zu bieten mit den Google Web-Fonts.
Die Fonts kann man relativ leicht aktivieren, so dass sie dann vom Google-Server geladen werden. Man kann sie aber auch herunterladen und auf einem eigenen Server ablegen, dann muss man etwas mehr Aufwand treiben. Hier im Blog habe ich mir das recht einfach gemacht und das Plugin WP Google Fonts installiert, über das ich die Fonts aus einer Dropdown-Liste auswählen kann.
Weitere Informationen finden sich auf einer Reihe von interessanten Webseiten:
es gibt noch viel mehr Fonts, als die von Google:
Seit vielen Jahren benutze ich Horde/Imp und Squirrelmail als Webmailer. In der letzten Zeit nutze ich aber lieber die Programmpakete:
Bei Roundcube handelt es sich um ein freies Programm, welches sich im wesentlichen auf die Mail-Funktionalität beschränkt, aber eigentlich alles bietet, was man so braucht. Eine Anleitung finde man auf den Anbieter-Seiten in verschiedenen Sprachen, u.a. auf Deutsch. Ein sehr umfangreiches Benutzerhandbuch ist auch auf den Seiten der Fachhochschule Darmstadt zu finden.
Group-Office ist ein sehr viel umfangreicheres Tool, mit Kalender und weiteren Groupware-Funktionen. Daher ist der Administrationsaufwand auch etwas höher. Die Installation ist aber sehr einfach und und nicht besonders anspruchsvoll. Es gibt eine kostenfreie Community-Version und eine kostenpflichtige Professional-Version. Die englischsprachige Dokumentation ist im Group-Office Wiki zu finden. Eine deutsche Anleitung, für eine ältere Version, findet sich im Web.
Das Grafikformat SVG fängt an sich im Internet mehr zu verbreiten. Es gibt nur noch einen winzig weichen Browser, der mit dem Format nicht umgehen kann.
Die Quelle für freie SVG-Grafiken im Netz ist Openclipart.org. Leider ist die Seite seit einiger Zeit nicht mehr erreichbar, lediglich der Downloadbereich unter http://download.openclipart.org/downloads/ ist noch zugänglich.Leider sind die Archive nicht thematisch sortiert, sondern nach Urhebern. Ich habe daher nach andere Archiven mit freien SVG-Grafiken gesucht und die folgenden Seiten gefunden