[Linux/Hardkernel] NAS et owncloud perso avec Odroid XU4 et son boitier Cloudshell

23/04/2018 : Cet article prend désormais en charge le nouveau boitier Cloudshell n°2 du fabricant Hardkernel.

29/09/2016 : Article mis à jour. Il prends en charge Ubuntu 16.04 uniquement et n’est plus valable pour Ubuntu 14.04.

La carte mère Odroid XU4 est une des dernières moutures du fabricant coréen Hardkernel qui se présente avec une puissance globalement 3 fois plus puissante que son concurrent anglais Raspberry Pi 2.odroid-xu41

Elle embarque notamment un SoC Samsung Exynos 5422 octo-core et 2Go de RAM, accompagnés par 1 port Ethernet Gigabit, 2 ports USB 3.0, 1 port USB2.0.

PROJET

=> monter un NAS de toute pièce qui permettra l’accès à des fichiers avec les services suivants :

  • Accès aux fichiers depuis un PC Windows ou Linux (Samba),
  • Accès à ces fichiers depuis Internet (ownCloud),
  • Lecture des fichiers depuis le Freebox player, smartphone, tablette (miniDLNA).

Depuis les débuts de Raspberry Pi, j’ai toujours voulu monter un NAS perso, compact et basse conso en utilisant un de ces modèles de mini carte-mère. Les versions de Raspberry Pi ont fusé depuis mais aucune d’entre-elles ne permettaient d’alimenter un disque dur externe sans devoir passer par des hubs et autres alimentations externes faisant sauter le critère « compact » et « propre » du projet initial. Bon ce n’est plus le cas aujourd’hui puisque Western Digital propose un disque dur spécialement conçu pour le Raspberry Pi : http://www.wdc.com/wdproducts/library/QIG/Global/4079-705156.pdf.

Même si la problématique du disque dur auto-alimenté est résolue, ça n’est pas le seul point faible du Raspberry Pi. En effet, sur ce dernier et quel que soit la version, l’USB (au passage toujours en 2.0) et l’Ethernet sont gérés par le même contrôleur, ayant pour conséquence une réduction du débit puisque celui-ci est partagé. Ce qui n’est pas le cas avec l’Odroid XU4 qui possède l’USB 3.0 et l’Ethernet Gigabit gérés indépendamment. Le fabricant Hardkernel affiche un débit (soit-disant) de 80Mo/s en copie depuis un partage géré par l’XU4 vers un PC :

201507011941294036

Bref, cet Odroid XU4 me semblait avoir tout pour faire un NAS et le constructeur en rajoute une couche en proposant justement un boitier compact permettant de monter la carte et un disque dur 2,5″, avec en prime un petit écran LCD pour afficher des informations au choix : le  « Cloudshell » ou sa version améliorée permettant d’embarquer deux disques 3,5″ et de faire du RAID, le « Cloudshell 2 » :

Avec le Cloudshell v1, j’en avais eu pour un total de 362€ comprenant la carte XU4, le boitier et deux disques de 2To (achetés en promo).

Avec le Cloudshell v2, j’ai réutilisé la même carte mère mais j’ai racheté deux disques de 4To et le boitier, dont voici le détail :

  • 1 boitier Cloudshell 2 à $88.60 (soit 71€), auquel j’ai dû ajouter 29€ de frais de douanes (super) pour un total de 90€,
  • 2 disques WD 4To en promo pour un total de 176.22€.

Soit un total de 266,22€ pour cette mise à jour vers ce nouveau boitier. Ca fait un peu cher la mise à jour quand même et encore je ne suis pas au bout de mes surprises.

MESAVENTURES DE LIVRAISON

Il y a longtemps que je voulais me payer ce nouveau boitier afin de pouvoir profiter de disques au format 3,5″ qui sont relativement moins cher à l’achat que des disques 2,5″. J’ai donc profité d’une promo pour acheter des disques 4To puis j’ai laissé passer quelques mois avant d’enfin prendre le boitier.

Je commande donc le boitier sur le site officiel Hardkernel en prenant le temps de vérifier sur les forums les retours et éventuels problèmes qu’ont pu rencontrer d’autres utilisateurs. Rien d’alarmant donc je commande le boitier « les yeux fermés » et sans le cordon d’alim à 3$, c’est toujours ça de gagné (en gros ils fournissent le transfo mais sans le cordon d’alim. Comme il s’agit d’un cordon classique ça ne sert à rien de se ruiner pour ça). Jusque là je ne me pose pas plus de questions et je paie.

Je reçois quelques jours plus tard le mail de confirmation d’envoi de ma commande et que celle-ci me parviendra sous 7 jours. OK.

3 heures plus tard je reçois mail, sms, la totale de DHL me disant qu’il faut que je paie les frais de douanes d’un montant de 29€ auquel cas je ne recevrais pas ma commande (par contre je devrai payer quand même les frais de douanes, ah ouais donc pas le choix). C’est à partir de là que j’ai commencé à en vouloir un peu à Hardkernel. Je n’ai jamais payé de frais de douanes de ma vie, et je n’en avait pas eu lors de ma commande de la carte XU4 et du boitier quelques années auparavant. Pourtant le montant de la commande était tout aussi éligible aux frais de douanes (166€ à l’époque). Enfin bref pas de chance mais ça commence à faire très cher pour un boitier…

Je reçois le colis deux jours plus tard (ça a pris moins de 7 jours finalement).

MONTAGE

Je déballe le colis et là, premiere déception : les pièces sont protégées mais il y a un énorme vide dans le carton. Il manque clairement de papier bulle ou d’un truc pour caler le tout. Ici rien n’empêche les pièces de se balader si le carton est retourné pendant le transport :

Enfin bon je me dis que le livreur était tendre et que mon colis n’a pas subi quelconque traumatismes !

J’attaque le montage à l’aide des instructions du site officiel, autant vous dire que c’est un peu la galère : les instructions ne sont pas très claires et les photos sont prises sous un angle qui n’aide pas. Quelques photos du montage :

J’arrive tant bien que mal à terminer le montage et je dois avouer que je reste mitigé du résultat. Le montage est plutôt bien pensé, certaines pièces s’emboitent un peu comme des lego afin de pouvoir être démontées plus facilement si besoin (en cas de maintenance par exemple). Mais du coup il y a du jeu entre les pièces ! Le boitier est plutôt robuste dans sa partie inférieure grâce aux deux disques vissés dans la structure, mais la partie supérieure et arrière est une catastrophe (le capôt est maintenu par une pièce verticale, elle même maintenue par une autre pièce horizontale, elle même fixée par une pièce qui verrouille le tout, elle même fixée par une vis…olala). Ca manque clairement de finition de ce côté là et c’est dommage pour un boitier à 71€ (ah bah non j’oubliais, 90€ finalement).

Enfin bon je continue, je branche le tout et le serveur démarre. C’est beau ça s’allume, ça se lance, ça fait du bruit (le ventilo arrière) et je visualise le boot sur l’écran LCD. Oh tiens il est tout bizarre l’affichage, j’ai pas enlevé la protection ça doit être pour ça. Ah bah non en fait il y a une grosse fissure sur une partie de l’écran, génial ! (quand je vous disais qu’il y avait du vide dans le carton d’emballage, peut être qu’il a pris cher pendant le transport). Ca commence à faire trèèèèès très cher pour un boitier tout pété :

J’envoie un mail à Hardkernel, photo à l’appui, en leur disant que leur emballage ne va pas du tout et en leur demandant de me renvoyer un controlleur raid avec écran LCD, et surtout qu’il n’est pas question que je paie un renvoi ou quoi que ce soit, j’en ai ras le bol de payer. Ils m’ont demandé des photos de l’emballage et m’ont proposé de me renvoyer un écran LCD. Entre le premier mail et la réception du nouvel écran : 15 jours de passés. L’emballage était parfait cette fois, rien à redire, rien payé et le nouvel écran est fonctionnel. Sujet clos.

PETIT BILAN

Vous l’aurez deviné, je reste un peu mitigé de cet achat, autant sur l’emballage que sur le produit final. L’électronique a l’air de bonne qualité, ça fait le job mais ça n’a rien de révolutionnaire et c’est cher pour un boitier pas super esthétique. Comme sur la v1, l’écran apporte tout de même un plus par rapport à un NAS classique, ça permet d’afficher des informations ou d’avoir la main sur le shell si besoin, c’est assez pratique.

La possibilité de faire du RAID manquait vraiment à la v1, mais ici encore, rien de révolutionnaire pour un NAS. Le ventilateur apporte un bon flux d’air dans tout le boitier mais il est assez bruyant par contre (même avec le mode « silencieux »).

PRÉPARATION DU SYSTÈME

Plusieurs cas possibles :

Si vous ne souhaitez pas vous emmerder vous pouvez installer OpenMediaVault, un OS bien connu dans le monde du NAS et basé sur Debian. Une image optimisée pour l’Odroid XU4 est disponible ici : https://sourceforge.net/projects/openmediavault/files/Odroid%20images/

Avec OMV tout est administrable depuis une interface Web, accessible sur http://IP_DU_NAS Il est même possible de bidouiller le vhost Nginx afin de rendre l’interface disponible sur Internet. Avec ça vous avez la possibilité d’initialiser un RAID logiciel, des partages Samba, NFS, FTP et pleins d’autres services. C’est un produit bien fini et ça ne bug pas à priori (sauf la partie SMART qui plante dès qu’on l’active).

Sinon il existe toujours une image ubuntu-minimal, actuellement la 16.04 LTS, téléchargeable ici : http://odroid.in/ubuntu_16.04lts/ubuntu-16.04-minimal-odroid-xu3-20160706.img.xz

Mon choix perso en terme d’OS : j’ai testé pendant quelques jours OMV en attendant mon écran LCD de remplacement, pour voir si ce genre de solution me plaisait pour administrer mon NAS. Puis j’ai fini par retourner sur ubuntu-minimal pour les raisons suivantes :

  • Je préfère avoir le contrôle sur mes fichiers de config, ça me permets de savoir ce que je fais, ce que j’ajoute, ce que je supprime, de savoir où se trouvent les fichiers de conf sur mon système, de gérer les droits, etc… et de ne pas perdre la main !
  • OMV est bien foutu mais franchement c’est chiant. Après chaque modif, il faut appliquer ses changements, il faut cliquer partout et moi ça me gonfle.
  • Debian (l’OS caché derrière OMV) aussi m’a gonflé, j’ai trop galéré ne serait-ce que pour changer les locales du serveur et les passer en français. Tout a planté j’ai été obligé de désinstaller les locales et les réinstaller, ce qui bien sûr désinstalle dans la foulée le paquet openmediavault et ses dépendances (nginx, etc..), allez savoir pourquoi. Bref c’était encore plus du bricolage que sur ubuntu-minimal.

Sinon en terme de redondance des disques, j’ai choisi finalement de ne pas faire de RAID, explications :

  • A priori le RAID matériel que fourni le contrôleur du Cloudshell ne serait pas trop dégueu. D’après ce que j’ai vu sur le site officiel et sur les forums il semble même bien fonctionner et offre un bon débit. Ce qui me pose problème c’est que c’est du RAID matériel et que si le contrôleur crame.. ben je l’ai profond. Et vu la durée anecdotique de la garantie des composants Hardkernel (2 semaines ou un truc comme ça mdr !) et vu les mésaventures de livraison que j’ai pu avoir avec Hardkernel, je n’ose même pas imaginer de devoir les contacter pour demander un remplacement. Imaginez que dans quelques années ils arrêtent la production parce qu’il produisent un Cloudshell v5 ou autre, pareil je l’ai profond si mon contrôleur crame à ce moment là. Imaginez qu’ils ferment, qu’ils font faillite, je l’ai profond aussi. Bref je n’ai pas trop confiance en Hardkernel je l’avoue.
  • Concernant le RAID logiciel, ça a très bien fonctionné avec mdadm lorsque j’ai testé OMV, par contre ça divisait le débit en deux et ça mettait pas mal de charge au proc…
  • Puis au final quand j’y réfléchis, j’utilises mon NAS surtout le soir quand je suis chez moi, le reste du temps (toute la journée et une bonne partie de la nuit) il est au repos. A part dans le monde de l’entreprise, il me semble que la redondance des disques n’est pas vraiment utile pour la plupart des gens. De plus mes deux disques étant issus de la même série, cela augmente le risque qu’ils lâchent en même temps. Du coup de la même manière qu’avec le Cloudshell v1, je choisi de n’utiliser qu’un seul disque pendant que l’autre se conserve et reste au repos. Chaque nuit un backup du disque principal vers le disque secondaire est effectué, puis à nouveau le second disque retourne se reposer. Je ne risque pas grand chose de cette manière je pense. Je n’utilise donc pas toutes les fonctionnalités qu’offre le Cloudshell v2 c’est vrai, mais pour moi l’avantage de ce nouveau boitier était qu’il puisse accueillir des diquess 3,5″.

La procédure qui suit est une copie de mon précédent article sur le Cloudshell v1 que j’ai légèrement mis à jour et ré-adapté.

J’ai donc utilisé une carte SD sur laquelle j’ai installé ubuntu-minimal 16.04 LTS.

La procédure pour installer le système sur une carte SD est la même que pour un Raspberry Pi (Win32DiskImager sous Windows).

Très important : ne pas plugger tout de suite l’Odroid XU4 au boitier et aux disques, il faut le faire booter seul, car le kernel 4.14.5-92 plante lorsqu’on branche tout ce ptit monde ensemble. Il va falloir mettre à jour le kernel avant (on y arrive). Si vous avez téléchargé une image ubuntu possédant un kernel plus récent que 4.14.5-92 alors vous pouvez peut-être vous passer de cet avertissement.

Premier démarrage

Mettre sous tension l’Odroid, celui-ci va s’éteindre au bout de quelques secondes (absence de la led bleue). Je ne sais pas pourquoi, mais le remettre sous tension en appuyant sur le bouton intégré à la carte.

Le serveur SSH est activé par défaut, il est alors possible de se connecter à distance à l’XU4 dès son démarrage. Il suffit de trouver quelle adresse IP lui a été attribué par le serveur DHCP du réseau (scan IP ou bien en regardant les baux actifs dans l’interface de gestion de votre box par exemple).

L’utilisateur et le mot de passe par défaut sur ubuntu-minimal 16.04 LTS sont : root / odroid.

Effectuer les mises à jour :

$ apt update
$ apt upgrade
$ apt install linux-image-xu3 (il s'agit de la mise à jour du kernel, elle reste volontairement en suspend, d'où le fait qu'on la fait à part)

La mise à jour du kernel affiche un message qui dit qu’on fait quelque chose de très dangereux oulalaa, et qu’il faut abandonner tout de suite. Répondre par No :

Do you want to abort removal now?
> No

Rebooter et vérifier que le nouveau kernel 4.14.24-113 ou plus est actif :

uname -a 
Linux odroid 4.14.24-113 #1 SMP PREEMPT Mon Mar 5 12:21:35 UTC 2018 armv7l armv7l armv7l GNU/Linux

A partir de là, on peut éteindre le système puis brancher la carte au Cloudshell v2. Normalement ça boot sans problème.

Changer le passwd root :

$ passwd

Installer des paquets de base :

$ apt install vim top htop rsync

Configuration de la langue et de l’encodage des caractères :

$ apt install language-pack-fr
$ echo "LANG=fr_FR.UTF-8" > /etc/default/locale
$ dpkg-reconfigure locales

Dans la liste, sélectionner fr_FR.UTF-8 UTF-8, puis confirmer à nouveau ce choix à l’étape suivante afin qu’il soit configuré par défaut. Se déconnecter pour prendre en compte les nouveaux paramètres.

Configuration de la Time Zone :

$ dpkg-reconfigure tzdata

Puis choisir Europe puis Paris.

(Optionnel) Par défaut, la couleur est désactivée dans le terminal. Pour l’activer, il faut éditer le fichier suivant dans le home directory de l’utilisateur root :

$ cd
$ vim .bashrc

Dé-commenter la ligne suivante :

force_color_prompt=yes

Enregistrer, quitter, puis exécuter la commande suivante pour appliquer les changements :

$ source .bashrc

CONFIGURATION DE LA CARTE RÉSEAU ET DU NOM D’HÔTE

Éditer le fichier « /etc/network/interfaces », commenter la ligne « source-directory » et ajouter les paramètres suivants pour configurer l’adresse IP de la carte réseau (à adapter en fonction de votre réseau local) :

auto eth0
iface eth0 inet static
address 192.168.0.X
netmask 255.255.255.0
gateway 192.168.0.254

Éditer ensuite le fichier « /etc/resolvconf/resolv.conf.d/base » en y ajoutant une adresse de serveur DNS (j’utilise ma box principalement pour ma part, suivi du DNS de Google) :

nameserver 192.168.0.254
nameserver 8.8.8.8

Éditer le fichier « /etc/hostname » et renseigner/modifier le nom court de la machine. Par exemple :

odroid

Éditer le fichier « /etc/hosts » puis renseigner cette fois le nom complet (FQDN) suivi du nom court de la machine. Ajouter une ligne avec l’adresse IP et à nouveau le nom complet et court du serveur. Commenter les lignes concernant IPv6. Par exemple :

127.0.0.1       localhost
127.0.0.1       odroid.home.org odroid
#::1            localhost ip6-localhost ip6-loopback
#ff02::1        ip6-allnodes
#ff02::2        ip6-allrouters

192.168.0.X     odroid.home.org odroid

Recharger la configuration pour prendre en compte les nouveaux paramètres :

$ resolvconf -u
$ service networking restart

Rebooter l’XU4 puis vérifier avec ifconfig que la nouvelle IP a bien été prise en compte :

$ ifconfig

CONFIGURATION DE L’ECRAN LCD ET DU VENTILATEUR

Ajouter le dépôt suivant :

add-apt-repository ppa:kyle1117/ppa

More info: https://launchpad.net/~kyle1117/+archive/ubuntu/ppa
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmp997cpxxq/secring.gpg' created
gpg: keyring `/tmp/tmp997cpxxq/pubring.gpg' created
gpg: requesting key 6AD57103 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmp997cpxxq/trustdb.gpg: trustdb created
gpg: key 6AD57103: public key "Launchpad PPA for KYLE LEE" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
OK

Puis installer les paquets suivants :

$ apt update
$ apt install odroid-cloudshell cloudshell2-fan

Rebooter :

$ reboot

L’écran devrait s’allumer au bout de quelques secondes et faire défiler les étapes de boot, puis le prompt de login au bout de quelques minutes. Le ventilateur devrait se mettre à tourner.

Il est possible d’éteindre l’écran LCD :

$ echo 1 | sudo tee /sys/class/backlight/*/bl_power

Et de le rallumer :

$ echo 0 | sudo tee /sys/class/backlight/*/bl_power

Il est possible d’installer des cripts permettant d’afficher des informations sur l’écran (charge CPU, température, etc) : https://wiki.odroid.com/accessory/add-on_boards/xu4_cloudshell2/xu4_cloudshell2#enable_lcd_and_fan

PRÉPARATION DES DISQUES

Il faut maintenant préparer les disques connectés à l’XU4. Le premier sera le disque de stockage principal du NAS et le second son backup.

Créer et formater une partition sur les disques

Repérer les disques avec fdisk :

$ fdisk -l
Disque /dev/sdb : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E41BAA80-43F3-445D-87AD-1E101807D99A

Périphérique Start Fin Secteurs Size Type
/dev/sdb1 2048 7814037134 7814035087 3,7T Linux filesystem


Disque /dev/sda : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs
Unités : sectors of 1 * 512 = 512 octets
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E9731481-0343-4B77-8BF4-98B85CA30EE6

Périphérique Start Fin Secteurs Size Type
/dev/sda1 2048 7814037134 7814035087 3,7T Linux filesystem

/dev/sda sera le disque principal. /dev/sdb sera le backup

Pour info dans le NAS, sda est le disque se situant en bas et sdb se situe en haut.

Utiliser « cfdisk » pour préparer le premier disque :

$ cfdisk /dev/sda

Avec l’utilitaire, supprimer toute partition qui pourrait déjà exister (option [Delete]) puis créer une nouvelle partition primaire (option [New]) de type 83 Linux (option [Type]). Valider les opérations par l’option [Write] puis quitter.

La partition a été créée. Il ne reste plus qu’à la formater en EXT4 avec la commande suivante :

$ mkfs.ext4 /dev/sda1

Donner un label (un nom) à ce disque afin qu’il soit plus facilement identifiable si vous inversez un jour la position des disques dans le NAS :

$ tune2fs -L "disk1" /dev/sda

Faire de même avec /dev/sdb (supprimer puis créer une nouvelle partition et lui donner le label « disk2 »)

Si besoin, blkid est capable de nous redonner le label des disques :

$ blkid

/dev/mmcblk1p1: SEC_TYPE="msdos" LABEL="boot" UUID="52AA-6867" TYPE="vfat" PARTUUID="3cedfd53-01"
/dev/mmcblk1p2: LABEL="rootfs" UUID="e139ce78-9841-40fe-8823-96a304a09859" TYPE="ext4" PARTUUID="3cedfd53-02"
/dev/sdb1: LABEL="disk2" UUID="20756356-5b84-43ee-a396-fad3ba5ea34c" TYPE="ext4" PARTUUID="f543fd74-dcc6-4318-bad0-21e8d6d508a6"
/dev/sda1: LABEL="disk1" UUID="94b4dc47-43ee-423c-a325-f1c2ae5e7495" TYPE="ext4" PARTUUID="e4192971-1e5f-45ec-af2f-60e5b5c9bcc3"
/dev/mmcblk1: PTUUID="3cedfd53" PTTYPE="dos"
Créer un montage permanent et automatique des disques

Repérer l’UUID de la partition préparée précédemment avec « blkid » :

$ blkid
/dev/mmcblk1p1: SEC_TYPE="msdos" LABEL="boot" UUID="52AA-6867" TYPE="vfat" PARTUUID="3cedfd53-01"
/dev/mmcblk1p2: LABEL="rootfs" UUID="e139ce78-9841-40fe-8823-96a304a09859" TYPE="ext4" PARTUUID="3cedfd53-02"
/dev/sdb1: LABEL="disk2" UUID="20756356-5b84-43ee-a396-fad3ba5ea34c" TYPE="ext4" PARTUUID="f543fd74-dcc6-4318-bad0-21e8d6d508a6"
/dev/sda1: LABEL="disk1" UUID="94b4dc47-43ee-423c-a325-f1c2ae5e7495" TYPE="ext4" PARTUUID="e4192971-1e5f-45ec-af2f-60e5b5c9bcc3"
/dev/mmcblk1: PTUUID="3cedfd53" PTTYPE="dos"
Copier les deux UUID puis éditer le fichier "/etc/fstab" en ajoutant les lignes suivantes (à adapter en fonction de vos UUID) :
UUID=94b4dc47-43ee-423c-a325-f1c2ae5e7495 /media/disque ext4 defaults 0 2
UUID=20756356-5b84-43ee-a396-fad3ba5ea34c /media/disque_sauvegarde ext4 defaults 0 2

Créer alors les répertoires de montage :

$ mkdir /media/disque
$ mkdir /media/disque_sauvegarde

Puis monter les partitions dans ces répertoires :

$ mount /media/disque
$ mount /media/disque_sauvegarde

Ici on peut redémarrer l’XU4 afin de vérifier que le montage s’effectue bien automatiquement. Exécuter la commande suivante qui liste tous les montages actifs et vérifier que « /dev/sda1 » est monté sur « /media/disque » et « /dev/sdb1 » est monté sur « /media/disque_sauvegarde » :

$ mount -l
[...]
/dev/sdb1 on /media/disque_sauvegarde type ext4 (rw,relatime,data=ordered) [disk2]
/dev/sda1 on /media/disque type ext4 (rw,relatime,data=ordered) [disk1]
[...]

A partir de là, c’est à vous de choisir quel(s) service(s)  vous souhaitez mettre en place sur votre XU4.

INSTALLATION DES SERVICES

SAMBA

La mise en place de Samba permet d’accéder aux fichiers stockés sur le disque principal depuis un PC Windows (ça marche aussi depuis un PC Linux). Personnellement, j’ai choisi de mettre en place la configuration suivante :

  • 1 répertoire « Partage » accessible à tous les PC du réseau local. Ce répertoire contiendrait par exemple des photos, de la musique, des films…
  • 1 répertoire « Perso » pour chaque utilisateur. L’utilisateur aura accès à son répertoire mais n’aura pas accès à celui des autres.

Créer un répertoire pour samba dans « /media/disque » :

$ mkdir /media/disque/samba

Puis créer le répertoire « Partage » ainsi que les répertoires perso de chaque utilisateur :

$ mkdir /media/disque/samba/Partage
$ mkdir /media/disque/samba/toto
$ mkdir /media/disque/samba/titi
...

Installer Samba et ses outils de test :

$ apt install samba samba-testsuite

Samba crée par défaut un groupe « sambashare ». Attribuer les droits suivants au répertoire précédemment créé :

$ chown root:sambashare /media/disque/samba
$ chmod 550 /media/disque/samba

Passons à la conf. Faire une sauvegarde du fichier « /etc/samba/smb.conf » :

$ cp /etc/samba/smb.conf /etc/samba/smb.conf.old

Éditer « /etc/samba/smb.conf  » et ajouter la conf suivante :

#======================= Global Settings =======================

[global]
workgroup = WORKGROUP
netbios name = NAS
server string = %h server (Samba, Ubuntu)
security = user
dns proxy = no
log level = 2
log file = /var/log/samba/samba.log
max log size = 50
  

#======================= Share Definitions =======================
# Répertoire perso de chaque utilisateur. 
[Perso]
comment = Repertoire Perso
# Si l'utilisateur s'appelle toto, alors son répertoire perso sera /media/disque/samba/toto grâce à la variable %u:
path = /media/disque/samba/%u
browseable = yes
public = no
writeable = yes
create mask = 0700
directory mask = 0700
printable = no

# Répertoire de partage entre utilisateurs 
[Partage]
comment = Repertoire Partage
path = /media/disque/samba/Partage
browseable = yes
public = no
writeable = yes
create mask = 0770
directory mask = 0770
force group = sambashare
printable = no

Enregistrer puis tester les paramètres avec la commande suivante :

$ testparm -s

La commande ne doit pas renvoyer d’erreurs, sinon vérifier la configuration.

Redémarrer samba :

$ /etc/init.d/samba restart

Pour créer un utilisateur Samba, il faut qu’un utilisateur Linux du même nom existe. Créer par exemple un utilisateur « toto » Linux qui fera partie du groupe « sambashare » (juste un truc avant de valider, prenez le temps de lire le « Conseil » juste un peu plus bas, ça peut être utile) :

$ useradd -s /usr/sbin/nologin -G sambashare toto  # ici on crée un utilisateur toto, membre du groupe sambashare et n'ayant aucun home directory sur le NAS ni aucun accès au shell

Créer un mot de passe pour cet utilisateur :

$ passwd toto

L’utilisateur Linux est prêt, créer ensuite l’utilisateur Samba du même nom :

$ smbpasswd -a toto

Appliquer les droits suivants :

$ chown -R root:sambashare /media/disque/samba/Partage
$ chmod -R 770 /media/disque/samba/Partage

$ chown -R toto:root /media/disque/samba/toto
$ chmod -R 700 /media/disque/samba/toto

$ chown -R titi:root /media/disque/samba/titi
$ chmod -R 700 /media/disque/samba/titi

Lors de l’accès aux répertoires « Perso » et « Partage » depuis Windows, un nom d’utilisateur et un mot de passe sera demandé. Utiliser alors l’utilisateur et le mot de passe samba créé pour cet utilisateur (et non le mot de passe Linux, à moins qu’il ne soient identiques).

Conseil : le plus pratique ici est de créer un utilisateur Linux possédant le même nom d’utilisateur que celui de la session Windows. Puis créer un utilisateur Samba possédant le même mot de passe que celui de la session Windows. Ainsi, plus besoin de taper de mot de passe lors du montage des partages Samba sous Windows, puisque ce dernier va par défaut tenter de se loguer en utilisant l’utilisateur et le mot de passe de la session en cours. Je reformule avec un exemple pour être plus clair :

Sous Windows mon login/mdp est : Toto/123456

Sur mon NAS, je vais donc créer :

  • Un utilisateur Linux « Toto » (bien respecter la casse) avec mdp « 123456 »
  • Un utilisateur samba avec smbpasswd « Toto » (bien respecter la casse) et mot de passe « 123456 »

Ainsi sur mon PC Windows, quand j’accède à « Partage » ou à mon répertoire perso sur le NAS, je serai identifié automatiquement, car par défaut Windows va tenter de s’authentifier avec mon couple login/mdp de ma session (Toto/123456) et cela matchera avec l’utilisateur samba créé précédemment. Pratique pour ne pas devoir rentrer son mot de passe à chaque accès.

Performances :

Comme annoncé par Hardkernel, les débits offerts par cette carte mère sur un partage Samba sont assez impressionnants et sont en moyenne de 80 Mo/s en copie (parfois des pics à 90 Mo/s). De mon PC vers le NAS (on constate la bonne stabilité) :

capture

L’opération inverse offre les même débits à quelque chose près.

OWNCLOUD

Pour accéder à mes fichiers depuis Internet et les partager, j’ai choisi la solution ownCloud. Il va donc falloir installer un serveur web et php.

INSTALLATION DE LEMP (NGINX, MYSQL, PHP)

LEMP n’est pas un paquet à proprement parler. C’est la désignation d’un ensemble de logiciels open source permettant de créer un serveur web : Linux EngineX (aka Nginx) MySQL, PHP.

Notre Linux est prêt, alors continuons à installer et configurer les derniers composants du serveur LEMP.

V.2.1.1. PHP/MySQL

Installer les paquets suivants pour  PHP et MySQL et autres dépendances d’owncloud  :

$ apt install mysql-server php7.0-mysql php7.0-fpm php7.0-gd php7.0-json php7.0-curl php7.0-intl php7.0-mcrypt php-imagick php7.0-zip php7.0-xml php7.0-mbstring

MySQL demandera si l’on souhaite changer le mot de passe de l’utilisateur root pour MySQL. Changer ce mot de passe en optant pour quelque chose de sécurisé.

Puis terminer l’installation en lançant le script suivant :

$ /usr/bin/mysql_secure_installation

Il sera demandé le mot de passe « root » de MySQL. Puis il sera demandé si l’on souhaite changer ce mot de passe. Taper « N », nous l’avons déjà changé précédemment :

Change the root password? [Y/n] N

Répondre ‘Y’ aux questions suivantes :

Par défaut, MySQL crée un utilisateur « anonymous » permettant à quiconque de se connecter à MySQL sans compte attitré. Répondre « Y » à la question suivante pour supprimer cet utilisateur :

Remove anonymous users? [Y/n] Y
 ... Success!

La question suivante demande si l’on veut autoriser « root » à se connecter à MySQL depuis une machine distante (c’est à dire différente de « localhost »). Par principe de sécurité, on choisi de ne pas autoriser ce type de connexion en répondant par « Y » :

Disallow root login remotely? [Y/n] Y
 ... Success!

Par défaut, MySQL crée une base de données « test » accessible à tout le monde. Répondre « Y » à la question suivante pour supprimer cette base de données :

Remove test database and access to it? [Y/n] Y
 - Dropping test database...
ERROR 1008 (HY000) at line 1: Can't drop database 'test'; database doesn't exist
... Failed!  Not critical, keep moving...
- Removing privileges on test database...
... Success!

Appliquer les changements en répondant « Y » à la question suivante :

Reload privilege tables now? [Y/n] Y
 ... Success!

Cleaning up...


All done!  If you've completed all of the above steps, your MySQL
installation should now be secure.

Thanks for using MySQL!

V.2.1.2. Nginx

Poursuivre par l’installation de Nginx :

$ apt install nginx -y

Démarrer Nginx :

$ service nginx start

Il est alors possible de vérifier le bon fonctionnement depuis un navigateur à l’adresse http://192.168.0.X (IP du NAS) . Le serveur doit renvoyer sa page par défaut « Welcome to nginx ».

CONFIGURATION
Configurer PHP-FPM

Éditer le fichier « /etc/php/7.0/fpm/php.ini » et rechercher (ECHAP puis /marecherche sous vim) la ligne « cgi.fix_pathinfo=1 ». Pour ma part, celle-ci était commentée d’une dièse. Dé-commenter cette ligne et passer sa valeur à 0 afin d’empêcher toute exécution de code malveillant lorsque PHP tente de corriger un chemin non trouvé :

cgi.fix_pathinfo=0

Puis rechercher et modifier les lignes suivantes afin d’augmenter la limite d’upload et le timeout :

post_max_size = 5G # Définit la taille maximale des données reçues par la méthode POST. Ici fixée à 5Go.
upload_max_filesize = 5G # Définit la taille maximale d'un fichier à charger. Ici fixée à 5Go. 
default_charset = "UTF-8" # Dé-commenter cette ligne
[...]
max_input_time 3600 
max_execution_time 3600

Éditer le fichier « /etc/php/7.0/fpm/pool.d/www.conf » puis commenter (attention il faut commenter avec un point virgule dans ce fichier) et ajouter une ligne tel que :

;listen = /run/php/php7.0-fpm.sock
listen = 127.0.0.1:9000

Redémarrer PHP-FPM :

$ service php7.0-fpm restart
Réserver un nom de domaine

Si vous mettez en place ownCloud, c’est que vous souhaitez pouvoir accéder à votre NAS depuis l’extérieur. De préférence il vous faudra donc un nom de domaine. Ce n’est pas obligatoire, mais c’est plus propre que de devoir taper votre IP publique dans le navigateur. De plus il existe des noms de domaines gratuits qui prennent en compte les changements d’adresse IP de votre box. Le plus connu étant www.noip.com.

Personnellement j’ai acheté un nom de domaine chez OVH pour 0.99€/an avec l’extension .ovh mais je vous montre un exemple de configuration avec www.noip.com si vous ne voulez vraiment pas y mettre un rond.

No-IP

Créer un compte sur www.noip.com. Accéder au menu « Hostnames », puis ajouter un nouveau nom de domaine en cliquant sur « Add Hostname » :

noip01

noip02

Choisir un nom et un domaine qui vous convient, par exemple :

La prise en compte est immédiate.

Il reste alors à configurer la box Internet pour qu’elle envoie régulièrement sa nouvelle adresse IP publique à No-IP. Exemple avec une Freebox :

Accéder aux paramètres :

freebox01

Passer en mode avancé puis aller dans « DNS Dynamique » :

freebox02

Activer No-IP puis renseigner le nom d’utilisateur et le mot de passe du compte No-IP ainsi que le nom de domaine configuré :

Passer ensuite dans l’onglet « Gestion des ports » :

gestion_ports_01

Ajouter deux redirections vers l’XU4 :

  • une pour le port 80
  • une autre pour le port 443

Avec cette configuation, les requêtes HTTP et HTTPS sur le nom de domaine que vous avez choisi seront redirigées vers l’XU4.

OVH

Si vous choisissez un nom de domaine OVH, il vous faudra dans un premier temps ajouter un DynHost puis créer un couple login/mdp à renseigner ensuite dans l’interface de la Freebox, onglet DNS Dynamique) :

Configurer Nginx (config générale)

Continuons par la configuration de Nginx, éditer le fichier de config générale « /etc/nginx/nginx.conf » et ajouter/vérifier les paramètres suivants :

user www-data;
worker_processes auto;
pid /run/nginx.pid;


events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:';
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:10m;   

    ## 
    # X-XSS Protection header 
    ##

    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    
    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/nginx_access.log;
    error_log /var/log/nginx/nginx_error.log;

    ##
    # Gzip Settings
    ##

    gzip off;
    gzip_disable "msie6";

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/sites-enabled/*.conf;
}

Créer le répertoire de logs s’il n’existe pas déjà :

$ mkdir /var/log/nginx

On est bon pour la conf générale, passons aux Vhosts.

Configurer Nginx (Vhost :80)

La déclaration et la configuration de Vhosts s’effectue dans deux répertoires :

sites-available : qui contient les fichiers de configuration des Virtualhosts. Les fichiers stockées ici ne sont pas automatiquement pris en compte.

sites-enabled : contient des liens symboliques vers les fichiers de sites-available. Une fois le lien symbolique ajouté, le fichier est pris en compte et le site est activé.

Par défaut, Nginx génère un fichier « default » dans « /etc/nginx/sites-available ». On va supprimer ce fichier :

$ cd /etc/nginx/sites-available
$ rm default -f

A partir d’ici, deux configurations possibles :

  • Cas 1 : Accéder à owncloud depuis un sous-domaine, ex : https://owncloud.mondomaine.com
  • Cas 2 : Accéder à owncloud depuis un sous-répertoire, ex : https://mondomaine.com/owncloud

Créer un nouveau fichier et entrer les paramètres suivants en fonction du cas choisi et en adaptant votre nom de domaine :

Cas 1 Cas 2
$ vim owncloud.mondomaine.ovh.conf


upstream php-handler {
  server 127.0.0.1:9000;
}

server {
  listen 80;
  server_name owncloud.mondomaine.ovh;
  root /var/www/owncloud;
  # Forcer https ; on laisse ce paramètre commenté pour le moment
  # return 301 https://$server_name$request_uri;

  access_log /var/log/nginx/owncloud.mondomaine.ovh_access.log;
  error_log /var/log/nginx/owncloud.mondomaine.ovh_error.log;
}
$ vim mondomaine.ovh.conf


upstream php-handler {
  server 127.0.0.1:9000;
}

server {
  listen 80;
  server_name mondomaine.ovh;
  root /var/www;
  # Forcer https ; on laisse ce paramètre commenté pour le moment
  # return 301 https://$server_name$request_uri;

  access_log /var/log/nginx/mondomaine.ovh_access.log;
  error_log /var/log/nginx/mondomaine.ovh_error.log;
}

Créer un lien symbolique dans sites-enabled afin d’activer la configuration effectuée puis redémarrer Nginx :

$ cd /etc/nginx/sites-enabled
$ ln -s ../sites-available/owncloud.mondomaine.ovh.conf (pour le cas 1)
$ ln -s ../sites-available/mondomaine.ovh.conf (pour le cas 2)
$ service nginx restart

C’est le strict minimum pour le moment. On a ici un Vhost qui écoute sur le port 80. Nous ajouterons un second Vhost qui écoutera sur le port 443 (HTTPS) lorsque nous aurons un certificat SSL. Nous allons donc faire une demande de certificat avant de compléter la conf Nginx.

Certificat SSL Let’s Encrypt

Maintenant qu’on a un nom de domaine sympa, il va falloir préparer de quoi sécuriser les échanges sur ownCloud, c’est à dire chiffrer les communications avec un certificat.

Pour cela, on va utiliser Let’s Encrypt qui est une autorité de certification reconnue par les navigateurs modernes et qui propose de signer des certificats gratuitement pour une durée de 3 mois, suite à quoi il faut renouveler le certificat.

Créer un répertoire « /etc/letsencrypt » dans lequel on installera le client certbot-auto de Let’s Encrypt :

$ mkdir /etc/letsencrypt && cd /etc/letsencrypt
$ wget https://dl.eff.org/certbot-auto

Puis exécuter le client certbot-auto avec le paramètre –nginx pour lancer la demande de certificat :

$ cd /etc/letsencrypt
$ chown root:root certbot-auto && chmod 770 certbot-auto
$ ./certbot-auto --nginx

Let’s Encrypt va rechercher les Vhosts accessibles sur le serveur et demandera pour lequel on souhaite générer un certificat (exemple ci-dessous du cas 1 avec le sous-domaine « owncloud. »). Le script proposera ensuite de générer pour nous la configuration du Vhost 443, on refuse par « c » car nous allons nous même le configurer plus bas.

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: owncloud.mondomaine.ovh
2: un-autre-domaine.fr
3: toto.domaine.org
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):1
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for owncloud.mondomaine.ovh
Generating key (1024 bits): /var/lib/letsencrypt/snakeoil/0000_key.pem
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0008_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0008_csr-certbot.pem
Generating key (1024 bits): /var/lib/letsencrypt/snakeoil/0001_key.pem
Deployed Certificate to VirtualHost /etc/nginx/sites-enabled/owncloud.mondomaine.ovh.conf for set(['owncloud.mondomaine.ovh'])

Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): c

-------------------------------------------------------------------------------
Congratulations! You have successfully enabled https://owncloud.mondomaine.ovh

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=owncloud.mondomaine.ovh
-------------------------------------------------------------------------------

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/owncloud.mondomaine.ovh/fullchain.pem. Your cert will
   expire on 2017-06-26. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot-auto again with the
   "certonly" option. To non-interactively renew *all* of your
   certificates, run "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Les certificats sont stockés dans /etc/letsencrypt/live/owncloud.mondomaine.ovh/

Ajouter une tâche cron dans lequelle on lancera la commande de renouvellement automatique des certificats (pour ma part je lance ça tous les jours à minuit) suivi du redémarrage de nginx pour prise en compte d’un éventuel nouveau certificat :

$ crontab -e
0 0 * * * /etc/letsencrypt/certbot-auto renew && service nginx restart

Il est d’ailleurs possible de tester un renouvellement automatique : le client certbot vérifiera la date du certificat en cours et estimera s’il faut ou non le renouveler :

$ /etc/letsencrypt/certbot-auto renew
The following certs are not due for renewal yet:
  /etc/letsencrypt/live/owncloud.mondomaine.ovh/fullchain.pem (skipped)
No renewals were attempted.

Ci-dessus, le client considère que le certificat n’a pas encore atteint une date proche de l’expiration, du coup il ne fait rien. Il me semble que le renouvellement s’effectue à 30 jours de l’expiration. A vérifier dans 2 mois donc.

On va pouvoir poursuivre la configuration de Nginx en créeant un nouveau Vhost pour la conf HTTPS.

Configurer Nginx – suite (Vhost :443)

D’abord, dans le Vhost:80, dé-commenter la redirection vers HTTPS, ainsi que les éventuels ajouts du certbot de Let’s Encrypt (il est possible qu’il ait ajouté des paramètres malgré tout) :

return 301 https://$server_name$request_uri;

Puis de même, selon le cas, créer un nouveau fichier qui contiendra la conf pour HTTPS + un include de la conf owncloud (qui sera écrite dans un fichier différent que nous verrons plus bas) :

Cas 1 Cas 2
$ vim owncloud.mondomaine.ovh_https.conf

https://www.inzecloud.net/index.php/vhost-ssl-cas-1/

$ vim mondomaine.ovh_https.conf

https://www.inzecloud.net/index.php/vhost-ssl-cas-2/

A ce stade nous avons donc un Vhost qui écoute sur le port 80 et qui redirige aussitôt le navigateur du client vers la version HTTPS du site, du coup nous avons un second Vhost plus complet qui écoute sur le port 443 et qui contient tout un tas d’options de sécurité. Nous allons créer des pages d’erreurs personnalisées pour gérer les erreurs communes (404, 500, 503…). L’interêt de ces pages custom est qu’elles n’afficheront pas les versions de Nginx et de l’OS contrairement à celles implémentées par défaut.

Créer le répertoire qui contiendra les pages d’erreurs customisées :

$ mkdir /var/www/custom_errors

Puis créer deux nouvelles pages HTML pour gérer les erreurs 404 et 50x (un seul fichier pour tous les types d’erreurs 500) :

$ cd /var/www/custom_errors
$ echo "<h1>Error 404: Not found</h1>" > custom_404.html
$ echo "<h1>Oops! Something went wrong...</h1>" > custom_50x.html
$ chown -R www-data:www-data /var/www/custom_errors
$ chmod -R 750 /var/www/custom_errors

Passons ensuite à la config pour ownCloud.

Se placer dans le répertoire « conf.d » et éditer un nouveau fichier :

$ cd /etc/nginx/conf.d
$ vim owncloud
Cas 1 Cas 2
https://www.inzecloud.net/index.php/vhost-ssl-config-owncloud-cas-1/  https://www.inzecloud.net/index.php/vhost-ssl-config-owncloud-cas-2/

Créer un lien symbolique dans sites-enabled cette fois pour activer la configuration du vhost HTTPS :

$ cd /etc/nginx/sites-enabled
$ ln -s ../sites-available/owncloud.mondomaine.ovh_https.conf (pour le cas 1)
$ ln -s ../sites-available/mondomaine.ovh_https.conf (pour le cas 2)

Redémarrer Nginx :

$ service nginx restart

A partir d’ici, vous devriez avoir un serveur fonctionnel et sécurisé. Un test sur SSLLABS renvoie le résultat « A+ » : https://www.ssllabs.com/ssltest/analyze.html?d=owncloud.mondomaine.ovh&hideResults=on&latest

INSTALLER OWNCLOUD

Un serveur web c’est cool mais sans contenu ça sert à rien, donc c’est parti pour l’install d’ownCloud

Ajouter les dépôts pour ownCloud :

$ apt install apt-transport-https
$ echo 'deb https://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/ /' >> /etc/apt/sources.list.d/owncloud.list
$ wget -nv http://download.owncloud.org/download/repositories/stable/Ubuntu_16.04/Release.key -O Release.key
$ apt-key add - < Release.key
$ rm Release.key

Mettre à jour la liste des paquets :

$ apt update

Installer ownCloud :

$ apt install owncloud-files

Appliquer les droits suivants sur le répertoire d’installation d’ownCloud :

$ chown -R www-data:www-data /var/www/owncloud
$ chmod -R 750 /var/www/owncloud

Se connecter à MySQL en tant que root :

$ mysql -u root -p

Lorsque le prompt « mysql » apparait, créer une nouvelle base de données pour ownCloud. On pourra appeler celle-ci « owncloud » par exemple :

mysql> CREATE DATABASE owncloud;
Query OK, 1 row affected (0.00 sec)

Créer un nouvel utilisateur afin de pouvoir se connecter à cette base de données. On pourra également appeler cet utilisateur « owncloud » par exemple. Renseigner également son mot de passe dans la commande :

mysql> GRANT ALL PRIVILEGES ON owncloud.* TO 'owncloud'@'localhost' IDENTIFIED BY 'password'; (remplacer password par le mot de passe de votre choix)
Query OK, 0 rows affected (0.00 sec)

Appliquer les changements :

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

Puis quitter MySQL :

mysql> exit;
Bye

Voilà ! Il est temps de se connecter à ownCloud depuis un navigateur à l’adresse https://owncloud.mondomaine ou https://mondomaine/owncloud

ownCloud demande encore quelques infos pour terminer son installation. Renseigner un nom d’utilisateur afin de créer un compte administrateur. Faire dérouler le menu « Stockage & base de données », choisir « MySQL/MariaDB », renseigner le nom d’utilisateur « owncloud » créé précédemment pour l’occasion et son mot de passe associé ainsi que le nom de la base de données d’ownCloud (« owncloud »), puis cliquer sur « Terminer l’installation » :

CHANGER L’EMPLACEMENT DE STOCKAGE DES DONNÉES

Puisqu’on veut que nos données soient stockées sur le disque de l’XU4, il va falloir changer l’emplacement de stockage des données dans ownCloud. Il suffit de déplacer le répertoire « data » situé dans « /var/www/owncloud » vers le nouvel emplacement.

Arrêter Nginx :

$ service nginx stop

Déplacer les données vers le nouvel emplacement :

$ mv /var/www/owncloud/data /media/disque/

Appliquer les droits suivants sur le nouvel emplacement :

$ chown -R www-data:www-data /media/disque/data
$ chmod -R 750 /media/disque/data

Éditer le fichier « /var/www/owncloud/config/config.php » et modifier la ligne « datadirectory » en indiquant le nouvel emplacement :

'datadirectory' => '/media/disque/data',

Enregistrer puis redémarrer Nginx :

$ service nginx restart
RÉSOUDRE LES ERREURS DE LA PAGE D’ADMINISTRATION D’OWNCLOUD

Dans la page d’administration, ownCloud effectue un certain nombre de tests de conf et de sécurité qui peuvent retourner des erreurs :

  • « Aucun cache de la mémoire n’est configuré. Si possible, configurez un « memcache » pour augmenter les performances. Pour plus d’information consultez la documentation » :

Dans ce cas, il faut mettre en place un moteur de cache. Pour ce type d’installation,  APCu est recommandé (pour + d’infos : https://doc.owncloud.org/server/8.1/admin_manual/configuration_server/caching_configuration.html)

Ajouter le dépôt Xenial Universe :

$ echo 'deb http:// xenial main universe' >> /etc/apt/sources.list

Mettre à jour la liste des paquets et installer APCu :

$ apt update
$ apt install php-apcu

Éditer le fichier « /var/www/owncloud/config/config.php » et ajouter la ligne suivante :

'memcache.local' => '\OC\Memcache\APCu',

Redémarrer PHP et Nginx :

$ service php7.0-fpm restart && service nginx restart

Recharger la page d’administration ownCloud et vérifier que l’avertissement a disparu.

  • « php ne semble pas être configuré de manière à récupérer les valeurs des variables d’environnement. Le test de la commande getenv(« PATH ») retourne seulement une réponse vide.[…] » :

Éditer le fichier « /etc/php/7.0/fpm/pool.d/www.conf » et dé-commenter la ligne suivante :

env[PATH] = /usr/local/bin:/usr/bin:/bin

Redémarrer PHP et Nginx :

$ service php7.0-fpm restart
  • Plus bas dans la page d’administration, les tâches automatiques de Cron sont en erreurs (rond rouge) :

Pour son bon fonctionnement ownCloud a besoin que certaines tâches soient exécutées automatiquement (actualisation, nettoyage de BDD…). La méthode recommandée est d’utiliser Cron plutôt qu’Ajax (qui peut surcharger le serveur). Pour cela, mettre en place une tâche dans la crontab de l’utilisateur www-data :

$ crontab -u www-data -e

Puis ajouter la ligne suivante qui programme la tâche toutes les 15 minutes et sauvegarder :

*/15  *  *  *  * php -f /var/www/owncloud/cron.php

PHPMYADMIN (optionnel)

Personnellement, j’aime bien avoir une interface graphique pour mieux visualiser mes bases de données et mes utilisateurs MySQL. J’installe donc PhpMyAdmin :

$ apt install phpmyadmin

PhpMyAdmin n’est pas installé dans le même répertoire racine qu’ownCloud :

  • ownCloud : /var/www
  • PhpMyAdmin : /usr/share

Or dans la config pour Nginx, le répertoire racine a été défini sur « /var/www ». Le plus simple est de créer un lien symbolique :

$ ln -s /usr/share/phpmyadmin /var/www/phpmyadmin

Appliquer les droits suivants :

$ chown -R www-data:www-data /var/www/phpmyadmin
$ chmod -R 750 /var/www/phpmyadmin

Créer un nouveau fichier « phpmyadmin » dans « /etc/nginx/conf.d » avec les paramètres suivants :

### Config PHPMYADMIN ###

  location /phpmyadmin {
    index index.php index.html index.htm;
    location ~ ^/phpmyadmin/(.+\.php)$ {
      try_files $uri =404;
      root /var/www;
      fastcgi_pass php-handler;
      fastcgi_param HTTPS on;
      fastcgi_index index.php;
      fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
      include /etc/nginx/fastcgi_params;
    }
    location ~* ^/phpmyadmin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
      root /var/www/;
    }
  }
  location /phpMyAdmin {
    rewrite ^/* /phpmyadmin last;
  }

Puis appliquer cette config en ajoutant la ligne suivante dans « /etc/nginx/sites-available/owncloud.mondomaine.ovh.conf » :

include conf.d/phpmyadmin;

Redémarrer Nginx :

$ service nginx restart

PhpMyAdmin est alors accessible à l’adresse suivante : https://owncloud.mondomaine.ovh/phpmyadmin

MONTAGE DES PARTAGES SAMBA DANS OWNCLOUD

ownCloud possède un plug-in officiel permettant de monter des lecteurs ou services via différents protocoles, et notamment SMB/CIFS utilisé par Samba. Ce plug-in nécessite que le paquet suivant soit installé :

$ apt install smbclient

Puis se loguer sur ownCloud avec un compte administrateur et se rendre dans le menu « Applications » (l’apparence de l’interface a pu changer depuis) :

owncloud_app01

Puis simplement activer le plug-in « External storage support » :

owncloud_app02

Une nouvelle catégorie « Stockage externe » apparait alors sur la page d’administration, c’est ici que l’on va monter les partages Samba :

owncloud_app03

Libre à vous d’autoriser ou non les utilisateurs à ajouter des stockages externes en cochant ou décochant la case appropriée. Ajouter les partages créés précédemment dans le fichier de conf Samba en choisissant « SMB / CIFS » :

owncloud_app04

Une fois logué sous l’utilisateur à qui ont a rendu disponible les partages, les liens vers les partages montés apparaissent en page d’accueil ainsi qu’un nouveau menu « Stockage externe » sur la gauche contenant ces mêmes liens :

owncloud_app05

SAUVEGARDE ET RESTAURATION D’OWNCLOUD

SAUVEGARDE D’OWNCLOUD

ownCloud, c’est 3 points essentiels :

  • Le répertoire des sources : /var/www/owncloud,
  • La base de données ownCloud,
  • Le répertoire /media/disque/data qui contient tous les fichiers des utilisateurs.

Par précaution, arrêter les services nginx et php7.0-fpm :

$ service nginx stop
$ service php7.0-fpm stop

1. Créer une archive pour sauvegarder le répertoire des sources /var/www/owncloud. Puis copier cette archive vers un répertoire de sauvegarde (un emplacement réseau, une clé USB ou un disque dur externe par exemple) :

$ cd /var/www/
$ tar cvzf sauv_owncloud.tar.gz owncloud/
$ cp sauv_owncloud.tar /répertoire_de_sauvegarde

2. Sauvegarder la base de données (le mot de passe de l’utilisateur owncloud sera demandé) :

$ mysqldump --lock-tables -u owncloud -p owncloud > backup-bdd-owncloud.sql
# en bleu : nom de la base de données, à adapter si vous l'avez appelé autrement

3. Faire une sauvegarde du répertoire « data » sur un autre emplacement :

On peut faire une copie manuelle sur un autre emplacement à l’aide de la commande cp, scp, rsync, etc.. ou bien programmer des sauvegardes automatiques avec une tâche cron par exemple. Personnellement mon répertoire data se trouve dans « /media/disque » et j’ai donc une sauvegarde programmée toutes les nuits qui copie « /media/disque/data » et « /media/disque/samba » sur le second disque. J’explique tout cela dans l’avant dernière partie du tutoriel.

RESTAURATION D’OWNCLOUD

Si votre ownCloud crash, il est possible de le restaurer rapidement à condition d’avoir sauvegardé les 3 points essentiels précédents (du moins les fichiers sources et la BDD).

1. Restaurer les fichiers sources : supprimer au préalable l’ancien répertoire à restaurer :

$ rm /var/www/owncloud -rvf

Puis dézipper l’archive « sauv_owncloud.tar.gz » dans le répertoire « /var/www/ ». Cela copiera le répertoire « /var/www/owncloud » contenant les fichiers de config fonctionnels issus de votre précédente sauvegarde :

$ cd /var/www/
$ tar xvzv sauv_owncloud.tar.gz

Rétablir les bons droits.

2. Restaurer la base de données : utiliser la commande suivante pour restaurer une sauvegarde de la base de données (le mot de passe de l’utilisateur owncloud sera demandé) :

$ mysql -u owncloud -p owncloud < backup-bdd-owncloud.sql
# en bleu : nom de la base de données, à adapter si vous l'avez appelé autrement

3. Restaurer le répertoire data : copier la sauvegarde du répertoire « data » au bon endroit (pour ma part /media/disque/data).

Plus d’infos : https://doc.owncloud.org/server/10.0/admin_manual/maintenance/restore.html

MISE A JOUR D’OWNCLOUD

La mise à jour d’ownCloud peut se faire de deux manières différentes :

  • Via l’interface Web
  • Ou via le gestionnaire de paquets (recommandé)

Dans tous les cas, il est fortement recommandé de faire une sauvegarde d’ownCloud et de la base de données avant de se lancer dans une mise à jour. C’est le seul moyen de restaurer rapidement une config si ça venait à planter.

Interface Web

L’interface Web qui indique la présence d’une nouvelle mise à jour en faisant apparaitre un bandeau jaune lors de la connexion d’un compte administrateur :

owncloud_maj01

Pour activer ce type d’alerte, il faut rajouter la ligne suivante à la suite dans « /var/www/owncloud/config.config.php » :

'updater.server.url' => 'https://updates.owncloud.com/server/',

Se rendre alors sur la page d’administration, onglet « Mise à jour » et lancer tout simplement la mise à jour (cependant je recommande plutôt la mise à jour via le gestionnaire de paquets apt, voir plus bas) :

owncloud_maj02owncloud_maj03

La page sera rafraichie automatiquement et renverra le message suivant :

owncloud_maj04

Conseil : préférer l’utilisation des lignes de commandes pour démarrer la mise à jour tel que décrit à la fin du message. Cela permet d’éviter les timeout et par conséquent de tout défoncer (ça m’est arrivé 9 fois sur 10). De plus cela permet de voir réellement ce qu’il se passe. Pour cela, se rendre dans le répertoire d’installation :

$ cd /var/www/owncloud

Puis rendre exécutable le script PHP suivant :

$ chmod +x occ

Ce script doit être exécuté par www-data, par conséquent on le précise dans la commande suivante :

$ sudo -u www-data ./occ upgrade
ownCloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Set log level to debug - current level: 'Debug'
Turned on maintenance mode
Checking whether the database schema can be updated (this can take a long time depending on the database size)
Checked database schema update
Checking updates of apps
Checking whether the database schema for <activity> can be updated (this can take a long time depending on the database size)
Checking whether the database schema for <files_sharing> can be updated (this can take a long time depending on the database size)
Checking whether the database schema for <files_trashbin> can be updated (this can take a long time depending on the database size)
Checked database schema update for apps
Updating database schema
Updated database
Disabled 3rd-party app: files_locking
Updating <files_texteditor> ...
Updated <files_texteditor> to 2.0
Updating <gallery> ...
Updated <gallery> to 14.2.0
Updating <files> ...
Updated <files> to 1.2.1
Updating <activity> ...
Updated <activity> to 2.1.4
Updating <files_external> ...
Updated <files_external> to 0.3.0
Updating <files_sharing> ...
Updated <files_sharing> to 0.7.0
Updating <files_trashbin> ...
Updated <files_trashbin> to 0.7.0
Updating <files_versions> ...
Updated <files_versions> to 1.1.0
Updating <provisioning_api> ...
Updated <provisioning_api> to 0.3.0
Update successful
Turned off maintenance mode
Reset log level to 'Debug'

La base de donnée puis les différentes applications sont mis à jour. Une fois terminé, rafraichir la page ownCloud et se connecter.

Gestionnaire de paquets

Si le paquet « owncloud-files » apparait lorsque vous exécutez apt upgrade, c’est qu’une mise à jour d’ownCloud est disponible. Installer ce paquet puis terminer la mise à jour en exécutant occ dans « /var/www/owncloud » tel que décrit ci-dessus.

RESET D’OWNCLOUD

Pour repartir d’une conf toute neuve en conservant les fichiers des utilisateurs.

Dans PhpMyAdmin : supprimer les utilisateurs liés à ownCloud dans « Utilisateurs », puis supprimer la base de données ownCloud :

phpmyadmin_01phpmyadmin_02

phpmyadmin_03

Dans « /var/www/owncloud/config/ », supprimer le fichier config.php :

$ rm /var/www/owncloud/config/config.php

Recréer la base avec les commandes suivantes. Se connecter à MySQL en tant que root :

$ mysql -u root -p

Lorsque le prompt « mysql » apparait, créer une nouvelle base de données pour ownCloud. On pourra appeler celle-ci « owncloud » par exemple :

mysql> CREATE DATABASE owncloud;
Query OK, 1 row affected (0.00 sec)

Créer un nouvel utilisateur afin de pouvoir se connecter à cette base de données. On pourra également appeler cet utilisateur « owncloud » par exemple. Renseigner également son mot de passe dans la commande :

mysql> GRANT ALL PRIVILEGES ON owncloud.* TO 'owncloud'@'localhost' IDENTIFIED BY 'password'; (remplacer password par le mot de passe de votre choix)
Query OK, 0 rows affected (0.00 sec)

Appliquer les changements :

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

Puis quitter MySQL :

mysql> exit;
Bye

Retourner sur la page d’accueil ownCloud et créer un utilisateur administrateur de la même manière que la première installation.

Les utilisateurs devraient retrouver leurs fichiers.

Éditer le fichier /var/www/owncloud/config/config.php et rajouter les lignes pour configurer le cache et les domaines approuvés (voir tuto d’installation et de configuration ownCloud).

SERVEUR DLNA

Pour que la lecture de musiques, vidéos et photos depuis le Freebox Player soit possible, il faut passer par un serveur DLNA/UPnP tel que miniDLNA ou MediaTomb. MediaTomb étant très complexe, j’ai choisi miniDLNA pour sa facilité de configuration.

Installer miniDLNA :

$ apt install minidlna

Éditer le fichier « /etc/default/minidlna » et entrer les paramètres suivants :

# Defaults for minidlna initscript
# sourced by /etc/init.d/minidlna
# installed at /etc/default/minidlna by the maintainer scripts

# These options can be set to modify the behavior of the minidlna init script.
# The options commented out show the default values.

# Start the daemon if set to "yes"
START_DAEMON="yes"

# Path to the configuration file
CONFIGFILE="/etc/minidlna.conf"

# Path to the log file
LOGFILE="/var/log/minidlna.log"

# User and group the daemon should run as
USER="minidlna" # le daemon sera lancé en tant qu'utilisateur minidlna
GROUP="sambashare" # et avec le groupe sambashare afin que le partage samba soit accessible pour minidlna

# Additional options that are passed to the daemon
DAEMON_OPTS=""

Puis éditer le fichier de configuration « /etc/minidlana.conf » et adapter la configuration afin que le serveur puisse accéder aux fichiers du partage Samba :

# This is the configuration file for the MiniDLNA daemon, a DLNA/UPnP-AV media
# server.
#
# Unless otherwise noted, the commented out options show their default value.
#
# On Debian, you can also refer to the minidlna.conf(5) man page for
# documentation about this file.

# Specify the user name or uid to run as.
user=minidlna

# Path to the directory you want scanned for media files.
#
# This option can be specified more than once if you want multiple directories
# scanned.
#
# If you want to restrict a media_dir to a specific content type, you can
# prepend the directory name with a letter representing the type (A, P or V),
# followed by a comma, as so:
#   * "A" for audio    (eg. media_dir=A,/var/lib/minidlna/music)
#   * "P" for pictures (eg. media_dir=P,/var/lib/minidlna/pictures)
#   * "V" for video    (eg. media_dir=V,/var/lib/minidlna/videos)
#   * "PV" for pictures and video (eg. media_dir=PV,/var/lib/minidlna/digital_camera)
# Répertoire de base :
media_dir=/media/disque/samba/Partage 

# Set this to merge all media_dir base contents into the root container
# (The default is no.)
# merge_media_dirs=no

# Path to the directory that should hold the database and album art cache.
db_dir=/etc/minidlna

# Path to the directory that should hold the log file.
log_dir=/var/log

# Type and minimum level of importance of messages to be logged.
#
# The types are "artwork", "database", "general", "http", "inotify",
# "metadata", "scanner", "ssdp" and "tivo".
#
# The levels are "off", "fatal", "error", "warn", "info" or "debug".
# "off" turns of logging entirely, "fatal" is the highest level of importance
# and "debug" the lowest.
#
# The types are comma-separated, followed by an equal sign ("="), followed by a
# level that applies to the preceding types. This can be repeated, separating
# each of these constructs with a comma.
#
# The default is to log all types of messages at the "warn" level.
log_level=general,artwork,database,inotify,scanner,metadata,http,ssdp,tivo=warn

# Use a different container as the root of the directory tree presented to
# clients. The possible values are:
#   * "." - standard container
#   * "B" - "Browse Directory"
#   * "M" - "Music"
#   * "P" - "Pictures"
#   * "V" - "Video"
#   * Or, you can specify the ObjectID of your desired root container
#     (eg. 1$F for Music/Playlists)
# If you specify "B" and the client device is audio-only then "Music/Folders"
# will be used as root.
# Je veut que le serveur affiche directement la racine du 
# répertoire /media/disque/samba/Partage :
root_container=B

# Network interface(s) to bind to (e.g. eth0), comma delimited.
# This option can be specified more than once.
# Interface réseau sur laquelle le serveur écoute :
network_interface=eth0

# Port number for HTTP traffic (descriptions, SOAP, media transfer).
# This option is mandatory (or it must be specified on the command-line using
# "-p").
# Le port utilisé par l'interface web, alors accessible à http://IP:8200 
port=8200

# URL presented to clients (e.g. http://example.com:80).
#presentation_url=/

# Name that the DLNA server presents to clients.
# Defaults to "hostname: username".
# Nom sous lequel le serveur apparaitra dans l'explorateur Windows ou 
# l'explorateur du Freebox Player :
friendly_name=Serveur Multimedia

# Serial number the server reports to clients.
# Defaults to 00000000.
serial=681019810597110

# Model name the server reports to clients.
#model_name=Windows Media Connect compatible (MiniDLNA)

# Model number the server reports to clients.
# Defaults to the version number of minidlna.
#model_number=

# Automatic discovery of new files in the media_dir directory.
# Afin que le serveur scan automatiquement les nouveaux fichiers :
inotify=yes

# List of file names to look for when searching for album art.
# Names should be delimited with a forward slash ("/").
# This option can be specified more than once.
# Le serveur considèrera les fichiers suivants comme étant des
# pochettes d'albums :
album_art_names=Cover.*/cover.*/AlbumArtSmall.jpg/albumartsmall.jpg/front.*/Front.*
album_art_names=AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg
album_art_names=Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg

# Strictly adhere to DLNA standards.
# This allows server-side downscaling of very large JPEG images, which may
# decrease JPEG serving performance on (at least) Sony DLNA products.
#strict_dlna=no

# Support for streaming .jpg and .mp3 files to a TiVo supporting HMO.
#enable_tivo=no

# Notify interval, in seconds.
# Intervalle de temps (en secondes) entre chaque scan de fichiers : 
notify_interval=3600

# Path to the MiniSSDPd socket, for MiniSSDPd support.
#minissdpdsocket=/run/minissdpd.sock

# Always set SortCriteria to this value, regardless of the SortCriteria
# passed by the client
# e.g. force_sort_criteria=+upnp:class,+upnp:originalTrackNumber,+dc:title
#force_sort_criteria=

# maximum number of simultaneous connections
# note: many clients open several simultaneous connections while streaming
# Nombre maximal de connexion simultanés : 
max_connections=20

Créer un répertoire « /etc/minidlna/ » dans lequel la base de données sera générée :

$ mkdir /etc/minidlna
$ chown minidlna:minidlna /etc/minidlna

Ajouter l’utilisateur « minidlna »au groupe sambashare afin qu’il puisse accéder au différents sous-répertoires dans « /media/disque/samba/ » :

$ usermod -G sambashare minidlna

Réinitialiser la base de données de miniDLNA et redémarrer le service :

$ minidlnad -R
$ /etc/init.d/minidlna restart

Il est alors possible de voir le nombre de fichiers scannés, les clients connectés et le nombre de fichiers qu’ils ont ouvert sur le serveur, depuis l’adresse suivante : http://adresse_IP:8200

SAUVEGARDE, SÉCURITÉ, MONITORING

Vous aimerez aussi...

43 réponses

  1. Tyron dit :

    Bonjour,
    Dans la section « INSTALLER OWNCLOUD », ne manque-t-il pas l’ajout du dépôt en lui-même? Il n’y a que l’ajout de la clef public (apt-key add) du dépôt..

    Cdt

  2. Henri dit :

    Bonjour,

    Merci pour ce tutoriel facile à suivre pour un débutant comme moi. Une petite question, quand j’arrive à la partie « SAMBA » et lorsqu’il faut modifier le fichier « smb.conf », j’y met les paramètres que vous indiquez (je ne fais que copier-coller à la fin du fichier). Puis quand je test sous Windows, je vois un partage qui s’appelle « ODROID », et dedans il y a effectivement deux partages bien appelés « Partage » et « Perso » mais ceux-ci sont vu comme des imprimantes, impossible d’y accéder. Je vais continuer à me renseigner sur le Net ça me parait étrange :s.

  3. Henri dit :

    Bon finalement c’est juste que je suis nul et re-nul, je n’avais pas créé de répertoire /samba/Partage | henri dans media/disque… Oui vous pouvez rire… Ça marche bien pour des fichiers solos mais pour des dossiers contenant des sous-dossiers l’utilisateur henri semble ne pas avoir les droits de copie, je pense comme ça crée de nouveaux dossiers sur le disque les droits récursifs ne sont plus appliqués même avec chmod -R sur le répertoire « Partage ».

  4. Henri dit :

    create mask = 660
    force create mode = 660
    security mask = 660
    force security mode = 660
    directory mask = 0770
    force directory mode = 0770
    directory security mask = 0770
    force directory security mode = 0770

    J’ai ajouté ça dans smb.conf comme dit ici http://askubuntu.com/questions/97669/i-cant-get-samba-to-set-proper-permissions-on-created-directories
    Ce sont les droits collés aux répertoires lorsqu’un utilisateur en crée dans le partage…

    Bon j’arrête de polluer votre bel article, merci encore pour le tuto je vais continuer !!!

  5. Henri dit :

    Bonjour, je reviens à la charge (oui votre tuto est dans mes favoris Chrome depuis au moins 1 mois).
    Pour avoir accès à Owncloud depuis l’extérieur, c’est assez bizarre, en local pas de soucis https://odroid.home.org/owncloud marche nickel.
    Mais après création de l’adresse ip chez noip et configuration sur la Freebox (exactement comme indiqué dans le tutoriel) aucun résultat, j’obtiens seulement une page avec « machin.truc.org a mis trop de temps à répondre. ».
    j’ai fait des tests, en re-dirigeant, via le firewall de la Freebox, le port 80 vers l’XU4, j’arrive à me connecter à nginx en faisant machin.truc.org:80, là j’arrive sur la page de base de Nging, donc accéder à l’XU4 depuis l’extérieur fonctionne. J’ai aussi été regarder les fichiers de log de owncloud, nginx, php5 etc. mais aucune erreur ne remonte.
    J’ai dû louper un truc :s.

  6. Henri dit :

    Bon bas en redirigeant le port 443 HTTPS et non 80 pour HTTP et en mettant https://machin.truc.org:443/owncloud ça fonctionne. J’apprend à apprendre avec ce tutoriel c’est top. Merci !

    • admin dit :

      Bonjour,
      Merci du retour, j’apprécie ce type de commentaire car cela me permet de déceler les erreurs et les oublis dans mon tutoriel et vous venez de soulever le point des redirections que j’ai oublié de mentionner dans ce tuto.
      Vous avez tout compris : il faut bien rajouter une redirection du port 443 pour que cela fonctionne. J’ajouterai que la redirection du port 80 est aussi utile car si vous omettez un jour d’ajouter le « s » à « http », cela ne vous renverra rien (car pas de redirection du port 80). Le début de la conf Nginx oblige le navigateur à utiliser https, donc si vous attaquez le site en http, vous passerez automatiquement en https. Essayez, ça devrait fonctionner, c’est ce que j’ai en place actuellement. Aussi vous pouvez vous affranchir de préciser les ports dans l’URL (:80 :443), ça fonctionne très bien sans.
      Merci du retour et n’hésitez pas à partager l’article à des personnes qui souhaiteraient mettre en place ce type de solution. Cet Odroid XU4 est vraiment un bon compromis et vaut bien la plupart des NAS grand public. De plus comme vous l’avez dit : il permet d’apprendre ! 🙂

      • Henri dit :

        J’ai testé de rediriger aussi le port 80 et effectivement ça fonctionne très bien sans avoir à ajouter le port après l’adresse, merci !
        En effet c’était pour apprendre que j’avais choisit cette solution plutôt qu’un Syno par exemple. Pour l’instant j’en suis carrément satisfait hormis quelques détails comme la vitesse quand je transferts des fichiers sur l’XU4, je n’atteins pas les perfs qu’Odroid et vous avez, j’ai seulement 50 mo/s, ce qui est toujours bien mieux que ma Freebox avec ses 36 mo/s max mais bon.
        Merci encore pour le tuto, il reste dans mes favoris 😀

        • admin dit :

          Pour les perfs, il existe des outils (je pense à iperf mais il y en a d’autres) permettant de mesurer les débits max entre deux machines. Cela permet de voir rapidement de quoi est capable réellement l’XU4 et d’en déduire si le problème vient du réseau ou de la conf de l’XU4 (samba notamment).

  7. Henri dit :

    Oui je pense que c’est Samba, les machines sont reliées entre elles via un switch GB et des câbles S/FTP de catégorie 6A, et ça transfert entre disques de 2T, 7200 RPM Sata III, je vais essayer de gratter dans les fichiers de conf de Samba du coup, j’ai déjà jeté un oeil sur des forums, certains parlent de « journalisation EXT4 », à suivre, je ne baisserai pas les bras ! 😀

    • admin dit :

      Si vous trouvez des optimisations pour Samba, je suis preneur car j’avais aussi regardé pas mal de forums et testé pas mal d »optimisations » sans grandes améliorations, au contraire c’était parfois pire. Au final je m’en sort très bien avec ma conf basique mais ça m’intéresse tout de même.

  8. Henri dit :

    Par contre impossible de créer un utilisateur « invité » pour un accès en « read only » sur le partage Samba. L’utilisateur « invité » dans un autre groupe que celui du propriétaire du partage Samba n’ai vraisemblablement pas les droits d’accès au partage, les logs de Samba me remontent ça « reply_sesssetup_and_X: Rejecting attempt at ‘normal’ session setup after negotiating spnego. ». J’ai pourtant bien fait un chmod sur le partage de manière à ce que les autres que le propriétaire et son groupe puissent au moins lire (chmod -R 664 *). Mon but étant d’avoir une session « invité » sur OwnCloud pour que des gens de mon entourage puissent seulement télécharger des trucs sur mon server, mais aucun droit de modification. Si vous avez une idée de comment me dépatouiller, j’ai fouillé pleins de forums sans trouver de réponses :s.

    • Henri dit :

      Bon bas j’ai bidouiller les droits des utilisateurs et c’est ok… Ah une autre petite chose qui m’est arrivé durant l’installation d’Owncloud, pour les partages Samba il m’a été demandé d’installer le paquet « smbclient », effectivement un client est nécessaire à Owncloud pour pouvoir se connecter aux partages, peut-être un point en plus sur le tuto :).

  9. admin dit :

    Bonjour,

    Tuto mis à jour avec la génération d’un certificat par la CA Let’s Encrypt afin d’avoir un certificat reconnu par les navigateurs et qui n’affiche plus d’alerte de sécurité !

  10. Henri dit :

    Oups, merci d’avoir changé mon url :s, pour le problème je regarde les logs et sur Internet, je devrais trouver une solution. En tout cas ça fait plus d’un mois que j’ai mis en place votre tutoriel et ça marche du feu de Dieu !

  11. Henri dit :

    Entendu, effectivement après quelques recherches, votre solution de refaire une configuration du service Nginx semble la meilleur. Merci encore pour vos coups de main.

  12. admin dit :

    Bonjour,

    Tuto mis à jour : je suis passé sur Ubuntu 16.04 LTS. Ça a été l’occasion de reparcourir tout le tuto. J’ai donc fait quelques arrangements afin qu’il soit plus lisible et son enchainement plus logique.

    – Passage à PHP7
    – Pour Let’s Encrypt : l’installation des certifs s’effectue maintenant avec certbot afin de pouvoir les demander plus facilement et les renouveler automatiquement.
    – J’ai acheté un bloc d’alimentation 5V/6A vendu par HardKernel afin de pouvoir connecter mon second disque faisant office de sauvegarde sur l’XU4 et non plus sur ma Freebox où les permissions n’étaient pas modifiables. L’alim supporte très bien les deux disques (compter une trentaine d’€ par contre…).
    – Je ne trouve pas de paquet dans les dépôts pour installer l’écran LCD. Il faut que je me renseigne là-dessus.
    – J’ai regroupé dans l’avant dernier chapitre différents points sur la sauvegarde, la sécurité et le monitoring du serveur. Je mets à disposition des scripts persos.

    L’ancien tuto pour Ubuntu 14.04 est disponible ici mais je ne le mettrai plus à jour : https://www.inzecloud.net/index.php/2016/04/04/linuxhardkernel-nas-et-cloud-perso-avec-odroid-xu4-et-son-boitier-cloudshell-old-ubuntu-14-04/

  13. Henri dit :

    Super, merci pour la màj je vais le mettre en place dès que possible. J’avais également besoin d’un client torrent, comme je n’ai pas trouvé trop d’info pour en avoir un via Owncloud, j’ai trouvé une version très légère de Transmission (daemon), accessible via ligne de commande mais surtout via une interface web et/ou une appli. Android (si on ouvre le port adapté) c’est pas mal du tout et ça « synergise » très bien avec Owncloud.

  14. cuny dit :

    merci de ton article, vraiment clair et très intéressant.

    je me pose néanmoins la question de savoir l’intérêt par rapport à un NAS.

    Le prix est de 363€, à peu près équivalent au DS215J.

    Pouvez-vous m’éclairer?

    • admin dit :

      Hello,

      Le principal avantage que je vois dans cette solution est la maîtrise totale de l’OS et des services installés sur le serveur. L’OS étant Ubuntu, j’ai un large choix de paquets disponibles et je peux faire de mon serveur bien plus qu’un simple NAS. Ça m’a aussi permis de gagner en compétences sous Linux.
      Au niveau des prix, ce n’est pas forcément plus avantageux je l’accorde, notamment pour les disques durs. J’ai eu la chance de trouver des disques 2,5″ de 2To à un prix abordable (~80€). Aujourd’hui le prix de ces mêmes disques est supérieur à 100€. Donc oui, une solution NAS classique avec des disques format 3,5″ est certainement plus avantageuse selon la gamme choisie.

      Je n’ai pas regardé en détails la fiche du DS215J mais si vous souhaitez juste un NAS facile à installer, que vous placerez dans un coin sans plus y toucher, les Synology sont de très bons produits et font très bien le job 🙂

      • Henri dit :

        Perso, ça ma coûté le même prix qu’un NAS de base parce que je n’ai pas acheté de boitier cloudshell ni de disque 2″5, j’ai acheté l’XU4, deux disques 3″5 à 100 euros (2 et 3To) un ventilateur de 10 cm et deux câbles USB+transfo pour les disques durs. J’ai mis les disques dans un module en métal arraché d’un ancien boitier de PC, j’ai bidouillé pour y fixer le ventilateur et le tour est joué. C’est pas très beau -> http://www.hostingpics.net/viewer.php?id=166772IMG20160905153229.jpg mais c’est un peu moins cher et ça a été très enrichissant de monter son petit serveur de A à Z. Dernier problème, c’est avec Owncloud, les fichiers >2Go, partagés via samba ne peuvent pas être téléchargés correctement, ils sont toujours tronqués à 2Go, j’ai bien fouillé depuis des mois sur le net et posé la question sur GitHub mais sans succès, mis-à-part ça tout marche à la perfection.

        • admin dit :

          Bonjour Henri,

          Merci du retour,

          Même si ce n’est « pas très beau », c’est une implémentation intéressante qui montre qu’avec un peu d’imagination on peut encore économiser quelques euros. Le boîtier Cloudshell n’a jamais été une obligation en soit. D’ailleurs je pense que ce tuto pourrait tout à fait s’adapter à un vieux PC transformé en serveur sur lequel serait installé ubuntu-server.

          Pour owncloud je ne sais pas, je télécharge essentiellement des petits fichiers donc je ne saurai pas vous aider…

          • Henri dit :

            Vous m’avez déjà beaucoup aidé, je fais mes petites recherches, je finirais bien par trouver avec les fichiers de logs, Wireshark, Google etc. Je suis parti de 0 en connaissances en administration de système Linux (Ya qu’à voir mes premières questions ici…), maintenant je me sens beaucoup plus à l’aise, ce tutoriel est tout bonnement et simplement fantastique. Un grand merci encore !

  15. Magemax dit :

    Bonjour,
    Tout d’abord merci pour ce tuto, j’ai reçu mon xu4 aujourd’hui et je vais m’y mettre demain (sachant que je compte en faire exactement la même utilisation que vous).
    J’ai juste une petite question pour commencer, j’ai vu (dans les différents tutos / vidéos que j’ai pu trouvé) que sur les release ubuntu précédentes, la première chose qu’il semble falloir faire est de redimensionner la partition pour qu’elle prenne en compte toute la carte sd. Sauf erreur de ma part je n’ai pas vu ça dans votre tuto. Est-ce nécessaire ? Si oui savez vous comment faire ? Merci

    • admin dit :

      Hello,
      Sur ubuntu 16.04 LTS le redimensionnement est fait automatiquement lors du premier démarrage du système. Il n’y a donc rien à faire.
      Ce qui n’était pas le cas sur les anciennes releases où il fallait en effet le faire manuellement (un utilitaire « odroid-utility.sh » était fourni par le fabricant). J’en parle dans l’ancien tuto applicable pour la 14.06 LTS (le lien d’accès est au début de ce tuto) 🙂

      • Magemax dit :

        D’accord merci pour la réponse claire et rapide 🙂 Je vais pouvoir essayer ça sereinement demain alors ! Je ne connais que très peu linux donc ça va être un saut dans l’inconnu mais ça devrait être formateur. Encore merci !

        • admin dit :

          Si vous rencontrez des difficultés ou si certains passages de l’article ne sont pas clairs n’hésitez pas ! 🙂
          Et oui, c’est un excellent moyen pour se former !

  16. Henri dit :

    Bonjour, j’ai fait une ré-installation toute neuve, en suivant ce tuto de nouveau (qui a bien changé depuis 2016 !), et, arrivé au moment ou je dois me connecter à https://mondomaine/owncloud pour finaliser mon installation, mon navigateur m’indique juste une erreur « ERR_TOO_MANY_REDIRECTS ». J’ai bien vidé mon cache, cherché dans les fichiers de conf de nginx si je n’avais pas fait une erreur mais celle-ci semble m’échapper…

    • Henri dit :

      En fait c’est qu’il faut juste faire aussi un lien symbolique pour la config HTTPS. Ça marche toujours aussi bien ce tuto, encore mieux avec cette iso: https://wiki.odroid.com/odroid-xu4/os_images/linux/ubuntu_4.14/20171213 on a le bonheur par exemple de passer de 80 mb/s lecture/écriture à 110.

      • admin dit :

        Bonjour Henri,

        Je suis en cours de rédaction de l’évolution de cet article, où j’utilises le cloudshell v2 et une version plus récente d’ubuntu. J’en profites pour rectifier des oublis et effectivement il manque le lien symbolique du vhost HTTPS, merci de me l’avoir signalé !

        J’ai aussi remarqué une amélioration des débits de transfert avec samba, c’est le top ! Merci de toujours soutenir cet article, ça fait plaisir 🙂

  17. Henri dit :

    Bonjour, vous savez, sans ce tutoriel, mon XU4 serait sans doute au placard. J’ai essayé d’autres alternatives, comme des tutoriels d’installation d’Open Media Vault (que j’ai pas trop aimé à cause de la sur-couche), pour revenir encore et toujours à celui-ci qui est sans nul doute le plus complet.
    De mon côté j’ai opté pour Nextcloud plutôt que OC, car, j’ai remarqué sur ce dernier, que certaines applications étaient devenues payantes :S. L’installation est tout à fait similaire, à ceci-prêt que Nextcloud n’a pas de dépôt officiel sur Debian ou Ubuntu.
    Pour les problèmes de gros fichiers et Samba dans Nextcloud/Owncloud, il semble qu’installer un wrapper PHP plus récent via PECL (PECL install smbclient -> version 0.9.0 au lieu de 0.8.0 sur les dépôts officiels) et ajouter la librairie dans PHP fpm règle partiellement le problème, mais apparemment rare sont les utilisateurs de samba parmi ceux qui ont NC ou OC, donc ça ne sert pas à grand chose dans ce tuto.
    Merci encore pour votre travail, je continuerai à poster !

    • admin dit :

      Bonjour,

      L’article a été mis à jour, j’ai corrigé quelques coquilles et j’expose mon avis sur le nouveau boitier de Hardkernel et OpenMediaVault. Il n’y a pas de grosses améliorations puisque les services restent les mêmes et il n’y a pas de raisons qu’ils changent puisque ça fonctionne 🙂

      Il y aura surement une mise à jour à l’avenir avec prise en compte de la nouvelle version 18.04 LTS d’ubuntu (qui sort dans quelques jours) mais pour le moment on reste sur 16.04 avec un kernel un peu plus récent.

      Je n’ai pas encore l’intention de passer à Nextcloud mais j’y songe car effectivement Owncloud a prit une direction un peu + commerciale. Si vous avez un moment, pouvez vous m’expliquer pourquoi vous utilisez l’extension php-smbclient plutôt que le paquet système directement (smbclient) ? Car de mon côté j’ai toujours utilisé le paquet smbclient, mais j’avoue que je ne sais pas ce qu’il en est pour les gros fichiers car j’évite de les manipuler depuis owncloud.

      apt-cache policy smbclient
      smbclient:
      Installé : 2:4.3.11+dfsg-0ubuntu0.16.04.13
      Candidat : 2:4.3.11+dfsg-0ubuntu0.16.04.13
      Table de version :
      *** 2:4.3.11+dfsg-0ubuntu0.16.04.13 500
      500 http://ports.ubuntu.com/ubuntu-ports xenial-updates/main armhf Packages
      500 http://ports.ubuntu.com/ubuntu-ports xenial-security/main armhf Packages
      100 /var/lib/dpkg/status
      2:4.3.8+dfsg-0ubuntu1 500
      500 http://ports.ubuntu.com/ubuntu-ports xenial/main armhf Packages

      root@odroid:~# smbclient -V
      Version 4.3.11-Ubuntu

      • Henri dit :

        Bonjour,

        En fait j’utilise tout comme vous le paquet smbclient pour que Nextcloud ait accès aux partages smb, mais par contre j’utilise le « wrapper » php pour samba, je n’ai pas trop compris mais il semblerait que ce soit un paquet qui enveloppe le samba pour que php le « lise » correctement, à vérifier je suis loin d’être spécialiste.
        Dans les dépôts officiels c’est la version 0.8.0 (libsmbclient) qui n’est pas terrible, via PECL on peut avoir une version plus récente, la 0.9.0.
        Cependant je crains que tous ces efforts ne soient vains, après bien des recherches il semblerait que le problème principal persiste et vienne de Owncloud/Nextcloud.
        J’ai des collègues au boulot qui travaillent tous les jours avec Nextcloud je tâcherai de leur demander des explications.

        Bien à vous !

  18. Alex dit :

    Salut,

    Très bon tuto! je vous remercie mile fois.
    Je suis tombé sure une erreur, mon navigateur m’indique « ERR_TOO_MANY_REDIRECTS ». J’ai lu le commentaire de Henri, mais je ne sais pas trop comment m’y prendre. Savez-vous ce que je dois faire?

    Merci

    • admin dit :

      Bonjour,

      Effectivement ça ressemble à un problème de conf nginx, il faut que vous vérifiez que vous avez effectué l’étape « Créer un lien symbolique dans sites-enabled cette fois pour activer la configuration du vhost HTTPS : »
      Puis rechargez la conf nginx.
      Si ça ne résoud pas le problème, on investiguera ensemble 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

%d blogueurs aiment cette page :