Distributionen: Fedora Core, CentOS
Zuerst lädt man sich das Apache-SRPM (httpd*.src.rpm) von einem Mirror herunter (für Fedora z.B. von http://wftp.tu-chemnitz.de/pub/linux/fedora-core/updates/4/SRPMS/) und installiert das SRPM (rpm -i).
Anschließend sich geht man in das SPECS-Verzeichnis und editiert die httpd.spec. Um Zeile 260 herum findet sich der configure-Aufruf, bei dem auch die Parameter für suexec festgelegt werden. So kann man z.B. die minimale, für suexec erlaubte ID anpassen:
--with-suexec-uidmin=93 --with-suexec-gidmin=93 \
Mittels rpmbuild -ba SPECS/httpd.spec wird dann das neue RPM gebaut.
Ggf. müssen noch einige devel-Pakete installiert werden.
Achtung: Unter Fedora Core 4 gibt es den Bug, dass einige devel-Pakete noch mit dem alten Redhat-Schlüssel signiert sind, wodurch das Installieren mit yum scheitert. Leider ist Redhat der Ansicht, dass dies kein Bug ist und daher auch erst in Fedora Core 5 behoben werden muss (Bug 160988 - yum default config on FC4 fails because packages signed with RH key). Daher ist derzeit der sauberste Weg, ggf. noch den alten Redhat-Schlüssel zu installieren:
rpm--import /etc/pki/rpm-gpg/RPM-GPG-KEY
Anschließend findet sich unter RPMS/i386/ das neue httpd-RPM, das auch das neue suexec enthält. Entweder man entpackt das RPM manuell und extrahiert nur /usr/sbin/suexec, welches man anschließend nach /usr/sbin kopiert und mit den richtigen Rechten versieht (bei Fedora Core 4: {{chown root.apache /usr/sbin/suexec; chmod 4510 /usr/sbin/suexec}}). Oder man installiert das eigene RPM direkt. In diesem Fall muss aber darauf geachtet werden, eine höhere Release-Nummer im Spec-File einzusetzen, damit das RPM auch Vorrang vor RPMs der Distribution hat.
Im Laufe der Zeit wird es vermutlich immer mal wieder Apache-Updates geben. Hier muss jedes Mal suexec neu kompiliert werden, da die Distributionspakete es entweder überschreiben (manuelle Installation) oder die neuen Pakete ggf. nicht installiert werden (höhere Release-Nummer).
Ein Klick der mittleren Maustaste schließt unter Windows ein Tab, unter Linux jedoch nicht. Die entsprechende Konfiguration ist middlemouse.contentLoadURL, die über about:config auf false gestellt werden muss.
Problem: Ein Benutzer kann in Indesign 3.0.1 (Creative Suite 1) nur "Geräteunabhängig" als PPD auswählen, wenn er im Drucken-Dialog Postscript auswählt. Unter dem Benutzer, der die Creative Suite installiert hat, trat das Problem nicht auf, er konnte aus mehreren Dutzend PPDs wählen. Weitere lokale Benutzer (auch mit Admin-Rechten) konnten diese PPDs aber nicht sehen. Das Problem trat nicht konsistent bei allen Maschinen auf, hier handelte es sich um einen PowerMac G5 Dual 1,8 GHz.
Lösung: Anscheinend kommt Indesign mit unterschiedlichen Sprachen durcheinander. Wenn man den Ordner /Library/printers/PPDs/Contents/Resources/de.lproj durch en.lproj im gleichen Verzeichnis ersetzt und Indesign neu startet, funktioniert alles wieder. Unter Umständen reicht es sogar, die Datei ADPDF6.PPD zu kopieren.
Damit X.509-Zertifikate (SSL, TLS) gültig sind, müssen sie von einer CA (Certificate Authority) zertifiziert ("unterzeichnet") werden. Es gibt natürlich viele kommerzielle CAs (z.B. Verisign), die aber recht viel kosten. Für den Hausgebrauch kann man sich daher eigene Zertifikate erstellen.
Hinweis: Wer kostenlose SSL-Zertifikate für öffentliche Rechner brauchte, sollte bitte KEINE eigene CA aufsetzen, sondern CAcert verwenden! Diese Anleitung existiert nur, damit Rechner in einem internen Netz mit ungültigen Domainnamen (*.example, *.invalid) auch mit SSL-Zertifikaten versorgt werden können, da CAcert dafür keine Zertifikate erteilt!
Warnung: Diese Anleitung dient nur zu Testzwecken! Insbesondere wird nicht auf die Absicherung der hochgeheimen CA-Daten eingegangen.
Folgende Verzeichnisstruktur muss erzeugt werden:
/home/myuser/myCA
|
|- crl
|- newcerts
|- private
Die zentrale Datenbank index.txt muss erst erzeugt werden:
touch index.txt
Außerdem muss noch die Datenbank mit den vergebenen Seriennummern initialisiert werden.
echo "01" > serial
Die Datei openssl.cnf in das Verzeichnis kopieren (bei Fedora in /etc/pki/tls/openssl.cnf zu finden, vor FC5 unter /usr/share/ssl/openssl.cnf) und nach eigenem Gusto anpassen.
(...) HOME = /home/myuser/myCA RANDFILE = $HOME/.rnd (...) [ CA_default ] dir = $HOME # Where everything is kept (...)
Dabei kann man auch gleich die Gültigkeitsdauer eines Zertifikats anpassen, z.B. auf fünf Jahre (Standard ist ein Jahr):
default_days = 1825 # how long to certify for
Zum Abschluss muss noch der supergeheime private key der eigenen CA erzeugt werden:
openssl req -config openssl.cnf -new -x509 -extensions v3_ca \
-keyout private/cakey.pem -out cacert.pem -days 7300
Siehe SSL/X.509-Zertifikate generieren
openssl ca -config openssl.cnf -policy policy_anything -out domain.crt -infiles domain.csr
In domain.crt findet sich anschließend das signierte Zertifikat.
Die CA-Implementierung in openssl sollte eigentlich nur als Beispiel für eine CA-Implementierung dienen.
$ man 1 ca
(...)
WARNINGS
(...)
The ca utility was originally meant as an example of how to do things
in a CA. It was not supposed to be used as a full blown CA itself:
nevertheless some people are using it for this purpose.
(...)
Daher kann es Probleme im realen Betrieb einer CA mit Hilfe der openssl-Implementierung geben. Um diese Klippen zu umschiffen, eignen sich kommerzielle PKI-Produkte oder Open-Source-Lösungen wie OpenCA oder dessen sehr aktiver Fork OpenXPKI. Oftmals ist auch CAcert sehr geeignet, dort gibt es z.B. auch einen speziellen Modus für Unternehmen, die ihre Zertifikate dort über mehrere Benutzerzugänge verwalten können und so unabhängig von einzelnen Administratoren sind.
Bestimmten JPG-Bilder können nicht mit Firefox (oder Mozilla) geöffnet werden. Es erscheint dann nur die Meldung: "Die Grafik ... kann nicht angezeigt werden, weil sie Fehler enthält".
Natürlich besteht die Möglichkeit, dass die Datei tatsächlich kaputt ist. Allerdings kommt diese Meldung auch bei CMYK-JPGs, also Bildern, deren Farbkodierung nicht über das RGB-Schema passiert. Insbesondere Adobe Photoshop speichert JPGs häufig als CMYK.
Firefox kann solche Bilder derzeit nicht anzeigen. Unter Bug 44781 finden sich mehr Details.
Bacula kann auch benutzt werden, um einen MS Exchange Server zu sichern. Allerdings spielt auch ntbackup eine Rolle, so dass die klassischen Nachteile dieses Schmalspur-Backupprogramms zu tragen kommen. Damit ein Exchange-Server wirklich ausschließlich mit Bacula gesichert werden kann, müsste Bacula eine Plugin-API anbieten. Ein erster Schritt in diese Richtung könnte schon in der kommenden Version 1.37 getan werden.
Solange ist aber noch eine andere Vorgehensweise erfoderlich...
Achtung: Die vorliegenden Dateien funktionieren nur mit Windows 2000 und Exchange 2000. Im Windows Server 2003 hat Microsoft wohl die Kommandozeilen-Parameter von ntbackup geändert, so dass das angepasst werden müsste. Entsprechende Hinweise gerne an mich.
TODO
Aus der bacula-dir.conf:
Job {
Name = "Exchange"
...
FileSet = "Exchange_files"
Client Run Before Job = "C:\\bacula\\exchange\\exchange.bat %l"
Client Run After Job = "del /F /Q C:\\bacula\\exchange\\files\\*"
}
FileSet {
Name = "Exchange_files"
Include {
Options {
compression=GZIP
signature=MD5
portable=yes
}
File = "C:/bacula/exchange/files"
}
}
Vermutlich könnte man sogar die GZIP-Kompression weglassen, da ich vermute, dass ntbackup bereits komprimiert.
Den Windows-Filedaemon konfiguriert wie jeden anderen Filedaemon auch, daher gebe ich diese Konfiguration hier nicht an.
Ich habe folgende Verzeichnisse angelegt:
C:\
|
|- bacula\
|
|- exchange\
|
|- exchange.bat
|- exchange.py
|- files\
Die exchange.bat hat eigentlich nur den Zweck, anschließend das eigentliche Python-Skript aufzurufen, ohne dass man im Bacula director den Windows-Pfad des Python-Interpreters kennen muss... Die eigentliche Arbeit macht exchange.py, womit auf dem Exchange-Server natürlich Python installiert sein muss. Alternativ kann man auch die bat-Datei etwas erweitern (bzw. die auskommentierten Befehle wieder aktivieren), aber diese verkrüppelte Windows-Skriptsprache der CMD.EXE ist nun wirklich nicht schön.
Das Skript kann Exchange komplett oder differentiell sichern, alle anderen Bacula-Level werden auf differentiell abgebildet.
Das Alptraumgespann überhaupt.
Software: Outlook 98
Problem: Beim Anklicken eines E-Mail-Links auf einer Webseite erscheint folgende Outlook-Meldung: Die Datei für den temporären Formularspeicher "C:\WINNT\FORMS\FRMCACHE.DAT" ist ungültig. Wenden Sie sich an Ihren Administrator. Entfernt man die FRMCACHE.DAT, kommt bei einem Mail-Versuch nur die Meldung Element kann nicht erstellt werden., selbst wenn die Berechtigungen sehr lax gesetzt sind.
Lösung: Benutzer kurz zum Administrator auf der Maschine machen (neu anmelden), Outlook neu starten, Maillink anklicken, alles geht. Benutzer dann Administratorrechte entziehen. Scheinbar konnte Outlook dadurch irgendwelche Dateien aktualisieren, so dass wieder alles geht.
Problem: Ein Benutzer hat unter MacOS X 10.3 einen Alias auf dem Desktop, der dazu führen soll, dass ein SMB-Share eingehängt wird. Allerdings muss er beim Doppelklick auf den Alias immer erst sein Passwort eingeben (dieses wurde bereits früher zum Schlüsselbund hinzugefügt) und auch den Benutzernamen korrigieren.
Hintergrund: Der Alias kam ursprünglich von einem anderen Benutzer und wurde dann über "für alle Benutzer" kopiert. Dabei blieben irgendwelche Meta-Informationen erhalten.
Lösung: Man muss den Server einhängen, den Alias wegwerfen und einen neuen Alias für den Server erstellen (Rechtsklick auf das Icon des eingehängten Servers, Alias erstellen).
Problem: Jedes Mal, wenn eine Datei über SMB auf eine Windows-Freigabe kopiert wird, wird auch eine gleichnamige Datei angelegt, die allerdings mit einem Punkt beginnt und meist auch sehr klein ist.
Hintergrund: Mac-Programme arbeiten traditionell mit mehreren Resource Forks ("Streams" unter Windows), d.h. etwas sieht für den Benutzer wie eine Datei aus, das Programm kann diese aber wie mehrere ansprechen und so z.B. Schriften und Bilder zu einem Bundle zusammenschnüren. Leider hat Apple diese Resource Forks für "unwissende" Programme nicht transparent gestaltet, so dass auf anderen Dateisystemen als dem Mac-eigenen (HFS) mehrere Dateien nötig sind. Der Metadaten-Fork ist dabei die Punkt-Datei.
Lösung: Keine bekannte. Mit OS X ist die reale Nutzung der Resource Forks stark zurückgegangen, so dass meist nur wenige und relativ unwichtige Informationen im Resource Fork gespeichert werden (Ersteller, Dateityp). Bei vielen Programmen ist es problemlos möglich, diese Geisterdateien wegzuschmeißen. Allerdings könnte man damit auch eine Katastrophe verursachen, wenn z.B. die eingebetteten Schriften weg sind!
Programme, die keine Resource Forks brauchen:
Problem: Um schnell auf eine Windows-Freigabe zugreifen zu können, soll ein Shortcut auf dem Desktop angelegt werden.
Lösung: Zunächst wird die Freigabe eingehängt (am sichersten über "Gehe zu" - "Mit Server verbinden..." und dann smb://IP-Adresse). Anschließend Rechtsklick und "Alias erzeugen" auswählen. Der Alias kann dann beliebig benannt werden.
Für einige Anwendungsgebiete kann es sehr nützlich sein, sich mit einer grafischen Oberfläche auf einem Linux-System einzuloggen. Das X-Protokoll bietet dafür sogar direkten Support, allerdings unterstützt z.B. Windows kein X. VNC wiederum läuft mit minimaler Installation wirklich plattformunabhängig. Hier daher eine Anleitung, um sich grafisch an einem System mit dem GDM (Gnome Display Manager) anzumelden.
Ein Benutzer kann mittels einem beliebigen VNC-Client ein anderes Linux-System verwenden. Die Anmeldung geschieht wie im lokalen Fall per GDM, es ist also ein Linux-Benutzer erforderlich. Verschlüsselung der Verbindung geschieht nicht.
In der /etc/X11/gdm/gdm.conf muss
[xdmcp] Enable=true
gesetzt werden. Dies kann auch grafisch über Systemeinstellungen - Anmeldebildschirm geschen.
Das XDMCP-Protokoll (X Display Manager Control Protocol) ist das eigentliche netzwerktransparente X-Protokoll, so dass man sich eben auch an anderen Rechnern per X einloggen kann. Allerdings braucht man in der Firewall des Zielrechners nicht die X-Ports freischalten, da der VNC-Server ja auf dem Zielrechner läuft.
Damit der xinetd nicht meckert, muss folgende Zeile in die /etc/services aufgenommen werden.
vnc 5900/tcp # VNC server
Unter Fedora Core 4 wird der xinetd standardmäßig nicht mit installiert und muss daher (z.B. per yum) noch hinzugefügt werden.
Damit der VNC-Server auch gestartet wird, bietet sich eine Konfiguration über den xinetd an. Dazu die Datei /etc/xinetd.d/vncserver mit folgendem Inhalt anlegen:
service vnc
{
protocol = tcp
socket_type = stream
wait = no
user = nobody
server = /usr/bin/Xvnc
server_args = -inetd -query localhost -once -geometry 1024x768 -depth 16 SecurityTypes=None
# only_from = XXX.XXX.XXX.XXX 127.0.0.1
port = 5900
}
Der geometry-Parameter kann natürlich beliebig geändert werden. Durch securitytypes=none wird keinerlei VNC-Authentifizierung durchgeführt, da GDM dies macht.
Damit auch alle Änderungen wirksam werden, müssen xinetd und GDM neu gestartet werden. Ein init 3, init 5 sollte das eigentlich tun, ev. hilft auch ein Neustart. xinetd-Fehler stehen im allgemeinen Syslog. Der Zielrechner muss auch standardmäßig in den grafischen Login booten (Eintrag id:5:initdefault: in /etc/inittab).
Sollte eine Firewall (besser: ein Paketfilter) aktiviert sein, muss beim Zielrechner VNC erlaubt sein, was ich mitttels system-config-securitylevel mache ("Andere Ports: 5900:tcp") und sonst halt händisch erledigt werden muss.
Standardmäßig haben Benutzer unter Linux keinen Zugriff auf diverse Geräte (z.B. USB-Scanner, Brenner etc.). Unter Fedora/CentOS gibt es aber das Modul pam_console, das nach während der Passwortüberprüfung aufgerufen wird und die Rechte so setzt, dass ein physisch anwesender Benutzer die lokalen Geräte benutzen kann. Dabei wird zwischen lokalen Anmeldungen (Konsole, lokaler GDM) und entfernten Anmeldungen (z.B. SSH) unterschieden.
Glücklicherweise kann man pam_console so konfigurieren, dass auch Anmeldungen über VNC als "lokal" angesehen werden. Dies hat zur Folge, dass ein Benutzer z.B. Sounds abspielen, CDs brennen oder auch Bilder von einer USB-Digitalkamera herunterladen kann.
/etc/security/console.handlers
console consoledevs tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] workstation:[0-9]
/etc/security/console.perms
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] workstation:[0-9]
workstation ist dabei der Hostname des Rechners, auf dem der VNC-Server läuft. Außerdem muss noch dann noch die Datei "hostname:displaynummer" (z.B. "workstation:1") im Verzeichnis /dev mit dem Eigentümer root existieren.
Bei Fedora Core gibt es noch das Problem, dass das /dev-Verzeichnis durch udev bei jedem Neustart neu erzeugt wird, so dass auch die entspr. Dateien neu angelegt werden müssen. Bevor pam_console aber das /dev-Verzeichnis konsultiert, prüft es erst das aktuelle Arbeitsverzeichnis, doch ich weiß nicht genau, welches das ist.
Für die Fehlersuche ist es nützlich, pam_console in den debug-Modus zu schalten. Dies geschieht für VNC/GDM-Logins in der /etc/pam.d/gdm und für SSH-Logins in der /etc/pam.d/login mit folgendem Eintrag
session optional pam_console.so debug
Ob ein Benutzer durch pam_console erweiterte Rechte bekommen hat, sieht man daran, ob die Dateien /var/run/console/console.lock (Inhalt ist der Benutzername) und /var/run/console/<benutzername> existieren.
Allerdings sollte bei VNC-Logins beachtet werden, dass nur der zuerst angemeldete erste Benutzer die erweiterten Rechte bekommt (und nach dessen Abmeldung derjenige, der sich als nächstes anmeldet).
Natürlich ist diese Anleitung nicht alleine auf meinem Mist gewachsen - im Internet gibt es viele Seiten, die ähnliche Konfigurationen beschreiben oder Hinweise in eine Richtung geben. Nachdem aber bei mir vieles nicht richtig funktioniert hat, habe ich hier meine persönliche Anleitung zusammengestellt.