Les différents BSD

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
Mois de parution
septembre 2014
Spécialité(s)


Résumé

« Salut, je voudrais installer *BSD, vous me conseillez quoi ? »Cette phrase, lue et relue des centaines, des milliers de fois, est fondamentalement incorrecte. *BSD n'existe pas. Plus important, lorsque l'on souhaite mettre le pied à l'étrier d'un système BSD, un minimum de contexte est nécessaire, car chacun des héritiers de BSD UNIX suit une philosophie bien définie, et si chacun d'entre eux s'avère éminemment versatile, certains seront plus adaptés et faciles d'accès fonction de l'utilisation souhaitée. Nous allons ici faire connaissance avec les trois systèmes BSD les plus connus, NetBSD, FreeBSD et OpenBSD et évoquer leurs forces et faiblesses afin de guider votre choix de façon la plus objective possible.


Body

« BSD » signifie Berkeley Software Distribution, et ne constituait initialement qu'une collection d'outils étendant les possibilités de l'UNIX originel. 1BSD, sous l'impulsion de Bill Joy (qui deviendra plus tard fondateur de Sun Microsystems), verra le jour en 1977 sous forme de greffon à UNIX V6, lui ajoutant entre autres le légendaire ex, ancêtre de vi. Le groupe publiant ces « distributions logicielles » s'appelait le CSRG, pour « Computer Systems Research Group » et travaillait, dans l'université de Berkeley aux États-Unis, à améliorer le système UNIX, lui ajoutant de nombreuses fonctionnalités. En 1983, ces derniers aboutissent à une version 4.2BSD disposant d'une première implémentation de TCP/IP, un travail financé par l'armée américaine afin de bénéficier d'un système d'exploitation supportant un protocole de communication liant un concept encore naissant : DARPAnet. Le CSRG pressent cependant que le succès de l'implémentation pile TCP/IP aboutira tôt ou tard à son démantèlement. Aussi, Bill Jolitz (voir GLMF n°114) et quelques apôtres s'affairaient à préparer le futur et travaillaient d'arrache-pied sur un portage de 4.3BSD Reno vers l'architecture i386. En 1991, une version inachevée de ce portage voit le jour, elle s'appellera Net/2. Elle servira de base de travail au premier UNIX libre utilisable, 386BSD, ainsi qu'à BSD/386 de la société BSDI, future BSDi, société créée par d'anciens membres légendaires de la CSRG.

Au milieu de l'année 1992, il existe deux systèmes BSD sur architecture Intel. Le premier, BSD/386, plus tard nommé BSD/OS, est un produit commercial issu de la société BSDi ; c'est un système utilisable et bien moins cher que le rival UNIX System V vendu par AT&T. Le second, 386BSD, est le tout premier UNIX libre totalement fonctionnel (comprendre : pas uniquement un noyau) maintenu par Bill Jolitz, qui quitta la société BSDi avec pertes et fracas lorsqu'il comprit que l'objectif de celle-ci était uniquement de vendre le système BSD/386 sans possibilité de diffusion gratuite et sans support.

Seulement voilà, 386BSD est un échec. Rares sont ceux qui réussissent simplement à l'installer, et Jolitz est réfractaire à l'inclusion de patchkits proposés par quelques groupes d'utilisateurs. Devant la frustration grandissante et la divergence d'opinion des contributeurs de 386BSD et de son auteur, quatre d'entre eux décident de fonder leur propre version du système, leur ambition étant de proposer du code propre et portable. Ces quatre développeurs sont Chris Demetriou, Theo de Raadt, Adam Glass et Charles Hannum. En écho à l'importance grandissante du réseau dans l'informatique, et en raison du modèle distribué et collaboratif de développement, Theo de Raadt propose le nom « NetBSD ». Le 21 mars 1993, le dépôt du code source du projet est mis en place.

Le projet FreeBSD trouve ses origines exactement au même endroit, à quelques mois d'écart, et pour les mêmes motifs, mais avec une emphase importante sur la très populaire architecture i386. Sous l'impulsion de Jordan Hubbard, Nate Williams et Rodney Grimes, la première release officielle voit le jour le 1er novembre 1993.

Enfin, le projet OpenBSD prend ses racines dans NetBSD. En effet, l'attitude de l'un des fondateurs de ce dernier, Theo de Raadt, n'était pas du goût de tous. Ses avis tranchés, divergences d'opinion, mais surtout sa dureté avec les utilisateurs ont eu raison de son commit bit en décembre 1994. Il fondera alors le projet OpenBSD en octobre 1995, dont la première release, OpenBSD 1.2, verra le jour en juillet 1996.

1. Lequel ? Pourquoi ?

À l'issue de cette petite introduction historique, nous partirons d'un postulat naïf pour vous aider dans votre choix :

- Le/la lecteur/trice n'a d'apriori sur aucun des trois projets ;

- Il/elle possède des bases d'UNIX/Linux ;

- C'est son baptême BSDiste, ou il/elle a vécu une expérience douloureuse par le passé ;

- L'ordre d'apparition des héritiers de 4.4BSD se fera chronologiquement, et non par préférence.

1.1 NetBSD

Le système NetBSD met un point d'honneur à produire du code de qualité. La propreté et la portabilité des composants du système, noyau et espace utilisateur, en font une plateforme qui sied à un nombre important d'architectures matérielles. On retrouve NetBSD dans du matériel professionnel comme des commutateurs (Brocade, Force10, ...), des imprimantes (Ricoh), ou encore les bornes Wi-Fi d'un iGéant bien que ce dernier ne communique pas sur cet aspect. Ce leitmotiv a permis en particulier d'intégrer la libc de NetBSD dans le système d'exploitation MINIX en un temps record, et a récemment suscité un vif intérêt de Google qui voyait là un moyen élégant d'homogénéiser sa libc Bionic pour le système Android.

NetBSD se contente de quelques mégaoctets de mémoire vive et de stockage pour être parfaitement opérationnel ; de plus, outre les architectures processeur, NetBSD supporte un nombre important de périphériques d'entrée/sortie. Ces atouts en font un système de choix pour l'embarqué ou les appliances.

Notons de plus que NetBSD supporte le système de virtualisation Xen depuis la version 2.0 de ce dernier, tant en mode domU que dom0, ainsi, son utilisation en serveur virtualisé est simple et attirante. J'utilise pour mes besoins propres des machines virtuelles NetBSD/Xen sur des dom0 Debian GNU/Linux depuis plusieurs années avec grande satisfaction.

Côté logiciels tierce partie, NetBSD repose sur pkgsrc [1], un framework directement issu des ports de FreeBSD, mais qui lui aussi vise la portabilité. En effet, pkgsrc est disponible et fonctionnel sur nombre de plateformes telles qu'*IllumOS/SmartOS/OpenIndiana* (tous des forks et évolutions de SunOS/Solaris), GNU/Linux, DragonFly BSD, FreeBSD, OpenBSD, Mac OS X et j'en passe. Bien qu'initialement pkgsrc repose sur la compilation des logiciels, il est possible d'utiliser des dépôts binaires à l'aide du gestionnaire de paquets pkgin [2], dont l'utilisation est calquée sur des outils tels que l'apt de Debian ou encore le yum de Red Hat.

1.2 FreeBSD

Le système FreeBSD se focalise sur le développement de fonctionnalités modernes, la stabilité et la vitesse de traitement. Il ne supporte pas autant d'architectures que NetBSD, néanmoins il tourne sur à peu près n'importe quelle machine serveur ou de bureau - à savoir x86, amd64, sparc64, powerPC - et sur certaines architectures embarquées type ARM ou MIPS.

FreeBSD met un point d'honneur à rester à la pointe de la technologie sur les aspects réseau, performance et sécurité. On peut noter que FreeBSD dans sa dernière version intègre par défaut l'*hyperviseur* bhyve [3], des outils de bac à sable, ou jails [4], permettant de restreindre les droits de certains programmes, ou encore un gestionnaire de paquets très complet, pkgng [5].

Il est de notoriété publique que « FreeBSD runs the Internet ». En effet, de grands acteurs de l'Internet utilisent (ou utilisaient) dans leur infrastructure des serveurs tournant sur FreeBSD : Yahoo!, Rackspace.com, Hotmail, Netflix et bien d'autres... De plus, un certain nombre de produits sont tout ou partie basés sur FreeBSD sans forcément que cela se sache, en particulier Mac OS X, PlayStation4, Juniper ou NetApp.

Concernant la bibliothèque logicielle proposée sur FreeBSD, elle compte aujourd'hui plus de 24000 applications pour serveurs (web, mail, ...), stations de travail (Xorg, applications graphiques), ou bien environnements embarqués. À l'instar de pkgsrc et pkgin sur NetBSD, FreeBSD possède deux systèmes de distribution de logiciels : le premier sous forme de sources à compiler ports [6] et le second sous forme de binaires pré-compilés pkg [5].

1.3 OpenBSD

OpenBSD [7] se concentre plutôt sur les barbecues et la randonnée. Pour ce qui est du code, il paraît que certains développeurs mangent des enfants, mais sont aussi surtout intéressés par la sécurité et la stabilité avant tout, quitte à sacrifier les performances, qui sont (il paraît) généralement en deçà des autres BSD. Ainsi, pas de virtualisation en tant qu'hôte, et un support multiprocesseur pouvant être amélioré. OpenBSD n'hésite pas à faire des changements controversés pour faire bouger l'écosystème des applications environnantes, et peut aller jusqu'à forker les logiciels quand la qualité de ceux-ci n'est pas satisfaisante. Ainsi, le projet LibreSSL [8] vise à nettoyer le code d'OpenSSL, en supprimant toutes les parties considérées comme obsolètes, ou non correctement écrites d'un point de vue sécurité.

Côté matériel, une douzaine d'architectures sont supportées, du vax à l'hppa en passant par MIPS, sans oublier alpha. Les architectures mainstream fonctionnent aussi, avec le support de KMS/DRM sur i386/amd64/macppc, un très bon support des chipsets Wi-Fi récents, ainsi que de la mise en veille via l'ACPI, ce qui en fait aussi un très bon OS pour portable. Ainsi, on peut installer via pkg_add(8) un nombre croissant de packages binaires (OpenBSD ayant le support de ceux-ci depuis 2005), tels que les habituels GNOME3, KDE4, Xfce, LibreOffice, Firefox, Thunderbird, Chromium..., ce qui permet d'utiliser OpenBSD comme une machine de bureau classique.

Cependant, une majorité des utilisations d'OpenBSD se font au niveau du réseau, que ce soit en firewall avec PF, en reverse proxy/load balancer avec nginx/relayd, en routeur avec OpenBGPD [9], en serveur mail avec OpenSMTPD [10], tous ces logiciels étant présents dans l'installation de base. Enfin, OpenBSD est aussi connu pour être à l'origine du projet OpenSSH [11], qui est sûrement installé sur votre machine, et que vous utilisez probablement quotidiennement...

2. L'installation

Dans cette partie, nous allons voir rapidement comment installer chacun de ces systèmes.

2.1 FreeBSD

Le processus d'installation de FreeBSD utilise l'installeur bsdinstall(8), qui a succédé à sysinstall(8) lors de la sortie de FreeBSD 9.0. La figure 1 montre l'écran de départ de l'installation d'une FreeBSD.

freebsd_install

Fig. 1 : Écran d'installation de FreeBSD

Cet installeur est à ce jour le plus « eye-candy » de tous, possédant une interface curses conviviale, et propose des fonctionnalités sympathiques comme l'installation sur une racine ZFS (Z File System), le support de GPT (GUID Partition Table) et les volumes chiffrés via GELI. Son fonctionnement est basé sur des scripts d'installation et des cibles « à la Makefile », et il est possible de scripter l'installation en déposant dans le média d'installation un script comme celui qui suit dans /etc/installerconfig :

PARTITIONS=ada0
DISTRIBUTIONS="kernel.txz base.txz"
BSDINSTALL_DISTSITE="ftp://ftp.fr.freebsd.org/pub/FreeBSD/releases/amd64/10.0-RELEASE"

#!/bin/sh

# Configuration de em0 en mode DHCP
echo "ifconfig_em0=DHCP" >> /etc/rc.conf

# Démons actifs par défaut
echo "sshd_enable=YES" >> /etc/rc.conf
echo "cfengine3_enable=YES" >> /etc/rc.conf

# Installation de CFEngine
pkg install cfengine3

Le fait de placer ce script sur le média d'installation :

- partitionnera automatiquement le premier disque SATA/SCSI disponible,

- installera les sets kernel et base (système minimal), depuis le média ou le miroir spécifié si besoin est,

- lancera le script situé après le shebang (#!/bin/sh) pour finaliser l'installation dans le contexte du système nouvellement installé (chroot(8)).

Il est aussi possible d'utiliser Cobbler [12], un support expérimental de FreeBSD étant disponible ici : http://www.cobblerd.org/manuals/2.6.0/1/3/2_-_FreeBSD.html. Ce n'est pas pour le moment totalement finalisé, mais cela permet une intégration propre avec ce formidable outil de déploiement qu'est PXE !

Le plus : NanoBSD

Le projet FreeBSD offre une méthode d'installation et d'utilisation innovante pour créer des applications embarquées (« appliances ») : NanoBSD [13].Ce système a pour but de faire tourner un système en lecture seule sur une partition du média de stockage (disque dur, carte SD, CD-ROM) tout en stockant la configuration sur une partition /cfg spécifique. La mise à jour est facilitée par le fait que deux partitions système soient présentes et mises à jour en alternance, ce qui permet en cas d'échec de redémarrer sur la dernière partition valide.

C'est ce système qui sert de base, par exemple, à l'appliance pfSense, qui sera abordée dans un autre article au sein de ces pages.

2.2 NetBSD

L'installeur de NetBSD (Fig. 2), sysinst(8), est lui aussi esthétique, mais est un peu plus « brut » par rapport aux questions qu'il pose. Il demandera un peu plus de connaissances pour comprendre les tenants et aboutissants des questions posées, notamment au niveau du partitionnement.

netbsd_install

Fig. 2 : Écran d'installation de NetBSD

Il est aussi possible dans son cas d'automatiser une installation, certes de manière moins accessible, via plusieurs méthodes :

- Faire l'installation via un script (partitionner, formater, installer un secteur de boot, déployer les sets et copier le kernel dans /netbsd). C'est extrêmement formateur et amusant. On ne travaille pas avec « the original UNIX » pour rien !

- Utiliser des outils comme sysutils/mklivecd ou sysutils/mkmemstick. Il suffit alors de modifier l'installeur avant sa copie. En effet, sysinst(8) n'est rien de plus qu'une installation comme présentée au point précédent, avec une solide quantité de tests autour. Il devient alors possible de mettre diverses valeurs en dur, voire d'initialiser le réseau et de récupérer un script d'installation personnalisé distant.

- Démarrer le système via PXE sur une image d'installation personnalisée. Comme toujours sur les OS BSD, un soin important est apporté à la documentation, il est donc possible d'en savoir plus via man diskless(8).

Note importante : à la fin de l'installation interactive, l'installeur propose assez discrètement l'installation de pkgin [2], un package manager basé sur pkgsrc et inspiré de apt/yum, initialement créé par iMil, le gentil lutin co-auteur du présent article. C'est bon, mangez-en !

Le plus : les anykernels

NetBSD a été à l'origine de l'implémentation d'un concept original : les noyaux rump [14]. Le principe est à la fois simple et complexe : pouvoir obtenir un noyau capable de tourner sur n'importe quelle plateforme, qui communique avec cette plateforme via des appels machine appelés « hypercalls » et puisse lui fournir tous ses services comme par exemple l'accès à un système de fichiers, ou bien un pilote réseau.

Ces services offerts par le noyau NetBSD peuvent donc tourner, non modifiés, sur une plateforme (ou « client »), qui n'est pas le noyau lui-même mais une plateforme abstraite par les hypercalls (Fig. 3). Ce concept de noyau, nommé « AnyKernel » ou « rump », est implémenté dans NetBSD depuis 2012.

netbsd_rump

Fig. 3 : Système d'abstration des hypercalls

2.3 OpenBSD

L'installeur d'OpenBSD est le plus direct d'entre tous : les questions sont posées en mode texte, une à la fois, de manière séquentielle et ordonnée (Fig. 4). C'est aussi le plus rapide d'entre tous à compléter, un média d'installation rapide peut mener à une installation terminée en 5 minutes chrono même en mode interactif !

openbsd_install

Fig. 4 : Écran d'installation d'OpenBSD

Il existe là encore plusieurs façons d'installer ce système de manière personnalisée :

- La méthode « standard » est d'utiliser un set d'installation spécial, siteXX.tgz, et éventuellement un script personnalisé, install.site, dans ce set. L'inconvénient est que l'installation est encore interactive, ce set/script ne sert qu'à personnaliser la fin de l'installation.

- Il est aussi possible d'utiliser un installeur personnalisé, modifiant bsd.rd (qui contient le noyau lancé lors de l'installation de OpenBSD). Il existe beaucoup de scripts permettant de faire ça sur Internet, comme par exemple http://download.ironflake.org/openbsd_autoinstall_howto.txt.

Le plus : les sous-projets d'OpenBSD

OpenBSD est réputé pour être à l'origine de nombreux outils de grande qualité et utilisés, comme par exemple le très réputé OpenSSH. Ce n'est que la face connue de l'iceberg, et le projet OpenBSD est extrêmement prolixe en projets du genre :

- OpenSSH : Service SSH libre, aujourd'hui quasiment une implémentation de référence ;

- OpenBGPd : Service de routage BGP ;

- OpenNTPd : Service de gestion de la dérive d'horloge NTP ;

- OpenSMTPd : Service SMTP (Mail) léger, inspiré de la syntaxe du pare-feu PF pour sa configuration ;

- LibreSSL : Implémentation SSL/TLS reprise de OpenSSL, en cours d'amélioration pour nettoyer le code et redonner une dynamique communautaire au projet.

2.4 Que faire en cas de problème lors de l'installation ?

Les installeurs BSD, comme vu précédemment, sont restés relativement simples par exemple par rapport aux installeurs GNU/Linux. Il existe donc plusieurs méthodes pour se débrouiller suivant le cas :

- Demander accès à une console distante chez son hébergeur (KVM, iLO, iDRAC...) : petit(e) joueur(euse) ;

- Utiliser une méthode d'installation distante qui n'utilise pas la console, mais plutôt un accès SSH ;

- Utiliser le plan B.

2.4.1 La solution diplomatique

Il existe, au moins pour FreeBSD et OpenBSD, des méthodes permettant de se passer d'un accès physique à la machine pour l'installer, et d'utiliser exclusivement un accès réseau.

Sur FreeBSD, le projet mfsBSD [15] permet d'aider à la création d'une image d'installation légère tenant exclusivement en mémoire, et permettant l'installation via SSH. Il devient ainsi possible de déposer brutalement sur un média quelconque cette image (par exemple sur le disque dur du serveur à installer, via un OS déjà en place, ou bien un mode de secours) et de démarrer la machine distante dessus pour que auto-magiquement l'installeur soit accessible via SSH. Un tutoriel détaillé d'installation utilisant cette méthode est gentiment fourni par Keltia : https://www.keltia.net/howtos/mfsbsd-zfs91/.

OpenBSD, lui, propose le projet yaifo [16]. Le principe est presque le même : on dépose sur le disque distant l'image d'installation et, au démarrage, celle-ci rend l'installeur disponible via SSH.

2.4.2 Le plan B

Le plan B est en fait une méthode qui fonctionne pour tout système qui :

- ne se formalise pas des changements de matériel, en particulier niveau contrôleur de disque,

- si possible, soit capable d'identifier ses disques via un label ou un identifiant unique.

Cette méthode fonctionne donc en particulier sur GNU/Linux, tous les *BSD et sans doute Minix, Haïku, etc. Elle est relativement simple : installer le système dans une machine virtuelle, puis utiliser cette image sur la machine cible. Il existe là encore deux manières de s'y prendre :

- Installer le système sur une machine virtuelle directement sur la machine distante ;

- Installer le système sur une machine virtuelle locale, puis transférer le disque.

Pour la première méthode, il est possible de le faire si on a un système de sauvetage accessible sur la machine distante par SSH et qu'elle permet de lancer QEMU. Si c'est le cas, il suffit d'installer QEMU sur la machine via le gestionnaire de paquetages du système de sauvetage, de télécharger l'image ISO du système voulu et la magie fera le reste :

$ qemu-system-x86_64 -no-kvm -hda /dev/sda -cdrom FreeBSD-10.0-RELEASE-amd64-bootonly.iso -curses -boot d

À noter que cette méthode ne fonctionne que si l'installation se fait en mode texte ou via une interface curses (ce qui est le cas de FreeBSD, NetBSD, OpenBSD, DragonFly BSD, et certaines distributions GNU/Linux).

L'autre méthode, un tantinet plus brutale, consiste à reprendre une technique assez utilisée dans les systèmes embarqués : installer un système « témoin » fonctionnel dans une machine, puis transférer son contenu sur une autre. Pour ce faire, il suffit d'installer le système dans une machine virtuelle utilisant un disque « brut » (« raw ») et ensuite de transférer cette image sur la machine cible, par exemple via la commande dd(1) :

$ gzip image-vm-freebsd.raw | ssh -o "Compression no" utilisateur@machine.cible.org "gzip -d > dev/sda"

Cette commande transfère le contenu de l'image sur le système distant en la compressant à la volée via gzip, pour économiser de la bande passante. Notons que cette commande demande un processeur décemment puissant, et est à proscrire pour une machine qui est dotée d'un processeur peu véloce (Dedibox SC chez Online.net par exemple).

2.5 Tester *BSD

Si vous êtes habitué à installer un système GNU/Linux, pas d'inquiétude : votre essai avec *BSD se passera bien. Il n'y a pas vraiment de piège, et les concepts sont similaires, la seule étape qui diffère est la manière dont les systèmes BSD gèrent les partitions (notion de disklabels [17], et une fois habitué on n'y fait même plus attention). Il faut aussi se souvenir d'un fait simple : contrairement aux légendes, les utilisateurs de systèmes BSD ne sont pas de méchants administrateurs barbus et antipathiques, mais des gens comme tout le monde rassemblés autour d'un système qui les passionne... C'est la grande magie du logiciel libre. Ils sont prêts à aider tout nouvel arrivant (si tant est qu'il ait bien lu la documentation avant, naturellement) en cas de pépin. Il ne faut donc pas hésiter à venir se frotter à un système BSD « pour voir ».

Conclusion

À l'issue de cet exposé, peut-être avez-vous déjà fait votre choix, la rigueur de NetBSD, la réactivité de FreeBSD, ou encore la sécurité d'OpenBSD ; cependant, cent fois sur le métier remettez votre ouvrage, profitez de la richesse proposée par ces systèmes ancestraux et mettez-les à l'épreuve ! De plus, si les OS et leurs philosophies diffèrent, leurs communautés aussi ; les besoins et attentes des utilisateurs sont propres à chacun des héritiers de 4.4BSD Lite2, et il est probable que vous développiez une affection particulière pour l'une d'entre elles. Ne perdez pas de vue qu'un UNIX BSD n'est pas uniquement constitué d'un noyau sur lequel on empile des outils dont la provenance n'est pas homogène ! Il est construit autour d'un système de base cohérent, maintenu par un groupe responsable de la production d'un système d'exploitation complet, fonctionnel et prêt à l'emploi ; les outils présents dès le premier boot sont écrits et pensés pour former un ensemble contrôlé. Ainsi, un dysfonctionnement et son rapport de bogue associé ne se matérialisent pas par une bouteille à la mer sur d'obscurs bugtrackers, mais bel et bien auprès du projet concerné. Laissez-vous séduire par la qualité de systèmes UNIX dont les origines sont enracinées dans l'histoire démarrée dans les laboratoire de Bell et dont une proportion importante des auteurs ont participé et écrit l'Internet que vous connaissez aujourd'hui [18].

Références

[1] Site officiel de NetBSD : http://www.netbsd.org

[2] Site officiel de pkgin : http://www.pkgin.net

[3] Site de l'hyperviseur bhyve : http://www.bhyve.org

[4] Les environnements jails : http://www.freebsd.org/doc/fr/books/handbook/jails.html

[5] Le gestionnaire de paquets pkgng : https://wiki.freebsd.org/pkgng

[6] Les ports FreeBSD : http://www.freebsd.org/ports/

[7] Site officiel d'OpenBSD : http://www.openbsd.org/

[8] Site officiel du projet LibreSSL : http://www.libressl.org/

[9] Routeur OpenBGPD : http://www.openbgpd.org/

[10] Serveur mail OpenSMTPD : https://www.opensmtpd.org/

[11] Outils de connectivité de réseau OpenSSH : http://www.openssh.com/

[12] Site officiel de Cobbler : http://www.cobblerd.org/

[13] Introduction à NanoBSD : http://www.freebsd.org/doc/fr/articles/nanobsd/

[14] Rump : https://github.com/rumpkernel/wiki/wiki

[15] mfsBSD : http://mfsbsd.vx.sk/

[16] Yaifo : https://github.com/jedisct1/yaifo

[17] Les disklabels BSD : http://fr.wikipedia.org/wiki/BSD_disklabel

[18] McKusick K., « A narrative history of BSD », https://www.youtube.com/watch?v=ds77e3aO9nA



Article rédigé par

Par le(s) même(s) auteur(s)

SmolBSD : un système UNIX de 7 mégaoctets qui démarre en moins d’une seconde

Magazine
Marque
GNU/Linux Magazine
Numéro
265
Mois de parution
septembre 2023
Spécialité(s)
Résumé

Que de racolage en si peu de mots. Et pourtant si, c’est bien la promesse de cet article, comment parvenir à construire un système d’exploitation fonctionnel en moins de… 10 mégabits. Quelle est cette sorcellerie ? En utilisant une fonctionnalité prévue, mais pas utilisée à cet escient par le noyau NetBSD, nous allons lui faire subir un régime drastique !

La grande migration, Épisode II

Magazine
Marque
Linux Pratique
Numéro
138
Mois de parution
juillet 2023
Spécialité(s)
Résumé

Dans l’épisode précédent [1], nous avons posé les premières briques d’une infrastructure d’auto-hébergement : vm-bhyve comme solution de virtualisation, sous FreeBSD donc, Wireguard comme gestionnaire de tunnel, une petite instance t4g.nano, 2 cœurs ARM64 et 512M de RAM chez AWS et un premier succès de déplacement de machine virtuelle hébergeant un simple serveur web d’un serveur dédié vers notre infrastructure personnelle. Nous allons voir maintenant comment migrer en douceur une machine virtuelle concentrant les services de base d’une architecture à l’autre.

La grande migration, Épisode I

Magazine
Marque
Linux Pratique
Numéro
137
Mois de parution
mai 2023
Spécialité(s)
Résumé

Il arrive parfois un jour où, ça y est, vous avez pris votre décision, le courage et l’envie sont là, c’est le moment : on va migrer. D’une ancienne technologie à une plus récente, par impératif professionnel, personnel, parce que c’est plus cohérent dans vos nouvelles coutumes, vous voyez exactement de quoi je parle, on frappe dans ses mains, on regarde le chantier, et on dit à voix haute : c’est parti.

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Les listes de lecture

8 article(s) - ajoutée le 01/07/2020
Découvrez notre sélection d'articles pour faire vos premiers pas avec les conteneurs, apprendre à les configurer et les utiliser au quotidien.
11 article(s) - ajoutée le 02/07/2020
Si vous recherchez quels sont les outils du DevOps et comment les utiliser, cette liste est faite pour vous.
8 article(s) - ajoutée le 02/07/2020
Il est essentiel d'effectuer des sauvegardes régulières de son travail pour éviter de perdre toutes ses données bêtement. De nombreux outils sont disponibles pour nous assister dans cette tâche.
Voir les 58 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous