Page suivante Page précédente - Table des matières

13. FAQ

Q1. J'ai créé un sendmail.init et syslogd.init. Je les ai mis dans /usr/local/bin et essayé de les lancer, mais ils me donnent des erreurs.

R1. Ces fichiers sont appellés scripts d'initialisation. Ils sont lancés par le programme init quand votre ordinateur démarre. Ils ne vont pas avec les binaires de /usr/local. Consultez le Guide de l'Administrateur Système Linux (Linux System Administrators Guide) ou le Guide pour Bien Démarrer avec Linux (Linux Getting Started Guide) pour des informations sur la manière d'utiliser les scripts d'initialisation du système.

Q2. J'ai mis ces lignes dans /etc/sendmail.cf :

divert(0)
VERSIONID(`tcpproto.mc')
OSTYPE(linux)
FEATURE(redirect)
FEATURE(always_add_domain)
FEATURE(use_cw_file)
FEATURE(local_procmail)
MAILER(local)
MAILER(smtp)

Et j'obtiens une sortie vraiment étrange. Pourquoi ?

R2. Vous ne devez pas mettre ces lignes directement dans /etc/sendmail.cf. Le fichier sendmail.cf a été écrit pour que sendmail le comprenne facilement et est difficile à lire aux humains. Ainsi, pour le rendre facile à configurer, nous utilisons un programme appellé m4 et ses capacités de macros pour créer le fichier sendmailf.cf . Les lignes FEATURE sont en fait des macros qui se développent par rapport à la configuration de Sendmail. Lisez la documentation de sendmail pour savoir comment configurer sendmail avec cette méthode. Aussi, notez que vous créez un fichier /etc/sendmail.cf principal et le script virtfs le copie sur /virtual/domain1.com/etc/sendmail.cf. Puis, vous éditez ce sendmail.cf pour l'adapter à votre domaine.

Q3. Ou puis-je trouver virtuald, qu'est-ce donc et comment l'utiliser ?

R3. Virtuald est un programme en C que j'ai écrit pour lancer un service virtuel. Il est inclus dans ce HOWTO. Vous le compilez comme un programme C normal : make virtuald . Le binaire résultant est placé dans /usr/local/bin. Ajoutez les lignes nécessaires à /etc/inetd.conf pour utiliser virtuald comme une facade vers un programme serveur.

Q4. Dialog n'est pas installé sur mon système ?

R4. Dialog est un programme qui permet d'avoir des fenêtres dans vos scripts shell. Il est nécéssaire pour faire fonctionner mon script shell virtuel. Vous pouvez trouver une copie de dialog sur metalab. Il ne devrait pas y avoir de problèmes pour le compiler et l'installer.

Q5. Comment puis-je savoir si le syslogd virtuel marche ?

R5. Quand virtuald est lancé, il doit envoyer le message suivant à syslogd (/var/log/messages) :

Nov 19 17:21:07 virtual virtuald[10223]: Virtuald Starting: $Revision: 1.1.1.1 $
Nov 19 17:21:07 virtual virtuald[10223]: Incoming ip: 204.249.11.136
Nov 19 17:21:07 virtual virtuald[10223]: Chroot dir: /virtual/domain1.com

Le message du chroot est envoyé par virtuald une fois l'appel système chroot effectué. Si ce message apparaît, alors le syslogd virtuel fonctionne. Si le service que vous rendez virtuel logue les messages par syslogd et que vous les voyez, c'est aussi un signe que le syslod virtuel fonctionne correctement.

Noter que si vous n'avez pas mis l'option VERBOSELOG lors de la compilation, Virtuald ne loguera pas du tout. Le seul moyen de savoir si le syslogd virtuel marche dans ce cas là, c'est de voir si un démon qui rend un service virtuel indépendamment, logue quelque chose avec syslogd.

Q6. Comment puis-je installer des quotas à travers un système de fichiers virtuel ?

R6. Vous l'installez comme vous le feriez d'habitude. Aller voir le Quota mini-HOWTO. Cependant, vous devez être sûr qu'il n'y ait pas de conflits d'uid entre les domaines. S'il y'a des conflits, les utilisateurs devront partager un quota. Préparez un intervalle d'uid qui auront le quota activé et dites aux domaines qu'ils ne peuvent avoir d'utilisateurs dans cet intervalle, à part ceux qui sont retenus pour avoir un quota.

Q7. Que fait cette notation "\" dans toutes les entrées du inetd.conf ?

R7. C'est juste une méthode pour couper une ligne d'un fichier de configuration en deux lignes. J'ai fait ça pour que les lignes puissent avoir un retour à la ligne de manière à obtenir une meilleure présentation. Vous pouvez ingorer le "\" et les rejoindre en une seule.

Q8. Quand je lance passwd ou n'importe quel programme concernant les logins, le système me renvoie permission denied . Quand je lance FTP ou su le système me renvoié no modules loaded for service XXX . Pourquoi ?

R8. Ce sont les messages d'erreur de PAM. J'ai écrit les scripts avant que PAM ne sorte. Mon script virtfs ne copie pas /etc/pam.d , /usr/lib/cracklib_dict.* , /lib/security ou n'importe quel fichier dont PAM a besoin. PAM en a besoin pour fonctionner. Si vous éditez mon script virtfs pour copier ces fichiers, il n'y aura plus de problèmes.

Q9. Est-ce que virtuald peut fonctionner avec les hosts.allow et hosts.deny de tcpd ?

R9. Oui, il peut, mais avec quelques modifications.

D'abord, le code source doit être changé en deux endroits.

Il faut insérer ces lignes là où les arguments sont analysés.

 if (!argv[3])
 {
 syslog(LOG_ERR,"invalid arguments: no program to run");
 exit(0);
 }

La ligne d'exécution doit remplacer :

 if (execvp(argv[2],argv+2)<0)

par :

 if (execvp(argv[2],argv+3)<0)

Deuxièmement, les lignes du fichier inetd.conf  :

ftp stream tcp nowait root /usr/local/bin/virtuald \
 virtuald /virtual/conf.ftp tcpd wu.ftpd -l -a

Troisièmement, éditer les fichier /virtual/domain1.com/etc/hosts.allow et /virtual/domain1.com/etc/hosts.deny pour mettre vos paramètres.

Q10. Est-ce que mon serveur virtuel peut lancer des CGI ?

R10. Bien sûr, mais je vous recommande de mettre le répertoire /cgi-bin à un endroit en dehors du chroot , où vous seul avez accès. Par exemple, /var/www/cgi-bin/domain1.com. Donner l'accès aux cients à /cgi-bin leur donne la possibilité de lancer des programmes sur votre serveur. C'est un gros trou de sécurité. Soyez prudent. Je ne laisse aucun CGI tourner sur mon système sans que je n'ai pas personnellement cherché d'éventuels bugs.

Q11. Mes fichiers de configuration sont différents de vos exemples. Que dois je faire ?

R11 Il y a deux styles de configuration : System V et BSD. Les exemples fournis dans ce HOWTO sont basés sur les fichiers de configuration System V. Les services virtuels marchent aussi bien sur l'autre système. Pour des informations sur la méthode pour configurer vos fichier de style BSD, consultez l'origine de votre distribution ou le site LDP le plus près.

Q12. Je vous ai envoyé un mail et n'ai pas reçu de réponses ou alors elles ont pris un long moment avant de me parvenir. Pourquoi ?

R12. Vous n'avez sûrement pas mis VIRTSERVICES HOWTO dans le sujet. Sachez que je suis un administrateur réseau, et que parmi mes 20 heures par jour, j'administre mes machines virtuelles et celles de mes clients. Un mail qui est proprement adressé aura toujours une réponse dans les deux ou trois jours suivants. Les mails mal adressés ne seront pas filtrés vers ma boîte aux lettres pour VIRTSERVICES, et peuvent m'être inconnus pendant plusieurs jours, voir semaines.

Q13. Est-ce que virtuald marche avec une connection a 100Mbit ?

R13. La vitesse d'une carte réseau est totalement indépendante du fait que virtuald fonctionne ou pas. Vérifiez que votre serveur tourne sous 10Mbit et que votre carte 100Mbit fonctionne normalement sans un serveur virtuel.

Q14. Est-ce que je dois utiliser la table virthost de sendmail ?

R14. Non, c'est une fonctionnalité de Sendmail qui reçoit les informations pour plusieurs domaines. Virtuald donne à chaque Sendmail son propre environnement chroot . Installez Virtuald et configurez sendmail comme vous le feriez à l'habitude pour chaque domaine.

Q15. Puis-je installer un telnet virtuel sur ma machine ? Et est-il possible de créer un compte root virtuel, pour que les client puissent administrer leur propre domaine ?

R15. Ces questions reviennent souvent, et pour etre honnête, j'en ai un peu marre de les entendre. La réponse, qui est dans ce document, est que n'importe quel service lancé par inetd peut être rendu virtuel, donc rien ne vous empêche de le faire. Rien, à part le bon sens. Cependant, les bénéfices que vous pouvez avoir sont fortement altérés par le prix de la securité de votre machine virtuelle (ainsi que les sites que vous êtes supposés héberger d'une manière résponsable). Voici quelques exemples :

  • Afin de duper une session telnet entrante vous devez modifier le noyau, pour avoir plusieurs proccessus, réinitialiser votre adresse IP source pour les connections sortantes, duper gethostname pour qu'il utilise le nom de domaine virtuel et non celui du système, etc. Si vous êtes un utilisateur avancé, hackez le kernel. Pour un débutant, je ne le recommande pas.
  • En autorisant les utilisateurs à venir sur votre machine en telnet, vous les autorisez à lancer des programmes dangereux. Et ceux qui savent hacker peuvent prendre les privilèges root et causer des dommages sur votre système.
  • Donner un accès root en telnet sur une machine virtuelle est très mauvais. Un utilisateur root virtuel peut quand même lire les fichiers des péripheriques , ce qui annule le chroot , peut éteindre le système et tuer les autres processus sur le système.
  • Telnet est un service réseau non sécurisé. Des mots de passes sont envoyés en clair par le réseau. Si un utilisateur avec de mauvaises intentions récupère ce mot de passe, il ou elle peut utiliser les attaques mentionnées ci-dessus pour nuire à votre système.
  • Votre environnement virtuel devra être plus gros. Vous aurez besoin de plus de librairies, plus de fichiers de configuration, et plus d'exécutables. Un disque de 6Go peut être très vite rempli.

Comme quoi, c'est une très mauvaise idée d'autoriser des connections sur une machine virtuelle. Si vous le permettez, tous les sites hebergés sur cette machine seront en danger. Si vous voulez autoriser un propriétaire de site à administrer ses utilisateurs, vous devez alors écrire (pas de script) le programme nécessaire pour lancer un processus virtuel qui l'autorise à les ajouter, effacer ou modifier en se connectant par ssh. Ceci devra être complètement exécuté par menus, vous ne devrez jamais autoriser de consoles, ou d'accès root. Afin d'accomplir ceci, vous devrez changer le propriétaire des fichiers concernés de root à un autre utilisateur. Si c'est fait de cette maniere, c'est assez securisé pour être incorporé dans une machine virtuelle. Il ne sera jamais acceptable d'autoriser des connections root en telnet ou ssh. Le faire, serait simplement une invitation au désastre. S'il y avait une raison de le faire, le site devrait être hébergé sur une machine dédiée, où le risque serait juste pour lui. Aucun administrateur responsable ne ferait autrement et donc je ne perdrai pas plus de temps sur cette question.

Q16. Y a-t-il un rpm, tar, site web, liste de diffusion, etc. associé à virtuald et au Virtual-Services HOWTO ?

R16. Pour le moment il n'y a rien de tout ceci. Ce HOWTO est la seule source d'information sur tout ce que j'ai fait concernant ce projet. Je trouve ce HOWTO assez informatif, rendant le besoin d'autres renseignements superflu.

Q17. Quand j'essaye de lancer virtexec en tant que simple utilisateur, j'ai chroot: operation not permitted . Pourquoi ?

R17. chroot est un appl système restreint au root. Seulement le super utilisateur peut l'executre. Le script virtexec lance le programme chroot ce qui implique le besoin d'être root pour le lancer.

Q18. J'ai mis en place pop et sendmail, mais la récuperation des mails ne semble pas marcher. D'où cela vient-il ?

R18. Certains programmes pop prennent comme emplacement des fichiers mail /usr/spool/mail . Je sais que qpop doit etre édité manuellement pour résoudre ce problème. Soit vous recompilez les sources de votre programme, soit vous faites un lien symbolique de /virtual/domain1.com/usr/spool vers /virtual/domain1.com/var/spool .

Q19. Je n'ai pas utilisé le programme mentionné dans votre HOWTO, j'utilise le programme XXX. Il ne marche pas. Pourquoi ?

R19. J'ai essayé de faire des exemples le plus génerique possible pour chaque serveur. Je sais que certaines personnes ont leur version favorite de chaque serveur. Envoyez-moi le plus d'informations possible, et j'essaierai de trouver une solution à votre problème et je l'incluerai dans la FAQ. L'information la plus importante est de me dire ou trouver la version du programme que vous utilisez (sous la forme ftp://ftp.domain.com/subdir/subdir/file.tgz).

Q20. Quand je lance virtexec il dit symlink not a virt function . Qu'est-ce que cela veut dire et comment le réparer ?

R20. Virtexec est programme pour lequel les arguments sont les quatres premiers caractères, et il lance le nom restant dans l'environnement virtuel. Par exemple, virtpasswd lance passwd . Si les quatres premiers caracteres ne sont pas virt , il se plaint et sort un message d'erreur. Virtexec est écrit en script shell et devrait être très simple à porter. Référez vous aux pages de manuels de bash ou du shell que vous utilisez pour vos question sur la programmation de script shell.

Q21. J'ai une question à propos de Qmail, Samba, Apache, etc. qui n'a aucun rapport avec la mise en place de virtuald ou l'interface entre le paquetage et virtuald.

R21. Tous les paquetages décris ici sont pleinement documentés. Certains ont un site web comme www.nom_du_paquetage.org qui leur est entièrement dédié. S'il vous plait consultez ces documents à propos de ce genre de questions.

Q22. J'ai plusieurs alias de domaines pointant sur domain1.com mais les mails continuent à être renvoyés aux alias. D'où est-ce que ca vient ?

A22. Virtmaildelivery compte sur les variables d'environnement qui lui sont passées pour déterminer quel répertoire /virtual/domain1.com utiliser pour distribuer le courrier. Il ne fait pas de recherche DNS pour déterminer l'adresse du mail. Puis, si l'adresse est submail.mail.domain1.com , virtmaildelivery essayera en premier cette adresse puis mail.domain1.com et puis domain1.com . Il essaye dans cet ordre, jusqu'à ce qu'une concordance ait lieu où qu'il ne reste plus de noms de domaines.

De toutes facons, si vous avez des alias de domaines qui ne sont pas des sous-domaines d'un autre, vous devez créer des liens symboliques comme :

cd /virtual
ln -s domain1.com domain1alias.com

De cette manière, virtmaildelivery sera trompé en pensant que ces mêmes répertoires existent même si l'un d'eux est un lien symbolique et le mail pourra être distribué à user@domain1.com ou user@domain1alias.com . Notez que virtexec listera les deux répertoires des domaines dans la boîte de dialogue quand vous le lancerez. Vous pouvez choisir n'importe lequel, mais ce sera le même système de fichier.


Page suivante Page précédente - Table des matières