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
Archiv ‘Linux’
Samstag, 27. August 2011
Debian unter VMware meldet „Waiting for root file system“
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.
Sonntag, 31. Juli 2011
TeX Live 2011 sucks
Da wollte ich also gestern schnell mal TeX Live 2011 auf dem Windows-Laptop meiner Freundin installieren, scheiterte schlussendlich aber kläglich …
Zuerst habe ich mir install-tl.zip für Windows heruntergeladen, entpackt und danach die Datei install-tl.bat gestartet. Die Installation lief durch, hing aber schlussendlich bei „Finished downloading“. Erst viel später merkte ich, dass im Hintergrund ein Kommandozeilenfenster geöffnet war und irgendwas von mir wollte.
Der zweite Installationsversuch klappte ebenfalls nicht, obwohl alle erneut Pakete heruntergeladen werden mussten (!). Die Einträge im Startmenu fehlten.
Als ich deshalb den Installer unter C:\texlive\2011\ erneut ausführen wollte (ein zweiter Durchlauf kann nie schaden), erschien folgende Fehlermeldung:
Cannot open 'C:/texlive/2011/tlpkg/installer/texlive.png' in mode 'r' at C:\texlive\2011\tlpkg\tlperl\lib/Tk/Image.pm line 21.
Nach etwas pröbeln kopierte ich kurzerhand den von der Web-Site heruntergeladenen install-Ordner unter ~/Downloads über den Ordner in C:/texlive/2011/tlpkg/installer/. Damit die Pakete dabei aber nicht erneut heruntergeladen werden mussten, startete ich den Installer von der Kommandozeile mit
install-tl.bat -in-place
Die Installation lief nun das erste Mal richtig durch, indem TeX Live auch klar sichtbar konfiguriert wurde. Der Ordner im Startmenu tauchte aber auch hier nicht auf.
Unter C:\texlive\2011\ fand ich eine Taskbar-Applikation, welche mir so Zugriff auf TeXWorks verschaffte. Die Kompilierung einer Beispieldatei schlug grandios fehl, die Fehlermeldung lautete:
kpathsea: Running mktextex latex.ini Running: pdftex --ini --jobname=latex --progname=latex -translate-file=cp227.tcx *latex.ini*latex.ini (Press Enter to retry, or Control-Z to exit) Please type another input file name: ! Emergency stop. <*> *latex.ini No pages of output. Transcript written on latex.log.
Offenbar ist dieses Problem im Netz nicht sonderlich bekannt, eine Google-Suche lieferte nur bruchstückhafte Hinweise auf die Ursache (und Lösung) des Problems.
Indem ich
fmtutil --missing
ausführte, erhielt ich die Fehlermeldung präsentiert, dass mangels .ini-Dateien 37 Format-Dateien nicht hätten erstellt werden können. Eine Beispielsuche nach latex.ini zeigte mir, dass die Datei unter C:\texlive\2011\ vorhanden war — doch wieso fand sie fmtutil nicht?!
Über Mailinglistenkommentare führte ich folgenden Befehl aus, welcher aber ohne Output hängen blieb:
tlmgr generate --rebuild-sys language
Die Anpassung auf
tlmgr generate language
lief zwar durch, brachte aber keine Besserung.
Lösungsansätze
Die Ursache allen Übels scheint zu sein, dass folgender Befehl nichts zurückgibt:
kpsewhich latex.ini
Im Mailinglisten-Thread [tex-live] Error : „I can’t find the format file `latex.fmt‘! sind die Fehlermeldungen besprochen, obwohl die Ursache hier eine andere zu sein scheint.
Hellhörig macht mich nur:
Normally the TEX… variables are not set in the shell but by
loading texmf.cnf in the tex-related programs.
You should use kpathsea debugging to see what is really
going on.
Ein anderer Ansatz könnte folgende Unterlassung sein:
Administrator privileges on Vista and Windows 7: even when running as administrator, if you want to install for all users, right-click install-tl.bat and select ‘Run as administrator’. The same is needed when running tlmgr (TeX Live Package Manager).
Quelle: TeX Live Windows installation
Samstag, 23. Juli 2011
Mac OS X 10.7 Lion ohne Samba?!
As part of the Lion release, Apple switched their SMB server from the open-source Samba implementation to an internal implementation.
Quelle: Update to Mac users on OS X 10.7 (Lion) support on Sonos – Sonos Forums
Irgendwie ist das völlig an mir vorbeigezogen … aber anscheinend soll die GPLv3 Schuld daran sein. Stattdessen werkelt unter Lions Haube nun SMBX, ein von Apple intern entwickelte SMB1/2-Implementation.
Tags: Lion, Mac OS X, Opensource, OSS, Samba
Labels: Apple, Linux
Montag, 13. Juni 2011
cacti pingt nicht mehr
Heute habe ich mich endlich einem Problem angenommen, das mich mit meiner Cacti-Installation seit mehr als einem Jahr plagt: Die Ping-Werte für Google werden nicht mehr aufgezeichnet.
Nachdem ich unter
- Console
- System Utilities
- View Cacti Log File
nach „ping“ gesucht hatte und feststellen musste, dass das Script ~/cacti/scripts/ping.pl permanent „U“ als Wert zurücklieferte, begann das Debugging.
Auch die manuelle Ausführung von
~/cacti/scripts/ping.pl www.google.com
brachte ein „U“ als Resultat hervor. Was cheibs?
Im Grunde ruft das Perl-Script folgenden Kommandozeilenbefehl auf und filtert im Anschluss den Rückgabe wert:
ping -c 1 www.google.com | grep icmp_seq | grep time
Als ich dies auf der Kommandezeile ausführte, wurde ein leerer Wert zurückgegeben.
Nachdem ich ein Blick auf das Resultat von
$ ping -c 1 www.google.com PING www.l.google.com (74.125.79.104) 56(84) bytes of data. 64 bytes from ey-in-f104.1e100.net (74.125.79.104): icmp_req=1 ttl=53 time=34.6 ms --- www.l.google.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 34.695/34.695/34.695/0.000 ms
geworfen hatte, war mir sofort klar, was das Problem war: grep nach icmp_seq kann nicht von Erfolg gekrönt sein, weil hier offenbar icmp_req steht.
Das Problem ist im ping.pl does not account for ping using icmp_req rather than icmp_seq in some versions of ping festgehalten: Offenbar gab es bei ping irgendwann einmal eine Anpassung am Code, die nur noch diese Ausgabe zur Folge hatte.
Nach einem Blick auf den Patch nahm ich die Anpassung an ~/cacti/scripts/ping.pl selber vor — irgendwie einfach ein wenig anders als vorgeschlagen:
... open(PROCESS, "ping -c 1 $host | grep -E 'icmp_(r|s)eq' | grep time |"); ...
Damit klappte es wieder.
Nachtrag
Unter einer Synology DiskStation klappt es auch trotz dieser Anpassung nicht. Der Ping-Befehl gibt folgendes aus:
ping -c 1 192.168.8.8 PING 192.168.8.8 (192.168.8.8): 56 data bytes 64 bytes from 192.168.8.8: seq=0 ttl=64 time=0.223 ms
Keine Spur von icmp_seq, stattdessen steht dort nur seq. Somit passt man das Script finalerweise folgendermassen an:
... open(PROCESS, "ping -c 1 $host | grep -E '(r|s)eq' | grep time |"); ...
Tags: cacti, Howto, ICMP, Internet, Perl, Ping
Labels: Linux
Donnerstag, 9. Juni 2011
Unable to connect to CUPS server
Erscheinen im syslog folgende Fehlermeldungen …
May 18 17:00:21 smbd[25311]: [2011/05/18 17:00:21.386431, 0] printing/print_cups.c:108(cups_connect) May 18 17:00:21 smbd[25311]: Unable to connect to CUPS server localhost:631 - Connection refused
… sollte man in der /etc/samba/smb.conf folgenden Eintrag sicherstellen:
... printcap name = /etc/printcap ...
Mittwoch, 8. Juni 2011
Zertifikatsprobleme mit imapfilter bei einem loadbalancierten Exchange 2010-Server
ACHTUNG: Funktioniert leider doch nicht wie erwünscht.
imapfilter ist das Tool meiner Wahl, um einkommende Mail-Nachrichten in IMAP-Unterordner zu verschieben. Dessen Anwendung habe ich in einem Blog-Artikel erläutert.
Seit mein Arbeitgeber mein E-Mail-Konto von einem Unix-Mailserver auf eine Microsoft Exchange 2010-Lösung migriert hat, gab es Probleme mit den Zertifikaten. (Natürlich hätte ich die Regeln erneut unter Exchange erfassen können, aber der Vorteil von imapfilter ist eben gerade, dass man nur die Serververbindung anpassen muss, und die Mails werden weiter schön sauber sortiert).
imapfilter lässt man bekanntlich beim ersten Verbindungsversuch im interaktiven Modus laufen und akzeptiert dort dann brav das Zertifikat das Mail-Servers:
Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch Server certificate issuer: /C=BM/O=QuoVadis Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis Global SSL ICA Server key fingerprint: CD:10:34:E9:6D:1D:07:09:3D:9E:53:FC:B5:94:B0:10 (R)eject, accept (t)emporarily or accept (p)ermanently? p
Doch leider schien dieser Server in der Folge einfach so den Fingerprint zu wechseln. Als ich imapfilter nach einiger Zeit (und Fehlermeldungen im cron.log) erneut im interaktiven Modus ausführte, erschien folgende Warnung:
Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch Server certificate issuer: /C=BM/O=QuoVadis Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis Global SSL ICA Server key fingerprint: 6D:D9:E8:FF:A3:70:2A:D8:44:10:0C:7D:0E:94:65:FC ATTENTION: SSL/TLS certificate fingerprint mismatch. Proceed with the connection (y/n)? y
Leider führte das Bestätigen der Warnung nicht dazu, dass dieses neue Zertifikat akzeptiert wurde (wohl, weil für denselben Server bereits ein anderes Zertifikat gespeichert war). Meine Vermutung: Da mein Arbeitgeber einen loadbalancierte Exchange 2010-Infrastruktur aufgebaut hat, besitzt jeder Server ein anderes Zertifikat (auch wenn beide gegen aussen als mail.campus.unibe.ch in Erscheinung treten).
Der Workaround sah folgendermassen aus:
$ copy ~/.imapfilter/certificates ~/.imapfilter/certificates.old $ imapfilter -c myconfigfile (... accept certificate permanently ...) $ cat ~/.imapfilter/certificates.old >> ~/.imapfilter/certificates
Ab sofort motzte imapfilter nicht mehr über den gelegentlich wechselnden Fingerprint, weil nun einfach beide möglichen Zertifikate in der Datei gespeichert sind.
Tags: CA, IMAP, imapfilter, PKI, Verschlüsselung, Zertifikate
Labels: Linux
Sonntag, 5. Juni 2011
ffmpeg will AVI-Video nicht mehr nach MP4 konvertieren
Nachfolgender Befehl tat während vieler Monate genau das, was er tun sollte: Eine AVI-Videodatei (mit mencoder aus JPEG-Bildern zusammengesetzt; hier $1) in eine MP4-Datei (hier: $2) umzuwandeln, damit diese auch auf einem iPhone betrachtet werden kann.
Doch seit Neuestem nun dies:
$ ffmpeg -flags +loop -y -i "$1" -b 200000 -s 320x240 -vcodec libxvid -an -f mp4 "$2" ... [libxvid @ 0x97f1ab0] Invalid pixel aspect ratio 1701/1504
Nach einem hilfreichen Hinweis in einem Online-Forum dann die Lösung: Abkehr von libxvid, neu setze ich voll auf MPEG4:
$ ffmpeg -flags +loop -y -i "$1" -b 200000 -s 320x240 -vcodec mpeg4 -an -f mp4 "$2"
...
Input #0, avi, from '$1':
Metadata:
encoder : MEncoder 1.0rc4-4.4.5
Duration: 00:00:04.60, start: 0.000000, bitrate: 1898 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 567x376 [PAR 1:1 DAR 567:376], 20 tbr, 20 tbn, 20 tbc
[buffer @ 0x968fef0] w:567 h:376 pixfmt:yuv420p
[scale @ 0x96dd580] w:567 h:376 fmt:yuv420p -> w:320 h:240 fmt:yuv420p flags:0xa0000004
Output #0, mp4, to '$2':
Metadata:
encoder : Lavf52.87.1
Stream #0.0: Video: mpeg4, yuv420p, 320x240 [PAR 95:84 DAR 95:63], q=2-31, 200 kb/s, 20 tbn, 20 tbc
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
frame= 92 fps= 0 q=12.4 Lsize= 225kB time=4.60 bitrate= 400.5kbits/s
video:223kB audio:0kB global headers:0kB muxing overhead 0.666259%
Tags: Multimedia, Video
Labels: Linux
Sonntag, 5. Juni 2011
mencoder meldete für verschiedene Libraries „no version information available“
Debian ist gut und recht, aber leider ist die ganze Geschichte mit Multimedia-Tools auf Grund von Problemen mit geistigem Eigentum unnötig kompliziert.
Das führt dann auch mal zu einer solchen Flut von Fehlermeldungen, wenn man den mencoder benutzen möchte:
$ mencoder /usr/bin/mencoder: /usr/lib/i686/cmov/libswscale.so.0: no version information available (required by /usr/bin/mencoder) /usr/bin/mencoder: /usr/lib/i686/cmov/libpostproc.so.51: no version information available (required by /usr/bin/mencoder) /usr/bin/mencoder: /usr/lib/i686/cmov/libavutil.so.50: no version information available (required by /usr/bin/mencoder) /usr/bin/mencoder: /usr/lib/i686/cmov/libavcodec.so.52: no version information available (required by /usr/bin/mencoder) /usr/bin/mencoder: /usr/lib/i686/cmov/libavformat.so.52: no version information available (required by /usr/bin/mencoder) /usr/bin/mencoder: relocation error: /usr/bin/mencoder: symbol av_reverse, version LIBAVUTIL_50 not defined in file libavutil.so.50 with link time reference
Das Problem konnte ich schlussendlich lösen, indem ich folgende Zeilen wieder in die /etc/apt/sources.list aufnahm:
... # mplayer deb http://www.debian-multimedia.org squeeze main deb-src http://www.debian-multimedia.org squeeze main ...
Anschliessend ein apt-get update && apt-get upgrade. Irgendwann einmal waren dann nur noch zwei Fehlermeldungen zu sehen:
$ mencoder /usr/bin/mencoder: /usr/lib/i686/cmov/libavcodec.so.52: no version information available (required by /usr/bin/mencoder) /usr/bin/mencoder: /usr/lib/i686/cmov/libavformat.so.52: no version information available (required by /usr/bin/mencoder)
Doch dieses Problem schien nun unmöglich zu lösen zu sein:
# apt-get install ffmpeg libavcodec52 libavdevice52 libavformat52 libavfilter1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
ffmpeg : Depends: libavfilter1 (>= 5:0.6.1+svn20101128) but 4:0.6.2-3 is to be installed
libavfilter1 : Depends: libavcodec52 (< 4:0.6.2-99) but 5:0.6.1+svn20101128-0.2 is to be installed or
libavcodec-extra-52 (< 4:0.6.2-99) but it is not installable
Depends: libavutil50 (< 4:0.6.2-99) but 5:0.6.1+svn20101128-0.2 is to be installed or
libavutil-extra-50 (< 4:0.6.2-99) but it is not installable
Depends: libswscale0 (< 4:0.6.2-99) but 5:0.6.1+svn20101128-0.2 is to be installed or
libswscale-extra-0 (< 4:0.6.2-99) but it is not installable
E: Broken packages
Die Lösung:
/etc/apt/preferences:
... Package: * Pin: origin www.debian-multimedia.org Pin-Priority: 600
und dann:
# apt-get install -t unstable ffmpeg
Samstag, 4. Juni 2011
Eine portable Festplatte unter Linux mit FAT32 formatieren
Windows ist ja mittlerweile recht bockig, wenn es darum geht, übergrosse portable Festplatten mit FAT32 zu formatieren — stattdessen empfiehlt die Formatierungssoftware aus Redmond, man solle doch bitte das proprietäre NTFS verwenden. Der Haken dabei: Linux und Mac OS X bringen immer noch keine saubere Unterstützung dieses Dateisystems mit sich, wenn es um Schreiboperationen geht (im Klartext: auf eigenes Risiko!).
Unter Linux ist es ein Kinderspiel, auch neueste Festplatten mit riesigen Volumina mit FAT32 zu formatieren.
Nachdem man herausgefunden hat, unter welchem Devicenamen à la /dev/sdX die USB-Festplatte ansprechbar ist, erstellt man erstmals eine Partition:
# fdisk /dev/sdd
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-9729, default 1): <enter>
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-9729, default 9729): <enter>
Using default value 9729
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))
Command (m for help): w
Mit dieser Befehlsabfolge hat man nun eine primäre Partition mit dem Dateisystem FAT32 angelegt.
Die Festplatte muss nun aber auch noch formatiert werden, damit Daten darauf geschrieben werden können. Das ist noch viel einfacher als die Partitionierung:
# mkfs -t vfat /dev/sdd1
Tags: Debian, Howto, Uncategorized
Labels: Linux
