Questions fréquentes à propose de 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.

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.

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.

Fedora CoreOS artifacts are available at fedoraproject.org.

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.

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

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.

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

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

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.

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.

Débogage avec Toolbx.

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.

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.

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.

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.

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.

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

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

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.

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 :

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

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:

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

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:

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:

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

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.

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.