2010/06/17

One-liner again

Je voulais pouvoir récupérer la liste complète des ports outdated de FreeBSD, pour ça nous disposons de portscout mais ce dernier ne présente que la liste par mainteneur, or je voulais la liste complète... mais portscout propose un flux rss qui, si il est appelé sans le paramètre ?m=, liste tous les ports outdated (attention le fichier est gros).

J'ai donc pris quelques armes :

le résultat :

feed=(${(f)"$(fetch -q -o - http://portscout.org/rss/rss.cgi)"}) && for item ({1..$(xml sel -t -v "count(//item)" =( print -lr $feed))}) { xml sel -t -v //item[$item]/title =( print -lr $feed) | html2text } > portscout.txt

avec cette ligne je récupère un fichier portscout.txt donc le contenu est :

categorie/port: ancienne_version -> nouvelle_version

tout simplement

UPDATE :

Voici une version plus zshienne (plus besoin de xmlstarlet ni de html2text) en revanche elle est moins souple mais plus rapide :

feed=(${(f)"$(fetch -q -o - http://portscout.org/rss/rss.cgi)"}) && for item ({0..$#feed}) { [[ -z ${feed[$item]:#\<item\>*} ]] && { print ${${${${feed[$item + 1]}/&#x3E;/>}/\<\/title\>/}/\<title\>} } } > portscout.txt

2010/06/03

FS partagé et répliqué

Je suis un grand utilisateur de proxmox, j'ai beaucoup de machine virtuelles OpenVZ et kvm en mode cluster sur mes proxmox.

Pour diverses raisons, je souhaite que les machines kvm utilisent des disques sous la forme de fichiers plats et non des volumes LVM. Mais je souhaites aussi pouvoir migrer rapidement les VMs d'un noeud du cluster à un autre. Pour cela j'utilise drbd en mode multimaster pour répliquer un volume lvm entre les noeuds du cluster, et ocfs2 pour disposer d'un système de fichier partagé.

Dans l'exemple suivant nous auront deux noeuds : virt01 et virt02.

Le tuto suivant a été fait sur un proxmox 1.5 avec la mise à jour du 17 mai 2010, afin de disposer de OpenVZ et de kvm le noyau utilisé est proxmox-2.6.24-11

virt01 et virt02 disposent chacun d'une interface d'admin dédiée :

Le volume partagé par les deux sera nommé "shared".

Commençons par le créer :

virt01$ lvcreate --name shared --size 800G vg
virt02$ lvcreate --name shared --size 800G vg

DRBD

Installons les outils drbd :

virt01$ apt-get install drbd8-utils
virt02$ apt-get install drbd8-utils

Sur les deux noeuds créons le fichier /etc/drbd.conf avec le contenu suivant :

global { usage-count no; }
common { syncer { rate 30 M; }}
resource r0 {
	protocol C;
	startup {
		wfc-timeout 15;
		degr-wfc-timeout 60;
		become-primary-on both;
	}
	net {
		cram-hmac-alg sha1;
		shared-secret "mon-secret";
		allow-two-primaries;
		after-sb-0pri discard-zero-changes;
		after-sb-1pri discard-secondary;
		after-sb-2pri disconnect;
	}
	on virt01 {
		device /dev/drbd0;
		disk /dev/vg/shared;
		address 10.56.1.1:7788;
		meta-disk internal;
	}
	on virt02 {
		device /dev/drbd0;
		disk /dev/vg/shared;
		address 10.56.1.2:7788;
		meta-disk internal;
	}
}

Démarrons drbd sur les deux noeuds :

virt01$ /etc/init.d/drbd start
virt02$ /etc/init.d/drbd start

Puis on crée le "device metadata" (si quelqu'un a un nom français plus parlant ? :)) :

virt01$ drbdadm create-md r0
virt01$ drbdadm up r0
virt02$ drbdadm create-md r0
virt02$ drbdadm up r0

En regardant le status (/proc/drbd) sur le deux, ça devrait maintenant ressemble a ça :

virt01$ cat /proc/drbd
version: 8.3.2 (api:88/proto:86-90)
GIT-hash: dd7985327f146f33b86d4bff5ca8c94234ce840e build by root@oahu, 2010-05-14 09:29:27
 0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r----
     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:2096348

tout est prêt il faut maintenant faire la première synchronisation, sur Un seul des noeud :

virt01$ drbdadm -- --overwrite-data-of-peer primary r0

il faut maintenant attendre que la synchronisation soit terminée (le fichier /proc/drbd permet de le voir)

Une fois la synchronisation terminée il faut redémarrer drbd pour s'assurer qu'il passe bien en mode primary/primary :

virt01$ /etc/init.d/drbd stop
virt02$ /etc/init.d/drbd stop
virt01$ /etc/init.d/drbd start
virt02$ /etc/init.d/drbd start

OCFS2

Passons maintenant à l'OCFS2 :

Si il n'est pas déjà installé, il faut le faire :

virt01$ apt-get install ocfs2-tools
virt02$ apt-get install ocfs2-tools

Sur les deux membres du cluster il faut créer le fichier suivant : /etc/ocfs2/cluster.conf

node:
	ip_port = 7777
	ip_address = 10.56.1.1
	number = 0
	name = virt01
	cluster = ocfs2

node:
	ip_port = 7777
	ip_address = 10.56.1.2
	number = 1
	name = virt02
	cluster = ocfs2

cluster:
	node_count = 2
	name = ocfs2

sur l'un des noeud uniquement :

virt01$ mkfs.ocfs2 /dev/drbd0

Vérifier que la réplication se passe bien :

virt01$ watch cat /proc/drbd

Attention: la réplication peut être très longue !!!

il ne reste plus qu'à ajouter dans la fstab le tout sur les deux noeuds :

/dev/drbd0 /shared ocfs2 _netdev 0 0

Je vous laisse vous débrouiller seul pour la suite (ie rajouter ce stockage dans proxmox : c'est du clika suivant dans l'interface web).

Je peux maintenant, pour toutes les VMs crées dans ce FS, les basculer entre les noeuds du cluster à chaud et de manière quasi instantanée, convi non ?

2010/06/01

Vous reprendrez bien un peu de lourd ?

DISCLAIMER : Ceci est un post à haute teneur en troll.

Redmine est de loin le meilleur outil web multiprojet pour le développement que j'ai pu utiliser en opensource. De plus il a l'avantage de bien s'interfacer avec mercurial, git et autres (D)VCS, parfait non ? Oui mais voila redmine pose plusieurs soucis :

Si en plus on rajoute les contraintes suivantes :

Et bien déployer du ruby deviens tout de suite peu évident. Je précise que j'ai une faible connaissance du ruby et de son écosystème, ce qui n'aide pas. Or j'ai bien l'impression que c'est un sujet qu'il faut suivre de près si l'on si l'on veut pouvoir réellement l'utiliser efficacement en production.

Je ne vais tout de même pas m'arrêter là, cet outil répond au besoin, il faut donc trouver un moyen de l'installer et répondant aux contraintes.

C'est là que je tombe sur jruby, je me renseigne dessus et apprend que des applis rails de type redmine peuvent tourner sur des serveurs d'application java de type tomcat ou jetty par exemple et que les performances seraient plutôt bonnes. C'est peut être une bonne piste pour les performances, mais il reste la problématique de la reproductibilité de l'installation sur des machines sans accès à Internet.

Un peu de recherche et je tombe sur warbler ce petit outil me permettrai de pouvoir fabriquer un war (donc un package déployable sur un serveur d'application java) embarquant tout le nécessaire du monde ruby, plutot pas mal.

Je me lance donc, je prend une machine ChiantOS (oui la pire des contraintes c'est que ça doit tourner sur du chiantos :(), j'installe l'openjdk et j'installe jruby.

j'ai plus qu'à installer tout le nécessaire pour redmine :

$gem install rails -v=2.3.5
$gem install jruby-openssl warbler activerecord-jdbcpostgresql-adapter

Je fais une installation classique de redmine (je choisi la 0.9.4 là dernière au moment de ce post) je configue tout normalement, j'applique le patch pour le support de jruby 1.5.0

Attention dans le fichier config/database.yml il faut bien faire attention de précéder le nom du driver par jdbc :

adapter: postgresql devient adapter: jdbcpostgresql

Dans le répertoire redmine, taper :

$warble config

il faut maintenant éditer le fichier config/warble.rb générer :

il suffit maintenant de générer le fichier war :

$warble

il doit avoir créé un fichier redmine.war qui embarque tout le nécessaire, il ne reste plus qu'à le déployer dans votre serveur d'application java de choix.

Dans mon cas j'ai choisi jetty.

Le résultat est surprenant, sur la même machine, redmine semble être boosté aux amphétamines et la consommation mémoire toujours élevée est quand même très largement réduite, par rapport au ruby classique.

2010/04/30

Permission de sortie : 30 minutes

Le Besoin

Les ingrédients

Recette

PF

scrub in all
set skip on lo0
pass out all
block in all
table <allowips> persist
pass in quick inet proto tcp port https keep state
pass in quick inet proto tcp from <allowips> to port 8080 keep state

Voila tout simple tout beau, en gros on bloque tout sauf le https. On autorise toutes les ips qui sont contenu dans la table allowips

Problème : comme rajouter des adresses IPs dans la table allowips et surtout comment les supprimer au bout de 30 minutes

CGI shell

Nous créons donc un script cgi qui après une authentification "ultra basique" ajoutera l'adresse IP du demandeur dans la table allowips et schedulera la supression de celle ci

#!/bin/sh
if [ "$REQUEST_METHOD" = "POST" ];then
	query="dd count=$CONTENT_LENGTH bs=1 2> /dev/null"
else
	echo "Bad request"
	return
fi

# Ceci n'est pas super clean, il y a mieux à faire mais flemme :)
eval $query

if [ -z $passwd ]; then
	echo "Bad request"
	return
fi

decodedpasswd=$(echo $passwd | awk '"'BEGIN{for(i=0;i<10;i++)hex[i]=i;hex["A"]=hex["a"]=10;hex["B"]=hex["b"]=11;hex["C"]=hex["c"]=12;hex["D"]=hex["d"]=13;hex["E"]=hex["e"]=14;hex["F"]=hex["f"]=15;}{gsub(/\+/," ");i=$0;while(match(i,/%../)){;if(RSTART>1);printf"%s",substr(i,1,RSTART-1);printf"%c",hex[substr(i,RSTART+1,1)]*16+hex[substr(i,RSTART+2,1)];i=substr(i,RSTART+RLENGTH);}print i;}'"')

if [ -f /usr/local/etc/authpasswd ]; then
	read encryptpasswd < /usr/local/etc/authpasswd
else
	echo "No password file"
	return
fi

cryptpasswd=$(echo $decodedpasswd | /sbin/sha256)
if [ "$cryptpasswd" = "$encryptpasswd" ]; then
	/usr/local/bin/sudo /sbin/pfctl -t allowips -T add $REMOTE_ADDR
	echo "/usr/local/bin/sudo /sbin/pfctl -t allowips -T delete $REMOTE_ADDR" | /usr/bin/at now + 30 minute
	echo "Acces granted for 30 minutes"
else
	echo "Acces refused"
fi

C'est pas terrible mais suffisant : le mot de passe de référence est stocké dans /usr/local/etc/authpasswd et est en sha256

Il faut maintenant autoriser l'utilisateur www à pouvoir utiliser at :

$ echo "www" > /var/at/at.allow

Ensuite rajouter les entrées sudo qui vont bien dans /usr/local/etc/sudoers

%www	ALL=NOPASSWD:	/sbin/pfctl -t allowips *

Il vous reste à faire un fichier html qui appelle le script CGI via la méthode POST en lui fournissant le mot de passe donné dans une variable "passwd". Mettre le tout à dispo via un serveur web supportant le CGI.

Après on me demande pourquoi j'aime les Unix...

EDIT : alors on me dit dans l'oreillette que pfctl -t allowips -T expire 1800 lancé toutes les minutes dans une crontab ferait le même boulot mais je préfère ma solution à coup de at puisque at est géré par cron sous FreeBSD et que ce n'est exécuté qu'au besoin et non toutes les minutes

2010/02/27

Emprisonner une debian dans un FreeBSD

Parfois on a besoin de tester des choses sous linux, parfois on a besoin d'utiliser des applications linux-only, où pour tout un tas d'autre raison on a besoin de faire tourner un linux.

Pour ça c'est vrai que l'on peut virtualiser dans un virtualbox ou un qemu, c'est bien mais c'est quand même coûteux en terme de ressources pour le host.

Sous FreeBSD nous disposons du linuxulator c'est la couche d'emulation permettant de faire tourner des applications Linux sous FreeBSD.

Ni une ni deux je me dis qu'il est possible de faire de petites choses sympathiques avec ça : une jail linux-only.

Il faut d'abord préparer le terrain :

# mkdir /home/jails/debian
# mkdir /home/jails/debian/dev
# mkdir /home/jails/debian/proc
# mkdir /home/jails/debian/sys
# kldload linux
# kldload linprocfs
# kldload linsysfs
# kldload lindev
# mount -t devfs none /home/jails/debian/dev
# mount -t linprocfs none /home/jails/debian/proc
# mount -t linsysfs none /home/jails/debian/sys

Nous allons donc utiliser /home/jails/debian comme racine de la debian que nous allons installer.

Nous chargeons tous les pilotes nécessaires (notez que lindev est apparu en FreeBSD 9 et a été MFCed en 8-STABLE il n'est absolument pas obligatoire)

On pourrait faire l'installation avec debootstrap, mais comme je suis un feignant j'ai préféré utiliser un template openvz tout fait :

# fetch http://download.openvz.org/template/precreated/debian-5.0-x86.tar.gz

Puis le depacker dans ma jail :

# tar xvfp debian-5.0-x86.tar.gz -C debian --exclude dev* --exclude proc* --exclude sys*

Pour démarrer correctement la jail il faut qu'au minimum un service tourne dans la jail (je n'ai pas réussit à faire une jail linux-only persistente). Par défaut le script de démarrage des jails essaye de lancer /etc/rc que nous allons créer et de lancer /etc/rc.shutdown pour s'arrêter.

# echo "/etc/init.d/cron start" > /home/jails/debian/etc/rc
# chmod 755 /home/jails/debian/etc/rc
# echo "/etc/init.d/cron stop" > /home/jails/debian/etc/rc.shutdown
# chmod 755 /home/jails/debian/etc/rc.shutdown

dans /etc/rc.conf on règle le lancement de la jail

jail_debian_rootdir=/home/jails/debian
jail_debian_hostname="debian"
jail_debian_ip="192.168.1.3"
jail_debian_interface="nfe0"
jail_debian_devfs_enable="YES"
jail_debian_devfs_ruleset="devfsrules_jail"
jail_debian_flags="-n debian"

on démarre la jail :

# /etc/rc.d/jail start debian

et magie :

#jls
   JID  IP Address      Hostname                      Path
    15  192.168.1.3     debian                        /home/jails/debian
#jexec debian uname -a
Linux debian 2.6.16 FreeBSD 8.0-STABLE #3: Sun Jan 10 20:39:38 CET 2010 i686 GNU/Linux
#jexec debian cat /etc/debian_version
5.0.4

Vous voila avec une belle debian emprisonnée dans un freebsd.

Attention, tout ne fonctionne pas parfaitement : sysklogd ne marche pas à cause des accès /dev par exemple, mais c'est 99% fonctionnel quand même.

2010/02/25

Une jail 32bits sur un host 64bits

J'ai un eeepc 1000H qui fonctionne à merveille sous FreeBSD tout y est reconnu, juste un petite compilation maison pour le wifi, bref c'est pas le sujet de ce post.

Le truc c'est qu'un eeepc bah c'est lent pour la compilation, le binaire fournis par freebsd ne sont pas vraiment compilés avec les options que je souhaite, mais il s'avère que j'ai un beau Q6660 qui lui est plutôt très bien pour la compilation.

D'un autre côté je mijote toujours ma version FreeBSD de pkgin, du coup je me dis pourquoi pas compiler sur mon Q6600 les packages binaires depuis les ports et les installer via pkgin sur le 1000H, bah oui en voila une idée qu'elle est bonne.

De ce pas je me configure une jail 32bits (de la doc pour ça il y en a partout je vous laisse chercher :)) je me connecte dessus :

$ jexec eeepc /bin/sh

Je commence à compiler des ports, mais rapidement ça brotch de partout. Normal il me compile la moitié des choses en pensant avoir affaire à un amd64 :

$ uname -a
FreeBSD eeepc 8.0-STABLE FreeBSD 8.0-STABLE #3: Sun Jan 10 20:39:38 CET 2010     root@galway.lan:/usr/obj/usr/src/sys/GALWAY  amd64

C'est pas du tout, mais alors pas du tout la cible que je cherche, moi je veux build de l'i386, en suivant la branche RELEASE du kernel (pour les drivers venant des ports).

Réglons les problèmes un par un.

Tout d'abord faisons fonctionner freebsd-update afin de pouvoir avoir le dernier niveau de patch de la branche RELEASE

$ freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 8.0-STABLE from update5.FreeBSD.org... failed.
Fetching metadata signature for 8.0-STABLE from update4.FreeBSD.org... failed.
Fetching metadata signature for 8.0-STABLE from update2.FreeBSD.org... failed.
No mirrors remaining, giving up.

C'est pas gagné pourtant j'ai bien installé un jail 8.0-RELEASE. Il me faut donc le lui faire savoir. Pour cela, il suffit de modifier le /etc/login.conf de la jail et remplacer :

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\

par

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,UNAME_m=i386,UNAME_p=i386,UNAME_r=8.0-RELEASE-p2,OSVERSION=800107,UNAME_v=FreeBSD 8.0-RELEASE-p2:\

Une recontruction de la db est nécessaire :

$ cap_mkdb /etc/login.conf

On peut maintenant quitter l'environnement et se reconnecter à la jail, par contre pour forcer la prise en compte de login.conf il faut forcer l'utilisateur dans la ligne jexec du coup :

$ jexec -U root eeepc /bin/sh
$ uname -a
FreeBSD eeepc 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 i386

Parfait, maintenant relancez freebsd-update vous verrez qu'il fonctionne correctement.

Second problème les ports, là il en faut un peu plus.

En effet les ports vont chercher l'architecture via le sysctl :

Là notre astuce ne fonctionne plus, de plus il est impossible de les changer depuis une jail. Du coup en cherchant un peu dans /usr/ports/Mk/*.mk on se rend vite compte que l'on peut contourner le problème via /etc/make.conf. Pour ça, il suffit de rajourer les variables suivantes :

MACHINE=i386
MACHINE_ARCH=i386

Désormais je peux tout compiler tranquilement depuis ma jail et utiliser les packages sous mon eeepc. Afin de gagner en simplicité j'utilise ma version maison de pkgin (oui un jour elle sera intégrée upstream), en générant un INDEX.bz2 de la liste de mes packages et en mettant ça à dispo sur un serveur web par exemple

PS: pour générer l'INDEX.bz2, j'ai fait un petit prog en C: pkg_index, il n'est pas aussi complet que l'INDEX.bz2 normal mais beaucoup plus simple à utiliser et suffisant pour pkgin.

$ ./pkg_index /usr/ports/packages

PS2: pour créer mes packages j'utilise portmaster c'est moins lourd qu'une tinderbox

$ portmaster -ag

2010/02/10

Cgit et autres cgi dans nginx

Jusqu'a présent pour avoir cgit je passais pas par la méthode thttpd.

Ça ne marchait pas trop mal, mais bon ça ne me plaisait pas trop de faire tourner un serveur web complet derrière mon nginx

Et puis pour je ne sais plus quelle raison, j'étais obligé d'utiliser un virtual-root=/cgit/ qui ne me plaisait pas beaucoup plus.

Aujourd'hui dans mes recherches, je tombe sur : fcgiwrap, je récupère donc le tout :

$ git clone git://github.com/gnosek/fcgiwrap.git

Je modifie le Makefile pour y ajouter -I/usr/local/include et -I/usr/local/lib afin que gcc puisse trouver fcgi comme il faut. Et j'install le tout :

$ install -m 755 -o root -g wheel fcgiwrap /usr/local/bin

pour lancer les fastcgi, j'utilise spawn-fcgi, et pour les avoir au démarrage ma méthode est un peu gruik mais ça marche :

$ cd /usr/local/etc/rc.d
$ sed -e 's/fcgi/fcgiwrap/g' spawn-fcgi > spawn-fcgiwrap-tmp
$ sed -e 's|/usr/local/bin/spawn-fcgiwrap|/usr/local/bin/spawn-fcgi|' spawn-fcgiwrap-tmp > spawn-fcgiwrap
$ chmod 555 spawn-fcgiwrap
$ rm spawn-fcgiwrap-tmp

Puis dans /etc/rc.conf

spawn-fcgiwrap_enable="YES"
spawn_fcgiwrap_app="/usr/local/bin/fcgiwrap"
spawn_fcgiwrap_bindsocket="/tmp/fcgiwrap.sock"

Enfin pour finir je configure comme suis le nginx :

server {
	access_log /var/log/nginx/git.access.log main;
	server_name git.*;
	location / {
		rewrite ^/(.*)$ /cgit.cgi/$1 break;
		include fastcgi_params;
		root /usr/local/www/cgit;
		fastcgi_param SCRIPT_NAME /cgit.cgi;
		fastcgi_pass unix:/tmp/fcgiwrap.sock;
	}

	location ~ \.(png|css)$ {
		root /usr/local/www/cgit;
	}
}

Dans le /usr/local/etc/cgitrc il faut mettre : virtual-root=/

Le résultat est

2009/11/25

Convertir l'arbre CVS des ports en git (round 2)

Il y a quelques mois je cherchais tranquillement à convertir l'arbre cvs des ports FreeBSD en arbre git.

Ça avait bien marché, mais il y avait deux inconvénients majeurs :

Et puis hier, gaston me montre ça nonchalamment, puis ça, bon j'y crois pas trop mais je me lance

Récupération du CVSROOT

Créer le fichier de config suivant pour csup

*default host=cvsup.free.org
*default base=/var/db
*default prefix=/usr/portsdev/cvsroot
*default release=cvs
*default delete use-rel-suffix

*default compress

ports-all

Puis récupérer le cvsroot :

$ csup cvsroot-supfile

Installation des pré-requis

Installation des packages

$ make -C /usr/ports/devel/mercurial install clean
$ make -C /usr/ports/lang/ruby18 install clean
$ make -C /usr/ports/textproc/ruby-iconv install clean
$ make -C /usr/ports/devel/ruby-rbtree install clean

Installation de rcsparse

$ hg clone http://ww2.fs.ei.tum.de/~corecode/hg/rcsparse
$ cd rcsparse 
$ ruby extconf.rb
$ make
$ make site-install

Récupération des sources de fromcvs

$ hg clone http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs

Conversion du CVSROOT en git

Préparation du répertoire de destination

$ mkdir /usr/portsdev/freebsd-ports.git
$ cd /usr/portsdev/freebsd-ports.git
$ git init --bare

Conversion

$ cd /usr/portsdev/fromcvs
$ ruby togit.rb /usr/portsdev/cvsroot ports /usr/portsdev/freebsd-ports.git

2h30 (oui seulement 2h30 !!! ) après c'était fait

Le répertoire de destination fait 720Mo.

Repack du rep

$ cd /usr/portsdev/freebsd-ports.git && git repack -a -f -d

Ce coup ci ça ne dure que 5 petites minutes et le répertoire ne fait plus que 410Mo

Mise à jour de l'arbre git

Comme fromcvs fonctionne de manière incrémentale, il faudra juste relancer le csup de temps en temps et relancer la commande togit.rb pour faire très rapidement les mises à jours

Bilan du round 2

fromcvs n'est pas parfait (il n'importe pas encore les tags) en revanche il a été capable de me conserver plus de branches que ce que parsecvs avait fait, en plus il est beaucoup, beaucoup, beaucoup plus rapide :

Pour les ports la conversion passe de 17h30 à 2h30 le repack passant lui de 28h50 à 5min, la taille du repos avant repack de 4go à 710Mo.

Par contre attention togit.rb est un très gros consommateur de RAM : il a bouffé mes 4Go de RAM plus 3Go de SWAP pour convertir les ports !!!

La mise à jour fonctionne parfaitement. Autant dire que je garde cette méthode. J'ai bien essayé de modifier fromcvs afin qu'il puisse importer les tags, mais je n'y suis pas arrivé, le ruby ne m'aime définitivement pas.

2009/11/17

Du flan oui mais convi

De plus en plus dans mon boulot je dois faire du flan, du corpo flan même je dirai, le problème c'est qu'il faut pour cela utiliser OpenOffice... Et OpenOffice bah c'est très très lourd, c'est bloat, et quand je rédige, je ne vois pas pourquoi j'utiliserai autre chose que mon convi vim.

Heureusement pandoc existe, il s'agit d'un convertisseur de document qui gère entre autre en entrée le format markdown et gère entre autre en sortie le format odt.

Je tente le coup, je rédige un début de document en markdown avec mon plus beau vim et je le converti en odt.

$ pandoc -f markdown -t conviflan.txt -o corpoflan.odt

Le résultat est presque parfait, mon document OpenOffice respecte différente hiérarchie de style. Presque parfait parce qu'il faut que j'y applique le style de la boite à ce document, quand même. Pour cela rien de plus simple.

On extrait le style d'un document corpoflan déjà existant :

$ unzip corpoflan-modele.odt styles.xml

Puis on l'insère dans le document générer :

$ zip corpoflan.odt styles.xml

Et voilà un beau document rédigé en toute légèreté qui respecte la mise en forme corpo.

Voici une autre petite astuce que j'ai trouvé pour rédiger des diagrammes simplement :

J'utilise pgf/tikz parce que ça fait très simplement de très belles choses corpo ready via LateX. Je fait donc mon diagramme en LateX et le transforme en pdf avec pdflatex, enfin, pour pouvoir le réutiliser sous la forme de png dans les documents corpoflan, imagemagick est mon sauveur :

$ convert -density 200x200 -quality 90 -trim diagramme.pdf diagramme.png

Elle n'est pas belle la vie ?

UPDATE

Si dans votre modèle de document d'origine il y a des images, pour les récupérer il faudra déterminer où elle se trouve de corpoflan-modele.odt, pour xmlstarlet peut vous aider :

$ xml sel -N draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0"  -N xlink="http://www.w3.org/1999/xlink" -t -v "//draw:image/@xlink:href" styles.xml
Pictures/100000000000004200000032A4B86058.png

d'où

$ unzip Pictures/100000000000004200000032A4B86058.png corpoflan-modele.odt
$ zip corpoflan.odt Pictures/100000000000004200000032A4B86058.png

(Il faut noter là que xml c'est le nom du binaire de xmlstarlet sous FreeBSD sous linux c'est généralement xmlstarlet le nom du binaire.

Exemple en image :

vim

pandoc-nosytle

pandoc-nosytle

2009/11/05

Une forge sous NetBSD

Installation des packages

Installation de pkgin

D'abord on installe le package pkgin en lui même via la méthode binaire "traditionnelle" NetBSD

$ export PKG_PATH=ftp://ftp.fr.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/5.0/All
$ pkg_add -v pkgin

Il faut ensuite modifier le fichier /usr/pkg/etc/pkgin/repositories.conf pour y ajouter la ligne

ftp://ftp.fr.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/5.0/All

Puis mettre à jour la liste des packages binaire disponibles

$ pkgin update

Installation des autres composants

Les composants dont on aura besoin sont les suivant :

On installe donc tout ça

$ pkgin install scmgit postgresql84-server ruby18-postgres-pr ruby18-RMagick thin

Quelques minutes plus tard tout est arrivé et installé

Installation des gems

Il faudra ensuite installer les Ruby On Rails via les gem

$ gem install rail -v=2.2.2

Récupération de redmine

Exemple pour la version 0.8.6 ici :

$ ftp http://rubyforge.org/frs/download.php/66633/redmine-0.8.6.tar.gz

Maintenant que tout est près passons à la configuration

Configuration

Ajouts des utilisateurs

Nous allons faire tourner chaque processus avec des utilisateurs différents :

redmine:redmine pour le serveur web thin git:git pour le daemon git

$ groupadd _redmine
$ groupadd _git
$ useradd -m -g _redmine _redmine
$ useradd -m -g _git _git

Préparation du serveur postgresql

D'abord on copie le script d'init de postgresql dans /etc/rc.d/ pour qu'il puisse être activé au démarrage :

$ cp /usr/pkg/share/examples/rc.d/pgsql /etc/rc.d/pgsql
$ echo "pgsql=YES" >> /etc/rc.conf

Puis on initialise la base :

$ /etc/rc.d/pgsql initdb -E unicode

Enfin on démarre le serveur

$ /etc/rc.d/pgsql start

On crée ensuite la base qui va bien

$ createuser -I -E -P -S -R -D redmine

Renseigner le mot de passe

$ createdb -T template0 -O redmine -E UTF8

Postgresql est maintenant utilisable

Configuration de redmine

$ tar xvfz redmine-0.8.6.tar.gz 
$ mv redmine-0.8.6 redmine # non obligatoire
$ cd redmine

Configuration de la base de production redmine

$ cp config/database.yml.example config/database.yml

Il faut modifier ensuite ce fichier pour correspondre à :

production:
 adapter: postgresql
 database: redmine
 host: localhost
 username: redmine
 password: mon_pwd

On initialise la base redmine :

$ RAILS_ENV=production rake db:migrate

Et on insère les données par défaut :

$ RAILS_ENV=production rake redmine:load_default_data

Afin que redmine puisse fonctionner, l'utilisateur dans lequel va tourner le serveur thin doit pouvoir accéder à certains répertoires :

$ mkdir tmp public/plugin_assets
$ sudo chown -R _redmine:_redmine files log tmp public/plugin_assets
$ sudo chmod -R 755 files log tmp public/plugin_assets

Configuration du serveur thin

Notez que ici redmine est installé dans /home/_redmine

Il faut simplement créer un script rcng pour démarrer automatiquement thin : /etc/rc.d/thin

#!/bin/sh
#
# PROVIDE: thin
# REQUIRE: DAEMON

. /etc/rc.subr

name="thin"
rcvar=$name
command="/usr/pkg/bin/$name"
stop_cmd="/usr/pkg/bin/thin -c /home/_redmine/redmine -e production stop"
command_args="-c /home/_redmine/redmine -e production -d -u _redmine -g _redmine start"

load_rc_config $name
run_rc_command $1

Puis l'activer

$ chmod 755 /etc/rc.d/thin
$ echo "thin=YES" >> /etc/rc.conf
$ /etc/rc.d/thin start

Un serveur thin tourne maintenant sur le port 3000 du serveur

le daemon git

On considère ici que les dépots git se trouveront dans /home/_git/depots Tout comme pour thin il faut simplement créer un script rcng

#!/bin/sh
#
# PROVIDE: gitdaemon
# REQUIRE: DAEMON  

. /etc/rc.subr

name="git-daemon"
rcvar=$name
pidfile="/var/run/$name.pid"
command="/usr/pkg/libexec/git-core/git-daemon"
command_args="--detach --base-path=/home/_git/depot --user=_git --group=_git --pid-file=$pidfile"

load_rc_config $name
run_rc_command $1

Puis l'activer

$ chmod 755 /etc/rc.d/gitdaemon
$ echo "gitdaemon=YES" >> /etc/rc.conf
$ /etc/rc.d/gitdaemon start

Déposer les dépots git dans /home/_git/depots et ils seront automatiquement disponibles, par exemple :

Pour un depot /home/_git/depots/CBlog.git :

$ git clone git://monbeauserveur/CBlog.git 

Pour plus d'information ici UnixGarden est ton ami : et

Conclusion

La forge est maintenant opérationnelle, pour y accéder : http://monbeauserveur:3000 .

UPDATE :

rhaamo vient de rajouter le support de mercurial

Pages : 1 2 3 4 5 6 7