bytelude

Crashplan auf Windows Homeserver (WHS) installieren

Seit langem bin ich auf der Suche nach einer Off-Site Backup Lösung, die preislich noch im Rahmen ist, aber gleichzeitig auch relativ große Datenmengen erlaubt. Letzteres ist bei nahezu allen “einfachen” Diensten wie Dropbox, OneDrive, iCloud usw. nicht gegeben, da dort eher im Bereich GB bis wenige TB gearbeitet wird. Als Fotograf mit sehr vielen und leider auch sehr großen RAW Files stoße ich da relativ schnell an die Grenzen. Hinzu kommt die Einschränkung, dass ich meine Daten auf einem Windows Homeserver liegen habe, der auch gleichzeitig das zentrale Backup übernehmen soll. Mit Crashplan bin ich fündig geworden – es gibt einen “unlimit” Backup für 60€ im Jahr – und der Client läuft auch unter Windows Homeserver. Andere Anbieter blockieren sofort, wenn sie merken, dass der Client auf einer “Serverversion” von Windows läuft. Crashplan glücklicherweise nicht.

Zurück zum Thema. Ich hab den Client installiert und es passiert nichts. Der Dienst besteht aus zwei Teilen: einer Backup Engine und der Gui. Die Gui sagte mir einfach nur, dass sie die Backup Engine nicht finden könne. Ein Blick in den Dienste Manager von Windows zeigte mir, dass der Service auch nicht lief. Wenn man ihn starten wollte, kam nur die Meldung, dass der Dienst “gestartet und anschließend gleich wieder gestoppt/pausiert wurde. Keine weiteren Hinweise oder Logs. Nach etwas Recherche im Netz fand ich zumindest Hinweise, dass es wohl Probleme mit den Portbelegungen gibt – aber bei mir wollte ja der Dienst nicht mal starten. Die Lösung war dann doch etwas simpel: Der Client verbraucht per Default mittlerweile 1GB Ram – und das hat mein Acer Aspire easyStore H340 mit seinen 2GB Ram scheinbar nicht mehr übrig. Also editiert man in der Datei “c:\Programme\CrashPlan\CrashPlanService.ini” die Zeile mit den Java Virtual Machine Parameters:

von

-Xmx1024M

-Xmx512M

Und schon läuft der Service, sobald man ihn nochmal startet. Aber der Client wollte noch immer nicht – und da kam die eben genannte Port Problematik zum Vorschein. Um dies nachvollziehen zu können, ruft man die Command Shell von Windows auf und gibt da folgendes ein:

netstat -ona

Bildschirmfoto 2016-05-08 um 14.28.37 Kopie

Wie man sieht, lauscht die Backup Engine auf Port 4242, der Port im Client ist per Default jedoch 4243. Wenn man nun in der Datei “c:\Programme\CrashPlan\conf\ui.properties” die folgende Zeile editiert, läuft es:

#servicePort=4243

servicePort=4242

Abschließend startet man nun den Client und wird endlich von der Crashplan Oberfläche empfangen 😉

[Quicktip] Sudoers Zugriffsrechte in Mac OSX zurücksetzen

Da ich eben an der Provisionierung eines Macs via Ansible gespielt habe und dabei aus Versehen einen Syntax Error in der Datei /etc/sudoers drin hatte, war ich in der Falle. Ich konnte die Datei nicht mehr bearbeiten, weil ich nicht die nötigen Zugriffsrechte hatte, und sudo konnte ich auch nicht verwenden, weil ja ein Syntax Error drin war.

Die Lösung des Problems ist dann doch sehr leicht: Man öffnet den Finder, drückt “CMD + Shift + G” und trägt in das nun erscheinende Textfeld einfach “/etc” ein. Dann gelangt man in den im Finder versteckten Ordner und kann dort die Datei “sudoers” finden. Mit einem Rechtsklick auf die Datei kann man den Punkt “Informationen” aufrufen.

dateirechte

Dort im untersten Bereich “Freigabe & Zugriffsrechte” kann man die Dateirechte wieder korrekt setzen bzw. Schreibrechte für jedermann ermöglichen (vorher rechts unten auf das Schloss klicken und den Bereich damit entsperren). Nun kann man den/die Fehler in der sudoers korrigieren, anschließend die Schreibrechte wieder zurücksetzen und schon funktioniert sudo wieder.

[Quicktip] Macbook erkennt Thunderbold Ethernet Adapter nicht richtig

Sollte euer Mac den Thunderbold-Ethernet Adapter nicht erkennen bzw. sich über “Kabel nicht angeschlossen” beschweren (selbst nach einem Neustart), dann probiert mal folgendes aus:

Systemeinstellungen -> Netzwerk und dort den Thunderbold Adapter in der linken Spalte auswählen. Anschließend den Button “weitere Optionen” auswählen und dann zum Tab “Hardware” wechseln.

Hier sollte euch die Mac Adresse des Adapters angezeigt werden. Ist dies nicht der Fall, dann ist der Adapter wahrscheinlich hinüber. Wenn die Mac Adresse angezeigt wird, dann stellt das Dropdown “Konfiguration” auf “manuell” und bei “Geschwindigkeit” auf “automatisch”.

Speichert das ganze und wartet kurz ab, dann sollte der Adapter das eingesteckte Netzwerkkabel wieder korrekt erkennen. Evtl. könnt ihr mit dem Abziehen und anschließendem erneuten Einstecken des Adapters etwas nachhelfen.

Jenkins OSX Slave für das automatisierte Bauen von iOS Apps

Die Aufgabe ist simpel: ich möchte in meine Jenkins Build Umgebung einen Rechner mit Mac OSX einbinden, der für mich automatisiert iOS Apps bauen soll. Für die Vereinfachung verwende ich dazu das xctool von Facebook, welches das Handling von XCode und co. übernimmt.

Mein Vorgehen war folgendes: Jenkins User auf dem Zielsystem eingerichtet und anschließend den Jenkins Slave per ssh vom Master aus gestartet. Das funktioniert auch alles wunderbar, aber sobald man im Build versucht auf eine Gui Applikation zuzugreifen – das macht z.B. der Aufruf der Unit Tests, weil diese den iPhone Simulator benötigen – knallt xctool ohne eine Fehlermeldung mit einem Exit Code 1 weg. Das Problem an der Stelle ist einfach, dass es in OSX einen Unterschied macht, ob man ein Programm per ssh oder direkt in einer Shell auf dem System startet. Die Variante über ssh darf eben nicht auf GUI Applikationen zugreifen. Und somit laufen die Tests nicht.

Korrekterweise muss man den Jenkins Slave als per JNLP starten. Dazu stellt man im Master in den Slave Einstellungen die „Startmethode“ auf „Starte Slave Agenten über JNLP“. Nach dem Speichern wir einem in der Übersicht des Knotens ein Shell Command angezeigt, den man auf dem Slave ausführen soll:

java -jar slave.jar -jnlpUrl http://[PFAD_ZUM_JENKINS_MASTER]/computer/[SLAVE_NAME]/slave-agent.jnlp -secret [SECRET_HASH]

In diesem Command ist die Datei „slave.jar“ verlinkt und kann heruntergeladen werden. Genau das sollte man auf dem OSX Slave machen und die Datei irgendwo auf der Platte ablegen. Anschließen startet man das Programm „Automator“. Dort wählt man „Applikation“ aus und sucht anschließend in der Bibliothek nach „Shell Script ausführen“. Diesen Eintrag zieht man rechts in die graue Fläche.

In das nun vorhandene Textfeld trägt man folgendes Shellscript ein:

cd [PFAD_ZUR_JAR_DATEI]
java -jar slave.jar -jnlpUrl http://[PFAD_ZUM_JENKINS_MASTER]/computer/[SLAVE_NAME]/slave-agent.jnlp -secret [SECRET_HASH]

Das ganze speichert ihr im Ordner Programme als „run_jenkins_slave“ ab. Nun geht ihr in die „Systemeinstellungen” -> “Benutzer und Gruppen“ und wählt bei Jenkins die „Startobjekte“ aus. Dort fügt ihr nun das eben erstellte Programm „run_jenkins_slave“ hinzu. Anschließend geht ihr noch auf „Anmeldeoptionen“ und stellt da den User „Jenkins“ für den automatischen Login ein.

Wenn ihr nun den OSX Rechner neu startet, dann sollte er automatisch einen Jenkins Slave starten und diesen beim Master registrieren. Nun sind wir genauso weit wie mit dem ssh Weg – aber: wenn man nun Jobs startet, dann dürfen diese auch auf GUI Applikationen zugreifen. Sprich, die Unit Tests mit dem iPhone Simulator laufen nun ohne Probleme durch. Der Jenkins Slave verhält sich in etwa so, als ob man direkt auf dem Desktop eine Shell startet und dann Befehle ausführt.

[Quicktip] Adobe Photoshop Lightroom 6 / CC stürzt in OSX direkt beim Start ab

Nachdem ich mich sehr auf das neue Lightroom Update über die Creative Cloud gefreut hatte, war die Ernüchterung sehr schnell da: Die App stürzt immer kurz nach dem Start ab. Zunächst wurde mein Katalog ohne Probleme konvertiert, dann kam der Lightroom Splashscreen und kurz danach erschien der Apple Crashreport. Dieser enthielt folgende Meldung:

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000348

Der Fehler tritt bei jedem Start von Lightroom auf. Da Adobe bisher noch keinen Fix für das Problem bereit gestellt hat, möchte ich hier zumindest einen Workaround zeigen:

Startet Lightroom mit gedrückter Alt Taste, sodass der Auswahldialog für den zu öffnenden Katalog erscheint. In diesem Dialog wählt ihr einfach euren bestehenden Katalog und klickt auf „öffnen“. Nun sollte Lightroom wie gewohnt laufen. Sollte das auch nicht funktionieren, erstellt über den Dialog einen neuen Katalog, öffnet diesen und klickt dann direkt in Lightroom auf Datei – „Katalog öffnen“ und wählt da euren „alten“ Katalog aus.

[Quicktip] Jenkins meckert mit einem reject HostKey trotz korrektem Eintrag in der known_hosts Datei

Ihr möchtet mit Jenkins auf einen anderen Server per ssh/scp zugreifen, habt auf der Shell bereits erfolgreich mit dem User Jenkins eine ssh Verbindung aufbauen können, aber im Build Prozess bekommt ihr folgenden Fehler:

com.jcraft.jsch.JSchException: reject HostKey: ...

Das Problem ist relativ simpel zu lösen – die Einträge in der ~/.ssh/known_hosts dürfen nicht verschlüsselt sein. Lösen könnt ihr das folgendermaßen:
– alten Hosts Eintrag löschen: ssh-keygen -R [SERVER_NAME]
– in eurer ssh_config den Parameter „HashKnownHosts“ auf “no” setzen
– per ssh auf den Server eine Verbindung aufbauen und die Frage, ob der Key hinzugefügt werden darf, mit ja beantworten

Nun sollte der Eintrag im Klartext in der known_hosts stehen und Jenkins sollte die Verbindung aufbauen können.

[Quicktip] Jenkins baut bereits gelöschte git Branches

Besonders wenn man einen Jenkins Job nicht auf einen bestimmten Branch einschränkt wird man dieses Problem schnell bemerken: Jenkins baut in bestimmten Fällen auf Basis von git Branches, die eigentlich bereits gelöscht sind. Der Fehler tritt auf, weil Jenkins per default das lokale git Repository nicht mit dem Origin bezüglich gelöschter Branches synchronisiert.

Dieses Problem kann man relativ einfach beheben. Dazu geht ihr in die Konfiguration des betroffenen Jenkins Job und im Bereich “Source-Code-Management“ wählt ihr im Dropdown “Additional Behaviours“ den Punkt “Prune stale remote-tracking branches“. Damit wird vor dem Pull bzw. Fetch genau dieser Sync durchgeführt. Sprich, es werden lokal alle Branches gelöscht, die im Origin nicht mehr vorhanden sind.

Wie man in der Owncloud Gallery App die natürliche Sortierung von Dateien aktiviert

Owncloud hat mich wirklich von Anfang an begeistert – genauso gut wie Dropbox, aber auf dem eigenen Server. Die Clients auf den Rechnern arbeiten zuverlässig und tun genau, was sie sollen. Die mobilen Clients sind noch etwas verbesserungswürdig, die Owncloud Web Applikation hingegen ist schon ziemlich gut. Besonders gefallen hat mir die Gallery App, die Foto Ordner in schöne Galerien umwandelt. Sie hat aber ein gravierendes Problem: die Sortierung.

Meine Dateinamen in einem Ordner heißen beispielsweise:

Bild-1.jpg
Bild-2.jpg
Bild-3.jpg
…
Bild-10.jpg
…
Bild-20.jpg
…
Bild-100.jpg

In der Owncloud Datelliste werden sie auch so korrekt aufgelistet, in der Gallery App passiert jedoch folgendes:

Bild-1.jpg
Bild-10.jpg
Bild-100.jpg
…
Bild-2.jpg
Bild-20.jpg
Bild-3.jpg

Dieses Verhalten ist auf eine Javascript Funktion zurückzuführen und kann relativ einfach korrigiert werden. Editiert dazu einfach die Datei “apps/gallery/js/gallery.js”. Sucht nach der Zeile:

Gallery.fillAlbums = function () {
	var sortFunction = function (a, b) {
		return a.path.toLowerCase().localeCompare(b.path.toLowerCase());
	};

und ändert diese in

Gallery.fillAlbums = function () {
	var sortFunction = function (a, b) {
		return a.path.toLowerCase().localeCompare(b.path.toLowerCase(), 'de', {numeric: true});
	};

Und schon ist die Sortierung wieder so, wie erwartet.

[Quicktip] Wie man go get und Atlasssian Stash bzw. Gitlab zusammen bringt

In meiner Tätigkeit als Jenkins Admin hat mir das Thema „go get“ und Stash viel Kopfzerbrechen bereitet. Letztendlich ist „go get“ eine Art Alias für git pull, jedoch wird da einige Magic angewendet. Im Normalfall – also mit github und auch plain git Repos funktioniert das ganze wunderbar, sobald man aber Software wie Gitlab oder Stash verwendet, wird es etwas problematisch. Zum einen ist das „.git“, welches sowohl Gitlab als auch Stash an jedes Repo hängen ein Problem, zum anderen aber auch SSH über alternative Ports.

Zum Problem der „.git“ Endung: hängt einfach ein weiteres „.git“ an euren „go get“ Command. Also:

go get git.mydomain.com/foo/bar.git.git

Etwas kniffliger ist die Verwendung eines alternativen Ports und ssh. Stash macht nämlich genau das – der ssh Port ist 7999 in der Default Config. Aber auch hierfür gibt es eine Lösung. Dazu müsst ihr die Datei „.gitconfig“ in eurem Home Folder editieren bzw. anlegen. Die Datei muss dann so aussehen:

[url "ssh://git@stash.yourdomain.com:7999/"]
insteadOf = https://stash.yourdomain.de/

Sobald ihr nun einen Checkout auf

https://stash.yourdomain.de/foo/bar.git

macht, biegt Git diesen Request auf

ssh://git@stash.yourdomain.com:7999/foo/bar.git

um. Somit könnt ihr auf andere Ports gehen, komplett auf andere Domains umschreiben usw.

[Quicktip] Wie installiere ich ein CA Zertifikat unter Debian Linux

Wenn ihr ein CA Zertifikat bzw. das zugehörige pem File auf eurem Debian Linux installieren möchtet, dann sind folgende Schritte nötig:

pem File unter /usr/share/ca-certificates ablegen
Datei /etc/ca-certificates.conf editieren und um den gerade hinzugefügten Dateinamen ergänzen. Falls ihr die Datei direkt in /usr/share/ca-certificates hinterlegt habt, dann reicht [Dateiname].pem, wenn ihr einen Unterordner erzeugt habt, dann ist der Eintrag [Unterordner]/[Dateiname].pem
als root bzw. per sudo “update-ca-certificates“ ausführen. Dort sollte euch gemeldet werden, dass mindestens ein Eintrag hinzugefügt wurde
fertig 😉