Probiert habe ich es mit Mac OS-X 10.7 Server (Lion Server).

Vorraussetzung für die Installation ist Xcode welches im Mac App Store runtergeladen werden kann.

Der Packetmanager Homebrew kann die Installation vereinfachen, muss aber nicht genutzt werden.

Möchte man Homebrew nicht verwenden kann einfach die Installationsanleitung für Linux befolgt werden.

Interessant wird es dann wieder bei der Einrichtung als LaunchDaemon.

Installation mit Homebrew

• Zu aller erst muss der Packetmanager Homebrew installiertwerden:/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"
• Dann sollte erstmal git installiert werden damit Homebrew anständig läuft:brew install git
• Mit brew install node wird node.js installiert.
• Der node Paketmanager npmist leider wegen Problemen nicht im Homebrew enthalten, muss also manuell installiert werden:curl http://npmjs.org/install.sh | sh

Sind alle Programme vorhanden um wirklich Etherpad-Lite zu installieren:

• Es muss in den Ordner gewechselt werden in dem Etherpad-Lite installiert werden soll. Bei mir:cd /usr/local/
• Dann wird mit git die aktuelle Version von Etherpad-Lite runtergeladen:git clone 'git://github.com/Pita/etherpad-lite.git'
• In den etherpad-lite Ordner wechselncd etherpad-lite
• um noch weiter Abhängigkeiten mit npm und die Default-Configs zu installierenbin/installDeps.sh
• Jetzt kann Etherpad-Lite ausgeführt werden

bin/run.sh

• Einen Browser öffnen und http://localhost:9001 eingeben.

Das Etherpad-Lite sollte jetzt laufen!

Es können jetzt noch Einstellungen in settings.json angepasst werden.

Konfiguration als LaunchDaemon

Etherpad-Lite sollte unter einem extra Benutzer laufen. Dieser Benutzer heißt bei mir: etherpad

Wenn der Benutzer angelegt ist müssen die Rechte für den Etherpad-Ornder angepasst werden:

sudo chown -R etherpad /usr/local/etherpad-lite/

Jetzt muss noch im log-Verzeichnis ein Ordner für die Logs von Etherpad-Lite angelegt werden:

sudo mkdir /var/logs/etherpad-lite

Auch für diese Verzeichnis müssen die Rechte angepasst werden:

sudo chown etherpad /var/logs/etherpad-lite

Die LaunchDaemon-Plist muss unter /Library/LaunchDaemons/org.etherpad.etherpad-lite.plist gespeichert werden.

<?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>KeepAlive</key>
	<true/>
	<key>Label</key>
	<string>org.etherpad.etherpad-lite</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/etherpad-lite/bin/safeRun.sh</string>
		<string>/var/log/etherpad-lite/etherpad.log</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
	<key>StandardOutPath</key>
	<string>/var/log/etherpad-lite/etherpad.log</string>
	<key>StandardErrorPath</key>
	<string>/var/log/etherpad-lite/etherpad-error.log</string>
	<key>UserName</key>
	<string>etherpad</string>
	<key>GroupName</key>
	<string>etherpad</string>
</dict>
</plist>

Wurden andere Pfade benutz müssen diese in der Property-Liste angepasst werden.

Hat alles geklappt kann das Etherpad-Lite mit launchd gestartet werden:

sudo launchctl load /Library/LaunchDaemons/org.etherpad.etherpad-lite.plist

Jetzt sollte das Etherpad-Lite wieder unter http://localhost:9001 verfügbar sein.

Webapp

In Lion Server kann man jetzt ziemlich einfach Proxies und Webservices on-demand laufen lassen mit WebApps.

Einen guten Überblick über webappctl verschafft dieser Artikel und die manpages x-man-page://webappctl und x-man-page://webapp.plist
Die Konfigurationsdateien für Webapps liegen in /etc/apache2/webapps/
Für das Etherpad-Lite habe ich die Datei org.etherpad.etherpad-lite.plist hinzugefügt.

<?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">

<!-- See man pages for webapp.plist(5) and webappctl(8) for information about this example webapp.plist -->

<plist version="1.0">
<dict>
	<key>includeFiles</key>
	<array>		<!-- Include files are activated in virtual host when webapp is started -->
		<string>/etc/apache2/httpd_etherpad.conf</string>
	</array>
	<key>launchKeys</key>
	<array>		<!-- Launchd plists in /System/Library/LaunchDaemons are loaded when webapp is started -->
<!--		<string>com.example.mywebapp</string> -->
	</array>
	<key>name</key>
	<string>org.etherpad.etherpad-lite</string>
	<key>proxies</key>		<!-- ProxyPass/ProxyPassReverse directives are activated when webapp is started -->
	<dict>
		<key>/etherpad</key>		<!-- Sets up a reverse proxy -->
		<dict>
			<key>path</key>
			<string>/etherpad</string>
			<key>urls</key>		<!-- URLs comprise a proxy_balancer group -->
			<array>
				<string>http://localhost:9001</string>
			</array>
		</dict>
	</dict>
	<key>requiredModuleNames</key>
	<array>		<!-- Apache plugin modules are enabled when webapp is started -->
		<string>proxy_module</string>
	</array>
        <key>requiredWebAppNames</key>
        <array>         <!-- Required web apps are started when this webapp is started -->
<!--                <string>com.example.webapp.myotherwebapp</string> -->
        </array>

	<key>sslPolicy</key>	<!-- Determines webapp SSL behavior -->
	<integer>0</integer>	<!-- 0: default, UseSSLWhenEnabled -->
			<!-- 1:	UseSSLAlways -->
			<!-- 2:	UseSSLOnlyWhenCertificateIsTrustable -->
			<!-- 3:	UseSSLNever -->
			<!-- 4:	UseSSLAndNonSSL -->
</dict>
</plist>

Die eingebundene Konfiguration /etc/apache2/httpd_etherpad.conf enthält Einstellungen für die Authentifizierung. Nur Benutzer die in der Gruppe etherpad_users sind können auf das Etherpad zugreifen:

#configuration File for Etherpad-Lite webapp
<Location "/etherpad">
	AuthType Digest
	AuthName "Access Etherpad"
	Require group etherpad_users
</Location>

Die Webapp starten:
sudo webappctl start org.etherpad.etherpad-lite

Das Etherpad solle jetzt unter http://localhost/etherpad erreichbar sein.

Wenn eine Datei oder ein Ordner in den Ordner gelegt wird, werden automatisch die Zugriffsrechte für allen Unterobjekten auf Lese- und Schreibzugriff für alle Benutzer geändert (chmod 777), zusätzlich wird an jeden Unterordner das Skript als Folder-Action angefügt.

Das Skript kann zum Beispiel dazu genutzt werden auf einem File-Server alle Objekte in einer Freigabe für alle Benutzer les- und schreibbar zu halten, auch wenn ein Benutzer ausversehen ein Objekt mit “falschen” Zugriffsrechten in den Ordner kopiert.

on adding folder items to this_folder after receiving added_items
	tell application "Finder"
		repeat with this_item in added_items
			my theScript(this_item)
			my subfolders(this_item)
		end repeat
	end tell
end adding folder items to

on subfolders(this_folder)
	tell application "Finder"
		repeat with each_folder in (get every folder of this_folder)
			my theScript(each_folder)
			my subfolders(each_folder)
		end repeat
	end tell
end subfolders

on theScript(action_folder)
	set script_file to ((path to library folder as Unicode text) & "Scripts:Folder Action Scripts:chmodPublic_and_addScript.scpt" as Unicode text)
	tell application "System Events"
		attach action to (action_folder as alias) using (script_file as alias)
	end tell

	set posix_path to quoted form of POSIX path of action_folder as string
	set ScriptReturn to do shell script "/bin/chmod -R -f 777 " & posix_path

end theScript

Auf der Sucher nach den Vuvuzela-Frequenzen bin ich auf die Webseite von Tobias Herre gelandet, der die Frequenzen schon analysiert und mit Logic aus dem Tonsignal vom Fernseher rausgefiltert hat.

Mit Garageband und dem AUFilter als Effekt kann man recht einfach bestimmte Frequenzen rausfiltern.

Ich habe dann noch etwas an den Frequenzen rumgespielt und nach einen Blick auf AudioXplorer noch ein paar anderen hinzugefügt. Natürlich bekommt man das Geräusch der Vuvuzelas nicht ganz weg und der Kommentator klingt etwas verzerrt, es funktioniert aber trotzdem recht gut.

Wenn man dann Monitoring aktiviert kann man das Eingangssignal gefiltert ausgeben.

Da ich über einen DVB-T-Stick am Computer gucke, musste ich mir eine Möglichkeit suchen das Audio-Signal von EyeTV in Garageband zu routen. Soundflower ist hier der Retter in Not. Einmal installiert bietet Soundflower virtuelle Audio-Devices an an die man in EyeTV als Ausgang einstellen kann und dann in Garageband als Eingang.

Danach kann man die WM-Übertagungen etwas Vuvuzela-freier genießen.
Hoffentlich merken die Sender auch mal, dass man das Stadion-Vuvuzela-Geräusch nicht braucht und drehen die Stadion-Mikros ab…

Hier mein GarageBand Projekt zum Download: Vuvuzela Filter (Update weiter unten)
Ich hoffe der eine oder andere kann so die WM Vuvuzele-Gefiltert genießen.

Nachtrag:

Der von den Vuvuzelas erzeugte Grundton ist fast ein kleine Ais(ich habe 235Hz gemessen), doch lassen sich auch andere Töne der Naturtonreihe auf einer Vuvuzela spielen, also 470Hz, 705Hz, 940Hz, 1175Hz, 1410Hz, 1645Hz, 1880Hz, 2115Hz, usw.

Wenn diese Frequenzen aus dem Audio-Signal rausgefiltert werden sollten die Vuvuzelas nicht mehr hörbar sein.

Download mit aktualisierten Frequenzen: Vuvuzela Filter

push "dhcp-option DNS 10.66.0.4"
push "dhcp-option DNS 10.66.0.5"
push "dhcp-option WINS 10.66.0.8"

unter 10.4 und 10.5 Problemlos, doch seit 10.6 wird der lokale DNS-Server ersetzt. Deshalb geht dann die Namensauflösung von externen Server nicht mehr oder nur noch sehr langsam über das VPN.In der Dokumentation von http://code.google.com/p/tunnelblick/wiki/QuickStartGuide steht, dass man wenn man beide DNS-Server nutzen möchte, ein dazu passendes Skript schreiben muss.

Da ich meinen lokalen und den DNS-Server auf der anderen Tunnelseite nutzen möchte, muss ich mein eigenes Skript schreiben. Das Skript konfiguriert welcher DNS-Server für die gegebene Domain benutzt werden soll.

#!/bin/bash
####
# The script sets/deletes the DNS-Server to use for a given domain
# by Tobias Conradi Mar 21 2010
# www.tobias-conradi.de
#####
if [ "$1" = "add" ]
then
mkdir -p /etc/resolver > /dev/null
echo "nameserver $3" > /etc/resolver/$2
elif [ "$1" = "delete" ]
then
rm -Rf /etc/resolver/$2
fi
if [ "$1" = "add" ] || [ "$1" = "delete" ]
then
killall DirectoryService
exit 0
else
echo "Error"
echo "Usage: $0 add|delete mydomain.de 192.168.1.1"
fi

up "/Applications/Utilities/Tunnelblick.app/Contents/Resources/set-DNS.sh add mydomain.de 192.168.66.2"
down "/Applications/Utilities/Tunnelblick.app/Contents/Resources/set-DNS.sh delete mydomain.de"

Jetzt noch in Tunnelblick “Nameserver festlegen” deaktivieren und schon müssten beide DNS-Server funktionieren.

Links:
OpenVPN
Tunnelblick