![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Index de la FAQ] [Section 9 - Migrer vers OpenBSD] [Section 11 - Le système X Window]
Sous OpenBSD, les utilisateurs appartenant au groupe wheel sont autorisés à utiliser le programme su(1) pour devenir root. Sinon ils auront une erreur.
Si vous créez un utilisateur avec adduser(8), vous pouvez l'ajouter dans le groupe wheel en répondant wheel à la question "Invite user into other groups:". Les utilisateurs existant sur le système doivent être rajoutés au groupe "wheel" à la main. Voici un exemple d'une entrée /etc/group pour mettre l'utilisateur ericj dans le groupe "wheel" :
wheel:*:0:root,ericj
Si vous voulez donner l'accès aux privilèges du super utilisateur, sans pour autant mettre les utilisateurs dans le groupe "wheel", utilisez sudo(8).
Pour dupliquer votre système de fichiers, utilisez dump(8) et restore(8). Par exemple, pour dupliquer tout ce qu'il y a sous le répertoire SRC vers le répertoire DST, faites un :
# cd /SRC; dump 0f - . | (cd /DST; restore -rf - )
dump est conçu pour vous fournir beaucoup de possibilités de sauvegarde, et c'est peut-être trop si vous voulez juste dupliquer une partie d'un système de fichiers (entier). La commande tar(1) peut être plus rapide pour ce genre d'opération. Le format est très similaire à celui de dump :
# cd /SRC; tar cf - . | (cd /DST; tar xpf - )
/etc/rc.conf (comme guide), /etc/rc.conf.local (pour les changements), /etc/rc.local et /etc/rc.shutdown sont les principaux fichiers à connaître par l'administrateur système. Pour comprendre le fonctionnement de la procédure rc(8), en voici le déroulement :
/etc/rc est appelé après le démarrage du noyau :
La plupart des services fournis avec OpenBSD sont lancés au démarrage simplement par des variables définies dans le fichier de configuration /etc/rc.conf. Pour commencer, jetez un coup d'oeil au fichier /etc/rc.conf par défaut. Vous verrez des lignes similaires à la ligne suivante :
ftpd_flags=NO # for non-inetd use: ftpd_flags=""
Une ligne telle que celle-ci montre que ftpd(8) n'est pas lancé au démarrage du système (du moins pas à travers rc(8); ftpd est souvent démarré via inetd(8), lisez la FAQ Serveur FTP Anonyme pour plus d'informations). Chaque ligne est dotée d'un commentaire qui vous montre les drapeaux utilisés dans le cadre d'une utilisation courante du service ou du démon. Cela ne veut pas dire que vous devez appeler ce service avec ces mêmes drapeaux. Lisez la page man correspondante pour savoir comment démarrer un service ou démon donné de la manière que vous souhaitez.
Nous vous suggérons fortement de ne pas toucher au fichier /etc/rc.conf lui-même. À la place, créez ou éditez le fichier /etc/rc.conf.local, copiez juste les lignes que vous désirez modifier de /etc/rc.conf et ajustez-les à votre convenance. Cela permettra de faire les futures mises à jour simplement -- tous les changements seront dans un seul fichier qui ne sera pas touché lors de la mise à jour. En fait, le processus de mise à jour standard considère que vous n'avez pas modifié /etc/rc.conf, et l'écrasera avec la nouvelle version.
Par exemple, voici la ligne par défaut concernant httpd(8) :
httpd_flags=NO # for normal use: "" (or "-DSSL" after reading ssl(8))
D'après cet exemple, vous pouvez voir qu'aucun drapeau n'est nécessaire pour démarrer httpd normalement. Ainsi, la ligne " httpd_flags="" ajoutées à /etc/rc.conf.local suffit. Mais pour démarrer httpd avec le support SSL (reportez-vous à la FAQ SSL ou à ssl(8)), vous devez démarrer httpd avec une ligne comme celle-ci : "httpd_flags="-DSSL", et vous pouvez aussi ajouter d'autres paramètres pour d'autres raisons.
Pour les services que vous installez via les paquetages ou d'autres méthodes, vous pouvez utiliser le fichier /etc/rc.local. Par exemple, j'ai installé un service fourni par l'applicatif /usr/local/sbin/daemonx. Je souhaite que ce service soit lancé au démarrage. Pour cela, je peux ajouter les lignes suivantes dans /etc/rc.local :
if [ -x /usr/local/sbin/daemonx ]; then echo 'Starting daemonx'; /usr/local/sbin/daemonx fi
(Si le service ne se détache pas automatiquement lors de son démarrage, souvenez-vous de rajouter "&" à la fin de la commande.)
À partir de là, ce service sera lancé au démarrage. Vous pourrez voir toutes les erreurs au démarrage. Un démarrage normal sans erreurs affichera le message suivant :
Starting daemonx
Ces scripts, un par démon, sont invoqués par rc. La gestion des démons système se code dans rc, et celle pour les paquetages supplémentaires par la variable d'environnement pkg_scripts, qui devrait être définie dans /etc/rc.conf.local. Notez que le simple fait de placer un script dans ce répertoire ne suffit pas à le faire s'exécuter au démarrage; le nom du script doit être spécifié dans la variable pkg_scripts pour se lancer au démarrage.
Le démarrage des scripts système est déterminé par les entrées dans le fichier /etc/rc.conf.local. Par exemple, /etc/rc.d/httpd ne lance pas httpd(1) sauf si le fichier /etc/rc.conf ou /etc/rc.conf.local contient une ligne définissant la variable "httpd_flags". Pour vous assurer que votre système sera en place comme prévu lors du prochain démarrage, les scripts rc.d ne vont pas lancer leurs démons si la variable appropriée n'est pas définie. Vous pouvez bien sûr invoquer manuellement /usr/sbin/httpd avec les options que vous voulez, si vous souhaitez lancer le programme manuellement.
Il faut remarquer qu'au lieu d'avoir chaque script dans rc.d gérant la totalité des démarrages, arrêts, rechargements, redémarrages et les opérations de vérification, la plupart des scripts rc.d peuvent être réduits à juste spécifier quelques variables et invoquer le script rc.subr, qui gère la plupart des façons d'exécuter ces tâches.
Par exemple, notre application précédente, daemonx, pourrait être lancée avec un fichier /etc/rc.d contenant:
et il faudrait ajouter le nom du démon à la variable pkg_scripts dans /etc/rc.conf.local.#!/bin/sh daemon="/usr/local/sbin/daemonx" . /etc/rc.d/rc.subr rc_cmd $1
/etc/rc.shutdown est un script exécuté à l'arrêt de la machine. Toutes les tâches à effectuer avant l'arrêt du système devront être ajoutées à ce fichier. Si vous avez apm, vous pouvez aussi positionner "powerdown=YES". C'est l'équivalent de "shutdown -p".
Essayez ceci :
# grep relay-domains /etc/mail/sendmail.cf
Le résultat ressemblerait à la ligne suivante :
FR-o /etc/mail/relay-domains
Si ce fichier n'existe pas, créez-le. Vous devez saisir les hôtes qui envoient des messages à distance en respectant la syntaxe suivante :
.domain.com #Allow relaying for/to any host in domain.com sub.domain.com #Allow relaying for/to sub.domain.com and any host in that domain 10.2 #Allow relaying from all hosts in the IP net 10.2.*.*
N'oubliez pas d'envoyer un signal 'HangUP' à sendmail (signal qui notifie la plupart des processus de relire leur fichier de configuration) :
# kill -HUP `head -1 /var/run/sendmail.pid`
La plupart des problèmes rencontrés avec POP sont liés aux fichiers temporaires et aux fichiers verrous. Si votre serveur POP renvoie une erreur du type :
-ERR Couldn't open temporary file, do you own it?
Essayez de positionner les permissions comme suit :
permission in /var drwxrwxr-x 2 bin mail 512 May 26 20:08 mail permissions in /var/mail -rw------- 1 username username 0 May 26 20:08 username
Vérifiez aussi que l'utilisateur possède son propre fichier /var/mail. Bien évidemment, ceci devrait être le cas (comme par exemple l'utilisateur joe qui possède /var/mail/joe) mais si ça n'a pas été configuré proprement, le problème viendrait de là !
Bien entendu, si vous donner l'accès à /var/mail en écriture au groupe mail, vous allez probablement vous exposer à des vagues et obscurs problèmes de sécurité. Il se pourrait que ça ne pose aucun problème mais on ne sait jamais (et particulièrement si vous êtes un site de haut vol, un FAI,...) ! Il existe plusieurs services POP de la collection de ports OpenBSD. Si possible, utilisez popa3d(8) disponible dans le système de base d'OpenBSD. Ou peut-être vous avez sélectionné les mauvaises options pour votre programme POP serveur (comme le dot locking). Ou vous avez peut-être simplement besoin de changer le répertoire dans lequel les verrous sont crées (bien que les opérations de verrouillage ne devraient être bénéfiques qu'au service POP).
Note : Il est à noter que OpenBSD n'a pas de groupe "mail". Vous devez en créer un, si nécessaire, dans le fichier /etc/group. La ligne suivante devrait suffire :
mail:*:6:
Par défaut, Sendmail utilise le DNS pour la résolution de nom, non le fichier /etc/hosts. Ce comportement peut être changé par l'usage du fichier /etc/mail/service.switch.
Si vous désirez interroger le fichier d'hôtes avant les serveurs DNS, créez un fichier /etc/mail/service.switch contenant les lignes suivantes :
hosts files dns
Si vous désirez n'interroger QUE le fichier d'hôtes, utilisez ce qui suit :
hosts files
Envoyez un signal HUP à Sendmail :
# kill -HUP `head -1 /var/run/sendmail.pid`
et les changements prendront effet.
OpenBSD est fourni avec des bibliothèques RSA et un service httpd supportant SSL. Pour utiliser SSL avec httpd(8), vous devez d'abord créer un certificat. Ce certificat sera stocké dans /etc/ssl avec la clef correspondante dans /etc/ssl/private/. Les étapes décrites ici sont en partie prises de la page de manuel ssl(8). Lisez la pour plus d'informations. Cette partie de la FAQ s'intéresse seulement à la génération d'un certificat RSA pour les serveurs Web. Elle ne décrit pas les certificats serveur DSA. Pour plus d'informations à ce sujet, lisez la page de manuel ssl(8).
Pour commencer, vous aurez besoin de créer votre clé serveur et le certificat en utilisant OpenSSL :
# openssl genrsa -out /etc/ssl/private/server.key 2048
Ou si vous voulez que la clé soit cryptée avec un mot de passe que vous devez saisir à chaque démarrage des serveurs
# openssl genrsa -aes256 -out /etc/ssl/private/server.key 2048
La prochaine étape consiste à générer une requête de signature de certificat qui est utilisée pour permettre à une autorité de certification (CA) de signer votre certificat. Pour cela, utilisez la commande suivante :
# openssl req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr
Le fichier server.csr pourra alors être communiqué à une autorité de certification qui signera la clé. Une de ces autorités est Thawte Certification que vous pourrez joindre à l'adresse http://www.thawte.com/.
Si vous ne pouvez pas vous permettre un tel service, ou si vous voulez auto signer le certificat, vous pouvez utiliser la commande suivante :
# openssl x509 -sha256 -req -days 365 -in /etc/ssl/private/server.csr \
-signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt
Avec /etc/ssl/server.crt et /etc/ssl/private/server.key, vous devez être désormais capable de démarrer httpd(8) avec le drapeau -DSSL (consultez la section à propos de rc(8) dans cette faq), activant ainsi les transactions https sur le port 443 de votre machine.
Si vous éditez /etc/passwd, vos modifications seront perdues. OpenBSD génère /etc/passwd dynamiquement avec pwd_mkdb(8). Le fichier principal de mots de passe sous OpenBSD est /etc/master.passwd. D'après pwd_mkdb(8),
FILES
/etc/master.passwd fichier courant de mots de passe
/etc/passwd fichier de mots de passe au style "6th Edition"
/etc/pwd.db fichier non sécurisé de mots de passe au format base de données
/etc/pwd.db.tmp fichier temporaire
/etc/spwd.db fichier sécurisé de mots de passe au format base de données
/etc/spwd.db.tmp fichier temporaire
Dans un fichier de mots de passe Unix traditionnel, toutes les informations y compris le mot de passe crypté de l'utilisateur sont à la disposition de n'importe quel utilisateur du système (et c'est la cible principale de programmes tels que Crack). 4.4BSD a introduit le fichier master.passwd qui a un format étendu (avec les options additionnelles par rapport à /etc/passwd). Ce fichier n'est accessible que pour root. Pour un accès plus rapide aux données, les appels à la bibliothèque qui utilisent ce type d'informations accèdent normalement à /etc/pwd.db et à /etc/spwd.db.
OpenBSD met à votre disposition un outil qui vous permet d'éditer le fichier de mots de passe. Cet outil s'appelle vipw(8). vipw utilisera vi (ou votre éditeur favori tel que défini par $EDITOR) pour éditer /etc/master.passwd. Suite à vos modifications, vipw recréera /etc/passwd, /etc/pwd.db et /etc/spwd.db qui tiendront compte de vos modifications. vipw verrouille aussi l'accès à ces fichiers de telle façon à en interdire l'accès à quiconque essaie d'en changer le contenu en même temps que vous.
OpenBSD offre deux commandes pour facilement créer des comptes utilisateurs sur le système :
Il est toujours possible de créer des utilisateurs à la main en utilisant vipw(8), mais cela complique la plupart des étapes.La manière la plus facile pour créer un compte utilisateur sous OpenBSD est d'utiliser le script adduser(8). Ce script est paramétrable à travers le fichier /etc/adduser.conf. adduser(8) permet d'effectuer des vérifications sur la cohérence de /etc/passwd, /etc/group et les bases de données shell. adduser(8) crée pour vous les entrées correspondantes et les répertoires $HOME. Il peut aussi envoyer un message de bienvenue aux utilisateurs. Le comportement de ce programme peut être adapté à vos besoins. Pour illustrer notre propos, prenons comme exemple la création du compte testuser. Le répertoire de cet utilisateur sera /home/testuser. L'utilisateur fera partie du groupe guest comme groupe et aura un shell /bin/ksh .
# adduser Use option ``-silent'' if you don't want to see all warnings and questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. Don't worry about mistakes. There will be a chance later to correct any input. Enter username []: testuser Enter full name []: Test FAQ User Enter shell csh ksh nologin sh [ksh]: ksh Uid [1002]: Entrée Login group testuser [testuser]: guest Login group is ``guest''. Invite testuser into other groups: guest no [no]: no Login class authpf daemon default staff [default]: Enter Enter password []: Type password, then Enter Enter password again []: Type password, then Enter Name: testuser Password: **** Fullname: Test FAQ User Uid: 1002 Gid: 31 (guest) Groups: guest Login Class: default HOME: /home/testuser Shell: /bin/ksh OK? (y/n) [y]: y Added user ``testuser'' Copy files from /etc/skel to /home/testuser Add another user? (y/n) [y]: n Goodbye!
Pour supprimer des comptes utilisateurs, utilisez la commande rmuser(8). Cette commande supprimera toute chose relative à l'utilisateur. Elle supprimera son entrée crontab(1), son répertoire $HOME (s'il lui appartient) et son courrier. Bien évidemment, cette commande supprimera aussi les entrées correspondantes dans /etc/passwd et /etc/group. Comme exemple, nous allons utiliser cette commande pour supprimer le compte utilisateur précédemment crée. Notez que la commande vous demande l'identifiant du compte et si oui ou non elle doit supprimer le répertoire home de l'utilisateur.
# rmuser Enter login name for user to remove: testuser Matching password entry: testuser:$2a$07$ZWnBOsbqMJ.ducQBfsTKUe3PL97Ve1AHWJ0A4uLamniLNXLeYrEie:1002 :31::0:0:Test FAQ User:/home/testuser:/bin/ksh Is this the entry you wish to remove? y Remove user's home directory (/home/testuser)? y Updating password file, updating databases, done. Updating group file: done. Removing user's home directory (/home/testuser): done.
Ces outils sont moins interactifs que la commande adduser(8), ce qui en facilite l'usage dans des scripts.
La liste complète des outils est :
La commande /usr/sbin/user est juste un frontal pour le reste des commandes /usr/sbin/user*. Par conséquent, les commandes suivantes peuvent être ajoutées à l'aide de user add ou useradd, qui font que ce que vous avez choisi ne change pas les résultats à tous. Rappelez-vous, puisque user(8) n'est pas interactif, le plus simple pour ajouter des utilisateurs c'est avec adduser(8). useradd (8) est moins intimidant à utiliser si vous connaissez les paramètres par défaut à l'avance. Ces paramètres se trouvent dans le fichier usermgmt.conf(5) et peuvent être visualisés comme suit :
$ user add -D group users base_dir /home skel_dir /etc/skel shell /bin/csh inactive 0 expire Null (unset) range 1000..60000
Ces paramètres vont être utilisés tant que vous ne changez pas leur valeur en utilisant des options en ligne de commande. Par exemple, nous voulons que l'utilisateur soit ajouté au groupe guest et non pas à users. Il est à noter que lors de la création des comptes utilisateurs, les mots de passe doivent être spécifiés en ligne de commande. Le plus important, les mots de passe doivent être chiffrés, vous devez donc utiliser, au préalable, l'utilitaire encrypt(1). Par exemple : Les mots de passe par défaut sous OpenBSD utilisent l'algorithme Blowfish avec 6 réitérations. Voici un exemple pour créer un mot de passe chiffré pour le donner à useradd(8) :
$ encrypt -p -b 6 Enter string: $2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq
Maintenant que nous avons un mot de passe chiffré, nous sommes prêts à créer le compte utilisateur. Nous allons ajouter le même utilisateur avec les mêmes spécifications que l'utilisateur que nous avons ajouté plus haut, via adduser(8).
# user add -p '$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq' -u 1002 \ -s /bin/ksh -c "Test FAQ User" -m -g guest testuser
Remarque : Assurez vous d'utiliser " pour englober le mot de passe. L'utilisation de "" ne permet pas d'empêcher le shell d'interpréter le jeu de caractères correspondant au mot de passe avant de les communiquer à user(8). De même, assurez vous d'utiliser l'option -m si vous voulez créer le répertoire $HOME de l'utilisateur et copier les fichiers à partir de /etc/skel vers $HOME.
Pour voir si le compte utilisateur a été correctement crée, nous pouvons recourir à plusieurs utilitaires. Voici quelques commandes pour vérifier rapidement que tout s'est bien passé :
$ ls -la /home total 14 drwxr-xr-x 5 root wheel 512 May 12 14:29 . drwxr-xr-x 15 root wheel 512 Apr 25 20:52 .. drwxr-xr-x 24 ericj wheel 2560 May 12 13:38 ericj drwxr-xr-x 2 testuser guest 512 May 12 14:28 testuser $ id testuser uid=1002(testuser) gid=31(guest) groups=31(guest) $ finger testuser Login: testuser Name: Test FAQ User Directory: /home/testuser Shell: /bin/ksh Last login Sat Apr 22 16:05 (EDT) on ttyC2 No Mail. No Plan.
En plus de ces commandes, user(8) fournit son propre utilitaire, appelé userinfo(8), qui permet d'afficher les caractéristiques d'un compte utilisateur :
$ userinfo testuser login testuser passwd * uid 1002 groups guest change Wed Dec 31 19:00:00 1969 class gecos Test FAQ User dir /home/testuser shell /bin/ksh expire Wed Dec 31 19:00:00 1969
Pour supprimer des comptes utilisateurs avec la hiérarchie de commandes user(8), vous devez utiliser userdel(8). Cette commande est simple et efficace. Pour supprimer le compte précédemment crée, utilisez :
# userdel -r testuser
Notez bien l'option -r qui doit être spécifiée si vous voulez supprimer les répertoires $HOME aussi. Si vous voulez juste bloquer l'accès au compte sans supprimer des informations liées au compte, utilisez -p au lieu de -r.
Il y a plusieurs méthodes pour effectuer cette opération. Une des manières les plus communes est d'ajouter /usr/bin/false" à "/etc/shells". A partir de là, lorsque vous affectez "/usr/bin/false" à un utilisateur, il ne sera plus capable d'ouvrir une session interactive sur le système, néanmoins il pourra utiliser le service ftp. Vous souhaiterez peut-être aussi restreindre l'accès en Confiner les utilisateurs à leur répertoire HOME avec ftpd(8).
Les quotas sont utilisés pour limiter l'espace disque disponible pour les utilisateurs. Ce système peut être très utile si vous avez des ressources limitées. Les quotas peuvent être configurés par utilisateur et/ou par groupe.
La première étape pour configurer les quotas est de s'assurer que option QUOTA est présente dans votre configuration noyau. Cette option est incluse dans le noyau GENERIC. Ensuite, vous aurez besoin de marquer les systèmes de fichiers où les quotas sont utilisés dans le fichier /etc/fstab. Les mots clés userquota et groupquota doivent être utilisés pour marquer chaque système de fichiers où les quotas sont activés. Par défaut, les fichiers quota.user et quota.group seront crées à la racine des systèmes de fichiers où les quotas sont utilisés pour stocker les informations relatives à ces derniers. Si vous voulez les créer ailleurs, spécifiez un fichier avec l'option des quotas dans /etc/fstab, par exemple "userquota=/var/quotas/quota.user". Voici un exemple de /etc/fstab avec un système de fichiers avec quotas activés et le fichier de quotas se trouvant dans un endroit non-standard :
/dev/wd0a / ffs rw,userquota=/var/quotas/quota.user 1 1
Maintenant, il faut configurer les quotas par utilisateur. À cette fin, nous utilisons la commande edquota(8). Une utilisation simple est "edquota <user>". edquota(8) va utiliser vi(1) pour éditer les quotas à moins que la variable d'environnement EDITOR est positionnée pour charger un autre éditeur. Par exemple la commande :
# edquota ericj
Affichera un résultat similaire à :
Quotas for user ericj:
/: KBytes in use: 62, limits (soft = 0, hard = 0)
inodes in use: 25, limits (soft = 0, hard = 0)
Pour ajouter des limites, éditer là pour donner un résultat similaire à :
Quotas for user ericj:
/: KBytes in use: 62, limits (soft = 1000, hard = 1050)
inodes in use: 25, limits (soft = 0, hard = 0)
Notez que l'allocation de quotas est en blocs de 1k. Dans ce cas-ci, softlimit est fixé à 1000k et hardlimit à 1050k. softlimit est une limite qui permet au système de prévenir les utilisateurs quand ils l'ont dépassé. Ils auront alors jusqu'à la fin de leur période de grâce pour redescendre en dessous de cette limite. Les périodes de grâce peuvent être configurées à l'aide de l'option -t de edquota(8). Après la fin de la période de grâce, softlimit est géré comme hardlimit. Ce qui cause un échec d'allocation.
Une fois les quotas configurés, il faut les activer. Pour cela, utilisez la commande quotaon(8). Par exemple :
# quotaon -a
Cette commande analysera le contenu de /etc/fstab et activera les quotas sur les systèmes de fichiers où les options de quota sont positionnées. Maintenant que les quotas sont activés, vous pouvez les visualiser à l'aide de quota(1). Ainsi, la commande "quota <user>" fournit les informations concernant cet utilisateur. Si aucun argument n'est utilisé, quota vous fournira des statistiques sur les quotas. Par exemple :
# quota ericj
Afficherait :
Disk quotas for user ericj (uid 1001):
Filesystem blocks quota limit grace files quota limit grace
/ 62 1000 1050 27 0 0
Par défaut, les quotas positionnés dans /etc/fstab seront activés au démarrage. Pour les désactiver, utilisez :
# quotaoff -a
OpenBSD inclut KerberosV comme un composant pré-installé sur le système par défaut.
Pour plus d'information concernant KerberosV, sur votre système OpenBSD, utilisez la commande :
# info heimdal
Le mode FTP anonyme permet à des utilisateurs sans compte d'accéder aux fichiers sur votre machine en utilisant le protocole de transfert de fichiers. Ce chapitre a pour but de fournir une vue d'ensemble de la configuration d'un serveur FTP anonyme, les logs générés, etc...
La première étape consiste à créer un compte ftp sur votre système. Ce compte ne doit pas avoir de mot de passe utilisable. Dans cet exemple, nous allons considérer que /home/ftp est le répertoire correspondant au compte "ftp" mais vous n'êtes pas obligé de choisir la même chose. Quand le mode anonyme est utilisé, le service ftp va se confiner au répertoire HOME de l'utilisateur ftp (dans notre cas, ce répertoire est /home/ftp). Pour en savoir plus, lisez les pages du manuel ftpd(8) et chroot(2). Voici un exemple de création du compte ftp en utilisant la commande adduser(8). Au préalable, nous avons besoin d'ajouter /usr/bin/false au fichier /etc/shells. C'est le shell que nous allons attribuer à l'utilisateur ftp. Il ne permettra pas de connexion en login à ce compte même si nous configurons un mot de passe vide. Pour effectuer cette opération, il suffit de faire
Ensuite vous êtes prêt pour ajouter l'utilisateur ftp.echo /usr/bin/false >> /etc/shells
# adduser Use option ``-silent'' if you don't want to see all warnings and questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. Don't worry about mistakes. There will be a chance later to correct any input. Enter username []: ftp Enter full name []: anonymous ftp Enter shell csh false ksh nologin sh [ksh]: false Uid [1002]: Entrée Login group ftp [ftp]: Entrée Login group is ``ftp''. Invite ftp into other groups: guest no [no]: no Login class authpf daemon default staff [default]: Entrée Enter password []: Entrée Set the password so that user cannot logon? (y/n) [n]: y Name: ftp Password: **** Fullname: anonymous ftp Uid: 1002 Gid: 1002 (ftp) Groups: ftp Login Class: default HOME: /home/ftp Shell: /usr/bin/false OK? (y/n) [y]: y Added user ``ftp'' Copy files from /etc/skel to /home/ftp Add another user? (y/n) [y]: n Goodbye!
L'opération a crée, en plus de l'utilisateur, le répertoire /home/ftp. C'est ce que nous voulons mais nous avons besoin d'effectuer quelques modifications pour préparer le système à héberger le service FTP anonyme. Ces modifications sont expliquées dans la page du manuel ftpd(8).
Vous n'avez pas besoin de créer un répertoire /home/ftp/usr ou /home/ftp/bin.
Il est à noter que tous ces répertoires doivent être la propriété de "root". Voici à quoi doivent ressembler les répertoires après leur création :
# pwd /home # ls -laR ftp total 5 dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 . drwxr-xr-x 7 root wheel 512 Jul 6 10:58 .. dr-x--x--x 2 root ftp 512 Jul 6 11:34 etc dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 pub ftp/etc: total 43 dr-x--x--x 2 root ftp 512 Jul 6 11:34 . dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 .. -r--r--r-- 1 root ftp 316 Jul 6 11:34 group -r--r--r-- 1 root ftp 40960 Jul 6 11:34 pwd.db ftp/pub: total 2 dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 . dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 ..
Vous pouvez choisir d'exécuter ftpd soit à partir de inetd(8) soit de le lancer directement via les scripts rc. Les exemples suivants vous montreront le service lancé via inetd.conf. Tout d'abord, nous devons nous familiariser avec quelques options de ftpd. La ligne par défaut dans /etc/inetd.conf est :
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -US
Comme vous pouvez le voir, ftpd est invoqué avec -US. Ces options vont permettre de loguer les connexions anonymes dans /var/log/ftpd et les sessions courantes dans /var/run/utmp. Ce qui permet de voir ces sessions via who(1). Dans certains cas, on souhaitera fournir un accès anonyme et désactiver ftp pour les utilisateurs du système. Pour cela, il faut utiliser l'option -A de ftpd. Voici une ligne d'invocation de ftpd en mode anonyme exclusif. On utilise aussi -ll qui logue chaque connexion vers syslog en plus des commandes ftp get, retrieve, etc...
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -llUSA
Note : Les personnes gérant des serveurs ftp à HAUT trafic ne devraient pas invoquer ftpd à partir de inetd.conf. La meilleure option consiste à commenter la ligne correspondant à ftpd dans /etc/inetd.conf et à démarrer ftpd à partir de rc.conf.local. Cela va démarrer ftpd en tant que service. Ce mode de fonctionnement est beaucoup moins coûteux et plus rapide que le démarrage via inetd. La ligne correspondant à ftpd dans rc.conf.local ressemblerait à :
ftpd_flags="-llUSA" # for non-inetd use: ftpd_flags=""
Bien évidemment, cette méthode ne fonctionnera que si ftpd est commenté dans /etc/inetd.conf et en veillant qu'inetd ait bien relu son fichier de configuration.
Il n'est pas nécessaire d'ajouter des options supplémentaires à ftpd pour activer les connexions anonymes. Les étapes précédentes pour créer un utilisateur 'ftp' et configurer les répertoires nécessaires avec les permissions correctes sont suffisantes. Cependant, pour arrêter les connexions anonymes il n'est pas nécessaire de supprimer tout cela. Il faut juste redémarrer ftpd en incluant l'option -n. Les connexions anonymes seront désactivées.
Par défaut, lorsque les utilisateurs se connectent en ftp, ils peuvent aller dans n'importe quel répertoire du système, dans la mesure où les contrôles d'accès leur permettent. Dans certains cas, ce comportement peut ne pas être souhaitable. Il est possible de restreindre les utilisateurs ftp à leur répertoire HOME en utilisant "chroot".
Si vous voulez autoriser les connexions ftp en chroot, utilisez l'option -A de ftpd(8).
Si vous voulez utiliser chroot de manière plus fine, consultez "login capability infrastructure" et ftpd(8)
Les utilisateurs appartenant à une classe de connexion où la variable ftp-chroot est positionnée seront automatiquement mis dans un chroot. De plus, vous pouvez ajouter un nom d'utilisateur au fichier /etc/ftpchroot pour mettre ces utilisateurs dans un chroot. Un utilisateur a uniquement besoin d'être listé dans un de ces endroits.
Même avec OpenBSD, des bogues apparaissent de temps à autre. Certaines bogues causent des problèmes de fiabilité (par exemple, quelque chose peut amener le système à ne plus fonctionner correctement). D'autres bogues causent des problèmes de sécurité (qui peuvent permettre à d'autres personnes d'utiliser votre machine de façon inattendue et non autorisée). Lorsqu'un bogue critique est trouvé, le correctif sera mis en place au niveau de l'arborescence du code source -current. Ce correctif sera ensuite propagé vers les versions maintenues d'OpenBSD. Ces correctifs apparaissent sur la page web des errata. Ils sont séparés en correctifs "communs" applicables à toutes les plates-formes, et en correctifs applicables à une ou plusieurs plates-formes mais pas toutes.
Cependant, il est à noter qu'il n'y a pas de correctifs pour les nouvelles fonctionnalités et le nouveau matériel ajoutées à OpenBSD, et ils sont uniquement publiés pour d'importants problèmes de stabilité ou de sécurité qui doivent être réglés très rapidement sur les systèmes impactés (mais pas tous les systèmes vu que l'application de tel ou tel correctif dépend des applications utilisées).
Il existe trois façons d'installer les correctifs sur votre système :
Tous les correctifs postés sur la page web des errata concernent uniquement l'arborescence des sources de la version indiquée dans cette page. Les autres correctifs qui concernent l'arborescence actuelle de CVS peuvent contenir certaines modifications qui ne sont peut-être pas désirables sur la version de production. Ceci est important : Si vous avez installé un snapshot et que vous avez téléchargé les arborescences du code source au moment où vous avez obtenu le snapshot, il se peut que si vous essayer d'appliquer un des correctifs publiés, ça ne marche pas à cause d'une modification du code source.
Les correctifs d'OpenBSD sont distribués sous la forme de fichiers diff unifiés. Ces fichiers sont des fichiers texte qui contiennent les différences par rapport au code source d'origine. Ils ne sont PAS distribués sous forme binaire. Cela veut dire que pour appliquer les correctifs, vous devez avoir à disposition sur votre système le code source de la version RELEASE d'OpenBSD. De manière générale, il est recommandé d'avoir à disposition l'arborescence complète du code source. Si votre machine héberge une version à partir d'un CDROM officiel, l'arborescence du code source est disponible sur le disque 3. Elle est aussi disponible sous forme de fichiers à partir des serveurs FTP. Nous allons désormais supposer que vous avez l'arborescence complète à votre disposition.
À titre d'exemple, nous allons appliquer le correctif 001 pour OpenBSD qui corrige un bogue au niveau du pilote st(4) qui gère les lecteurs de bandes magnétiques. Sans ce correctif, la restauration de sauvegardes était assez difficile. Les personnes utilisant un lecteur de bandes magnétiques avaient besoin de ce correctif. Les autres personnes pouvaient s'en passer. Jetons un coup d'oeil à ce correctif :
# more 001_st.patch
Apply by doing:
patch -p0 < 001_st.patch
Rebuild your kernel.
Index: sys/scsi/st.c
===================================================================
RCS file: /cvs/src/sys/scsi/st.c,v
retrieving revision 1.41
retrieving revision 1.41.2.1
diff -u -p -r1.41 -r1.41.2.1
--- sys/scsi/st.c 1 Aug 2004 23:01:06 -0000 1.41
+++ sys/scsi/st.c 2 Nov 2004 01:05:50 -0000 1.41.2.1
@@ -1815,7 +1815,7 @@ st_interpret_sense(xs)
u_int8_t skey = sense->flags & SSD_KEY;
int32_t info;
- if (((sense->flags & SDEV_OPEN) == 0) ||
+ if (((sc_link->flags & SDEV_OPEN) == 0) ||
(serr != 0x70 && serr != 0x71))
return (EJUSTRETURN); /* let the generic code handle it */
Le message "Hunk #1 succeeded" indique que le correctif a été appliqué avec succès. Plusieurs correctifs sont plus complexes que l'exemple utilisé, et impliqueront de multiples "hunks" et fichiers. Dans ce cas, il faudrait que vous vous assuriez que tous les "hunks" ont été appliqués avec succès pour tous les fichiers concernés. Si ce n'est pas le cas, ceci veut normalement dire que votre arborescence du code source est quelque peu différente de l'arbre "release" d'où le patch a été créé, ou que vous n'avez pas suivi les instructions, ou encore que le correctif ne correspond pas au correctif originel. Les correctifs sont très sensibles aux espaces blancs -- un copier/coller depuis votre navigateur changera la plupart du temps les caractères de tabulation en espaces ou modifiera les espaces blancs de telle façon à rendre le correctif inutilisable.# cd /usr/src # patch -p0 < 001_st.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Apply by doing: | cd /usr/src | patch -p0 < 001_st.patch | |Rebuild your kernel. | |Index: sys/scsi/st.c |=================================================================== |RCS file: /cvs/src/sys/scsi/st.c,v |retrieving revision 1.41 |retrieving revision 1.41.2.1 |diff -u -p -r1.41 -r1.41.2.1 |--- sys/scsi/st.c 1 Aug 2004 23:01:06 -0000 1.41 |+++ sys/scsi/st.c 2 Nov 2004 01:05:50 -0000 1.41.2.1 -------------------------- Patching file sys/scsi/st.c using Plan A... Hunk #1 succeeded at 1815. <-- Ce message indique le succès de l'opération done
Vous pouvez maintenant compiler et installer le nouveau noyau, et redémarrer le système normalement.
Les correctifs ne s'appliquent pas systématiquement au noyau. Dans certains cas, vous devrez recompiler des utilitaires. Dans d'autres, vous devrez recompiler tous les utilitaires liés statiquement à une bibliothèque sujette à correction. Suivez les instructions dans l'en-tête du correctif, et si vous n'êtes pas certain, recompilez tout le système.
Les correctifs qui n'impactent pas directement votre utilisation du système n'ont pas besoin d'être appliqués normalement. Par exemple, si vous n'aviez pas de lecteur de bande magnétique dans votre système, vous ne bénéficierez pas du correctif ci-dessus. Cependant, les correctifs sont supposés être appliqués dans l'ordre. Il est donc possible qu'un correctif ultérieur dépend d'un correctif apparu plutôt. Soyez conscient de ce mode de fonctionnement si vous sélectionnez la méthode consistant à choisir vous-même vos correctifs. Si vous avez un doute, appliquez-les tous, dans l'ordre de leur mise à disposition.
Sous OpenBSD, le serveur httpd(8) d'Apache est chroot(2)é par défaut. Étant un grand pas en avant du point de vue de la sécurité, cela peut créer des problèmes si vous n'y êtes pas préparé.
En gros, chroot(2)er Apache est quelque chose qui n'est pas adopté par la plupart des autres systèmes d'exploitation. Beaucoup d'applications et de configurations système ne fonctionneront plus comme avant sans aménagement. De plus, il faut se souvenir que sécurité et commodité sont souvent incompatibles. L'implémentation d'Apache sous OpenBSD ne sacrifie pas la sécurité aux profits des capacités ou de la "facilité".
Oui, la dernière ligne tente de redémarrer Apache immédiatement et dans le cas où cela ne fonctionnerait pas, on attend quelques secondes puis on réessaie. Et oui, cela signifie bien que pendant quelques secondes chaque fois que vous effectuerez une rotation des logs, votre serveur web sera inaccessible. Bien que cela puisse poser des problème, n'importe quelle tentative pour permettre à httpd(8) de rouvrir des fichiers après avoir chroot(2)é ira à l'encontre de l'intérêt même du chroot ! Il existe néanmoins d'autres techniques, notamment loguer vers un pipe(2), et utiliser un programme extérieur afin de réaliser une rotation des fichiers à la fin du pipe.# apachectl stop rename your log files # apachectl start ; sleep 10 ; apachectl start
Tout d'abord, nous installons le paquetage wwwcount. Nous le configurons et le testons et c'est là que nous en déduisons qu'il ne semble pas fonctionner : Apache nous affiche le message "Internal Server Error". La première étape consiste à arrêter Apache et à le redémarrer avec l'option -u pour vérifier que le problème vient bien du chroot(2) et pas de la configuration système.
Après avoir fait cela, nous constatons que le compteur fonctionne correctement, du moins après avoir changé les droits d'un répertoire afin qu'Apache (et les CGIs qu'il exécute) puisse écrire à des fichiers. Ainsi, nous sommes maintenant certains que le problème vient du chroot. Nous arrêtons alors et redémarrons Apache à nouveau en utilisant le chroot par défaut :# apachectl stop /usr/sbin/apachectl stop: httpd stopped # httpd -u
# apachectl stop /usr/sbin/apachectl stop: httpd stopped # httpd
Un bon point pour commencer serait de supposer que wwwcount utilise des bibliothèques et d'autres fichiers qu'il ne peut accéder une fois dans le chroot. On peut utiliser à cet effet la commande ldd(1) pour trouver les dépendances dynamiques dont le CGI a besoin :
# cd /var/www/cgi-bin/
# ldd Count.cgi
Count.cgi:
Start End Type Open Ref GrpRef Name
1c000000 3c007000 exe 1 0 0 /var/www/cgi-bin/Count.cgi
0c085000 2c0be000 rlib 0 1 0 /usr/lib/libc.so.57.0
08713000 08713000 rtld 0 1 0 /usr/libexec/ld.so
Puis nous essayons le compteur à nouveau.# mkdir -p /var/www/usr/lib /var/www/usr/libexec # cp /usr/lib/libc.so.57.0 /var/www/usr/lib # cp /usr/libexec/ld.so /var/www/usr/libexec
Au moins, le programme s'exécute maintenant et nous affiche des messages d'erreur directement : "Unable to open config file for reading". Nous avons bien progressé mais nous n'avons pas encore fini. Le fichier de configuration se trouve normalement dans le répertoire /var/www/wwwcount/conf, mais au sein de l'environnement chroot, le programme devrait le voir sous /wwwcount/conf. Nous avons donc deux options. Soit nous recompilons le programme pour qu'il tienne compte du nouveau fichier de configuration par défaut (où plutôt du chemin pour l'atteindre) soit nous déplaçons les fichiers de données. Vu que nous avons installé le programme à partir d'un paquetage, nous prenons l'option 2, à savoir le déplacement des fichiers de données. Afin que nous puissions utiliser exactement la même configuration dans un environnement chroot(2)é ou pas, nous utiliserons un lien symbolique :
Remarquez que le lien symbolique a été pensé pour fonctionner au sein du chroot. Nous testons notre programme à nouveau et nous voilà avec un autre problème. Maintenant wwwcount se plaint de ne pas trouver les fichiers "strip image" qu'il utilise pour afficher des messages. Après quelques recherches, nous nous rendons compte que ces fichiers sont stockés dans /usr/local/lib/wwwcount, nous devons donc les copier dans le chroot aussi.# mkdir -p /var/www/var/www # cd /var/www/var/www # ln -s ../../wwwcount wwwcount
Nous testons à nouveau ... et ça marche !# tar cf - /usr/local/lib/wwwcount | (cd /var/www; tar xpf - )
Notez que nous n'avons copié que les fichiers strictement nécessaires au bon fonctionnement. En général, seuls les fichiers nécessaires à l'application doivent être copiés dans le chroot.
Toutes les applications ne peuvent ou ne devraient pas être chroot(2)ées.
Le but est la mise en place d'un serveur web sécurisé et le chroot(2)age n'en est qu'un outil, pas un but en soi. Souvenez-vous, la configuration initiale de l'Apache chroot(2)é sous OpenBSD fait en sorte que l'utilisateur sous lequel le programme httpd(8) tourne ne peut pas lancer de programme, ne peut pas modifier de fichiers et ne peut pas prendre l'identité d'un autre utilisateur. Réduire ces restrictions diminuera votre sécurité, chroot ou pas.
Certaines applications sont relativement simples et les mettre dans un chroot(2) n'a aucun sens. D'autres sont très complexes. Elles ne valent pas les efforts nécessaires pour les mettre en chroot(2) et même si c'était le cas, vous perdriez les avantages du chroot(2) après avoir copié la masse importante de fichiers dont elles ont besoin pour fonctionner. Ainsi le programme OpenWebMail a besoin de pouvoir lire et écrire dans le répertoire mail, le répertoire home de l'utilisateur et doit pouvoir travailler en tant que n'importe quel utilisateur du système. Essayer le mettre cette application en chroot serait inutile car vous serez obliger de désactiver tous les bénéfices du chroot(2)age. Même avec des applications aussi simples que le compteur précédent, il doit pouvoir écrire sur le disque (pour garder la trace de ses compteurs) et donc, une partie du bénéfice du chroot(2) est perdue.
Toute application qui doit fonctionne sous root ne vaut pas le coup d'être chroot(2)ée puisque root peut généralement s'échapper du chroot(2).
N'oubliez pas, si la procédure de chroot pour votre application est trop complexe vous pourriez ne pas mettre à jour votre système aussi souvent qu'il le faudrait. Ceci pourrait rendre votre système MOINS sécurisé qu'un système plus facilement administrable et dont le chroot est désactivé.
Le shell par défaut sur OpenBSD de l'utilisateur root est ksh.
Une directive Unix traditionnelle est d'utiliser pour l'utilisateur root des shells compilés statiquement, car si votre système démarre en mode utilisateur unique, les partitions non-root ne seront pas montées et les shells liés dynamiquement ne seront pas capable d'accéder aux bibliothèques situées dans la partition /usr. Ceci n'étant pas très important pour OpenBSD, car le système vous demandera de choisir un shell lors d'un démarrage en mode utilisateur unique, le shell par défaut étant sh. Les trois shells standards sous OpenBSD (csh, sh et ksh) sont liés statiquement et donc utilisables en mode utilisateur unique.
Les utilisateurs qui sont à l'aise avec bash, souvent utilisé sur les systèmes Linux, trouveront probablement ksh très familier. Ksh(1) offre la plupart des options habituellement utilisées avec bash, notamment l'achèvement des commandes avec la touche tab, l'édition de la ligne de commande et l'historique via les touches fléchées, et CTRL-A/CTRL-E pour aller au début/à la fin de la ligne de commande. Si vous désirez d'autres options de bash, bash peut être installé soit via les paquetages ou soit via les ports.
Le prompt de ksh peut être facilement changé de manière à fournir plus d'informations que le simple "$ " par défaut en modifiant la variable PS1. Par exemple, en insérant la ligne suivante :
dans votre /etc/profile, cela produira le prompt suivant :export PS1='$PWD $ '
Consultez le fichier /etc/ksh.kshrc, qui inclut plusieurs options utiles ainsi que des exemples, et qui peut être invoqué dans les fichiers .profile de vos utilisateurs./home/nick $
ksh(1) sous OpenBSD a été amélioré. Un certain nombre de caractères spéciaux ont été ajoutés au niveau de la chaîne primaire de l'invite de commandes, PS1. Ces caractères sont similaires à ceux présents dans bash. Par exemple :
\e - Insertion d'un caractère d'échappement ASCII.(consultez la page du manuel ksh(1) pour plus de détails , et beaucoup, beaucoup plus de caractères spéciaux ! Veuillez noter que le caractère "$" a une signification spéciale à l'intérieur des double quotes. Il est donc à manipuler avec précaution)
\h - Le nom d'hôte sans le nom de domaine.
\H - Le nom d'hôte complet, avec le nom de domaine.
\n - Insertion d'un caractère de retour à la ligne.
\t - L'heure actuelle, sur 24 heures, au format HH:MM:SS.
\u - Le nom de l'utilisateur actuel.
\w - Le répertoire de travail actuel. $HOME est abrégé en `~'.
\W - La racine du répertoire de travail actuel.
\$ - Affiche "#" pour les super-utilisateurs, et "$" pour les autres
Vous pouvez par exemple utiliser la commande suivante :
pour disposer d'une invite de commandes très parlante mais dont l'utilité n'est que relative.export PS1="\n\u@\H\n\w \\$ "
OpenBSD peut-être utilisé aussi bien comme client que serveur de bases de données contenant l'identification de l'utilisateur, l'information sur les groupes et d'autres données liées au réseau.
Évidemment vous pouvez utiliser différents services d'annuaires sur OpenBSD. Mais YP est le seul qui peut-être accessible directement en utilisant les fonctions standards de la librairie C comme getpwent(3), getgrent(3), gethostbyname(3) et bien d'autres. Donc, si vous conservez vos données dans une base de données YP, vous n'avez pas besoin de les copier dans les fichiers de configuration locaux comme master.passwd(5) avant de l'utiliser, par exemple pour authentifier des utilisateurs système.
YP est un service d'annuaire compatible avec Sun Microsystems NIS (Network Information System). Regardez yp(8) pour un aperçu des pages de manuel disponibles. Soyez prudent, certains systèmes d'exploitation possèdent des services d'annuaires qui contiennent des noms similaires mais qui sont incompatibles, comme par exemple NIS+.
Pour utiliser d'autres services d'annuaires à l'exception de YP, vous avez besoin de remplir les fichiers de configuration locaux de l'annuaire ou vous avez besoin d'un frontal YP pour l'annuaire. Par exemple, vous pouvez utiliser le port sysutils/login_ldap quand vous choisissez le premier, alors que le démon ypldap(8) fournit ce dernier.
Pour certaines applications, synchroniser simplement un petit nombre de fichiers de configuration sur un groupe de machines en utilisant des outils comme cron(8), scp(1) ou rsync (disponible dans les ports) constitue une alternative robuste et facile à un service d'annuaire complet.
Pour des raisons de compatibilité, toutes les fonctionnalités de sécurité de OpenBSD construites dans l'implémentation de YP sont désactivées par défaut. Même quand elles sont toutes activées, le protocole NIS reste intrinsèquement non sécurisé pour deux raisons : Toutes les données, incluant les données sensibles comme les hashs de mot de passe, sont transmises non chiffrées sur le réseau, et ni le client ou le serveur ne peut vérifier de manière fiable l'identité de l'autre.
Donc, avant de mettre en place un serveur YP, vous devez considérer ces faiblesses de sécurité intrinsèque comme acceptable dans votre contexte. En particulier, YP n'est pas adapté si des attaquants potentiels ont un accès physique à votre réseau. Quiconque obtient l'accès root d'un des ordinateurs connecté sur l'un de vos segment réseau faisant transiter du trafic YP peut se connecter sur votre domaine YP et récupérer des données. Dans certains cas, faire transiter du trafic YP à travers des tunnels SSL ou IPSec peut-être une option, ou vous devrez considérer de combiner YP avec une authentification kerberos(8).
Un serveur YP sert un groupe de clients appelé un "domaine". Vous devez d'abord choisir un nom de domaine; cela peut être une chaîne arbitraire et ne doit pas avoir de lien avec les noms de domaines DNS. Choisir un nom aléatoire comme "Eepoo5vi" peut améliorer de façon marginale la sécurité, avec l'effet d'être plutôt de la sécurité par l'obscurité. Dans le cas où vous devez maintenir plusieurs domaines YP distincts, il est sûrement meilleur de choisir des noms de description comme "ventes", "marketing" et "recherche" pour ne pas avoir d'erreurs d'administration système causées par l'obscurité. Il faut aussi remarquer que certaines versions de SunOS doivent utiliser le nom de domaine DNS de l'hôte, donc votre choix est plutôt restreint dans un réseau incluant de tels hôtes.
Utilisez l'utilitaire domainname(1) pour configurer le nom de domaine et le mettre dans le fichier defaultdomain(5) pour qu'il soit automatiquement configuré au démarrage du système.
echo "puffynet" > /etc/defaultdomain domainname `cat /etc/defaultdomain`
Initialiser le serveur YP en utilisant la commande interactive :
À ce stade, il n'est plus nécessaire de spécifier les serveurs esclaves. Pour ajouter des serveurs esclaves, vous pourrez relancer ypinit(8) plus tard, en utilisant l'option -u. Configurer au moins un serveur esclave pour chaque domaine est utile pour éviter les interruptions de service, le serveur maître pourrait s'arrêter ou perdre sa connectivité réseau, en particulier les processus clients essaieront d'accéder aux blocs de tables YP indéfiniment tant qu'ils ne recevront pas les informations demandées. Donc, les interruptions de service YP rendront typiquement les hôtes clients complètement inutilisables tant que le service YP n'est pas de retour.ypinit -m
Il faut décider ou stocker les fichiers sources pour générer vos tables YP initiales. Garder distincte la configuration du serveur de la configuration du service aide à contrôler quelle information sera donnée de celle qui ne le sera pas, donc le répertoire par défaut /etc n'est pas souvent le meilleur choix.
Le seul inconvénient causé par le changement de répertoire source est que vous ne pourrez plus ajouter, supprimer ou modifier des utilisateurs et des groupes dans le domaine YP en utilisant des utilitaires comme user(8) et group(8). À la place, vous devrez éditer les fichiers de configuration avec un éditeur de texte.
Pour définir le répertoire source, éditez le fichier /var/yp/`domainname`/Makefile.yp et modifiez la variable DIR, par exemple :
DIR=/etc/yp/src/puffynet
Considérez la possibilité de personnalisation d'autres variables dans /var/yp/`domainname`/Makefile. Regardez Makefile.yp(8) pour plus de détails.
Par exemple, même dans le cas ou vous utilisez le répertoire source par défaut /etc, vous n'avez généralement pas besoin de tous les comptes et groupes existants sur le serveur pour tous les hôtes clients. En particulier, ne pas fournir de compte root et garder le hash du compte root confidentiel est souvent bénéfique pour la sécurité. Étudiez les valeurs des variables MINUID, MAXUID, MINGID et MAXGID et ajustez les selon vos besoins.
Si tous vos clients YP utilisent OpenBSD ou FreeBSD, excluez les mots de passe chiffrés de la table passwd en configurant UNSECURE="" dans /var/yp/`domainname`/Makefile.yp.
La pratique courante d'éditer le fichier modèle /var/yp/Makefile.yp n'est plus recommandé. Les changements dans ce fichier affectent tous les domaines initialisés après le changement, mais n'affecte pas les domaines initialisés avant le changement, il s'agit donc d'erreurs de toute façon : vous risquez que les changements attendus ne soient pas pris en compte, et vous risquez de les oublier et qu'ils affectent d'autres domaines plus tard alors que cela n'était pas voulu.
Créez le répertoire source et le remplir avec les fichiers de configuration dont vous avez besoin. Regardez Makefile.yp(8) pour savoir quel table YP a besoin de quel fichier source. Pour le format de fichier de configuration individuel, consultez passwd(5), group(5), hosts(5) voir plus, et regardez les exemple dans /etc.
Créez la version initiale de votre table YP en utilisant les commandes
Ne vous inquiétez pas des messages d'erreurs de yppush(8) maintenant. Le serveur YP ne fonctionne pas encore.cd /var/yp make
YP utilise les rpc(3) (remote procedure calls) pour communiquer avec ces clients, il est donc nécessaire d'activer portmap(8). Pour le faire, éditez rc.conf.local(8) et configurez portmap_flags="". Cela démarrera le portmapper au prochain redémarrage. Vous pouvez aussi éviter de redémarrer en le démarrant manuellement :
echo 'portmap_flags=""' >> /etc/rc.conf.local portmap
Pensez à utiliser soit le securenet(5) ou les fonctionnalités de sécurité de votre serveur démon YP dans ypserv.acl(5). Mais sachez que les deux fournissent seulement du contrôle d'accès IP. Ainsi, ils aident aussi longtemps que des agresseurs potentiels n'ont ni l'accès physique au matériel du réseau transportant des segments de votre trafic YP, ni l'accès root de toute machine connectée sur ces segments réseaux.
Finalement démarrez le démon serveur YP :
Il démarrera automatiquement à chaque redémarrage aussi longtemps que le répertoire /var/yp/`domainname` continuera d'exister.ypserv
Pour tester le nouveau serveur, faite le devenir son propre client en suivant les instructions de la première partie de la section suivante. Dans le cas ou vous ne voulez pas que le serveur utilise ces propres tables, vous pouvez désactiver la partie cliente après le test avec les commandes suivantes :
pkill ypbind rm -rf /var/yp/binding
Si vous désirez permettre aux utilisateurs de changer leurs mots de passe des machines clientes, vous devez activer yppasswdd(8) :
Dans le cas ou vous utilisez le répertoire source par défaut dans /etc, utilisez juste yppasswdd_flags="".echo 'yppasswdd_flags="-d /etc/yp/src/puffynet"' >> /etc/rc.conf.local rpc.yppasswdd
Rappelez vous que chaque fois que vous changez un fichier source d'une table YP, vous devez regénérer vos tables YP.
Cela va mettre à jour tous les fichiers de bases de données dans /var/yp/`domainname`, avec une exception : le fichier ypservers.db, contenant tous les serveurs YP maîtres et esclaves associés avec le domaine, qui est crée directement avec ypinit -m et modifié exclusivement par ypinit -u. Dans le cas ou vous l'avez supprimé accidentellement, exécutez ypinit -u pour le recréer de zéro.cd /var/yp make
Comme sur le serveur, vous devez configurer le nom de domaine et activer le portmapper:
echo "puffynet" > /etc/defaultdomain domainname `cat /etc/defaultdomain` echo 'portmap_flags=""' >> /etc/rc.conf.local portmap
Il est recommandé de fournir une liste de serveurs YP dans le fichier de configuration /etc/yp/`domainname`. Sinon le démon client YP utilisera des broadcasts réseaux pour trouver les serveurs YP pour son domaine. Spécifier de manière explicite les serveurs et plus robuste et aussi marginalement moins ouvert aux attaques. Si vous n'avez pas configuré de serveurs esclaves, mettez juste le nom du serveur maître dans /etc/yp/`domainname`.
Le démon client YP est appelé ypbind(8). Le démarrer manuellement créera le répertoire /var/yp/binding, comme cela il sera automatiquement redémarré au démarrage.
ypbind
Si tout se passe bien vous devez être capable de faire une requête sur le serveur YP en utilisant ypcat(1) et voir votre table passwd retournée.
D'autres outils utiles pour déboguer votre configuration YP inclus ypmatch(1) et yptest(8).ypcat passwd bob:*:5001:5000:Bob Nuggets:/home/bob:/usr/local/bin/zsh ...
Pour une liste des tables standards YP et leur usage standard, regardez Makefile.yp(8). L'utilisation la plus courante des cas :
Si vous désirez utiliser tous les comptes utilisateurs de votre domaine YP, ajoutez la balise par défaut au fichier master.passwd et reconstruisez la base de données de mot de passe :
Pour des détails sur l'inclusion ou l'exclusion sélective de comptes utilisateurs, regardez passwd(5). Pour tester si l'inclusion fonctionne, utiliser l'utilitaire id(1).echo '+:*::::::::' >> /etc/master.passwd pwd_mkdb -p /etc/master.passwd
Si vous voulez inclure tous les groupes de votre domaine YP, ajoutez la balise par défaut YP au fichier group :
Pour des détails sur l'inclusion sélective de groupes, regardez group(5).echo '+:*::' >> /etc/group
Si vous distribuez des noms d'hôtes via YP, vous devez maintenant regarder resolv.conf(5) et vérifier que l'ordre de recherche de service d'annuaire est correct. La plupart des utilisateurs utiliseront une ligne comme celle-là :
lookup file yp bind
Pour utiliser l'un des jeux de caractères, la variable d'environnement LC_CTYPE doit être définie par le nom d'une langue supportée. LC_CTYPE affecte seulement le jeu de caractères disponible dans les applications. Elle ne va pas changer les langages utilisés par les messages d'applications.
La liste des langues supportées peut être obtenue avec la commande:
La variable d'environnement LC_CTYPE peut être définie par les façons suivantes:ls /usr/share/locale
à ~/.xsession avant de lancer le gestionnaire de fenêtres (jetez un oeil à la section personnaliser X pour plus de détails). Cet exemple active le jeu de caractères Unicode (UTF-8) et va faire que des applications comme xterm(1) vont activer le mode UTF-8 par défaut.export LC_CTYPE="en_US.UTF-8"
Si vous vous loguez via une console texte, ajoutez une ligne comme
à ~/.profile. Notez que la console texte supporte uniquement l'ASCII et l'ISO8859-1. Elle ne supporte pas l'UTF-8.export LC_CTYPE="en_US.ISO8859-1"
À ce jour, quelques utilitaires dans le système de base supportent l'UTF-8. La plupart va utiliser l'ASCII si l'UTF-8 est défini. Cependant, quelques programmes de la collection de ports supportent l'UTF-8.
UTF-8 peut également être utilisé par des applications spécifiques si vous lancez ces applications dans uxterm(1). Cela fonctionne même si la session de login utilise une langue non-UTF-8.
Si vous vous loguez à un système distant avec ssh(1), la variable d'environnement LC_CTYPE n'est pas étendue et va devoir être définie à la même valeur dans le terminal local.
La langue utilisée pour les messages d'application peut être changée en donnant à la variable d'environnement LC_MESSAGES le nom d'un locale supporté. Ceci peut être fait de la même façon qu'avec LC_CTYPE, décrite précédemment. LC_MESSAGES et LC_CTYPE devraient tous deux être définis sur la même valeur.
À ce jour, quelques utilitaires dans le système de base supportent d'autres langues que l'anglais. Cependant, certains programmes de la collection de ports supportent le messages localisés dans plusieurs langages. Ils retournent à l'anglais si la langue désirée n'est pas disponible.
[Index de la FAQ] [Section 9 - Migrer vers OpenBSD] [Section 11 - Le système X Window]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org