13/08/2014

Emile "iMil" Heitor 's home >> Holidays (IT)checklist

Par : iMil
Tags:
Blogroll
Ibiza

Well, it’s that time of the year again, next week I’ll be flying to my beloved Ibiza.

Being an Internet/IT junkie, I don’t exactly “disconnect”; actually I like to read / dig / test some new topics while on holidays (and while I’m not at the beach / clubbing / sunbathing). So every year I go through a particular “checklist” in order to be sure I can connect to the Internet no matter what, here’s the list as of now:

Any idea that comes to mind? :)

The post Holidays (IT)checklist appeared first on Emile "iMil" Heitor 's home.


11/08/2014

Emile "iMil" Heitor 's home >> virt-manager: “nc: unix connect failed”

Par : iMil
Tags:
Blogroll
FreeBSD
KVM
libvirt

I came across an annoying behaviour while trying to connect to a remote KVM hypervisor from a FreeBSD GUI. virt-manager failed to connect to the server and showed the following error message:

libvirtError: End of file while reading data: nc: unix connect failed: No such file or directory: Input/output error

In short, virt-manager tries to access to /usr/local/var/run/libvirt/libvirt-sock because it is compiled with a /usr/local PREFIX on FreeBSD. Of course they didn’t plan anything on a plain text configuration file. I figured out this has to be configured in GConf, for example using gconf-editor, simply replace:

qemu+ssh://user@host/system

with:

qemu+ssh://user@host/system?socket=/var/run/libvirt/libvirt-sock

Other parameters for remote URIs can be found at this address.

The post virt-manager: “nc: unix connect failed” appeared first on Emile "iMil" Heitor 's home.


08/08/2014

Emile "iMil" Heitor 's home >> FreeBSD 10, KMS and Intel 4500MHD

Par : iMil
Tags:
Blogroll

I recently borrowed a Dell machine at work, model E4300, a nice little laptop whose graphical display is done by a much common Intel 4500MHD. While the card worked out of the box for a classical 2D display with a fresh FreeBSD 10.0 install, I noticed that DRM/DRI (in short, 3D) wasn’t available; I knew it was somewhat related to the new KMS/GEM infrastructure, so I began a few searches and found those useful resources:

Those pages gave bits and pieces of information, but stack a lot of useless complex information for the newcomer. Actually, setting up KMS on FreeBSD 10 is pretty simple. Olivier and farfa gave me the right link: a post on the FreeBSD announce mailing list which explains that there’s an alternative repository for what they call “NEW_XORG”, aka Xorg 1.12.4 with KMS. Simply create a new pkg configuration file in /usr/local/etc/pkg/repos/FreeBSD_new_xorg.conf (create the directory if it does not exist), it must contain the following:

FreeBSD_new_xorg: {
   url: "pkg+http://pkg.FreeBSD.org/${ABI}/new_xorg",
   mirror_type: "srv",
   signature_type: "fingerprints",
   fingerprints: "/usr/share/keys/pkg",
   enabled: yes
}

Then run:

# pkg update -f
# pkg upgrade

You should be asked whether or not you want to upgrade a couple of packages, and among them, some Xorg-related packages.

There was one glitch on this process, xf86-input-keyboard and xf86-input-mouse actually have the same version in the standard pkg repository and the WITH_NEW_XORG repository, so it is mandatory to delete them using:

# pkg delete -f xf86-input-mouse xf86-input-keyboard

Then add:

WITH_NEW_XORG=yes

to /etc/make.conf, ensure your ports tree is up to date by running:

# portsnap fetch update

and rebuild xf86-input-keyboard and xf86-input-mouse with portmaster:

# portmaster x11-drivers/xf86-input-mouse x11-drivers/xf86-input-keyboard

If you don’t do this, Xorg will start but its log will explain the mouse and keyboard driver ABI mistmatches Xorg current version.

Restart Xorg, and enjoy your GLX-enabled environment :)

The post FreeBSD 10, KMS and Intel 4500MHD appeared first on Emile "iMil" Heitor 's home.


07/08/2014

GCU-Squad! >> ifconfig^Warp^Wnetstat^Wroute^Wip

Par : pinpin
Tags:
IP
Irc
Linux
arp
commands
deprecated
ifconfig
netstat

Thx to gradator, une cheatsheet parfaite pour se souvenir ce qu’on est sensé utiliser sous linux en 2014 pour récupérer des infos sur le réseau. En attendant les équivalents systemd pour 2015..

http://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/ proposé par gaston sur #GCU@freenode


04/08/2014

GCU-Squad! >> IT threats Q2 2014

Par : pinpin
Tags:
Irc
infosec

Si ça c’est pas un panorama relativement complet et exhaustif de tout ce qui se fait en termes de fraudes, exploits et autres arnaques. Ça va couper un peu dans votre productivité…

https://securelist.com/analysis/quarterly-malware-reports/65340/it-threat-evolution-q2-2014/ proposé par Seb sur #GCU@freenode


31/07/2014

Weblog de Natacha >> Le transfert de fichiers en 2014

Par : Natacha Kerensikova
Tags:
Geek

Supposons que l'on ait un fichier, ou un ensemble de fichiers (au besoin rassemblés dans une archive), sur un ordinateur que je vais appeler Alpha, parce que ce serait dégradant de lui donner un prénom féminin.

Le problème dont il va être question dans tout cet article va être de faire en sorte de copier ces fichiers sur un autre ordinateur, que je désignerai par Bravo, qui peut appartenir ou non à la même personne qu'Alpha.

On va considérer que ces données sont d'une taille raisonnable pour les standards actuels.

Quelle est la façon la plus pratique de s'y prendre ?

En général, le plus pratique est de passer par une mémoire flash (ou « clef ») USB. Même si la plupart des ordinateurs sont connectés sur un réseau, c'est dire le triste état des logiciels et de leurs interfaces à notre époque.

Il n'y a pas grand chose à dire sur cette solution éprouvée. Supposons donc que, pour une raison ou pour une autre, par exemple à cause de la distance entre les deux ordinateurs ou les craintes de transmissions virales, cette solution ne soit pas acceptable.

La solution la plus pratique est généralement de passer par un serveur HTTP accessible en réseau (ce qui suppose donc que ces deux ordinateurs soient connectés à un réseau).

C'est (encore) dire le triste état de l'informatique actuelle, utiliser un protocole de transfert d'hyper-textes pour transférer des fichiers.

Ça doit plutôt bien fonctionner, vu qu'il y a un marché raisonnable pour faire précisément ça, entre DropBox, Google Drive, One, etc.

Qu'il faille faire intervenir un troisième ordinateur, disons Sierra, pourquoi pas, ce n'est pas pire qu'une mémoire flash ou qu'un fournisseur d'accès à internet. Mais qu'il faille faire intervenir une personne morale supplémentaire, avec un droit de regard direct sur mes fichiers, ça me gène un peu plus. Pour paraphraser Benjamin Bayart, qu'est-ce que mes données foutent sur pas-ma machine ?

J'ai donc entrepris d'écrire un serveur web à cet effet, que j'ai publié en logiciel libre, parce que tout le monde s'en fout éperdument et donc je n'ai aucun risque de le voir forké ou de me faire démonter publiquement. Le dépôt fossil n'est pas encore montrable, mais le miroir sur GitHub est tout à fait fonctionnel.

Il s'agit donc d'un serveur de fichiers publiquement accessible sur le grand 'ternet (et en réseau local, pour peu que l'on l'y déploie). Il est assez évident qu'un serveur de fichiers ouvert à tous les vents va rapidement être abusé, donc il faut trouver un moyen de le sécuriser, mais sans gêner les utilisateurs légitimes.

Ce dernier point exclut les systèmes de comptes et les autres identifications fortes : pour être utile, il faut que ce soit simple et efficace pour un utilisateur quelconque, qu'il contrôle Alpha ou Bravo. Il ne reste donc guère que l'utilisation d'un secret quelque part dans l'URL.

Comme l'utilisateur quelconque peut jouer le rôle d'Alpha, cela implique que techniquement, n'importe qui peut envoyer un fichier, sans aucun contrôle. Pour garder le contrôle, il ne me reste donc que la possibilité de cacher le lien de téléchargement d'un fichier envoyé.

En fait s'il fallait vraiment contrôler avant l'envoi, il resterait la possibilité de créer des quota, avec une identification dans l'URL avant de recevoir le formulaire HTML. Je finirai peut-être par y venir, mais ça implique une interface d'administration pour moi, soit par HTTP avec la complexité de distinguer les utilisateurs quelconque des administrateurs, soit par un autre moyen qui suppose que je ne sois pas coincée derrière un firewall idiot. Avec la difficulté supplémentaire de communiquer ce qui est valide au front-end qui accepte le formulaire avant de donner le contrôle à mon application.

Comment cacher le lien de téléchargement ? En incorporant un secret dans son URL, connu seulement de l'opérateur du serveur (c'est-à-dire moi). Mais sans utiliser d'informations trop profondément cachées dans le serveur, pour pouvoir calculer l'URL sans avoir besoin du serveur.

Quelque chose d'imprévisible modulé par un secret, ça fait immédiatement penser au HMAC. Mais pas un HMAC du fichier, parce que si j'avais le fichier, je n'aurais pas besoin qu'on me l'envoie. Donc plutôt un HMAC du hash du fichier, plus facile à faire parvenir par d'autres canaux.

Le hash du fichier sert en même temps à construire l'URL d'un rapport de téléchargement, aimablement fourni à l'envoyeur, pour qu'il puisse vérifier que l'envoi s'est bien passé en comparait les hash, et au recevoir pour lire commentaires et nom original.

Autre astuce : le HMAC se comporte en fait comme un répertoire, en servant le fichier quelque soit le suffixe, ce qui permet de donner un nom arbitraire (pas forcément le même qu'à l'envoi) au fichier reçu.

Enfin, mon expérience personnelle avec le partage de fichier en utilisant un répertoire servi par HTTP, est que les fichiers s'y accumule et que ce n'est pas toujours facile de retrouver lesquels peuvent être effacés. Donc avec ce serveur, en plus du commentaire qui aide à resituer le fichier, j'attache une date d'expiration, au delà de laquelle le fichier est effacé.

Mon instance est disponible sur upload.instinctive.eu, que je préfère ne pas lier pour éviter les robots pénibles qui n'auraient que faire de robots.txt. Attention, c'est très moche, je n'ai pas encore pris le temps de lui donner une apparence décente (mais c'est moins moche que la page de LibreSSL).


29/07/2014

code. grind. sleep. >> Les stats de PostgreSQL dans un tmpfs avec Proxmox

Tags:

Au ${BOULOT}, on utilise Proxmox pour virtualiser, et surtout des containers OpenVZ (pour les hypeux qui ne jurent que par lxc, c'était et c'est pas encore si sec que ça lxc, faut beaucoup enrober, et on n'a pas le temps). Les machines PostgreSQL se trouvent donc être des containers OpenVZ.

Pour soulager les disques de certains I/O, des fois ça aide de placer le répertoire de travail du stats collector, par défaut $PGDATA/pg_stat_tmp et configurable par le GUC stats_temp_directory sur un ramdisk.

Sauf que dans un container, le guest ne peut pas manipuler ses filesystems, on doit passer par l'hyperviseur. Dans le cas d'OpenVZ, on peut ajouter un programme sous le nom CTID.mount qui permet de monter, justement, un tmpfs. Ce fichier est à placer à coté du fichier de conf, dans /etc/vz/conf.

On decide alors de placer nos stats dans /var/lib/postgresql/tmpfs, un tmpfs en mémoire. On ajoute ces répertoires pour garder la hiérarchie classique des instances PostgreSQL sur Debian : 9.3/main/pg_stat_tmp.

On écrit donc le script shell suivant dans /etc/vz/conf/CTID.mount, ou CTID est le numéro du container :

#!/bin/sh
# Script de montage d'un tmpfs pour les stats de PostgreSQL

# If one of these files does not exist then something
# is really broken
[ -f /etc/vz/vz.conf ] || exit 1
[ -f $VE_CONFFILE ] || exit 1
# Source both files. Note the order is important.
. /etc/vz/vz.conf
. $VE_CONFFILE

mountpoint=/var/lib/postgresql/tmpfs
subdir=9.3/main/pg_stat_tmp
postgres_uid=104
postgres_gid=108
size=104857600 # 100 Mo

mkdir -p ${VE_ROOT}${mountpoint}
mount -t tmpfs -o size=${size},uid=${postgres_uid},gid=${postgres_gid},mode=0700 tmpfs ${VE_ROOT}${mountpoint}
mkdir -p ${VE_ROOT}${mountpoint}/${subdir}
chown -R ${postgres_uid}.${postgres_gid} ${VE_ROOT}${mountpoint}

Dans le script tout ce fait dans le context de l'hyperviseur, c'est pourquoi on utilise les uid/gid numériques de postgres dans le container pour que les permissions soient correctes dès le boot.

Enfin, il ne reste qu'à modifier le fichier postgresql.conf pour configurer stats_temp_directory :

stats_temp_directory = '/var/lib/postgresql/tmpfs/9.3/main/pg_stat_tmp'

On peut alors redémarrer le container sur l'hyperviseur :

# vzctl restart CTID

Et voir depuis le container le nouveau FS :

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/simfs      100G   28G   73G  28% /
tmpfs           100M   12K  100M   1% /var/lib/postgresql/tmpfs
tmpfs           410M   32K  410M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           820M     0  820M   0% /run/shm

28/07/2014

GCU-Squad! >> Xen modes, le retour

Par : pinpin
Tags:
EC2
Irc
Xen
aws
hvm
pv
pvh
pvhvm
virtualization

Parce que c’est bien joli tout ça, mais comment on sait quel mode un guest donné utilise, hein ?

http://www.brendangregg.com/blog/2014-05-09/xen-feature-detection.html proposé par Seb sur #GCU@freenode


28/07/2014

GCU-Squad! >> Xen modes

Par : pinpin
Tags:
Irc
Xen
hvm
pv
pvh
pvhvm
virtualization

Le fin mot de l’histoire sur les différents modes supportés par Xen : tout ce que vous avez toujours voulu savoir, voire un peu plus.

http://www.brendangregg.com/blog/2014-05-07/what-color-is-your-xen.html proposé par Seb sur #GCU@freenode


28/07/2014

Le Blog Maniatux - BSD >> Aperçu de bhyve - Episode 2 vmrc

Par : Xavier
Tags:

Dans l'article Aperçu de bhyve - Episode 1 vmrun.sh nous avons vu que bhyve est intéressant mais que le script vmrun.sh est trop limité pour pouvoir se faire plaisir. Nous allons voir si vmrc nous offre plus de possibilités ou non.

Installation de vmrc

Voyons si vmrc est disponible dans les dépôts pkgng :

# pkg search vmrc

Arf non :( ! Et visiblement il n'est pas non plus dans les ports. Il va falloir l'installer à la main. Bon, commençons par installer git :

# pkg install git

Puis récupérons les sources du projet :

# git clone https://github.com/michaeldexter/vmrc.git

Entrons dans le répertoire et installons le tout à l'aide des script install-vmrc.sh et install-templates.sh :

# cd vmrc
# ./install-vmrc.sh
# cd templates
# ./install-templates.sh

La documentation de vmrc recommande sysutils/grub2-bhyve pour les guest Linux :

# pkg install grub2-bhyve

Utilisation de vmrc

Création d'un guest FreeBSD

Dans le répertoire de vmrc récupéré par git (/root/vmrc dans notre exemple) se trouve le script mkvm.sh qui permet de choisir le type de vm dont on a besoin et d'en automatiser la création et l'installation. Exécutons mkvm.sh :

# cd /root/vmrc
# ./mkvm.sh

Nous pouvons alors choisir le type de VM que nous souhaitons créer :

Listing templates in /usr/local/vmrc/templates/

t_centos65              t_freebsd92stablezfs    t_pfsense-fetch.sh
t_freebsd10             t_freebsd92zfs          t_ubuntu1304
t_freebsd10malloc       t_freenas               t_ubuntu1310
t_freebsd10zfs          t_freenas-fetch.sh      virtio21pf
t_freebsd11current      t_master_template       virtio83
t_freebsd11currentzfs   t_openbsd               virtio83pf
t_freebsd92             t_openbsd-fetch.sh      virtio84
t_freebsd92stable       t_pfsense               virtio91

Enter a template to use:

Ici comme je veux une VM Freebsd classique j'ai sélectionné t_freebsd10 et validé. Ensuite on donne un nom à la vm, j'ai mis freebsd.

Enter a custom name without ID or leave blank to keep vm2
freebsd

Le script va créer un disque virtuel de 2G puis télécharger les différents sets (base.txz et kernel.txz) de FreeBSD pour les installer. Voyons maintenant si on peut booter. Pour cela on va utiliser le service vm qu'on doit activer dans le /etc/rc.conf.local :

vm_enable="YES"

Puis on démarre la vm :

# service vm start freebsd
vm: starting freebsd
vm: freebsd: no configuration file found: Skipping...

Wow ! Cela ne fonctionne pas ! Étrange. Jetons un œil au /usr/local/vmrc/vm :

# ls /usr/local/vmrc/vm/
freebsd2        openbsd01       vm0

Il semble qu'il ait décidé de nommer ma vm freebsd2. Je sens venir les confusions quand on commence à avoir beaucoup de vm, mais peut-être que j'aurais du choisir un autre nom. Bon, soit, utilisons freebsd2 :

# service vm start freebsd2
vm: starting freebsd2
starting freebsd2
Entering f_load()
Entering f_eptcheck()
Entering f_vmmcheck()
f_vmmcheck: vmm.ko kernel module not loaded. Loading...
f_netstart: bridgestp.ko kernel module not loaded. Loading...
f_netstart: if_bridge.ko kernel module not loaded. Loading...
f_netstart: if_tap.ko kernel module not loaded. Loading...
net.link.tap.up_on_open: 0 -> 1
Creating the bridge0 network interface.
Associating em0 with bridge0.
Running: ifconfig bridge0 addm em0 up
f_load: Attaching raw image /usr/local/vmrc/vm//freebsd2/freebsd2.img for fsck
f_load: DEBUG: disk image is /usr/local/vmrc/vm//freebsd2/freebsd2.img; vm_device is md1
f_load: fsck_ufs -y md1p2
** /dev/md1p2
** Last Mounted on /usr/local/vmrc/vm/freebsd2/mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
13303 files, 139007 used, 368296 free (208 frags, 46011 blocks, 0.0% fragmentation)

***** FILE SYSTEM MARKED CLEAN *****
Entering f_mddestroy()
f_mddestroy: Destroying all memory devices associated with freebsd2
f_mddestroy: Destroying mdconfig device: md0
mdconfig: ioctl(/dev/mdctl): Device busy
f_mddestroy: Destroying mdconfig device: md1
f_load: Running the bhyveload command:
/usr/sbin/bhyveload -m 1024 -d /usr/local/vmrc/vm//freebsd2/freebsd2.img freebsd2
Consoles: userboot

FreeBSD/amd64 User boot, Revision 1.1
(root@snap.freebsd.org, Thu Jan 16 22:18:02 UTC 2014)
Loading /boot/defaults/loader.conf
can't find 'kernel'
-
can't load 'kernel'

Type '?' for a list of commands, 'help' for more detailed help.
OK

Bon, ça ne marche toujours, cependant je remarque les points suivants :

Bon, changeons de tty (ctrl+alt+f2 ou alt+f2 pour vmware) et arrêtons la vm :

service vm stop freebsd2

Ensuite retournons en tty1 et voyons ce qui s'est passé. Analysons le contenu de /usr/local/vmrc/vm/freebsd2/mnt pour voir si le kernel est effectivement manquant (on remarque au passage que vmrc a la délicatesse de faire un point de montage, afin de voir depuis l'hôte ce qu'il y a dans le fichier freebsd2.img) :

# ls /usr/local/vmrc/vm/freebsd2/mnt/
.cshrc          bin             lib             proc            sys
.profile        boot            libexec         rescue          tmp
.snap           dev             media           root            usr
COPYRIGHT       etc

Hum, à première vue tout semble correct, mais il semble qu'un fichier kernel soit manquant dans boot/kernel.

Faisons une autre machine virtuelle pour voir, que nous nommons freetest :

# cd /root/vmrc
# ./mkvm

Bon on remarque qu'il la nomme freetest3. Aucune importance, démarrons cette VM

# service vm start freetest3
  ______               ____   _____ _____
 |  ____|             |  _ \ / ____|  __ \
 | |___ _ __ ___  ___ | |_) | (___ | |  | |
 |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
 | |   | | |  __/  __/| |_) |____) | |__| |
 | |   | | |    |    ||     |      |      |
 |_|   |_|  \___|\___||____/|_____/|_____/    ```                        `
                                             s` `.....---.......--.```   -/
 +------------Welcome to FreeBSD-----------+ +o   .--`         /y:`      +.
 |                                         |  yo`:.            :o      `+-
 |  1. Boot Multi User [Enter]             |   y/               -/`   -o/
 |  2. Boot [S]ingle User                  |  .-                  ::/sy+:.
 |  3. [Esc]ape to loader prompt           |  /                     `--  /
 |  4. Reboot                              | `:                          :`
 |                                         | `:                          :`
 |  Options:                               |  /                          /
 |  5. Configure Boot [O]ptions...         |  .-                        -.
 |                                         |   --                      -.
 |                                         |    `:`                  `:`
 |                                         |      .--             `--.
 |                                         |         .---.....----.
 +-----------------------------------------+


Booting...
f_load: freetest3 appears to have loaded.
Entering f_boot()
f_boot: Starting VM Networking. "File exists" warnings are okay.
Running: ifconfig tap8030 create
ifconfig: create: bad value
Running: ifconfig bridge0 addm tap8030 up
ifconfig: BRDGADD tap8030: File exists
Checking for preflight script /usr/local/vmrc/vm//freetest3/freetest3.
preflight.sh

f_boot: Running the bhyveload command:
/usr/sbin/bhyveload -m 1024 -d /usr/local/vmrc/vm//freetest3/freetest3.img freetest3
f_boot: nmdm.ko is loaded.
f_boot: Booting freetest3 on console /dev/nmdm3A
root@FreeBSD:~/vmrc #

Cette fois, cela fonctionne. Donc pour une raison inconnue, la dernière fois l'installation du kernel ne s'est pas terminée correctement.

Connectons-nous à la console de freetest3 :

# service vm attach freetest3

On voit alors toute la séquence de démarrage, puis on arrive au login :

Thu Jul 24 07:21:19 PDT 2014

FreeBSD/amd64 (bhyve) (console)

login:

Question idiote : quel est le mot de passe root défini par mkvm ? Apparemment ce n'est pas root, ce n'est pas vide, ce n'est pas le nom de la vm. Et les instructions ne disent rien à ce sujet. Passons sur le tty2 (ctrl+alt+f2 ou alt+f2) et jetons un œil au script lui-même :

# cat /usr/local/vmrc/templates/t_freebsd10 | grep password
vm_password="bsd" # VM password (clear text for now) (FreeBSD only)

Voilà ! Le mot de passe root est bsd !

Voyons si la connexion à internet fonctionne :

# ping 8.8.8.8

Hum ! Apparemment non ! Essayons de voir pourquoi :

# cat /etc/rc.conf
[...]
ifconfig_vtnet0="192.168.2.210 netmask 255.255.255.0"
defaultrouter="192.168.2.1"
[...]

Hum, ce sous-réseau ne correspond pas au réseau de l'hôte (192.168.232.0/24), donc à moins qu'il y ait du NAT cela ne peut pas marcher aussi facilement. Sur l'hôte, la commande pfctl -sr m'indique que pf ne fonctionne pas. Donc pas de NAT. Jetons un œil au /usr/local/vmrc/vm/freetest3/freetest3.conf :

[...]
vm_ipv4="192.168.2.210"  # VM IPv4 address (blank for DHCP) (FreeBSD only)
vm_gw="192.168.2.1"      # VM IPv4 gateway (FreeBSD only)
[...]

Donc modifions cela pour spécifier une adresse sur la même plage que l'hôte, en partant du principe que vmrc active un bridge :

[...]
vm_ipv4="192.168.232.210"  # VM IPv4 address (blank for DHCP) (FreeBSD only)
vm_gw="192.168.232.1"      # VM IPv4 gateway (FreeBSD only)
[...]

Puis redémarrons la VM :

# service vm restart freetest3

Entrons dans la VM et modifions son /etc/rc.conf :

ifconfig_vtnet0="192.168.232.210 netmask 255.255.255.0"
defaultrouter="192.168.232.1"

Relançons le réseau :

# service netif restart

Lançons maintenant un ping vers internet :

# ping 8.8.8.8

Hum, encore une fois, cela ne marche pas. Essayons un ping vers 192.168.232.1, la passerelle vmware :

 # ping 192.168.232.1
PING 192.168.232.1 (192.168.232.1): 56 data bytes
64 bytes from 192.168.232.1: icmp_seq=0 ttl=128 time=2.127 ms

Cette fois ça fonctionne !

Donc dans mon cas pas d'accès à internet, mais j’émets l'hypothèse suivante : c'est VMware qui refuse les paquets venant de mon bridge.

Le bilan est déjà beaucoup plus positif qu'avec vmrun.sh. Nous sommes parvenus à installer - très facilement - et à faire fonctionner un guest FreeBSD10. Nous n'avons pas pu utiliser le réseau, mais nous n'étions pas loin.

Guest Linux

Reprenons notre ISO de debian, debian-7.6.0-amd64-netinst.iso, et voyons si vmrc va réussir à la booter et à installer un système invité debian. Jetons un œil aux templates :

 # ls /usr/local/vmrc/templates/
t_centos65              t_freebsd92stablezfs    t_pfsense-fetch.sh
t_freebsd10             t_freebsd92zfs          t_ubuntu1304
t_freebsd10malloc       t_freenas               t_ubuntu1310
t_freebsd10zfs          t_freenas-fetch.sh      virtio21pf
t_freebsd11current      t_master_template       virtio83
t_freebsd11currentzfs   t_openbsd               virtio83pf
t_freebsd92             t_openbsd-fetch.sh      virtio84
t_freebsd92stable       t_pfsense               virtio91

Pas de template pour debian :( mais comme je suis fou, je vais prendre le template t_ubuntu1304 et le modifier pour Debian. Je commence par le dupliquer :

# cd /usr/local/vmrc/templates
# cp t_ubuntu1304 t_debian76

Puis j'édite mon template :

# My awesome debian template

vm_cpus="1"              # Number of VM virtual CPUs (max 16)
vm_ram="256"            # VM RAM Allocation in MB
vm_console="nmdm"       # stdio, nmdm, tmux or tmux-detached (sysutils/tmux)
vm_os_type="linux"       # freebsd, openbsd, or linux
vm_os_ver="debian7.6"  # Exact OS version if auto-fetching
vm_dev_layout="gpt"      # "gpt" or "mbr" volume layout (FreeBSD only)
vm_dev_type="img"        # "img" for image, "zvol" or blank for other device
vm_device=""             # An existing device (sans /dev/) i.e. "ada1"
vm_dev_size="10G"         # M or G for raw "img" volumes
vm_hostname=""           # VM hostname (FreeBSD only)
vm_timezone=""           # VM timezone (FreeBSD only)
vm_ipv4_addr=""          # Experimental for jail use
vm_searchdomain=""       # (FreeBSD only) Commented out below
vm_dns_addr=""           # (FreeBSD only) Commented out below
dist_site=""             # Hostname and directory for binary distribution sets
iso_site="http://cdimage.debian.org/debian-cd/7.6.0/amd64/iso-cd/"
                         # Hostname and directory for ISO image
iso_img="debian-7.6.0-amd64-netinst.iso"
                         # ISO filename for remote fetch
grub_boot_cmd="/usr/local/sbin/grub-bhyve -r hd0,msdos1 -m ${host_vmroot}/${vm_name}/device.map -M $vm_
ram $vm_name"
                         # grub-bhyve command to boot from IMG
grub_iso_cmd="/usr/local/sbin/grub-bhyve -r cd0 -m ${host_vmroot}/${vm_name}/device.map -M $vm_ram $vm_
name"
                         # grub-bhyve command to boot from ISO
vm_hostbridge=""         # "amd_" for the AMD hostbridge
bhyve_flags=""           # Additional bhyve(8) flags
virtio_type="virtio-blk" # "ahci-hd" or "virtio-blk"

Ensuite on lance la création de la vm que je vais nommer debian:

# cd /root/vmrc
# ./mkvm.sh

Durant la création de la VM, j'obtiens beaucoup d'erreurs de ce type :

No such file or directory

Je remarque que le template semble se comporter comme pour un guest FreeBSD car je vois passer du loader.conf. Même problème si j'utilise les templates ubuntu fournis. Sont-ils bugués ? Bon, la documentation dit qu'après avoir provisionné la vm, il faut utiliser une commande particulière pour la démarrer vu qu'on utilise une iso. On va partir du principe que le provisionnement est fait et lancer la fameuse commande :

# /usr/local/etc/rc.d/vm iso debian0
vm: booting the ISO for VM  debian0
Entering f_grubcheck()
Entering f_tmuxcheck()
Entering f_eptcheck()
Entering f_vmmcheck()
f_vmmcheck: vmm.ko is loaded.
f_netstart: bridgestp.ko is loaded.
f_netstart: if_bridge.ko is loaded.
f_netstart: if_tap.ko is loaded.
f_netstart: bridge0 exists.
        member: em0 flags=143
f_netstart: em0 is assoc. with host0.
Entering f_iso()
f_iso: /usr/local/vmrc/vm//debian0/debian0.img found.
f_iso: Checking for /usr/local/vmrc/distributions//debian7.6/
f_iso: Checking for /usr/local/vmrc/vm//debian0/debian0.iso
f_iso: Fetching debian-7.6.0-amd64-netinst.iso
/usr/local/vmrc/distributions//debian7.6//debi100% of  222 MB 2520 kBps 01m30s
f_iso: Copying debian-7.6.0-amd64-netinst.iso to /usr/local/vmrc/vm//debian0/debian0.iso
Copying debian-7.6.0-amd64-netinst.iso to /usr/local/vmrc/vm//debian0/debian0.iso
f_iso: Creating /usr/local/vmrc/vm//debian0/device.map
(hd0) /usr/local/vmrc/vm//debian0/debian0.img
(cd0) /usr/local/vmrc/vm//debian0/debian0.iso
f_iso: Running the ISO grub command:
/usr/local/sbin/grub-bhyve -r cd0 -m /usr/local/vmrc//debian0/device.map -M 256 debian0
Could not create VM debian0
Error in initializing VM
funcname: Calling f_boot
Entering f_boot()
f_boot: debian0 is not loaded. Skipping...

Fail... encore une fois, pas moyen de démarrer Linux. Mais j'ai l'impression que cette fois le problème est localisé sur grub2-bhyve, car vmrc a bien téléchargé l'iso et commandé l'exécution de la vm.

L'article étant assez long, on va s'arrêter là.

Crashes et incidents

J'ai observé plusieurs crashes ou comportements étranges avec FreeBSD. J'ai rencontré des freezes du système, mais le bug le plus ennuyeux et le plus fréquent est celui de l'auto-démarrage des vm. En effet, puisqu'on a ajouté vm_enable="YES" au rc.conf.local , les vm sont lancées au démarrage de l'hôte. En soit ce n'est pas grave, sauf que les vm se lancent au premier plan, et bloquent systématiquement sur le bootloader. A ce stade aucune frappe clavier ne peut être prise en compte. Il faut donc redémarrer FreeBSD directement dans la console vmware et appuyer sur CTRL+c au boot pour annuler le lancement des vm. C'est un bug critique et très embêtant qui retire toute possibilité d'utiliser vmrc en production pour le moment. J'ai également fait face à un autre problème étrange : le mot de passe root de l'hôte qui saute. Parfois, après un reboot ou le lancement d'une vm, je suis dans l'incapacité de me logger en root sur l'hote, que ce soit en direct ou en SSH, car le mot de passe est refusé. Je n'ai pas d'autre solution que de me réinitialiser ou charger un snapshot VMware pour revenir en arrière.

Conclusion

vmrc apporte beaucoup par rapport au script vmrun.sh puisqu'il permet d'automatiser l'installation des vm, à la manière de lxc ou ezjail, ce qui nous facilite assez la vie. Cependant seuls les templates FreeBSD semblent fonctionnels et je n'ai toujours pas pu démarrer un guest Linux. Pas d'accès au réseau non plus mais je ne tire pas de conclusions sur ce point. Enfin on sent le côté expérimental de vmrc avec des bugs critiques au démarrage de l'hôte notamment, qui empêchent toute utilisation en production pour le moment. J'essaie de contacter l'auteur de vmrc pour obtenir de l'aide sur ce point. vmrc est un projet intéressant à suivre.

Dans le prochain