11.17.08
Posted in Coup de coeur, Jeux at 11:18 pm by michauko
Je me demande comment il jouera aux FPS - oui bah ça va, c’est tout ce qui me vient à l’esprit. Pour l’instant, il fait ses réflexes sur Burnout (et poissonrouge.com aussi, je suis pas [qu']un bourrin)… prometteur d’ailleurs sur Burnout.
Et quand je vois ça : http://www.nofrag.com/2008/nov/17/30079/, j’ai peur pour son avenir… de gamer. Je me dis qu’il n’aura plus moyen de se gratter les couill… en jouant aux FPS sans se faire péter une grenade sur les pieds ? Tu décapsules ta binouse en pleine LAN-à-la-webcam et boum, une ‘nade sur les pieds, équipe décimée. Tu farfouilles dans le tas de Haribo, hop, “defuse” ta bombe enclenchée par erreur. Tu te grattes le menton ? boum auto head-shot. Tu te grattes la jambe en pleine course ? dérapage au frein à main. Tu veux soigner ton coéquipier ? plante lui une seringue dans le bid’
Ca promet l’avenir technologique…
fiouuu, je suis fatigué moi
Permalink
11.05.08
Posted in Coup de coeur at 6:49 pm by michauko
Permalink
Posted in Coup de coeur at 10:53 am by michauko
Pour une fois, c’est pas dans un film ou une série.
JFK avait raison, il aura fallu 40 ans.
Pourvu qu’il ne se fasse pas buter.
Et bon courage à lui.
Permalink
11.03.08
Posted in Debian, Ubuntu, planet-libre.org at 5:58 pm by michauko
Moi qui croyait n’être embetté que sous Windows par ces histoires de limitations de taille de fichiers, de disques, de partitions etc, je viens de m’en prendre une en pleine tête : formatter une grappe RAID5 de 6*500 Go (SATA), volume utile 2.5 To.
Je n’avais pas trop fait attention à l’installation de la Debian, mais j’ai loupé une question cruciale par méconnaissance : le type de table de partition.
Tout cela est expliqué et difficile à suivre sur wikipedia. Moi j’en retiendrai juste le résultat pratique.
Eviter le problème à l’installation…
Au tout premier accès au disque “virtuel” ainsi créé, je me souviens que le programme d’installation m’a demandé ça :
Ca n’arrive que sur des disques jamais initialisés (comme des grappes RAID) ou des disques virtuels. Peut-être aussi des disques sortis d’usine sans aucun pré-traitement, je ne sais pas.
Par défaut, c’était GPT. J’ai pas trop réfléchi, j’ai mis msdos car j’avais déjà eu ce cas (sur un disque virtuel de petite taille, type machine VirtualBox pour faire joujou). En fait, la proposition par défaut doit être la bonne. Car impossible de formatter au delà de 300 Go ensuite (pourquoi 300 ?)
Si comme moi, vous avez râté cette étape, voici ci-dessous comment corriger.
…ou le corriger après coup
FDISK ne dit trop rien à la création des partitions, masi il crée une partition de moindre taille.
CFDISK est à peine plus bavard. En l’utilisant en console (et non pas à distance), j’ai vu passer des messages d’erreur, notamment :
Very big device. Trying to use READ CAPACITY(16)
De là, Google m’a expliqué le problème et il a fallu le rectifier en changeant ce type de table de partitions. Vous pourrez alors adresser tout l’espace physique de votre disque et le formatter.
Corrigez en utilisant l’outil PARTED :
[root@toto: ~]$ parted /dev/sdb
GNU Parted 1.7.1
Using /dev/sdb
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) mklabel gpt
(parted) mkpart
Partition name? []? MON_GROS_HD
File system type? [ext2]? ext3
Start? 0
End? -1
(parted) p
Disk /dev/sdb: 2500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 2500GB 2500GB MON_GROS_HD
(parted) quit
[root@toto: ~]$ fdisk -l /dev/sdb
Disk /dev/sdb: 2499.9 GB, 2499946741760 bytes
255 heads, 63 sectors/track, 303934 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 267350 2147483647+ ee EFI GPT
[root@toto: ~]$ mkfs.ext3 /dev/sdb1
mke2fs 1.40-WIP (14-Nov-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
305184768 inodes, 610338551 blocks
30516927 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
18627 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 35 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Et voilà le travail.
Au fait : ext3 semble être limité à 8 To. S’il y a quelques années 8 To paraissaient être une limite lointaine, actuellement, c’est moins évident. Il faudra alors passer en XFS ou ReiserFS (OK, j’évite les blagues de mauvais goût)
Permalink
10.14.08
Posted in Debian, Ubuntu, planet-libre.org at 3:30 pm by michauko
Raaah, je me trainais ce truc là depuis longtemps ; pourtant je sais parfaitement que le FTP est un de ces protocoles un peu pourris vis-à-vis des firewalls (et proxies), mais j’avais jamais rien fait pour m’arranger la situation.
Bref, l’occasion de faire un rappel - je passe la théorie car je donnerais dans l’à peu près, mais j’explique l’aspect pratique pour régler le problème titre de cet article.
Lorsque vous avez des problèmes de mode passif, actif etc en FTP, pensez à ceci.
Si quelqu’un veut poster en commentaire la théorie expliquant le problème, n’hésitez pas. Il me semble me rappeler des histoires de trames FTP contenant les IP émettrices et donc nécessité d’avoir des modules de masquerading particulier pour bien gérer le FTP… un vague résidu de cours de réseau 
La configuration
J’ai un serveur avec :
un FTP - restreints à certaines IP, rappelez-vous que FTP n’est pas du tout sûr (mot de passe en clair) et qu’il vaut mieux privilégier SFTP (du FTP par dessus SSH),
un shorewall ouvrant les ports 20 et 21
Bref que du bonheur en apparence.
Le problème
Malgré ça, je galère toujours d’un client FTP à l’autre. Le dernier en date : ncftp pour des échanges depuis un LAN vers ce serveur public. Ca se traduit par un cafouilli général dans les modes passifs etc.
Et un message d’erreur que pour une fois, j’ai relu lentement et me suis rappelé le coup du NAT spécifique FTP :
Falling back to PORT instead of PASV mode
En soit, je me foutais de savoir comment le client FTP établissait sa connexion, car dans tous les cas ça marchait, ça restait sécurisé dans la limite de ce que je demandais, mais c’était surtout que la complétion de nom, style cd rep TAB-TAB-TAB mettait 20 secondes à répondre le temps de passer en mode “PORT” justement. Soit environ 19,8 secondes de trop.
Comment on le règle ?
On pense à activer le NAT spécifique au protocole FTP, dans netfilter. Pour ce faire, par exemple via l’outil modconf (ou sudo modconf chez Ubuntu) afin d’activer ces 2 modules :
./kernel/net/netfilter/nf_conntrack_ftp.ko
./kernel/net/ipv4/netfilter/nf_nat_ftp.ko
Point besoin de rebooter, rien.
Voilà, un protocole FTP mieux géré par firewall netfilter sur votre serveur.
Excusez-moi pour l”à peu près technique concernant cet article. FTP ça me gave, c’est un sac d’ennuis ce truc. Mais c’est pratique.
Permalink
10.09.08
Posted in Coup de coeur, Debian, planet-libre.org at 5:09 pm by michauko
Wordpress est un outil de blog (un CMS diront certains) que je trouve assez sympa. Son premier but est de pouvoir publier facilement un blog, c’est-à-dire publier du contenu. Il n’est cependant pas trop prévu pour publier du contenu à accès restreint.
Dans les dernières versions, on voit des options pour protéger par mot de passe un article (ou une page). Mais ça s’arrête là, mais ça peut suffire dans bien des cas.
J’avais besoin de monter un site rapidement avec quelques pages statiques et des news, facilement éditables. Wordpress convenait donc, mais dans un contexte entreprise, il fallait priver l’intégralité de l’accès.
En cherchant un peu, on trouve donc 2 plug-ins parfaits pour ça.
Voici ce retour d’expérience : installer Wordpress avec authentification LDAP et contenu complètement privé (members-only).
Installation
Je suis parti sur une version SVN (la 2.6.2) car elle permet d’utiliser des plug-ins récents, qui ne fonctionnent pas pour ma version “stable” Debian (2.0.x). J’ai donc tout fait à la main, je vous résume ceci.
Préparation de la base MySQL
En console mysql, vous taperez par exemple :
CREATE DATABASE wordpress;
CREATE USER ‘wpadmin’@’localhost’ IDENTIFIED BY ‘mon_passwd’;
GRANT ALL ON wordpress.* TO ‘wpadmin’@’localhost’;
Ceci vous crée la base vide et un utilisateur d’administration.
Installation et configuration de l’application
Je schématise, côté OS et téléchargement de l’application :
mkdir /srv/www/wordpress
cd /srv/www/wordpress
svn co http://svn.automattic.com/wordpress/trunk/
Vous éditerez alors votre fichier /srv/www/wordpress/trunk/wp-config.php pour y renseigner au moins les champs suivants :
define(’DB_NAME’, ‘wordpress’);
define(’DB_USER’, ‘wpadmin’);
define(’DB_PASSWORD’, ‘mon_passwd’);
define(’DB_HOST’, ‘localhost’);
Vous ajouterez la conf Apache qui va bien (VirtualHost ou non), avec au moins ceci :
< Directory> # sans l’espace
Options FollowSymLinks
AllowOverride Limit Options FileInfo
DirectoryIndex index.php
< /Directory> # sans l’espace
Du classique, je ne détaille pas trop, je me concentre sur Wordpress, pas Apache2.
Lancement de l’installeur
Ensuite, vous irez sur http://votre_site/votre_blog/wp-admin/install.php pour lancer l’installation en 2/3 clics.
Vous voilà avec un wordpress tout vide et opérationnel.
Je passe sur le tour du propriétaire, j’enchaîne directement sur le choix et l’installation des plug-ins qui vont bien.
Les plug-in LDAP
Il y en a plusieurs, plus ou moins suivi, plus ou moins compatibles avec votre version de Wordpress. J’ai trouvé sur le site notamment celui-ci (wpDirAuth) compatible avec plein de LDAP, notamment OpenLDAP.
Après 2 heures de galère, on apprend que la version officielle sur ce site (1.2) n’est pas compatible avec Wordpress 2.6+.
Vous utiliserez donc la version 1.3 disponible ici.
L’installation est classique, en gros :
cd /srv/www/wordpress/trunk/wp-content/plugins
wget http://www.royal.wednet.edu/~ayearout/wpDirAuth-1.3.zip
unzip wpDirAuth-1.3.zip
Puis activation du plugin dans l’interface d’administration de WordPress. Classique. Son paramétrage ressemble à ceci, très complet :
Plug-in “members-only”
Enfin, ce plug-in permet de faire en sorte qu’il faille être connecté pour accéder au moindre contenu. Par défaut, vous êtes donc redirigé vers la page d’authentification.
![plug-in \"members-only\" pour Wordpress](http://michauko.org/blog/wp-content/uploads/2008/10/20081009_165503-300x296.png "plug-in \\"members-only\\" pour Wordpress")
Et voilà le travail
Permalink
Posted in Debian at 9:18 am by michauko
Tiens, on dirait que ça accélère… mes mails ce matin :
Bon, va falloir que je remette à jour ma doc, moi…
Permalink
10.03.08
Posted in Debian, planet-libre.org at 4:45 pm by michauko
Salut,
J’ai eu à déplacer l’outil sympa - très bien pour gérer des mailings-lists avec modération - d’un serveur à un autre.
L’outil était sur le backend de mail, avec la conf apache de sympa, la base de données de sympa et évidemment les binaires (le package sympa).
Le but était de déplacer la partie binaire, apache et base de données ; en conservant les boîtes mails et alias sur le backend de départ.
Je vous livre un petit retour d’expérience car c’est un poil plus compliqué que de déplacer une application LAMP classique.
Je partais d’une version Debian/stable, donc package sympa 5.2.3-1.2+etch1 et la cible était la même.
Je considère que vous avez déjà un Apache2 et MySQL sur la machine cible - et une machine cible capable de relayer des mails (recevoir et envoyer) sur postfix
La migration classique
La base reste la même :
1) Sur la machine cible, installez l’application - même version évidemment, packagée.
2) Reprenez (à la main ou en écrasant) la conf /etc/apache2/conf.d/sympa d’un serveur à l’autre
3) Reprenez ou adaptez /etc/sympa
4) Exportez/importez la base de données “sympa”, comme une brute, par exemple :
machine_depart:$> mysqldump -u votre_user_qui_va_bien -p -B sympa > migr_sympa.sql
puis
machine_cible:$> mysql -u user -p < migr_sympa.sql
5) Assurez-vous d’avoir les bons identifiants de login de l’application sympa dans les tables “mysql” de Mysql (= les tables du schéma mysql. Pigé ? il doit y avoir notamment une ligne dans la table mysql.user concernant le User sympa) :
use mysql ; SELECT * from user where User = ’sympa’;
La partie spécifique “sympa”
Ce qui est ci-dessus est ce que vous auriez à faire avec une appli LAMP typique qui stocke tout en base.
Manque de chance, sympa - au moins dans la version 5.2 (actuellement 5.4 dispo, pas essayé) - stocke tout un tas d’informations dans /var/lib/sympa, /usr/lib/sympa etc. Sans compter les alias mails qui permettent de transmettre les mails aux processus de gestion de sympa.
Donc il vous reste à faire :
La redirection des alias mail
Normalement, sur votre serveur de départ, vous devriez avoir tout un tas d’alias de mail dans /etc/aliases, genre :
sympa: “| /usr/lib/sympa/bin/queue sympa”
listmaster: “| /usr/lib/sympa/bin/queue listmaster”
sympa-request: postmaster
sympa-owner: postmaster
maliste1: “| /usr/lib/sympa/bin/queue maliste1″
maliste1-request: “| /usr/lib/sympa/bin/queue maliste1-request”
maliste1-owner: “| /usr/lib/sympa/bin/bouncequeue maliste1″
maliste2…..
Il faut reprendre cette configuration telle quelle sur la machine cible et s’assurer sur la première - qui reste la machine de backend de mail (mon MX en gros), donc celle qui reçoit le mail - qu’elle sache faire suivre tout ça à la machine cible qui est devenue celle qui gère sympa.
Donc dans la machine de départ, vous trafiquerez tout de la sorte :
sympa: “sympa@machinecible.com”
listmaster: “listmaster@machinecible.com”
sympa-request: postmaster (j’ai laissé tel quel, c’est un choix)
sympa-owner: postmaster (j’ai laissé tel quel, c’est un choix)
maliste1: “maliste1@machinecible.com”
maliste1-request: “maliste1-request@machinecible.com”
maliste1-owner: “maliste1-owner@machinecible.com”
maliste2…..
A la recherche du bordel éparpillé partout
Ensuite, je m’étais arrêté là - ahahah, erreur.
Sur l’interface web (la nouvelle), je ne voyais plus mes listes. La raison est que “sympa” stocke les listes, les archives etc hors de la base, dans des répertoires comme /usr/lib/sympa et /var/lib/sympa.
Donc, il faut reprendre tout ça sur la machine cible (des bêtes “tar” avec conservation des permissions suffisent).
Finalement, j’ai opté pour un joli :
dpkg -L sympa | less
De là, je suis passé dans tous les répertoires nommés (sauf les doc, le “man” etc - faut pas pousser) et je me suis assuré qu’il n’y ait pas de différence - attention à certains droits en setuid/setgid au nom de “sympa:sympa”.
Ensuite, vous envoyez la purée auprès de vos utilisateurs pour leur indiquer que le système est à nouveau dispo, sur une liste modérée tant qu’à faire, afin de bien faire tous les tests.
Si rien n’arrive, c’est pas grave, vous avez raté un truc.
Si vous recevez la demande de modération, c’est que ça semble bien parti
Le nettoyage
Lorsque vous ferez le DROP DATABASE sympa sur l’ancienne machine et le aptitude purge sympa, ça vous confirmera ce que je vous racontais sur le stockage des archives, des listes etc :
Permalink
09.23.08
Posted in Debian, planet-libre.org at 5:10 pm by michauko
Salut,
Il arrive qu’on ait besoin d’une application en “testing” sur un serveur en “stable”. Par exemple OCSInventory-NG. Il y a la bonne et la mauvaise méthode pour faire ça.
La mauvaise méthode (rapide, mais naze sur le long terme)
La méthode bourrin consiste à ajouter momentanément les lignes qui vont bien dans /etc/apt/sources.list, faire un apt-get update, l’installer et enlever les dépôts ensuite.
Ca marche mais on ne profite pas des mises à jour qui peuvent être importantes. Je dis ça car ensuite il vaut mieux enlever ces lignes qui risquent de vous faire migrer une partie de vos applis de “stable” à “testing” (si des fois vous êtes aveugles lors de votre “upgrade” régulier).
A ce propos, il ne faut pas oublier d’ajouter les lignes concernant le dépôt de sécurité.
Exemple, j’ajoute les lignes “lenny” pour donner ça :
deb ftp://ftp2.fr.debian.org/debian/ etch main contrib non-free
deb ftp://ftp2.fr.debian.org/debian/ lenny main contrib non-free
deb http://security.debian.org/ etch/updates main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free
La bonne méthode (presque aussi rapide)
La méthode propre consiste à garder tout le temps les lignes concernant les 2 (4) dépôts, mais à indiquer à APT le niveau de release que l’on veut conserver par défaut. Pour ce faire, créer un fichier du genre 00release dans /etc/apt/apt.conf.d/. Exemple :
# cat /etc/apt/apt.conf.d/00Release
APT::Default-Release “stable”;
Soyez prudent les 2/3 premières fois où vous mettrez à jour vos dépôts + upgrade. Histoire d’être sûr.
Le bug qui en découle
Souvent, l’effet de bord sera ça à votre prochain “apt-get update” :
Fetched 14.6MB in 50s (292kB/s)
Reading package lists… Error!
E: Dynamic MMap ran out of room
E: Error occurred while processing tkdiff (NewVersion1)
E: Problem with MergeList /var/lib/apt/lists/debian_debian_dists_lenny_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.
E: Couldn’t rebuild package cache
La correction sera d’augmenter un buffer quelconque pour APT, en ajoutant/adaptant, généralement dans /etc/apt/apt.conf.d/70debconf la ligne suivante :
APT::Cache-Limit 15728640; // 15 MB
Afin de repousser un peu la limite.
Voilà, c’est tout pour cette petite astuce néanmoins bien pratique.
Permalink
09.22.08
Posted in Coup de coeur, Ubuntu at 9:44 pm by michauko
Pense-bête tout con mais ça fait tellement de bien : pour couper les p#*_”~s de bips de votre shell ou de n’importe quelle fenêtre - je parle sous Ubuntu, allez dans Système -> Préférences -> Sons puis onglet “Bip système” et désactiver le truc qui va bien.
Je ne sais pas comment j’ai fait pour tenir si longtemps avec cette horreur.
(et avec modconf, vous pourrez virer une bonne fois le module pcspkr (”PC Speaker”), section kernerls/drivers/input/misc - yarglaaaaa)
Permalink
« Previous entries
![plug-in \"members-only\" pour Wordpress](http://michauko.org/blog/wp-content/uploads/2008/10/20081009_165503.png "plug-in \\"members-only\\" pour Wordpress")
