Auto-hébergement : DNS secondaire via Poweradmin, qui n’en veut ?

Nobox : ok, ADSL : ok, QOS : ok, Serveur DNS : ok, Partage : pas ok

Avoir une nobox qui turbine c’est bien, partager ses ressources c’est mieux.

Je lance donc un appel aux auto-hébergés qui n’en veulent : si vous avez besoin d’un NS secondaire, viendez !

Description de la « bête »

Tout est là : composants pour une nobox libre et acentrée

Entre-temps, je lui ai rajouté de la mémoire : 4 Go de RAM pour être tranquille.

Et si elle est sage, elle aura peut-être droit à un SSD (j’hésite cependant, les prix sont encore délirants).

Description de la « liaison »

Avant… Oui, avant, j’étais chez Orange : pourquoi je quitte Orange et son IP dynamique

Mais, comme dirait certains, « J’ai changé ». (#EPIC FAIL)

Et depuis, c’est que du bonheur : IP fixe, port 25 « libéré », débit stable, tarif divisé par 2.

Description de la « QOS »

Le ping est prioritaire. Ben vi, ça rend les gens heureux, les cheveux soyeux et le kiki tout dur.

Juste après vient le service DNS : ce sont de petites requêtes alors autant les privilégier (et shunter le trafic restant s’il le faut).

En résumé, je peux télécharger comme un goret (des vidéos de chatons) et seeder en P2P comme un porc (du contenu sous licence CC), le trafic DNS est, et sera toujours, prioritaire, donc forcément stable.

Je n’ai pas terminé ma série de billets sur la QOS mais, tests à l’appui, ça marche. 😉

Lire la suite…


Proxmox 2/3 : outil de sauvegarde incrémentale pour containers OpenVZ

EDIT 1 : Après plusieurs mois de gestation le projet est désormais disponible ici :

La doc est sera bientôt disponible, ainsi qu’un forum pour les retours d’expérience.

EDIT 2 : Openvz-diff-backups fonctionne avec Debian 6/7 + OpenVZ et/ou Proxmox 2 & 3.

EDIT 3 : L’outil de backup ayant énormément évolué (euphémisme), ce billet est complètement « outdated ».

« Boarf… Un bon gros tar.gz de 137 Go, ça n’a jamais tué personne… » (Patrice B., réfractaire aux backups journaliers)

Avant, j’utilisais vzdump et mes cheveux backups étaient gras

Faire des sauvegardes c’est bien, les répliquer sur un serveur distant c’est mieux.

Sauf que, si vous vous amusez chaque jour à transférer les archives générés par vzdump, à mon avis ça va mal se mettre au niveau de la bande passante (sans parler de l’espace disque nécessaire pour conserver un historique décent).

Pour l’instant ma nobox ne contient que 50 Go de données (libres, toussa…) mais vu l’upload tout moisi que l’on a derrière une misérable ligne ADSL et le fait que je voulais quand même disposer d’une sauvegarde distante et journalière, fallait bien trouver autre chose que le transfert des tar.gz classiques.

Maintenant, j’utilise rsync et mon delta est resplendissant

Bon, ok, même si dans la pratique cette affirmation est globalement vraie (si, si…), il y a certains cas « particuliers » où cela ne se passe pas aussi bien. (Ben tiens ! On s’en serait pas douté…)

A chaque appel du script de sauvegarde, celui-ci va faire sa tambouille puis, afin de créer un historique, stocker dans un nouveau répertoire les différences par rapport à l’ancien backup.

L’archivage se fait à l’aide de liens hard en utilisant la directive « –link-dest » de rsync. Le principal avantage de cette méthode, contrairement à « cp -al », est que les changements de propriétaires ou de permissions sont pris en en compte sans impacter rétroactivement les anciennes sauvegardes.

Donc, en français dans le texte, cela signifie que, dès qu’une modification est détectée sur un fichier (taille, données, permissions, etc), rsync ne va pas créer un hard link lors de l’archivage mais tout simplement copier intégralement le fichier modifié.

Étant donné qu’il s’agit du comportement attendu et souhaité, jusqu’ici tout va bien.

Lire la suite…


Proxmox 2 : compilation d’un kernel OpenVZ à partir des sources

Comme dirait Luke : même pas mal ! (d’abord…)

A part occuper (un peu) les geeks et frimer (bêtement) sur IRC, ça sert à quoi ?

Si comme bibi vous avez soumis un bug auprès des développeurs d’OpenVZ, la première chose qu’ils vont vous demander c’est, justement, de reproduire ledit bug avec un kernel OpenVZ « stock ». Donc là, forcément, pas moyen, va falloir s’y coller.

Sinon, et c’est ce qui m’intéressait le plus, en ayant accès aux sources il devient alors possible de modifier certains modules du noyau car, croyez le ou non, certains paramètres utiles sont hardcoded. Non seulement c’est mal mais en plus ça ennuie tout le monde.

Bref, je voulais juste augmenter la taille de la file d’attente du scheduler SFQ (Stochastic Fair Queue) mais pour cela, il est nécessaire de modifier directement les valeurs dans le code source.

Étape 1/10 : récupérer le « Source RPM » qui va bien même qu’il y a tout dedans

Pour cela, direction l’espace de download d’OpenVZ : http://download.openvz.org/kernel/

La branche stable actuelle est la « rhel6-2.6.32 » donc z’allions fouiller à l’intérieur et nous poser sagement dans le répertoire « current ». Là, parmi les différents RPM, il y en a un qui contient le mot « src » (flash, flash…) et il est facile à trouver vu que c’est le plus gros.

Ensuite, tant qu’on y est, nous allons récupérer la config du noyau adéquate dans le sous répertoire « configs ». Deux choix possibles en fonction de votre processeur,  32 ou 64 bits.

Mais, j’aperçois quelques feignasses dans le fond, alors voici le lien direct : lien-magique-toujours-à-jour-vers-le-dernier-noyau-openvz

Bon, ok, elle est nulle mais comme le lien change à chaque mise à jour, il est plus sûr de chercher le bon fichier soi-même.

Lire la suite…