TraductionDeLaPageSurSuseParDavidKrider

Avertissement

Cette page est une traduction de la page http://www.davidkrider.com/suse_8.2.php Installing SuSE 8.2, j'en ai changé le titre car aujourd'hui elle dépasse de beaucoup la suse 8.2. Cependant David est passé à la gentoo, est donc vraissemblable qu'il n'enrichira plus cette page.

De temps en temps, j'ajoute une note ("ndt", c'est à dire "Note Du Traducteur"). Par la suite cette page vivra indépendamment de son auteur initial.

Ndt: l'auteur utilise régulièrement "insserv" pour mettre en place les scripts liés aux niveaux d'exécution. Quand à moi, je préfère utiliser l'éditeur de niveaux d'exécution que l'on trouve dans Yast/système, ce qui donne le même résultat.

Je n'ai traduit que les parties que je peux un minimum tester, vous pouvez traduire le reste si vous vous sentez d'attaque :-).

Installer une SuSE (8.2 et suivantes)

Introduction

J'ai écrit ceci pour ma propre référence avant toute autre chose. Je m'y réfère toujours quand je configure un de mes serveurs ou que j'en assure la maintenance. Je continue à mettre à jour cette information occasionnellement, mais je ne ferais pas de nouvelle page sur le sujet avant que la 9.2 soit diffusée (quel que soit le nom qu'ils lui donnent). Après que Red Hat ai reserré les boulons, j'ai migré vers la SuSE 8.2 après une longue et minutieuse évaluation de toutes les principales distributions disponibles, et j'étais décidé à épuiser les deux ans de support qu'ils proposent. J'ai été extrèmement heureux de ma décision. Même avant la fantastique nouvelle de l'acquisition de SuSE et Ximian's par Novell. Et les revues de presse encourageante qui ont suivi. J'ai utilisé la 9.0 avec le bureau Ximian, et je ne vois pas comment ça aurait pû être meilleur. Je suis sur des charbons ardents dans l'attente de la 9.1, et je n'en peux plus d'attendre pour voir ce qui se passera quand Novell aura eu la possibilité d'intégrer complètement SuSE et Ximian avec leur manière à la noix de prendre les rènes d'une entreprise.

(I'm on pins and needles waiting for 9.1, and I can't wait to see what will happen when Novell has had a chance to fully integrate SuSE and Ximian with their stated soup-to-nuts philosophy of taking over the enterprise.)

Important! Ce texte assume que vous êtes déjà familier avec Linux en général, bien sûr, mais aussi avec SuSE Linux, au moins en passant. Si vous avez besoin d'aide sur les aspects généraux du fonctionnement de SuSE Linux (qui est assez différent des autres distributions), consultez la FAQ SuSE excellente bien que non-officielle de [http://susefaq.sourceforge.net/ Togan Muftuoglu],

Il y a aussi plusieurs listes de discussion e-mail SuSE. Dans mon expérience, elles diffèrent de celles de Red hat de façon significative. La plus part des messages d'une liste Red Hat sont du genre : "Ceci est cassé, quand est-ce que ce sera réparé" auxquels la réponse est : "attendez la prochaine beta". La plus part des messages des listes SuSE sont du style "Je veux faire ça et ça. Comment faire ?". Suivent en général plusieurs réponses utilisables. Vous pouvez trouver une description des listes et [http://www.suse.com/en/private/support/online_help/mailinglists/ les instructions pour y souscrire] ici : . (note du traducteur : il n'y a pas de liste en français, et leur débit est assez èlevé. [http://www.dodin.net/linux/index.shtml Une liste non officielle] en français de très faible débit existe. Notez qu'ils ont aussi une liste non documentée "off-topic" ("hors sujet") à "suse-ot". C'était intéressant, mais en définitive trop politique pour moi. Je veux dire que je m'attendais à ce que suse-ot soit hors sujet, mais toujours au sujet de SuSE ou au moins Linux, en général. PAS au sujet de "Georges Bush est un horrible menteur". Faisons une pose.

Mise à jour automatique

Le coeur du système SuSE est Yast. Aussi ca vaut le coup de jouer finement avec. J'aime configurer un miroir local des mises à jour officielles de la distribution, et ensuite de configurer toutes mes machines pour retrouver le miroir local. Cela évite de perdre de la bande passante quand chaque machine va récupérer les patches, et ca épargne même la peine de faire des demandes de mises à jour inutiles, quand elles ne sont pas nécessaires. C'est bon pour vous et bon pour SuSE.

D'abord je crée un répertoire local et je le remplis depuis un miroir SuSE avec un job cron, comme ceci (qui doit tenir sur une seule ligne) :

 lftp -c 'mirror -e -vvv ftp://<mirror.of.your.choice>/
  <path/to/i386>/i386/update/8.2/ /data/suse/updates/i386/update/'

OU, si vous voulez utiliser rsync qui est plus rapide :

 rsync -rltv --delete rsync://<mirror.of.your.choice>/
  <path/to/i386>/i386/update/8.2/
  /data/suse/updates/i386/update/8.2/

Puis je partage ce répertoire avec le reste du réseau an ajoutant au fichier /etc/exports une ligne du genre :

 /data           *(ro)

Vous pouvez démarrer le service NFS avec un "rcnfs start", mais n'oubliez pas que pour que le service démarre au boot, il faut `insserv nfsd'. Une fois ceci configuré, vous pouvez monter le répertoire sur vos machines client et ajouter les points de montage à leur fichier /etc/fstab, ainsi :

 excelsior:/data      /mnt/excelsior/data  nfs        defaults              0 0

Ensuite, vous devez modifier /etc/youservers et pointer le système de mise à jour sur votre répertoire local. Je n'ai qu'une ligne (hors commentaire) dans ce fichier :

 dir:///mnt/excelsior/data/suse/updates

Vous n'avez pas besoin de la liste officielle des serveurs de mise à jour, vous pouvez donc donner pour instruction à online_update de ne pas la rechercher. Vous devez modifier /etc/sysconfig/onlineupdate pour cela, ainsi que pour lui dire quelles mises à jour vous voulez. Les exemples possibles donnés par 'online-update -help" sont security, recommended, document, and optional. Notez que chaque option successive inclu la précédente. Je met le mien sur "recommended".

 YAST2_LOADFTPSERVER="no"
 CMDLINE_OPTIONS="recommended"

Finalement, vous devez dire à Yast de mettre en place une tâche de mise à jour automatique. Vous pouvez faire cela à travers l'interface graphique ou, si vous êtes habitué à crontab, à la main. L'interface Yast va simplement créer dans /etc/cron.d un fichier nommé "yast2-online-update" avec le contenu suivant :

 0 3 * * * root online_update

Note, pour ceux qui jouent à ça à la maison, ceci est un format légèrement différent des autres crontab. Il y a un argument supplémentaire (user) dont les tables exécutées depuis ce répertoire ont besoin.

Ca doit être tout. Si vous avez un alias d'admin correct, vous devriez avoir quelques compte rendus de mise à jour chaque jour, un pour la synchronisation ftp et un pour chaque client qui essaie de mettre à jour. Pour configurer un alias pour avoir les rapports, ajoutez simplement dans /etc/aliases une ligne pour root, comme ceci :

 root:	user@someplace.org

Puis exécutez `newaliases'.

Vivre avec SuSEfirewall2

On peut dire beaucoup de choses dans ce chapitre car le script SuSEfirewall2 peut faire une surprenante quantité de choses. Dans /usr/share/doc/packages/SuSEfirewall2/README, l'auteur affirme que ce programme est le meilleur dans sa catégorie. J'étais d'abord sceptique, mais maintenant je le crois. Jusqu'à présent il n'y a rien que l'on veuille faire avec un parefeu qu'il ne soit possible de réaliser... une fois qu'on a compris comment le système fonctionne (il est particulièrement agréable qu'il fasse avec ICMP et consort plein de choses qui sont péniblement répétitives à faire à la main avec les commandes iptables brutes). Le principal à comprendre est que le programme SuSEfirewall2 est un script qui lit le fichier /etc/sysconfig/SuSEfirewall2. Toute votre configuration doit aller dans le fichier de sysconfig file. Lisez-le.

Non, vraiment, Allez le lire maintenant, j'attendrais...

La documentation pour /etc/sysconfig/SuSEfirewall2 est là, directement dans le fichier lui-même. Cependant, du fait que cette documentation n'est constituée, après tout, que de commentaires, et du fait qu'il montre parfois son origine germanique,il peut être difficile à comprendre (ndt: surtout qu'il est en anglais). Par exemple, il est difficile de comprendre la différence entre les paramètres "FW_FORWARD" et "FW_FORWARD_MASQ" au premier coup d'oeil. En fait, mettre au point le fichier de configuration est au-delà de mes objectifs actuels. Mon but est seulement de montrer quelques éléments indispensables.

Après avoir modifié le fichier /etc/sysconfig/SuSEfirewall2 exécutez simplement "SuSEfirewall2" pour valider les modifications. Ne vous occupez pas des fichiers /etc/init.d/SuSEfirewall_*. Si vous ne l'avez pas encore fait, exécutez "insserv SuSEfirewall_" pour chacun d'eux et vous en serez débarrassés.
Si vous êtes habitués à regarder les jeux de règles standard iptables (comme il faut le faire avec les autres distributions), vous pouvez regarder ce que produit SuSEfirewall2 en exécutant "SuSEfirewall2 debug".
Pour une sortie à peu près lisible du jeu de règles courant, vous pouvez faire "SuSEfirewall2 status". C'est tout ce que vous pourrez en tirer de bon. De toutes façons, c'est toujours mieux qu'un "iptables -L".
Prenez soin de vous familiariser avec les autres options de SuSEfirewall2. Il y a des modes opératoires pour vider le jeu de règles (pour voir si vos règles posent un problème quelconque), Fermer le parefeu au traffic extérieur (le temps de bien comprendre ce que vous voulez faire), and pure panic (while you browse the messages log to find out what damage was done).

Configurer Postfix

J'utilise Postfix comme serveur de courrier. Il reçoit les courriers pour davidkrider.com et il agît comme relai pour moi, où que je sois, en demandant une authentification. Je l'utilise pour envoyer mes mails persos, même quand je suis au travail. Qui plus est, j'encrypte toutes les communications extérieures au départ et à l'arrivée du serveur à travers SSL pour garder les choses personnelles. Par dessus le marché, j'utilise quelques éléments de prévention anti-spam inclus dans Postfix et SpamAssassin.

Le bon côté de ce travail de configuration est que la partie importante peut être faite par Yast, avec l'éditeur de fichier sysconfig, aux rubriques Network, Mail, Postfix. Ensuite "SuSEconfig --module postfix" règle tout et crée /etc/postfix/main.cf. Si vous regardez ce fichier, vous verrez quelques lignes d'options qui sont générés par SuSEconfig à la fin du fichier. J'ai mis un moment avant de croire que SuSEconfig faisait tout le nécessaire, mais c'est le cas...

Mettre POSTFIX_LOCALDOMAINS à localhost (defaut), <votre.domain.com>, mail.<votre.domain.com>, et tout FQDN que vous pouvez avoir en local (FQDN=Full Qualified Domain Name, Nom de domaine complètement qualifié, c'est à dire avec le nom de l'ordinateur, le nom du domaine, l'extension (fr, com, org...).
Mettre POSTFIX_RBL_HOSTS à un éliminateur de spam (RBL=Real time Black List, Blacklistage en temps réel). J'utilise actuellement elays.ordb.org, bl.spamcop.net, sbl.spamhaus.org, et proxies.relays.monkeys.com. (ndt: mettre beaucoup de sites dans cette liste est une mauvaise idée qui va vous faire perdre des mails. Il vaut mieux choisir soigneusement un site sérieux et s'y tenir, en ce qui me concerne je n'en veux aucun).
Mettre POSTFIX_BASIC_SPAM_PREVENTION à medium. (Hard est une bonne idée, mais il va rejeter plus de courrier que vous ne le voulez). S'il vous faut autant de protection, vous n'allez sans doute pas utiliser ces méthodes automatisées.
Mettre POSTFIX_MDA = procmail.
Mettre POSTFIX_SMTP_AUTH_SERVER = yes.
Mettre POSTFIX_SMTP_TLS_SERVER = yes.
Mettre POSTFIX_ADD_SMTPD_RECIPIENT_RESTRICTIONS = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination.
Mettre POSTFIX_ADD_SMTPD_TLS_AUTH_ONLY = yes.

Après avoir réglé tout ça, exécutez "SuSEconfig --module postfix", ou, au moins, "SuSEconfig". Egalement, si, comme moi, vous utilisez smtpd avec authentification, comme moi, il vous faut "rcsaslauthd start" et "insserv saslauthd".

Egalement, si, après avoir réglé tout ça, vous décidez d'utiliser SSL pour sécuriser vos communications avec le serveur de mail, vous devez générer un certificat SSL. Faites juste "mkpostfixcert" et vous aurez passé l'étape.

Mise à jour : depuis le lancement du virus "Swen", j'ai mis en place une stratégie visant à bloquer les mail avec la plupart des types de pièces jointes. C'est doublement utile. SpamAssassin avait un gros travail pour apprendre à les gérer, et j'ai fini de perdre de la bande passante avec 200 messages de 150ko par jour à effacer de mon disque. Pour faire celà, j'ai finalement trouvé ce [http://www.securitysage.com/antispam/intro.html tutoriel] à SAGE, Spécialement cette page (c'est un [http://www.securitysage.com/files/mime_header_checks fichier à recopier]. Tout ce que vous avez à faire est de créer un répertoire /etc/postfix/maps, et placer ce fichier là. Puis ajoutez une ligne à /etc/sysconfig/postfix du genre 'POSTFIX_ADD_MIME_HEADER_CHECKS="regexp:/etc/postfix/maps/mime_header_checks"', Puis "SuSEconfig --module postfix" and "rcpostfix reload".

NOTE BENE!!! Si vous utilisez votre parefeu comme serveur de mails, vous pouvez avoir un problème. S'il vous plait, lisez soigneusement avant de m'écrire à ce sujet, car vous devez comprendre l'accumulation de circonstances de façon a savoir si vous êtes concerné. La configuration par défaut de Postfix, telle que distribuée par SuSE, configure votre serveur e-mail comme un relay ouvert pour toutes vos interfaces réseau. Normalement vous devriez avoir un serveur de mail derrière un parefeu, et ce ne serait pas un problème, car vous voulez sans doute relayer le courrier pour votre réseau local. Cependant, si vous avez un démon d'e-mail en action sur votre parefeu, et que vous avez une connection à large bande avec un sous réseau partagé, cela fait que vous avez un relai ouvert pour tout le monde sur votre sous réseau ! Si vous tombez dans cette catégorie, ne paniquez pas. La réponse est simple, vous devez simplement ajouter un paramètre à /etc/sysconfig/postfix comme ceci, en vous souvenant de remplacer "192.168.0.0/24" par quelque chose d'approprié pour votre réseau interne.

POSTFIX_ADD_MYNETWORKS="192.168.0.0/24, 127.0.0.1/32"

ndt : [http://www.abuse.net/relay.html l'URL suivante] vous permettra de vérifier si vous êtes ou non en relai ouvert vis à vis de l'Internet (auquel cas il vous faudra prendre des mesures).

Configurer SpamAssassin

Il n'y a qu'une paire de choses à savoir pour faire marcher SpamAssassin. D'abord, après que vous ayez configuré votre MTA ? pour utiliser procmail comme MDA, vous devez modifier /etc/procmailrc. Le mien utilise le réglage spamc/spamd qui est beaucoup plus rapide que la méthode /usr/bin/spamassassin (N'oubliez pas "rcspamd start" et "insserv spamd" !). Ca ressemble à ça :

 :0 hbfw
 | /usr/bin/spamc

Maintenant vous pouvez modifier /etc/mail/spamassassin/local.cf. J'aime particulièrement la manière dont ils ont inclu l'option "defang mime" dans cette version. A nouveau ça ressemble à ça :

 rewrite_subject 0
 report_header 1
 use_terse_report 1
 defang_mime 1

Finalement, vous voudrez sans doute faire quelque chose pour le courrier marqué par SpamAssassin dans votre fichier local ~/.procmailrc. Encore une fois, le mien ressemble à ça :

 :0:
 * ^X-Spam-Status: Yes
 /dev/null

Notez que je me contente de jeter les mails marqués par SpamAssassin. J'ai fini par lui faire assez confiance pour faire ça. Vous pouvez faire autre chose, comme les collecter dans un répertoire séparé pour examen ultérieur. Avec tous ces filtres en place, vous pouvez penser ne jamais voir de spam, malheureusement ce n'est pas le cas. J'en récupère toujours un par jour environ. D'un autre côté, j'en prends 100 par jour !

ndt: certains courriers de vendeurs comme les cartes de téléphone virtuelles d'Iradium risquent de passer pour du spam. En ce qui me concerne, je préfère conserver une journée les spams (mais j'utilise le filtre de mozilla, thunderbird ou kmail, donc sur le client).

Configurer IMAP

Introduction

Ceci est devenu une question fréquemment posée sur les mailing-lists SuSE [suse-linux-e-subscribe@suse.com souscrivez ici si vous voulez]. C'est un peu embrouillé, il vous faudra donc supporter une explication un peu longue.

Le problème vient de ce que SuSE a compilé le paquetage imap-2002 pour qu'il n'accepte pas les mots de passe non cryptés. Vous avez deux options avec le paquetage standard. Vous pouvez soit créer une base de données de mots de passe CRAM-MD5 ou établir l'authentification SSL. Vous avez aussi la troisième option de recompiler le paquetage pour accepter à nouveau les mots de passe non cryptés. Je vais décrire ces trois méthodes et laisser le lecteur déterminer celle qui lui convient le mieux.

Faire une base de données de mots de passe CRAM-MD5

Par défaut, le paquetage uw-imap réalise une authentification avec des mots de passe encryptés en CRAM-MD5. Malheureusement (ou heureusement) cela demande de créer une base de données de mots de passe séparée. C'est malheureux si vous voulez juste que les utilisateurs usuels de la machine puissent récupérer leurs mails avec imap ou pop. D'un autre côté, c'est heureux si vous voulez créér un système ou les utilisateurs principaux du mail n'ont pas besoin de comptes d'utilisateurs. Par exemple, ça peut marcher pour un serveur Samba. Le problème de base c'est qu'il est pénible de gérer deux bases de données. Une fois que vous avez installé imap-2002, les instructions pour configurer cette deuxième base de données de mots de passe sont clairement données dans /usr/share/doc/packages/imap/md5.txt, et je ne les rabacherais pas ici (ndt: il est en anglais, ). Si vous réglez imap pour faire ça, pensez à régler également votre client e-mail pour utiliser les mots de passe CRAM-MD5.

Permettre IMAP par dessus SSL

C'est en quelque sorte la "bonne" façon de résoudre le problème. Par "bonne", je veux dire celle qui suit le mieux la manière "SuSE" de faire les choses. Ce qui signifie que si SuSE fait une mise à jour de sécurité d'un de ces paquetage, la mise à jour automatique que j'ai décrite ailleurs pourra être utilisée et tout continuera à fonctionner, sans re-compilation ni maintenance supplémentaire.

L'installation du paquetage imap-2002 demande un service inetd et je pense que vous devriez installer xinetd pour satisfaire cette condition. Les instructions ci-dessous s'appliquent à ce paquetage particulier. Si vous voulez utiliser l'ancien paquetage inetd, vous avez sans doute vos raisons et vous pouvez modifier ces instructions à votre goût.

D'abord, éditez le fichier /etc/xinetd.d/imap et ajoutez une instance comme :

 #
 # imaps - SSL-encrypted imap mail daemon
 #
 service imaps
 {
        disable         = no
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        server          = /usr/sbin/imapd
        server_args     = -s
        flags           = IPv4
 }

Notez l'addition du "s" dans le nom de service et la ligne supplémentaire "server_args". N'oubliez pas non plus de changer la ligne "disable" (désactiver) en "no" si vous utilisez la configuration existante. J'ai oublié ça souvent. Maintenant vous pouvez faire "rcxinetd reload" et vous devriez voir un service appelé "imaps" dans l'affichage de "netstat -a --inet". Vous devriez pouvoir maintenant utiliser IMAP à travers SSL (port 993) avec vos comptes de mots de passe existants. Une dernière chose, n'oubliez pas de faire "insserv xinetd" pour que xinetd se lance au démarrage.

Ensuite, il vous faudra un certificat SSL pour encrypter la transmission de données entre le serveur et les clients. Cependant, la toute première chose que vous devez faire est de mettre à jour le paquetage openssl installé par défaut. Les nouvelles versions ne cherchent pas le certificat au même endroit que les anciennes, autant régler ça tout de suite. Pour créer effectivement le certificat, (ndt: le doc original indique un article de la base SuSE qui n'existe plus). Les instructions se trouvent là : /usr/share/doc/packages/imap/README.SuSE. Cela revient essentiellement à :

 cd /etc/ssl/certs
 openssl req -new -x509 -nodes -out imapd.pem -keyout imapd.pem -days 365

ndt: l'option -days rends le certificat valide pour un an. Je ne sais pas trop ce qui se passe ensuite, il faut sans doute refaire l'opération ci-dessus (y penser :-).

Recompiler le paquetageg imap-2002 pour accepter les mots de passe non cryptés

Si vous n'avez jamais recompilé un RPM, ne vous découragez pas. Ce n'est pas grand chose si vous avez le RPM source comme base de travail. Cela marche comme dans mon HOWTO sur l'installation des [http://www.davidkrider.com/frontpage.php extensions Front Page] de Microsoft sous Red Hat (). Passez juste root et faites ceci :

Installez le paquetage source (srpm) de imap-2002. Prenez soin d'installer la dernière version que l'on trouve dans le répertoire update des mirroirs.

 rpm -ivh imap-2002-45.src.rpm

Allez dans le répertoire /usr/src/packages/SPECS. Modifiez le fichier imap.spec pour changer "SSLTYPE=nopwd" en "SSLTYPE=unix". Dans mon cas, c'était ligne 83 : "make lnp MYCFLAGS="$CFLAGS" SSLTYPE=unix".
Exécutez (SuSE 8.2) :

 rpm -bb imap.spec

Attention!!!

A partir de la SuSE 9.0, faites :

 rpmbuild --rebuild imap.spec"

Vous allez maintenant trouver trois nouveaux paquetages dans /usr/src/packages/RPMS/i386. Vous devez installer imap-2002-45.i386.rpm et imap-lib-2002-45.i386.rpm pour pouvoir utiliser IMAP. Vous auriez à installer le RPM "-devel" si vous deviez compiler un programme dépendant d'imap, mais je n'en connais pas de bon exemple. Pour celà :

 rpm -ivh imap-2002-45.i386.rpm imap-lib-2002-45.i386.rpm

Après l'installation, modifiez l'instance "imap" dans /etc/xinetd.d/imap pour mettre la ligne "disable" à "no". Ensuite relancez xinetd ("rcxinetd restart") et vous devriez pouvoir utiliser l'authentification non cryptée pour IMAP, sur le port 143. J'espère que vous faites ça pour du traffic entièrement interne...

Installer Apache

Je vais juste dire pour la postérité que j'ai eu un mal du diable à mettre ça en route à nouveau. Après avoir tout configuré sur mon serveur principal à mon domicile, j'ai eu à réinventer la roue sur la façon d'avoir SSL en fonctionnement à nouveau. Je suppose que c'est juste une leçon pour que je sois meilleur à documenter tout ce que je fais sur les ordinateurs. Je suis trop vieux pour continuer à réinventer la roue.

Tout d'abord, je n'aime pas la façon qu'à SuSE de placer la racine du web à /srv/www. En tout cas, je suppose que ça n'est pas important que je le change pour le défaut de Red Hat, /var/www anyway, C'est juste que, même si vous ne vous en occupez pas, il ne sera toujours pas dans une partition montable secondaire. Au minimum, j'aime conserver /var dans une partition différente, au cas où les logs deviendraient fous. Aussi, la première chose que je fais est de faire un répertoire appelé /home/wwwrun et de mettre tout le contenu web là dedans, chaque serveur virtuel dans son propre répertoire.

Maintenant, voilà que yast va multiplier vos efforts de façon très significative. Utilisez-le pour éditer le fichier sysconfig d'Apache, et activez tous les modules que vous voulez utiliser, comme PHP, SSL, et, par exemple, FrontPage. Vous pouvez aussi créer un fichier séparé dans lequel vous mettez toutes vos adaptations, et utiliser yast pour l'inclure dans votre configuration. De façon assez surprenante, j'ai appelé le mien "custom.conf". La variable qui sert à ça est appelée "HTTPD_CONF_INCLUDE_FILES". Cela remplace toute directive du fichier principal httpd.conf sans y toucher. Sinon Yast ne le mettra pas à jour avec les correctifs.

Ajouter les extensions FrontPage

Après avoir installé le fichier mod_frontpage RPM, il vous faudra faire un lien symbolique (A moins que SuSe n'ai corrigé ça). Faites juste "ln -s /usr/lib/frontpage /usr/local".

Ensuite, vous devez créer un compte pour servir d'administrateur Front Page. Je ne sais pas si vous trouverez ça dans la documentation, mais il vous faut un user id plus grand que 500, et un group id plus grand que 100.

Ensuite, "chown" le répertoire dans lequel vous avez installé les extensions vers l'utilisateur et le groupe de l'administrateur Front Page.

N'oubliez pas de modifier votre fichier de configuration Apache pour inclure "AllowOverride All" dans la directive directory.

Enfin, utilisez le programme fpsrvadm.exe pour installer les extensions dans le répertoire contenant le serveur virtuel.

ndt: et si vous pactisez avec le démon en suivant ces instructions, ne venez pas vous plaindre si vous avez des ennuis :-).

Configurer Squirrelmail

note du traducteur

J'ai énormément galéré pour faire marcher IMAP/squirrelmail sur mon serveur. Le premier problème a été que le fichier config/conf.pl de Squirrelmail ne veut pas se lancer sur mon appareil. Je n'ai pas compris pourquoi, mais en lançant perl d'abord, il marche ("perl conf.pl", dans le répertoire config), c'est toujours plus commode que de modifier le fichier de config à la main avec vi :-).

Ensuite, pour une raison que je n'ai pas encore élucidée, sur mon appareil localhost ne réponds pas correctement. Pour que les serveurs imap soient trouvés, il faut que je le désigne par le nom de domaine (dodin.org). C'est probablement ce qui fait que j'ai vainement expérimenté l'utilisation de SSL, alors que netstat me donnait bien imap activé (et imaps).

A noter que j'ai eu des erreurs de lancement de mysql et stunnel (failed en rouge) alors que tout fonctionnait normalement (rcmaysql status -> running).

Configuration

Avec CRAM-MD5

A cause des complications pour travailler avec imap-2002, vous devez faire un saut ou deux pour utiliser Squirrelmail. Maintenant, à ce que je comprends, Squirrelmail peut utiliser les mots de passe CRAM-MD5, Aussi, si vous avez utilisé cette solution avec IMAP, vous pouvez toujours l'utiliser. Cependant, je n'ai pas essayé (ndt: moi si, ca marche).

Avec la version d'IMAP par défaut en CRAM-MD5, il suffit d'indiquer cram-md5 (en minuscules) dans le fichier config.php. Vous pouvez le faire avec

 perl conf.pl

et en suivant les menus, où le modifier à la main dans config.php, on doit avoir une ligne

 $imap_auth_mech = 'cram-md5';

Pour qu'un utilisateur supplémentaire soit possible, il faut qu'il soit créé dans la base cram-md5 d'IMAP (voir ici même).

Avec stunnel

J'ai choisi d'utiliser IMAP sur SSL. Malheureusement, Squirrelmail ne supporte pas encore ça (ndt: peut-être oui, maintenant, avec le plugin de compatibilité). La bonne nouvelle est que vous pouvez le tromper avec stunnel.

La procédure va configurer un service qui va écouter le port IMAP normal, non-SSL (143) et relayer les tentatives de connections vers le port IMAP-SSL (993). En même termps il va encrypter le traffic SSL. Le résultat final est que Squirrelmail peut se connecter sur le serveur par la méthode qui lui convient et qu'il sera connecté au démon IMAP de la manière qui convient à celui-ci. Il agît comme un intermédiaire pour les faire travailler ensembles.

Nota bene (notez-le bien) : Si mon Squirrelmail travaillait sur un autre poste que mon serveur web/e-mail, je ne ferais pas ça de cette manière. Les logins de Squirrelmail arrivent toujours sur le serveur en clair. Si ce traffic d'authentification doit passer par un réseau non fiable, alors vous devez y remédier. Dans mon cas, Squirrelmail se trouve sur mon serveur web et e-mail, aussi le traffic ne touche jamais le câble, et donc ne peut pas être sniffé. Si mon poste est "rooté" alors quelqu'un peut récupérer les mots de passe, mais il pourrait même lire les mails, de toute façon.

ndt: ce n'est pas indiqué dans l'original, mais il faut bien sûr installer stunnel, ce qui se fait avec Yast.

Vous devez éditer le fichier /etc/stunnel/stunnel.conf, changer la ligne "client" par "yes" en haut du fichier, puis rajouter une instance comme ceci :

 [imap]
 accept  = 143
 connect = 993

Notez que la ligne "[imap]" n'est pas optionnelle. Au premier abord, comme tous les exemples sont commentés, je pensais qu'elle était juste là pour la décoration. En fait non.

Maintenant il vous faut un certificat SSL certificate. J'utilise simplement l'exemple de commande montré dans /usr/share/doc/packages/stunnel/README.SuSE.

 (umask 077; /usr/bin/openssl req -new -x509 -days 365 -nodes \
  -config /usr/share/doc/packages/stunnel/stunnel.cnf \
  -out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem)

ndt: il suffit de copier coller le texte ci-dessus dans une console, tel que.

Cela placera le certificat dans le même répertoire que le fichier de configuration, ce qui est l'emplacement où il est recherché, de toute façon. Ceci fait, vous pouvez démarrer stunnel avec rcstunnel start ou "/etc/init.d/stunnel start". Vous pouvez vérifier s'il marche avec "netstat -a --inet". Vous devez voir une ligne comme :

 tcp  0 0 *:imap   *:*  LISTEN

Comme toujours, n'oubliez pas de valider le démarrage avec "insserv stunnel".

En plus de la configuration SSL nécessitée par Squirrelmail pour communiquer avec le démon IMAP, j'aime utiliser SSL pour encrypter le traffic web vers et depuis Squirrelmail contre un éventuel défaut de sécurité du réseau comme, par exemple, pour l'internet. Pour celà, vous devez sécuriser Apache. Vous pouvez faire une clé SSL pour ça avec :

 openssl genrsa -out server.key 1024
 openssl req -new -x509 -days 365 -key server.key -out server.crt

Vous devez alors placer la clé dans le répertoire convenable de /etc/httpd. Après ça, je crée un autre serveur virtuel pour travailler à travers SSL dans la configuration déjà discutée (custom.conf). Je ne devrais sans doute pas faire ça, mais la première mise au point est réellement pénible. Notez que "your.webserver.com" et "/some/other/directory" doivent évidemment être changés pour les valeurs convenables pour votre propre serveur.

 <VirtualHost *:443>
        ServerName <your.webserver.com>
        SSLEngine On
        SSLCertificateFile /etc/httpd/ssl.crt/server.crt
        SSLCertificateKeyFile /etc/httpd/ssl.key/server.key
        DocumentRoot </some/other/directory>
        Alias /mail "/srv/www/htdocs/squirrelmail"
        <Directory /srv/www/htdocs/squirrelmail>
                Options Indexes Includes FollowSymLinks
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>
 </VirtualHost>

Bidouiller les performances d'une carte NVidia

Si vous avez une carte video NVidia, et que vous voulez l'accélération OpenGl pour les jeux video, vous devez télécharger les pilotes Linux sur le site NVidia. Si vous n'avez pas besoin de graphiques 3D, vous pouvez garder le pilote générique de Xfree. Apparemment vous pouvez "installer" le pilote à partir de "YOU" ("Yast Online Update"), mais c'est un intermédiaire supplémentaire dont je n'ai pas besoin, et du coup je ne l'ai pas essayé. Le pilote NVidia est un script shell qui s'occupe de tout, y compris la mise à jour et la désinstallation.

La seule astuce, ici, est qu'après avoir installé le pilote il faut toujours utiliser sax2 en root. C'est encore un autre programme de configuration pour X, mais il marche assez bien. J'en ai surtout besoin pour régler les fréquences de mon moniteur. Après l'installation des pilotes NVidia (à la main ou avec Yast), vous pouvez choisir d'activer l'accélération 3D pendant la configuration avec sax2. Cela entraîneras l'usage des pilotes "nvidia" par /etc/XF86Config au lieu de "nv" (vous pouvez changer ça à la main aussi). L'installation des pilotes NVidia provoque l'écriture d'une ligne dans /etc/modules.conf qui va charger le module du noyau au démarrage.

Arrivé là, vous pouvez exécuter des programmes avec l'accélération OpenGL, Mais vous pouvez aller plus loin pour obtenir les meilleures performances de votre équipement. Par défaut, le pilote NVidia ne tire pas avantage de l'AGP. En laissant de côté certaines particularités avancées de l'AGP, il agît avec précautions car certaines de ces capacités peuvent entrîner une instabilité du système, des blocage, etc. J'ai validé ces options sur mon système et aucun de ces inconvénients n'est apparu. Chacun fait sa propre expérience.

D'abord, vous devez charger un autre module du noyau, "agpgart". Une fois que vous aurez vérifié que tout marche, vous pourrez ajouter ce module à votre processus de démarrage en modifiant /etc/sysconfig/kernel. Ajoutez simplement "agpgart" à la ligne "MODULES_LOADED_ON_BOOT".

Ensuite, vous devez ajouter une autre ligne à /etc/X11/XF86Config. Elle doit aller dans la section "Device" en même temps que les infos sur la carte NVidia) et ressemble à ça :

 Option       "NvAgp" "3"

La documentation pour cette option peut être trouvée dans /usr/share/doc/NVIDIA_GLX-1.0/README. A la base, le "3" permet au pilote NVidia d'utiliser le meilleur interface AGP de la carte avant d'essayer l'interface NVidia par défaut.

Arrivé là, vérifiez que le module NVidia est bien démarré et lancez X. Même si c'est un bon début, il y a encore des bidouillages que vous pouvez réaliser pour que votre carte fonctionne encore mieux. Malheureusement, ils ne sont pas documentés dans le fichier README, je les ai trouvés sur Google.

Une fois que le système de base fonctionne correctement, jetez un oeil sur la sortie de la commande suivante : "cat /proc/driver/nvidia/agp/*". Les 4 premières lignes montrent des faits sur votre carte vidéo. Les 5 suivantes sur votre Carte mère et le reste sur votre statut actuel. Chez moi, j'ai ceci :

 Fast Writes:     Supported
 SBA:             Supported
 AGP Rates:       4x 2x 1x
 Registers:       0x1f000217:0x0f000314
 Host Bridge:     Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller
 Fast Writes:     Supported
 SBA:             Supported
 AGP Rates:       4x 2x 1x
 Registers:       0x0f000217:0x00000314
 Status:          Enabled
 Driver:          AGPGART
 AGP Rate:        4x
 Fast Writes:     Enabled
 SBA:             Enabled

La chose importante à noter est le multiplicateur AGP que votre carte video et votre carte mère supportent et si tous deux supportent "Fast Writes" et "Side Band Addressing". Votre vitesse AGP sont probablement réglés sur la meilleure valeur possible, mais pas FW et SBA. Vous devez ajouter les lignes suivantes dans /etc/modules.conf.local :

 options nvidia NVreg_EnableAGPFW=1 NVreg_EnableAGPSBA=1

Vous pouvez tester le résultat soit en passant en relançant X (par exemple en passant en init 3 et en rechargeant le module NVidia ou simplement en reboutant. Si vous n'avez pas la meilleure vitesse AGP supportée par votre carte video et votre carte mère, vous pouvez aussi ajouter "NVreg_ReqAGPRate=X" à la ligne ci-dessus, avec, évidemment, X=2, 4, or 8.

J'aurais voulu pouvoir dire que ce processus a entraîné une grosse amélioration dans ma vitesse de trame en jouant certains jeux exigeants, en particulier "Unreal Tournament 2003", mais j'ai toujours exactement les mêmes mesures de vitesse avant et après les bidouillages. Pendant mes essais, j'étais sûr que la jouabilité était meilleure à cause de ces modifications, mais la vitesse de trame ne ment pas. J'ai dû changer quelque chose d'autre qui a rendu le jeu un peu plus agréable. Encore une fois, chacun fait sa propre expérience.

Samba et CUPS

Au cas où vous seriez tout débutant avec CUPS, vous pouvez configurer la majorité des options à travers un navigateur pointé sur <nowiki>http://<cups_server>:631/</nowiki>. Cependant, la première chose que vous devez noter après l'installation de CUPS quand vous allez sur cette page est que les pages du serveur n'ont pas l'air tout à fait correct. Le problème vient de quelques liens qui manquent vers une paire de CSS. J'avais donné tout le nécessaire pour corriger ça, mais SuSE l'a corrigé, il vous suffit donc de mettre à jour.

Tout ce que j'ai à faire avec Samba est de montrer les imprimantes CUPS que j'utilise du côté Linux aux clients Windows. J'ai utilisé Windows 98 pour ses possibilités de jeu, mais, franchement, j'ai trouvé que Windows 2000 et ses mises à jour fait aussi bien. Notez qu'alors que 98 ne comprends pas le protocole CUPS natif (IPP), 2000 le fait, aussi si vous voulez utiliser des imprimantes CUPS avec ce système, vous pouvez (et j'essaierai et je mettrais mes observations ici - ndt:il ne semble pas l'avoir fait).

La seule chose que j'ai eu à faire pour que mes clients Windows 98 impriment sur mon serveur CUPS a été de changer quelques options avec SWAT. Si vous ne l'avez pas installé, vous devriez le faire dès maintenant. J'attendrais... Oui, oui. Je sais que vous aurez à faire passer votre mot de passe root à travers l'intranet, mais vous avez confiance en tout le monde, sur votre réseau local, non ? De toute façon tapez <nowiki>http://<samba_server>:901/</nowiki> et changez "Security" en "SHARE," "printcap name" en "CUPS," and "printing" to "cups". J'ai aussi mis "workgroup" à la même valeur que mon nom de domaine interne, mais c'est juste pour le plaisir.

Dans les situations où il faut utiliser un vrai domaine, vous aurez sans doute aussi à changer "PAM password change" et "unix password sync" pour "Yes" pour que les utilisateurs puissent modifier eux-même leur mot de passe. Avec tant de façon de configurer Samba pour autant d'OS différents, il faut que je pense à mettre ici une note sur la fazçon de faire, que je puisse y regarder si j'oublie.

ndt:

A la date de Juillet 2005, c'est tout ce que david a écrit. Permettez-moi de compléter.

Il y a longtemps maintenant que les réglages ci-dessus sont faits par défaut (par exemple sur la 9.0 que j'utilise sur mon serveur.

Je n'aime pas SWAT. En fait, je n'aime aucun des systèmes de configuration web que je connais. J'utilise celui de CUPS car je ne sais pas encore faire le travail à la main (CUPS est bien plus complexe que lpd), mais pour Samba, il est si facile de modifier à la main le fichier smb.conf, que ça ne vaut pas la peine de s'en priver.

Squid et SquidGuard

J'ai mis ça en place pour me protéger de ce qui est désagréable sur le net. Il n'est pas aussi bon que Dan's Guardian, car il ne fait pas blocage basé sur le contenu, Mais je voulais l'essayer de toute façon, et je vais vous dire pourquoi. D'abord, c'est une expérience intéressante. Ensuite j'ai une fille qui a environ 4 ans et demi au moment où j'écris et elle va commencer à butiner sur internet dans une paire d'années. Il m'en faudra un peu plus à ce moment.

En résumé, je veux un proxy filtrant qui puisse tourner sur mon parefeu. Avec cet arrangement j'espère créer un dispositif qui ne puisse être contourné poiur empêcher ma famille de voir des quantités de choses qu'elle ne doit pas voir. J'allais écrire une courte explication à ce sujet, mais j'ai vu que ça partait en spirale et hors de contrôle rapidement. Je laisse ça pour une autre page. Avec ce réglage, je serais en mesure de bloquer tout le traffic sortant sauf celui qui passe par le proxy du parefeu. A moins que mes enfants piratent mon pare feu et deviennent root. Ce qui me rendrait très fier. D'autres services seront bloqués également.

ndt: je comprends la problématique de David, mais je suis pas sûr d'être de son avis. Il est illusoire de vouloir empêcher un enfant de voir ce qu'on ne veut pas qu'il voie. Mon fils ne s'est pas gêné pour aller voir des cassettes porno chez un copain et même pour m'en ramener (marquées "cours de math", c'est comme ça que je les ai trouvées, il n'aurait jamais visionné une cassette de math :-). Dans mon lycée beaucoup de sites intéresssants ne sont pas accessibles car "bloqués" alors que mes élèves visionnent tout ce qu'ils veulent dès qu'ils pensent que j'ai le dos tourné. Une bien meilleure méthode est l'éducation - surfez avec vos enfants sur les sites litigieux (au cours d'une séance éducative, pas tous les jours :-), vous verrez qu'ils seront vite plus choqués que vous si ils ont reçu l'éducation appropriée. Manifestez vigoureusement votre désaprobation quand à l'usage de ces sites, le plus choquant étant qu'il est difficile de ne pas tomber dessus par hasard. Savoir éviter les mauvais garçons est utile dès le plus jeune âge, à moins que vous ne puissiez payer un garde du corp à vos enfants.

Malheureusement, sur SuSE, la configuration par défaut ne vous mènera pas très loin.

installez squid et squidGuard
téléchargez la dernière archive de liste noire depuis le site de squid, Copiez son contenu dans /var/lib/squidGuard/db, Donnez à squid la propriété de ces fichiers si ce n'est pas déjà le cas.
Modifiez /etc/squid/squid.conf pour avoir une ligne de ce genre :

 redirect_program /usr/sbin/squidGuard

Faites une autre modification au fichier squid.conf pour permettre à votre réseau interne d'accéder au proxy (inutile si vous installez squid sur votre machine personnelle pour une raison ou une autre).

 acl local_internal_network src 192.168.4.0/24
 http_access allow local_internal_network

Modifiez /etc/squidguard.conf. Des instructions très utiles commencent ici.
Démarrez le service squid
Faite que le service squid démarre au boot
Modifiez la configuration de votre parefeu pour autoriser le réseau interne à accéder à votre proxy
De plus, vérifiez que votre parefeu peut faire les ports tcp 80, 443, et 23
Réglez votre navigateur pour qu'il pointe sur le proxy au port 3128

A un moment ou à un autre, il faudra que je mette un mot de passe pour pouvoir contourner ça si j'en ai besoin, mais ça fera l'affaire pour le moment.

Nagios

"Nagios" is a web application that monitors servers and services. It can email you when problems arise. It can even dial a modem with an add-on. I use it where I work, and it works quite well. Just about anything you can imagine wanting from something like this, it does. Just to make a note about it, I'm documenting a few notes about how to get it running. Probably the most significant part of what I've done to get Nagios running (for my workplace) is that I found a script that checked on the status of FlexLM license managers, and hacked it up both for how I wanted it to work, and made a new version for checking IBM iFor license managers as well. Since the original was open source, they are included below. (I should document them better or something.)

Change user daemon to have a home directory, say, /home/daemon, and setup ssh keys for that account there.
Edit /etc/nagios/nagios.cfg.
Install the flexlm binaries and the check_flexlm nagios script.
Install the LUM for Linux RPM and configure it to look at the iFor server. Then install the check_ifor script.
Install the check_nt binary.

Un DNS à deux têtes

"Split-Brained" DNS

I finally needed to do this for a project, and I just wanted to make a note about it here for future reference. When splitting my DNS server, I chose to make two instances, one for handling each side of the serving. I simply made two copies of /etc/named.conf, one called named-internal.conf, and you can guess the other. Then I created the directory /var/run/named, and chowned it to named:named. In the named-*.conf files, I included lines like the following:

listen-on port 53 { 127.0.0.1; 192.168.0.1; };

pid-file "/var/run/named/named-internal.pid";

Note that this sort of gets out of YaST's ability to handle. Rather than trying to graft this sort of thing into the standard rc script sort of arrangement, I took the weasley way out and simply added two lines to /etc/init.d/boot.local, like so:

/usr/sbin/named -u named -c /etc/named-external.conf /usr/sbin/named -u named -c /etc/named-internal.conf

You'll lose some control this way (no ``rcnamed reload'' now), but I felt the tradeoff was worth it.

Dernier commentaire par david

This page last updated July 16, 2005. All content copyrighted © 1997-2005, David Krider, all rights reserved. Acts 17:28, "For in Him we live, and move, and have our being." Free Software: Will you use the power for good... or for awesome? Problems emailing me? Try here.