Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Ce chapitre n’a pour but que de vous faire un petit résumé des différentes étapes à partir de l’installation de Owncloud sur un Raspberry Pi, jusqu’à avoir un server fonctionnel.

Je vais aussi en profiter de cette partie pour tester la dernière version en date de Owcloud.

Pour rappel, nous avons besoin de:

  1. Matériel:

    – Raspberry Pi 2 B
    – Carte micro SD, Classe 10
    – Câble HDMI avec un moniteur (écran télé) qui supporte le HDMI
    – Câble Ethernet

  2. Firmware:

    – Owncloud 9.1.3
    – Raspbian 8.0

  3. Configuration:

    – Adresse IP Publique
    – Adresse IP Privée statique (LAN) pour le RPi
    – Nom de domaine (NetLibre, nsupdate)
    – Certificat LE (Lets encrypt)

Ne vous attendez donc pas à ce que je détaille les différentes étapes de l’installation, puisque çà a déjà été abordé dans les différents chapites associés. Je vous renvoie donc vers les différentes sections pour plus d’information.

Chap 1. Prise en main du RPi
—————————————–

$ df -h

$ sudo umount /dev/sdb1

$ sudo apt install dcfldd

$ sudo dcfldd if=20XX-YY-ZZ-raspbian-jessie-lite.img of=/dev/sdb bs=1M
$sync

$ sudo cat >  /etc/network/interfaces.d/eth0 << eof > auto eth0
>
> iface eth0 inet static
>     address 172.16.1.16
>      netmask 255.255.255.0
>      gateway 172.16.1.1
> eof

# ifdown eth0

# ifup eth0

# vi /etc/resolv.conf
# Generated by resolvconf
nameserver 8.8.8.8
nameserver 8.8.4.4

# chattr +i /etc/resolv.conf 


$ sudo apt update
$ sudo apt upgrade

$ sudo apt install vim

$ sudo raspi-config 

Un petit plus,

pi@raspberrypi:~ $ sudo hostname nouveau-nom
pi@nouveau-nom:~ $ sudo vim /etc/hosts
!--sortie tronquée--!
127.0.1.1	nouveau-nom

Faite une copie de sauvegarde du système installé sur la carte SD vers un autre support (disque dur local par exemple):

$ sudo umount /dev/sdb1
$ sudo umount /dev/sdb2

mon@ordi$ cd ~/Backup

$ sudo dcfldd if=/dev/sdb of=sd.img bs=4M

Chap 3. Sécuriser votre RPi
—————————————–

mon@ordi$ ssh pi@10.1.2.3

$ sudo adduser USERNAME
$ sudo adduser USERNAME sudo

$ groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio
$ groups USERNAME
USERNAME : USERNAME sudo

$ sudo usermod -a -G adm,dialout,cdrom,audio,video,plugdev,games,users,input,netdev,spi,i2c,gpio USERNAME

mon@ordi$ ssh USERNAME@10.1.2.3

sudo deluser --remove-home pi

Je n’ai pas réussi à supprimer l’utilisateur pi du premier coup, car la commande renvoie l’erreur que cet utilisateur a un process actif (bash). J’ai du redémarrer le RPi et relancer la même commande. Une autre alternative serait d’utiliser la commande ci-dessous:

$ sudo userdel -f pi

$ sudo passwd -dl root

$ sudo vim /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
$ sudo service ssh restart

*Connection SSH côté client
—————————————

mon@ordi$ sudo apt-get install openssh-client
mon@ordi$ ssh-keygen -t rsa

N’ommetez pas la passphrase!!!

Les clés générées devraient se trouver dans le répertoire ~/.ssh:
– clé privée: id_rsa (vous devez ne jamais fournir cette clé à personne)
– clé publique: id_rsa.pub

mon@ordi$ ssh-copy-id -i ~/.ssh/id_rsa.pub USERNAME@10.1.2.3

*Connection SSH côté server
—————————————

USERNAME@raspberrypi$ sudo apt-get install openssh-server

Vérifier et modifier les permissions pour les fichiers et dossiers si nécessaire.

drwx------ .ssh
-rw------- .ssh/authorized_keys


$ sudo vim /etc/ssh/sshd_config
PasswordAuthentication no

$ sudo service ssh restart

*Parefeux
—————————————

$ sudo vim /etc/iptables.firewall.rules
*filter

# Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

# Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow RDP connections from anywhere (uncomment if rdp connection is needed)
# -A INPUT -p tcp --dport 3389 -j ACCEPT

# Allow SSH connections
# The -dport number should be the same port number you set in sshd_config
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow ping
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT
$ sudo iptables-restore < /etc/iptables.firewall.rules
$ sudo iptables -L

sudo vim /etc/network/if-pre-up.d/firewall
#!/bin/sh
/sbin/iptables-restore < /etc/iptables.firewall.rules

$ sudo chmod +x /etc/network/if-pre-up.d/firewall

$ sudo apt install fail2ban

Chap 2. Installation de OwnCloud sur un Raspberry Pi
—————————————–

$ mkdir /home/USERNAME/www-dev
$ cd /home/USERNAME/www-dev


$ sudo wget http://download.owncloud.org/community/owncloud-9.1.3.tar.bz2
$ sudo wget http://download.owncloud.org/community/owncloud-9.1.3.tar.bz2.md5
$ md5sum -c owncloud-9.1.3.tar.bz2.md5 < owncloud-9.1.3.tar.bz2
owncloud-9.1.3.tar.bz2: OK

$ sudo tar -xvf owncloud-9.1.3.tar.bz2

$ sudo chown -R www-data:www-data /home/USERNAME/www-dev

*Apache
—————————————

$ sudo vim /etc/apache2/sites-available/owncloud.conf
Alias /owncloud "/home/USERNAME/www-dev/owncloud/"
<Directory /home/USERNAME/www-dev/owncloud/>
 Options +FollowSymlinks
 AllowOverride All

 <IfModule mod_dav.c>
 Dav off
 </IfModule>

 SetEnv HOME /home/USERNAME/www-dev/owncloud
 SetEnv HTTP_HOME /home/USERNAME/www-dev/owncloud

</Directory>


Lier symboliquement /etc/apache2/sites-enable/owncloud.conf à /etc/apache2/sites-avaibled/owncloud.conf:
$ sudo a2ensite owncloud.conf

Remplacer a2ensite par a2dissite pour supprimer le lien symbolique.

$ sudo a2enmod rewrite
$ sudo a2enmod headers

$ sudo service apache2 restart
$ sudo systemctl daemon-reload

$ sudo a2enmod ssl
$ sudo a2ensite default-ssl
$ sudo service apache2 reload

$ sudo cp /etc/php5/apache2/php.ini /etc/php5/apache2/php.ini.bak
$ sudo vim /etc/php5/apache2/php.ini
upload_max_filesize = 2G
post_max_size = 2G

$ sudo service apache2 restart

 

*MySQL/MariaDB
—————————————

$ sudo mysql_secure_installation
Enter current pasword for root, #taper le mot de passe root de MariaDB, qui devrait être le même que celui lors de l'installation du service
Change root password, #taper “n” pour NON
Remove anonymous users, #taper “y” pour OUI
Disallow root login remotely, #taper “y” pour OUI
Remove test database and access to it, #taper “y” pour OUI
Reload privilege tables no, #taper “y” pour OUI

$ sudo mysql -u root -p
Enter password: #taper le mot de passe root de MariaDB

MariaDB [(none)]> CREATE USER 'ownclouduser'@'localhost' IDENTIFIED BY 'password';
MariaDB [(none)]> CREATE DATABASE IF NOT EXISTS owncloudDB;
MariaDB [(none)]> GRANT ALL PRIVILEGES ON owncloudDB.* TO 'ownclouduser'@'localhost' IDENTIFIED BY 'password';
MariaDB [(none)]> quit

 

Si vous rencontrez un message du type:

Error 403: Forbidden
You don’t have permission to access/owncloud/ on this server

Il suffit d’ajouter dans le fichier de configuration de apache2 les lignes ci-dessous. Pour rappel, ce n’est pas nécessaire de le faire avec la version 8 de Owncloud.

$ sudo vim /etc/apache2/apache2.conf

<Directory /home/USERNAME/www-dev/>
 Options Indexes FollowSymLinks
 AllowOverride All
 Require all granted
</Directory>

Chap 5. Connection en SSH
—————————————–

*SSH serveur
---------------------------------------

raspi$ sudo vim /etc/ssh/ssh_config
ClientAliveInterval 60
$ sudo service sshd restart

*SSH client
---------------------------------------

monOrdi$ vim ~/.ssh/config
Host *
ServerAliveInterval 60

Modification/mise-à-jour de la passephrase:

monOrdi$ cd ~/.ssh/

monOrdi:~/.ssh $ ls 
id_rsa id_rsa.pub 
monOrdi:~/.ssh $ ssh-keygen -f id_rsa -p

Chap 4. Accès au serveur Web Owncloud à partir
—————————————–

Je vous propose de revoir ce chapitre pour les détails du comment pointer votre adresse IP publique à votre nom de domaine.

$ sudo cp  /etc/apache2/apache2.conf  /etc/apache2/apache2.conf.bak
$ sudo vim /etc/apache2/apache2.conf

Ajouter les deux lignes a la fin de la page

ServerSignature Off
ServerTokens Prod

$ sudo service apache2 restart

$ sudo vim ~/www-dev/owncloud/config/config.php
'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => '10.1.2.3',
    2 => 'Mon.Adresse.IP.Publique',
    3 => '.netlib.re',
    4 => '.nsupdate.info',
  ),

$ sudo service apache2 restart

Voici le contenu de mon fichier /etc/apache2/site-enabled/owncloud.conf
=====================================================
Alias /owncloud "/home/USERNAME/www-dev/owncloud"

 <VirtualHost *:80>
 ServerName MaPage.netlib.re
 Redirect permanent / https://MaPage.netlib.re/
</VirtualHost>

<VirtualHost *:80>
 ServerName MaPage.nsupdate.info
 Redirect permanent / https://MaPage.nsupdate.info/
</VirtualHost>

# Web server configuration

<VirtualHost *:443>
 ServerName MaPage.netlib.re/
 ServerAlias MaPage.nsupdate.info/

 # SSL configuration
 #SSLEngine on

 # Restrict/deny/allow access to certain directories

 <Directory /home/USERNAME/www-dev/owncloud/>
 Options +FollowSymlinks
 AllowOverride All

 <IfModule mod_dav.c>
 Dav off
 </IfModule>

 SetEnv HOME /home/USERNAME/www-dev/owncloud
 SetEnv HTTP_HOME /home/USERNAME/www-dev/owncloud
 </Directory>

 <Directory "/home/USERNAME/www-dev/owncloud/data/">
 # just in case if .htaccess gets disabled
 Require all denied
 </Directory>

</VirtualHost>



# modern configuration, tweak to your needs
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite !--Sortie Tronquee--!
SSLHonorCipherOrder     on
SSLCompression          off

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000) 

 

Ci-dessous, quelques commandes utile pour vérifier les erreurs de syntax dans /var/apache2/site-enabled/owncloud.conf

$ sudo apache2ctl configtest
$ sudo journalctl | tail


$ systemctl status apache2.service 

Pour régler les problèmes annoncés dans la page d'administration de Owncloud, il suffit d'installer php5-apcu

$ sudo apt install php5-apcu 

Puis d'ajouter la ligne ci-dessous dans ~/www-dev/USERNAME/owncloud/config/config.php

<?php
$CONFIG = array (
!--Sortie Tronquee--!
'memcache.local' => '\OC\Memcache\APCu',
);
$ sudo service apache2 restart


Chap 7. Let's Encrypt (LE)
-----------------------------------------

Le nouveau système pour l'installation de LE est beaucoup plus simple qu'auparavant.


$ mkdir ~/Letsencrypt
$ cd Letsencrypt/
~/Letsencrypt $ wget https://dl.eff.org/certbot-auto
~/Letsencrypt $ chmod a+x certbot-auto $ ./certbot-auto

Puis faites un test de verification du renouvellement automatique.

~/Letsencrypt $ certbot-auto renew --dry-run 

Créer ensuite une règle dans crontab, qui va lancer automatiquement, une demande de renouvellement du certificat une fois tous les 12 heures.

$ sudo crontab -e
  #Minute Hour Day of Month Month Day of Week Command
  #(0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)

crontab
* */12 * * * /home/matakasi/letsencrypt/certbot-auto renew --quiet --no-self-upgrade >> /var/log/apache2/letsencrypt-renew.log 2>&1

Référence:

Apache on Debian (other)

Suppression et ajout d’une interface graphique

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 9. Suppression et ajout d’une interface graphique

Dans ce chapitre, je vais essayer de donner le maximum d’information sur les différentes commandes à entrer pour désinstaller et réinstaller l’interface graphique (ou GUI, de Graphique User Interface) de notre système d’exploitation, qui est ici du Raspbian. Les différentes étapes que je vais décrire ici peuvent s’appliquer ailleurs, toujours dans le monde de linux bien sur.

I. Suppression de l’interface graphique et des différents composés qui y sont associés

J’espère qu’avec le temps, vous utiliserez moins, si ce n’est plus du tout, l’interface graphique pour gérer votre serveur sous linux. Il est donc temps de supprimer définitivement le GUI, d’autant plus que celà vous faira gagner un peu d’espace sur votre carte SD. Cet espace de gagné est loin d’être négligable.

Qu’est-ce que donne la commande « df »?

En général, pour avoir des informations pour chaque commande, il faut passer par un « man [nom_de_la_commande]« . Pour changer, je vous propose de découvrir la commande « apropos« . Comme le nom l’indique, on veut avoir les informations à propos de la commande « df« .

Notez bien que cette commande va chercher toutes les commandes qui contiennent « df » dans le nom. Tapez « apropos df » dans une console, et voyez le résultat.

Comme on connait exactement (option -e) le nom de notre commande, on ne va pas s’embêter à afficher tout le résultat de la commande « df ».

$ apropos -e df
df (1) - report file system disk space usage

La commande « df » nous donne donc l’espace disponible sur notre disque. Voyons ce qu’on a:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
 /dev/root       7.2G  5.6G  1.4G  81% /
 devtmpfs        483M     0  483M   0% /dev
 /dev/mmcblk0p1   60M   21M   40M  35% /boot

L’option -h de la commande « df » nous permet de lire plus facilement le résultat.

Il ne me reste plus que 1,4Go d’espace libre sur ma carte SD. Je tiens à préciser à ceux qui n’ont pas suivit ce chapitre depuis le début que j’ai branché un disque dur externe pour le stockage de données dans Owncloud.

Il est à noter que cette commande va de paire avec la commande « du » qui, par contre nous affiche l’espace utilisé par un ou plusieurs fichier. Comme example, vérifiez ce que contient le dossier tmp qui, je le rappelle, devrait se vider automatiquement à chaque démarrage de l’ordinateur.

$ sudo du -h /tmp/

Voyez le même résultat sans l’option -h.

Qu’est ce qu’on peut supprimer sur Raspbian pour gagner de l’espace?

Les étapes suivantes peuvent s’appliquer à la suppression de tout environement de bureau. Initialement, Mate a été installé par défaut avec Raspbian.

Pour ceux qui n’ont pas besoin d’explication, vous pouvez directement supprimer Mate, ou tout autre environement de bureau (DE, Desktop Environment) comme suit.

$ sudo aptitude purge `dpkg --get-selections | grep 'gnome\|mate\|xorg\|lightdm' | cut -f 1`
$ sudo aptitude -f install
$ sudo aptitude purge `dpkg --get-selections | grep deinstall | cut -f 1`
$ sudo aptitude -f install

Vous avez certaintement remarqué que j’ai utilisé aptitude au lieu de apt. Il y a une raison pour celà.

II. Aptitude vs apt-get vs apt

Je ne vais pas rentrer dans les détails concernant laquelle de ces commandes il est préférable d’utiliser. Par contre, je ne peux m’empécher de vous inciter à n’utiliser que APT tant que possible, qui est en fait une amélioration de la commande apt-get.

Si vous êtes familier avec aptitude ou apt-get, alors l’utilisation de apt ne devrait pas trop vous poser de problèmes.

apt install       Installe le paquet
apt remove     Supprime le paquet
apt purge         Supprime le paquet ainsi que ses fichiers de configuration
apt autoremove                         Supprime les dépendances du/des paquets désinstallés

apt update                                  Met à jour les métadonnées de l’archive du paquet
apt upgrade                                Installe les version candidates des paquets installés sans supprimer les anciens
apt full-upgrade                        Idem que « apt upgrade » mais cette commande peut aussi supprimer les anciens paquets
apt -f install                               Répare les fichiers « cassés »

apt list –installed                     Affiche la liste des paquets installés
apt list –upgradable                Affiche la liste des paquets installables

Il est possible d’installer et de supprimer plusieurs paquets en même temps, en ajoutant le signe « + » ou « – » juste après le nom du ou des packets. Voici deux exemples qui donnent les mêmes résultats: suppression du packet2 puis installation du packet1.

# apt install packet1 packet2-

# apt remove packet2 packet1+

N’hésitez pas à taper « man apt » pour plus d’information.

 

Pourquoi continuer d’utiliser aptitude pour certaines tâches?

Ce qui m’embête le plus avec apt, c’est résultat donné suite à une rechercher de paquets.

Voyez la différence entre apt search et aptitude search. Personnellemment, je trouve que le résultat donné par aptitude search est beaucoup plus lisible.

$ aptitude search 

 

selection_036

« i » indique que le paquet est installé, « p » quand il est installable. Pour n’afficher que les paquets installés,

$ aptitude search | grep ^i

Effectuer ensuite le même test avec apt search.

$ apt search
$ apt search | grep installed

 

selection_035

Noter l’alerte qui nous prévient que cette commande n’est pas tout à fait au point pour les scripts.
Ci-dessous deux options de aptitude qui me paraissent incontournables, et dont je n’ai pas encore réussit à trouver les équivalents avec apt:

-s               simule le résultat de la commandes
-d               télécharge seulement les paquets sans les installer ni les mettre à jour

 

Si malgré celà vous souhaitez n’utiliser que apt, sachez que si vous rencontrez des problèmes de dépendances et qui n’arrivent pas à s’installer avec apt, mieux vaut utiliser aptitude dans ce cas.

L’option « why » vous donne la liste de dépendances nécessaire à l’installation du paquet, tandis que « why-not » vous donne une indication pour laquelle le(s) paquet(s) ne peut/peuvent pas être installé(s).

 

selection_019

Comme vous pouvez le constater, avant de pouvoir supprimer définitivement xorg, il faudrait commencer par supprimer ces dépendances.

$ sudo aptitude purge `dpkg --get-selections | grep  | cut -f 1`
$ sudo aptitude -f install
$ sudo aptitude purge `dpkg --get-selections | grep deinstall | cut -f 1`
$ sudo aptitude -f install

Ici, est à remplacer successivement par la liste de dépendance des paquets de mate, xorg, lightdm et gnome.

En prenant le cas de xorg qui a pour dépendance plymouth et desktop-base,

$ sudo aptitude purge `dpkg --get-selections | grep -e plymouth -e desktop-base -e xorg | cut -f 1`
$ sudo aptitude -f install
$ sudo aptitude purge `dpkg --get-selections | grep deinstall | cut -f 1`
$ sudo aptitude -f install

Pourquoi utiliser dpkg dans la commande aptitude purge?

III. DPKG

Il faut savoir que la commande « aptitude purge » ne supprime que le/les paquets spécifiés dans la commande, ainsi que son/ses fichiers de configuration.

De ce fait, le fait de lancer la commande « aptitude purge gnome » ne supprime que l’environement de bureau du même nom, en laissant toute une liste de packets et de programmes, orphelins. Certes, ces paquets ne prennent pas de place, mais quand même.

L’astuce pour tout supprimer serait d’afficher la liste des paquets contenant le nom de celui qui nous intéresse, puis de lancer la commande aptitude purge sur résultat de la première commande.

Voyons pas à pas ce qu’il faut faire.

1. Afficher de la liste de tous les packets

$ dpkg --get-selections

2. Faire le tri parmis ces paquets afin de n’afficher que ceux qui contiennent gnome dans leurs noms

$ dpkg --get-selections | grep gnome

Comme la commande dpkg nous donne pas mal d’informations étalées sur plusieurs colones, concernant le packet installées

3. Supprimer toutes les colonnes, autre que celle qui affiche le nom du packet

Le champ (en anglais: Field, d’où l’option -f de cut) qui nous intéresse est exactement la première colone.

$ dpkg --get-selections | grep gnome | cut -f 1

 

selection_020

Vous pouvez jouer avec des valeurs entre 1 à 10 par exemple, de l’option -f de « cut » pour voir comment cet outil fonctionne. Amusez-vous bien!

4. Suppression des packets donnés par dpkg

$ sudo aptitude purge `dpkg --get-selections | grep gnome | cut -f 1`

Notez les deux accents graves à l’intérieur de la commande aptitude purge, pour lancer une commande à l’intérieur d’une autre. La commande ci-dessus revient dont à taper la série de commandes suivantes.

$ sudo aptitude purge gnome
$ sudo aptitude purge gnome-icon-theme
$ sudo aptitude purge gnome-keyring
etc.

Pour aller encore un peu plus loin, dans la même commande, on peut faire une recherche de tous les packets contenant plusieurs mots clés avec grep. Voici la listes de commande finale à taper.

$ sudo aptitude purge `dpkg --get-selections | grep 'gnome\|mate\|xorg\|lightdm' | cut -f 1`
$ sudo aptitude -f install
$ sudo aptitude purge `dpkg --get-selections | grep deinstall | cut -f 1`
$ sudo aptitude -f install

Si les anti-slashs (\) vous embêtent, l’option -E ou -e de grep serait un très bon choix. Ou tout simplement, utiliser egrep.

$ sudo aptitude purge `dpkg --get-selections | grep -E 'gnome|mate|xorg' | cut -f 1`
$ sudo aptitude purge `dpkg --get-selections | egrep 'gnome|mate|xorg' | cut -f 1`
$ sudo aptitude purge `dpkg --get-selections | grep -e gnome -e mate -e xorg | cut -f 1`

Vous vous demander certainement pourquoi lancer une nouvelle commande de purge après avoir supprimé tous les paquets avec leurs dépendances! C’est qu’il en reste quelques fichiers de configuration qui trainent encore par-ci et par-là, qu’on n’a pas pu supprimer totallement avec la commange aptitude purge.

En jouant avec la commande « dpkg -l » associé à la commande « aptitude why« , j’ai pu vérifier que d’autres paquets indépendant de l’interface graphique, ne sont plus nécessaires et peuvent aussi être supprimés.

$ dpkg -l | grep x11
ii x11-common

$ aptitude why x11-common
i iceweasel Depends firefox-esr
i A firefox-esr Depends libxt6
i A libxt6 Depends libice6 (>= 1:1.0.0)
i A libice6 Depends x11-common

Il ne faut donc pas oublier de supprimer firefox, iceweasel et d’autres applications dont vous n’avez plus besoin.

Comment lire le résultat de « dpkg -l »?

Cette commande donne une liste de paquets avec un indice à 2 ou 3 caractères dans la première colone pour nous donner une indication de l’état de chacun de ces paquets.

$ dpkg -l

Le premier caractère

i Installer
r Supprimer/désinstaller

Le deuxième caractère

i Installé
c Fichier de configuration

Le troisième caractère

Pas de message d’erreur

Ce qui se résume à:

ii      Le packet devrait être installé, et il l’est
rc     Le packet a été supprimé, mais son fichier de configuration ne l’est pas

 

selection_021

Pour plus d’information sur la commande dpkg, ‘hésitez pas à lire le manuel.

Voyons maintenant combien d’espace est-il disponible sur notre carte SD.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
 /dev/root       7.2G  4.5G  2.5G  65% /
 devtmpfs        483M     0  483M   0% /dev
 /dev/mmcblk0p1   60M   21M   40M  35% /boot

Pour rappel, initialement on avait

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
 /dev/root       7.2G  5.6G  1.4G  81% /
 devtmpfs        483M     0  483M   0% /dev
 /dev/mmcblk0p1   60M   21M   40M  35% /boot

Au final, j’ai donc gagné 16% d’espace disque sur un total de 8Go de ma carte SD.

IV. (Ré)installation de l’interface graphique

Une des raisons pour laquelle certains d’entre vous souhaite réinstaller l’interface graphique, c’est généralement pour essayer un autre environnement de bureau (DE, Desktop Environment).

Afin de vous aider à tout remettre en place « presque » comme avant, commencer par faire une rechercher sur les DEs qui peuvent s’installer sur votre système. Installer ensuite la version « core », c’est à dire la version minimale de cet environnement, afin de n’installer que le néssaire sans les paquets inutiles comme les jeux Gnomes qui nous prennent de l’espace pour rien.

Pour réinstaller Mate,

$ sudo aptitude install mate-desktop-environment-core

Je recommande ensuite d’installer un navigateur internet, un terminal et peut-être un éditeur de texte. Pour les plus curieux, je vous propose d’essayer l’outil webmin.

Sources:

What is MATE?
aptitude, apt-get, and apt Commands
7 Linux Grep OR, Grep AND, Grep NOT Operator Examples
apt-get / apt-cache comparés à aptitude

Ajout d’un disque dur externe et migration de données

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 8. Ajout d’un disque dur externe et migration de données

Je vous ai parlé de sécurité tout au long des différents chapitres précédents. Au risque de vous décevoir, ce ne serait pas pour la dernière fois que je vais vous en parler de méthodes qui pourraient améliorer la sécurité sur vos serveurs.

Dans le chapitre 2, nous avons installé Owncloud avec les options par défaut, dans le répertoire racine du serveur apache, c’est à dire dans le dossier « /var/www/html/ ». Ceci dans le but de simplifier l’installation et la configuration de Owncloud pour les non-initiés.

Sachez que ce choix est loin d’être le meilleur. Ci-dessous je vais essayer de vous aider à migrer vos dossiers et configurations vers la nouvelle destination.
Si vous ne vous sentez pas à l’aise pour le faire, le meilleur choix serait de faire une nouvelle installation, puis de bien choisir les options qui vous intéressent, entre autre l’emplacement pour installer Owncloud ainsi que celui où placer les données.

/!\ Personnelement, je pense qu’il faut réinstaller Owncloud.
Ce chapitre est donc conçu à titre informative, pour vous aider à être un peu plus à l’aise avec les différentes manipulations sous linux.

I. Installation dans le dossier racine de Apache

Ceci est juste un petit rappel de la méthode décrite dans le chapitre 2. Ici, Owncloud a été installé directement dans le dossier racine par défaut du serveur Apache, c’est à dire dans /var/www/html. Comme je l’ai dit plus haut, ce n’est pas le meilleur choix, mais il est intéressant de le faire afin de pouvoir suivre les différentes étapes pour apprendre comment migrer les différentes informations de notre serveur Owncloud.
Si vous ne l’avez pas encore remarqué, le répertoire /var/www/html ainsi que son contenu, appartient par défaut à l’utilisateur root. Faites donc très attention à y appliquer un utilisateur sans privilège (ici www-data) à ce dossier.

raspi$ ls -al /var/www/html/
total 28288
drwxr-xr-x  4 root     root         4096 Apr  8 19:07 .
drwxr-xr-x  3 root     root         4096 Jan  4 20:19 ..
-rw-r--r--  1 www-data www-data     12 Apr  3 23:21 index.html
drwxr-xr-x 15 www-data www-data     4096 Apr  8 18:32 owncloud
drwxr-xr-x  2 root     root         4096 Apr 19 22:58 .well-known

Ceci dit, afin de limiter la casse si jamais il y a accès non autorisé à votre serveur, donner donc le minimum de permission à l’utilisateur Owncloud pour que ce dernier n’ait pas accès au reste du système. Cet utilisateur ne doit absolument pas avoir des mêmes privilèges que n’importe quel utilisateur de votre système dont la liste ne se limite pas seulement à l’utilisateur root, ou l’utilisateur principal que j’ai appelé USERNAME depuis de début de cette série d’article.

Noter que le choix du nom de l’utilisateur Owncloud n’a pas d’importance. Par défaut, l’utilisateur Apache doit appartenir au groupe www-data, et c’est par soucis de simplicité que j’ai choisi un utilisateur Apache de même nom que le groupe.

II. Installation dans le dossier /home

Pour ceux qui sont un peu plus sceptique concernant l’efficacité du choix proposé par défaut, un autre choix serait d’installer Owncloud dans /home. Ne l’oubliez pas que l’utilisateur Owncloud ne doit pas avoir les mêmes permissions que n’importe quel utilisateur du système (ie root, USERNAME, etc.).
Ce choix d’installation dans /home est un bon choix pour les utilisateurs qui ne trouvent pas pratique de travailler dans un répertoire qu’ils n’ont pas choisi.
Il est fort probable que vous avez déjà installé Owncloud dans le dossier racine de Apache, c’est à dire dans /var/www/html/owncloud. Ce n’est pas grave, je vais vous indiquer comment effectuer la migration de vos configurations et données, vers un autre répertoire de votre choix.

Migrations du répertoire Owncloud dans /home

Etape 1: Arrêter le serveur web

Arrêter le serveur Apache avant de migrer vos données.

raspi$ sudo service apache2 stop

Etape 2: Commencer la migration des données

Créer un répertoire de travail Owncloud, puis y appliquer les permissions pour l’utilisateur www-data.

raspi$ mkdir /home/USERNAME/www-dev

Migrer vos données et configurations Owncloud.

raspi$ sudo cp -rv /var/www/html/owncloud /home/USERNAME/www-dev

Appliquer et vérifier les nouvelles permissions.

raspi$ chown -R www-data:www-data /home/USERNAME/www-dev

raspi$ ls -l /home/USERNAME | grep www-dev
drwxr-xr-x 2 www-data www-data 4096 Jul 10 14:21 www-dev
$ ls -l /home/USERNAME/owncloud
total 168
drwxr-xr-x 28 www-data www-data  4096 Jul 10 14:30 3rdparty
drwxr-xr-x 21 www-data www-data  4096 Jul 10 14:31 apps
-rw-r--r--  1 www-data www-data   477 Jul 10 14:31 AUTHORS
drwxr-xr-x  2 www-data www-data  4096 Jul 10 14:30 config
-rw-r--r--  1 www-data www-data  3017 Jul 10 14:31 console.php
-rw-r--r--  1 www-data www-data 34520 Jul 10 14:31 COPYING-AGPL
drwxr-xr-x 19 www-data www-data  4096 Jul 10 14:31 core
-rw-r--r--  1 www-data www-data  5915 Jul 10 14:31 cron.php
drwxr-x---  5 www-data www-data  4096 Jul 10 14:31 data
-rw-r--r--  1 www-data www-data 23886 Jul 10 14:31 db_structure.xml
-rw-r--r--  1 www-data www-data   179 Jul 10 14:31 index.html
-rw-r--r--  1 www-data www-data  2026 Jul 10 14:31 index.php
-rw-r--r--  1 www-data www-data  2595 Jul 10 14:31 indie.json
drwxr-xr-x  3 www-data www-data  4096 Jul 10 14:31 l10n
drwx--x---  3 www-data www-data  4096 Jul 10 14:30 letsencrypt
drwxr-xr-x  6 www-data www-data  4096 Jul 10 14:31 lib
-rw-r--r--  1 www-data www-data   283 Jul 10 14:31 occ
drwxr-xr-x  2 www-data www-data  4096 Jul 10 14:31 ocs
drwxr-xr-x  2 www-data www-data  4096 Jul 10 14:31 ocs-provider
-rw-r--r--  1 www-data www-data  2969 Jul 10 14:31 public.php
-rw-r--r--  1 www-data www-data  4521 Jul 10 14:31 remote.php
drwxr-xr-x  3 www-data www-data  4096 Jul 10 14:32 resources
-rw-r--r--  1 www-data www-data    26 Jul 10 14:31 robots.txt
drwxr-xr-x 13 www-data www-data  4096 Jul 10 14:31 settings
-rw-r--r--  1 www-data www-data  1817 Jul 10 14:31 status.php
drwxr-xr-x  3 www-data www-data  4096 Jul 10 14:30 themes
-rw-r--r--  1 www-data www-data   233 Jul 10 14:31 version.php

Renommer l’ancien repértoire Owncloud au lieu de le suppprimer.

raspi$ sudo mv /var/www/html/owncloud /var/www/html/owncloud_original

Etape 3: Indiquer le nouveau chemin d’accès vers Owncloud au Serveur Web

Vu que notre serveur Owncloud a changé de répertoire, il faut indiquer au serveur web comment y accéder. Pour celà, il suffit de créer un lien symbolique dans /var/www/html.

raspi$ sudo ln -s /home/USERNAME/www-dev/owncloud /var/www/html/owncloud

raspi$ chown -R www-data:www-data /var/www/html/owncloud

Etape 4: Relancer le serveur web Apache

Relancer le server web, puis essayer d’accéder à l’URL de votre serveur Owncloud.

$ sudo service apache2 start

Tout devrait être bon, et vous ne devriez pas avoir de problèmes de permission.

III. Déplacer le dossier Data de la carte SD vers un disque dur externe

Pourquoi direz vous qu’il est préférable d’installer les données de Owncloud sur un support extérieur au raspberry pi?
Il y a au moins deux raisons à celà. Notez tout d’abord que l’espace disponible sur une carte SD est assez limitée. Puis ayez en tête que la durée de vie d’une carte SD est beaucoup plus courte en comparaison de celle d’un disque mécanique (HDD ou SDD). Si je peux, je vais aussi évoquer le fait que monter et démonter un disque dur externe ne nécessite pas un arrêt total du raspberry pi dans le cas où vous pensez remplacer le support physique sur lequel est enregistré vos données.

/!\ Je tiens à préciser que le disque dur doit être fourni avec une alimentation externe, puisque le raspberry pi n’est pas assez puissant pour pour alimenter un autre appareil via son port USB.

Etape 1: Partitionner le disque dur externe

Brancher maintenant votre disque dur sur l’un des ports USB du raspberry pi. Puis identifier les différentes partitions.

raspi$ sudo fdisk -l
!--Sortie Tronquée--!
Device         Boot  Start     End Sectors  Size Id Type
/dev/mmcblk0p1        8192  131071  122880   60M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      131072 2848767 2717696  1.3G 83 Linux
!--Sortie Tronquée--!

Device     Boot Start     End Sectors  Size Id Type
/dev/sda1        2048 3907028991 3907026944  1.8T 83 Linux

« Rappel sur la désignation des partitions

Les périphériques sont désignés par le système par des fichiers dans le répertoire /dev/.
Les périphériques de stockage seront donc reconnus par /dev/sda, /dev/sdb, etc.
Les partitions sont désignées par leur numéro dans le disque (/dev/sda1, /dev/sda2, …)
Les partitions peuvent aussi être reconnues par leur UUID et leur label. » (lu sur ubuntu-fr.org)

Le disque qui nous intéresse est celui en /dev/sda, et contient déjà une partition (/dev/sda1) qu’on va supprimer avant d’en créer une nouvelle. Les autres partitions (/dev/mmcblk0p[number]) sont ceux de la carte SD du raspberry pi, qu’il ne faut surtout pas toucher.
Pour partitionner ce disque, plusieurs outils sont à votre dispositions. Entre autre, il y a fdisk et cfdisk. Je préfère utiliser fdisk qui ne nécessite pas l’utilisation des flèches pour se déplacer sur la page, et qui me permet donc d’aller plus vite dans le partionnement du disque.
Pour plus d’information sur ces différentes commandes, n’hésitez pas à visiter la page « Partitionner son disque dur en ligne de commande« .

/!\ Les commandes ci-dessous vont supprimer tout le contenu de votre disque. Faites donc bien attention à ce que vous faites.

raspi$ sudo fdisk /dev/sda

Command (m for help): p
Disk /dev/sda: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xec7a7cb7

Device     Boot Start        End    Sectors  Size Id Type
/dev/sda1        2048 3907028991 3907026944  1.8T 83 Linux

Supprimer la ou les partitions de votre disque dur externe, ici /dev/sda1.

Command (m for help): d
Selected partition 1
Partition 1 has been deleted.

Vérifier que la ou les partitions ont bien été supprimées.

Command (m for help): p
Disk /dev/sda: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xec7a7cb7

Créer ensuite une nouvelle partition. Sur mon disque de 2To, je ne vais utiliser que la moitié pour l’instant.

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-3907029166, default 2048): 
Last sector, +sectors or +size{K,M,G,T,P} (2048-3907029166, default 3907029166): +1T

Created a new partition 1 of type 'Linux' and of size 1 TiB.

Vérification.

Command (m for help): p
Disk /dev/sda: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xec7a7cb7

Device     Boot Start        End    Sectors Size Id Type
/dev/sda1        2048 2147485695 2147483648   1T 83 Linux

Enregistrer les modifications et quitter fdisk.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Voyons ce que çà donne avec la commande fdisk.

raspi$ sudo fdisk -l
!--Sortie Tronquée--!
Device     Boot Start        End    Sectors Size Id Type
/dev/sda1        2048 2147485695 2147483648   1T 83 Linux

Je n’ai utilisé que 1To d’espace disque pour les données. Je réserve le reste d’espace disponible pour une utilisation ultérireure.

Etape 2: Formatez le disque

Formatez la nouvelle partition en un système de fichier EXT4.

raspi$ sudo mkfs.ext4 /dev/sda1

Noter que la méthode « sudo mkfs -t /dev/sda1 » est à déprécier (voir « man mkfs » ).

Si vous n’êtes pas à l’aise avec les lignes de commandes pour partitionner et formater un disque, l’outil graphique GParted est votre ami.

Etape 3: Monter le disque dur externe

Vérifier encore une fois que vous voyez toutes les partitions, et plus particulièrement celle en /dev/sda1.

raspi$ sudo fdisk -l

Créer maintenant un point de montage, c’est à dire qu’il nous faut un nom de dossier à partir duquel on pourra accéder au disque. Je n’ai pas à préciser que ce dossier doit être impérativement vide.

raspi$ sudo mkdir /mnt/owncloud

Ne créer surtout pas de dossier nommé « data » sous /mnt/owncloud, pour éviter d’avoir un sous-dossier data à l’intérieur même du dossier du même nom. Ce qu’on veut c’est un dossier /mnt/owncloud/data/ et non /mnt/owncloud/data/data/.

Il est temps de monter le disque dur externe dans le répertoire indiqué.

raspi$ sudo mount /dev/sda1 /mnt/owncloud

Vérifier ensuite que le disque est bien monté.

raspi$ df -HT
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4      7.8G  4.9G  2.6G  66% /
devtmpfs       devtmpfs  506M     0  506M   0% /dev
tmpfs          tmpfs     511M     0  511M   0% /dev/shm
tmpfs          tmpfs     511M  7.0M  504M   2% /run
tmpfs          tmpfs     5.3M  4.1k  5.3M   1% /run/lock
tmpfs          tmpfs     511M     0  511M   0% /sys/fs/cgroup
/dev/mmcblk0p1 vfat       63M   22M   42M  35% /boot
tmpfs          tmpfs     103M     0  103M   0% /run/user/1000
/dev/sda1      ext4      1.1T   75M  1.1T   1% /mnt/owncloud

Vous vous êtes certainement posé la question, à un moment ou à un autre, s’il faut choisir /mnt ou /media dans lequel il faut monter notre disque externe. Il y a pas mal de débat sur internet là dessus, mais cet article m’a convaincu qu’il faut choisir /mnt lorsqu’on monte manuellement un disque et qui, de plus, si le disque est supposé rester connecté en permanence au raspberry pi.

Etape 4. Migrer le dossier DATA

Migrer uniquement données du dossier DATA vers le disque dur externe. Et surtout, n’oubliez pas d’éteindre le serveur web avant d’aller plus loin.

Avant de se lancer dans le test, je me suis connecté à l’URL de mon Owncloud (http://localhost) avec un utilisateur de test (Username). Puis j’ai téléversé la video de Bug Bunny. Si tout va bien, à la fin de la migration, je devrai pouvoir télécharger et téléversion des fichiers avec mon utilisateur de test. Vérifions celà.

Selection_006
fig 1. Fichier de test dans Owncloud

Arrêter le serveur web.

raspi$ sudo service apache2 stop

Migrer les données vers la nouvelle partition.

raspi$ sudo cp -rv /var/www/html/owncloud/data /mnt/owncloud

raspi$ mv /var/www/html/owncloud/data var/www/html/owncloud/data_original

raspi$  sudo chown -R www-data:www-data /mnt/owncloud/data

Etape 5: Mettez à jour les informations des serveurs PHP

Mettez à jour le fichier de config.php pour y indiquer la nouvelle route pour atteindre le dossier DATA.

raspi$ vim /var/www/tml/howncloud/config/config.php

Remplacer ‘datadirectory’ => ‘/var/www/owncloud/data‘
Par ‘datadirectory’ => ‘/mnt/owncloud/data‘.

Etape 6: Mettez à jour les informations des serveurs Apache

De même que pour le serveur PHP, modifier les informations de owncloud.conf.

raspi$ sudo vim /etc/apache2/sites-available/owncloud.conf


!--sortie tronquée--!
    <Directory "/mnt/owncloud/data">
	# just in case if .htaccess gets disabled
	Require all denied
    

Etape 7: Redémarrer le serveur web

Relancer le server Apache.

raspi$ service apache2 start

Etape 8: monter automatiquement le disk dur externe

Si vous négligez cette étape, vous risque de ne plus avoir accès à vos données après redémarrage du raspberry pi, si vous oubliez de monter votre disque. De ce fait, il est préférable de le monter automatiquement afin d’éviter ce genre de désagrément.

Lancer la commande blkid afin d’identifier la partition qui nous intéresse et de récupérer son UUID.

raspi$ sudo blkid 
/dev/sda1: UUID="55ec24c7-c730-4689-9811-f1158362ea3c" TYPE="ext4"

Noter l’UUID: 55ec24c7-c730-4689-9811-f1158362ea3c
Editer le fichier /etc/fstab:

raspi$ sudo cp /etc/fstab /etc/fstab_original

raspi$ sudo vim /etc/fstab

Ajouter les informations du disque à monter à la dernière ligne de la page. Quand c’est indiqué [TAB], c’est qu’il faut appuyer sur la touche Tabulation du clavier.

UUID=55ec24c7-c730-4689-9811-f1158362ea3cd [TAB] /mnt/owncloud [TAB] ext4 [TAB] defaults,nofail [TAB] 0 [TAB] 2

D’après les notes dans cet excellent article, l’auteur a du ajouter l’option NOFAIL pour résoudre le problème de redémarrage du raspberry pi, du au fait que le disque dur externe met trop de temps à se monter, ce qui empêche le démarrage du système.

L’option DEFAULTS, inclue l’option automount de la nouvelle partition. Cet option utilise les configurations par défaut en une seule commande au lieu de rentrer la série d’option suivante: rw, suid, dev, exec, auto, nouser, async.

Et comme d’habitude, si vous ne vous sentez pas à l’aise avec les lignes de commandes,vous pouvez toujours utiliser un outil graphique commme disk-manager par exemple.

Etape 9: Test de vérification

Connectez vous à l’URL de votre Owncloud, puis faites les tests ci-dessous pour vérifier si la migration des données s’est bien déroulée, et que vous avez toujours ajouter ou supprimer des fichiers.
Comme vous pouvez le constater au niveau de la figure 2, nous avons toujours la vidéo de Bunny, ainsi qu’on a téléversé un nouveau fichier et tout s’est bien déroulé.

Selection_008
fig 2. Ajout d’un nouveau fichier

L’espace disque disponible est bien celui auquel on s’attend.

Selection_009
fig 3. Vérification de l’espace disponible

Le test suivant consite à redémarrer le raspberry pi, puis de vérifier si le disque dur externe est monté automatiquement suite à ce redémarrage.

raspi$ sudo reboot

Attendez une bonne petite vingtaine de secondes, puis reconnectez vous de nouveau en ssh au raspberry pi. N’hésitez pas à pinger l’appareil pour vérifier qu’il est accessible ou non.

Taper la commande

raspi$ df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.2G  4.6G  2.4G  66% /
devtmpfs        483M     0  483M   0% /dev
tmpfs           487M     0  487M   0% /dev/shm
tmpfs           487M  6.6M  481M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           487M     0  487M   0% /sys/fs/cgroup
/dev/mmcblk0p1   60M   21M   40M  35% /boot
/dev/sda1      1008G  341M  957G   1% /mnt/owncloud
tmpfs            98M     0   98M   0% /run/user/1000

Si vous voyez la partion /dev/sda1 monté comme prévu, et ben je n’ai rien à ajouter de plus. Féliciation! Ce chapitre est terminé pour vous.

Sources et Références

How to set/change data directory
Deplacer le contenu de /var/www/html vers /home/USERNAME/
comment migrer uniquement les donnees dans home
Raspberry Pi OwnCloud 9 (Drop box Clone)
Install OwnCloud on your Raspberry Pi
Simple Owncloud Installation on Raspberry Pi 2
Owncloud and an external hard drive
What’s the most “correct” mount point for a permanent NTFS partition?
Ubuntu: Mount The Drive From Command Line
Comment ajouter un nouveau disque dur
How to set/change data directory
Le montage des systèmes de fichiers
Raspberry Pi External Storage Part 1 – Step by Step Permanent External Hard Drive (plus OwnCloud Adjustments)

Let’s Encrypt (LE)

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 7. Let’s Encrypt (LE)

Certificats & CA

Dans un des chapitres précédents, je vous ai fait installé un Certificat auto-signé (self-signed certificate). Ce qui fait qu’à chaque fois que vous vous connectez à votre page, vous auvez droit à un message d’avertissement comme ci-dessous.

036

Pour éviter ce genre de désagrément, il vous faudra un certificat signé par une autorité de certification (CA). Malgré le fait qu’un site présente un certificat auto-signé ou signé par un CA, garder en tête que rien ne prouve que le site visité est bel et bien émis par son propriétaire. Cependant, la présence de certificats apporte une assurance que les communications avec le serveur sont chiffrées.

Let’s Encrypt est un très bon choix de CA, puisque ce dernier offre des certificats gratuits qui de plus, ssont reconnus par la plupart des navigateurs internets, etc, sans oublier que le projet est soutenu par pas mal d’entreprises de poids, dont la liste se trouve ici.

Installation et configuration de Let’s Encrypt

Letsencrypt se trouve dans le dépot Jessie-backport de debian, mais nous n’allons pas l’installer avec la méthode conventionnelle.

Il faut savoir qu’une fois lestencrypt installé et, surtout en fonction des options d’installation choisies, ce dernier peut modifier les configurations de vos différents serveurs (serveur web, serveur owncloud, etc.) en fonction de ces besoins. Deuxième point à prendre en compte, c’est que cette application étant toujours en mode Béta, si vous n’êtes pas confortable avec l’utilisation de logiciels ou d’applications en mode Béta, passer votre chemin.

Le plugin Webroot, anciennement appelé simplefs, est la meilleure option à choisir, pour pouvoir garder entièrement le contrôle sur chacun de nos serveurs, sans que letsencrypt s’y mèle lors de l’installation, et même après. Avec ce plugin, le client letsencrypt ne fera rien de plus que ce qu’on lui demande de faire, c’est à dire de créer/ renouveller/révoquer un certificat.

Allons-y pour l’installation.

1. Créer un dossier pour l’installation de letsencrypt

$ sudo mkdir -p /var/www/html/owncloud/letsencrypt/.well-known/acme-challenge

Vérifier les permissions, puis restreindre au maximum ce qu’on peut.

$ ls -l /var/www/html/owncloud/
drwxr-xr-x 3 root root 4096 Apr 8 16:58 letsencrypt

$ sudo chown -R www-data:www-data /var/www/html/owncloud/letsencrypt

$ sudo chmod -R 750 /var/www/html/owncloud/letsencrypt

2. Lancer l’installation

Installer le paquet « git » dans un premier temps, qu’on utilisera pour télécharger le client Let’s Encrypt par la suite.

$ sudo apt-get install git

Télécharger une copie conforme du dossier officiel Let’s Encrypt à partir de github, à placer dans le dossier /opt.

Petite note concernant le dossier /opt, sur un système à base de debian, on y place généralement les logiciels tierces, non compris dans les dépôts officiels, dans ce dossier.

$ cd /opt

$ sudo git clone https://github.com/letsencrypt/letsencrypt

$ ls /opt/letsencrypt
  acme
  letshelp-letsencrypt
  CHANGES.rst                     LICENSE.txt
  CONTRIBUTING.md                 linter_plugin.py
  docker-compose.yml              MANIFEST.in
  Dockerfile                      pep8.travis.sh
  Dockerfile-dev                  README.rst
  docs                            readthedocs.org.requirements.txt
  examples                        setup.cfg
  letsencrypt                     setup.py
  letsencrypt-apache              tests
  letsencrypt-auto                tools
  letsencrypt-auto-source         tox.cover.sh
  letsencrypt-compatibility-test  tox.ini
  letsencrypt-nginx               Vagrantfile

Avant d’aller plus loin, vérifions que la commande letsencrypt-auto fonctionne correctement, en lançant la commande de demande d’aide par exemple (« letsencrypt-auto –help » ou « letsencrypt-auto –help all »).

/opt/letsencrypt$ sudo ./letsencrypt-auto --help [all]
!---Tronquée---!
ca-certificates is already the newest version.
gcc is already the newest version.
gcc set to manually installed.
python is already the newest version.
The following extra packages will be installed:
  dh-python libexpat1-dev libmpdec2 libpython-dev libpython2.7-dev
  libpython3-stdlib libpython3.4-minimal libpython3.4-stdlib
  python-chardet-whl python-colorama-whl python-distlib-whl
  python-html5lib-whl python-pip-whl python-pkg-resources
  python-requests-whl python-setuptools-whl python-six-whl
  python-urllib3-whl python2.7-dev python3 python3-minimal
  python3-pkg-resources python3-virtualenv python3.4 python3.4-minimal
Suggested packages:
  augeas-doc augeas-tools python-distribute python-distribute-doc
  python3-doc python3-tk python3-venv python3-setuptools python3.4-venv
  python3.4-doc binfmt-support
Recommended packages:
  libssl-doc
!---Tronquée---!
Installing Python packages...
Installation succeeded.

Comme vous pouvez le constater, letsencrypt installe automatiquement toutes les dépendances dont il a besoin.

L’option « all » après l’instruction « –help », est optionnel, mais nous fournit plus d’information concernant les options disponibles avec la commande lestencrypt.
Si vous avez un résultat comme ci-dessus avec l’option « –help » ou « –help all », c’est que vous êtes bon pour poursuivre la procédure d’obtention de certificats signés par le CA, Let’s Encrypt.

3. letsencrypt-auto

Letsencrypt est un progamme écrit en python, qui se charge d’installer et de mettre à jour automatiquement tous les outils dont il a besoin comme on l’a vu plus haut. Pour l’utiliser, il suffit juste de se placer dans le dossier /opt/letsencrypt, puis de lancer la commande « ./letsencrypt-auto ».
Pour information, durant la phase Béta, le nombre de certificats émis par le CA (Let’s Encrypt), est assez limité. De ce fait, avant de lancer votre requête, faites un test pour vérifié que votre requête serait accordée ou non.

N’oubliez pas de désactiver la redirection http vers https, sinon vous allez avoir droit un message d’erreur du type:

044

Pour ce faire, ajouter un dièse ‘#’ devant l’instruction de redirection.

$ sudo vim /etc/apache2/site-availables/owncloud.conf

  ServerName linuxintosh.nsupdate.info
# Redirect permanent / https://.nsupdate.info

  LogLevel info ssl:warn

  ErrorLog /var/log/apache2/error.log
  CustomLog /var/log/apache2/access.log combined

N’oubliez pas de réactiver la redirection, une fois le certificat final obtenu. Ne vous inquiétez pas, je vais vous le rappeler un peu plus tard dans ce chapitre.

4. Test de vérification avant installation du certificat

Poursuivons notre aventure! Faisons un test de requête de certificat.

/opt/letsencrypt$ sudo letsencrypt-auto certonly --test-cert

Selectionner l’option 2 « Place files in webroot directory (webroot)

038

Entrez votre adresse email

039

Accepter les conditions d’utilisation

040

Entrer l’URL, .netlib.re par exemple, pour accéder à votre serveur Owncloud

041

Entrer le chemin du webroot, /var/www/html (sur Debian par défaut)

042

043

Vérifier le résultat

045

# ls /etc/letsencrypt/live/.netlib.re
  cert.pem chain.pem fullchain.pem privkey.pem

Si tout est bon et que le résultat de ce test vous convient, lancer maintenant l’installation.

5. Installation du certificat

Rappeler vous que je me suis enregistré sur deux domaines différents (netlib.re, et nsupdate.info qui est l’alias du premier). Il me faut donc un seul certificat qui serait valide pour ces deux domaines à la fois.

Afin d’automatiser un peu plus les la demande de certificat et d’éviter de retaper toutes les informations comme lors du test, j’ai ajouté d’autres paramètres à la commande letsencrypt-auto.

/opt/letsencrypt$ sudo ./letsencrypt-auto certonly \
  --agree-tos \
  --webroot \
  --webroot-path /var/www/html/ \
  --email admin@example.com \
  --domains .netlib.re \
  --domains .nsupdate.info

Pour une version allégée de la même commande,

/opt/letsencrypt $ sudo ./letsencrypt-auto certonly \
  --agree-tos \
  --webroot \
  -w /var/www/html/ \
  -m admin@example.com \
  -d .netlib.re \
  -d .nsupdate.info

046

Le message dit que vous avez déjà un certificat associé au même nom de domaine que celui entré manuellement, puis nous demande ce qu’on veut faire. J’ai choisi l’option 2, qui va remplacer/renouveller le certificat existant.

Si tout s’est bien passé, vous devriez avoir un message avec la date d’expiration de votre certificat, comme ci-dessous.

047

Le certificat signé par le CA va se placer ensuite dans le dossier /etc/letsencrypt/live/.

6. Vérification

Vérifions justement le contenu du dossier /etc/letsencrypt/live/, dans lequel doit se trouver toutes les clés générées par les commandes ‘letsencrypt’ ou ‘letsencrypt-auto’.

$ sudo ls -a /etc/letsencrypt/live/.netlib.re/
  . .. cert.pem chain.pem fullchain.pem privkey.pem
  • privkey.pem – clé privée à ne jamais partager avec personne
  • cert.pem – certificat du serveur uniquement
  • chain.pem – certificat pour root et intermédiaire uniquement
  • fullchain.pem – ensemble de tous les certificats (chain.pem + cert.pem)
$ sudo ls -l /etc/letsencrypt/live/.netlib.re/
  total 0
  lrwxrwxrwx 1 root root 45 Apr 19 22:58 cert.pem -> ../../archive/linuxintosh.netlib.re/cert3.pem
  lrwxrwxrwx 1 root root 46 Apr 19 22:58 chain.pem -> ../../archive/linuxintosh.netlib.re/chain3.pem
  lrwxrwxrwx 1 root root 50 Apr 19 22:58 fullchain.pem -> ../../archive/linuxintosh.netlib.re/fullchain3.pem
  lrwxrwxrwx 1 root root 48 Apr 19 22:58 privkey.pem -> ../../archive/linuxintosh.netlib.re/privkey3.pem 

$ sudo ls -l /etc/letsencrypt/archive/.netlib.re/
  total 48
  -rw-r--r-- 1 root root 1870 Apr 8 19:11 cert1.pem
  -rw-r--r-- 1 root root 1850 Apr 8 19:51 cert2.pem
  -rw-r--r-- 1 root root 1850 Apr 19 22:58 cert3.pem
  -rw-r--r-- 1 root root 1675 Apr 8 19:11 chain1.pem
  -rw-r--r-- 1 root root 1647 Apr 8 19:51 chain2.pem
  -rw-r--r-- 1 root root 1647 Apr 19 22:58 chain3.pem
  -rw-r--r-- 1 root root 3545 Apr 8 19:11 fullchain1.pem
  -rw-r--r-- 1 root root 3497 Apr 8 19:51 fullchain2.pem
  -rw-r--r-- 1 root root 3497 Apr 19 22:58 fullchain3.pem
  -rw-r--r-- 1 root root 1704 Apr 8 19:11 privkey1.pem
  -rw-r--r-- 1 root root 1704 Apr 8 19:51 privkey2.pem
  -rw-r--r-- 1 root root 1708 Apr 19 22:58 privkey3.pem 

$ sudo ls -l /etc/letsencrypt/keys/
  total 12
  -rw------- 1 root root 1704 Apr  8 19:11 0000_key-letsencrypt.pem
  -rw------- 1 root root 1704 Apr  8 19:51 0001_key-letsencrypt.pem
  -rw------- 1 root root 1708 Apr 19 22:58 0002_key-letsencrypt.pem

Pour information, /etc/letsencrypt/archive et /etc/letsencrypt/keys contiennent toutes les anciennes clés et certificats, par contre /etc/letsencrypt/live n’en contient que la dernière version.

Vérifier ensuite qu’il n’y a pas de fichiers qui traine dans le dossier .well-known/acme-challenge/. Si c’est le cas, supprimer tout ce qu’il contient comme information.

$ sudo -s
# rm /var/www/owncloud/letsencrypt/.well-known/acme-challenge/*

 

Mise-à-jour des informations de Owncloud

1. Réactiver la redirection HTTP vers HTTPS

Une fois que votre certificat émis, supprimer le dièse ‘#’ devant « Redirect » afin de pouvoir rediriger de nouveau, les traffics HTTP vers HTTPs.

$ sudo vim /etc/apache2/site-availables/owncloud.conf

  ServerName linuxintosh.nsupdate.info
  Redirect permanent / https://.nsupdate.info

  LogLevel info ssl:warn

  ErrorLog /var/log/apache2/error.log
  CustomLog /var/log/apache2/access.log combined

2. Mettre à jour les informations du vHost avec le nouveau certificat signé

Désactiver les certificats auto-signés puisqu’on n’en a plus besoin, puis ajouter le chemin d’accès aux clés et chaînes généré par Let’s Encrypt, dans le fichier de configuration de owncloud.

$ sudo vim /etc/apache2/sites-available/ownCloud.conf

  # Self-signed certificate
  #
  #SSLCertificateFile /etc/ssl/localcerts/owncloud.pem
  #SSLCertificateKeyFile /etc/ssl/localcerts/owncloud.key

  # Let's Encrypt certificate
  #
  SSLCertificateFile /etc/letsencrypt/live/.netlib.re/cert.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/.netlib.re/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/live/.netlib.re/fullchain.pem

  # Certificate signed by CA
  #
  #SSLCACertificateFile /Path/to/CA/Certificate
  #SSLVerifyDepth 2

3. Vérifier l’état de connection à votre page

Vous devriez pouvoir accéder directement à votre page, sans avoir à valider quoi que ce soit.

048
Navigateur – Chromium

049

 Navigateur – Firefox

4. Un petit test de plus!

Une fois n’est pas coutume, lancer de nouveau un test sur Qualys SSL Labs et voyer le résultat.

060
Cette fois ci, le test passe et j’obtient un A+ comme note. Youpiii!

Quelques informations supplémentaires

1. Renouvellement du certificat

Le certificat signé par Let’s Encrypt n’est valide que pour une durée de 90jours maximum. Il est donc préférable de s’y prendre un peu à l’avance pour mettre à jour notre certificat. Vous pouvez le faire de façon manuelle ou automatique.

Avec la méthode manuelle, taper dans une console,

/opt/letsencrypt$ sudo ./letsencrypt-auto renew
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  sudo /home/USERNAME/.local/share/letsencrypt/bin/letsencrypt renew

  -------------------------------------------------------------------------------
  Processing /etc/letsencrypt/renewal/.netlib.re.conf
  -------------------------------------------------------------------------------

  The following certs are not due for renewal yet:
  /etc/letsencrypt/live/.netlib.re/fullchain.pem (skipped)
  No renewals were attempted.

Par contre je n’ai pas réussi à faire fonctionner le renouvellement automatique avec CRON. J’ai essayé plusieurs fois, mais j’ai des doutes sur la fonctionnalité de la commande ci-dessous, bien qu’en théorie, çà devrait marcher.

$ sudo crontab -e
  #Minute Hour Day of Month Month Day of Week Command
  #(0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)

  crontab
  * * */1 * * /opt/letsencrypt/letsencrypt-auto renew >> /var/log/apache2/letsencrypt-renew.log 2>&1

Ici, Cron doit exécuter la commande « letsencrypt-auto renew » une fois par jour. A chaque exécution de cette commande, je devrais avoir une information dans le fichier /var/log/apache2/letsencrypt-renew.log, ainsi qu’un email doit être envoyé du serveur, mais nada.
J’ai noté qu’en y apportant une petite modification dans la commande, comme par exemple, si je veux effectuer une requête de renouvellement de certificats à la minute, la commande semble fonctionner après quelques bidouilles. Je ne vais pas trop tarder dessus. Je pense avoir effectué suffisament de test pour vérifier que la commande de renouvellement de certificat fonctionne sans problème, mais couplée avec cron, rien ne va plus!

Voici ce que j’ai réussi à récupérer dans les logs quand çà fonctionne.

/var/log/apache2$ cat letsencrypt-renew.log
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  /root/.local/share/letsencrypt/bin/letsencrypt renew

  -------------------------------------------------------------------------------
  Processing /etc/letsencrypt/renewal/.netlib.re.conf
  -------------------------------------------------------------------------------

  The following certs are not due for renewal yet:
  /etc/letsencrypt/live/.netlib.re/fullchain.pem (skipped)
  No renewals were attempted.

Dans les notes sur la page officielle de Let’s Encrypt, il est dit qu’ils vont sortir un script bientôt pour automatiser la tâche de renouvellement des certificats.

Sinon, utiliser l’installeur Apache ou Nginx au lieu de Webroot comme j’ai procédé dans cet article. Ces installeurs vont gérer directement le renouvellement des certificats, sans que vous ayez à vous soucier de quoi que ce soit.

2. Révocation du certificat

Si pour une raison quelconque, vous souhaitez révoquer votre certificat de Let’s Encrypt, taper la commande ci-dessous en précisant le nom de domaine concerné.

/opt/letsencrypt$ sudo ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/.netlib.re/cert.pem
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/.netlib.re/cert.pem

Vous n’aurez pas de confirmation de révocation du certificat. Par contre, si vous retaper exactement la même commande, vous allez avoir un message vous prévenant que le certificat a déjà été révoqué.

/opt/letsencrypt$ sudo ./letsencrypt-auto revoke --cert-path /etc/letsencrypt/live/linuxintosh.netlib.re/cert.pem
  Checking for new version...
  Requesting root privileges to run letsencrypt...
  /root/.local/share/letsencrypt/bin/letsencrypt revoke --cert-path /etc/letsencrypt/live/.netlib.re/cert.pem
  An unexpected error occurred:
  The request message was malformed :: Certificate already revoked
  Please see the logfiles in /var/log/letsencrypt for more details.

Vous pouvez le vérifier en accédant à votre page.

061

3. Mise-à-jour du client letsencrypt

Pour mettre à jour le client letsencrypt, accéder au dossier /opt/letsencrypt, puis taper la commande « git pull ».

$ cd /opt/letsencrypt
$ sudo git pull

N’oubliez pas que le client Let’s Encrypt est toujours en mode Béta. Prennez donc le temps de visiter la page officielle de Let’s Encrypt pour lire les informations sur les dernières mise-à-jour.

Les articles ci-dessous sont très intéressants. Je ne peux que vous le recommander. Si l’anglais vous rébute, utilisez l’outil itool de Google pour traduire ces pages.

Why Use a Certificate?
Fishing for Hackers: Analysis of a Linux Server Attack

Sources et Références

User script location in Debian
Fully automate Let’s Encrypt certificate on Debian using central webroot Folder
Client certificate authentication
Apache directives
Set server wide ssl configuration
Install Let’s Encrypt to Create SSL Certificates
Crontab generator
Missing Docs for cert.pem, chain.pem, fullchain.pem, etc #608
Where are my certificates?

Les fichiers journaux

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 6. Les fichiers journaux

Vous vous êtes peut-être demandé où se situe les fichiers journaux (logs) sur votre serveur? C’est ce que je vais traiter dans cette partie. Je ne vais cependant pas me limiter à celà, puisque je vais vous aider à configurer un serveur SMTP pour automatiser l’envoie de certains fichiers journaux par courrier (email).
Je n’ai pas beaucoup parlé des fichiers journaux jusque ici. Pourtant, ces derniers sont très important, surtout pour la compréhension et l’aide au dépannage des problèmes qui peuvent survenir sur nos serveurs.

Où sont enregistré les messages d’erreur du serveur Apache?

Soyons curieux et jettons un coup d’oeil dans le fichier de configuration de /etc/apache2/apache2.conf. Faites une recherche avec le mot clé ErrorLog.

Voici ce que vous devriez trouver.

# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a 
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a 
# container, that host's errors will be logged there and not here.
#
ErrorLog ${APACHE_LOG_DIR}/error.log

#
# LogLevel: Control the severity of messages logged to the error_log.
# Available values: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the log level for particular modules, e.g.
# "LogLevel info ssl:warn"
#
LogLevel warn

Ici, il est précisé que les messages d’erreurs doivent se trouver dans le dossier donné par la variable ${APACHE_LOG_DIR}/.Pour avoir des informations sur les variables dans apache, ouvrez donc le fichier /etc/apache2/envvars et faites une recherche encore une fois.

# Only /var/log/apache2 is handled by /etc/logrotate.d/apache2.
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX

Comme on le voit ici, tous les fichiers de log vont être sauvegardés dans le dossier /var/log/apache2/.

Voyons maintenant ce que contient le fichier /var/log/apache2.

$ ls /var/log/apache2
access.log
access.log.1
access.log.X.gz
!---tronquée---!
error.log
error.log.1
error.log.Y.gz
!---tronquée---!
other_vhosts_access.log

On note qu’il y a trois types de fichiers, que je vais présenter un par un ci-dessous.

1. Apache Error Log File
Ce fichier de log (ou fichier journal) contient tous les détails de ce qui s’est mal passé sur le serveur Apache (messages d’erreurs), ainsi que les information de diagnostic, pour y remédier.

2. Apache Access Log File
Le serveur Apache enregistre toutes les requêtes entrantes dans ce fichier journal.

3. Apache vHosts Access File
Les requêtes entrantes en destinations des différents hôtes virtuels y sont enregistrées dans ce fichier.

Maintenant qu’on a vu où sont enregistrés les fichiers journaux, il faut qu’on précise aussi quel niveau d’alerte doit être récupé. Vous avez différents niveaux, mais par défaut, Apache récupère tous les alertes de type WARN.

# emerg : Messages Urgents - Le système est inutilisable
# alert : Messages d’actions qui doivent être effectuées immédiatement
# crit : Messages critiques
# error : Messages d’erreur
# warn : Messages d’avertissement (par défaut)
# notice: Messages normaux mais significatives
# info : Messages d’informations
# debug : Messages de débogage
# trace[1-8]

Et, en ce qui concerne les hôtes virtuels?

Pour pour chaque hôte virtuel, vous pouvez aussi définir quel type d’information vous souhaitez voir dans les fichiers journaux, le niveau d’alerte ainsi que le dossier où les enregistrer.

La template pour s’inspirer des informations à placer dans notre fichier owncloud.conf, se trouve dans le fichier /etc/apache2/sites-enabled/000-default.conf.

$ sudo vim /etc/apache2/sites-available/owncloud.conf

	ServerName .MonDomai.ne
	Redirect permanent / https://.MonDomai.ne

	LogLevel info ssl:warn

	ErrorLog /mon/dossier/error.log
	CustomLog /mon/dossier/access.log combined

Dans cet exemple, nous allons récupérer tous les traffics en HTTPS (level Warning), ainsi que les traffics autre que ceux utilisant le protocol TLS/SSL (level Info), vers notre serveur Owncloud ainsi que ceux en destination de notre serveur Apache.
Je vais m’arrêter ici sans rentrer dans les détails. Vous pouvez toujours lire l’article sur les fichier journaux Apache si vous souhaitez en savoir un peu plus.

Comment faire pour recevoir par courriel, certains fichiers journaux?

Déjà, avant d’aller plus loin, il faut se poser la question de l’utilité d’envoie des fichiers journaux par courriel. Chaque administrateur a sa propre raison de le faire. Personnelement, j’aime bien recevoir par courriel, toutes les activités qui se passent sur mon serveur. Logwatch est de ce fait, un très bon choix.

Installation et configuration de Logwatch

Logwatch est au fait, un script écrit en perl. Son installation et sa configuration est très simple comme nous allons le voir ci-dessous.

$ sudo apt-get install logwatch
!---Tronquée---!
The following extra packages will be installed:
bsd-mailx exim4-base exim4-config exim4-daemon-light libdate-manip-perl
liblockfile-bin liblockfile1 libsys-cpu-perl
Suggested packages:
mail-reader eximon4 exim4-doc-html exim4-doc-info spf-tools-perl swaks
fortune-mod
Recommended packages:
mailx
Vérifier que le programme fonctionne correctement.
$ logwatch
 ################### Logwatch 7.4.0 (03/01/11) #################### 
        Processing Initiated: Wed Apr 13 22:32:28 2016
        Date Range Processed: yesterday
                              ( 2016-Apr-12 )
                              Period is day.
        Detail Level of Output: 0
        Type of Output/Format: stdout / text
        Logfiles for Host: raspi
 ################################################################## 
 
 --------------------- httpd Begin ------------------------ 

 Connection attempts using mod_proxy:
    a.b.c.d -> www.xxxxxxx.com:port: 1 Time(s)
    e.f.g.h -> www.yyyyyyy.com:port: 4 Time(s)
 
!--Tronquée--!
 
 ---------------------- httpd End ------------------------- 

 
 --------------------- pam_unix Begin ------------------------ 

 sudo:
    Authentication Failures:
       USERNAME(1000) -> USERNAME: 1 Time(s)
    Sessions Opened:
       USERNAME -> root: 14 Time(s)
 
 systemd-user:
    Unknown Entries:
       session closed for user USERNAME: 3 Time(s)
       session opened for user USERNAME by (uid=0): 3 Time(s)
 
 
 ---------------------- pam_unix End ------------------------- 

 
 --------------------- SSHD Begin ------------------------ 

 
 Users logging in through sshd:
    USERNAME:
       i.j.k.l: 3 times
 
 ---------------------- SSHD End ------------------------- 

 
 --------------------- Sudo (secure-log) Begin ------------------------ 

 
 USERNAME => root
 ----------------
 /bin/cat                       -   1 Time(s).
 /bin/ls                        -   3 Time(s).
 /sbin/iptables                 -   4 Time(s).
 /sbin/iptables-restore         -   2 Time(s).
 /usr/bin/crontab               -   2 Time(s).
 /usr/bin/vim                   -   2 Time(s).
 
 ---------------------- Sudo (secure-log) End ------------------------- 

 
 --------------------- Disk Space Begin ------------------------ 

 Filesystem      Size  Used Avail Use% Mounted on
 /dev/root       7.2G  3.6G  3.4G  52% /
 devtmpfs        483M     0  483M   0% /dev
 /dev/mmcblk0p1   60M   20M   41M  34% /boot
 
 
 ---------------------- Disk Space End ------------------------- 

 
 ###################### Logwatch End #########################

Editer ensuite le fichier /etc/cron.daily/000logwatch, pour que le serveur vous envoie automatiquement les informations obtenues par la commande logwatch comme ci-dessus, par email.

$ sudo vim /etc/cron.daily/00logwatch

Remplacer la ligne,

/usr/sbin/logwatch --output mail

Par

/usr/sbin/logwatch --mailto mon@adresse.mail --detail high

Pour en savoir un peu plus sur CRON, je vous renvoie sur cette page.

Configuration du serveur email

Si vous n’avez pas installé de serveur email, autre que celui installé par défaut sur Debian (Exim), installer l’outil Mailutils, qui vous permettra d’envoyer des emails.
L’installation de l’outil GNU/Mailutils est très simple.
$ apt-get install mailutils
Taper ensuite la commande « mu-tool info » pour avoir plus d’information sur ce que l’outil peut gérer.

$ mu-tool info
VERSION=2.99.98
SYSCONFDIR=/etc
MAILSPOOLDIR=/var/mail/
SCHEME=mbox
LOG_FACILITY=mail
IPV6
USE_LIBPAM
HAVE_LIBLTDL
WITH_KYOTOCABINET
WITH_GNUTLS
WITH_GSASL
WITH_GSSAPI
WITH_GUILE
WITH_PYTHON
WITH_PTHREAD
WITH_READLINE
HAVE_MYSQL
WITH_LDAP
WITH_LIBWRAP
ENABLE_VIRTUAL_DOMAINS
ENABLE_IMAP
ENABLE_POP
ENABLE_MH
ENABLE_MAILDIR
ENABLE_SMTP
ENABLE_SENDMAIL

Vérifier maintenant que vous pouvez envoyer un email du serveur.

Pour faire simple, j’envoie un email sans contenu, d’où le message « le corp du message est vide, etc. »

$ mail -s "Hello World!" mon@adresse.mail < /dev/null
Null message body; hope that's ok
!--Tronquée--!
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

mon@adresse.mail
Mailing to remote domains not supported

Ici, le message d’erreur est très clair. Le message ne peut pas être envoyé, puisque l’envoie d’email à un serveut distant n’est pas supporté.

Vérifions la configuration de notre serveur email, Exim.

$ sudo dpkg-reconfigure exim4-config

Choisissez « internet site », afin de pouvoir envoyer et recevoir les emails via le protocol SMTP.

050

Donner un nom au système email.

051

Ne rien modifier sur cette page.

052

Pour les autres destinations, j’ai choisi le même nom qu’à l’étape précédente.

053

Passer à la page suivante sans rien modifier sur celle-ci.

054

Pareil pour cette page.

055

Cliquer sur NON à la demande de garder un nombre minimal de requêtes DNS.

056

Choisissez ensuite l’option mbox.

057

Choisissez de ne pas découper le fichier de configuration de Exim en plusieurs petits fichiers configurables individuellement.

058

Ajouter toutes les adresses emails sur lesquelles vous souhaitez recevoir les alertes. L’ajout de root n’est pas obligatoire.

059

Mettez à jour les informations du Parefeux

Ajouter une règle dans le parefeux pour autoriser les paquets SMTPs à sortir de votre réseau.

$ sudo vim /etc/iptables.firewall.rules
# Allows SMTP access
-A INPUT -p tcp --dport 25 -j ACCEPT

$ sudo iptables-restore < /etc/iptables.firewall.rules

Vérifier ensuite que la nouvelle règle est prise en compte.

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere loopback/8 reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp
ACCEPT tcp -- anywhere anywhere tcp dpt:urd
ACCEPT tcp -- anywhere anywhere tcp dpt:submission
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT icmp -- anywhere anywhere icmp echo-request
LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
DROP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
DROP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Envoyer un email de test en ligne de commande, puis de vérifier si vous l’avez reçu dans votre boîte email.

$ mail -s "Hello World!" mon@adresse.mail < /dev/null
Null message body; hope that's ok

Sources et Réferences

How To Configure Logging And Log Rotation In Apache On An Ubuntu VPS
Log Files
Install Logwatch To Keep An Eye On Things
Linux mail command examples – send mails from command line
How To Install the Send-Only Mail Server « Exim » on Ubuntu 12.04
How to send email from the Linux command line
Exim Internet Mailer

Connection SSH

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 5. Connection SSH

Qu’est ce que le SSH?

« Secure Shell (SSH) est à la fois un programme informatique et un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de chiffrement en début de connexion. Par la suite, tous les segments TCP sont authentifiés et chiffrés.
Le protocole SSH a été conçu avec l’objectif de remplacer les différents programmes rlogin, telnet, rcp, ftp et rsh. » (Wikipedia)

Pour faire simple, il y a deux manières pour se connecter à un serveur distant.

Un de façon non sécurité, et que l’on déconseille fortement, puisque tout le traffic passe en mode clair sur le réseau. C’est comme si vous communiquer avec votre banquier à l’autre bout de la rue, avec un mégaphone, pour lui faire part de vos possessions et biens, ainsi que leurs emplacements.

L’autre méthode serait de chiffrer tous les échanges entre votre poste et le serveur, afin que ces communications restent confidentiels à l’abris des regards indiscrets.

Pas mal d’astuces sur la façon de mieux sécuriser l’accès au serveur SSH on déjà été proposés dans les précédents chapitre, donc je ne vais pas m’étaler dessus.Ici, je vais essayer d’ajouter quelques points non vus précédement.

Gel du terminal après disconnection du SSH

Vous avez certainement noté un problème de « gel » de votre terminal, un certain temps d’inactivité, lorsque vous vous connectez en SSH à votre serveur, et que vous n’arrivez plus à prendre la main dessus! C’est tout à fait normal, puisqu’un fois la session en SSH terminée, votre machine se déconnecte du serveur, mais ne vous laisser pas reprendre la main sur la console.

Pour y remédier, vous avez une liste de méthode.

Méthode 1:

Taper deux fois la touche « ENTREE » puis successivement sur les touches « ~ » et « . », sans les guillemets.

$ man ssh
!---Tronquée---!
The supported escapes (assuming the default ‘~’) are:
~.      Disconnect.
!---Tronquée---!

Méthode 2:

Si vous pensez que cette solution n’est pas pratique, vous pouvez toujours ajouter une ligne avec la commande « ~. », sans les guillemets bien sûr, dans le fichier .ssh/config de votre RPi.

raspi$ vim ~/.ssh/config
~.
raspi$ sudo service ssh restart

Méthode 3:

Une solution des plus classique, serait d’éditer l’un des fichiers de configuration du serveur ou de votre poste de travail. Il n’est pas nécessaire de le faire sur les deux à la fois.

SSH serveur

raspi$ sudo vim /etc/ssh/ssh_config
ClientAliveInterval 60
raspi$ sudo service sshd restart

N’oublier pas de redémarrer le service correspondant à chaque modification d’un fichier de configuration sur un serveur.

SSH client

Ajouter les deux lignes ci-dessous dans le fichier dans la configuration locale de votre ssh.

monOrdi$ vim ~/.ssh/config
Host *
ServerAliveInterval 60

L’option ServerAliveInterval va garder la connection active même si l’utilisateur est inactif. Et l’option ClientAliveInterval va tout de même envoyer des paquets vides vers le serveur toutes les 60 secondes, pour garder la connection active.

Méthode 4:

Sur le même principe qu’à la méthode 3, vous pouvez ajouter comme argument ServerAliveInterval, lorsque vous vous connectez en SSH.

monOrdi$ ssh -o ServerAliveInterval=60 user@example.com

Méthode 5:

Configurer PUTTY, avec une valeur de keepalive interval:

monOrdi$ sudo apt-get install putty

037

 

Création d’une Banière personnalisée

Afficher un message d’acceuil (Message du jour ou MOTD) lors de la connection en SSH, est une très bonne idée. Une banière peut servir à afficher un message d’avertissement, etc., celà dépend de vos besoins.
Le message d’information affiché par défaut, lors de la connection sur notre serveur RPi nous donne les informations d’utilisation du logiciel, ainsi que les informations sur la dernière connection réussie sur le serveur.

018

Pour donner une touche plus personnelle à votre banière, rendez-vous dans le fichier /etc/motd et apportez-y toutes les modifications nécessaires.

Si comme moi, vous êtes nostalgique du logo de tux, alors récupérer le logo sur github. Copier  ensuite avec un outil graphique en mode root (gvim, gksudo gedit, etc.), les lignes situées entre BEGIN_LOGO et END_LOGO.
Mais avant tout, garder tout de même une copie de l’ancien fichier motd.

raspi$ sudo mv  /etc/motd /etc/motd_old

Il va de soit que, pour se connecter en mode graphique, il nous faut un visionneur de bureau distant, Remmina par exemple, et qu’il faut aussi ouvrir le port 3389 du parefeux de votre serveur RPi si ce n’est pas le cas.

raspi$ sudo gvim /etc/motd

Et voici le résultat avec le choix de « classic.log ».

019

Customisation du MOTD

Pour un tunning un peu plus poussé de votre page, voici deux liens qui pourraient vous être utile: Customize your MOTD – LINUX,et Custom MOTD – Message of the Day.

Mettre à jour de la passephrase

Dans le cas où vous avez créé une passphrase lors de la création de clés pour une connection sécurisée entre votre poste et le serveur RPi, si comme moi vous avez utilisé un mot de passe simple pour faire des tests, il est donc temps de mettre un mot-de-passe un peu plus sûr.
Pour ce faire, à partir de l’ordinateur sur lequel vous avez généré la clé, taper,

monOrdi$ cd ~/.ssh/

monOrdi$ ls
id_rsa id_rsa.pub
monOrdi$ ssh-keygen -f id_rsa -p

A lire

Je vous recommande aussi de lire les articles suivants, si vous souhaitez approfondir vos connaissances sur le SSH:

Secure Secure Shell
Awesome SSH
The ultimate ssh tips & tricks

Sources et Réferences

SSH – ubuntu-fr
Banner Files
OpenSSH Change a Passphrase With ssh-keygen command
Connecting to a server using SSH on Linux or Mac OS

Accès au serveur Web Owncloud à partir de son nom de domaine

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 4. Accès au serveur Web Owncloud à partir de son nom de domaine

Avant d’aller plus loin, je souhaite rappeler que « internet c’est la jungle ». Tout et n’importe quoi peut-y arriver. Il ne faut donc pas prendre la question de sécurité à la légère. Prennez donc toutes les précautions nécessaires, comme mettre régulièrement à jour vos serveurs, etc.

1. Configuration du réseau

Matériel

  • Raspberry Pi 2 B
  • Carte micro SD, Classe 10
  • Câble HDMI
  • Câble Ethernet
  • Télé ou moniteur PC, avec support HDMI (pour l’installation de Raspbian uniquement)
  • Disque dur Externe USB 3 autonome, raccordé à une source d’alimentation (optionnel)
  • Un parefeux (optionnel)

Configuration

  • Adresse IP Publique (internet) statique, ou dynamique (nécessite l’utilisation d’un script)
  • Adresse IP Privée statique (LAN) pour le RPi (optionnelement, pour le parefeux aussi)
  • Nom de domaine (NetLibre, nsupdate)
  • Certificat SSL (OpenSSL)

Topologie du réseau

Pour une meilleure sécurité, assurez-vous d’avoir votre serveur Owncloud dans la zone DMZ (ou zone démilitarizée) de votre réseau. Ceci n’est pas une vulnérabilité, mais bien au contraire. Cette fonctionnalité vous permet de séparer le réseau accessible à partir d’internet, de votre réseau local.

pic1

Une fois le DMZ mis-en place, vous ne devriez pas vous soucier du port forwarding. A moins que vous ne souhaitez accéder à votre site, qu’à partir d’un port autre que les ports 80 et 443.

Si vous n’avez que le RPi sur le DMZ (fig 1), au niveau de la configuration du routeur de votre FAI (fournisseur d’accès à internet), vous devriez avoir l’option d’entrer l’adresse IP de votre RPi. Si par contre, vous avez un parefeux sur votre réseau (fig 2), dans la zone DMZ bien sûr, il vous faudra renseigner l’adresse IP de ce parefeux dans la configuration du DMZ du routeur FAI, puis de faire un NAT pour rediriger le traffic vers vos serveurs. Je ne vais pas rentrer dans les détails ici.

De ce fait, dans les deux cas, assurez vous d’assigner une adresse IP privée fixe au RPi, mais aussi à votre parefeux si vous en avez un.

Assigner une adresse IP fixe au RPi

Brancher votre RPi directement au routeur FAI afin de récupérer les valeurs données par « ip add show dev eth0 » (anciennement connu par « ifconfig’).

$ ip add show
    inet 10.1.2.3/24 brd 10.1.2.255 scope global eth0

Créer ensuite un fichier /etc/network/interfaces.d/eth0, dans lequel on va y ajouter les informations données par la commande précédente. La plus d’information concernant la configuration de l’interface réseau, je vous recommande de lire cet article sur le site officiel debian.

$ sudo vim /etc/network/interfaces.d/eth0 
auto eth0
iface eth0 inet static
     address 10.1.2.3
     netmask 255.255.255.0
     gateway 10.1.2.254

$ sudo ifup -v eth0

2. Accéder à votre server web via un nom de domaine

L’étape suivante serait d’associer un nom facile à retenir, qui va pointer vers l’adresse ip publique de votre routeur, tel que MaPage.monDomaine.fr.

Comme serveur DNS pour avoir un nom de domain, j’ai choisi de m’enregistrer sur NetLib.re (projet francophone), et nsupdate.info (projet anglophone) pour les raisons suivantes:
– Nom de domaine gratuit
– Codes sources du projet en opensource
– Facilité d’inscription
– Aucune compétence particulière nécessaire pour l’utilisation du site

Enregistrement de type « A » (‘A Record’ en anglais)

Notre priorité étant de mapper le domaine MaPage.monDomaine.fr à notre adresse IP publique, il nous faut donc un enregistrement de Type A, si l’adresse IP Publique est sous format IPv4, sinon de Type AAAA pour l’IPv6.
Pour les autres types d’enregistrement (SRV et MX, etc.), je ne vais pas en parler puisqu’on en a pas besoin pour l’instant.

Connectez-vous sur la site NetLibre. Noter qu’il y a déjà deux champs pré-remplis sur cette page, qu’il faut éviter de supprimer : ns0.arn-fai.net. et alsace.tetaneutral.net.

pic2

Remplissez les différents champs comme suit:

Type: A
Nom: @
TTL: 3600
Valeur: <mon adress IP publique>

Une ligne supplémentaire vous confirmant l’ajout de l’information, devrait s’afficher sur la page.

pic3
Une fois que vous avez compris comment çà marche, vous pouvez vous enregistrer aussi sur nsupdate.info puis refaire la même procédure afin d’avoir une adresse en .nsupdate.info.

Vérification de la résolution de nom

Patientez quelques 5-10 minutes, puis vérifier si vous pouvez accéder à votre page en utlisant le nom de domaine. Si rien ne s’affiche, faite un ping ou utiliser cet outil internet.

$ ping .netlib.re

pic4

L’outil internet ci-dessous donne les mêmes résultats qu’une simple commande nslookup.

pic5

Domaine de confiance (Trusted domain)

Ne vous inquiétez pas du message affiché lors de la première connection sur MaPage.monDomaine.fr (.netlib.re), qui nous informe que domaine n’est pas de confiance.

pic6

Pour y remédier, il suffit d’ajouter le nom de domaine de votre page, ainsi que l’adresse IP publique de votre site dans le fichier /var/www/html/owncloud/config/config.php.

$ sudo vim /var/www/html/owncloud/config/config.php
'trusted_domains' =>
  array (
    0 => 'localhost',
    1 => '10.1.2.3',
    2 => 'Mon.Adresse.IP.Publique',
    3 => '.netlib.re',
    4 => '.nsupdate.info',
  ),

$ sudo service apache2 restart

Adresse IP dynamique

Vous ne le savez peut être pas mais, l’adresse IP assignée par les FAIs à notre routeur peut changer à une fréquence très variable. Du genre une fois par jour/mois, etc. A la base, cette règle a été conçu pour empêcher certaines personnes malhonnêtes d’attaque continuellement la même adresse IP.

Je n’ai pas trouvé de solution viable pour l’instant. Je ne vais donc pas me lancer dans les explications sur comment faire pour y remédier au problème d’adresse IP dynamique.

Si vous avez une meilleure solution autre que les scripts proposés sur certains sites qui, généralement envoient les informations de connection non chiffrées à notre serveur de domaine, entre autre le mot-de passe, je suis preneur.

3. Quelques conseils de sécurité

Si vous avez suivit l’étape d’installation de Owncloud sur un RPi dans cet article, vous n’avez plus besoin de réactiver le mode « a2enmod ssl » du server Apache.
Vérifier que vous avez bien accès à votre page en utilisant https://.netlib.re:/owncloud (si vous n’avez pas pas de redirection de port, le lien se résume à https://.netlib.re/owncloud).
Un avertissement s’afficher à l’écran si vous vous connectez en HTTPs, pour vous prévenir que le serveur auquel vous voulez accéder n’a pas de certificat de sécurité valide.

pic7
Pour pouvoir continuer la visite de la page, et faire fi du message, cliquer tout simplement sur Proceed to MaPage.netlib.re (unsafe).

Supprimer les informations sur les versions de vos serveurs

Il y a plusieurs façon d’afficher une page d’erreur sur une page. J’ai choisi une basique, en demandant au navigateur d’afficher la page http://.netlib.re:443/owncloud.

pic8

Pour y remédier, ajouter « ServerSignature Off » à la fin du fichier /etc/apache2/apache2.conf.

Taper ensuite,

$  curl -v http://.netlib.re:/owncloud

pic9

Ici, c’est la commande « ServerTokens Prod » qu’il faut ajouter dans le fichier de configuration de Apache.

En conclusion, pour éviter d’afficher les informations des différents serveurs (type, version, etc.), désactiver leurs signatures dans /etc/apache2/apache2.conf.

$ sudo vim /etc/apache2/apache2.conf
ServerSignature Off
ServerTokens Prod

Ce n’est pas tout, vérifier aussi que l’option d’affichage de la version de php est bien désactivée, ce qui devrait être le cas par défaut.

$ sudo vim /etc/php5/apache2/php.ini

Faite une recherche en tapant

/expose

pic10

Vous devriez avoir « expose_php = Off », si ce n’est pas le cas, remplacer le On par Off.
Redémarrer le serveur Apache.

$ sudo service apache2 restart

4. Avant d’aller plus loin

Je vous propose de lire l’article « Développement et administration des services réseaux« , à partir duquel j’ai retirré les informations ci-dessous.

apache2.conf : le fichier de configuration générale (ancien httpd.conf). C’est à partir de lui que tous les autres fichiers sont chargés

envvars : le fichier utilisé pour définir des variables d’environnement propres à Apache

ports.conf : le fichier qui contient la directive listen qui spécifie les adresses et les ports d’écoutes

mods-available/ : le dossier contenant les modules disponibles

mods-enabled/ : le dossier contenant les modules activés

sites-available/ : le dossier contenant les fichiers de configuration des sites disponibles (la liste des vhosts installés)

sites-enabled/ : le dossier contenant les fichiers de configuration des sites activés (la liste des vhosts utilisés)

Vhosts fait référence aux hôtes virtuels.

Nous allons ensuite associer l’adresse IP publique de notre serveur Owncloud à un nom de domaine sur internet (de préférence, choisissez-en deux au cas où l’un des URLs devient inaccessible).
Je me suis enregistré sur netlib.re, puis nsupdate.info pour les raisons suivantes. Un, à cause de la facilité d’utilisation pour les débutants. Deux, pour leurs gratuités. Et trois, à cause de la disponibilité de leurs codes sources.

Pour accéder à mon serveur, je n’ai donc plus qu’à taper

.netlib.re
.nsupdate.info

5. Accéder à Owncloud en SSL (HTTPS)

Pour rappel, le HTTPS est une combinaison entre les protocoles HTTP et SSL/TLS, pour chiffrer les informations échangées entre notre poste et le serveur visité. Ceci justement, dans le but de créer une connection avec une sécurité « résonnable » à travers le réseau pour protéger les utilisateurs, ainsi que les données qui y transitent.

Si vous avez besoin de plus de sécurité, vous devriez utiliser un certificat signé par une authorité de certification (CA).

Création d’un certificat SSL

Ci-dessous la marche à suivre pour mettre en place un Site Web sécurisé via protocole SSL. J’ai choisi la méthode de création de Certificat auto-signé, option « -x509 » avec l’utilisation de la commande openssl, qu’on va placer dans le dossier /etc/ssl.

$ ssh .netlib.re
$ sudo mkdir -p /etc/ssl/localcerts
$ sudo openssl req -new -x509 -days 365 -nodes -out /etc/ssl/localcerts/owncloud.pem -keyout /etc/ssl/localcerts/owncloud.key

pic11

Le certificat créé avec option « -days 365 », sera valide pour 1an. Si comme moi, vous ne souhaitez pas protéger votre clé privée par un mot de passe, ajouter l’option « – nodes » à la commande openssl.
Modifier ensuite les permissions du dossier /etc/ssl/localcerts, qui contient les deux clés owncloud.key et owncloud.pem, afin que personne d’autre que le proprétaire du dossier (ici Root), n’a accès à son contenu.

$ ls -l /etc/ssl/localcerts/
total 8
-rw-r--r-- 1 root root 1704 Mar 25 06:03 owncloud.key
-rw-r--r-- 1 root root 1440 Mar 25 06:03 owncloud.pem
$ sudo chmod 600 /etc/ssl/localcerts/owncloud*
$ ls -l /etc/ssl/localcerts/
total 8
-rw------- 1 root root 1704 Mar 25 06:03 owncloud.key
-rw------- 1 root root 1440 Mar 25 06:03 owncloud.pem

/!\ Les permissions pour accéder à ces clés tel que présenté ci-dessus, a pour but de limiter leurs accès à une tierce personne. Il ne faut surtout, mais SURTOUT pas partager votre clé privée, ni la perdre d’ailleur.

Activer le mode ssl,

$ sudo a2enmod ssl

Un message s’affichera avec la liste des dépendances activées, si le mode ssl est déjà activé.

Considering dependency setenvif for ssl:

Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Module socache_shmcb already enabled
Module ssl already enabled

Configuration de Apache2

Il n’y a rien à modifier au niveau des ports d’écoute, puisque Apache2 est configuré par défaut pour écouter sur les ports 80 et 443.

$ cat /etc/apache2/ports.conf 
# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf
Listen 80

    Listen 443



    Listen 443

Sauvegarde des fichiers de configuration

N’oubliez pas de faire une sauvegarde de vos fichiers de configuration, quelqu’il soit (owncloud.conf, config.php, apache2.conf, etc.), avant de les modifier.

1. Fichier de configuration de owncloud

$ sudo cp /etc/apache2/sites-available/owncloud.conf /etc/apache2/sites-available/owncloud.bak

2. Fichier de configuration du serveur web

$ sudo cp /etc/apache2/apache2.conf /etc/apache2/sites-available/apache2.bak

3. Tableau de configuration PHP du serveur owncloud

$ sudo cp /var/www/html/owncloud/conf/config.php /var/www/html/owncloud/conf/config.bak

4. Fichier .htaccess

Dans la liste de fichiers de configuration, il faut absolument ne pas toucher au fichier .htaccess comme indiqué sur dans le tutoriel de Apache. Par contre, rien ne vous empêche d’en faire une copie de sauvegarde.
A titre d’information, dans le dossier contenant l’option « AllowOverride All », /var/www/html/owncloud/ par exemple (cf. « Sécuriser notre Hôte Virtuel » qu’on verra un peu plus tard dans ce chapitre), les règles données par .htaccess vont être prioritaires aux directives du serveur Apache.

    AllowOverride All

Ce qui n’empêche pas le serveur Apache d’y appliquer d’autres règles qui ne rentrent pas en conflit avec ceux du .htaccess, dans le même dossier.

Recharger la configuration d’Apache

Si vous modifier l’un des fichiers de configuration de votre serveur, n’oublier pas de redémarrer le serveur Apache.

$ sudo service apache2 restart

Configuration SSL

Vérifier dans un premier temps la version de chacun de vos serveurs.

Version de Apache:

$ apachectl -V
Server version: Apache/2.4.10 (Raspbian)

$ aptitude show apache2
Version: 2.4.10-10+deb8u4

Version de OpenSSL:

$ openssl version
OpenSSL 1.0.1k 8 Jan 2015

$ aptitude show openssl
Version: 1.0.1k-3+deb8u4

Version du PHP:

$ php --version
PHP 5.6.17-0+deb8u1 (cli) (built: Jan 24 2016 12:25:22)

$ aptitude show php5
Version: 5.6.17+dfsg-0+deb8u1

Générer ensuite une configuration SSL convenable, en fonction de la version de vos serveurs, à partir de ce lien.

pic12

Sécuriser notre Hôte Virtuel

Rediriger tous les traffics HTTP (port 80) vers HTTPS (port 443).
Pour ce faire, je vous suggère de supprimer tout le contenu du fichier /etc/apache2/sites-available/owncloud.conf, puis de le remplacer par celui ci-dessous, en l’adaptant à vos besoins.

Pour rappel, mon adresse IP publique est liée à deux URLs différents. Un en netlib.re, puis l’autre en nsupdate.info.

$ sudo vim /etc/apache2/sites-available/owncloud.conf
# Force port redirecting (HTTP to HTTPS)

    ServerName .netlib.re
    Redirect permanent / https://.netlib.re



    ServerName .nsupdate.info
    Redirect permanent / https://.nsupdate.info


# Web server configuration


    ServerName .netlib.re
    ServerAlias .nsupdate.info
    DocumentRoot /var/www/html/owncloud/
    # SSL configuration

    SSLEngine on
    SSLCertificateFile /etc/ssl/localcerts/owncloud.pem 
    SSLCertificateKeyFile /etc/ssl/localcerts/owncloud.key
    #SSLCACertificateFile /path/to/all_ca_certs
    # Restrict/deny/allow access to certain directories

    
        Options +FollowSymLinks
        AllowOverride All
        
            Dav off
        

    SetEnv HOME /var/www/html/owncloud
    SetEnv HTTP_HOME /var/www/html/owncloud
    

    
        # just in case if .htaccess gets disabled
        Require all denied
    
 

# modern configuration, tweak to your needs
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder     on
SSLCompression          off

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000)

Quelques notes concernant cette configuration:

  • DocumentRoot définit la racine des documents pour chaque hôte virtuel
  • SSLEngine doit être activé, afin que le server web puisse utiliser le SSL
  • SSLCertificateFile et SSLCertificateKeyFile définit le chemin d’accès à nos certificats et clés
  • SSLCACertificateFile à acitiver, si vous avec un certificat signé par un CA

6. Sécurités et avertissements sur les configurations

L’ajout de la règle en HSTS dans l’hôte virtuel n’est pas une bonne idée. D’autant plus que celà ne va pas supprimer l’avertissement qui s’affiche dans la page d’administration de votre Owncloud.

HSTS-warning

Dans /etc/apache2/apache2.conf, ajouter

$ sudo vim /etc/apache2/apache2.conf
#
# Force all traffic to remain on HTTPS
# HSTS (mod_headers is required) (15768000 seconds = 6 months)
#

      Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"


# 
# Force people coming to your site to use HTTPS
#
# 1. Enable the Rewrite capabilities
#
RewriteEngine On
#
# 2. Check to make sure the connection is not already HTTPS
#
RewriteCond %{HTTPS} !=on
#
# 3. Redirect users from their original location, to the same location but using HTTPS.
# i.e.  http://www.example.com/foo/ to https://www.example.com/foo/
# The leading slash is made optional so that this will work either in httpd.conf
# or .htaccess context
#
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Profitons-en par la même occasion pour régler aussi le problème de Mémoire cache.
$ sudo apt-get install php5-apcu

$ aptitude show php5-apcu
Version: 4.0.7-1

Sans passer par l’interface graphique, une méthode pour vérifier si le memcache est configuré, le résultat de la commande ci-dessous doit être égale à 1 si c’est activé. Sinon, on devrait avoir 0.

$ sudo cat /var/www/html/owncloud/config/config.php | grep -ci -m1 "'memcache.local'"
0

Dans le fichier /var/www/html/owncloud/config/config.php, ajouter la ligne ci-dessous, puis revérifier le memcache, qui devrait maintenant avoir pour valeur 1:

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

pic13

Vérifier de nouveau que tous est maintenant rentré dans l’ordre dans la page d’administration de votre serveur Owncloud.

pic14

7. Différents Tests

Test d’accès en HTTP à votre page

Après avoir supprimé les caches et cookies de votre navigateur, entrer l’url de votre site en HTTP, puis vérifier le résultat.
Si tout s’est bien passé, vous devriez désormais avoir accès à votre page de manière sécurisée, en HTTPS.

pic15

Et voilà. Apprécier votre nouveau « Dropbox-like ». Mais, attendez, ce n’est pas tout!

Test de sécurité du serveur

Pour le fun, effectuer un test de sécurité de votre page sur Quallys SSL Lab.

pic16

Le résultat du test nous donne un T à cause d’un problème de certificat. Sans celà, le site mérite un A. Ce qui fait que notre site est digne de « confiance ».

Vous pouvez également vérifier quels ports sont ouverts avec Pentest-tools.

pic17

Amusez-vous bien!

 

Références et Ressources:

Netlibre, un nom de domaine gratuit, facilement administrable
Principes de base du système DNS
Hardening and Security Guidance
How to turn off server signature on Apache web server
Tutoriel: Virtualhosts avec Apache2
Atelier 3 partie 4 – Installer son serveur à la maison
Self-Signed_Certificate (Debian)
Certificates and Encodings
What is a Pem file and how does it differ from other OpenSSL Generated Key File Formats?
Enable SSL for Owncloud 8 on Ubuntu
Redirect Request to SSL
Common Apache Missconfigurations
How To Configure Apache 2
Configuring Memory Caching
Sécuriser son serveur Linux
Protéger son site Internet des cyberattaques