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


26/07/2014

Le Blog Maniatux - BSD >> Retour sur Debian GNU/kFreeBSD dans une jail FreeBSD

Par : Xavier
Tags:

Dans un précédent article j'ai résumé comment installer Debian GNU/kFreeBSD Wheezy dans une jail FreeBSD 10 et indiqué que j'avais migré le serveur hébergeant mon blog : Maniatux.fr : Debian GNU/kFreeBSD + IPv6 . Voici un petit retour d'expérience sur Debian GNU/kFreeBSD, que j'appellerai kfreebsd parce que c'est plus court.

Tout d'abord il vaut mieux utiliser la branche Jessie, et pas Wheezy car il y a quelques bugs gênants comme OpenSSH qui ne fonctionne pas à moins de devoir faire pas mal de bidouilles sur l'hôte. De plus la branche kfreebsd de Jessie est développée sur un kernel FreeBSD10, alors que pour Wheezy c'est un FreeBSD8, on s'assure donc en théorie une meilleure compatibilité.

Maniatux tournait sur une jail FreeBSD avec nginx et php_fpm compilés à partir des ports. Suite au passage en kfreebsd, avec toujours nginx et php5-fpm à partir d'apt-get, j'ai noté une baisse des performances d'affichage de mes pages, et une hausse du load average sur mon serveur. C'est très faible mais tout de même notable à l'utilisation. La commande top semble indiquer que c'est php5-fpm qui est le plus gourmand de tous, la version fournie par debian n'étant probablement pas la même que dans les ports.

A propos de la commande top, l'indicateur d'utilisation de la ram ne semble plus fiable avec des jails sous kfreebsd. Par exemple si je lance htop dans ma jail kfreebsd, il m'indique que le système utilise 120Mo de ram. Si j'installe htop directement sur l'hôte et l'exécute, il n'indique que ~30Mo. Dans la jail kfreebsd il n'est pas évident d'utiliser df car il faut exécuter une commande permettant d'extraire les informations de /proc/mounts et le résultat n'est pas toujours optimal.

Si on met de côté ces quelques points, mon impression est plutôt positive. Debian (le projet) a fait un super travail en portant son système d'exploitation sur FreeBSD, et cela n'a pas été fait à la va vite. Il y a véritablement un support suivi et cela prouve une fois de plus que Debian est une distribution de référence.


23/07/2014

Le Blog Maniatux - BSD >> Aperçu de bhyve - Episode 1 vmrun.sh

Par : Xavier
Tags:

bhyve est un hyperviseur pour FreeBSD qui utilise les capacités de virtualisation du CPU (VT-x + EPT chez Intel et AMD-V + RVI chez AMD) et fourni des périphériques virtuels VirtIO aux systèmes invités. En un sens c'est une alternative à Linux-KVM pour FreeBSD. Cette solution vient en complément des jails qui se limitent à faire tourner du FreeBSD. bhyve supporte déjà des systèmes invités Linux, FreeBSD et OpenBSD. On ne sait pas encore si Windows sera supporté, mais c'est très probable. bhyve n'émule pas encore de bios ni de carte VGA, ce qui signifie que vous allez devoir travailler en mode texte, exactement comme pour les jails.

Il est intéressant de noter que bhyve est déjà pris en charge par libvirt, ce qui vous permet de gérer et piloter vos VM grâce à cette API, en local ou via une console distante (virt-manager). Je testerai cela probablement dans un prochain article.

Du virtuel dans du virtuel

Je n'ai pas de machine physique libre ayant les pré requis pour bhyve, c'est à dire avec un processeur suffisamment récent pour supporter à la fois VT-x et EPT. J'ai donc utilisé mon ordinateur portable de 2012 équipé d'un i5, sur lequel tourne Windows 7 (pour le travail) et sur lequel j'installe VMware Workstation. Pourquoi VMware ? Parce qu'il fourni une fonctionnalité intéressante : le support de nested VT-x. En gros la machine virtuelle que vous faites tourner peut elle-même faire tourner des machines virtuelles. Donc je vais pouvoir créer dans VMware une machine virtuelle FreeBSD, puis exécuter bhyve dans cette dernière afin de faire tourner d'autres VM dedans.

A noter que VirtualBox ne supporte pas le nested VT-x, ce qui signifie que votre VM FreeBSD ne pourra pas exécuter bhyve car absence d'accès aux instructions VT-X + EPT du CPU hôte.

Allons-y

Le site du projet bhyve fourni un lien vers un fichier texte contenant les instructions. Donc je me contente de les suivre pour le moment.

Charger les modules

Pour charger les modules de manière volatile :

# kldload vmm
# kldload if_tap

Note : Si une erreur s'affiche au chargement du module vmm, il est probable que votre processeur ne soit pas supporté, ou qu'il ne dispose pas des instructions VT-x ou EPT.

Pour charger les modules de manière persistante (au reboot), éditez le fichier /boot/loader.conf

vmm_load="YES"
if_tap_load="YES"

Récupérer le script d’exécution

Le script d’exécution devrait être présent dans /usr/share/examples/bhyve/vmrun.sh mais il est également possible de le récupérer à cette adresse :

# fetch http://people.freebsd.org/~neel/bhyve/vmrun.sh

Ce script va gérer la création de la VM, le montage de l'iso ,d'un périphérique de stockage et d'une interface réseau. Rendons-le exécutable :

# chmod +x vmrun.sh

Guest FreeBSD

Récupérer une ISO de FreeBSD 10 :

fetch http://people.freebsd.org/~neel/bhyve/release.iso.iso

Démarrer la VM :

./vmrun.sh vm1

Le bootloader du FreeBSD invité devrait alors s'afficher.

Après le chargement du kernel, on obtient une magnifie erreur de point de montage root non trouvé :

J'ai trouvé ce fil de discussion qui explique une solution de contournement, mais le problème c'est que je ne peux rien saisir au clavier, les caractères ne sont pas pris. Bug ? Limitation due à l'utilisation de VMware ? Il semblerait plutôt que ce soit un problème de console non adaptée.

Bon, faisons un deuxième essai. La FAQ de Bhyve mentionne l'existence d'images RAW de FreeBSD11-CURRENT conçues exprès pour démarrer dans Bhyve. Commencez par visiter le FTP avec l'adresse suivante : http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/11.0-CURRENT/amd64/Latest/ afin de repérer le nom de l'image. Ensuite récupérez cette image avec fetch (commande non détaillée car l'URL est trop longue).

Ensuite supprimons le fichier release.iso pour ne pas qu'il soit capturé par vmrun.sh, décompressons notre image RAW, et démarrons le tout :

# rm release.iso
# unxz FreeBSD-11.0-CURRENT-amd64-20140714-r268622.raw.xz
# ./vmrun.sh -d FreeBSD-11.0-CURRENT-amd64-20140714-r268622.raw vm1

Et cette fois ça marche. On arrive au login, il suffit d'entrer "root" sans mot de passe, et on accède à notre système virtuel FreeBSD 11 :

Pas d'accès au réseau pour le moment, mais c'est normal car la carte tap0 crée par le script vmrun.sh n'est reliée à rien (ni bridge ni routage). Il ne semble pas possible pour le moment de "sortir" de la vm ou de l'éteindre avec la commande shutdown. Cette dernière commande ne fera qu'arrêter le système guest, mais bhyve continuera de fonctionner. La solution constite à passer sur un autre tty (ALT+F2) et utiliser la commande suivante :

# bhyvectl --destroy --vm=vm1

Bhyve fonctionne plutôt bien mais est extrêmement basique, beaucoup de choses se font manuellement et l'émulation d'un CDROM ne semble pas vraiment au point puisque FreeBSD10 n'a pas réussi à booter. L'utilisation d'une image FreeBSD-11 toute prête a permis de contourner le problème, le boot s'est déroule bien et le clavier est pris en charge.

J'ai expliqué mon problème de FreeBSD10 qui ne boote pas sur irc (#bhyve), on m'a recommandé d'utiliser vmrc. Cela fera peut-être l'objet d'un prochain article.

Guest Linux

bhyve affirme supporter les guest Linux. Faisons donc un essai avec Debian Wheezy.

# fetch http://cdimage.debian.org/debian-cd/7.6.0/amd64/iso-cd/debian-7.6.0-amd64-netinst.iso

Ensuite démarrons cette VM à l'aide du script vmrun.sh mais en spécifiant cette fois l'emplacement de l'ISO :

# ./vmrun.sh -I debian-7.6.0-amd64-netinst.iso vm2

Le test va être rapide car cela ne marche pas du tout :

En l'absence de BIOS ou UEFI, bhyve n'est pas capable de booter tout seul. La FAQ de bhyve indique la nécessité d'utiliser sysutils/grub2-bhyve. On va s'arrêter là et miser sur vmrc dans un prochain article car il parait que tout ceci est alors automatisé.

Conclusion

Cette première découverte de bhyve est très intéressante. L'idée est bonne, utiliser la virtualisation matérielle VT-x + EPT et VirtIO pour les périphériques, ce qui assure en théorie le maximum de performances. Malheureusement son utilisation n'est vraiment pas évidente, on sent le côté expérimental de la chose. bhyve est un produit encore brut qu'il faudra exploiter avec de meilleurs outils.


21/07/2014

Le Blog Maniatux - BSD >> pf.conf pour FreeBSD + IPv6 tunnel

Par : Xavier
Tags:

Mon serveur tourne sur FreeBSD 10 et les services sont fournis par des jails sous Debian GNU/kFreeBSD. J'ai activé pf, le pare-feu sur l'hôte avec quelques règles de filtrage pour grosso modo tout autoriser en sortie, mais bloquer en entrée ce qui n'est pas désiré. Ces règles n'agissent que sur la partie IPv6 car je me repose sur le NAT de la box et les redirections de port pour filtrer ce qui entre l'IPv4.

Exemple

Dans l'exemple ci-dessous on va considérer les adresses suivantes :

Configuration

Note : Je me suis basé sur cette documentation chez SixXs.

/etc/rc.conf.local

# PF
pf_enable="YES"
pflog_enable="YES"

/etc/pf.conf/

# Macros
sendpoint = "2001:470:c851::1" # Votre Server IPv6 Address
cendpoint = "2001:470:c851::2" # Votre Client IPv6 Address
www = "2001:470:c851::1001" # ip de la jail www
mail = "2001:470:c851::1002" # ip de la jail mail
ext_inf = "gif0" # Mon interface tunnel

# don't filter l0
set skip on l0

# scrub incomming packets
scrub in all

# block in/out on $tun_if
block in log on $ext_inf inet6
block out log on $ext_inf inet6

# allow heartbeat ping
pass in quick on $ext_inf inet6 proto { ipv6-icmp } from $sendpoint to $cendpoin
t keep state

# pass tcp, udp, and icmp6 out on the ipv6 tunnel interface.
pass out quick on $ext_inf inet6 proto { tcp udp ipv6-icmp } keep state

# www jail
pass in quick on $ext_inf inet6 proto tcp from any to $www port { 80 443 }

# mail jail
pass in quick on $ext_inf inet6 proto tcp from any to $mail port { 25 143 587 }

Vérifier

pf dispose d'une commande pour vérifier un fichier de configuration :

# pfctl -vnf /etc/pf.conf

Charger

Lorsque la vérification est OK, on peut charger :

# service pf restart

Test en ligne

Certains sites vous proposent de scanner vos ports en ligne, notamment ce site. Il supporte les navigateurs en mode texte donc vous pouvez faire le scan directement depuis votre serveur ;)

Ressources


03/07/2014

Mon chti blog >> Fossil, ssh et nanojail

Tags:
fossil
sjail
sshd

Aimant avoir le contrôle de mes développements, je n'ai pas succombé aux sirènes des forges et préfère utiliser fossil.

Ce système de contrôle de version fournit, au sein d'un unique binaire, tout ce qu'on peut attendre de ce type d'outil et réussit le tour de force d'intéger un wiki et un gestionnaire de ticket.

Voyons comment mettre en place ce service à partir des ingrédients suivant:

Fixons les objectifs:

Commençons par créer une jail à l'aide de sjail:

$ cd $HOME && mkdir -p tmp/sjail && fetch -o sjail.tar.gz 'http://fossil.bsdsx.fr/sjail/tarball/sjail.tar.gz?uuid=trunk'
$ alias sjail $HOME/tmp/sjail/sjail
$ cd $HOME && mkdir -p tmp/fossil && cd tmp && sjail fossil init
If you need log, don't forget to add '-l /usr/home/dsx/tmp/fossil/var/run/logpriv'
on syslogd_flags and restart (not reload) syslogd
You could edit /usr/home/dsx/tmp/fossil/usr/local/etc/pkg/repos/sjail.conf before adding any package to match your configuration

Avant d'ajouter /usr/sbin/sshd les plus curieux iront regarder $HOME/tmp/sjail/_sjail_usr_sbin_sshd:

$ sjail fossil /usr/sbin/sshd

Un soupçon de configuration (à adapter suivant vos goûts):

$ cat >> fossil/etc/ssh/sshd_config
UseDNS no
UsePAM no
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
StrictModes no
AuthorizedKeysFile /etc/ssh/authorized_keys
AllowGroups src
^D

Pour faire court: j'interdis un maximum de chose et je centralise les clefs des utilisateurs. De toute façon, leur $HOME sera en lecture seule, aucune raison qu'ils y déposent quoi que ce soit.

ATTENTION à StrictModes ! L'arborescence générale de mes jails n'est pas créée par root et cela peut poser problème avec sshd. Sans cette directive, fossil/etc/ssh doit appartenir à root ce qui n'est pas le cas chez moi. Ce n'est pas une faille de sécurité mais un contrôle supplémentaire. L'objectif est de pouvoir manipuler le fichier des clefs depuis l'hôte.

Je rajoute à cette jail /usr/sbin/daemon afin que fossil tourne en temps qu'utilisateur non privilégié:

$ sjail fossil /usr/sbin/daemon
$ sjail fossil pkg install fossil

Passons à la configuration desdits utilisateurs:

$ cat >> fossil/etc/pw.conf
defaultpasswd no
home /repos
homemode 500
shells sh
defaultshell sh
defaultgroup src
minuid 30000
maxuid 31000
^D

Il est temps de créer ce fameux groupe src:

$ sudo chroot fossil pw groupadd src -g 30000

Et un utilisateur toto:

$ sudo chroot fossil pw useradd toto -c 'toto commiter' -m
Password for 'toto' is: 3bzM/cNT
$ grep ^toto fossil/etc/passwd
toto:*:30000:30000:toto commiter:/home/toto:/bin/sh
$ ls -la fossil/home/
total 12
drwxr-xr-x  3 root   wheel  512 Jul  1 22:03 .
drwxr-xr-x  6 dsx    wheel  512 Jul  1 22:00 ..
dr-x------  2 30001  30000  512 Jul  1 22:03 toto

Le service fossil sera exécuté (froidement) par l'utilisateur nobody, je crée le répertoire /repos avec les droits kivonbien:

$ mkdir fossil/repos && sudo chown -R nobody:30000 fossil/repos && sudo chmod -R 775 fossil/repos

La configuration de la jail (attention à la configuration réseau à adapter):

$ cat /etc/jail.conf
exec.clean;
mount.devfs;
exec.jail_user = "root";
exec.consolelog = "/var/log/jails/$name";
fossil {
        path = "/home/dsx/tmp/fossil";
        host.hostname = "fossil.bsdsx.fr";
        ip4.addr = lo1|10.30.12.2;
        exec.start = "/usr/sbin/sshd -e";
        exec.start += "/usr/sbin/daemon -c -u nobody /usr/local/bin/fossil server --files *.json,*.html,*.js,*.css,*.txt --notfound /index.html /repos";
}
$ sudo jail -c fossil
fossil: created

Il me faut une clef pour mon utilisateur toto afin de tester l'accès par ssh:

$ ssh-keygen -q -t rsa -N "" -C "toto's rsa key" -f toto
$ cat toto.pub >> fossil/etc/ssh/authorized_keys
$ ssh -F /dev/null toto@10.30.12.2 -i toto
The authenticity of host '10.30.12.2 (10.30.12.2)' can't be established.
RSA key fingerprint is 2f:e7:02:1c:cc:65:00:06:1b:4d:75:6c:f0:11:e8:cf.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.30.12.2' (RSA) to the list of known hosts.
$ echo /*bin/*  /usr/*bin/* /usr/local/*bin/*
/bin/sh /sbin/ldconfig /usr/sbin/daemon /usr/sbin/nologin /usr/sbin/pw /usr/sbin/pwd_mkdb /usr/sbin/sshd /usr/local/bin/fossil
$ ls
ls: not found
$ echo pouet > toto
cannot create toto: Permission denied

Fervent adepte de chroot, je pensais pouvoir utiliser la commande suivante pour créer un premier projet:

$ sudo chroot -u nobody fossil /usr/local/bin/fossil init /repos/systemd.fossil
invalid home directory: /root

Après avoir essayer:

J'en suis arrivé à la conclusion suivante: on ferait mieux de commencer par le commencement.

$ sudo chroot -u nobody fossil/ /bin/sh 
$ echo $HOME
/root

Tout s'explique. Je disais donc, initialisons un projet de domination du monde:

$ sudo chroot -u nobody fossil /bin/sh -c 'HOME=/repos; /usr/local/bin/fossil init /repos/systemd.fossil'
project-id: 7e8592bc69fbccb40162ef6a17235b8945ed6225
server-id:  c59ad0fe02d3f67d11d2406a951d53602d4cd027
admin-user: root (initial password is "1abd87")

C'est pas encore ça. Mêmes maux, mêmes remèdes:

$ sudo chroot -u nobody fossil /bin/sh -c 'HOME=/repos; USER=nobody; /usr/local/bin/fossil init /repos/systemd.fossil'
project-id: a8581c262d2925e760718319cf5e65287afe60d0
server-id:  22dca47163f6911ba39aba051643418e11364db0
admin-user: nobody (initial password is "4ae1c5")

Est-ce que notre utilisateur toto peut commiter ?

$ cat ~/.ssh/config
Host fossil
    User toto
    IdentityFile ~/.ssh/toto
    IdentitiesOnly yes
$ cd && mkdir -p src/toto && cd src/toto && mkdir src fossils
$ fossil clone ssh://fossil//repos/systemd.fossil fossils/systemd.fossil

ATTENTION !!! Le double / devant repos n'est pas une typo !

Round-trips: 2   Artifacts sent: 0  received: 3
Clone finished with 543 bytes sent, 1044 bytes received
Rebuilding repository meta-data...
  100.0% complete...
project-id: a8581c262d2925e760718319cf5e65287afe60d0
admin-user: dsx (password is "077a9a")
$ cd src/
$ fossil open ../fossils/systemd.fossil 
project-name: <unnamed>
repository:   /usr/home/dsx/src/toto/src/../fossils/systemd.fossil
local-root:   /usr/home/dsx/src/toto/src/
config-db:    /home/dsx/.fossil
project-code: a8581c262d2925e760718319cf5e65287afe60d0
checkout:     8c1b91007ea057d7e9d1a7fbddde1f88b7c4ef45 2014-07-03 19:05:16 UTC
leaf:         open
tags:         trunk
comment:      initial empty check-in (user: nobody)
checkins:     1
$ touch neuneu && fossil add neuneu && fossil commit -m 'add neuneu' neuneu
ADDED  neuneu
Autosync:  ssh://fossil//repos/systemd.fossil
Round-trips: 1   Artifacts sent: 0  received: 0
Pull finished with 319 bytes sent, 228 bytes received
New_Version: 4fcf2e727ba9e86eb64d5dc9ea1c967a7fe9ff59
Autosync:  ssh://fossil//repos/systemd.fossil
Round-trips: 1   Artifacts sent: 2  received: 0
Sync finished with 518 bytes sent, 282 bytes received

Cerise(s) sur le gâteau

Qui dit ssh pense aussitôt FORCE_COMMAND

$ cat fossil/etc/ssh/authorized_keys
command="/usr/local/bin/fossil http /repos/systemd.fossil" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDCsZv7o9FjGBW8hpLcCuqE2EC8Togg01M7b5B7k2ogYz+ZnntIwiQcRy9MEUMfY7rK0fhnKiJNd7lg1jUwoZMjbkIOuc/AKe8V3HLALDY/1609IzAb243sVgRGEG6Ezfi2l/PT6Ej2mldwx99L7plXgIZwA5JEdjiaz2SczxtZDAJoBJm1R/lmBc7Min0shV4hzXRcUZ0ncPs84OAfd8hiKbbSOSvhLyqebBmHpUHRiMX6AZkQaUv/JHxl/gPoL996DAPdWso1G0vpniYWw/EFqGVb0D+8omnccpJ/q0hXF/SsuZbeaTcNZX1H8DRgL5+7Bs/ZHZb1Kuhj3iucs8kV toto's rsa key
$ fossil clone ssh://fossil//repos/systemd.fossil fossils/systemd.fossil
Round-trips: 2   Artifacts sent: 0  received: 3
Clone finished with 543 bytes sent, 1045 bytes received
Rebuilding repository meta-data...
  100.0% complete...
project-id: 816a46cf938e770be7dde7323969efdb6e13eb70
admin-user: dsx (password is "cbfaa5")
$ ssh fossil
^CConnection to fossil.bsdsx.fr closed.

Avantages:

Est-ce qu'on peut encore faire mieux ? Je pense que oui:

Ombre(s) sur le gâteau

fossil est lancé en tant qu'utilisateur nobody, il ne peut donc pas écouter sur un port inférieur à 1024 (ce qui tombe bien car par défaut il écoute sur 8080). Mais comment accéder à l'interface web ? La raréfaction des adresses ipv4 impose bien souvent l'utilisation d'un reverse proxy tel que nginx. Pour l'ipv6, il faudra jouer de la redirection de port (80 -> 8080).

Retours

Remarque pertinente (comme à son habitude :) de Natacha: définir le HOME des utilisateurs à /repos. Premier effet kisskool:

$ fossil clone ssh://fossil//repos/systemd.fossil fossils/systemd.fossil
# devient
$ fossil clone ssh://fossil/systemd.fossil fossils/systemd.fossil

Deuxième effet kisskool: inutile de créer des répertoires pour les utilisateurs:

$ sudo chroot fossil pw useradd toto -c 'toto commiter' -m
# devient
$ sudo chroot fossil pw useradd toto -c 'toto commiter'

et

$ cat >> fossil/etc/pw.conf
defaultpasswd random
home /home
homemode 500
shells sh
defaultshell sh
defaultgroup src
minuid 30000
maxuid 31000
^D
# devient
$ cat >> fossil/etc/pw.conf
defaultpasswd random
home /repos
shells sh
defaultshell sh
defaultgroup src
minuid 30000
maxuid 31000
^D

Contre effet kisskool: le $HOME des utilisateurs devient accessible en écriture mais contre contre effet kisskool avec la commande forcée par la clef.

Merci Natacha !

Retour bis

Les perfectionnistes pourront:


02/07/2014

Emile "iMil" Heitor 's home >> Back to 2000-2005: FreeBSD desktop

Par : iMil
Tags:
Blogroll
Desktop
FreeBSD
NetBSD

A while ago, I had my ${DAYWORK} workstation running NetBSD, and honestly, it did pretty well. Things began to become more painful when there was no more DRI acceleration with the radeon driver, it then did an okay-ish job, but the overall desktop became somewhat laggy.
It was told someone was working on porting KMS/GEM, that was more than a year ago, and as of today, that work -and I guess it is not an easy one- isn’t mature enough to be used as a workstation, I need my desktop to run various tools, and not only terminal-based ones.
Two weeks ago, I asked for a new desktop, more powerful, so I can run more virtual machines with it. That new box was shipped with an nvidia graphic card and various modern components which I knew were not supported by NetBSD. This is one regret I have about that beautiful project, running on VAX, PlayStation 2 and Amiga is fun, but I’ll tell you a little secret: nobody cares anymore about VAX, PlayStation 2 and Amiga.
So I gave FreeBSD 10 a try. And I was not disappointed: everything, and I mean everything worked almost out-of-the-box. Of course there was a bit of fighting with the proprietary nvidia driver, but it worked as expected with 3D acceleration and all.
Not everything is perfect either, but I must say FreeBSD does a great job as a workstation, actually, it does what I needed: display a decent 2014 hardware powered desktop, no more, no less.
Under no circumstances will I replace my NetBSD servers / virtual machines (as long as they still support the underlying hardware!), they do an amazing job and I am quite happy with them, but don’t expect desktop-related commits from me to pkgsrc for the time being…

Update

Well well, this blogpost have bring much unexpected rage. Just to clarify: this is definitely not a troll or whatsoever, only an end user opinion on what’s preventing me of using NetBSD as a desktop at work for the moment.
Read the previous sentence a couple of times and notice the word “work”, the place where you can’t spend countless hours patching / tuning / trying / crashing / rebooting (sounds like a Daft Punk song) before you can reply to an urgent customer inquiry. Yes, that place. The only thing I say is: FreeBSD, as of today, does a better job at being an out-of-the-box modern desktop.
I will continue to use NetBSD as my server OS of choice, because it does rock, because it is stable, simple and fills the task perfectly. As soon as it doesn’t anymore, I’ll switch to something else, that’s what I do. Pragmatic.
So yes, I have the weakness to like shiny desktops that run something else than twm, I like transparency, I like effects when I change my virtual desktop, I like my windows to be displayed and moved rapidly, you know, pretty much like all those BSD developers that actually use OSX because it does all those things.
I will also continue contributing to pkgsrc, because it is in my optinion the most beautifull packaging system around, all I’m saying is that I won’t commit desktop-related tools I can’t really test or use. Nothing more.

The post Back to 2000-2005: FreeBSD desktop appeared first on Emile "iMil" Heitor 's home.


01/07/2014

Emile "iMil" Heitor 's home >> Back to 2000-2005: FreeBSD desktop

Par : iMil
Tags:
Blogroll
Desktop
FreeBSD
NetBSD

A while ago, I had my ${DAYWORK} workstation running NetBSD, and honestly, it did pretty well. Things began to become more painful when there was no more DRI acceleration with the radeon driver, it then did an okay-ish job, but the overall desktop became somewhat laggy.
It was told someone was working on porting KMS/GEM, that was more than a year ago, and as of today, that work -and I guess it is not an easy one- isn’t mature enough to be used as a workstation, I need my desktop to run various tools, and not only terminal-based ones.
Two weeks ago, I asked for a new desktop, more powerful, so I can run more virtual machines with it. That new box was shipped with an nvidia graphic card and various modern components which I knew were not supported by NetBSD. This is one regret I have about that beautiful project, running on VAX, PlayStation 2 and Amiga is fun, but I’ll tell you a little secret: nobody cares anymore about VAX, PlayStation 2 and Amiga.
So I gave FreeBSD 10 a try. And I was not disappointed: everything, and I mean everything worked almost out-of-the-box. Of course there was a bit of fighting with the proprietary nvidia driver, but it worked as expected with 3D acceleration and all.
Not everything is perfect either, but I must say FreeBSD does a great job as a workstation, actually, it does what I needed: display a descent 2014 hardware powered desktop, no more, no less.
Under no circumstances will I replace my NetBSD servers / virtual machines (as long as they still support the underlying hardware!), they do an amazing job and I am quite happy with them, but don’t expect desktop-related commits from me to pkgsrc for the time being…

The post Back to 2000-2005: FreeBSD desktop appeared first on Emile "iMil" Heitor 's home.