Récupération d'articles d'archives
This commit is contained in:
@@ -0,0 +1,3 @@
|
||||
description: "Couverture originale créée localement pour accompagner la republication de l'article C'est quoi le Libre ?."
|
||||
attribution: "Codex"
|
||||
prompt: "Illustration abstraite éditoriale sur le logiciel libre et l'émancipation numérique, avec symbole d'ouverture, rayons lumineux et ambiance rétro-web 2012, sans texte, sans logo."
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 105 KiB |
@@ -0,0 +1,41 @@
|
||||
---
|
||||
comments_url: https://com.richard-dern.fr/post/521
|
||||
cover: images/cover.png
|
||||
date: '2012-02-13 00:09:00'
|
||||
links:
|
||||
- lang: fr
|
||||
name: Page d'origine sur Archive.org
|
||||
url: https://web.archive.org/web/20120224015034/http://ingnu.fr/2012/02/13/cest-quoi-le-libre/
|
||||
tags:
|
||||
- Libre
|
||||
- Logiciel
|
||||
title: C'est quoi le Libre ?
|
||||
weather:
|
||||
humidity: 59
|
||||
illuminance: 0.0
|
||||
precipitations: false
|
||||
pressure: 1025.2
|
||||
source:
|
||||
- open-meteo
|
||||
temperature: -8.8
|
||||
wind_direction: 225
|
||||
wind_speed: 3.1
|
||||
---
|
||||
|
||||
Je sais qu'il y a beaucoup de sources d'informations pour savoir ce qu'est le Libre ([dont la principale](https://web.archive.org/web/20120224015034/http://www.gnu.org/philosophy/free-sw.html)), mais j'ai toujours constaté avec regret qu'il y a encore beaucoup de gens qui considèrent mal les Libristes, les défenseurs du Libre.
|
||||
|
||||
Je les ai vu dire que dans certains domaines, les Logiciels Libres n'arrivent pas à la cheville des logiciels privateurs, sur le plan technique. J'en ai vu dire que les Logiciels Libres n'apportent rien, et ne sont d'aucune utilité face aux logiciels privateurs. J'en ai vu dire que les Logiciels Libres ne sont pas des alternatives viables aux logiciels privateurs, ou aux services web du type Google ou facebook. J'en ai même lu qui disaient que si un auteur de Logiciel Libre voulait insérer dans son code une partie destinée à espionner l'utilisateur, personne ne le verrait.
|
||||
|
||||
Alors, j'ai décidé d'essayer autre chose, que dire "les Logiciels Libres c'est mieux, les logiciels privateurs c'est mal".
|
||||
|
||||
La plupart des critiques que j'ai lu sont fondées sur l'aspect technique des Logiciels Libres. Or, le fondement même des Logiciels Libres est la liberté justement. Ils n'existent pas simplement pour qu'une alternative à Microsoft Office ou Microsoft Windows existe, ils existent pour apporter la liberté au sein de l'informatique. Ils ont été conçus pour libérer leurs utilisateurs des contraintes arbitrairement et injustement imposées par les éditeurs de logiciels.
|
||||
|
||||
C'est à Richard Stallman que l'on doit cette vision du Logiciel Libre. Tout défenseur du Logiciel Libre se doit de connaître et approuver Stallman, tandis que ses détracteurs se doivent de connaître les intentions formulées par Licence Publique Générale.
|
||||
|
||||
L'aspect technique des Logiciels Libres est pour ainsi dire secondaire: la priorité est d'accorder des libertés fondamentales aux auteurs et aux utilisateurs de ces logiciels; l'aspect technique ne doit être mis en avant que pour leur valorisation par rapport aux solutions privatrices.
|
||||
|
||||
Par exemple, dire que GIMP est une plaisanterie face à Photoshop relève de l'ignorance, puisque cela revient à comparer les deux logiciels sur un plan technique. Or, GIMP n'est pas une réponse technique à Photoshop, c'est une réponse de principe. GIMP existe pour que puisse exister une alternative Libre à Photoshop.
|
||||
|
||||
Ce que certains considèrent comme une faiblesse est en réalité une force du Logiciel Libre: puisqu'on veut parler d'aspect technique, la technicité d'un Logiciel Libre est dépendante de sa communauté, forte de plusieurs milliers d'utilisateurs qui sont autant de contributeurs, tandis que la technicité d'un logiciel privateur n'est dépendante que du bon vouloir de l'entreprise qui le publie. Autrement dit, elle n'est motivée que par l'argent.
|
||||
|
||||
Ce qui m'amène à poser la question suivante: comment un Libriste peut se considérer comme tel s'il ne voit aucun inconvénient à utiliser une solution privative?
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
comments_url: https://com.richard-dern.fr/post/522
|
||||
date: '2012-02-13 14:04:00'
|
||||
dossier:
|
||||
- Créer son propre Cloud
|
||||
links:
|
||||
- lang: fr
|
||||
name: Page d'origine sur Archive.org
|
||||
url: https://web.archive.org/web/20120221004519/http://ingnu.fr/2012/02/13/gerer-ses-photos-avec-photoshow/
|
||||
tags:
|
||||
- PhotoShow
|
||||
title: Gérer ses photos avec PhotoShow
|
||||
weather:
|
||||
humidity: 63
|
||||
illuminance: 34842.5
|
||||
precipitations: false
|
||||
pressure: 1020.6
|
||||
source:
|
||||
- open-meteo
|
||||
temperature: 0.1
|
||||
wind_direction: 258
|
||||
wind_speed: 12.5
|
||||
weight: 11
|
||||
---
|
||||
|
||||
Maintenant que nous disposons d'[une solution de stockage en ligne](https://web.archive.org/web/20120221004519/http://ingnu.fr/2012/02/12/une-alternative-a-dropbox/), la prochaine étape consistera à mettre en place une application web pour partager ses photos avec le reste du monde.
|
||||
|
||||
Bien que de très nombreuses solutions existent, et de très bonne qualité (voir mon article sur [les alternatives à Google](https://web.archive.org/web/20120221004519/http://ingnu.fr/2011/12/29/quelles-sont-les-alternatives-a-google/)), mon choix s'est porté sur une petite application du nom de [PhotoShow](https://web.archive.org/web/20120221004519/http://www.photoshow-gallery.com/).
|
||||
|
||||
Je l'ai choisi pour plusieurs raisons.
|
||||
Tout d'abord, elle ne nécessite aucune base de données.
|
||||
Ensuite, elle ne nécessite pratiquement aucune maintenance, dans la mesure où les photos sont analysées automatiquement.
|
||||
Est également automatique la génération des miniatures.
|
||||
Et malgré sa simplicité, il reste possible de définir tout ou partie de la galerie comme étant privée, dont l'accès sera réservé aux utilisateurs de votre choix, ou simplement protégé par mot de passe.
|
||||
|
||||
Enfin, l'arborescence des fichiers n'a pas besoin de se trouver dans l'arborescence du site.
|
||||
Cela permet d'éviter que n'importe qui (les moteurs de recherche par exemple) puisse aspirer sans vergogne vos photos.
|
||||
On respecte ainsi une autre prérogative de [ma série d'articles](https://web.archive.org/web/20120221004519/http://ingnu.fr/category/creer-son-propre-cloud/) : préserver la confidentialité de nos données.
|
||||
|
||||
## Hôte virtuel
|
||||
|
||||
Première chose, comme d'habitude, on s'occupe de l'hôte virtuel dans apache :
|
||||
|
||||
```bash
|
||||
nano /etc/apache2/sites-available/photos.exemple.fr
|
||||
```
|
||||
|
||||
```text
|
||||
<VirtualHost *:80>
|
||||
ServerName photos.exemple.fr
|
||||
Redirect / https://photos.exemple.fr/
|
||||
</VirtualHost>
|
||||
|
||||
<VirtualHost *:443>
|
||||
ServerName photos.exemple.fr
|
||||
|
||||
DocumentRoot /var/www/exemple.fr/photos/www
|
||||
|
||||
SSLEngine On
|
||||
SSLCertificateFile /scripts/certificate_authority/apache/photos.exemple.fr.crt
|
||||
SSLCertificateKeyFile /scripts/certificate_authority/apache/photos.exemple.fr.key
|
||||
|
||||
CustomLog /var/www/exemple.fr/photos/log/access.log
|
||||
ErrorLog /var/www/exemple.fr/photos/log/error.log
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe.
|
||||
Créons maintenant les certificats :
|
||||
|
||||
```bash
|
||||
/scripts/certificate_authority/make_request apache photos.exemple.fr
|
||||
/scripts/certificate_authority/sign_request apache photos.exemple.fr
|
||||
chown www-data:www-data /scripts/certificate_authority/apache/*
|
||||
```
|
||||
|
||||
Warning : Lorsque le *Common Name* vous sera demandé, indiquez le nom de domaine !
|
||||
Et dans notre cas, acceptez la création d'une clé sans mot de passe !
|
||||
|
||||
On active le site, et on redémarre apache :
|
||||
|
||||
```bash
|
||||
a2ensite photos.exemple.fr
|
||||
/etc/init.d/apache2 restart
|
||||
```
|
||||
|
||||
## Installation de PhotoShow
|
||||
|
||||
On créé l'arborescence du site :
|
||||
|
||||
```bash
|
||||
mkdir -p /var/www/exemple.fr/photos/{www,log,thumbs}
|
||||
```
|
||||
|
||||
Puis on télécharge et on installe PhotoShow :
|
||||
|
||||
```bash
|
||||
cd /usr/src
|
||||
git clone git://github.com/thibaud-rohmer/PhotoShow.git
|
||||
cp -R PhotoShow/* /var/www/exemple.fr/photos/www/
|
||||
chown -R www-data:www-data /var/www/exemple.fr/photos
|
||||
```
|
||||
|
||||
On configure l'application :
|
||||
|
||||
```bash
|
||||
nano /var/www/exemple.fr/photos/www/config.php
|
||||
```
|
||||
|
||||
```php
|
||||
$config->photos_dir = "/var/public-docs/Photos";
|
||||
$config->ps_generated = "/var/www/exemple.fr/photos/thumbs";
|
||||
```
|
||||
|
||||
Vous noterez le répertoire */var/public-docs/Photos* qu'il faut créer, et qui contiendra donc vos photos.
|
||||
|
||||
```bash
|
||||
mkdir /var/public-docs/Photos
|
||||
```
|
||||
|
||||
L'application en elle-même est prête, vous pouvez la visiter depuis l'adresse `http://photos.exemple.fr`.
|
||||
|
||||
Vous pouvez créer un compte "*anonyme*", ou "*invites*", protégé par mot de passe, si vous ne voulez pas que des personnes non identifiées aient accès à votre galerie.
|
||||
Vous pouvez aussi simplement la protéger avec un mot de passe, sans avoir besoin de créer un utilisateur particulier.
|
||||
|
||||
## Envoyer automatiquement ses photos prises avec un smartphone Android
|
||||
|
||||
Facile, si vous avez installé l'application WebDav File Manager comme indiqué dans [mon précédent article](https://web.archive.org/web/20120221004519/http://ingnu.fr/2012/02/12/une-alternative-a-dropbox/) (ou toute autre application Android capable de se synchroniser avec un dépôt WebDav ou SSH).
|
||||
Il vous suffit de mettre en place une synchronisation entre le répertoire où vos photos sont stockées sur votre smartphone (*DCIM/*) et `https://files.exemple.fr/public/Photos`.
|
||||
|
||||
Important : Attention si vous mettez d'autres photos depuis une autre source, ces photos seront aussi copiées sur votre téléphone.
|
||||
Pour l'éviter, vous pouvez créer un dossier */var/public-docs/Photos/Android*, que vous utiliserez pour la synchronisation.
|
||||
|
||||
Le tutoriel d'aujourd'hui est déjà terminé.
|
||||
Nous avons vu des choses relativement compliquées à mettre en oeuvre, mais c'était aussi pour nous simplifier la vie plus tard.
|
||||
Je vous avais bien dis que les prochains articles seraient plus simples !
|
||||
@@ -0,0 +1,256 @@
|
||||
---
|
||||
comments_url: https://com.richard-dern.fr/post/523
|
||||
date: '2012-02-13 15:19:00'
|
||||
dossier:
|
||||
- Créer son propre Cloud
|
||||
links:
|
||||
- lang: fr
|
||||
name: Page d'origine sur Archive.org
|
||||
url: https://web.archive.org/web/20120225092126/http://ingnu.fr/2012/02/13/renforcer-la-securite-de-son-serveur/
|
||||
tags:
|
||||
- Apache
|
||||
- Certificat
|
||||
- Client
|
||||
- Fail2ban
|
||||
- iptables
|
||||
title: Renforcer la sécurité de son serveur
|
||||
weather:
|
||||
humidity: 66
|
||||
illuminance: 35349.3
|
||||
precipitations: false
|
||||
pressure: 1019.9
|
||||
source:
|
||||
- open-meteo
|
||||
temperature: 0.5
|
||||
wind_direction: 267
|
||||
wind_speed: 14.8
|
||||
weight: 12
|
||||
---
|
||||
|
||||
Nous voilà sur la dernière ligne droite de notre série d'articles consacrée à la [mise en place d'un cloud personnel](https://web.archive.org/web/20120225092126/http://ingnu.fr/category/creer-son-propre-cloud/).
|
||||
Nous avons installé à peu près tout ce dont on peut avoir besoin, mais à part un [script de pare-feu](https://web.archive.org/web/20120225092126/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/) relativement restrictif et une protection anti-spam et anti-virus pour [le serveur mail](https://web.archive.org/web/20120225092126/http://ingnu.fr/2012/02/06/installation-de-son-propre-serveur-mail/), il reste encore quelques petites choses à faire pour sécuriser notre serveur.
|
||||
|
||||
Avant toute chose, contrairement à ce que beaucoup de gens recommandent comme bonne pratique, je ne vais pas aborder la question du changement de port pour améliorer la sécurité de notre serveur.
|
||||
Je pense en effet qu'un simple *nmap* sur l'hôte à tester suffit pour déterminer quels sont les ports ouverts sur une machine, et ce n'est pas en déplaçant ce port que le "pirate" va jeter l'éponge.
|
||||
Si quelqu'un est vraiment déterminé à récupérer de votre serveur des données auxquelles il n'a pas le droit d'accéder, il y parviendra.
|
||||
|
||||
Je mise donc sur une approche différente qu'on va tout de suite mettre en place, et qui repose sur [fail2ban](https://web.archive.org/web/20120225092126/http://www.fail2ban.org/).
|
||||
Pour mémoire, fail2ban analyse les tentatives de connexion à votre serveur, et blacklist toute IP qui tentera d'accéder à votre serveur sans succès, selon un certain nombre de règles (qui peuvent être bien velues à configurer...).
|
||||
|
||||
## fail2ban
|
||||
|
||||
Installons l'application :
|
||||
|
||||
```bash
|
||||
apt-get install fail2ban
|
||||
/etc/init.d/fail2ban stop
|
||||
```
|
||||
|
||||
On configure ensuite l'application :
|
||||
|
||||
```bash
|
||||
mv /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf-orig
|
||||
nano /etc/fail2ban/jail.conf
|
||||
```
|
||||
|
||||
Le nombre d'applications nécessitant une connexion réseau pour fonctionner est relativement limité sur notre serveur, ce qui va simplifier la configuration de fail2ban, d'autant que la plupart des filtres existe déjà.
|
||||
|
||||
Voici un fichier *jail.conf* de référence, correspondant à notre serveur :
|
||||
|
||||
```text
|
||||
[DEFAULT]
|
||||
ignoreip = 127.0.0.1 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
|
||||
bantime = 600
|
||||
maxretry = 3
|
||||
backend = polling
|
||||
destemail = contact@exemple.fr
|
||||
banaction = iptables-multiport
|
||||
mta = sendmail
|
||||
protocol = tcp
|
||||
|
||||
action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
|
||||
|
||||
action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
|
||||
%(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s]
|
||||
|
||||
action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
|
||||
%(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s]
|
||||
|
||||
# Choose default action. To change, just override value of 'action' with the
|
||||
# interpolation to the chosen action shortcut (e.g. action_mw, action_mwl, etc) in jail.local
|
||||
# globally (section [DEFAULT]) or per specific section
|
||||
action = %(action_)s
|
||||
|
||||
[ssh]
|
||||
enabled = true
|
||||
port = ssh
|
||||
filter = sshd
|
||||
logpath = /var/log/auth.log
|
||||
maxretry = 6
|
||||
|
||||
[ssh-ddos]
|
||||
enabled = false
|
||||
port = ssh
|
||||
filter = sshd-ddos
|
||||
logpath = /var/log/auth.log
|
||||
maxretry = 6
|
||||
|
||||
[pam-generic]
|
||||
enabled = true
|
||||
filter = pam-generic
|
||||
port = all
|
||||
banaction = iptables-allports
|
||||
port = anyport
|
||||
logpath = /var/log/auth.log
|
||||
maxretry = 6
|
||||
|
||||
[apache]
|
||||
enabled = true
|
||||
port = http,https
|
||||
filter = apache-auth
|
||||
logpath = /var/www/*/*/log/error.log
|
||||
maxretry = 6
|
||||
|
||||
[apache-multiport]
|
||||
enabled = true
|
||||
port = http,https
|
||||
filter = apache-auth
|
||||
logpath = /var/www/*/*/log/error.log
|
||||
maxretry = 6
|
||||
|
||||
[apache-noscript]
|
||||
enabled = true
|
||||
port = http,https
|
||||
filter = apache-noscript
|
||||
logpath = /var/www/*/*/log/error.log
|
||||
maxretry = 6
|
||||
|
||||
[apache-overflows]
|
||||
enabled = true
|
||||
port = http,https
|
||||
filter = apache-overflows
|
||||
logpath = /var/www/*/*/log/error.log
|
||||
maxretry = 2
|
||||
|
||||
[postfix]
|
||||
enabled = true
|
||||
port = smtp,ssmtp
|
||||
filter = postfix
|
||||
logpath = /var/log/mail.log
|
||||
|
||||
[sasl]
|
||||
enabled = true
|
||||
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
|
||||
filter = sasl
|
||||
logpath = /var/log/mail.log
|
||||
|
||||
[named-refused-tcp]
|
||||
enabled = true
|
||||
port = domain,953
|
||||
protocol = tcp
|
||||
filter = named-refused
|
||||
logpath = /var/log/named/security.log
|
||||
```
|
||||
|
||||
Si vous activez le monitoring pour bind, vous devez activer la journalisation :
|
||||
|
||||
```bash
|
||||
nano /etc/bind/named.conf.options
|
||||
```
|
||||
|
||||
```text
|
||||
logging {
|
||||
channel security_file {
|
||||
file "/var/log/named/security.log" versions 3 size 30m;
|
||||
severity dynamic;
|
||||
print-time yes;
|
||||
};
|
||||
category security {
|
||||
security_file;
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
```bash
|
||||
/etc/init.d/bind9 restart
|
||||
```
|
||||
|
||||
Vous devriez être relativement tranquille avec ce fichier de configuration.
|
||||
|
||||
Notice : N'oubliez surtout pas de renseigner correctement votre (vos) adresse(s) IP en début de fichier !
|
||||
|
||||
Démarrez ensuite le service :
|
||||
|
||||
```bash
|
||||
/etc/init.d/fail2ban start
|
||||
```
|
||||
|
||||
Désormais, si quelqu'un n'entre pas dans les clous, son adresse IP sera bloquée directement au niveau d'iptables, pour une durée déterminée spécifiée en début de fichier de configuration.
|
||||
|
||||
## Un firewall "modulaire"
|
||||
|
||||
On va un peu compléter [notre script de pare-feu](https://web.archive.org/web/20120225092126/http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/) pour vous permettre de spécifier vous-même une liste d'adresses IP à bannir.
|
||||
|
||||
```bash
|
||||
nano /scripts/firewall
|
||||
```
|
||||
|
||||
Ajoutez tout à la fin du fichier :
|
||||
|
||||
```text
|
||||
if [ -f "/scripts/firewall.hosts" ]
|
||||
then
|
||||
for ip in `cat /scripts/firewall.hosts`; do
|
||||
${IPT} -A INPUT -s $ip -j DROP
|
||||
done
|
||||
fi
|
||||
```
|
||||
|
||||
Créez ensuite le fichier en question :
|
||||
|
||||
```bash
|
||||
touch /scripts/firewall.hosts
|
||||
```
|
||||
|
||||
Vous pouvez maintenant remplir ce fichier avec les adresses IP que vous souhaitez bloquer (une par ligne).
|
||||
|
||||
N'oubliez pas de relancer le script une fois vos modifications terminées :
|
||||
|
||||
```bash
|
||||
/scripts/firewall
|
||||
```
|
||||
|
||||
## Accès via certificats clients
|
||||
|
||||
Si vous le souhaitez, vous pouvez limiter l'accès à certains de vos sites Internet à certains clients disposant d'un certificat délivré par vous-même.
|
||||
|
||||
Notice : Évitez cette restriction sur l'accès webdav : les clients webdav peuvent ne pas gérer les certificats clients.
|
||||
|
||||
Il suffit de modifier le fichier de configuration de l'hôte virtuel que vous voulez "protéger", en rajoutant les lignes suivantes :
|
||||
|
||||
```text
|
||||
<Location />
|
||||
SSLCACertificateFile /scripts/certificate_authority/ca.crt
|
||||
SSLVerifyClient require
|
||||
SSLVerifyDepth 4
|
||||
</Location>
|
||||
```
|
||||
|
||||
Vous créez ensuite un certificat classique :
|
||||
|
||||
```bash
|
||||
/scripts/certificate_authority/make_request apache-client sous-domaine.exemple.fr
|
||||
/scripts/certificate_authority/sign_request apache-client sous-domaine.exemple.fr
|
||||
chown -R www-data:www-data /scripts/certificate_authority/apache-client
|
||||
```
|
||||
|
||||
Notice : Dans ce cas, ne créez pas de certificat sans mot de passe.
|
||||
|
||||
Il faut ensuite exporter le certificat créé et signé dans un format compatible :
|
||||
|
||||
```bash
|
||||
openssl pkcs12 -export -clcerts -in /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.crt -inkey /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.key -out /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.p12
|
||||
```
|
||||
|
||||
Transmettez ce certificat et son mot de passe au client qui doit accéder au site, client qui devra l'importer dans son navigateur.
|
||||
Utilisez de préférence SSH pour effectuer ce transfert
|
||||
@@ -0,0 +1,211 @@
|
||||
---
|
||||
comments_url: https://com.richard-dern.fr/post/524
|
||||
date: '2012-02-13 16:00:00'
|
||||
dossier:
|
||||
- Créer son propre Cloud
|
||||
links:
|
||||
- lang: fr
|
||||
name: Page d'origine sur Archive.org
|
||||
url: https://web.archive.org/web/20120222160009/http://ingnu.fr/2012/02/13/trucs-et-astuces-pour-son-serveur-prive/
|
||||
tags:
|
||||
- Astuces
|
||||
- Trucs
|
||||
title: Trucs et astuces pour son serveur privé
|
||||
weather:
|
||||
humidity: 72
|
||||
illuminance: 14570.5
|
||||
precipitations: false
|
||||
pressure: 1019.2
|
||||
source:
|
||||
- open-meteo
|
||||
temperature: 0.0
|
||||
wind_direction: 266
|
||||
wind_speed: 14.1
|
||||
weight: 13
|
||||
---
|
||||
|
||||
Avant d'aborder un système de sauvegarde et de restauration pour son cloud personnel, je me suis dis que ce serait une bonne idée de compiler dans un article quelques trucs et astuces, relatifs notamment à la surveillance de votre serveur.
|
||||
|
||||
C'est l'occasion d'apprendre ou réapprendre à se servir des outils inclus dans toute bonne distribution qui se respecte, mais aussi comment compléter ces outils.
|
||||
|
||||
## Monitoring "sur site"
|
||||
|
||||
## Journaux
|
||||
|
||||
Ce que j'appelle "monitoring sur site", c'est comment surveiller son système depuis un shell.
|
||||
Un certain nombre de commandes existent pour nous permettre de diagnostiquer le fonctionnement de notre serveur.
|
||||
|
||||
Pour commencer, rien ne vaut les journaux.
|
||||
Concernant notre serveur, voici ceux qui sont principalement à surveiller :
|
||||
|
||||
- */var/log/syslog*, probablement le plus important de tous
|
||||
- */var/log/fail2ban.log*, pour surveiller ce que fail2ban fait
|
||||
- */var/log/mail.log*, pour surveiller le serveur mail
|
||||
- */var/www/*/*/log/*, pour surveiller les accès et erreurs sur l'ensemble de vos sites Internet
|
||||
|
||||
Pour consulter en temps réel un journal, utilisez la commande suivante :
|
||||
|
||||
```bash
|
||||
tail -f /var/log/syslog
|
||||
```
|
||||
|
||||
Pour consulter les X dernières lignes d'un journal :
|
||||
|
||||
```bash
|
||||
tail -X /var/log/syslog
|
||||
```
|
||||
|
||||
## Processus
|
||||
|
||||
Le monitoring sur site implique également la surveillance des processus.
|
||||
La commande suivante :
|
||||
|
||||
```bash
|
||||
ps aux
|
||||
```
|
||||
|
||||
Vous indiquera l'état des processus au moment où vous lancez la commande.
|
||||
Pour consulter l'état des processus en temps réel, utilisez la commande :
|
||||
|
||||
```bash
|
||||
top
|
||||
```
|
||||
|
||||
Cette commande vous informe également de l'état de la mémoire, de l'utilisation CPU, et d'autres choses encore.
|
||||
|
||||
## Matériel
|
||||
|
||||
Si vous hébergez vous-même votre serveur "à la maison", vous pourrez également avoir besoin de quelques capteurs de température :
|
||||
|
||||
```bash
|
||||
apt-get install lm-sensors
|
||||
sensors-detect
|
||||
```
|
||||
|
||||
De même pour les disques durs :
|
||||
|
||||
```bash
|
||||
apt-get install hddtemp
|
||||
hddtemp /dev/sd*
|
||||
```
|
||||
|
||||
D'autres informations relatives à votre matériel peuvent être extraites du pseudo système de fichiers */proc* :
|
||||
|
||||
```bash
|
||||
cat /proc/cpuinfo
|
||||
cat /proc/meminfo
|
||||
```
|
||||
|
||||
## RAID
|
||||
|
||||
Si vous bénéficiez d'un raid logiciel, vous pouvez consulter son état de différentes manières :
|
||||
|
||||
```bash
|
||||
cat /proc/mdstat
|
||||
mdadm --detail /dev/md0
|
||||
```
|
||||
|
||||
## Monitoring distant
|
||||
|
||||
Le monitoring distant est effectué depuis une interface web par exemple.
|
||||
J'ai choisi [phpSysInfo](https://web.archive.org/web/20120222160009/http://phpsysinfo.sourceforge.net/), que je trouve plus agréable à configurer et utiliser que munin, trop centré sur la création de graphs, et relativement compliqué à mettre en œuvre.
|
||||
|
||||
## Hôte virtuel
|
||||
|
||||
Première chose, comme d'habitude, on s'occupe de l'hôte virtuel dans apache :
|
||||
|
||||
```bash
|
||||
mkdir -p /var/www/exemple.fr/system/www
|
||||
nano /etc/apache2/sites-available/system.exemple.fr
|
||||
```
|
||||
|
||||
```text
|
||||
<VirtualHost *:80>
|
||||
ServerName system.exemple.fr
|
||||
Redirect / https://system.exemple.fr/
|
||||
</VirtualHost>
|
||||
|
||||
<VirtualHost *:443>
|
||||
ServerName system.exemple.fr
|
||||
|
||||
DocumentRoot /var/www/exemple.fr/system/www
|
||||
|
||||
SSLEngine On
|
||||
SSLCertificateFile /scripts/certificate_authority/apache/system.exemple.fr.crt
|
||||
SSLCertificateKeyFile /scripts/certificate_authority/apache/system.exemple.fr.key
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe.
|
||||
Créons maintenant les certificats :
|
||||
|
||||
```bash
|
||||
/scripts/certificate_authority/make_request apache system.exemple.fr
|
||||
/scripts/certificate_authority/sign_request apache system.exemple.fr
|
||||
chown www-data:www-data /scripts/certificate_authority/apache/*
|
||||
```
|
||||
|
||||
Warning : Lorsque le *Common Name* vous sera demandé, indiquez le nom de domaine !
|
||||
Et dans notre cas, acceptez la création d'une clé sans mot de passe !
|
||||
|
||||
On active le site, et on redémarre apache :
|
||||
|
||||
```bash
|
||||
a2ensite system.exemple.fr
|
||||
/etc/init.d/apache2 restart
|
||||
```
|
||||
|
||||
Dans ce cas, il n'y a pas vraiment besoin de tenir des journaux.
|
||||
|
||||
## Installation de phpSysInfo
|
||||
|
||||
Rien de particulier à signaler : une fois l'application téléchargée et installée dans son répertoire (*/var/www/exemple.fr/system/www*), il suffit juste de la configurer en fonction des blocs que vous souhaitez afficher.
|
||||
|
||||
Certaines dépendances peuvent être nécessaires, en fonction des blocs que vous aurez configuré.
|
||||
L'application vous informera via des messages d'erreurs si des dépendances ne sont pas satisfaites.
|
||||
Vous pourrez alors aisément les installer.
|
||||
|
||||
## Notifications
|
||||
|
||||
Si vous faites appel à crontab pour effectuer des tâches routinières, il peut être intéressant d'avoir des rapports par mail.
|
||||
Il vous suffit d'éditer votre crontab et d'y insérer la ligne suivante :
|
||||
|
||||
```text
|
||||
MAIL="contact@exemple.fr"
|
||||
```
|
||||
|
||||
Nous avons installé [un serveur XMPP](https://web.archive.org/web/20120222160009/http://ingnu.fr/2012/02/08/communiquer-via-xmpp/), on peut également s'en servir comme service de notification.
|
||||
Ainsi, pour toute application qui permet d'exécuter une commande suivant un évènement donné, on peut demander à cette application d'envoyer un message à un compte XMPP que vous aurez créé à cet effet.
|
||||
Nous utiliserons pour cela le script *sendxmpp* :
|
||||
|
||||
```bash
|
||||
apt-get install sendxmpp
|
||||
```
|
||||
|
||||
Que l'on utilisera de la manière suivante :
|
||||
|
||||
```bash
|
||||
echo "Votre message" | sendxmpp -u <utilisateur> -p <mot de passe> -j exemple.fr <destinataire>@exemple.fr
|
||||
```
|
||||
|
||||
## Liste des paquets installés
|
||||
|
||||
Il peut être utile de récupérer la liste de tous les paquets installés, par exemple dans le cas d'une réinstallation ou d'un mirroring.
|
||||
Pour récupérer cette liste, on utilisera la commande suivante :
|
||||
|
||||
```bash
|
||||
dpkg -l | grep ii | awk -F ' ' '{print $2}'
|
||||
```
|
||||
|
||||
On peut, du coup, exporter cette liste dans un fichier :
|
||||
|
||||
```bash
|
||||
dpkg -l | grep ii | awk -F ' ' '{print $2}' > packages.list
|
||||
```
|
||||
|
||||
## Conclusion
|
||||
|
||||
Plein d'autres choses manquent surement à l'appel.
|
||||
On ne peut pas tout voir, mais théoriquement, ce qu'on a vu jusqu'aujourd'hui devrait être suffisant pour que vous puissiez jouer avec votre propre cloud.
|
||||
|
||||
Important : Ceci dit, avant de vraiment jouer avec, attendez au moins l'avant-dernier article (qui est aussi le prochain), consacré à la sauvegarde et à la restauration de son serveur !
|
||||
Reference in New Issue
Block a user