Re: [linux] ATI Radeon X300 SE
On Fri, 10 Jun 2005 15:45:33 +0200 (CEST) "Thomas Silvestre" <[EMAIL PROTECTED]> wrote: > quelle distri? Debian sarge Merci d'avance, > > Je n'arrives pas à configurer une ATI Radeon X300 SE... > > C'est pas pour jouer c'est pour travailler...mais bon y a ça dessus et > > tout > > ce que je trouves sur google c'est des infos sur l'usage des driver > > proprio > > d'ATI... > > > > J'ai désactivé le frame buffer j'aurais peut-être pas du? > > > > Quelqu'un à des infos à me donner sur la manière exacte de procéder pour > > la > > configurer avec uniquement des drivers libres? > > Je suis sur une debian sarge. Benoît ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
Re: [linux] Corruption DB ldap SuSE 9.2
A ce propos, c'est peut-etre l'occasion d'essayer le directory server de redhat plutot qu'openldap :-) http://directory.fedora.redhat.com/wiki/Main_Page Xavier Vincent Jamart wrote: Hello A nouveau, la DB est corrompue ce matin mais cette fois-ci, le FS n'est pas en cause puisque 95%. Le daemon est stoppé et lordsque je le redémarre, localmessages n'affiche pas d'erreurs: Jun 10 09:05:19 hera slapd[1371]: @(#) $OpenLDAP: slapd 2.2.15 (Jan 26 2005 16:34:33) $ [EMAIL PROTECTED]:/usr/src/packages/BUILD/openldap-2.2.15/servers/slapd Jun 10 09:05:19 hera slapd[1371]: bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (October 1, 2004) Jun 10 09:05:20 hera slapd[1371]: bdb_db_init: Initializing bdb database Jun 10 09:05:20 hera slapd[1376]: slapd starting Jun 10 09:05:20 hera slapd[1376]: conn=0 fd=12 ACCEPT from IP=127.0.0.1:51261 (IP=0.0.0.0:389) Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 BIND dn="" method=128 Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 RESULT tag=97 err=0 text= Jun 10 09:05:20 hera slapd[1376]: connection_input: conn=0 deferring operation: binding Jun 10 09:05:20 hera slapd[1376]: conn=0 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Par compte, si je fais un ldapsearch -x, il s'arrête tout de suite: hera:/var/log # ldapsearch -x # extended LDIF # # LDAPv3 # base <> with scope sub # filter: (objectclass=*) # requesting: ALL # # fft.be dn: dc=fft,dc=be o: fft dc: fft objectClass: top objectClass: dcObject objectClass: organization # Manager, fft.be dn: cn=Manager,dc=fft,dc=be cn: Manager sn: Manager objectClass: top objectClass: person # People, fft.be dn: ou=People,dc=fft,dc=be ou: People objectClass: top objectClass: organizationalUnit Je dois faire un ^C pour reprendre la main et db_recover n'y change rien. Ca arrive trop souvent, sans logique et je n'ai plus confiance dans ce package bdb +openldap (en tout cas le RPM de Suse). Activer un PDC windows me prendrait moins de temps que débugger ce brol... On Fri, 3 Jun 2005, Vincent Jamart wrote: Hello le slapcat est fait avec la DB down, donc a froid...c'est ca le pire db_recover, je vais tester plutot qu'un restore brutal On Thu, 2 Jun 2005, Xavier Renard wrote: Hello, En fait,faire un slapcat à chaud risque de corrompre tes fichiers. cfr man slapcat Limitations Your slapd(8) should not be running (at least, not in read-write mode) when you do this to ensure consistency of the database. Note qu'il me semble qu' avec des versions plus récentes, on puisse le faire (mais je ne sais plus quel numéro de version :-() maintenant, si tu n'as pas besoin des attributs opérationnels, un ldapsearch ferait l'affaire Pour rétablir la db en cas de corruption, tu as aussi l'utilitaire db_recover Xavier Vincent Jamart wrote: Hello Depuis presque un an, le PDC de la societe tourne avec Samba et LDAP. e remarque régulièrement que lorsqu'un backup s'est terminé en erreur (le plus souvent media full), la DB LDAP est corrompue. Le système est en SuSE 9.2, openldap2-2.2.15-5.2, mode bdb (le seul compilé dans le RPM De SuSE, c'est déja pas sérieux) et db-4.2.52-90/db41-4.1.25-75. Tous les soirs, je fais un backup offline de la DB ldap avec un slapcat -l. Le matin, régulièrement, les users SMB et les services dépendant du LDAP ne peuvent s'authentifier et pour cause, le service n'a pas redémarré après le backup comme prévu et lorsqu'à ce moment je fais un restart du daemon et un ldapsearch -x, l'output s'arrête après: # extended LDIF # # LDAPv3 # base <> with scope sub # filter: (objectclass=*) # requesting: ALL # # fft.be dn: dc=fft,dc=be o: fft dc: fft objectClass: top objectClass: dcObject objectClass: organization # Manager, fft.be dn: cn=Manager,dc=fft,dc=be cn: Manager sn: Manager objectClass: top objectClass: person # People, fft.be dn: ou=People,dc=fft,dc=be ou: People objectClass: top objectClass: organizationalUnit et je dois faire un stop du daemon, crasher les fichiers bdb corrompus et restaurer le backup avec slapadd -l et ensuite redémarrer le dameon (+smb) et là tout remarche. J'ai l'impression que l'implémentation de LDAP avec BDB est super foireuse et que SuSE n'ait pas compilé avec un support GDBM (ou autre plus robuste) c'est du n'importe quoi. ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #
Re: [linux] Corruption DB ldap SuSE 9.2
Hi, C'est bizarre quand meme. Tu as combien d'entrée? Sinon, au niveau debug, essaye peut-etre un niveau plus élevé avec la directive loglevel: http://www.openldap.org/doc/admin22/slapdconfig.html#Configuration%20File%20Directives (cfr section 5.2.1.5 pour les différents niveaux) ou avec l'option -d de slapd Xavier Vincent Jamart wrote: Hello A nouveau, la DB est corrompue ce matin mais cette fois-ci, le FS n'est pas en cause puisque 95%. Le daemon est stoppé et lordsque je le redémarre, localmessages n'affiche pas d'erreurs: Jun 10 09:05:19 hera slapd[1371]: @(#) $OpenLDAP: slapd 2.2.15 (Jan 26 2005 16:34:33) $ [EMAIL PROTECTED]:/usr/src/packages/BUILD/openldap-2.2.15/servers/slapd Jun 10 09:05:19 hera slapd[1371]: bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (October 1, 2004) Jun 10 09:05:20 hera slapd[1371]: bdb_db_init: Initializing bdb database Jun 10 09:05:20 hera slapd[1376]: slapd starting Jun 10 09:05:20 hera slapd[1376]: conn=0 fd=12 ACCEPT from IP=127.0.0.1:51261 (IP=0.0.0.0:389) Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 BIND dn="" method=128 Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 RESULT tag=97 err=0 text= Jun 10 09:05:20 hera slapd[1376]: connection_input: conn=0 deferring operation: binding Jun 10 09:05:20 hera slapd[1376]: conn=0 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Par compte, si je fais un ldapsearch -x, il s'arrête tout de suite: hera:/var/log # ldapsearch -x # extended LDIF # # LDAPv3 # base <> with scope sub # filter: (objectclass=*) # requesting: ALL # # fft.be dn: dc=fft,dc=be o: fft dc: fft objectClass: top objectClass: dcObject objectClass: organization # Manager, fft.be dn: cn=Manager,dc=fft,dc=be cn: Manager sn: Manager objectClass: top objectClass: person # People, fft.be dn: ou=People,dc=fft,dc=be ou: People objectClass: top objectClass: organizationalUnit Je dois faire un ^C pour reprendre la main et db_recover n'y change rien. Ca arrive trop souvent, sans logique et je n'ai plus confiance dans ce package bdb +openldap (en tout cas le RPM de Suse). Activer un PDC windows me prendrait moins de temps que débugger ce brol... On Fri, 3 Jun 2005, Vincent Jamart wrote: ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
Re: [linux] ATI Radeon X300 SE
quelle distri? > Salut la liste! > > > C'est encore moi. ;) > > Je n'arrives pas à configurer une ATI Radeon X300 SE... > C'est pas pour jouer c'est pour travailler...mais bon y a ça dessus et > tout > ce que je trouves sur google c'est des infos sur l'usage des driver > proprio > d'ATI... > > J'ai désactivé le frame buffer j'aurais peut-être pas du? > > Quelqu'un à des infos à me donner sur la manière exacte de procéder pour > la > configurer avec uniquement des drivers libres? > Je suis sur une debian sarge. > > > Merci d'avance > > -- > Benoît > ___ > Linux Mailing List - http://www.unixtech.be > Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > Archives: http://www.mail-archive.com/linux@lists.unixtech.be > IRC: chat.unixtech.be:6667 - #unixtech > NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech > > ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
[linux] ATI Radeon X300 SE
Salut la liste! C'est encore moi. ;) Je n'arrives pas à configurer une ATI Radeon X300 SE... C'est pas pour jouer c'est pour travailler...mais bon y a ça dessus et tout ce que je trouves sur google c'est des infos sur l'usage des driver proprio d'ATI... J'ai désactivé le frame buffer j'aurais peut-être pas du? Quelqu'un à des infos à me donner sur la manière exacte de procéder pour la configurer avec uniquement des drivers libres? Je suis sur une debian sarge. Merci d'avance -- Benoît ___ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
Re: [linux] Corruption DB ldap SuSE 9.2
Hello A nouveau, la DB est corrompue ce matin mais cette fois-ci, le FS n'est pas en cause puisque 95%. Le daemon est stoppé et lordsque je le redémarre, localmessages n'affiche pas d'erreurs: Jun 10 09:05:19 hera slapd[1371]: @(#) $OpenLDAP: slapd 2.2.15 (Jan 26 2005 16:34:33) $ [EMAIL PROTECTED]:/usr/src/packages/BUILD/openldap-2.2.15/servers/slapd Jun 10 09:05:19 hera slapd[1371]: bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (October 1, 2004) Jun 10 09:05:20 hera slapd[1371]: bdb_db_init: Initializing bdb database Jun 10 09:05:20 hera slapd[1376]: slapd starting Jun 10 09:05:20 hera slapd[1376]: conn=0 fd=12 ACCEPT from IP=127.0.0.1:51261 (IP=0.0.0.0:389) Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 BIND dn="" method=128 Jun 10 09:05:20 hera slapd[1376]: conn=0 op=0 RESULT tag=97 err=0 text= Jun 10 09:05:20 hera slapd[1376]: connection_input: conn=0 deferring operation: binding Jun 10 09:05:20 hera slapd[1376]: conn=0 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Par compte, si je fais un ldapsearch -x, il s'arrête tout de suite: hera:/var/log # ldapsearch -x # extended LDIF # # LDAPv3 # base <> with scope sub # filter: (objectclass=*) # requesting: ALL # # fft.be dn: dc=fft,dc=be o: fft dc: fft objectClass: top objectClass: dcObject objectClass: organization # Manager, fft.be dn: cn=Manager,dc=fft,dc=be cn: Manager sn: Manager objectClass: top objectClass: person # People, fft.be dn: ou=People,dc=fft,dc=be ou: People objectClass: top objectClass: organizationalUnit Je dois faire un ^C pour reprendre la main et db_recover n'y change rien. Ca arrive trop souvent, sans logique et je n'ai plus confiance dans ce package bdb +openldap (en tout cas le RPM de Suse). Activer un PDC windows me prendrait moins de temps que débugger ce brol... On Fri, 3 Jun 2005, Vincent Jamart wrote: > Hello > > le slapcat est fait avec la DB down, donc a froid...c'est ca le pire > db_recover, je vais tester plutot qu'un restore brutal > > On Thu, 2 Jun 2005, Xavier Renard wrote: > > Hello, > > > > En fait,faire un slapcat à chaud risque de corrompre tes fichiers. > > cfr man slapcat > > > > Limitations > >Your slapd(8) should not be running (at least, not in read-write > > mode) when you do this to ensure consistency of the database. > > > > > > > > Note qu'il me semble qu' avec des versions plus récentes, on puisse le > > faire (mais je ne sais plus quel numéro de version :-() > > maintenant, si tu n'as pas besoin des attributs opérationnels, un > > ldapsearch ferait l'affaire > > Pour rétablir la db en cas de corruption, tu as aussi l'utilitaire > > db_recover > > > > Xavier > > > > Vincent Jamart wrote: > > > > >Hello > > > > > >Depuis presque un an, le PDC de la societe tourne avec Samba et LDAP. e > > >remarque régulièrement que lorsqu'un backup s'est terminé en erreur > > >(le plus souvent media full), la DB LDAP est corrompue. Le système est > > >en SuSE 9.2, openldap2-2.2.15-5.2, mode bdb (le seul compilé dans le RPM > > >De SuSE, c'est déja pas sérieux) et db-4.2.52-90/db41-4.1.25-75. Tous > > >les soirs, je fais un backup offline de la DB ldap avec un slapcat -l. Le > > >matin, régulièrement, les users SMB et les services dépendant du LDAP ne > > >peuvent > > >s'authentifier et pour cause, le service n'a pas redémarré après le backup > > >comme prévu et lorsqu'à ce moment je fais un restart du daemon et un > > >ldapsearch -x, l'output s'arrête après: > > ># extended LDIF > > ># > > ># LDAPv3 > > ># base <> with scope sub > > ># filter: (objectclass=*) > > ># requesting: ALL > > ># > > > > > ># fft.be > > >dn: dc=fft,dc=be > > >o: fft > > >dc: fft > > >objectClass: top > > >objectClass: dcObject > > >objectClass: organization > > > > > ># Manager, fft.be > > >dn: cn=Manager,dc=fft,dc=be > > >cn: Manager > > >sn: Manager > > >objectClass: top > > >objectClass: person > > > > > ># People, fft.be > > >dn: ou=People,dc=fft,dc=be > > >ou: People > > >objectClass: top > > >objectClass: organizationalUnit > > > > > >et je dois faire un stop du daemon, crasher les fichiers bdb corrompus et > > >restaurer le backup avec slapadd -l et ensuite redémarrer le dameon (+smb) > > >et là tout remarche. J'ai l'impression que l'implémentation de LDAP avec > > >BDB est super foireuse et que SuSE n'ait pas compilé avec un support GDBM > > >(ou autre plus robuste) c'est du n'importe quoi. > > > > > > > > > > > > > ___ > > Linux Mailing List - http://www.unixtech.be > > Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux > > Archives: http://www.mail-archive.com/linux@lists.unixtech.be > > IRC: chat.unixtech.be:6667 - #unixtech > > NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech > > > > ___ > Linux Mailing List - http://www.un
