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

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 (Samba),
  • Accès et partage des fichiers depuis Internet (ownCloud),
  • Lecture des fichiers depuis le Freebox player et des appareils Android (à l’aide d’un serveur DLNA).

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 » :

cloudshell1-e1458489464531

Pour un total de 166€, je me donc offert le boitier et la carte-mère chez un revendeur anglais, commandé et livré sous 3 jours. La commande comprenait donc :

  • 1 Odroid XU4 + son alimentation,
  • 1 boitier Cloudshell en pièces détachées avec sa quincaillerie,
  • 1 câble USB,
  • 1 écran LCD et sa nappe.

Le tout soigneusement emballé :

Avec ça deux disques externes Seagate Backup Plus de 2To (un disque principal et un disque secondaire pour la sauvegarde) dont le boitier est facilement démontable, ce qui permet d’en extraire le disque et de le pluger au cloudshell :

Pour alimenter le second disque, il faut prévoir d’acheter une alimentation 5V/6A (disponible pour 31$ FDP inclus soit 28,58€ ici : http://www.hardkernel.com/main/products/prdt_info.php?g_code=G146977556615 ). Les sauvegardes du premier disque vers le second seront planifiées tous les jours.

Coût total :

  • Odroid XU4 + Cloudshell = 166€
  • 2x Seagate Backup Plus 2To = 168€
  • 1 alimentation 5V/6A = 28,58€

Total = 362,58€

MONTAGE DU BOÎTIER CLOUDSHELL

Les instructions officielles sont disponibles ici : http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143599699669

Je n’ai eu aucun mal à monter le boitier. J’ai choisi cependant de connecter le disque dur sur le port USB3.0 du bas contrairement à ce qui est montré sur les instructions officielles. Cela permet un accès plus facile au deuxième port lorsque tout est fixé dans le boitier.

Quelques photos du montage :

img_20160318_181540 img_20160318_181600 img_20160318_182405

img_20160318_182605 img_20160318_183337 img_20160318_183705

PRÉPARATION DU SYSTÈME

Pour ma part, j’ai utilisé une carte SD sur laquelle j’ai installé ubuntu-minimal (=server) 16.04 LTS. L’image est téléchargeable à l’adresse suivante : http://odroid.in/ubuntu_16.04lts/ubuntu-16.04-minimal-odroid-xu3-20160706.img.xz

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

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.

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

$ apt-get 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 > 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
$ nano .bashrc

Dé-commenter la ligne suivante :

force_color_prompt=yes

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

$ source .bashrc

Mettre à jour les paquets :

$ apt-get update
$ apt-get upgrade -y

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

Sur Ubuntu 16.04, les noms d’interfaces réseau changent. Pour une raison que j’ignore, elles ne sont plus nommées eth0, eth1, etc…

Comme on aimait bien les anciens noms et qu’on ne veut pas changer cette habitude, on va renommer l’interface en eth0.

Faire un ifconfig et copier l’adresse MAC de l’interface dont on souhaite changer le nom :

$ ifconfig
enx001e063049ff      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet adr:192.168.0.11  Bcast:192.168.0.255  Masque:255.255.255.0
          adr inet6: fe80::21e:6ff:fe30:2f35/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:51 erreurs:0 :0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:5350 (5.3 KB) Octets transmis:7003 (7.0 KB)

Ajouter une règle udev en éditant un nouveau fichier (vide) :

$ nano /etc/udev/rules.d/10-network.rules

Dans lequel on ajoute la ligne suivante en indiquant l’adresse MAC récupérée précédemment :

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="xx:xx:xx:xx:xx:xx", NAME="eth0"

É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

Redémarrer (reboot) l’XU4 pour prendre en compte le changement de nom et d’IP.

É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é conservée :

$ ifconfig

CONFIGURATION DU BOITIER CLOUDSHELL ET DE L’ECRAN LCD

Ici nous allons voir comment mettre en place l’affichage sur l’écran LCD du boitier.

Éditer un nouveau fichier vide « /etc/modprobe.d/odroid-cloudshell.conf » et ajouter la ligne suivante :

options fbtft_device name=hktft9340 busnum=1 rotate=270 speed=40000000

Éditer le fichier « /etc/modules » et ajouter les lignes suivantes :

spi-s3c64xx
fbtft_device

Faire une sauvegarde du fichier « /etc/X11/xorg.conf » :

$ cp /etc/X11/xorg.conf /etc/X11/xorg.conf.old

Puis éditer ce fichier et ajouter une des configurations suivantes :

Une fois la configuration en place, rebooter l’XU4 :

$ 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.

Il est possible d’éteindre l’écran LCD : (ne fonctionne plus sur 16.04)

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

Et de le rallumer :

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

PRÉPARATION DU DISQUE

Il faut maintenant préparer le disque connecté à l’XU4 et qui sera le stockage principal du NAS.

Créer et formater une partition sur le disque

Repérer le disque avec « fdisk -l » :

$ fdisk -l
Disque /dev/mmcblk0 : 29,7 GiB, 31914983424 octets, 62333952 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: dos
Disk identifier: 0x3cedfd53

Périphérique Amorçage Start Fin Secteurs Size Id Type
/dev/mmcblk0p1 2048 264191 262144 128M c W95 FAT32 (LBA)
/dev/mmcblk0p2 264192 62332928 62068737 29,6G 83 Linux

Disque /dev/sda : 1,8 TiB, 2000398925824 octets, 3907029152 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: 4B6FD4B0-21DE-11E6-8662-D2FD8B2802E3

Périphérique Start Fin Secteurs Size Type
/dev/sda1 2048 3907028991 3907026944 1,8T Linux filesystem

A moins que vous ayez connecté d’autres supports de stockage, il devrait s’agir de « /dev/sda ».

Utiliser « cfdisk » pour préparer ce 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
Créer un montage permanent et automatique du disque

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

$ blkid
/dev/mmcblk0: PTUUID="0008aae4" PTTYPE="dos"
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="5F78-D927" TYPE="vfat" PARTUUID="0008aae4-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="e139ce78-9841-40fe-8823-96a304a09859" TYPE="ext4" PARTUUID="0008aae4-02"
/dev/sda1: UUID="a7e39b7f-a2ac-43a7-a993-f8464c7ae47c" TYPE="ext4" PARTUUID="44fdfe06-01"

Copier l’UUID puis éditer le fichier « /etc/fstab » en ajoutant la ligne suivante (à adapter en fonction de votre UUID) et du répertoire de montage souhaité (pour ma part /media/disque) :

UUID=a7e39b7f-a2ac-43a7-a993-f8464c7ae47c /media/disque ext4 defaults 0 2

Créer alors le répertoire de montage :

$ mkdir /media/disque

Puis monter la partition dans ce répertoire :

$ mount /media/disque

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 » :

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

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 de pouvoir accéder aux fichiers stockés sur le disque dur 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-get 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 770 /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

#======================= 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
printable = no
# Masquer les fichiers Thumbs.db de l'explorateur Windows
veto files = /Thumbs.db/Desktop.ini/

# Répertoire de partage entre utilisateurs 
[Partage]
comment = Repertoire Partage
path = /media/disque/samba/Partage
browseable = yes
public = no
writeable = yes
printable = no
veto file = /Thumbs.db/Desktop.ini/

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.

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 -d /home/toto -m -s /bin/bash -G sambashare toto

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:sambashare /media/disque/samba/toto
$ chmod -R 700 /media/disque/samba/toto

$ chown -R titi:sambashare /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.

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 :

$ apt-get install mysql-server php7.0-mysql php7.0-fpm

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-get 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 (Ctrl+W sous nano) 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 = 10G # Définit la taille maximale des données reçues par la méthode POST. Ici fixée à 10Go.
upload_max_filesize = 10G # Définit la taille maximale d'un fichier à charger. Ici fixée à 10Go. 
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
$ nano 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;
}
$ nano 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
https://www.inzecloud.net/index.php/vhost-ssl-cas-1/ 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
$ nano 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/

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 :

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

Mettre à jour la liste des paquets :

$ apt-get update

Installer ownCloud :

$ apt-get install owncloud

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 doient 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-get update
$ apt-get 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 && service nginx 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-get install phpmyadmin

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

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

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 {
    root /var/www;
    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.

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-get install smbclient

Puis se loguer sur ownCloud avec un compte administrateur et se rendre dans le menu « Applications » :

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 de 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 que j’ai connecté sur le port USB2.0. 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. 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/9.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 les paquets « owncloud » et « owncloud-files » apparaissent lorsque vous exécutez apt-get upgrade, c’est qu’une mise à jour d’ownCloud est disponible. Installer ces paquets 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-get 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

Redémarrer le service miniDLNA pour prendre en compte les modifications :

$ /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

DEBUG

ownCloud

Après activation de l’application « External storage support », j’ai obtenu une page blanche lorsque j’ai rafraichi ownCloud. Pour résoudre ce problème, supprimer le fichier « mount.json » situé dans le répertoire « data ». Cela peut arriver lors d’une réinstallation d’ownCloud.

Vous aimerez aussi...

35 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 !

Laisser un commentaire

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

%d blogueurs aiment cette page :