Auto Hébergement et Raspberry Pi
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Auto Hébergement
et
Raspberry Pi.
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Table des matières
État du lard..................................................................................................................... 4
Glossaire de la documentation....................................................................................... 5
Rendre les services accessibles de l'Internet..................................................................6
Les ports..................................................................................................................... 6
Le système..................................................................................................................... 8
Préparation du Raspberry........................................................................................... 8
Système d'exploitation........................................................................................... 8
Réseau.................................................................................................................. 10
Le fichier /etc/hostname...................................................................................10
Le fichier /etc/hosts.......................................................................................... 10
Le stockage.............................................................................................................. 11
Connexion SSH et sécurité....................................................................................... 15
Changer le port d'écoute depuis Internet.............................................................15
Désactiver le compte Root................................................................................... 15
Gérer la connexion SSH par clé............................................................................ 16
Bannir les intrus : Fail2Ban................................................................................... 18
Un nom de domaine ?................................................................................................... 19
Registrar................................................................................................................... 19
Gestion sur le web.................................................................................................... 19
Gestion dynamique.................................................................................................. 22
Création des champs nécessaires............................................................................ 24
Gestion en local........................................................................................................ 25
WebServices................................................................................................................. 26
Installation d'un serveur web : Lighttpd...................................................................26
Gestion du service.................................................................................................... 27
Envie d'un site ?....................................................................................................... 28
Installation de GetSimple CMS..............................................................................28
Installation de PluXML.......................................................................................... 31
Courrier électronique.................................................................................................... 32
Envoyer des messages électroniques.......................................................................32
Configuration du système pour la messagerie.....................................................32
Création des utilisateurs...................................................................................33
Création des Alias............................................................................................. 33
Installation et paramétrage de Postfix..................................................................34
Installation et paramétrage de Dovecot...............................................................40
Consulter les courriers électroniques.......................................................................42
Configuration d'un logiciel de messagerie............................................................42
Configuration de Thunderbird...........................................................................42
Configuration d'Evolution................................................................................. 42
Configuration d'Outlook....................................................................................42
Installation et paramétrage d'HastyMail2.............................................................43
Installation et paramétrage de SquirrelMail..........................................................44
Antispam - Antivirus................................................................................................. 44
Contacts & tâches........................................................................................................ 45
Installer et configurer Baikal Server.........................................................................45
Configuration de Thunderbird................................................................................... 47
Paramétrage du calendrier...................................................................................47
Paramétrage des contacts.................................................................................... 48
Configuration d'Evolution......................................................................................... 48
Paramétrage du calendrier...................................................................................48
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Paramétrage des contacts.................................................................................... 50
Configuration d'Android............................................................................................ 50
Paramétrage du calendrier...................................................................................51
Paramétrage des contacts.................................................................................... 51
Sauvegarde.................................................................................................................. 53
Automatisation......................................................................................................... 53
Tester une remontée................................................................................................. 53
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
État du lard
L'écriture de ce « livre » m'est venue un jour ou je me demandais « comment pourrais je contribuer à
l'avancée de l'auto-hébergement ». N'étant ni codeur dans l'âme (encore que pour de petits services
personnels), ni développeur web je ne me voyais pas proposé un outil bugué ou incomplet à la communauté,
d’où ce petit livre.
Les écrits et exemples que vous trouverez au travers de ces quelques pages ne seront pas exempts d'erreurs
ou pourront aussi être complétés par des personnes plus avisées que moi sur certains sujets.
L'auto-hébergement est un fait d'actualité dans les sphères geek aujourd'hui, de par la liberté que cela apporte
mais aussi à cause des différentes affaires telles que Prism ou encore l'article 20 de la Loi de Programmation
Militaire qui ont fait l'actualité ces derniers temps.
Toutes ces lois et textes mis en place ne poussent que vers une seule chose : chiffrer et toujours chiffrer plus.
J'essaierais dans ces quelques lignes d'apporter mes connaissances en la matière et ainsi permettre à chacun
de disposer de son propre serveur, autonome et « sécurisé ».
Ceci dit, l'auto hébergement n'est pas une chose super fun quand tout tombe en rade, et ça arrive bien plus
souvent qu'on ne le pense. Ici je vais tenter de relater les aventures et configurations que j'ai été amené à
produire pour mon mini serveur à la maison, un Raspberry Pi 256Mo.
De plus, l'auto-hébergement n'est pas si « gratuit » que cela, en effet une connexion internet est nécessaire,
une machine, une seconde pour de la redondance si jamais on le souhaite ainsi que de la sauvegarde. Même
si toutes ces variables semblent « gratuites » car vous disposez de machines en spare, une connexion internet
partagée légalement avec le voisin ou encore un lecteur de bandes pour archiver vos données ; Le coût en
temps est monstrueux et pousse même à parfois s'arracher les cheveux jusqu'à ce qu'une nuit vous vous
réveilliez en percutant ce qui bloque depuis 3 jours.
Et oui c'était ce foutu smtpd_recipient_restrictions dans Postfix auquel vous aviez mis une condition avant
l'autre (Ca n'arrivera pas ici, je me suis assez cassé les dents dessus !;) ).
Qui dit Raspberry Pi dit carte SD, écritures régulières, crash, lenteur etc. L'installation sur ce type de
machine est chronophage, il faut du temps et il faut vouloir y passer du temps.
Ceci dit (une fois de plus !) il existe des distributions déjà toutes prêtes à l'emploi qui ont été pensée et
développées par des personnes souhaitant partager leurs connaissances et techniques pour apporter au plus
grand nombre l'hébergement facile, je pense particulièrement au projet Yunohost (http://yunohost.org) mais
aussi à bien d'autres, Google pourra le trouver facilement pour vous.
Pour finir, cette documentation a été faite sur base de connaissances personnelles acquises tant bien que mal
sur la plupart du temps (libre ! :)). En aucuns cas je ne peux me proclamer comme étant omniscient et il se
pourrait donc qu'un à un moment donné cette doc soit obsolète ou non à jour ou encore truffée d'erreur.
Cette documentation se veut être la plus claire possible et la plus vulgarisante, je l'ai clairement orientée avec
des points de vue et échange de ma part de façon à guider le débutant et ne pas le perdre en cours de route. Je
comprends tout à fait que les confirmés passent leur chemin et ne prennent pas le temps de s'attarder ici. La
doc est plus longue que ce que j'avais initialement prévu de par les avis que je laisse avant ou après chaque
manipulation.
Cela ne sera que ma modique contribution à un sujet qui me tient à cœur, ne m'en tenez pas rigueur et
apportez les modifications que vous souhaitez à cette documentation, que chacun puisse en profiter.
En vous souhaitant une bonne lecture.
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Glossaire de la documentation
Tout au long de la doc, j'essayerais d'être « uniforme ». J'entends par là que j'essayerais tant bien que mal de
conserver le même langage et les mêmes expressions avec par exemple
• http://ndd.tld → Représente l'adresse de votre serveur sous la forme FQDN
(ex : http://google.fr)
• http://10.10.10.251 → Représente l'adresse de votre serveur via son IP
• rpi → Représente RaspberryPi en abrégé, mais vous l'aurez remarqué
Dans certains fichiers de configuration j'utiliserai des nom et / ou logins génériques. Ceux ci seront tout à fait
utilisable mais ne seront pas obligatoires et pourront bien évidemment être changés selon les goûts.
Afin d'éviter des erreurs de copier / coller ou autres, les principaux fichiers de configurations nécessaire au
bon fonctionnement seront fournis dans l'archive qui contient ce document mis à part les fichiers demandant
des modifications mineures.
Ceci dit ces fichiers seront tout de même détaillés (tant bien que mal parfois) autant que possible afin de
comprendre leurs contenus et leurs fonctions.
Le contenu indiqué de couleur orange et encadré indiquera au cours de la documentation que nous nous
trouvons dans un terminal en mode administration du serveur. Dans ce contenu je surligne en gras des
informations qui ne sont pas forcément à conserver, qui peuvent être adaptées comme des identifiants ou
encore des noms de groupe.
Je vous inviterais d'ailleurs à ne pas forcément copier / coller les lignes de commande afin d'éviter
d'éventuelles erreurs dues au retour à la ligne forcé par LibreOffice et qui n'est pas forcément le cas dans le
terminal ou vous travaillerez.
Le contenu indiqué de couleur rouge et encadré représentera une sorte de synthèse ou rappel concernant la
partie active de la documentation.
Toutes les manipulations et paramétrages sont faits avec l'utilisateur root. J'aborderai au cours de la doc une
partie sécurité quant à la connexion via SSH et nous verrons aussi comment gérer la connexion par clé afin
de supprimer le couple login / mot de passe et aussi pour renforcer la sécurité.
En avant !
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Rendre les services accessibles de l'Internet
Une partie « masquée » de l'auto-hébergement est de rendre les services accessibles depuis Internet. Ici une
sérieuse barrière se pose devant nous, la box de l'opérateur. Pas de soucis ils ont (dans la plupart des cas)
pensé aux gentils bonhommes qui utilisent leur propre serveur à la maison et permettent donc de rediriger le
trafic entrant vers une ou plusieurs machines sur notre réseau.
Il faut bien entendu savoir que les opérateurs (même en 2013 et 2014) qui fournissent une adresse IP
publique fixe avec un reverse configurable sont rares :
• OVH
• Free
• […]
Rattrapez moi si j'en oublie.
Je suis personnellement chez SFR et tout se passe bien malgré le fait que je ne dispose pas d'adresse IP
publique fixe. Le tout moyennant quelques bidouillages plus ou moins honteux mais on fait avec les moyens
du bord (moyens qui seront abordés dans cette documentation plus tard).
Les ports
Les ports sont ce que l'on peut ramener aux portes d'une maison pour une image que tout le monde pourra
s'imaginer. En effet comme pour une maison, chaque ouverture sert à quelque chose. La porte d'entrée
s'ouvre pour le facteur qui vient vous livrer votre Raspberry, la porte du garage s'ouvre pour la voiture etc.
Nous aurons bien compris que la porte d'entrée, la porte du garage et la fenêtre des wc reçoivent des flux.
Ces flux peuvent être du web, du mail, du ftp, du ssh etc. Voici un petit récapitulatif non exhaustif des ports :
• 80/443 → http / https
• 25 / 465 → smtp / smtps
• 22 → ssh
• 143 / 993 → imap / imaps
• 20 / 21 → FTP
Il est donc important de saisir le but des ports. En effet, derrière chaque port accessible se trouve un service
qui écoute et attend des requêtes.
Le serveur dispose de ports mais la box aussi, et c'est à la box que le trafic entrant à destination du serveur
s'adressera en premier.
La box étant par défaut « sécurisée » ne laissera pas entrer le trafic dont elle ne connaît pas l'origine ni la
destination et ne saura de toute façon pas vers quelle machine rediriger ce trafic.
Pour rendre l'installation accessible il sera donc nécessaire d'ouvrir presque tous les ports cités
précédemment à savoir ssh, smtp, smtps, imaps, http et https etc. à destination du serveur.
Je ne détaillerais pas ici comment ouvrir ou rediriger un port sur une box opérateur, de multitudes de
documentations sont disponibles sur Internet pour cela.
Il faudra cependant penser lorsque vous ferez la redirection des ports à déterminer quelle sera l'adresse IP
locale (192.168.1.x ou toute autre adresse) de votre serveur afin que le trafic soit correctement acheminé et
vous y tenir tout au long de la documentation.
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Le système
Sur le Raspberry Pi, une installation du système est faisable sur un disque dur USB mais je n'aborderais pas
cette technique dans ces pages, ne l'ayant pas mise en place chez moi je ne sais pas de quoi il en retourne et
cela ne m'intéresse pas. Si la carte SD du Pi flambe, je balance l'image système que j'ai faite au préalable
dans une autre SD et tout repart (10€ de spare on a connu pire). Une carte SD n'est pas faite à proprement
parler pour encaisser des écritures en continu. Or tout OS Linux garde trace de manière régulière de ce qu'il
se passe dans le système et écrit donc les logs.
J'ai choisir de brancher un disque dur usb du rpi. J'ai ainsi monté /var de manière automatique sur le disque
mécanique, afin de réduire les écritures sur la SD et apporter un peu de souffle à la machine en terme
d'espace de stockage.
Si votre installation ne se fait pas sur un raspberry pi vous pouvez tout de même suivre cette documentation,
les installations et configurations sont identiques. Cependant vous pouvez déjà passer à la partie webservices.
Préparation du Raspberry
Une fois de plus, si vous faites votre installation sur autre chose qu'un raspberry ou une autre machine
n'utilisant pas de cartes SD, passez au prochain chapitre :). Je ne détaillerai pas ici la méthode pour préparer
la carte SD sous Windows, ne disposant pas de ce type de système actuellement, je ne peux l'expliquer.
Cependant ce lien : http://computers.tutsplus.com/articles/how-to-flash-an-sd-card-for-raspberry-pi--mac-
53600
Ou encore une recherche avec « write raspberry pi image sd card windows » sur notre ami Google devrait
aider à trouver la solution.
Système d'exploitation
Il faut donc télécharger l'image du système ici : http://downloads.raspberrypi.org/raspbian_latest
Une fois l'image téléchargée on la dézippe, on écrit le contenu du .img obtenu sur la carte SD.
unzip 2013-05-25-wheezy-raspbian.zip
dd bs=4M if=2013-05-25-wheezy-raspbian.zip of=/dev/mmcblk0
sync
Notre carte SD est donc prête à être insérée dans le rpi, on peut donc lancer la bête.
Si comme moi vous ne disposez pas d'écran à brancher sur la bête, vous pouvez lancer un scan du réseau
pour récupérer l'adresse ip attribuée par le serveur dhcp.
nmap 192.168.1.*
Si 192.168.1.0 est l'adresse de votre réseau
Nmap scan report for raspberrypi (192.168.1.179)
Host is up (0.0026s latency).
Not shown : 999 closed ports
PORT STATE SERVICE
22/tcp open ssh
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
On peut donc se connecter en SSH (login : pi – mdp : raspberry) sur la machine et commencer
l'administration. Celle-ci est assez intuitive et se fait relativement simplement, on accède au menu de
paramétrage en tapant :
sudo raspi-config
De multiples paramètres sont accessibles via le menu qui s'affiche. On peut commencer par
1 Expand Filesystem
qui va nous permettre d'exploiter la taille totale de la carte SD.
On pourra ensuite paramétrer la langue du pi
4 Internationalisation Options
Change Locale
Puis on choisit fr_FR.UTF8 UTF-8 et on valide tout en confirmant fr comme langue par défaut.
On configure ensuite le « split » mémoire, à savoir la quantité de ram que l'on va allouer au gpu.
8 Advanced Options
A3 Memory Split
Sur mon pi 256M j'ai choisi de n'allouer que 16M de ram au GPU, soit le maximum pour le système.
On peut ensuite sortir du menu et redémarrer le pi :
Finish
reboot
Réseau
Nous aborderons ici la configuration de fichiers réseau tels que /etc/hostname et /etc/hosts. Ces deux
fichiers sont importants et sont nécessaires au bon fonctionnement du serveur.
Le fichier /etc/hostname
Ce fichier intègre le FQDN (Fully Qualified Domain Name) de notre machine. On y retrouve donc par
exemple
mail.ndd.tld
Le fichier /etc/hosts
Ce fichier sert de « résolveur » DNS. A savoir que le système d'exploitation viendra se renseigner dans ce
fichier afin d'obtenir l'adresse ip d'un hôte sur le réseau à partir de son nom avant d'aller demander
l'information à un serveur DNS tiers.
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Plusieurs services peuvent s'appuyer sur ce fichier et le système même vient interroger la configuration pour
récupérer des adresses ip. Ci dessous le contenu d'un fichier /etc/hosts d'une machine située derrière une box
127.0.0.1 localhost
10.10.10.251 mail.ndd.tld sv
127.0.1.1 mail.ndd.tld
Le fichier interfaces
Il est pertinent de fixer une adresse ip fixe à la machine qui va héberger nos services. Sous Debian ça se fait
dans /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.10.10.251
netmask 255.255.255.0
gateway 10.10.10.1
dns-nameservers 10.10.10.1 194.2.0.20
network 10.10.10.0
broadcast 10.10.10.255
Bien entendu la configuration mise en gras est à appliquer selon votre configuration. L'adresse IP choisie ici
correspond à mon plan d'adressage sur mon réseau @ home.
Il est fort probable que votre plan d'adressage soit du type 192.168.1.x ou 192.168.0.x. La configuration de
l'interface serait donc plutôt du type
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.251
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1 194.2.0.20
network 192.168.1.0
broadcast 192.168.1.255
Il est aussi important de déterminer un nom d'hôte à votre goût et qui vous parle. Ce nom n'est aucunement
indicatif quant à la configuration de vos services mais peut être quelque chose comme
mail.ndd.tld
Comme le service le plus « important » est l'hébergement des mails, j'ai personnellement choisi de le
nommer mail.ndd.tld
Pour modifier le hostname du pi, il faut éditer le fichier /etc/hostname dans lequel on indiquera le nom sous
la forme FQDN (Fully Qualified Domain Name)
mail.ndd.tld
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Le stockage
Comme mentionné dans la page servant d'introduction au départ, l'espace de stockage qui accueillera les
données sera monté sur un autre disque. Nous bénéficierons ainsi d'un stockage mécanique plus performant
et plus « sécurisé » dans le temps que la carte SD. Toutefois si vous souhaitez conserver le service sur la
carte SD, vous pouvez passer à la partie Nom de domaine.
Après avoir branché le disque dur, préparez vous à créer une nouvelle partition puis un nouveau système de
fichier et enfin à automatiser le montage du disque et /var sur celui-ci pour qu'à chaque démarrage l'espace
de stockage soit monté.
On commence par identifier le disque dur sur lequel on veut travailler
fdisk -l
Va nous permettre d'afficher les disques connectés au système. Chez moi le résultat ressemble à ceci
Disk /dev/mmcblk0: 16.6 GB, 16642998272 bytes
4 heads, 16 sectors/track, 507904 cylinders, total 32505856 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000c7b31
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 32505855 16191488 83 Linux
Disk /dev/sda: 160.0 GB, 160041885696 bytes
81 heads, 63 sectors/track, 61254 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bcb59
Device Boot Start End Blocks Id System
/dev/sda1 2048 312581807 156289880 83 Linux
Le disque dur est /dev/sda, c'est sur ce disque que nous allons créer la partition
fdisk /dev/sda
fdisk est l'utilitaire qui va créer la partition
Un prompt va s'afficher et demander une saisie :
• m → Affiche l'aide
• n → Crée une nouvelle partition
• […]
Ici un second prompt attend une réponse :
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr• p → Crée une partition primaire
• 1 → Saisir un numéro de partition (Le plus souvent par défaut)
• Start Cylinder → Entrée
• Last Cylinder → Entrée
• w → Ecrit les changements sur le disque
La partition est maintenant créée. Il faut encore créer le système de fichier.
Pour créer le système de fichier, il nous faut la lettre du disque et le numéro de la partition précédemment
créée. Ici sûrement /dev/sda1
Création du système de fichier
mkfs.ext4 /dev/sda1
On peut maintenant créer un répertoire dans /mnt pour monter le système de fichier
mkdir /mnt/storage
De nos jours il n'est plus forcément nécessaire de saisir le type de système de fichiers que l'on monte, le
système d'exploitation peut détecter le type dont il s'agit et ainsi s'adapter.
mount /dev/sda1 /mnt/storage
Ou
mount -t ext4 /dev/sda1 /mnt/storage
Il suffit ensuite d'afficher l'espace disque pour se rendre compte que le disque est bien là
df -h
Sys. fich. Taille Util. Dispo Uti% Monté sur
rootfs 16G 2,0G 13G 14% /
/dev/root 16G 2,0G 13G 14% /
devtmpfs 108M 0 108M 0% /dev
tmpfs 24M 252K 23M 2% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 47M 0 47M 0% /run/shm
/dev/mmcblk0p1 56M 19M 38M 33% /boot
/dev/sda1 147G 13G 127G 9% /mnt/storage
A ce stade, la partition ne sera pas automatiquement montée au prochain redémarrage. Pour ce faire il faut
renseigner le fichier /etc/fstab avec l'UUID de la partition et aussi le point de montage.
UUID.. J'ai encore entendu il y a peu de temps que ça ne servait pas et qu'on pouvait continuer à utiliser
l'identifiant de la partition de type sdx, ce qui n'est pas fondamentalement faux, mais il vaut clairement
mieux utiliser l'UUID. En effet, l'UUID est un identifiant unique permettant d'identifier une partition. (Des
informations ici https://help.ubuntu.com/community/UsingUUID).
Il est donc préférable et recommandé d'utiliser ces UUID plutôt que /dev/sdX car en cas de changement de
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frdisque dur ou par hasard inversion de ports sur la carte mère, le système serait susceptible de ne plus
retrouver ses petits au redémarrage.
Il est donc nécessaire d'identifier la partition
ls -l /dev/disk/by-uuid
Ici cette commande me renvoie
lrwxrwxrwx 1 root root 10 nov. 27 23:17 f4b67733-3194-45fa-bd21-e304c9559978 ->
../../sda1
Le code en gras est l'uuid de ma partition
Il faut ensuite aller éditer le fichier /etc/fstab pour y ajouter nos informations à la dernière ligne
UUID="f4b67733-3194-45fa-bd21-e304c9559978" /mnt/storage ext4 defaults,noatime
0 1
Maintenant la partition sera montée automatiquement à chaque démarrage. Il est possible de s'en assurer en
tapant la commande mount qui si tout se passe bien ne doit rien renvoyer à l'écran.
Et pour s'en assurer définitivement, un petit reboot puis df -h une fois relogué.
Il nous reste (c'est fini ensuite pour cette partie) à créer des liens depuis /var/
• www
• log
• sqlite
• apt_cache
Pour y arriver, il faudra déplacer les répertoires souhaités en temps voulu. Toutefois si au cours de la
documentation j'oublie de le spécifier, je vais tenter d'expliquer la manipulation ici.
Historiquement les données du serveur web sont stockées dans /var/www/ mais nous souhaitons les déplacer
sur le disque dur prévu à cet effet.
On commence donc par déplacer le répertoire
mv /var/www/ /mnt/storage/
Puis on va créer le lien depuis le nouvel emplacement vers l'ancien afin de « feinter » au système que les
données n'ont pas bougées d'endroit.
Pour cela on utilise la commande ln -s avec en premier la source du lien et ensuite la destination vers
laquelle on souhaite faire pointer le lien, ici
ln -s /mnt/storage/www/ /var/
On peut donc faire des tests en créant un fichier dans /var/www/ puis en listant le répertoire sur le disque dur
/mnt/storage/www/
touch /var/www/toto
ls -l /mnt/storage/www/
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr-rw-r--r-- 1 root root 0 déc. 2 23:44 toto Le fichier est bien sur le disque dur, le lien symbolique fonctionne. Il suffit maintenant de répéter l'opération pour log et sqlite si l'on souhaite y stocker nos base de données sQlite (Baikal + CMS.) La configuration du système est terminée. Le serveur peut maintenant commencer à accueillir nos services. Pour cette partie de la documentation, d'autres sources concernant le paramétrage du Raspberry sont disponibles sur Internet si j'avais oublié quelques configurations. Connexion SSH et sécurité Il est possible de se connecter en SSH en local comme depuis l'Internet sur notre serveur. SSH présente des avantages qui ne sont plus à présenter pour l'administration d'un serveur. Dans la documentation qui suit concernant SSH, nous allons voir plusieurs méthodes qui seront compatibles ou non entre elles. En effet, le port d'écoute public par exemple n'impactera aucunement l'authentification, qu'elle soit par clé ou couple login / mot de passe. Toutefois le fait de forcer l'authentification par clé désactivera tout autre moyen de connexion et rendra inutile la configuration d'un groupe spécial ainsi que d'un utilisateur spécial. A chacun d'adapter cette configuration selon ses propres besoins, ici rien n'est forcé ni obligatoire ;). A noter tout de même que si seule l'authentification par clé est configurée, vous devrez vous munir de votre clé privée sur tous les postes depuis lesquels vous souhaiterez vous connecter. Changer le port d'écoute depuis Internet Historiquement le démon SSH tourne sur le port 22, on « camoufle » généralement ce port en en utilisant un tout autre pour éviter les tentatives de connexion sur ce service. Il existe deux sons de cloche concernant cette habitude, ceux qui partent du principe que la sécurité est assurée même sur le port 22 et les autres. Je fais personnellement partie du second groupe, je préfère ajouter cette « barrière », ça ne coûte rien et ça peut freiner les petits malins. Cette fonction de redirection de port est assurée par la box ou routeur qui est en front de votre connexion Internet. Le démon en local écoutera toujours sur le même port mais c'est la box qui lorsqu'elle recevra une requête sur le port par exemple 54321 qui redirigera sur le port 22 de la machine. A savoir donc si vous souhaitez employer cette technique, ici rien d'obligatoire. La configuration abordée ici est un premier pas (à mon sens) pour éviter de se faire scanner en permanence et aussi pour palier aux connexions intempestives. Le choix de changer le port public de connexion dépend de chacun, ici pas d'obligations une fois de plus. Désactiver le compte Root Par défaut tous les utilisateurs du système sont autorisés à se connecter en SSH. Cela ne pose pas de problème en soit excepté si le compte que vous utilisez se voit compromis, qui plus est si ce compte est root. Pour palier à ce problème plusieurs options sont envisageables. La première est de désactiver le compte root dans la configuration du serveur SSH. On pourra ensuite créer un groupe spécial et y ajouter un nouvel utilisateur avec lequel on ne fera que se connecter à distance sur le système pour ensuite passer Root. #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Pour désactiver la connexion de root
nano /etc/ssh/sshd_config
PermitRootLogin no
Ne pas appliquer la configuration tout de suite sous risque de se couper la main.
Nous allons maintenant créer un groupe « spécial SSH » pour y ajouter le compte « spécial SSH » qui sera
un compte qui ne servira qu'à se connecter au système et avec lequel nous élèverons les droits à root.
Le groupe et l'utilisateur indiqués dans les lignes suivantes sont à adapter selon votre choix
groupadd sshpowerusers
useradd -m -s /bin/bash mysshuser
gpasswd -a mysshuser sshpowerusers
Puis à la fin du fichier /etc/ssh/sshd_config on vient indiquer la ligne suivante pour autoriser la connexion
du groupe sshpowerusers
AllowGroups sshpowerusers
Avant de se déconnecter et de se reconnecter en SSH avec le nouvel utilisateur, il convient de modifier son
mot de passe
passwd mysshuser
Puis on redémarre le serveur ssh et on se déconnecte
/etc/init.d/ssh restart
exit
Si vous vous déconnectez vous ne pourrez pas vous reconnecter en root. Dorénavant la connexion se fera
avec l'utilisateur mysshuser. Cet environnement nous servira à nous authentifier avec l'utilisateur root une
fois la connexion établie.
La configuration abordée ici pourra servir à se connecter à distance depuis un poste qui ne disposera pas
de la clé privée que nous allons créer dans la suite de la configuration SSH. Toutefois la connexion par clé
est à privilégier par rapport à la méthode de groupe. A chacun d'y trouver son usage.
Gérer la connexion SSH par clé
La connexion par clé présente plusieurs avantages, en effet nous pourrons nous connecter au serveur sans
avoir à rentrer à chaque fois le couple login / mot de passe mais il est aussi possible de forcer chaque
utilisateur à se connecter via cette méthode et ainsi désactiver la connexion par login afin de renforcer la
sécurité du système.
Dans cette partie je n'aborderais que la configuration d'un client Linux, plus tard viendra sûrement cet aspect
de la configuration dans un environnement Microsoft. Comme nous avons configuré un utilisateur dans la
partie précédente, j'ai pris le parti de continuer la documentation avec cet utilisateur pour nous connecter par
clé et ensuite nous authentifier avec le compte root.
On commence par créer une clé sur le système client depuis lequel nous nous connecterons au serveur.
Laisser les champs par défaut lors de la création.
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frssh-keygen -t dsa
Enter file in which to save the key (/root/.ssh/id_dsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
00:3f:e9:21:26:5e:df:55:91:06:1f:cf:7e:93:62:c9 root@manulaptop
The key's randomart image is:
+--[ DSA 1024]----+
| . ..+o |
| o . oo+ |
| . + * ... o |
| . + + = . ... .|
| . o S E.o.|
| . ...|
| |
| |
| |
+-----------------+
Aperçu du processus de création de clé
Nous allons maintenant copier la clé publique sur le serveur afin de pouvoir nous y connecter. L'adresse IP
du serveur est à modifier ici aussi en fonction de la configuration.
ssh-copy-id -i .ssh/id_dsa.pub mysshuser@mail.ndd.tld
Ici le mot de passe root sera demandé à la première connexion puis vous serez invité à vous connecter au
serveur pour essayer la connexion sans mot de passe.
Jusqu'ici, la connexion par login / mot de passe fonctionne toujours. Il est possible de désactiver cette
fonction afin de n'autoriser que l'authentification par clé (Non obligatoire).
nano /etc/ssh/sshd_config
Puis on décommente et on passe la ligne suivante à No qui indique que l'on refuse les connexions par mot de
passe
#PasswordAuthentication yes
à
PasswordAuthentication no
Puis on redémarre le serveur SSH
/etc/init.d/ssh restart
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frOn peut maintenant essayer de se connecter avec n'importe quel compte, la connexion sera refusée.
Permission denied (publickey).
La configuration abordée dans les lignes précédentes est la plus restrictive pour les connexions
extérieures. En effet il nous faudra disposer de la clé privée afin de nous connecter. Toute altération de la
clé nous sera ainsi signalée par le système afin de par exemple prévenir d'une attaque de type Man In the
Middle.
Bannir les intrus : Fail2Ban
Fail2ban est un puissant analyseur de logs. L'outil passe son temps à analyser les logs qu'on lui soumet dans
la configuration et peut ainsi détecter si un nombre important de connexions a lieu sur un service et peut ainsi
bannir l'adresse IP distante pour un certain temps.
J'avais configuré il y a longtemps Fail2ban sur mon Pi en m'appuyant sur la documentation de Maylug
http://www.maylug.org/wiki/doku.php?id=documentation:fail2ban
Je vous invite à suivre cette doc qui est facile d'accès plutôt que la reproduire ici :).
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frUn nom de domaine ? Un nom de domaine sera clairement utile pour joindre les différents services, qui plus est si vous ne disposez pas comme moi d'adresse ip publique fixe. Le nom de domaine peut être personnalisé à souhait surtout que maintenant il est possible d'utiliser des caractères spéciaux et bientôt des .bzh (dédicace:)), des .paris etc. Registrar Plusieurs fournisseurs peuvent vous fournir un nom de domaine avec plus ou moins de services : protection contre le vol, masquage de vos informations etc. Mon nom de domaine est enregistré chez OVH historiquement le fournisseur chez lequel j'avais tous mes services hébergés. (3 noms de domaines + 2 serveurs dédiés fut une époque = avant le rapatriement de mes services @ home:)). OVH fournit un service de DNS dynamique, ce qui veut dire que si vous ne disposez pas d'adresse IP fixe vous pourrez mettre vos enregistrements à jour dynamiquement et de manière automatisée sans avoir donc à vous poser la question si votre box à changée d'adresse ou autres soucis liés à cette problématique. Vous pouvez néanmoins obtenir votre nom de domaine chez Online.net ou encore 1and1. D'autres registrars sont disponibles sur Internet mais ce n'est pas l'objet de la documentation ici. Dans les parties dédiées au DNS qui suivent je parlerais exclusivement de la configuration via le manager OVH. Si votre nom de domaine n'est pas enregistré chez ce fournisseur, vous pourrez passer à la suite de la documentation après avoir bien sur fait des recherches sur les DNS dynamiques chez les autres registrars. Gestion sur le web OVH met à disposition de ses services un manager qui sert à configurer la totalité des services. Ainsi en mode graphique il est facilement possible de configurer sa propre zone DNS depuis l'interface web. Pour se connecter sur l'interface de configuration, c'est ici : https://www.ovh.com/managerv3/ L'interface ressemble normalement (elle peut changer) à la capture d'écran suivante Pour configurer la zone, il faut sélectionner le service soit dans l’ascenseur situé en haut de la page ou alors dans la colonne de gauche du manager puis suivre les captures d'écran suivantes #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
On trouvera sur la capture d'écran suivante l'interface nécessaire à la configuration de notre zone et à l'édition des nombreux champs nécessaires Il peut être nécessaire de « faire le ménage » dans la configuration DNS fournie par OVH. Dans la capture d'écran précédente on peut voir qu'il existe une fonction pour Réinitialiser le Domaine. La « procédure » pour faire cette réinitialisation est détaillée dans la capture suivante #Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.fr
Après quelques secondes, la zone est réinitialisée, on va pouvoir commencer la configuration. Les champs
crées sont fictifs et sont la à titre indicatif excepté pour les champs NS qui sont absolument à conserver dans
notre cas. On peut donc supprimer les champs CNAME et MX pour partir d'une configuration vierge.
Le champs A ne peut être supprimé et pour cause, nous allons le modifier pour le « transformer » en champs
DynHost afin de pouvoir le mettre à jour régulièrement. Dans le manager, cliquer sur le bouton de
modification du champs de type A (Le bouton se trouve en face de l'enregistrement).
Dans le menu qui s'affiche, activer les fonctions et remplir les champs comme indiqué dans la capture d'écran
qui suite. L'adresse 1.2.3.4 est volontairement indiquée, nous verrons ainsi plus facilement l'impact sur la
configuration lors de la mise à jour dynamique via le script détaillé plus loin dans cette documentation. (Ne
pas oublier de valider:)).
Sur l'écran suivant, nous allons configurer l'identifiant et le mot de passe nécessaire à la mise à jour de notre
enregistrement. Bien entendu l'identifiant choisi dans cette procédure n'est là qu'à titre indicatif, vous pourrez
en choisir un tout autre sans soucis. Évitez tout de même les caractères spéciaux. L'identifiant sera donc du
type ndd.tld-identifiantchoisi.
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frL'écran suivant confirme la création de l'identifiant. En nous rendant à nouveau dans le détail de la zone
DNS, on peut voir que le champs de type A est maintenant modifié en champs de type DynHost et
l'enregistrement est 1.2.3.4. La configuration de la zone DNS est maintenant « presque » terminée. Il nous
reste à gérer la mise à jour dynamique du champs.
Gestion dynamique
La gestion dynamique est autonome. Moyennant quelques configurations, la solution une fois en place ne
consomme presque pas de ressources et les mises à jour se font de manière totalement transparentes.
Pour commencer quelques explications. OVH met à disposition des clients de nom de domaine une
connexion à leur infrastructure afin de permettre les mises à jour « automatiques ». C'est cette fonction que
nous allons aborder ici.
La documentation technique est disponible ici : http://guides.ovh.com/DynDns ou encore là :
http://www.funtaff.com/software/addns.pl/ pour la configuration du script que nous allons utiliser.
La configuration se fait en plusieurs étapes : création des fichiers de configuration pus automatisation du
tout.
On commence par créer le fichier de configuration principal dans /etc/ et on y copie / colle le contenu suivant
(Bien faire attention aux guillemets quand nécessaire).
nano /etc/addns.conf
[webcheck]
{
server_host = www.ovh.com
update_host = ndd.tld
detect_method = "webcheck"
ip_detect_host = "checkip.dyndns.org"
ip_detect_port = 80
username = "ndd.tld-identifiant"
password = "mot_de_passe_ovh"
}
Les champs marqués en gras sont à adapter à votre configuration
Puis copier / coller le script addns.pl contenu dans le dossier de cette documentation. Si celui-ci est altéré ou
absent, il est possible d'obtenir la dernière version du script à cette adresse
http://www.funtaff.com/software/addns.pl/addns-1.2a.tar.gz
Il faut ensuite rendre le script exécutable
chmod +x /etc/addns.pl
Le script a besoin d'un fichier log ou stocker les différents échanges, on va donc le créer
touch /var/log/addns.log
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frIl faudra ensuite se rendre dans le répertoire /etc/ puis exécuter le script
cd /etc/
./addns.pl
La mise à jour doit normalement se faire. Vous devrez voir la capture d'écran suivante dans votre terminal
ainsi que le champs mis à jour après avoir rafraîchit la page du manager OVH.
La partie mise à jour automatique est terminée, le restant de notre configuration se basera sur
l’enregistrement DynHost pour la totalité de nos services (mail : champs MX, et des alias de type
CNAME).
Création des champs nécessaires
Différents champs seront nécessaires pour la suite de la documentation. Les champs MX serviront à la
configuration mail et les alias CNAME serviront à rediriger les requêtes d'une manière plus « parlante ».
Il sera par exemple envisageable de diriger les requêtes à destination du webmail vers l'url
https://webmail.ndd.tld ou encore les requêtes à destination d'un blog vers http://blog.ndd.tld.
Cette configuration se fera au niveau du DNS de la même manière que pour la création du champs DynHost.
Dans le manager OVH, il faudra commencer par créer un enregistrement de type CNAME avec comme
valeur mail.ndd.tld comme indiqué dans la capture d'écran suivante
Une fois l'enregistrement crée, on va pouvoir créer le champs MX nécessaire au routage des courriers
électroniques.
De la même manière dans le manager, sélectionner le Type MX puis remplir les champs comme indiqué ci-
dessous
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frUne fois l'opération validée, on se retrouve donc avec les champs dans l'ordre
.ndd.tld NS ns100.ovh.net
.ndd.tld NS dns100.ovh.net
mail.ndd.tld MX 5 ndd.tld
.ndd.tld DynHOST @PUBLIQUEBOX
mail.ndd.tld CNAME ndd.tld
Le reste de la configuration sera semblable à la création du champs mail.ndd.tld. En effet comme la totalité
de l'installation que nous allons faire repose sur une seul adresse IP, les futurs champs crées seront de type
CNAME.
Par exemple dans ma configuration, mon site est accessible « sur le champs » type A mais l'ensemble des
services annexes comme cloud, webmail ou autre sont de « simples » CNAME.
Gestion en local
Le DNS en local fonctionne de la même manière que sur l'Internet. Un poste client émet une requête vers un
serveur de nom afin d'obtenir l'adresse IP en fonction du nom.
La plus basique des box peut faire office de serveur DNS. Les champs à renseigner seront identiques à ceux
indiqués dans le manager de votre registrar à l'exception des champs MX.
On pourra donc retrouver par exemple dans la configuration DNS de la box
→ mail.ndd.tld 192.168.0.x
→ blog.ndd.tld 192.168.0.x
→…
Ceci dit, si vous ne disposez que d'un seul ordinateur à la maison, il est possible d'outrepasser cette fonction
de la box et d'inscrire directement « en dur » ces renseignements dans le fichier hosts. (Technique
fonctionnelle mais relativement déconseillée de par le manque de souplesse de la solution).
Sous Windows de mémoire le fichier en question se trouve dans C:\Windows\System32\drivers\etc et sous
Linux le fichier à renseigner est /etc/hosts.
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frLa configuration du Nom de Domaine est désormais terminée, l'installation se doit d'être autonome, la
configuration du DynHost est là pour ça. La suite de cette partie sur le DNS peut varier en fonction de
votre fournisseur d'accès et donc de la box ou routeur fourni par ce dernier.
De multiples documentations sont disponibles sur Internet. Vu la multitude de box disponibles sur le
marché, il serait trop long de détailler les configurations de chacune d'elles.
Cette dernière partie est très générale et reprend les principes du DNS local afin que pour l'usage d'un pc
nomade par exemple, vous n'ayez pas à reconfigurer votre client mail selon que vous soyez ou non au
domicile.
WebServices
Installation d'un serveur web : Lighttpd
Basé sur une Debian, nous allons utiliser aptitude pour mettre à jour le système et installer le « coeur » de
l'installation notre serveur web.
aptitude update
aptitude upgrade
aptitude install lighttpd
Lighttpd est désormais opérationnel, il faut maintenant installer php5 afin que le serveur web apprenne à
interpréter ce langage
aptitude install php5-cgi
Il faut maintenant activer php5 dans la configuration de Lighttpd (avec votre éditeur de texte favori éditez le
fichier /etc/php5/cgi/php.ini puis on y décommente à la ligne 765 cgi.fix_pathinfo=1.
Toujours avec votre éditeur de texte favori, éditez le fichier /etc/lighttpd/lighttpd.conf pour y ajouter le
mod_fastcgi dans server.modules
server.modules = (
« mod_access »,
« mod_alias »,
« mod_compress »,
« mod_redirect »,
« mod_rewrite »,
« mod_fastcgi »,
« mod_accesslog »,
)
Il est possible d'activer ces modules via la commande lighty-enable-mod mais je trouve (avis perso)
préférable de les gérer dans le fichier de configuration, d'un seul coup d'oeil on peut ainsi voir quels sont les
modules activés avec par exemple cette commande
cat /etc/lighttpd/lighttpd.conf | grep mod
Qui nous renvoie toutes les lignes de ce fichier contenant mod
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frAfin d'activer PHP dans la configuration du serveur web, il est nécessaire de préciser à celui-ci ou se trouve
le répertoire d'exécution de PHP. Ajouter les lignes suivantes dans /etc/lighttpd/lighttpd.conf
fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/tmp/php.socket"
)))
Répertoire d'exécution de PHP
On redémarre ensuite Lighttpd
/etc/init.d/lighttpd restart
Redémarrage de Lighttpd
Tant que nous y sommes on pourra activer SSL (Secure Socket Layer) pour des transactions sécurisées,
intéressant notamment lorsqu'on se connectera au webmail pour ne pas que les identifiants passent en clair
sur le réseau.
mkdir /etc/lighttpd/certs
cd /etc/lighttpd/certs
openssl req -new -x509 -keyout lighttpd.pem -out lighttpd.pem -days 3650 -nodes
Une suite de question est ensuite demandée avec dans l'ordre des réponses
FR
Bretagne ? =)
maville
[]
[]
/!\ common name : hostname.monndd.tld
masuperadresse@monndd.tld
Le CommonName est très important car il va déterminer la « crédibilité » du certificat aux yeux du
navigateur web. Ainsi si le certificat porte le nom monsuperhost.ndd.fr et que le service que l'on souhaite
couplé a SSL porte le nom monsupertruc.ndd.fr, les noms ne matcheront pas et des applications pourront
vous envoyer voir plus loin si vous y êtes.
Ceci étant dit, un wildcard (certificat *.ndd.tld) permet de résoudre le problème.
Gestion du service
GetSimple repose sur XML et PHP. Un large panel de serveurs web permet de le faire tourner. Dans le cadre
de cette documentation je vais détailler l'installation des tous les webservices sur Lighttpd qui est un serveur
web minimaliste par on emprunte sur le système mais hyper puissant par son usage.
Lighttpd stocke toute sa configuration dans un seul et même fichier que l'on « amménagera » au cours de
cette documentation selon les besoins et les services que nous mettrons en place.
Cela dit, il est possible de « spliter » la configuration par sous domaine / service en jouant avec des include
dans le fichier de configuration principal de Lighttpd.
Pour démarrer, redémarrer ou arrêter le service Lighttpd
#Autohebergement Emmanuel Le Nohaïc http://lacavernedemanu.frVous pouvez aussi lire
