bonjour,
 
j'ai un serveur samba sous debian 7.
avec samba (mode sécurité domaine), kerberos , winbind et les acl qui sont issues d'un domaine Active Directory (le contrôleur de domaine est sur un site distant : c'est important )
 
Si nous avons une coupure de courant (orage , edf etc) le serveur samba est censé rebooter tout seul grâce au réglages du bios.
ce que le serveur fait sans soucis MAIS ...
 
quand il redémarre, le réseau WAN (ou se trouve le domaine AD) n'est pas encore accessible (liaison adsl oblige : le synchro dsl est longue) et  samba ne voit plus le domaine AD => Les acl (groupes et utilisateurs du domaine AD)  ne sont plus appliquées sur le partage samba , donc les utilisateurs du site local (ou est la debian) n'ont plus accès à leurs fichiers !
 
Après retour du réseau wan (dés cet instant  on peut faire un ssh sur le serveur debian) il faut redémarrer le service samba pour avoir à nouveau les acl prises sen compte !
 
Avez vous une idée de ce souci ou véritable bug de samba ?

J'ai l'impression d'être tombé la dessus :
https://bugzilla.samba.org/show_bug.cgi?id=6103

up +

Tu ne peux pas faire un script de test de connexion à ton serveur AD et dès que c'est co un redémarrage de samba ?

salut bardiel,
 
je pense à des options de Samba.
 
conf de winbind :
 
exemple :
 
winbind cache time
idmap cache time
idmap negative cache time
 
winbind offline logon
winbind reconnect delay (cela semble etre la cause ....)
 
 
Mais je crois avoir vu une option pour activer le polling du daemon en cas de coupure réseau mais je ne sais plus ou.
 
là :
https://lists.samba.org/archive/sam [...] 51288.html
 
Il semblerait aussi que ce daemon gère assez mal les status du CONNTRACK de la stack IP, du style il reste accroché sur un ESTABLISHED même si la connexion distante avec l'ip est down. (un truc ds le genre)
 
Je pensais pas que la team samba puisse laissé un bug aussi important courir depuis 4 ans !
(car en prod cela ne pardonne pas)

T'utilise quoi comme init ?  
Sinon un simple delay sur l'init : tant qu'il chope pas l'adresse WAN, il met son init en pause. (dans ton script d'init pour samba tu lui inclus un "sleep X" ou X est le temps que met ton WAN a revenir up)
Ou un watchdog

le daemon usuel de samba, smb, nmb , winbind sur du sysv

C'est fait mais c pas propre ...
Pourquoi Samba ne gere t'il pas, tout comme un serveur membre, le fait que le site central (avec son DC et ses controleurs) soit non joignable ?
 
Suis-je sur un cas si délirant ?

Rien n'indique que les serveurs de fichiers Windows ne font pas de même avec une "sauce" interne  
 
Après ce n'est pas un cas délirant, je l'avais vu aussi dans une administration où l'authentification NTLM et LDAP passait par le réseau externe au site, avant d'autoriser comme toi par les ACLs les accès au Samba. La solution du script qui ping l'AD (ou le serveur LDAP) m'est venu d'un collègue qui faisait ainsi.

salut bardiel,
 
merci pour ton support.
 
En fait sur le synology nas (samba 3.6 est piloté par dsm 5.0)
j'ai fait une tache planifiée qui se lance toutes les heures (assez pas assez on verra) et fait les choses suivantes dans ce script bash :
 
ping avec un timeout de 10s (!)
si le ping est ok on sort avec un code erreur 0 (ras)
sinon on se lance dans un do while qui ping avec un timeout de 10s et quand il sort (c'est que le dc est pingable) il relance le service samba.
 
Le hic c'est que si la coupure wan se passe entre chaque heure ... ben mon script ne pipe rien ....

c'est clair qu'on ne sait pas comment les "redmond coder" gérent le truc !
(connaissant les entrailles de la partie impression windows ... cela doit être bien degeux ! , idem pour le client dfs : c'est horrible j'ai eu accès au grafcet du code)

Vu les quelques octets utilisés pour un ping, tu peux réduire sans problème à 5 minutes voire 2-3 minutes de délai pour ton script.
 
Pour utiliser smokeping sur un réseau moyennement important (quelques dizaines de serveurs et de postes de travail "repères" dans le réseau), ça ne prend pas tant que ça.

ok, le problème c'est que chez syno le scheduler ne descends  pas en dessous de l'heure : je vais devoir balancer cela dans la crontab.