Im großartigen MacOS Terminal Programm iTerm2 gibt es ein sehr lästiges Feature, mit welchem man mittels Trackpad-Pinch-Geste (also die aufziehende Geste zum Vergrößern von Bildern z.B.) die Schriftgröße des aktuellen Terminals verändert. Leider gibts dafür auch keine direkte Einstellung, aber wenigstens ein hidden Setting. Und das aktivierst du so:
defaults write com.googlecode.iterm2 PinchToChangeFontSizeDisabled -bool true
Um rsync langsamer zu machen, damit es z.B. nicht die Leitung eures Gegenübers dicht macht, verwendet man folgenden Parameter:
--bwlimit=1M
Damit wird die Datenrate auf 1Mb/s begrenzt.
Man kann auch Kommawerte verwenden:
--bwlimit=1.6M
Ü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.
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.
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!
Wenn euch screen bei der Ausführung nur mit folgender Meldung begrüßt:
Cannot find termcap entry for ‘rxvt-256color’.
Dann gebt vorher folgendes einfach in die Shell ein:
TERM=xterm
Anschließend sollte screen wieder wie gewohnt 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
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.
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.
Erinnerung an mich selbst: wenn mich ein remote git Repo das nächste mal mit so einer Fehlermeldung begrüßt
fatal: failed to write object error: unpack failed: unpack-objects abnormal exit Auto packing the repository for optimum performance. fatal: Unable to create '/[reponame].git/packed-refs.lock': Permission denied
…dann macht es Sinn zu prüfen, ob der jeweilige User auf dem Zielserver überhaupt die entsprechenden Schreibrechte für den Repository Ordner hat…