FreeBSD 11.1

39
28
juil.
2017
FreeBSD

Après la publication de versions bêtas depuis le 10 juin 2017 et une première version candidate le 30 juin, FreeBSD 11.1 est disponible depuis le 26 juillet.

C’est la première mise à jour dite mineure de FreeBSD 11 ; ce qui, pour suivre le principe POLA (Principle Of Least Astonishment), ne devrait pas vous exposer à des changements de configuration contraignants.

FREEBSD

Pour rappel, FreeBSD est un système complet issu de la famille UNIX, qui comprend un noyau et une base d’outils et de bibliothèques, dont une suite de développement logiciel ainsi qu’un mécanisme d’installation de logiciels tiers.

Cette version rassemble en premier lieu l’ensemble des correctifs publiés depuis la publication de la version 11 et branche nombre d’outils et de bibliothèques de la base sur les révisions officielles (upstream). Elle apporte la prise en charge de nouveaux matériels et de nouvelles fonctionnalités et intègre les améliorations développées tout le long du cycle de développement de la branche 11-STABLE. Elle démine aussi le terrain en déclarant obsolète les outils ou configurations qui pourraient évoluer ou disparaître lors de la sortie de FreeBSD 12. Pensez à consulter les journaux du système, à la recherche d’avertissements qui auraient pu survenir : ils pourraient vous prévenir de l’utilisation de clefs ou de configurations dépréciées et donc susceptibles de disparaître lors de la prochaine mise à jour.

Sommaire

À noter

Si cette nouvelle version ne devrait pas bouleverser vos habitudes, ces quelques changements intéressants sont à noter :

  • la suite de compilation Clang/LLVM 4.0 est désormais livrée de base ;
  • les Chromebook sont pris en charge via le pilote chromebook_platform(4) ;
  • blacklistd(8), le démon venu de NetBSD qui remplit la liste noire de votre pare‐feu à l’initiative d’autres démons, écoute le serveur OpenSSH.

Un important travail d’amélioration d’IPsec a été effectué, avec, en autres, l’intégration de la pseudo‐interface réseau if_ipsec(4), qui implémente des tunnels IPsec virtuels pour créer des routes sur VPN.

Les récentes annonces concernant les failles de type « stackclash » ont été entendues et cette version propose un correctif.

Procédures

Plusieurs moyens sont à votre disposition pour obtenir le système, de l’installation complète sur une machine physique aux images pour hyperviseurs en passant, bien sûr, par la simple mise à jour.

Des DVD, manuels et autres décapsuleurs sont en vente sur le site FreeBSD Mall.

Installation

Cette version est disponible pour un grand nombre d’architectures, des classiques AMD64/x86 aux ARMv6 en passant par les PowerPC et SPARC64. Téléchargez une image depuis le site officiel à graver sur CD (ISO) ou clef USB (img).

Notez que les images ARM et ARM64 configurent par défaut le compte freebsd/freebsd sur ssh. Pensez à les mettre à jour, ainsi que le mot de passe du super‐utilisateur root.

Pour installer aisément le système dans une machine virtuelle, des images au format QCOW2 (QEMU), VHD (VirtualBox), VMDK (VMware) et raw (HDD), sont proposées pour les architectures AMD64, x86 et AArch64.

En ce qui concerne les cibles ARM64 et AArch64, une amorce EFI modifiée pour QEMU est requise pour pouvoir démarrer :

    % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
    -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \
    -drive if=none,file=VMDISK,id=hd0 \
    -device virtio-blk-device,drive=hd0 \
    -device virtio-net-device,netdev=net0 \
    -netdev user,id=net0

Attention, l’architecture ARM64 présente quelques soucis décrits dans le paragraphe suivant.

Des images sont aussi proposées par Amazon et Vagrant.

Désormais, l’installeur, bsdinstall(8) prend en charge les réseaux cachés lors la configuration du Wi‐Fi. De plus, il crée une partition UEFI plus grande, de 200 Mio.

Mise à jour

S’il ne s’agit que de mettre à jour une version antérieure, suivez la procédure
habituelle :

# freebsd-update upgrade -r 11.1-RELEASE

Acceptez ou adaptez les fichiers de configuration, puis installez le nouveau système :

# freebsd-update install
# shutdown -r now
# freebsd-update install

Il est ici conseillé de mettre à jour tous les logiciels installés :

# freebsd-update install

Errata

Plusieurs problèmes sont apparus sans avoir pu être corrigés avant la sortie de cette release, consultez les errata pour vérifier que votre installation n’est pas concernée.

i386

FreeBSD pourrait échouer à démarrer sur i386 suite à l’intégration de kern.kstack_pages. Pour contourner le problème, appuyer sur Échap dès le démarrage, pour obtenir une invite de commande et entrez :

set kern.kstack_pages=4
boot

depuis les sources

Suite à un bogue dans les anciennes versions de Clang, il est recommandé de mettre à jour les machines sous 9.x vers la révision r286035 et les machines sous 10.x vers r286033, si vous reconstruisez le système depuis les sources.

ARM64

L’architecture ARM64 ne fournit pas d’horloge RTC sous EFI, le système va donc démarrer sans avoir de date correctement configurée.

Les installations dont la partition racine (root) est sous ZFS peuvent refuser de démarrer. Malheureusement, il n’y a pas de solution à ce problème.

VirtualBox

Les systèmes qui tournent sous VirtualBox et qui ont mis à jour depuis la RC2 doivent réinstaller le paquet virtualbox-ose-additions ou virtualbox-ose-additions-nox11. Pour assurer le démarrage après la mise à jour, désactivez vboxguest dans rc.conf(5).

Nouveautés

On trouve un bon nombre de nouvelles options de configuration ou de construction dans cette publication. La plupart vous permettent d’adapter le système à vos besoins et aux limites de votre machine.

Configuration

Le fichier src.conf(5) est destiné à configurer votre système, la base comme le noyau, lors de sa construction. Les variables suivantes amènent de nouvelles fonctions ou de nouveaux comportements :

  • WITHOUT_TCP_WRAPPERS : le service inetd(8) ne prend plus en charge libwrap ;
  • WITHOUT_LIBTHR : la bibliothèque libthr(3) et les fichiers associés sont maintenant validés et supprimés lors d’un delete-old-libs ;
  • WITH_RPCBIND_WARMSTART_SUPPORT : elle permet de construire rpcbind(8) sans la prise en charge (-w) de démarrage à chaud warmstart (sauvegarde des infos RPC en cas de coupure).

Depuis quelques années, afin de vous permettre de configurer vos machines plus finement tout en conservant une base générique, nombre d’outils ou services incluent un répertoire ou un fichier /usr/local/etc pour leur configuration en plus de /etc. Cette révision apporte cette facilité pour les logiciels suivants :

  • cron(8) lit /usr/local/etc/cron.d en plus de /etc/cron.d ;
  • syslog.conf(5), lit /etc/syslog.d et /usr/local/etc/syslog.d par défaut.

Les scripts periodic(8), qui prédéfinissent des actions à réaliser à intervalles réguliers, comprennent de nouveaux éléments :

  • les options anticongestion_sleeptime et consolidating random sleeps remplacent daily_ntpd_avoid_congestion, dont les valeurs par défaut sont de 3 600 secondes ;
  • ajout de 410.status-mfi (daily_status_mfi_enable) pour surveiller les contrôleurs RAID mfi(4).

Ajout de l’entrée jail_confwarn dans rc.conf(5) qui élimine les avertissements générés par des configuration jail(8) obsolètes.

Démarrage

L’option vfs.root_mount_always_wait est ajoutée ; elle force le noyau à attendre la fin des montages, même si le point de montage racine est présent. C’est utile en particulier pour attendre les montages sur USB.

L’option EARLY_AP_STARTUP du noyau est activée par défaut sur les architectures AMD64 (MINIMAL et GENERIC) comme i386 ; elle active les processeurs restants ( Application Processors , grosso modo : mettre en route le SMP ) plus tôt dans le démarrage du noyau. Ce qui devrait l’accélérer (un peu).

L’amorçage EFI prend en charge TFTPFS, qui permet de démarrer depuis le réseau sans serveur NFS. Levez le drapeau LOADER_TFTP_SUPPORT lors de la construction du chargeur d’amorçage pour l’activer, depuis make.conf(5). La variable netproto fixe la méthode avec les valeurs NET_TFTP, NET_NFS ou NET_NONE. En cas d’appel à dhcp, le choix va dépendre des options choisies.

ZFS

Le système de fichiers phare de FreeBSD a été revu et amélioré.

En particulier, l’intégration de l’outil zfsbootcfg(8) permet des configurations dans le style de boot.config(5) pour zfsboot(8).

La clef vfs.zfs.debug_flags disparaît au profit de vfs.zfs.debugflags qui peut être appelée depuis loader.conf(5) ; donc, dès le démarrage.

La clef vfs.zfs.compressed_arc_enabled, est activée par défaut. Elle autorise la compression en mémoire des données ARC de ZFS, ce qui permet de stocker plus de cache en mémoire. Pour compléter, top(1) présente la part du cache qui est compressée et calcule son ratio :

ARC: 390M Total, 49M MFU, 332M MRU, 16K Anon, 2165K Header, 6895K Other
     310M Compressed, 397M Uncompressed, 1.28:1 Ratio

En revanche, vous ne pouvez plus créer d’instantanés (snapshots) ZFS directement par un mkdir sous le répertoire .zfs.

Base

La base, appelée aussi « le monde », est l’ensemble des outils et bibliothèques livrées avec le système. Tout ou presque aurait pu être listé sous ce chapitre. J’indique ici les apports isolés auxquels je ne pouvais pas consacrer une rubrique.

Le moteur de jail(8) permet désormais d’assigner explicitement des adresses IPv4 et IPv6.

Il est possible de router les sorties stdout et stderr de daemon(8) vers syslog(3) ou un fichier.

L’outil ELF(1) a été branché sur la révision r3490. En particulier, il précise désormais l’architecture ARM de l’objet.

L’utilitaire strings(1) a corrigé son statut en cas d’erreur survenue sur une liste de fichiers.

L’interpréteur Shell tcsh a rejoint la version 6.20.0.

L’outil de génération d’analyseurs byacc(1) rejoint la version 20170201. À noter : nombre d’apports venus de NetBSD.

L’outil primes(6) liste des nombres premiers au‐delà de 3825123056546413050, jusqu’à 264 - 1 (en fait, (uint64_t)(-1)).

reproducible.org

Des efforts ont été fournis pour suivre les recommandations de reproducible-builds.org et ainsi permettre de mieux cerner et corriger les problèmes rencontrés par les utilisateurs.

Par exemple, groff(1) utilise la première date du fichier CHANGELOG, donc la plus récente, plutôt que celle du fichier à traiter. À noter que ce vénérable outil sera déclaré obsolète dès FreeBSD 12.

Amélioration de mandoc(1) pour rendre sa sortie plus cohérente. En particulier, l’ordre de parcours des fichiers est prédéterminé, les pages et leurs liens, triés.

Le script sys/conf/newvers.sh comprend les options (-[rR]) qui permettent d’exclure les métadonnées (hostname, username) de la construction du noyau. Vous pouvez fixer cette option dans src.conf par WITH_REPRODUCIBLE_BUILD.

Le système de démarrage UEFI fixe l’horodatage des objets PE/COFF à une valeur arbitraire, mais connue.

Noyau et ABI

Cette rubrique s’adresse surtout aux développeurs et à ceux qui aiment se concocter un noyau aux petits oignons ou améliorer la sécurité de l’ensemble.

Quand l’horloge temps réel (RTC) est mise à jour, par clock_settime(2), les fils d’exécution (threads) en sommeil sont réveillés et leur valeur de « temps de sommeil » est réévaluée.

La bibliothèque libmd (chiffrement) ajoute des fonctions qui prennent comme argument un descripteur plutôt qu’un nom de fichier.

Correction d’un bogue qui date d’une importation de BSD4.4-Lite (il y a 23 ans) : la routine kvm_close(3) renvoie un masque correspondant aux erreurs survenues depuis le dernier appel à close(2) au lieu de 0.

Arrivée de clock_nanosleep(2), ex-nanosleep(2), pour se conformer à POSIX.

L’extension reallocarray(3) venue d’OpenBSD, déjà incluse dans la libc, est utilisée en lieu et place de realloc dans nombre de bibliothèques (dont la libc elle‐même) pour mieux contrôler les débordements.

Suite aux récentes découvertes sur les stack clashes, le drapeau MAP_GUARD a été intégré à l’allocateur mémoire mmap(2) pour poser une barrière sous la pile.
Ces barrières sont aussi utilisées par rtld(1), si le noyau le permet.
Notez que HardenedBSD a choisi une implémentation différente pour protéger le système.

Développer, Compiler, déboguer

La chaîne de compilation est portée à la version 4 de LLVM/CLang, sur toutes les architectures. Vous pouvez enfin utiliser lldb et son interface utilisateur depuis la base.

Plus triviale, mise à jour des en‐têtes pour fournir les entrées suivantes :

  • définition de max_align_t pour assurer la compatibilité C11 ;
  • ajout du qualificatif nullability dans la libc ;
  • l’attribut GNU __nonnull__ a été remplacé par le nullability de Clang ; Les portages compilés avant janvier 2017 (r312860) devront être reconstruits.

Enfin, l’option WITH_LLD_AS_LD a été ajoutée ; elle installe ldd(1) sur /usr/bin/ld. Quel que soit ce réglage, l’éditeur de liens (linker) reste ld(1) pour le noyau et le monde. Ce réglage n’est activé par défaut que sur ARM64.

Notre bmake à nous intègre la version 20170510, en coopération avec NetBSD.

Pour déboguer plus aisément, ptrace(2) prend en charge les événements de vfork(2).

Les vidages mémoire (core dumps) contiennent maintenant les identifiants des processus (PID) et les arguments précisés en ligne de commande.

On ne peut plus accéder à /dev/kmem via mmap(2). Pour cela, vous devez utiliser les appels read() et write().

Manipulation de variables UEFI via efivar(8).

Bacs à sable

L’intégration des solutions d’accès cloisonnés aux ressources, Capsicum et cloudabi, continue…

Capsicum est pris en charge par bspatch(1).

cloudabi(4) comprend les binaires 32 bits dans un environnement 64 bits si l’option du noyau COMPAT_CLOUDABI32 est activée.

Plusieurs routines peuvent maintenant être appelées en mode cloisonné :

L’hyperviseur bhyve est en cours de « capsicumisation ».

Réseau

Que ce soit sur la pile réseau elle‐même, les fonctionnalités ou sur la prise en charge de nouvelles cartes, cette version apporte de nombreuses nouveautés, à commencer par le travail sur les protocoles liés à IPsec(4).

IPsec

Les modules ipsec et tcpmd5 ont été ajoutés ; ils sont chargés automatiquement si l’option IPSEC_SUPPORT est activée dans le noyau. Ceux‐ci apportent l’interface if_ipsec(4). Dans les configurations, l’option IPSEC_FILTERTUNNEL du noyau a été abandonnée au profit des clefs net.inet.ipsec.filtertunnel et net.inet6.ipsec6.filtertunnel. Pour les développeurs, le code associé a été déplacé vers sys/netipsec.

Prise en charge par défaut de NAT-T. L’option du noyau IPSEC_NAT_T a été supprimée.
Modification de setkey(8) pour afficher la configuration NAT-T. Les commutateurs -g et -t permettent d’afficher respectivement les règles globales et virtuelles, associés aux drapeaux -D et -P.

Suppression de l’encapsulation de type UDP_ENCAP_ESPINUDP_NON_IKE.

Pare‐feu

Quelques modifications majeures du pare‐feu ipfw(4) :

  • accès aux états dynamiques par un nom ;
  • ajout du module ipfw_nptv6, implémentation de Network Prefix Translation for IPv6 de la RFC 6296 ;
  • ajout du module ipfw_nat64, implémentation de règles NAT64 stateless et stateful ;
  • ajout du module ipfw_pmod, conçu pour manipuler les paquets de n’importe quel protocole, mais qui ne comprend que TCP MSS` actuellement.

OpenSSH prend en charge (enfin) blacklistd(8). Pour l’activer, ajoutez l’option UseBlacklist=yes dans votre sshd_config(5) ou sshd_flags="-o UseBlacklist=yes" dans votre src.conf(5).

Le drapeau keep state d’IPFilter n’inclut plus par défaut keep frags, pour respecter la spécification.

Pile

La pile réseau comprend l’appel ip6_tryforward(), qui en réduisant le nombre de contrôles améliore les performances.
Correction d’un cafouillage lors de l’émission de message UDP log_in_vain ou d’appel de inet_ntoa() dans un contexte concurrentiel.

Amélioration du redimensionnement automatique du tampon de réception de la pile TCP ; elle se déclenche par période de RTT (temps estimé d’une transmission suivie d’un acquittement). De plus, ce redimensionnement partage une fonction commune entre la méthode standard et les modules fastpath et n’est plus réinitialisé lors des réceptions en mode bulk (gros volumes). Tout ceci a permis un bond de performance d’environ 3 Mio/s à 100 Mio/s des téléchargements sous AWS S3.

Prise en charge des retransmissions GARP (gratuitous ARP), la nouvelle clef net.link.ether.inet.garp_rexmit_count en fixe le nombre maximum.

Venu de NetBSD, getaddrinfo(1) a débarqué.

Protocoles

Le client NFS est corrigé pour gérer correctement l’erreur NFS4ERR_BAD_SESSION. Il prend désormais en charge l’Elastic File System (EFS) d’Amazon.

Le client RPC du noyau évite de créer une nouvelle connexion TCP à la réception d’un ERESTART depuis un sosend().

Il est possible désormais de sauvegarder un mot de passe de plus de 18 caractères sur SMBFS.

Matériel

Le pilote cxgbe(4), dont le micrologiciel est porté à la version 1.16.45.0, s’attache aux cartes Chelsio T6. De plus, la fonctionnalité VFS (virtual functions) de ces modèles est apportée par le pilote cxgbev(4). Pour aider au débogage de ces cartes, l’outil cxgbetool(8) a été introduit.

Les pilotes suivants ont été ajoutés :

  • bnxt, pour les cartes Ethernet BCM57301/2/4 et BCM57402/4/6 ;
  • miibus(4), pour les contrôleurs Ethernet Microchip/Micrel KSZ9031 ;
  • alc(4), pour les contrôleurs Ethernet Atheros® Killer E2500™ ;
  • qlnxe(4), dont le micrologiciel a été porté à 8.30.0.0, pour les contrôleurs Ethernet basés sur Cavium® Qlogic™ 45000.

L’interface pour commutateur Ethernet etherswitch(4) ajoute les cartes RTL8366RB et RTL8366SR à sa collection.

le module ctl(4) ne prend plus en compte les périphériques iSCSI. C’est désormais le rôle de cfiscsi(4). Ajoutez WITH_ISCSI=yes dans src.conf(5) pour que les outils ctladm(8) et ctld(8) le prennent en charge.

D’un point de vue général, devctl(8) ajoute la commande clear driver qui supprime une assignation forcée par set driver.

Obsolescence programmée

Dans l’idée de promouvoir lldb, the debugger, les débogueurs gdb et kgdb sont dépréciés. Si leur disparition de la base est prévue pour la prochaine version majeure, cela ne devrait pas être le cas sur toutes les architectures.

Outre groff déjà mentionné, la série des vénérables « r-outils », rlogin, rwho et autres rsh, ainsi que les démons associés sont déclarés obsolètes. Il est prévu de les supprimer dans la version 12.

Du côté des pilotes, on annonce la fin de la prise en charge des périphériques et outils suivants :

Afin de respecter le POLA, Principle Of Least Astonishment, le système vous avertit pour toute déclaration d’un pilote, d’un outil ou d’une clef dépréciée.

Matériel

En vrac, FreeBSD prend en charge, améliore ou intègre de nouvelles fonctions aux périphériques suivants :

  • apport du module cfumass(4), qui fournit une interface aux matériels USB On‐The‐Go pour les déclarer en tant que lecteurs de mémoire Flash ;
  • jedec_ts(4) prend en charge les sondes de température pour les extensions mémoire ; actuellement, ce pilote comprend les cartes compatibles avec la spécification JEDEC JC 42.4 ;
  • le pilote mpr(4) comprend le tri‐mode (SAS/SATA/PCIe) des contrôleurs de disques Broadcom® et intègre plus de sorties de diagnostic apportées par NetFlix ;
  • prise en charge des cartes ARM Allwinner A13 ;
  • le pilote de clavier atkbdc(4) prend en charge les pavés tactiles via la clef hw.psm.elantech_support de loader.conf(5) ;
  • prise en charge des contrôleurs CPIO pour Intel® Bay Trail™ via bytgpio(4).

Le pilote des cartes SD mmcsd(4) dépend aussi de geom_flashmap. De plus, ce pilote dépend maintenant explicitement de celui de son bus mmc.

Virtualisation

Le transfert (passthrough) de périphériques PCI de bhyve(4) permet une configuration plus dynamique en autorisant l’affectation de périphériques vers l’hôte ou l’invité au‐delà du chargement de vmm. La clef hw.vmm.iommu.enable désactive cette fonction.

Chez Microsoft®, Hyper-V™ propose des machines virtuelles FreeBSD :

  • prise en charge de ces derniers passthrough PCI ;
  • le pilote de réseau virtuel hv_netvsc(4) implémente une interface pour gérer les cartes qui permettent le partage de ressources, Virtual Function (VF), c.‐à‐d. les cartes réseau Mellanox® Connect-X3™ ; ceci afin de permettre une migration sans coupure ;
  • mise à jour du chargeur UEFI pour pouvoir amorcer des machines virtuelles de deuxième génération ;
  • prise en charge des claviers synthetic keyboards.

Chez Amazon® EC2™ :

  • activation de l’IPv6 par défaut ;
  • intégration du module ena(4), soit la nouvelle génération de l’Elastic Network Adapter.

Correctifs

Les logiciels suivants ont été modifiés pour corriger un défaut de sécurité :

Les logiciels suivants ont été corrigés :

À venir

La troisième édition d’Absolute FreeBSD est en préparation.

Le dépôt de logiciels portmaster sera‐t‐il toujours maintenu ?

Rendez‐vous à l’EuroBSDCon qui se déroulera à Paris du 21 au 24 septembre 2017.

  • # Un pas de moins vers le passé

    Posté par (page perso) . Évalué à 9 (+7/-0).

    C'est une excellente nouvelle que FreeBSD arrive à se débarasser d'outils comme les r-machins. Je me souviens avoir vu une question sur IRC les concernant à laquelle bapt avait répondu qu'il suffisait de demander, et voila qu'ils sont marqués dépréciés et poubelle en 12.

    La disparition de groff est également une excellente nouvelle, la documentation va pouvoir être uniformisée.

    L'intérêt de Microsoft et AWS pour FreeBSD est toujours présent et c'est une excellente nouvelle qu'ils aient contribué à la couche drivers pour leurs cloud respectifs, c'est un frein de moins pour l'adoption de FreeBSD.

    Merci pour cette dépêche très complète (un peu plus complète que le changelog officiel :p)

    CNRS & UNIX-Experience

    • [^] # Re: Un pas de moins vers le passé

      Posté par (page perso) . Évalué à 4 (+3/-0).

      C'est une excellente nouvelle que FreeBSD arrive à se débarrasser d'outils comme les r-machins.

      Le plus curieux, c'est que rwall(1) soit toujours là.

      Une forme d' hommage peut-être.

      La disparition de groff est également une excellente nouvelle, la documentation va pouvoir être uniformisée.

      En fait, il y a plusieurs modifications sur la chaîne de mandoc(1) dont makewhatis(8). ( il y a une petite boulette dans les notes à ce sujet, mais je n'ai pas du le dire assez fort ).

      L'intérêt de Microsoft et AWS pour FreeBSD est toujours présent
      et c'est une excellente nouvelle qu'ils aient contribué à la couche drivers pour leurs cloud respectifs,
      c'est un frein de moins pour l'adoption de FreeBSD

      Il faut dire que l'intérêt affiché de compagnies comme NetAPP (qui a ses serveurs chez AWS ) ou Whatsapp ( donc Facebook ) pour FreeBSD ne doit pas être étranger à cette stratégie.

    • [^] # Re: Un pas de moins vers le passé

      Posté par (page perso) . Évalué à 2 (+1/-0).

      La disparition de groff est également une excellente nouvelle,
      la documentation va pouvoir être uniformisée.

      Notez que mandoc ,
      - C'est un projet indépendant -
      branché sur la 1.14, a subit beaucoup de modifications; entre autres, il ne dépend plus de sqlite.

    • [^] # Re: Un pas de moins vers le passé

      Posté par (page perso) . Évalué à 3 (+2/-0).

      C'est une excellente nouvelle que FreeBSD arrive à se débarasser d'outils comme les r-machins.

      Par contre, pour ruptime(1), rwho(1) et rwhod(8), c'est reporté à la 12.
      - Errata publié le 9 août -

  • # Installeur freebsd bsdinstall pour Arm

    Posté par . Évalué à 1 (+1/-0). Dernière modification le 28/07/17 à 15:46.

    Ce serait formidable de disposer d'une iso d'installation avec l'installeur freebsd pour l'architecture Arm à la maniere d'Openbsd. Pourquoi les releases sous Arm ne sont-elles pas construitent sur le modele des .tgz à installer via l'installeur ?

    Certe l'image actuelle convient pour un usage sur carte SD, mais pour un systeme que l'on souhaite installer sur un disque dur Sata avec un partitionnement customisé, il manque sans aucun doute en complément un bout de documentation sur la démarche correcte à suivre pour copier le systeme d'un support vers l'autre sans le compromettre ( droits, liens symboliques, etc… ).

    Je peux certe partir à l'aventure, dans la jungle du web à la recherche du bon logiciel avec la bonne ligne de commande à taper, parmis les avis personnels glanés sur des forums au cour des dix dernières années. Mais il serait cependant plus judicieux pour moi dans mon apprentissage comme pour le dev, de publier cela d'une facon officielle.

    J'ai donc appris a compiler une release avec une configuration customisé Armv6 pour obtenir mes fichiers .tgz que j'installe par la suite via l'installeur. Je partitionne mon disque dur, j'installe mes .tgz puis je fini a la mano pour ce qui est du bootloader u-boot.

    • [^] # Re: Installeur freebsd bsdinstall pour Arm

      Posté par (page perso) . Évalué à 3 (+2/-0).

      Je n'ai pas bien compris quel était le problème en fait. Sans doute parce que je ne sais pas ce que fait OpenBSD pour s'installer sur des ARM.
      Je «configure» l'installation sur le disque depuis une console et non par l'installeur, même sur un PC classique, en fait. Ensuite, bsdinstall(8) peut se lancer à n'importe quel moment.

      Mais il serait cependant plus judicieux pour moi dans mon apprentissage comme pour le dev, de publier cela d'une facon officielle

  • # cloud Microsoft Azure

    Posté par . Évalué à 1 (+1/-0).

    C'est bien que Microsoft supporte FreeBSD dans son cloud.

    Cependant, je ne comprend pas bien la description donnée dans cette dépêche :

    le pilote de réseau virtuel hv_netvsc(4) implémente une interface pour gérer les cartes qui permettent le partage de ressources, Virtual Function (VF), c.‐à‐d. les cartes réseau Mellanox® Connect-X3™ ; ceci afin de permettre une migration sans coupure

    Quelles ressources sont partagées ? Il me semble qu'il s'agit simplement de basculer d'un datapath à un autre ?

    Le patch : https://reviews.freebsd.org/D8964

  • # code

    Posté par . Évalué à 4 (+2/-0). Dernière modification le 01/08/17 à 10:41.

    J'ai vu plusieurs points intéressants pour les dev:

    • Notre bmake à nous intègre la version 20170510, en coopération avec NetBSD.

    bmake, c'est une alternative à gnu make? Quels sont ses points d'intérêts techniques (donc, hors licence)?

    • Venu de NetBSD, getaddrinfo(1) a débarqué.

    Euh… vous utilisiez quoi ces 16 dernières années, du coup? Je me souviens vaguement d'une autre fonction pour faire le même genre de trucs, sauf que de mémoire (impossible de me rappeler le nom, c'est pas possible ça!) IPv6 n'était pas supporté et elle apportait des problèmes de sécurité…
    Et pour le "ces 16 dernières années", je me base sur le fait que "Conforming To POSIX.1-2001" signifie pour moi que le standard en question date de 2001. Je me trompe peut-être cela dit.

    • Dans l’idée de promouvoir lldb, the debugger, les débogueurs gdb et kgdb sont dépréciés.

    Déprécier gdb, pourquoi pas. Faut dire que je ne suis pas fan de readline qui a des comportements aléatoires sur mes machines (genre "la commande grep est inconnue" dans bash, ou équivalent sous gdb, parce que cette stupide lib de readline semble ajouter des caractères invisibles suite à une typo que je corrige, mais seulement de façon aléatoire! grrr) et donc de tout logiciel qui se base dessus.
    Par contre, je suis intrigué pour kgdb: je ne m'en suis certes jamais servi, n'ayant jamais eu l'occasion de hacker du kernel, mais j'aurai tendance à penser que débug un kernel nécessite des outils spécifiques, alors que je soupçonne lldb d'être généraliste, à l'instar de gdb.

    Pour finir sur gdb/lldb… quid des frontends? La dernière fois que j'ai cherché (il y a moins d'un an) je n'ai trouvé aucun frontend correct. Ce n'est pas comme s'il en existait beaucoup pour gdb, mais j'arrive au moins à des résultats décents avec cgdb.
    J'avais vu que lldb avait une interface ncurses intégrée, mais j'ai été totalement incapable de m'en servir, et pas foutu de trouver la moindre doc à ce sujet non plus!

    Enfin, de toute façon, le fait de passer à clang/llvm rends la l'obsolescence de gdb inévitable: je ne compte plus les emmerdes que j'ai eues à débug du binaire clang avec gdb, alors j'imagine que la réciproque doit être vraie également.

    Mis à part ces points de dev, j'ai vu plusieurs fois l'idée d'une collaboration avec NetBSD?
    Je sais bien que le monde du libre est… libre, mais j'avais toujours imaginé les *BSD assez compartimenté, donc ça m'a surpris.
    Il y a un objectif à plus moyen terme derrière, ou c'est juste accidentel?
    Je sais que la philosophie de Net et Free BSD est très différente, mais peut-être que plus d'outils pourraient être partagés, ça serait pas mal.

    PS: pardon pour le pavé

    • [^] # Re: code

      Posté par (page perso) . Évalué à 4 (+3/-0).

      bmake

      C'est le make issu de NetBSD et c'est un make considéré comme portable. Il a été adopté sous FreeBSD 10 de mémoire et a remplacé pmake. Le make gnu est dans les ports, le cas échéant.

      getaddrinfo(1)

      C'est une commande, un wrapper, autour de la routine getaddrinfo(3) qui elle, existe depuis au moins FreeBSD 4 ( elle a du arriver quelque part en 3.x).
      Elle est là pour tenir compagnie aux netstat et autres sockstat.

      lldb

      J'ai trouvé assez simple l'utilisation de la gui lldb pour ma part, il suffit de taper gui à l'invite. Je conseille quand même de charger le code et les breakpoints avant. C'est bien plus utilisable que le mode tui de GDB.

      Partage de code

      Il y a toujours une coopération et du partage de code entre les différents BSD, de Open à Dragonfly.
      - pf, bmake, procctl, balcklistd, pilotes … C'est aussi une question de réseaux je pense. Les développeurs se rencontrent lors des BSDCon et communiquent leurs expériences plus facilement au sein de la famille.

      N'oubliez pas la coopération avec illumos, notamment avec zfs, dtrace et bientôt mdb ?

      • [^] # Re: code

        Posté par . Évalué à 2 (+0/-0). Dernière modification le 01/08/17 à 13:31.

        getaddrinfo(1)

        Ah ok… j'avais pas tilté le numéro de manpage! Ca explique tout du coup, merci.

        il suffit de taper gui à l'invite.

        Hum… moui, lancer l'interface, j'avais réussi. C'est m'en servir, que je n'ai pas réussi. Bon, je parle de la version de Debian aussi, devait être debian 7, donc ça a dû changer pas mal.
        Quant à gdb, j'admets ne pas avoir insisté avec son interface, vu que j'ai déjà cgdb qui me dépanne.

        • [^] # Re: code

          Posté par (page perso) . Évalué à 2 (+1/-0).

          [lldb GUI] C'est m'en servir, que je n'ai pas réussi. Bon, je parle de la version de Debian aussi, devait être debian 7, donc ça a dû changer pas mal.

          En fait, il suffit de lancer les mêmes commandes au clavier (s/n/c/ etc.) pour suivre l'évolution dans le code. Ça reste simple.
          Par contre, il ne fonctionne pas, ou très mal, chez moi sous (u)rxvt, je n'ai pas encore trouvé d'où venait le problème.

          • [^] # Re: code

            Posté par . Évalué à 2 (+0/-0).

            Du coup, c'est juste qu'il affiche le code correspondant à la section que l'on debug? Il n'y a pas vraiment de contrôle interactif, dans le sens ou l'on peut utiliser autre chose que des commandes pour le piloter?

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.