Meine Spieleliste

Was macht man so, wenn man Langeweile hat.? Man kommt auf die komischsten Ideen. Dabei ist mir mal in den Sinn gekommen, zu erfassen mit welchen Computerspielen – vornehmlich auf PC und Mac – ich in meinem bisherigen Leben so meine Zeit verdaddelt habe. Wobei ich sagen muss, dass ich längst nicht alle wirklich durchgespielt habe. Ich hoffe dennoch, dass ich in Zukunft weiterhin Zeit und Muse haben werde, damit diese länger wird. Zum gegenwärtigen Zeitpunkt freue ich schon sehr auf die Veröffentlichung von Thimbleweed Park von Ron Gilbert, welches ich 2014 auf Kickstarter mit gefundet habe.

Link zur Liste im Wiki

Suchmaschinen in Chrome-Browser verwalten

Aus bildungstechnischen Gründen bin ich vorläufig für die nächst Zeit genötigt einen Windows-PC zu benutzen. Aber mir war klar, dass ich den Internet Explorer als Standart-Browser nicht benutzen werde. Argumente dazu habe ich zwar im Moment keine, es wird sicherlich dennoch welche geben, die meine Entscheidung stützen können. Ich habe mich dann doch erstmal für Google Chrom entschieden. Mein Beweggrund zu dieser Entscheidung war, dass Chrome bereits ein eigenes PlugIn für Adobe-Flash integriert hat und nicht der Flash-Player von Adobe separat systemweit installiert werden muss. Wenn man dennoch Google nicht als Suchmaschine verwenden möchte, so kann man in den Einstellungen eine andere wählen oder – wenn nicht angeboten – eine weitere hinzufügen. Die in der Adresszeile eingegeben Begriffe werden so nicht mehr von Google verarbeitet, sondern an die eigene präferierte weitergeleitet. Ich selber habe mich für DuckDuckGo entschieden. Wie weit das in Bezug auf Datenschutz gut ist, weis ich jetzt nicht, aber es ist zumindest ein Anfang. Anbei also die Werte, die in den Browsereinstellungen eingetragen werden müssen.

Zu erreichen über „Chrome anpassen und einstellen“ -> Button „Suchmaschinen verwalten“

Einträge in Chrome für DuckDuckGo als Standart-Suchmaschine

Einträge in Chrome für DuckDuckGo als Standart-Suchmaschine

Erstellen eines eigenen SSL-Server-Zertifikates

Nachdem ich mir vor sechs Wochen wieder ein vServerchen geleistet habe um meinen Senf in diesem Blog ablassen zu können, bin ich für mich mal die Frage durchgegangen wie ich das mit der Transportverschlüsselung löse. Denn früher hatte ich das nämlich bei dieser Domain noch nicht getan. Für mich war ganz klar, dass ich über meinem ISP keine zusätzliche 50,- Euro für ein von einer offiziellen Zertifizierungsstelle signiertes SSL/TLS-Zertifikat jährlich ausgeben werde. Die Lösung des Ganzen befindet sich sowieso in Form eigener Bordmittel in jedem Linux oder lässt sich im Zweifel auch auf anderen Systemen nachinstallieren. Im nachfolgenden werde ich meine eigene CA erstellen, um mir mein eigenes SSL-Zertifikat erzeugen zu können.

1. Erstellen der CA

Ist OpenSSL – beziehungsweise als Alternative neuerdings gerne auch LibreSSL – auf dem Rechner installiert, ist es mal der Ordnung halber praktisch sich einen Ordner ca anzulegen, wo die Dateien abgelegt werden sollen.

root@linux# mkdir /root/ca
root@linux# cd /root/ca

Die Gültigkeit setze ich mit 10 Jahren bewusst erst einmal sehr hoch an. Läuft die CA aus, so werden nämlich auch alle damit signierten Serverzertifikate ungültig. Die CA enthält einen geheimen Schlüssel, welcher automatisch erzeugt und in der Datei cakey.pem abgelegt wird. Das CA-Zertifikat wird nach cacert.pem geschrieben. Der folgende Befehl erzeugt einen Schlüssel für das Zertifikat mit einer Länge von 2048 Bit:

root@linux# openssl req -new -x509 -newkey rsa:2048 -keyout cakey.pem -out cacert.pem -days 3650
Generating a 2048 bit RSA private key
..............................................................
..............................................................
.........................................+++
......................................+++
writing new private key to 'cakey.pem'

Wer den geheimen Schlüssel der CA kennt, kann damit beliebige Serverzertifikate signieren. Deshalb wird diese Schlüsseldatei nicht im Klartext auf der Festplatte abgelegt, sondern mit einer Passphrase verschlüsselt. Diese Passphrase benötigt man immer dann, wenn mit dieser CA neue Zertifikate ausgestellt werden sollen.
Danach wird man gebeten, Daten einzugeben, welche die CA identifizieren. Diese werden dem Client angezeigt, wenn er aufgefordert wird, das Zertifikat zu akzeptieren oder abzulehnen. Der Code für Deutschland ist DE. Wenn ein Feld leer bleiben soll, so reicht es, einen Punkt ein zu geben. Ansonsten wird der in eckigen Klammern stehende Defaultwert eingetragen.
Das Feld Common Name (CN) ist hier der offizielle Name der Zertifizierungsstelle. Für die eigene CA reicht es, den eigenen Namen einzutragen.
Am Ende sind dann die Dateien cacert.pem und cakey.pem entstanden.
Vorsichtshalber sollten man die Rechte so setzen, dass die Schlüsseldatei nur für root lesbar ist.:

root@linux# chmod 600 cakey.pem

Mit dem Befehl

root@linux# openssl rsa -in cakey.pem -noout -text

kann man nun einmal prüfen, ob sich der Schlüssel mit der Passphrase öffnen lässt.

2. Schlüssel für das Serverzertifikat erzeugen

Nachdem nun die eigene CA vorhanden ist, kann diese nun endlich eigene Zertifikate herausgeben. Dazu wird zunächst ein 2048 Bit langer RSA-Schlüssel erzeugt, welcher mit AES 256 verschlüsselt auf der Platte abgelegt wird. Die Passphrase muss diesmal nicht sonderlich geheim sein, da sie ohnehin im Anschluss wieder entfernt wird. OpenSSL lässt allerdings keine leere Phrase zu.

root@linux# openssl genrsa -out serverkey.pem -aes256 2048 -days 3650

Jetzt ist es ganz praktisch die Passphrase wieder zu entfernen, da der Server auch ohne Zutun des Administrators in der Lage sein soll, den Schlüssel zu lesen. Sonst müsste bei jedem Booten der Machine ein Passwort eingegeben werden.

root@linux# openssl rsa -in serverkey.pem -out serverkey.pem

3. Certificate Signing Request erzeugen

Der nächste Schritt zum eigenen Zertifikat ist ein CSR. Dies muss dann nur noch von der CA signiert werden. Hier sind wieder Angaben analog zum Erstellen der CA nötig, was oft Verwirrung stiftet. Die allgemeinen Daten kann man gegebenfalls gleich wie oben eingeben.

root@linux#  openssl req -new -key serverkey.pem -out req.pem -nodes

ACHTUNG, jetzt kommt das Wichtige: Beim Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name stehen, unter dem der Client den Server anspricht! Wird das Zertifikat für eine HTTPS-Verbindung zu www.domain.tld verwendet, so muss der Common Name eben genau www.domain.tld heißen. Andernfalls wird der Browser das Zertifikat nicht akzeptieren, da er davon ausgehen muss, auf dem falschen Server gelandet zu sein.

Common Name (eg, YOUR name) []: www.domain.tld
Email Address []: name@domain.tld

Weitere Optionen kann man einfach leer lassen.

A challenge password []:
An optional company name []:

4. OpenSSL-Konfiguration anpassen

Leider kann man bei OpenSSL nicht alle Daten als Kommandozeilenargumente übergeben. Einige Einstellungen müssen lästigerweise in der Datei /etc/ssl/openssl.cnf geändert werden, bevor man signieren kann. Dazu die Datei öffnen und folgende Zeilen in der Sektion [ CA_default ] anpassen.

dir             = .              # Where everything is kept
new_certs_dir   = $dir           # default place for new certs
private_key     = $dir/cakey.pem # The private key
RANDFILE        = $dir/.rand     # private random number file
default_days    = 3650           # how long to certify for

Das Feld default_days ist auf 365 Tage voreingestellt und gibt die Gültigkeit des Zertifikates an. Dieses setze ich wie im Beispiel auf 10 Jahre herauf.
Wenn bei dem Serverzertifikat kein Bundesstaat angegeben ist, wird folgende Änderung unter [ policy_match ] benötigt.

stateOrProvinceName     = optional

Nun muss man noch einige Dateien anlegen:

root@linux# echo 01 > serial
root@linux# touch index.txt

5. Serverzertifikat signieren

Als krönenden Abschluss signiert die eigene CA nun das Zertifikat

root@linux# openssl ca -in req.pem -notext -out servercert.pem

6. Zertifikate installieren

Wohin die erzeugten Zertifikate installiert werden sollen, hängt vom jeweiligen Serverdienst ab. Was ihnen aber allen gemeinsam ist, es werden nur die Dateien cacert.pem, servercert.pem und serverkey.pem benötigt. Die Datei cakey.pem wird nicht benötigt und sollte nicht auf dem Server liegen sondern am besten sicher auf einem anderen Rechner verwahrt werden.
Da es sich bei den Dateien im wesentlichen nur um Textdateien handelt, ist es prinzipiell egal wie sie heißen. Der Übersicht halber und zur besseren Ordnung kann man sie aber auch im Nachhinein in eine umgänglichere Form unbenennen.

cacert.pem -> ca.crt
servercert.pem -> server.crt
serverkey.pem -> server.key

Jetzt sind das aber alles keine neuen Erkenntnisse. Im letzen Jahr erst wurde mit Let’s Encrypt eine alternative Zertifizierungsstelle ins Leben gerufen, um für alle Server-Betreiber kostenlose Zertifikate anbieten und ausstellen zu können. Diese wird unter anderem von der Mozilla und der Electronic Frontier Foundation gesponsert. Man wird sehen wie sich das entwickeln wird.

Einen Telnet-Server unter Debian/Ubuntu-Linux installieren

Für eine bestimmte Anwendung brauche ich zur Zeit Telnet und da ja die SSH seit Ewigkeiten Telnet wegen des Sicherheitsaspektes abgelöst hat, muss man den Server manuell nach installieren.

sudo apt-get install telnetd

Da sowohl das aktuelle Debian- als auch Ubuntu-Linux auf systemd umgestiegen ist, so muss man mit

sudo /etc/init.d/openbsd-inetd  restart

diesen noch starten.

Auf die Diskussion, dass ja die SSH ja sicher ist, brauche ich mich hier jetzt nicht einlassen. Für die Anwendung wo Telnet eingesetzt wird, fallen keine Sicherheitsrelevanten Daten an. Im Gegenteil: Das Protokoll ist für die Client zu Server Kommunikation nach jetziger Implementierung eher besser geeignet. Für die eigentlichen Fernwartungsaufgaben steht ja nach wie vor die SSH auf dem Zielrechner zur Verfügung.

Autostart von irssi in einer screen-Session

Wenn man bestimmte Skripte oder andere Sachen automatisiert mit dem Systemstart zum rollen bringen will, so lassen sich diese in die Datei /etc/rc.local einbinden.

sudo -u $username screen -d -m -U -S irssi irssi

Egal ob Änderungen in der Datei vorgenommen werden oder auch nicht, am Ende muss in der letzten Zeile immer „exit 0“ stehen!

Da ich diese Konfiguration das erste Mal auf einem Raspbian zum starten bringen wollte, musste ich zu meinem Entsetzen feststellen, dass auf diesem standardmäßig erst einmal kein sudo installiert ist. Ist zwar kein Problem, weil lässt sich ja nach installieren, aber ich war schon erstaunt.

WLAN am Raspberry PI einrichten

Der Net-Installer des Debian-Port Raspbian für den Raspberry Pi ist recht übersichtlich und auf der Projektseite hier dokumentiert. Da ich in dem Fall zu Anfangs lediglich immer nur ein Grundsystem mit einem SSH-Server auf eine SD-Karte werfe, gibt es keine Möglichkeit, dass man sich mit dem Pi out of the Box via WiFi ins Netz verbinden kann. Leider fehlt bei einer Standart-Debian-Installation auch das Toolkit um WLAN-Adapter zu konfigurieren. Also muss dieses als erstes nach installiert werden:

apt-get install wireless-tools wpasupplicant

Da ich mich auch für den allgemein bei den Pi’s sehr beliebten Edimax EW7811Un USB-Adapter entschieden habe, hilft es auf folgende Weise zu verifizieren ob dieser vom System im eingesteckten Zustand ordentlich erkannt wurde.
Durch Eingabe von lsusb sollte das WLAN-Gerät über den USB-Host-Adapter mit seinen vollen Namen aufgelistet werden.
Mit lsmod kann man prüfen, ob das entsprechende Kernelmodul zu den Realtek-Chip mit geladen wurde. In diesem Fall heisst dies 8192cu.
Als finale Möglichkeit zu Überprüfen ob der Edimax einsatzbereit ist, kann man sich mit iwconfig mal die „aktuelle“ Konfiguration des WLAN-Interface anzeigen lassen. Entscheidend dabei ist, das es einen Eintrag mit wlan0 gibt.

Wenn das alles gegeben ist, kann man mit restlichen Konfiguration weiter machen.

Als erstes muss das WLAN-Gerät in die Datei /etc/network/interfaces hinzugefügt und die Konfigurationsparameter mitgegeben werden. In diesem Fall soll die IP-Adresse via DHCP bezogen werden und es wird in der letzten Zeile ein Verweis auf die Konfigurationsdatei wpa_supplicant.conf gesetzt.

/etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary LAN-network interface
allow-hotplug eth0
iface eth0 inet dhcp

# The Edimax USB-WiFi interface
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
        wpa-driver wext
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Die eigentliche WLAN-Konfiguration mit den Parametern zum Aufbau der (verschlüsselten) Verbindung wird unter /etc/wpa_supplicant/wpa_supplicant.conf definiert. In dem Fall WPA/WPA2 verschlüsselt. Sollte die Datei noch nicht existieren, dann erstellt man sie einfach.

/etc/wpa_supplicant/wpa_supplicant.conf:

network={
        ssid="_Name_des_Netwerk_"
        scan_ssid=1
        proto=RSN
        key_mgmt=WPA-PSK
        pairwise=CCMP TKIP
        group=CCMP TKIP
        psk="_Absolut_sicheres_Passwort_"
}

Mit dem Befehl ifup wlan0 wird dann das Interface neu gestartet und soll eine IP-Adresse beziehen mit der es sich dann versucht ein zu wählen. Ein Neustart des gesamten Raspbian tut aber auch nicht weh. Wenn ein ifconfig wlan0 als Ausgabe plausible Adress- und Netzmaskenwerte gibt, dann wurde alles richtig gemacht.

Im Wiki des Ubuntu-Forum gibt es auch sehr hilfreiche Howtos und Erklärungen zu Thema, die einem weiter bringen.
http://wiki.ubuntuusers.de/WLAN/Installation
http://wiki.ubuntuusers.de/WLAN/wpa_supplicant

Saubere MacPorts

Nach Jahren der Updaterei und neues Mac OS X Betriebssystem hinüber bügeln, tut es einfach mal gut, alle Programme via MacPorts mal zu deinstallieren und wieder neu zu installieren. Dabei werden automatisch alle Versions-Leichen, welche nicht mehr benötigt werden und Bibliotheken die einst mal mit installiert wurden weil ich Programm XY mal kurz ausprobiert habe, mit gelöscht.
Anbei eine Liste von Programme, die ich standartmässig auf einem Mac installiere:

sudo port -v -fp uninstall installed && sudo port -v install erlang gnupg2 irssi mc minicom mtr py27-ipython py-pip py-serial py-py2app nmap rtmpdump simh tcpdump tcpflow tmux w3m watch wget

Danach klappt’s auch wieder mit den Verlinkungen sauber.

Update:

Anmerkung vom Clemens:

In diesem Kontext auch hilfreich: wiederholt sudo port uninstall leaves ausführen. Das gleiche mit ein bisschen mehr Toolchain drumrum: sudo port install port_cutleaves; port_cutleaves.

Programme unter Mac OS X deinstallieren

Einem Thema, welchen ich mich bisher verweigert habe, ist das Deinstallieren von Programmen unter Mac OS X. Es ist ja ganz praktisch, dass die meisten Programme dank ihres Application-Framework keine Routinen für das Installieren und wieder Deinstallieren benötigen. Es bleiben aber dennoch ja nach Programm in folgen Verzeichnen programmspezifische Daten zurück.

– Voreinstellungen in ~/Library/Preferences/
– Hilfsdaten und Cache in ~/Library/Application Support/
– gespeicherte Programme in ~/Library/Saved Application State/

Meistens habe ich diese Dateien von Hand aus den Verzeichnen heraus gefummelt. Aber vor einigen Tagen habe ich mal diverse Deinstallations-Programme ausprobiert, die es einem ermöglichen per ‚Drag & Drop‘ ein Programm auf dieses zu ziehen und die Meta-Daten gleich automatisch mit löschen. Unter diesen Lösungen gibt es allerdings auch Potenzial, mit der sich das ein wenig weiter automatisieren lässt. AppTrap ist eine kleine Erweiterung für die Systemsteuerung, die einen kleinen Hintergrundprozess startet und schaut, ob der Benutzer ein Programm aus den Applikationenordner löscht, und löscht damit auch alle anderen Programmspezifischen Daten. Man sollte vielleicht aber die Abfrage eingeschaltet lassen, da dieser Mechanismus auch greift, wenn die Programme sich selbst aktualisieren und man so Gefahr läuft, dass die Daten auch dann weg sind, wenn man es nicht möchte.

Ein anderes Thema sind aber Programme oder Betribessystemkomponenten, die eine Installationsroutine mitbringen. Sie befinden sich in einem .pkg oder .dpkg Paket. Hier reicht nicht das einfache verschieben des Programm-Icon in den Papierkorb – wenn es überhaupt eines gibt. Sondern man will unter Umständen wieder Teile aus dem systemweiten Ordnern /Library und /System entfernen. Seit Ewigkeiten gibt es mit dem Paketmanager OSXPM ein Tool, welches diese Funktion auch beherrscht. Problem ist aber, dass das Programm bei neueren Mac OS X Versionen als Snow Leopard (10.6.x) nicht mehr lauffähig ist, da es für die PowerPC-Architektur geschrieben wurde und die neuen Betriebssystemversionen keinen PowerPC-Code mehr ausführen können.
Abhilfe hierbei schafft hierfür endlich nach langer Zeit das Programm UninstallPKG welches vom corecode-Entwicklerteam für ca 7 € angeboten wird. Es listet ausschliesslich alle Programme und Komponenten auf, die mit einer Installationsroutine auf dem System installiert wurden und man kann diese – beziehungsweise dessen verwaisten Einträge – wieder löschen. Hintergrund ist: Das das Mac OS X einen eigenen ProperyList-Eintrag für jede Komponente führt, der so wieder heraus genommen werden kann.

Die Wolke in der eigenen Hand

Seit der iTunes-Version 11.2 und iOS 7.0.3 hat nun Apple das vollzogen, wovon ich nie gedacht hätte, dass es passieren würde. Man kann die Kalender- und Kontaktdaten nun nicht mehr lokal über WiFi oder USB zwischen Computer und iPhone/iPad synchronisieren. Stattdessen braucht man dazu seine Apple-ID um das über die iCloud abzugleichen. Aber die iCloud kommt für mich nicht in Frage, da die Daten nichts auf fremden Servern zu suchen haben, die zu allen Überfluss auch noch im Ausland stehen. Ich weis schliesslich nicht, ob sie dort auch verschlüsselt abgelegt werden und muss eventuell davon ausgehen, dass irgendwelche staatlichen Behörden auf diese Server zugriff haben. Deswegen habe ich nun beschlossen, einen meiner Raspberry Pi’s dazu zu nutzen und auf ihn ownClod installieren, der sicher in meiner eigenen Wohnung steht. Mit ihm werde ich meine Kalender- und Kontaktdaten über mein lokales Netz austauschen, währenddessen die Bilder-, Audio- und Applikationen sowieso ich über USB synchronisiere.

Raspberry Pi für ownCloud

Raspberry Pi für ownCloud

Anbei ein kleiner Workaround zur Installation von ownCloud.

Ich entscheide mich hierbei für den Webserver nginx, der wohl etwas Ressourcen schonender als der Apache-Webserver ist und flüssiger läuft.

Auf dem Server werden also folgende Komponenten zur ownCloud mit installiert:

  • nginx Webserver
  • PHP5
  • SQLite (Datenbank auf Dateibasis)
  • sowie diverse Pakete zum Performancegewinn

Nachdem man sich via http://www.raspbian.org/RaspbianInstaller mit den Raspbian-Installer ein Debian Weezy Grundsystem installiert hat, installiert man sich mit raspi-config ein sehr praktisches Konfigurationswerkzeug, um auf dem System ein paar grundlegende Einstellungen für das Gerät vorzunehmen.

sudo apt-get install raspi-config
sudo raspi-config
  1. change_locale zu „en_US.UTF-8“ für das komplette System (Ansonsten meckert ownCloud, dass es zu Fehlern bei Dateinamen mit Sonderzeichen kommen kann)
  2. memory_split auf „16“ MB einstellen. Dies ist die kleinst mögliche Einstellung. Die GPU bekommt somit 16MB.
  3. overclock auf „Medium“ 4. „Finish“ und danach die Frage nach dem Reboot mit „Yes“ beantworten.

Paketlisten aktualisieren

sudo apt-get update
sudo apt-get upgrade

Benutzer erstellen

sudo groupadd www-data
sudo usermod -a -G www-data www-data

Installation der Pakete

 sudo apt-get install nginx openssl ssl-cert php5-cli php5-sqlite php5-gd php5-curl php5-common php5-cgi sqlite php-pear php-apc curl libapr1 libtool curl libcurl4-openssl-dev php-xml-parser php5 php5-dev php5-gd php5-fpm memcached php5-memcache varnish

SSL Zertifikat erstellen (gültig für 1 Jahr)

sudo openssl req $@ -new -x509 -days 365 -nodes -out /etc/nginx/cert.pem -keyout /etc/nginx/cert.key
sudo chmod 600 /etc/nginx/cert.pem
sudo chmod 600 /etc/nginx/cert.key

nginx Webserver konfigurieren

sudo nano /etc/nginx/sites-available/default

Hier löscht man den kompletten Inhalt und fügt stattdessen den unten stehenden ein.
Darauf achten, dass man die IP-Adresse „192.168.XXX.XXX“ mit der des Raspberry Pi ersetzt.

server {
listen 80;
  server_name 192.168.XXX.XXX;
  rewrite ^ https://$server_name$request_uri? permanent;  # enforce https
}

server {
listen 443 ssl;
server_name 192.168.XXX.XXX;
ssl_certificate /etc/nginx/cert.pem;
ssl_certificate_key /etc/nginx/cert.key;
root /var/www;
index index.php;
client_max_body_size 1000M; # set maximum upload size
fastcgi_buffers 64 4K;


location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README) {
  deny all;
}


location / {
  try_files $uri $uri/ index.php;
}

location @webdav {
  fastcgi_split_path_info ^(.+\.php)(/.*)$;
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param HTTPS on;
  include fastcgi_params;
}

location ~ ^(?.+?\.php)(?/.*)?$ {
  try_files $script_name = 404;
  include fastcgi_params;
  fastcgi_param PATH_INFO $path_info;
  fastcgi_param HTTPS on;
  fastcgi_pass 127.0.0.1:9000;
}
}

Danach in folgender Datei die Werte „upload_max_filesize“ sowie „post_max_size“ auf 1000M setzen.

sudo nano /etc/php5/fpm/php.ini
upload_max_filesize = 1000M
post_max_size = 1000M

Am Ende der Datei noch folgendes einfügen:

upload_tmp_dir = /srv/http/owncloud/data

Als nächstes muss folgender Ordner mit den dazugehörigen Rechten erstellt werden

sudo mkdir -p /srv/http/owncloud/data
sudo chown www-data:www-data /srv/http/owncloud/data

PHP konfigurieren

sudo nano /etc/php5/fpm/pool.d/www.conf

Hier ändert man folgende Zeile von:

listen = /var/run/php5-fpm.sock

zu

listen = 127.0.0.1:9000

Webserver und PHP neustarten

sudo /etc/init.d/php5-fpm restart
sudo /etc/init.d/nginx restart

ownCloud installieren
Als letztes wird ownCloud installiert. Folgende Befehle müssen abgearbeitet werden.

wget http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/Release.key
apt-key add - < Release.key echo 'deb http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/ /' >> /etc/apt/sources.list.d/owncloud.list
apt-get update
apt-get install owncloud

Nun lässt sich der Server im lokalen Netz aufrufen. In meinem Fall ist das https://192.168.1.104/owncloud. Als letztes muss nur noch ein Administratorkennwort und ein Benutzername festgelegt werden. Somit ist die Installation vollends abgeschlossen.

Der schnellste Weg, Adressbücher und Kalender in die eigene Wolke zu laden, führt über die Webanwendung von Owncloud, die Dateien im VCF- und ICS-Format importieren kann.

Bei Adressbüchern (.vcf) klappte der Import im Versuch allerdings nicht immer reibungslos. Bei einem Adressbuch, in dessen Feldern Doppelpunkte vorkamen, brach der Import leider ab. Im Zweifel muss man vor dem Import noch an den Daten feilen. Auch Gruppen ließen sich nicht importieren, da ownCloud sie als regulären Adressbuch-Eintrag interpretierte. Ein Fehler, der hoffentlich bald behoben wird.

Weiterführende Links:
Artikel bei iRights.info
Das Howto im RaspberryPi-Forum

QBASIC Primzahlgenerator

Vor einer halben Ewigkeit hatte auch ich mich mal ein wenig mit der Programmiersprache BASIC auseinander gesetzt. Um genau zu sein, mit der Microsoft-Implementation QBASIC, die mit den DOS-Versionen 5 und 6.x kostenlos ausgeliefert wurde. Irgendwann bekam ich auch ein seinerzeit schon ein völlig veraltetes Lehrbuch zu QBASIC in die Hände, welchem eine Diskette mit Beispielprogrammen im Sourcecode beilagen. Eines davon war ein Generator für Primzahlen. Irgendwann hatte mir ein Bekannter geholfen, diesen Generator so auszubauen, dass er etwas flexibler mit den Start- und Endwerten war. Ein Riesen Nachteil von QBASIC zu dem etwas grösseren und kostenpflichtigen Quickbasic war, dass es keinen Compiler besass um aus dem Code einen direkten für die DOS-Shell ausführbaren Maschienencode zu erzeugen. Das erstellte Programm kann nur im BASIC-Interpreter selbst ausgeführt werden. Und so habe ich QBASIC und den Primzahlgenerator über die Zeit bis heute auf allen meinen Computerplattformen mit dem DOS-Emulator DOSBox mitgeschleift.

Neulich kam ich aber dann doch mal auf die Idee, dass man den Generator mit einer populäreren Sprache auf eine aktuelle Plattform implementiert. Der Hauptbewegpunkt dabei ist, dass der Generator so direkt die Rechenleistung des Computer nutzen kann und nicht noch eine Emulationsebene zwischen Programm und Hardware die ganze Geschichte ausbremst. Kurzum: so arbeitet er viel schneller.
Interessant war aber dann doch die Möglichkeit, welche Compiler und IDE’s es so gibt, die mit dem Q(uick)BASIC-Dialekt noch zurechtkommen und so ein Kompilat für ein aktuelles Mac OS, Linux oder Windows erstellen können. Hier bin ich mit QB64 fündig geworden. Es läuft auf allen diesen Plattformen, zuzüglich der Android-Plattform für Mobilgeräten.

Aber vielleicht werde ich mich dennoch mal hinsetzen und den Generator in einer aktuellen und populäreren Sprach wie zum Beispiel C, Erlang oder Python neu implementieren. Wobei letzteres nicht so toll performen wird, da Python eine Interpretersprache ist. Obwohl ich mir sicher bin, dass es da bereits Lösungen gibt.

Anbei hier der Sourcecode des Generator in QBASIC