Firefox Extensions systemweit installieren?
Hallo, weiß jemand, ob es einen vorgeschlagenen Weg gibt, Firefox Extensions systemweit zu installieren, so dass alle Benutzer eines Rechners darauf zugreifen können? Danke, Thomas
Re: wo ist apt-proxy?
Hallo, > Mein apt-proxy 1.9.18 aus Sid funktioniert unter Sarge eigentlich recht > gut. kann ich auch bestätigen; Ich habe nach Anfangsschwierigkeiten allerdings in der config disable_pipelining=1 gesetzt. Ade, Thomas
Re: kleopatra importiert WEB.DE-Zertifikat nicht
On Friday 10 December 2004 21:21, Hauke Seidel wrote: Hallo, > S/MIME-Fähigkeiten für KMail verschafft. Das war sehr problemlos. Ich habe > nun aber die Schwierigkeit, dass ich mein WEB.DE-Zertifikat, das ich in die > Datei "freemail.p12" exportiert habe, nicht importieren kann. Unter Mozilla > funzt es ohne weiteres. Ich habe auch versucht, im Kontrollzentrum die > ganzen WEB.DE.Trustcenter-Zertifikate als CAs zu importieren. Gerade das > "eMail-Trustcenter"-Zertifikat ging aber nicht. das habe ich letzte Woche auch probiert und schließlich auch hinbekommen. Man muss offensichtlich mit openssl die Verschlüsselung entfernen und beim Einlesen mit gpgsm dann wieder eine Passphrase setzen. Wenn ich mich recht erinnere, dann ging das etwa so (s.u.). Wenn Du es schaffst, mit KMail S/MIME-codierte oder signierte Mails zu verschicken, dann lass es mich bitte wissen. Das habe ich dann nämlich nicht geschafft :-( Ade, Thomas - (http://lists.gnupg.org/pipermail/gpa-dev/2003-January/001148.html) Hi all, after playing a little bit with gpgsm and openssl last night, I have hacked up a micro-HOWTO on how to import S/MIME certificates, e.g. from some freemail service like web.de or CAs like Thawte into GPGSM. Please have a look at it and tell me if there's an easier way to do this: HOWTO import externally generated keys and certificates into GPGSM == Let's assume you have an S/MIME certificate, probably a personal freemail certificate from Thawte or some other Certification Authority. Thawte offers X509 S/MIME certificates via a web interface, you cannot have gpgsm generate the Certificate Request and thus the private key, your browser will do that. So the problem is, after the certificate got issued, you have in inside you browser while you need it in GPGSM. "Where's the problem?" you might say. "I can always export my certificate as a PKCS#12 certificate bundle and import it into GPGSM." That's true, but it's a bit more difficult. While GPGSM has an import feature for PKCS#12 encoded secret keys, it is very limited: 1. GPGSM cannot import the complete PKCS#12 bundle, ONLY the secret key 2. The Key must not be encrypted. You need to import the secret key, the certificate, and the issuers certificate. Unfortunately, there seems to be no GPGSM-Only solution, but you can get along with a little help from OpenSSL :-) Here's a step-by-step HOWTO that I used to get my Thawte certificate into GPGSM: 1. Export the Certificate from your browser. You probably have Netscape or Mozilla, konqueror currently lacks support for generating certificate requests. The browser will ask you to specifiy an Export Password, be sure to remember it for the rest of the procedure, and store the certificate into a file "certbundle.p12". 2. Use OpenSSL to extract the key from the bundle. GPGSM currently seems to be unable to handle the complete bundle in one go. You need to extract the pieces yourself. This can be done with the following OpenSSL calls: First, you must convert the bundle from PKCS#12 into PEM format: bash$ openssl pkcs12 -in certbundle.p12 -out certbundle.pem -nodes OpenSSL will ask you for the Export Password, that's the password you used in your Browser to export the password. Then, extract the key from the bundle and export it, again in PKCS#12 format bash$ openssl pkcs12 -in certbundle.pem -export -out certkey.p12 -nocerts \ -nodes Again, OpenSSL will ask you for an Export Password, just use the same as in the previous step. Now you have your secret key ready for import into GPGSM: bash$ gpgsm --call-protect-tool --p12-import --store certkey.p12 3. Import the Issuers certificate and your own certificate Now that you have imported your secret key successfully, you need to import the issuers certificate, too. To obtain this certificate, you may have to browse to the issuers website and download it, but Thawte for example stores their certificate in the bundle you get when you request the certificate. You can then extract it from the file certbundle.pem you generated in the first step, simply with a text viewer. My preferred way is to display the file in vi, then mark the issuer certificate with the mouse and copy it into a shell, where before I typed in: bash$ gpgsm --import This will import the issuers certificate. Once you have successfully completed this step, do the same with your own certificate. If GPGSM did not spit out any error messages, you have now successfully imported your freemail certificate and use your favourite, Aegypten-enabled mailer to send and receive S/MIME messages with your own certificates. You can check with "gpgsm --list-secret-keys". If your freemail certificate shows up, you're ready to go.
Re: Dunkelschaltung des Bildschirms verhindern?
On Thursday 18 November 2004 01:24, Stephan Windmüller wrote: Hallo, nach einigem Probieren ( apm=off in Kernel-Command Line / setterm -blank 0 / xset s 0 0 / xset s off / xset s noblank, ...) kann ich bestätigen, dass in der Tat > xset s off ausreichend dafür ist, dass unter X11 der Bildschirm nicht mehr nach 10min schwarz wird. Danke! MfG Th. Gebhardt
Re: Dunkelschaltung des Bildschirms verhindern?
Hallo, > xset -q zeigt die aktuellen Einstellungen (DPMS, Standby, Suspend, > Off) DPMS (Energy Star): Standby: 1200Suspend: 1800Off: 2400 DPMS is Disabled "DPMS is Disabled" verstehe ich mal so, dass man die Zeile darüber ignorieren kann. Was mich aber stutzig macht; ein paar Zeilen darüber heißt es: Screen Saver: prefer blanking: yesallow exposures: yes timeout: 600cycle: 600 Wer hat den Screen Saver bestellt? Vermutlich ist der für das Dunkelwerden verantwortlich. Ich habe in /etc/console-tools/config auch mal # screen blanking timeout. monitor remains on, but the screen is cleared to # range: 0-60 min (0==never) kernels I've looked at default to 10 minutes. # (see linux/drivers/char/console.c) BLANK_TIME=0 gesetzt. Vielleicht hat das Dunkelschalten der Text-Konsole mit dem Dunkelschalten des X11-Servers auch gar nichts zu tun, sondern beruht auf einem unabhängigen Mechanismus? Danke, Thomas
Dunkelschaltung des Bildschirms verhindern?
Hallo, nach ca. 10 min wird der Bildschirm auf meinem Debian/Sarge (genauer: Knoppix-basiert) System schwarz; wenn man die Maus schubst oder eine Taste drückt, kommt das Bild wieder. Weil dieser PC als Monitor für eine WebCam dienen soll, ist dieses Verhalten hier unerwünscht. Ich suche daher nach einem Weg, dies zu verhindern. Beobachtungen: 1. Es scheint nicht am Monitor zu hängen: wenn man den aus/einschaltet oder ein/ausstöpselt, bleibt das Bild schwarz. 2. Es läuft kein Bildschirmschoner (Prozesstabelle) 3. Option "DPMS" "false" in der XF86Config-4 bringt nichts; es scheint auch nichts mit X11 zu tun haben: der Effekt ist auch auf den Text-Konsolen zu beobachten. Weiß jemand, wie man das Dunkelschalten des Bildschirms verhindern kann? Danke, Thomas
Re: Apt-proxy extrem lahm
On Friday 10 September 2004 14:04, Christoph Haas wrote: Hallo, > Selbst in unstable ist nur die 1.9.17. :) > > Aber Google hat mich gerade zu apt-proxy.sf.net geführt. Gibt es Pläne, > aus der v2 ein Debian-Paket zu basteln? Die neueste Version auf apt-proxy.sf.net ist 1.9.17+CVS vom 24 Aug 2004. Vom gleichen Tag stammt der Bug-Report "Shouldn't be included on sarge" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267880 vom Autor selbst: Package: apt-proxy Version: 1.9.17 Severity: serious This package is really usable for most users but have a lot of already know and serious bugs so I think is better leave it out of sarge. A possibility is after this bugs are solved we maintain an official backport for it or something like that. Thanks, Otavio Salvador - Liebe Grüße, Thomas
Re: X startet extrem langsam
On Tuesday 17 August 2004 19:47, Martin Palma wrote: Hallo, > Vielleich hat jemand eine Lösung von euch Probier mal als root ein "dpkg-reconfigure fontconfig". Ade, Thomas
Re: .xsession-errors: 1.98GB in einer Nacht
On Saturday 07 August 2004 10:51, Ole Bahlmann wrote: Hallo, > kdecore (KIconLoader): WARNING: Icon directory /usr/share/icons/hicolor/ > group 48x48/stock/chart not valid. vgl dazu http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241283 Liebe Grüße, Thomas
Re: /etc/environment wird nicht gelesen
On Monday 19 July 2004 16:58, Bertram Scharpf wrote: Hallo, > Wenn ich die gleiche Anweisung in `/etc/pam.d/su' angebe, > ist mein Problem aber immer noch nicht behoben; > `/etc/environment' wird nicht gelesen. Daß aber genau diese > Datei verantwortlich ist für `su', verifiziere ich, indem ich > die Zeile mit dem Modul `pam_rootok.so' auskommentiere. > > Isch versteh dem net. Ich kann das Verhalten reproduzieren und mit google findet man schnell andere, denen es genauso geht (ohne dass man unmittelbar auf eine Lösung gestoßen wird). Mein Tipp ist, dass pam_env.so zwar aufgerufen wird, su aber aus Sicherheitsgründen alle Env-Variablen vor dem Aufruf der Shell löscht; die man-page kann man jedenfalls so verstehen. Gegen diese Arbeitshypothese spricht allerdings, dass ich keine logs sehe, wenn ich pam_env.so die Option debug mitgebe. Vermutlich besteht die pragmatische Lösung darin, die Definitionen in /etc/profile reinzuschreiben. Ade, Thomas pgp1F4bViEUNZ.pgp Description: signature
Re: /etc/environment wird nicht gelesen
On Saturday 17 July 2004 21:17, Bertram Scharpf wrote: Hallo, > Dies passiert nur, wenn ich vorher als `user' eingeloggt > war. Auf der Konsole genauso. Warum, und wie behebe ich es? wie kommst Du denn darauf, dass /etc/environment ausgewertet werden sollte? Wo ist das dokumentiert? Ist das ein "offizielles" Feature? Es ist tatsächlich so, dass in manchen Umgebungen diese Datei gelesen und interpretiert wird. Das scheint mir aber eher sowas wie ein "undocumented feature" zu sein, auf das man sich im Zweifelsfall nicht verlassen sollte. Das ist jedenfalls mein Eindruck. Ade, Thomas
Probleme mit DRI+sarge
Hallo, seit ich auf sarge umgestiegen bin, laufen manche 3D Grafik-Programme nur noch mit miserabler Frame-Rate. Meine Grafikarte (ATI Rage 128) ist zwar nicht der Renner, aber unter woody konnte man doch halbwegs flightgear spielen, das geht jetzt nicht mehr (< 1 fps). Das Problem scheint nicht ganz trivial zu sein: DRI scheint zu funktionieren und einige Programme (tuxkart, tuxracer, ..) laufen auch weiterhin ganz manierlich. glxgears kommt auf ca. 520 fps (bzw. 1100 fps bei 16 Bit Farbtiefe) und glxinfo sieht auch ganz vernünftig aus (s.u.) Hat jemand eine Idee, wo das Problem liegen könnte? Konkret funktionieren torcs und flightgear nicht mehr, tuxkart, tuxracer und searchandrescue sind ok. ( Wahrscheinlich hat es gar nix damit zu tun: der Start von kdm dauert recht lange und ein strace tonnenweise Fehlermeldungen a la [pid 705] vm86old(0x85c41a0) = -1 ENOSYS (Function not implemented) Danach scheint es aber ohne offensichtliche Probleme weiterzugehen. ) Liebe Grüße, Thomas --- glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa DRI Rage128 20020221 Pro AGP 4x x86/MMX/3DNow! OpenGL version string: 1.2 Mesa 4.0.4 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r . . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 Slow 0x25 24 tc 0 24 0 r . . 8 8 8 0 0 24 0 16 16 16 0 0 0 Slow 0x26 24 tc 0 24 0 r . . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x27 24 tc 0 24 0 r y . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 Slow 0x29 24 tc 0 24 0 r y . 8 8 8 0 0 24 0 16 16 16 0 0 0 Slow 0x2a 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x2b 24 dc 0 24 0 r . . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0x2c 24 dc 0 24 0 r . . 8 8 8 0 0 24 8 0 0 0 0 0 0 Slow 0x2d 24 dc 0 24 0 r . . 8 8 8 0 0 24 0 16 16 16 0 0 0 Slow 0x2e 24 dc 0 24 0 r . . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow 0x2f 24 dc 0 24 0 r y . 8 8 8 0 0 24 0 0 0 0 0 0 0 None 0x30 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 0 0 0 0 0 0 Slow 0x31 24 dc 0 24 0 r y . 8 8 8 0 0 24 0 16 16 16 0 0 0 Slow 0x32 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 Slow --- $ ldd tuxracer (geht flott) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40034000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4003d000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40054000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x4011c000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40124000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40132000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40148000) libdl.so.2 => /lib/libdl.so.2 (0x40199000) libtcl8.4.so.0 => /usr/lib/libtcl8.4.so.0 (0x4019c000) libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x4024b000) libpthread.so.0 => /lib/libpthread.so.0 (0x4033c000) libSDL_mixer-1.2.so.0 => /usr/lib/libSDL_mixer-1.2.so.0 (0x4038d000) libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x403da000) libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x40449000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x404c4000) libm.so.6 => /lib/libm.so.6 (0x4057e000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x405a) libc.so.6 => /lib/libc.so.6 (0x405a8000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) libasound.so.2 => /usr/lib
Re: NFS-Kernel-Server leidet unter HD-I/O
On Wednesday 09 June 2004 17:23, Jan Lühr wrote: Hallo, > wird auf meinem Debian-Woody System die HD stark beansprucht, z.B. von > einer NFSD instanz, so scheint der NFS-Server dieser kurz auszusetzen und > so melden alle Klienten "NFS Server xxx.xxx.xxx.xxx not responding- still > trying". Das ganze ist aber mehr oder weniger ein Witz. > Der Server hat ein 1000MBit Backbone, die HD schafft 30MB/sec und der > Client ist über eine 100MBit Leitung an den Server angebuden. Die CPU hat > 1.8 GHz (p4). > Wo liegt hier der Flaschenhals? Bist Du sicher, dass es sich nicht um eine Problem FullDuplex vs. HalfDuplex handelt? Gibt es viele Kollisionen auf dem Ethernet-Interface? Ade, Thomas
