Serveur web à la maison : Raspberry Pi

[size=150]Retrouvez ce tutoriel sur le wiki : isalo.org/wiki.debian-fr/Ser … spberry_pi[/size]

Voici un petit tutoriel pas à pas pour monter son propre serveur domestique à la maison, qui consomme ~5W.
Je ne suis absolument pas expert en la matière, donc toute critique/ajout sera le bienvenu.

[ul]Installation du Raspberry Pi[/ul]

[ul]Matériel à acheter[/ul]

  • Raspberry Pi modèle B (le modèle A ne possède pas de port éthernet)

  • Une carte SD rapide et de marque (éviter les noname)

  • Un transformateur µUSB 5V et >700mA (certaines alimentations de téléphones portables font l’affaire, mais pas celle de mon Samsung)

  • Éventuellement un boîtier

    Tout ça se trouve sans problème dans la boutique officielle. Pour la carte SD, je l’ai achetée ailleurs et c’est une SanDisk 32Go qui se vante de faire du 30Mo/s en lecture.
    Le tout monte la facture à ~80€.

[ul]Installation du système[/ul]

J'ai décidé, parmi les systèmes proposés, d'installer Raspbian Wheezy qui n'est, vous l'aurez deviné, qu'une adaptation de Debian Wheezy 7. Celle-ci se récupère sur le site officiel : [raspberrypi.org/downloads](http://www.raspberrypi.org/downloads). Pensez à vérifier que l'image téléchargée est bien intègre en vérifiant sa somme SHA-1 [i]via[/i] [color=#008080]sha1sum raspbian.img[/color].

Ensuite, insérez la carte SD dans votre orifice favori. Notez son chemin grâce, par exemple, à la commande [color=#008080]df -h[/color], puis démontez-la. Si son chemin est par exemple [color=#008080]/dev/sdf1[/color], lancez la commande [color=#008080]dd bs=4M if=/chemin/de/raspbian.img of=/dev/sdf[/color]. Avant de retirer la carte, un petit coup de sync pour vider les tampons.

Enfichez la carte SD dans le Raspberry Pi, branchez-y un câble éthernet, un clavier USB et un écran HDMI. Lors de la mise sous tension, le système devrait booter correctement.
Lors du premier démarrage, le système lance automatiquement l'utilitaire [color=#008080]raspi-config[/color], qui vous permet de régler quelques options intéressantes de la machine. En l'occurence, si comme moi vous avez opté pour une carte SD d'un volume supérieur aux 4GB recommandés, vous pouvez choisir l'option [color=#008080]expand_rootfs[/color] pour que la partition / s'étende à toute la carte. Pensez à configurer la disposition de votre clavier avec l'option [color=#008080]configure_keyboard[/color], un mot de passe solide avec l'option [color=#008080]change_pass[/color], la langue avec [color=#008080]change_locale[/color], et votre fuseau horaire avec [color=#008080]change_timezone[/color]. Activez le serveur SSH avec l'option [color=#008080]ssh[/color], et désactivez le lancement du serveur X au démarrage avec l'option [color=#008080]boot_behaviour[/color]. Enfin, allouez seulement 16MB de RAM à la puce graphique avec l'option [color=#008080]memory_split[/color] et vérifiez que l'overclock est bien désactivé avec l'option [color=#008080]overclock[/color].
Et voilà, c'est bon pour la configuration de base, vous pouvez redémarrer.

[ul]Accès root[/ul]

Pour le moment, vous pouvez accéder au compte root avec la commande [color=#008080]sudo su[/color]. Le reste de la configuration est à effectuer en tant que root.

[ul]Configuration d’SSH[/ul]

À ce stade, le serveur SSH est activé mais pas encore configuré. Si vous ne voulez pas vous coltiner des tentatives incessantes d'invasion coréennes par le port 22 (port par défaut d'SSH), vous avez tout intérêt à vous pencher un peu sur le fichier [color=#008080]/etc/ssh/sshd_config[/color], le temps de modifier la ligne [color=#008080]Port[/color] pour régler un autre port que le 22 (au choix entre 1 et 65536, en évitant les ports déjà utilisés : 21, 22, 80, 443 et 3306) et la ligne [color=#008080]PermitRootLogin[/color] pour changer [color=#008080]yes[/color] en [color=#008080]no[/color]. Ajoutez aussi à la fin du fichier la ligne [color=#008080]AllowUsers pi[/color], pour n'autoriser que votre utilisateur à se connecter à SSH. Pour finir, [color=#008080]service ssh restart[/color].

[ul]Attribution d’un IP fixe[/ul]

Pour pouvoir se connecter au serveur depuis votre poste habituel, c'est mieux de savoir à quelle adresse IP toquer. Pour ça, il faut simplement configurer le serveur en IP fixe (qui s'oppose à l'habituel DHCP). Côté serveur, il suffit d'éditer [color=#008080]/etc/network/interfaces[/color] de la façon suivante :

[code]auto lo
iface lo inet loopback

iface eth0 inet static
address 192.168.0.x
gateway 192.168.0.x
netmask 255.255.255.0[/code]
address est l’IP interne que vous souhaitez réserver à votre serveur et gateway l’adresse de votre routeur (.254 pour une Freebox V5).
Ensuite, côté *box, il doit être possible (en tout cas ça l’est sur une Freebox V5) de réserver une adresse IP donnée à une adresse MAC (adresse physique de l’interface réseau). Pour obtenir l’adresse MAC, vous pouvez passer par ifconfig eth0 par exemple, et noter l’adresse au format xx:xx:xx:xx:xx:xx derrière Hwaddr.
Ensuite, pour une Freebox V5 il suffit de se rendre dans « configurer mon routeur Freebox » et « Baux DHCP permanents », et d’indiquer l’adresse IP que l’on veut faire correspondre à l’adresse MAC du serveur.
Éteindre l’interface réseau par ifdown eth0, redémarrer la *box, puis remonter l’interface réseau par ifup eth0. Vous devriez être connecté avec l’adresse IP demandée (vérifier éventuellement avec ifconfig eth0).

Vous devriez maintenant pouvoir vous connecter à votre serveur en SSH avec la commande suivante : [color=#008080]ssh [pi@ip.de.votre.server](mailto:pi@ip.de.votre.server) -p xxxx[/color] où [color=#008080]xxxx[/color] est le port que vous avez réglé sur le serveur SSH.

[ul]Installation du serveur web[/ul]

[ul]Introduction[/ul]

Le Raspberry Pi n'est pas un quad-core avec 12GB de RAM, il convient donc d'opter pour la légèreté. Pour le serveur HTTP, nginx fait très bien l'affaire. On y adjoindra seulement PHP et sqlite/mysql.

[ul]Prérequis[/ul]

[ul]Vérification de l’état du système[/ul]
Avant de se lancer dans l’installation, on s’assure que le système est bien à jour : aptitude update && aptitude full-upgrade.

[ul]Utilisateurs et groupes[/ul]
Vérifier aussi que le groupe www-data existe et que l’utilisateur www-data en fait bien partie : groupadd www-data && usermod -a -G www-data www-data.

[ul]Paquets à (dés)installer[/ul]

On peut ensuite commencer par virer tout ce qui se rapporte au serveur X, puisqu'on n'en aura pas l'usage :
Après, un petit ménage des fichiers de configuration avec  [color=#008080]aptitude purge ~c[/color], puis on installe localepurge pour faire de la place dans les fichier de locales : [color=#008080]aptitude -R install localepurge && localepurge[/color].

On installe ensuite les paquets utiles pour le serveur :

[ul]Paramétrage[/ul]

[ul]nginx[/ul]
Première étape importante : paramétrer le serveur HTTP, nginx. La configuration que j’utilise consiste à rediriger les requêtes HTTP (port 80) vers son pendant sécurisé HTTPS (port 443). Je n’ai d’ailleurs rien inventé, c’est la configuration recommandée par OwnCloud :

[code]cat > /etc/nginx/sites-available/default << EOF
server {
listen 80;
server_name x.x.x.x;
rewrite ^ https://$server_name$request_uri? permanent; # enforce https
}

server {
listen 443 ssl;
server_name x.x.x.x;
ssl_certificate /etc/nginx/cert.pem;
ssl_certificate_key /etc/nginx/cert.key;
root /var/www;
index index.php index.html index.htm;
client_max_body_size 1000M; # set maximum upload size

deny direct access

location ~ ^/owncloud/(data|config|.ht|db_structure.xml|README) {
deny all;
}

default try order

location / {
try_files $uri $uri/ @webdav;
}

WebDAV

location @webdav {
fastcgi_split_path_info ^(.+.php)(/.*)$;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param HTTPS on;
include fastcgi_params;
}

enable php

location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param HTTPS on;
include fastcgi_params;
}
}
EOF[/code]
x.x.x.x est l’IP du serveur.

[ul]SSL[/ul]
Comme la connexion au serveur va se faire par HTTPS, il nous faut une clé SSL. Pour ça, openssl req -new -x509 -days 365 -nodes -out /etc/nginx/cert.pem -keyout /etc/nginx/cert.key && chmod 600 /etc/nginx/cert.pem && chmod 600 /etc/nginx/cert.key
[ul]PHP[/ul]
Pour pouvoir envoyer de gros fichiers sur votre serveur via PHP (utile si comme moi vous hébergez un OwnCloud), modifiez les lignes upload_max_filesize et post_max_size de /etc/php5/fpm/php.ini pour les régler sur 1000M (1GB).
Toujours si vous hébergez un OwnCloud, pour lui permettre de stocker ses fichiers temporaires, mkdir -p /srv/http/owncloud/data et décommenter la ligne upload_tmp_dir de /etc/php5/fpm/php.ini pour la passer à /srv/http/owncloud/data.

[ul]Sécurisation[/ul]

[ul]sudo[/ul]
Pour des raisons d’auto-discipline, bien que sudo soit supposé sécurisé je préfère ne pas l’utiliser sur un serveur. Pour s’en passer, il faut d’abord attribuer un mot de passe au compte root : sudo su && passwd. Puis supprimer le paquet sudo : aptitude purge sudo. Maintenant, pour s’identifier en tant que root, su - suivi du mot de passe.

[ul]MySQL[/ul]
MySQL embarque un script de sécurisation automatique, que vous pouvez invoquer par mysql-secure-installation. Ce qui est fort conseillé d’ailleurs.

[ul]SSH[/ul]
Le serveur SSH, si vous avez suivi, doit être déjà sécurisé à ce stade (voir § configuration d’SSH).

[ul]fail2ban[/ul]
Pour éviter que de mauvais garçons tentent de s’introduire chez vous pour piquer les photos de tante Martine, il est de bon ton d’installer fail2ban. Ce programme lit les fichiers logs des services installés sur le serveur, repère les échecs d’identification et les IPs y correspondant, les bloque avec une règle iptables et vous envoie un mail pour vous en avertir. Simple et efficace.
Après aptitude -R install fail2ban, un peu de configuration s’impose.
D’abord éditer le fichier /etc/fail2ban/jail.conf. Dans ce fichier, chercher la ligne qui commence par action = (attention, pas action_ =). Ce réglage vous permet de choisir quel type de rapport va vous envoyer fail2ban dans la boîte mail de root lors d’une tentative d’intrusion. Personnellement j’ai opté pour action =%(action_mwl)s qui envoie un rapport complet avec un whois de l’enquiquineur et les lignes de logs responsables du ban. Ensuite viennent plusieurs blocs type

[ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6
Chaque bloc correspond à un service qui peut être protégé par fail2ban. Le jeu est donc de protéger ceux qui nous intéressent en passant la variable enabled correspondante à true. Dans notre cas, on active les blocs de surveillance ssh, ssh-ddos, apache, apache-noscript, apache-overflows et vsftpd. /!\ Attention : penser à changer le port SSH avec celui qu’on a choisi. /!\ Accessoirement on peut aussi ajouter les ports sftp dans le même bloc SSH en modifiant sa ligne port comme suit :

[ssh] enabled = true port = port_choisi,sftp filter = sshd logpath = /var/log/auth.log maxretry = 6
Comme si ça ne suffisait pas, on va ajouter deux règles perso (issues de l’excellent wiki.debian-fr). Pour ça, éditer le fichier /etc/fail2ban/jail.local pour y ajouter

[code][apache-admin]
enabled = true
port = http
filter = apache-admin
logpath = /var/log/apache*/error*.log
maxretry = 6

[apache-404]
enabled = true
port = http
filter = apache-404
logpath = /var/log/ispconfig/httpd//error
maxretry = 10[/code]
Auxquels il faut penser à adjoindre les filtres correspondants. Pour ça, créer dans le dossier /etc/fail2ban/filter.d/ les fichiers apache-admin.conf contenant

[code]# Fail2Ban configuration file

Author: Cyril Jaquier

$Revision: 471 $

[Definition]

Option: failregex

Notes.: regex to match the password failure messages in the logfile. The

host must be matched by a group named “host”. The tag “” can

be used for standard IP/hostname matching.

Values: TEXT

[client x.x.x.x] File does not exist: /home/www/admin/admin,

failregex = [[]client []] File does not exist: .*admin|PMA|mysql

Option: ignoreregex

Notes.: regex to ignore. If this regex matches, the line is ignored.

Values: TEXT

ignoreregex =[/code]
et apache-404.conf contenant

[code]# Fail2Ban configuration file

Author: Cyril Jaquier

$Revision: 471 $

[Definition]

Option: failregex

Notes.: regex to match the password failure messages in the logfile. The

host must be matched by a group named “host”. The tag “” can

be used for standard IP/hostname matching.

Values: TEXT

[client x.x.x.x] File does not exist: /home/www/admin/admin,

failregex = [[]client []] File does not exist: .*

Option: ignoreregex

Notes.: regex to ignore. If this regex matches, the line is ignored.

Values: TEXT

ignoreregex =[/code]
Après ça, service fail2ban restart et on y est !

[ul]denyhosts[/ul]
Partiellement redondant avec fail2ban, denyhosts lit seulement les logs d’SSH et blackliste les plaisantins dans le fichier /etc/hosts.deny.
Denyhosts nécessite beaucoup moins de configuration que fail2ban. Ici, on va juste s’assurer que les machines à partir desquelles vous vous connectez habituellement en SSH à votre serveur seront reconnues comme des amies et ne génèreront pas de rapport. Pour ça, éditer /etc/denyhosts.conf pour passer l’option SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS à NO. Ensuite, éditer le fichier /var/lib/denyhosts/allowed-hosts pour y entrer les IPs que vous souhaitez définir comme amies. Après un service denyhosts restart, c’est tout bon.

[ul]Rendre le serveur accessible depuis l’extérieur[/ul]

[ul]Paramétrage de la *box[/ul]

Pour le moment le serveur est accessible en interne. Pour le rendre accessible depuis l'extérieur, il suffit de rediriger le trafic entrant de certains ports de votre *box vers le serveur. En gros, quand la freebox sera interrogée sur le port 80 (HTTP), il faut lui faire savoir qu'elle doit rediriger cette interrogation vers le port 80 du serveur.
Pour une freebox, les options de redirection se trouvent dans « Configurer mon routeur Freebox » et « Redirections / Baux DHCP ». Là on explique que le port externe 80 TCP doit être redirigé vers le port interne 80 à l'adresse IP interne de votre serveur. Et on refait la même chose pour les ports 443 (HTTPS), 21 (FTP), 3306 (MySQL) et le port SSH que vous avez configuré.
Pensez aussi, côté serveur, à modifier [color=#008080]/etc/nginx/sites-available/default[/color] pour y renseigner votre IP publique au lieu de votre IP interne. Vous pouvez l'obtenir en visitant [duckduckgo.com/?q=my+ip](https://duckduckgo.com/?q=my+ip) par exemple.
Après redémarrage de votre *box, votre serveur sera normalement accessible depuis l'extérieur via l'IP (fixe, c'est préférable) de votre *box.

[ul]Nom de domaine[/ul]

Je ne vous expliquerai pas comment configurer votre propre serveur DNS. En ce qui me concerne, je possédais déjà un nom de domaine chez OVH, et il suffit de se connecter à son interface pour rediriger le nom de domaine vers l'IP publique de votre *box. Rien de bien compliqué.

[ul]Usage[/ul]

[ul]SSH[/ul]

Se connecter en SSH : [color=#008080]ssh [pi@nom.du.server](mailto:pi@nom.du.server) -p xxxx[/color].
Pour copier un fichier vers le serveur : [color=#008080]scp fichier_local.ext [pi@ip.de.votre.server](mailto:pi@ip.de.votre.server):fichier_distant.ext[/color].
Inversement, pour copier un fichier depuis le serveur : [color=#008080]scp [pi@ip.de.votre.server](mailto:pi@ip.de.votre.server):fichier_distant.ext fichier_local.ext[/color].

[ul]FTP[/ul]

Le client ftp fourni par défaut avec Debian est un peu caduque. Vous avez le choix, mais en ligne de commande ncftp m'a l'air vraiment bien. Avec interface graphique, j'utilise gftp.
Dans les deux cas, le mieux est de vous connecter avec l'utilisateur [color=#008080]www-data[/color] (et son mot de passe associé) pour vous retrouver directement dans le répertoire [color=#008080]/var/www/[/color], qui est le dossier auquel vous accédez quand vous interrogez votre serveur sur les ports HTTP ou HTTPS.

[ul]Sources[/ul]

[ul]Tutoriaux[/ul]

Je n'ai évidemment rien inventé, et voici en vrac les liens dans lesquels j'ai allègrement pioché pour écrire ce tutorial :

penguintutor.com/linux/light-webserver
jeremymorgan.com/tutorials/r … eb-server/
raspberrypioneer.com/2012/06 … mp-server/
instructables.com/id/Raspber … ver/#intro
isalo.org/wiki.debian-fr/ind … e=Fail2ban
petrockblog.wordpress.com/2012/ … pberry-pi/

[ul]Liens officiels[/ul]

raspberrypi.org/
raspberrypi.rsdelivers.com/default.aspx pour le matériel
themagpi.com/ : un magazine dédié au Raspberry Pi
elinux.org/RaspberryPiBoard : le wiki officiel

[size=150]Préférer la version du Wiki (PDF pas maintenu à jour) : isalo.org/wiki.debian-fr/Ser … spberry_pi[/size]

J’ai joint à ce message une version PDF (meilleure mise en page).
raspberrypi_webserver.pdf (207 KB)

Merci , c’est vraiment sympa!

Punaise faut que je m’en achète un deuxième. Le premier me sert de portable pour faire mes présentations au boulot je ne peux plus m’en passer.
Question : 32GB suffisent bien pour se faire un owncloud?
Et deuxième question : Sachant que j’ai un débit descendant de 512kb et montant à 6ko est ce vraiment utile que je fasse ça (surtout pour des gros fichiers de 200Mo?) ou bien vaut-il mieux ma bonne vieille clef USB?

Quelle bonne idée! :slightly_smiling:

[quote=“michel_vi”]
Et deuxième question : Sachant que j’ai un débit descendant de 512kb et montant à 6ko est ce vraiment utile que je fasse ça (surtout pour des gros fichiers de 200Mo?) ou bien vaut-il mieux ma bonne vieille clef USB?[/quote]
Si tu compte héberger des fichiers très petits, oui, sinon, ça risque d’être difficile pour les usagers.

C’est surtout pour moi ^^. Le nombre de fois où arrivé au lycée je m’aperçois que j’ai oublié ma clef à 1h de route avec le boulot dessus :laughing:
Avec l’arrivé de la plateforme moodle ça devrait changer mais un truc qui est en java et me met des messages d’erreur 1 fois sur 3 j’ai pas top confiance

Tout dépend ce que tu y stockes évidemment. Sache juste que le système complet occupe moins de 4GB. Ça te laisse une grosse vingtaine de GB pour stocker sur ton OwnCloud. Pour moi c’est amplement suffisant. Si tu as besoin de capacités de stockage très importantes, tu peux toujours mettre un disque dur externe (alimenté en externe pour pas pomper sur l’alim du Pi), les temps d’accès seront juste un peu plus longs.

Comme l’a déjà dit Thuban, pour les gros fichiers ça le fera pas. Si tu fais le calcul : 200Mo/6ko = plus de 9h pour télécharger le fichier. Par contre pour les petits fichiers (à partager éventuellement), le calendrier et le carnet d’adresse, ça passe.

[quote=“seb-ksl”] Pour moi c’est amplement suffisant. Si tu as besoin de capacités de stockage très importantes, tu peux toujours mettre un disque dur externe (alimenté en externe pour pas pomper sur l’alim du Pi), les temps d’accès seront juste un peu plus longs.
[/quote]
Comment ça pomper? le pi en prendrait un coup?

[quote=“thuban”][quote=“seb-ksl”] Pour moi c’est amplement suffisant. Si tu as besoin de capacités de stockage très importantes, tu peux toujours mettre un disque dur externe (alimenté en externe pour pas pomper sur l’alim du Pi), les temps d’accès seront juste un peu plus longs.
[/quote]
Comment ça pomper? le pi en prendrait un coup?[/quote]
Le Pi n’est pas capable de délivrer plus de 140mA (de mémoire) sur chaque port USB. Impossible d’alimenter un disque dur avec ça, il faut une alim externe.
Il y a bien des solutions pour passer outre mais ça implique de faire des modifs sur la carte (court-circuiter les polyfuses).

D’accord j’ai compris :slightly_smiling: merci.

Hello, je vais peut-être dire une bêtise… mais je suis surpris que dans la config denyhosts pour la raspian, ce soit le fichier ‘allowed-hosts’. Sur la Debian stable, pour amd64, ou i386, c’est le fichier ‘hosts-valid’…

Normal ?

C’est ma première expérience avec denyhosts, donc je suis incapable de te répondre sérieusement. Il est tout à fait possible qu’un des deux fichiers soit partiellement redondant avec l’autre (histoire de versions ?). Tout ce que je peux dire c’est que ça fonctionne avec allowed-hosts.

Ce que je veux dire, c’est que le fichier ‘allowed-hosts’ n’existe pas dans ces autres saveurs :wink:

Je suis surpris que ce soit légèrement différent d’une architecture à l’autre !

C’est peut-être dû à la version de denyhosts utilisé … ?!

Salut et merci
Une page dans le Wiki sur le sujet serait la bienvenue! :wink:

[quote=“lol”]Salut et merci
Une page dans le Wiki sur le sujet serait la bienvenue! :wink:[/quote]
OK, je m’y affaire en fin de semaine !

Re,

[quote=“seb-ksl”][quote=“lol”]Salut et merci
Une page dans le Wiki sur le sujet serait la bienvenue! :wink:[/quote]
OK, je m’y affaire en fin de semaine ![/quote]

Excellent, et d’autant plus excellent que je devrais avoir mon jouet sous peu… :wink:

Comme tu y vas… Moi j’ai eu 4 semaines de retard par rapport aux 6 semaines annoncées ! (farnell)
M’enfin le principal c’est que ça finisse par arriver. :mrgreen:

Rien qu’une toute petite précision, pour postgresql, il faut créer la base de donnée comme ça :

su - -c "psql" postgres CREATE USER clouduser WITH PASSWORD 'userpass'; CREATE DATABASE clouddb OWNER clouduser ENCODING 'UTF8'; GRANT ALL PRIVILEGES ON DATABASE clouddb TO clouduser; \q

Si vous aussi vous êtes mauvais avec les BDD, ça devrait suffire :slightly_smiling:

J’aurais une question…
Comment faire pour que l’installation du paquet owncloud n’installe pas apache?

Installer à partir du tarball de www.owncloud.org (c’est ce que j’ai fait). Essaie avec “aptitude -R” sinon, si le paquet n’est que recommandé ça ira.