Questions fréquentes à propose de Fedora CoreOS

Si vous avez d’autres questions que celles mentionnées ici ou si vous souhaitez échanger plus en détails, rejoignez-nous sur notre canal IRC Libera.Chat, #fedora-coreos, ou sur notre espace de discussion. N’hésitez pas à consulter à nouveau cette page car les questions et réponses seront mises à jour.

Qu’est-ce que Fedora CoreOS ?

Fedora CoreOS est un système d’exploitation avec mise à jour automatiques, minimal, monolithique, centré sur les conteneurs, conçu pour les clusters mais aussi fonctionnel indépendamment, optimisé pour Kubernetes mais aussi intéressant sans. Il a pour but de combiner le meilleur de CoreOS Container Linux et Fedora Atomic Host, en intégrant des technologies telles qu’Ignition provenant de Container Linux avec rpm-ostree et le durcissement via SELinux de Project Atomic. Son objectif est de proposer le meilleur système hôte pour exécuter des tâches dans des conteneurs de façon sûre et à l’échelle.

Quel est le rapport entre Fedora CoreOS et Red Hat CoreOS ?

Fedora CoreOS est une distribution communautaire et disponible librement, qui sert de base à Red Hat CoreOS. Alors que Fedora CoreOS se prête à une variété de cas d’usage à base de conteneurs, Red Hat CoreOS fourni un système d’exploitation centré sur OpenShift, mis à disposition et avec un cycle de vie lié à la plateforme.

Est-ce que Fedora CoreOS remplace Container Linux ? Qu’est-il arrivé à Container Linux ?

Fedora CoreOS est le successeur officiel de CoreOS Container Linux, mais ce n’est pas un remplaçant direct ne nécessitant aucune modification. CoreOS Container Linux sera en fin de vie à partir du 26 mai 2020 et ne recevra plus de mises à jour après cette date. Pour les notes de migration depuis Container Linux vers Fedora CoreOS, voir le guide de migration.

Est-ce que Fedora CoreOS remplace Fedora Atomic Host ? Que va-t-il arriver à Fedora Atomic Host et CentOS Atomic Host ?

Fedora CoreOS est le successeur official de Fedora Atomic Host. La dernière version de Fedora Atomic Host est la version 29, qui est désormais en fin de vie.

CentOS Atomic Host continuera de produire des versions « downstream » de RHEL Atomic Host et est aligné avec sa fin de vie. Le projet Fedora CoreOS est le point de rassemblement pour les distributions communautaires. Les utilisateurs sont encouragés à s’y rendre dans le futur.

Qu’est-il arrivé à projet Atomic ?

Project Atomic est un projet chapeau qui regroupe les deux versions d’Atomic Host (Fedora and CentOS) ainsi que d’autres projets relatifs aux conteneurs. Project Atomic en tant que nom de projet ne sera plus utilisé à partir de la fin de l’année 2018 car le l’éclairage sera mis sur les projets individuels qui ont eu du succès, tels Buildah et Cockpit. Cela permet de mieux regrouper la communauté liée au système d’exploitation avec Fedora et permettre ainsi une communication plus claire pour les autres projets supportés par la communauté, plus particulièrement le « hashtag » #nobigfatdaemons, l’approche de Buildah et l’outils graphique flexible de gestion de serveur Cockpit.

Quels sont les moyens de communication pour Fedora CoreOS ?

Nous avons les moyens de communication suivants pour Fedora CoreOS :

Une réunion de la communauté se tient chaque semaine. Plus d’informations sont disponibles dans le calendrier fedocal de Fedora CoreOS.

Si vous pensez avoir trouvé un problème avec Fedora CoreOS, n’hésitez pas à créer un ticket dans le tracker de bugs.

FAQ technique

Où puis-je télécharger Fedora CoreOS ?

Les versions de Fedora CoreOS sont disponibles à l’adresse getfedora.org.

Est-ce que Fedora CoreOS a la même philosophie que Container Linux au niveau des mises à jour ?

Oui, Fedora CoreOS est configuré pour des mises à jour automatiques régulières. Plusieurs flux de mise à jour sont mis à disposition pour convenir aux différents usages et besoins utilisateurs. Pour cela, un nouveau service basé sur rpm-ostree et responsable des mises à jour est présent sur chaque nœuds, avec un composant serveur qui peut être optionnellement auto-hébergé. Les échecs qui empêchent le système de démarrer après une mise à jour entraînent un retour automatique à la version précédente.

Comment sont provisionnés les nœuds Fedora CoreOS ? Puis-je réutiliser des configurations cloud-init existantes ?

Fedora CoreOS est provisionné à l’aide d’Ignition. En revanche, des changements sont nécessaires pour les configurations Ignition existantes car la configuration de l’OS diffère par rapport à Container Linux. Les configuration cloud-init existantes ne sont pas supportées et devront être converties en un équivalent pour Ignition.

Quels sont les données qui persistent au fil des mises à jour et redémarrages du système ?

Les dossiers /etc et /var sont montés en lecture-écriture pour laisser les utilisateurs y créer et modifier des fichiers.

Le contenu du dossier etc peut évoluer en fonction des déploiements, mais les changements réalisés par l’administrateur seront préservés. Le contenu de /var est laissé inchangé par rpm-ostree lors de l’application des mises à jour ou d’un retour en arrière. Pour plus d’informations, se référer à la documentation sur Systèmes de fichiers montés.

Comment puis-je migrer de Container Linux à Fedora CoreOS ?

Les migrations peuvent être effectuées à l’aide d’un re-provisionnement du système avec Fedora CoreOS. Pour les notes de migration de Container Linux à Fedora CoreOS, voir le guide de migration.

Comment puis-je migrer de Fedora Atomic Host à Fedora CoreOS ?

De même que pour Container Linux, il est recommandé de re-provisionner le nœud suite à la transition de cloud-init à Ignition. Comme Fedora CoreOS est basé sur la technologie rpm-ostree, il est possible de convertir un système Fedora Atomic Host en Fedora CoreOS, mais ce n’est pas recommandé. Il est préférable de monter en expérience dans le déploiement de système à l’aide d’Ignition pour permettre ainsi de les re-provisionner facilement si nécessaire. Pour les notes de migration de Atomic Host à Fedora CoreOS, voir le guide de migration.

Quels sont les gestionnaires de conteneurs disponibles sur Fedora CoreOS ?

Fedora CoreOS inclut Docker et podman par défaut. Cette liste pourra évoluer en fonction des besoins de la communauté et du support disponible.

Quelles sont les plateformes supportées par Fedora CoreOS ?

Fedora CoreOS fonctionne (liste non-exhausitve) sur

  • Alibaba Cloud,

  • AWS,

  • Azure,

  • GCP,

  • OpenStack,

  • QEMU,

  • VMware,

  • et les système physiques si installé sur un disque ou démarré depuis le réseau.

Est-ce que je peux faire fonctionner Kubernetes sur Fedora CoreOS ?

Oui. En revanche, Fedora CoreOS n’inclue pas d’orchestrateur de conteneur (ou de version spécifique de Kubernetes) par défaut — comme Container Linux et Atomic Host. Nous travaillerons avec la communauté « upstream » Kubernetes sur des outils (par exemple kubeadm) et des recommandations pour installer Kubernetes sur Fedora CoreOS.

Que dois-je faire pour exécuter des applications spécifiques sur Fedora CoreOS ?

Sur Fedora CoreOS, les conteneurs sont le mécanisme privilégié pour installer et configurer des applications qui ne sont pas fournies dans le système de base. Le mécanisme de superposition ou ajout de paquets RPM fourni par rpm-ostree restera disponible notamment pour debugger un système Fedora CoreOS, mais nous décourageons fortement sont utilisation. Pour plus d’informations à ce sujet, reportez-vous à la documentation.

Où puis-je trouver mon outils préféré pour le débogage ?

L’image système de Fedora CoreOS est gardé minimale volontairement. La majeure partie des outils de diagnostic ne sont pas inclus par défaut. A la place, il est recommandé d’utiliser l’utilitaire toolbox pour les obtenir.

Comment puis-je coordonner les mises à jour du système à m’échelle d’un cluster ? Est-ce que locksmith ou le Container Linux Update Operator est disponible avec Fedora CoreOS ?

La fonctionnalité etcd-lock du projet locksmith a été directement importée dans Zincati en tant que stratégie de mise à jour à base de verrous. De plus, cette fonctionnalité a été généralisée pour supporter plusieurs type de services en arrière plan et ne plus être ainsi limitée à etcd2 uniquement.

Les fonctionnalités du gestionnaire de mise à jour de Container Linux (Container Linux Update Operator ou CLUO) ont été intégrées dans le gestionnaire de configuration système (Machine Config Operator ou MCO), qui est un composant principal d’OKD. Le MCO est aussi capable de gérer la réconciliation des changements de configuration système.

Comment puis-je ajouter Fedora CoreOS à une région AWS EC2 privée ?

Fedora CoreOS est pour l’instant uniquement disponible dans les régions AWS standards. Pour les régions spécifiques telles que GovCloud et AWS China, vous devez ajouter les images de vous même.

Notez que Fedora CoreOS fait usage d’un partitionnement spécifique unifié BIOS et UEFI. Ainsi, il n’est pas compatible avec l’API aws ec2 import-image (pour plus d’informations, voir cette discussion). A la place, vous devez utiliser aws ec2 import-snapshot combiné avec aws ec2 register-image.

Pour plus d’informations sur ces APIs, voir la documentation AWS pour importer des « snapshots » et créer des AMIs à partir d’un EBS.

Est-ce que je peux faire fonctionner des conteneurs avec Docker et podman simultanément ?

Non. Faire fonctionner des conteneurs avec docker et podman simultanément peut cause des problèmes et des comportement inattendus. Nous recommandons fortement de ne pas essayer d’utiliser les deux en même temps.

Il est important de noter qu’avec Fedora CoreOS nous avons désactivé docker.service par défaut mais qu’il est automatiquement démarré si une connection est établie via la socket /var/run/docker.sock car docker.socket est activé par défaut. Cela veut dire que si l’utilisateur lance une commande docker (via sudo docker) alors le démon sera activé. Ce choix a été décidé pour faciliter la transition pour les utilisateurs de Container Linux.

Dans le ticket coreos/fedora-coreos-tracker#408 il a été pointé qu’au vu de l’activation à l’aide d’une socket UNIX, les utilisateurs de podman pourraient démarrer le démon docker de façon non-intentionnelle. Cette configuration pourrait réduire la sécurité du système à cause des interactions de chaque gestionnaire de conteneurs sur le pare-feu du système. Pour éviter ce problème, vous pouvez désactiver docker complètement en masquant l’unit systemd docker.service.

Exemple de configuration Butane pour désactiver le service docker.service
variant: fcos
version: 1.4.0
systemd:
  units:
    - name: docker.service
      mask: true

Est-il est possible d’utiliser les images disques de Fedora CoreOS à la fois pour les systèmes avec BIOS ou Firmware UEFI ?

Les images qui sont fournies sont à la fois compatibles avec les système BIOS (ancienne génération) et UEFI. Ces images sont construites avec un partitionnement hybride BIOS/UEFI ce qui les rend compatible avec les deux fonctionnements. L’exception à cette règle est l’image metal4k (image native format 4k), qui est spécifiquement prévue pour les disques avec des secteurs 4k, et qui n’a pas de partition pour démarrer avec un BIOS parce que les disques natifs 4k sont supportés uniquement avec UEFI.

Quelle est la différence entre les configurations Ignition et Butane ?

Les configuration pour Ignition sont une interface bas niveau utilisée pour définir l’ensemble des options de configuration pour une instance. Cette interface est prévue pour être utilisée par un programme car le contenu est encodé en JSON et la structure suit un schéma fixe. Cette configuration en JSON est utilisée par chaque instance de Fedora CoreOS lors du premier démarrage.

Plusieurs outils de plus haut niveau existent pour générer des configurations pour Ignition à partir d’un format spécifique, comme par exemple terraform, matchbox, openshift-installer et Butane.

Butane est l’un de ces outils de plus haut niveau. Il a été conçu pour être plus accessible, définit ses propres options de configuration et utilise le format YAML. Cette configuration YAML n’est jamais directement lue par les systèmes Fedora CoreOS (seul le résultat de la conversion en configuration Ignition l’est).

Bien que similaire, les configurations Ignition et Butane n’ont pas la même structure. Ainsi, une conversion de l’un vers l’autre n’est pas uniquement une conversion YAML vers JSON mais implique des étapes supplémentaires. Butane propose des raccourcis (par exemple des options spécifiques à certaines distributions et des configurations courantes) qui ne sont pas présentes dans Ignition et rendent ainsi les formats non-interchangeables. De plus, les différents formats (YAML pour Butane, JSON pour Ignition) permettent d’éviter de mélanger les configurations par mégarde.

Quel est le format utilisé pour les numéros de version ?

La documentation de conception explique ce sujet en détails.

Pour résumer, Fedora CoreOS utilise le format X.Y.Z.A

  • X est la version majeure de Fedora (par exemple 32)

  • Y est l’horodatage correspondant à l’instant où l’ensemble des paquets utilisé des dépôts de Fedora a été figé (par exemple 20200715)

  • Z est le code utilisé pour les versions officielles

    • 1 pour le flux next

    • 2 pour le flux testing

    • 3 pour le flux stable

  • A est un numéro de révision qui est incrémenté pour chaque nouvelle construction du projet avec les même paramètres X.Y.Z

Le format de numérotation de version peut être amené à évoluer et n’a pas été prévu pour être analysé de façon automatisée.

Pourquoi l’unit systemd 'dnsmasq.service' est-elle masquée ?

Nous avons découvert que le binaire dnsmasq peut être utilisé par plusieurs applications du système, notamment podman et NetworkManager. Pour cette raison, nous incluons le paquet dnsmasq dans l’image OSTree de base, mais nous décourageons l’usage de dnsmasq.service sur l’hôte en le masquant avec systemctl mask dnsmasq.service.

"Pourquoi est-ce que vous masquez le service ?"

dnsmasq est aussi utile en tant que serveur DHCP/DNS/TFTP accessible à des clients externes (i.e. non local au système), mais nous préférons que les utilisateurs obtiennent ces fonctionnalités à l’aide d’un conteneur. Placer un tel service à l’intérieur d’un conteneur l’isole des changements résultants de la mise à jour du système hôte et des potentiels problèmes de compatibilité. Par exemple, si NetworkManager et podman arrêtent d’utiliser dnsmasq, nous retirerons dnsmasq de l’hôte et le service sur lequel vous dépendiez cesserai de fonctionner.

"Mais je souhaite vraiment l’utiliser !"

Nous ne le recommandons pas, mais si vous le souhaitez vraiment, vous pouvez démasquer l’unit et l’activer :

Exemple de configuration Butane pour démasquer le service dnsmasq.service
variant: fcos
version: 1.4.0
systemd:
  units:
    - name: dnsmasq.service
      mask: false
      enabled: true

Pour plus d’informations, voir la discussion dans le traquer de bugs.

Why does SSH stop working after upgrading to Fedora 33?

In Fedora 33 there was a change to implement stronger crypto defaults. Part of this included taking the advice of OpenSSH upstream and disabling the use of the ssh-rsa public key signature algorithm.

You may hit issues if you use RSA keys and:

  • use an old version of the SSH client

  • use tooling/software libraries that don’t support using RSA SHA2 public key signatures

For example, Go has an open issue to solve this problem in its SSH implementation, but has yet to resolve it. This has been hit and worked around by the FCOS community in our build tooling and also our higher level projects:

If you run into this problem and need to work around the issue, you have a few options:

  • Switch to a newer non-RSA key type.

  • Provide a configuration to your machine that re-enables the insecure key signatures:

Exemple de configuration Butane pour réactiver les signatures de clé SSH RSA SHA1
variant: fcos
version: 1.4.0
storage:
  files:
    - path: /etc/ssh/sshd_config.d/10-insecure-rsa-keysig.conf
      mode: 0600
      contents:
        inline: |
          PubkeyAcceptedKeyTypes=+ssh-rsa

Why do I get SELinux denials after updates if I have local policy modifications?

Currently the OSTree and SELinux tooling conflict a bit. If you have permanently applied local policy modifications then policy updates delivered by the OS will no longer apply; your policy stays frozen. This means any policy "fixes" needed to enable new functionality will not get applied. See coreos/fedora-coreos-tracker#701 for more details.

This means you may see denials like the following, which can take down critical parts of a system like in coreos/fedora-coreos-tracker#700:

Example SELinux denial
systemd-resolved[755]: Failed to symlink /run/systemd/resolve/stub-resolv.conf: Permission denied
audit[755]: AVC avc:  denied  { create } for  pid=755 comm="systemd-resolve" name=".#stub-resolv.confc418434d59d7d93a" scontext=system_u:system_r:systemd_resolved_t:s0 tcontext=system_u:object_r:systemd_resolved_var_run_t:s0 tclass=lnk_file permissive=0

To see if your system currently has local policy modifications you can run ostree admin config-diff. The following system has a modified policy:

Example system with a modified SELinux policy
$ sudo ostree admin config-diff | grep selinux/targeted/policy
M    selinux/targeted/policy/policy.32

To work around this incompatibility, please attempt to apply policy modifications dynamically. For example, for an SELinux boolean you can use the following systemd unit that executes on every boot:

Example Butane config for dynamically applying SELinux boolean
variant: fcos
version: 1.4.0
systemd:
  units:
    - name: setsebool.service
      enabled: true
      contents: |
        [Service]
        Type=oneshot
        ExecStart=setsebool container_manage_cgroup true
        RemainAfterExit=yes
        [Install]
        WantedBy=multi-user.target

If your system’s basic functionality has stopped working because of SELinux denials check to see if your system currently has local policy modifications. You can check with ostree admin config-diff:

Example system with a modified SELinux policy
$ sudo ostree admin config-diff | grep selinux/targeted/policy
M    selinux/targeted/policy/policy.32

If your system is in this state you have two options:

  • Re-deploy starting with the latest image artifacts.

    • This means you start with the latest policy.

  • Follow the workaround in coreos/fedora-coreos-tracker#701 to restore the base policy.

Pourquoi l’unité systemd 'systemd-repart.service' est-elle masquée ?

system-repart is a tool to grow and add partitions to a partition table. On Fedora CoreOS, we only support using Ignition to create partitions, filesystems and mount points, thus systemd-repart is masked by default.

Ignition runs on first boot in the initramfs and is aware of Fedora CoreOS specific disk layout. It is also capable of reconfiguring the root filesystem (from xfs to ext4 for example), setting up LUKS, etc…​ See the Configuring Storage page for examples.

See the Why is the dnsmasq.service systemd unit masked entry for an example config to unmask this unit.