--- old/custom.conf	2011-07-07 09:35:01.462829111 +0200
+++ new/custom.conf	2011-07-07 09:30:27.146258540 +0200
@@ -7,6 +7,7 @@
 [xdmcp]
 
 [greeter]
+IncludeAll=false
 
 [chooser]

Damit werden nicht oder zB nur per scp genutzte Benutzernamen ausgeblendet.

Gernot Walzl wrote a “nasty workaround” (quoting himself) in the form of the following script:

#!/bin/sh
 
# nvidia_dpms_fix.sh
# 2011-06-12
# by Gernot WALZL
 
# nasty workaround for nvidia drivers to resume from dpms off/suspend
 
export DISPLAY=:0
 
getXauthority () {
  export XAUTHORITY=$(ps -C X -f | grep "$DISPLAY" \
    | sed -n 's/.* -auth \([^ ]*\).*/\1/p')
}
 
handle_line () {
  if echo "$1" | grep -e "(EE) NVIDIA.* DisplayPort link training failed" \
      > /dev/null; then
    getXauthority
    xset dpms force on
  fi
}
 
tail --follow=name /var/log/Xorg.0.log --retry --lines=1 2> /dev/null \
  | while read line; do
    handle_line "$line"
  done

To actually make this do its job, I copied it into /usr/local/bin, made it executable and created an autostart entry for GNOME 3 by saving the following lines under ~/.config/autostart/nvidia_dpms_fix.sh.desktop

[Desktop Entry]
Type=Application
Exec=/usr/local/bin/nvidia_dpms_fix.sh
Hidden=false
X-GNOME-Autostart-enabled=true
Name=NVidia DPMS fix
Comment=Wakes up the display properly

I believe the problem that is being worked around is indicated by a line in the Xorg.0.log:

(WW) NVIDIA(GPU-0): AUO (DFP-3): Failed to set DisplayPort power state

Although I could only test this on my machine (HP EliteBook 8440p), with some luck this works for all cases where a similar log message is found.

Once a writing process is identified, lsof can tell you which files are actually written. Depending on what you want to achieve, you can then continue to relocate that file to a different disk (e.g. if you have two disks and want one of them to sleep most of the time) or to memory (using tmpfs). The latter obviously means that the written data will be lost at the next reboot, but sometimes this is perfectly fine e.g. for the files inside /tmp. Therefore, it is generally a good idea to move that directory into volatile memory following the instructions on the openSUSE Wiki.

All good and well if you actually manage to relocate or move a file. Often file locations are a matter of configuration and otherwise you can help yourself with dynamic links. But there was one very special file on my openSUSE 11.4 installation that withstood all my assaults for quiet some time. I’m speaking of a beast called .xsession-errors residing in your $HOME directory. Created by KDM, one would expect to be able to configure the location of that file. Indeed, there is a configuration option called ClientLogFile specifically for that purpose. Unfortunately this is only the first and easier of two necessary steps:

1. As root open your /usr/share/kde4/config/kdm/kdmrc, go to a section labelled [X-:0-Core] (there may be multiple of those, but don’t worry and just pick the last one) and add the following line:

   ClientLogFile=../../tmp/xsession-errors-%u

   This will move the file into the /tmp directory. Mind the path relative to $HOME.

2. Now the hidden piece: again as root open your /etc/X11/xdm/Xsession and make the following changes (I deliberately use the patch syntax here i.e. remove lines with a minus sign and add those with a plus sign):

   --- Xsession.old        2011-05-01 19:46:40.000000000 +0200
   +++ Xsession    2011-05-02 22:18:39.000000000 +0200
   @@ -123,8 +123,8 @@
        # GDM seems to handle this its self
        test -z "$GDMSESSION" || break
    
   -    # Once if KDM does handle this its self
   -    #test -z "$KDMSESSION" || break
   +    # KDM handles this itself
   +    test -z "$KDE_SESSION_VERSION" || break
    
        # Avoid bad symbolic links
        case "$errfile" in

Done; logout, restart KDM, re-login and check if the xsession-errors* exists at the new location. If so, remove your old one and cheer to a long living SSD. Only, of course, if the new location is not on your SSD, but e.g. in memory. It doesn’t hurt to re-check with pidstat.

1. Prepare a partition on the USB stick and/or make sure there is enough space on it (it must be slightly larger than the ISO image).
2. Make sure it is flagged bootable. ( fdisk -l /dev/sdX is your friend)
3. Remember the name of the USB partition you’re going to use or if unlabelled, label it.
4. Loop-mount the ISO image using something like mount -o loop /path/to/iso /mnt/loop
5. Copy the content of the ISO over to the USB
6. Install GRUB on the USB by issuing grub-install --no-floppy --root-directory=/mnt/usb /dev/sdX
7. Create a /mnt/usb/boot/grub/grub.cfg with the following content

   menuentry "Fedora Live" {
    linux /isolinux/vmlinuz0 root=live:LABEL=XYZ rootfstype=auto ro liveimg quiet  rhgb rd_NO_LUKS rd_NO_MD rd_NO_DM
    initrd /isolinux/initrd0.img
   }
    
   menuentry "Fedora Live (Basic Video)" {
    linux /isolinux/vmlinuz0 root=live:LABEL=XYZ rootfstype=auto ro liveimg quiet  rhgb rd_NO_LUKS rd_NO_MD rd_NO_DM xdriver=vesa nomodeset
    initrd /isolinux/initrd0.img
   }

   where XYZ must be replaced by the actual partition name of your USB partition.

8. Unmount and boot

echo 1 > /sys/devices/platform/hp-wmi/als

Also don’t forget to check if the ALS is enabled in the BIOS if this doesn’t work. It seems to be enabled by default though.

As quick search for the topic brought me to an article in the Ubuntu Forums which solved 90% of the problem. Installing Mozplugger

yum install mozplugger

and raising the priority of Evince as its PDF handler made most of the PDFs open embedded just as intended. However, Zotero seems to assign an unusual MIME type for the PDFs it stores that is “application/octetstream”. Thus to fit my needs, I added that type to the Mozplugger PDF handler

sudo vim /etc/mozpluggerrc

which now reads as

application/pdf:pdf:PDF file
application/x-pdf:pdf:PDF file
text/pdf:pdf:PDF file
text/x-pdf:pdf:PDF file
application/octetstream:pdf:PDF file
        repeat noisy swallow(evince) fill: evince "$file"
#       ACROREAD()
#       repeat noisy swallow(kpdf) fill: kpdf "$file"
#       repeat noisy swallow(Xpdf) fill: xpdf -g +9000+9000 "$file"
#       repeat noisy swallow(okular) fill: okular "$file"
#       GV()
#       repeat noisy fill exits: evince "$file"

Redmine

Der Grund für die doch etwas aufwendige Aktion war ein mehr oder weniger fehlgeschlagener Versuch, die das Projektmanagement-Tool Redmine als Ersatz für das bisher eingesetzte Trac auszuprobieren. Leider stieß mein alter Server dabei an seine Grenzen und verweigerte für kurze Zeit sogar die Annahme von E-Mails.

Weil ich einen Umstieg schon seit einem Jahr immer wieder überlegte, nahm ich die Situation zum Anlass um mit meinem Provider die Optionen zu besprechen. Mir wurde ein Upgrade angeboten, das sich heute leider als ungültig erwiesen hat. Letztendlich ist der einzige Unterschied eine Monatsmiete, weil ich beide Verträge nur mit einmonatiger Bindung abgeschlossen habe.

Den für Redmine notwendigen Ruby Stack habe ich aus den aktuellen Quellen selbst kompiliert, weil die Versionen in den CentOS Repositories für diese junge Software stark veraltet sind. Ruby stellt mit den gut unterstützen Gems eine gute eigene Paketverwaltung bereit.

CentOS

Weil ich auf meinem Laptop seit einiger Zeit auf die Linux Distribution Fedora setze, habe ich meine Distributionswahl am Server überdacht und statt Debian auf das Fedora-ähnliche aber auf den Servereinsatz aufgelegte CentOS gesetzt. Vom Geist der Revolution beflügelt, habe ich mich auch gleich versuchsweise von Apache als Webserver verabschiedet und auf Nginx umgestellt. Die gerade angezeigte WordPress wird entsprechend von PHP-FPM ausgeführt.

Für die Mailserver Infrastruktur verlasse ich mich weiterhin auf das bewährte Gespann von Dovecot und Exim. Weil mein Server meine zentrale Sammelstelle für alle E-Mail Konten ist (per Fetchmail), wollte ich hier nichts riskieren und sah auch wirklich keinen einzigen Grund für eine Veränderung.

VCS

Meine alten Subversion Repositories habe ich natürlich unverändert kopiert. Daneben habe ich mit Hilfe von Gitosis eine für meine Zwecke perfekte Git Verwahltung eingerichtet, die (wie svn+ssh) unter einem einzelnen Systemaccount und einer Sammlung von autorisierten öffentlichen Schlüsseln beliebig viele Git Repositories mit getrennt einstellbaren Zugriffsrechten zur Verfügung stellt. Nebenbei war die Unterstützung von Git und Subversion einer der Mitgründe für den Umstieg von Trac auf Redmine.

Fertig

Also genug Fachjargon. Fazit: Ich habe einige glückliche Stunden mit meiner virtuellen “Immobilie” verbracht. Nur damit die Änderungen nach außen hin nicht völlig unbemerkt bleiben habe ich auch gleich das WordPress Motiv geändert.

Bei diesem Titel versteht es sich vielleicht von selbst, dass FTP hier kein Thema ist. Es ist vermutlich zu einem nicht unwesentlichen Teil persönliche Präferenz, aber wenn ich das Wort sicher im Zusammenhang mit Servern verwende, verlasse ich mich immer gern auf SSH. Im Fall eines Fileservers bietet sich also das SFTP Protokoll an. Generell wirft die Verwendung von SSH und, im Speziellen, die Weitergabe von Zugangsdaten für einen SSH Server (zumindest) zwei brennende Fragen auf.

Zum einen muss verhindert werden, dass der eingeloggte Benutzer beliebigen Code ausführen kann. Da er zumindest für das Upload Verzeichnis Schreibrechte hat, kann ein eventueller Upload von Exploits nicht prinzipiell verhindert werden, aber wenn man dem Benutzer erst gar keine Shell gibt, kann er die Ausführung des Schadcodes nicht veranlassen. Diese Strategie verfolgt die scponly Software.

Zum anderen ist man als Administator auch interessiert, dem eingeloggten Benutzer möglichst wenig Information über das System preiszugeben. Das erreicht man mit einer chroot Umgebung. Nun wird sogar von scponly ein Skript angeboten, um eine solche Umgebung zu erstellen. Dessen Verwendung wird auf der ubuntuusers Wiki beschrieben. Leider ist dafür das Setzen des SUID Bits notwendig, was meiner Meinung nach keine saubere Lösung ist. Daher werde ich hier beschreiben, wie man eine äquivalente Umgebung mit dem makejail Skript erstellt. Diese Vorgehensweise orientiert sich stark an der Anleitung zum Absichern von Debian, welche in ihrer Gesamtheit auf jeden Fall eine Lektüre wert ist, wenn man einen Debian Server administrieren muss.

Praxis

Diese Anleitung bezieht sich auf Debian Lenny. Zuerst werden die erforderlichen Pakete installiert:

# aptitude install libpam-chroot makejail scponly

Nun wird das eben installierte PAM Modul libpam-chroot für SSH Logins aktiviert. Dazu werden die folgenden Zeilen zu der Datei /etc/pam.d/sshd hinzugefügt:

session    required     pam_chroot.so

Zunächst muss der entsprechende Benutzer erstellt werden, mit dem man sich später am Server anmelden kann.

# adduser --home /home/sftp --shell /usr/bin/scponly --no-create-home sftp

Damit das PAM Modul auch wirklich greift, muss es für den neuen Benutzer aktiviert werden. Das geschieht durch folgende Zeile in der Datei /etc/security/chroot.conf.

sftp	/var/chroot/users/sftp

Als nächstes wird das Verzeichnis für die chroot Umgebung erstellt und der neue Benutzer erhält Schreibrechte für sein Heimatverzeichnis.

# mkdir -p /var/chroot/users/sftp/home/sftp
# chown sftp:sftp /var/chroot/users/sftp/home/sftp

Für die Verwendung des makejail Skripts wird eine Konfigurationsdatei mit folgendem Inhalt erstellt und als sftp-jail.py gespeichert.

chroot="/var/chroot/users/sftp"
users=["sftp"]
testCommandsInsideJail=["scponly", "ls", "scp", "rm", "ln", "mv", "chmod", "chown", "chgrp", "mkdir", "rmdir", "pwd", "groups", "id", "echo", "passwd"]
forceCopy=["/usr/lib/sftp-server"]
cleanJailFirst=1
preserve=["/home/sftp"]

Es folgt der Aufruf des Skripts.

# makejail sftp-jail.py

Die am Ende ausgegebenen Warnungen können getrost ignoriert werden. Wenn man so vorsichtig ist wie ich, muss man noch dafür sorgen, dass der SSH Login für den neuen Benutzer freigegeben wird. Dazu fügt man den neuen Benutzernamen dem AllowUsers Parameter in der Datei /etc/ssh/sshd_config hinzu und startet das SSH Service neu.

# /etc/init.d/ssh restart

This might not have been possible in KDE 4.2 (I haven’t verified), but it is in KDE SC 4.4. The Input Actions dialog (under System Settings) allows for the configuration of DBus calls from hotkeys. This was configured fast and works painless. I have exported the hotkey group and pasted the content below. To use it, save this as PowerManagement.khotkeys and import it in the Input Actions dialog.

[Data]
DataCount=1
 
[Data_1]
Comment=Power management mappings of XF86 events
DataCount=1
Enabled=true
Name=Power Management
SystemGroup=0
Type=ACTION_DATA_GROUP
 
[Data_1Conditions]
Comment=
ConditionsCount=0
 
[Data_1_1]
Comment=Enables suspend hotkey
Enabled=true
Name=Suspend
Type=SIMPLE_ACTION_DATA
 
[Data_1_1Actions]
ActionsCount=1
 
[Data_1_1Actions0]
Arguments=
Call=org.freedesktop.PowerManagement.Suspend
RemoteApp=org.freedesktop.PowerManagement
RemoteObj=/org/freedesktop/PowerManagement
Type=DBUS
 
[Data_1_1Conditions]
Comment=
ConditionsCount=0
 
[Data_1_1Triggers]
Comment=Simple_action
TriggersCount=1
 
[Data_1_1Triggers0]
Key=Sleep
Type=SHORTCUT
Uuid={c1706a53-bde8-4364-b0af-71e9c1be6b3f}
 
[Main]
AllowMerge=true
ImportId=Power Management
Version=2