Troll : Debian stable ? Obsolète ?
Classé dans : Réflexions, OS | 7 commentaires | publié le 05 mars 2014

Puisque l'actualité Linux est au ralenti on en vient à ressortir des vieux troll, notamment sur l'utilité de forker à tout-va, en utilisant la plupart du temps une base debian ou ubuntu. Cep cite et réfute l'hypothèse que ces forks sont motivés par l'obsolescence de Debian. Il n'en fallait pas moins pour déclencher un troll et même un clash entre blogueurs.

En effet à première vue la Debian Stable n'est pas toute fraiche, Wheezy utilise un kernel 3.2 ce qui nous ramène à l'été 2012 et contrairement à RedHat/CentOS, on ne backporte rien dedans. Cela peut être problématique pour certains ordinateurs équipé de matériel récent. Je prends pour exemple pour Asus B43 que j'ai acheté en 2012. A l'époque j'ai pris soin de choisir du matériel 100% intel en génération n -1 pour que ce soit pleinement compatible Linux. Le problème est qu'il existe un bug avec la gestion de l'énergie de la carte vidéo, qui a été corrigé à partir du kernel 3.3. Lors de l'achat, Debian était en version 6 et venait avec un kernel 2.6.32. Aujourd'hui, Debian est en version 7 avec un kernel 3.2. Donc pour avoir un kernel > 3.2 il faut attendre Jessie, qui n'arrivera probablement pas avant la fin 2015. Faisons le calcul, 2015-2012 = 3 ans. Pour utiliser Debian stable sur ma machine je dois donc attendre 3 ans.

Donc oui, pour le desktop il est clair que Debian se traine, il est préférable d'utiliser les dérivés, je pense notamment à Kubuntu, Xubuntu ou Fedora selon le format de paquet désiré. Est-ce le mot de la fin ? Non. En entreprise il n'est pas rare de travailler sur des versions très anciennes des logiciels, j'ai vu des postes de travail déployés en Windows XP à la fin 2012 (Windows 7 était pourtant sorti depuis 3 ans), et même des serveurs en Windows 2000 pour garder une compatibilité avec le matériel et les logiciels. Cyrille Borne déclare maintenir un parc de Debian stable dans son établissement parce que c'est le seul système Linux qui continue à fonctionner au fil du temps et des mises à jour.

Il semble donc que Debian stable et ses vieux logiciels trouve un public en entreprise et sur les serveurs, là où le mot d'ordre est "si ça marche touche-z-y pas" et où nouveauté est synonyme de plantages et incompatibilités.

En conclusion j'en reviens à citer mon troisième paragraphe : pour un bon compromis stabilité / nouveauté, essayez les (x)ubuntu, les Fedora, les Mint. Pour les utilisateurs exigeants qui en sont au stade de la bagarre pour faire marcher correctement leurs machines, Debian est un bon choix.

Migration du serveur sous FreeBSD 9.2
Classé dans : Serveur, Virtualisation, OS, Planet-Libre | 1 commentaire | publié le 22 janvier 2014

EDIT : Oui je sais, FreeBSD 10 vient de sortir, je suis d'ailleurs l'un des auteurs de cette dépêche sur Linuxfr. Mais quand j'ai commencé à migrer mon serveur, c'était encore la 9.2 qui était stable. Et avec les jails et les ports je préfère éviter de tourner sur les versions non stables...

Puisque mon serveur perso n'est pas critique (je peux me permettre une coupure d'une journée) j'en profite changer l'OS assez souvent, en quête de la perle rare ou tout simplement pour apprendre de nouvelles choses. Actuellement mon serveur ne sert que pour Jabber et la messagerie, mais à terme j'aimerai récupérer l'hébergement de mon blog (web). Or je souhaite séparer la partie web et messagerie pour la sécurité. Pour cela plusieurs solutions :

  • Utiliser 2 serveurs : très consommateur en énergie et prend plus de place.
  • Utilisez Linux + KVM (virtualisation) : incompatible avec mon serveur (Atom 32 bits).
  • Utiliser Linux + LXC ou Linux + OpenVZ : LXC déjà exploré j'ai envie d'autre chose.
  • Utiliser FreeBSD + Jails : Ouais !!!

Schéma cible

Compilation vs packages binaires

Bien que mon serveur soit de faible puissance, j'ai choisi de compiler moi-même les ports. Pourquoi ? Simplement parce que les packages binaires sont trop basiques et n'incluent pas les options sont j'ai besoin. Exemple : pour le serveur web, j'avais besoin du support fpm pour php. Or le seul moyen pour avoir cela c'est de compiler soi-même le paquet php55 et activer l'option fpm. Avec le package binaire officiel, pas de fpm.

Hôte : TARDIS

L'hôte est FreeBSD 9.2 i386 installé en UFS, avec les rôles d'hôte pour les jails et serveur DNS (named). Pour l'instant uniquement du cache, on verra ultérieurement s'il y a besoin de déclarer des zones. Named est installé dans le système de base, donc aucune manipulation particulière à faire à part l'activer dans le rc.conf et commenter la petite ligne dans /var/named/etc/namedb/named.conf qui spécifie qu'il ne faut écouter qu'en 127.0.0.1. Pour gérer mes jails, j'utilise ezjail, un outil de fainéant qui permet non seulement de tout gérer très facilement, mais en plus de générer un template avec des montages dynamiques.

root@TARDIS:~ # jls

   JID  IP Address      Hostname                      Path

     1  192.168.0.4     xmpp                          /usr/jails/xmpp

     2  192.168.0.3     www                           /usr/jails/www

     3  192.168.0.2     mail                          /usr/jails/mail

Pour que toutes mes nouvelles jail utilisent le bon serveur DNS, il faut éditer le fichier /usr/jails/newjail/etc/resolv.conf et ajouter l'IP qui va bien.

Jail : mail

La jail mail est destinée à recevoir, stocker, envoyer des mails. J'utilise un backend sqlite que j'ai mis en place en suivant ce tutoriel très complet (légère adaptation à faire pour utiliser sqlite à la place de mysql). Il faut commencer par installer dovecot2 en activant le support sqlite. Puis on installe Postfix en activant aussi le support sqlite mais également l'authentification SASL via dovecot. Je voulais que mon serveur de messagerie puisse gérer plusieurs domaines, d'où mon choix d'une structure plus complexe avec un backend sql.

Lorsqu'un mail est reçu, il est traité par Postfix qui vérifie dans la base sqlite si le domaine existe bien. Si oui il le transmet alors à Dovecot qui va se charger de le stocker à l'emplacement qui va bien. Lorsqu'un utilisateur veut envoyer un mail, il le soumet à Postfix (submission 587) qui demande à Dovecot si l'utilisateur est authentifié. Tous les échanges sont sécurisés en STARTTLS.

Jail : www

La jail www est destinée à faire office de serveur web. Pour l'installation de php, il faut compiler php55 avec le support de fpm, mais aussi php55-extensions qui permet de supporter session, gd (requis par pluxml), et d'autres si besoin.

C'est sur cette jail que mon blog (maniatux.fr) sera bientôt rapatrié. L'adresse e-mail de contact sera elle rapatriée sur la jail précédente (mail) car comme je l'ai indiqué, je peux gérer plusieurs domaines. Pluxml étant très léger et sans base de données, le serveur devrait tenir.

Jail : xmpp

La jail xmpp est destinée à faire office de serveur Jabber. J'utilise une fois de plus Prosody, que j'ai couplé avec sqlite pour le stockage des comptes (je n'aime pas le stockage en clair dans /var/lib/prosody qui est utilisé par défaut). La mise en place a été assez compliquée car en cas d'erreur, Prosody refuse de démarrer mais n'indique pas pourquoi. J'ai du spécifier un emplacement pour les logs et mettre les bons droits dessus (chown -R prosody:wheel) afin d'avoir un debug. En fait il n'arrivait pas à écrire le pid. Pour pouvoir utiliser sqlite il faut installer le port luadbi avec l'option sqlite. Après avoir un peu bataillé, ça marche.

Charge système

root@TARDIS:~ # df -h

Filesystem             Size    Used   Avail Capacity  Mounted on

/dev/ada0p2            140G    2.5G    126G     2%    /

devfs                  1.0k    1.0k      0B   100%    /dev

devfs                  1.0k    1.0k      0B   100%    /var/named/dev

/usr/jails/basejail    140G    2.5G    126G     2%    /usr/jails/xmpp/basejail

devfs                  1.0k    1.0k      0B   100%    /usr/jails/xmpp/dev

fdescfs                1.0k    1.0k      0B   100%    /usr/jails/xmpp/dev/fd

procfs                 4.0k    4.0k      0B   100%    /usr/jails/xmpp/proc

/usr/jails/basejail    140G    2.5G    126G     2%    /usr/jails/www/basejail

devfs                  1.0k    1.0k      0B   100%    /usr/jails/www/dev

fdescfs                1.0k    1.0k      0B   100%    /usr/jails/www/dev/fd

procfs                 4.0k    4.0k      0B   100%    /usr/jails/www/proc

/usr/jails/basejail    140G    2.5G    126G     2%    /usr/jails/mail/basejail

devfs                  1.0k    1.0k      0B   100%    /usr/jails/mail/dev

fdescfs                1.0k    1.0k      0B   100%    /usr/jails/mail/dev/fd

procfs                 4.0k    4.0k      0B   100%    /usr/jails/mail/proc

L'espace disque utilisé est de 2,5GB, sachant que l'on compte le système de base, le template, et l'arbre de ports. C'est assez intéressant. Voyons maintenant la charge CPU et mémoire :

last pid: 12938;  load averages:  0.00,  0.00,  0.00    up 0+22:54:08  13:14:23

48 processes:  1 running, 47 sleeping

CPU:  1.1% user,  0.0% nice,  1.5% system,  0.2% interrupt, 97.2% idle

Mem: 55M Active, 216M Inact, 113M Wired, 69M Buf, 589M Free

Swap: 4096M Total, 4096M Free

En gros même avec 3 VPS le système est très peu sollicité : 55Mo de mémoire utilisé, et CPU à 3% de charge.

Supervision

Pour assurer la supervision j'utilise tout simplement logwatch. C'est un script qui génère un rapport et envoie régulièrement un mail qui indique l'espace disque, les connexions ssh, les tentatives infructueuses d'accès à certain services. Logwatch peut être installé à partir de /usr/ports/sysutils/logwatch. Ensuite il faut spécifier Output = mail dans le logwatch.conf et ajouter un cron (@daily /usr/local/sbin/logwatch.pl).

On peut soit installer logwatch sur l'hôte uniquement, soit le mettre sur chaque jail. J'ai choisi la deuxième option pour avoir plus de détails.

Sur le serveur mail, c'est Postfix qui est utilisé pour l'envoi du rapport. Par contre sur les autres jail, j'ai laissé sendmail. Il faut éditer le fichier /etc/mail/freebsd.mc puis spécifier :

define(`SMART_HOST', `192.168.0.2')

Sauvegarder puis entrer :

m4 /etc/mail/freebsd.mc > /etc/mail/freebsd.cf

Sendmail va ensuite utiliser notre relay. Pas besoin de l'activer dans le rc.conf car il ne fonctionne pas comme un daemon dans ce cas là.

Sauvegarde

Pour les sauvegardes on parle beaucoup de bacula ou rsync. Dans mon cas j'ai choisi de faire plus simple car : 1) bacula est adapté pour les grosses infra avec plusieurs serveurs et du stockage dédié 2) rsync nécessite un support de stockage distant que je n'ai pas (mon NAS ne tourne pas 24/24). Donc je me contente d'un simple script sh :)

#!/bin/sh

tar -zcvf /root/"sauvegarde-`date -v-1d +%B-%Y`".tar.gz \

/etc \

/var/named/etc \

/usr/jails/mail/etc \

/usr/jails/mail/home \

/usr/jails/mail/usr/local/etc \

/usr/jails/www/etc \

/usr/jails/www/home \

/usr/jails/www/usr/local/etc \

/usr/jails/xmpp/etc \

/usr/jails/xmpp/home \

/usr/jails/xmpp/usr/local/etc

Et dans crontab -e :

@monthly /root/sauvegarde.sh

Le 1er du mois à minuit le script sera exécuté, et dans son nom il sera indiqué le mois (précédent). Ainsi une sauvegarde exécutée le 1er Fevrier 2014 sera nommée January-2014.tar.gz si tout se passe bien.

Je n'ai pas de bases de données dont pas besoin d'arrêter les jail avant la sauvegarde. Je sauvegarde les /etc qui contiennent la configuration et les /home qui contiennent les données. Pas besoin du reste.

Note : ezjail-admin permet de sauvegarder les jails, mais je ne l'utilise pas en raison de deux inconvénients majeurs : 1) ça sauvegarde tout incluant l'arbre des ports, ce qui est long et inutile 2) ça nécessite d'arrêter la jail, et je n'ai pas envie d'avoir des interruptions de service à chaque sauvegarde, on est pas sur Windows Server.

Conclusion

FreeBSD ça envoie du rêve, c'est très puissant, ezjail-admin est un outil qui m'a fait franchir le pas. On gère ses jails avec une facilité déconcertante. Je suis volontairement resté vague sur cet article, car le but était de présenter un retour d'expérience, et non un tutoriel qui aurait été de toutes manières trop long. Si vous vous lancez dans l'aventure et souhaitez obtenir mes fichiers de configuration ou des explications, n'hésitez pas !

VirtualBox : P2V
Classé dans : Virtualisation, Astuces, OS | 1 commentaire | publié le 20 décembre 2013

Un P2V (Physical to Virtual) est une opération qui consiste à transférer le système d'exploitation d'un ordinateur physique vers une machine virtuelle. C'est très pratique lorsque le hardware est défaillant ou sous-dimensionné et que vous souhaitez redonner un peu de patate à un serveur ou un poste de travail. Dans mon cas il s'agit d'un poste sous Windows XP que je souhaite virtualiser afin de l'utiliser sur une autre machine plus récente équipée de Windows 7. Voici la procédure.

Etape 1 : Génération du fichier VHD

Téléchargez l'utilitaire Disk2vhd sur la machine cible et exécutez-le en administrateur. Pensez à stopper l'antivirus et tous les services pouvant ralentir l'opération. Sélectionnez votre disque C:\ puis décochez la case "Use VhdX" (VirtualBox supporte mal) et sélectionnez l'emplacement du fichier cible (qui peut très bien être en local).

Exécutez l'opération, et patientez. Pour information, 40GB de vhd prennent à peu près 1 heure. Lorsque le fichier est complète généré, transferez-le sur votre machine qui va exécuter VirtualBox. Privilégiez un réseau 1000Mbps sinon cela risque d'être long (quasiment 1h20 pour mon fichier vhd de 40GB!).

Etape 2 : Création de la VM

Sur la machine qui exécute VirtualBox cliquez sur le bouton pour créer une nouvelle VM. Donnez-lui un nom, sélectionnez le type d'OS adapté dans la liste, allouez de la RAM (2GB pour XP 32 bits est suffisant) et sélectionnez "Utiliser un fichier de disque dur virtuel existant" et allez chercher votre fichier vhd. Pour finir, cliquez sur "créer".

Etape 3 : Configuration

Pour ma machine virtuelle en Windows XP j'ai du activer IO-APIC et PAE/NX. Pour cela sélectionnez votre VM puis cliquez sur "Configuration". IOi-APIC se situe dans la catégorie "Système" puis onglet "Carte mère". PAE/NX se situe dans l'onglet "Processeur".

Exécuter la VM

Plus qu'à cliquer sur le bouton "Démarrer" ! Attention si votre Windows XP était enregistré sur un domaine, pensez à le renommer pour éviter les conflits sur l'A.D.

FreeNAS + dlna (BBox)
Classé dans : Serveur, Astuces, OS, Planet-Libre | 1 commentaire | publié le 04 décembre 2013

Je stocke mes données sur un serveur maison qui tourne sur FreeNAS. Il est équipé de deux disques de 1TB membres d'un pool ZFS en mode miroir. L'accès se fait via un partage SMB, solution retenue car la majorité des accès se fait depuis un PC sous Windows (mais c'est également possible sous Linux avec smb://).

La BBox dispose d'un lecteur multimédia censé pouvoir lire les contenus des NAS. Mais de base cela ne fonctionne pas, mon partage SMB n'est pas visible. Après une petite recherche sur le web j'ai découvert qu'elle ne fonctionne qu'avec le dlna, en gros c'est un standard qui qui fourni plusieurs composants pour diffuser des contenus sur un réseau domestique. Mais FreeNAS n'offre pas la possibilité de faire serveur dlna. Heureusement, c'est possible avec un plugin.

Pré requis

FreeNAS doit être configuré et avoir accès à internet. Nous ne traiterons pas la mise en place des partages et le stockage des données. Dans l'exemple je stocke mes films dans /mnt/DATA/Films.

Configurer les jails

Comme FreeNAS est bien conçu, il utilise les jails de FreeBSD pour stocker ses plugins :) il faut donc commencer par les configurer. Rendez-vous dans Jails > Configuration. Entrez un chemin de stockage pour les jails, dans mon cas j'ai mis /mnt/DATA/jls. Pour la partie réseau assurez-vous qu'il s'agit du même que celui utilisé. Par exemple si votre NAS a l'IP 192.168.0.30, vous pouvez spécifier une start adress de 192.168.0.40 et une end adress de 192.168.0.50. Faites attention à la disponibilité de ces adresses (elles sont attribuées en statique, non par DHCP).

Installation du plugin dlna

Rendez-vous dans Plugins et sélectionnez "DLNA / UPnP" dans la liste. Cliquez sur "Install".

Au bout de quelques secondes, le plugin est installé.

Configuration du plugin dlna

Il va falloir voir deux points :

  1. Le plugin étant dans une jail, il n'a pas accès aux données, il faut donc définir un point de montage.
  2. Il faut indiquer au plugin où trouver les média

Allez dans Jails > dlna_1 > Stockage > Add Storage. Dans Source indiquez /mnt/DATA/Films (là où sont stockés les films). Dans Destination indiquez /mnt (l'emplacement dans la jail où vont apparaitre les films).

Allez dans Modules > MiniDLNA. Options à ajouter :

  • Friendly Name : FreeNAS (ou autre, c'est le nom qui sera visible sur le réseau)
  • Media directory : /mnt (correspondant au point de montage défini précédemment)
  • Cocher Rescan on (re)start

Validez.

Maintenant dans la page des Modules, vous pouvez passer l'interrupteur sur ON pour MiniDLNA :D

Test

Il faut utiliser un appareil ou un logiciel capable de visualiser les périphériques DLNA. Une BBox fait l'affaire, mais vous pouvez aussi utiliser une application android pour tester :D si vous détectez votre périphérique "FreeNAS" tout en ayant la possibilité de voir les films dessus, c'est gagné :)

Bon visionnage !

Aperçu de Mageia 4 beta
Classé dans : OS, Planet-Libre | 4 commentaires | publié le 29 novembre 2013

Je teste par curiosité la beta de Mageia 4, en virtuel et en live. Je l'ai trouvé plutôt réussie, d'où ce court article pour en parler. J'ai choisi la version KDE4, question de goût, et une fois passé l'installeur qui n'a pas trop changé et dont le thème serait à revoir, on arrive sur un bureau légèrement personalisé.

Là où la plupart des distributions KDE vanilla mettent en avant les "activités", Mageia utilise une disposition à l'ancienne en utilisant l'ancien menu kickoff, les boutons de lancement dans la barre et 4 bureaux virtuels. Et le rendu n'est pas mauvais, le bureau est plutôt simple à utiliser et intuitif.

Marque de fabrique de la famille : le centre de configuration maison. Il va permettre d'administrer son système de manière graphique et simple, avec les éléments suivants :

  • Gestion du matériel
  • Installer des logiciels ou mettre à jour le système
  • Gestion des scanner & impressions
  • Configurer le réseau (connexions et possibilité de faire un serveur vpn ou proxy)
  • Configurer l'authentification du système
  • Configurer les partages réseau (mise en place ou accès)
  • Partitionner les disques
  • Configurer le parefeu
  • Configurer le contrôle parental
  • Et d'autres...

Il faut avouer que le centre de configuration n'est pas indispensable pour un desktop, car de nos jours tout fonctionne out-the-box sur n'importe quelle distribution. Le centre de configuration réseau de Mageia n'est pas vraiment pertinent face à Network-Manager qui fait la même chose et est universel. Mais ça marche et c'est l'essentiel. Ça vaut le coup d'œil.

Un autre point notable : la richesse des dépôts logiciels, et surtout la présence des non-free. En quelques clics on peut installer le plugin flash à partir du gestionnaire de logiciels, ainsi que Skype et Steam. Cela représente un confort non négligeable beaucoup et épargne certaines bidouilles qu'il faut parfois réaliser.

Cette Mageia4 s'annonce très réussie, espérons qu'elle fasse parler d'elle a sa sortie et soit adoptée par beaucoup de monde !

Retour sur kubuntu 13.10
Classé dans : OS, Planet-Libre | 2 commentaires | publié le 24 novembre 2013

Je suis à la base un utilisateur de Fedora convaincu, mais je dois avouer que les dernières "nouveautés" ne m'ont pas forcément plu, par exemple l'installeur à la sauce Gnome3 trop limité a mon sens et parfois incompréhensible ainsi que des bugs sur la version KDE, avec l'indicateur d'énergie qui se retrouve tout le temps sur le bureau. J'ai décidé de tester une autre distribution basée sur KDE et simple à utiliser : kubuntu. Mon serveur étant sur debian, je suis très familier avec les distributions qui en sont dérivées.

Tout comme Fedora, kubuntu fonctionne out-the-box, avec un installeur plus simple car il s'agit de celui de ubuntu. Pour ajouter mes logiciels, j'ai décidé d'utiliser Muon, qui est l'équivalent de la logithèque ubuntu avec une interface QT. Et il faut dire que non seulement c'est réussi (installation aisée) mais en plus les dépôts sont bien remplis. Deux exemples tout bêtes : flashplugin et dropbox. Surtout que pour dropbox, le paquet n'installe pas nautilus comme dépendance, ce qui est appréciable. La présence de ces logiciels "non-free" fera sûrement râler les puristes, mais à mon sens c'est diablement pratique.

Utiliser kubuntu, c'est avoir :

  • Des logiciels récents (linux 3.11, kde 4.11, firefox 25...)
  • Un environnement KDE non modifié (le même que Fedora)
  • Un système stable et performant
  • Beaucoup de logiciels prêts à l'emploi dans la logithèque Muon
  • Profiter de la souplesse de apt-get en console
  • Exploiter le système ubuntu et profiter de la communauté

Bref des points qui peuvent intéresser pas mal de monde :)

Kubuntu est une excellente distribution Linux, qui combine un environnement KDE vanilla sur une base ubuntu et tous les logiciels qui vont avec. Je regrette vraiment qu'elle reste dans l'ombre. Je ne compte pas réinstaller Fedora pour le moment, kubuntu est vraiment mon coup de cœur du moment.

Windows 8
Classé dans : Divers, OS | 5 commentaires | publié le 19 mai 2013

PCInpact titre son article "Windows 8, échec et mat ?". Pour les gens non familiers avec l'univers de Microsoft vous obtenez le même niveau de troll en remplaçant "Windows 8" par "Gnome Shell". Les raisons du rejet sont les mêmes : changements radicaux par rapport à la version précédente et choix ergonomiques imposés à l'utilisateur (retrais volontaire de pas mal de fonctions).

L'article déclare que Windows 8 n'a pas su relancer le marché des PC. A mon sens le but de Windows 8 n'était pas de relancer le marché du PC, mais de jouer un double jeu PC / Tablettes. Avoir la même interface sur toutes les plateformes, et les mêmes applications si on passe par le market. En soit ce n'est pas idiot, mais retirer des éléments comme le menu démarrer était un choix risqué.

J'ai utilisé Windows 8 pendant trois mois au travail, car je souhaitais me faire ma propre idée sur l'efficacité des outils en entreprise. La disparition du menu démarrer ne m'a pas trop perturbé, je l'ai toujours trouvé trop bordélique. Sur 8 le lancement des applications se fait en appuyant sur la touche Windows puis en tapant les premières lettres du nom. Les habitués de Gnome-Do, Synapse, ALT-F2 sur KDE, Unity, Gnome-Shell retrouveront facilement leurs marques. Les applications présentes en "tuiles" (provenant du market) sont absolument inutiles, la plupart du temps on ne lance que le bureau ou des applications standard depuis le start screen.

La présence du market me semble inappropriée dans une version PRO de Windows. En effet l'utilisateur peut installer les applications même s'il n'est pas administrateur. De quoi casser les stratégies de sécurité du domaine et potentiellement semer la pagaille sur le réseau (que se passe-t-il si un utilisateur décide d'installer un client bittorrent et télécharger à fond ?).

Sous le capot les changements sont bien moindres par rapport à Windows 7. Les outils d'administration sont toujours là et les pilotes sont majoritairement compatibles. Par exemple notre serveur d'impression ne fournit que les pilotes XP & 7, mais j'ai pu m'y connecter sans problèmes. C'est la même chose pour les applications utilisées. Par contre, le client SCCM 2007 ne semble pas fonctionner.

Sur l'ordinateur que j'utilise (un Fujistu Lifebook e752) j'ai pu tester l'UEFI avec Secure Boot, par contre impossible de voir la puce TPM sur Windows et activer le chiffrement du disque. Cela me semble étrange, car si Secure Boot marche alors la puce TPM est bien là et reconnue. Mystère.

Ce qui m'a fait finalement downgrader en Windows 7 c'est une migration de domaine manquée et la volonté de repartir sur un environnement propre.

Mon expérience de Windows 8 n'est pas si mauvaise, après quelques heures d'utilisation on s'habitue et on peut retrouver la même productivité qu'avec Windows 7. A mon sens la marche à franchir est bien moins importante que Gnome 2 / Gnome 3. Si les ventes de PC chutent vraiment je pense qu'il faut chercher d'autres raisons.

ezjail : gérer facilement des jail sur FreeBSD
Classé dans : Serveur, Virtualisation, OS, Planet-Libre | 3 commentaires | publié le 29 avril 2013

Les jails permettent de créer des VPS sur un système FreeBSD. Les processus sont emprisonnés dans un niveau d'exécution et un environnement distinct. L'équivalent sur Linux est OpenVZ / VServer / LXC mais le système de jails sous FreeBSD est intégré au système et plutôt mature.

La documentation de FreeBSD décrit le processus manuel de création de jails. Je recommande la lecture et le suivi de l’exercice proposé afin d'acquérir les bases. Il est aussi mentionné la possibilité d'utiliser un "squelette" commun à toutes les jails, ces dernières n'ayant que les répertoires susceptibles d'être modifié. Cela évite d'avoir 10 fois la même arborescence alors que beaucoup d'éléments sont communs. ezjail est un outil permettant d'automatiser tout ceci, et nous allons voir que c'est plutôt bien foutu.

Installation de FreeBSD

Depuis la version 9, l'installeur a été simplifié au point qu'il n'est plus nécessaire de le détailler. Le choix des sets importe peu sur le résultat final, mais personnellement j'ajoute les sources car j'estime que cela fait partie de l'OS.

La suite de l'installation ne nécessite pas de paramétrage particulier.

Configuration

Vous pouvez commencer par mettre à jour le système :

# freebsd-update fetch

# freebsd-update install

# reboot

Nous allons maintenant installer ezjail. Il y a deux solutions : le compiler à partir des ports, ou le télécharger sous forme binaire avec pkg_add.

Méthode 1 : ports

Commencez par télécharger l'arbre des ports :

# portsnap fetch extract

Puis compilez et installez sysutils/ezjail :

# cd /usr/ports/sysutils/ezjail

# make install clean

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Méthode 2 : pkg_add

Utilisez la commande suivante :

# pkg_add -r ezjail

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Création de la jail de base

La commande suivante va préparer la jail de base :

# ezjail-admin install
Note : Si vous souhaitez ajouter les sources dans la jail de base, vous devez rajouter le paramètre s. Pour avoir les ports (récupérés à partir de portsnap) dans la jail de base ajoutez le paramètre p. Si vous avez déjà installé la jail de base et souhaitez rajouter les ports ou les sources, réutilisez la commande ezjail-admin install mais spécifiez le paramètre en majuscule, par exemple ezjail-admin install -P

Création d'une jail

Utilisez la commande suivante :

# ezjail-admin create dns 'em0|192.168.0.2'
Note : "dns" est le nom donné à notre jail, adaptez-le si besoin ! em0 est le nom de la carte réseau, adaptez-le en fonction de votre système. L'adresse IP sera automatiquement ajoutée comme alias par ezjail, pas de paramétrage à faire, à part spécifier celle que vous désirez donner à votre jail !

Démarrer une jail

Voici la commande :

# ezjail-admin start dns
Note : Les jails se lancent automatiquement au démarrage de l'hôte grâce au paramètre ezjail_enable ajouté au rc.conf.

Arrêt d'une jail

ezjail-admin stop dns

Mise à jour des jails

La jail de base va être mise à jour, ce qui va répandre les modifications sur toutes les jails.

# ezjail-admin update -u
Note : Le u (minuscule) applique les mises à jour mineures. Le U (majuscule) applique les mises à jour majeures. A vous de décider. L'option P (majuscule) met à jour les ports (en utilisant portsnap).

Suppression d'une jail

La commande est la suivante :

# ezjail-admin delete -wf dns
Note : Le paramètre w spécifie la suppression de l'arborescence de la jail sur le disque. Le paramètre f demande l'arrêt de la jail avant suppression.

Modifier le "modèle" des jail

Cas concret : vous voulez activer SSH sur toutes les jails créées. C'est faisable ! La jail "modèle" est située ici : /usr/jails/newjail. Donc il faut éditer/créer le fichier /usr/jails/newjail/etc/rc.conf :

# echo sshd_enable="YES" >> /usr/jails/newjail/etc/rc.conf

Et voilà !

Documentation

D'autres usages sont possibles, certains seront intéressés par les possibilités offertes avec l'intégration ZFS.

  • Site officiel ezjail : Très pauvre, mais les bases sont là.
  • Utiliser la commande man ezjail-admin directement sur FreeBSD, c'est très complet.
FreeBSD vs DragonflyBSD : Episode 2
Classé dans : Serveur, OS, Planet-Libre | 3 commentaires | publié le 25 avril 2013

Dans l'épisode 1 je signalais des freezes à répétition sur DragonflyBSD fonctionnant dans VMware. Le problème s'est reproduit sur une autre VM qui avait été épargnée jusqu'ici. J'ai donc migré de VMware à VirtualBox (il suffit de créer une VM en utilisant le disque .vmdk existant, puis de changer le contrôleur IDE en SAS) pour voir si les choses s'améliorent.

Les warning kernel qui s'affichaient semblent avoir disparu... en revanche j'ai toujours des avertissements relatifs à "sendmail/postfix" (quoi ? sendmail ? je me suis battu des heures pour qu'il se taise car j'utilise postfix !! ). L'autre point étrange c'est que je reçois par mail des rapports de fonctionnement (logwatch) qui me signalent l'existence de vulnérabilités dans les paquets tiers installés :

Fetching package vulnerabilities database:



Checking pkgsrc packages for vulnerabilities:

Package perl-5.14.2nb5 has a arbitrary-code-execution vulnerability, see http://secunia.com/advisories/51498/

Package perl-5.14.2nb5 has a denial-of-service vulnerability, see http://secunia.com/advisories/52472/

Package dovecot-2.1.9 has a denial-of-service vulnerability, see http://secunia.com/advisories/51455/

Package curl-7.27.0 has a remote-system-access vulnerability, see http://secunia.com/advisories/52103/

Package curl-7.27.0 has a remote-information-disclosure vulnerability, see http://secunia.com/advisories/53051/

Package scmgit-base-1.7.12nb1 has a man-in-the-middle-attack vulnerability, see http://secunia.com/advisories/52361/

C'est très bien mais... que puis-je faire ? Ces logiciels ont été installés à partir de pkgin et ils sont déjà à jour. A quoi bon me signaler l'existence de vulnérabilités puisque je ne peux rien faire à part attendre que ce soit corrigé dans les dépôts de pkgin ? Mieux : pourquoi y a-t-il autant de vulnérabilités sur les logiciels fournis par pkgin ???

Du côté de FreeBSD difficile de juger, puisque l'outil pkgng (équivalent de pkgin) n'est pas pleinement utilisable. En effet les dépôts publics sont fermés depuis plusieurs mois suite à des problèmes de sécurité ! Donc le seul moyen de tester pkgng c'est de créer vous-même votre dépôt... Ce que je n'ai pas vraiment envie de faire.

DragonflyBSD offre beaucoup de points intéressants, mais semble avoir des problèmes de comportement en environnement VMware et avec certains logiciels tiers. FreeBSD est encore en phase de transition vers pkgng mais se comporte plutôt bien dans les différents cas où je l'ai testé.

FreeBSD vs DragonflyBSD : Episode 1
Classé dans : Serveur, OS, Planet-Libre | 3 commentaires | publié le 17 avril 2013

J'ai mis en place plusieurs machines virtuelles sous VMware qui ont les rôles suivants :

  • Un serveur DNS sous FreeBSD 9.1 amd64
  • Un serveur Jabber sous DragonflyBSD 3.2 x86_64
  • Un serveur mail sous DragonflyBSD 3.2 x86_64
  • Un serveur web sous CentOS 6.4 x86_64

FreeBSD et CentOS se comportent bien, en revanche DragonflyBSD ne semble pas aimer VMware. Parfois le boot n'aboutit pas, parfois le système se freeze. A l'heure où j'écris ce billet, le serveur Jabber ne répond pas, alors que le mail oui. Ce qui me laisse penser que la VM Jabber a planté.

La gestion des ports (tous systèmes *BSD confondus) est à mon sens problématique, surtout lors de l'installation d'un logiciel qui en remplace un autre dans le système de base (Postfix pour Sendmail par exemple). DragonflyBSD embarque pkgin qui facilite l'installation mais pas la configuration. Cas concret : j'ai installé Postfix sur DragonflyBSD pour remplacer Sendmail (car je ne le connais pas du tout). La configuration s'est bien passé, la réception des mails fonctionne. En revanche en installant fetchmail je me suis rendu compte que le système s'appuyait sur Sendmail. Or comme ce dernier n'est pas configuré, les messages ont été envoyés dans une dimension parallèle.

Une distribution Linux sous forme de paquets RPM ou DEB me semble donc bien plus propre que la séparation "world" et "port" que l'on trouve sous FreeBSD et les autres. Sous Debian l'installation de Postfix retire complètement Exim les risques de confusion sont donc réduits. Sous FreeBSD et dérivés, l'impossibilité de retirer Sendmail (sauf par recompilation du world avec le bon src.conf) peut au contraire poser des problèmes.

Je dois quand même dire que Pkgin est un excellent outil qui permet d'avoir une vraie gestion des paquets et de leur mises à jour. Étant implémenté dans NetBSD et DragonflyBSD il est amené à évoluer assez rapidement. Quelques exemples d'utilisation :

# pkgin update

# pkgin search postfix

# pkgin install postfix

# pkgin upgrade

Si on s'en tient au système de base, tout va beaucoup mieux. L'implémentation de Bind sous FreeBSD est très correct et chrootée par défaut. Les fichiers sont situés dans /var/named/etc/namedb mais vus par l'application comme /etc/namedb. La mise en place de mon fichier de zone s'est bien passé, ainsi que l'ajout d'un fichier named.conf.local appelé par un Include (oui je suis trop habitué à Debian et aux fichiers de configuration modulaires).

A bientôt pour de nouvelles aventures.

Aperçu de DragonflyBSD
Classé dans : Serveur, OS, Planet-Libre | aucun commentaire | publié le 17 novembre 2012

DragonflyBSD est un système d'exploitation visant à obtenir de meilleures performances que FreeBSD dont il est dérivé. C'est probablement l'un des plus discrets à côté de FreeBSD, NetBSD et OpenBSD et je n'y avais jamais touché avant que ce journal sur linuxfr ne m'en donne envie.

Les développeurs sont partis de FreeBSD 4 et ont opté pour des choix techniques différents dans la gestion des processeurs multiples (SMP). Ils ont aussi lancé un nouveau système de fichiers HAMMER offrant plus de souplesse et de performances qu'UFS.

Dans cet aperçu je me contenterai de l'aspect serveur, qui est pour moi le plus intéressant. J'ajouterai que ce n'est pas un retour d'expérience, je ne l'ai pas mis en production (ça viendra peut-être), mais juste un premier essai.

Installation

On peut difficilement faire plus simple puisqu'il s'agit d'une suite de menus permettant de partitionner son disque en choisissant le système de fichiers UFS ou bien HAMMER. Pas de choix dans les sets d'installation, tout va à l'essentiel. Il est tout de même possible de configurer son clavier, horloge, réseau, mot de passe root.

Sources du système et logiciels tiers

DragonflyBSD, tout comme les autres systèmes *BSD, est en fait un système d'exploitation avec plusieurs logiciels intégrés dans les branches de développement qui reçoivent du support et des correctifs (SSH, sendmail...). Si l'utilisateur souhaite installer un autre logiciel (par exemple Dovecot) il peut le récupérer par l’intermédiaire de pkgsrc. Un logiciel ne faisant pas partie du système ne reçoit pas de patchs de l'équipe de développement, il s'agit en fait de la version "normale" (vanilla) avec un jeu de scripts permettant le lancement sur le système.

Les sources du système servent pour les mises à jour et la compilation de pilotes ou de certains outils. Elles ne sont pas fournies sur CD mais on peut les télécharger en entrant tout simplement la commande suivante :

cd /usr
make src-create

Pour les logiciels additionnels, DragonflyBSD utilise pkgsrc, issu de NetBSD, contrairement à FreeBSD qui utilise les ports. Au final le principe reste tout de même plus ou moins indentique. Pour récupérer pkgsrc, la commande est la suivante :

cd /usr
make pkgsrc-create

J'aime bien ce principe qui est assez simple pour récupérer les sources ! Notez cependant que la documentation recommande de passer par les packages précompilés ou bien par pkgin (gestionnaire de paquets un peu plus abouti).

Les mises à jour du système se font par compilation, il faut tout d'abord récupérer les sources puis lancer un buildworld suivi des commandes suivantes qui vont bien, comme pour FreeBSD.

Administration

DragonflyBSD utilise un fichier rc.conf dans lequel on indique les paramètres du système (nom d'hôte, réseau...) ainsi que les services à démarrer. Rien de neuf de ce côté, mais c'est donc simple et efficace.

Pour gérer les services, il faut invoquer les scripts rc. Par exemple, pour lancer le daemon ssh :

# /etc/rc.d/sshd start

On peut automatiser le démarrage de sshd en ajoutant dans notre rc.conf la ligne suivante :

sshd_enabled="yes"

On garde un fonctionnement et une administration faciles à comprendre, à la portée de tous. Les habitués des systèmes *BSD ne seront pas dépaysés.

Difficultés

J'ai eu beaucoup de mal à récupérer pkgsrc, car pour une raison étrange le système arrivait à court de mémoire et de swap. J'avais pourtant respectivement 1GB et 2GB, ce qui me semble largement suffisant pour un système en mode texte.

Comme je faisais mes tests sous VMware je suis passé sous VirtualBox mais là encore le problème s'est reproduit.

Je suis allé faire un tour sur le salon IRC de dragonflybsd pour y exposer mon problème, et on m'a conseillé d'éditer /usr/Makefile pour y commenter les lignes contenant la commande :

git gc --aggressive

Et le problème est résolu.

Conclusion

Le système est globalement très proche de FreeBSD mais apporte une valeur ajoutée sur beaucoup de composants. Il est simple à utiliser et à administrer. Un excellent choix pour un serveur, j'espère avoir un jour l'occasion de travailler avec et d'en apprendre plus.

Retour sur pfSense
Classé dans : Réseau, OS, Planet-Libre | 16 commentaires | publié le 25 septembre 2012

Cela va bientôt faire 3 mois que j'utilise pfSense, un système d'exploitation FreeBSD orienté routeur. En 2011 j'avais déjà rédigé un article dessus, mais depuis Juillet 2012 je l'ai mis en "production" avec fonctionnement 24h/24 et conditions réelles. Plusieurs points m'ont particulièrement plu dans pfSense, je vais les décrire ci-dessous.

Voici les fonctionnalités que j'exploite actuellement :

  • NAT et PAT
  • Firewall (DMZ)
  • Serveur DHCP
  • Client OpenVPN
  • Routes statiques
  • 3 VLAN taggés sur un unique port
  • Casé sur une carte CF
  • 4 postes utilisateurs sur le VLAN30, 4 serveurs sur le VLAN20 (dmz)

Notez qu'il y en a de nombreuses autres que je n'utilise pas : serveur NTP, DNS, relai DHCP, IPSec, la liste est longue...

Fiabilité

Pour l'instant, 79 jours d'uptime, ça peut paraître peu mais comme je l'ai dit précédemment cela ne fait que 3 mois. Les derniers redémarrages ont été volontaires pour des opérations de mise à jour ou des coupures en cas d'orage. Il faut aussi comparer cela à une merdebox domestique qui nécessite un reboot quasi journalier pour rétablir l'accès à internet. Bref, pfSense c'est fiable, ça tourne sans interruption.

Fonctionnalités

J'apprécie particulièrement que cette petite boite noire (Alix 1.d) soit capable de gérer à elle toute seule l'intégralité du réseau. J'ai ainsi pu y "greffer" mon VPN, mais aussi un serveur DHCP. Et les autres points appréciables concernent les outils de diagnostic. On peut faire des ping, visualiser les tables de routage, arp, traceroute, et il y a même un sniffeur de réseau réglable sur plusieurs niveaux de verbosité.

Simplicité

Tout est bien organisé, facile à trouver et à utiliser. Les changements sont pris en compte sans devoir redémarrer le routeur (là encore, comparaison aux box domestiques) ce qui est appréciable. Les tableaux récapitulatifs des règles de parefeu sont assez bien pensés. La configuration peut être exportée dans un fichier XML si vous désirez "formater" la machine (pour une mise à jour par exemple).

Conclusion

Je ne regrette pas le choix de pfSense comme solution pour gérer mon réseau :D toutes les qualités que l'on peut rechercher y sont, avec la souplesse, la simplicité et la fiabilité. C'est une appliance excellente qui n'est pas prête de me lâcher !

FreeBSD et Intel graphics
Classé dans : Divers, Matériel, OS | 1 commentaire | publié le 08 septembre 2012

J'ai installé FreeBSD 9.1RC sur un ordinateur portable équipé d'un processeur Sandy Bridge (puce graphique intégrée dedans, Intel® HD Graphics 3000). Les pilotes graphiques Intel sont très bien réputés car ils sont libres, à jour, et développés par le constructeur ! Que demander de mieux ?

C'est donc avec une (très) grande surprise que j'ai découvert que les puces graphiques Intel ne sont pas supportées sur FreeBSD. Si j'en crois cet article de Phoronix, la raison est qu'Intel ne travaille qu'en KMS (Kernel Mode Setting), disponible uniquement sur Linux. Donc, pour FreeBSD, toute machine tournant sur un processeur graphique Intel fonctionne sur le pilote vesa en 1024x768... et je ne parle pas de l'accélération 2D et 3D. Heureusement(?), FreeBSD est en train de développer son Kernel Mode Setting afin de pouvoir faire tourner les pilotes graphiques qui ne sont compatibles qu'avec ça. On peut trouver sur les forums une procédure pour activer KMS sur le système et compiler le pilote Intel qui va bien. Malheureusement c'est très long et le résultat est un peu aléatoire (j'ai réussi mais je n'avais plus de souris).

Etant donné qu'AMD ne fourni pas de pilotes pour FreeBSD, il semble que le seul "bon" constructeur sous cet OS soit Nvidia. En effet, même pour les cartes haut de gamme (GTX600), on trouve des pilotes FreeBSD.

Est-il acceptable de faire des pilotes pour Xorg fonctionnant uniquement sur Linux ? Cette dépendance est une des reproches que l'on fait à systemd et à Lennart Poettring [combo troll] pour ses propos sur les systèmes *BSD. La notion de "bon" constructeur ne se résume donc pas à la licence.

Mon top distributions Linux
Classé dans : OS, Planet-Libre | 12 commentaires | publié le 27 juillet 2012

La première partie est assez subjective et traite de ce que je préfère et pas de ce qui est le meilleur. La seconde partie va tenter d'être un peu plus objective.

Top distributions desktop

1/ Fedora

Elle propose des paquets récents, des nouvelles technos, elle est stable, elle est belle. Personnellement j'utilise le spin KDE que je trouve excellent. Un autre point positif est l'implémentation de KVM et son écosystème (libvirt, virt-manager) qui est vraiment à la pointe par rapport aux autres.

2/ Ubuntu

Depuis la 12.04, Ubuntu s'approche vraiment de ce qu'elle devrait être : récente et stable.

3/ Arch

Même si je râle sur le prosélytisme omniprésent envers cette distribution, c'est une des meilleurs au niveau desktop. Son gestionnaire de paquets est rapide, les versions sont récentes, la configuration est simple.

Top distributions serveur

1/ Ubuntu server

Tout simplement parce que c'est une Debian avec 5 ans de mises à jour, et des paquets plus récents.

2/ Debian

Je reviendrai dessus sur le point suivant.

3/ CentOS

Elle est grosse, elle est stable, incassable, les dernières technologies de virtualisation y sont. Ce qui la pénalise un peu est le nombre faible de paquets, par exemple il n'y a pas Prosody. Elle est plus stricte au niveau des architectures processeur, je ne peux par exemple pas l'installer sur mon Alix car le CPU ne supporte pas les instructions 686.

Si devait n'en rester qu'une

J'ai cité au dessus les distributions que je préfère, mais si on me demande laquelle est objectivement la meilleure, je pense que c'est Debian. Il y a un nombre incroyable de paquets mais également d'architectures. Ajoutez à cela la philosophie de liberté, d'ouverture, de travail de qualité, et cela explique pourquoi je choisirai celle-là si je devais n'en garder qu'une.

OpenBSD : p2v
Classé dans : Serveur, Virtualisation, Astuces, OS, Planet-Libre | 3 commentaires | publié le 19 juin 2012

Voici une petite bidouille pour transférer un serveur OpenBSD physique vers une machine virtuelle (VMware dans mon cas, mais cela devrait fonctionner avec tous).

A moins de faire une mauvaise commande, il n'y a aucun risque pour le serveur car on ne modifie rien dessus.

Etape 1 : installation de la VM

Ici, rien de particulier. Récupérez une ISO d'OpenBSD et effectuez l'installation dans une machine virtuelle. Configurez le réseau afin d'avoir un accès SSH.

Etape 2 : lister l'essentiel sur le serveur physique

Si je liste ce que contient mon serveur, voilà ce que j'obtiens :

$ ls /
altroot boot    bsd.mp  dev     home    obsd    sbin    sys     usr
bin     bsd     bsd.rd  etc     mnt     root    stand   tmp     var

Mon serveur fait tourner OpenSMTPD dont la config se trouve dans /etc et les messages dans /home. Vient ensuite dovecot installé à partir des ports, ses fichiers se situent dans /usr (et la config dans /etc). Et pour finir, prosody qui vient lui aussi des ports et exploite une base de données située dans /var. La liste des répertoires à transférer est donc :

  • /etc
  • /home
  • /usr
  • /var

Etape 3 : sauvegarde des répertoires

On utilise un bon vieux tar (vous pouvez utiliser la compression en rajoutant l'argument z) :

# tar -pcvf etc.tar /etc/
# tar -pcvf home.tar /home/
# tar -pcvf usr.tar /usr/
# tar -pcvf var.tar /var/

Attention à ne pas travailler dans le répertoire /home lorsque vous faites la deuxième commande ! Sinon cela ne terminera jamais (il va archiver le fichier d'archive nouvellement créé, etc).

Etape 4 : transfert des archives sur la VM

Le plus simple est d'utiliser le protocole sftp (actif du moment que sshd est actif sur vos systèmes). Cela peut-être fait depuis Filezilla sur une tierce machine (avec les comptes root).

Etape 5 : Rétablissement des utilisateurs

Pour des raisons de sécurité, le fichier contenant les utilisateurs du système et leurs mots de passe est en lecture seule, même pour root (voir cette page). Vous devez utiliser l'outil vipw pour les importer.

Ouvrez vipw sur l'ordinateur hôte, copiez toutes les lignes situées après la ligne "nobody", et collez-là à la suite dans le vipw de la VM (vous pouvez faire cette opération depuis un ordinateur tiers et des connexions SSH).

Etape 6 : installation sur la VM

La procédure est classique, sauf qu'il faut penser à sauvegarder le fichier fstab car le partitionnement peut différer :

# tar -pxvf var.tar -C /
# tar -pxvf usr.tar -C /
# tar -pxvf home.tar -C /
# cp /etc/fstab /root/
# tar -pxvf etc.tar -C /
# cp /root/fstab /etc/
# reboot

Pensez à revoir la configuration du rc.conf, notamment le nom d'hôte et le réseau qui peuvent différer.