Dynamische Anwendung von Scopes

Was tun, wenn man Scopes auf eine ActiveRecord-Klasse dynamisch anwenden möchte ohne zig Klassenmethoden dafür implementieren zu müssen oder schlecht lesbare if-elsif-Konstrukte zu generieren? Diese Frage habe ich mir vor kurzem gestellt und ich bin zu folgendem Ergebnis gekommen.

Vorgeplänkel

Gehen wir für das folgende Beispiel davon aus, dass wir eine ActiveRecord-Klasse Human implementiert haben. Man beachte, dass die Scopes mit squeel definiert worden sind.

class Human < ActiveRecord::Base
  
  scope :order_by_created_at, lambda { order{created_at.desc} }
  scope :order_by_updated_at, lambda { order{updated_at.desc} }
  scope :order_by_name, lambda { order{name.desc} }

end

Beispiellösung

In meinem Fall war die Anforderung eine Klassenmethode auf Human zu definieren, die einen Hash mit Sortierungsparametern entgegen nimmt und anschließend Humans entsprechend der übergebenen Parameter sortiert zurückliefert. Möchten wir nun - aus welchen Gründen auch immer - die oben definierten Scopes anwenden um Humans sortiert abzufragen, können wir dies wie unten gezeigt bewerkstelligen.

class Human < ActiveRecord::Base
  
  # ...

  def self.order_by(*options)
    options = options.first || {}
    order    = ( options[:order].nil? || !options[:order].is_a?(Hash) ) ? {} : options.delete(:order)

    # Dynamically add scopes that order the humans by created_at, updated_at and name
    order.each do |key, value|
      scope_chain << "order_by_name" if key == :name
      scope_chain << "order_by_updated_at" if key == :updated_at
      scope_chain << "order_by_created_at" if key == :created_at
    end
          
    # Chain the relevant scopes and call each on Human
    scope_chain.inject(Human) { |obj, scope| obj.send(scope) }

  end

end

Der Methode order_by kann ein Hash order mit definierten Keys übergeben werden (hier sind es die Keys :name, :updated_at sowie created_at). Die Werte für jeden Key spielen keine Rolle. Alternativ hätte man auch ein Array nehmen können. Für jeden Hash-Key wird nun geprüft, ob dazu ein definierter Scope existiert. Ist dies der Fall wird der Scope-Name als String in ein Array scope_chain geschrieben. Schließlich wird ausgehend von Human mittels der inject-Methode jeder Scope durch send auf Human angewendet. Das Ergebnis wird zurückgeliefert.

Dieses Beispiel ist sehr kurz gehalten. In meiner Implementierung kommen noch einige Scopes mehr dazu sowie ein Defaut-Scoping, dass immer angewendet wird.

Zugriffsrechte auf geteilte Dateien und Ordner mit AFP und NAS4Free

FreeNAS 7 wird seit einiger Zeit nicht mehr unter diesem Namen weiterentwickelt. Das Projekt NAS4Free hat sich dem Sourcecode angenommen. Ich hatte zwar zwischenzeitlich einen Sprung auf FreeNAS 8 gewagt. Jedoch war ich von der Administrationsoberfläche und der Stabilität (zumindest auf meiner Hardware) nicht überzeugt.

Daher erfolgte am letzten Wochenende der Sprung zurück auf das ehemals FreeNAS 7 getaufte Projekt. Das Erkennen meines ZFS Pools machte keinerlei Schwierigkeiten. Mittels des Befehls zpool import 1 können spezifische Pools importiert werden. Vorteilhaft ist zuvor das Exportieren des Pools mit zpool export. Das hatte ich vergessen. Hat aber trotzdem funktioniert.

Das eigentliche Problem war im Anschluss das Bereitstellen und Teilen meiner ZFS Datasets über AFP zwischen verschiedenen Benutzern. Legt ein Benutzer A einen Ordner oder eine Datei an, der für das Teilen vorgesehen ist, kann ein zweiter Benutzer B nicht schreibend auf den Ordner zugreifen. Die voreingestellten Zugriffsrechte, die AFP nutzt, sehen dies nicht vor.

Die Dokumentation von netatalk beschreibt, wie man mit Hilfe der Parameter perm, dperm und fperm die Standardzugriffsrechte für neue Dateien und Ordner anpassen kann. Das geschieht in der Datei AppleVolumes.default, die unter NAS4Free unter /var/etc liegt. Leider bietet NAS4Free in der GUI keinerlei Einsellungsmöglichkeiten für die Zugriffsrechte. Ein manuelles Ändern der Zugriffsrechte in der Datei AppleVolumes.default ist möglich. Jedoch werden die Änderungen nach einem Neustart des AFP-Dienstes überschrieben.

Einen Workaround habe ich beim Probieren gefunden. In den Einstellungen eines AFP-Shares können am Ende des Eingabefeldes „Read/Write Access“ die benötigten Parameter angehangen werden. Diese werden in die AFP-Konfiguration übernommen. Wenn also Benutzer A, der einen Ordner oder eine Datei erstellt, und Benutzer B Zugriff auf den Ordner oder die Datei haben sollen, kann dies beispielsweise mit

Read/Write Access: userA,userB perm:0770

erreicht werden. Eine nicht besonders elegante Lösung. Sie funktioniert jedoch.

Eine grüne Familie

Ich hatte berichtet über den Dawanda-Shop von Ratzefummel. Dort hatte ich mir eine Hülle aus Filz und Fahrradschlauch für meine PSP besorgt. Und ich bin immernoch begeistert.

Mittlerweile ist eine kleine Familie daraus geworden, die ich lieb gewonnen habe.

familie_huelle.JPG

Airport lässt sich nicht mehr aktivieren

Ich habe heute über eine Stunde damit verbracht die Ursache dafür zu finden, dass sich die Wlan-Verbindung meines Macbook Pro (early 2008) nicht mehr aktivieren ließ. Den Grund hierfür habe ich nicht gefunden. Morgens beim Anmachen ging es einfach nicht mehr.

Glücklicherweise war die Lösung dann doch einfach und es war kein Hardwaredefekt: PRAM resetten. Vor der Anzeige des grauen Bildschirms beim Starten des Macs folgende Tastenkombination gedrückt halten bis der Mac nochmals neustartet:

command + option + p + r

EncFS in Verbindung mit Dropbox nutzen

In diesem Beitrag möchte ich kurz festhalten, wie man auf Mac OS X ein verschlüsseltes EncFS-Volume in der Dropbox nutzt und dies beim Login mittels launchd einbindet.

Installation von Fuse4X und EncFS
Da das Projekt MacFuse aufgegeben worden ist, werden wir für diesen Ansatz Fuse4X nutzen. Auf der Homepage des Projektes findet man ein Diskimage, aus dem man Fuse4X (zum Zeitpunkt des Schreibens Version 0.9) installieren kann. Weiterhin benötigen wir natürlich EncFS. Ein vorkompiliertes Paket für Snow Leopard ist dankenswerter Weise erhältlich. Das Paket ist nicht explizit Lion-kompatibel. Jedoch scheint es positive Erfahrungen gegeben zu haben (siehe Kommentare). Beides wird installiert und anschließend kann EncFS genutzt werden.

EncFS-Volume erstellen
Zunächst muss ein neues EncFS-Volume erzeugt werden. Dazu starten wir den Terminal unserer Wahl. Mit folgendem Befehl wird ein Volume erstellt, dessen verschlüsselter Teil in ~/Dropbox/.crypted liegt und, wenn gemounted, über ~/encrypted zugreifbar ist:

encfs ~/Dropbox/.crypted ~/encrypted

Bei Bedarf werden beide Ordner erstellt. Anschließend kann der Erstellungsmodus des Volumes angegeben werden. Siehe dazu die Dokumentation von EncFS bzw. die Manpage. Dann muss ein Passwort für das Volume gewählt werden. Dieses muss bei jedem Mounten des Volumes eingegeben werden. Wie wir das umgehen, steht weiter unten.

Das verschlüsselte Volume liegt nun in der Dropbox. Jetzt möchten wir das Volume beim Login einbinden und anschließend die Dropbox starten. Laut verschiedener Aussagen kann es zu Datenverlusten kommen, wenn erst Dropbox gestartet und dann das EncFS-Volume eingebunden wird. Daher unterbinden wir das automatische Starten der Dropbox beim Systemstart in den Einstellungen der Dropbox. Damit sollte das Anmeldeobjekt für den Benutzer gelöscht werden.

Passwort des EncFS-Volumes aus dem Schlüsselbund beziehen
Um nicht bei jedem Mounten des EncFS-Volumes das Passwort für selbiges eingeben zu müssen, werden wir das Passwort im Schlüsselbund ablegen und von dort beziehen. Dazu öffnen wir die Schlüsselbundverwaltung und erstellen einen neuen Schlüssel (s. Bild). Mit dem Eintrag im Feld „Account-Name“ werden wir im nächsten Schritt auf das Passwort zugreifen.

add_key_to_keychain.png

Skripte erstellen
Wir benutzen die folgenden zwei Shell-Skripte (vielen Dank an die Erdenker12) um das EncFS-Volume einzubinden und anschließend Dropbox zu starten. Beide liegen im Verzeichnis ~/encfs.

Skript 1 - fs-cryptmount: (Un-)Mounten des EncFS-Volumes

# Return code of script
errorCode=0

# Path to raw encfs volume
raw_encfs=~/Dropbox/.crypted

# Path to decrypted encfs volume
decrypt_encfs=~/encrypted

# Name of the mounted volume
vol_name=EncryptedDropbox

# Get password line out of keychain
password_line=$(security 2>&1 >/dev/null find-generic-password -ga encfs_volume)

# Retrieve raw password out of password line
password=$( echo "$password_line" | perl -n -e '/^password: "(.*)"$/ && print "$1n"')

# umount
if [ "$(basename $0)" = "fs-cryptumount.command" ]; then
  umount $decrypt_encfs
  if [ $? -eq 0 ]; then
    echo "EncFS volume $vol_name unmounted."
  else
    errorCode=$?
    echo "Error while unmounting volume $vol_name ."
  fi
  exit $errorCode
fi

# mount
echo -n "Mounting encfs volume $vol_name... "

mount | grep encfs >/dev/null 2>&1
if [ $? -ne 0 ]; then
  echo "${password}" | /usr/local/bin/encfs -o volname=$vol_name -S $raw_encfs $decrypt_encfs
  if [ $? -ne 0 ]; then
    errorCode=$?
    echo "Error while mounting volume $vol_name."
  else
    echo "Succesfully mounted volume $vol_name ."
    fi
else
  echo "Encfs volume $vol_name is already mounted."
fi

exit $errorCode

Wenn das EncFS-Volume einfach über die Kommandozeile ausgehangen werden soll, kann hier optional ein Link angelegt werden:

cd ~/encfs
ln -s fs-cryptmount.command fs-cryptumount.command

Nun kann mit dem Aufruf ~/encfs/fs-cryptumount.command das Volume ausgehangen werden. Das kann aber auch wie mit jedem anderen Volume direkt über den Finder geschehen.

Skript 2 - fs-secure-dropbox-start: Starten von Dropbox erst nach Einbindung des EncFS-Volumes


# Path to script
encfs_mount_script_path=~/encfs/fs-cryptmount.command

# Is the crypted directory (encfs process) already mounted?
ps ax | grep encfs | grep Dropbox >/dev/null
if [ $? -ne 0 ]; then
  # We have to mount EncFS
  $encfs_mount_script_path
  if [ $? -ne 0 ]; then
    exit $?
  fi
fi

# EncFS is mounted, now start Dropbox
open /Applications/Dropbox.app

LaunchAgent einrichten
Zum Schluss muss ein LaunchAgent für den aktuellen Benutzer eingerichtet werden, der die Skripte aufruft. Alternativ kann ein Anmeldeobjekt erstellt werden, welches das Skript fs-secure-dropbox-start ausführt. Dabei wird jedoch nach dem Einloggen ein Terminal-Fenster geöffnet, was nicht so schick ist.

Der LaunchAgent kann entweder mittels GUI (Lingon) oder per Hand mit einem Texteditor erstellt werden. Der Inhalt der Datei sollte ungefähr so aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>local.username.EncryptedDropbox</string>
	<key>ProgramArguments</key>
	<array>
		<string>/Users/username/encfs/fs-secure-dropbox-start.command</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
	<key>ServiceDescription</key>
	<string>Securely start Dropbox after an encrypted encfs volume was mounted.</string>
</dict>
</plist>

Dieser LauchAgent wird immer beim Einloggen ausgeführt; also genau, was wir möchten. Dabei wird das Skript fs-secure-dropbox-start gestartet.

Die erstellte Datei wird im Verzeichnis ~/Library/LaunchAgents/local.username.EncryptedDropbox.plist abgelegt. Der Dateiname kann frei gewählt werden. Wer Lingon genutzt hat, kann nun den aktuellen Benutzer abmelden und sich wieder neu anmelden. Dann sollte der Ordner ~/encrypted als Volume angezeigt werden. Er kann im Finder zur Sektion „Geräte“ gezogen werden und erscheint nun immer dort, wenn das Volume gemounted wird.

Wer den LaunchAgent manuell erstellt hat, muss sich eventuell noch mit launchctl auseinandersetzen und den LaunchAgent manuell laden.