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

[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

Wie schreibe ich eigene / custom Funktionen in einem Makefile?

Mittels selbst definierter Funktionen kann man so ein Makefile deutlich effizienter und übersichtlicher gestalten.

Definiert wird eine Funktion wie folgt:

define name-meiner-funktion
	@ [hier steht dein shellcode] \
	[mehrzeiliger Code muss pro Zeile mit \ abgeschlossen werden] \
	[Variablen werden mit $1, $2, usw. angesprochen]
endef


Aufgerufen wird die Funktion dann mittels:

$(call name-meiner-funktion,parameter1,parameter2,...)

Wichtig ist hier, dass zwischen den Kommas KEIN Leerzeichen sein darf, sonst kommt es zu Fehlermeldungen!

[Quicktip] Aptitude meldet fehlerhafte Signaturen für Jenkins

Wenn ihr ein 

aptitude update

durchführt und die Meldung

W: GPG-Fehler: http://pkg.jenkins-ci.org binary/ Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 9B7D32F2D50582E6

erscheint, dann müsst ihr folgendes machen:

sudo apt-key adv --recv-keys --keyserver keys.gnupg.net 9B7D32F2D50582E6

Damit wird der angezeigte öffentliche Schlüssel auf den neuesten Stand gebracht und der Fehler hat sich erledigt. (9B7D32F2D50582E6 ist die Schlüssel-ID in meinem Fall, kann natürlich auch eine andere sein)

[Quicktip] Fehlerhafte Festplatte unter OSX formatieren

Seit einiger Zeit habe ich einen ziemlich komischen Fehler mit meiner Time Machine Festplatte. Es handelt sich um eine 2 TB USB 3.0 Festplatte, die an meinem Retina Mac wunderbar funktioniert. Die Platte ist mit dem Mac OS Dateisystem in der verschlüsselten Variante formatiert und wird, wie gesagt, komplett für meine Timemachine Backups verwendet.

Sobald ich diese Platte jedoch an mein relativ altes Macbook mit USB 2.0 stecke, lässt es sich dort nach Ewigkeiten irgendwie mounten, funktioniert aber partout nicht. An sich nicht schlimm, ABER: sobald ich die Platte nun wieder an meinen Retina Mac hänge, ist sie kaputt. Trotz korrektem Passwort kann ich sie nicht mehr entsichern und das Festplattendienstprogramm meldet auch immer wieder, dass mit dem Laufwerk etwas nicht stimmt. Solltet ihr diesen Fehler auch haben, dann kommt ihr um die erneute Formatierung leider nicht herum. Aber hier lauert der nächste Fehler: die Platte lässt sich nicht mehr formatieren.

Mit folgendem Trick geht es aber nun doch wieder:

– öffnet das Terminal
– gebt “diskutil list“ ein und schaut, ob ihr die gewünschte Platte in der Liste findet. Wichtig hierbei ist die Angabe /dev/disk[x], wobei das „[x]“ für eine Zahl 0, 1, 2, 3 usw. steht. Das ist der internet Identifier eurer Platte.

– führt nun auf der Console ein “ps aux | grep fsck“ aus und schaut, ob ihr damit einen Prozess findet. Dieser sieht dann ungefähr so aus:

– Schaut euch vorn die ID des Prozesses an und killt diesen mit einem „sudo kill [ProzessID]“ auf der Konsole. Anschließend sollte die Platte ausgeworfen werden. Wenn ihr sie nun eurneut an den Rechner steckt, sollte sie erneut erkannt werden und sich dann zumindest wieder formatieren lassen.

[Quicktip] Wie ändere ich nachträglich die Email und den Namen von git Commits?

Stellt euch folgende Situation vor: ihr habt lokal ein Tool entwickelt und während der Entwicklung natürlich bereits mit einem git Repository gearbeitet. Nun wollt ihr das Repository mit einem Server synchronisieren und bemerkt, dass ihr unter falschenm Namen/Email Adresse die Commits abgesetzt habt. Um dies nun nachträglich noch zu ändern, haben die Jungs von Github ein nettes Script zusammengebastelt:

https://help.github.com/articles/changing-author-info

Kopiert den Code in eine Datei namens “replace.sh” in den jeweiligen Repository Ordner und ersetzt die Stellen “your@email.to.match” mit der Email Adresse, bei der ihr eine Ersetzung durchführen wollt. Bei “Your New Committer Name” und “Your New Committer Email” (und das gleiche für “Author”) fügt ihr die neuen Daten ein, die ihr in den jeweiligen Commit Messages sehen wollt.

Wenn ihr nun das Script per “./replace.sh” ausführt, geht git jeden einzelnen Commit durch, schaut, ob die “your@email.to.match” Email Adresse passt und ersetzt in diesen Commits die Daten mit den von euch hinterlegten Ersetzungen.

BITTE AUFPASSEN: Führt dieses Script keinesfalls in git Repositories aus, die bereits mit einem Server bzw. anderen Usern synchronisiert wurden. Dies kann fatale Auswirkungen haben!

[Quicktip] sshd auf einem Synology NAS / DiskStation neu starten

Synology hat einiges an seiner Linux Distribution DSM umgebastelt, sodass sich die Service Scripte nicht wie gewohnt in /etc/init.d befinden. Um den sshd neu starten zu können, muss man daher folgendes Kommando verwenden:

/usr/syno/etc.defaults/rc.d/S95sshd.sh restart

Weitere Restart Kommandos findet ihr hier:
forum.synology.com

[Quicktip] git per Samba Share zeigt alle Dateien als “geändert” an

Nehmen wir folgende Konstellation: Du hast einen Linux Server, der einen Ordner per SMB (Samba, Windows Freigabe) Share freigibt, in dem sich git Repositories befinden. Greifst du nun von einem anderen Rechner auf diese Dateien zu, so wird git alle Dateien innerhalb dieses Repositories als geändert anzeigen. Ein git diff zeigt dann z.B. folgendes:

old mode 100644
new mode 100755

Dies bedeutet nichts anderes, als dass sich die Zugriffsrechte der Dateien geändert haben. Innerhalb der Samba Share Konfiguration kann man diese Rechte (also Zugriff für Benutzer, Gruppe, Alle) regeln. In vielen Fällen wird sich diese Konfiguration von der in git eingecheckten unterscheiden. Um das Problem zu umgehen, gibt es nun folgende Möglichkeiten:

– im Samba Share Config File die Dateirechte korrekt setzen
– innerhalb des git Repositories folgenden Parameter setzen bzw. umstellen:

git config core.filemode false

Bitte beachten: Wenn dieser Parameter gesetzt wird, kann man KEINE Änderungen von Dateirechten in git committen!

Wollt ihr dies auf eurem Rechner global für alle Repositories machen, dann verwendet folgenden Befehl:

git config --global core.filemode false

Bitte hier besonders daran denken, dass nun in ALLEN git Repositories, auf die dieser Rechner zugreift, kein Committen von Änderungen an den Dateirechten möglich ist – es sei denn, der Parameter wird in einzelnen Repositories explizit überschrieben.

[Quicktip] SSH Key zu Github per Shell hinzufügen

Für alle, die sich unnötige manuelle Schritte beim Hinzufügen eines neuen SSH Keys zum eigenen Github Account sparen wollen:

mit

curl --data "{\"title\": \"NAME\",\"key\": \"`cat ~/.ssh/id_rsa.pub`\"}" --request POST https://api.github.com/user/keys --user "USERNAME:PW"

wird automatisch der Public SSH Key des aktuellen Benutzers im Github Account hinterlegt.
Unter NAME wird ein eindeutiger Name für den Schlüssel angegeben, USERNAME und PW sollten selbsterklärend sein.

Noch ein kleiner Tipp am Rand: bestehende Keys werden weder überschrieben, noch doppelt hinzugefügt.