Archiv ‘Linux’

Mittwoch, 4. Oktober 2006

BSG – der Countdown läuft

Diesen Freitag ist es soweit – die dritte Staffel von Battlestar Galactica geht (vorerst in den USA) On Air. Dank bittorrent werde ich wohl spätestens am Samstag-Abend über ein ca. 300MB grosses .avi-File auf meinem RAID10 liegen haben. Dessen Inhalt? Geheimnis!

NZZ Folio

Wer bis zum Beginn der neuen Staffeln nicht warten kann, lese doch das NZZ Folio dieses Monates.

Beruhigt haben mich unter anderem folgende Aussagen:

Sex and the City

In meiner Wahrnehmung war das einfach eine gewöhnliche Sitcom. Sie konnte nie den selbstauferlegten Anspruch erfüllen, sexy und provozierend zu sein. […] Ich finde die Personen in „Sex and the City“ überzeichnet und gleichzeitig beliebig.

Desperate Housewives

Ich habe die Serie nie verstanden. […] er [der Autor] hatte ein tolle Idee: eine Leiche, die aus dem Off das Leben ihrer Freundinnen kommentiert. […] man ist sich in der Branche einig, dass die zweite Staffel Schwächen im Skript hat.

Quelle: NZZ Folio, 10/2006, „Der Serientäter“, S. 28ff.

Jä so, erstes Geheimnis gelüftet. Die Frauenstimme war mir desöfteren aufgefallen, konnte aber keine Erklärung dafür finden.

[…] die Geschichte vom edlen Wilden, der sich durch die moderne Zivilisation staunt, ist gut für jene Sorte Zuschauer, die Rousseau für eine Disco in Moskau halten.

Quelle: NZZ Folio, 10/2006, „Teleshopping“, S. 22.

[…] Ausserdem bedient man sich der Halbbildverdoppelung und einiger Filtereffekte, wodurch das auf Digitalvideo gedrehte Material körniger und damit filmischer wirkt.

Quelle: NZZ Folio, 10/2006, „Die Drama-Dosis“, S. 60.

Als ich GZSZ vor kurzem das erste Mal seit Jahren geguckt habe (nicht freiwillig, meine bessere Hälfte bestand darauf), fiel mir sofort das „andere“ Bild auf. Sie konnte es mir nicht erklären. Aber dafür gibt es ja das NZZ Folio!

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 27. September 2006

/dev/lp0 fehlt

Kleine Nachwehen begleiten meinen Umstieg auf den 2.6er-Kernel – das Drucken funktioniert seit dem Umstieg nicht mehr richtig. Genauer gesagt: Nach jedem Neustart tat sich trotz einer langen Druck-Queue nichts mehr. Nach einigen Nachforschungen erkannte ich die Hauptursache: /dev/lp0 fehlt! Doch wieso nur?

Ein …

mknod -m 660 /dev/lp0 c 6 0

… löste das Problem zwar in Luft auf – doch das konnte nicht der Weisheit letzter Schluss sein. Diesen Befehl bei jedem Neustart von Hand (!) auszuführen war dann wohl doch zuviel des Guten.

Einige Nachforschungen ergaben dann den finalen Hinweis:

The only explanation I can immediately think of for this is that in your
previous kernel, parallel port support was compiled into the kernel
whereas in your 2.6.8 build you have built it as a module.

Quelle: switching to kernel 2.6 – manual „modprobe lp“ to dev /dev/lop

Ach sooo, ja, meinen 2.4.25er hatte ich damals ja mit Ach und Krach selber „gebacken“!

Die Lösung

Die manuelle Erstellung von /dev/lp0 kann man sich sparen, indem man ein …

modprobe lp

… ausführt. Um das ganze zu automatisieren, genügt ein Eintrag lp auf einer neuen Zeile in der Datei /etc/modules, und beim nächsten Reboot sollte auch dieses Modul geladen und mein LPRng wieder ordungsgemäss funktionieren. Hoffen wir es.

Nebenbei

Endlich bin ich hisax_fcpcipnp losgeworden – die Fritz!Card habe ich schon lange dem Elektro-Schrott übergeben, doch aus missglückten Tests (ich hasse proprietäre, vorkompilierte Treiber, liebe AVM!) waren wohl einige Überreste im System liegen geblieben. Und so begrüsste mich bei jedem Neustart folgende Zeilen:

ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/1.1.2.3/1.1.2.2/1.1.2.2 loaded
HiSax: Linux Driver for passive ISDN cards
HiSax: Version 3.5 (module)
HiSax: Layer1 Revision 2.46.2.5
HiSax: Layer2 Revision 2.30.2.4
HiSax: TeiMgr Revision 2.20.2.3
HiSax: Layer3 Revision 2.22.2.3
HiSax: LinkLayer Revision 2.59.2.4
hisax_isac: ISAC-S/ISAC-SX ISDN driver v0.1.0
hisax_fcpcipnp: Fritz!Card PCI/PCIv2/PnP ISDN driver v0.0.1

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 14. September 2006

Tivoli Storage Manager (TSM) unter Debian Linux

Soeben habe ich den Tivoli Storage Manager Client unter Debian Linux installiert. Hier eine kurze Anleitung, um die wenigen Fallstricke gekonnt zu umschiffen:

Binaries

Zuerst benötigt man die Binaries. In meinem Fall hiess die gesuchte Datei TSM534C_LINUX86.tar und war satte 76MB gross. Diese wird freundlicherweise im Intranet bereitgestellt.

Man bezieht das Ding am Besten so:

cd /tmp
wget "http://www.domain.ch/TSM534C_LINUX86.tar"
tar xvf TSM534C_LINUX86.tar

Do you speak RPM? No!

Nun sollte man im /tmp-Verzeichnis einige Files rumliegen haben:

server:/tmp# ls -l
total 102239
-rw-r-----  1 root bin    186681 2006-04-26 10:01 LICENSE.TXT
-rw-r--r--  1 root bin     27011 2006-04-26 10:01 README_api_enu.htm
-rw-r--r--  1 root bin     92708 2006-04-26 10:01 README_enu.htm
-rw-r--r--  1 root bin     59366 2006-04-26 10:01 README_hsm_enu.htm
-rwxr-----  1 root bin     16846 2006-04-26 10:01 README.NEWDSMSCOUTD
-rw-r--r--  1 root bin   2195792 2006-04-26 10:05 TIVsm-API64.i386.rpm
-rw-r--r--  1 root bin   5324235 2006-04-26 09:59 TIVsm-API.i386.rpm
-rw-r--r--  1 root bin  16593919 2006-04-26 09:59 TIVsm-BA.i386.rpm
-rw-r--r--  1 root bin  55224942 2006-04-26 10:00 TIVsm-HSM.i386.rpm

Da schlägt doch des Debian-Aficionados Herz höher – wer liebt sie nicht, die RPMs? RHEL – das ist was für fehlgelenkte Windows-Admins! Hier im Debian-Land spricht man apt-get, dpkg und .deb.

alien, daher!

Glücklicherweise hat sich die Entwickler-Community diesem Problem angenommen:

apt-get install alien

und danach:

alien -d TIVsm-API.i386.rpm
alien -d TIVsm-BA.i386.rpm

Im /tmp liegen nun zwei neue Dateien herum:

server:/tmp# ls -l | grep .deb
total 102239
-rw-r--r--  1 root root  5313996 2006-09-14 20:10 tivsm-api_5.3.4-1_i386.deb
-rw-r--r--  1 root root 16580418 2006-09-14 20:10 tivsm-ba_5.3.4-1_i386.deb

Jetzt geht’s los!

Jetzt wird wieder in die Hände gespuckt, denn wir installieren uns das IBM-Produkt … *sing*

dpkg -i tivsm-api_5.3.4-1_i386.deb
dpkg -i tivsm-ba_5.3.4-1_i386.deb

Konfigurationsdateien

Unter /opt/tivoli/tsm/client/ba/bin erstellt man nun noch die zwei Konfigurationsdateien dsm.opt und dsm.sys mit folgendem Inhalt:

cat dsm.opt
SERVERNAME              xxx.yyy.ch

… und …

cat dsm.sys
SERVERNAME              xxx.yyy.ch
TCPSERVERADDRESS        10.0.6.70
PASSWORDACCESS          GENERATE

SCHEDLOGNAME            /var/log/tsm/schedule.log
ERRORLOGNAME            /var/log/tsm/error.log

Der Sinn eines korrekten Hostnamens

Als ich dsmc nun starten wollte, gab es diese blöde Fehlermeldung:

ANS1353E Session rejected: Unknown or incorrect ID entered

Auch das setzen der Variable NODENAME in dsm.opt resp. dsm.sys brachte nicht den gewünschten Effekt:

ANS1036S Invalid option 'NODENAME' found in options file '/opt/tivoli/tsm/client/ba/bin/dsm.opt'

… weshalb ich nicht darum herum kam, dem Server endlich den richtigen Hostnamen zu verpassen:

echo xxx.yyy.ch > /etc/hostname
/bin/hostname -F /etc/hostname

Als ich nun dsmc ausführte, war ich nach der Eingabe des Passwortes drin! Heureka.

Ohne Scheduler läuft nichts!

Deshalb nun noch der obligatorische Eintrag in /etc/inittab:

itsm::once:/usr/bin/dsmc sched > /dev/null 2>&1

… und beim nächsten Neustart sollte der Scheduler geladen werden (hoffentlich, ausprobiert habe ich es nicht – diese Datei war mir bisher unbekannt).

Um den Scheduler ohne Neustart zu laden, genügt folgender Shell-Befehl:

nohup dsmc schedule 2> /dev/null &

Drei Probleme und Lösungen

Fehler 1: Beim Starten von dmsc erscheint folgende Fehlermeldung:

dsmc: error while loading shared libraries: libgpfs.so: cannot open shared object file: No such file or directory

Es ist nötig, die Datei /etc/ld.so.conf zu erstellen (wenn sie noch nicht existiert) und folgende Zeile einzufügen:

/opt/tivoli/tsm/client/api/bin/

Danach müssen die „shared objects“ neu eingelesen werden:

ldconfig

Fehler 2: Beim Starten von dmsc erscheint folgende Fehlermeldung:

dsmc: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

Es fehlt das Debian-Paket libstdc++5:

apt-get install libstdc++5

Fehler 3: Beim Starten von dmsc erscheint folgende Fehlermeldung:

ANS9999E amsgrtrv.cpp(3087): Message No 11000 could not be found.
ANS9999E amsgrtrv.cpp(3087): Message No 11000 could not be found.
ANS0101E Unable to open English message repository 'dsmclientV3.cat'.

Ein symbolischer Link fehlt:

server:/opt/tivoli/tsm/client/ba/bin# ln -s ../../lang/en_US/

/etc/init.d/tsm

Zieht man statt der inittab ein Start-Script unter /etc/init.d/ vor, sollte dies ungefähr folgendermassen aussehen (Dank: Reto):

#!/bin/sh 

if [ $1 = "start" ]; then 
        /usr/bin/nohup /usr/bin/dsmc schedule 2> /dev/null &
        echo "Starting ADSM scheduler"
else 
        if [ $1 = "stop" ]; then 
                pid=`/bin/ps -e | /bin/grep dsmc | /bin/sed -e 's/^ *//' -e 's/ .*//'` 
                if [ "${pid}" != "" ]; then 
                        echo "Stopping ADSM scheduler" 
                        /usr/bin/kill ${pid} 
                fi 
        fi
fi

Dank

Tags:
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Donnerstag, 31. August 2006

MySQL über SSH tunneln

Heute habe ich die lang ersehnte Instanz auf einem VMWare ESX-Server erhalten und werde in den nächsten Tagen Web-Sites von einem Solaris-System auf LAMP (Debian, Apache2, PHP4, MySQL 4.0) migrieren.

Bereits wenige Stunden nach der Installation von Debian stand ich vor einem grösseren Problem: Wie kopiere ich eine über 50 MB grosse Datenbank-Tabelle vom einen auf den anderen Server? (Achtung: Es steht hier jetzt nicht zur Diskussion, ob ich die Daten richtig normalisiert habe …) Und zwar selbständig, ohne den Sysadmin der Solaris-Kiste anzuflehen, mir das Tabellenfile zum Download zur Verfügung zu stellen? Auch phpMyAdmin kam nicht in Frage: Das Ding ist gut und recht – nur würde sich die Applikation garantiert an der Grösse der Textdateien verschlucken. Wenn nicht beim Download, dann spätestens beim Upload.

Was nun? SSH ist – wie so oft – die Lösung. Das Konzept ist simpel: Auf dem Zielrechner tunnle ich Anfragen über einen bestimmten Port via SSH auf den Solaris-Rechner und habe so Zugriff auf die zu migrierende Datenbank, als würde ich lokal am Server angemeldet sein.

Drei einfache Schritte sind nötig, um eine Datenbank-Tabelle von Server A nach Server B zu verschieben:

Port Forwarding über SSH Tunnel einrichten

Auf Server B erstellt man in der Datei ~/.ssh/config eine neue SSH-Konfiguration:

Host <irgendeine Wunschbezeichnung>
Hostname <IP Server A>
User <SSH-Benutzernamen auf Server A>
Localforward <beliebiger, nicht verwendeter Port> localhost:3306

Die IP nach Hostname entspricht der IP des Servers A, auf dem die zu spiegelnde Datenbank liegt. Nach User steht der Name eines gültigen SSH-Users auf Server A. 3307 ist der lokale Port (auf Server B, der auf Server A geforwardet wird und dort auf Port 3306 endet (dem MySQL-Port, notabene).

Ist die Textdatei gespeichert, braucht man nur noch die Verbindung zu starten:

ssh <irgendeine Wunschbezeichnung>

Man sollte nicht verblüfft sein, wenn alles wie eine normale Verbindungsaufnahme zu einem SSH-Server daherkommt. Man loggt sich wie gewohnt ein und lässt die Session laufen (Verbindung nicht trennen!). Es ist von Vorteil, wenn diese Verbindung in einem screen-Terminal geöffnet wurde.

Dump anlegen

Die Verbindung besteht nun also. Port 3307 steht bereit, Daten zu empfangen und diese an Server A weiterzuleiten.

Nun gut, auf was warten wir? Spätestens jetzt sollte man das Package mysql-client installieren, da darin mysqldump enthalten ist. Genau dieses verwenden wir nun, um die Tabelle in eine Datei ins lokalen Filesystem des Servers B zu speichern:

mysqldump -h 127.0.0.1 -P 3307 -u <MySQL-Benutzernamen Server A> -p <MySQL-Datenbank Server A> --tables <MySQL-Tabelle Server A> > /tmp/dump.sql

mysqldump nimmt nun Verbindung mit dem Datenbankserver auf. Nachdem man das korrekte Passwort übermittelt hat, wird der Dump schnurstracks in das entsprechende File übertragen. Nach kaum einer Minute waren 50MB an Daten über die Leitung transferiert und in /tmp/dump.sql gespeichert worden.

Dump einspielen

Die SSH-Verbindung zu Server A kann nun gekappt werden. Jetzt bleibt nur noch eines übrig: Den Dump in die Datenbank auf Server B einzulesen. Nichts leichter als das:

mysql -u <MySQL-Benutzernamen Server B> -p <MySQL-Datenbank Server B> < /tmp/dump.sql

Sind bis hierhin keine Fehlermeldungen aufgetaucht, ist die Tabelle nun auch auf Server B anzutreffen.

PS: Ob Kollege Torquie seine unzählige Gigabytes umfassende SAP-Datenbanken auf dieselbe Art spiegelt? *grins*

Nützliche Links

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 17. Juli 2006

Bilder aus PDF extrahieren

Die meisten Power-User werden es kennen: Da hat man eine PDF-Datei vor sich, die Bilder enthält. Und an diese Bilder will man rankommen. Aber wie?

Kein Problem, wie immer eilt uns OSS zu Hilfe:

pdfimages -j datei.pdf ~/JPEGs/

Sofern das Dokument nicht geschützt ist, werden mit diesem Kommandozeilen-Befehl alle Bilder der Datei datei.pdf im Format JPEG in den angegebenen Ordner extrahiert.

Nachtrag

Folgender, leicht angepasster Befehl habe ich im August 2018 verwendet:

pdfimages -all -p datei.pdf gugus

Der Präfix resp. der Ordner gugus ist wichtig; gibt man bspw. . (Punkt) an, werden keine Bilder extrahiert. -all weist pdfimages an, jegliche Art von Bildern zu extrahieren, mit -p werden dem Dateinamen neben dem Präfix die Seiten- und Bildnummer mitgegeben.

Nachtrag 2

Damit das unter macOS klappt, muss das MacPorts-Paket poppler installiert sein.

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 7. Juli 2006

Partyguide Strikes Back


Partyguide Strikes Back I
Originally uploaded by emeidi.

Partyguide Strikes Back II
Originally uploaded by emeidi.

Gestern Donnerstag, kurz nach Mitternacht, muss es Jason und den Argonauten endgültig den Nuggi rausgejagt haben. Wenige Tage vor dem siebenjährigen Geburtstag der (in den letzten sechs Monaten wohl am häufigsten gehacktenTM) schweizerischen Party-Community blies man nun zum Gegenschlag gegen den so verhassten think eMeidi.

Die Verantwortlichen entdeckten – ob durch Hinweis eines Dritten Mitstreiters sei dahingestellt – meine Arbeiten am vierten Partyguide-Hack (JavaScript-Injection, später dazu mehr – dank an Anonymous für den ursprünglichen Tipp).

Nach stundenlangen Beratungen im Tipi des Häuptling Jasons kamen die geistreichen Argonauten zum Schluss, mit geballter Feuerkraft zurückzuschiessen. Für was verfügt man denn über genug Bandbreite und eine Vielzahl an Servern (zum Teil gar durch Gönner mitfinanziert)?

So wurde mein Debian-Server kurz nach 00:00 Uhr Ziel einer stümperhaften DoS-Attacke, die erst heute Nachmittag kurz vor 16:00 Uhr abbrach. Wie man es den beiden cacti-Graphen ansieht, äusserten sich die geballten Aufrufe meines Scriptleins, das Usernamen und Passwort-Hashes (aus dem Cookie) in Empfang nahm, sowohl in einem konstanten ein- und ausgehenden Traffic auf eth0 sowie einer stark erhöhten Load Average auf meiner schmalbrüstigen Pentium III-CPU (600MHz).

Fazit

Ein access.log, das fünfmal so schwer wiegt wie sonst:

ALPHA:/var/log/apache2# ls -l
total 44808
-rw-r--r-- 1 root adm  29612337 2006-07-08 01:01 access.log
-rw-r--r-- 1 root adm   5789490 2006-07-02 06:24 access.log.1

… und uns auch noch etwas über die Technik von Partyguide erzählt:

217.150.245.77 - - [07/Jul/2006:15:50:27 +0200] "GET /b.gif?i=84455&p=ab5c62bbb11b644fdcecd91e89acd768 HTTP/1.1" 302 - "-" "curl/7.12.1 (i686-pc-linux-gnu) libcurl/7.12.1 OpenSSL/0.9.6m zlib/1.2.2"

… sowie auch die IP des mutmasslichen „Täters“ freigibt:

84.72.129.186 - - [07/Jul/2006:00:06:25 +0200] "GET /b.gif?i=100&p=1234 HTTP/1.1" 302 20 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4"

217.150.245.77 - - [07/Jul/2006:00:29:04 +0200] "GET /b.gif?i=196828 HTTP/1.1" 302 700 "-" "curl/7.12.1 (i686-pc-linux-gnu) libcurl/7.12.1 OpenSSL/0.9.6m zlib/1.2.2"

84.72.129.186 - - [07/Jul/2006:00:30:05 +0200] "GET /b.gif HTTP/1.1" 302 224 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4"

84.72.129.186 - - [07/Jul/2006:00:30:24 +0200] "GET /b.gif?i=196828 HTTP/1.1" 302 218 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4"

Eine MySQL-Tabelle mit knapp 110’000 Records, die allesamt vom Partyguide-Server aus kamen:

mysql> SELECT COUNT( * )  FROM  `xss`  WHERE ip =  '217.150.245.77';
+------------+
| COUNT( * ) |
+------------+
|     109342 |
+------------+
1 row in set (0.47 sec)

Und nicht zuletzt ein Beweis, wie robust Debian Linux mit Apache 2.0.55, PHP 4.4.2 und MySQL 4.1.15 ist.

Fehler von meiner Seite

Das nächste Mal schalte ich E_ALL in solch sensitiven Verzeichnissen wieder aus:

[Fri Jul 07 00:29:04 2006] [error] [client 217.150.245.77] PHP Notice:  Undefined index:  p in /var/www/pg-search/xss.php on line 12

Leider Gottes ein zu guter Ansatzpunkt für potentielle PG-Hacker …

Zu guter Letzt noch dies …

Es tut mir wirklich leid, das sagen zu müssen: Anstelle eure Energie an einem kleinen Fisch wie mir zu verschwenden, unterzieht ihr all eure PHP-Scripts einmal einem richtig gründlichen Security-Audit.

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 30. Juni 2006

Apache: Address already in use

Nach einer Aktualisierung meiner Debian-Pakete kam Apache nicht mehr hoch:

Starting apache 2.0 web server...(98)Address already in use: make_sock: could not bind to address 192.168.0.101:80
no listening sockets available, shutting down
Unable to open logs
 failed!

Dank Google fand ich bald den richtigen Befehl, um den verantwortlichen Prozess ausfindig zu machen:

fuser 80/tcp

Die angezeigten Nummern entsprechen den pids (Process IDs), die man dann mittels

kill -9 <pid>

abschiesst.

Nun noch ein

/etc/init.d/apache2 start

und schon funkt man wieder im Internet.

Via: Apache – Address already in use: make_sock: could not bind to address

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 14. Juni 2006

How-To: LPRng als Print-Server

Ziel: Im Netzwerk einen Druckserver zur Verfügung zu stellen, der Aufträge mit LPR/LPD entgegennimmt und auf einem Postscript-fähigen Drucker am Parallelport ausgibt.

Obwohl sich cups nach den Anpassungen an der Konfigurationsdatei wieder starten liess, produzierte der Drucker bei Netzwerkdrucken nur noch Zeichensalat (PostScript wurde als plain/text ausgedruckt …).

Da ich unfähig war, das Problem zu beheben, entschied ich mich, auf LPRng downzugraden.

Hierzu installierte ich auf meinem Debian-Server das Paket mittels

apt-get install lprng

Danach musste ich mit viel Googeln noch die Konfigurationsdateien anpassen. Das hier ist herausgekommen:

/etc/printcap

Laserdrucker:Laserdrucker
        :server
        :cm=HP Laserjet 1300
        :lp=/dev/lp0
        :sd=/var/spool/lpd/lp
        :lf=/var/log/lprng.log
        :af=/var/log/lprng-accounting.log
        :mx=0

/etc/lprng/lpd.perm

Folgender Befehl muss auskommentiert werden, sonst können Clients im Netzwerk keine Verbindung auf Port 515 aufnehmen:

##  If you want to have connections only from programs on
##  the local host,  then uncomment the next line:
#REJECT NOT SERVER

Mit dem Befehl checkpc überprüft man die Konfigurationseinstellungen. Gibt es Fehlermeldungen, hilft

checkpc -f

Damit werden alle nötigen Verzeichnisse und Dateien angelegt und mit den richtigen Berechtigungen versehen.

Am Schluss startet man den Druckserver mit dem Befehl

/etc/init.d/lprng restart

von Hand neu.

Konfiguration der Clients

Die Clients werden nun so eingerichtet, dass sie mittels LPR (bei Windows über ‚Erweiterte UNIX-Druckdienste‘ oder ähnlich nachzuinstallieren, bei Mac OS X selbstverständlich schon dabei) auf die IP x.x.x.x drucken und dazu den Queue Laserdrucker verwenden.

Tags:
Labels: Linux

1 Kommentar | neuen Kommentar verfassen

Mittwoch, 14. Juni 2006

cupsd: Unable to read configuration file

Wer kürzlich die neueste Version von cups installiert hat und beim Starten des Daemons folgende Fehlermeldung erhält:

cupsd: Unable to read configuration file '/etc/cups/cupsd.conf' - exiting!

sollte in der cupsd.conf nach (mittlerweile) fehlerhaften IP-Notationen Ausschau halten. Bei mir waren das

Allow From 192.168.

die ich in

Allow From 192.168.0.0/24

umwandeln musste.

Via: Bug#372291: cupsd: Unable to read configuration file ‚/etc/cups/cupsd.conf‘ – exiting!

Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 4. Juni 2006

Installing snmpd on IPCop router for MRTG monitoring

Ein englischer Artikel, der bisher von meinem lokalen Server in die weite Welt „gebroadcastet“ wurde. Die deutschen (und des Englischen nicht mächtigen) Leser mögen mir verzeihen.

This article first was published several years ago when I switched from fli4l to IPCop (open source router software based on GNU/Linux).

The Task

After some days of testing I finally found out a relative simple solution to run a SNMP-Daemon on my IPCop-Router. You will like this added value when graphing traffic stats on a second server running MRTG or RRD or cacti.

Package management under Mac OS X

First of all, I had to deal with Debian-packages. This posed some problems to me, because I don’t have any linux box here except the one running IPCop, which hasn’t package-managers installed [addendum: In the meantime, I switched from Windows to Debian Linux – a reasonable choice. Bye bye Microsoft!]. After I dived into manuals for dpkg i was able to extract the files on my PowerMac running Mac OS X. Before you can execute the shell command below, you need to download and install Fink. After that, continue:

dpkg-deb -x <package>.deb <destination-dir>

Installation

You now do have the required files on your workstation, but yet they need to be put on the IPCop-box. Make use of an SFTP-Client, which requires the SSH-Service enabled on the router. With a SSH-connection to the box, I checked the error messages which occured upon start of the snmpd and then went out to look for the additional files required. The ’search file within packages‘-Function of some package-sites helped me a lot!

Packages needed

These 3 Debian-Packages are essential for your success. Download the .debs and extract them to a single folder with the command mentioned above:

  • snmpd (4.2.3-2)
  • libsnmp4.2 (= 4.2.3-2)
  • libwrap0

File locations

I had to copy all files over to IPCop manually, therefore I made this list to monitor all the files necessary.

/lib/libwrap.so.0
/usr/lib/libucdagent-0.4.2.so
/usr/lib/libucdmibs-0.4.2.so
/usr/lib/libsnmp-0.4.2.so

/usr/sbin/snmpd

You can download the files (confirmed working with IPCop 1.4.0b6) from my local server.

Caveats

Don’t try to copy snmpd.conf over to the box. In my case, it prevented snmpd to act the way it should. I have no idea where the problem lied, but after deleting snmpd.conf, everything worked fine. I hope this saves you a lot of headaches.

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen