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.
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”
Les versions récentes d’OpenOffice ne savent pas travailler correctement sur NFS3; au démarrage elles essaient de locker le fichier, ce qu’elle ne font pas correctement sur ce type de support. La solution la meilleure est de passer à NFS4 mais ceci n’est pas toujours le cas, comme par exemple lorsque vos fichiers sont sur un NAS un peu ancien comme c’est mon cas …
J’ai donc trouver cette solution qui consiste à désactiver le lock d’open Office en éditant le fichier /usr/bin/soffice (sur SLED 11) et en modifiant les lignes
# file locking now enabled by default
SAL_ENABLE_FILE_LOCKING=1
export SAL_ENABLE_FILE_LOCKING
Par
# file locking now enabled by default
#SAL_ENABLE_FILE_LOCKING=1
#export SAL_ENABLE_FILE_LOCKING
Il semble que la methode losetup avec loop_fish2 soit désuée… Voici la nouvelle methode semble-t-il plus actuelle:
1 – creer un fichier servant de disque avec des données aléatoire svp !
dd if=/dev/urandom of=./monFichier bs=1M count=10 (pour 10 Mo)
2 – initialiser le disque :
losetup /dev/loop0 ./monFichier
cryptsetup luksFormat /dev/loop0
là on entre la clef de cryptage
3 – formater le disque:
cryptsetup luksOpen /dev/loop0 myDevice
mkfs.ext2 /dev/mapper/myDevice
4 – monter le disque :
mount /dev/mapper/myDevice /mnt
Monter une partition existante:
losetup /dev/loop0 ./monFichier
cryptsetup luksOpen /dev/loop0 myDevice
mount /dev/mapper/myDevice /mnt
Demonter tout ca propremment
umount /mnt
cryptsetup luksClose /dev/mapper/myDevice
losetup -d /dev/loop0
Durant tres longtemps j’ai été mon propre hebergeur ayant besoin de machines dédiées la solution d’hebergement à la maison etait plus rentable et permettait un meilleur control. Cette année je fais le pas et migre sur un serveur dédié sous la forme d’un RPS. Dans un autre article vous trouverez des information sur la performance du serveur en lui même, mais ici je souhaite aborder la performance perçue de mes utilisateurs.
J’ai donc realisé quelques tests basique pour voir le gain à attendre. En terme de spec, pour situer, la machine OVH est moins performante par contre le reseau n’a rien à voir : 100Mb pour OVH contre 1Mb pour mon adsl sur l’upload.
Le premier test est le chargement d’une page simple, sans la moindre donnée dedans (0 octets). Le résultat est obtenu avec woozweb qui mesure les temps de reponse. Il est sans appel, le temps moyen de chargement sur l’adsl est de 0.49s en moyenne contre 0,01s sur le RPS