Merci à Cristian :-)
16 décembre 2009
01 novembre 2009
Démarrer tftpd
J'avais parlé d'une net install de Debian sur Mac PowerPC : Mac mini de NetBSD à Debian
Eh bien il se trouve qu'il est parfois difficile de démarrer from scratch un tftpd pour que le Mac l'attaque. Alors voici une façon de faire, sur une Ubuntu 9.04 (eh oui : la 9.10 est d'une discutable stabilité).
Modifier /etc/inetd.conf tout de même, en rajoutant l'option « -s » à : /usr/sbin/in.tftpd -s /srv/tftp
Mettre les fichiers à servir dans /srv/tftp/ : yaboot, etc.
Démarrer inetd :
Eh bien il se trouve qu'il est parfois difficile de démarrer from scratch un tftpd pour que le Mac l'attaque. Alors voici une façon de faire, sur une Ubuntu 9.04 (eh oui : la 9.10 est d'une discutable stabilité).
$ sudo aptitude install tftpdinetd ne veut pas démarrer au cours de l'install ? Pas grave, l'idée n'était justement de le rendre résiduel.
Modifier /etc/inetd.conf tout de même, en rajoutant l'option « -s » à : /usr/sbin/in.tftpd -s /srv/tftp
Mettre les fichiers à servir dans /srv/tftp/ : yaboot, etc.
Démarrer inetd :
$ sudo inetd
11 octobre 2009
La persistance applicative comme un aspect
Dans le développement d'une application on pense souvent très tôt à la solution de persistance. Certains ont même une idée tellement précise du « modèle physique des données » — terminologie qui est une drôle de façon se se rassurer —, qu'ils vont à terme jusqu'à contraindre le comportement de l'application ou du système pour se conformer au schéma de la base. Ainsi du genre de réponses « on ne peut pas faire ce que vous demandez, à cause des clefs étrangères qui sont déclarées dans la base ». Ah… Et pourquoi ne pas faire des batchs d'audit et de rattrapage ? Et pourquoi ne pas gérer des états de mes données ? Et pourquoi ne pas laisser les transitions se faire de façon asynchrone ? Et surtout : si vous vous appuyez sur des clefs étrangères pour assurer l'intégrité métier de mes données, vous me faites plutôt penser que vous n'avez pas compris mon métier !
Quel métier se résume à des contraintes techniques d'intégrité ? (contraintes que du reste les DBAs font la plupart du temps sauter en production afin d'améliorer les perfs).
Cependant je ne veux pas reparler ici de centrer les objectifs du cycle de développement sur les processus métier, je considère que c'est acté.
Non, je voudrais parler de persistance.
Il y a des cas où les processus métier sont suffisamment simples pour être embarqués dans une application transactionnelle, où il n'y a pas ou quasiment pas d'existant, bref, où on a la latitude pour développer. Pléthore de frameworks de persistance viennent en sus à notre rescousse, on peut citer Hibernate (https://www.hibernate.org/) dans les premiers.
Pourtant nombre d'entre nous continuent de vouloir poser le schéma de la base, quand bien même serait-il un mapping naïf des propriétés des objets Java, dès le commencement.
Pourquoi ne pas simplement développer l'application ? On met toutes les données en mémoire, et on optimisera ensuite ! J'ai juste besoin dans un coin d'un compteur transactionnel pour mes états métier (ben, oui), compteur que je peux implémenter par un synchronized tout bête, et je fais mouliner le reste avec des classes ad hoc.
Plus tard, quand j'aurai besoin de partager mes données sur un cluster, ou de performances, ou tout simplement de sauvegardes parce que j'aurai à mettre en place un PRA (Plan de reprise d'activité, en gros comment remettre d'aplomb un deuxième système informatique si le premier vient de calancher, par exemple suite à un incendie), alors là, oui, je me pencherai sur la persistance. Mais c'est un aspect de l'application, au même titre que la sécurité ou les logs. Ce n'en est pas le cœur ni le socle ; ce n'est pas fondamental : l'absence de persistance des données, dans le sens général, n'empêche pas l'application de tourner.
D'ailleurs combien, parmi ceux qui pensent de suite à la solution de persistance, le font réellement parce qu'ils envisagent un PRA ou des performances maximales ? Non, le plus souvent la couche de persistance est envisagée comme une nécessaire façon de réaliser une application. Dans d'autres domaines on sait s'affranchir de ce genre de préjugés : les compilateurs dégagent, avec Ruby ou Groovy et l'aide des IDEs, les descriptions XML sont supplantées par des conventions ou des annotations, le besoin de hardware diminue grâce au cloud, on se fiche de l'OS parce qu'on fait du web, etc.
La couche technique de persistance n'est pas nécessaire dans une application. En revanche la couche logique de manipulation simple des données, notamment avec des verrous voire des états, et des vérifications d'intégrité, oui.
Et il y aura toujours moyen plus tard d'orchestrer tout ça et d'y ajouter les aspects désirés.
Pour finir, l'approche que je décris vise à éjecter la problématique de la persistance lorsqu'on se centre sur du développement applicatif. Pour d'autres types de réalisations, par exemple techniques, la question de la persistance se rencontre évidemment dès le début du chemin.
Quel métier se résume à des contraintes techniques d'intégrité ? (contraintes que du reste les DBAs font la plupart du temps sauter en production afin d'améliorer les perfs).
Cependant je ne veux pas reparler ici de centrer les objectifs du cycle de développement sur les processus métier, je considère que c'est acté.
Non, je voudrais parler de persistance.
Il y a des cas où les processus métier sont suffisamment simples pour être embarqués dans une application transactionnelle, où il n'y a pas ou quasiment pas d'existant, bref, où on a la latitude pour développer. Pléthore de frameworks de persistance viennent en sus à notre rescousse, on peut citer Hibernate (https://www.hibernate.org/) dans les premiers.
Pourtant nombre d'entre nous continuent de vouloir poser le schéma de la base, quand bien même serait-il un mapping naïf des propriétés des objets Java, dès le commencement.
Pourquoi ne pas simplement développer l'application ? On met toutes les données en mémoire, et on optimisera ensuite ! J'ai juste besoin dans un coin d'un compteur transactionnel pour mes états métier (ben, oui), compteur que je peux implémenter par un synchronized tout bête, et je fais mouliner le reste avec des classes ad hoc.
Plus tard, quand j'aurai besoin de partager mes données sur un cluster, ou de performances, ou tout simplement de sauvegardes parce que j'aurai à mettre en place un PRA (Plan de reprise d'activité, en gros comment remettre d'aplomb un deuxième système informatique si le premier vient de calancher, par exemple suite à un incendie), alors là, oui, je me pencherai sur la persistance. Mais c'est un aspect de l'application, au même titre que la sécurité ou les logs. Ce n'en est pas le cœur ni le socle ; ce n'est pas fondamental : l'absence de persistance des données, dans le sens général, n'empêche pas l'application de tourner.
D'ailleurs combien, parmi ceux qui pensent de suite à la solution de persistance, le font réellement parce qu'ils envisagent un PRA ou des performances maximales ? Non, le plus souvent la couche de persistance est envisagée comme une nécessaire façon de réaliser une application. Dans d'autres domaines on sait s'affranchir de ce genre de préjugés : les compilateurs dégagent, avec Ruby ou Groovy et l'aide des IDEs, les descriptions XML sont supplantées par des conventions ou des annotations, le besoin de hardware diminue grâce au cloud, on se fiche de l'OS parce qu'on fait du web, etc.
La couche technique de persistance n'est pas nécessaire dans une application. En revanche la couche logique de manipulation simple des données, notamment avec des verrous voire des états, et des vérifications d'intégrité, oui.
Et il y aura toujours moyen plus tard d'orchestrer tout ça et d'y ajouter les aspects désirés.
Pour finir, l'approche que je décris vise à éjecter la problématique de la persistance lorsqu'on se centre sur du développement applicatif. Pour d'autres types de réalisations, par exemple techniques, la question de la persistance se rencontre évidemment dès le début du chemin.
06 octobre 2009
svn://svn+ssh
Ceci sera un post légèrement cryptique pour les non informaticiens.
C'est juste pour me rappeler… comment accéder à Subversion par SSH avec clefs…
Sur le serveur : SSH. Permettre l'authentification par clefs.
Dans /etc/ssh/sshd_config :
C'est lors de la génération des clefs qu'est demandée la « passphrase », mot de passe qui active la clef privée.
Sur le serveur : Subversion. Vu qu'on va faire du svn+ssh, pas besoin de lancer svnserve, donc.
Sur le client : SSH.
Sous Unix, clefs privées et publiques à mettre dans ~/.ssh. En général leurs noms respectifs sont « id_rsa » (-rw-------) et « id_rsa.pub » (-rw-r--r--). Connexion en : ssh -l <username> -i </path/to/private/key>
Sous Windows, clefs à mettre chais pas où, tellement c'est sécurisé. Faire pointer Putty dessus.
Rappel : les clefs publiques « xxx.pub » sont destinées à être fournies publiquement : envois par e-mail, publication dans un blog…
En revanche les clefs privées sont à protéger absolument. Elles sont plus précieuses que le mot de passe (« passphrase ») qui les active.
Sur le client : agent SSH. Pour éviter d'avoir à s'authentificer à chaque fois.
Sous Unix, ssh-agent :
ssh-agent et Pageant peuvent être lancés au démarrage pour gagner du temps. Cela dépend de l'usage qu'on en a.
Sur le client : Subversion+SSH.
Sous Unix, déclarer dans son .profile une variable d'environnement SVN_SSH, du genre :
Sous Windows, après une installation de la version de CollabNet de Subversion, j'ai mis ceci dans C:\Documents and Settings\<user>\Application Data\Subversion\config :
C'est juste pour me rappeler… comment accéder à Subversion par SSH avec clefs…
Sur le serveur : SSH. Permettre l'authentification par clefs.
Dans /etc/ssh/sshd_config :
RSAAuthentication yesDans les ~/.ssh/ des intéressés, fichier authorized_keys avec une ligne par clef publique acceptée, du genre :
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
ssh-rsa AAAAB3Nz(…)PMRJl8=Pour produire des clefs publiques, ssh-keygen sous Unix et Puttygen sous Windows. Si Puttygen, une fois la clef publique créée, l'exporter au format OpenSSH pour pouvoir l'utiliser sur un serveur Unix.
ssh-rsa AAAAB3Nz(…)PM60l8==
ssh-rsa AAAAB35u(…)rT62zA== dandriana@ordinateur
C'est lors de la génération des clefs qu'est demandée la « passphrase », mot de passe qui active la clef privée.
Sur le serveur : Subversion. Vu qu'on va faire du svn+ssh, pas besoin de lancer svnserve, donc.
Sur le client : SSH.
Sous Unix, clefs privées et publiques à mettre dans ~/.ssh. En général leurs noms respectifs sont « id_rsa » (-rw-------) et « id_rsa.pub » (-rw-r--r--). Connexion en : ssh -l <username> -i </path/to/private/key>
Sous Windows, clefs à mettre chais pas où, tellement c'est sécurisé. Faire pointer Putty dessus.
Rappel : les clefs publiques « xxx.pub » sont destinées à être fournies publiquement : envois par e-mail, publication dans un blog…
En revanche les clefs privées sont à protéger absolument. Elles sont plus précieuses que le mot de passe (« passphrase ») qui les active.
Sur le client : agent SSH. Pour éviter d'avoir à s'authentificer à chaque fois.
Sous Unix, ssh-agent :
exec ssh-agent bashSous Windows, Pageant.
ssh-add </path/to/private/key>
ssh-agent et Pageant peuvent être lancés au démarrage pour gagner du temps. Cela dépend de l'usage qu'on en a.
Sur le client : Subversion+SSH.
Sous Unix, déclarer dans son .profile une variable d'environnement SVN_SSH, du genre :
export SVN_SSH="ssh -l <username> -i </path/to/private/key>"Si ça ne fonctionne pas, voir ~/.subversion/config.
Sous Windows, après une installation de la version de CollabNet de Subversion, j'ai mis ceci dans C:\Documents and Settings\<user>\Application Data\Subversion\config :
[tunnels]
ssh=<C:\path\to\>PLINK.EXE -l <username> -i <C:\path\to\private\key>
11 septembre 2009
Mac mini de NetBSD à Debian
Après qu'il a déjà fourni trois ans de bons et loyaux services sous NetBSD, dont dix-huit mois à faire silencieusement des backups enfermé dans un carton à la cave, je me suis mis dans l’idée de passer un Mac mini PPC sous Debian.
C’était l’occasion de sortir, de son carton également, un écran cathodique dix ans d’âge, et de dépoussiérer un peu les étagères.
Une fois l’écran et un clavier Dell de base connectés au Mac, enfoncer les touches Windows-Alt-O-F au démarrage pour accéder à Open Firmware.
Pour lancer depuis Open Firmware un netboot d’installation de Debian 5.0.3 (dit « Lenny ») :
Une fois l’installation terminée, après la configuration de SSH en clefs publiques, puis la mise au jour des postes clients « bureau », « salon » et « salle de jeux » en vérifiant qu’ils savent se connecter au nouveau système, le Mac mini, flanqué d’une nouvelle étiquette, a rejoint son grand carton.
Silencieusement, bientôt oublié dans le carton du fond avec sa pomme sur le couvercle, un vaillant petit serveur mouline.
C’était l’occasion de sortir, de son carton également, un écran cathodique dix ans d’âge, et de dépoussiérer un peu les étagères.
Une fois l’écran et un clavier Dell de base connectés au Mac, enfoncer les touches Windows-Alt-O-F au démarrage pour accéder à Open Firmware.
Pour lancer depuis Open Firmware un netboot d’installation de Debian 5.0.3 (dit « Lenny ») :
okCette ligne nécessite que sur le réseau local :
0 > boot enet:192.168.0.12,yaboot
- les adresses IP soient attribuées par un serveur DHCP,
- la machine 192.168.0.12 fasse tourner un serveur TFTP,
- et serve par TFTP les fichiers d’installation de Debian, dont yaboot, yaboot.conf, vmlinux, etc.
Une fois l’installation terminée, après la configuration de SSH en clefs publiques, puis la mise au jour des postes clients « bureau », « salon » et « salle de jeux » en vérifiant qu’ils savent se connecter au nouveau système, le Mac mini, flanqué d’une nouvelle étiquette, a rejoint son grand carton.
Silencieusement, bientôt oublié dans le carton du fond avec sa pomme sur le couvercle, un vaillant petit serveur mouline.
08 juin 2009
Comment le Parlement européen avait voté contre Hadopi
Sur le bon blog « Coulisses de Bruxelles » un article qui narre le vote majoritaire (c'est important) du paquet télécom au Parlement européen, avec la fameuse obligation d'une décision judiciaire pour couper un accès internet : Surprise partis à Strasbourg.
Rappelons que le Parlement européen est élu au suffrage universel direct. C'est ce qui vient de se passer ce dimanche 7 juin 2009. Le suffrage universel direct est une disposition démocratique extrêmement importante, qui semble aller de soi, notamment en France, mais qui n'est pas naturelle. En pratique il faut d'abord la gagner (rappelez-vous 1789), la valider, vérifier son application, et l'alimenter au fil des ans et des générations (non, l'abstention n'est pas une façon d'entretenir le suffrage universel).
En revanche la Commission européenne n'est pas élue directement : elle représente peu ou prou les États (disons les gouvernements) en tant que nations, pas en tant que peuples. Or c'est elle qui propose 80 % des textes qui seront ensuite votés, pas le Parlement européen. S'il y a dissensions entre le désir citoyen et les « décisions de Bruxelles » c'est justement en grande partie parce que les textes proposés ne réflètent pas les simples problématiques des peuples.
Vouloir que l'entité européenne (aujourd'hui la Commission) qui propose les textes aux votes soit plus proche de l'expression populaire, c'est une certaine façon de vouloir l'Europe, absolument pas partagée par tous les membres de l'Union. En pratique cela consisterait à modifier les institutions, ce qui ne se fait pas pendant les élections européennes (dont les effets se limitent au Parlement), mais par des traités, généralement soumis à référendums populaires. Cela peut également se faire par une révolution populaire européenne ou un putsch de niveau Empire.
On fait mine de croire que tout est géré « en haut lieu », mais il faut au contraire être bien conscient qu'il y a actuellement un combat très tendu entre ce que pourrait être une Europe des citoyens et une éventuelle Europe des gouvernements.
Pour ce sujet, dans quel sens le défunt TCE et le Traité de Lisbonne vont-ils ? Eh bien vers un accroissement de pouvoir du Parlement européen. Ce nécessaire accroissement est-il suffisant ? Sans doute pas.
Rappelons que le Parlement européen est élu au suffrage universel direct. C'est ce qui vient de se passer ce dimanche 7 juin 2009. Le suffrage universel direct est une disposition démocratique extrêmement importante, qui semble aller de soi, notamment en France, mais qui n'est pas naturelle. En pratique il faut d'abord la gagner (rappelez-vous 1789), la valider, vérifier son application, et l'alimenter au fil des ans et des générations (non, l'abstention n'est pas une façon d'entretenir le suffrage universel).
En revanche la Commission européenne n'est pas élue directement : elle représente peu ou prou les États (disons les gouvernements) en tant que nations, pas en tant que peuples. Or c'est elle qui propose 80 % des textes qui seront ensuite votés, pas le Parlement européen. S'il y a dissensions entre le désir citoyen et les « décisions de Bruxelles » c'est justement en grande partie parce que les textes proposés ne réflètent pas les simples problématiques des peuples.
Vouloir que l'entité européenne (aujourd'hui la Commission) qui propose les textes aux votes soit plus proche de l'expression populaire, c'est une certaine façon de vouloir l'Europe, absolument pas partagée par tous les membres de l'Union. En pratique cela consisterait à modifier les institutions, ce qui ne se fait pas pendant les élections européennes (dont les effets se limitent au Parlement), mais par des traités, généralement soumis à référendums populaires. Cela peut également se faire par une révolution populaire européenne ou un putsch de niveau Empire.
On fait mine de croire que tout est géré « en haut lieu », mais il faut au contraire être bien conscient qu'il y a actuellement un combat très tendu entre ce que pourrait être une Europe des citoyens et une éventuelle Europe des gouvernements.
Pour ce sujet, dans quel sens le défunt TCE et le Traité de Lisbonne vont-ils ? Eh bien vers un accroissement de pouvoir du Parlement européen. Ce nécessaire accroissement est-il suffisant ? Sans doute pas.
02 mai 2009
La face cachée d'Hadopi
Sur Agora Vox, un article intitulé La face cachée du projet de loi Internet & Création, dite « HADOPI », avec lequel je suis assez d'accord.
L'article parle bien du problème de la preuve : en gros ce qui fera techniquement preuve dans un premier temps sera l'adresse IP interceptée et qui aura permis de remonter jusqu'à la connexion à internet de l'abonné. Je détaillerais :
Problématique de la preuve, donc, et volonté de pouvoir accuser n'importe qui. C'est extrêmement grave.
Le deuxième énorme problème à mon sens est celui de la surveillance, dont parle également l'article d'Agora Vox.
Je pense que la question de la preuve, donc ici de l'arbitraire, voire du délirant (quand l'arbitraire est, en plus, « de bonne foi » !), est un cas d'école des coups de boutoirs que subit régulièrement la République. Dans le but de conforter une structure économique qui na pas su s'adapter (ici le modèle de distribution des œuvres numériques), on souhaite remodeler le consommateur lui-même (un peu comme Monsanto qui remodèle les graines pour imposer son modèle d'agriculture), quitte à ce qu'il y ait des effets nocifs sur l'individu en tant que citoyen, et quitte à se torcher avec les fondamentaux du droit.
Pour moi ce n'est pas une tension entre le fric et la République, tension qu'il s'agirait de régler par une voie médiane, mais très fondamentalement un combat entre des comportements débridés, qui se conçoivent eux-mêmes comme sans limites ou alors éventuellement extérieures — ainsi le droit est considéré comme une circonstance —, et une volonté positive, dont le droit est logiquement une conséquence.
L'article parle bien du problème de la preuve : en gros ce qui fera techniquement preuve dans un premier temps sera l'adresse IP interceptée et qui aura permis de remonter jusqu'à la connexion à internet de l'abonné. Je détaillerais :
- Ces adresses peuvent être « forgées » : selon le niveau de protocole qui sera utilisé pour le filtrage, il est possible d'usurper l'adresse IP de quelqu'un d'autre.
- Ces adresses publiques ne concernent pas les sous-réseaux : dans le cas d'un accès partagé à internet (réseau domestique, Wi-Fi...), impossible de décider quel ordinateur est impliqué. C'est pour cela qu'un logiciel client est indispensable pour avoir des preuves tangibles. Sans logiciel client, la preuve est potentiellement fausse, d'où l'absurdité de la loi, or une loi absurde est dangereuse. Avec un logiciel client (et certainement pas open source, ce n'est pas l'esprit), adieu votre vie privée.
- Ces adresses concernent un accès à internet, mais pas une personne : en cas d'ordinateur partagé par une famille ou un groupe, impossible de savoir qui a fait quoi. Donc d'une part on peut vous pirater, d'autre part ça peut venir de chez vous. La loi va dans le sens de vous accuser a priori.
Problématique de la preuve, donc, et volonté de pouvoir accuser n'importe qui. C'est extrêmement grave.
Le deuxième énorme problème à mon sens est celui de la surveillance, dont parle également l'article d'Agora Vox.
Je pense que la question de la preuve, donc ici de l'arbitraire, voire du délirant (quand l'arbitraire est, en plus, « de bonne foi » !), est un cas d'école des coups de boutoirs que subit régulièrement la République. Dans le but de conforter une structure économique qui na pas su s'adapter (ici le modèle de distribution des œuvres numériques), on souhaite remodeler le consommateur lui-même (un peu comme Monsanto qui remodèle les graines pour imposer son modèle d'agriculture), quitte à ce qu'il y ait des effets nocifs sur l'individu en tant que citoyen, et quitte à se torcher avec les fondamentaux du droit.
Pour moi ce n'est pas une tension entre le fric et la République, tension qu'il s'agirait de régler par une voie médiane, mais très fondamentalement un combat entre des comportements débridés, qui se conçoivent eux-mêmes comme sans limites ou alors éventuellement extérieures — ainsi le droit est considéré comme une circonstance —, et une volonté positive, dont le droit est logiquement une conséquence.
Inscription à :
Messages (Atom)
