[Linux-bruxelles] Mise en cause du serveur Linux

[ymai]

Merci à tous ceux qui ont répondu
> Laurent Léonard a écrit :
>
> Je peux me tromper mais il s'agit là d'un message d'erreur relatif aux accès
> multi-utilisateurs au niveau d'Access... Un lock doit avoir été laissé par la
> machine en question qui s'est peut-être déconnectée de manière brutale ? En
> tout cas le problème vient bien de la couche Access et non de la couche
> Samba, sinon tu n'aurais pas un message aussi détaillé, tu aurais
> probablement un message du genre "Impossible d'accéder au fichier en lecture
> ou en écriture"...
C'est bien un accès multi-utilisateur qui pose problème. Quand une
seule personne accède à la base de données, aucun crash.
> De toute façon, Samba implémente CIFS, il n'y a donc pas de raison que son
> comportement soit différent d'un serveur de fichiers Windows (mise à part
> l'absence de bugs, on est presque vendredi... ).
Merci de renforcer mon opinion par un avis de pro; mais face à la
mauvaise foi, c'est difficile de défendre le serveur Linux. Pas la
peine de chercher plus loin: le fautif idéal était trouvé.
> Donc si la société en
> question supporte les accès multi-utilisateurs via partage Windows, leurs
> réponses devraient être également valables pour ton cas... Au pire tu peux
> omettre de dire que tu utilises Samba ?
Notre utilisation de Linux est notoire. Lors d'une des dernières mises
à jour du logiciel, j'ai posé la question de savoir quand nous aurions
la compatibilité Linux.
J'ai eu droit à une réponse très circonstanciée et très intéressante.
En fait, ils ont déjà tant de difficultés à assurer la compatibilité
des produits Microsoft entre-eux qu'ils ne souhaitent pas entamer une
recherche de compatibilité avec Linux ni même Mac.
J'avais fait quelques tests, en son temps, sous Wine/FF 7.10 .
Fonctionnement apparemment correct sur mon Desktop mais plantage au
démarrage, une fois sur deux, sur mon portable. Sous HH 8.04, ne
fonctionne plus. Confirmé par un autre utilisateur Linuxien convaincu.

Eric a écrit :
> Avec Access, il faut que toutes les personnes utilisant le mdb sortent de
> l'application car pour la modification de la structure il faut l'ouvrir en
> exclusive donc c'est normal.
Nous n'avons aucun accès à la base de données (verrouillée par mdp) en
dehors de l'application de gestion.
Nous n'avons donc certainement aucun accès en modification de la structure.
L'idée était bonne, mais pas d'application ici.
>
> Suffit peut-être de leur dire qu'il ne se trouve pas sur un serveur
> Samba/Linux mais simplement sur un serveur ;)
lire plus haut...
L'une des premières questions ayant été "quel type de serveur
utilisez-vous?". Et la réplique fusa...
> maintenant leur application
> n'est peut-être pas prévue pour tourner en mode multi-utilisateurs.
Si, si! Nous payons assez cher la licence multi-utilisateur :o) .
>
> Le problème peut se présenter également sur un autre type de server genre
> Novell
Il reste à les en convaincre.

Rémi Letot a écrit :
>
> J'imagine qu'ils ne sont pas tenus de supporter leur applicatif en
> dehors de l'utilisation prévue, mais je ne suis pas certain que le
> problème ne se présenterait pas sur un serveur win.
Sans doute de même qu'il n'y a aucune garantie sur le support sous Mac
/ Microsoft ni même Windows 64 bits.

Gaëtan Frenoy a écrit :
>
> N'y a-t-il pas une fichier ".ldb" qui traîne sur le serveur alors que
> toutes les connexions sont fermées ?
A vérifier.
Mais le diagnostic semble concorder avec les observations. Y aurait-il
des raisons que les fichiers .ldb ne soient pas traités correctement
sur un serveur Samba/Linux? Et rien qu'eux? Et tout à coup?
Une procédure (existante dans le logiciel) de nettoyage de la BD n'a
pas permis d'éviter un nouveau crash 30 minutes plus tard. Les
procédures existantes de levée des verrous réseau n'ont rien résolu
non plus.
>
> Ou bien justement, l'utilisateur qui démarre l'application n'a pas
> (plus) le droit de créer/modifier ce fichier.
>
> Bref, jete un oeil sur le KB208778 de Microsoft.
Les messages d'erreur indiquent effectivement qu'un verrou a été posé
par un utilisateur nommé "admin" (qui n'existe pas parmi nos
utilisateurs) et que l'utilisateur actuel ne peut accéder à la base de
données => crash et perte de toutes les modifications effectuées par
cet utilisateur.
A mon sens, ceci seul justifie déjà que Linux n'est sans doute pas en
cause, mais seulement l'application de gestion.
Mais je ne suis pas un pro.
>
> Et bien entendu, cherche à migrer ton applicatif Acces vers un
> logiciel libre :-)
Quelle belle idée. :o)
Ce logiciel libre devrait toutefois tenir compte de toutes les
contraintes formulées par les administrations et rester constamment à
l'écoute des nouvelles directives émanant du Ministère. Tel formulaire
doit avoir telle forme précise avec telles informations présentées de
telle façon; puis ça change quelques semaines plus tard.
Malgré les défauts que l'on peut trouver à l'application actuelle, il
faut avouer que le suivi de ces contraintes est plutôt précis.
> Bonne journée.
Pour clôturer le sujet, je signalerai qu'une modification de la
configuration du logiciel m'a été suggérée par le fournisseur de
l'application. J'avoue avoir oublié exactement de quoi il s'agissait.
Le cochage d'une case au fin fond d'une boîte de dialogue devrait
permettre une meilleure stabilité de la BD. Il fallait que chaque
station redémarre une fois à blanc l'application (démarrer + arrêter)
pour que la modification soit prise en compte dans la BDR de Windows.
Ensuite, on a encore travaillé pendant une paire d'heures sans qu'il
n'y ait de plantage.
J'arguerai volontiers du fait s'il s'avère que la stabilité a vraiment
été retrouvée.

Pour ma part, je reste parfaitement confiant dans le serveur
Samba/Linux sur lequel nous faisons également tourner la compta sous
BOB. Depuis plusieurs années aussi. Sans souci majeur après la mise en
oeuvre initiale: LE spécialiste BOB (charmant, par ailleurs) dépéché
sur les lieux ne connaissant rien à Linux et mes compétences étant
très limitées.

Merci à tous.