Créer un sous-domaine avec un user spécifique

Ce billet est inspiré de ce post du forum OVH : http://forum.ovh.net/showthread.php?p=511134#post511134, merci à jicao son auteur. Il a pour but de répondre à une question récurrente parmi les utilisateurs de serveurs en release 2 OVH : comment créer un sous-domaine qui appartienne à un utilisateur spécifique (et non pas à l’utilisateur du domaine principal).

La question peut en effet se poser lorsqu’on souhaite confier la gestion d’un sous-domaine à un tiers (y compris l’accès FTP) sans pour autant lui confier le mot de passe de l’ensemble de l’hébergement du domaine en question. Ce cas de figure n’est malheureusement pas prévu dans la release OVH. En effet, la release 2 OVH (en particulier son module OVHm) permet sans problème de créer un nombre illimité de sous-domaines (sd1.domaine.com, sd2.domaine.com, etc.), mais tous appartiendront obligatoirement à l’utilisateur qui est lié à l’hébergement de domaine.com. Il faut donc se connecter avec le login et le mot de passe de l’hébergement de domaine.com pour y accéder, ce qu’on souhaite précisément éviter. Il va donc falloir ruser … et voici comment faire :

1) Créer le domaine et le sous-domaine voulus dans OVHm

Cela se fait le plus naturellement du monde, là : https://12.34.56.78:10000/?cat=ovhm (et cela se passe de commentaire)

2) Créer l’utilisateur qui sera dédié à ce sous-domaine

Il est possible de faire cela par Webmin :
Système > Utilisateurs et groupes > Créer un nouvel utilisateur
Autrement dit, là : https://12.34.56.78:10000/useradmin/edit_user.cgi

A cet endroit, il vous faudra remplir au moins les champs suivants :

  • Nom d’utilisateur : c’est arbitraire, à vous de choisir
  • Mot de passe (Mot de passe normal) : encore une fois à vous de choisir, n’oubliez pas de choisir un mot de passe fort.
  • Interpréteur de commandes : /bin/false/
Le but de mettre l’interpréteur de commandes à /bin/false/ est d’interdire à votre futur utilisateur l’accès SSH à votre serveur. C’est prudent … mais il est cependant possible que vous souhaitiez permettre à votre utilisateur de pouvoir se connecter en ligne de commande. Auquel cas il convient de mettre /bin/bash à cet endroit  mais il est alors recommandé de régler le paramètre “Groupe primaire” (un peu plus bas sur la page) à “

3) Modification du VirtualHost dans Apache

Jusqu’ici nous avons créé un sous-domaine dans OVHm (ce qui a eu pour effet de créer un répertoire /home/domaine/sd/sousdomaine/www) et nous avons créé un utilisateur système (ce qui a eu pour effet de créer un répertoire /home/utilisateur/www/). Il va à présent falloir demander au serveur web (Apache) de ne pas aller chercher le sous-domaine dans /home/domaine/sd/sousdomaine/www/, mais bien dans /home/utilisateur/www/.

Pour ce faire, rendez vous dans le module Apache :
Webmin > Serveurs > Serveur Web Apache > Configuration globale > Édition des fichiers de configuration
Autrement dit, là https://12.34.56.78:10000/apache/allmanual_form.cgi

Trouvez à cet endroit (probablement tout en bas de la zone de texte) la partie qui ressemble à ceci :

<VirtualHost 12.34.56.78:80>
ServerAdmin webmaster@domaine.com
DocumentRoot /home/domaine/sd/sousdomaine/www
SuexecUserGroup domaine users
ServerName sous.domaine.com
CustomLog logs/sous.domaine.com-access_log combined
ScriptAlias /cgi-bin/ /home/domaine/cgi-bin/
AddHandler x-httpd-php5 .php
</VirtualHost>

Et remplacez là par ceci (en adaptant, bien sûr) :

<VirtualHost 12.34.56.78:80>
ServerAdmin webmaster@domaine.com
DocumentRoot /home/utilisateur/www
SuexecUserGroup utilisateur users
ServerName sous.domaine.com
CustomLog logs/sous.domaine.com-access_log combined
AddHandler x-httpd-php5 .php
</VirtualHost>

Attention à adapter la ligne “SuexecUserGroup” si vous avez décidé de  créer un nouveau groupe du même nom que l’utilisateur (voir le point 1 concernant l’accès SSH). Dans ce cas, cette ligne doit être du genre :

SuexecUserGroup utilisateur utilisateur

Et enfin sauvegardez.

4) Relancer le bouzin

Ne pas oublier de retourner un coup dans OVHm et de cliquer sur le fameux lien “Redemarrer tous les services (pour prendre en compte les changements)”, ce qui aura pour effet de relancer Apache (et donc de prendre en compte les changements que vous avez faits).

Et si je veux une base de données pour ce sous-domaine ?

Et bien ça non plus ce n’est pas prévu dans la release OVH … mais il y a également moyen de ruser, assez simplement d’ailleurs. Il suffit de vous connecter à phpMyAdmin (https://12.34.56.78/phpMyAdmin/), puis cliquer sur “Privilèges” et ensuite “Ajouter un utilisateur”.

Sur la page suivante, il vous faudra choisir un nom d’utilisateur (il ne doit pas forcément être identique à l’utilisateur système que vous avez créé au point 1) ainsi qu’un mot de passe. Dans le champ “serveur”, choisissez “Local”. Il reste alors à choisir, un peu plus bas sur la page, l’option “Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base”. C’est tout : votre nouvel utilisateur (MySQL cette fois) aura les pleins pouvoirs sur cette base, mais sur cette base seulement.

Et si je veux supprimer le tout ?

Et bien il suffit défaire ce que vous avez fait, soit :

  1. Vous rendre dans OVHm et supprimer le sous-domaine
  2. Vous rendre dans “Webmin > Système > Utilisateurs et groupes” et supprimer l’utilisateur que vous avez créé
  3. (si vous avez créé une base de données) Supprimer la base de données dans phpMyAdmin ainsi que le user MySQL que vous avez créé pour cette base.

Enjoy 🙂

Virtualmin + Debian : Usermin pas démarré au boot

A tous les coups c’est pareil : il suffit que je prenne quelques jours de congé pour qu’il se passe un truc bizarre qui m’oblige à bosser. Ca doit être la loi de Murphy…

Enfin bref, voici donc le truc bizarre du jour (sur un serveur installé en Debian Lenny + Virtualmin) : un client me dit que Usermin (le webmail qui vient avec Virtualmin et qui se trouve sur le port 20000 – au contraire de Webmin qui se trouve sur le port 10000) n’est plus accessible suite à un reboot de son serveur. Vérification faite, Usermin n’était tout simplement pas lancé. Il a suffit donc de :

/etc/init.d/usermin start

Et tout est rentré dans l’ordre. Seulement voilà, c’est bien … mais pas suffisant : au prochain reboot, Usermin risque fort de ne plus être lancé. On a beau ne pas rebooter tous les jours, il faut tout de même que cela tienne le reboot ! Je m’empresse donc de vérifier sur un serveur de test et j’arrive à reproduire le problème : Usermin ne se lance effectivement plus au démarrage. Cela doit probablement dater d’une des dernières mises à jour de Usermin (peut-être la version 1.480 datant du 5 aout dernier mais j’ignore précisément laquelle car je reboote fort heureusement assez rarement).

Après une petite recherche Google, il semble que la solution n’est pas bien compliquée (mais pas forcément facile à trouver, d’où ce billet). Elle se trouve ici : http://readlist.com/lists/lists.sourceforge.net/webadmin-list/2/13638.html. Il suffit donc de :

insserv usermin

Et le script d’init est à nouveau correctement activé (au besoin, installer le paquet insserv par apt-get install). Testé et approuvé : ça tient à présent le reboot.

Voilou, ce n’est pas très fouillé et je n’ai pas testé à fond … mais bon, n’oublions pas que je suis en vacances 😉

Virtualmin et DNS secondaire chez OVH

Si vous installez Virtualmin sur un serveur dédié et que vous vous empressez de créer un hébergement (un “Virtual Server” en langage Virtualmin), voici le genre de zone Bind que vous allez obtenir pour votre nom de domaine. Elle sera automatiquement créée par Virtualmin  et, pour l’exemple, je prends ici syrelis.com comme nom de domaine, 11.22.33.44 comme adresse IP et ns1234.ovh.net comme nom de serveur :

(contenu de /var/lib/bind/syrelis.com.hosts)

$ttl 38400
@    IN    SOA    ns1234.ovh.net. root.ns1234.ovh.net. (
1299337556
10800
3600
604800
38400 )
@    IN    NS    ns1234.ovh.net.
syrelis.com.    IN    A    11.22.33.44
www.syrelis.com.    IN    A    11.22.33.44
ftp.syrelis.com.    IN    A    11.22.33.44
m.syrelis.com.    IN    A    11.22.33.44
localhost.syrelis.com.    IN    A    127.0.0.1
webmail.syrelis.com.    IN    A    11.22.33.44
admin.syrelis.com.    IN    A    11.22.33.44
mail.syrelis.com.    IN    A    11.22.33.44
syrelis.com.    IN    MX    5 mail.syrelis.com.
syrelis.com.    IN    TXT    "v=spf1 a mx a:syrelis.com ip4:11.22.33.44 ?all"

A première vue, ça a une bonne tête, mis à part peut-être le numéro de série (ici : 1299337556) qui devrait plutôt être au format “année-mois-jour-chiffre-chiffre”, soit 2011030501 à l’heure où j’écris ces lignes) mais passons, ce n’est pas le but de ce billet…

Il manque en tout cas quelque chose d’important, vous ne trouvez pas ?

Il s’agit bien sûr d’un champ NS, car savez sûrement que l’usage veut qu’un nom de domaine doit avoir 2 serveurs DNS. Il est donc logique que sa zone Bind ait 2 champs NS !

Toujours en suivant notre exemple, syrelis.com doit donc avoir 2 serveurs DNS : (1) le primaire qui correspond au serveur sur lequel est installé le site (en l’occurrence ns1234.ovh.net) et (2) le secondaire, qui dépend d’OVH. Chez OVH, quand vous installez un nom de domaine sur un serveur dédié, ils est d’ailleurs nécessaire d’inscrire vous-même le nom de domaine sur le DNS secondaire. Cela se passe dans le manager, plus précisément là (ns1234.ovh.net > Services) :

Inscrire votre nom de domaine dans le DNS secondaire (sdns2.ovh.net – ou bien ns.kimsufi.com si votre serveur est un Kimsufi), c’est bien. Mais faire en sorte que votre serveur communique avec le DNS secondaire, c’est bien mieux ! Pour cela, retournons à votre serveur et ajoutons une ligne dans la zone Bind du nom de domaine :

@    IN    NS    sdns2.ovh.net.

Simple, non ? Oui, mais le problème c’est qu’il va falloir le faire à chaque fois que vous créez un hébergement sur le serveur via Virtualmin. Là, c’est tout de suite moins cool…

Heureusement, il y a une parade simple : juste un petit paramètre à ajouter dans Virtualmin. Commencez donc par cliquer sur System Settings > Server Templates :

Puis sur Default Settings :

Et enfin choisissez BIND DNS Domain :

Ajoutez alors sdns2.ovh.net (ou bien ns.kimsufi.com si votre serveur est un Kimsufi) dans le formulaire, là  :

Et sauvez.

C’est tout. Dorénavant, tous les “Virtual Server” que vous allez créer auront les bons champs NS dans leur zone Bind et, cerise sur le gâteau, toutes les modifications que vous allez faire sur votre serveur (ajout/suppression de sous-domaines par exemple) seront automatiquement transmises au DNS secondaire 🙂

Release OVH : OVHm et les domaines avec accents

Tiens, un petit bug dans la release OVH … et du coup, hop, un petit billet 🙂

Comme le savent les utilisateurs de cette distribution, OVHm est le module Webmin qui permet de gérer les hébergements et les noms de domaines qui se trouvent sur le serveur. Ce module permet sans problème de créer un hébergement pour un nom de domaine contenant des caractères spéciaux, notamment des accents. Par exemple accentué.com <– ce nom de domaine est libre à l’heure où j’écris ces lignes, allez-y, foncez ! 😉 Il suffit simplement d’indiquer à OVHm le punycode de votre nom de domaine (dans notre exemple : xn--accentu-hya.com) et ça fonctionne très bien.

Là où ça se gâte un peu, c’est quand on souhaite créer un alias de nom de domaine : on a beau essayer accentué.com ou bien xn--accentu-hya.com, rien n’y fait, OVHm nous envoie sur les roses :

Moche hein ? Oui, mais rien de grave : OVHm refuse en fait qu’un nom de domaine contiennent deux tirets qui se suivent.

La solution est toute bête, il suffit simplement d’aller modifier le fichier /usr/libexec/webmin/ovhm/ajouter_alias.cgi

Repérez la ligne :

&error ($text{'domaine_ko'}) if ($alias !~ /^[0-9a-zA-Z]+(-[0-9a-zA-Z]+)*(\.[0-9a-zA-Z]+)+$/);

Et remplacez la par :

&error ($text{'domaine_ko'}) if ($alias !~ /^[0-9a-zA-Z]+(-+[0-9a-zA-Z\-]+)*(\.[0-9a-zA-Z]+)+$/);

Fastoche !

Relancer les services mail en release 2 OVH

Un petit billet en vitesse à destination des clients OVH qui administrent leur serveur en release 2 via Webmin.

Il arrive régulièrement qu’on doive relancer certains services sur un serveur dédié, ne fût-ce que quand on fait la moindre modification sur un fichier de configuration. Ceux qui ont l’habitude d’administrer leur serveur en SSH connaissent bien le répertoire /etc/init.d/ pour avoir déjà tapé au moins 100.000 fois des commandes du genre /etc/init.d/mysql restart.

Ceux qui connaissent moins bien SSH passent par Webmin pour administrer leur serveur. Là aussi il est possible de relancer les services :

  • Le bouton “Appliquer les changements” dans Bind
  • Le bouton “Stop MySQL server” (suivi bien sûr de “Start”) dans MySQL
  • L’onglet “Appliquer les changements” dans Apache
  • Le lien “Redemarrer tous les services (pour prendre en compte les changements)” dans OVHm (qui relance à la fois Bind et Apache)
  • Etc, etc.

Tous fonctionnent et permettent de relancer proprement les services … tous sauf un : QMail. Ceux qui ont eu un jour la curiosité de cliquer sur le bouton “Stop QMail Processes” (ou bien dont le serveur de mail a bêtement planté) ont probablement eu la désagréable surprise de ne pas pouvoir relancer le serveur de mail.

On a beau cliquer sur “Start QMail Processes”, ça ne redémarre pas.

Et pourquoi ça ne marche pas ? C’est tout simplement dû à l’installation du serveur de mail sur la release OVH : le trio QMail – Spamassassin – ClamAV (serveur de mail – antispam – antivirus) est une installation OVH “maison” et Webmin a un peu de mal à le prendre en charge.

Alors que faire ? Pas le choix, il faut passer en SSH (par pitié, ne cédez pas à la tentation du reboot : rebooter un serveur linux, c’est mal !) et lancer les commandes suivantes dans l’ordre :

/etc/init.d/clamd stop
/etc/init.d/spamd stop
/etc/init.d/qmail stop
/etc/init.d/qmail start
/etc/init.d/clamd start
/etc/init.d/spamd start

Voilà qui devrait faire l’affaire. Rien ne vous empêche d’ailleurs de vous faire un petit script perso qui vous permette de lancer toutes ces commandes automatiquement les unes après les autres.

Debian : Mise à jour de Bind9 fait buguer Webmin

Une récente mise à jour de Bind dans les dépôts Debian induit un léger bug dans Webmin / Virtualmin.

Ceux qui sont dans le cas (Webmin / Virtualmin installé sur une Debian Lenny) et qui mettent à jour (apt-get upgrade) apercevront sans doute que Bind “ne tourne plus”. En tout cas c’est ce que vous dira votre Webmin. Si vous essayez alors de lancer Bind via Webmin, vous obtiendrez une jolie erreur “Unknown Error”. Pas vraiment rassurant…

Heureusement, c’est en fait nettement moins grave qu’il n’y paraît : Bind tourne bel et bien (un petit passage en SSH vous le confirmera vite), c’est simplement Wembin qui ne le détecte plus. Pour fixer ça, il suffit de se rendre dans Webmin -> Servers -> BIND DNS Server -> Module Config -> System configuration et ajouter ceci dans Default PID file location(s) :

/var/run/bind/run/named/named.pid

Avec le bon chemin vers named.pid, Webmin retrouvera ses petits et il ne vous embêtera plus 🙂

Source : https://www.virtualmin.com/node/14569 (inscription nécessaire sur le site)

Attention, cela concerne aussi les nouvelles installations : pour ceux qui ont l’habitude d’installer Virtualmin sur Debian, ne soyez pas surpris de constater que Bind ne “semble” pas tourner sur une installation fraîche (la manipulation pour fixer le bug est évidemment identique).