Migration du blog sur github

28/05/2014, 20:29:31

Finalement le temps ne me permettant plus d’administrer mon serveur dédié comme il faut, j’ai décidé de l’abondonner et transférer mes services ailleurs. Pour le blog et le wiki, j’ai choisi de faire un site/blog github avec jekyll, vu que c’est tout prémaché.

Sur github, l’hébergement c’est du fichier html, donc statique, on a plusieurs possibilités pour créer un site :

L’avantage de pelican est dans sa capacité à importer le contenu d’un blog dotclear, et transformer la syntaxe en markdown. Le markdown semble avoir la cote, beaucoup de générateurs de site l’utilisent, d’ailleurs je m’y suis mis.

Comme j’avais déjà fait le site de pitrery avec jekyll sur github, la migration fut plus facile, une fois le dotclear migré grâce à pelican.

Au final, j’ai maintenant un truc tout simple avec un thème bootstrap, et le jekyll de base de github est largement suffisant.

La bonne découverte fut pandoc, un super convertisseur de format de document texte, qui va me servir pour la migration du dokuwiki à base de :

pandoc -f html -t markdown http://wiki.orgrim.net/page?do=export_html

Le mot de la fin, ça demande un peu de boulot de nettoyage manuel, mais vu le nombre impressionant de posts que j’ai pu produire en quatre ans, c’était pas trop méchant.

modular-xorg, radeon et pas de KMS

23/08/2013, 19:10:00

Il y avait un moment que je n’avais pas touché à NetBSD et donc mis à jour mon lappy avec du pkg frais. Entre temps, la version de X.org modular, donc issue de pkgsrc, est revenue en 2012, avec son lot de drivers mis à jour. Le drivers xf86-video-ati, est passé en version 7.1.0, sauf qu’il fonctionne uniquement en KMS (Kernel Mode Setting), chose qu’on n’a pas encore dans notre kernel.

Il faut donc la dernière version de la branche 6 du driver, qui contient encore le support UMS, disponible dans le paquet x11/xf86-video-ati6, qui porte le même nom de package, bizarrement. Tout ça est suivi dans le PR 47935.

Pour que le serveur X trouve le device avec ce driver, j’ai du virer la ligne BusID dans la section Device du xorg.conf.

pitrery - Faciliter la restauration PITR de PostgreSQL

05/06/2013, 08:38:00

pitrery est un ensemble de scripts pour gérer plus facilement la sauvegarde à chaud et la restauration PITR dans PostgreSQL.

Il s’agit de simples scripts bash, qui n’imposent pas autant de dépendances qu’un pgbarman et se concentre uniquement sur le PITR, là où des outils tels que OmniPITR, PITRTools semblent vouloir gérer également la réplication. L’objectif de pitrery est de pouvoir facilement restaurer.

La version 1.3 apporte des nouveauté intéressantes :

La documentation est à jour sur https://dalibo.github.io/pitrery/documentation.html

Le code est disponible sur https://github.com/dalibo/pitrery/

Les versions sont disponibles sur https://dl.dalibo.com/public/pitrery/

Les idées pour la prochaine version sont, en vrac :

Un bulk build par jour dans un screen

10/05/2013, 12:40:00

Mes packages NetBSD sont préparés par pbulk, qui tourne en continu grâce au script pbulk-builder.

J’avais prévu avec l’option -1 de lui éviter d’entrer dans une boucle infinie, et j’ai pas eu tort. En effet, la majorité des tours ne fait que mettre à jour l’arbre pkgsrc, résoudre les dépendances, sans rien compiler de nouveau. La première solution que j’ai trouvé a été de créer une règle sieve pour ne pas recevoir des dizaines de mails de rapport de bulk inutiles, en les plaçant dans un répertoire séparé…

N’ayant jamais pris le temps d’utiliser cette fameuse option one-shot, j’ai décidé de mettre le lancement du bulk dans la crontab, sauf que c’est long et qu’il vaut mieux suivre ça avec screen. C’est possible grâce aux options -d et -m (avec -S pour mettre un titre) :

0 23 * * * /usr/pkg/bin/screen -dmS bulk -c /root/.screenrc /usr/pkg/bin/bash ~orgrim/nb-utils/pkgsrc/pbulk-builder -c -1 /data/pbulk

On peut alors attacher le screen quand le bulk tourne.

PS: merci au fans de tmux de passer sur le chan #netbsdfr sur Freenode pour me dire comment faire pareil avec tmux :)

Oups... des tablespaces imbriqués

06/04/2013, 07:10:00

Imbriquer des tablespaces n’a pas vraiment de sens dans PostgreSQL surtout si on veut se prendre la tête avec des montages dans tous les sens… Mais bon c’est permis, car PostgreSQL utilise uniquement les liens symboliques dans $PGDATA/pg_tblspc pour accéder au contenu des tablespaces.

Si on veut savoir ce qu’il en est voici une requête qui montre ça.

Pour PostgreSQL <= 9.1 :

SELECT f.oid, f.spcname AS name, f.spclocation AS location,
  f.spclocation ~ ('^' || (SELECT setting FROM pg_settings
                           WHERE name = 'data_directory')) AS inside_pgdata,
  (SELECT o.spcname
   FROM pg_tablespace o
   WHERE f.spclocation ~ ('^' || o.spclocation || '/')
     AND o.spcname NOT IN ('pg_default', 'pg_global')
   ORDER BY o.spclocation DESC LIMIT 1) AS parent,
  (SELECT o.spclocation   FROM pg_tablespace o
   WHERE f.spclocation ~ ('^' || o.spclocation || '/')
     AND o.spcname NOT IN ('pg_default', 'pg_global')
   ORDER BY o.spclocation DESC LIMIT 1) AS parent_location
FROM pg_tablespace f
WHERE f.spcname NOT IN ('pg_default', 'pg_global');

Pour PostgreSQL >= 9.2, la colonne spcname de pg_tablespace a été remplacée par la fonction pg_tablespace_location() :

SELECT f.oid, f.spcname AS name, pg_tablespace_location(f.oid) AS location,
  pg_tablespace_location(f.oid) ~ ('^' || (SELECT setting FROM pg_settings
                                    WHERE name = 'data_directory')) AS inside_pgdata,
  (SELECT o.spcname
   FROM pg_tablespace o
   WHERE pg_tablespace_location(f.oid) ~ ('^' || pg_tablespace_location(o.oid) || '/')
     AND o.spcname NOT IN ('pg_default', 'pg_global')
   ORDER BY pg_tablespace_location(o.oid) DESC LIMIT 1) AS parent,
  (SELECT pg_tablespace_location(o.oid)
   FROM pg_tablespace o
   WHERE pg_tablespace_location(f.oid) ~ ('^' || pg_tablespace_location(o.oid) || '/')
     AND o.spcname NOT IN ('pg_default', 'pg_global')
   ORDER BY pg_tablespace_location(o.oid) DESC LIMIT 1) AS parent_location
FROM pg_tablespace f
WHERE f.spcname NOT IN ('pg_default', 'pg_global');

On obtient par exemple :

  oid  |   name   |                       location                       | inside_pgdata | parent  |                 parent_location                 
-------+----------+------------------------------------------------------+---------------+---------+-------------------------------------------------
 16399 | inside   | /home/pgsql/postgresql-9.0.10/data/inside            | t             |         | 
 16400 | outside  | /home/pgsql/postgresql-9.0.10/outside                | f             |         | 
 16414 | imbrique | /home/pgsql/postgresql-9.0.10/outside/imbrique       | f             | outside | /home/pgsql/postgresql-9.0.10/outside
 16415 | rimb     | /home/pgsql/postgresql-9.0.10/outside/rimb           | f             | outside | /home/pgsql/postgresql-9.0.10/outside
 16416 | rimbimb  | /home/pgsql/postgresql-9.0.10/outside/rimb/imb       | f             | rimb    | /home/pgsql/postgresql-9.0.10/outside/rimb
 16417 | deuimb   | /home/pgsql/postgresql-9.0.10/outside/rimb/truc/2imb | f             | truc    | /home/pgsql/postgresql-9.0.10/outside/rimb/truc
 16418 | truc     | /home/pgsql/postgresql-9.0.10/outside/rimb/truc      | f             | rimb    | /home/pgsql/postgresql-9.0.10/outside/rimb
(7 rows)

Pour bien gérer ses tablespaces, l’idéal est de faire un répertoire dédié au même niveau que $PGDATA, et de créer les tablespaces dedans, avec un tablespace par répertoire sur un seul niveau :

 /home/pgsql/postgresql-9.2.4
├── data
└── tblspc
    ├── tbs_1
    ├── tbs_2
    ├── ...
    └── tbs_n

C’est plus propre et on voit tout de suite l’utilisation disque avec df : parce qu’on met des disques différents derrière, bien entendu… :)