Dieser Bereich steht für häufig gestellte Fragen (frequently asked questions) und besondere Tips und Tricks zur Verfügung. Für Vorschläge und Ergänzungen hierzu einfach ein E-Mail an das LUG Team.
Abhilfe:
Es macht sicherlich Sinn von Zeit zu Zeit sein ext2-Filesystem auf seine
Integrität hin zu prüfen und Inkonsistenzen zu fixen.
Wer jedoch z.B beim Testen neuer Kernelkonfigurationen ist und sein Linux
deshalb mehrmals hintereinander booten muß,
läuft leicht Gefahr in die standardmäßig gesetzten 20 Mounts der
Rootpartiton zu fahren.
Dann ist eine Kaffeepause von u. U. mehreren Minuten angesagt, jenachdem
wie groß die Partition ist und wieviel Daten darin enthalten sind.
Das muß nicht sein wie folgendes Beispiel zeigt:
Mittels tune2fs -l [Rootpartition bei mir /dev/sdf1] wird die
aktuelle Konfiguration der Platte angezeigt.
In der Zeile "Maximum mount count" steht nun nach wie vielen
Bootvorgängen ein Check durchgeführt werden soll.
Mit tune2fs -c n [Rootpartion] kann der Wert auf "n"
Mountvorgänge verändert werden, bis der nächste
Routinecheck durchgeführt wird.
Aber bitte bei der Wahl von "n" daran denken, daß ein Filesystemcheck
irgendwann auch mal sein muß ;)
(rf)
Abhilfe:
Diese Meldung wird z.B. bei RedHat 6.0/Mandrake 6.0 oder auch bei SuSE 6.1
alle 20 Minuten ins syslog geschrieben.
Zum Abstellen (ohne negative Auswirkungen) muß man als root in
/etc/syslog.conf folgenden Eintrag zu der Zeile hinzufügen,
die für die Console (/dev/console) bzw. für die syslog-Datei
(z.B. /var/log/messages) zuständig ist:
;mark.none
Damit sieht z.B. unter RedHat 6.0/Mandrake 6.0 die entsprechende Zeile in /etc/syslog.conf folgendermaßen aus:
*.info;mail.none;authpriv.none;mark.none /var/log/messages
(sp)
Abhilfe:
(sp)
Manchmal kann es sinnvoll sein, auch als normaler Benutzer das System ordnungsgemäß herunterzufahren. Das sollte natürlich auch ohne Neuanmeldung als 'root' Benutzer möglich sein. Da das bei Debian GNU Linux standardmäßig nicht eingestellt ist, gibt es hier ein kleines Workaround. Dabei müssen die nachfolgend aufgelisteten Schritte abgearbeitet werden:
Es ist denkbar, daß diese Anleitung auch auf anderen Linux Distributionen mit geringen oder gar keinen Änderungen anzuwenden ist.
(oe)
WARNUNG: Nachfolgende Anleitung ist nur für User geschrieben, die wissen wie man einen Kernel aus den Quellen übersetzt und installiert.
Um obengenanntes Kartenlese- und Schreibgerät unter Linux 2.2 und 2.4 nutzen zu können, müssen die Kernelquellen geändert und neu übersetzt werden. Es sollte selbstverständlich sein, daß auch USB Unterstützung, SCSI-Emulation und "Probe all LUNs" im Kernel aktiviert sein muß.
Die Datei /usr/src/linux/drivers/usb/storage/unusual_devs.h editieren und folgendes am Ende hinzufügen:
UNUSUAL_DEV( 0x0aec, 0x5010, 0x0100, 0x0100,
"Card Reader/Writer", "soligor card reader/writer",
US_SC_SCSI, US_PR_BULK,
NULL, US_FL_FIX_INQUIRY),
Danach werden die Kernelquellen wie gewohnt übersetzt und installiert.
Nach einem Neustart mit dem neuen Kernel sollte dann mit dmesg etwa folgendes bzw. ähnliches zu finden sein:
# dmesg .... scsi0 : SCSI emulation for USB Mass Storage devices Vendor: Card Rea Model: soligor card read Rev: 0100 Type: Direct-Access ANSI SCSI revision: 02
(oe)
Sollte obige Fehlermeldung beim Beenden von X auftreten, muß die Datei /etc/X11/XF86Config geändert werden. Dazu die Datei in einen Editor laden und in dem Abschnitt "Files" die Zeile 'FontPath "unix/:7100"' suchen. Den Port 7100 vom Fontserver auf Port 7110 ändern. Jetzt den XServer neu starten und die Fehlermeldung sollte nicht mehr erscheinen.
Ausschnitt aus /etc/X11/XF86Config:
Section "Files"
FontPath "unix/:7110" # local font server
Auszug der Meldung nach dem Beenden von XFree86:
Build Operating System: Linux 2.4.24-1-k7 i686 [ELF]
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/XFree86.0.log", Time: Tue Apr 20 11:36:36 2004
(==) Using config file: "/etc/X11/XF86Config"
Could not init font path element unix/:7100, removing from list!
waiting for X server to shut down
(oe)
Mit Quell-RPM-Paketen (*.src.rpm) lassen sich Binärpakete für die eigene Distribution neu erstellen, um z.B. nicht standardmäßig verfügbare Software nachzuinstallieren, die Konfiguration des Standardpaketes zu modifizieren oder hardwareoptimiert zu kompilieren.
Quell-RPM-Pakete enthalten den Quellcode der Software als Original-Tarball, eventuelle Patches und eine Steuerdatei (*.spec), mit deren Hilfe sich das Binärpaket erstellen läßt. Im Unterschied zu den Binärpaketen werden Quell-RPM-Pakete bei der Installation nicht in der RPM-Paketdatenbank registriert; sie lassen sich auch nicht über den normalen rpm-Mechanismus (rpm -e paketname) aus dem Dateisystem löschen. Der Inhalt des Pakets wird durch die Installation lediglich in das Dateisystem an eine definierte Stelle gespielt. Zum Entfernen müssen die Dateien von Hand gelöscht werden.
Die Ablage dieser Dateien ist je nach Distribution etwas unterschiedlich; genaueres zeigt Tabelle 1.
| Distribution | Basisverzeichnis | Berechtigungen |
|---|---|---|
| RedHat | /usr/src/redhat | drwxr-xr-x |
| SuSE | /usr/src/packages | drwxrwxrwt |
| Mandrake | /usr/src/RPM | drwxr-xr-x |
Man erkennt leicht, dass die reklameträchtige Namensgebung durch RedHat, die ja als Erfinder dieses Paketsystems gelten, von den Nachahmern nicht gerne aufgenommen wurde, sondern eine Abwandlung nach eigenem Geschmack fand. Alle direkt von RedHat abgeleiteten Distributionen wie z.B. Fedora oder Centos haben die Originalbezeichnung beibehalten.
Weiterhin fällt das bei SuSE veränderte Berechtigungsmuster auf, was hier den Vorteil hat, dass man ohne weiteren Konfigurationsaufwand auch als normaler Benutzer Quell-RPM-Pakete installieren und in diesem Verzeichnisbaum neue Binärpakete bauen kann. Bei RedHat und Mandrake ist das so nur als root möglich, wovon aber entschieden abzuraten ist.
Im folgenden sei eine Konfiguration beschrieben, die es unter allen rpm-basierten Distributionen (auch SuSE) erlaubt, das Bauen von rpm-Paketen im privaten Heimatverzeichnis durchzuführen. Dieses Vorgehen hat auch den Charme einer etwas vereinfachten Datensicherung.
Zunächst wird eine Konfigurationsdatei mit Namen .rpmmacros erstellt, die im Heimatverzeichnis angelegt wird und folgenden Inhalt haben soll:
%_topdir %(echo $HOME/var/rpm) %_tmppath %(echo $HOME/var/tmp) %packager Vorname Name <gueltige@e-mail.adresse>
Mit dem %packager-Eintrag identifiziert man sich als Ersteller von rpm-Paketen, durch die beiden anderen rpm-Makros werden zwei rpm-Variablen auf Verzeichnisse innerhalb des Heimatverzeichnisses des Benutzers gesetzt. Diese beiden Verzeichnisse müssen, wenn sie noch nicht existieren, anschließend angelegt werden:
mkdir -p ~/var/rpm ~/var/tmp
Im Verzeichnis ~/var/rpm werden nun eine Reihe von Standardverzeichnissen angelegt, die später als Ablage für unterschiedliche Aufgaben dienen:
cd ~/var/rpm/ mkdir BUILD RPMS SOURCES SPECS SRPMS cd RPMS/ mkdir athlon i386 i486 i586 i686 noarch
Die Konfiguration ist damit schon abgeschlossen, so dass nun Quell-RPM-Pakete in diesen Verzeichnisbaum installiert werden können. Dazu reicht das Ausführen des folgenden Kommandos mit einem Quell-RPM-Paket nach persönlichem Geschmack bzw. Interesse:
rpm -i paketname.src.rpm
Den Quellcode des Pakets sowie eventuelle Patches findet man nun unter ~/var/rpm/SOURCES. Weiterhin wurde eine Steuerdatei installiert, die sich unter ~/var/rpm/SPECS befindet. Mit Hilfe dieser Steuerdatei kann man nun ein neues Binärpaket bauen. Dazu wechselt man in das Verzeichnis ~/var/rpm/SPECS und führt folgendes Kommando aus:
rpmbuild -ba paketname.spec
Wer rpm in einer Version < 4.0 einsetzt, muß an dieser Stelle statt rpmbuild das Kommando rpm verwenden. Durch das rpm-Tool gesteuert, wird nun der Quellcode entpackt (unter ~/var/rpm/BUILD), eventuelle Patches eingespielt, der Quellcode kompiliert, in ein temporäres Verzeichnis (unter ~/var/tmp) installiert und anschließend ein neues architekturabhängiges Binärpaket (unter ~/var/rpm/RPMS/<arch>) sowie ein Quellpaket (unter ~/var/rpm/SRPMS) erzeugt. Das Binärpaket kann anschließend in gewohnter Weise installiert werden.
Der Prozess der Paketerzeugung läuft natürlich nur dann störungsfrei durch, wenn alle notwendigen Bibliotheken und sonstige benötigte Software installiert sind. Oft kann es vorkommen, dass noch Entwicklungspakete (devel) nachinstalliert werden müssen.
(gs)
In /etc/smb.conf muß der Eintrag encrypt passwords = yes gesetzt werden. (s.a. WinNT.txt in der Samba Dokumentation unter /usr/doc/samba* bei RedHat bzw. /usr/share/doc/packages/samba* bei SuSE).
Abhilfe:
Im /sbin/connect Skript gibt es in der Funktion "Line_OK" u.U. eine
falsche Abfrage:
[...] if [ -n "`imontty | grep $PHONE | grep outgoing`" ] [...]
Die Abfrage nach "outgoing" mußte in "Out" geändert werden
(Groß-/Kleinschreibung ist wichtig!).
Was genau abgefragt werden muß kann folgendermaßen herausgefunden werden:
(sp)
Da es bei analogen Anlagen vorkommen kann, daß die letzte Ziffer "verstümmelt" wird, hängt man sie einfach nochmal dran. Die Telekomiker sagen zwar, man solle "#" (Raute) verwenden, der Doppler ist jedoch sicherer. Dann wird aus der Einwahlnummer 0191011 einfach 01910111.
Auf dem per Einschreiben zugestellten Dokument sind verschiedene Nummern enthalten (Anschlußkennung, T-Online-Nr., Kennwort). Der Benutzername setzt sich zusammen aus Anschlußkennung (inkl. führender Nullen!) direkt gefolgt von der T-Online-Nummer. Daran schließt sich das Doppelkreuz (#) an, aber nur,falls die Anschlußkennung weniger als 12 Stellen hat. Dann kommt noch die auf 4 Stellen aufgefüllte Mitbenutzerkennung. Das Kennwort wird - welch Wunder - 1:1 übernommen ;)
Beispiel 1:
Anschlußkennung 12-stellig
Anschlußkennung 00 00 08 15 08 16
T-Online-Nummer 0123456789
Mitbenutzernummer 1
Daraus folgt als Benutzerkennung: 00000815081601234567890001
Beispiel 2:
Anschlußkennung 11-stellig
Anschlußkennung 0 00 08 15 08 16
T-Online-Nummer 0123456789
Mitbenutzernummer 1
Daraus folgt als Benutzerkennung: 000081508160123456789#0001
Logisch, oder?
(sp)
Lösung: Nach langem hin und her mit der T-Online-Hotline wurde
festgestellt, daß falls der gewünschte Alias die Buchstabenkombination
"pop" enthält, also z.B. in Poppi@t-online.de, dieser mit einer
irreführenden Fehlermeldung abgewiesen wird. Eine genaue Erklärung
konnte allerdings nicht gegeben werden. Damit bleibt nur die
Möglichkeit, einen anderen Alias zu verwenden, oder evtl. einen Remailer
wie GMX zu verwenden, der diese Einschränkung erwiesenermaßen nicht hat.
(sp)
URL: http://www.lug-burghausen.org/dienste/faq.html
Letzte Änderung 26.12.2005