Das hier fand ich eines Morgens in meiner Achselhöhle, pardon, im
Changelog von KDE2.1:
> External taskbar re-added
Ich deute das ja so, dass man nun wieder die Liste der aktiven
Programme aus der Kontrollleiste herauslösen kann, um sie etwa wie
in KDE1.x an den oberen Rand des Bildschirms zu kleben. Mittlerweile
habe ich aber alle Menüpunkte von Kcontrol durchwühlt - es geht
nicht. Oder ich kann es nicht.
Hat das schon mal einer geschafft? Oder wo kann ich nachlesen? Die
KDE-Hilfe bezieht sich auf KDE 2.0 und meint, das das erst in der
nächsten Version gehen soll (irrt sich aber an einigen Stellen).
Gruß,
Alfred
Tomas Duewiger wrote:
>
> On 6 Apr, Michael Schreyer wrote:
>
> > Hi die Frage mag zwar etwas veraltet sein aber seis drum.
> >
> > Wer kann mir sagen, was ich machen muss, damit meine Gravis Ultrasound
> > PNP laute von sich gibt?
> >
> > Im Kernel hab ich sie Aktiviert. /dev/dsp und /dev/audio ist auch
> > aktiviert. IRQ und I/O stimmen. Sie gibt aber trotzdem keinen Ton von
> > sich. Ich hab auch schon ma versucht mit einem Mixer die Lautstärke zu
> > erhöhen aber ohne Erfolg. Ich weis keinen Rat mehr.
>
> Hast Du denn das ganze PnP Gelumpe konfiguriert? pnpdump? Linux muss
> erstmal wissen dass die Karte da ist.
>
> Tomas
>
Also die isapnp.conf hab ich konfiguriert. Die stimmt. Muss man denn
noch was anderes konfigurieren?
--
Michael Schreyer ŽExodus`
PGP available
ICQ #7284996
--
Um aus der Liste ausgetragen zu werden, eine Mail an majordomo(a)suse.com
schicken, mit dem Text: unsubscribe suse-linux
Hallo Liste,
ich möchte mit "skype" telefonieren.
Habe mir deshalb eine neue Soundkarte
(C-Media Electronics Inc CM8738) gekauft.
"skype" und diese Soundkarte funktionieren so weit, auch scheint das
Mikrofon zu tun (höre mich selbst) -nur kommt beim Gesprächspartner
kein Ton an (ich kann den anderen hören).
Habe zwar diverse Problemlösungen er-googelt aber leider keine die mir
weiter hilft...
Habe einen Desktop-PC Pentium II, Suse 8.2, Soundkarte C-Media
Electronics Inc CM8738 (Terratec, Aureon 5.1), funktionierendes Mirko
und im Kmixer ist das Mikro auch an geschaltet (mich selbst kann ich
ja hören).
thomas82@linux:~> /sbin/lspci
00:00.0 Host bridge: Intel Corp. 440LX/EX - 82443LX/EX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corp. 440LX/EX - 82443LX/EX AGP bridge (rev
03)
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 01)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:08.0 Multimedia audio controller: C-Media Electronics Inc CM8738
(rev 10)
00:0b.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 05)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC
AGP (rev 3a)
thomas82@linux:~>
und
thomas82@linux:~> /sbin/lspci -n
00:00.0 Class 0600: 8086:7180 (rev 03)
00:01.0 Class 0604: 8086:7181 (rev 03)
00:07.0 Class 0601: 8086:7110 (rev 01)
00:07.1 Class 0101: 8086:7111 (rev 01)
00:07.2 Class 0c03: 8086:7112 (rev 01)
00:07.3 Class 0680: 8086:7113 (rev 01)
00:08.0 Class 0401: 13f6:0111 (rev 10)
00:0b.0 Class 0200: 8086:1229 (rev 05)
01:00.0 Class 0300: 1002:475a (rev 3a)
thomas82@linux:~>
?
Kann mir jemand weiter helfen?
Vielen Dank,
Thomas
--
Ein Herz für Klicky_Bunti_GUI-Fans!
Hallo,
nx tut immer noch nicht. Es gab ja hier schon einige Threads. Der
entscheidende Tipp fehlt noch.
habe:
FreeNX-0.4.1-1.1.i586.rpm
NX-1.5.0-9.1.i586.rpm
knx-0.1-10.1.i586.rpm
vom SuSE Server auf SuSE 9.2 installiert.
Dann "nxsetup --install --setup-nomachine-key" laufen lassen.
zur Sicherheit noch ein "nxserver --restart"
Eine Verbindung zum Server per "knx" tut nicht.
Ich habe mal "ssh -i /usr/share/knx/client.id_dsa.key nx@suse-server"
laufen lassen. Wenn die keys zusammenpassen, müsste ich nun als nx
eingeloggt werden.
Mein Rechner will aber ein Passwort!
Wenn ich mich zum Vergleich mit einer debian-Kiste verbinde tut es:
ssh -i /usr/share/knx/client.id_dsa.key nx@debian-kiste
HELLO NXSERVER - Version 1.4.0-04 OS (GPL)
NX> 105
quit
Quit
NX> 999 Bye
Connection to debian-kiste closed.
Was könnte faul sein?
ssh funktioniert sonst.
Rupert
Hallo,
ich habe hier ein Problem mit Moneyplex und dem Chipkartenleser Cyberjack(USB
mit Tastatur, ohne Display). Der Kartenleser wird von Moneyplex erkannt und
der Funktionstest verläuft positiv.
Anmelden (in Moneyplex) funktioniert auch, nur wenn ich versuche die Umsätze
zu aktuallisieren meldet Moneyplex: "Der Zugriff auf die Chipkarte war nicht
erfolgreich. Decipher: Der Chipkartenleser kann nicht angesprochen werden.
Die Verbindung zur Bank wird getrennt."
Die Rechte bzgl. ttyUSB0 stimmen, der Benutzer ist in der Gruppe uucp und
ttyUSB0 hat folgende Rechte:
aaron@tux:~/tmp> ls -l /dev/ttyUSB*
crw-rw---- 1 root uucp 188, 0 2005-10-09 16:32 /dev/ttyUSB0
Mein System: AMD Athlon 64 3000+
SuSE Linux 10.0
Moneyplex 2004/v5.0 (Kaufversion)
Hat eine Idee zur Lösung?
Gruß, Aaron
Hi,
wollte mal rumfragen, ob es sich empfiehlt, das Kernel Update für 10.0
von suser-agirardet einzuspielen, das per apt über
[ftp://ftp4.gwdg.de/pub/linux/suse/apt SuSE/10.0-i386 suser-agirardet]
erhältlich ist.
Die Quelle hat Install-apt4suse automatisch hinzugefügt - könnte man
also eigentlich als "sicher" betrachten. Allerdings bin ich am Zweifeln,
ob man neue Kernels nicht nur von SuSE installieren sollte...
By the way, weiß jemand, welche Source azareus zur Verfügung stellt?
Grüße, David
--
David Geiger
info(a)david-geiger.de <mailto:info@david-geiger.de>
Hallo,
ich habe vor einigen Tagen SuSE Linux 9.3 auf einem AMD-Opteron-
basierten System eingerichtet (Mainboard: Tyan Thunder K8SE (S2892),
Chipsatz: NVIDIA nforce4 Professoinal). Das Mainboard hat einen
S-ATA-Controller integriert. Insgesamt sind aktuell vier S-ATA-
Platten angeschlossen.
Soweit läuft alles problemlos:
- Die vier Platten werden als "sda", "sdb", "sdc" und "sdd" via
"libata" erkannt und können problemlos angesprochen werden (etwas
schade ist, dass "smartctl" noch nicht zugreifen kann, aber das
ist eine andere Sache).
- Von den vier S-ATA-Platten laufen jeweils zwei zusammen in einem
Software-RAID1-Verbund, und die beiden RAID1-Verbünde bilden ein
phsyikalisches LVM-Volumeset.
Siehe hierzu auch:
| fsa01-neu:~ # cat /proc/scsi/scsi
| Attached devices:
| Host: scsi0 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: ST3200822AS Rev: 3.01
| Type: Direct-Access ANSI SCSI revision: 05
| Host: scsi1 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: ST3200822AS Rev: 3.01
| Type: Direct-Access ANSI SCSI revision: 05
| Host: scsi2 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: ST3200822AS Rev: 3.01
| Type: Direct-Access ANSI SCSI revision: 05
| Host: scsi3 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: ST3200822AS Rev: 3.01
| Type: Direct-Access ANSI SCSI revision: 05
Jetzt soll in einigen Monaten noch ein "richtiger" SCSI-Hostadapter in
die Maschine eingebaut werden (Adaptec 29160 Ultra160 SCSI adapter),
der sich zur Zeit noch in einem anderen Rechner befindet. An diesen
Adaptec-Adapter sollen zwei weitere SCSI-Festplatten (und ein Streamer)
angeschlossen werden.
Meine Frage nun: Wie verhindere ich nun, dass die zwei SCSI-Festplatten
die Devicenamen der S-ATA-Platten "nach hinten" verschieben?
Ich hätte gerne, dass die S-ATA-Platten weiterhin "sda", "sdb", "sdc"
und "sdd" heißen und die SCSI-Platten dann als "sde" und "sdf" an-
schließen. Ich habe aber die Befürchtung, dass sich der SCSI-Controller
quasi "vordrängelt".
Seht Ihr eine Möglichkeit, das zu verhindern (z.B. durch eine Modul-
Option)? Wo wird die Reihenfolge festgelegt?
Soweit ich weiß, ist, wenn ich zwei "echte" SCSI-Einsteckadapter hätte,
in der Regel die Nummer des PCI-Slots ausschlaggebend. In meinem Fall
habe ich aber einen Onboard-S-ATA-Controller und einen PCI-SCSI-Adapter,
da kann ich nur begrenzt "umstecken".
Oder muss ich ein Verschieben der Devicenamen einfach hinnehmen und
eventuell die Devices der RAID-Sätze ändern?
Ich bedanke mich im Voraus für alle Antworten!
Viele Grüße,
Steffen
Hallo zusammen,
ich versuche seit einiger Zeit einem Linuxrechner beizubringen sich an
einem DomänenController anzumelden und ein Homeverzeichnis von einem
Windows Fileserver zu mounten.
Die Sache mit dem Anmelden funktioniert mittels Winbind und Kerberos
auch ohne Probleme.
Nur das Verzeichnis wird nicht mit pam_mount gemountet. Es kommt bei
einer Anmeldung über SSH immer folgende Fehlermeldung:
pam_mount: error trying to retrieve authtok from auth code
Es sieht so aus, als ob pam_mount kein Passwort übergeben bekommt. Das
komische ist, dass es bei einer lokalen Anmeldung funktioniert. Auch
wenn ich mittels su Benutzername den User wechsel wird das Verzeichnis
gemountet. Nur über SSH leider nicht.
Beim Abmelden wird das Verzeichnis leider in keinem Fall wieder
"geunmountet". Das System meckert immer darüber, dass es ich nicht
root sei und somit kein umount ausführen könnte. Chmod 4755 habe ich
da auch schon probiert.
Ich würde mich freuen, wenn jmd. eine solche Konstellation schon mal
zum laufen gebracht hat und mir helfen könnte. KonfigFiles schicke ich
auf anforderung gerne an die Liste.
Folgende Software wird eingesetzt:
Samba (inkl. Winbind) 3.0.20-21 (SuSE von ftp.sernet.de)
OpenSSH 0.9.7e
pam_mount
pam_mkhomedir
SuSE 9.3 Prof.
Kerberos
Die Server laufen unter Windows Server 2003
Vielen Dank für evtl. Anregungen
Gruß
Ansgar Brauner
Hallo,
ich habe seit einigen Wochen einen AMD-Opteron-basierten File-Server
im Testeinsatz. Auf dieser Maschine ist SuSE Linux 10.0 installiert,
als Kernel läuft ein Vanilla-2.6.14.
Am Samstag um 10:30 Uhr hat "cron.daily" das Kommando "logrotate" ge-
startet. So weit - so gut.
Gegen Mittag wollte ich mich remote via SSH auf der Maschine einloggen.
Zwar kam ich noch bis zur Passwortabfrage des SSH-Clients, aber dann
hing das Login. Andere Dienste, die auf das ebenfalls auf dieser Ma-
schine gehaltene OpenLDAP-Verzeichnis zugreifen wollten, hingen eben-
falls.
Der auf der selben Maschine laufende Webserver dagegen publizierte zur
gleichen Zeit die vorhandenen Test-Webseiten absolut problemlos.
Ich fuhr dann am Samstagnachmittag hin zum Standort des Servers und
stellte fest: Auch an der Konsole ist kein Login mehr möglich. Eben-
falls war nichts Spannendes auf der Konsole, die per "ALT+F10" erreich-
bar ist, zu finden. Die Maschine an sich lief aber noch. Der darauf
laufende Webserver antwortete einwandfrei und performant.
Nach einem Reset lief der Rechner wieder "normal".
Interessant war: Seit 10:30:01 Uhr gab es keine Logfile-Einträge in
"/var/log/messages" bzw. "/var/log/warn" mehr.
Also gut - ich dachte, der OpenLDAP-Server hatte sich aufgehängt und
daher Probleme mit dem Login gemacht. Ich hatte anschließend auch in
"/etc/ldap.conf" Timeout-Parameter gesetzt, damit im Falle eines nicht
erreichabren OpenLDAP-Servers das PAM nicht ewig wartet, sondern lo-
kale Benutzer "zur Not" auch bei nicht funktionierendem OpenLDAP-Server
reinlässt. Also gut - getestet - Login klappt zur Not auch ohne einen
laufenden OpenLDAP-Server nach einem gewissen Timeout von 30 Minuten.
Über die Tatsache, weshalb seit 10:30:01 Uhr kein Logfile-Eintrag
mehr geschrieben wurde, machte ich mir dort aber noch keine Gedanken.
Nächstes Ereignis:
Am Sonntag war ich schon am frühen morgen per SSH einloggt (besser ge-
sagt - ich hatte die Shell noch vom Samstagabend her offen, und hatte
den ganzen Sonntag noch nicht auf der Maschine gearbeitet). Gegen 14
Uhr wollte ich mich mit einer weiteren Shell einloggen, da ich zwei
Kommandozeilenfenster zum Server haben wollte für diverse Arbeiten.
Aber: Das selbe Problem wie am Tag zuvor: Auf der zweiten Shell war
kein Login möglich. SSH-Daemon fordert (ziemlich träge) das Passwort
an und macht nach Eingabe desselben gar nichts mehr.
Ich beendete und restartete in der ersten Shell diverse Dienste, da
ich dachte, sie seien evtl. für das Verhalten verantwortlich. Nichts
zu sehen. Auch nichts, was massenhaft CPU oder Speicher in Anspruch
nahm.
Dann blickte ich nach "/var/log/messages" und sah mir gegen 14 Uhr
die letzten Ausgaben an:
| Oct 30 09:30:02 fsa01-neu slapd[5549]: conn=0 op=583 SRCH base="dc=egu,dc=schule,dc=ulm,dc=de" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=squid))"
| Oct 30 09:30:02 fsa01-neu slapd[5549]: conn=0 op=583 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
| Oct 30 09:30:02 fsa01-neu slapd[5549]: <= bdb_equality_candidates: (uid) index_param failed (18)
| Oct 30 09:30:02 fsa01-neu slapd[5549]: conn=0 op=583 SEARCH RESULT tag=101 err=0 nentries=0 text=
| Oct 30 09:30:02 fsa01-neu syslog-ng[4813]: SIGHUP received, restarting syslog-ng
| Oct 30 09:30:03 fsa01-neu slapd[5549]: conn=0 op=584 SRCH base="dc=egu,dc=schule,dc=ulm,dc=de" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=man))"
Ah ja. Die Maschine hatte die ganze Nacht durch diverse Meldungen
der OpenLDAP-DB nach "/var/log/messages" geschrieben. Ist ja auch
okay.
Aber um 09:30 Uhr, genau 24 Stunden nach dem Log-Stopp am Samstag
(-> Zeitumstellung) hört das Logging erneut auf.
Nach einem Restart des "syslog-ng"...
| Oct 30 14:39:09 fsa01-neu syslog-ng[5985]: syslog-ng version 1.6.8 starting
...konnte ich mich dann problemlos wieder einloggen:
| Oct 30 14:39:14 fsa01-neu sshd[5889]: Accepted keyboard-interactive/pam for root from 10.0.0.1 port 35203 ssh2
Nun habe ich nicht darauf geachtet, ob der "syslog-ng" tot war oder
gar nicht mehr lief.
Mein Verdacht war dann:
"logrotate" schickt (wenn es was zu rotieren gibt) - laut der Da-
tei "/etc/logrotate.d/syslog" ein "/etc/init.d/syslog reload". Das
wiederum dürfte ein "SIGHUP" senden.
Heute (Montag) ist nichts passiert. "syslog-ng" loggt einwandfrei
und neue SSH-Connections sind auch kein Problem. Aber heute hat
"logrotate" auch nichts zum Rotieren gehabt. Also auch keine "post-
rotate"-Kommandos, und damit kein "/etc/init.d/syslog reload".
Seltsamerweise kann ich das Aufhängen (oder Beenden) des "syslog-ng"
nicht provozieren, indem ich den "/etc/init.d/syslog reload" manuell
ausführe. Ich warte jetzt also ab bis "logrotate" wieder rotiert.
Die Fragen, die sich mir stellen, sind jetzt:
- Warum "spinnt" der "syslog-ng" herum, wenn er ein HUP-Signal ge-
sendet bekommt? Warum hört er dann mit dem Logging auf?
- Hat dieses Verhalten denn sonst schon jemand beobachtet, ins-
besondere unter SuSE Linux 10.0 x86_64?
Die neusten SuSE-Updates dürften alle eingespielt sein. Bis auf
den Vanilla-2.6.14-Kernel sind eigentlich keine großartigen Ver-
änderungen an der Standardinstallation vorgenommen worden.
- Wie verhält sich denn ein Rechner, bei dem der Syslog-Daemon gar
nicht mehr läuft? Kann es tatsächlich zu dem von mir beobachteten
Fall kommen, dass nach einer gewissen Zeit die Dienste, die loggen
wollen, hängen?
Wenn ich das richtig sehe, schreiben die Dienste, die loggen wollen,
in das "named socket" unter "/dev/log" rein. Was aber passiert, wenn
dort niemand mehr rausliest? Puffert der Kernel eine Weile? Und erst
nach einer gewissen Anzahl an Meldungen passiert's?
Denn, wenn ich den "syslog-ng" manuell beende, kann ich mich (zumin-
dest unmittelbar danach) noch problemlos via SSH einloggen oder an-
dere Dienste benutzen, die loggen (z.B. OpenLDAP-Anfragen stellen).
Längere Zeit hatte ich den Syslog-Daemon bisher nicht absichtlich
beendet lassen.
Oder treten die Hänger der Applikationen nur dann auf, wenn Syslog-
Daemon-Prozess zwar noch läuft, sich aber aufgehängt hat?
Fragen über Fragen. Vielleicht weiß ja hier jemand weiter oder kann
zumindest Details zur Arbeit des Syslog-Daemons sagen. Ich wollte
auf jeden Fall mal auf Nummer sicher gehen, bevor ich an SuSE einen
Bug melde bzgl. "syslog-ng".
Danke und Grüße,
Steffen
