expertenaustausch > linux.debian.user.german

Jan Kohnert (14.09.2005, 23:10)
Ulrich Fürst schrieb:

> Wohin logt den pam?


Das kommt ganz darauf an, was du deinem Syslogdaemon dazu gesagt hast.
Für syslog-ng könnte es etwa so aussehen:
destination authlog { file("/var/log/auth.log"); };

für syslog beispielsweise so:
auth,authpriv.* /var/log/auth.log

Aber ob da Fehler geloggt werden, wenn irgendein source $FILE nicht
funktioniert, wage ich zu bezweifeln (nun gut, es könnte sein, daß es eine
debug-log Funktion in PAM gibt, ähnlich wie in CUPS, aber da bin ich
überfragt)

> Ulrich


MfG Jan
Andreas Pakulat (14.09.2005, 23:30)
On 14.09.05 22:45:39, Ulrich Fürst wrote:
> Andreas Pakulat <apaku> wrote:
> > On 13.09.05 23:03:37, Ulrich Fürst wrote:

> Ohne das export tut's aber genauso.


Hmm, das wuerde bedeuten du liest das in der /etc/profile oder evtl. in
$HOME/.bash_profile (oder ~/.profile) ein. Mit anderen Worten: Variablen
ohne export sind nur in der aktuell gestarteten Shell gueltig und wenn
in deinen XTerms diese Variablen so gesetzt sind, bedeutet es dass sie
in der Login-Shell gesetzt werden.

> > Dann macht irgendeine deiner bash-configs ungefaehr das hier:
> > . /etc/environment

> Hab aber nichts gefunden:
> # egrep -RH "/etc/environment" /etc/*


Guck doch mal in $HOME, Kandidaten sind .bash*, .profile, .login (wenn
ich mich nicht taeusche), .xinitrc und .xsession. Mehr fallen mir da
jetzt nicht ein.

> # egrep -RH "\. /etc/environment" /etc/*


Es koennte auch "source /etc/environment" sein.

> Kann es sein das er das export als Variable sieht, sprich auch zwei
> Variablen in einer Zeile gehen und dann halt in irgendeinem Log eine
> unauffällige Fehlermeldung steht?


Da fragst du ehrlich gesagt den falschen. Wie PAM diese Datei auswertet
weiss ich nicht.

> Wohin logt den pam?


Wenn ich mich nicht taeusche ins auth.log.

Andreas
Ulrich Fürst (14.09.2005, 23:50)
"Ulrich Fürst" <fuerst.ulrich> wrote:
> Kann es sein das er das export als Variable sieht, sprich auch zwei
> Variablen in einer Zeile gehen und dann halt in irgendeinem Log eine
> unauffällige Fehlermeldung steht?
> Wohin logt den pam?


Also ich hab's jetzt einfach mal ausprobiert (mit zwei unauffälligen
garantiert nicht anderweitig vergebenen Variablen):

ohne export funktionierts
mit export funktioniert ebenso
nein zwei variablen in einer Zeile funktionieren nicht er nimmt den
Teil bis zum ersten "=" als Variable den Rest als Wert. (Sofern bis zum
ersten "=" kein Leerzeichen kommt!

Zeile wie:
tu mal=eins mach_mal=zwei
werden komplett ignoriert.

Ulrich
Michael Rex (15.09.2005, 00:20)
Quoth Michael Bienia:
> Also bei zsh wurde vor kurzem UTF-8 Unterstützung eingebaut. zsh-beta
> aus unstable soll das können.
>


Ich hab vor ein paar Tagen mal die zsh-beta in Testing ausprobiert, da
konnte ich immerhin schon Umlaute eingeben, aber Umlaute im Pfad wurden
immer noch nicht richtig dargestellt. Weiß jetzt nicht, welche Version das
war, werde mir nochmal die aktuelle Version ansehen.

Naja, momentan kann (muß) ich damit leben, gibt ja leider keine brauchbare
Alternative zur zsh ;-)

Bye,
Michael
Michael Rex (15.09.2005, 00:30)
Quoth Andreas Pakulat:
> Wobei da aber das Problem ist: Wenn bei einer Datei nicht angegeben ist,
> welches Encoding benutzt wird, _muss_ dass Programm irgendeine Annahme
> machen. Denn wie schon gesagt, aus dem Inhalt kann man leider nicht aufs
> Encoding schliessen.


Tja. Dabei wäre die Lösung doch so einfach: XML für alles, da kann man ja
ein Encoding angeben ;-)

Ok, ernsthaft. Das Problem sollte ja hauptsächlich bei einfachen Textdateien
auftreten. Bei irgendwelchen speziellen Dokumentformaten ist das meistens
irgendwo festgelegt oder im Dokument angegeben.

> Naja, kopete hatte das letzte Mal auch noch Probleme beim ICQ - aber das
> ist schon ne Weile her...


Scheinen gelöst zu sein, jedenfalls ist mir beim Test vor kurzem nichts
derartiges aufgefallen. Leider kann Kopete nicht mit Licq mithalten, also
werde ich wohl noch ein Weilchen Probleme mit ICQ haben.

Bye, Michael
Michael Rex (15.09.2005, 00:50)
Quoth Markus Schulz:
>> Das Problem habe ich auch, liegt aber nicht daran, daß die anderen
>> kein UTF8 kennen, sondern irgendwo bei Licq selbst, wie ich nach
>> einigem googlen herausgefunden habe.

> beziehst du dich dabei auf Fehler #203346 ?


Nein, auf irgendeine Diskussion, auf die ich beim Googeln gestoßen bin. Auf
der licq-devel-Liste, wenn ich mich noch richtig erinnere. Da kam man wohl
zu dem Ergebnis, das das Problem bei Licq liegt. Da die da sicher mehr
Ahnung von Licq-Interna haben, vertraue ich einfach mal auf diese
Einschätzung ;-)

> Weil licq kann ja nicht dafür verantwortlich gemacht werden wenn der
> Windows Client gegenüber die UTF8 Umlaute nicht versteht. Und genau das
> Problem hatte _ich_.


Wer weiß. Irgendwie wird es dem Gegenüber ja auch sagen müssen, welches
Encoding es verwendet.

> Allerdings ist mir jetzt auch aufgefallen, das wenn ich Umlaute von
> Windows Usern bekomme diese nicht ordentlich nach UTF8 konvertiert
> werden (das ist in dem Fehler #203346 auch gemeint) wie es eigentlich
> passieren müßte. Der Weg hin zum Windows Client sollte doch kein licq
> Problem sein oder ist im icq Protokoll eine locale fest vorgeschrieben?


Tja, ich habe beide Probleme. Wobei ich nicht weiß, wie meine Umlaute bei
den anderen so ankommen, bisher hat nur einer mal was gesagt. Bei mir
kommen zumindest von niemandem die Umlaute richtig an.

>> Hm, mit der Einstellung hab ich auch mal rumgespielt, brachte aber
>> leider keine Besserung. Muß ich mir wohl nochmal anschauen.

> also das funktioniert bei mir wunderbar. Hab seitdem trotz UTF8 Umgebung
> keine fehlerhaften Umlaute mehr in licq.


Welche Version hast du? Bei mir läuft 1.2.7, vielleicht liegt's ja daran.

Bye,
Michael
Andreas Pakulat (15.09.2005, 00:50)
On 15.09.05 00:08:18, Michael Rex wrote:
> Ok, ernsthaft. Das Problem sollte ja hauptsächlich bei einfachen Textdateien
> auftreten. Bei irgendwelchen speziellen Dokumentformaten ist das meistens
> irgendwo festgelegt oder im Dokument angegeben.


Nein, das tritt leider nicht nur bei Textdateien auf, z.B. id3v1-Tags,
da gibts kein Feld fuer das Encoding, bei id3v2 existiert es zwar, aber
es wird meines Wissens von keinem id3-Tag-Editor oder id3-Tag-"Leser"
interpretiert - sprich ist so gut wie nicht existent. Damit weisst du
nicht wirklich in welchem Format die id3-Tags sind. die libtag1 fuer
KDE-Programme nimmt latin1 an, xmms nimmt die locale (sehr gut zu sehen,
wenn man latin1-Kodiert hat und ne UTF-8 Umgebung)... Zum Glueck hab ich
nur noch ogg's - da ists immer UTF-8 :-)

Ich denke es gibt noch weitere nicht-Textfiles die betroffen sind, auch
wenn mir grad nichts einfallen will...

> > Naja, kopete hatte das letzte Mal auch noch Probleme beim ICQ - aber das
> > ist schon ne Weile her...

> Scheinen gelöst zu sein, jedenfalls ist mir beim Test vor kurzem nichts
> derartiges aufgefallen. Leider kann Kopete nicht mit Licq mithalten, also
> werde ich wohl noch ein Weilchen Probleme mit ICQ haben.


Ich nutze gaim, aber auch nur, weil ich da die Smilies von Trillian
haben kann...

Andreas
Michael Rex (15.09.2005, 00:50)
Quoth Andreas Hemel:
> Das ging mir genauso, bis mir aufgefallen ist, dass es nicht nur die
> Einstellung in den Optionen gibt, die hatte ich auch immer umgestellt
> ohne eine Veränderung zu bemerken.
> Es gibt aber in dem Fenster in dem man die Nachrichten schreibt oben
> rechts noch einen Button, mit dem man den Zeichensatz ändern kann. Als
> ich den auf "Western European" umgestellt hab, kamen die Umlaute in
> beide Richtungen wieder korrekt an.


Danke, werde ich mal ausprobieren. Den habe ich zwar auch schon gesehen,
aber ich habe gedacht, daß die Einstellung in den Optionen gilt, wenn man
im Chatfenster nichts spezielles einstellt, deshalb hab ich den gar nicht
weiter beachtet.

Bye, Michael
Markus Schulz (15.09.2005, 01:20)
Am Donnerstag, 15. September 2005 00:22 schrieb Michael Rex:
> Quoth Markus Schulz: [...]
> Welche Version hast du? Bei mir läuft 1.2.7, vielleicht liegt's ja
> daran.


die 1.3.0 aus sid. (auf Arbeit die Sarge Version, ob das dort auch
funktioniert kann ich momentan nicht sagen)
Habe dort im Chatfenster (Button oben rechts) auf iso8859-15 gestellt
und seitdem keine Probleme mehr mit Umlauten.(im Optionsmenu auch
latin9 eingestellt)
Wenn ich dort auf meine locale (UTF8) umstelle, meckern alle meine
Windows Kollegen das meine Umlaute kaputt wären.
Im übrigen scheint er sich die locale Einstellung pro Chatpartner zu
merken.
Andre Bischof (16.09.2005, 17:20)
Andre Bischof schrieb:
> Hallo Ulrich,
>>> root@linux:~# cat /etc/environment
>>> LANG=de_DE@euro
>>> Sollte ich dort (oder woanders?) evtl. noch weitere Angaben zu
>>> LC_CTYPE und charmap machen? Wie müßten diese Einträge dann aussehen?
>>> So?


Hallo,

ich hab jetzt mal diverse Einstellungen bei LC_TYPE und charmap
ausprobiert, und dabei zufällig entdeckt, dass meine Zeichensatzprobleme
in joe nur für den Benutzer root existieren, nicht für meinen "normalen"
User. Beide lesen aber aus /etc/joe/joerc, eine .joerc im
Homeverzeichnis gibt es nicht.

Hat da jemand 'ne Idee, warum das für root nicht funktioniert?

Viele Grüße
André
Michael Rex (22.09.2005, 02:50)
Quoth Markus Schulz:
> die 1.3.0 aus sid. (auf Arbeit die Sarge Version, ob das dort auch
> funktioniert kann ich momentan nicht sagen)
> Habe dort im Chatfenster (Button oben rechts) auf iso8859-15 gestellt
> und seitdem keine Probleme mehr mit Umlauten.(im Optionsmenu auch
> latin9 eingestellt)
> Wenn ich dort auf meine locale (UTF8) umstelle, meckern alle meine
> Windows Kollegen das meine Umlaute kaputt wären.
> Im übrigen scheint er sich die locale Einstellung pro Chatpartner zu
> merken.


Ok, ich habe jetzt mal etwas damit rumgespielt. Mittlerweile kommen meine
Umlaute meistens richtig an. Die Einstellung in den Optionen scheint
irgendwie nichts auszusagen, nur die Einstellung im Chatfenster scheint zu
zählen. Was mich noch etwas wundert ist, daß anscheinend manche Leute mit
demselben Client UTF-8 verstehen, manche nur ISO-8859-15. Naja, solange ich
weiß, bei wem was funktioniert, ist mir das egal.

Bye, Michael
Michael Rex (22.09.2005, 03:10)
Quoth Andreas Pakulat:
> On 15.09.05 00:08:18, Michael Rex wrote:
> Nein, das tritt leider nicht nur bei Textdateien auf, z.B. id3v1-Tags,
> da gibts kein Feld fuer das Encoding, bei id3v2 existiert es zwar, aber
> es wird meines Wissens von keinem id3-Tag-Editor oder id3-Tag-"Leser"
> interpretiert - sprich ist so gut wie nicht existent. Damit weisst du


Hm. Also ich erstelle die Tags meiner MP3s mit easytag und als Player
verwende ich amaroK. Bisher hat das noch immer geklappt. Ob jetzt id3v1
oder id3v2 ist mir relativ egal. Wobei id3v1 wenn ich mich da recht
erinnere auch noch eine Längenbeschränkung für die einzelnen Einträge hat,
was mir schon weitaus öfter negativ aufgefallen ist als Zeichensatz-
probleme.

Zumindest zeigt amaroK auch alte MP3s, die ich noch mit ISO-5589-15 gerippt
habe, korrekt an.

> nicht wirklich in welchem Format die id3-Tags sind. die libtag1 fuer
> KDE-Programme nimmt latin1 an, xmms nimmt die locale (sehr gut zu sehen,
> wenn man latin1-Kodiert hat und ne UTF-8 Umgebung)... Zum Glueck hab ich
> nur noch ogg's - da ists immer UTF-8 :-)


Hm. Xmms scheint bei mir garnicht mit UTF-8 zurechtzukommen, egal mit
welcher Locale die Tags erstellt wurden. Und Ogg verbietet sich bei mir
schon automatisch. Leider kommen die wenigsten Player damit zurecht, und
selbst wenn würde ich sicher nicht meine ganzen MP3s in Ogg konvertieren.
So taub bin ich noch nicht, daß ich nach zweifacher verlustbehafteter
Kompression keinen Unterschied bemerken würde ;-)

> Ich denke es gibt noch weitere nicht-Textfiles die betroffen sind, auch
> wenn mir grad nichts einfallen will...


Ok, mag sein. Mir fiel halt nur das ein, was auch heißt: mir ist sonst noch
kein Problem mit anderen Formaten aufgefallen. Was natürlich nicht heißt,
daß es keins gäbe. Aber solange das mich nicht betrifft, bin ich
zufrieden :-)

>> Scheinen gelöst zu sein, jedenfalls ist mir beim Test vor kurzem nichts
>> derartiges aufgefallen. Leider kann Kopete nicht mit Licq mithalten, also
>> werde ich wohl noch ein Weilchen Probleme mit ICQ haben.

> Ich nutze gaim, aber auch nur, weil ich da die Smilies von Trillian
> haben kann...


Ich nutze Licq, weil ich Smilies lieber in ASCII sehe. Unter anderem. Und
die Zeichensatzprobleme habe ich mittlerweile dank dieser Mailingliste auch
lösen können.

MfG,
Michael
Andreas Pakulat (22.09.2005, 17:20)
On 22.09.05 02:42:08, Michael Rex wrote:
> Quoth Andreas Pakulat:
> > On 15.09.05 00:08:18, Michael Rex wrote:

> Zumindest zeigt amaroK auch alte MP3s, die ich noch mit ISO-5589-15 gerippt
> habe, korrekt an.


Ist ja auch richtig, aber UTF-8 kodierte id3's zeigt er nicht korrekt
an. In einer UTF-8 Umgebung "sollten" die ID3-Tags aber UTF-8 kodiert
sein, jedenfalls erzeugt grip IIRC UTF-8 kodierte Tags in einer UTF-8
Umgebung.

Ich hatte "damals" die Probleme mit xmms.

> > nicht wirklich in welchem Format die id3-Tags sind. die libtag1 fuer
> > KDE-Programme nimmt latin1 an, xmms nimmt die locale (sehr gut zu sehen,
> > wenn man latin1-Kodiert hat und ne UTF-8 Umgebung)... Zum Glueck hab ich
> > nur noch ogg's - da ists immer UTF-8 :-)

> Hm. Xmms scheint bei mir garnicht mit UTF-8 zurechtzukommen, egal mit
> welcher Locale die Tags erstellt wurden.


Ist ne Weile her, aber IIRC musste man dafür so ne Multibyte-Option in
den Options einschalten (oder ausschalten) und nen passenden Font
aussuchen (sprich einen mit iso10646 am Ende drin).

> Und Ogg verbietet sich bei mir schon automatisch. Leider kommen die
> wenigsten Player damit zurecht, und selbst wenn würde ich sicher nicht
> meine ganzen MP3s in Ogg konvertieren. So taub bin ich noch nicht,
> daß ich nach zweifacher verlustbehafteter Kompression keinen
> Unterschied bemerken würde ;-)


Ich hab meine MP3's in Ogg konvertiert und bisher ist mir kein
Unterschied aufgefallen. Was mich dennoch nicht abhält die CD's bei
Gelegenheit nochmal zu rippen (der Winter ist ja lang...)

Aber vllt. hab ich auch einfach keine HiFi-Stereo-Ohren ;-)

Andreas

Ähnliche Themen