🗓️ Note : Cet article est une archive importée de mon ancien blog. Certaines informations peuvent ne plus être à jour.

Ou comment j’ai commencé à administrer mon serveur avec les pieds…

Dans mon dernier article , je vous présentais Helios64. C’est une belle coquille vide. Il faudrait désormais mettre des trucs dedans !

 

Introduction

 

A propos :

Je ne suis pas développeur. Je ne travaille pas dans l’informatique. Je ne suis pas adminsys. Vous trouverez ci dessous un résumé de mes pérégrinations sur les internets pour apprendre à administrer mon serveur. Il y a certainement des petites coquilles, c’est à prendre en compte si jamais vous voulez pointer du doigt les inexactitudes ou les erreurs techniques. De plus, il y a certainement 278 976 manières de faire. C’est une méthode. La mienne. Peut être pas la meilleure, mais celle que j’ai réussi à faire (presque) tout seul. Je remercie Jae, Tinerion, et vlp pour leur aide précieuse. Cette article essaye de détailler (mais pas trop non plus), il faut plutot le voir comme une présentation générale de la philosophie, que comme un tuto pas à pas ultra détaillé. (C’est pourquoi je ne traiterai pas de l’attribution d’une IP locale statique (ou de la mise en place d’un service DHCP) )

 

Ne pas avoir peur

Bien que cet article est certainement l’un des plus techniques que j’ai eu l’occasion d’aborder sur ce blog, il ne faut pas en avoir peur. Je pense qu’il peut être tout à fait déroutant si on a aucun baggage technique. Des connaissances de bases sur un environnement Linux et sur les lignes de commandes dans un terminal seront certainement grandement utile. Néanmoins, si vous vous y intéressez ne serait ce qu’un tout petit peu ça peut devenir très enrichissant. Je vous invite à lire avec la plus grande attention ce qui va suivre, et essayer d’en comprendre la substantifique moelle . Je ne peux que vous conseiller de vous procurer une petite machine pour vous « amuser » à expérimenter des choses. Mon expérience avec mon Olimex Lime 2 m’a été très utile. C’est pourquoi je vous invite à également lire cet article qui me parait être une bonne introduction sur certains points (car il y aura beaucoup de points communs par moments…).

 

Pourquoi pas Yunohost ?

Justement, on pourrait se demander pourquoi je m’embête à tout administrer « à la mano from scratch », et que je n’utilise pas un outil « clef en main ». J’ai déja partiellement répondu. D’abord Yunohost n’est pas disponible (enfin pas encore) pour Helios64. En revanche, on peut trouver un système similaire appelé « Syncloud compatible avec le serveur de chez Kobol. Bien que ces outils soient vraiment très pratique, on reste tout de même relativement bloqué par les options qu’ils proposent. Même si on peut personnaliser pas mal de chose, on a pas le total contrôle sur notre système. C’est pourquoi, dans une optique d’avoir « ma config rien qu’a moi aux petits oignons comme je l’aime » mais également désirant apprendre et comprendre le fonctionnement de cette machine, j’ai décidé de tout faire à la main.

 

 

Les mains dans le camboui

 

Le nom de domaine

En premier lieu, je me suis acheté un nom de domaine. (Je sais que je vais en avoir besoin après…) En effet, je souhaite que mon serveur soit accessible facilement et simplement. Bien qu’on puisse s’y connecter avec une IP. C’est quand même plus pratique d’avoir un nom de domaine, et ca permet beaucoup plus de chose.

J’ai personnellement opté pour un nom de domaine chez Gandi.net (mais vous pouvez allez ailleurs si vous voulez. OVH par exemple (et il y en a d’autres…).

Il y a tous les prix selon les extensions (.com par exemple est souvent plus cher) et le nom de domaine que vous voulez. Bref; j’ai personnellement opté pour un .me … C’était en promo, ca m’est revenu à 4.80 € pour une année (puis 19.20€ par an) … Ramenez ça au mois : et je trouve que c’est acceptable.

 

Se connecter via SSH ;

Je considère que vous avez finalisé l’installation (cf ce lien) et que vous avez transféré votre OS sur la mémoire eMMC ou ailleurs. Personnellement j’ai opté pour la première option. De plus, je considère que vous vous êtes déjà connecté via SSH et que vous vous êtes loggé une première fois en tant que root (cf ce lien).

 

Changer le mot de passe,

Normalement, à votre première connexion, le système vous demandera de modifier votre mot de passe. Il faut le faire. C’est très important pour des questions évidentes de sécurité !  Si jamais vous ne l’avez pas fait ; connecté en tant que root vous pouvez taper :

sudo passwd root

et suivre les instructions à l’écran.

 

Créer un utilisateur.

Normalement à votre première connexion le système vous demandera de créer un nouvel utilisateur. Encore une fois, c’est important car on est pas censé se connecter sur « root » pour faire des manips de la vie courante. Taper ceci pour ajouter un utilisateur (ici, il s’appelle marcel mais évidemment, vous : vous mettez ce que vous voulez. Evitez cependant les caractéres spéciaux et les majuscules)

adduser marcel


Le système vous demandera de préciser des informations sur l’utilisateur. Vous pouvez appuyer sur Entrée à chaque fois pour ignorer ces spécifications.

Enter the new value or press ENTER for the default
 Full Name []:
 Room Number []:
 Work Phone []:
 Home Phone []:
 Other []: Enfin, le système vous demandera de confirmer.

Is the information correct? [Y/n] Tapez Y (pour Yes)

Maintenant, il ne nous reste plus qu’a lui donner les privilèges à ce petit Marcel. (Pour nous éviter de passer par le compte root )

usermod -aG sudo marcel

Et voilà. Normalement, c’est bon. Il ne vous reste plus qu’a vous connecter en tant que marcel. Et si besoin utiliser sudo ou su -.

Mise à jour du système

Avec la commande armbian-config on peut accéder à des outils directement implémentés dans armbian. Notamment une mise à jour du firmwire et du systeme.

Une fois redémarré, on se connecte à nouveau. Par réflexe j’ai retapé sudo apt-get update && sudo apt-get upgrade même si je crois que ca a déja été fait vu la manip’ que l’on vient de faire avec la mise à jour du firmwire.

Installer un serveur web

On attaque le vif du sujet ! On va installer un serveur web. Ca nous permettra de communiquer avec notre serveur via Internet ; et donc, depuis n’importe où dans le monde !

Choix du serveur web

Il existe plusieurs serveurs web, les plus connus étant Apache et Nginx. Néanmoins, on va utiliser ni l’un ni l’autre. Pourquoi ? Pourquoi pas ! On m’a présenté Caddy récemment, et j’ai beaucoup aimé sa philosophie. J’ai l’impression qu’il est plus simple à comprendre et à utiliser que Apache et Nginx. En plus, il gère automatiquement HTTPS et la gestion des certificats LetsEncrypt. Pour m’être un peu frotté à ses problématiques dans le passé, c’est (pour moi) un avantage non négligeable. (Bonus : un article relatif à la guéguerre Apache VS Nginx)

Installation de Caddy

Pour installer Caddy, je me suis tout simplement fié à la documentation officielle en ligne. J’ai choisis d’installer la version stable :

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/cfg/gpg/gpg.155B6D79CA56EA34.key' | sudo apt-key add -
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/cfg/setup/config.deb.txt?distro=debian&version=any-version' | sudo tee -a /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Prise en main de Caddy

(Ce qui suit est inspiré de cette partie de la documentation officielle)

Une fois que vous avez installé Caddy. Vous pouvez taper la commande caddy, vous verrez alors toutes les options qui s’offrent à vous :

Caddy is an extensible server platform.

usage:
  caddy <command> [<args...>]

commands:
  adapt           Adapts a configuration to Caddy's native JSON
  build-info      Prints information about this build
  environ         Prints the environment
  file-server     Spins up a production-ready file server
  fmt             Formats a Caddyfile
  hash-password   Hashes a password and writes base64
  help            Shows help for a Caddy subcommand
  list-modules    Lists the installed Caddy modules
  reload          Changes the config of the running Caddy instance
  reverse-proxy   A quick and production-ready reverse proxy
  run             Starts the Caddy process and blocks indefinitely
  start           Starts the Caddy process in the background and then returns
  stop            Gracefully stops a started Caddy process
  trust           Installs a CA certificate into local trust stores
  untrust         Untrusts a locally-trusted CA certificate
  validate        Tests whether a configuration file is valid
  version         Prints the version

Use 'caddy help <command>' for more information about a command.

Full documentation is available at:
https://caddyserver.com/docs/command-line

Notez la présence du lien vers la documentation.

JSON ou Caddyfile ?

On peut configurer Caddy via des fichiers JSON de ce style :

{
	"apps": {
		"http": {
			"servers": {
				"example": {
					"listen": [":2015"],
					"routes": [
						{
							"handle": [{
								"handler": "static_response",
								"body": "Hello, world!"
							}]
						}
					]
				}
			}
		}
	}
}

Ou utiliser ce qu’on appelle le Caddyfile. Un fichier (sans extension) dans lequel on peut préciser quelques régles. C’est ce fichier qui va générer le fichier de configuration JSON. Sa syntaxe est plus simple :

:2015
respond "Hello, world!"

C’est exactement la même chose que le fichier JSON ci dessus. Evidemment les deux méthodes ont leurs avantages et leurs inconvénients. Personnellement, je vais prendre la solution de facilité et utiliser Caddyfile.

Premier lancement avec Caddyfile

Par défaut, le fichier Caddyfile est situé /etc/caddy/ . Vous pouvez éventuellement rechercher le fichier avec find / -name Caddyfile si vous ne le trouvez pas. Maintenant l’idée, c’est de lancer Caddy, en lui précisant « utilise ce fichier de configuration« . Deux méthodes sont possibles :

1. Lancer Caddy depuis l’emplacement du fichier Caddyfile. Pour cela :
   cd /etc/caddy/
caddy run
2. Lancer Caddy en précisant l’emplacement du fichier Cadyfile. Pour cela :
   caddy run --config /chemin/vers/Caddyfile

(par la suite, j’utiliserai personnellement la premiére methode)

La commande « run » va lancer le serveur, et afficher des logs sur le terminal. Une fois que c’est fait, on peut aller faire notre premier essai pour voir si notre serveur répond ! Personnellement, j’ai configuré mon routeur pour que l’adresse IP locale de ma machine ne bouge pas ; et j’ai donc attribué manuellement une adresse IP locale. En cas de doute on peut taper hostname -I pour afficher notre adresse locale.

Puis, dans la barre d’adresse de votre navigateur préféré, il suffit de taper cet adresse IP suivi du port 80 comme ceci :

192.168.1.2:80
(à adapter selon votre configuration) ; et vous devriez obtenir ceci !

On est content ! On va couper le serveur Caddy pour le moment, et on le relancera quand on aura tout préparé !

caddy stop

Accéder à notre serveur depuis l’extérieur du réseau : les enregistrements DNS.

Pour le moment, on se connecte à notre serveur via notre réseau local . L’idée étant de pouvoir accéder depuis n’importe quel ordinateur dans le monde à notre serveur. Pour celà, il faut aller configurer les enregistrements DNS.

C’est maintenant que le nom de domaine que l’on a acheté précedemment va nous servir. L’idée c’est de lié l’adresse monsupersite.truc à votre serveur. Par analogie avec un annuaire téléphonique, ca serait de lier le nom de la personne Marcelle Michu à un numéro 01 47 20 00 01 (par exemple : pour la blague, c’est le numéro de Jean Mineur 😀 ). Ainsi à chaque fois que je souhaite appeler Marcelle Michu, ca me redirige automatiquement surs on numéro.

Il faut donc aller modifier les enregistrements DNS de votre registrar. Ca dépend evidemment de chaque registrar, il faut aller fouiller. Généralement aprés une petite recherche avec les bons mots clef, vous trouverez comment faire ça. Généralement, ces enregistrements sont gérés par un fichier texte. Dans tout çà vous devriez avoir une ligne ou deux lignes qui ressemble à :

@ 10800 IN A 111.222.33.44


@ 10800 IN AAAA 2222:444:8888:3333:bbbb:5555:3333:1111

La premiere ligne correspond à IPv4 et la deuxieme à IPv6 (ici, ce sont des adresses fictives). Peut être que vous n’aurez que la premiere, et que le premier nombre ne soit pas 10800 mais une autre valeur. Tout ce qu’il faut faire c’est supprimer ces lignes et ajouter à la place les IP publiques (v4 et/ou v6) de réseau.

Bref, une fois qu’on a nos adresses, on supprime les lignes que je viens de vous présenter, et à la place on précises nos valeurs :

Pour l’IPv4

@ 10800 IN A 111.222.33.44
* 10800 IN A 111.222.33.44 

Pour l’IPv6 le cas échéant :

@ 10800 IN AAAA 2222:444:8888:3333:bbbb:5555:3333:1111

* 10800 IN AAAA 2222:444:8888:3333:bbbb:5555:3333:1111

Si vous ignorez votre IPv4 , dans un terminal d’une machine sur votre réseau il suffit de taper curl -4 icanhazip.com
Siv ous ignorez votre IPv6,  dans le terminal de votre serveur, curl -6 icanhazip.com (en effet, l’adresse IPv6 est différente pour chaque appareil)

N’oubliez pas d’enregistrer / d’appliquer cette modification. Selon le registrar ca peut prendre plus ou moins de temps. De instantané, à 48 heures.

 

Accéder à notre serveur depuis l’extérieur du réseau : la redirection des ports.

J’en avais déja parlé dans cet article ci. Il faut maintenant faire une direction de port. Par rapport à ce qu’on vient de faire précédemment, on a « dit au réseau » que mon serveur habitait à tel endroit. Mais comme vous le voyez, il y a plusieurs machines sur mon réseau local. Il faut donc dire à qui on veut parler.

Malheureusement, chauqe modem/routeur étant différent, c’est toujours compliqué à expliquer étape par étape.  Sachez qu’il faut rediriger toutes les connexion en HTTP (port 80) et HTTPS (port 443) vers votre machine. Chez moi ca ressemble à ça :

• Nom du service : on peut mettre ce qu’on veut. Je vous conseil évidemment de mettre quelquechose d’explicite plutot que « Jeanine » ou « TartempionRoujax_3000 ».
• Adresse IP source : Ici, on ne met rien. Ca veut dire quoi ? Que votre serveur est accessible depuis toutes les machines du monde. Si on précisait une IP ou une plage d’IP ; votre machine ne serait accessible que depuis ces points.
• Plage de port : Ici, c’est le port entrant. C’est à dire que lorsqu’on se connecte sur ce port là , on va être redirigé selon les régles que l’on spécifie juste aprés.
• Adresse IP locale : Ici, je précise l’adresse IP locale de la machine sur laquelle je souhaite me connecter.
• Port local : Sur mon modem routeur, je peux différencier le port entrant, du port local. C’est à dire que je peux rediriger vers un autre port. On en reparlera quand paramétrera SSH.
• Protocole : TCP (je rentre pas plus loin dans les détails (parceque j’y connais rien à ce sujet) je sais juste qu’il faut mettre TCP.

On valide, on applique, on redémarre le boitier si besoin.

 

Préparer une landing page.

Maintenant, on va reprendre les indications que nous donnait Caddy :

La premiére étape, c’est fait ! On a redirigé notre domaine vers notre serveur.
Maintenant étape 2, on va préparer une page d’accueil pour notre serveur web. On appelle ça « landing page ».

Dans le terminal connecté à notre serveur. On va créé un répertoire pour héberger cette page.

mkdir -p /var/www/html

Puis on va créer le fichier index.html :

nano /var/www/html/index.html

On écrire un petit code HTML tout simple. On pourra l’améliorer plus tard :

<!doctype html> <html> <head> <title>Mon Super Site</title> </head> <body> <p>Youpi ! Ca marche !</p> </body> </html>

On enregistre ça et on continue !

Editer le fichier Caddyfile.

C’est l’étape 3 (cf le screenshot ci dessus), il faut éditer notre fichier Caddyfile :

nano /etc/caddy/Caddyfile

  GNU nano 4.8                      /etc/caddy/Caddyfile                               
# The Caddyfile is an easy way to configure your Caddy web server.
#
# Unless the file starts with a global options block, the first
# uncommented line is always the address of your site.
#
# To use your own domain name (with automatic HTTPS), first make
# sure your domain's A/AAAA DNS records are properly pointed to
# this machine's public IP, then replace the line below with your
# domain name.
:80

# Set this path to your site's directory.
root * /usr/share/caddy

# Enable the static file server.
file_server

# Another common task is to set up a reverse proxy:
# reverse_proxy localhost:8080

# Or serve a PHP site through php-fpm:
# php_fastcgi localhost:9000

# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile

Voilà le fichier que vous obtenez par défaut.
Il faut modifier :80 par le nom de domaine qu’on a acheté précédemment.
Puis modifier /usr/share/caddy par /var/www/html . Ca doit donner qqch comme ça :

monsupersite.truc
(...)
root * /var/www/html

On enregistre le fichier.

Relance le serveur : alors, ça marche ?

Puis, on va redemarrer notre serveur Caddy (je rappel que j’utilise la méthode où l’on se place dans le répertoire contenant Caddyfile.)
caddy start

Cette fois ci, j’utilise la commande « start » plutot que « run » car je veux que Caddy s’execute en background pour garder la main sur le terminal.

Enfin, on tente de se connecter via un navigateur en tapant notre nom de domaine dans la barre d’adresse :

 

Et si tout se passe bien, vous remarquerez que votre site est automatiquement géré en HTTPS par Caddy. Vous n’avez rien configuré de plus !

 

Conclusion

On a notre serveur en ligne ! Youpi ! Bon. Actuellement, ca fait pas grand chose. Mais la prochaine fois, on l’améliorera ! On y ajoutera notre premier service , on s’intéressera au reverse proxy, et au fail2ban… Comme dirait un grand philosophe français :

« C’est que le début : d’accord, d’accord ».

 

Merci d’avoir lu cet article, j’espére qu’il vous a plu que vous avez appris des choses. N’hésitez pas à me faire vos retours ! Si vous rencontrez des difficultés techniques, je vous suggére de vous orientez vers des forums spécialisées ; vous y obtiendrai une meilleure aide que la mienne.