Kein Problem! Man benutze hierzu einfach Einträge in der Datei ~/.ssh/config à la:
Host github github.com Hostname github.com IdentityFile ~/.ssh/id_rsa_git
Quelle: Best way to use multiple ssh private keys on one client
Samstag, 27. August 2011
Kein Problem! Man benutze hierzu einfach Einträge in der Datei ~/.ssh/config à la:
Host github github.com Hostname github.com IdentityFile ~/.ssh/id_rsa_git
Quelle: Best way to use multiple ssh private keys on one client
Samstag, 27. August 2011
Vor einigen Wochen habe ich einen Account auf Github eröffnet und teile dort nützliche und weniger nützliche Programmierwürfe aus meiner Hand.
Da ich meine PHP-Entwicklungen mit Subversion verwalte und Git deshalb äusserst selten verwende, habe ich mir folgende Kurzanleitung von der Web-Site kopiert, damit ich ein Projekt im Nu eingecheckt habe.
Zuerst erstellt man sich unter Create a New Repository ein neues Repository. Anschliessend führt man lokal folgende Befehle aus:
mkdir arbeitsjournal cd arbeitsjournal git init git remote add origin git@github.com:emeidi/arbeitsjournal.git git pull touch arbeitsjournal.py git add arbeitsjournal.py git commit -m 'first commit' git push -u origin master
Für alles weiterführende sei beispielsweise auf eines der vielen Git-Cheatsheets verwiesen.
Tags: Entwicklung, Git
Labels: Web
Samstag, 27. August 2011
Gestern wurde der VMware-Server aktualisiert, unter welchem eine von mir betreute Debian GNU/Linux-Installation läuft. Wie ich erst jetzt realisiert habe, funktioniert der Server seit dem Update nicht mehr.
Nachdem ich mich per VPN über den Terminalserver und den VMware vSphere Client auf die Konsole der Kiste eingewählt und die Kiste neu gestartet hatte, lächelte mich folgende Fehlermeldung an:
Waiting for root file system
Nach einer Google-Suche und einiger Lektüre stiess ich auf einen erhellenden Artikel “Waiting for root file system” caused by out dated VMware Server, dessen Lösung für mich zwar nicht anwendbar war, mich aber immerhin darauf brachte, die in GRUB hinterlegten Referenzierungen auf die Partitionen zu überdenken.
Und siehe da: Zuerst betätigte ich beim GRUB-Screen zuerst einmal den Cursor, um den automatischen Start des Betriebssystems zu verhindern. Anschliessend bearbeitete ich den standardmässig aktivierten Eintrag mit Druck auf die Taste e. Hier wechselte ich folgende Angaben:
kernel /boot/vmlinuz-2.6.26-2-686 root=/dev/sdb2 ro
auf
kernen /boot/vmlinuz-2.6.26-2-686 root=/dev/sda2 ro
und einem anschliessenden Enter gefolgt von b liess die Kiste wieder booten.
Als nächstes musste ich die soeben gemachte Anpassung noch fix in /boot/grub/menu.lst vornehmen. Beim nächsten Neustart lief alles wieder wie gewohnt.