Re: [vhffs] bug synchro sqlite ?

[ Thread Index | Date Index | More vhffs.org/vhffs Archives ]


Salut ;

pour ce qui est de notre utilisation, ce n'est qu'un début. même si notre hébergement n'est pas vraiment voué à faire des la grosse masse, je trouve l'outil très pratique. et la liste des services gérés est vraiment sympa, c'est pour cela que je l'ai choisi et que j'ai persisté.
il y aura certainement d'autres questions / rapports de bug, mais en tout cas mercid e votre réactivité.

pour le script :
correct, je n'y ai pensé que plus tard.
mais j'avais lancé le script à la main avant la "correction" :-|
je vais vérifier le fonctionnement de tout cela de près, et faire des tests sur ma VM.
je vous tiens au courant.

Laurent.

2011/10/7 Sébastien Le Ray <beuss@xxxxxxxxxxxxx>
Le vendredi 07 octobre 2011 à 01:14 +0200, Laurent Stella a écrit :
> Bonsoir ;
>
> sur notre installation de VHFFS, nous utilisons le NSS sqlite, avec le
> script de synchro nss-mirror.pl, comme expliqué dans la doc.
> ca avait l'air de bien marcher, mais après avoir fait joujou avec l'ajout et
> la suppression des groupes, nous avons rencotré des problèmes : des id de
> groups non résolus au niveau unix.
> effectivement ils n'existaient pas dans la base sqlite, par contre ils
> existaient dans la base postgre.
> j'ai donc analysé le script de synchro, et le problème semble situé tout à
> la fin :
> $pw_dbh->do(q{INSERT OR REPLACE INTO passwd SELECT * FROM tmp_passwd});
> $pw_dbh->do(q{INSERT OR REPLACE INTO groups SELECT * FROM tmp_groups});
> $pw_dbh->do(q{INSERT OR IGNORE INTO user_group SELECT * FROM
> tmp_user_group});
> $sp_dbh->do(q{INSERT OR REPLACE INTO shadow SELECT * FROM tmp_shadow})
> 3 requêtes pour insérer dans les tables sqlite depuis les tables temporaires,
> ca semble normal. sauf que la 3eme requête fait un ignore à la place de
> replace quand les données existent déjà. après correction et avoir relancé
> le script, tout est corrigé.
>
> y avait-il une raison précise à cela ?
>
> Laurent.

Salut,

[Insérer ici des commentaires étonnés sur le fait qu'on a des
utilisateurs]

Oui, il y a une raison simple c'est que user_group ne doit être composé
(de mémoire) que des (uid, gid), donc en cas de doublon il n'y a pas
lieu de remplacer puisqu'il n'y a pas d'information à mettre à jour. De
plus celle-ci n'a rien à voir avec la résolution des ID de groupe, elle
gère uniquement l'appartenance des utilisateurs. J'aurais plutôt
tendance à penser que le script n'avait pas été lancé et que son
lancement manuel a mis à jour les groupes. Vous le lancez via un Cron ?
Vous pouvez jeter un œil aux logs pour voir s'il se lance bien
régulièrement ?

cordialement

Sébastien





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/