Le blog à Fred

Aller au contenu | Aller au menu | Aller à la recherche

fév. 13

Merci de fermer les portes !

J'aurais pu sous-titrer ce billet Quand la confiance ne règne plus :-/

Il m 'avait déjà été demandé par le passé de sécuriser l'accès à un serveur Subversion mais vu les effets de bord, j'étais revenu en arrière, histoire de pas embêter mes petits camarades développeurs.
Comme toutes les choses ont une fin, c'est reparti de plus belle.
Heureusement, cette fois-ci, j'ai réussi à m'y coller, non sans avoir foutu un beau bordel pendant quelques heures.
Je vais quand même tenter de vous expliquer ce qu'il y avait à faire et comment je suis arrivé à mes fins.
Ça vous semblera peut-être très simple mais il y avait des pièges.
Imaginons un référentiel Subversion ayant la structure suivante :

/
├── Projet1
│   ├── branches
│   ├── tags
│   └── trunk
└── Projet2
    ├── branches
    ├── tags
    └── trunk

Un exemple simple de fichier d'accès est le suivant :

[groups]
projet1_devs=john, joe
projet1_admins=john
projet2_devs=jane, joe
projet2_admins=jane

[/]
* = r

[Projet1]
@projet1_devs = r

[Projet1/tags]
@projet1_admins = rw
@projet1_devs = r

[Projet1/branches]
@projet1_devs = rw

#Et ainsi de suite pour chaque projet

Jusque là, c'est pas trop grave mais tous les développeurs peuvent voir le code de chaque projet mais ne peuvent pas y écrire, on est typiquement dans le cas classique tel que décrit dans la doc.
Tant que l'on a confiance, pas de problème mais quand le doute vous habite, ça va plus.
Allons-y, fermons les portes !

Le premier réflexe est de retirer la partie liée au /... C'est une bonne idée mais dont le principal effet de bord est de gêner les outils de navigation dans le référentiel et qui oblige le développeur à connaître l'URL complète vers son projet.
Alors comment faire pour continuer à pouvoir browser tranquillement mais que dans les projets où on a les droits ?
Et bien, au lieu de mettre des droits, on en retire explicitement :

[groups]
projet1_devs=john, joe
projet1_admins=john
projet2_devs=jane, joe
projet2_admins=jane

[/]
* = r

[Projet1]
* =
@projet1_devs = r

[Projet1/tags]
* =
@projet1_admins = rw
@projet1_devs = r

[Projet1/branches]
* = 
@projet1_devs = rw

#Et ainsi de suite pour chaque projet

Vous avez remarqué la subtilité ?
Pour chaque section de projet, il suffit de retirer les droits mis à tous.
Bon, c'est simple mais fallait y penser.

nov. 26

A l'abri dans ma ''Git''-oune

D'après Wikipedia, le terme guitoune désigne une tente ou un abri de fortune.
Du coup, y a un petit côté camping au mieux ou au pire, un truc fait de bric et de broc.
Ce que j'aime bien avec la tente, c'est le petit côté communautaire si la tente est grande, un peu comme une yourte. En plus, la tente, c'est le truc où on a l'impression d'être à l'écart du monde[1] au milieu de nulle part à profiter de la nature, à s'inventer une existence hors des carcans de notre société uniformisante.
Il y a aussi la tente indienne dans laquelle les personnes importantes du clan se retrouvent autour du shaman qui prédit l'avenir et donne les grandes orientations après avoir bien tiré sur le calumet.
Finalement, tout ça représente assez bien ce dont je vais parler maintenant.
Je vous préviens, c'est dense et chiant à lire :D

Notes

[1] ok, sauf au mois d'août dans un camping des Landes ou de la Côte d'Azur :D

Lire la suite...

oct. 26

Perversions et paires de versions

Là, ça part fort et vous vous demandez certainement de quoi je vais encore vous entretenir.
C'est simple, juste deux trois trucs que je lis ça et là sur la gestion de versions et qui me foutent des boutons.

Lire la suite...

sept. 4

Et qu'on n'en parle plus !!

Encore un billet excellent sur Subversion et l'utilisation au jour le jour que je suis amené à en faire.
Bon, en gros, pour que vous sachiez si vous devez lire la suite, ça traite des ajouts automatiques faits par les greffons Subversion d'Eclipse.

Lire la suite...

juil. 6

Damn' I'm good

Two posts in one night, Waooowww !!!
Well this is one is in english as it seems that few non-french speaking people landed there.
It's not the first time but this time, I'd like to ask you something :

Tell me the articles you'd like to read in English

I know this is a difficult question as you cannot choose easily but there few technical topics :

  • FreeBSD
  • Subversion
  • Networking with FreeBSD
  • CodaFS
  • Ada
  • And others you might find while surfing here


Please tell, I will be glad to translate these if you have any interest.
BUT, I think sometimes humour will be diffcult to translate[1].

So don't be shy and ask !

Notes

[1] As I saw there :D

juin 2

Et comment qu'on fait ?

Quand on a un seul Subversion et plusieurs environnements Trac ?

Pour comprendre ce qui suit, mieux vaut maitriser un tant soit peu Subversion et Trac. M'enfin, je dis ça, je dis rien.

Lire la suite...

mai 31

Transfert auto-largue... Enfin presque

Enfin un billet technique après des mois d'absence !!!
Dans le cadre de certaines de mes occupations professionnelles, j'ai eu à migrer un repository Subversion d'une machine vers une autre.
Vous trouverez ici un petit tuto pour migrer facilement via le réseau.

Lire la suite...

sept. 9

Attention, codeur, je t'ai à l'oeil !

Frappé une fois de plus par un élan lyrique, je vous propose une prose sur les outils nécessaires, à mon humble avis, pour faire du soft qui laisse pas un arrière-goût de pas bien fini.

Je vous préviens tout de suite, c'est long.

Lire la suite...

sept. 29

Les lignes de code, les lignes de code... Ils n'ont que ça à la bouche

Vendredi dernier, grande relance du chef sur le nombre de lignes de code du projet.
Off course avec mon acolyte Marcello[1], nous avons recommencé à expliquer le pourquoi du le nombre de lignes de code, c'est mal et ça mesure pas combien on gland... Travaille dur.
Et là, quasi-éclair de quasi-génie !!!
Vous ai-je déjà dit que j'étais aussi le grand Manitou du serveur Subversion ?
Oui, je l'ai fait ? Bon, bah, je le redis :

Je suis le grand Manitou Subversion dans mon boulot... Enfin, dans mon département... Bon, okay, dans ma salle de dev

Il m'est venu une idée: Plutôt que de mesurer le nombre de lignes de code à un moment donné[2], ne serait-il pas opportun de regarder l'évolution de ce nombre au fur et à mesure du projet ?
En effet, ce nombre ne fait pas qu'augmenter. Par exemple, lors d'un refactoring, il n'est pas rare de supprimer plus de lignes que d'en rajouter.
Du coup, en comptant l'ensemble des variations de lignes de code depuis le début du projet et en appliquant une règle pondérant le nombre de lignes supprimées par rapport au nombre de lignes ajoutées[3], on peut rapprocher cette variation du temps de développement. Car au final, c'est bien le nombre demandé par le chef : "Combien de lignes de code vous écrivez à l'heure ? Combien ça me coûte ?".
Bon, on a déjà eu le même coup avec le nombre de bugs et on en a pris plein la figure à l'époque donc finalement, je crois que je vais laisser traîner :-/

Enfin, votre avis m'intéresse sur la question, chers lecteurs et lectrices.

Notes

[1] Je ne donnerai pas ici de précision sur lui pour sa sécurité :D

[2] Lundi, y a huit jours pour mon chef ;-)

[3] C'est toujours plus rapide de supprimer des pans entiers de code que d'en rajouter... Quoique !! -;)

mai 22

Subversion et svnadmin

Au boulot, j'ai migré il y a peu un repository Subversion d'un poste Window$ XP vers un FreeBSD 7.0 flambant neuf.
Et bien, je suis très content !!!
Enfin, ce n'est pas cela dont je veux vous entretenir. Lors de la migration, j'ai eu le problème :
suivant après création du repository et import du dump de l'existant, celui-ci était inaccessible. Il se trouve que c'était un problème de droits dans des fichiers de la base de données BDB. En effet, le 'repository' est accessible via Apache qui tourne sous le compte utilisateur www et le moindre fichier appartenant à root le met mal à l'aise[1]. Un petit


chown -R www:www mon_repository

et il n'y paraît plus.
Tout allait donc pour le mieux dans le meilleur des mondes quand hier, pour une raison qui m'est encore inconnue, il m'est venu à l'idée de faire un petit


root :/data/svn# svnadmin list-unused-dblogs mon_repository | xargs rm

root :/data/svn# svnadmin recover mon_repository

Cette foutue deuxième ligne que j'ai tapée comme ça pour le fun m'a patiemment remis quelques fichiers dans l'escarcelle du puissant root[2]. Je vous passe les cris d'horreur de mes chers condisciples développeurs ne pouvant plus, d'un coup, s'abreuver de leur dose de "commits" journaliers (voire pluri-horaires pour certains). Sauf que là, chat échaudé craint l'eau froide, je suis passé pour un demi-dieu de la gestion de conf en tapant mon chown magique.

Et voilà, encore une grande aventure de mon quotidien d'informaticien.

Message perso à mon Padawan : Tu vois, on peut balancer un tip à 30 centimes de balle en plus de quinze lignes, faut savoir si prendre, c'est tout.

Notes

[1] C'est vrai, un root laché comme ça au milieu d'autres utilisateurs met toujours mal à l'aise

[2] Rien ne vaut un root puissant lancé avec fracas qu'un root silencieux qui vous trahit tout bas (Magic Lolo)