Weiter zum Inhalt

Ansible Dokumentation bauen

Ich hinterlasse das einfach mal hier, damit ich beim nächsten Mal nicht wieder ewig suchen muss…
Aktuell nutze ich die Zeit in der Bahn zur Arbeit dafür endlich mal meinen Server via Ansible zu konfigurieren. Da der Empfang, nun ja, durchwachsen ist, war ich auf der Suche nach einer Offlineversion der Dokumentation. Und die Antwort ist wieder einfacher als man so glaubt:

Hier sind die simplen Schritte (auf einem Ubuntu Rechner – Mac sollte ähnlich sein. Windows -> viel Glück!):

  1. Erstelle einen Clone des Ansible Repository:
    git clone git@github.com:ansible/ansible.git
  2. Stelle sicher das Sphinx installiert ist:
    sudo pip install sphinx
  3. Und bauen lassen:
    cd ansible; make webdocs

Synology SSH mit Keys

Da sass ich wieder und versuchte auf meinem Synology mich mittels meines SSH Schlüssels zu authentifizieren. Irgendwie funktionierte das nicht so recht, aber die Lösung war, wie so oft, simpler als gedacht. Und in der Hoffnung anderen Leidensgenossen etwas Zeit zu ersparen, hier sind die wenigen Schritte die wirklich benötigt sind:

  1. Aktiviere SSH auf dem Synology. Die Einstellung ist im Kontrollzentrum unter „Terminal & SNMP“
  2. Du benötigst einen Nutzer in der Gruppe „administrators“ – erstelle einen Neuen oder editiere einen bestehenden.

Mit diesen einfachen Schritten ist SSH schon mal einmal aktiviert, jetzt zum interessanten Teil. Logge Dich mit dem Nutzer ein, der jetzt in der Gruppe administrators ist. Ich nutze den folgenden Befehl dafür:

# Ersetze user und 192.168.1.200 mit Deinen richtigen Werten
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@192.168.1.200

Das Passwort ist das Selbe wie für die Weboberfläche. Als nächstes Erstellen wir das benötigte .ssh Verzeichnis:

mkdir .ssh
chmod 700 .ssh

Nun ist es Zeit Deinen öffentlichen SSH Schlüssel zu hinterlegen. Kopiere diesen in die Datei .ssh/authorized_keys. Was jetzt noch übrig ist ist der Punkt, der mich fast wahnsinnig gemacht hat. authorized_keys benötigt die richtigen Zugriffsrechte – das ist der einfache Teil. Aber das Heimatverzeichnis des Nutzers ist zu offen. Und das war der Knackpunkt. Also bringen wir die Rechte in Ordnung:

chmod 600 .ssh/authorized_keys
chmod 750 .

Voila, ab jetzt funktioniert der SSH Schlüssel.

Caddy und Spring Boot

Ich bin gerade dabei an diversen kleinen Spielprojekten zu arbeiten. Jedes davon nutzt Spring Boot für die Serverseite.

Nun begab es sich, dass ich ein statisches Bilderverzeichnis brauchte – also wenn ich http://localhost/images/my-image.jpg eingebe, soll das Bild erscheinen. Und faul wie ich bin sollte es nicht extra Code benötigen. Nichts leichter als das.
Ein nettes Tool, welches ich schon länger auf dem Radar habe, kommt da genau richtig: Caddy. Zum Einen ist es eine interessante Alternative für alle Nutzer, die „einfach“ SSL gesicherte Seiten ins Netz bringen wollen – egal ob internes oder internationales Netz. Zum Anderen ist es aber auch extrem simpel zu konfigurieren und bringt ein Proxymodul gleich mit.
Also Caddy herunter geladen und folgende kleine Konfigurationsdatei geschrieben:

localhost:80 {
	gzip
	proxy / localhost:8080 {
	  except /images
	  proxy_header X-Forwarded-Proto {scheme}
          proxy_header X-Forwarded-For {host}
          proxy_header Host {host}
	}
}

localhost:80/images {
  root /tmp
  gzip
}

Und damit habe ich spontan sowohl meine Spring Boot Applikation via http://localhost verfügbar als auch meine Bilder.

Kleine Randnotiz: Interessanterweise benötigt die proxy Anweisung die proxy_header Direktiven, da sonst Redirects von Spring MVC via redirect:/target einfach auf http://localhost:8080/target weiterleiten würden.

Von jetzt an sollst Du genannt werden Brian – was soviel heiß wie Brian – Git Branch Version

Und wieder eine kleine Notiz für mich und vielleicht dem Einen oder anderen da draussen.

In meinem aktuellen Projekt gibt es einen recht gut funktionierenden Prozess um Pull Requests in die firmen-weite Code Basis unsere DevOps zu bekommen. Wir erstellen Branches welche als Namen eine Ticket-ID bekommen. Diese ID wird von Jira erzeugt. Nun, genau das ist der aktuelle Schwachpunkt. Sobald ich ein neues Ticket erstelle, schauen unsere fleissigen DevOps auch direkt rein. Also erzeuge ich erst einen Branch, nenne ihn sinnvoll – zum Beispiel „brian“ – und sobald meine Änderungen reif für die grosse, weite Welt sind, erstelle ich das Jira Ticket.

Nun muss ich aber einen bestehenden Branch umbenennen. Entweder nur lokal oder auch remote. Und das geht, wie immer, so simpel, dass ich es sicher bis zum nächsten Mal vergessen habe.

Lokal geht das Umbenennen mittels:

 git branch -m <old-name> <new-name> 

Oder, wenn ihr bereits den Branch ausgecheckt habt:

 git branch -m <new-name> 

Bleibt noch der Fall, dass der Branch auch remote gelöscht werden soll. Der „Trick“ ist, den umbenannten Branch zum Remote zu senden und den alten Branch zu löschen. Also:

# Push branch with new name
git push -u origin <new-name>
# Delete branch with old name
git push origin :<old-name>

Und schon hat (der Branch) Brian einen neuen Namen, aber bedeutet immer noch so viel wie Brian 🙂

Wie man die Liste der Remote Git Branches aufräumt

GitGerade bin ich über eine kleine aber durchaus interessante Problematik gestolpert. Ich liebe Git und nutze es eigentlich überall. Auch bin ich ein grosser Fan von Git Flow als Branching Model und habe damit einige Branches, die so in der Welt herum geistern. Und genau damit hatte ich gerade die folgende Szenerie:

Einer meiner Branches, genannt feature/rest-fronted-get-users, existierte sowohl in meinem Remote als auch auf zwei meiner Rechner. Nachdem das Feature fertig implementiert war, wurde alles aus dem Branch in meinen develop integriert und sowohl lokal auf Rechner A als auch vom Remote gelöscht. Aber da gab es ja noch meinen zweiten Rechner, Rechner B. Der kannte den Branch noch, war lokal sogar noch darauf „geeicht“.

Das Wechseln in den develop Branch ist ja mit

git checkout develop

kein Problem. Aber Git glaubte immer noch den Branch auf dem Remote zu sehen.

Die Lösung ist, wie so oft mit Git, extrem simpel. So simpel, dass ich sie bestimmt wieder sofort vergesse. Also schreibe ich sie hier einfach nieder. Und wer weiß, vielleicht hilft es ja dem Einen oder Anderen auch weiter.

Und hier ist sie: Einfach im lokalen Git Repository folgende Befehle ausführen:

git branch -d feature/rest-frontend-get-users
git remote prune origin

Der erste Befehl löscht den Branch lokal. Und der Zweite räumt dann (u.a.) die Liste der Branches auf.

MongoDB Frühling im Boot

MongoDB Logo

Es ist endlich soweit, ein Projekt in dem ich MongoDB produktiv einsetzen kann. Und wie es der Zufall will, ist MongoDB 3.0 mittlerweile stabil und damit erste Wahl für eine frische Installation.

Mit der neuen Version wechselt MongoDB das user model von MONGODB-CR zu SCRAM-SHA-1 (siehe auch Security Changes). Eigentlich alles ganz easy, oder?
Spring Logo

Nun, ist es auch tatsächlich, wenn man die neuesten Java MongoDB Treiber nutzen kann. Was aber wenn das Projekt auf dem wundervollen Spring Boot basiert und MongoDB „nur“ über Spring Data MongoDB als einfacher Persistenzcontainer genutzt wird? Nun, dann bekommt mein ein Problem. Denn die Authentifikation wird dann nicht so einfach funktionieren.

Aber keine Angst, wir können einen kleinen Workaround nutzen um dennoch ans Ziel – eine Spring Boot / Spring Data MongoDB Anwendung die MongoDB mit aktiver Authentifikation nutzt – zu kommen. Dieser Workaround wird im Mongo DB Jira in einem Kommentar zum Issue SERVER-17459 aufgezeigt. Mit MongoDB 3.0 wird zwar das alte user model aus Version 2.4 pensioniert (authSchema = 2), aber das user model mit authSchema = 3 wird weiterhin unterstützt.

Kommen wir also endlich zum praktischen Teil.  Wie kann ich mit meiner Spring Boot basierten Java-Anwendung nun MongoDB 3 mit aktiver Au­then­ti­fi­ka­ti­on nutzen? Nun, zuerst installieren wir die aktuellste Version. Auf einem Ubuntu Server zum Beispiel mittels

sudo apt-get install mongodb-org

Die Installation sollte mit einer gestarteten MongoDB Instanz enden. Zu dieser verbinden wir uns mittels der mit-installierten Shell:

mongo localhost/admin

und führen folgenden Befehl aus:

db.system.version.save({"_id" : "authSchema", "currentVersion": 3})

Was wir jetzt noch brauchen ist ein Nutzer, mit dem wir den Rest später konfigurieren können. Dafür brauchen wir nur folgenden Befehl ausführen (in der admin Datenbank und mit einem richtigen Password anstatt <PUT REALLY SECURE PASSWORD HERE>):

db.createUser( {
 user: "siteRootAdmin",
 pwd: "<PUT REALLY SECURE PASSWORD HERE>",
 roles: [ "root" ]
 });

Das war es schon an Vorbereitung. Wir können nun die Au­then­ti­fi­ka­ti­on in der Konfigurationsdatei /etc/mongod.conf aktivieren:

#noauth=true
auth=true

und den Service neu starten:

sudo service mongod restart

Von nun an muss man sich mit einem Nutzer gegenüber der MongoDB authentifizieren. Für die Shell geht das so:

mongo --username admin --password <THE PASSWORD YOU CHOSE EARLIER>

Für unsere Spring Applikation können wir folgende Zeile in den application.properties setzen:

spring.data.mongodb.uri=mongodb://admin:<THE PASSWORD YOU CHOSE EARLIER>@localhost:27017

natürlich wieder mit <THE PASSWORD YOU CHOSE EARLIER> mit dem richtigen Passwort ersetzt.

Zu guter Letzt noch der (offensichtliche) Hinweis: Es ist absolut nicht ratsam den Nutzer mit der uneingeschränkten root Rolle für die Webapplikation zu nutzen. MongoDB bietet eine nette Dokumentation zum Thema Nutzermanagement an. Da lohnt sich das Lesen und Umsetzen.

 

Sehen, was die MySQL DB gerade tut

Ich bin gerade dabei ip2nation in meine MySQL Instanz zu importieren. Dabei handelt es sich um ein Mapping von IP Adressen auf Länder, was von einem WordPress Plugin für das Amazon Affiliate Programm benötigt wird, welches ich gerade ausprobieren möchte.

Aber das ist es eigentlich nicht, worüber ich kurz schreiben wollte. Die Daten von ip2nation sind in einem rund 4 MB großen SQL File abgelegt, welches ich in meine MySQL laden will. Dies dauert aktuell etwas länger, was mir komisch vorkam. Also wollte ich wissen, ob und was meine Datenbank denn da so treibt. Im Großen und Ganzen wollte ich eine topartige Auskunft bekommen. Und siehe da, genau so etwas gibt es auch. Das Tool heißt mytop und ist unter Debian bzw. Ubuntu mittels

sudo apt-get install mytop

auch fix installiert. Und danach kann man schön sehen, was die Datenbank denn so treibt:

mytop Screenshot

 

Viel Spass beim Datenbank stalken 😉

 

Eine weitere Alternative zu DynDNS und No-IP

Wie vor kurzem berichtet hat DynDns mittlerweile den kostenlosen Dienst eingestellt. Viele sind dabei zum Beispiel zu No-IP gewechselt, auch ich hatte das damals ja kurz empfohlen.
Nun gab es in den letzten Tagen einiges an Wirbel um No-IP und Domains, die von Microsoft kurzfristig übernommen wurden. Mein geschätzter Blogger-Kollege Caschy hat dazu zum Beispiele was geschrieben, und noch was und noch mal was.

Jetzt herrscht im Netz ja bekanntermaßen ein reges Treiben und es gibt noch mehr Dienste, die sich der geneigte Selbst-Hoster einmal anschauen könnte. Und einer von diesen Diensten ist FreeDNS von afraid.org.
Urpsrünglich wurde ich auf den Dienst aufmerksam, als er im Chaosradio 199 erwähnt wurde. Das tolle daran: Ihr könnt hier sogar auf eine Domain, die ihr besitzt, Services setzen, die eine dynamische IP nutzen müssen.

Ich habe das einmal für eine von meinen Domains ausprobiert.
Meine Domains liegen alle bei InternetX – hier nutze ich ebenfalls die DNS Server des Unternehmens und habe volle Kontrolle über die DNS Einträge. Denn für das, was wir hier vor haben, sind so genannte NS Einträge notwendig. Dafür muss man natürlich nicht unbedingt Kunde bei InternetX sein – aber viele Anbieter (z.B. 1&1) ermöglichen nur das konfigurieren von A und AAAA Einträgen.
Ok, Du kannst also einen NS Eintrag konfigurieren. Sehr gut, denn davon brauchen wir jetzt 4. Diese Einträge müssen auf folgende Nameserver von FreeDNS zeigen:

  • NS1.AFRAID.ORG.
  • NS2.AFRAID.ORG.
  • NS3.AFRAID.ORG.
  • NS4.AFRAID.ORG.

Natürlich muss auf der FreeDNS Seite die entsprechende (Sub-)Domain angemeldet sein. Meine Subdomain „testdyn“ habe ich daher über den Eintrag „Subdomains“ hinterlegt und anschliessend eine feste IPv6 Adresse ergeben. Denn diese ändert sich dank meines SixXS Tunnels  nicht.

Um nun die IPv4, die dank der in Deutschland üblichen Zwangstrennung alle 24 Stunden wechselt, regelmäßig zu aktualisieren, nutze ich eine URL, die ich über den Menüeintrag „Dynamic DNS“ einsehen kann. Hier kann ich sowohl für IPv4 (A-Record) als auch für IPv6 (AAAA-Record) die URL, ein curl Beispiel und ein wget Beispiel ansehen.

Auf meinem RaspberryPi habe ich dafür einen Crontab über

crontab -e

angelegt und nutze wget für den URL Aufruf. Wie wget mit welchen Parametern aufgerufen werden muss, dass findet ihr direkt in der oben beschriebenen Stelle auf der FreeDNS Seite. Bei mir sieht der Crontab Eintrag wie folgt aus:

* */2 * * * wget -O - [meine FreeDNS Direct URL] >> /tmp/freedns-ipv4.log 2>&1 &

Das die URL einen geheimen Code erhält, der genau meine Domain, die ich aktualisieren will, identifiziert, habe ich einmal einen Platzhalter – nämlich [meine FreeDNS Direct URL] benutzt. Ihr solltet die URL auch niemanden geben, also immer schön aufpassen 😉

Mit dem obigen Crontab Eintrag ruft mein RPi nun alle 2 Stunden die geheime URL auf und schreibt alle Ausgaben in die Datei /tmp/freedns-ipv4.log. Natürlich würde es reichen, die URL kurz nach der geplanten Trennung aufzurufen (meine FritzBox kappt zu einer definierten Zeit einfach die Verbindung, so habe ich halbwegs Kontrolle darüber, wann es passiert). Aber bei potenziellen Störungen, wie zum Beispiel Stromausfall, wäre es schon ganz gut, wenn der RPi innerhalb eines überschaubaren Zeitrahmens mal wieder die IP meldet.

Neben der Möglichkeit, eigene Domains zu „dynamisieren“, kann bei FreeDNS aus einer Reihe von frei zur Verfügung stehenden Domains gewählt werden. Aber auch andere DNS Dienste sind hier zu finden. So kann zum Beispiel ein FreeDNS Account auch für IPv6 Reverse DNS Einträge genutzt werden. Da bin ich gerade dabei, dass einmal auszuprobieren.

Viel Spass beim Ausprobieren 😀

Review von „Building an Application with CoffeeScript“

3675OS_VideoLange hat es gedauert, aber wie hier schon mal angedeutet, habe ich ja nicht nur das Video-Tutorial „Building Hadoop Clusters“ zum Review erhalten, sondern auch „Building an Application with CoffeeScript“. Und da möchte ich euch jetzt nicht länger darauf warten lassen…

Das Video-Training ist wieder in 8 Kapitel aufgebaut. Der Autor Darko Bozhinovski führt dabei in jeweils 3 Videos pro Kapitel nach und nach in CoffeeScript ein. Sehr angenehm ist, dass Darko in seinem GitHub Account ein Projekt zum Training zur Verfügung stellt. Darin finden sich die Sourcen, organisiert nach Kapitel und ein leeres Projektgerüst, um die Schritte und empfohlenen Übungen einfacher mit machen zu können.

Neben diesen zusätzlichen Materialien verweist Darko auch auf verschiedene, oft sogar in den Video-Kommentaren verlinkten, Webseiten mit weiterführenden Informationen. So gibt er mit js2coffee.org ein nützliches Tool an die Hand, verweist aber auch auf Webauftritte wie html5rocks.com.
Zu diesen Web-Tipps gesellen sich Hinweise und Beispiele zur objektorientierten Entwicklung mit CoffeeScript, dem MVC Pattern und auch Tipps für den Blick über den Tellerrand, um zum Beispiel ein geeignetes Web-Routing JavaScript zu finden (im Tutorial wird auf die Seite microjs.com zum Recherchieren verwiesen).

Alles in allem macht es also technisch Spass dem Training zu folgen. Allerdings ist dem Tutorial teilweise schwer zu folgen, das Darko doch mit einem starken Akzent spricht und, beispielsweise im Video 2 des 2. Kapitels, auch die Aufnahmetechnik wohl geschwächelt hat (es klingt sehr dunpf und entfernt).

Zusammenfassend – also sowohl technisch als auch vom „drumherum“ – kann ich aber durchaus zu diesem Video raten. Darko zeigt, dass er mit dem Thema seit langer Zeit zu tun hat und er verweist immer wieder auf Best Practices und geht auf aktuelle Technologien wie HTML 5 und LocalStorage (und auch, warum er keine alternative lokale Speichertechnologie gewählt hat) ein.

PacktPub wird 10

Anlässlich von PacktPub’s 10 jährigen Jubiläum bekommt ihr alle Videos und Bücher für nur 10 Dollar. Ihr wollt stöbern? Dann hier entlang.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close