Facturation MMS et GPRS, vive le marketing

Je suis un utilisateur d’Internet sur mobile, j’avoue que la possibilité d’utiliser mon téléphone comme modem GPRS pour pouvoir accéder à l’Internet de n’importe où en France est plutot un truc super … J’ai simplement été assez surpris de payer pas loin de 100 euro de factures hors de mon forfait data alors que celui-ci n’était pas entamé … que c’est-t-il donc passé ?!?

Après une prise de contact avec le service commercial de mon opérateur (au demeurant fort désagréable) j’ai eu le fin mot de l’histoire : c’est balo, mais j’utilisais le canal “multimedia” et non le canal “e”
Cette différence est intéressantes à creuser puisque le service rendu par ces deux canaux est exactement le même, à savoir un accès Internet sans distinction de débit ou qualité de service… Outre le fait que la facturation soit hors forfait, il est aussi intéressant de constater que le prix du Méga est grosso modo 3 fois plus cher que sur le réseau “e”… Mais pourquoi donc ?!?
A mon avis pour mieux comprendre il faut regarder du coté du nom du réseau (mms) indiquant clairement que ce réseau est celui utilisé pour l’échange de mms ; ainsi, j’ai eu la joie de surfer au tarif mms plutôt qu’au tarif Internet. La réponse de ces différences n’est donc sûrement pas du coté technique du réseau, mais, il fallait le comprendre du coté Marketing !
Le MMS est en effet un service très utilisé que l’on peut donc facturer un maximum aux consommateurs, alors que le service Internet est lui plus anecdotique et ne pourra se développer qu’avec des tarifs plus bas. L’histoire ne dit pas si l’on peut envoyer des mms en utilisant le réseau “e” low cost, mais elle dit en tout cas que si vous voulez payer plus cher pour votre accès internet, il n’y aura aucun problème… L’opérateur vous configure même une liaison nommée GPRS Bouygtel par défaut, reliée sur le réseau MMS pour être sûr que vous y alliez, par erreur, si ce n’est pas par habitude.
En réponse on vous expliquera que c’est de votre faute et l’opérateur ne fera même pas le moindre méa-coulpa, vous avez payé 10 euros par mois de forfait data sans en consommer plus de 5%, mais on ne vous fera pas la moindre fleur sur les données consommées sur le mauvais canal à prix d’or. Business is business… n’empêche que ça donne envie d’aller à la concurrence.

Utilisation de subversion

Subversion est un outil de gestion de sources ou plus généralement de gestion de configuration. Subversion est le successeur de cvs.
Son utilisation est à première vu similaire à celle de cvs mais avec quelques différences non anodines. Nous allons voir l’installation sur un environnement Opensuse.
Tout d’abord, il faut installer le rpm de subversion. Il faudra ensuite indiquer dans le fichier /etc/sysconfig/svnserve le répertoire où stocker le repository de subversion. C’est dans la variable SVNSERVE_OPTIONS que l’on indiquera le répertoire choisi. On enlèvera aussi l’option -R qui bloque l’accès en écriture
Il faut ensuite créér un utilisateur svn et un groupe svn. Ceci se fera en editant les fichiers passwd et group ou en utilisant les commandes useradd et groupadd

Ces premières étapes passées il faut créer le repository , pour cela, nous allons appeler la commande suivante : svnadmin create –fs-type fsfs repertoire_du_repository
Cette commande va créer un ensemble de répertoires dans repository. Nous allons commencer par editer deux des fichiers du repository:
/conf/svnserv.conf : nous allons dé-commenter les lignes suivantes:
[general]
anon-access = read
auth-access = write
password-db = passwd

Ensuite, nous allons modifier le fichier des mots de passe pour ajouter les utlisateurs nécessaires. ce fichier est conf/passwd:
[users]
# harry = harryssecret
# sally = sallyssecret
utilisateur = mot_de_passe

On vérifiera que l’utilisateur et le groupe propriétaire de tous les fichiers du repository soit bien svn:svn, sans quoi il sera impossible d’ecrire dedans par la suite.

Le serveur svn peut alors être démarré en utilisant le script fournit par suse: /etc/rc.d/svnserve restart

La création d’un projet dans le repository se fera par la commande suivante : svn import path svn://localhost/projet. Normalement, un mot de passe doit être demandé, il s’agit de celui précédemment saisi dans le fichier passwd.

Quelques commentaires :

  • Nous avons créé un repository à la norme fsfs, il s’agit de la façon dont sont stockées les données, ici sous forme de fichiers. Il existe aussi la possibilité d’utiliser un base de donnée berkeley, (option –fs-type bdb) mais d’après la documentation de svn, ce mode de fonctionnement est beaucoup moins avantageux.
  • Le repository peut être accédé de plusieurs façons, la première etant directement via le filesystem local (quand le repository est sur la même machine) ; par file://path/to/repo. Le second est l’utilisation de svnserv par svn://path/to /repo. Le troisieme svn+ssh://serveur/path/to/repo pour utiliser le protocole svn au travers d’un tunnel ssh et la dernière est http (ou https) par http://serveur/repo pour utiliser WebDav

Utilisation de MySql sur NFS

Pourquoi utiliser MySql sur un lien NFS alors que c’est franchement déconseillé ?!? Après tout là n’est pas vraiment la question car la doc de Mysql nous le déconseille fortement, par contre elle oublie de répondre à la vrai question : COMMENT ?

Car si l’on essaie de démarrer un MySql dont les base sont stockées sur un file-system monté on obtient l’erreur suivante : InnoDB: Unable to lock ./ibdata1, error: 13

Pour s’en sortir, il faut ajouter aux paramètre de NFS l’option nolock sous la forme mount … -o nolock … ou en l’ajoutant dans la liste des options de la fstab.

Maintenant pourquoi ?
Par exemple parce que l’on souhaite qu’une partie d’un file système d’une VM contenant les données ne soit pas en capsulé dans 3 couches de filesystem virtuel… en cas de crash… ça peut vous sauver la mise ; quand les perf ne sont pas la contrainte absolue et qu’en plus il ne s’agit que de l’utilisation d’un reseau virtuel au travers d’un bridge… c’est acceptable

OpenSuse 10.2 – bilan

Finalement, je ne suis pas déçu (du moins pour l’instant), l’installation sous Linux OpenSuse 10.2 s’est merveilleusement passée – tous les périphériques ont été détectés et configurés correctement. Seul petite peur au démarrage : des barrette de DDR2 non reconnues par la CM (marque LDLC), mais qui marchent très bien sur ma P5B-VM empêchaient la carte de démarrer… mais du style encéphalogramme plat … petite frayeur !

Passé ce point, mise à jour du BIOS … de base était livré un 0401, je cherche donc a mettre le 0608 à partir d’une clef USB (qu’il faut brancher avant de demarrer le PC)… Ca ne marche pas … La carte mère croyant que 0401 est plus récent que 0608 … bravo Asus … solution : passer par l’utilitaire de flashage DOS. Les versions suivantes n’ont pas ce problème.

La configuration du Raid Jmicron s’est plutot bien passée sur mes deux disques SATA et le nouveau disque ainsi créé a tout de suite été identifié sous Linux, j’ai pu créer mes partitions dessus. les performances semblent bien meilleures que ce que j’obtenais par raid-soft.
Le reste de l’installation de linux s’est déroulé sans accros : adaptateur réseau détecté, pas de soucis pour l’instant avec 4Gb…

En bref, après tous mes déboirs lié au chipset 965G, je suis plutot satisfait de la P5N-E et sont N650i.

Asus P5B-VM, corruption au dela de 2 Go de mémoire

Depuis que j’utilise un P5B-VM d’assus, j’ai nombre d’ennui, mais celui-ci qui est la cause de pas mal de crash de mon serveur de production est de loin le plus ennuyeux : les données sont corrompues sur les disques… de façon aléatoire.
J’ai mis un moment pour cerner la cause … le temps de vérifier les deux disques utilisés en SATA, de checker la mémoire, puis de s’assurer que ce ne soit pas lié à l’usage de XEN ou du RAID… Maintenant, c’est clair, le problème apparaît sur une Linux de base fraîchement installé … pourquoi, c’est encore un grand mystere, mais donc attention à cette carte mère !!!

Ma config : ASUS P5B-VM (bios 901) avec core 2 duo underclocker (ca merde aussi à frequence normale) @ 1.6G / 4Go de Ram / 2 HD Sata 80Go. Kernel 2.6.18 (Opensuse 10.2)

Mise en evidence du problème :
xen-prod:/ # head –bytes=300m /dev/urandom > test
xen-prod:/ # for i in `seq 0 9` ; do cp test test$i ; done
xen-prod:/ # md5sum test*
014666c728c9e3b8299579fae499864a test
014666c728c9e3b8299579fae499864a test0
333fd93d093ac612cd8d5f65628f734e test1
1ab6ee68c6a7d9ff5a05f9d63f0f6df6 test2
96e96483e3175a59c9c05b6720514e1e test3
014666c728c9e3b8299579fae499864a test4
b24dbccc9f4831f8825ab4a55a3be4aa test5
8493efc9c14e4b5c162ac23696fbc16a test6
6a5f4301f66d0379049d79d0e14e2a87 test7
2c81cfa1c3a03aba134574922ee5d75c test8
2ea15c8392bfd0123472a80125bb3abe test9

Soit après copie, 70% des fichiers diffèrent de l’orignal !!

J’ai un peu tout essayé : desactivé le Memory remapping et me priver de 1.2G, passer le sata en mode “compatible” ; ext3 / reisefs … rien n’y fait !!!

Je suis a deux doigts d’aller m’acheter un autre carte mère, donc mon conseil, éviter celle-ci… et si vous avez une solution … contactez moi !
Après quelques recherches supplémentaires, en enlevant 2G le problème disparaît. la mémoire n’est pas en cause puisqu’en inversant les barrettes le problème n’apparaît plus non plus. C’est bien la carte mère (ou sa gestion sous linux) qui pose problème. J’avais lu des problèmes liés au chip ethernet, mais pas au contrôleur SATA … il y en a donc … Bref, au choix .. un serveur à 2Gb ou une nouvelle carte mère.. je crois que je vais tenter l’option n°2

OpenSuse 10.2, problème de niveau sonore

Toujours quelques soucis de plus … sans quoi je m’ennuierai sans doute … Bref, depuis que je suis passé de l’opensuse 10.1 à 10.2 j’ai perdu pas mal de dB sur ma carte son.

Je ne suis pas totalement sure de la cause, mais si ça vous arrive, je peux vous proposer la solution suivante :
Choisir comme système de son OSS (dans le control-panel de KDE > Son et multimédia > Système de son > Matériel). Une fois le système de son relancé (il faudra peut être un petit kill des familles pour tuer l’ancien…) il est possible via Kmix de modifier le niveau des VIA-DXS, ils étaient grosso-modo à 0 … quand on les passe à quelque chose comme 75% … comme par hasard ça fonctionne 😉
Une fois ce paramétrage fait, il est aussi possible de positionner les valeurs des DXS par les commandes suivantes:

amixer set ‘VIA DXS’,0 85% unmute
amixer set ‘VIA DXS’,1 85% unmute
amixer set ‘VIA DXS’,2 85% unmute
amixer set ‘VIA DXS’,3 85% unmute

Passage à Mysql5 et format des TIMESTAMP

Suite a une migration vers Mysql5 et le driver jdbc 3.1.12, mes programmes qui fonctionnaient bien avant se sont mis à générer des exceptions pour le motif suivant :
java.sql.SQLException: Cannot convert value ‘0000-00-00 00:00:00′ from column 11 to TIMESTAMP

Il semble donc que les dites versions, par rapport aux anciennes retournent un valeur “000-00-00 00:00:00” plutot que null lorsque l’on a cette valeur en base (ce qui soit dit en passant a peut être du sens) n’empeche que ca met bien la grouille… alors plutot que de se lancer dans une fastidieuse réécriture de code, il y a le paramètre miracle qui sauve la vie !!

Pour revenir au fonctionnement d’antant, il faut ajouter à la suite de la chaine de connexion l’option suivante:
jdbc:mysql://monHost/maBase?zeroDateTimeBehavior=convertToNull

Testé et approuvé !

Mise à jour avec Yast sur opensuse 10.1

J’ai rencontré quelques soucis pour mettre à jour ma Suse 10.1 ; plus particulièrement pour configurer le serveur de mise à jour. En effet dans mon cas la procédure d’inscription par Yast n’a jamais voulu fonctionner. Bref … Voila comment configurer manuellement le serveur de mise à jour ..

Vous procédé comme pour l’installation d’un fournisseur de RPM quelconque mais choisissez les modes et options suivantes:

  • HTTP
  • nom du serveur : ftp.tu-chemnitz.de
  • répertoire : /pub/linux/suse/ftp.suse.com/suse/update/10.1

Chez moi … ca fonctionne!