Gnus öffnet keine Anhänge
by Bjoern Schiessle
Hallo,
ich habe ein kleines Problem mit Emacs22.2.1 bzw. Gnus von Fedora 9.
Wenn ich auf einen Mail-Anhang klicke, sollte der Anhang eigentlich in
dem Standardprogramm für die entsprechende Datei angezeigt werden.
Seit meinem Update auf Fedora 9 funktioniert das aber nicht mehr.
In der Statuszeile sehe ich:
Displaying /usr/bin/xdg-open /tmp/emm.11606Zez/screenshot.png...done
Aber es passiert nichts. xdk-open funktioniert, ich habe das mal direkt
im Terminal getestet. Das Problem scheint zu sein, dass Gnus die zu
öffnende Datei nicht in /tmp ablegt. Es existiert nicht mal das
Verzeichnis /tmp/emm.11606Zez.
Meine erste Vermutung war, dass vielleicht SELinux Gnus den Zugriff auf
/tmp verwehrt. Ich habe jetzt aber SELinux mal komplett deaktiviert und
es hat sich nichts geändert.
Hat jemand eine Idee was hier schief gehen könnte?
Danke!
Björn
--
Bjoern Schiessle (http://www.schiessle.org)
Join the Fellowship and protect your freedom! (http://fsfe.org/join)
15 years, 10 months
Fedora Core 9 installation auf meinem Amilo 1667g
by daniel franke
Guten Morgen,
ich hab heute versucht FC9 x86_64 auf meinen Notebook zu installieren. Nachdem die Installation beendet ist, startet er alledings nicht durch, er geht die Dienste durch, und bleibt dann ( nachdem die Auflistung mit den Diensten durchgelaufen ist ) ohne erkenntlichen Grund stehen. Maus lässt sich nicht bewegen und Tastatureingaben werden auch komplett ignoriert (man kommt nicht mehr auf die Konsole etc. ).
Hab mir dann gedacht, starte doch einfach mal mit der DVD in den Rescue-Modus, und als ich dann in der chroot Umgebung war, hab ich keine Fehlermeldungen gefunden ( klar sie liegen in /var/log ;) ) aber z.B. ne Xorg.log oder ähnliches war nicht vorhanden.
Hab dann von der chroot Umgebung heraus X auch problemlos starten können, aber beim nächsten booten isser wieder an der selben Stelle abgeschmiert.
Ich weiß leider nicht mehr weiter, hat vllt. jmd. von euch ne Idee?
Lieben Gruß
Daniel
--
Begruende nichts mit Geisteskrankheiten, was sich auch mit einer
defekten Tastatur erklaeren laesst. (Noses in de.talk.liebesakt)
15 years, 10 months
Fedora 9 und Yahoo Messenger
by Matthias Milsch
Hallo Leute !
Ich bin grade dabei meine ersten Schritte mit Linux zu machen, dazu habe ich mir die neue Fedora 9 runtergeladen und sie installiert. Viele kleine Probleme konnte ich bisher selber lösen, allerdings scheiter ich jetzt immer an ein und selben Aufgabe.
Ich möchte gerne den Yahoo Messenger installier, beim booten lese ich was von Red Hat 6.0. Auf der Seite http://us.messenger.yahoo.com/unix.php finde ich dann einen passenden Download für Redhat 6.x
Allerdings scheitert dann alles an einer libdb.so.3, ein Paket welches das Installationsprogramm vermisst. Google hilft mir auch nicht weiter und in einem rpm seek finde ich ziemlich viele Links ... allerdings keiner, der mir auch nur irgendwie logisch erscheint ... also was mit libdb.so.3 zutun hat.
Vielleicht kann mir ja jemand von euch helfen ...
Viele Grüße,
Matthias
15 years, 10 months
"Routingproblem" mit ipsec (OpenS/WAN)
by Matthias Borrack
Hallo zusammen
Ich habe zwei Server die per ipsec miteinander verbunden sind
(net-to-net). Auf dem einen (ServerA) läuft u. a. ein OpenVPN-Server,
der die Benutzer über die AD authentifizieren soll. Dummer Weise ginge
das nur, wenn ich, wie beim Ping, das Interface mit angebe, da
Verbindungen von ServerA in das Subnetz hinter ServerB sonst mit der
öffentlichen IP-Adresse weggehen bzw. ankommen
# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:01:09.297502 IP vpn2.server.de > 192.168.1.68: ICMP echo request, id
28444, seq 43, length 64
15:01:10.297494 IP vpn2.server.de > 192.168.1.68: ICMP echo request, id
28444, seq 44, length 64
15:01:11.297493 IP vpn2.server.de > 192.168.1.68: ICMP echo request, id
28444, seq 45, length 64
Ein
ping -I 172.20.1.1 192.168.1.68
wird dann auch beantwortet.
Daran scheitert dann auch alle lokalen Dienste, die ich nicht auf ein
anderes als das öffentliche Interface binden kann. Nicht nur das
ldapsearch und dapwhoami, sondern auch sowas banales wie portforwarding
funktionier nur mit SNAT.
Jemand Idee oder einen Workaround?
Danke und Grüße,
Matthias
15 years, 10 months
OpenVPN und libssl.so.4
by Matthias Borrack
Hallo zusammen
Ich stand hier vor einem kleinem Problem, dass mich gerade einiges an
Nerven gekostet hat :(
Der ganze Text ist nur zu Dokumentationszwecken, da ich die Erfahrung
gemacht habe, dass solche Probleme zwar immer gelöst, aber nie die
Lösung dargelegt wird.
Ich habe ein FC6-Installation, auf der OpenVPN installiert ist
Linux srbfwp 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 13:44:07 EST 2007 i686
i686 i386 GNU/Linux
openvpn-2.1-0.17.rc2.fc6
openssl-0.9.8b-15.fc6
Wenn ich OpenVPN starten wollte, kam die Fehlermeldung:
---8<---
openvpn starten: /usr/local/sbin/openvpn: error while loading shared
libraries: libssl.so.4: cannot open shared object file: No such file or
directory
--->8---
Nach alter Manier natürlich erstmal den Link gesetzt, den openSSL
verändert sich ja auch nu mal ab und zu und die war in den alten
Versionen vorhanden.
---8<---
openssl097a.i386 0.9.7a-9 core
Matched from:
/lib/libssl.so.4
libssl.so.4
--->8---
Aber: Nix da, da kam dann die nächste:
---8<---
openvpn starten: /usr/local/sbin/openvpn: error while loading shared
libraries: libcrypto.so.4: cannot open shared object file: No such file
or directory
--->8---
Wundersam fand ich, welches Binary verwendet werden sollte, denn OpenVPN
ist ja laut rpm gar nicht in /usr/local/sbin/openvpn.
---8<---
# rpm -ql openvpn
/etc/openvpn
/etc/rc.d/init.d/openvpn
/usr/lib/openvpn
/usr/lib/openvpn/plugin
/usr/lib/openvpn/plugin/lib
/usr/lib/openvpn/plugin/lib/openvpn-auth-pam.so
/usr/lib/openvpn/plugin/lib/openvpn-down-root.so
/usr/sbin/openvpn
...
--->8---
Erschreckender Weise gibt es dort tatsächlich ein Binary, was aber nicht
dahingehört, denn egal auf welchen Server ich suchte, ich fand dort nie
ein Binary:
---8<---
# ll /usr/sbin/openvpn
-rwxr-xr-x 1 root root 506616 3. Mär 2007 /usr/sbin/openvpn
# ll /usr/local/sbin/openvpn
-rwxr-xr-x 1 root root 916026 18. Okt 2004 /usr/local/sbin/openvpn
--->8---
Also großes Rollback und das Binary "gesichert"
---8<---
# cd /usr/local/sbin/
# mv openvpn openvp_
--->8---
Und siehe da:
# service openvpn start
openvpn starten: [ OK ]
Und die Moral von der Geschicht?
Egal wer wo rumpfuscht: Aufräumen ist die halbe
Herausforderungsbeseitigung. Da hatte doch tatsächlich mal jemand
OpenVPN aus den Sourcen installiert und vor / bei / nach der
Installation des RPMs nicht aufgeräumt.
Grüße,
Matthias
15 years, 10 months