Remarques sur le serveur de modularité

La liste suivante propose des observations sur des cas d'utilisation de serveurs de modularité individuels :

Lorsque vous utilisez un système non UTF-8 et le protocole Samba sur un serveur de modularité, il est capital de le configurer correctement (notez que YaST2 dans SuSE ne le fait pas correctement). Il est extrêmement important que le paramètre unix charset soit défini correctement (dans la section général de smb.conf). Vous pouvez définir par exemple iso8859–15, valeur qui fonctionne bien pour les paramètres régionaux occidentaux. Si vous oubliez ce paramètre, tous les fichiers s'affichent. Notez que, si un nom de répertoire contient des NLC, vous serez en mesure de l'afficher et de le parcourir. Vous ne pourrez cependant afficher aucun des fichiers qu'il contient. Du point de vue de l'utilisateur, le job échoue. Après avoir modifié ce genre de paramètre, veillez à recharger Samba.

Par défaut, si un serveur de modularité Linux est configuré pour utiliser NFS et Samba, les agents utiliseront Samba. Sur le serveur de modularité, utilisez respectivement les commandes "sd_sscmd addshare" et "sd_sscmd removeshare" pour définir cette configuration selon vos souhaits.

Samba et NFS posent des problèmes différents en ce qui concerne les noms de fichiers et de répertoires. Samba est doté d'un mécanisme interne qui mappe les noms de fichiers et de répertoires si nous lui indiquons que nous utilisons, en tant qu'agent, UTF-8 (ou non UTF-8). La mappage de noms s'effectue discrètement. En revanche, NFS ne dispose pas d'un tel mécanisme, ce qui peut poser problème lorsque vous connectez, par exemple, un agent non UTF-8 à un serveur de modularité UTF-8 (ou l'inverse) et que vous tentez d'accéder à des noms de fichiers ou de répertoires contenant des NLC. Il n'existe malheureusement aucune solution (mis à part d'utiliser Samba à la place de NFS).

Si vous utilisez le partage de fichiers Samba sur un serveur de modularité, nous vous recommandons de configurer correctement l'accès à la bibliothèque (sd_sscmd libraryaccess …) afin que les agents Linux utilisant le système CIF puissent accéder sans problème au partage de fichiers Samba.

Ce problème est lié aux paramètres de configuration de la sécurité Samba. Si la sécurité du serveur de modularité a été configurée pour être utilisée en mode partagé, les agents ne pourront créer le partage à l'aide du système CIF qu'en tant qu'utilisateur invité (utilisateur par défaut s'il n'y a pas d'accès à la bibliothèque).

En revanche, si un autre type de sécurité a été configuré sur le serveur de modularité Samba, tel que le niveau de sécurité utilisateur, les utilisateurs anonymes ne pourront pas être créés à l'aide du système CIF car le système requiert un nom d'utilisateur explicite avec son mot de passe. En outre, l'utilisateur doit avoir été ajouté au fichier utilisateur Samba à l'aide de la commande smbpasswd -a.

Nous avons choisi de privilégier le système CIF (mount -t cifs) parce qu'il a plus de facilité avec les NLC qu'avec le système courant SMB (smbmount).

Nous recommandons aux administrateurs de configurer leurs serveurs de modularité ainsi :

sd_sscmd libraryaccess …
Vous configurez ainsi les informations d'identification pour Software Delivery utilisées lorsque des jobs sont envoyés à des agents.
smbpasswd -a …
Vous configurez ainsi les informations d'identification dans Samba même.
Ouvrez smb.conf à l'aide d'un éditeur et supprimez (ou transformez en commentaires) la ligne "guest ok = Yes" pour les partages sdlibrary et sdmsilib. Enfin, pour des raisons de sécurité, le paramètre de sécurité (dans la section générale) ne doit pas être défini en tant que partager (paramètre par défaut) mais en tant qu'utilisateur (au moins). Veuillez vous reporter à la page du manuel de smb.conf pour obtenir la signification exacte de tous les paramètres du serveur de modularité Samba.
Rechargez Samba ainsi :
/etc/init.d/smb reload

Les nouveaux paramètres sont activés.

Remarque : Si vous n'effectuez pas cette étape, les jobs devraient tout de même pouvoir être exécutés car la solution de rechange, le mécanisme de transport Interne - non-NOS, entrera alors en jeu. Interne - non-NOS fonctionne également, mais pas aussi efficacement que Interne NOS.

Les systèmes Linux qui semblent fonctionner de manière préconfiguré sont SuSE 9 ES ; les systèmes Linux qui ne semblent pas fonctionner de manière préconfigurée sont RedHat 3 ES et RedHat 4 ES.