Donnerstag, 9. Juni 2011
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
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
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
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
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
Samstag, 4. Juni 2011
Der täglich ausgeführte Cron-Job /etc/cron.daily/man-db meldete seit dem Upgrade auf die neueste Debian-Version folgende Probleme:
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 22552 package 'am-utils': 'Replaces' field, reference to 'amd': error in version: version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 22555 package 'am-utils': 'Conflicts' field, reference to 'amd': error in version: version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 52773 package 'root-tail': 'Conflicts' field, reference to 'rt': error in version: version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 65726 package 'wmnetselect': 'Suggests' field, reference to 'mozilla': error in version: version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 69143 package 'e3': error in Version string 'e3-2.30-1': version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 75804 package 'tac-plus': error in Version string 'F4.0.4.alpha-9.1': version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 125732 package 'epic4-script-thirdeye': 'Depends' field, reference to 'epic4': error in version: version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 149557 package 'cnews': error in Version string 'cr.g7-31': version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 152423 package 'kernel-image-2.4.25': error in Version string 'mad.8': version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 168065 package 'mkcdrec': error in Version string 'v0.8.0-2': version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 189590 package 'request-tracker1': 'Conflicts' field, reference to 'rt': error in version: version number does not start with digit dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 201432 package 'epic4': 'Conflicts' field, reference to 'epic4-help': error in version: version number does not start with digit
Nachdem ich mir die Datei /var/lib/dpkg/available angeschaut hatte, kam ich zum Schluss, dass ich lieber die Finger von dieser Auflistung lasse (ich überlegte mir kurz, die Versionsangaben der betreffenden Pakete manuell anzupassen).
Die Überprüfung auf das Vorhandensein all dieser Pakete förderte nichts zu Tage:
$ dpkg --list | grep am-utils $ dpkg --list | grep root-tail $ dpkg --list | grep wmnet $
Komisch! Stattdessen fand ich nach ein wenig Googlen das Patentrezept gegen solche Probleme:
# dpkg --clear-avail # apt-get update
Mittwoch, 25. Mai 2011
… lautet neu 2D1F94A8.
Als ich im Sommer 2007 meine Teilzeitanstellung bei der Liip AG antrat, war eine der ersten Aufgaben, einen PGP-Schlüssel zu erstellen.
Ich habe damals den Anfängerfehler begannen, für jede meiner E-Mail-Adressen ein neues Private/Public-Schlüsselpaar zu erstellen. Dieses Problem habe ich heute nun endlich behoben und alle meine E-Mail-Adressen mit einem einzigen universalen Schlüssel ausgestattet und die alten deaktiviert.
Einmal in den Umlauf gebrachte öffentliche PGP-Schlüssel lassen sich nicht mehr löschen. Stattdessen muss der Besitzer diese mittels „revoke“ unbrauchbar machen.
Hierzu war es von Vorteil, dass ich im 2007 bereits bei der Erstellung der Schlüssel mittels gpg --gen-revoke 4A7347BE entschlessende Revoke-Zertifikate erstellt hatte. Diese konnte ich nun endlich einsetzen:
$ gpg --import revocation-4A7347BE.txt $ gpg --send-keys 4A7347BE
Dies geschieht mit grosser Hilfe des GnuPG-Tools ganz einfach mit folgendem Befehl:
$ gpg --gen-key
Als nächstes erstellt man das Revoke-Zertifikat:
$ gpg --gen-revoke 2D1F94A8
Und nun endlich fügt man dem neuen Schlüssel weitere E-Mail-Adressen hinzu:
$ gpg --edit-key 2D1F94A8 > adduid
Sobald man alle E-Mail-Adressen erfasst hat, schickt man den öffentlichen Schlüssel an einen PGP-Keyserver:
gpg --send-keys 2D1F94A8
Um zu überprüfen, dass der Schlüssel beim Server angekommen ist und von anderen Benutzern gefunden werden kann, kann man diesen mittels einer Web-Oberflache abfragen:
Schlüssel vom Server abrufen und lokal speichern:
$ gpg --recv-keys DDB43876
Schlüssel für eine von mehreren E-Mailadresse ungültig machen:
$ gpg --edit-key 2D1F94A8 > uid 2 > revuid $ gpg --send-keys 2D1F94A8
Mittlerweile existiert für Mac OS X 10.6 ein Software-Paket, dass das Betriebsystem mit allen nötigen (GUI-)Tools ausstattet, die man so benötigt:
Da ich auf einem Rechner noch Mac OS X 10.5 einsetze, musste ich für das dort installierte Apple Mail eine ältere Version des MailBundle installieren.
Tags: GnuPG, PGP, Sicherheit, Verschlüsselung
Labels: Linux
Samstag, 21. Mai 2011
Heute hiess es ernst: Auf einem meiner Teilzeitstellen wurde der Dateiserver migriert: Die Nutzerdaten wurden von einem uralten Dell-Server auf einen neueren HP-Server kopiert. Auf der Dell-Kiste lief Samba 2.2, auf dem HP-Server Samba 3.2.
Wie es die Samba-Konfiguration des alten Server so wollte, waren alle Datei- und Ordnernamen mit der Windows-Codepage 850 abgelegt. Erst seit Version 3 legt Samba Dateien intern mit UTF-8-Kodierung ab (falls nicht anders eingestellt).
Zehntausende von Dateien von Hand umzubenennen wäre hirnverrückt gewesen — doch wofür gibt es das Tool convmv?
Nachdem der Quelltext heruntergeladen worden war, konnte ich das Tool folgendermassen installieren:
# wget "http://www.j3e.de/linux/convmv/convmv-1.14.tar.gz" # tar xvzf convmv-1.14.tar.gz # cd convmv-1.14 # make # make install
Anschliessend startete ich das Tool unter /home/public:
# convmv -f cp850 -t utf8 -r .
Nachdem ich mich an Hand der Testausgabe abgesichert hatte, dass die Sonderzeichen in den Dateinamen tatsächlich korrekt nach UTF-8 übertragen wurden, führte ich den Befehl noch einmal aus — doch dieses Mal wurden die Dateinamen auch wirklich angepasst:
# convmv -f cp850 -t utf8 -r --notest .
Tags: Howto, Microsoft, Samba, Shell, Terminal, Windows
Labels: Linux
Mittwoch, 18. Mai 2011
Heute entschloss ich mich, einen unserer produktiven Web-Server von Debian Lenny nach Squeeze zu migrieren, das seit März 2011 stabile Release 6 der Debian GNU/Linux-Distribution. Wie erwartet klappte beim Upgrade vorerst nicht alles wie am Schnürchen — doch schlussendlich obsiegte meine Wagemutigkeit.
Eines der grössten Probleme war, dass die unter Apache 2.2.16 gegen LDAP authentifizieren beschriebene Authentifizierung gegen einen LDAP-Server nicht mehr funktionierte. Der Web-Browser zeigte bei jedem Login-Versuch die Meldung „500 — Internal Server Error“ an, ohne dass im Apache error.log irgendwelche Meldungen aufgeführt wurden.
Als erstes hiess es deshalb, in /etc/apache2/apache2.conf den LogLevel heraufzusetzen:
... #LogLevel warn LogLevel debug ...
Nach einem erneuten Login-Versuch fanden sich nun erleuchtende Einträge im Apache error.log:
... [Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(982): [24124] auth_ldap url parse: `ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)', Host: ldap.domain.tld, Port: 636, DN: o=company,c=ch, attrib: uid, scope: subtree, filter: (gidNumber=1160), connection mode: using SSL [Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160) [Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160) [Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160) [Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160) [Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160) [Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160) [Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160) [Wed May 18 16:11:17 2011] [info] [client 192.168.1.2] [24124] auth_ldap authenticate: user maeby authentication failed; URI /admin [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server] ...
Eine Google-Suche führte mich auf die richtige Spur:
To reenable my running lenny configuration in squeeze I had to add
LDAPTrustedGlobalCert.
Quelle: Bug#620398: Apache LDAP/S Authentication Causes
Offenbar fehlte dem Server nach dem Upgrade also ein GlobalCert, welches die Kommunikation mit dem LDAP-Server verschlüsselt. Wie konnte ich mir dieses beschaffen?
Zuerst hiess es nun also, herauszufinden, mit welchem Zertifikat der IT-Dienstleister die Kommunikation verschlüsselte. Hierzu behalf ich mir mit folgendem Befehl:
$ openssl s_client -connect ldap.domain.tld:636 -showcerts depth=2 /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=CH/ST=Bern/L=Bern/O=Company/OU=Department - Security/CN=ldap.domain.tld i:/C=BM/O=QuoVadis Limited/OU=www.quovadisglobal.com/CN=QuoVadis Global SSL ICA -----BEGIN CERTIFICATE----- MIIFFjCCA/6gAwIBAgICKIcwDQYJKoZIhvcNAQEFBQAwazELMAkGA1UEBhMCQk0x GTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxHzAdBgNVBAsTFnd3dy5xdW92YWRp ...
Der Zertifikatsherausgeber war also QuoVadis, dessen QuoVadis Global SSL ICA von unserer IT-Abteilung zur Signierung der eigenen Verschlüsselungszertifikate verwendet wurde.
Mit dieser Information bewaffnet konnte ich nun auf die Suche nach dem öffentlichen Zertifikat gehen. Jeder Zertifikatsanbieter bietet auf seiner Web-Site nämlich die firmeneigenen GlobalCerts zum Download an, so auch QuoVadis. Unter QuoVadis Root Download fand sich eine Liste, in welcher ich mich — aus offensichtlichen Gründen — für das QuoVadis Global SSL ICA entschied.
Dieses Zertifikat kopierte ich von der Web-Site und fügte es auf dem Server in die Datei /etc/ldap/certs/qv_root.pem ein (Gratistipp: vim ist mit :set paste auf die Kopieraktion vorzubereiten).
Anschliessend musste ich noch /etc/apache2/mods-enabled/ldap.conf mit folgender Zeile ergänzen:
... LDAPTrustedGlobalCert CA_BASE64 /etc/ldap/cacerts/qv_root.pem ...
Nach einem Neustart von Apache (/etc/init.d/apache2 restart) klappte der Login schlussendlich wieder.
Tags: Apache, Authentifizierung, Debian, LDAP
Labels: Linux
Mittwoch, 23. Februar 2011
Aus gegebenem Anlass habe ich mich heute Morgen das erste Mal seit langem wieder mit dem Web-Framework Ruby on Rails aus der Küche von David Heinemeier Hansson (einer der Partner hinter 37signals) auseinandergesetzt.
Nachfolgend habe ich zusammengefasst, wie ich das Framework auf meinem heimischen Entwicklungsserver zum Laufen gekriegt habe.
(Ich folge der englischen Anleitung Debian Lenny – Ruby on Rails von SliceHost)
Zuerst lädt man Debian-Pakete herunter und installiert diese:
# apt-get install ruby-dev ruby ri rdoc irb libreadline-ruby libruby libopenssl-ruby sqlite3 libsqlite3-ruby libsqlite-dev libsqlite3-dev
Anschliessend lädt man die Quellen von RubyGems herunter und kompiliert diese (man sollte auf das vorkompilierte Debian-Paket verzichten weil es mit Version 1.2.0 unglaublich veraltet ist):
# cd /tmp # wget "http://rubyforge.org/frs/download.php/74234/rubygems-1.5.2.tgz" # tar xvzfz rubygems-1.5.2.tgz # cd rubygems-1.5.2 # ruby setup.rb
Nun noch die obligatorischen Update-Anweisungen, die man sich als Linux-Benutzer von vielen Paketmanagern kennt, und dann ist man bereit:
# gem update
Bei mir erhielt ich bei der Ausführung von gem update folgende Fehlermeldung zu Gesicht:
# gem -v /usr/bin/gem:10: undefined method `manage_gems' for Gem:Module (NoMethodError)
Der Anleitung unter RubyGems: undefined method ‘manage_gems’ for Gem:Module (NoMethodError) – easy fix folgend wurde ein veraltetes Binary installiert, welches zuerst mit einer aktuellen Version ersetzt werden muss:
# mv /usr/bin/gem /usr/bin/gem-backup # ln -s /usr/bin/gem1.8 /usr/bin/gem
Anschliessend aktualisiert man das System (nun hoffentlich erfolgreich):
# gem update # gem update --system
Notabene: Bei mir wurden keine Updates nachgeladen, alles war bereits auf dem neuesten Stand …
Damit Ruby mit der Datenbank sqlite3 sprechen kann, muss ein entsprechender Treiber bereitgestellt werden. Falls bei
# gem install sqlite3
die Fehlermeldung
Fetching: sqlite3-1.3.3.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing sqlite3:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.8 extconf.rb
extconf.rb:3:in `require': no such file to load -- mkmf (LoadError)
from extconf.rb:3
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/sqlite3-1.3.3 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/sqlite3-1.3.3/ext/sqlite3/gem_make.out
erscheint, hat man im obigen apt-get für die Grundinstallation vergessen, die Header-Pakete von Ruby zu installieren (via Stackoverflow). Dies holt man mit folgendem Befehl nach:
# apt-get install ruby-dev libsqlite3-dev
Obwohl man Ruby (on Rails) natürlich auch mit sqlite3 benutzen könnte, ist der LAMP-Web-Entwickler primär mit MySQL vertraut — so kann diese Datenbank mit der ansprechenden GUI phpMyAdmin administriert werden und ist bei grösseren Datenmengen auch klar performanter als sqlite3.
Um den Treiber zu installieren, bemächtigt man sich folgender Debian-Pakete:
# apt-get install libmysql-ruby libmysqlclient-dev
Anschliessend ist
# gem install mysql
Problemlos möglich.
Mit dem Ruby-Paketmanager gem kann man sich nun endlich Rails aus dem Netz herunterladen und installieren lassen:
# gem install rails
Fertig! Jetzt sollte man eine funktionierende Ruby on Rails-Installation auf dem Server liegen haben und man ist bereit, mit Bordmitteln das erste Projekt anzulegen. Wie dies genau vor sich geht, folgt in einem weiteren Artikel.
Tags: Debian, Howto, RoR, Ruby, Ruby on Rails, Web-Entwicklung
Labels: Linux, Web
Mario Aeby, geboren am 25. September 1980 in Bern, Schweiz
Ein Weblog über IT (Linux, OSS, Apple), Heim-Automation; mein mittlerweile abgeschlossenes Geschichtsstudium; Erkenntnisse aus meiner aktuellen Tätigkeit in der Informationssicherheit, meine Erfahrungen als IT-Berater, IT-Auditor, Web-Developer und IT-Supporter; die Schweiz, den Kanton Bern, meine ursprüngliche und auch wieder aktuelle Wohngemeinde Neuenegg, meine vorherige Wohngemeinde Bern, über lokale, regionale und globale Politik; meine Reisetätigkeit und Erfahrungen mit anderen Kulturen; und zu Guter letzt auch das Älter werden.
Alle in diesem Blog gemachten Aussagen und Meinungen sind persönlich und nicht als Ansichten meines aktuellen und/oder meiner bisherigen Arbeitgeber zu verstehen.
 |
You are currently browsing the archives for the Linux category.