[OpenBSD]

[Index de la FAQ] [Section 9 - Migrer vers OpenBSD] [Section 11 - Le système X Window]

10 - Gestion du Système


Table des matières


10.1 - Quand j'essaie de passer root à l'aide de su, on me dit que je suis dans le mauvais groupe

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).

10.2 - Comment dupliquer un système de fichiers ?

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 - )

10.3 - Comment démarrer des services en même temps que le système ? (Vue d'ensemble de rc(8))

OpenBSD utilise lui-même un démarrage de type rc(8). Il utilise seulement quelques fichiers clés pour le démarrage.

Comment fonctionne rc(8) ?

/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 :

Démarrage des services fournis avec OpenBSD

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.

Démarrage et configuration des services locaux

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

Le répertoire /etc/rc.d/

À partir d'OpenBSD 5.0, les démons système ("services") sont démarrés, stoppés et contrôlés par /etc/rc.d. Tous les démons système sont contrôlés par ces scripts, et la plupart des paquetages complémentaires également.

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:

#!/bin/sh

daemon="/usr/local/sbin/daemonx"

. /etc/rc.d/rc.subr

rc_cmd $1
et il faudrait ajouter le nom du démon à la variable pkg_scripts dans /etc/rc.conf.local.

rc.shutdown

/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".

10.4 - Pourquoi les utilisateurs sont interdits de relais quand ils envoient des mails à distance à travers mon système OpenBSD ?

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`

Pour plus d'informations

10.5 - J'ai mis en place POP, mais j'ai des erreurs quand j'accède à ma messagerie via POP. Que puis-je faire ?

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:

10.6 - Pourquoi Sendmail ignore-t-il le fichier /etc/hosts ?

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.

10.7 - Configurer HTTP en mode sécurisé à l'aide de SSL(8)

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.

10.8 - J'ai effectué des changements dans /etc/passwd avec vi(1), mais les changements ne semblent pas être pris en compte. Pourquoi ?

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.

10.9 - Comment puis-je créer/supprimer un compte utilisateur ?

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.

Créer des comptes utilisateurs via user(8)

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 :

Création effective des comptes utilisateurs

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

Suppression des comptes utilisateurs

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.

10.10 - Comment puis-je créer un compte pour ftp uniquement ?

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).

10.11 - Mise en place des quotas

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

10.12 - Mise en place de Clients et Serveurs KerberosV

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

10.13 - Mise en place d'un serveur FTP Anonyme

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...

Création du compte FTP

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

echo /usr/bin/false >> /etc/shells
Ensuite vous êtes prêt pour ajouter l'utilisateur ftp.
# 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!

Configuration du répertoire

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 ..

Démarrage du serveur et logs

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.

Autres fichiers importants

10.13 - Confiner les utilisateurs à leur répertoire HOME avec ftpd(8)

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.

10.15 - Appliquer des correctifs sous OpenBSD

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 :

Encore une fois, la correction de fichiers individuels n'est pas toujours simple. Pensez à utiliser la deuxième méthode décrite plus haut et suivre la branche -stable (dite aussi la branche "des correctifs") d'OpenBSD. L'utilisation combinée de ces différentes méthodes est possible si vous comprenez exactement comment ça fonctionne. Les nouveaux utilisateurs devront choisir une seule méthode.

Quelle est la différence entre les correctifs de la page des errata et ce qui existe au niveau de la base de données CVS ?

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.

Application des correctifs

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 */
Comme vous pouvez le constater, le début du patch inclut de brèves instructions sur la façon de l'appliquer. Nous admettrons que vous avez placé ce patch dans le répertoire /usr/src auquel cas les étapes suivantes seront utilisées :
# 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
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.

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.

10.16 - Parlez-moi de chroot(2) Apache

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é.

Qu'est-ce qu'un chroot ?

Une application chroot(2)ée est bloquée dans un répertoire spécifique et ne peut errer dans les autres répertoires de l'arbre du système de fichiers et voit ce répertoire comme son répertoire / (root). Dans le cas d'httpd(8), le programme démarre, ouvre ses fichiers log, ouvre ses ports TCP (bien qu'il n'accepte pas encore de données), et lit son fichier de configuration. Ensuite, il se fixe lui-même dans le répertoire /var/www et baisse ses privilèges. Ce qui veut dire que tous les fichiers servis et utilisés par Apache, doivent être dans le répertoire /var/www. Dans la configuration par défaut d'OpenBSD, tous les fichiers du répertoire /var/www sont en lecture seule pour l'utilisateur qui fait tourner Apache, www. Cela aide considérablement la sécurité ; si il devait y avoir un problème de sécurité, les dégâts seraient confinés dans un seul répertoire avec les permissions de "lecture seule" et aucune ressource pour causer des problèmes.

Qu'est-ce que cela signifie pour l'administrateur ?

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é".

Dans certains cas, les applications ou les configurations peuvent être changées pour fonctionner dans le chroot(2). Dans d'autres cas, vous devrez tout simplement retirer cette option en utilisant l'option -u de httpd(8) dans /etc/rc.conf.local.

Exemple de chroot(2) d'une application : wwwcount

Voyons comment mettre en place chroot(2) pour une application à travers un exemple. Cet exemple se base sur wwwcount, un compteur tout simple d'accès aux pages web disponible dans les paquetages. Bien qu'il soit un programme très efficace, wwwcount ne sait rien d'Apache chroot(2)é et ne fonctionnera pas dans un environnement chroot(2)é avec sa configuration de base.

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.

# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# httpd -u
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

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
Ah ! voilà un problème. Deux fichiers ne sont pas disponibles dans l'environnement chroot(2). Alors, on les copie dans cet environnement :
# 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
Puis nous essayons le compteur à nouveau.

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 :

# mkdir -p /var/www/var/www
# cd /var/www/var/www
# ln -s ../../wwwcount wwwcount
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.
# tar cf - /usr/local/lib/wwwcount | (cd /var/www; tar xpf - )
Nous testons à nouveau ... et ça marche !

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.

Dois-je utiliser chroot ?

Dans l'exemple précédent, le programme est relativement simple et pourtant nous avons rencontré différents types de problèmes.

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é.

10.17 - Puis-je changer le shell de l'utilisateur root ?

Il est parfois dit qu'il ne faut pas changer le shell de l'utilisateur root, bien qu'il n'y ait aucune raison de ne pas le faire sous OpenBSD.

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.

10.18 - Que puis-je faire d'autre avec ksh ?

Sous OpenBSD, ksh est pdksh, le Shell Korn du Domaine Public (Public Domain Korn Shell), et est le même binaire que sh.

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 :

export PS1='$PWD $ '
dans votre /etc/profile, cela produira le prompt suivant :
/home/nick $
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.

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.
\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
(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)

Vous pouvez par exemple utiliser la commande suivante :

export PS1="\n\u@\H\n\w \\$ "
pour disposer d'une invite de commandes très parlante mais dont l'utilité n'est que relative.

10.19 - Services d'Annuaires

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.

10.19.1 - Quels sont les services d'annuaires disponibles ?

É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.

10.19.2 - Considérations sur la sécurité de YP

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).

10.19.3 - Configurer un serveur YP

  1. 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`
    
  2. Initialiser le serveur YP en utilisant la commande interactive :

    ypinit -m
    
    À 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.
  3. 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
    
  4. 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.

  5. 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.

  6. Créez la version initiale de votre table YP en utilisant les commandes

    cd /var/yp
    make
    
    Ne vous inquiétez pas des messages d'erreurs de yppush(8) maintenant. Le serveur YP ne fonctionne pas encore.
  7. 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
    
  8. 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.

  9. Finalement démarrez le démon serveur YP :

    ypserv
    
    Il démarrera automatiquement à chaque redémarrage aussi longtemps que le répertoire /var/yp/`domainname` continuera d'exister.
  10. 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
    
  11. Si vous désirez permettre aux utilisateurs de changer leurs mots de passe des machines clientes, vous devez activer yppasswdd(8) :

    echo 'yppasswdd_flags="-d /etc/yp/src/puffynet"' >> /etc/rc.conf.local
    rpc.yppasswdd
    
    Dans le cas ou vous utilisez le répertoire source par défaut dans /etc, utilisez juste yppasswdd_flags="".
  12. Rappelez vous que chaque fois que vous changez un fichier source d'une table YP, vous devez regénérer vos tables YP.

    cd /var/yp
    make
    
    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.

10.19.4 - Configurer un client YP

Configurer un client YP comprend deux parties distinctes. En premier, vous devez exécuter le démon YP client, connecter votre hôte client au serveur YP. Finaliser les points suivants vous permettra de récupérer les données du serveur YP, mais ces données ne seront pas encore utilisables par le système :
  1. 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
    
  2. 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`.

  3. 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
    
  4. 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.

    ypcat passwd
    bob:*:5001:5000:Bob Nuggets:/home/bob:/usr/local/bin/zsh
    ...
    
    D'autres outils utiles pour déboguer votre configuration YP inclus ypmatch(1) et yptest(8).
La deuxième partie de configuration de votre client YP inclus l'édition de fichiers de configuration locale comme certaines tables YP utilisées par certains moyens offerts par le système. Tous les serveurs ne fournissent pas toutes les tables standards supportées par le système d'exploitation, certains serveurs fournissent aussi des tables non standards, et vous n'êtes pas obligé d'utiliser tous les tables. Laquelle de ces tables doit ou ne doit pas être utilisé, et à quelles fins elles seront utilisées, est entièrement à la discrétion de l'administrateur système de l'hôte client.

Pour une liste des tables standards YP et leur usage standard, regardez Makefile.yp(8). L'utilisation la plus courante des cas :

10.20 - Jeux de caractères et localisation

OpenBSD utilise les caractères ASCII par défaut. Il supporte également les jeux de caractères Latin (ISO-8859-*), KOI-8, et Unicode (UTF-8).

10.20.1 - Configurer le jeu de caractère actif

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:

ls /usr/share/locale
La variable d'environnement LC_CTYPE peut être définie par les façons suivantes:

À 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.

10.20.2 - Changer la langue des messages d'applications

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] www@openbsd.org
$OpenBSD: faq10.html,v 1.87 2013/03/08 15:50:18 ajacoutot Exp $