Hin und wieder sollen die Seiten die man baut ja auch gut aussehen. Damit auch wir normalentwicklerfredels dabei zumindest nicht gegen alle Regeln des guten Geschmacks verstossen gibt es http://hackdesign.org/ .
Anmelden – mitmachen – schlau werden.

Das ist ja ein Ding. Da hab ich mir nach Anraten von meinem Lieblings-Concurrent-Version-Provider github deren Client für den Mac installiert (und für mich als unbrauchbar wieder gefeuert) um dann bei den durch github für Mac geklonte Repositories fortwährend nach Benutzer und Kennwort gefragt zu werden … *narf*.

Woran liegts?

Der Grund ist recht einfach. Github für Mac stellt das geklonte Repository auf Protokoll https um – und da geht nur Benutzer Kennwort.

Und wie stellt man es wieder um?

Am Besten schaut man erstmal nach ob das wirklich der Grund ist. (Das vorher geprüft wird, ob ssh korrekt konfiguriert ist setze ich mal voraus)
Ein cat ~/.ssh/config schafft hier Sicherheit. Wenn man hier einen Eintrag a la
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = https://github.com/gunnarmagholder/Repo.git
findet hat man den Übeltäter.

Abhilfe schafft hier dann ein
git config remote.origin.url git@github.com:your_username/your_project.git
also in meinem Falle ein

git config remote.origin.url git@github.com:gunnarmagholder/Repo.git

Nun sollte es mit dem git pull etc. auch wieder ohne Kennwort klappen.

Viel Spass!

Backgroundrb ist schon eine tolle Sache. Man kann lang laufende Jobs an diesen Job Server übergeben und Mailinglisten, Reportjobs oder ähnliches blockieren nicht die tägliche Arbeit.

Das Problem an einer Hintergrundverarbeitung ist nun aber dass sie .. naja.. im Hintergrund läuft. Zwar kann man mit einem einfachen backgroundrb status dem Jobserver auf die Finger schauen, aber das ewige Einloggen ist auf Dauer dann doch ein wenig unspannend.

Aus diesem Grund habe ich das folgende Skript zusammengezimmer. Es prüft ob der backgroundrb läuft und schmeisst im Fehlerfall eine Email heraus bzw. startet den Job gleich neu. Kann man natürlich alles mit Nagios, Monit und ähnlichen Lösungen auch ganz toll machen, aber manchmal braucht man halt eine schnelle und schmutzige Lösung.
#! /bin/bash
export PATH=/ruby/bin/:$PATH
/home/railsapp/apps/rails_app/current/script/backgroundrb status
status=$?
logger the status is $status
if [ $status -ne 0 ]; then
(echo "Der backgroundrb job ist deaktiv und wird neu gestartet") | mail -s "Backgroundrb failed" gunni@email.irgendwo
/home/railsapp/apps/rails_app/current/script/backgroundrb start
logger Restarting background RB
fi

Wie funktioniert das Ganze nun? In der ersten Zeile wird die bash shell gesetzt – kennt man hoffentlich.

Danach kommt etwas, was nötig sein kann (aber nicht muss). Wenn man auf einem Host mehrere Rubyversionen betreibt kann es sein, das diese Versionen nicht gleich dem Crond (also dem von mir genutzten Scheduler) zugänglich sind. Eine einfache Erweiterung des Pfades schafft hier Abhilfe. Ansonsten kann es eben sein, das in dem crond kein Ruby zur Verfügung steht (oder das falsche Ruby) was nervt.

Danach wird dann in der jeweiligen Rails Anwendung das Script backgroundrb ausgeführt. Der Parameter status liefert uns .. naja nun den Status zurück. Dieses sichere ich in der Variable $status.

Wenn der Inhalt der Variable $status nicht null ist ist irgendwas schiefgegangen. Also gibt es ne Email an den Admin und danach wird der Backgroundrb neu gestartet.

In “meiner” crontab (erreichbar mit crontab -e) sieht die Zeile dann so aus

0,15,30,45 * * * * /home/railsapp/apps/rails_app/scripts/check_backgroundrb

Wie man sieht habe ich das oben angegebene Script in das  Verzeichnis scripts meiner rails_app abgespeichert.

Die Ausgabe sieht dann im syslog so aus

Dec 31 16:45:01 www logger: the status is 3
Dec 31 16:45:08 www logger: Restarting background RB
Dec 31 17:00:02 www logger: the status is 0

Alles keine schwarze Kunst, aber es kann einem dann doch helfen. So und nun bereite ich mich auch auf 2013 vor (schaut mal aufs Datum)

Nun hab ich mal wieder meinen Emacs aktualisiert. Auf Emacs 24. Ging ganz leicht, aber ….

Beim Installieren eines meiner Lieblingstools (magit) kam es beim make zu folgendem Fehler:

Loading cl-extra...

In toplevel form:
magit.tmp.el:3462:19:Warning: reference to free variable
`magit--bisect-info-for-status'
magit.tmp.el:5805:1:Error: Symbol's function definition is void: declare-function
mv magit.tmp.elc magit.elc #NO_DIST
mv: rename magit.tmp.elc to magit.elc: No such file or directory
make: *** [magit.elc] Error 1

Der Fehler ist meiner Meinung nach ein reiner Mac OS X Fehler und liegt daran, das auf dem Mac ein Emacs in /usr/bin installiert ist, das mit den aktuellen Befehlen des magit nicht klar kommt.

Man kann aber dem Make per Parameter mitteilen, wo denn nun der “richtige” Emacs liegt (Bei mir in Applications), und der Befehl

make EMACS=/Applications/Emacs.app/Contents/MacOS/Emacs

schafft dann auch die gewünschte Abhilfe.

Viel Spass mit Emacs!

Heute habe ich versucht mit watchr eine Continous Integration Umgebung auf meinem Lion hochzuziehen und …. ES HAT NULL FUNKTIONIERT!

Kleine Nachforschung ergab, das die fsevent Maschine mit Lion erstmal nicht tut. Also ein
gem install rb-fsevent
mit anschliessendem
gem install watchr
und schon läuft sie Sache wieder.. gewusst wie.

Heute bin ich über einen eigentlich logischen, aber dennoch komischen Fehler gestossen. Ich wollte per Setup eine bestehende FIM 2010 verändern und bekam immer die Fehlermeldung, dass die Website oder Webanwendung nicht vorhanden ist.

Ein Griff in die alternativen Zugriffszuordnungen des SharePoint löste dieses Problem. Wie in den Best Practices vorgeschlagen habe ich http als Protokoll stillgelegt und nur https erlaubt; ein Umstand, den das Setup so gar nicht mag. Also schnell wieder http eintragen und es läuft wieder.

Um auf einer Office365 Umgebung eine Remote Powershell für das Online Exchange zu starten muss die folgende Befehlssequenz ausgeführt werden:

$LiveCred = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $LiveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

Viel Spass damit!!

Eben gerade haben Guido und ich versucht ein Problem anzugehen, das bei dem Versand von Emails auftreten kann. Das Problem heisst “ist diese Email Adresse auch echt?”.
Man kann sich dem Ganzen ja von mehreren Seiten nähern unter anderem durch den exzessiven Gebrauch von regulären Ausdrücken (hab ich versucht und bin gescheitert) aber wenn man nicht soooo hochvolumig unterwegs ist geht es auch anders.

Jede Email muss ja irgendwie zu einem Zielhost kommen um da in den Posteingang des betreffenden Users zu gelangen. Der Wegweiser zu diesem Zielhost ist im DNS hinterlegt und hört auf den sprechenden Namen MX-Record (MX = Mail eXchanger).

Wenn wir nun versuchen herauszubekommen, ob es eine Mailadresse wirklich gibt ist die erste Frage ja, ob die Maildomain überhaupt erreichbar ist und wie bei ruby üblich gibt es auch hier ne Spitzenlösung. Sie hört auf den Namen net-dns und ist als gem installierbar. Also erstmal

sudo gem install net-dns

Damit haben wir schon mal ein nettes Tool für DNS Abfragen am Start. Wir können nun folgende Befehlssequenz abfeuern um auf das Vorhandensein eines MX Eintrages zu testen

require 'net/dns/resolver'
packet = Net::DNS::Resolver.start("web.de", Net::DNS::MX)
answer = packet.answer
answer.any?

Die letzte Zeile liefert true, wenn es einen MX Record für diese Domäne gibt und false wenn es diesen nicht gibt. Damit sind natürlich zwei Fragen noch nicht geklärt:

1. gibt es den eingetragenen Mailserver noch? (oder ist der abgeschaltet)
2. gibt es die Email Adresse?

Zum ersten kann man sich natürlich eine kurze Routine schreiben, die nachguckt ob auf Port 25 (SMTP) jemand lauscht. Dazu holt man sich aus dem Answer Paket einfach die IP Adresse des Mailservers.

Bei dem zweiten wird es etwas schwieriger. In Zeiten des massiven Email Spams sind gut eingestellte Mailserver mit der Herausgabe von Emailadressen oder auch nur dem Vorhandensein der selben sehr sparsam. Man möchte vermeiden, das ein Spammer durch einen Harvesting genannten Prozess einfach kostenlos an jede Menge gültiger Mailadressen kommt. Diese Abfrage ist uns also in den meisten Fällen verwehrt.. vielen Dank an die Bulk Mailer dieser Welt.

Ich danke an dieser Stelle Rodrigo Urubatan dessen Post mich auf diese Nummer gebracht hat.

Heute sind wir über ein lustiges, kleines Phänomen gestolpert.

Man nehme eine Standard Rails Anwendung und setze dort authlogic (nebenbei ein super System für Authentifikation) ein. Nun geht man auf die Logon Seite und gibt erstmal nix ein. Nach Druck auf den Logon Knopf ist die URL dann

http://localhost:3000/user_session

und nun kommt der Trick: In das Browsereingabefeld klicken und auf Enter latschen und schon kriegt man nen schööönen 500er Fehler. Warum?

Eigentlich ganz einfach. Laut Beschreibung wird der Controller bei authlogic in der routes.rb als RESTful-controller eingerichtet (was er eigentlich ja gar nicht ist) und der Browser macht nun nach einem direkten Aufruf des user_session controllers das, was jeder RESTful controller macht; er benutzt show wenn keine andere Aktion angegeben wurde. Leider gibt es diese show action aber nicht und damit stirbt das Teil dann … hier ein Quick-and-Dirtiy-Workaround:

def show
  render :action => :new
end

Diese Zeilen dem user_session Controller hinzufügen und alles ist Bingo. Bleibt nur die Frage, ob es nicht sinnvoller wäre den Controller gar nicht erst RESTful zu machen; aber dazu dann später mehr.

Kollege Gülck hat sich einen Teil seiner Daten geshreddert. Aber wie jeder gute Admin hat er solange nachgesessen, bis alles wieder da war. Hier der Erfahrungsbericht