Wie lade ich in Django 1.10 ein Bild von der Festplatte per Django Command hoch?

Für den Fall, dass man ein Bild in eine Django Applikation uploaden möchte, gibt es unzählige Tutorials – kniffelig wird es dann ein bisschen, wenn man ein Bild von der Festplatte des Servers, auf dem die Applikation läuft, mittels Django Command hochladen möchte. In meinem Beispiel importiere ich Bilder per Cronjob aus einem anderen Programm. Bisher ging der Upload auch ohne Probleme, aber seit Django 1.9 oder 1.10 wurde das Sicherheitskonzept geändert – man darf keine Dateien mehr ausserhalb des Media_Path Kontextes hochladen (Suspicious File Operation. Um das Problem zu umgehen, muss man das “normale” Fileobject, welches man normalerweise dann an das Model übergeben würde, in den Django File Wrapper packen. Dazu importiert ihr diesen Wrapper wie im Beispiel unten, übergebt den realen Pfad zum Bild und, und das ist nun wichtig, übergebt per “name” Parameter einen beliebigen Dateinamen, mit dem diese Datei dann im “Upload Prozess” von Django ankommt. Nun müsst ihr das “image” Objekt einfach nur an den Image Parameter eures Models hängen, und schon klappt das Einspielen der Datei wieder. Bei mir war es tatsächlich der fehlende “name” Parameter, der mich in die Verzweiflung getrieben hat 🙂

from django.core.files import File
image = File(open("[PATH_TO_REAL_FILE]", "rb"), name="[SOME_FILE_NAME]")

[Quicktip] Wie kann ich alle installierten Python pip Packages upgraden?

Über einen kleinen Umweg kann man auf der Bash ganz einfach alle aktuell installierten pip Pakete updaten / upgraden:

pip freeze | sed -e 's/==.*//g' > upgrade.txt
pip install --upgrade -r upgrade.txt
rm upgrade.txt

Das Script lässt sich alle installierten Pakete ausgeben, entfernt das “==[Versionsnummer]” hinter dem Namen und packt diese Liste in die Datei upgrade.txt. Anschließend wird diese Datei bei einem “pip upgrade” als “requirements.txt” übergeben und mit dem upgrade Befehl ausgeführt.

[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.

[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] Vagrant up kann die Netzwerkinterfaces nicht starten

Wenn ihr mit

vagrant up

eine virtuelle Maschine starten wollt und während des Hochfahrens die Fehlermeldung kommt, dass das Interface eth1 (oder eth2 usw.) nicht hochgefahren werden konnte, dann probiert folgendes:

  • Virtualbox öffnen
  • die laufende Vagrant Maschine im Virtualbox beenden und anschließend dort auch wieder starten, damit ihr diese direkt steuern könnt
  • anschließend mittels User „vagrant“ und Passwort „vagrant“ einloggen
  • mittels “sudo su“ zu root wechseln
  • “/etc/network/interfaces“ mit vi aufrufen und alle Zeilen löschen, die nichts mit eth0 zu tun haben. In der Regel sollte über diesen Zeilen „# VAGRANT START“ stehen
  • Anschließend noch den Ordner “/etc/udev/rules.d/70-persistent-net.rules“ mittels “rm -rf“ löschen
  • die Maschine herunterfahren und Virtualbox beenden
  • nun mittels „vagrant up“ die Maschine wieder starten, sie sollte nun erfolgreich booten
  • sollte die Provisionierung nicht starten, dann führt anschließend noch ein „vagrant provision“ durch

[Quicktip] Globalen SSH Key in Atlassian Stash hinterlegen

Wenn ihr in Stash viele Repositories habt und ein CI Tool wie Jenkins oder Teamcity nutzt, dann möchtet ihr sicher nicht bei jedem einzelnen Repo den SSH Key des Tools hinterlegen. Da ich lange nach der entsprechenden Stelle in Stash gesucht habe und in den Settings nichts dazu zu finden ist, hier eine mögliche Lösung für das Problem:

Die eine globale Stelle für das Problem gibt es nicht, ABER ihr könnt pro Projekt Zugriffsschlüssel hinterlegen. Ruft dazu einfach das Projekt auf, geht dann in die Einstellungen und dort auf Zugriffsschlüssel. Alle hier hinterlegten Keys können nur lesend oder auch lesend und schreibend für ALLE Repositories dieses Projektes freigeschalten werden. So lange ihr also nicht über allzu viele Projekte verfügt, ist die Einrichtung schnell erledigt 😉

[Quicktip] Wie bekomme ich einen Page Access Token als Facebook Entwickler im Graph API Explorer?

Die Facebook API ist ziemlich gut dokumentiert und es gibt auch allerhand Tools, um das ganze auch gleich direkt testen zu können. Im konkreten Beispiel wollte ich etwas von einer Facebook Fanpage auslesen – und ich bekam immer wieder die Fehlermeldung

“(#210) A page access token is required to request this resource.”

Der Trick ist nun folgender: man holt sich einen ganz normalen Access Token, der unter anderem die Berechtigungen für „manage_pages“ enthält. Dann ruft man die Ressource 

“me/accounts“

auf. Derzeit lautet die komplette URL also:

„https://graph.facebook.com/v2.2/me/accounts”

Nun bekommt man die Infos zu seinen Pages geliefert – inkl. des Page Access Tokens 😉

[Quicktip] Jenkins zeigt keine Trend Grafiken für Checkstyle, phpmd usw. an

Wenn ihr im Jenkins einen Job auswählt, der eigentlich die Ergebnisse von Checkstyle, phpmd usw. auswerten und anzeigen sollte – ihr aber keine tollen Diagramme sondern nur irgendwelche „headless“ Fehlermeldungen seht:

Installiert mittels

sudo apt-get install ttf-dejavu

die Font ttf-dejavu.

Nachdem die Schriftart installiert ist und Jenkins neu gestartet wurde, sollte Jenkins die Verlaufsdiagramme korrekt generieren und anzeigen.

[Quicktip] Symfony2 Framework läuft nach Update auf Version 2.3.3 nicht mehr

Nachdem ich eine Symfony2 Installation auf die neueste Version 2.3.3 per Composer geupdatet hatte, bekam ich auf dem Zielsystem per app/console immer wieder die Fehlermeldung

[Symfony\Component\DependencyInjection\Exception\InvalidArgumentException]
  The parameter "kernel.trusted_hosts" must be defined.

präsentiert. Scheinbar haben diesen Fehler nicht allzu viele Leute, eine Google Suche brachte keine Ergebnisse. Die Formulierung der Fehlermeldung ist auch relativ ungünstig, denn es fehlt kein Parameter, sondern ein Config Eintrag. Kurz gesagt, müsst ihr folgende Zeile in euere app/config/config.yml Datei eintragen:

...
framework:
    ...
    fragments:       ~
    trusted_hosts:   ~
...

Anschließend sollte die Symfony2 Console sowie das System an sich wieder laufen.