Questions fréquentes à propose de Fedora CoreOS

If you have other questions than are mentioned here or want to discuss further, join us in our Matrix room, #coreos:fedoraproject.org, or on our discussion board. Please refer back here as some questions and answers will likely get updated.

Qu’est-ce que Fedora CoreOS ?

Fedora CoreOS is an automatically updating, minimal, monolithic, container-focused operating system, designed for clusters but also operable standalone, optimized for Kubernetes but also great without it. Its goal is to provide the best container host to run containerized workloads securely and at scale.

How does Fedora CoreOS relate to RHEL CoreOS?

Fedora CoreOS is a freely available, community distribution that is the upstream basis for RHEL CoreOS. While Fedora CoreOS embraces a variety of containerized use cases, RHEL CoreOS provides a focused OS for OpenShift, released and life-cycled in tandem with the platform.

Quels sont les moyens de communication pour Fedora CoreOS ?

Nous avons les moyens de communication suivants pour Fedora CoreOS :

There is a community meeting that happens every week. See the Fedora CoreOS fedocal for the most up-to-date information.

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

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

Fedora CoreOS artifacts are available at fedoraproject.org.

Does Fedora CoreOS update itself automatically?

Yes, Fedora CoreOS comes with automatic updates and regular releases. Multiple update channels are provided catering to different users' needs. Fedora CoreOS provides a node-update service based on rpm-ostree technologies, with a server component that can be optionally self-hosted.

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

Fedora CoreOS is provisioned with Ignition. Existing cloud-init configurations are not supported and will need to be migrated into their Ignition equivalent.

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.

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.

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

Yes. However, Fedora CoreOS does not include a specific container orchestrator (or version of Kubernetes) by default.

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.

How do I coordinate cluster-wide OS updates?

The Zincati update manager includes a lock-based updates strategy that supports multiple backends.

OKD’s Machine Config Operator (MCO) automatically handles updates of Fedora CoreOS in OKD clusters. The MCO additionally covers reconciliation of machine configuration changes.

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.

It is worth noting that in Fedora CoreOS we have docker.service disabled by default but it is easily started if anything communicates with the /var/run/docker.sock because docker.socket is enabled by default. This means that if a user runs any docker command (via sudo docker) then the daemon will be activated.

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.5.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.

Why is the dnsmasq.service systemd unit masked?

We have found that the dnsmasq binary can be used for several host applications, including podman and NetworkManager. For this reason we include the dnsmasq package in the base OSTree layer, but we discourage the use of the dnsmasq.service in the host by masking it with 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.5.0
systemd:
  units:
    - name: dnsmasq.service
      mask: false
      enabled: true

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

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.5.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.

Why is the systemd-repart.service systemd unit masked?

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.

How do I keep dropped wireless firmware?

Some Wi-Fi firmwares were split into subpackages in Fedora 39 and Fedora 40. Fedora CoresOS will keep them in until Fedora 41, but display a warning message in the console if NetworkManager-wifi is layered without any other Wi-Fi firmware packages layered.

To request the Wi-Fi firmware stay installed even when Fedora CoreOS drops these packages please follow the steps to perform Wi-Fi enablement on an existing system.

Once the packages are requested you can now disable the warning so it won’t be checked on subsequent boots.

sudo systemctl disable coreos-check-wireless-firmwares.service