Benutzeranmeldung mit SASL als “shell-less” Benutzer mit einem geschützten Webbereich beim Apache 2 Server unter Ubuntu 11.04

Bevor dieses kleine HOWTo funktioniert, sollte das vorherige durchgearbeitet werden. Hier wird die Installation und Inbetriebnahme der SASL Dienste beschrieben:

Installation von SASL mit Verwendung im Apache 2 unter Ubuntu 11.04

Als erstes wird ein neuer Benutzer angelegt. In diesem Abschnitt wollen wir über SASL einen Systembenutzer authentifizieren, der zwar am System ein Konto hat, aber sich nicht über SSH am System anmelden kann. Dazu dienst die Pseudoshell /bin/false. Diese Shell gibt immer “fehlgeschlagen” an den Anmeldedienst zurück. Der Benutzer kann sich somit nicht am System anmelden. Über bleibt die Anmeldung via SASL am System. Also zuerstmal den Benutzer in das System einpflegen. Unser neuer Benutzer für den Test heißt stardust.

root@antilight:~# adduser --no-create-home --shell /bin/false stardust
Lege Benutzer »stardust« an ...
Lege neue Gruppe »stardust« (1001) an ...
Lege neuen Benutzer »stardust« (1001) mit Gruppe »stardust« an ...
Erstelle Home-Verzeichnis »/home/stardust« nicht.
Geben Sie ein neues UNIX-Passwort ein:
Geben Sie das neue UNIX-Passwort erneut ein:
passwd: password updated successfully
Changing the user information for stardust
Enter the new value, or press ENTER for the default
Full Name []: Stardust
Room Number []: 23
Work Phone []: 42
Home Phone []: 64
Other []: 13
Sind diese Informationen korrekt? [J/n] j

Zack und fertig. Nun prüfen wir, ob auch alles korrekt durchgeführt wurde. Das lassen wir grep erledigen, weil wir nur kurz schauen wollen, ob auch die richtige Shell dem Benutzer zugeordnet worden ist. Schließlich kann ein fehlendes Argument, oben das hinter –shell, schnell dazu führen, dass doch der User sich anmelden kann. Kontrolle ist immer gut.

root@antilight:~# egrep "^(stardust|neurodump):" /etc/passwd
neurodump:x:1000:1000:neurodump,,,:/home/neurodump:/bin/bash
stardust:x:1001:1001:Stardust,23,42,64,13:/home/stardust:/bin/false

Fein, wir sehen das neurodump sich anmelden kann und stardust nicht. So solls sein. Jetzt müssen wir nur den benutzer auch in der httpd.conf Datei hinzufügen. Dort schaut der Apache nach, welche Benutzer was wo dürfen und so weiter.

root@antilight:~# pico /etc/apache2/httpd.conf

Geändert werden muss die Zeile. “Require user neurodump” in “Require user neurodump stardust“. Wahlweise kann die Zeile auch in diese geändert werden:

Require valid-user

Nun speichern. Damit die Änderungen aktiv werden, muss der Apache Dienst seine Config neu laden. Das erledigt folgender Befehl.

root@antilight:/var/www/protected# service apache2 reload
* Reloading web server config apache2 [ OK ]
root@antilight:/var/www/protected#

Jetzt sollte der neue Benutzer stardust nur noch zur Gruppe sasl gehören, damit alles mit den Rechten glatt geht. Das erledigt dieser Befehl.

root@antilight:/var/www/protected# adduser stardust sasl
Füge Benutzer »stardust« der Gruppe »sasl« hinzu ...
Adding user stardust to group sasl
Fertig.

Nun sollte die Anmeldung klappen. Sollte nach dem Reboot der saslauthd nicht hochkommen, weil etwas mit den init-Skripten nicht 100%ig stimmt, den kurz manuell starten. Optional:

root@antilight:/var/www/protected# service saslauthd start
* Starting SASL Authentication Daemon saslauthd [ OK ]
root@antilight:/var/www/protected#

Written on August 24th, 2011 , Interessantes, Technik Tags: , , , , , , , , , , , , , , , , ,
Installation von SASL mit Verwendung im Apache 2 unter Ubuntu 11.04

Bevor mit diesem HOWTO begonnen werden kann, muss der Apache2 Server unter Ubuntu installiert sein. Die “it works.” Seite muss entsprechend erscheinen, sollte man den Server ansprechen. Auf dem Testrechner wurde der Apache zusammen mit phpmyadmin und einem MySQL Server installiert. Entsprechend dazu wurden auch alle PHP5 Pakete soweit installiert, wie benötigt wurden. Mit dem Tool tasksel lässt sich unter ubuntu schnell ein Webserver aufsetzen.

Ist alles soweit vorbereitet kann es losgehen. Installiert werden soll SASL. Dazu soll der Apache2 Webserver so konfiguriert werden, dass ein Unterverzeichnis auf dem Webserver statt mit .htaccess mit SASL und einem Systembenutzer geschützt werden kann. Gut, los gehts.

root@antilight:~# apt-get install sasl2-bin

Damit wird der SASL Dienst auf dem System installiert. Bevor Apache mit SASL arbeiten kann, muss der Demon erst korrekt arbeiten. Dann wird Apache mit dem richtigen SASL Modul bestückt und konfiguriert.

root@antilight:~# adduser neurodump sasl

Damit der Beispielbenutzer neurodump mit sasl sich am Apache authentifizieren kann, muss dieser auch in der von dem Packet angelegten Gruppe sein. Der obige Befehl erledigt das.

root@antilight:~# su neurodump

Nun wird zu diesem Benutzer gewechselt. Es wird geprüft, ob der Benutzer sich korrekt in der Gruppe befindet. Der Befehl groups zeigt alle Gruppen an, wo der Benutzer neurodump Mitglied ist.

neurodump@antilight:/root$ groups
neurodump@antilight:/root$ exit

Mit exit geht es wieder zum Superuser zurück. Jetzt soll dem SASL Demon, also dem Dienst, Leben eingehaucht werden. Das Paket ist erstmal nur installiert, macht aber noch nichts. Dazu verwendet der Benutzer den Editor seiner Wahl und editiert die Datei unten in der Befehlszeile.

root@antilight:~# pico /etc/default/saslauthd

In dieser Datei wird das Parameter START=no auf START=yes geändert. Auf diese Weise ist nun dem SASL Demonen klar, dass er “aufleben” soll.

Jetzt wird der Dienst mit dem Blitz des root zum Leben berufen. Der Befehl service startet, stoppt und so weiter Dienste unter Ubuntu.

root@antilight:~# service saslauthd start

Nun laut rufen: “It’s alive, it’s alive!!!” (erst ab 4 Liter Club Mate) Jetzt ist genau der richtige Zeitpunkt den Demonen zu testen. Die Authentifzierung wird mit dem folgenden Befehl getestet.

root@antilight:~# testsaslauthd -u neurodump -p netzchef

Das Passwort des Benutzers wird hier in Klartext übergeben und landet damit unverschlüsselt im history file. Und auch auf dem Bildschirm für neugierige Nasen. Steht success oder Erfolg auf dem Bildschirm, so funktioniert der Demon SASL und kann richtig authentifizieren.

root@antilight:~# clear
root@antilight:~# history -c

Das Löschen der History und das Löschen der Zeilen auf dem Bildschirm gehört hoffe ich danach auch zum Standard. Am besten vielleicht vorher das Kennwort des Benutzers einfach mit passwd ändern.

Jetzt wird das Apache SASL Modul installiert. Damit wird der Apache in die Lage versetzt mit dem SASL Demon zu reden. Ohne das Modul gehts nichts.

root@antilight:~# apt-get install libapache2-mod-authn-sasl

Ist das Modul fertig installiert, muss das Modul noch im Apache aktiviert werden. Dazu ist folgender Befehl notwendig.

root@antilight:~# a2enmod authn_sasl

Damit alle Dienste auch korrekt aufeinander zugreifen können und auch nichts mit den Dateirechten vor die Wand läuft, muss der Apache Benutzer www-data ebenso wie der Benutzer neurodump in der Gruppe sasl sein. Das macht folgender Befehl.

root@antilight:~# adduser www-data sasl

Nun ist fast alles soweit fertig und der Apache Dienst kann neu gestartet werden. Das wird so erledigt.

root@antilight:~# service apache2 restart

Nun geht es an das Einrichten der geschützten Webseite. Dazu wird in das Verzeichnis des Webservers HTML Bereich gewechselt. Dort wird beispielhaft das Verzeichnis protected eingerichtet. In das Verzeichnis kommt eine leere HTML Testdatei, die nur dafür sorgt, dass beim ersten Test der Server keinen 404 wirft.

root@antilight:~# cd /var
root@antilight:/var# cd www
root@antilight:/var/www# mkdir protected
root@antilight:/var/www# cd protected
root@antilight:/var/www/protected# su neurodump
neurodump@antilight:/var/www/protected$ touch empty.html
neurodump@antilight:/var/www/protected$ exit

Damit der Webserver weiß, was er schützen soll und vor allem wie, muss dazu eine Konfiguration in die httpd.conf eingetragen werden. Dazu wird die Datei mit einem Editor aufgerufen.

root@antilight:/var/www# pico /etc/apache2/httpd.conf

Folgendes wird eingefügt:

<Directory /var/www/protected>
AuthType Basic
AuthName “Restricted”
AuthBasicProvider sasl
AuthBasicAuthoritative On
AuthSaslPwcheckMethod saslauthd
Require user neurodump
</Directory>

Nun wird die Config des Apache 2 neu geladen. Der Server weiß nun um die Änderungen und schützt das Verzeichnis. Der folgende Befehl erledigt das.

root@antilight:/var/www# service apache2 reload

Das wars schon. Jetzt sollte das Unterverzeichnis mit http://ipadresse/protected/empty.html aufrufbar sein. Der Browser sollte jetzt brav nach Benutzer und Kennwort fragen. Viel Spaß beim Ausprobieren!

Weiterführend: Benutzeranmeldung mit SASL als “shell-less” Benutzer mit einem geschützten Webbereich beim Apache 2 Server unter Ubuntu 11.04
_____________________________________________
Fassung mit fast allen Systemausgaben.
Logge dich bei deinem System mit z.B. SSH ein.

login as: root
root@10.23.32.64's password:
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-10-generic x86_64)

* Documentation: https://help.ubuntu.com/

Last login: Mon Aug 22 19:36:39 2011
root@antilight:~#

Installation des SASL Packetes unter Ubuntu 11.04. Mit apt-get ist das fix erledigt.

root@antilight:~# apt-get install sasl2-bin
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
db4.8-util
Die folgenden NEUEN Pakete werden installiert:
db4.8-util sasl2-bin
0 aktualisiert, 2 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 259 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 954 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]? J
Hole:1 http://de.archive.ubuntu.com/ubuntu/ natty/main db4.8-util amd64 4.8.30-5ubuntu2 [137 kB]
Hole:2 http://de.archive.ubuntu.com/ubuntu/ natty/main sasl2-bin amd64 2.1.23.dfsg1-5ubuntu3 [122 kB]
Es wurden 259 kB in 1 s geholt (142 kB/s)
Vorkonfiguration der Pakete ...
Vormals abgewähltes Paket db4.8-util wird gewählt.
(Lese Datenbank ... 362761 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacken von db4.8-util (aus .../db4.8-util_4.8.30-5ubuntu2_amd64.deb) ...
Vormals abgewähltes Paket sasl2-bin wird gewählt.
Entpacken von sasl2-bin (aus .../sasl2-bin_2.1.23.dfsg1-5ubuntu3_amd64.deb) ...
Trigger für man-db werden verarbeitet ...
Trigger für ureadahead werden verarbeitet ...
ureadahead will be reprofiled on next reboot
db4.8-util (4.8.30-5ubuntu2) wird eingerichtet ...
sasl2-bin (2.1.23.dfsg1-5ubuntu3) wird eingerichtet ...
update-rc.d: warning: saslauthd stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (1)
* To enable saslauthd, edit /etc/default/saslauthd and set START=yes
root@antilight:~#

Den zu verwendenden Benutzer für die Apache SASL Anmeldung in die SASL Gruppe heben.

root@antilight:~# adduser neurodump sasl
Füge Benutzer »neurodump« der Gruppe »sasl« hinzu ...
Adding user neurodump to group sasl
Fertig.
root@antilight:~#

Wechsel zu dem Benutzer. Prüfe ob der Benutzer wirklich auch in der Gruppe sasl ist.

root@antilight:~# su neurodump
neurodump@antilight:/root$ groups
neurodump adm dialout cdrom sasl plugdev lpadmin admin sambashare
neurodump@antilight:/root$ exit

Editierte die Datei /etc/default/saslauthd und stelle START=no auf START=yes.

root@antilight:~# pico /etc/default/saslauthd

Starte nun den SASL Dienst.

root@antilight:~# service saslauthd start
* Starting SASL Authentication Daemon saslauthd [ OK ]
root@antilight:~#

Prüfe ob die Authentifizierung des Benutzers, hier neurodump mit SASL funktioniert.

root@antilight:~# testsaslauthd -u neurodump -p netzchef
0: OK "Success."
root@antilight:~#

Lasse dein Kennwort, hier netzchef, besser nicht sichtbar auf dem Bildschirm und lösche es auch umbedingt aus deiner BASH History.

root@antilight:~# clear
root@antilight:~# history -c

Wenn soweit alles okay ist, bringe nun dem Apache sein SASL Modul bei. Dazu muss das Paket dazu installiert werden. Das erledigt wieder apt-get für uns. Mit den folgenden Befehlen gehts weiter.

root@antilight:~# apt-get install libapache2-mod-authn-sasl
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Die folgenden NEUEN Pakete werden installiert:
libapache2-mod-authn-sasl
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 7.580 B an Archiven heruntergeladen werden.
Nach dieser Operation werden 81,9 kB Plattenplatz zusätzlich benutzt.
Hole:1 http://de.archive.ubuntu.com/ubuntu/ natty/universe libapache2-mod-authn-sasl amd64 1.1-1 [7.580 B]
Es wurden 7.580 B in 0 s geholt (25,0 kB/s)
Vormals abgewähltes Paket libapache2-mod-authn-sasl wird gewählt.
(Lese Datenbank ... 362817 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacken von libapache2-mod-authn-sasl (aus .../libapache2-mod-authn-sasl_1.1-1_amd64.deb) ...
libapache2-mod-authn-sasl (1.1-1) wird eingerichtet ...
root@antilight:~#

Nun reicht die Installation des Paketes nicht aus. Das Paket muss im Apache Webserver auch noch korrekt aktiviert werden. Der folgende Befehl erledigt das.

root@antilight:~# a2enmod authn_sasl
Enabling module authn_sasl.
Run '/etc/init.d/apache2 restart' to activate new configuration!
root@antilight:~#

Damit auch alles mit den Rechten funktioniert, müssen diese noch kurz angepasst werden. Dazu muss der Apache Benutzer www-data auch in der Gruppe sasl sein.

root@antilight:~# adduser www-data sasl
Füge Benutzer »www-data« der Gruppe »sasl« hinzu ...
Adding user www-data to group sasl
Fertig.
root@antilight:~#

Nun muss der Apache 2 Server neu gestartet werden.

root@antilight:~# service apache2 restart
* Restarting web server apache2 ... waiting [ OK ]
root@antilight:~#

Nun wurde der Server neu gestartet. Jetzt beginnt das Einrichten der geschützten Seite. Dazu gehts in das Webverzeichnis des Apache Servers.

root@antilight:~# cd /var
root@antilight:/var# cd www
root@antilight:/var/www# ls
index.html

Nun wird ein Unterverzeichnis protected angelegt. Dort wird die geschützte Seite abgelegt werden. Mit touch wird nun eine leere HTML Datei angelegt, die nichts beinhaltet. Auf diese Weise wirft der Apache beim ersten Test keine 404 Meldung. Ersetze vielleicht die leere HTML Datei durch eine kleine “It works….” Seite.

root@antilight:/var/www# mkdir protected
root@antilight:/var/www# ls -l
insgesamt 8
-rw-r--r-- 1 root root 177 2011-08-14 18:27 index.html
drwxr-xr-x 2 root root 4096 2011-08-22 20:10 protected
root@antilight:/var/www# cd protected
root@antilight:/var/www/protected# exit
neurodump@antilight:/var/www/protected$ touch empty.html
neurodump@antilight:/var/www/protected$ ls -l
insgesamt 0
-rw-r--r-- 1 neurodump neurodump 0 2011-08-22 20:14 empty.html
neurodump@antilight:/var/www/protected$ pwd
/var/www/protected
neurodump@antilight:/var/www/protected$

Bevor der erste Test gestartet werden kann, muss der Server noch wissen, was er nun mit dem Verzeichnis machen soll. Dazu muss in der httpd.conf etwas hinzugefügt werden.

neurodump@antilight:/var/www/protected$ exit
root@antilight:/var/www# pico /etc/apache2/httpd.conf

In Datei einfügen:

<Directory /var/www/protected>
AuthType Basic
AuthName “Restricted”
AuthBasicProvider sasl
AuthBasicAuthoritative On
AuthSaslPwcheckMethod saslauthd
Require user neurodump
</Directory>

root@antilight:/var/www# service apache2 reload
* Reloading web server config apache2 [ OK ]
root@antilight:/var/www#

Nach dem Reload der Config sollte eine Anmeldung am Apache Server mit dem Systembenutzer funktionieren. Das Kennwort wird hierbei unverschlüsselt übertragen.

Hier gehts weiter: Benutzeranmeldung mit SASL als “shell-less” Benutzer mit einem geschützten Webbereich beim Apache 2 Server unter Ubuntu 11.04

Written on August 23rd, 2011 , Interessantes, Technik Tags: , , , , , , , , , , , , , , , ,
Netzwerkdaten mit tshark aufzeichnen

Hat der Benutzer seine Netzwerkbrücke geschaltet, so können die Daten, die über die Bridge fließen mitgeschrieben werden. Dazu ist das Programm tshark hervorragend geeignet. Das Paket heißt genauso, nämlich tshark, welches ggf. nachinstalliert werden muss. Installieren des Paketes einfach mit apt-get.

# apt-get install tshark

Nun sollte tshark bereit stehen. Das Programm hat viele Fähigkeiten, ein Blick in die Manpage lohnt sich. Gut, nun zu dem Aufzeichnen der Netzwerkdaten. Wurde die Bridge so aufgebaut, wie es im letzten Artikel beschrieben wurde, so lautet die Brücke br0.

# tshark -q -n -b filesize:25000 -w /meinpfad/bezeichner.pcap -i br0 &

So, Enter gedrückt und los gehts. tshark unter root zu betreiben ist gefährlich. Wie jede andere Software hat tshark hier und da möglicherweise einen Fehler. So ist es einem Angreifer möglich, der weiß, dass mit tshark aufgezeichnet wird, Code in diesen Prozess zu injizieren. Da dieser nun mal in unserem Beispiel mit root läuft, hat derjenige dann vollen Zugriff auf das gesamte System. Also: Konfiguriere einen User und definiere vorher korrekt alle Rechte und starte tshark mit so wenig Rechten, wie nötig.

Was wurde oben mit den ganzen Parametern alles mitgereicht? -q definiert den Quiet-Mode. Tshark werkelt, aber redet nicht sonderlich viel mit dem Benutzer. Das Parameter -n deaktiviert die Namensauflösung via DNS. Die Hostnamen erscheinen nun als IP Adressen. Wir wollen hören und mitschneiden, später kann geschaut werden, welcher Hostname zu welcher IP gehört. Mit dem Parameter -b filesize:xxxxx wird angegeben, wie groß die Datei werden darf, bis tshark eine neue anlegt. Sehr nützlich, da viele Analysetools nicht umbedingt Gigabytes einlesen mag. Der Wert wird in KB angegeben. 25 MB also 25000 ist ein schöner Wert. -w gibt den Zielpfad der Dateien an. Der Bezeichner wird als Präfix später genutzt. -i gibt das Interface an, hier wählen wir die Bridge br0.

Viel Spaß! :-)

Written on August 21st, 2011 , GRML-Box, Interessantes, Technik Tags: , , , , , , , , , ,
Tastaturlayout umstellen unter Ubuntu

Warum auch immer sowas öfters passiert…. Trotz der Auswahl einer deutschen Tastatur ist nach einer Ubuntu Server Installation das Layout der Tastatur US. Abhilfe schafft das Paket console-data.

# apt-get install console-data

Wenn das Paket noch nicht installiert wird, kann der Benutzer nun sein Wunschlayout wählen, in meinem Fall qwertz und german. Poff. Schon ist alles gut. Sollte das Paket bereits installiert so gibt es Abhilfe mit:

# dpkg-reconfigure console-data

Viel Spaß!

Written on August 8th, 2011 , Interessantes, Technik Tags: , , , , , , , , , , , , ,
Installation von CAPI4HylaFax unter Kubuntu 10.04

Nachdem beschrieben wurde, wie eine AVM Fritz!Card unter Linux zum Laufen zu bewegen ist und wie entsprechend die CAPI Schnittstelle eingerichtet werden muss, wird jetzt ein weiterer Schritt folgen. Das Verwenden der CAPI Schnittstelle mit HylaFax. Verwendet wurde hier Kubuntu 10.04 bzw. Ubuntu in der gleichen Version. Als Treiber der hier angesprochen fcpci Treiber, der entsprechend gepatched worden ist. Für einige Konfigurationsangelegenheiten wird das Paket dialog benötigt, falls es nicht bereits installiert worden ist. Der Anwender gibt ein:

# apt-get install dialog

Nun ist es an der Zeit das Paket für CAPI4HylaFax zu installieren. Wieder bemühen wir apt-get.

# apt-get install capi4hylafax

Nachdem das Paket installiert worden ist, müssen einige Konfigurationsänderungen durchgeführt werden. Falls nicht schon geschehen, werden die Rechte der CAPI Schnittstelle geändert. Der Benutzer uucp und die Gruppenmitglieder in der Gruppe dialout sollen auf diese zugreifen können. Hierzu gibt der Anwender folgendes ein:

# chown -R uucp:dialout /dev/capi*

Nun wird zur Gruppe dialout die Gruppe uucp hinzugefügt. Die dazu nötigen Informationen stehen in der Datei /etc/group. Diese wird mit einem Editor geöffnet. Jede Zeile beinhaltet eine Einstellung, so sucht der Benutzer die korrekte Zeile die ungefähr so lauten könnte: dialout:x:20:username. Hinter den Benutzernamen wird entsprechend die Gruppe eingetragen. Also lautet die Zeile dann folgendermaßen:

dialout:x:20:username,uucp

HylaFax verwendet standardmäßig das Gerät /dev/faxCAPI, um auf die CAPI-Schnittstelle zuzugreifen. Unsere CAPI-Schnittstelle liegt aber auf /dev/capi*, als Wildcard für meistens /dev/capi20. Unnötiges Geschrubbel soll vermieden werden, also lassen wir /dev/faxCAPI auf /dev/capi20 verweisen. Dies geschieht mit einem symbolischen Link, der auf das Dateisystem geschrieben wird. Um das zu bewerkstelligen, geben wir folgendes ein:

# ln -s /dev/capi20 /dev/faxCAPI

Nun wird alles von /dev/faxCAPI zu /dev/capi20 umgeleitet. Beim Systemneustart allerdings sind die Einstellungen nicht mehr vorhanden. Zumindest nicht alle. Die Rechte werden durch die Defaultwerte überschrieben. Also wird ein Startscript angepasst, das jene Dinge für uns macht, die sonst per Hand erledigt werden müßten. Dieses Script exestiert unter /etc/rc.local. Nun wird diese Datei mit einem Editor geöffnet und entsprechend angepaßt.

# pico /etc/rc.local

Diese Datei sollte folgendermaßen aussehen.

#!/bin/sh -e
#
# rc.local
#
/bin/chown -R uucp:dialout /dev/capi*
/bin/ln -s /dev/capi20 /dev/faxCAPI
/etc/init.d/capi4hylafax restart
/etc/init.d/hylafax restart

exit 0

Nun ist es fast soweit. Kleine weitere Änderungen müssen noch verrichtet werden, damit alles korrekt läuft. Die Datei /etc/default/capi4hylafax muss leicht angepaßt werden. Die Einstellung run_capi4hylafax muss auf true, also auf 1 gesetzt werden. Dies sieht in der Datei so aus:

run_capi4hylafax=1

Die obige Datei ist natürlich recht lang und besteht nicht nur aus einer Zeile. Nun wird die Datei /etc/default/hylafax etwas angepaßt.

# pico /etc/default/hylafax

In dieser Datei werden zwei Zeilen verändert. RUN_HYLAFAX wird entsprechend auf true, also 1 gesetzt und USE_FAXGETTY wird auf no, also nein, gesetzt. Es soll ja kein analoges Modem verwendet werden, sondern die CAPI Schnittstelle.

USE_FAXGETTY=no
RUN_HYLAFAX=1

Jetzt muss eine Datei in dem Verzeichnis /etc/init angelegt werden. Diese Datei lautet hylafax.conf.

# touch /etc/init/hylafax.conf

Diese Datei wird wieder mit einem Editor geöffnet und folgende Zeile wird eingefügt:

T5:23:respawn:/usr/bin/c2faxrecv

Nun die Datei /etc/hylafax/config bearbeiten, um folgende Zeilen zu ändern. Die Datei ist länger, hier sind nur die Änderungen aufgeführt.

# pico /etc/hylafax/config

SendFaxCmd: "/usr/bin/c2faxsend"
DialStringRules: "etc/dialrules"
InternationalPrefix: 011
SendFaxCmd: "/usr/bin/c2faxsend"
Use2D: "no"
MaxTries: 1
MaxDials: 3

Nun sollte geprüft werden, ob das Paket psrip installiert ist. Wenn nicht muss dieses nachinstalliert werden.

# apt-get install psrip

Nun muss die Datei /etc/hylafax/setup.cache verändert werden. Hier wird eine neue Zeile eingefügt.

IMPRIP='/usr/bin/psrip'

Nun die Datei /etc/hylafax/config.faxCAPI wieder mit einem Editor öffnen und entsprechend bearbeiten.

# pico /etc/hylafax/config.faxCAPI

SpoolDir: /var/spool/hylafax
FaxRcvdCmd: /usr/bin/c2faxrecv
PollRcvdCmd: /var/spool/hylafax/bin/pollrcvd
FaxReceiveUser: uucp
FaxReceiveGroup: dialout
LogFile: /var/spool/hylafax/log/capi4hylafax
LogTraceLevel: 4
LogFileMode: 0600
{
HylafaxDeviceName: faxCAPI
RecvFileMode: 0666
FAXNumber: +49.800.123456
LocalIdentifier: "DEIN NAME"
MaxConcurrentRecvs: 2
OutgoingController: 1
OutgoingMSN: 89012345
SuppressMSN: 0
NumberPrefix:
UseISDNFaxService: 0
RingingDuration: 0
{
Controller: 1
AcceptSpeech: 1
UseDDI: 0
DDIOffset: "12345"
DDILength: 3
IncomingDDIs:
IncomingMSNs: "8901234"
AcceptGlobalCall: 0
}
}

Nun die Dienste neu starten. Das geht so:

# /etc/init.d/hylafax restart
# /etc/init.d/capi4hylafax restart

Wenn keine Fehlermeldungen erscheinen, kann entsprechend nun gefaxt werden. Kabel anstecken nicht vergessen. Faxen geht in der Konsole so:

sendfax -n -d Faxnummer Datei.ps

Viel Spaß.

Written on May 20th, 2010 , Interessantes, Technik Tags: , , , , , , , , , , , , , , , ,
Installation einer AVM!Fritz ISDN PCI Karte unter ubuntu 10.04

Für Anfänger ist die Installation einer ISDN Karte nicht immer einfach. Es gibt viele verschiedene Kartentypen, einige sind sehr günstig zu beschaffen, einige weniger. In erster Linie wird hier die Installation einer A1 Karte (PCI) behandelt. Besser, allerdings auch teurer, arbeitet die B1 Karte, da sie das System durch eine interne CPU weniger belastet und zusätzlich die Treiberunterstützung besser sein soll. Zu meinem Erstaunen hat AVM keine vernünftig funktionierde Treiber für A1 Karten für die aktuellen Linux Versionen bereitgestellt. Mit den Suchmaschinen konnte schließlich eine Variante von Lutz Willek, die für die Kernelversionen 2.6.24 bis 2.6.28 gepatched wurde, beschafft werden. Kubuntu/Ubuntu 10.04 hat einen neueren Kernel. Auch mit diesem funktionieren die Treiber einwandfrei.

Der Treiber kann hier geladen werden: fritz-fcpci-src-2.6.31.zip
Nun wird von vorne begonnen. Die Kubuntu bzw. Ubuntu 10.04 Installation ist normal abgeschlossen und alles funktioniert soweit. Für das Ändern von Textdateien kann pico/nano oder schlicht der Midnight Commander (mc) verwendet werden. Die Pakete müssen ebenso nachinstalliert werden. Hat der Anwender einen Editor seiner Wahl, dann sollte dieser installiert werden.

Als erstes müssen die Kernel-Header installiert werden, damit der Treiber kompilieren werden kann. Das erledigt fix apt-get mit entsprechenden root-Rechten. Der Anwender gibt ein:

# apt-get install linux-headers-2.6.32-21-generic

An dieser Stelle muss angemerkt werden, dass dies die Kernel-Header von der Kubuntu 10.04 sind. Wurde ein anderer Kernel installiert, so müssen entsprechend diese Header installiert werden. Nun werden die benötigten Teile des Compilers installiert, damit überhaupt etwas übersetzt werden kann. Die nötigen Bestandteile werden mit dem Paket build-essential installiert. Der Anwender gibt ein:

# apt-get install build-essential

Nun wird die Linux CAPI installiert, damit die ISDN Karte auch später mit der Außenwelt sprechen kann. Dazu sind drei Pakete nötig: capi-utils, libcapi20-3 und libcapi20-dev. Dazu wird das Paket pppdcapiplugin installiert. Dazu gibt der Anwender ein:

# apt-get install capi-utils
# apt-get install libcapi20-3
# apt-get install libcapi20-dev
# apt-get install pppdcapiplugin

Das Paket libcapi20-3 wird sehr wahrscheinlich in Abhängigkeit mit capi-utils automatisch mitinstalliert. Das Eingeben des Befehls schadet nicht, es erscheint ggf. die Meldung, dass dieses Paket bereits installiert worden ist.

Nun ist es an der Zeit die Sourcen des Fritz-Karten Treibers zu entpacken. Geeignet ist das Home-Verzeichnis des normalen Benutzers. Entpackt werden kann entsprechend mit Root, entsprechende Rechte werden für die Kompilierung benötigt. Nun kopiert der Anwender die komprimierte Datei in ein Verzeichnis seiner Wahl. Bei .tar.gz Dateien lautet das Parameter -xvzf. Zum Entpacken wird folgendes eingegeben:

Originalfile von Lutz Willek:
# tar -xvjf fritz-fcpci-src-2.6.31.tar.bz2

Oben zur Verfügung gestelltes Zip-File:
# unzip fritz-fcpci-src-2.6.31.zip

Jetzt muss definiert werden, um welche Prozessor-Architektur es sich handelt, worauf der Treiber kompiliert und gestartet werden soll. Handelt es sich um einen 32-Bit Prozessor, so muss die 32-fcpci-lib.o verlinkt werden. Kann der Prozessor 64-Bit Befehle verarbeiten und ist auch ebenso ein entsprechender Kernel installiert, was meist bei der Installation automatisch entschieden wird, so muss die Datei 64_fcpci-lib.o verlinkt werden. Beispielsweise handelt es sich bei einem Pentium 4 um einen 32-Bit Prozessor, während ein AMD Phenom 64-Bit fähig ist. Besteht an dieser Stelle Unsicherheit, so hilft Wikipedia entsprechend weiter. Der Anwender wechselt in das lib-Verzeichnis des Source-Codes.

# cd fritz-fcpci-src-2.6.24-2.6.31
# cd lib

In diesem Verzeichnis existieren zunächst einmal drei Dateien, nämlich 32_fcpci-lib.o, 64_fcpci-lib.o und fcpci-lib.o. Bei der letzten Datei handelt es sich um einen Dummy, der ausgetauscht wird durch einen sog. symbolischen Link, der auf eine der anderen Dateien verweisen wird. Die Dummy-Datei hat 0 Byte. Der Dateiname wird kurz gemerkt und die Datei wird gelöscht.

# rm fcpci-lib.o

Nun muss ein neuer symbolischer Link erzeugt werden, der entsprechend Zugriffe auf diesen Namen zu einer anderen Datei umleitet.

# ln -s 64_fcpci-lib.o fcpci-lib.o
Für 64-Bit Prozessoren eingeben

# ln -s 32_fcpci-lib.o fcpci-lib.o
Für 32-Bit Prozessoren eingeben

Soll überprüft werden, ob die Verlinkung funktioniert hat, so kann dies leicht mit dem Befehl ls -l gemacht werden. Hat alles geklappt findet sich ein Eintrag, ähnlich wie dieser: fcpci-lib.o -> 64_fcpci-lib.o

Nun ist die Voreinstellung abgeschlossen. Jetzt wird entsprechend in das Verzeichnis fcpci-3.11.07 gewechselt.

# cd ..
# cd fcpci-3.11.07

In diesem Verzeichnis befinden sich entsprechend die c-Dateien und die make-Dateien. Falls mit dem Code bereits gearbeitet wurde, sollte vorhei ein make clean ausgeführt werden, um alte Binärdateien zu löschen. Der Befehl make all erzeugt nun automatisch die entsprechend Kernelobjekte.

# make all

Hat alles geklappt ist nun viel auf dem Bildschirm erschienen und es existieren einige neue .ko Dateien im gleichen Verzeichnis. Jetzt müssen die Dateien an die richtige Stelle kopiert werden. Dazu wird zunächst ein Verzeichnis angelegt, wo diese Objekt für den Kernel abgelegt werden. Der Anwender gibt ein:

# mkdir /lib/modules/`uname -r`/extra

Jetzt werden die Kernel-Objekts in dieses Verzeichnis kopiert. Entsprechend wird folgendes eingegeben:

# cp fcpci.ko /lib/modules/`uname -r`/extra

Nun muss entsprechend das neue Objekt eingerichtet werden. Dies erledigt der Befehl depmod.

# depmod -a

Jetzt ist das Kernel-Objekt bereit und kann geladen werden. Der Befehl modprobe wird Kernel-Objekte laden und entladen. Es wird zunächst das Kernel-Modul geladen und anschließend getestet, ob es auch geladen worden ist.

# modprobe -rf fcpci
# modprobe -v fcpci

Hat alles geklappt, nun freuen. Oft funktioniert es an dieser Stelle gerade nicht. Es erscheint eine Fehlermeldung …device or ressource busy… Kein Grund zur Panik. Ein anderes Kernel-Modul verhindert das Laden von fcpci. Dabei handelt es sich häufig um das Modul mit dem Namen avmfritz. Dies kann wiederum mit modprobe entladen werden. Anschließend der neue Versuch mit den neuen Treibern.

# modprobe -r avmfritz
# modprobe -rf fcpci
# modprobe -v fcpci

Hat alles funktioniert, so erscheint unten im Text eine entsprechende zweizeilige Erfolgsmeldung. Das ist schonmal ganz gut, allerdings wird beim Neustart des System das Problem wieder auftreten. Damit das vermieden wird, so ist es nötig entsprechend dem System klar zu machen, dass es das Modul avmfritz nicht mehr lädt. Das Setzen von avmfritz auf eine Blacklist schafft dauerhaft Abhilfe und fcpci kann beim Start normal laden. Es wird eine neue Datei erzeugt.

# pico /etc/modprobe.d/blacklist-avmfritz.conf

In dieser Datei wird folgendes eingetragen:

blacklist avmfritz

Die Zeile bitte mit einem Enter abschließen, so dass der Cursor links unter dem Text steht. Nun speichern und neu starten. Entsprechend wieder einloggen und in die Root-Console wechseln.

Die ISDN Karte ist nun installiert. Jetzt muss die CAPI eingerichtet werden. Hierzu gibt es einen seperaten Blogeintrag.

Mehr dazu bei: Installation von CAPI4Hylafax
Auch nützlich hierzu: CAPI einrichten unter Ubuntu 10.04

Written on May 6th, 2010 , Interessantes, Technik Tags: , , , , , , , , , ,
X: cannot stat /etc/X11/X (No such file or directory), aborting.

In Ubuntu 6.06 ließ sich trotz normaler Installation nicht der XServer starten. Es erschien, folgende Fehlermeldung.

X: cannot stat /etc/X11/X (No such file or directory), aborting.

Erscheint dieser Fehler oben, so fehlt etwas wichtiges, nämlich der X-Server. Der Splashscreen anfangs erscheint, der so ein wenig grafisch ist, aber nichts mit dem X-Server zu tun hat. Der Anfänger sollte sich hier nicht täuschen lassen. Anschließend versucht gdm oder kdm bzw. der Manager Ihrer Wahl den X zu starten. Das klappt aber nicht. Nicht immer wird eine Ausgabe erzeugt. Hat sich der Benutezr unter der Console eingeloggt (Strg+Alt+1 usw.) so bekommt er meist mit startx etc. eine entsprechende Meldung wie oben.

Warum auch immer der X-Server bei der Installation nicht immer mitinstalliert wurde… Abhilfe schafft das Packet xserver-xorg, dass folgendermaßen installiert wird.

# apt-get install xserver-xorg

Nun befindet sich der xorg X-Server auf dem System und kdm, wdm, gdm und so weiter sollte nun entsprechend starten. Natürlich sollte ein Window-Manager ihrer Wahl nicht fehlen, kde bzw. gnome oder fluxbox sollte ebenso installiert werden. Natürlich gibt es auch die stark resourcenschonenden Oberflächen, falls RAM und Leistung sehr knapp sind, aptitude hilft entsprechend bei der Auswahl.

Written on May 5th, 2010 , Interessantes, Technik Tags: , , , , , , , , ,
Aktivieren des universe APT Repository in Ubuntu 6.06 für PHP4

Ich habe sehr alte Skripte, die nur unter PHP4 laufen. Natürlich könnten diese auf PHP5 angepasst werden, aber dazu ist keine Zeit und vermutlich auch sehr wenig Lust vorhanden. Also ein älteres Linux mit PHP4 ausstatten und gut ist. Natürlich lassen wir die Sicherheitsaspekte an dieser Stelle außen vor. Das System sollte intern verwendet werden und möglich keinen Internetzugang haben. Sonst ist man möglicherweise fix nicht mehr alleine.

Der Benutzer wird schnell feststellen, dass nach der einfachen Ubuntu 6.06 Installation kein PHP4 Paket mit apt-cache angezeigt wird. Eine kleine Anpassung in /etc/apt/sources.list schafft hier Abhilfe.

Editieren der Datei mit root-Rechten.
# pico /etc/apt/sources.list

Folgende Zeilen sollten dort vorhanden sein:

deb http://archive.ubuntu.com/ubuntu/ dapper main restricted
deb-src http://archive.ubuntu.com/ubuntu/ dapper main restricted

Diese Zeilen etwas anpassen, etwa so:

deb http://archive.ubuntu.com/ubuntu/ dapper main restricted universe
deb-src http://archive.ubuntu.com/ubuntu/ dapper main restricted universe

Speichern und folgendes ausführen:
# apt-get update

Dies updated das Repository und fügt entsprechend alle Dateien, die in universe vorhanden sind in apt ein.

Written on May 5th, 2010 , Interessantes, Technik Tags: , , , , , ,

Projekt: Neurodump is proudly powered by WordPress and the Theme Adventure by Eric Schwarz
Entries (RSS) and Comments (RSS).

Projekt: Neurodump

Gedankenauszüge eines Datenreisenden