Enigme résolue (en lisant un peu la doc…) pour acceder depuis un MAC à une imprimante partagée depuis un Linux au travers de IPP, il faut mettre la configuration suivante:
Dans le champ adresse : l’ip du serveur
Dans le champ nom de la file : /printers/nom de l’imprimante
Ensuite il faut choisir le driver correspondant à l’imprimante
Le tout etait donc de bien penser à ajouter /printers …
J’ai pu expérimenter la migration de VM avec kvm-qemu sur une opensuse 11.3 … Rien à redire c’est tres simple à mettre en oeuvre à condition de respecter 2,3 petites choses qui sont notées nul part :
– Pour pouvoir lancer la migration, il est nécessaire que le fichier de description de la VM soit bien présent sur la destination.
– Pour pouvoir lancer la migration, il faut que la source se connecte en utilisant le nom de machine et non son adresse IP sans quoi un message d’erreur générique est affiché, sans plus de détails.
– Il faut que le chemin du disque de la vm, partagé entre source et destination soit totalement identique.
– Il faut que le port VNC (à vérifier) soit disponible, celui-ci étant dynamique, il semble qu’il soit préférable de le forcer à une valeur fixe par VM lorsque la destination a deja des VM en cours d’exécution.
Bon, chaque mie à jour de matos à son lot d’emmerdes, et à ce jeux, je n’ai franchement pas de bol 🙁 l’informatique doit m’en vouloir … bref, me voila avec un système Xen Linux qui crash lamentablement dès que sont transférés plusieurs 100ènes de Mo sur une des cartes réseau … perso, je pense que le périphérique virtuel BR (bridge) est moisi, mais bon …
Manque de bol, les logs ne sont pas parlante et surtout rarement accessibles. De fait, j’ai eu besoin de brancher un jolie cable null-modem entre mon server et un portable pour avoir les logs jusqu’au dernier instant. Un petit rappel ici de comment mettre en oeuvre ceci
Tout d’abord, il faut trouver le cable null-modem, je le dit tout de suite, le petit dealer informatique du coin, lui parler null-modem ou chinois c’est kifkif ; j’ai donc trouvé mon bonheur chez un petit vendeur de composants électronique (mais pourquoi ai-je balancé mes tonnes de câbles passés !!!)
Une fois connecté, il est simple de tester la connexion en tapant sur un coté :
tail -f /dev/ttyS0
et de l’autre coté :
echo “coucou” > /dev/ttyS0
L’activation de la console se fait ensuite en modifiant /boot/grub/menu.lst pour ajouter les options suivante sur la ligne de commande, attention dans le cas de xen et d’un kernel normal c’est un peu différent :
Pour xen ajouter à la ligne kernel : loglvl=all guest_loglvl=all com1=9600,8n1 console=com1
¨Pour xen ajouter à la ligne modules : console=hvc0 earlyprintk=xen
Pour Linux ajouter :
Reste ensuite à booter et ecouter, pour l’ecoute je conseille deux terminaux :
cat /dev/ttyS0 > log.out
tail -f log.out
Comme ca on enregistre et affiche en meme temps le résultat dans un fichier.
Pour la vitesse, il serait mieux de passer à 115200 bauds, toutefois, pour ma part, je ne sais pourquoi mais le portable de reception n’a pas eu envie d’aller au dela de 9600bps, ce qui, il faut le dire ralenti grave le boot au point de le planter parfois.
Après avoir utilisé un serveur RPS durant 1 an, j’ai choisi de migrer sur un serveur Kimsufi. Le serveur RPS n’est pas mal mais le disque pose problème : il y a le principe du disque partagé à la bande passante vraiment trop limitée d’une part et la taille de ce disque elle aussi trop contraignante d’autre part.
Le serveur RPS offre un processeur normalement un peu plus rapide (double coeur et fréquence plus élevée) mais dont l’usage semble vraiment limité par le disque pour un usage web faisant appel à une BDD.
Le but de cet article est donc de comparer la performance avec mes petits outils habituels : bonnie++ et lmbench
Test du disque
Avec un facteur de l’ordre de 10, il est clair que la performance du serveur kimsufi est très loin devant celle du RPS. La perf du RPS est de l’ordre de celle d’un disque NFS sur reseau 100Mb ; soit de l’ordre de 2 fois moindre qu’un disque USB suivant d’autres tests que j’ai pu réaliser. La performance du disque Kimsufi est conforme à des tests effectués sur des disques classiques sata. Ce facteur limitant impacte fortement les performances d’accès à la base de donnée par exemple ; pour le reste, sur un serveur web, hors temps de backup c’est moins critique.
Test du processeur
Comme convenu la performance du Celeron est en dessous de celle de l’atom d’une génération plus recente avec une fréquence plus élevée et surtout un double coeur. N’empêche que l’écart entre les deux n’est pas d’un facteur 10 pas de 30 à 50% surtout lié aux accès mémoire.
Reste à tester mysql ; pour se faire j’ai utilisé myBench un petit outil tout simple en php :
Résultat plutôt surprenant où je m’attendais à ce que le kimsufi soit largement devant … une petite vérification des fichiers de conf s’impose ! à moins que ce ne soit le bench qui ne travaille que dans le cache …
Voyons donc avec sql-bench qui est distribué avec mysql et couvre plus de tests: (perl run-all-tests –server=mysql –user=.. –password=.. apres avoir créé une base ‘test’ sur mysql)
Etrange comportement du RPS sur les creation de table, j’imagine que celles-ci demande beaucoup d’I/O. Les requetes de select et insert sont beaucoup plus rapide. Ma config ayant beaucoup de cache (pour plier au probleme de disque) la puissance CPU semble prendre le dessus sur les requete insert/select/update et ce avec un facteur important de l’ordre de 2 à 3. Il semble donc, et c’est avec surprise, que la config RPS soit meilleure pour les accès bdd, ce qui pour le coup m’ennuie. On note toutefois que dès lors que l’on sort des conditions optimales, le test n’est pas du tout linéaire …
Voici donc quelques détails supplémentaires avec 1.5M de lignes à traiter:
Rien de bien neuf donc… si limite il y a dans la rupture de linéarité, elle est bien au dela des 1.5M de lignes.
Au final, une fois les sites migrés, je constate, à l’aide d’une sonde woozweb, que le temps de chargement moyen du site est 2 fois plus lente avec un KimSufi qu’avec un RPS, mais reste totalement acceptable, situant mes site dans la trache où 40% des sites font mieux pour du java et 9% pour du php basique.
Les logs apaches grossissent, grossissent à n’en plus finir … une solution est donc de faire de la rotation de log, c’est à dire de créer un nouveau fichier tous les mois. Pour celà il existe deux solutions:
le principal problème du système apache est que le log devient alors indexé, ce qui le rend plus difficile pour un traitement statistique automatique avec awstat par exemple (mais des solutions doivent exister). Pour plus de détails, suivre les liens ci-dessous …
Click to access log_file_rotation.pdf
http://httpd.apache.org/docs/2.0/programs/rotatelogs.html
http://www-uxsup.csx.cam.ac.uk/~jw35/courses/apache/html/x1670.htm
Quelques soucis pour installer NeXpose sous Windows et Linux… Le principal problème est que l’installeur ne fonctionne que si la langue du système est anglaise, du coup avant de lancer l’install sous Linux, tapez la commande suivante: export LANG=en_us.UTF-8
Ensuite sous Linux il faut absolument appeler la commande d’install avec ./NeXposeSetup-Linux64.bin et non sh ./NexposeSetup… Donc préalablement il faudra faire un chmod a+x ./NeXposeSetup-Linux64.bin
Enfin, pour ma part j’ai du préciser le chemin pour la jvm : ./NeXposeSetup-Linux64.bin -is:tempdir /home/xxxxx -is:javahome /usr/lib64/jvm/jre/
Bon courage !
Ref de l’erreur initiale:
This application requires a Java Run Time Environment (JRE)to run. Searching for one on your computer was not successful. Please use the command line switch -is:javahome to specify a valid JRE. For more help use the option is:help
Au démarrage d’une VM, si cela est configuré, Xen crée une console graphique accessible par VNC. L’ip est localhost (127.0.0.1) et le port 5900 + ID de la VM.
Attention, cette console est celle à regarder en priorité ( versus xen console nomVm ) car elle contient tous les messages du demarrage, alors que la console texte native elle n’a pas certaines informations, en particulier lors des e2fck …
Lors d’un boot, l’état des disques est vérifié et un e2fsck est lancé. Cette vérification est clairement bénéfique et système et il est déconseillé de l’outrepasser, mais il arrive qu’elle soit bloquante d’autant qu’une réparation demandera un lancement manuel d’un e2fsck sur une console texte dans un environnement très limité. Il est donc possible de demander au système de ne pas effectuer ce test. Pour celà, il faut simplement modifier le dernier digit de la ligne du fichier fstab pour remplacer le “1” par un “0”