Planète auto-hébergement

2015-01-28

Debloquer les 4 ports LAN sur la B-Box 2

Belgacom fournit un box appellée B-Box (à ne pas confondre avec la Bouygues Bbox en France).

Elle contient 2 ports LAN et 2 ports TV. Mais il s’agit de ports ethernet dans les 2 cas. Voyons voir comment utiliser les ports TV comme ports LAN pour brancher plus d’ordinateurs sur la box !

Allez dans l’interface d’admin ( http://192.168.1.1 ) -> Advanced settings -> Route -> Routing. Puis tout en bas de la page, vous verrez ceci :

RoutingDécochez les ports TV et Cliquez sur le bouton Apply. Voila !

J'aime(2)Ferme-la !(0)

2015-01-27

Votre blog avec de vrais morceaux de SSL !

CAcert-logo-colour-1000

Avoir un vrai certificat signé et approuvé par une autorité de certification SSL, c’est un peu le Graal pour le geek !

Mais voilà, ça coûte souvent (très) cher, pas toujours évident à mettre en place …

Voici donc une méthode simple pour avoir vos propres certificats (oui oui, au pluriel !) @ home et cela gratuitement (c’est la crise ma brave dame !).

I) Inscription sur cacert.org

Commencez par vous inscrire sur https://www.cacert.org/ (certains me diront, qu’il y a startssl qui propose aussi des certificats, mais c’est un vrai parcours du combattant pour s’y inscrire …)
Vous aurez un formulaire à remplir de ce type, attention toutes les infos doivent être vraies ! (car si vous souhaitez aller plus loin, il faudra fournir des pièces d’identités officielles)

Capture d'écran - 27012015 - 13:22:48

 

II) L’interface d’administration

Une fois inscrit, et que vous avez validé les mails …
Vous avez accès au menu suivant :

Capture d'écran - 27012015 - 13:28:13

Vous pouvez vous dès à présent générer un certificat client puis l’installer dans votre navigateur, pour vous connecter plus tard sur cacert.org (ce que je vous recommande et ce qui est même obligatoire si vous souhaitez passer des tests, devenir accréditeur …)

C’est sur ce menu que vous allez générer vos différents certificats, rajouter des domaines, modifier des options …

Mais aussi, pouvoir demander à être accréditer, c’est important, car de base, vous avez 0 points, avec ce nombre bien maigre, vous allez tout de même pouvoir générer vos certifs, mais ils ne seront valident que 6 mois !!

Un poil fatiguant, je vous l’accorde !

Une fois que vous aurez été validé physiquement et à l’aide d’au moins deux pièces d’identités, vous allez obtenir des points.
le premier pallier (la liste complète est ici : https://wiki.cacert.org/FAQ/Privileges ) est à 50 points et vous permets d’avoir des certificats valident 24 mois.

Vous trouverez la liste des accréditeurs proches de chez vous à partir du menu, il y en a un peu partout en France, et il y également des sessions de signature dédiées à ça plusieurs fois par an.

 

 

 

III) Créer son premier certificat

M’enfin revenons à notre mouton, pour le créer (le certificat hein !), il faut commencer par rajouter un domaine dans le menu « Domaines », une fois validé (avec une simple vérification par mail), vous aurez une liste ce ce type :

Capture d'écran - 27012015 - 13:44:17

L’étape suivant se passe sur votre serveur :

On installe le paquet pour générer les clés et les demandes :

apt-get install openssl

Puis on génère une clé (le fichier key) :

openssl genrsa -out server.key 2048

Et enfin une demande de signature (le csr)

openssl req -new -key server.key -out server.csr

Attention à bien répondre aux questions !

retournez sur cacert.org, et ajouter un certificat serveur grâce au menu du même nom (ils ont bien fait les choses !)
puiscollez y votre fichier CSR

Capture d'écran - 27012015 - 13:54:47

Il vous reste à choisir le type de hachage et à valider !
à l’étape suivante, vous aurez votre certificat, que vous aurez à coller sur votre serveur dans le fichier server.crt

nano server.crt

Vous aurez un résumé de ce type :

Capture d'écran - 27012015 - 13:58:27

IV) Modifier votre serveur web

Votre certificat étant créée et validé, vous avez plus qu’à l’utiliser !
voici un exemple sur un serveur web nginx (avec fastcgi) :

nano /etc/nginx/sites-enabled/default-ssl
server {
    root /var/www/;
    listen       443;
    server_name www.sheldon.fr;
    index index.php index.html index.pl;

#ssl
        ssl on;
        ssl_certificate /etc/nginx/ssl/www.sheldon.fr.crt;
        ssl_certificate_key     /etc/nginx/ssl/www.sheldon.fr.key;

location /nginx_status {
    stub_status on;
    access_log off;
    allow 127.0.0.1;
    deny all;
}
    server_name_in_redirect off;
    port_in_redirect off;

    location ~* ^.+\.(jpg|jpeg|gif|css|png|js|ico)$ {
        access_log        off;
        expires           30d;
    }

    # rewrite rules
    location / {
        if (!-e $request_filename) {
            rewrite  ^/(.*)$  /index.php?q=$1  last;
        }
    }

    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }

}

Et si vous souhaitez que votre port 80 redirige automatique sur le port 443, faites la modif suivante :

nano /etc/nginx/sites-enabled/default
server {
    listen       80;
    server_name www.sheldon.fr;
    return 301 https://www.sheldon.fr$request_uri;
}

Après avoir redémarré votre serveur web, et consulté votre magnifique site, voici ce que vous obtiendrez (et sans erreur obscure de votre navigateur !)

Capture d'écran - 27012015 - 14:11:00 Capture d'écran - 27012015 - 14:09:42

Alors, happy ? :)

Il vous reste plus qu’à faire comme moi et rajouter un certificat par service (messagerie, hébergement divers, xmpp …) et sans oublier de vous faire accréditer !!

Mon petit PRA (plan de reprise d’activité) d’auto-hébergement chez CloudWatt, avec OpenStack

J’ai mis en place un petit PRA (https://fr.wikipedia.org/wiki/Plan_de_reprise_d’activité) pour mes serveurs.

C’est rigolo d’appliquer pour l’auto-hébergement les mêmes procédures qu’en entreprise. Les besoins et la mise en œuvre sont finalement assez proches.

Et ce n’est pas juste pour l’exercice : ces petits serveurs (Sheevaplug et Olinuxino A20) sont fragiles. Les filesystems sont sur des cartes SD, l’alimentation non redondée, le matériel non protégé etc. Le risque de panne est donc réel. L’idée est d’avoir un plan de secours en cas de gros problème, pour remettre en ligne le nécessaire le plus vite possible.

Et c’est chez CloudWatt que j’ai décidé de mettre mon instance de secours, en utilisant les APIs OpenStack

cloudwatt   OpenStack

Avant de basculer en PRA

Le PRA est en général un dernier recours.

En cas de panne, il faut d’abord essayer de refaire marcher l’ensemble sur site. Pour ça, on s’appuie sur du classique :

  • sauvegardes régulières (et testées de temps en temps)
  • du matériel de spare (si possible exactement le même : ça peut permettre d’y déplacer directement le filesystem)
  • pouvoir (sans trop transpirer) déplacer des services d’une machine à une autre
  • rendre les services (et serveurs) aussi indépendants les uns des autres que possible : si l’un est indisponible, il faut éviter que ça bloque les autres

Objectifs du PRA dans mon contexte d’auto-hébergement

D’abord identifier les services les plus critiques. Dans mon cas, c’est essentiellement ce blog. J’y rajouterai probablement d’autres services par la suite.

Ensuite définir les objectifs :

Ici, une “perte de données maximale” de 1j me parait largement raisonnable. Le contenu (articles + commentaires) ne bouge pas très souvent donc il y a de grandes chances de ne perdre aucune donnée en restaurant une sauvegarde à J-1.

Quant à la “durée d’interruption maximale”, je ne pourrai pas faire mieux qu’1j, à moins que le problème se produise quand je suis chez moi.

Quel site externe ?

L’idée est de pouvoir basculer rapidement le blog sur un autre serveur en cas de gros problème technique. Mais où ça ?

Pour faire tourner le blog, les besoins sont assez minimalistes, et il y a plein de solutions.

Mes exigences étaient que cela soit gratuit ou très peu cher, et que je puisse facilement faire basculer dessus la résolution DNS.

Assez vite, je me suis tourné vers des clouds avec tarification à l’usage.

En effet, 99 % du temps, je n’ai pas besoin que ma machine de PRA soit en ligne. Je n’en ai besoin que dans 2 cas de figure :

  • quand je veux mettre à jour les données dessus (quelques minutes chaque jour)
  • quand je veux basculer dessus (ce qui n’arrivera que très rarement, je l’espère)

Le reste du temps, il faut éviter de payer pour rien.

Pourquoi CloudWatt ?

CloudWatt a quelques particularités qui m’ont plu :

  • Basé sur OpenStack : je préfère ne pas me lier à un cloud particulier via des APIs propriétaires. Et ce que j’apprendrai sur les APIs OpenStack pourra me servir sur d’autres clouds
  • Apparemment engagé dans le logiciel libre
  • Hébergé en France

cloudwatt

Pour ne pas payer inutilement, il faut re-créer l’instance (la VM) à chaque fois qu’on en a besoin. Évidemment, ça peut se faire programmatiquement via l’API. Et les données peuvent être persistées dans des volumes, images et snapshots (tarifés suivant l’espace disque utilisé)

Coût prévisionnel

Stockage bloc (image, snapshot ou volume) : 3Go => 0.12€HT/mois

Instance tiny (la moins puissante) : quelques minutes par jour pour la mise à jour. 6 minutes/j = 3h/mois => 0.03€HT/mois

Trafic réseau : minimum=1Go => 0.089€HT/mois

Au total : 0.239€HT/mois = un peu moins de 30 centimes TTC/mois => moins de 3€50/an. Ça parait tout à fait raisonnable.

Et, si j’utilise l’instance de PRA (ce qui devrait être très rare, et ne pas durer longtemps), ça coûte un peu moins de 30 centimes TTC par jour. Là aussi, ce n’est franchement pas exorbitant.

De plus, tout ça est gratuit jusqu’au 24 mars 2015, ce qui permet de tester sans frais.

Pourquoi pas un serveur similaire chez un autre auto-hébergé ?

Ce serait une solution radicalement différente : plutôt que de mettre son PRA dans un cloud, le mettre chez un autre auto-hébergé.

Je trouve que cette solution serait assez fun.

Mais c’était l’occasion de jouer avec CloudWatt/OpenStack, donc pas pour cette fois.

Peut-être pour la v2 ? :-)

Implémentation et méthode

Besoin : synchroniser automatiquement les données vers le serveur externe, une fois par jour.

Principe et persistance des données

Comme déjà évoqué, je n’ai pas besoin d’une instance qui tourne 24h/24, mais uniquement quelques minutes par jour (le temps d’y mettre à jour les données).

Mais comment avoir des données persistantes, et ne pas repartir à zéro à chaque fois ?

Au départ, j’avais pensé à mettre tout le filesystem (OS compris) dans un volume persistant. C’est le plus simple à mettre en œuvre mais je suis tombé sur une limitation : impossible de créer un volume persistant (basé sur Debian) de moins de 20 Go. Or je n’ai pas envie de payer pour tout cet espace alors que j’en utiliserai 10 fois moins.

Donc, solution alternative :

  • un snapshot du filesystem pour l’OS et la configuration d’Apache/MySQL : 1.3Go. Je n’aurai besoin de refaire ce snapshot que pour les mises à jour du système ou de la configuration
  • un volume persistant pour les données (avec des liens symboliques qui pointent dessus pour /var/www et  /var/lib/mysql) : 1Go. C’est là-dessus que les données seront mises à jour quotidiennement

Petit inconvénient de cette solution : si on peut attacher un volume au démarrage via l’API, on ne peut pas le faire depuis la console de gestion web. Si on n’a pas d’accès SSH/console à la machine, il faut donc créer l’instance, puis attacher l’IP et le volume, puis la rebooter.

Préparation du serveur distant

sudo apt-get install apache2 libapache2-mod-php5 php5-mysql mysql-server rsync bash-completion
sudo a2enmod rewrite ssl

+ Création du ou des sites Apache2

+ Création du user et de la base de données MySQL

Script de sauvegarde

Création/lancement de la VM

Télécharger le fichier openrc.sh depuis votre compte CloudWatt (qui contient les identifiants), et installer le client Openstack en ligne de commande (j’ai utilisé la version en Python).

OpenStack

La VM peut être lancée par script comme suit :

#!/bin/bash
source openstack-env/bin/activate
source openrc.sh
echo "Création de l'instance"
nova boot --image bb6785de-81de-48c0-8418-f20f48321f4b --flavor 16 instance_pra --block-device id=1fdffab7-1298-4e7b-9261-43bfb67a7605,source=volume,dest=volume
echo "Attente 30s de la préparation de l'instance..."
sleep 30
echo "Affectation de l'IP publique"
nova add-floating-ip instance_pra x.x.x.x
echo "Attente 90s du démarrage d'OpenSSH..."
sleep 90

Synchronisation des données

echo "Synchronisation des données PHP"
rsync -av --delete /var/www/wordpress/ cloud@x.x.x.x:/var/www/wordpress
echo "Export de la base MySQL"
mysqldump -u wordpress --password=xxx wordpress >export_wordpress.sql
echo "Transfert du dump de la base MySQL"
scp export_wordpress.sql cloud@x.x.x.x:/home/cloud
echo "Adaptation des données pour la VM, en SSH"
scp adaptation_donnees_pra.sh cloud@x.x.x.x:/home/cloud
ssh cloud@x.x.x.x 'chmod +x /home/cloud/adaptation_donnees_pra.sh;/home/cloud/adaptation_donnees_pra.sh'

echo "Attente 30s avant suppression de l'instance, par précaution"
sleep 30
echo "Suppression de l'instance"
nova delete instance_pra

Adaptation des données pour la VM

Le fichier adaptation_donnees_pra.sh est exécuté sur le serveur distant :

#!/bin/bash
echo "Import des données MySQL"
mysql -u wordpress --password=xxx -D wordpress < /home/cloud/export_wordpress.sql
# Pratique pour les tests, si l'URL n'est pas la même
#echo "update wp_options set option_value='http://y.y.y.y' where option_name='siteurl' or option_name='home';" | mysql -u root -p -D wordpress
echo "Désactivation de WP SuperCache"
sudo sed -i "/^# BEGIN WPSuperCache/,/^# END WPSuperCache/d" /var/www/wordpress/.htaccess
sudo rm -rf /var/www/wordpress/wp-content/cache/*
sudo rm -rf /var/www/wordpress/wp-content/plugins/wp-super-cache
sudo chown -R www-data:www-data /var/www/wordpress

Et on met tout ça dans un cron pour que ça s’exécute chaque nuit.

Problème de clé SSH regénérée pour chaque instance CloudWatt

En l’état, les scripts ci-dessus échouent à cause d’un problème de clé SSH : à chaque création d’une nouvelle instance chez CloudWatt, la clé SSH est écrasée par une nouvelle. Donc le client SSH plante en disant qu’il ne reconnaît pas la clé correspondant à l’IP.

Première (mauvaise) solution : rajouter des options à ssh/scp/rsync pour qu’ils ignorent le problème

-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=error

Pour rsync, cela consiste à rajouter l’option :

-e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=error"

(le LogLevel est nécessaire pour qu’il n’y ait pas de “Warning : Permanently added ‘x.x.x.x’ to the list of known hosts” dans la sortie d’erreur, qui génère en envoi de mail quand c’est lancé en cron)

Ca fonctionne bien, mais ouvre une belle faille de sécurité.

Meilleure solution : donner des clés SSH fixes à la création de l’instance en Customization Script / User Data

Avec OpenStack, il est possible de passer ce qu’ils appellent un “Customization Script” (autrement appelé “User Data”) à la création d’une instance.  Entre autres choses, cela permet de lui dire quelles clés SSH utiliser (au lieu qu’il les génère à la création).

Dans la VM, c’est exécuté au premier démarrage via le package cloud-init (au moins sur Debian et Ubuntu, je ne sais pas pour les autres OS)

A partir des exemples de http://cloudinit.readthedocs.org/en/latest/topics/examples.html, j’ai pu créer un fichier cloud-config.txt qui ressemble à ça (les clés SSH sont des exemples) :

#cloud-config

# Send pre-generated ssh private keys to the server
# If these are present, they will be written to /etc/ssh and
# new random keys will not be generated
ssh_keys:
  rsa_private: |
    -----BEGIN RSA PRIVATE KEY-----
    MIIBxwIBAAJhAKD0YSHy73nUgysO13XsJmd4fHiFyQ+00R7VVu2iV9Qcon2LZS/x
    1cydPZ4pQpfjEha6WxZ6o8ci/Ea/w0n+0HGPwaxlEG2Z9inNtj3pgFrYcRztfECb
    1j6HCibZbAzYtwIBIwJgO8h72WjcmvcpZ8OvHSvTwAguO2TkR6mPgHsgSaKy6GJo
    PUJnaZRWuba/HX0KGyhz19nPzLpzG5f0fYahlMJAyc13FV7K6kMBPXTRR6FxgHEg
    L0MPC7cdqAwOVNcPY6A7AjEA1bNaIjOzFN2sfZX0j7OMhQuc4zP7r80zaGc5oy6W
    p58hRAncFKEvnEq2CeL3vtuZAjEAwNBHpbNsBYTRPCHM7rZuG/iBtwp8Rxhc9I5w
    ixvzMgi+HpGLWzUIBS+P/XhekIjPAjA285rVmEP+DR255Ls65QbgYhJmTzIXQ2T9
    luLvcmFBC6l35Uc4gTgg4ALsmXLn71MCMGMpSWspEvuGInayTCL+vEjmNBT+FAdO
    W7D4zCpI43jRS9U06JVOeSc9CDk2lwiA3wIwCTB/6uc8Cq85D9YqpM10FuHjKpnP
    REPPOyrAspdeOAV+6VKRavstea7+2DZmSUgE
    -----END RSA PRIVATE KEY-----

  rsa_public: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAGEAoPRhIfLvedSDKw7XdewmZ3h8eIXJD7TRHtVW7aJX1ByifYtlL/HVzJ09nilCl+MSFrpbFnqjxyL8Rr/DSf7QcY/BrGUQbZn2Kc22PemAWthxHO18QJvWPocKJtlsDNi3 smoser@localhost

  dsa_private: |
    -----BEGIN DSA PRIVATE KEY-----
    MIIBuwIBAAKBgQDP2HLu7pTExL89USyM0264RCyWX/CMLmukxX0Jdbm29ax8FBJT
    pLrO8TIXVY5rPAJm1dTHnpuyJhOvU9G7M8tPUABtzSJh4GVSHlwaCfycwcpLv9TX
    DgWIpSj+6EiHCyaRlB1/CBp9RiaB+10QcFbm+lapuET+/Au6vSDp9IRtlQIVAIMR
    8KucvUYbOEI+yv+5LW9u3z/BAoGBAI0q6JP+JvJmwZFaeCMMVxXUbqiSko/P1lsa
    LNNBHZ5/8MOUIm8rB2FC6ziidfueJpqTMqeQmSAlEBCwnwreUnGfRrKoJpyPNENY
    d15MG6N5J+z81sEcHFeprryZ+D3Ge9VjPq3Tf3NhKKwCDQ0240aPezbnjPeFm4mH
    bYxxcZ9GAoGAXmLIFSQgiAPu459rCKxT46tHJtM0QfnNiEnQLbFluefZ/yiI4DI3
    8UzTCOXLhUA7ybmZha+D/csj15Y9/BNFuO7unzVhikCQV9DTeXX46pG4s1o23JKC
    /QaYWNMZ7kTRv+wWow9MhGiVdML4ZN4XnifuO5krqAybngIy66PMEoQCFEIsKKWv
    99iziAH0KBMVbxy03Trz
    -----END DSA PRIVATE KEY-----

  dsa_public: ssh-dss AAAAB3NzaC1kc3MAAACBAM/Ycu7ulMTEvz1RLIzTbrhELJZf8Iwua6TFfQl1ubb1rHwUElOkus7xMhdVjms8AmbV1Meem7ImE69T0bszy09QAG3NImHgZVIeXBoJ/JzByku/1NcOBYilKP7oSIcLJpGUHX8IGn1GJoH7XRBwVub6Vqm4RP78C7q9IOn0hG2VAAAAFQCDEfCrnL1GGzhCPsr/uS1vbt8/wQAAAIEAjSrok/4m8mbBkVp4IwxXFdRuqJKSj8/WWxos00Ednn/ww5QibysHYULrOKJ1+54mmpMyp5CZICUQELCfCt5ScZ9GsqgmnI80Q1h3Xkwbo3kn7PzWwRwcV6muvJn4PcZ71WM+rdN/c2EorAINDTbjRo97NueM94WbiYdtjHFxn0YAAACAXmLIFSQgiAPu459rCKxT46tHJtM0QfnNiEnQLbFluefZ/yiI4DI38UzTCOXLhUA7ybmZha+D/csj15Y9/BNFuO7unzVhikCQV9DTeXX46pG4s1o23JKC/QaYWNMZ7kTRv+wWow9MhGiVdML4ZN4XnifuO5krqAybngIy66PMEoQ= smoser@localhost

Il suffit ensuite, lors de la création de l’instance avec nova boot, de rajouter l’option :

--user-data cloud-config.txt

Cf http://docs.openstack.org/user-guide/content/inserting_userdata.html

Baptême par le feu et enseignements

Le 1er janvier 2015, coupure d’accès Internet chez mon FAI (défaillance du modem). Pas de bol. J’ai dû me lancer dans le PRA à marche forcée.

C’était à peu près prêt, sauf que la mise à jour des données n’était pas encore automatisée. J’ai donc dû mettre à jour les données à la main, mais en-dehors de ça, ça s’est bien déroulé.

Quels enseignements de ce premier test ?

  • Il faut prévoir comment faire la bascule en n’étant pas chez soi. D’où nécessité d’avoir accès aux identifiants/clés pour tout faire (en l’occurrence se connecter à CloudWatt et Gandi + si possible une possibilité de se logger sur la machine : clé SSH ou user/mot de passe). Mais attention à les conserver de manière sécurisée…
  • Si on bascule en PRA, il faut ensuite penser à bloquer la mise à jour quotidienne des données (sinon cela écraserait les données modifiées dans la journée)
  • Prévoir la procédure de bascule retour (fin du PRA). En l’occurrence, il s’agit simplement de re-transférer le site PHP et la base MySQL dans l’autre sens, et refaire la bascule DNS.

Contraintes

Une fois la procédure mise en place, la mise à jour se fait tous les jours, et tout est prêt pour un éventuel PRA.

Seules contraintes qui restent :

  • Tester de temps en temps une bascule, ne serait-ce que pour vérifier que les données sont à jour, que la procédure fonctionne toujours etc
  • Tenir à jour la configuration d’Apache sur l’instance de PRA, quand elle change sur sur le serveur principal

2015-01-26

Eviter les piratages « bêtes »

Le Monde raconte de quelle façon il s’est fait « piraté » son compte Twitter.

C’est intéressant comme dé-mystification de l’image du pirate. On y voit que les attaquants :

  • cherchent à provoquer l’erreur humaine en envoyant des faux mails (n’importe qui peut choisir le nom et l’adresse de l’émetteur des mails qu’il envoie) qui contiennent un lien vers une page web imitant l’interface d’administration des sites qu’elle connaît (LeMonde, Facebook, Gmail, etc…) dans le but de lui soutirer son mot de passe. Et ça marche !
  • volent le compte en parvenant à répondre à la fameuse « question personnelle » qui permet de récupérer son compte ou son mot de passe sur la majorité des services en ligne comme Gmail, Facebook ou Twitter.

Il n’y a donc point d’exploit informatique ici, juste une méconnaissance des usagers vis à vis des bonnes pratiques:

  • Ayez un ordinateur non compromis (pas de virus, pas de cheval de Troie). Ceux qui ont compris ça utilisent uniquement des logiciels de confiance (pas de crack qui vient de n’importe où, pas de logiciel gratuits à publicités qui viennent t’espionner). Le mieux est d’utiliser uniquement des logiciels libres compilés par une tierce personne de confiance. Ça diminue encore les risques.
  • Vérifier toujours l’adresse de la page web sur laquelle vous êtes quand vous rentrez un mot de passe. C’est la seule garantie que vous envoyez le mot de passe au bon site. Ne vous fiez pas à la charte graphique. Vérifiez également que le cadenas SSL est présent.
  • Hébergez vos services vous même, comme ca pas besoin de « question personnelle » pour récupérer votre compte puisque vous avez accès à la machine pour modifier le mot de passe si besoin :-)
    • ou activez la double authentification (il faut une confirmation depuis votre smartphone pour changer le mot de passe du compte) et donnez une « question vraiment très personnelle » pour récupérer votre compte que ni un recherche Google ni votre plus proche ami, mère ou copain ne pourrait trouver. Sinon cette question devient une porte d’entrée plutôt qu’une sécurité.
J'aime(8)Ferme-la !(1)

2015-01-24

Sécuriser ses services avec les Jails FreeBSD et Packet Filter #2

Pour ceux qui auraient séchés la partie 1 :

Nous étions partis sur une architecture de cette forme, avec en fin de première partie 1, des petites jails en marche, chacune faisant tourner un service de votre choix ou rien, les services ne sont donnés qu'a titre d'exemple.



Dans mon exemple je n'utilise pas d’accès SSH direct sur mes jails, je me connecte toujours sur la machine hôte (j'ai fait le choix de ne pas me connecter à mes jails directement vers SSH) il va donc être important d'effectuer un petit lifting d'OpenSSH sur la machine hôte.

Menuiserie de la porte d'entrée :

Un petit rappel rapide qui ne fait pas de mal, une excellent méthode pour éviter de se faire emmerder par le bruteforce des scripts kiddies, changer le port d'écoute ssh par quelque chose d'assez haut : exemple le code postale de votre commune (ne fonctionne pas si vous êtes en région parisienne évidemment), laissez sur le port 22 va faire surchauffer votre /var/auth.log placer le port d'écoute sur 23235 (par exemple) va faire tendre le nombre de tentatives de connexions indésirables vers 0.

Un autre réflexe à prendre et de bannir l’accès ssh à root, avoir une politique de mot de passes très forte, et d'imposer une identification par clés sur des utilisateurs appartenant à un groupe autorisé à se connecter.

J'étais parti dans l'idée de mettre toute une explication de config mais quelqu'un d'autre le fait très bien ici.

Nous voilà avec une configuration un peu plus acceptable ... et c'est pris d'un réflexe casi pavlovien que vous vous précipitez sur un "pkg install fail2ban" pour empêcher toutes tentative de bruteforce sur votre socket SSH.

Oublie tout ça, maintenant c'est la vrai vie:

Et oui avec packet Filter, Fail2ban est inutile, en tout cas dans le cadre de la protection du bruteforce SSH (il peut toutefois rester utile pour faire d'autres choses). Je vous l'ai dit, on utilise un vrai Firewall qui sait tout faire, pas besoin de déjà commencer à ajouter une verrue ;).

Failban rend plein de bon et loyaux service en ... analysant les logs, c'est le problème il analyse les logs et ne travaille pas au niveau de la pile réseau ce qui dans le cadre de performances réseaux est tout bonnement à proscrire.

Une fois avoir activé notre firewall dans notre fichier /etc/rc.conf en ajoutant pf_enable="YES" à la fin.

Une règle de filtrage de ce genre dans notre firewall devrait convenir.
Je la prends volontaire en exemple car il s'agit sans doute d'une des plus "complexe" utilisant macro et options, que vous aurez à déclarer dans votre pf.conf :

# Block SSH bruteforce
pass in on $ext_if proto tcp from any to $ext_if port 22 \ flags S/SA keep state \ ( max-src-conn-rate 5/30, max-src-conn 5 \ overload <blacklist> flush global )


Ce qui signifie grossièrement de :
Passer les paquets TCP entrant sur l'interface $ext_if qui arrivent de n'importe ou any à destination du port 22.

Les handshakes TCP complets sont limitées à 5 en même temps max-src-conn 5, et pas plus de 5 tentatives toutes les 30 secondes. max-src-conn-rate 5/30.

Si une de ses limite est dépassée l'IP sera alors ajoutée dans une <'table'> overload <'bruteforce'> et toutes les connexions existantes seront supprimées flush global.

Oui comme son nom ne l'indique pas Packet Filter sait aussi manipuler des tables, ces dernières contenant des listes d'IP, de plages IP, v4 ou v6.

Le contenu de cette table peut directement être traiter/tester dans toutes nos règles.

# Et plus loin : Block des bruteforceur ssh.
block drop in on $ext_if from <blacklist>
#On peut utiliser également une whitelist
pass in on $ext_if from <whitelist>


La même mécanique est évidemment applicable à tous les ports.

Si vraiment vous trouvez ça trop fatiguant et souhaitez définitivement ajouter une verrue... vous pouvez toutefois utiliser un outil un façon "Fail2ban" likee pour SSH pf-sshguard qui s’intègre nativement à Packet Filter.

Celui-ci travaillant au niveau réseau en créant des tables Packet Filter et non pas sur une analyse de log.

Voilà petite mise en bouche "pratique", qui ne manquera pas de vous faire mettre tout de suite en route le téléchargement de FreeBSD.

En revanche attendez un peu avant de formater votre Ubuntu server ... continuez au moins la lecture.

Je t'avais prévenu PF c'est du fat ma gueule :

Le fichier de configuration est le bien nommé /etc/pf.conf, c'est dans ce dernier que vous configurerez vos règles de firewalling.
Un peu à la manière d'IPtable, ce dernier possède une syntaxe particulière et vos règles doivent être déclarées dans un certain ordre.

L'organisation du fichier représente également l'ordre dans lequel les paquets sont traités.

#- MACRO 
Declaration des "variables"
#- TABLES Déclaration des tables
#- GLOBAL OPTIONS scrubing paquets / gestion log
#- TRAFFIC NORMALIZATION Normalisation paquets
#- QUEUEING RULES et Prioritization Règles QoS / Gestion du traffic (je n'en fais pas encore)
#- TRANSLATION RULES (NAT) Translation d'adresses / Redirections
#- FILTER RULES Regles de filtrage
pass in log all keep state pass out log all keep state


Chaque partie est optionnelle, vous pouvez vous passer de TABLES ou de TRAFIC NORMALISATION.

En revanche il n'est pas possible de déclarer Les règles de filtering avant celle du NAT, ou une MACRO après une règle quelconque.

Je table sur une victoire Macro :

Quelque chose qui m'est apparu naturel, en découvrant Packet Filter est la présence des "variables", même des "listes", ou des "tables".
Tous les informaticiens sont accoutumés au concept de la variabilisation de valeurs.
Pourtant ... je n'avais jamais fait attention mais on ne peut pas créer de variables dans IPtables ... en découvrant l'usage dans Packet Filter on constate vraiment à quel point c'est dommage, ce concept est pratique et intuitif.

# --- Macro Variables and Tables ---
#
ext_if = "re0" int_if = "lo2" lan_network = $int_if:network
# --- Ip de vos JAILS --- JAIL_WEB="10.8.8.8" JAIL_SQL="10.8.8.9" JAIL_DNS="10.8.8.7"
# !!! Modifier en fonction de votre addresse !!! # Machine Hôte, faisant tourner les jails myself="192.168.1.15"
# --- IP d ou vous comptez vous connecter (ssh ou autre) admin="{ 192.168.0.0/24, 192.16.16.16, 2001:470:903f::/48 }"
# --- Vos ports sshport="25300" webports= "{ http, https }"
# --- Vos Tables table <blacklist> table <asia> persist file "/etc/pf.asia"


Jusque là je pense que tout le monde à bien compris, tout est clair pas besoin d'explication, notez comment on peut définir nos variables, nos plages d'IP en v4 ou v6, la façon dont il est possible de les déclarer, par leur numéro ou leur nom des services.
Les tables peuvent quant à elles chargée en mémoire et "flushée" lors du reload de la configuration du firewall ou d'un reboot de la machine.

Mais on peut aussi en déclarer en dur, les données seront chargées depuis un fichier, ou en leur appliquant l'option "const"

Oui, oui j'ai collé une bonne partie des IP de l'asie dans une table en chargeant le tout depuis un fichier ... Oui je suis un bourrin.
Avec IPtable ce n'est pas possible de faire ça, il faut utiliser une autre verrue encore une .. IPSet ou quelque chose du genre.

Extrait du contenu de /etc/pf.asia :

# Vietnam (VN)
1.52.112.0/20
14.160.0.0/11
27.64.0.0/12
42.112.0.0/13
58.186.0.0/15
112.78.0.0/20
112.197.0.0/16
112.213.80.0/20
113.22.0.0/16
113.23.0.0/17
113.160.0.0/11
115.72.0.0/13
115.84.176.0/22
116.96.0.0/12
117.0.0.0/13


Chaussures de ville exigées :

Une fois toutes nos macros/variables de déclarés, déclarons la politique globale à respecter sur le traitements des paquets.
# --- Global options / Normalisation ---
set block-policy drop set loginterface re0 set skip on lo scrub in all

  • set bloc-policy drop
Définit la politique par défaut d'un paquet refusé, le rejette t-on salement sans prévenir (drop). Ou préviens t'on l’émetteur avec une trappe ICMP que son paquet a été refusé.

  • loginterface re0
L'interface dont PF va s'occuper de loguer et analyser en l’occurrence notre interface physique.

  • skip on lo
Ne pas s'occuper de l'interface de loopback.

  • scrub in all
Assure une certaine hygiène réseau en rassemblant toutes les trames fragmentées, et rejetant les packets se présentant avec une mauvaise entête TCP. Permet de se protéger entre autre contre certains type d'attaques.

3eme porte à droite :

Il est temps maintenant de mettre en place nos règles de redirection et NAT; si l'on faisait de la QoS et du Queue de protocole il aurait fallut les déclarer juste avant or à ce jour je n'en fais toujours pas.

Cela fera une bonne occasion d'écrire un article à ce sujet le jour ou je m'y intéresserai :-)

Sauf exception, les packets matchant les règles de redirections ne sont pas exempts de filtrage.
Un paquet redirigé vers ma jail http par une régle de forwarding subira le traitement des règles de filtering avant de sortir de la carte réseau.

Avec PF tout est très clair ... pas comme avec vous savez qui ...

Les étapes de NAT et ou Redirections s'appellent donc avec le mot clé : "nat" ou "rdr"

# --- NAT and Redirect ---
#-------------------------

# Celle ligne assure le NAT des jails sur l'interface externe
# Tout ce qui arrive depuis $lan_network (soit le réseau virtuel) vers n'importe où
# Sortira avec l'IP réelle de la machine ($ext_if).
nat on $ext_if from $lan_network to any -> ($ext_if)

#S'assure qu'aucune IP indésirable ne sera forwardée vers mes JAILS HTTP - Puissant ! rdr on $ext_if inet proto tcp from { !<asia> !<bruteforce> } to $myself port { http, https } -> $JAIL_WEB # Exemple DNS notez l option pass rdr pass on $ext_if inet proto { tcp udp } from 192.168.0.0/24 to $myself port 53 -> $JAIL_DNS


La, on commence à réellement tatter de la véritable puissance du bourrier.

La première ligne est assez claire, elle fait du NAT sur l'interface externe de tout les packets arrivant $lan_network (Macro que l'on a déclarée plus haut).

La seconde ligne vient de mettre à mal IPtable une nouvelle fois.
Il est possible d'effectuer en quelque sorte du filtrage pendant le NAT/RDR.

Le comparateur { !<'asia'> !<'bruteforce'> } correspond à toutes les IP qui ne se trouvent PAS "!" dans les tables <'asia'> ET <'bruteforce'>, ces tables pouvrant être testé/manipulé par vos règles de filtrages.
Il aurait été aussi possible de fonctionner à l'inverse en autorisant par uniquement les IP se trouvant par exemple dans la table <'whitelist'> auquel inutile d'utiliser la négation "!".

Il existe plusieurs comparateurs :
  •  != (not equal)
  • < (less than)
  • > (greater than)
  • <= (less than or equal)
  • >= (greater than or equal)
  • >< (range)
  • (inverse range)
  •  : (inclusive range)

Je vous laisse imaginer les combinaisons de filtrages possible avec ces comparateurs, que cela soit sur les ports, sur les IP, tables, Interfaces réseaux ....

Un méchant h4ck3rz ayant voulu vous la faire à l'envers sur votre connexion SSH, sera non seulement blacklisté à la connexion, mais également sur votre service HTTP, alors c'est pas de la bonne ça ?

Pour la dernière ligne je redirige uniquement les IP de mon réseau local personnel, vers mon service DNS : l'option supplémentaire pass signifie que le paquet est redirigé directement vers $JAIL_DNS sans passer par les règles de filtrage déclarées plus loin, c'est une sorte de "goto-end" après la ligne.

You should not pass !

Maintenant que vous commencer à comprendre, la différence de potentiel entre les jouets et les outils professionnels ... tapons dans les règles de filtering des packets.

Pour rappels tous les packets sont soumises à toutes règles dans un ordre strict, comme définit plus haut, sauf ordre contraire.

Nous l'avons vu au chapitre précédent l'argument "pass" dans le cadre d'une redirection permet de court-circuiter les rêgles de filtering.
Dans les rêgles de filtering c'est l'argument "quick" qui aura cet effet.

Il est également possible d'utiliser les "comparateurs" vu dans la partie redirection/filtering.

Rien de bien sorcier encore une fois, la lecture des règles est bien claire.

La double règle de protection SSH fait doublons, elle est là pour détailler les possibilités de procéder :

# --- Rules Filtering ---
# -----------------------
# Par défaut tout est bloque en entree
# Sans parametre in/out c'est in qui est pris par defaut
# Attention toutefois avec la regle log all sur block ... (volumétrie)
block log all # A vous de voir pour la sortie. # block out log all # Antispoofing si vous machine a une patte sur le Web empêche les classes IP privée de se présenter.
# antispoof log quick # Block avec l option Quick les paquets matchant cette regles ne seront pas evalués plus loin block in quick log on $ext_if proto tcp from { <blacklist> <asia> } to any # Ici on s'occupe du bruteforce sur SSH comme vue au début pass in on $ext_if proto tcp from any to $ext_if port $sshport \ flags S/SA keep state \ ( max-src-conn-rate 5/30, max-src-conn 5 \ overload <blacklist> flush global ) # Autoriser la redirection plus haut vers http/https option quick pass in quick on $ext_if proto tcp to $JAIL_WEB port { http, https } keep state
# Autoriser uniquement des IP locales vers la jail DNS pass in on $ext_if proto { tcp, udp } <style>from 192.168.0.0/24 to $JAIL_DNS port 53 keep state

# Empeche les requetes sortante distantes sur le 53 ma Jail DNS-cache utilise DNSCrypt block out quick log on $ext_if proto { tcp udp } from any to any port 53
# Autoriser la connexion à SSH uniquement aux IP définies dans $admin pass in quick on $ext_if inet proto tcp from $admin to $myself port $sshport keep state
# Open bar sur la sortie pass out quick on $ext_if modulate state


La syntaxe de lecture est relativement similaire à celles des règles de redirection.

On retrouve en plus notre option "quick" qui permet de sortir tout de suite des règles si le packet "match" la condition. Cette condition permet d'apporter de nombreuses possibilités de filtering très intéressantes.

L'argument "keep state" en fin de règle permet de définir le comportement de PF vis à vis de l'état de la connexion une fois cette dernière établie, ce sont des options de tunning réseaux avancées dont il n'est pas nécessaire de connaitre toutes les valeurs possibles pour commencer."keep state" est l'option par défaut des règles.


Dat toolbox :

Outre /etc/pf.conf : qu'il faudra bien évidemment inclure dans votre sauvegarde machine, l'autre élément important pour "driver" Packet Filter est la commande pfctl qui vous donnera pleins d'infos et de moyen de driver bien utiles.

Quelques chose de vraiment cool avec FreeBSD c'est qu'il y a une grosse documentation, maintenue et béton, c'est souvent elle d'ailleurs qui cause le mieux :



Avec notamment :



Ou encore :



Quelques exemples pour ne pas salement vous lâcher la documentation en guise d'explication ;

Charge le fichier pf.conf
# pfctl -f /etc/pf.conf 

Analyse le fichier mais ne le charge pas (Très Pratique)
# pfctl -nf /etc/pf.conf

Montre les règles en court.
# pfctl -sr

Affiche l'état des tables.
# pfctl -ss

Affiche les compteurs les stats des filtres.
# pfctl -si

Affiche TOUT ce qui est possible de voir comme info.
# pfctl -sa

Charge le fichier .new attends 30 secondes ; puis recharge le fichier original (Pour éviter de se retrouver à la porte de chez soi !)
pfctl -vf /etc/pf.conf.new ; sleep 30; pfctl -f /etc/pf.conf

Affiche les Tables
# pfctl -s Tables

Afficher les entrées de la table table-name
# pfctl -T show -t table-name

Affiche les compteurs de "table-name"
# pfctl -T show -vt table-name  

Ajoute une 'ip-address' dans la table 'table-name'
# pfctl -T add -t table-name ip-address

Supprime 'Ip-address' de la table 'table-name'
# pfctl -T delete -t table-name ip-address 

Supprime les règles NAT :
# pfctl -F nat

Supprime les règles de queues :
# pfctl -F queue

Supprime les règles de filtrage :
# pfctl -F rules

Supprime TOUTES les règles/stat/contenu des tables.
# pfctl -F all



pfctl permet aussi d'ajouter/supprimer des régles à chaud, sans recharger la configuration, très sympathique dans un script en mode batch pour ouvrir un port sur demande par exemple.

# Insert une nouvelle règle au début des règles actuelles.
# (echo "block all"; pfctl -sr) | pfctl -f 

Insert une nouvelle règle à la fin des règles actuelles
# (pfctl -sr; echo "pass quick on lo0") | pfctl -f -


Je vous recommende également un packet également tiers très pratique : "pftop" (cela ne s'invente pas), qui vous donnera en temps réel à la manière d'un "top" les connexions sur votre firewall.



Pratique tout ceci n'est-ce pas ?

L'oeil bienveillant de Moscou :

Évidemment Packet Filter vous permet de jouer les gentils agents du KGB infiltrés dans les flux réseaux sur tout ce qui rentre et sort du firewall.

Une options présente dans les règles de Packet filter que je n'ai pas trop abordé jusqu'a maintenant et que vous n'avez pas manqué de remarquer évidemment est l'option "log" de nos règles.

Ces dernières ne seront réellement effectives que si j'ai au préalable déclarée une interface réseau virtuelle dédie à cette tâche de surveillance flicage.

Comme d'habitude avec FreeBSD pour tout ce qui attrait à la configuration du système et au démarrage des services cela se déclare dans "/etc/rc.conf" (oui encore lui), où vous rajouterez :

#Packet Filter (firewalling)
pf_enable="YES"
# log PF ?
pflog_enable="YES"


Cela aura pour effet de vous ajouter une interface virtuelle pflog qu'il est possible d'analyser en temps réel, de plus tout sera tracé dans un fichier /var/log/pflog. Ce dernier subira une rotation des logs automatique par newsyslog , l'outil de rotation des logs native de FreeBSD.

Petite mise en garde toutefois avec le mot clé "log", allez y tranquillement, dans l'usage de celui-ci dans vos déclarations. De préférence n'utiliser celui-ci que sur des règles "clés", ex surveillance d'un port de service. Ou alors bien surveiller sa volumétrie notamment /var/log.
En cas de tentatives de hack du genre SYN_FLOOD qui viendraient chatouiller les ports de vos services, cela pourrait vous causez de mauvaises surprises sur les volumétries.

D'une manière générale il est évidemment conseillé de monitorer ses différentes volumétries ;)

# file /var/log/pflog
/var/log/pflog: tcpdump capture file (little-endian) - version 2.4 (OpenBSD PFLOG, capture length 116)

La log est au format binaire, il n'est pas possible de l'éditer avec des éditeurs textes comme vi ou cat uniquement avec tcpdump ou des outils de capture de tram équivalent.

L'avantage de ce format est qu'il est possible d'utiliser toutes les options de tcpdump est un outil d'analyse de niveau chirurgical des flux réseau.
Ce dernier fournissant des informations très fournis sur les flux ainsi que de très nombreuses options d'analyses et filtres sur la log. Tcpdump mériterait de nombreux chapitres à lui tout seul, son usage sort du scope de cet article mais rapidement :

# - Afficher les connexions sur les port 80
# tcpdump -n -e -ttt -r /var/log/pflog port 80

# - Possibilité de preciser en fonction d'une IP et d'un port.
# tcpdump -n -e -ttt -r /var/log/pflog port 80 and host 192.168.1.3 

# Ou même agir directement sur l'interface virtuel pflog
tcpdump -n -e -ttt -i pflog0 host 192.168.4.2


En plus des options "natives" à tcpdump, Packet Filter propose des options "bonus" à ce dernier pour encore améliorer la synergie entre les deux outils comme :

Famille IPv4
  • ip
Famille IPv6.
  • ip6
Paquet passé par l'interface "int"
  • on int
Le numéro de la règle qui a matché le packet :
  • rulenum num
L'action effectuée sur le paquet "block ou pass"
  • action "type"
La raison pour laquelle l'action a été réalisée sur ce paquet
  • reason "type"
Packet entrant
  • inbound
Packet sortant
  • outbound

Ce qui en substance peut se traduire par des choses comme :

tcpdump -n -e -ttt -i pflog0 inbound and action block and on re0


Affiche en temps réel la liste des packets entrant qui sont bloqués sur l'interface re0.

Avec ce genre d'artillerie, plus d'excuses pour ne pas savoir ce qui se trame sur votre porte d'entrée.

Formatting Ubuntu Server ... (Y/n) : ?

Nous avons fait le tour de ce qui me semble être une bonne approche à l'isolement des services avec les jails et PF.

J'espère être resté assez clair dans l'ensemble et je ne pense pas avoir zapé trop de choses - hormis les Queues et la QoS mais ça ou pourra y revenir -

Evidemment Packet Filter propose d'autres options de tunning que je n'ai pas abordés ici, encore une fois, c'est la documentation qui en parle le mieux, tout est dessus, mais cette dernière n'en reste pas moins sobre et courte, je vous conseille fortement d'y mettre le nez.

Je sais que vous êtes chaud bouillant pour remplacer votre Ubuntu Server par FreeBSD mais tout de même je vous conseille élégamment de maquetter dans une VM pour commencer (l'ensemble tourne niquel sous VirtualBox) pour vous faire un peu la main, une fois votre conf au résultat plus ou moins attendu il sera super simple d'exporter les jails de votre maquettes vers votre production , le fichier /etc/pf.conf avec.

Attention toutefois la version Packet Filter FreeBSD est une version un peu en retard de sa soeur sous OpenBSD, et ne bénéficie pas de tout les mots clés par exemple comme "grep".

La prochaine fois on ira sans doute voir comment s'occuper un peu d'une politique de backup et restauration sérieuse et pas trop fatigante.

Ou bien peut-être abordera t-on une mise en place des jails plus "harmonieuse/réfléchit" entre ses services, découpage Mysql/Php/Nginx dans des jails différentes avec un Nginx-proxy-cache en frontal ... j'sais pas trop on verra bien ... p'tête que je parlerai photo après tout aussi y a pas de raisons, ou de la météo ou du cours de l'euro tient aussi c'est pas mal ça le cours de l'euro ...

A +
Pentakonix.

Sécuriser ses services avec les Jails FreeBSD et Packet Filter #2

Pour ceux qui auraient séchés la partie 1 :

Nous étions partis sur une architecture de cette forme, avec en fin de première partie 1, des petites jails en marche, chacune faisant tourner un service de votre choix ou rien, les services ne sont donnés qu'a titre d'exemple.



Dans mon exemple je n'utilise pas d’accès SSH direct sur mes jails, je me connecte toujours sur la machine hôte (j'ai fait le choix de ne pas me connecter à mes jails directement vers SSH) il va donc être important d'effectuer un petit lifting d'OpenSSH sur la machine hôte.

Menuiserie de la porte d'entrée :

Un petit rappel rapide qui ne fait pas de mal, une excellent méthode pour éviter de se faire emmerder par le bruteforce des scripts kiddies, changer le port d'écoute ssh par quelque chose d'assez haut : exemple le code postale de votre commune (ne fonctionne pas si vous êtes en région parisienne évidemment), laissez sur le port 22 va faire surchauffer votre /var/auth.log placer le port d'écoute sur 23235 (par exemple) va faire tendre le nombre de tentatives de connexions indésirables vers 0.

Un autre réflexe à prendre et de bannir l’accès ssh à root, avoir une politique de mot de passes très forte, et d'imposer une identification par clés sur des utilisateurs appartenant à un groupe autorisé à se connecter.

J'étais parti dans l'idée de mettre toute une explication de config mais quelqu'un d'autre le fait très bien ici.

Nous voilà avec une configuration un peu plus acceptable ... et c'est pris d'un réflexe casi pavlovien que vous vous précipitez sur un "pkg install fail2ban" pour empêcher toutes tentative de bruteforce sur votre socket SSH.

Oublie tout ça, maintenant c'est la vrai vie:

Et oui avec packet Filter, Fail2ban est inutile, en tout cas dans le cadre de la protection du bruteforce SSH (il peut toutefois rester utile pour faire d'autres choses). Je vous l'ai dit, on utilise un vrai Firewall qui sait tout faire, pas besoin de déjà commencer à ajouter une verrue ;).

Failban rend plein de bon et loyaux service en ... analysant les logs, c'est le problème il analyse les logs et ne travaille pas au niveau de la pile réseau ce qui dans le cadre de performances réseaux est tout bonnement à proscrire.

Une fois avoir activé notre firewall dans notre fichier /etc/rc.conf en ajoutant pf_enable="YES" à la fin.

Une règle de filtrage de ce genre dans notre firewall devrait convenir.
Je la prends volontaire en exemple car il s'agit sans doute d'une des plus "complexe" utilisant macro et options, que vous aurez à déclarer dans votre pf.conf :

# Block SSH bruteforce
pass in on $ext_if proto tcp from any to $ext_if port 22 \ flags S/SA keep state \ ( max-src-conn-rate 5/30, max-src-conn 5 \ overload <blacklist> flush global )


Ce qui signifie grossièrement de :
Passer les paquets TCP entrant sur l'interface $ext_if qui arrivent de n'importe ou any à destination du port 22.

Les handshakes TCP complets sont limitées à 5 en même temps max-src-conn 5, et pas plus de 5 tentatives toutes les 30 secondes. max-src-conn-rate 5/30.

Si une de ses limite est dépassée l'IP sera alors ajoutée dans une <'table'> overload <'bruteforce'> et toutes les connexions existantes seront supprimées flush global.

Oui comme son nom ne l'indique pas Packet Filter sait aussi manipuler des tables, ces dernières contenant des listes d'IP, de plages IP, v4 ou v6.

Le contenu de cette table peut directement être traiter/tester dans toutes nos règles.

# Et plus loin : Block des bruteforceur ssh.
block drop in on $ext_if from <blacklist>
#On peut utiliser également une whitelist
pass in on $ext_if from <whitelist>

La même mécanique est évidemment applicable à tous les ports.

Si vraiment vous trouvez ça trop fatiguant et souhaitez définitivement ajouter une verrue... vous pouvez toutefois utiliser un outil un façon "Fail2ban" likee pour SSH pf-sshguard qui s’intègre nativement à Packet Filter.

Celui-ci travaillant au niveau réseau en créant des tables Packet Filter et non pas sur une analyse de log.

Voilà petite mise en bouche "pratique", qui ne manquera pas de vous faire mettre tout de suite en route le téléchargement de FreeBSD.

En revanche attendez un peu avant de formater votre Ubuntu server ... continuez au moins la lecture.

Je t'avais prévenu PF c'est du fat ma gueule :

Et comme tout ce qui envoie du bois, il y a les bon gros outils pour les manager et les bon outils ne sont bon que lorsqu’ils ont une vraie documentation, comme d'habitude avec FreeBSD aucun soucis pour ce dernier point.

Le fichier de configuration est le bien nommé /etc/pf.conf, c'est dans ce dernier que vous configurerez vos règles de firewalling.
Un peu à la manière d'IPtable, ce dernier possède une syntaxe particulière et vos règles doivent être déclarées dans un certain ordre.

L'organisation du fichier représente également l'ordre dans lequel les paquets sont traités.

#- MACRO 
Declaration des "variables"
#- TABLES Déclaration des tables
#- GLOBAL OPTIONS scrubing paquets / gestion log
#- TRAFFIC NORMALIZATION Normalisation paquets
#- QUEUEING RULES et Prioritization Règles QoS / Gestion du traffic (je n'en fais pas encore)
#- TRANSLATION RULES (NAT) Translation d'adresses / Redirections
#- FILTER RULES Regles de filtrage
pass in log all keep state pass out log all keep state


Chaque partie est optionnelle, vous pouvez vous passer de TABLES ou de TRAFIC NORMALISATION.

En revanche il n'est pas possible de déclarer Les règles de filtering avant celle du NAT, ou une MACRO après une règle quelconque.

Je table sur une victoire Macro :

Quelque chose qui m'est apparu naturel, en découvrant Packet Filter est la présence des "variables", même des "listes", ou des "tables".
Tous les informaticiens sont accoutumés au concept de la variabilisation de valeurs.
Pourtant ... je n'avais jamais fait attention mais on ne peut pas créer de variables dans IPtables ... en découvrant l'usage dans Packet Filter on constate vraiment à quel point c'est dommage, ce concept est pratique et intuitif.

# --- Macro Variables and Tables ---
#
ext_if = "re0" int_if = "lo2" lan_network = $int_if:network
# --- Ip de vos JAILS --- JAIL_WEB="10.8.8.8" JAIL_SQL="10.8.8.9" JAIL_DNS="10.8.8.7"
# !!! Modifier en fonction de votre addresse !!! # Machine Hôte, faisant tourner les jails myself="192.168.1.15"
# --- IP d ou vous comptez vous connecter (ssh ou autre) admin="{ 192.168.0.0/24, 194.50.39.28, 2001:470:903f::/48 }"
# --- Vos ports sshport="25300" webports= "{ http, https }"
# --- Vos Tables table <blacklist> table <asia> persist file "/etc/pf.asia"


Jusque là je pense que tout le monde à bien compris, tout est clair pas besoin d'explication, notez comment on peut définir nos variables, nos plages d'IP en v4 ou v4, la façon dont il est possible de les déclarer, par leur numéro ou leur nom des services.
Les tables peuvent quant à elles chargée en mémoire et "flushé" lors du reload de la configuration du firewall ou d'un reboot.
Mais on peut aussi en déclarer en dur, les données seront chargées depuis un fichier.

Oui, oui j'ai collé une bonne partie des IP de l'asie dans une table en chargeant le tout depuis un fichier ... Oui je suis un bourrin.
Avec IPtable ce n'est pas possible de faire ça, il faut utiliser une autre verrue encore une .. IPSet ou quelque chose du genre.

Extrait du contenu de /etc/pf.asia :

# Vietnam (VN)
1.52.112.0/20
14.160.0.0/11
27.64.0.0/12
42.112.0.0/13
58.186.0.0/15
112.78.0.0/20
112.197.0.0/16
112.213.80.0/20
113.22.0.0/16
113.23.0.0/17
113.160.0.0/11
115.72.0.0/13
115.84.176.0/22
116.96.0.0/12
117.0.0.0/13


Chaussures de ville exigées :

Une fois toutes nos macros/variables de déclarés, déclarons la politique globale à respecter sur le traitements des paquets.
# --- Global options / Normalisation ---
set block-policy drop set loginterface re0 set skip on lo scrub in all

  • set bloc-policy drop
Définit la politique par défaut d'un paquet refusé, le rejette t-on salement sans prévenir (drop). Ou préviens t'on l’émetteur avec une trappe ICMP que son paquet a été refusé.

  • loginterface re0
L'interface dont PF va s'occuper de loguer et analyser en l’occurrence notre interface physique.

  • skip on lo
Ne pas s'occuper de l'interface de loopback.

  • scrub in all
Assure une certaine hygiène réseau en rassemblant toutes les trames fragmentées, et rejetant les packets se présentant avec une mauvaise entête TCP. Permet de se protéger entre autre contre certains type d'attaques.

3eme porte à droite :

Il est temps maintenant de mettre en place nos règles de redirection et NAT; si l'on faisait de la QoS et du Queue de protocole il aurait fallut les déclarer juste avant or à ce jour je n'en fais toujours pas.
Cela fera une bonne occasion d'écrire un article à ce sujet le jour ou je m'y intéresserai :-)

Sauf exception, les packets matchant les règles de redirections ne sont pas exempts de filtrage. Un paquet redirigé vers ma jail http par une régle de forwarding subira le traitement des règles de filtering avant de sortir de la carte réseau.

Avec PF tout est très clair ... pas comme avec vous savez qui ...

Les étapes de NAT et ou Redirections s'appellent donc avec le mot clé : "nat" ou "rdr"

# --- NAT and Redirect ---
#-------------------------

# Celle ligne assure le NAT des jails sur l'interface externe
# Tout ce qui arrive depuis $lan_network (soit le réseau virtuel) vers n'importe où
# Sortira avec l'IP réelle de la machine ($ext_if).
nat on $ext_if from $lan_network to any -> ($ext_if)

#S'assure qu'aucune IP indésirable ne sera forwardée vers mes JAILS HTTP - Puissant ! rdr on $ext_if inet proto tcp from { !<asia> !<bruteforce> } to $myself port { http, https } -> $JAIL_WEB # Exemple DNS notez l option pass rdr pass on $ext_if inet proto { tcp udp } from 192.168.0.0/24 to $myself port 53 -> $JAIL_DNS


La, on commence à réellement tatter de la véritable puissance du bourrier.

La première ligne est assez claire, elle fait du NAT sur l'interface externe de tout les packets arrivant $lan_network (Macro que l'on a déclarée plus haut).

La seconde ligne vient de mettre à mal IPtable une nouvelle fois.
Vous ne rêvez pas il est possible d'effectuer en quelque sorte du filtrage pendant le NAT/RDR.

Le comparateur { !<'asia'> !<'bruteforce'> } correspond à toutes les IP qui ne se trouvent PAS "!" dans les tables <'asia'> ET <'bruteforce'>, ces tables pouvrant être testé/manipulé par vos règles de filtrages.
Il aurait été aussi possible de fonctionner à l'inverse en autorisant par uniquement les IP se trouvant par exemple dans la table <'whitelist'> auquel inutile d'utiliser la négation "!".

Il existe plusieurs comparateurs :
  •  != (not equal)
  • < (less than)
  • > (greater than)
  • <= (less than or equal)
  • >= (greater than or equal)
  • >< (range)
  • (inverse range)
  •  : (inclusive range)

Je vous laisse imaginer les combinaisons de filtrages possible avec ces comparateurs, que cela soit sur les ports, sur les IP, tables, Interfaces réseaux ....

Un méchant h4ck3rz ayant voulu vous la faire à l'envers sur votre connexion SSH, sera non seulement blacklisté à la connexion, mais également sur votre service HTTP, alors c'est pas de la bonne ça ?

Pour la dernière ligne je redirige uniquement les IP de mon réseau local personnel, vers mon service DNS : l'option supplémentaire pass signifie que le paquet est redirigé directement vers $JAIL_DNS sans passer par les règles de filtrage déclarées plus loin, c'est une sorte de "goto-end" après la ligne.

You should not pass !

Maintenant que vous commencer à comprendre, la différence de potentiel entre les jouets et les outils professionnels ... tapons dans les règles de filtering des packets.

Pour rappels tous les packets sont soumises à toutes règles dans un ordre strict, comme définit plus haut, sauf ordre contraire.

Nous l'avons vu au chapitre précédent l'argument "pass" dans le cadre d'une redirection permet de court-circuiter les rêgles de filtering.
Dans les rêgles de filtering c'est l'argument "quick" qui aura cet effet.

Il est également possible d'utiliser les "comparateurs" vu dans la partie redirection/filtering.

Rien de bien sorcier encore une fois, la lecture des règles est bien claire, La double règle de protection SSH fait doublons, elle est là pour détailler les possibilités de procéder :

# --- Rules Filtering ---
# -----------------------
# Par défaut tout est bloque en entree
# Sans parametre in/out c'est in qui est pris par defaut
block log all
# A vous de voir pour la sortie.
# block out log all

# Antispoofing si vous machine a une patte sur le Web empêche les classes IP privée de se présenter.
# antispoof log quick # Block avec l option Quick les paquets matchant cette regles ne seront pas evalués plus loin block in quick log on $ext_if proto tcp from { <blacklist> <asia> } to any # Ici on s'occupe du bruteforce sur SSH comme vue au début pass in on $ext_if proto tcp from any to $ext_if port $sshport \ flags S/SA keep state \ ( max-src-conn-rate 5/30, max-src-conn 5 \ overload <blacklist> flush global ) # Autoriser la redirection plus haut vers http/https option quick pass in quick on $ext_if proto tcp to $JAIL_WEB port { http, https } keep state
# Autoriser uniquement des IP locales vers la jail DNS pass in on $ext_if proto { tcp, udp } <style>from 192.168.0.0/24 to $JAIL_DNS port 53 keep state

# Empeche les requetes sortante distantes sur le 53 ma Jail DNS-cache utilise DNSCrypt block out quick log on $ext_if proto { tcp udp } from any to any port 53
# Autoriser la connexion à SSH uniquement aux IP définies dans $admin pass in quick on $ext_if inet proto tcp from $admin to $myself port $sshport keep state
# Open bar sur la sortie pass out quick on $ext_if modulate state


La syntaxe de lecture est relativement similaire à celles des règles de redirection.

On retrouve en plus notre option "quick" qui permet de sortir tout de suite des règles si le packet "match" la condition. Cette condition permet d'apporter de nombreuses possibilité de filtering très intéressantes.

L'argumet "keep state" en fin de règle permet de définir le comportement de PF vis à vis de l'état de la connexion une fois cette dernière établie, ce sont des options de tunning réseaux avancées dont il n'est pas nécessaire de connaitre toutes les valeurs possibles pour commencer avec PF,"keep state" est l'option par défaut des règles.


Dat toolbox :

Outre /etc/pf.conf : qu'il faudra bien évidemment inclure dans votre sauvegarde machine, l'autre élément important pour "driver" Packet Filter est la commande pfctl qui vous donnera pleins d'infos et de moyen de driver bien utiles.

Quelques chose de vraiment cool avec FreeBSD c'est qu'il y a une grosse documentation, maintenue et béton, c'est souvent elle d'ailleurs qui cause le mieux :



Avec notamment :



Ou encore :



Quelques exemples pour ne pas salement vous lâcher la documentation en guise d'explication ;

Charge le fichier pf.conf
# pfctl -f /etc/pf.conf 

Analyse le fichier mais ne le charge pas (Très Pratique)
# pfctl -nf /etc/pf.conf

Montre les règles en court.
# pfctl -sr

Affiche l'état des tables.
# pfctl -ss

Affiche les compteurs les stats des filtres.
# pfctl -si

Affiche TOUT ce qui est possible de voir comme info.
# pfctl -sa

Charge le fichier .new attends 30 secondes ; puis recharge le fichier original (Pour éviter de se retrouver à la porte de chez soi !)
pfctl -vf /etc/pf.conf.new ; sleep 30; pfctl -f /etc/pf.conf

Affiche les Tables
# pfctl -s Tables

Afficher les entrées de la table table-name
# pfctl -T show -t table-name

Affiche les compteurs de "table-name"
# pfctl -T show -vt table-name  

Ajoute une 'ip-address' dans la table 'table-name'
# pfctl -T add -t table-name ip-address

Supprime 'Ip-address' de la table 'table-name'
# pfctl -T delete -t table-name ip-address 

Supprime les règles NAT :
# pfctl -F nat

Supprime les règles de queues :
# pfctl -F queue

Supprime les règles de filtrage :
# pfctl -F rules

Supprime TOUTES les règles/stat/contenu des tables.
# pfctl -F all



pfctl permet aussi d'ajouter/supprimer des régles à chaud, sans recharger la configuration, très sympathique dans un script en mode batch pour ouvrir un port sur demande par exemple.

# Insert une nouvelle règle au début des règles actuelles.
# (echo "block all"; pfctl -sr) | pfctl -f 

Insert une nouvelle règle à la fin des règles actuelles
# (pfctl -sr; echo "pass quick on lo0") | pfctl -f -


Je vous recommende également un packet tiers très pratique : "pftop" (cela ne s'invente pas), qui vous donnera en temps réel à la manière d'un "top" les connexions sur votre firewall.



Pratique tout ceci n'est-ce pas ?

L'oeil bienveillant de Moscou :

Évidemment Packet Filter vous permet de jouer les gentils agents du KGB infiltrés dans les flux réseaux sur tout ce qui rentre et sort du firewall.
Une options présente dans les règles de Packet filter que je n'ai pas trop abordé jusqu'a maintenant et que vous n'avez pas manqué de remarquer évidemment est l'option "log" de nos règles.

Ces dernière ne seront réellement effectives que si j'ai au préalable déclarée une interface réseau virtuelle dédie à cette tâche de surveillance flicage.

Comme d'habitude avec FreeBSD pour tout ce qui attrait à la configuration du système et au démarrage des services cela se déclare dans "/etc/rc.conf" (oui encore lui), ou vous rajouterez :

#Packet Filter (firewalling)
pf_enable="YES"
# log PF ?
pflog_enable="YES"


Cela aura pour effet de vous ajouter une interface virtuelle pflog qu'il est possible d'analyser en temps réel, de plus tout sera tracé dans un fichier /var/log/pflog. Ce dernier subira une rotation des logs automatique par newsyslog , l'outil de rotation des logs native de FreeBSD

# file /var/log/pflog
/var/log/pflog: tcpdump capture file (little-endian) - version 2.4 (OpenBSD PFLOG, capture length 116)

La log est au format binaire, il n'est pas possible de l'éditer avec des éditeurs textes comme vi ou cat uniquement avec tcpdump ou des outils de capture de tram équivalent.

L'avantage de ce format est qu'il est possible d'utiliser toutes les options de tcpdump est un outil d'analyse de niveau chirurgical des flux réseau, ce dernier fournissant des informations très fournis sur les flux ainsi que de très nombreuses options d'analyses et filtres sur la log, et ce dernier mériterait de nombreux chapitre à lui tout seul, son usage sort du scope de cet article mais rapidement :

# - Afficher les connexions sur les port 80
# tcpdump -n -e -ttt -r /var/log/pflog port 80

# - Possibilité de preciser en fonction d'une IP et d'un port.
# tcpdump -n -e -ttt -r /var/log/pflog port 80 and host 192.168.1.3 

# Ou même agir directement sur l'interface virtuel pflog
tcpdump -n -e -ttt -i pflog0 host 192.168.4.2


En plus des options "natives" à tcpdump, Packet Filter propose des options "bonus" à ce dernier pour encore améliorer la synergie entre les deux outils comme :

Famille IPv4
  • ip
Famille IPv6.
  • ip6
Paquet passé par l'interface "int"
  • on int
Le numéro de la règle qui a matché le packet :
  • rulenum num
L'action effectuée sur le paquet "block ou pass"
  • action "type"
La raison pour laquelle l'action a été réalisée sur ce paquet
  • reason "type"
Packet entrant
  • inbound
Packet sortant
  • outbound

Ce qui en substance peut se traduire par des choses comme :

tcpdump -n -e -ttt -i pflog0 inbound and action block and on re0


Affiche en temps réel la liste des packets entrant qui sont bloqué sur l'interface re0.

Avec ce genre d'artillerie d’autopsies, plus d'excuses pour ne pas savoir ce qui se trame sur votre porte d'entrée.

Formatting Ubuntu Server ... (Y/n) : ?

Nous avons fait le tour de ce qui me semble être une bonne approche à l'isolement des services avec les jails et PF.

J'espère être resté assez clair dans l'ensemble et je ne pense pas avoir zapé trop de choses - hormis les Queues et la QoS mais ça ou pourra y revenir -

Evidemment Packet Filter propose d'autres options de tunning que je n'ai pas abordés ici, encore une fois, c'est la documentation qui en parle le mieux, tout est dessus, mais cette dernière n'en reste pas moins sobre et courte, je vous conseille fortement d'y mettre le nez.

Je sais que vous êtes chaud bouillant pour remplacer votre Ubuntu Server par FreeBSD mais tout de même je vous conseille élégamment de maquetter dans une VM pour commencer (l'ensemble tourne niquel sous VirtualBox) pour vous faire un peu la main, une fois votre conf au résultat plus ou moins attendu il sera super simple d'exporter les jails de votre maquettes vers votre production , le fichier /etc/pf.conf avec.

Attention toutefois la version Packet Filter FreeBSD est une version un peu en retard de sa soeur sous OpenBSD, et ne bénéficie pas de tout les mots clés par exemple comme "grep".

La prochaine fois on ira sans doute voir comment s'occuper un peu d'une politique de backup et restauration sérieuse et pas trop fatigante.

Ou bien peut-être abordera t-on une mise en place des jails plus "harmonieuse/réfléchit" entre ses services, découpage Mysql/Php/Nginx dans des jails différentes avec un Nginx-proxy-cache en frontal ... j'sais pas trop on verra bien ... p'tête que je parlerai photo après tout aussi y a pas de raisons, ou de la météo ou du cours de l'euro tient aussi c'est pas mal ça le cours de l'euro ...

A +
Pentakonix.

Fail2ban pour Owncloud 7 sur Debian Jessie

Petit guide pour couper court au crackage de vos passwords par le formulaire de login d’Owncloud.

Ajouter dans le fichier /etc/fail2ban/jail.conf :

[owncloud]
enabled = true
port = http,https
filter = owncloud
logpath = /var/log/owncloud.log
maxretry = 3

Modifier le fichier /etc/owncloud/config.php

'loglevel' => '2',
'logtimezone' => 'Europe/Brussels',

Le loglevel ne doit pas être supérieur à 2 pour que les tentatives de login soient enregistrées dans le log !
le logtimezone doit être accordé avec l’heure de votre serveur. Sinon fail2ban pensera toujours que la connexion est ancienne et ne bannira rien.

Créer un fichier /etc/fail2ban/filter.d/owncloud.conf:

[Definition]
failregex = .*"message":"Login failed:.*IP: '<HOST>'.*
ignoreregex =

Relancer le service fail2ban:
# systemctl fail2ban restart

Faites trois mauvaises tentatives de login sur Owncloud pour vérifier !
Pour vérifier le status de fail2ban:

# fail2ban-client status owncloud

Pour débloquer une IP:

# fail2ban-client set owncloud unbanip 192.168.0.13

Cette configuration de Owncloud et Fail2ban devraient être par défaut dans Debian à mon sens.

On peut également se connecter à Owncloud par l’API REST. Je n’ai pas testé si les erreurs de connexion par cette API étaient aussi enregistrées dans le fichier de log, et donc prises en compte par Fail2ban.

J'aime(5)Ferme-la !(1)

2015-01-21

Bloc-Notes : intégrer ownCloud à son Nas

Encore un Bloc-Notes sur l’installation de mon Nas maison. Cette fois il s’agit d’intégrer ownCloud pour se créer un petit cloud perso. Cela me permet d’avoir accès à un tas de choses depuis internet, musique, photos pour soirée diapos avec la famille, partager la dernière photo classe avec les grands-parents, etc.

Installation

Pour l’installation il n’y a rien de plus simple avec les dépôts proposer pour Debian. L’avantage, les mises à jour sont automatiques, toutes les dépendances sont installées d’un seul coup. Il suffit de suivre la marche à suivre sur le site du dépôt.

echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/community/Debian_7.0/ /' >> /etc/apt/sources.list.d/owncloud.list 
apt-get update
apt-get install owncloud

Et voilà notre owncloud fraîchement installé. Lors du premier démarrage je choisis d’utiliser une base de données Mysql, possédant déjà un serveur MariaDB j’aurai tort de m’en privé. De mon point vu il est plus facile et plus stable de maintenir une BDD Sql qu’une BDD SQlite, mais c’est totalement subjectif.

 Migration

1. La base de Données :

Sur l’ancienne j’exporte la BDD

mysqldump -u root -p cloud > save_cloud.sql

J’importe le fichier save_cloud.sql sur le nas et je restaure la base. Attention au préalable j’ai créé une base vide appelée owncloud.

#Création de la nouvelle BDD
#Je créer l'utilisateur de la BDD
CREATE USER 'owncloud'@'%' IDENTIFIED BY 'motdepasse';
#réglage de ses privilèges
GRANT USAGE ON * . * TO 'owncloud'@'%' IDENTIFIED BY 'motdepasse' ;
#création de la base de données
CREATE DATABASE IF NOT EXISTS `owncloud` ;
#l'utilisateur owncloud n'aura accès qu'a la BDD owncloud
GRANT ALL PRIVILEGES ON `owncloud` . * TO 'owncloud'@'192.168.66.166';
#je restaure la BDD
mysql -u root -p owncloud < save_cloud.sql

2. Les données :

Pour cette partie il ne s’agit que d’un copier-coller bête et méchant. Avant de commencer je monte le répertoire DATA du nouveau owncloud sur l’ancien en NFS.

sudo cp -r /var/www/owncloud/data/* /media/nouveauownCloud/data/
#En Ssh sur le Nas je redéfini les bon droits
chown -R www-data:www-data /var/www/owncloud/data

 Accès depuis internet

Pour l’accès depuis internet j’ai configuré mon reverse proxy (nginx), et le serveur apache du nas. Pour une connexion en SSL j’ai créer un certificat gratuit sur StartSSl.

1.Nginx en reverse proxy

Pour le reverse proxy, j’ai rajouté ses lignes dans le fichier /etc/nginx/site-enabled/reverse

# ** server owncloud
server {
        listen 443;
        server_name moncloud.mondomaine.tld;
        access_log  /var/log/moncloud.access.log;
        error_log  /var/log/moncloud.nginx_error.log error;
        ssl on;
        ssl_certificate [chemin vers le certificat];
        ssl_certificate_key [chemin ver la clée];
        location / {
                proxy_pass https://[adresse ip locale du serveur]/;
}

2. Apache serveur web

#je crée l'hôte virtuel owncloud
sudo nano /etc/apache2/sites-available/owncloud
#j'édite le fichier comme suit
<VirtualHost *:443>
        ServerAlias moncloud.mondomaine.tld

        DocumentRoot "/var/www/owncloud"
        <Directory "/var/www/owncloud">
                Options -Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                Allow from all
        </Directory>
        SSLEngine on
        SSLVerifyClient none
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0ean-shutdown downgrade-1.0 force-r$
        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
        SSLCertificateFile [chemin vers le certificat]
        SSLCertificateKeyFile [chemin vers la clée]
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
    ServerSignature Off
</virtualHost>

#j'active l'hôte virtuel
sudo a2ensite owncloud
#je relance apache
sudo service apache2 restart

Lors de la migration je n’ai rencontré aucune difficultés particulières. Je profite à présent des avantages d’un petit cloud personnel couplé à la puissance de stockage d’un Nas.

2015-01-20

Installer un serveur Mumble sur Debian

Ils commencent à m’emmerder ces ploutocrates à vouloir m’espionner sans juges ! Voici comment avoir des discussions audio en toute intimité avec le logiciel libre Mumble.

Et ce sera la preuve que leurs systèmes d’écoute automatisée sur les réseau téléphone, Skype, etc… ne va renifler que les honnêtes gens, ou les terroristes de pacotille.

mumbleDonc pour discuter en toute discrétion, il vous faut:

  • un PC
  • dont vous connaissez l’IP sur Internet
    (astuce pour la connaître en ligne de commande : $ curl ifconfig.me)
  • et qui accessible depuis Internet sur les ports UDP and TCP 64738. Ca se configure dans la box/routeur de votre FAI si vous avez ça.

Une fois que vous avez ça. Il suffit d’installer le serveur libre Murmur.

Je donne l’exemple d’installation pour Linux pour la suite, mais Murmur marche aussi sous Windows et Mac OS. Donc voila la commande d’installation et configuration pour Debian :

# apt-get install mumble-server

Et voila, c’est tout! Dur hein?

Le serveur tourne, est accessible à tous les clients Mumble et les communications sont chiffrées entre le serveur et chaque client (chacun a un certificat). La classe.

Vous pouvez y accéder depuis votre Linux,Windows,Mac avec Mumble et de votre smartphone android avec Plumble, un logiciel libre disponible sur Fdroid ou Mumblefy sur iPhone.

Pour rendre le serveur privé, vous avez juste à renseigner un mot de passe derrière le paramètre serverpassword= dans le fichier /etc/mumble-server.ini.

Et cerise sur le gateau, le codec audio Opus est supporté par défaut :

J'aime(9)Ferme-la !(0)

2015-01-19

Don du mois : archlinux

Je trouve intéressante l'idée de Sam et Max de présenter les organisations pour lesquelles on a donné quelques euros (il n'y a pas de petit don). Je me lance donc aussi dans l'idée.

Ce mois-ci, ce fût archlinux, $5. Les raisons sont les suivantes :

  • Grande qualité et rapidité des mises à jour, je n'ai jamais eu de problème majeure, au pire quelques petits désagréments qui se sont résolus très vite.
  • Wiki clair et à jour, on y trouve beaucoup d'informations pertinentes et de qualités.
  • Forum agréable, mes rares questions ont trouvé réponse, les dev de la distribution prennent le temps de répondre.
  • Enorme choix de paquets, notamment grâce à AUR auquel je participe. Pouvoir faire mes propres paquets est une raison qui motive mon choix pour cette distribution.
  • J'utilise cette distribution depuis 4 ou 5 ans maintenant. L'installation n'est faire qu'à l'achat de ma machine.
  • J'ai la dernière version de tous les composants, je ne me pose aucune question lorsque j'utilise une lib ou un soft pour mon travail.

Je donne donc à archlinux pour cette satisfaction quotidienne.

Pour donner à archlinux.

2015-01-16

Ne demandez plus d’email pour poster un commentaire

Il y a déjà 2 ans, je me posais déja la question, toujours sans réponse, Pourquoi faut-il renseigner son e-mail pour poster un commentaire?

En effet, sans email :

  • Askimet est toujours aussi performant pour supprimer les spams.
  • On peut suivre les commentaires d’un billet particulier par RSS.
  • C’est plus facile pour tout le monde d’écrire un commentaire sous pseudonyme.
  • C’est mieux pour la vie privée pour ceux qui ont une IP dynamique (les autres je vous ai à l’oeil :p)
  • Ca évite de se casser la tête à donner un email bidon ou de se faire spammer si votre email est utilisée à mauvais escient.

Si vous aussi, vous trouvez que ça n’a pas de sens, installez le plugin WordPress :  Remove Email from Comments

J'aime(13)Ferme-la !(2)

2015-01-15

Comment se faire traquer sur internet sans cookies avec HSTS

Sam Greenhalgh a montré qu’on pouvait utiliser la fonctionnalité HSTS pour facilement tracer les utilisateurs. La faille est intéressante car elle est conceptuelle va être très compliquée à bloquer et touche quasiment tous les navigateurs web même les assez vieux ( >= Firefox 4 ).

Explication

Le principe d’ HSTS est simple. Lorsque le navigateur arrive sur un site web en HTTPS, et que le site web implémente HSTS, alors le navigateur reçoit du site web une directive indiquant qu’il doit toujours revenir en HTTPS sur le site web pour les prochaines visites sur ce nom de domaine.

HSTS permet ainsi de contenter les visiteurs qui veulent toujours accéder aux site web en HTTPS sans bloquer les autres visiteurs qui préfèrent utiliser HTTP.

Imaginons maintenant que http://1.toto.com renvoie un texte : « 0 » mais que https://1.toto.com renvoie une valeur différente : « 1 », ce qui est tout à fait faisable. Il n’y a pas d’obligation que les services HTTP et HTTPS soient des miroirs.

Donc si, sur mon site web « bidon.com », j’inclus un lien vers un contenu situé à l’adresse http://1.toto.com le contenu aura une valeur différente selon que l’utilisateur a déjà ou non visité « 1.toto.com » en HTTPS. Intéressant !

Avec seulement 33 requêtes différentes (1.toto.com, 2.toto.com, etc…, 33.toto.com) qui peuvent valoir 2 valeurs différentes : 0 ou 1 (HTTPS visité ou pas), j’ai 2^33 possibilités soit 8.6 milliards de valeurs différentes, soit suffisamment pour assigner une valeur différente à chaque humain sur Terre.

La faille est donc simple, un visiteur lambda arrive sur mon site « bidon.com », j’ai envie de lui coller un numéro, par exemple « 5 ». Je convertis ce numéro en binaire sur 33 bits ce qui fait 00000000000000000000000000000101. Je le fait charger des contenus en HTTP sur http://1.toto.com, http://2.toto.com, etc… sauf https://31.toto.com et https://33.toto.com où je lui donne des liens en HTTPS.

Quand le visiteur lambda reviendra sur mon site « bidon.com », je lui ferai encore charger charger mes 33 contenus mais en mettant des liens HTTP uniquement (http://1.toto.com, http://2.toto.com, etc…, http://33.toto.com). Normalement, ça devrait renvoyer 33 fois « 0 » sil m’était inconnu . Mais comme il a déjà visité 31.toto.com 33.toto.com en HTTPS, son navigateur va automatiquement modifier ses requêtes de http://31.toto.com et http://33.toto.com en https://31.toto.com et https://33.toto.com et ça renverra 00000000000000000000000000000101. Bingo, je l’ai reconnu.

Comment s’en protéger?

HSTS est enregistré comme préférence du site et non comme un cookie. Supprimer les cookies est donc inutile.

Votre identifiant peut être stocké dans dans les préférences de multiples sites web et non dans celui qui vous traque.

Or pour supprimer la préférence HSTS d’un domaine, il faut supprimer les toutes les préférences du site web depuis la page about:permissions sur Firefox, ce qui supprime aussi les mots de passe et son historique… Bref, pas très utilisable.

Bloquer Javascript sur le site du traqueur rend aussi la technique inefficace, mais difficile de savoir différencier le bon script du mauvais script sur un site web.

Dur dur…

J'aime(13)Ferme-la !(0)

2015-01-09

Bloc-Notes : Mise en veille programmé de disques durs

Petit bloc-notes en relation avec la construction de mon serveur de stockage. Aujourd’hui l’objectif est de mettre en veille les disques-durs de stockage, pas celui du système, en veille lorsqu’ils ne sont pas utilisés.

Cette mise en veille tout en arrêtant le disque, permet de réduire la consommation électrique de celui-ci et de diminuer légèrement son usure.

En faisant toutefois attention que ses arrêts-démarrages ne se produisent trop souvent, cela aura l’effet inverse et détériorera plus rapidement le disque.

Mise en place

c’est le logiciel HDPARM qui permet en autre de réaliser cette mise en veille.

sudo apt-get install hdparm

En premier je vérifie l’état du disque :

sudo hdparm -C /dev/sdc

/dev/sdc:
 drive state is:  online

Avec la commande suivante je force la vielle au bout de 5 secondes sans utilisation :

sudo hdparm -S 1 /dev/sdc

Je vérifie à présent l’état de mon disque :

sudo hdparm -C /dev/sdc

/dev/sdc:
 drive state is:  standby

L’option -S compte par tranche de 5 sec. Dans l’exemple ci-dessus le chiffre 1 correspond à 5 sec, si à la place j’avais placé le chiffre 2 la veille serait apparue au bout de 10 sec.

Pour mon utilisation je souhaite que les disques s’arrêtent au bout de 20 minutes d’inactivité, voici la commande que j’utilise.

sudo hdparm -S 240 /dev/sdc

240 x 5 =1250 sec = 20 minutes.

J’ai choisi 20 minutes car les disques ne sont pas sollicités pour de petites périodes. A la maison le serveur est très souvent utilisé, musique, consultation de documents, vidéos etc. Par conséquent les cycles marche-veille sont peu nombreux. Mais pour une utilisation plus occasionnelle je préfère augmenter les temps entre chaque veille, pour éviter des démarrages trop fréquents.

Problème de cette méthode, elle n’est pas permanente et il faut tout reconfigurer après chaque redémarrage. C’est là qu’entre en jeu le fichier /etc/hdparm.conf. Il permet de garder la configuration de façon permanente.

sudo nano /etc/hdparm.conf 
#je rajoute pour chaque disques la commande de mise en veille 
/dev/sdb { 
        spindown_time = 240 
} 
/dev/sdc { 
        spindown_time = 240 
}

Je redémarre le serveur et après 30 minutes je procède à l’essai

sudo hdparm -C /dev/sdc

/dev/sdc:
 drive state is:  standby

Mes disques sont bien en veille jusqu’à leur prochaine utilisation.

2015-01-08

Google en intraveineuse

google-spyLes journaux en ligne dénoncent souvent le profilage constant des internautes par les Google, Facebook, NSA & co et sont toujours prompt à défendre Snowden. Pourtant, à l’encontre de leur discours, ce sont eux qui participent le plus au flicage des internautes.

Les journaux en ligne gratuits, vivant essentiellement de la publicité, y sont contraint par leur modèle économique. Ils cherchent à maximiser leur audimat par tous les moyens (Facebook, etc…) et leurs revenus publicitaires et cela passe par donner vos infos de connexions à la régie publicitaire (Google). Il n’y a donc rien à attendre d’eux sinon qu’ils ferment leur gueule et se remettent en question en lisant leurs propres articles (cela leur permettrait de corriger leur fautes d’orthographe également).

Plus inquiétant, les journaux payants tels que Mediapart, incluent le traqueur Google Analytics sur toutes leurs pages. Piwik s’installe pourtant en quelques clics. Il y a donc un manque de volonté de mettre une action derrière les mots.

Encore plus inquiétant, des journaux payants spécialisés sur le sujet et en informatique tels que NextInpact (nouveau nom de PCInpact), qui pourtant désactivent Google Analytics pour les abonnés sur leur pages , viennent de m’envoyer (je suis abonné) un questionnaire à remplir sur Google Forms ! Ben oui, c’est simple, c’est gratuit et c’est moi le produit ! Pourtant il existe Limesurvey qui s’installe aussi en quelques clics.

Bref, Google semble présent en intraveineuse même chez les plus éduqués des grands journaux en ligne, pour des fonctionnalités aisément remplaçables avec un peu de volonté.

J'aime(16)Ferme-la !(0)

Objets connectés : attention aux services

Ces derniers temps, on parle beaucoup d'objets connectés, qui sont des accessoires divers — montre, cardiofréquencemètre, podomètre, vélo d'appartement, balance… — intégrant un ordinateur, connecté à votre réseau local ou à Internet afin de transmettre les informations qu'il collecte.

Attention donc à ne pas oublier une chose : si ces objets dépendent d'un service tiers, mis en place par le fabricant, ils ne dureront pas. Le jour où ce service prendra fin — car il prendra fin, ce n'est pas une hypothèse mais une certitude, à plus ou moins long terme — votre balance ou votre montre à plusieurs centaines d'euros ne fonctionnera plus, ou en tout cas pas comme ce qu'on vous a vendu.

2015-01-07

Mon nouveau Nas apprend la samba

Voici la suite de mes travaux sur mon petit serveur dédié au stockage. Après l’installation des partages Linux (NFS), je m’attaque maintenant aux partages windows. Même si je n’utilise pas windows pour mes activités informatiques, mise à part quelques jeux, je trouve utile pour un serveur d’être accessible depuis n’importe quel système notamment lorsque je veux échanger avec des invités qui sont sous windows, de plus cela faisait partie de mon cahier des charges.

De plus cet article me permet de mettre en place mon nouveau thème graphique pour 2015.

Les installations sous Debian se suivent et se ressemblent :

sudo apt-get install samba

Après cette formalité je passe directement à la configuration du serveur en lui-même. Tout se configure depuis le fichier /etc/samba/smb.conf. Voici la configuration détaillée que j’utilise :

#======================= Global Settings =======================
[global]
#Spécifie le groupe de travail
workgroup = WORKGROUP
#Description du serveur
server string = %h server
#pas de proxy
dns proxy = no
#Niveau de précision des log plus d'infos <a target="_blank" href="http://oreilly.com/openbook/samba/book/ch09_01.html&quot;%20target=&quot;_blank&quot; data-mce-href=&quot;http://oreilly.com/openbook/samba/book/ch09_01.html" data-mce-href="http://oreilly.com/openbook/samba/book/ch09_01.html&quot;%20target=&quot;_blank&quot; data-mce-href=&quot;http://oreilly.com/openbook/samba/book/ch09_01.html">ici[->]</a>
log level = 1
#pas de log d'évènement
syslog = 0
#où enregistrer le fichier de logs
log file = /var/log/samba/log.%m
#taille maximale du fichier
max log size = 1000
#mot de passes chiffrés
encrypt passwords = true
smb password file = /etc/smbpasswd
#niveau de sécurité : seul les utilisateurs avec un compte peuvent se connecter
security = user
#Permet de mapper les autorisation Unix vers windows, tous les fichiers créés à partir
#d'un poste windows auront les autorisations linux 777
create mask = 0777
#pareil que create mask mais pour les dossiers
directory mask = 0777
#améliore les transferts de fichiers
use sendfile = yes
aio read size = 16384
aio write size = 16384
#utilisateurs sans mot de passe interdit
null passwords = no
#seul maître à bords
local master = yes
#pas de serveur de temps ni de support <a target="_blank" href="https://fr.wikipedia.org/wiki/Windows_Internet_Naming_Service" data-mce-href="https://fr.wikipedia.org/wiki/Windows_Internet_Naming_Service">wins</a>
time server = no
wins support = no

Ensuite pour chaque utilisateurs autorisés à accéder aux partages je créer un compte samba. Exemple avec l’utilisateur olivier.

sudo smbpasswd -a olivier
New SMB password:
Retype new SMB password:
Added user olivier.

Concernant les utilisateurs de passages avec qui je souhaite échanger, je crée un compte unique dédié avec leur répertoire. Ce qui me permet de détecter d’éventuels fichiers corrompus grâce à clamav avant de les intégrer à mes dossiers courants. Et cela évite que certain se baladent tranquillement dans mes photos ou autre.

# Création du répertoire pour les invités
sudo mkdir /media/disk27B/johndoe
# création de l'utilisateur invité
sudo adduser johndoe
Ajout de l'utilisateur « johndoe » ...
Ajout du nouveau groupe « johndoe » (1001) ...
Ajout du nouvel utilisateur « johndoe » (1001) avec le groupe « johndoe                                                    » ...
Création du répertoire personnel « /home/johndoe »...
Copie des fichiers depuis « /etc/skel »...
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd : le mot de passe a été mis à jour avec succès
Modification des informations relatives à l'utilisateur johndoe
Entrez la nouvelle valeur ou « Entrée » pour conserver la valeur proposée
        Nom complet []: John Doe
        N° de bureau []:
        Téléphone professionnel []:
        Téléphone personnel []:
        Autre []:
Cette information est-elle correcte ? [O/n]o
#création du compte samba
sudo smbpasswd -a johndoe
New SMB password:
Retype new SMB password:
Added user johndoe.

Le serveur maintenant opérationnel je passe à la création des partages samba, toujours dans le fichier /etc/samba/smb.conf. En exemple le répertoire photos :

#======================= Share Definitions =======================
[photos]
path = /media/disk27B/photos/
#invités interdit
guest ok = no
#lecture seule non
read only = no
#dossier navigable
browseable = yes
#hérite des différentes acl
inherit acls = yes
inherit permissions = no
ea support = no
store dos attributes = no
printable = no
#lorsqu'un dossier ou un fichiers est crée il hérite des autorisations suivantes
create mask = 0755
force create mode = 0644
directory mask = 0755
force directory mode = 0755
hide dot files = yes

Une fois tous les partages configurés, je m’occupe du dossier  John Doe.

#=============== Share Definitions fo John Doe user=======================
[johndoe]
path = /media/disk27B/johndoe
#invités interdit
guest ok = yes
#lecture seule non
read only = no
#dossier navigable
browseable = yes
#hérite des différentes acl
inherit acls = yes
inherit permissions = no
ea support = no
store dos attributes = no
printable = no
#lorsqu'un dossier ou un fichiers est crée il hérite des autorisations suivantes
create mask = 0755
force create mode = 0644
directory mask = 0755
force directory mode = 0755
hide dot files = yes

Avec ce système mes utilisateurs courant ont accès aux dossiers partagés, sauf john doe qui a accès uniquement à son répertoire. Cette configuration est un premier jet, je l’ai réfléchi sur le “papier”. Je verrai à l’usage si l’utilisateur John Doe est utile ou s’il faut que j’adapte cette configuration.

 

2014-12-31

Cacher ses adresses mail, numéros de téléphone, etc… des spammeurs sur WordPress

Si vous laissez votre adresse email sur un site web, nul doute qu’un robot va venir la lire et l’ajouter à son fichier de SPAM. Pour éviter cela, on peut encoder l’email en Javascript.

Les humains regardant la page web verront l’email proprement car leur navigateur va décoder le javascript. (Aucun problème de copier coller contrairement aux images)

Les robots ne vont pas exécuter le javascript car c’est trop long et trop complexe pour eux.

Cette technique s’applique aux emails mais aussi à tout contenu que vous voudriez protéger des bots comme votre numéro de téléphone etc…

Il existe un plugin pour WordPress pour mettre en place cette technique facilement : Email encoder bundle

Pour cacher un email ou tout autre contenu des robots, écrivez celui-ci entre balises dans votre article :

[eeb_content]toto@gmail.com[/eeb_content]

J'aime(7)Ferme-la !(1)

2014-12-30

Forcer l’utilisation de SSL pour se connecter à WordPress

Un des moyens de ne pas se faire voler son mot de passe et login WordPress est de se connecter uniquement en chiffrant la connexion par SSL (HTTPS). WordPress a une fonctionnalité, un peu cachée, pour forcer l’utilisateur à utiliser SSL lors de sa connexion.

Pour activer cette fonctionnalité, vous devez rajouter dans le fichier wp-config.php la ligne suivante :

define('FORCE_SSL_ADMIN', true);

Source : Codex WordPress

J'aime(1)Ferme-la !(0)

2014-12-23

Mon nouveau nas : Partage NFS

La nouvelle machine montée avec son système installé, je peux maintenant commencer la configuration du Nas. Je commence donc par le partage de fichiers en NFS, pour les différents PC linux de la maison.

Pour rappel ma configuration se base une Debian 7.7 alias wheezy. C’est parti pour la configuration.

J’avais prévu de monter mes disques données en LVM, mais pour cela il fallait les formater et n’ayant pas de disque en plus pour mettre mes données à part le temps de créer le LVM. Du coup je m’en veux un peu de ne pas avoir anticipé sur ce sujet. Ce n’est que partie remise puisque je compte investir dans d’un 4 TO d’ici l’année prochaine ce sera donc l’occasion de déployer le LVM. Je repars donc sur un système avec deux disques de 1To pour stockage.

Installation sur Serveur NFS

Sous Debian en root il suffit de faire :

apt-get install nfs-kernel-server nfs-common

Ensuite je créer un répertoire export à la racine qui centralisera tous mes partages sur le réseau local. Dans se répertoire je monte les répertoires que je souhaite partager, cette aspect de la configuration est inhérent à la version 4 de NFS. Une fois mes deux disques montés au système, je monte les répertoires à partager dans /export, au préalable je créer les dossiers cibles pour accueillir les partages.

# création du dossier export pour centraliser mes partages.
sudo mkdir /export
#montage du dossier à partager dans /export.
cd /export
sudo mkdir photos
mount --bind /media/disk27B/photos photos

Pour que ce montage soit permanent il faut le renseigner dans le /etc/fstab :

# Ici je monte mes disques durs au système
UUID=27bd44d9-71aa-4b4a-9ed4-ab79e715d3fd /media/disk27B  ext4    defaults,noatime,nofail      0       0
UUID=5b8275e1-85cb-4406-ba7f-8c54d48d7978 /media/disk5B8  ext4    defaults,noatime,nofail      0       0

#Ici je monte mes partages réseaux
/media/disk27B/photos /export/photos none bind 0 0
/media/disk5B8/videos  /export/videos none bind 0 0

Maintenant il ne me reste plus qu’a configurer le serveur. Cela se passe dans le fichier /etc/exports.

Pour chaque partages il faut définir qui y aura accès et avec quels options.

#Configuration des partages
/export/photos   192.168.66.0/24(rw,subtree_check,insecure,no_root_squash)
/export/videos   192.168.66.0/24(rw,subtree_check,insecure,no_root_squash)
#Configuration du dossier export
/export 192.168.66.0/24(ro,fsid=0,root_squash,no_subtree_check,hide)

  • 192.168.66.0/24 – j’autorise n’importe quels ordinateurs du réseau à se connecter au partage
  • rw : accès en lecture/écriture
  • subtree_check : vérification de l’arborescence
  • insecure : permet au client de se connecter sur un port différent de celui par défaut le 1024, utile dans certains cas.
  • no_root_squash : spécifie que le root de la machine sur laquelle le répertoire est monté possède les droits root sur le répertoire

De plus j’ai configuré le dossier export afin qu’il ne soit pas visible sur le réseau, et non navigable.

Pour terminer je redémarre le service nfs.

sudo service nfs-kernel-server restart

 Configuration des clients

Dans le /etc/fstab des mes clients pour accéder aux partages j’ajoute :

192.168.66.166:/photos /home/olivier/photos nfs rw,defaults 0 0

Conclusion

Dommage je n’ai pas anticipé la configuration du LVM, mais ce n’est que partie remise. Le services NFS tourne depuis 4 jours sans aucun souci.

2014-12-21

Partager son serveur auto-hébergé

Mon serveur n’est pas un foudre de guerre mais peut techniquement héberger autre chose que mes propres contenus.

Une idée cool et qui arrange tout le monde

Ainsi, j’ai proposé il y a quelques années à une connaissance de lui héberger son blog et celui d’une asso pour laquelle il gère le site web (asso orientée entraide informatique et logiciels libres, par le biais de laquelle nous nous étions d’ailleurs rencontrés). Je l’ai proposé comme une solution basique mais néanmoins neutre, ne m’occupant théoriquement de mon côté que de l’hébergement en lui même. Précision importante, je ne perçois pas un centime de sa part, mon but n’étant d’offrir ici une prestation professionnelle, histoire de ne pas introduire non plus une relation client / fournisseur.

Ce que ça me coûtait ? La création de deux comptes sur mon serveur, l’accès FTP, l’ajout de deux redirections web dans la configuration d’apache et la création de deux bases de données MySQL, avec éventuellement une aide pour mettre les blogs en place. Autant dire pas grand chose.
Ce que ça lui coûtait ? Rien, d’autant que je fournissais au départ deux sous-domaines (avant que plus tard, il ne réserve les noms de domaine qui lui allaient mieux).
On pourrait donc résumer ça à un coup de pouce.

La perte progressive de contrôle

Malheureusement, ça a prit une tournure que je n’avais pas envisagé. A l’époque où j’avais moi même recours à un service d’hébergement gratuit, je me contentais du strict minimum et je faisais avec les inconvénients (quelques Mo d’espace, une seule base MySQL, un seul accès FTP, de la pub autour …). Pour autant, cela suffisait amplement pour mes besoins, c’est à dire ceux d’un particulier ayant envie de tenir une page avec des contenus ajoutés a un rythme tranquille.

Mon hébergé a donc très vite commencé à alimenter les deux blogs, et notamment son blog perso à un rythme soutenu. En soit, ça ne me pose aucun problème, au contraire. Après un certain temps, il a voulu diviser son blog perso en trois ayant chacun leur thématique. On l’a fait (modif des redirections apache, ajout de deux nouvelles bases).
Mais tout ces contenus dispersés, ça n’allait pas et il a donc fallu prévoir une autre page pour que ses trois blog aient un point d’entrée commun (page statique mais sur laquelle pointe son nom de domaine).
En parallèle, il a aussi voulu tester d’autres services, ce qui a demandé une nouvelle base de données MySQL.
Les blogs perso ont changé de nom il n’y a pas longtemps. J’ai donc dû modifier les virtuals hosts apache, mais sans virer les anciens sous-domaines pour ne pas perdre les visiteurs qui n’auraient pas connaissance des nouveaux noms.
L’emplacement de ses blogs et autres sites sur son espace web a aussi évolué plusieurs fois, si bien que ça a aussi demandé du boulot que je n’avais pas prévu.
De nouvelles mises à jour étaient prévues ces jours ci (et j’ai constaté qu’un nouveau nom de domaine était présent). D’autres mises à jour étaient aussi en prévision pour 2015.

Ce qui est au dessus relève du boulot de l’hébergeur.
A côté de ça, j’ai aussi plusieurs fois assuré le support technique sur ses blogs, automatisé l’archivage de ses bases de données, expliqué autant que je le pouvais les conséquences par exemple de tel ou tel choix, reçu près de 850 mails de sa part en 4 ans (dont 90% minimum relatifs à ses problèmes ou à ses projets futurs rien que sur ses sites ; avec en prime des relances lorsque je ne répondais pas assez vite), parfois passé un temps fou à comprendre ce qu’il cherchait à faire. Ce que ça m’a coûté, et que j’avais largement sous-estimé au début, c’est le temps que ça me boufferait. J’ai bien tenté de limiter un peu ça mais ça n’a pas été un franc succès.

Conclusion

J’ai donc décidé de ne plus héberger l’ensemble de ses contenus (ses blogs et celui de l’asso). J’ai en effet compris que ses demandes seraient continues à l’avenir. Bien entendu, hors de question de le faire du jour au lendemain. La fin effective d’hébergement se fera dans un délai que l’on aura défini ensemble.

Malgré ça, je ne l’accable pas du tout ! C’est quelqu’un de bien et je suis bien souvent en phase avec lui lorsqu’on parle de logiciels libres ou bien d’autres choses.
Il a eu une opportunité d’offerte sans limites claires et a demandé ce qu’il pensait être en droit de demander. La faute est entièrement la mienne et c’est lui qui en assume les conséquences, tout ça parce que je n’ai pas fixé de règles au départ. J’ai naïvement pensé que le bon sens suffirait.

A l’avenir, je n’exclue pas d’héberger à nouveau d’autre contenus que les miens.
Si l’occasion se représente, je veillerai toutefois à être très clair dès le départ.

2014-12-20

MySearch and GooglePlayDownloader passent en version 1.6

Voila c’est Noël avant l’heure, je sors une nouvelle version de mes 2 logiciels libres :

  • Mysearch : un métamoteur de recherche anonymisateur, sans pub, et avec la pertinence des résultats Google.
  • GooglePlayDownloader : il vous permet de télécharger les applications gratuites du PlayStore sans nécessiter d’utiliser un compte Google personnel ni d’installer les applis Google avec les droits root sur votre smartphone Android

Par un hasard incroyable ils atteignent le même numéro de version (1.6) en même temps :-)

Si vous voulez me faire plaisir, faite connaître ce blog plus largement sur la toile, ça me suffit.

Amusez-vous bien !

J'aime(8)Ferme-la !(0)

2014-12-17

Mon nouveau nas : le matériel

Ca y est j’ai reçu le matériel de mon nouveau Nas personnel pour le stockage de mes données.

Lors d’une précédente réflexion, j’étais revenu sur mon projet d’un Nas virtuel avec proxmox . Trop de contraintes logicielles, matérielles et une très grosse perte de performance n’ayant pas de machine hôte adaptée. De plus le trafic Nas ajouté  au trafic web habituel sur le serveur hôte le mettait à genou régulièrement.

Cahier des charges

J’ai finalisé un cahier des charges avant de passer commande à mon revendeur habituel. Ce nouveau devra répondre à certain critères, au moment où j’écris ses lignes je sais déjà que certains points ne pourront être réalisables j’y reviendrai dans un autre article. Voici la liste :

  • Consommation électrique a plus faible possible
  • Très silencieux, pour l’instant il sera entreposé dans le salon
  • Ajouter des disques durs facilement, prévoir de la place dans le boîtier pour deux ou trois disques d’avance
  • Encombrement minimal, en opposition avec le point ci-dessus
  • Système exploitation libre et configuration maison.
  • Être disponible 24/24, sur n’importe quelle plateforme de la maison (Pc portable, le HTPC, Tablette)
  • Multi OS, pouvoir accéder à n’importe quelle donnée depuis n‘importe quel système d’exploitation.

Concernant le point du système d’exploitation aucune hésitation se sera une Debian stable, avec partage Samba (windows), Nfs (Linux), ownCloud pour tout ce qui est de mon informatique dans les nuages. A cela se rajoutera un serveur rsync pour les sauvegardes des machines virtuelles de proxmox et autres données sensibles.

Petite parenthèse sur les sauvegardes, je compte récupérer mon ancien Nas synology pour réaliser une sauvegarde externalisée. C’est très bien de faire des sauvegardes, mais c’est encore mieux lorsqu’on peut les entreposer sur autre lieu.

Bien sûr rien n’est arrêté, tout sera amené à évoluer, mais dans l’immédiat cela constitue ma base de travail. Fort de cette petite liste en poche, j’ai commencé mes recherches sur les différents fournisseurs informatiques pour établir ma configuration.

Le Matériel

IMG_0144La carte mère, MSI J1800I :

  • Processeur Dual-Core Celeron J1800 basse consommation intégré (2.41 GHz / 2.58 GHz – Cache 1 Mo – TDP 10W)
    • 2 ports SATA 3Gb/s (obligé de prendre un carte d’extension sata)
    • Ports USB 3.0 (cela peut toujours servir en cas de récupération d’urgence)
    • Format ultra-compact Mini-ITX (17 x 17 cm) (gain de place de la boîtier)

C’est peut-être sur dimensionné pour un simple Nas, mais je prévois toujours large au cas où le Nas évolue sur des applications qui nécessitent un peu plus de ressources. Je n’aime pas être limité dans les projets à cause du matériel. Elle répond quand même à mon cahier des charges sur le point de la basse consommation.

IMG_0146La Ram, Corsair 2 Go en DDR3.

D’habitude je ne prends que de la Kingstone pour sa garantie à vie, qui n’est pas une garantie à vie réelle j’en fais l’expérience il y a quelques temps déjà le service après vente est nickel, mais sur le site revendeur il n’avait que des packs à 8 et 16 Go et par pur flemme je l’avoue j’ai pris cette barrette. L’avenir me dira si j’avais raison.

IMG_0148Une carte extension Sata afin de pouvoir brancher plus que les deux disques durs autorisés par la carte mère. J’espère qu’elle sera bien reconnue sous Debian, d’après mes recherches sur internet oui mais je me méfie toujours de ses cartes d’extension.

IMG_0149Le boîtier un cooler master elite 130.

Lorsque je l’ai sorti du carton j’ai dit : “mince il faisait plus petit sur les photos”, j’aurai dû prendre mon mètre et vérifier les dimensions, mais au final il reste très compact et surtout il me permet de placer jusqu’à 5 disques durs, réparti entre 3×3.5 pouces et 2×2.5 pouces, ce qui est quand même l’essence même du Nas avoir le plus grand espace de stockage. Je voulais aussi éviter du bricolage pour placer tous mes disques durs et qu’ils soient un minimum ventilés.

Il possède deux ventilateurs, un de 120 mm en façade et un autre de 80mm sur le côté pile en face de la carte mère. Il y a une possibilité d’en rajouter deux autres ventilateurs sur le côté. Pour le silence je verrai à l’usage.

IMG_0151 IMG_0150

Dans l’ensemble le montage c’est très bien passé, pas de difficulté particulière au niveau du boîtier. La Ram un peu dure à “enfoncer” dans son logement. Je ne l’ai pas encore démarré, car je suis en train de sauvegarder toutes les données qui migreront sur le Nas, pour ensuite en récupérer les disques durs, je n’en ai pas acheté d’autres ils ont moins d’un an. Pour commencer il y aura trois disques durs. Un pour le système , deux autres de 1 To très certainement en LVM (j’aurai occasion d’en reparler) pour les données.

La récupération des mes données est longue, très longue, mais je le savais en me laçant dans ce projet, une fois terminée, je pourrai commencer l’installation du système et réfléchir au stockage de mes données.

IMG_0152 IMG_0153 IMG_0154

Le boîtier une fois la carte mère montée.

2014-12-16

Mini guide MySQL

Je mets ici mon anti-sèche pour mes besoins basiques de MySQL, à savoir gérer des sites  WordPress, Owncloud, Piwik, etc…

Prise en main

Un super utilisateur nommé « debian-sys-maint » est créé par Debian pour administrer MySQL. Son mot de passe se trouve dans le fichier /etc/mysql/debian.cnf
# cat /etc/mysql/debian.cnf

On peut se connecter à MySQL avec l’une des solutions suivantes :

  • Mot de passe interactif :
    $ mysql -u debian-sys-maint -p
  • Mot de passe en chargeant le mot de passe directement depuis le fichier:
    # mysql --defaults-file=/etc/mysql/debian.cnf
  • Mot de passe avec le mot de passe dans la ligne de commande (déconseillé, le mot de passe se trouvant alors dans l’historique):
    $ mysqldump --user=debian-sys-maint --password=MOTDEPASSE

Vous devriez avoir l’invite de commande MySQL:
mysql>

Pour quitter MySQL à tout moment:
mysql> exit

On va maintenant pouvoir lancer des commandes, chaque commande se termine par le caractère ‘;‘, ne l’oubliez pas.

Pour lister toutes les bases de données présentes:
mysql> SHOW databases;

Pour lister tous les utilisateurs:
mysql> SELECT User,Host FROM mysql.user;

Procédure pour installer un nouveau site web facilement

Souvent, il vous arrivera pour installer un nouveau service (WordPress, Owncloud, Piwik, etc…) de devoir créer une nouvelle base de données et un nouvel utilisateur ayant tous les droits sur celle ci. Voyons comment faire ca.

Comme nous allons créer un nouvel utilisateur et son mot de passe, je vous invite générer un bon de mot de passe en suivant ce guide avant de commencer.

Ensuite, un fois connecté à MySQL :

Créez un nouvel utilisateur en utilisant le mot de passe généré:
mysql> CREATE USER 'piwik_user'@'localhost' IDENTIFIED BY 'mot_de_passe_complique';

Créez une nouvelle base de donnée:
mysql> CREATE DATABASE piwik_database;

Donnez les permissions à l’utilsateur sur la base de données:
mysql> GRANT ALL ON piwik_database.* TO 'piwik_user'@'localhost';

Appliquez les privilèges:
mysql> FLUSH PRIVILEGES;

Fini !
mysql> exit;

Et voila, vous êtes bon. C’était pas si dur :-)

Sauvegarde et restauration

Une chose super indispensable à savoir aussi, sauvegarder sa base de donnée. Car on ne peut pas récupérer les données sans que MySQL tourne. Donc il faut penser à bien faire ses sauvegardes tant que MySQL fonctionne.

$ mysqldump --user=debian-sys-maint --password=MOTDEPASSE piwik_database > ~/mysql-piwik_database-backup.sql

Pour restaurer:

$ mysqldump --user=debian-sys-maint --password=MOTDEPASSE piwik_database < ~/mysql-piwik_database-backup.sql

Si vous réimportez la base de données dans un MySQL vierge (ex: résintallation de PC), il faut aussi penser à re-créer les utilisateurs (cf guide ci-dessus) :
$ mysql --user=debian-sys-maint --password=MOTDEPASSE
mysql> CREATE USER 'piwik_user'@'localhost' IDENTIFIED BY 'mot_de_passe_complique';
mysql> GRANT ALL ON piwik_database.* TO 'piwik_user'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> exit;

J'aime(4)Ferme-la !(1)

2014-12-12

Sécuriser ses services avec les Jails FreeBSD et Packet Filter #1

Héberger une machine physique c'est tellement 90's :

S'auto-héberger c'est à nouveau à la mode surtout avec le THD. Mais avec le développement économique des pays asiatiques, ces derniers non content de nous bouffer toutes les IPv4 restantes, se sont aussi mis à construire des écoles pour enseigner l'informatique, diantre ...

Pour se protéger un minimum de toute cette plaie de l'est il est rudement conseillé d'avoir une bonne politique de sauvegarde pour restaurer avant le hack et surtout un environnement un minimum sécurisé et cloisonné.
L'intérêt de cloisonner est qu'en cas de service corrompu le p'tit chinois ne pourra pas avoir accès au reste de la machine et tournera en rond dans sa jails (prison) avec son vrai/faux compte root. Pour obtenir ce résultat il suffit de "virtualiser" notre environnement.

Il existe plusieurs type de virtualisations, toutes adaptés à un usage particulier.

Chacune à ses avantages et inconvénients, dans notre cadre l'hebergement@home ou indépendant utiliser des technologies comme VMWare ou XEN est absurde, car beaucoup trop gourmand en ressources machine et humaines pour l'administration, vous devez administrer chaque machines indépendamment. Les jails proposent assez de sécurité et de flexibilité d'administrations pour en faire l'un des outils parfait dans le cadre de l'hébergement de services persos, de plus elles offrent l'avantage de fournir des archives très simplement exportables.

Pour les plus curieux, les features complètes d'une jail ici.

Les jails sont des implémentations BSD STABLE, apparues avec FreeBSD 4.0 il y a déjà 10 ans, soit l'équivalent du cycle de développement d'un jeu Blizzard ... GNU/Linux l'OS en avance ... vient à peine de s'y mettre avec les conteneurs LxC tout buggés de partout ou il faut ajouter de la surcouche Apparmor pour obtenir une sécurité "acceptable" ... et des Dockers ou l'on est obligé de bidouiller pour les faire communiquer entre eux mouhaha.


Un peu d'art plastique :

Ce super croquis aux couleurs dégueulasses résume assez bien l'affaire :



En détail :

  • La machine hôte posséde une ip "publique" dans le LAN 192.168.0.x et une autre "virtuelle" dans le LAN 10.8.8.X
  • L'interface entre ses deux LAN est effectuée en passant par Packet Filter et du NAT.
  • L'accés à la machine hôte se fait en passant par Packet Filter par une IP 192.168.0.x
  • Chaque Jail possède une adresse IP différente, un espace utilisateur différent.
  • Les jails ont la possibilité de "discuter" entre elles (comme www et Mysql) ou pas, tout est réalisable.
  • On peut virtuellement ajouter autant de jails que l'on désire.
  • Les jails offrent le gros l'avantage d'être des modules facilement sauvegardes/exportables.
  • Je fais des schémas de merde.

Il est également possible de faire des choses comme ça, avec deux interfaces réseaux virtuelles, pour encore séparer la partie HTTP du reste notamment la partie MAIL / DNS qui est souvent source d'attaque.



Les combinaisons sont multiples et variées, mais nous ferons simple et resterons sur le scénario 1 qui propose déjà, couplé à quelques règles Packet-Filter, une isolation acceptable.

Ce type d'infra à bas "coût" constitue un bon moyen de mettre en place une architecture sécurisée chez soi, sans empiler des firewalls et autres routeurs physiques, c'est toujours mieux pour les ours polaires, même si bon honnêtement les écolos à la cons qui roulent en Diesel, je les emmerde.

Configurons notre hôte :

Pour une flexibilité maximale tous nos services doivent tourner dans des Jails, ce qui rendra ces derniers super-exportables, et minimisera la conf à se retaper sur la machine hôte, migrer une jail c'est vraiment trivial.

La machine hôte ne fera tourner que :

  • Nos Jails
  • SSH
  • Packet Filter
  • Eventuellement deux trois trucs en crontab (le moins possible toutefois).

Il est important de mettre le moins de données possible sur la machine dans /home par exemple ou dans /root, ou alors bien penser à les sauvegarder.
L'avantage de n'avoir que des jails dans votre hôte est que la machine devient quasi-échangeable à volonté, ex ma machine crash pas de problème je remonte tranquillement mes jails dans une VM Virtualbox sur mon PC de bureau en attendant, depuis mes jails sauvegardées vers le NAS.

Je considère que vous venez d'installer une FreeBSD toute fraiche avec son IP, ça prend 5 minutes chrono ( si vous avez déjà installé une Debian ou équivalent, c'est à peu près aussi difficile ) file system UFS, sans RAID c'est inutile (j'insiste), cette dernière sera accessible par le réseau.
Vous pouvez également vous référer au chapitre "Mise au propre de première installation" d'un de mon précédent billet.

/etc/rc.conf  : Le patron

Si vous découvrez FreeBSD (ou l'univers BSD en général) , vous allez très vite vous familiariser avec ce dernier.
Ce fichier est le fichier de configuration principale de FreeBSD c'est ici que vous définissez à peu prés tout. Adresses IP, cartes réseaux virtuelles, services au boot ...
Faites très attention dans sa syntaxe (oublie de quote ou autre), car en cas de syntaxe foireuse, vous vous retrouverez en mode dégradé sans connexion réseau, clavier qwerty, shell par défaut.

Editons /etc/rc.conf qui ne doit contenir grand chose si votre machine est fresh install, et ajoutons y quelques chose comme ça :

# Non d'hôte est type de clavier
hostname="host-box"
keymap="fr.iso.acc.kbd"

# Si vous voulez une IP dynamique #ifconfig_re0="DHCP"
# Sinon pour que l'hote ait une IP fixe. ifconfig_em0="inet 192.168.0.15 netmask 255.255.255.0" defaultrouter="192.168.0.1"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev="AUTO"
# Ssh activé sshd_enable="YES"
# NTPD pour l'heure auto ntpd_enable="YES" # Gestion de l'economie d énergie pour l amazonie powerd_enable="NO"
#On active les jails jail_enable="YES"
#On utilisera ezjail ezjail_enable="YES"
#Routage gateway_enable="YES"
#Packet Filter (firewalling) pf_enable="YES" pflog_enable="YES"
# Ici On crée une interface virtuelle cloned_interfaces="lo2"
# Et la on déclare no IP sur cette Interface (autant que nécessaire) # 14 Hosts / 16 IP /28 .240 # Voir : http://www.aelius.com/njh/subnet_sheet.html ifconfig_lo2_alias0="inet 10.8.8.5 netmask 255.255.255.240" ifconfig_lo2_alias1="inet 10.8.8.6 netmask 255.255.255.240" ifconfig_lo2_alias1="inet 10.8.8.7 netmask 255.255.255.240"

Pour finir ne pas oublier d'activer l'IP Forwarding :

sysctl net.inet.ip.forwarding=1

Vous pouvez rebooter pour simplement redémarrer la partie réseau avec :

19:50 root@host-box:[~]:$ service netif restart

Et vous devriez vous vos IP et l'interface crée plus tôt apparaitre :

lo2: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
	inet 10.8.8.5 netmask 0xfffffff0 
	inet 10.8.8.6 netmask 0xfffffff0 
	inet 10.8.8.7 netmask 0xfffffff0 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Tout le monde en tôle :

Maintenant que la conf réseau est en place y a plus qu'a pondre une jail ou deux.
Les mécanismes de jails sont très puissants ils permettent notamment de créer des "templates" identiques de vos configurations, très pratique pour avoir à se recoltiner 10 fois la même configuration.

Comme indiqué plus haut nous utiliserons ezjail, installons le :

pkg install ezjail

Pour la configuration c'est pour changer d'une difficulté ubuesque. Je détail la configuration dans ce billet.

Petit rappel pour les étourdis :

Les emplacement "clés" de ezjails sont :

  • /usr/jails/ : L'emplacement par défaut de vos jails (configuration selon vos souhaits).
  • /usr/jails/flavours/ : Les flavours sont vos jails "templates", utile pour du déploiement industrialisé, se créer des modèles de jails ISO avec le même user, les même outils ... .
  • /usr/jails/basejail/ : L'environnement de base de vos jails qui seront montés par chaque jails.
  • /usr/local/etc/rc.d/ezjail.sh : Stop / Start / Restart script
  • /usr/local/etc/ezjail.conf : LE fichier de configuration de ezjail, celui que nous allons configuré le cas présent, le reste n'est que pour la "culture général" du produit, celui qu'il faudra sauvegarder.
  • /usr/local/etc/ezjail/ : Le reste des ficheirs ezjails.

Bon en fait je n'ai qu'a modifier la conf de /usr/local/etc/ezjail.conf, c'est super balaise :

# Location of jail root directories
# L'endroit ou seront stocké nos jails
ezjail_jaildir=/usr/jails
# Le reste découle de la variable plus haut
# Pas nécessaire d'y toucher. ezjail_jailtemplate=${ezjail_jaildir}/newjail
# Location of the huge base jail
ezjail_jailbase=${ezjail_jaildir}/basejail
# Les sources utilisés par les jails
# Location of your copy of FreeBSD's source tree
ezjail_sourcetree=/usr/src
[...] # Autoriser le montage (ex NFS à l'intérieur d'une jail) # devfs et procfs servent à autoriser ou noms les jails à utiliser certains commandes
# tel que ps, top ... ezjail_mount_enable="YES" ezjail_devfs_enable="YES" # ezjail_devfs_ruleset="devfsrules_jail" ezjail_procfs_enable="YES" # ezjail_fdescfs_enable="YES" #Pas d'utilisation ZFS

Il ne reste plus qu'a installer l'univers jail (à faire une seule fois, ça peut prendre quelques minutes).

# ezjail-admin install

Plutôt que de s'embêter à reconfigurer 10 fois les jails après création, on va se créer un template de base qui sera configurer correctement pour toutes les jails que nous créerons par la suite. Toutes les nouvelles jails auront, notre user de crée ainsi que par exemple, bash, screen.

# ezjail-admin install

Dans /usr/jails/flavours/ :

02:19 root@host-box:[/usr/jails/flavours]:$ ll example/
total 16
drwxr-xr-x  4 root  wheel  512 Aug 21 00:07 ./
drwxr-xr-x  3 root  wheel  512 Sep 21 10:37 ../
drwxr-xr-x  3 root  wheel  512 Aug 21 00:07 etc/
drwxr-xr-x  3 root  wheel  512 Aug 21 00:07 usr/

Laissons le repertoire example par défaut et recopions le vers montemplate (par exemple hein ...) :

02:25 root@host-box:[/usr/jails/flavours]:$  cp -rp example/ montemplate

Profitons en pour copier resolv.conf dans le etc de notre jail, pour profiter d'internet.

# cp -p /etc/resolv.conf /usr/jails/flavours/montemplate/etc/resolv.conf

Et générons un début de rc.conf, le fichier qui va donc servir à paramétrer la jail au boot.

# cd /usr/jails/flavours/montemplate/

# vi etc/rc.conf

# Pretuned by German Engineers, si senor.

# No network interfaces in jails network_interfaces=""
# Prevent rpc rpcbind_enable="NO"
# Prevent loads of jails doing their cron jobs at the same time cron_flags="$cron_flags -J 15"
# Prevent syslog to open sockets syslogd_flags="-ss"
# Prevent sendmail to try to connect to localhost sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO"
# C'est comme vous voulez ... # sshd_enable="YES"

# cd /usr/jails/flavours/montemplate/

Ce fichier, sert à paramétrer vos jails à la création de cette dernière (hors IP), c'est du shell, on peut se faire plaisir, création d'utilisateurs, installation de logiciels, paramétrages divers ... c'est no-limit.
Pour rester simple dans l'exemple.

02:27 root@host-box:[/usr/jails/flavours/montemplate]:$ ll /etc/rc.d/
total 12
drwxr-xr-x  2 root  wheel   512 Aug 21 00:07 ./
drwxr-xr-x  3 root  wheel   512 Aug 21 00:07 ../
-rwxr-xr-x  1 root  wheel  1821 Aug 21 00:07 ezjail.flavour.example

Renommons le script qui va paramétrer la jail, vers quelque chose de plus approprié à notre nom de template,

sudo mv /etc/rc.d/ezjail.flavour.example /etc/rc.d/ezjail.flavour.montemplate

Puis éditons le, la conf est clair c'est du shell, remplacer toutes les occurrences "example" par le nom de votre template et profitez en pour créer nos users, et installons deux trois choses :
Il faudra évidement penser à changer le password de votre/vos user lors de la première connexion sur votre jail.

# echo -n '$1$p75bbfK.$Kz3dwkoVlgZrfLZdAXQt91' |\
# pw useradd -n mathieu-u 1001 -s /bin/sh -m -d /home/mathieu -G wheel -c 'Admin User' -H 0

Toujours dans votre fichier :

chown -R mathieu:wheel /home/mathieu
# Auto YES
export ASSUME_ALWAYS_YES=YES
pkg bootstrap
pkg install screen
pkg install bash
pkg install wget
pkg install perl5
chpass -s /usr/local/bin/bash mathieu

Sauvegardé, emballé c'est pesé.

Voilà en gros à chaque fois que je créerai une nouvelle jail ce dernier aura mon utilisateur de paramétré avec, bash et deux trois outils.

Plus qu'a construire une ou deux prisons :

Il ne reste plus qu'a créer nos jails, en leur donnant les IP que l'on a créer plus haut et en leur précisant la saveur (flavor) que l'on vient de créer, à noter que ce n'est du tout obligatoire vous pouvez créer une jail from scratch sans utiliser aucun "flavour" ce dernier n'aura rien à part, un compte root, et le shell par défaut.

Avec notre ami "ezjail-admin", vous pouvez le lancer le avec l'option -h pour voir toutes ces options.

23:47 root@host-box:[~]:$ ezjail-admin create -f montemplate majail 10.8.8.5
/usr/jails/majail/.
/usr/jails/majail/./etc
/usr/jails/majail/./etc/rc.d
/usr/jails/majail/./etc/rc.d/ezjail.flavour.montemplate
/usr/jails/majail/./etc/rc.conf
/usr/jails/majail/./etc/resolv.conf
5 blocks

Vous pouvez obtenir des warning sur des ports déjà utilisé comme syslog par exemple, n'en tenez pas compte.

Démarrage :

00:03 root@host-box:[~]:$ ezjail-admin start majail

Pour voir nos jails un petit coup de :

23:50 root@host-box:[~]:$ jls
   JID  IP Address      Hostname                      Path
     1  10.8.8.5        majail                       /usr/jails/majail

Ou encore :

23:57 root@host-box:[~]:$ ezjail-admin list
STA JID  IP              Hostname                       Root Directory
--- ---- --------------- ------------------------------ ------------------------
DR  1    10.8.8.5        majail                        /usr/jails/majail

Pour se connecter :

3:59 root@host-box:[~]:$ ezjail-admin console majail

Ca peut être intéressant de faire des backup aussi à l'occasion, pour ça c'est toujours aussi difficile.
Ca peut très bien se faire à chaud, mais pour le cas d'une base de donnée, c'est tout de même plus sur de la stopper pour figer les I/O RAM sur disque.

0:03 root@host-box:[~]:$ ezjail-admin archive -d /mnt/backup majail

Notez que les jails sont des environnement vraiment sécurisés, à tel point qu'on ne peut même pas pinger à l'intérieur !

Pour activer ceci il faut activer une option noyau, jail éteinte.

sysctl security.jail.allow_raw_sockets=1

Voilà avez un OS cloisonné ou vous pouvez tout faire comme sur la machine hôte ou presque.

Pour l'instant c'est un peu open bar niveau sécurité, mais Packet Filter va venir mettre de l'ordre dans tout ça en tabassant à coup de cross de M16 les packets des hackers Chinois qui tenterait de vous la faire à l'envers.

Et maintenant ?

Je vous laisse vous familiariser avec les jails, qui sont des outils très pratiques.

Vu que l'article commence à gagner en longueur je vais splitter ce dernier, la partie sur Packet Filter s'annonçant longue et détaillée, fera l'objet d'une suite dans une partie deux à part ... comment ça j'abuse ?
Je fais ce que je veux, c'est chez moi ici, non mais ... en attendant tu n'as qu'a aller visiter ma galerie photo et me commander des tirages ...

A +.

Pentakonix

2014-12-05

XCache pour accélérer WordPress (et le PHP de manière générale)

Je cherchais une manière d’améliorer les temps de réponse de ce blog. WP SuperCache est très efficace, mais il se désactive pour les utilisateurs qui ont mis un commentaire, et n’apporte rien sur la partie administration.

Et je suis tombé sur les “accélérateurs PHP“. Parmi ceux disponibles, j’ai retenu XCache.

xcache

En trois fois rien de temps, il m’a permis de faire afficher les pages presque 2 fois plus vite.

xcache_flowchart

(source : http://cerberusweb.com/book/latest/admin_guide/performance/xcache.html )

Installation et configuration

L’installation est enfantine :

apt-get install php5-xcache
service apache2 restart

La configuration se fait dans le fichier /etc/php5/mods-available/xcache.ini

J’ai simplement augmenté un peu la quantité de mémoire vive que je lui permets d’utiliser (64Mo au lieu de 16Mo), et lui ai indiqué qu’il pouvait utiliser les 2 cores de mon processeur

; to disable: xcache.size=0
; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size  =                64M
; set to cpu count (cat /proc/cpuinfo |grep -c processor)
xcache.count =                 2

Test de performance

Sur l’édition d’un article, dans l’administration de WordPress :

  • Sans XCache : 3.5s
  • Avec XCache (premier accès) : 5.3s
  • Avec XCache (accès suivants) : 2s

Je mesure ici le temps de réponse de la requête HTTP qui demande la page HTML (en excluant toutes les ressources javascript, image etc), en mesurant avec l’outil Réseau des outils de développement Web de Firefox.

J’ai les mêmes ordres de grandeur sur l’affichage des articles, et toutes les applications PHP en général : une requête qui prenait 1000ms n’en prend plus que 550 à 750 (suivant le cas). Évidemment tout ça dépend de ce que fait votre PHP…

Donc oui, ça vaut clairement le coup dans mon cas de figure ! On sent une amélioration notable de la navigation.

Quels inconvénients à cette solution ?

D’abord une légère surconsommation mémoire à prendre en compte.

Ensuite, un ralentissement du premier accès (autour de +50 % de temps de réponse). Si on ne règle pas correctement la quantité de mémoire allouée à XCache, on peut donc facilement dégrader les performances. D’où l’importance de monitorer l’utilisation mémoire de XCache :

Monitoring de XCache

Tout est dans la doc : http://xcache.lighttpd.net/wiki/InstallAdministration#HowtoInstallXCacheAdministrationPage

… mais elle semble adaptée à des versions récentes de XCache (3.x), alors qu’on a encore la version 2.x sur Debian Squeeze. J’ai trouvé mon bonheur sur http://www.tecmint.com/install-xcache-to-accelerate-and-optimize-php-performance/

Ca permet d’avoir facilement une page web qui indique les statistiques d’utilisation de XCache : nombre de hits/misses, utilisation de la mémoire, et même le détail par fichier PHP.

Nettoyer la base de données de WordPress

Après 7 ans de blog, il était temps de faire un peu de nettoyage dans la base de donnée de WordPress.

J’ai trouvé le plugin WP-Optimize pour faire cela et qui m’a diminué ma base de données de moitié.

Une autre source d’embompoint pour la base de données, les tables que les plugins de statistiques ne suppriment pas à leur désinstallation comme « wp_statpress » pour Statpress ou « wp_cn_track_post » pour Post views Stats. Ca peut vitre chiffrer dans les 50Mo.

Au final, ma base de données de WordPress fait désormais 10Mo pour 1000 articles et 3000 commentaires.

J’utilise désormais Piwik pour mes statistiques dans une base de données séparée.

J'aime(0)Ferme-la !(0)

2014-12-01

En mode préparation d’examens

Après de longues semaines de silence, je prends quelques minutes pour faire un petit signe de vie aux lecteurs qui me suivent. Non je ne suis pas mort, je suis seulement très occupé professionnellement depuis le mois d’octobre et jusqu’aux vacances de Noël. En effet je travaille dans un lycée professionnel hôtelier et en ce moment je suis en plein boom pour les inscriptions aux examens 2015. CAP, BEP, Bac pro, Bac techno, BTS, pas moins de 400 élèves à inscrire. Certes c’est un petit lycée, mais étant suis seul à gérer cette partie et cela demande beaucoup de temps et d’investissements.

Je ne compte pas abandonner le blog, ni mes aventures de libriste, je fais uniquement une petite parenthèse boulot. Cela ne m’empêche pas de continuer à travailler sur les différents projets que j’ai traités ici, notamment mes nouveaux serveurs. La machine qui fera office de Nas est commandée, j’attends la réception du matos dans les jours qui viennent. Cela sera certainement mon prochain article de fin d’année.

Cet article est aussi l’occasion pour moi de remercier tous les visiteurs quotidiens qui passent par mon blog, les commentateurs qui n’hésitent pas en toute franchise à partager leur expérience et leur point de vue. Ses échanges sont toujours très enrichissant.

Je vous dis Merci et à très bientôt.

Olivier

2014-11-25

Configuration d’un Olinuxino A20 en serveur Debian headless

J’ai acheté un deuxième appareil Olinuxino A20 MICRO.

Source : Olimex
Source : Olimex

Cet appareil correspond tout à fait à mes attentes pour en faire un serveur headless : 1 à 4W de consommation, fanless, architecture armhf (donc utilisation des packages debian standards), processeur dual core à 1GHz, 1Go de mémoire vive, connectique très complète, pas cher.

Voici comment je l’ai paramétré pour m’en servir de serveur Debian.

Configuration de base

J’ai utilisé la carte micro-SD proposée par le fabricant : https://www.olimex.com/Products/OLinuXino/A20/A20-Debian-SD/. Mais on peut a priori utiliser n’importe quelle carte : le contenu (filesystem Debian Wheezy) est disponible au téléchargement sur leur wiki : https://www.olimex.com/wiki/A20-OLinuXino-MICRO. Au moment où j’écris ces lignes, la dernière version est la “release 8″.

Avant d’insérer la carte micro-SD dans l’appareil, j’ai configuré le réseau en DHCP (je préfère affecter des baux DHCP permanents). Il suffit d’éditer le fichier /etc/network/interfaces, pour y mettre :

auto eth0
iface eth0 inet dhcp

Une fois accessible en TCP/IP, le serveur peut être administré via SSH.

Il manque l’auto-complétion dans Bash, dont je ne sais plus me passer :

apt-get install bash-completion

Dans la release 7,  il fallait également ajouter dans ~/.bashrc :

source /etc/bash_completion

… mais ce n’est plus nécessaire dans la release 8

Pour être à l’heure française :

dpkg-reconfigure tzdata

Pour renommer le serveur (qui s’appelle “a20-olimex” par défaut), il suffit de modifier les fichiers /etc/hosts et /etc/hostname

Récupération de la mémoire réservée à la carte graphique

L’appareil possède 1Go de mémoire vive. Pourtant, dans la configuration de base, 115 à 175 Mo (selon la version) sont réservés à la carte graphique.

Pour un serveur headless, ça ne sert à rien donc on peut récupérer cette mémoire. Voir https://www.olimex.com/forum/index.php?topic=2509.msg11180#msg11180

Il suffit de créer un fichier uEnv.txt dans la partition de boot.

Comme cette partition de boot n’est pas montée par défaut, je conseille de le faire en rajoutant dans /etc/fstab :

UUID=587A-1A07 /boot           auto    defaults        0       2

(ajuster si nécessaire le uuid : c’est celui de l’image d’Olimex. Un “blkid” vous donnera le vôtre)

puis en faisant un :

mount /boot

On peut ensuite créer le fichier /boot/uEnv.txt avec le contenu :

extraargs=sunxi_no_mali_mem_reserve sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16

Suppression du serveur X et de tous les packages associés

Dans l’image proposée par Olimex, il y a un serveur X et quelques applications graphiques (puisqu’il y a une sortie HDMI, cela fait partie des usages possibles). Ils ne me sont d’aucune utilité en headless.

Plutôt que de supprimer les packages un par un, j’ai préféré supprimer d’un coup tout ce qui dépend du serveur X :

apt-get remove --auto-remove --purge libx11-.*

Optimisation de la gestion des fréquences du processeur

Edité le 05/12/2014 : Les manipulations ci-dessous fonctionnaient en release 7, mais ne fonctionnent plus en release 8. En release 8, on choisit la stratégie dans le fichier /etc/default/cpufrequtils. Par défaut, c’est en mode “performance”. Après réflexion, j’ai gardé ces valeurs par défaut.

En release 7, j’avais initialement choisi la stratégie dite “ondemand”. Cf https://www.olimex.com/forum/index.php?topic=2575.0.

Pour choisir cette stratégie, il faut créer un fichier /root/tune_sunxi.sh avec le contenu :

#!/bin/sh
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 336000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1008000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo 336000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
echo 1008000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
echo 40 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 200000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate

… et l’appeler depuis /etc/rc.local, en y rajoutant la ligne suivante AVANT le “exit 0″ :

sh /root/tune_sunxi.sh

Utilisation des miroirs Debian français

C’est optionnel, mais pas la peine d’aller chercher à l’autre bout du monde ce qui se trouve pas très loin.

Remplacer le contenu de /etc/apt/sources.list par :

# Stable
deb ftp://ftp.fr.debian.org/debian/ wheezy main contrib non-free
deb-src ftp://ftp.fr.debian.org/debian/ wheezy main contrib non-free

# Stable-updates
deb ftp://ftp.fr.debian.org/debian/ wheezy-updates main contrib non-free
deb-src ftp://ftp.fr.debian.org/debian/ wheezy-updates main contrib non-free

# security
deb ftp://security.debian.org/debian-security/ wheezy/updates main contrib non-free
deb-src ftp://security.debian.org/debian-security/ wheezy/updates main contrib non-free

Et finir par installer les mises à jour :

apt-get update && apt-get upgrade

Enjoy !

Et vous voilà avec un serveur Debian (presque) standard, avec lequel vous allez pouvoir jouer comme vous voulez :-)

2014-11-20

Ackee, une webapp d'analytics auto-hébergée

Lors du dernier changement de thème de la SheevaBoite, j’avais installé Piwik mais je me suis très rapidement rendu compte que ce n’était pas un outil pour moi. Trop lourd, trop complet, je l’ai trouvé difficile à prendre en main probablement à cause des trop nombreuses options que je ne comprenais pas, bref j’ai déchanté au bout de quelques jours.

Peu de temps après, j’ai installé un autre outil d’analytics : Ackee développé par Tobias Reich, en parallèle de Piwik. Au bout de deux semaines, j’ai décidé de me séparer Piwik et de garder Ackee. Même s’il n’est pas parfait j’adore sa simplicité et le développeur est ouvert aux améliorations, ce qui est un bon point.

Les fonctionnalités

Ackee ne propose pas une myriade de fonctionnalités, on peut les compter sur les doigts d’une main :

  • Nombres de visiteurs (par heure, quotidiens, mensuels),
  • Nombres de pages vues (quotidiennes, hebdomadaire, mensuelle),
  • Informations sur les devices des visiteurs (résolution, plateforme, navigateur, langues, durée de visite),
  • Quelques statistiques de referrers.

C’est une liste courte mais de mon point de vue amplement suffisante pour un site comme la SheevaBoite.

Aperçu d'Ackee
Aperçu d'Ackee

La capture montre bien l’esprit de simplicité d’Ackee et personnellement je suis fan… Si seulement un utilitaire du même type existait pour les commentaires.

En plus de ces fonctionnalités, Ackee est très simple à installer sur un serveur et les données sont stockées dans une base SQLite ce qui est pour moi un avantage assez intéressant.

Conclusion

Ackee répond presque parfaitement à mes besoins. Il a encore quelques petites lacunes qui seront comblées dans le futur, je l’espère. Sa simplicité est pour moi sa plus grande qualité.

Bref, si vous voulez vous séparer de Google Analytics, je vous conseille de vous intéresser à Ackee qui je pense vaut le coup !

2014-10-30

Analyser ses logs Nginx avec Piwik sans Javascript.

Qu'est ce que tu dis de ça, mec :



Cette capture est tirée d'un Plugin je vous recommande très chaudement d'installer sur LE SEUL navigateur respectant votre vie privée.
Ce dernier bloquera pour toute les petites merdes, qui vous paraissent "invisible" à l’œil nu, pullulant sur les sites que vous l'avez l'habitude de visiter et faites moi confiance ça pullule, de partout.




Je reviendrai plus tard sur les bon outils à utiliser pour surfer relativement "sereinement".

Généralement ces "mouchards" ne servent - heureusement - qu'a analyser le comportement des Internautes visitant les sites, quelles adresses IP ont cliquées sur quoi, quel article est le plus consulté, combien de temps par page, combien de temps est-il resté, enfin des statistiques en veux tu en voilà sur tout et n'importe quoi.
Cette masse de donnée peu être revendue à des entités tiers pour pouvoir mieux "cibler le consommateur par la publicité" ou pour "améliorer la qualité du contenu du site internet, pour répondre au mieux aux attentes du consommateurs" grosso merdo est ce que je vais te coller de la pub pour de la lingerie ou pour le dernier Iphone ... bref de la bonne branlette de décisionnel marketing. En croisant tout ça avec l'âge du capitaine et la cylindrée de la voiture du jardinier, il leur est paraitrait-il possible de prédire la météo ... Bienvenu dans le monde de la BigData

Au fait pour bloquer leur pub il faut utiliser Adblock Plus, ça les détend généralement.

Oui mais on aime un peu ça la branlette :

Certes, d'autant plus que sur les petites plateformes, les sites auto-hébergé, et autre blogs persos, il s'agit juste de savoir si du monde vient faire coucou ou pas. Est-ce que mes articles sont intéressants, enfin satisfaire son Ego besoin de statistiques et au fond, on adore ça les statistiques et les courbes, n'est-ce pas ?



Aimant un peu également la ... enfin les statistiques et n'ayant pas envie de polluer mes visiteurs avec des merdes (ou le moins possible y a du JS dans ma galerie photo quand même).
Piwik fournit une méthode d'analyse des logs du serveur Web plutôt efficace d'ailleurs.

De plus cela allège les requêtes HTTP de quelques Kilo-octets, ce qui lorsqu'on est auto-hébergé n'est pas négligeable et cela fait bien plus propre, d'autant plus que les logs du serveur HTTP traces déjà toutes les entrées sur les pages donc quel intérêt d'aller coller des merdes supplémentaires sur vos navigateurs.

L'inconvénient est qu'il est nécessaire d'effectuer un peu plus de manipulation que simplement balancer son code Javascript sur la page, d'effectuer un peu de filtrage éventuel de ci de là dans la logs.
De plus les analyses ne sont pas temps réelles, mais effectuées sur demande.
Personnellement je m'en tamponne le coquillage, une mise à jour une fois par jour me va très bien.

Le magik tool fournit par Piwik :

Piwik fournit donc un script python bien utile avec plein d'options comme on les aimes planqué dans son répertoire principal :

Exécutez le avec l'option -h pour voir la miriade d'options disponibles :

pwk/misc/log-analytics # python ./import_logs.py -h

Dans l'idée nous allons mettre en place quelque chose comme ça, mettez le tout dans un script shell.

/usr/local/bin/python /mon/local/rep/vers/piwik/misc/log-analytics/import_logs.py \
--url="https://www.pentakonix.fr/piwik/" \
--login="mon-login" --password="monpassword" \
--idsite=1 --output="/var/log/nginx/archives/last-import.log" \
/var/log/nginx/nginx-access.log

L'ID de votre site est probablement 1 si vous n'en avez qu'un seul.

La log de sortie est bien bavarde elle aussi est vous fournira des choses comme ça :

Logs import summary
-------------------

1477 requests imported successfully 8 requests were downloads 1448 requests ignored: 16 HTTP errors 1362 HTTP redirects 0 invalid log lines 0 requests did not match any known site 0 requests did not match any --hostname
56 requests done by bots, search engines... 14 requests to static resources (css, js, images, ico, ttf...) 0 requests to file downloads did not match any --download-extensions

Website import summary ----------------------
1477 requests imported to 1 sites 1 sites already existed 0 sites were created:
0 distinct hostnames did not match any existing site:

Performance summary -------------------
Total time: 25 seconds Requests imported per second: 58.52 requests per second

Inutile d'effectuer du filtrage sur les logs, Piwik détecte tous seul les entrées déjà réalisée, exclu les bot des moteurs de recherche, pour éventuellement exclure encore d'autres IP, (comme la votre par exemple pour ne pas parasiter vos logs), il suffit d'aller dans la page d'administration de piwik > Paramètre > Gèrer > Site , et vous aurez le champs pour y mettre la liste des IP à ne pas analyser.

Puis de coller tout ceci dans un script qui tournera en crontab root aux heures désirées :

0 6,10,12,15,18,22 * * * /bin/sh /root/scripts/piwik-analyse.sh

Faites tourner les serviettes :

Sous FreeBSD, la rotation des logs est effectuée par newsyslog par défaut.
Les services que vous pourriez ajouter ne sont évidemment pas gérés automatiquement, on ne vous mâche pas le travail.
Une fois n'est pas coutume newsyslogest un peu léger en features, pour le coup on utilisera logrotate qui permet lui de lancer des scripts post / prés rotation.

La configuration de logrotate est assez trivial vous connaissez le principe :

root@www-prod:~ # pkg install logrotate

Laisser le fichier logrotate.conf tel quel (enfin sous FreeBSD ça ne pose pas de soucis), et créer un fichier du nom de votre choix dans logrotate.d/

root@www-prod:/usr/local/etc/logrotate.d # ll
total 4-rw-r--r-- 1 root wheel 587 1 nov 00:13 nginx

Avec à l'intérieur de mon fichier nginx, je vous passe le détail technique vous êtes érudit sur syslog hein, 52 jours de rétention, compression à n+2 tout ça tout ça.

/var/log/nginx/*.log {
        daily
        missingok
        rotate 52
        compress
        delaycompress
        notifempty
        create 640 www www
        sharedscripts
        prerotate
                /bin/sh /root/scripts/piwik-analyse.sh
        endscript
        postrotate
                /usr/sbin/service nginx reload
        endscript
}

De cette manière, avant chaque rotation des logs également, logrotate ira lancer l'analyse des logs nginx par notre script. Faîtes attentions aux droits lors de la création du nouveau fichier de log, ou nginx continuera de log dans l'ancien fichier au lieu d'écrire dans le nouveau après rotation. La partie postrotate indique à Nginx de recharger sa conf (ça ne provoque pas chez moi de coupure de service), le kill du PID ne fonctionnait pas chez moi en crontab j'ignore pourquoi.

Voilà, avec tout ça vous aurez une belle analyse des logs de vos visiteurs, semi temps réelle sans coller du javascript qui sera de toutes façons bloqué par les plugins firefox de vos visiteurs un peu soucieux de leur vie privée.

A +

Pentakonix.

2014-10-25

Migrer ses jails FreeBSD vers une autre machine.

Séparer le stockage du hosting

C'est l'idée de base. En fait cela me posait problème que le NAS joue également le rôle de machine http.
Ce sont deux fonctions différentes qui doivent être chacune effectuées sur deux supports physiques différents, le NAS sert du fichier, stock, archive, reçoit les backup, point.

J'en profite donc pour écrire un petit billet, expliquant comment faire pour migrer les doigts dans le nez ses jails d'une machine à une autre, et ce depuis une install "fresh".
L'idée est toujours de tendre vers du backup/restore ultime en lançant un seul script avec deux trois options, du bon gros truc de feignant comme on aime, ça va bien les soirées d'hivers à reconfigurer Nginx.
Cette première migration nous aidera simplement à débroussailler le terrain sous la forme d'un POC et à cerner les différents éléments à prendre en compte pour ce type de projet.

On en profitera également pour voir une première approche sur la sauvegarde, reconnaitre les éléments clés sur FreeBSD et un peu tripatouiller des jails également.

Le nouveau monstre et en fait c'est une vieille brouette HP de supermarché, que j'ai nettoyé et à laquelle j'ai ajouté un peu de RAM qui trainait dans mes cartons.
root@host-box:~ # dmesg | grep memory
real memory = 3221225472 (3072 MB) avail memory = 3027296256 (2887 MB)
root@host-box:~ # dmesg | grep CPU
CPU: Intel(R) Celeron(R) D CPU 3.20GHz (3199.17-MHz K8-class CPU)

Comme toutes les distributions BSD, l'installation FreeBSD est d'une trivialité enfantine, surtout si vous venez du monde Linux.

Je ne ferais pas de screenshot, au pire reportez vous au nombreux tutos qui existent sur le net.
Grosso modo faut mettre son fuseau, horaire, son type de clavier, l'installeur vous demande si vous souhaitez utiliser ZFS ou le bon vieux UFS ... la machine ne faisant pas de stockage et n'étant pas super puissante et n'ayant pas de RAM ECC, j'écarte volontairement ZFS.
Pour le coup sur cette machine j'utiliserai UFSv2 (QUOI ?!) ... UFS est sans doute le système de fichier le plus vieux du monde Unix et les BSD se le colle encore ... c'était bien la peine sur le précédent billet de se moquer d'ext3/4 pour coller ce truc ... bon au moins c'est ultra stable et ultra optimisé.
Ensuite le moment de choisir son shell ; vous aurez le choix entre csh, sh, ou tsch ... et non pas de Bash par défaut sous FreeBSD .... je vous conseille sh, nous installerons Bash "à la main" après l'installation.

Putain il est où bash et c'est quoi ce prompt tout sécoce :

Oui première surprise si vous découvrez FreeBSD bash ne fait pas office de shell par défaut sous BSD, mais pas de soucis ça s'installe très simplement, on ne va pas non plus s'assoir sur toutes les habitudes laissées par l'usage de GNU/Linux d'autant que Bash est un shell très efficace (rha CTRL+R).

Attention en revanche il est très fortement déconseillé de changer le shell par défaut (sh) de root, au pire FreeBSD possède un pseudo compte "root" le compte "toor", c'est la documentation FreeBSD qui en parle le mieux :

It can be dangerous to change root's shell to something other than sh or csh on early versions of FreeBSD and many other versions of UNIX®; you may not have a working shell when the system puts you into single user mode.

Et il est vite arrîvé de se retrouver avec un shell, "single user mode" par exemple en ayant oublié une parenthèse dans le fichier /etc/rc.conf ... ce qui vous obligera à vous connecter au cul de la machine physiquement, cette dernière refusant de lancer sa conf réseau, et là c'est sh, clavier qwerty à la con, la totale ... et d'une manière général pour une meilleur portabilité des scripts inter Unix, sh est conseillé.

La première connexion sous FreeBSD fait toujours un peu peur, un simple "dièse" en guise de prompte, pas de user, pas de nom de machine, la mort
On sent clairement qu'on a à faire à une distribution qui ne fait pas dans la surenchère "friendly user".

En revanche :



A peine plus de 20Mo de RAM paginé au démarrage, impressionnant.

Petite mise au propre de première installation.

Sous FreeBSD le système de base et les paquets sont clairement deux choses distincts à la différence de Debian ou un apt-get update va vous faire une MAJ de vos paquets et du système de base, sous BSD on ne mélange pas les torchons et les serviettes, ce sont deux choses bien différentes.

  • Mettre à jour le système :

Dans mon cas il ne me trouve rien mais en cas de "fresh install" il devrait télécharger un bon paquets de patch (un reboot sera nécessaire il y aura sans doute des maj du noyau).

root@host-box:~ # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 10.0-RELEASE from update6.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done.
No updates needed to update system to 10.0-RELEASE-p11.

Pour mettre à jour les paquets, on utilise le nouvel outil par défaut avec la 10.0 , pkgng : c'est comme apt mais en mieux évidemment (haha), vu qu'il fait tous et ne possède pas de "sous commande" du genre "dpkg reconfigure".

root@host-box:~ # pkg update
Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date.
root@host-box:~ # pkg upgrade
Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Checking for upgrades (0 candidates): 100% Checking integrity... done (0 conflicting) Your packages are up to date.

Vous devriez avoir ce résultat vu que vous n'avez encore rien installé : )

  • Installons Bash :

root@hosting-box:~ # yes | pkg install bash
Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. The following 3 packages will be affected (of 0 checked):
New packages to be INSTALLED: bash: 4.3.24 indexinfo: 0.2 gettext: 0.18.3.1_1

The process will require 16 MB more space. 3 MB to be downloaded.

On le configure pour notre/nos utilisateurs (et uniquement les utilisateurs, pas root) :

root@hosting-box:~ # chsh -s /usr/local/bin/bash mathieu
chsh: user information updated
root@hosting-box:~ # grep mathieu /etc/passwd
mathieu:*:1001:1001:Mathieu Aumont:/home/mathieu:/usr/local/bin/bash
root@hosting-box:~ #

Voilà ce n'était pas si compliqué, on dirait presque une Debian maintenant non ?

Bon on migre :

Il s'agit de récupérer tout les éléments qui étaient sur la machine "source".

Les éléments suivant que j'ai identifiés comme étant à "sauvegarder" pour une restauration rapides sont :

  • Les Jails et leur configuration.
  • /home (notamment pour les clés SSH ...).
  • /etc/rc.conf : qui est en quelque sorte le fichier de configuration maître de votre configuration sous FreeBSD, si vous le ne connaissez pas encore vous allez rapidement vous familiarisez avec lui.
  • /etc/pf.conf : Le fichier contenant vos rêgles de firewalling.
  • Pis c'est à peu prés tout, la data on s'en carre : elle reste sur le NAS, d'où l'intéret d'exploser la partie "computing" de la partie data.

Il faudra évidemment penser à légèrement adapter la conf réseau histoire de ne pas se retrouver avec deux fois la même IP.

En tôle les roumains ... :

Pour la gestion de mes jails j'utilises "ezjail" qui est un outils permettant d'administrer ses jails avec ou sans ZFS d'ailleurs, la preuve je vais migrer des jails depuis un environnement ZFS vers un environnement UFS avec cet outils.

Installons le sur la nouvelle machine :

root@cube-box:~ # pkg install ezjail

Dans ce cas précis de migration, la conf ezjail n'est pas tout à fait ISO, je passe de ZFS à USF et je n'ai pas exactement la même structure d'arborescence de FS, pour le coup j'ai quelques petites modifs à réaliser à la mano.
Dans le cas d'un backup pur ISO en revanche y aura même à se casser la tête il suffira de sauvegarder les fichiers de conf de ezjail.
La seule contrainte est de bien migrer d'un environnement 64bits vers 64bits, ou sinon vos jails ne démarrerons (j'en ai fait les frais une première fois).

Les emplacement "clés" de ezjails sont :

  • /usr/jails/ : L'emplacement par défaut de vos jails (configuration selon vos souhaits).
  • /usr/jails/flavours/ : Les flavours sont vos jails "templates", utile pour du déploiement industrialisé, se créer des modèles de jails ISO avec le même user, les même outils ... .
  • /usr/jails/basejail/ : L'environnement de base de vos jails qui seront montés par chaque jails.
  • /usr/local/etc/rc.d/ezjail.sh : Stop / Start / Restart script
  • /usr/local/etc/ezjail.conf : LE fichier de configuration de ezjail, celui que nous allons configuré le cas présent, le reste n'est que pour la "culture général" du produit.
  • /usr/local/etc/ezjail/ : Le reste des ficheirs ezjails.

Bon en fait je n'ai qu'a modifier la conf de /usr/local/etc/ezjail.conf sur la nouvelle machine c'est super balaise :

# Location of jail root directories
# L'endroit ou seront stocké nos jails
ezjail_jaildir=/usr/jails
# Le reste découle de la variable plus haut
# Pas nécessaire d'y toucher. ezjail_jailtemplate=${ezjail_jaildir}/newjail
# Location of the huge base jail
ezjail_jailbase=${ezjail_jaildir}/basejail
# Les sources utilisés par les jails
# Location of your copy of FreeBSD's source tree
ezjail_sourcetree=/usr/src
[...] # Autoriser le montage (ex NFS à l'intérieur d'une jail) # devfs et procfs servent à autoriser ou noms les jails à utiliser certains commandes
# tel que ps, top ... ezjail_mount_enable="YES" ezjail_devfs_enable="YES" # ezjail_devfs_ruleset="devfsrules_jail" ezjail_procfs_enable="YES" # ezjail_fdescfs_enable="YES" # Je laisse commenté toute la partie Option ZFS - Vu que j'utilise UFS

Maintenant il faut "installer" l'univers Jails sur la nouvelle machine, cela peut quand même prendre quelques minutes le temps de récupérer tout les paquets.

ezjail-admin install

Et voilà nous somme prés à recevoir nos jails depuis la machine "source".

Plus qu'a les exporter c'est possible de réaliser ça à chaud, mais dans le cas des bases d'une base de données il y a des choses à "figer" en mémoire, c'est donc mieux d'éteindre la jails pour éviter les archives foireuses.
D'autant plus qu'avec mes 3 visiteurs / mois les coupures de services d'une minute je m'en cogne un peu.

Depuis la source donc :

root@cube-box:~# ezjail-admin archive
Usage: ezjail-admin archive [-Af] [-a archive] [-d archivedir] jailname [jailname...]

root@cube-box:~ # ezjail-admin stop www-prod
root@cube-box:~ # ezjail-admin archive -d /mnt/backup/ www-prod
root@cube-box:~ # ezjail-admin stop mysql
root@cube-box:~ # ezjail-admin archive -d /mnt/backup/ mysql
root@cube-box:~ # ezjail-admin start mysql
root@cube-box:~ # ezjail-admin start www-prod

Les différents backup seront disponibles ici :

root@cube-box:~ # ll /mnt/backup/
total 7701478
-rw-r--r--  1 root  wheel   246264027 Oct 23 19:23 mysql-201410231920.04.tar.gz
-rw-r--r-- 1 root wheel 1114669984 Oct 23 19:19 www_prod-201410231912.42.tar.gz


Plus qu'a envoyé ça en scp vers la nouvelle machine.

Et niveau réseau ?

Vos jails possèdent toutes une adresse IP différentes. Il y a plusieurs façons de construire son architecture, on ne rentrera pas dans les détails sur Packet Filter el la configuration réseau ici - d'autres billets leur seront entièrement consacrées - de mon côté j'utilise des adresses IP sur une Interface virtuelle.

18:46 mathieu@host-box:[~]:$ ifconfig
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether 00:19:5b:5d:2d:8e
inet 192.168.0.15 netmask 0xffffff00 broadcast 192.168.0.255 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active
rl0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=2008<VLAN_MTU,WOL_MAGIC> ether 00:19:21:2c:6f:9a
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> media: Ethernet autoselect
status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> lo2: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> inet 10.8.8.8 netmask 0xfffffff0
inet 10.8.8.9 netmask 0xfffffff0
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33160root@cube-box:~# ezjail-admin archive

Sous BSD les interfaces ne sont pas nommées ethx comme sous linux mais re, rl ou encore bg, tout dépend de la marque du microcontrôleur de la carte réseau.
  • Ici re0 est ma carte réseau physique,
  • rl0 ne me sert plus c'est la carte réseau intégrée à la carte mère mais qui ne faisait que du 100Mbit/s.
  • lo0 : la loopback
  • lo2 : notre interface réseau virtuelle avec plusieurs d'IP d'attribuée (une pour chaque jails en service).
  • pflog0 : est une interface particulière dédiée à Packet Filter (pas d'intérêt ici).

Pour créer cette interface virtuelle, rien de plus simple, comment souvent tout se configure dans /etc/rc.conf

#On cree une interface virtuelle
cloned_interfaces="lo2"
# Nos deux alias sur l'interface virtuel en \28 = 14 Hosts / 16 IP /28 .240 # Voir : http://www.aelius.com/njh/subnet_sheet.html ifconfig_lo2_alias0="inet 10.8.8.8 netmask 255.255.255.240" ifconfig_lo2_alias1="inet 10.8.8.9 netmask 255.255.255.240"
#J'active les jails
jail_enable="YES"
#Routage
gateway_enable="YES"
#J'utilise ezjail
ezjail_enable="YES"
#Packet Filter (firewalling) pf_enable="YES"

Ou encore plus simple récupérer le fichier /etc/rc.conf sur l'ancienne machine en prenant soin d'adapter les quelques options comme le nom de l'interface physique.

Attention : à ne pas faire d'erreur de syntaxe, oublie de "quotes", dans rc.conf si ce dernier et bancale le boot bloquera et vous vous retrouverez en session de dépannage mono-user root sans réseau, clavier qwerty la totale ...

Voilà on commence à être pas mal, il ne reste plus qu'a recopier l'ancienne configuration de packet filter depuis l'ancienne machine à savoir le contenu de /etc/pf.conf et d'activer l'IP forwading sur la machine hôte

# sysctl net.inet.ip.forwarding=1

Et j'en oublierai presque de recréer mes jails, il ne s'agit après tout que du plus important :

root@host-box:~ # ezjail-admin create -a mysql-201410231920.04.tar.gz mysql 10.8.8.9
root@host-box:~ # ezjail-admin create -a www_prod-201410231912.42.tar.gz mysql 10.8.8.8

Un petit coup de reboot pour la prise en compte de toutes nos modifs notamment réseau et terminé :

19:05 root@host-box:[~]:$ ezjail-admin list
STA JID IP Hostname Root Directory
--- ---- --------------- ------------------------------ ------------------------ DR 1 10.8.8.8 www-prod /usr/jails/www-prod
DR 2 10.8.8.9 mysql /usr/jails/mysql

Pour vous connecter dans votre jail :

19:37 mathieu@host-box:[~]:$ sudo ezjail-admin console www-prod
Password: Last login: Sat Oct 25 23:52:20 on pts/0 FreeBSD 10.0-RELEASE-p10 (GENERIC) #0: Mon Oct 20 12:42:25 UTC 2014 Welcome to FreeBSD! - WWW-PROD JAILS - Edit /etc/motd to change this login announcement.
root@www-prod:~ #


Et sinon ?!

C'était une bonne première approche pour être capable de restaurer au cas où un crash de la machine physique arriverait.
L'idée est toujours d'industrialiser ça au maximum, je bosse actuellement sur un script qui ferait à peu prés la même chose tout seul en lui donnant un ou deux paramètre, backup/restore il sera capable de remonter la machine tout seul comme un grand à partir d'une sauvegarde.

La prochaine fois je reviendrai sur la manière de mettre en place ses services de manière relativement sécure depuis zéro, ou encore on ira mettre le nez dans le monstrueux Packet filter, un des firewall de l'univers BSD qui met Iptables loin, loin dans le brouillard ;-)


N'hésitez pas à me laisser une remarque si nécessaire, j'y répondrai dés que possible.

A +.

Pentakonix

2014-10-18

Free week-end chez Steam

A partir d’aujourd’hui et jusqu’à lundi 20 octobre c’est le free week end chez Steam. La plateforme met propose d’installer gratuitement dix jeux. Les pc Linux ne sont pas oubliés, car sur les dix jeux cinq d’entre eux sont jouables.

Il s’agit de :

  • Awesomenauts
  • Don’t Starve
  • Killing Floor
  • Trine 2
  • XCOM : Ennemy unknown;

A noter aussi qu’ils sont tous en promotions. Pour ma part j’ai craqué sur trois jeux.

Le premier c’est l’excellentissime Trine 2 (3,99 €) qui me faisait de l’oeil depuis un moment déjà. Ce jeu est un vrai chef-d’oeuvre, le mélange jeu de rôle et jeu de plateforme est super bien réalisé. Les trois personnages se complètent très bien en fonction des circonstances et l’univers est simplement magnifique.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube.com/embed/gcuQH3lmin8" width="560"></iframe>

Le deuxième c’est XCOM : Ennemy Unknow, j’avais adoré la première série sur 486 de l’époque, je l’ai installé pour voir si je retrouvais les mêmes sensations d’avec le premier épisode et malgré les graphismes qui ont beaucoup changés le plaisir est toujours là, le tour par tour est vraiment réussi. Pour 5€ pourquoi se priver.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube.com/embed/xCHgi2xGQ50" width="560"></iframe>

Le troisième c’est Don’t Starve, simplement pour la découverte. Je dois dire qu’il est vraiment unique en son genre. Je l’ai acheté à cause de ses graphismes qui m’intriguaient fortement et le style survie que je ne connaissais pas. C’est une vraie réussite on se prend vraiment dans le jeu dont la musique est simplement splendide. Le premier pack est à 6,45 je ne regrette pas mon achat.

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube.com/embed/W689SOpXG9o" width="560"></iframe>

Les vacances commencent bien, moi qui avait peur de m’ennuyer. J’apprécie de plus en plus le catalogue des jeux Steam sous Linux qui s’étoffe de plus en plus.

AjaxTerm : accès SSH minimaliste via le navigateur (après correction CSS)

AjaxTerm permet d’accéder à son serveur SSH via une interface HTML.
A quoi ça sert ? A pouvoir utiliser la ligne de commande dans un navigateur, via le protocole HTTP. C’est utile notamment quand le port SSH est bloqué par un proxy d’entreprise.

AjaxTerm est minimaliste et n’a pas évolué depuis des années. Mais il est très léger et facile à installer. Pour une utilisation ponctuelle hébergée sur un serveur peu puissant, je le trouve tout à fait adapté.

Le problème, c’est que, avec le package fourni par Debian, l’interface est quasi inutilisable sur un navigateur récent :
– le curseur n’est pas visible
– la police est proportionnelle donc les caractères ne sont pas alignés verticalement
– les passages à la ligne ne sont pas respectés

AjaxTerm CSS incorrect

Correctif du bug CSS

Tous ces problèmes viennent du style CSS qui ne s’applique pas correctement au HTML de AjaxTerm.
En le corrigeant un peu, AjaxTerm retrouve sa mise en forme normale :

AjaxTerm CSS corrigé

Il suffit de modifier le fichier /usr/share/ajaxterm/ajaxterm.css, pour remplacer son contenu par :

pre.stat {
    margin: 0px;
    padding: 4px;
    display: block;
    font-family: monospace;
    white-space: pre;
    background-color: black;
    border-top: 1px solid black;
    color: white;
}
pre.stat span {
    padding: 0px;
}
pre.stat .on {
    background-color: #080;
    font-weight: bold;
    color: white;
    cursor: pointer;
}
pre.stat .off {
    background-color: #888;
    font-weight: bold;
    color: white;
    cursor: pointer;
}
#term {
    float: left;
    margin: 0px;
    padding: 4px;
    display: block;
    font-family: monospace;
    white-space: pre;
    background-color: black;
    border-top: 1px solid white;
    color: #eee;
}
span.f0  { color: #000; }
span.f1  { color: #b00; }
span.f2  { color: #0b0; }
span.f3  { color: #bb0; }
span.f4  { color: #00b; }
span.f5  { color: #b0b; }
span.f6  { color: #0bb; }
span.f7  { color: #bbb; }
span.f8  { color: #666; }
span.f9  { color: #f00; }
span.f10 { color: #0f0; }
span.f11 { color: #ff0; }
span.f12 { color: #00f; }
span.f13 { color: #f0f; }
span.f14 { color: #0ff; }
span.f15 { color: #fff; }
span.b0  { background-color: #000; }
span.b1  { background-color: #b00; }
span.b2  { background-color: #0b0; }
span.b3  { background-color: #bb0; }
span.b4  { background-color: #00b; }
span.b5  { background-color: #b0b; }
span.b6  { background-color: #0bb; }
span.b7  { background-color: #bbb; }

body { background-color: #888; }

Le problème venait du fait que le CSS utilisait un sélecteur “pre.term” qui ne correspondait à aucune balise HTML. Par conséquent les styles qui l’utilisaient n’étaient pas appliqués.

Apparemment ce bug a été rapporté il y a peu de temps, mais n’avait pas encore été corrigé. J’ai donc proposé mon petit patch (à l’auteur de AjaxTerm, et dans le bug ouvert chez Debian).

Mais d’où vient ce bug ?

Il parait trop gros pour ne jamais avoir été vu depuis qu’il a été développé (en 2006)…

En creusant un peu, je me suis rendu compte que AjaxTerm (sans mon correctif) fonctionnait très bien avec des navigateurs plus anciens. Sur Firefox 3.0, et jusqu’à Firefox 19, pas de problèmes. Idem avec IE8.

C’est à partir de la version 20 de Firefox que ça n’a plus marché.

Damned, serait-ce une régression de Firefox dans la prise en charge CSS ?

Et bien non, c’est un peu + compliqué que ça : le DOM généré était légèrement différent dans les anciennes versions du navigateur. Et, en particulier, cela générait bien un nœud <pre class=”term”> à l’endroit attendu par le style CSS d’origine.

Dans les versions + récentes du navigateur (que ce soit Firefox ou Chromium/Chrome), ce nœud n’est pas généré. J’ai regardé rapidement le changelog de la version 20 de Firefox, mais je n’ai pas trouvé ce qui expliquerait ce petit changement.

NB : le CSS que je propose fonctionne à la fois sur les anciennes et récentes versions de navigateurs

Et la sécurité, dans tout ça ?

D’abord une évidence : il faut crypter la communication HTTP pour que le trafic ne passe pas en clair sur le réseau. Donc cryptage SSL obligatoire.

D’autre part, à ma connaissance, on ne peut pas utiliser d’authentification par clé avec AjaxTerm : on est donc limité à l’authentification par mot de passe.

Mais au fait, avec mon beau Fail2ban qui contrôle les tentatives d’accès par SSH, qu’est-ce que ça donne avec AjaxTerm ?

Sans surprise, les connexions semblent toutes venir de 127.0.0.1. Donc si Fail2ban bloque cette adresse, c’est tout AjaxTerm qui est bloqué.

Mais surtout, le gros problème est que, par défaut, Fail2ban ignore les échecs de connexion provenant de 127.0.0.1 : dans /etc/fail2ban/jail.conf :

# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1/8

Donc, par défaut, Fail2ban ne surveille pas les connexions SSH qui proviennent de AjaxTerm. Et ça, c’est pas cool.

Bien sûr, c’est paramétrable et on peut enlever 127.0.0.1 des IP ignorées. Mais  je n’ai pas osé le faire.

Au final, j’ai préféré protéger l’accès à AjaxTerm en configurant le VirtualHost Apache avec un autre login/mot de passe. Cette première authentification en Basic Authentication (sur HTTPS bien sûr) est bien surveillée par Fail2ban, qui bloquera bien uniquement l’IP qui pose problème.

Comme il s’agit d’une utilisation ponctuelle, cette double authentification n’est pas une grosse contrainte pour moi.

2014-10-12

L’image du jour

Parfois certaines images valent mieux que de long discours. Hommage à Denis Ritchie

stevejobthiefMerci à chdorb “chdorb@free-beer.ch” et Deppen Magnet ” deppenmagnet@nerdpol.ch” pour l’image.

2014-10-11

Bloc-Notes : Optimisation de myrepos – mrconfig

Suite à un article où j’expliquais comment gérer ses fichiers de configuration $HOME, avec git, mr et vcsh, j’ai décidé de me pencher plus précisément sur la configuration de myrepos alias mr. En effet maintenir un seul et même fichier pour une trentaine de dépôts cela devenait fastidieux. J’ai donc opté pour une organisation décentralisée, avec un dossier pour stocker les différents fichiers de configuration de mes dépôts, appelait par le “mrconfig”.

~
├── .config
│   └── labo
│       └── config.d
│           ├── emacs.vcsh
│           └── zsh.vcsh
│       
│           
└── .mrconfig

Dans cette configuration, j’ai un fichier par dépôts, que j’active ou désactive à souhait dans le “mrconfig”. Un fichier de dépôt est configuré de cette façon, exemple avec mon dépôt emacs :

[$HOME/.config/vcsh/repo.d/emacs.git]
checkout = 
		vcsh clone git@labo.olivierdelort.net:colmaris/emacs.git emacs
		vcsh emacs remote set-url --add origin git@github.com:colmaris/dotfiles-emacs.git

Le fonctionnement reste le même, je clone depuis mon Gitlab et lorsque je pousse mes modifications elles sont simultanément poussées sur mon Gitlab est sur Github.

Passons maintenant au chef d’orchestre le fichier “mrconfig” qui contrôle tout ce petit monde :

# -*- mode: sh -*-
[DEFAULT]
git_gc = git gc "$@"


include = cat ~/.config/labo/config.d/conky.vcsh
include = cat ~/.config/labo/config.d/terminator.vcsh
include = cat ~/.config/labo/config.d/emacs.vcsh
include = cat ~/.config/labo/config.d/zsh.vcsh

Je renseigne tous les dépôts que j’utilise et il me suffit d’un “#” pour désactiver le dépôt concerné. Et l’inverse pour l’activer. Ce fonctionnement est beaucoup plus souple dans mes habitudes de travail.

 

2014-10-08

BLOC-NOTES : S’amuser avec les collections intelligentes de Firefox OS

Objectif :

Les collections intelligentes sont des groupements d’applications proposées en fonction d’un thème. Les plus connues sont “social” “musique” et “jeux” que l’on trouve par défaut. Mais il est possible d’en installer d’autre et même d’avoir des thèmes personnalisés.

Mise en place :

Un appuie long sur le bureau pour arriver sur menu de Firefox OS 2.0 :

2014-10-08-14-38-38Ensuite on “tape” sur “Ajouter des collections intelligentes”. Apparaît alors une grande liste de thèmes.

2014-10-08-06-57-43 2014-10-08-06-58-00Personnellement j’ai choisi les thèmes : Actualité, Autour de moi, Restaurant.

2014-10-08-14-38-50Iil suffit d’ouvrir une collection pour profiter de ses applications.

2014-10-08-14-45-14Il est même possible de créer ses propres collections en fonction d’un thème particulier.

2014-10-08-07-01-34 2014-10-08-07-01-57Dans l’exemple ci-dessus j’ai demandé les applications en relation avec le thème “cloud”. Par contre rien n’empêche d’ajouter des applications installés sur le téléphone dans chacune des collections.

Conclusion :

Pour utiliser ses collections il faut être connecté à Internet , pas souvent évident lorsque l’on a pas de forfait illimité. En revanche, rien n’est installé sur le téléphone, ce qui évite d’avoir des services non désirés exécutés sur le téléphone, elles sont directement connectées au site internet en responsive design.

2014-10-07

Le script kiddie de la mort qui tue, le retour

Avant toute chose je tenais particulièrement à remercier toute l’équipe sécurité de 1and1 pour leur inactivité et leur formidable esprit de non communication, ça fait plaisir de se sentir épauler par des professionnels.

Ne voyant toujours rien venir de la part de 1and1, je n’attendais pas qu’ils me disent comment résoudre mon problème, n’étant pas leur client cela se comprend, mais seulement un message m’expliquant qu’ils avaient trouvés un truc bizarre et qu’ils travaillaient dessus. J’ai donc pris le taureau par les cornes et installé un IDS. J’aurai pu le faire avant et comme dit le proverbe : “les cordonniers sont toujours les plus mal chaussés”. La flemme, le manque de temps, d’envie et l’expression trop souvent répété “bah un petit serveur somme le mien personne ne s’y intéressera” auront eu raison de me jeter un “Bien fait toi !”. Qu’à cela ne tienne j‘étais décidé à en découdre.

J’ai souhaité installer snort inline, mais le projet a été abandonné et puis en y réfléchissant je n’avais pas forcément besoin de surveiller tout le réseau, tout du moins dans l’immédiat. Après vérification seul mon serveur de courriel était touché. J’ai donc installé ossec un HIDS, qui a la particularité de répondre aux attaques avec un bannissement par iptables par exemple. Merci à Hardware qui m’a parlé de Ossec, et m’a aidé sur les règles.

Je n’ai pas installé la version wheezy trop vieille. Et puis honnêtement l’installation depuis les sources est tellement facile, pourquoi se priver de la dernière version? Pour les télécharger rendez-vous à cette adresse :

http://www.ossec.net/?page_id=19

A l’heure ou j’écris ses lignes la dernière version stable est la 2.8.1.

#wget http://www.ossec.net/files/ossec-hids-2.8.1.tar.gz
#tar zxvf ossec-hids-2.8.1.tar.gz
#cd ossec-hids-2.8
#./install.sh

Il suffit de se laisser porter par l’installer qui est très bien fait. J’ai fait une installation en local, pour le moment, l’installation définitive se fera avec l’arrivée de mon nouveau serveur très prochainement. Avant de démarrer le service j’ai modifié un petit peu la configuration de base. Le fichier se trouve dans /var/ossec/etc/ossec.conf par défaut.

# L'envoi d'un courriel se fera lorsqu'une alerte à partir du niveau 5 sera détectée. Par défaut le niveau est à 7
 <alerts>
    <log_alert_level>1</log_alert_level>
    <email_alert_level>5</email_alert_level>
  </alerts>

#Ajout d'une commande spécifie pour l'attaque me concernant, chaque ip détectée sera bannie pour toujours par iptables.

 <command>
    <name>firewall-drop-always</name>
    <executable>firewall-drop.sh</executable>
    <expect>srcip</expect>
    <timeout_allowed>no</timeout_allowed>
  </command>

#Chaque hôte et ip activant la règle 3332 seront bannis définitivement 
<active-response>
    <command>firewall-drop-always</command>
    <location>local</location>
    <rules_id>3332</rules_id>
  </active-response>

#pour valider on démarre ossec
#service ossec start
Starting OSSEC HIDS v2.8 (by Trend Micro Inc.)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

Au bout de quelques heures de fonctionnement les premières adresses commencent à apparaître en état DROP dans iptables.

ban_iptables

Oups, je n’ai supprimé l’adresse de 1and1 Germany :)

Cette solution est plutôt radicale, mais elle demeurera jusqu’à ce que les choses se calme du côté des kiddies. Je laisserai donc le mot de la fin à notre cher Raoul Volfoni :

<iframe allowfullscreen="allowfullscreen" frameborder="0" height="476" src="http://www.youtube.com/embed/urX8n2sA97Q?feature=oembed" width="634"></iframe>

2014-10-06

Le Debian Jessie installer en version beta 2

L’annonce a été faite hier par Cyril Brulebois de l’équipe de développement sur la liste de diffusion, il est disponible dans sa version Beta 2. Le principal changement vient du choix de l’environnement de bureau, cette annonce officialise le retour de Gnome comme environnement par défaut. Un changement intervient aussi dans le menu Tasksel, le menu qui permet de choisir les logiciels à installer. Il est désormais possible de choisir directement quel environnement de bureau nous souhaitons. Cette modification ne permet plus de choisir l’environnement de bureau dès le premier menu d’installation, mais il est toujours possible de télécharger les isos spécifiques pour XFCE, LXDE et KDE. Pour finir j’ai noté l’ajout du support préliminaire pour les architectures arm64 et ppc64el. Pour rappel Jessie sera la nouvelle version stable de Debian, elle portera le numéro 8. Son développement sera gelé le 5 novembre 2014. A partir de cette date les versions des logiciels proposés n’évolueront plus et nous aurons donc un aperçu en attendant sa sortie définitive qui sera selon la devise Debian lorsque se sera prêt !

jessie1

Choix des différents environnements

jessie2

Disparitions du choix d’autres environnements que celui par défaut

Je vous laisse retrouver la liste complète de ses changements :

Important changes in this release of the installer
==================================================

 * Gnome is now the default desktop environment on Linux again.
 * A list of desktop environments is displayed in tasksel, making it
   easy to install another desktop environment (or several of them).
   Unfortunately that is currently a bit underdocumented (#764026).
 * Preliminary support for the arm64 and ppc64el architectures has been
   added.


Other changes in this release of the installer
==============================================

 * brltty: Append the configuration inherited from d-i to the end of
   brltty.conf instead of overwriting it (which was thus losing the
   documentation for the user).
 * brltty: Enable accessibility in XFCE, LXDE and MATE sessions too.
 * busybox: Add support for /32 subnets in udhcpc script (#652573).
 * choose-mirror: Strip off any scheme part found at the start of
   mirror/*/hostname (#706191).
 * console-setup: Correct default keymap for South Korea (#756052).
 * console-setup: Use nepali keymap for Nepali and Tharu by default.
 * debian-installer:
    - Fix the PXE boot images built for kfreebsd, hurd (#759686).
    - Add fonts-lohit-guru-udeb to gtk images, fixing rendering for
      Punjabi (#761573).
    - Remove desktop selection from syslinux; now available in
      tasksel.
    - Keep Linux modules.builtin file in the initrd.
    - Fix lib location and search path for syslinux &gt;= 5 (#756275).
 * fontconfig: Add conf.avail directory to the udeb, fixing broken
   Monospace font in graphical installer (#739011).
 * hw-detect: Improve driver injection disk support.
 * hw-detect: Move firmware installation code to pre-pkgsel.d
 * hw-detect: Correct detection of Macs needing to blacklist snd-aoa
   modules (#650588).
 * iso-scan: Do not error out when searching in folders with
   shell-special characters in their name (#640789).
 * lowmem: Update lowmem limits for linux-x86.
 * lowmem: Make the / ramfs fill the whole memory again (#759336).
 * netcfg: Do not kill_dhcp_client after setting the hostname and
   domain, otherwise Linux udhcpc will stop renewing its lease, and on
   other platforms dhclient will de-configure the network interface
   (#757711, #757988).
 * netcfg: Don't copy /etc/network/interfaces to /target if
   netcfg/target_network_config=ifupdown (#709017).
 * netcfg: Fix support for entering an ESSID manually, it was
   previously getting ignored (#757478).
 * preseed: Update auto-install/defaultroot for jessie.
 * preseed: Always disable locale &amp; keyboard question when auto is
   enabled, even if no preseed file was given on boot, in case the dhcp
   server provides it (#759290).
 * rootskel: Update lowmem limit for gtk on linux-x86.
 * rootskel: Use a tmpfs for some directories to avoid running out of
   space in the fixed-size initrd on kfreebsd-* (#757985).
 * rootskel-gtk: Update gtk-set-font to learn a new mapping (Lohit
   Punjabi).


Hardware support changes
========================

 * libdebian-installer: arm64: Detect UEFI based systems as "efi"
   subarch.
 * libdebian-installer: Add ppc64 and ppc64el support.
 * linux:
    - Include preliminary support for arm64 and ppc64el.
    - udeb: Add ccm, ctr to crypto-modules (#761902).
    - [armhf] udeb: Add ehci-platform, ohci-platform and phy-sun4i-usb
      to usb-modules (#761591).
    - udeb: Add rsi_usb to nic-wireless-modules
    - udeb: Add ath6kl_sdio, libertas_cs, libertas_sdio, mwifiex_sdio,
      r8192u_usb, r8723au, rtl8188eu, rtl818x_pci, rtl8723be,
      rtl8821ae, spectrum_cs to nic-wireless-modules.
    - [armel/orion5x] udeb: Include mvmdio in nic-modules udeb.
    - udeb: Add new sound drivers to sound-modules (#756998).


Known bugs in this release
==========================

 * Firmware handling: udev no longer reports missing firmware
   (#725714), and patches for the kernel need polishing before we are
   able to restore support for loading missing firmware.
 * CD-ROM modules are missing on ppc64el, but the netboot flavour is
   working correctly. This will be fixed in the next release.


Feedback for this release
=========================

We need your help to find bugs and further improve the installer, so
please try it. Installer CDs, other media and everything else you will
need are available at our web site[3].


Thanks
======

The Debian Installer team thanks everybody who has contributed to this
release.

2014-10-04

Le script kiddie de la mort qui tue

Non ce n’est pas le titre du dernier film d’horreur sorti, quoi que, mais de la mésaventure qui me touche depuis vendredi 03 octobre 2014. J’étais en train de faire le tour du propriétaire, vérification des sauvegardes quotidiennes, petit passage dans centreon, visite de mes quelques logs. Et là je m’aperçois que mon fichier mail.log avait grossi anormalement depuis deux jours.

Je commence mon investigation, au bout de quelques minutes je m’aperçois qu’un nom de domaine revient très très très fréquemment. Entre les une seconde et une minute.

connect from s15519008.onlinehome-server.com[74.208.164.28]
warning: s15519008.onlinehome-server.com[74.208.164.28]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
lost connection after AUTH from s15519008.onlinehome-server.com[74.208.164.28]
disconnect from s15519008.onlinehome-server.com[74.208.164.28]

De plus ce nom de domaine à l’air de provenir d’un dédié chez un prestataire puisque il est la forme sxxxxxxxxx.onlinehome-server.info, et qu’il change d’adresse toutes les deux tentatives.

Dans un premier temps j’opère un whois sur le domaine et j’obtiens les infos suivantes :

Email 	is associated with ~4,658,945 domains
is associated with ~1,876,696 domains
	
  
Registrant Org 	1&1 Internet Inc. is associated with ~430 other domains 	
  
Dates 	Created on 2003-10-27 - Expires on 2014-10-27 - Updated on 2013-10-27 	
  
IP Address 	212.227.142.1 - 5,070 other sites hosted on this server 	
  
IP Location 	Germany - Baden-wurttemberg - Karlsruhe - 1&1 Internet Ag
ASN 	Germany AS8560 ONEANDONE-AS 1&1 Internet AG,DE (registered Nov 26, 1997)
Domain Status 	Registered And Active Website

Je continue mes recherches sur internet et je tombe sur cet article de janvier 2014. Tout cela me parait louche. J’ai l’habitude de recevoir des tentative d’authentification sur mes serveurs, mais pas de cette façon. Mon instinct me dit de me méfier, car ce n’est jamais le même sous-domaine qui tente de s’authentifier, il en est de même pour l’adresse IP :

Je décide de contacter 1and1 une première fois, d’une pour les prévenir qu’ils ont peut-être une faille quelque part et d’autre pour si réellement ce domaine leur appartient, en même voir si cela ne vient pas de chez moi. Le technicien me confirme bien que ce domaine leur apartient, qu’il est géré par la maison mère en Allemagne pour finir qu’il va me mettre en relation avec un technicien sécurité. J’attends un peu et je tombe sur un gentil monsieur qui ne parle qu’allemand et tente de m’expliquer dans un anglais à l’accent très germanique qu’il va trouver quelque-un qui parle anglais. Malheureusement nous avons été coupés avant. Je rappelle une deuxième fois et là le technicien que j’ai au bout du fil, est français et je lui raconte ma mésaventure. Il m’explique que le ou les serveurs sont connus pour des fait similaire et me demande de leur envoyer mes fichiers log pour qu’ils enquêtent, ce que j’ai fait.

Il est midi et les attaques ne cessent, mais cela ne me bloque pas le serveur pour autant comme par exemple pendant une attaque ddos.

Je décide quand même de faire quelque-chose en commençant par créer une règle de filtrage fail2ban pour l’authentification sasl.

je modifie mon fichier jail.local dans /etc/fail2ban/ et j’y ajoute ses lignes :

[sasl]

enabled = true
port     = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter   = sasl
logpath  = /var/log/mail.log
bantime     = 86400

 Puis je crééla règle dans /etc/fail2ban/filter.d/sasl.conf :

[Definition]

failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: \w

ignoreregex =

 Je relance le daemon pour valider les changements. Au moment ou je créer ce filtrage Fail2ban ne me sert pas à grand chose puisque les hôtes d’attaque sont aléatoires, mais avec le temps il va forcément réutiliser une ip et là il sera banni, au fur et à mesure que son pool d’ip diminuera.

Je décide aussi de bloquer le domaine onliniehome-server.info dans iptable :

iptables -A INPUT -s onlinehome-server.info -j DROP

Au moment où j’écris ses lignes (03/10/2014) les attaques sont sont beaucoup calmées, peut-être une dizaine par heure contre plusieurs dizaines avant. Je n’ai toujours pas de retour de 1and1 et je ne sais pas si j’en aurai, je les relancerai par mail d’ici demain. A mon avis je ne pense pas qu’ils soient méchants, plutôt des jeunes qui s’amusent, il faut bien que jeunesse se fasse mais c’est quand même embêtant ce genre de situation.

L’affaire continue, suite au prochain numéro.

 

2014-10-03

La vidéoconférence par WebRTC est elle sécurisée?

Actuellement, le schéma WebRTC actuellement proposé par moult sites web comme Talky.io, vLine etc… est similaire. C’est le serveur web qui est responsable de la première mise en relation des clients et de leur authentification.

Le premier utilisateur rejoint une « salle » identifiée par une URL et chaque client qui se connecte à cette URL se joint à la « salle » de visioconférence.

Cela pose un problème de sécurité. Qu’est ce qui m’assure que :

  • le serveur web ne va pas s’interposer entre les clients pour enregistrer toutes les conversations? (il s’assurer que l’IP d’échange de données est bien celle de chaque correspondant)
  • qu’un client caché n’est pas aussi présent dans la salle? (il faudrait vérifier et comprendre le code source livré par le site web à chaque exécution)
  • que mon correspondant ou moi-même ne sommes pas l’objet d’un MITM sur un nœud de connexion réseau. Par exemple, un routeur de mon FAI ou de mon réseau local pourrait relayer la vidéo.

Ces problèmes sont présents actuellement dans les services proposés au grand public. Je vous invite à lire cet article : WebRTC Security – an overview & privacy/MiTM concerns (including a MiTM example) pour aller plus loin sur le sujet.

J'aime(1)Ferme-la !(0)

2014-10-02

La livebox et son loopback … « Go fuck ! »

Illustration issue de Degroupnews.com

Illustration issue de Degroupnews.com

Je suis très content de mon FAI (Sosh), qui m’offre de très bons débits (78/16) pour un prix modique et en « paysannie » !
Mais ils ont une livebox  Play comme modem/routeur :(

Elle est lente, moche, pleines de bugs, manque un tas d’options, et cale très mal les meubles.
donc elle est bonne à rien !

Mon plus gros reproche, est l’absence d’option pour gérer le loopback !
Comme vous le savez, je m’auto-héberge, ce qui veut dire que de chez moi, je suis susceptible d’accéder à des ressources via un nom de domaine  qui pointe en local.
la plus part des box opérateurs gèrent ça très bien, sauf bien sur, la livebox !
de l’extérieur sheldon.fr pointe sur mon serveur, de chez moi ça redirige vers … l’interface d’administration de la livebox :/

 

Quelles alternatives s’offrent à moi ?

  • la plus évidente : changer de modem, et prendre un vrai truc de bonhomme ! -> malheureusement il existe encore très peu de modem compatible VDSL2 (je ne parle même pas des routeurs), et encore moins qui sont compatible avec le protocole utilisé par l’agrume (VPC 8.35, G993_2)
  • changer d’opérateur ? -> il n’y a que Orange qui me propose du VDSL
  • modifier le fichier /etc/hosts sur chaque machine -> trop galère: j’ai trop de VMs, PC et pas pratique sur les smartphones & cie
  • bidouiller les nom DNS dans l’interface de la livebox -> solution simple, mais incompatible quand on utilise plusieurs domaines et sous domaines sur une même machine (ce qui est mon cas)
  • changer les DNS ? -> trop simple ça suffit pas
  • Obiwan envoi direct ses requêtes à Chuck Noris

Il en reste une dernière, monter son propre DNS local avec les usines habituelles telles que Bind, Bind9 …
ou alors maître en place Dnsmasq !

dnsmasq http://www.thekelleys.org.uk/dnsmasq/doc.html

Dnsmasq, c’est quoi ?

c’est un petit outil tout mignon, tout léger, qui fait des tas de trucs  et qui est très simple à administrer, pas mal non ?
On peut en faire :

  • un serveur DNS local
  • un cache DNS
  • un serveur DHCP
  • un relai DHCP
  • il supporte le DHCPv4, DHCPv6, le BOOTP et le PXE

On essai ?

J’ai décidé de monter un container pour gérer ce service, et bien évidemment j’utilise encore et toujours … OpenVZ (on va pas se refaire hein !)
mais une fois n’est pas coutume, il y a quelques modifs à faire sur le CT à savoir :

vzctl set CTID --capability setuid:on --save
vzctl set CTID --capability net_admin:on --save
vzctl set CTID --capability net_raw:on --save

Pour le reste des caractéristiques, j’ai mis : 1 core, 256 Mo ram, et 4 Go de disque
et je suis large, une fois ma VM configurée et Dnsmasq installé, elle consomme 9 Mo ram, et 8 taches (ça doit être ma plus petite VM ^^) !

l’installation n’est pas trop compliquée :

apt-get install dnsmasq

la partie configuration se situe dans /etc/dnsmasq.conf
voici un exemple de ma config et ses commentaires.

# utilisation du nom de domaine complet pour les requetes DNS
domain-needed

#simule les requetes reverses en local
bogus-priv

#interface d'écoute
interface=eth0

#mon domaine
domain=sheldon.fr

#la taille du cache en nombres de requetes
cache-size=1000

# Cette directive permet d'ajouter le domaine défini ci-dessous aux noms simples figurant dans /etc/hosts
expand-hosts

#gestion des logs, attention c'est verbeux !
log-facility=/var/log/dnsmasq.log
log-queries


# plage dynamique de 192.168.0.110 à 192.168.0.149 avec un bail de 24h
dhcp-range=192.168.0.110,192.168.0.149,255.255.255.0,24h

#les options se déclare avec type,valeur - ici la valeur 3 est la passerelle de ma livebox
dhcp-option=3,192.168.0.1

# adresse IP fixe pour la machine FF:FF:FF:FF:FF:FF
#dhcp-host=FF:FF:FF:FF:FF:FF,test,192.168.0.15

# Désactiver cette directive uniquement si votre serveur est le serveur DHCP officiel du réseau
dhcp-authoritative


#déclaration pour mon serveur xmpp
address=/xmpp.sheldon.fr/192.168.0.241
srv-host=_xmpp-client._tcp.sheldon.fr,192.168.0.241,5222
srv-host=_xmpp-server._tcp.sheldon.fr,192.168.0.241,5269
txt-record=_xmppconnect.sheldon.fr,"_xmpp-client-xbosh=http://sheldon.fr:5280/http-bind"

 

Le fichier resolv.conf

#mon domaine
domain sheldon.fr
search sheldon.fr

#la déclaration DNS
#en premier il s’interroge lui même afin de vérifier si il a la requête en cache
nameserver 127.0.0.1
#si il ne la connaît pas, il interroge un autre DNS
nameserver 208.67.222.222

 

La déclaration des machines en local, dans /etc/hosts :
mon fichier avec quelques exemples :

fe00::0         ip6-localnet
00::0           ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters



192.168.0.220   zimbra  zimbra.sheldon.fr
192.168.0.239   munin   munin.sheldon.fr
192.168.0.241   xmpp    xmpp.sheldon.fr
#...

127.0.0.1 localhost
192.168.0.10 ovz-dns.sheldon.fr  ovz-dns

::1             localhost ip6-localhost ip6-loopback

 

n’oubliez pas un /etc/init.d/dnsmasq restart après les modifications !

 

Dnsmasq est très pratique, il permet également la déclaration pour le protocole XMPP :)
Autre limitation de la livebox (décidément …), je ne peux pas modifier les DNS transmis par son propre serveur DHCP, j’ai donc été obligé de le désactiver (mince alors) pour utiliser celui de dnsmasq, afin qu’il renseigne sa propre ip en tant que DNS au client DHCP.
La partie cache, fonctionne également très bien, exemple :

Première requête, elle n’est pas dans le cache, elle est donc transmise vers mon DNS qui fait autorité (temps : 26ms)

dig linux.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> linux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37505
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;linux.org.			IN	A

;; ANSWER SECTION:
linux.org.		3104	IN	A	107.170.40.56

;; Query time: 26 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct  2 11:34:54 2014
;; MSG SIZE  rcvd: 43

à la seconde requête, elle est cette fois dans le cache, le traitement est instantané :

dig linux.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> linux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24005
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;linux.org.			IN	A

;; ANSWER SECTION:
linux.org.		3103	IN	A	107.170.40.56

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct  2 11:34:55 2014
;; MSG SIZE  rcvd: 43

Vous souhaitez vérifier le bon fonctionnement ?
allons faire un tour dans les logs :

Oct  2 11:34:54 dnsmasq[3027]: query[A] linux.org from 127.0.0.1
Oct  2 11:34:54 dnsmasq[3027]: forwarded linux.org to 208.67.222.222
Oct  2 11:34:54 dnsmasq[3027]: reply linux.org is 107.170.40.56
Oct  2 11:34:55 dnsmasq[3027]: query[A] linux.org from 127.0.0.1
Oct  2 11:34:55 dnsmasq[3027]: cached linux.org is 107.170.40.56
Oct  2 11:40:18 dnsmasq[3027]: query[A] linux.org from 127.0.0.1
Oct  2 11:40:18 dnsmasq[3027]: cached linux.org is 107.170.40.56

On voit donc la première requête est adressé à 208.67.222.222, qui la résous, puis la mets en cache, lors du second appel, c’est le cache de Dnsmasq qui répond.

Autre exemple, lorsque je veux utiliser ma webmail depuis chez moi, avant je tombais sur l’interface de la livebox, maintenant dnsmasq voit l’enregistrement présent dans /etc/hots et corrige ma requête DNS :

Oct  2 11:59:23 dnsmasq[3027]: query[A] zimbra.sheldon.fr from 192.168.0.211
Oct  2 11:59:23 dnsmasq[3027]: /etc/hosts zimbra.sheldon.fr is 192.168.0.220

Conclusion :
c’est simple à mettre en place (à peine 5/10 min), facile à maintenir, très souple (bon faut chercher un peu dans les options) et libre !
que demander de plus ?

Le changement c’est pour bientôt

A travers ce titre racoleur, je dois l’avouer, il s’agit plutôt d’une conjecture sur mon envie de changement concernant ma solution d’auto-hébergement plutôt qu’un sujet politique. Depuis 2011 je suis sur la même plate-forme, plusieurs machines virtuelles hébergées sur proxmox qui lui-même est installé sur un ordinateur de salon classique. Après un premier bilan il y a deux ans j’étais satisfait de cette solution, elle me convenait très bien. Mais le problème c’est que j’aime le changement, la remise en question, la nouveauté et les nouveaux défis.

Mon premier serveur(droite) sous mandrake 10

Mon premier serveur(droite) sous mandrake 10, lors de nos lan

Les gamers

Les Gamers

Les Gamers

Les Gamers

A l’époque j’avais concrétisé pas mal d’année de travail et de recherche en réalisant ce projet qui me tenait à coeur, m’auto-héberger presque en totalité. Ce projet à commencer au début de mes études en informatiques et il ne m’a jamais quitté depuis. Pourquoi confier à d’autres mes courriels, données, création, alors que j’ai la compétence pour le faire ? L’idée ne m’est pas venu un beau matin en me levant. Tout a commencé pendant mon BTS lorsque j’hébergeais pour tous les gamer de ma classe un petit forum et les versions serveurs de nos jeux préférés (counter-strike, quake 3, ennemi territory et bien d’autre), cela nous permettait de nous fragger (comme on dit le jargon gamer) après une dure journée de chauffage de banc. La seule constante avec aujourd’hui c’est que tous mes serveurs tournent sous Linux que j’ai découvert en 1995 avec une Mandrake 5.3. Depuis j’ai amélioré mes compétences, mes connaissances, ma technicité, sur l’administration système, réseau. Par la suite ce fut mon métier et j’ai commencé par héberger :

  • Un petit serveur web pour mon blog
  • Un serveur de courriel
  • Un serveur Dns
  • Un serveur de Base de données

De ce point de départ beaucoup de choses ont évoluées, certains serveurs ont disparu d’autre ont vu le jour suite à des besoins spécifiques (gitlab, owncloud, piwik, …). Aujourd’hui les choses continuent encore d’évoluer, Proxmox me correspond de moins en moins, le matériel vieillit (3 ans de fonctionnement 24/24 7/7), la quantité de données croit exponentiellement chaque année. Pour faire une parenthèse sur Proxmox je ne leur reproche absolument rien en particulier, mais il se tourne de plus en plus vers les entreprises leur cible principale et je les comprends. Proxmox m’a rendu pas mal de services en tant que particulier, mais n’étant pas une entreprise et ne souhaitant pas le devenir, je commence à chercher d’autre solution de virtualisations. Cela n’enlève rien à la qualité du logiciel, bien au contraire je suis sûr qu’il en sera encore meilleur.

Mon matériel aussi à évoluer au fil des ans, au départ il y avait :

Premier Pare-feu, Jetway mini-ITX sous ipcop

Pare-feu,  mini-ITX sous ipcop

first-firewall1

La bête mes à nue

  • Le serveur
  • Un Nas
  • Un pare-feu

Depuis le NAS et le pare-feu ont été virtualisés, mais avec le temps je m’aperçois que tous regroupé n’est pas forcément une bonne chose non plus, il faut trouver le juste milieu. Je repartirai très certainement sur trois appareils comme au départ, d’ailleurs j’ai déjà commencé avec le pare-feu : une Carte Alix avec ipfire.

Maintenant je souhaite passer sur une installation plus silencieuse, moins énergivore et moins encombrante niveau matériel. Toujours basée sur la virtualisation qui est pour moi une technologie d’avenir. Concrètement j’établis un pseudo mon cahier des charges.

Le matériel

Comme expliquer plus haut le cas du pare-feu est réglé, le plus facile. Il ne me reste plus que le futur serveur et le Nas. Tous deux doivent répondre aux mêmes contraintes :

  • Assez puissant pour héberger des hôtes virtuels
  • Disposer de ports SataPeu encombrantSilencieux
  • Générique : matériel grand public pour facilité les réparations en cas de pannes
  • Un prix entre 150€ – 200€ tout compris (Proc, RAM, Alim, Boîtier, sans les DD)
  • Qui consomme le moins possible d’énergie
  • Connectique la plus variée possible, mais au moins une carte réseau au Giga.

J’avoue que je louche de plus en plus sur les cartes de type bay trail, j’ai d’excellent retours de la part de plusieurs amis qui utilisent ses cartes-mères.

Deux modèles se détachent, le premier c’est la gigabyte GA-C1037UN-EU, la seconde c’est la MSI J1800I.

La gigabyte est plus adaptée en utilisation serveur, deux cartes réseau, 3 ports sata, possibilité d’ajouter de la RAM jusqu’à 16 go sur slot standard ce qui me permetra de garder la RAM de mon précédent serveur.

Je verrai plus la MSI en tant que Nas, seulement une carte réseau, des slots mémoires pour portable, Ram maxi 8Go.

En comptant le boîtier, l’alimentation, la Ram pour la MSI, je suis pratiquement dans mon budget.

En sachant que récupère tous Disque durs, certains sont tous neufs, la RAM, tout ce qui est petit câblage (Sata, alim etc …)

Le Logiciel

Comme je l’expliquais plus haut proxmox ne répond plus à mes besoins. Il me faut une solution de virtualisation moins gourmande en ressources que KVM, moins obsolète que OpenVZ (en ce qui concerne sur Debian). Et puis j’ai envi de décourvrir d’autre logiciel de virtualisation. Et plus précisément Docker, on peut parler de conteneur plus que de virtualisation pure.

J’ai donc commencé mes investigations sur Docker et je compte bien en apprendre plus. Du côté des hôtes virtualisés cela ne bougera pas trop, très certainement je basculerai tous mes serveurs web sous nginx, j’en ai marre de gérer la doublette avec apache, qui malgré mes optimisations il devient de plus en plus gourmand.

Rien n’est arrêté, je commence à peine mes réflexions sur mon nouveau projet, s’il le faut la semaine prochaine je partirai sur une autre installation. Mais ce qui est sûr c’est que je vais commencé à travailler sur Docker puis le matériel viendra tout seul.

Cela promet de belles aventures, que je ne manquerai pas de partager ici.

2014-10-01

bloc-notes : Déplacer le dossier data de owncloud

Objectif :

Déplacer le dossier data de owncloud vers un autre disque dur plus grand. Le dossier data contient les données de tous les utilisateurs de ownCloud. Y sont présent :

  • les fichiers
  • les agendas
  • les contacts
  • et autres

Mise en place :

En premier il faut arrêter le serveur web.

service stop apache2 #pour apache
service stop nginx   #pour nginx

 Puis il faut installer le nouveau disque dur, le partitionner, le formater et le monter.

Pour l’installer, spécificité de proxmox :

qm set <Id de la VM> -sata1 /dev/sdb
#cela fonctionne aussi avec un partion simple
qm set <Id de la VM> -sata1 /dev/sdb1

Redémarrage de la VM pour valider l’installation.

Pour le partitionner, j’ai utilisé cfdisk, mais un autre gestionnaire est possible.

Capture d'écran de 2014-09-28 14:33:30Pour le formatage :

mkfs.ext4 /dev/sdb

Pour le monter :

mkdir /mnt/datacloud
mount /dev/sdb1 /mnt/datacloud

Afin que le montage soit permanent il faut éditer le fichier /etc/fstab et rajouter la ligne en fin de fichier :

/dev/sdb1       /mnt/datacloud  ext4        defaults        0       0

A présent les données peuvent être déplacées :

mv /var/www/owncloud/data/ /mnt/datacloud/data

Cela prendra plus ou moins de temps en fonction de la taille du dossier.

Ensuite mise en place des droits, sans cela les données ne seront pas visible depuis l’interface Web. Il faut donner les droits à l’utilisateur qui gère le service web sur le serveur, sous Debian il s’agit de “www-data”.

chown -R www-data:www-data /mnt/datacloud/data/

Modification de la configuration de ownCloud :

#edition du fichier de configuration 
sudo nano /var/www/owncloud/config/config.php

Chercher la ligne “datadirectory” et modifier le champs avec le nouveau chemin.

'datadirectory' => '/mnt/datacloud/data',

Pour terminer, démarrage du serveur web :

service apache2 start
ou
service nginx start

2014-09-30

J’ai rejoint la framasphère

Suite l’article de Cyrille BORNE j’ai eu envie de retenter l’expérience DIASPORA*  version Framasoft. Lors de son annonce j’étais plus qu’enthousiaste à l’idée qu’un réseau social décentralisé, libre voit le jour et se place en concurrent de Facebook. Puis ce fut la désillusion, la réalité à vite reprit son cours et il y a eu les problèmes, une levée de fond fantôme, la mort d’un des développeurs, l’abandon du projet par le reste de l’équipe.

Mais Diaspora* c’est avant tout un logiciel libre car le code source appartient maintenant à sa communauté, il est accessible via Github.  A ceux qui pensent le contraire Diaspora* n’est pas mort pour autant, le réseau continue de vivre avec sa communauté. Un logiciel décentralisé car il est tout à fait possible d’installer son propre pod pour le connecter avec les autres, ainsi les données partagées sur le réseau sont hébergées chez soi. De plus Diaspora* continue toujours de faire parler de lui, très récemment suite à l’apparition d’une communauté importante autour de Firefox OS et aujourd’hui avec la création d’un pod français par Framasoft. C’est ce dernier évènement qui m’a donné envie de retenter l’aventure Diaspora* pour plusieurs raisons :

  1. Framasoft est un des acteurs majeurs du libre francophone, gage de sérieux
  2. Une initiative portée par une association à but non lucratif, cela pourrait convaincre certains de migrer.
  3. Actuellement en pleine remise en question sur mon utilisation des réseaux sociaux framasphère tombe à pic.
  4. L’envie d’ajouter ma petite participation à l’édifice et redonner sa chance à Diaspora*

Je souhaite bonne chance à Framasoft dans cette initiative et je me joins à eux pour la faire vivre avec la publication de mes articles et autres. Pour être un peu plus utopique je souhaite qu’elle change les habitudes du grand public envers les réseaux sociaux privateurs et commerciales, mais ça c’est une autre histoire.

Pour rejoindre la communauté, il suffit de se créer un compte sur https://framasphere.org, pour les puristes de Facebook il y a même de quoi le lier avec votre profil.

Quant à moi vous pourrez m’y retrouver sur Olivier Delort ou olivierd@framasphere.org, ou via les tags que je suis :

 frama1 frama2 frama3

Piwik et le syndrome de la page blanche

Suite à la mise à jour de mon piwik à 2.7.0, celui-ci refusait de fonctionner. En guise de page d’accueil j’avais une belle page blanche. Je procède donc à une investigation comme suit :

Pour commencer j’ai fait une recherche dans mon Error log qui se trouve /var/log/piwik.error.log, et il en ressort se message d’erreur :

[28-Sep-2014 15:57:09] PHP Fatal error: Maximum execution time of 30 seconds exceeded in .../piwik/vendor/tedivm/jshrink/src/JShrink/Minifier.php on line 302

Il semblerait que l’exécution du script php Minifier.php dure plus de 30 seconde, pour y remédier :

  1. Editer le fichier php.ini

sudo nano /etc/php5/apache2/php.ini

 2. Chercher la ligne : max_execution_time

 3. Remplacer le chiffre 30 par une valeur plus élevée (70 par exemple)

 4. Relancer le service apache

sudo service apache2 restart

Malgré cela j’avais toujours cette maudite page blanche, après avoir contacté le support par courriel, un gentil technicien m’a répondu et m’invita à supprimer le contenu du répertoire /tmp.

sudo rm -fr /var/www/piwik/tmp/*

Suite à cette action Piwik est réapparut, il manque néanmoins toutes les statistiques de la journée du dimanche 28 septembre mais c’est toujours mieux que d’avoir perdu trois ans de données.

2014-09-29

Nouvelle fonctionnalité Steam : le lecteur audio

Le 24 septembre dernier Steam a reçu une nouvelle mise à jour, pourquoi n’en parler qu’aujourd’hui ? Etant donné que je viens juste de réaliser cette mise à jour. Parmi les nouveautés un lecteur audio pour écouter les OST de mes jeux préférés. Si comme moi vous possédez la bande son de certains jeux vous pouvez désormais les écouter sans utiliser de logiciel annexe.

Il était tout à fait possible de copier les fichiers audio dans sa bibliothèque pour les écouter. Même si au final cela ne change pas grand-chose, j’apprécie lorsque j’ai lancé un jeu et que j’ai oublié de démarrer ma musique.

La mise en place très simple il n’y a pratiquement rien à faire.

Dans le menu afficher -> informations musicales (Figure 1)

Figure 1

Figure 1

Sur cette fenêtre il est possible d’ajouter l’album à une playlist, je n’ai pas trouvé comment faire des playlist par chansons et pas par album. On peut aussi afficher où se situe l’album sur notre disque dur. Il suffit ensuite de chercher l’album qui nous intéresse et de lancer la lecture. (Figure 2)

Figure 2

Figure 2

Pour finir un mini lecteur apparait. Avec toutes les fonctionnalités de base, lecture en répétition, aléatoire.

Capture d'écran de 2014-09-28 20:19:28

Petite fonctionnalité qui ne paye pas de mine, mais qui me simplifie grandement la vie.

2014-09-28

Journée de la transition de Perpignan

Hier, samedi 27 septembre, c’est tenu la journée nationale de transition citoyenne et Perpignan s’est joint à cet évènement. Bien évidemment j’étais de la partie avec mon association afin de montrer aux plus grands nombres qu’il existe une autre façon d’utiliser les nouvelles technologies, l’informatique à travers les logiciels libres, différentes solutions économiques comme le recyclage.

Nous partagions le stand avec l’association A.R.C qui s’occupe du recyclage informatique et de la revente à prix réduit pour les particuliers.

L’ambiance était super malgré le vent qui s’est levé en fin de matinée, plein d’animations étaient proposées, notamment pour les enfants, atelier cuisine avec des produits locaux, théâtre, poèmes, jeux de bois géants.

Nous avons tous passé une agréable journée, en espérant y participer de nouveau l’année prochaine.

 

IMG_0028 IMG_0030 IMG_0029 IMG_0031 IMG_0032 IMG_0033 IMG_0034 IMG_0035 IMG_0036 IMG_0037 IMG_0038

2014-09-27

Pourquoi Yahoo est contraint de livrer des données personnelles à la NSA

En 2008, Yahoo s’opposait à donner suite aux demande de données sur ses clients par la NSA. Yahoo a récemment publié comment elle s’est finalement pliée à la demande de la NSA.
Ces milliers de pages de documents déclassifiés sont très intéressants.

Premièrement, entre 1978 et 2007, la NSA avait besoin d’émettre un ordre FISA (service de renseignement envers les puissances étrangères) pour accéder à des données personnelles. Ces ordres ne permettaient que d’espionner les citoyens des puissances étrangères (ou agissant pour elles).

Cette limitation provient en partie du 4ème amendement de la constitution des états unis qui protège les citoyens américains d’intrusion dans leur vie privée sans mandat judiciaire et ciblé.

En 2005, Georges Bush est attrapé pour avoir permis à la NSA d’espionner les communications internationales de citoyens américains depuis 2002. Ces écoutes visaient officiellement à traquer les terroristes, mais étaient en tout état de cause contraire à la loi FISA de 1978.

Pour rendre légale ces écoutes, la loi FISA est amendée en 2007 par le Protect America Act. Celui-ci permet dorénavant à la NSA :

  • d’espionner les communications depuis ou vers des citoyens étrangers sans nécessiter d’autorisation
  • supprime la nécessité d’apporter de preuve que le citoyen visé est étranger ou en dehors des états unis.

Cela ouvre ainsi le champ à la surveillance électronique de masse des communications des citoyens non-américains. PRISM commence à voir le jour et la NSA voudrait que les services de communications mondiaux comme Yahoo donnent à la NSA un accès en masse aux données de leurs clients.

Il y a cependant une ambiguïté juridique, lorsque l’on espionne la communication entre un citoyen français et un citoyen américain, on espionne le citoyen américain en piétinant le garde fou du 4ème amendement ! De plus, puisque aucune preuve que le citoyen visé est bien hors US ou non américain n’est due par la NSA pour émettre un ordre d’écoute, cela ouvre la porte à bien des abus.

Ce sont ces points qu’à soulevé Yahoo pour refuser de donner un accès aux données de ses clients à la NSA. Cependant, la FISC, a conclu que ceux-ci n’étaient que des effets de bord minimes conformes à l’esprit de la loi. Yahoo à 250’000 $ de pénalité par jour tant qu’il refusait de se plier à la demande de la NSA.

Vous savez maintenant comment la NSA peut légalement et avec tout le confort lire vos emails (Gmail, Yahoo), écouter vos appels Skype, etc…

J'aime(3)Ferme-la !(0)

2014-09-26

Bloc-notes : Changer le fond d’écran de gdm

Objectif :

Changer l’image de fond sur l’écran de connexion de gnome sous Debian.

Mise en place :

Choisir une image par exemple :

the_tree_by_katenfelix-d3906jv

Image brute

Source : http://jesper-ullbing.deviantart.com/art/the-tree-196523563

J’ai choisi de la modifier pour qu’elle s’adapte à GDM et surtout à la résolution de mon écran sinon l’image ne sera pas entièrement visible.

Image modifier avec la bonne résolution

Image modifier avec la bonne résolution

La suite tien deux lignes de commandes.

sudo mv /usr/share/gnome-shell/theme/noise-texture.png /usr/share/gnome-shell/theme/noise-texture-bak.bak 
sudo cp Images/the_tree_by_flou.png /usr/share/gnome-shell/theme/noise-texture.png

Le thème de base proposé par debian utilise un fichier appelé “noise-texture.png” qui permet d’obtenir le fond gris foncé de base. L’idée est simplement de le remplacer par notre image modifiée.

Une petite fermeture de session plus tard :

Capture d'écran de 2014-09-25 20:34:38Capture d'écran de 2014-09-25 20:34:28Cette opération sera à répéter à chaque changement de fond, ou en cas de mise à jour de gnome-shell comme en ce moment avec la mise à jour vers la 3.14.

2014-09-25

Migration d’un serveur Gitlab

Après onze mois à l’essai j’ai enfin prit le temps de trouver une demeure définitive à mon Gitlab. En effet plus les mois passent, plus il est devenu indispensable dans ma vie de  tous les jours. Il me permet de garder un historique de mes scripts, fichiers de configurations et autres projets sur lesquels je travaille.

Gitlab est une sur-couche à git écrite en ruby qui permet de faire tourner un serveur git à la github chez soi. Beaucoup plus complet que ce propose github (avis très personnel), il est parfait lorsque l’on veut maintenir de petits fichiers de configurations. Il peut être aussi utilisé en complément de Github comme je le fais, ainsi je partage mes projets avec beaucoup plus de monde. Pour plus d’information rendez-vous sur le site officiel www.gitlab.com. Si vous voulez vous lancer dans l’aventure je vous conseille la “comunauty edition”.

 Préparation

Sur l’ancien serveur j’effectue une sauvegarde totale (base de données, dépôts …)

cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production

 

Par défaut celle-ci se trouve dans “/home/git/gitlab/tmp/backups”, c’est un fichier compressé qui ressemble à ça :

[TIMESTAMP]_gitlab_backup.tar #[TIMESTAMP] fait référence au moment de la sauvegarde

 

Je fais une copie de ce fichier pour plus tard, l’idée est de restaurer cette sauvegarde sur le nouveau serveur fraîchement installé. Se nouveau serveur sera installé à la même version que l’ancien, dans mon cas la 6.7.5. Lors de mes tentatives de restauration j’avais fait l’inverse, mais la migration ne s’est pas déroulée correctement.

Pour installer le nouveau serveur j’ai tout simplement suivit la documentation sur le site.

 Migration

Première étape j’importe le fichier [TIMESTAMP]_gitlab_backup.tar dans le dossier /root. A ne pas copier directement dans le dossier /home/git/gitlab/tmp/backups cela changera les droits. Ensuite la migration est très simple :

cd /home/git/gitlab/tmp
#Création du dossier de sauvegarde
mkdir backups
#Copie du fichier de sauvegarde
cp /root/[TIMESTAMP]_gitlab_backup.tar /home/git/gitlab/tmp/backups/[TIMESTAMP]_gitlab_backup.tar
#Attribution des droits à l'utilisateur git
sudo chown -R git:git /home/git/gitlab/tmp/backups/[TIMESTAMP]_gitlab_backup.tar
#Lancement de la restauration
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production

 

Après quelques secondes la restauration est terminée. Tout y est la base de données, les utilisateurs, les dépôts, toutes les données de l’ancien serveur.

Maintenant tout le travail de configuration reste à faire, afin basculer définitivement sur le nouveau serveur.

Configuration post migration

Gitlab

Dans un premier temps il faut indiquer à gitlab l’url à utiliser pour l’interface web. Deux fichiers sont à modifier, je profite aussi de l’occasion pour activer les connexions ssl de mon futur serveur.

Le premier se trouve dans /home/git/gitlab/config/gitlab.ymlATTENTION avec les fichiers en Yaml les espaces sont très important il faut les respecter scrupuleusement !

## GitLab settings
  gitlab:
    ## Web server settings
    host: url.monserveur.tld
    port: 443
    https: true #activation des connexions ssl

 

Le second se trouve dans /home/git/gitlab-shell/config.yml – ATTENTION avec les fichiers en Yaml les espaces sont très important il faut les respecter scrupuleusement !

# Url to gitlab instance. Used for api calls. Should be ends with slash.
gitlab_url: "https://url.monserveur.tld/"

 

Pour valider les modifications un redémarrage du service gitlab.

service gitlab restart

 

Un peu plus haut j’abordais l’activation du SSL pour l’interface web mais aussi pour toutes les communication avec git. J’ai créé un certificat de classe1 signé chez StartSSL. Par la suite je me suis trouvé dans l’obligation  de le modifier pour l’utiliser avec Nginx. Depuis le site de startSSL j’ai récupéré le certificat, la clef non chiffrée et le certificat intermédiaire. Afin d’utiliser conjointement le certificat et l’intermédiaire dans nginx il faut les combiner.

cat gitlab_ssl.crt sub.class.server.ca.pem > gitlab.combined.crt

 

Nginx

Activation des connexions ssl nginx. D’abords créer une sauvegarde de l’ancien fichier.

mv /etc/nginx/sites-available/gitlab /etc/nginx/sites-available/gitlab_bak

 

Pour récupérer le nouveau fichier :

git clone https://labo.olivierdelort.net/colmaris/gitlab-recipes.git

 

Ce fichier réécrit les requêtes entrantes sur le port 80 vers le port 443, de plus il corrige l’erreur 400 Bad request que j’ai eu lors du premier démarrage.

ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
service nginx restart

 

Hop un nouveau  lien symbolique vers les sites activés, et je relance nginx.

Lors de ma première connexion j’ai retrouvé tous mes utilisateurs, les dépôts, comme si de rien n’était. Je dois encore mettre à jour mon nouveau  serveur et profiter des dernières nouveautés de la 7.3.0 au moment où j’écris ses lignes.

Encore des stars à poil sur Internet

Ce week-end, a été publié encore une flopée de photos et vidéos de stars Hollywood dans des positions des plus embarrassantes si vous voyez ce que je veux dire.

Je suis impressionné que des mecs aient pu récolter des photos si compromettantes sur des personnes si ciblées.
Est ce que le système de données personnelles centralisé (vendu sous le petit nom moins angoissant « cloud ») qui permet entre autres à une poignée d’individus (les patrons des admins) de surveiller les autres (nous) ne se retourne pas finalement en partie contre eux ?

A un moment donné, ce système géant il faut bien le maintenir en fonctionnement, et malgré toute l’automatisation des machines il faut un grand nombres d’informaticiens pour maintenir cela en marche avec les délégations de pouvoir et d’accès qui vont avec.
Quel admin n’a jamais eu accès (je n’ai pas dit « accédé ») aux données confidentielles de ses clients?

Comme je doute qu’il y ait (pour l’instant) un traitement différencié pour les VIPs (et comment choisirait-on les VIPs?), il y a une palanquée de personnes qui ont accès aux photos, à la géolocalisation, aux carnets de contacts, agendas, etc… des système de données personnelles mondiaux. Et ceci quand ils veulent puisque tout est archivé pour l’éternité.

Comme, contrairement à beaucoup de chose, quand on copie les données, on n’empêche pas le système de tourner et on peut faire en sorte que ça ne se voit pas (admin power), il me parait moins étonnant que des admin, à priori quelconques, voient des choses croustillantes et décident de les garder sous le coude (coucou Mr Snowden).

Là où il fallait autrefois des moyens de fou furieux pour espionner une célébrité, il n’est plus besoin que de quelques touches de clavier pour les informaticiens ayant accès aux données en production.
Miam !

J'aime(3)Ferme-la !(1)

2014-09-24

La journée de transition citoyenne à Perpignan

L’association Perpinux sera présente pour démontrer qu’il existe aussi une transition, une alternative à notre utilisation des nouvelles technologies et du multimédia. N’hésitez à venir rencontrez les bénévoles sur notre stand si vous êtes dans le coin pour échanger, apprendre, débattre.

Plus d’infos sur le site internet de Perpinux.

Fail2ban pour sécuriser Tiny Tiny RSS (et module rpaf pour le reverse-proxy)

Fail2ban sait surveiller les authentifications faites par SSH, Basic Authentication d’Apache etc. Il peut bloquer l’IP et avertir l’administrateur au bout de n tentatives infructueuses (y compris par SMS).

Mais il peut aussi surveiller les authentifications applicatives, pour peu que l’application en question génère des logs exploitables.

C’est notamment possible avec Tiny Tiny RSS.

fail2ban+ tt-rss_logo_original_128

Configuration Fail2ban

Je suis parti d’un post sur les forums de tt-rss, qui explique comment configurer cela via les logs de syslog : http://tt-rss.org/forum/viewtopic.php?f=8&t=2817#p18518 (merci à son auteur : JackyOhh)

Ce que je propose ci-dessous n’est qu’une variante de sa solution, qui s’appuie sur les logs standards d’Apache plutôt que syslog.

Dans le fichier config.php de tt-rss, il faut commencer par activer les logs “PHP logging” plutôt que “SQL” :

define('LOG_DESTINATION', '');

La valeur vide indique d’utiliser la sortie log de PHP. Avec la configuration standard d’Apache, c’est redirigé vers le error.log de Apache (par défaut /var/log/apache2/error.log, ou l’emplacement spécifié via la directive ErrorLog).

Il faut ensuite ajouter un filter Fail2ban adapté, en créant un fichier /etc/fail2ban/filter.d/tt-rss-auth.conf :

# Fail2Ban configuration file
#
# Author: Mossroy
# Inspired by http://tt-rss.org/forum/viewtopic.php?f=8&t=2817#p18518
#
# $Revision$
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = apache-common.conf

[Definition]

# Option:  failregex
# Notes.:  regex to match the password failure messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values:  TEXT
#

failregex = ^%(_apache_error_client)s PHP Warning: *Failed login attempt for .* from .*$

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Puis ajouter dans /etc/fail2ban/jail.conf :

[tt-rss-auth]
enabled = true
filter = tt-rss-auth
port = http,https
logpath = /var/log/apache*/*error*.log

Et redémarrer fail2ban :

service fail2ban restart

Adaptations pour que cela fonctionne derrière un reverse-proxy

Dans ma configuration, j’ai un serveur1 en frontal qui est un reverse-proxy vers un serveur2 qui fait effectivement tourner tt-rss. Cela pose deux problèmes :

  • Fail2ban est installé sur serveur1 (car c’est là qu’il faudrait bloquer les IP). Mais serveur1 n’a pas directement accès aux logs de serveur2
  • Les logs de tt-rss (sur le serveur2) affichent toujours l’IP de serveur1 (puisque c’est effectivement serveur1 qui l’appelle), au lieu de l’IP de l’utilisateur réel (qui est celle qu’on veut pouvoir bloquer)

D’abord, j’ai configuré un partage NFS pour que serveur1 (et donc fail2ban) puisse voir les logs de serveur2.

Ensuite, il existe un module Apache, mod_rpaf, qui permet de “corriger” la variable REMOTE_ADDR, de sorte que Apache croit que les requêtes viennent directement depuis l’IP de l’utilisateur : https://github.com/gnif/mod_rpaf. Cela consiste à renseigner cette variable avec l’IP qu’il trouve dans l’entête HTTP X-Forwarded-For.

Et ce module est disponible dans les dépôts Debian : https://packages.debian.org/fr/wheezy/libapache2-mod-rpaf

NB : Tout jeu de mot entre le nom de ce module “rpaf” et une histoire drôle avec un chien serait purement fortuite ;-)

apt-get install libapache2-mod-rpaf

Puis il faut le configurer pour mettre l’IP du reverse-proxy dans /etc/apache2/mods-available/rpaf.conf :

RPAFproxy_ips 192.168.0.1

(remplacer le 192.168.0.1 par l’adresse IP du reverse-proxy)

Après avoir redémarré Apache, les logs affichent bien l’adresse IP de l’utilisateur.

A noter que ce module Apache m’a également permis de corriger plusieurs soucis liés à l’utilisation d’un reverse-proxy :

  • Les applications n’ont plus besoin d’être modifiées pour lire l’entête X-Forwarded-For. Elles peuvent directement lire l’IP source comme s’il n’y avait pas de reverse-proxy. C’est cool parce que rares sont les applications qui prennent en compte ce type de configuration
  • C’est plus sécurisé car le module ne fait confiance qu’aux adresses IP listées dans rpaf.conf. Cela évite que quelqu’un se fasse passer pour quelqu’un d’autre en ajoutant simplement une entête X-Forwarded-For

Enregistrement SRV pour XMPP sur les DNS de Gandi

Si vous lisez la documentation sur les enregistrements SRV pour XMPP, vous verrez qu’il est indiqué de mettre quelque chose comme ça dans votre zone DNS :

_xmpp-client._tcp.example.net. 86400 IN SRV 5 0 5222 example.net.
_xmpp-server._tcp.example.net. 86400 IN SRV 5 0 5269 example.net.

Manque de bol, ca ne marche pas si votre DNS est chez Gandi. Il faut mettre plutôt ceci :

_xmpp-client._tcp 86400 IN SRV 5 0 5222 example.net.
_xmpp-server._tcp 86400 IN SRV 5 0 5269 example.net.

Vous pouvez vérifier vos enregistrement SRV avec ce site (Attention, la propagation des modifications de votre DNS peut prendre du temps)

J'aime(1)Ferme-la !(0)

Mise à jour vers Gnome 3.14 sur Debian Sid

Depuis le 20 septembre je reçois des mises à jour depuis experimental sur la nouvelle mouture de de Gnome à savoir la 3.14.

Au moment où j’écris ses lignes la migration n’est pas complète, beaucoup de choses manques notamment les extensions pour générer les thèmes de gnome-shell la fameuse “user-themes“, qui est toujours coincée en 3.12 chez Sid. Du coup au revoir mon joli thème perso, je vais devoir le mettre à jour et l’activer à la main.

Après un rapide tour du propriétaire je remarque une nette rapidité à l’ouverture de session, le petit effet de zoom à l’exécution d’une application dans le menu est agréable. J’ai une réelle impression de vélocité du système dans ma navigation, utilisation, ouvertures de mes applications quotidiennes.

il y a encore quelques petits bugs, comme celui de Nautilus qui ne souhaite pas rester dans ma barre de favoris et quelques réglages effacés (l’affichage non désiré des fichiers cachés).

Beaucoup de paquets n’ont pas encore été mis à jour, mais cela devrait arriver dans les jours à venir. Pour ma part j’attends patiemment de retrouver une interface graphique stable, mais c’est le jeu quand on est sous Sid.

 

2014-09-20

Configurer Tiny Tiny RSS sur Debian Wheezy, et lire ses flux RSS sur Firefox OS

Il existe beaucoup de lecteurs de flux RSS, que ce soit sur ordinateur ou sur mobile.

Mais je voulais pouvoir centraliser la liste de mes flux, et synchroniser les articles lus/non lus, quel que soit l’appareil que j’utilise. Tout ça en auto-hébergement bien sûr. Pour cela, Tiny Tiny RSS (tt-rss) est parfait.

Mais son interface n’est pas bien adaptée sur un smartphone, donc j’utilise l’application FeedMonkey sur Firefox OS, qui sait s’y synchroniser.

tt-rss_logo_original_128 + feedmonkey-icon-128

Tiny Tiny RSS

C’est un excellent lecteur de flux RSS en mode web, que je vous recommande. Il est sous licence libre GPLv3, avec une interface web très bien léchée, et a toutes les fonctionnalités que j’attendais. Plus d’infos sur http://tt-rss.org/redmine/projects/tt-rss/wiki.

Cerise sur le gâteau : il a une option “minimiser l’usage du trafic” à la connexion, qui évite les aller-retours réseaux quand on le garde en arrière-plan (l’actualisation de la page ne se fait que quand on le demande). Pratique quand on utilise une connexion réseau dont il ne faut pas trop abuser.

Tiny Tiny RSS me parait très bien adapté à de l’auto-hébergement. Il a des concurrents plus légers en termes de consommation de ressources, mais qui ont moins de fonctionnalités. Pour mon besoin, c’est un bon compromis.  Il tourne raisonnablement bien sur mon Olinuxino A20, alors qu’il ramait un peu sur une sheevaplug.

Configuration de la mise à jour des articles

La seule difficulté d’installation est la configuration de la mise à jour des articles. La doc officielle http://tt-rss.org/redmine/projects/tt-rss/wiki/UpdatingFeeds dit d’utiliser :

php ./update.php --daemon (single process) or php ./update_daemon2.php (multi-process)

Et elle précise d’éviter de le faire sous le user root (pour des raisons de sécurité, effectivement). Mais elle n’explique pas comment faire ça facilement sous Debian Wheezy.

Heureusement, il se trouve que tt-rss a un package debian. Malheureusement pas pour la version Wheezy, mais pour la version “sid” de debian (c’est-à-dire celle qui est encore loin d’être stable). Plutôt que de réinventer la roue, j’en ai repris les scripts, en les adaptant à un tt-rss installé manuellement dans /var/www, et déjà configuré dans Apache.

En décompressant le fichier tt-rss_1.13+dfsg-1_all.deb (ou la dernière version en date), on peut y récupérer les fichiers /etc/init.d/tt-rss, /etc/default/tt-rss et /etc/logrotate.d/tt-rss

Il faut commencer par copier ces 3 fichiers tel quel dans l’arborescence de notre Debian Wheezy, puis les modifier :

/etc/init.d/tt-rss

Dans /etc/init.d/tt-rss, on ne touche pas au code, mais il faut modifier les valeurs de quelques variables en début de fichier :

Remplacer :

PIDFILE=/var/lib/tt-rss/update_daemon.lock

par :

PIDFILE=/var/www/tt-rss/lock/update_daemon.lock

et remplacer les /usr/share/tt-rss/www par /var/www/tt-rss dans les répertoires du daemon :

Remplacer :

DAEMON="/usr/share/tt-rss/www/update.php"
DAEMON_ARGS="--daemon"

if [ "$FORKING" != "0" ]; then
    DAEMON="/usr/share/tt-rss/www/update_daemon2.php"
    DAEMON_ARGS=""
fi

LOADER=/usr/bin/php
DAEMON_DIR="/usr/share/tt-rss/www"

par :

DAEMON="/var/www/tt-rss/update.php"
DAEMON_ARGS="--daemon"

if [ "$FORKING" != "0" ]; then
    DAEMON="/var/www/tt-rss/update_daemon2.php"
    DAEMON_ARGS=""
fi

LOADER=/usr/bin/php
DAEMON_DIR="/var/www/tt-rss/lock"

 /etc/default/tt-rss

Dans /etc/default/tt-rss, il faut simplement activer le daemon :

DISABLED=0

 /etc/logrotate.d/tt-rss

Rien à modifier dans ce fichier

 

Ensuite on peut installer le service :

update-rc.d tt-rss defaults

Puis le démarrer :

service tt-rss start

Et voilà ! Vous pouvez surveiller les logs dans /var/log/tt-rss.log

Attention à ne pas se faire avoir avec les permissions des répertoires : il faut que tout le répertoire /var/www/tt-rss (et ses sous-répertoires) ait pour owner www-data, de sorte que le contenu puisse être accessible en mis à jour par le daemon. Si nécessaire :

chown -R www-data:www-data /var/www/tt-rss

 

Réduction de la fréquence de mise à jour

Par défaut, je trouve que tt-rss est un peu “agressif” dans sa stratégie de mise à jour. Évidemment, ça permet d’avoir les nouveaux articles au plus vite, mais c’est au détriment d’une consommation de ressources importantes : CPU sur le serveur, réseau entre le serveur et les machines qui hébergent les flux RSS, réseau entre le serveur et le client web.

Personnellement, j’ai donc préféré réduire certaines fréquences de mise à jour.

Hélas, ce ne sont pas des paramètres externalisés dans tt-rss. Donc si vous modifiez comme moi ces valeurs, il faudra le refaire à chaque mise à jour de tt-rss.

Sur le serveur

Par défaut, les flux RSS sont tous interrogés toutes les 2 minutes. On peut choisir un délai différent dans l’IHM de tt-rss, flux par flux. J’ai préféré passer ce délai par défaut à 10 minutes, qui est donc appliqué à tous mes flux automatiquement.

Ca se passe dans le fichier include/rssfuncs.php : passer la valeur DAEMON_SLEEP_INTERVAL de 120 à 600 secondes

define_default('DAEMON_SLEEP_INTERVAL', 600);

Sur le client web

Par défaut, le client web interroge le serveur toutes les minutes (sauf si on activé le mode “minimiser l’usage du trafic” : dans ce cas l’interrogation est déclenchée par l’utilisateur). J’ai préféré passer ce délai à 15 minutes.

C’est dans le fichier js/tt-rss.js :

setTimeout("timeout()", 15*60*1000);

Optimisation des performances en désactivant la détection de la langue

Par défaut, tt-rss essaie sur chaque article de détecter quelle langue est utilisée, pour configurer la césure des mots dans cet article.

Le problème, c’est que cette fonctionnalité consomme beaucoup de CPU : http://tt-rss.org/redmine/issues/779. Quand on a un serveur peu puissant, ça me semble une fonctionnalité dont on peut largement se passer.

Un paramètre a été introduit en version 1.10, qui permet de désactiver la détection de la langue des articles. Dans le fichier config.php :

define('DETECT_ARTICLE_LANGUAGE', false);

 

Lecture des flux sur Firefox OS

ttrss-mobile

J’ai longtemps utilisé le projet ttrss-mobile.  C’est une petite application PHP qui utilise l’API JSON de tt-rss, pour exposer une IHM adaptée aux smartphones.

ttrss-mobile marche très bien, mais je l’ai finalement abandonné pour plusieurs raisons :

  • il ne permet pas la lecture hors-ligne
  • la saisie du login/mdp et les fréquents aller-retours avec le serveur rendent son utilisation un peu lourde au quotidien
  • le projet ne semble plus très actif

FeedMonkey

feedmonkey-icon-128

Cette application existe depuis longtemps sur le MarketPlace de Mozilla, mais il y avait jusqu’à peu des bugs qui la rendaient inutilisable pour moi : https://github.com/jeena/FeedMonkey/issues?q=is%3Aissue+author%3Amossroy

En particulier, j’ai corrigé le bug qui était le plus gênant pour moi, car il bloquait les mises à jour d’articles au bout de 24h : https://github.com/jeena/FeedMonkey/issues/30

Bref, maintenant, ça marche bien.

Ce qu’il faut savoir, c’est que FeedMonkey ne stocke actuellement pas votre mot de passe (uniquement l’URL du serveur et le login). C’est bien pour la sécurité. Par contre, si vous ne voulez pas avoir à re-saisir le mot de passe trop souvent, je vous conseille d’augmenter la durée de vie de la session du serveur, dans le fichier config.php de tt-rss :

Remplacer la durée de 24h :

define('SESSION_COOKIE_LIFETIME', 86400);

Par une durée d’une semaine (par exemple) :

define('SESSION_COOKIE_LIFETIME', 604800);

FeedMonkey est assez minimaliste dans son interface et dans ses fonctionnalités, mais c’est ce qui le rend efficace à mon goût. Il est très rapide et va à l’essentiel.

FeedSpider

feedspider_app_icon

J’ai découvert FeedSpider à travers l’article d’Olivier Delort : http://blog.olivierdelort.net/?p=1418

Il est sur le Marketplace, et il marche très bien aussi.

FeedSpider a bien plus de fonctionnalités que FeedMonkey, en particulier l’accès par catégories, plus d’options, l’ajout de flux RSS etc.

Mais il m’a semblé plus lent (il fait apparemment + d’aller-retours serveurs), et un peu plus lourd à l’utilisation.

Techniquement, il stocke votre mot de passe dans le localStorage (cf https://github.com/OthelloVenturesLtd/FeedSpider2/blob/68f7aafb0d345a99974e4c0a94229473939ef8e3/source/data/credentials.js). Ce n’est pas gravissime mais ça aurait été bien de prévenir l’utilisateur (et de lui laisser le choix). Et puis c’est dommage qu’il soit stocké en clair. A ce propos, stocker des informations cryptées fait partie des améliorations demandées à la plateforme Firefox OS par les développeurs : https://openwebapps.uservoice.com/forums/258478-open-web-apps/suggestions/6190136-encrypted-indexeddb

Bref, pour l’instant je reste sur FeedMonkey, mais ce FeedSpider est très complet fonctionnellement. J’y passerai peut-être un jour.

TE-Reader

te-reader-icon

Je l’ai trouvé par hasard sur le Marketplace. Mais je n’ai pas trouvé le code source, ni la licence. J’ai posé la question : http://www.apps.meissel.com/?p=12#comment-13

En attendant, je n’ai pas testé donc n’ai pas encore d’avis dessus.

2014-09-16

Serveur Tiny Tiny Rss et Firefox OS

En grand lecteur de flux Rss que je suis, il était indispensable que je puisse me connecter sur mon serveur Tiny Tiny Rss. Après quelques cliques sur internet je suis tombé sur l’application qui répond exactement à mes besoins : FeedSpider.

Cette petite application disponible via le market, permet de consulter ses flux rss depuis diverses sources :

  • Tiny Tiny Rss
  • Owncloud News
  • Feedly
  • The Old Reader
  • Inoreader
spider1

Sélection des différents services

La prise en main et la configuration sont très simple, l’interface est très bien pensée et très agréable lors la lecture. Du côté des fonctionnalités, pour moi tout y est, je retrouve la configuration faite dans TTRSS. Une fois le service sélectionné, il suffit de renseigner son login, mot de passe, et l’url du serveur TTRSS.

spider2

Connexion à Tiny Tiny Rss

Sur le premier écran sont visible uniquement les nouveaux articles avec leurs catégories respectives, il est possible de modifier cela dans les paramètres. Très appréciable aussi de pouvoir ajouter un flux à partir du téléphone sur le serveur.

spider3 spider4 spider5

Je n’ai pas encore fait le tour complet du propriétaire, je ne l’utilise seulement depuis un jour, mais pour l’instant j’y trouve mon compte et j’en suis satisfait.

2014-09-15

Maj Proxmox 3.3

Une nouvelle version de Promox en 3.3 vient d’être publiée.

proxmox_the_ultimate

Voici les principaux changements :

mais également :

  • gestion des vlan pour les CTs
  • gestion du htoplug sur les VMs (kvm)
  • nouveaux drivers pour les cartes réseaux (avec gestion « multiqueue »)
  • nouveaux kernels 26.32-136 et 3.10.0-4 (mais toujours pas de support OpenVZ)
  • basé sur Debian Wheezy et 7.6

source : http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_3.3

 

Pour mettre votre installation à jour, rien de plus simple, utilisez pveupgrade :

pveupgrade 
Starting system upgrade: apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libpve-storage-perl pve-cluster pve-firewall pve-manager snmpd srvadmin-omcommon
6 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 6,291 kB of archives.
After this operation, 1,999 kB disk space will be freed.
Do you want to continue [Y/n]?

2014-09-12

Mon nouveau jouet tout feu tout flame !

Moi aussi j’ai succombé à la déferlante Firefox os-Flame que je viens hier soir. Je ne vais pas refaire le détail du packaging qui a déjà été très bien réalisé par mon confrère libriste Dada.

A l’heure actuelle j’ai fait un rapide flashage en 2.0, avec une image pré-compilée, mais dès que possible j’essaierai de compiler un 2.1 histoire d’avoir une version avec les dernières modifications. J’ai aussi rencontré des problèmes avec mon serveur mail chiffré pourtant je n’ai pas de certificat auto-signé, j’utilise celui de Gandi.

Toujours de pas de carddav pour mes contacts hébergés sur ownCloud, mais par contre le calendrier fonctionne très bien tant que je ne souhaite pas le synchroniser en SSL.

Mis à part ses quelques problèmes à approfondir, j’accroche complétement à l’interface, le téléphone en lui-même est très bien. Je ne suis de toute façon pas objectif puisque mon ancien mobile était un vieux Galaxy S qui peinait à faire tourner CyanogenMod 10.

Pour info je n’ai payé que 29 euros de frais de douane et TVA contrairement aux 36 euros annoncés sur le wiki de Mozilla ou les 47 euros payés par d’autre. Je ne manquerai pas de faire d’autres articles en essayant de ne pas reprendre ce qui a déjà été fait, mais toujours en partageant mes expériences bonnes ou mauvaises.

Pour l’instant je suis encore dans l’euphorie de la nouveauté et de la découverte.

2014-09-08

Nouveaux paquets en test pour Proxmox

Je viens de trouver par hasard en faisant les maj d’un cluster Proxmox 3.2 quelques bonnes surprises :)

 

Logo-ProxmoxVE

  •  un nouveau module de gestion du Firewall, paramétrable au niveau du cluster, de l’hôte ou des VMs.
  • une console en HTML5, fini le vieux VNC asthmatique !
  • un nouveau kernel en 3.10, mais toujours pas de support officiel d’OpenVZ (ou alors il faut mettre les mains dans le cambouis sans garantie de succès)
  •  QEMU en 2.1
  • et une mise à jour de Corosync et Fence, rendant la gestion du HA moins hasardeuse !

vous trouverez ces paquets dans le repo de tests, pour cela,
éditez nano /etc/apt/sources.list

et ajoutez y :

# PVE pvetest repository provided by proxmox.com
deb http://download.proxmox.com/debian wheezy pvetest

Pensez à faire un upgrade ;)

pveversion -v
proxmox-ve-2.6.32: 3.2-136 (running kernel: 2.6.32-31-pve)
pve-manager: 3.2-30 (running version: 3.2-30/1d095287)
pve-kernel-2.6.32-32-pve: 2.6.32-136
pve-kernel-2.6.32-30-pve: 2.6.32-130
pve-kernel-2.6.32-29-pve: 2.6.32-126
pve-kernel-2.6.32-31-pve: 2.6.32-132
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.7-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.10-1
pve-cluster: 3.0-14
qemu-server: 3.1-34
pve-firmware: 1.1-3
libpve-common-perl: 3.0-19
libpve-access-control: 3.0-15
libpve-storage-perl: 3.0-22
pve-libspice-server1: 0.12.4-3
vncterm: 1.1-8
vzctl: 4.0-1pve6
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 2.1-5
ksm-control-daemon: 1.1-1
glusterfs-client: 3.5.2-1

Quelques screens :

L’interface Html5 :
Capture d'écran - 08092014 - 16:59:19

Capture d'écran - 08092014 - 17:26:45

La gestion du Firewall :

Capture d'écran - 08092014 - 17:00:33

Généré le 2015-02-01 19:27 UTC avec Planet Venus