- de meilleures fonctionnalités d'impression SPOOLSS pour les clients Win NT/2k/XP
- des corrections sur le partage de fichiers de bases de données Access et FoxPro
- des améliorations dans la couche VFS
- un outil tdbbackup pour sauvegarder/restaurer le tdb Samba
- meilleure échelonnabilité et stabilité
- des corrections sur le support MS-DFS
- les commandes d'impression Rpcclient fonctionnent de nouveau
Aller plus loin
- Miroir Samba pour la France (3 clics)
- WHATSNEW (2 clics)
- Samba France (5 clics)
- Téléchargement (3 clics)
# Trop koules !
Posté par Gyro Gearllose . Évalué à 10.
Ceci dit, le support des clients win2K n'est pas un mal, et fonctionne (déjà) plutôt bien.
Pensez-vous qu'un ramasseur de poubelles devrait être implémenté ? En effet, il n'est pas rare qu'un client windows plante (je ne recherche pas les trolls, c'est juste un constat), et dans ce cas là, les fichiers qui étaient ouverts par un client soudainement bleuté se retrouvent dans un état parfois indicible. Pour l'instant, la seule solution que j'ai pu trouver est de redémarrer samba, ce qui provoque la fermeture des fichiers ouverts, et redonne la main dessus à leurs proprios respectifs. Un garbage collector qui surveille l'état des clients serait (je pense) le bienvenu... Ce ne serait pas trop dur à implémenter : si ça ping (par ex), le client n'est pas mort, on continue. Si ça ping pas, il est mort, on ferme proprement ses fichiers ouverts, et comme ça dès qu'il revient, c'est tip top nickel !
[^] # process smbd
Posté par Lem-FR . Évalué à 10.
Tu "kill" simplement le processus smbd lié à l'utilisateur / station en cause, et ca suffit. Faudrait pas reconduire les habitudes windows sur des serveur unix tout de même :(
http://listes.ac-grenoble.fr/wws/info/samba-fr(...)
[^] # Re: process smbd
Posté par Gyro Gearllose . Évalué à 6.
Nom de nom ! Tu n'as pas tort du tout ! Bon, en fait, je relance le process smbd, ce qui a pour conséquence de fermer tous les fichiers et les sessions. C'est brutal, mais c'est efficace !
Ca dure 1/2 seconde, ça ne gêne personne !
De plus, les clients windows conservent les données d'identification sur le domaine, si bien que le simple fait pour eux de se balader dans leurs dossiers partagés sur le serveur samba les re-connecte automatiquement. Pas de problème donc ! En tout cas, jusque là, personne ne s'est plaint, et nous avons quand même 80 clients !
Sur le principe tu as raison, c'est dégueulasse (n'ayons pas peur des mots), mais je suis feignant !
Dans mon premier post, j'ai oublié de signaler l'effet de bord de samba suivant :
lorsqu'on définit un partage sous samba avec la directive "force user=nobody" par exemple, faut faire attention sur les clients windows , lorsqu'on connecte un lecteur réseau, à connecter celui-là en dernier, sinon, l'utilisateur prend l'identité "nobody", et ne peut plus se connecter au partage /home/%u . Ce que je dis là est valable pour les groupes également. A utiliser avec parcimonie et attention !
Ce comportement étrange est peut-être corrigé dans la version 2.2.4, je saurais ça quand j'aurai fait la mise à jour, c'est à dire la semaine prochaine.
# Certains ne perdent pas de temps !
Posté par Sebastien . Évalué à 9.
n/samba-2.2.4-i386-1.tgz: Upgraded to samba-2.2.4.
ftp://ftp.slackware.com/pub/slackware/slackware-current/ChangeLog.(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.