Raspberry à la sauce Alpinelinux

Note : cette étape n’est pas nécessaire à la réalisation du tutoriel, mais elle permet d’en connaître un peu plus sur cette distribution utilisée.
Nous n’avons trouvé que deux billets en français sur le site linuxfr.org, un datant de 2012 et un autre plus récent de 2015. Ce qui fait le charme de cette distribution, c’est sa légèreté aussi bien dans sa mise en œuvre que dans son occupation mémoire grâce notamment à Musl libc et à Busybox.

Bien que orienté serveur il existe des environnement de bureau comme Gnome, Xfce, Mate … ainsi que Firefox vlc … de quoi se faire un « linux maison ».
Le site du projet en anglais, indique que la distribution s’adresse aux « utilisateurs avancés » qui apprécient la simplicité la sécurité et l’efficacité.
Les utilisateurs d’Archlinux seront de suite à l’aise avec Alpinelinux à quelques différences mineures (systemd …).

Alpine est disponible pour les architectures suivantes X86, X86_64 et ARM le tout en plusieurs versions :
– Standard (iso de 299 MB),
– Mini (iso de 88 MB),
– Raspberry Pi (iso de 150 MB),
– Generic ARM (iso de 73 MB).

Suivant les architectures Alpine Linux propose trois modes d’installation :
– diskless : le boot se fait à partir d’un support tel que CD ou clef USB. C’est un mode « live », le système se charge uniquement en RAM. Un outil spécifique a donc été développé pour assurer la pérennité des modifications dans ce mode : Alpine Local Backup (LBU), afin d’enregistrer les modifications à conserver au redémarrage.

– data mode : comme en mode diskless, le système fonctionne à partir d’un support type « read only », mais ici une partition en lecture/écriture est utilisée pour conserver les données dans /var. C’est le mode d’utilisation préconisé dans le cas où de grandes quantités de données ont besoin d’être préservées entre les réinitialisations.

– sys mode : installation classique sur un disque dur.

Les intérêts d’Alpinelinux pour le Raspberry sont :
– la taille réduite du système et des paquets
– la faible empreinte mémoire qui laisse le maximum de ressources disponible pour le serveur
– le mode diskless totalement adapté (non sans quelques contraintes, que nous aborderons par la suite)

De même que Archlinux, Alpinelinux n’installe par défaut que les paquets strictement nécessaires au fonctionnement du système.
L’archive, de type tar.gz (alpine-rpi-3.x.x-armhf.rpi.tar.gz), étant téléchargée (http://alpinelinux.org/downloads/) il suffit de la décompresser sur une carte micro SD formatér en FAT32.
Insérer la carte micro SD dans son lecteur, sur votre PC. Dans une console tapez la commande :

tar xzvf alpine-rpi-3.2.3-armhf.rpi.tar.gz -C /chemin/vers/carte/micro/SD

Pour les utilisateur sous Windows 7zip fera la meme chose.

Ceci fait, installez la carte micro SD dans le Raspberry, connectez un écran, un clavier et le câble Ethernet à celui-ci et mettez sous tension.
Le système démarre très rapidement, et le prompt doit apparaître.

La première opération consiste donc à faire un setup, comme l’indique le message d’accueil. Par défaut le clavier est en format qwerty, ainsi pour taper la commande :
setup-alpine
Tapez : setup + tab +ql + tab

[ Pour les étapes sans précision, ci-après, il vous suffit d’approuver les choix par défaut en tapant Entrée. ]

– le type de clavier : fr puis fr-pc (tapez fr + parenthèse fermante+ pc),
– le hostname (exemple : monserveur),
– l’interface réseau (eth0 en dhcp),
– mot de passe (notez-le dans un coin !),
– la timezone (Europe, Paris).
– le proxy,
– les mirroirs,
– le serveur ssh,
– le serveur de temps (le Raspberry n’ayant pas d’horloge interne) : Chrony par défaut,
– où les paquets seront stockés (par défaut sur la carte micro SD du Raspberry),
– emplacement de sauvegarde des fichiers de configuration : carte SD par défaut,
– répertoire de sauvegarde des paquets : carte SD par défaut,

En cas de saisie incorrecte, il est toujours possible de revenir sur l’un ou l’autre de ces réglages en tapant la commande :
setup-
en remplaçant par :
keymap : pour le clavier,
hostname,
interfaces (pour l’interface réseau),
timezone,
proxy,
apkrepos (pour les mirroirs),
sshd,
ntp (pour le serveur de temps),
apkcache (emplacement de stockage des paquets),
lbu (stockage des fichiers de configuration).
Le changement de mot de passe se fera avec la commande : passwd (Attention, il faut connaitre l’ancien mot de passe !)

Enfin pour travailler plus confortablement ajoutez l’éditeur de texte nano (plus convivial que vim installé par défaut) :
apk add nano

Remarque 1 : il est nécessaire d’avoir une IP fixe sur le Raspberry soit par réservation d’un bail sur la box de son FAI (voir alors la doc de votre box pour les options dhcp / mac adress), soit par codage en dur directement sur le Raspberry (setup-interfaces).
Remarque 2 : si, lors de la première connexion le message : permission denied apparaît, éditer le fichier : sshd.conf
nano /etc/ssh/sshd_config
Ajouter ou rechercher la ligne :
PermitRootLogin
la décommenter et la passer à yes.
Enregistrer le fichier : ctrl + O ou F2
Enfin : redémarrer le service :
/etc/init.d/sshd restart

L’installation de base terminée, le Raspberry Pi est accessible en ssh depuis une machine distante du réseau local. l’écran dédié et le clavier sont donc inutiles. Votre Raspberry restant câblé (alimentation et réseau), à partir d’une autre machine relié au (même) réseau, tapez dans une console :
ssh root@ ip du Raspberry
Lors de cette première connexion un message vous préviens que l’hôte est inconnu (voir ci-dessous), vous devez continuer en tapant « yes » en toute lettre.

The authenticity of host ‘ ()’ can’t be etablished
ECDSA key fingerprint is
Are you sure you want to continue connecting (yes/no) ? yes

Le système vous préviens alors que l’hôte est ajouté dans la liste des hôtes connus :
Warning : Permanently added ” (ECDSA) to the list of the known hosts.
ssh_packet_read : connection closed

Retapez alors la commande, puis le mot de passe :
ssh root@ip du Raspberry
root@ip du Raspberry ‘s password :

Vous devez alors accéder à la console Alpine du Raspberry :
Welcome to Alpine !
The Alpine Wiki contains a large amount of how-to guides and general
information about administating Alpine Systems.
See
You can setup the system with the command : setup-alpine
You may change this message by editing /etc/motd.
hostname [~]#

Alternative libre à des services tels que Dropbox ou Google Drive, owncloud permet d’autohéberger ses fichiers. L’application dispose également de fonctions complémentaires telles que : calendrier partagé, lecteur audio et vidéo éditeurs de documents …

Installation des paquets de base :
Avant toute installation de paquets assurez-vous que vous avez les derniers paquets à disposition. Alpinelinux Package Management (apk) est l’outil qui permettra la mise à jour de la base de données des paquets, l’installation et la suppression des paquets (équivalent à pacman et yaourt pour Archlinux et apt pour Debian)
Mise à jour de la base de données des paquets, tapez dans la commande  :
apk update
Il s’agit ensuite de choisir la base de données qui sera utilisée : sqlite, postgresql, mariadb (mysql). Dans notre cas, n’ayant pas l’intention ni le besoin de synchroniser les fichiers déposés dans owncloud sur les machines clientes le choix s’est porté sur sqlite. On installe donc le paquet approprié :
apk add owncloud-sqlite
Le téléchargement est très (très) rapide, les paquets sont ultra-light, votre bande passante n’en souffrira pas !

Pour l’instant pas de réglages, il faut installer le serveur. Là encore le choix peut se faire entre Nginx et lighttpd. La règle de départ que nous nous étions fixé étant le light, notre choix s’est porté sur lighttpd (nous verrons plus loin ses limites). Les deux paquets pour le serveur lighttpd et php s’installent avec la commande :
apk add lighttpd php-cgi php-curl

Quelques réglages sont alors nécessaires. Ouvrez le fichier de configuration
nano etc/lighttpd/lighttpd.conf
Décommenter la ligne (pour trouver rapidement : ctrl + w + _fastcgi)
include “mod _fastcgi.conf”
Enregistrer la modification (ctrl + O)
puis démarrer Lighttpd :
/etc/init.d/lighttpd start
ou
rc-service lighttpd start
La commande :
rc-status
permettra de vérifier l’état des services :
lighttpd [started]

Pour tester simplement le fonctionnement, ajouter une page test tapez la commande :
echo “Lighttpd OK…” > /var/www/localhost/htdocs/index.html

Ouvrez ensuite votre navigateur et tapez l’IP du Raspberry dans la barre d’adresse, le texte « Lighttpd OK » doit s’afficher.
Dans le cas contraire, redémarrez le serveur :
/etc/init.d/lighttpd restart
Si tout est ok, régler le démarrage du service lighttpd au démarrage du Raspberry  Pi:
rc-update add lighttpd default

Il faut enfin ajouter un lien symbolique qui renverra le répertoire dans lequel owncloud est installé vers le répertoire du web server.
ln -s /usr/share/webapps/owncloud /var/www/localhost/htdocs

On pourra par la suite sécuriser un tantinet le serveur en utilisant une connexion https, voyez à ce sujet la page du wiki : http://wiki.alpinelinux.org/wiki/Lighttpd_Https_access

Remarque concernant la taille des fichiers en upload (machine distante -> serveur) :
La taille des fichiers téléchargeables et réglée par défaut à 2MB. Quoique vous fassiez, lighttpd vous limitera dans la taille des fichiers téléchargeables vers le serveur, avec la version actuelle de lighttpd (1.4.36). Toutefois, en attendant la mise à jour de Lighttpd, vous pouvez d’ors et déjà augmenter la taille des fichiers téléchargeables à la limite de 2048 MB : il faut modifier le fichier de configuration de php : éditez le fichier : /etc/php/php.ini, Chercher et modifier les deux lignes suivantes :
upload_max_filesize = 2048M
post_max_size = 2048M
enregistrez les modifications.
Redémarrer le serveur :
/etc/init.d/lighttpd restart

Le Raspberry Pi étant branché et relié au réseau, sur une autre machine dans votre navigateur favori, tapez l’adresse : http:// /owncloud
Si tout va bien la page d’accueil Owncloud s’affiche… avec une erreur ! En effet Owncloud vous indique que le serveur n’a pas les droits d’écriture nécessaires.
Il faut modifier les droits pour le répertoire /data dans /var/lib/owncloud :
Sur le Raspberry, placez-vous dans le répertoire /var/lib/owncloud (tapez : cd /var/lib/owncloud + entrée), puis modifiez les droits comme suit :
chown -R lighttpd:lighttpd data/
Même procédure pour le répertoire /etc/owncloud.

Il est également nécessaire de sauvegarder le répertoire /usr/share/webapps/owncloud l’inclusion dans LBU se fait avec la commande :
lbu add /usr/share/webapps/owncloud
(l’exclusion d’un fichier ou répertoire se fait simplement en remplaçant add par delete dans la commande)
Toutes les manipulations hasardeuses peuvent donc être faites sans risque pour le système, pour peu que celles-ci ne soient pas sauvegardées. Au prochain démarrage Alpine redémarrera avec la dernière archive créée. Il convient donc de ne faire un LBU que lorsque vous êtes sûr de vos modifications ! Ceci fait, l’archive pourra être précieuse pour restaurer le système, il n’est donc pas inutile de la stocker sur un support tiers avec la dernière sauvegarde du cache.
Voir à ce sujet : http://wiki.alpinelinux.org/wiki/Alpine_local_backup

Redémarrez le serveur
/etc/init.d/lighttpd restart
et recharger la page dans le navigateur (ctrl + r). La page d’accueil Owncloud doit maintenant s’afficher vous demandant d’entrer un nom d’utilisateur pour l’adminitrateur et un mot de passe. C’est gagné !
Ceci fait, il est temps de sauvegarder le système en y incluant les répertoires htdocs et data :
lbu add /var/www/localhost/htdocs
lbu add /var/lib/owncloud/data
lbu ci -v

Si tout va bien vous devez arriver à ça !

D’une part pour limiter l’usure de la carte micro SD du fait des écritures multiples des données utilisateurs, et d’autre part pour réserver la carte micro SD uniquement au système, les données seront écrites sur un disque externe USB (ici une clef USB branchée sur un des ports du Raspberry Pi). Le problème paraît simple au départ, il suffit d’ajouter une entrée dans le fstab de façon à monter automatiquement la clef USB au démarrage, de déplacer les répertoires des utilisateurs situées dans /var/lib/owncloud/data vers la clef USB puis de créer des liens symboliques du dossier /var/lib/owncloud/data vers les dossiers utilisateurs situés sur la clef de stockage et enfin d’exclure du LBU les répertoires utilisateurs (sinon LBU suivra les liens symboliques et enregistrera les données utilisateurs de la clef externe sur la micro SD…). Essayons cela.
lbu exclude /var/lib/owncloud/data/utilisateur1

Hélas, après redémarrage, cela ne fonctionne pas… En effet, le démarrage d’Alpine est trop rapide (!!) pour les disques externes et les clefs USB qui n’ont pas le temps de s’initialiser… Bien que le périphérique de stockage soit effectivement monté, les répertoires et fichiers qu’il contient n’apparaissent pas ! De plus, au redémarrage les liens symboliques ont été effacés, puisque exclus du LBU… Aïe !!

La solution :
1- Créer le répertoire de montage et monter la clef USB :
Remarque : le “nom” de la clef USB peut être facilement trouvé en tapant la commande :
fdisk -l
Cette commande renvoie la liste des périphériques de stockage. Sachant que la carte micro SD sera identifiée mmcblk… l’autre périphérique sera donc la clef USB de stockage (normalement : sda1)
tapez donc :
mkdir -p /media/sda1
mount /dev/sda1 /media/sda1
Vérifier le point de montage en tapant :
mount | grep sda1
la commande renvoie : /dev/sda1 on /media/sda1 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

2- Déplacez les répertoires utilisateurs (et leur contenu) situés dans /var/lib/owncloud/data vers la clef de stockage.
mv /var/lib/owncloud/data/nom_utilisateur1 /media/sda1/. (attention tapez le point en fin de ligne !!!)
etc…
Dans notre exemple (voir capture d’écran) utilisateur1 est admin.

Le message suivant va apparaître : mv: can’t preserve ownership of ‘/media/sda1/admin/files’: Operation not permitted
Peu importe, cela est du au système FAT 32 de la clef. Si ce message vous dérange, la clef devra être préalablement formatée en EXT3/4, mais pour la compatibilité il est préférable de rester en FAT.

3- La solution va consister à écrire un script qui s’exécutera en fin de démarrage du Raspberry et qui exécutera les actions suivantes :
– création d’un point de montage pour le périphérique de stockage USB :
– montage du périphérique :
– re-création du (des) lien(s) symbolique(s) du dossier /var/lib/owncloud/data vers les dossiers utilisateurs situés sur la clef de stockage
Cette solution pourra paraître peu orthodoxe, mais le script ci-dessous remplit parfaitement son rôle.
Éditer le fichier : nano /etc/local.d/demarrage.start

# !/bin.sh
#
#Script de démarrage
# Forcer le démarrage de Chrony
/etc/init.d/chronyd restart
# Création d’un point de montage pour la clef USB
mkdir -p /media/sda1
# Montage de la clef
mount /dev/sda1 /media/sda1
# Création des liens symboliques
ln -s /media/sda1/nom_utilisateur1/ /var/lib/owncloud/data/nom_utilisateur1
ln -s /media/sda1/nom_utilisateur2/ /var/lib/owncloud/data/nom_utilisateur2
return 0

Enregistrer : ctrl + O
Rendre le script exécutable : chmod + x /etc/local.d/demarrage.start
démarrer le service local : rc-update add local

Remarque : au démarrage il est apparu nécessaire de forcer le démarrage de chrony afin de s’assurer de la mise à la date et à l’heure du système, sans quoi il y a cafouillage avec la base de données.

Remarque 3 : attention, un petit lbu s’impose !!

Un serveur de fichiers c’est bien, mais s’il est accessible depuis n’importe où dans le monde, c’est mieux !
Certains FAI (tel que celui portant le nom d’un fruit dont nous ne donneront pas la couleur…) ne proposent l’IP fixe qu’aux clients professionnels ou pour la somme exorbitante de 18 € par mois pour les particuliers !!
De nombreuses solutions ont été explorées durant cette phase de mise au point, depuis l’excellent article de Michel Rambouillet dans le n° 90 de Linux Pratique en passant par les nombreux services de DynDNS (no-ip, freeDNS, etc. …). Dans bien des cas les scripts sont complexes et ceux écrits en bash ne sont pas toujours entièrement compatible avec le ash utilisé par Alpine, d’où un besoin de ré-écriture, pas envie… Bref !
Après recherches et tests divers il s’est avéré que le service proposé par duckdns.org (https://www.duckdns.org/) est largement le plus simple à mettre en œuvre. Comme tous les services de DNS dynamique, après création d’un compte, duckdns vous permet de choisir un nom de domaine qui sera associé à votre IP publique.
La surveillance du changement d’IP se fait par l’intermédiaire d’un script, d’une ligne (fourni par duckdns), à copier sur le Raspberry et qui devra s’exécuter périodiquement en programmant une tâche avec Cron.

echo url=”https://www.duckdns.org/update? domain= nom_du_domaine_ choisi&token=référence_ alphanumérique&ip= ” | curl -k -o /repertoire/où/enregistrer/le/log/duck.log -K –
Si cette ligne vous paraît absconde, sachez que toute la procédure est clairement définie sur le site du carnard.
C’est tout !
Ce script peut être copié dans le répertoire /periodic/hourly/. Ainsi l’IP sera vérifiée toute les heures (ce qui chez la cousine de la Clémentine n’est pas du luxe…). Notez que le fichier duck.log peut être enregistré directement dans un répertoire accessible via Owncloud.

Reste un dernier point à régler dans le fichier /etc/owncloud/config.php, cherchez la ligne “trusted domains”
Dans cette section il faut ajouter votre nom de domaine créé avec le service Duckdns. Ce qui doit ressembler à quelque chose comme ça :
‘trusted_domains’ =>
array (
0 => ‘192.168.1.9’,
1 => ‘VotreNomDeDomaine.duckdns.org’
),
‘overwrite.cli.url’ => ‘http://VotreNomDeDomaine.duckdns.org/owncloud’
‘dbtype’ => ‘sqlite3’,
);

Enregistrez et quittez.

L’accès au serveur doit alors être possible depuis l’Internet en tapant dans la barre d’adresse du navigateur quelque chose de ce type :
http://VotreNomDeDomaine.duckdns.org/owncloud

Laissez le temps à la page de s’afficher : n’oubliez pas que le Raspberry reste une petite machine.

Un peu rugueuse au premier abord, la distribution Alpinelinux trouve complètement sa place dans le Raspberry PI, au regard de son empreinte mémoire ridiculement faible et la taille de ses paquets. La configuration décrite ci-dessus fonctionne maintenant sans anicroche depuis plusieurs mois. Pour ceux qui ont déjà goutté à Archlinux, n’hésitez pas, Alpine est faite pour vous !
avec htop, (voir ci-dessus), on constate la faible empreinte mémoire au vu des services en fonctions, ainsi que la charge du CPU.
Lors d’une connexion vers les services Owncloud depuis une machine distante la charge du CPU monte rapidement mais redevient normale rapidement et l ‘on constate qu’au niveau mémoire Alpine en a encore largement sous le pied.

Attention : pour garder la stabilité de l’ensemble il est préférable de privilégier les mises à jour en provenance d’Alpine plutôt que d’Owncloud. En effet, ce dernier étant en développement constant certaines fonctionnalités demandent de nouvelles dépendances non encore prises en compte par les mainteneurs des paquets Alpine. Vous pouvez néanmoins le faire mais attendez-vous à passer quelques heures à rechercher les messages d’erreur dans les logs…
Avec un peu d’acharnement vous pourrez obtenir un lecteur de musique/vidéo, un agrégateur de flux RSS et bien d’autre plugins pour faire de votre Raspberry PI le meilleur “Cloud” chez vous !

Alpinelinux constitue par ailleurs une base parfaitement adaptée à la mise en œuvre de services réseaux tels que mails, dlna, gateway internet, proxy … Il faut juste avoir un peut de patience avant d’avoir les résultats escomptés. Bon Courage …