English Chinese (Simplified) (zh_CN)
$ sudo ostree admin config-diff | grep selinux/targeted/policy
M selinux/targeted/policy/policy.32
`1` for the `next` stream
`2` for the `testing` stream
`3` for the `stable` stream
`A` is a revision number that is incremented for each new build with the same `X.Y.Z` parameters
Alibaba Cloud,
Although similar, Ignition configurations and Butane ones do not have the same structure; thus, converting between them is not just a direct YAML-to-JSON translation, but it involves additional logic. Butane exposes several customization helpers (e.g. distribution specific entries and common abstractions) that are not present in Ignition and make the formats not interchangeable. Additionally, the different formats (YAML for Butane, JSON for Ignition) help to avoid mixing up inputs by mistake.
and bare-metal systems if installed to disk or network-booted.
Are Fedora CoreOS x86_64 disk images hybrid BIOS+UEFI bootable?
As with Container Linux, the best practice is to re-provision the node, due to the cloud-init/Ignition transition at least. Since Fedora CoreOS uses rpm-ostree technology, it may be possible to rebase from Fedora Atomic Host to Fedora CoreOS, but it is not recommended. It's preferable to gain experience deploying systems using Ignition so that they can be re-provisioned easily if needed. For notes on migrating from Atomic Host to Fedora CoreOS, see the xref:migrate-ah.adoc[migration guide].
Butane is one such high-level tool. It is primarily meant as a human-friendly interface, thus defining its own richer configuration entries and using YAML documents as input. This YAML configuration is never directly processed by FCOS instances (only the resulting Ignition configuration is).
_"But, I really want to use it!"_
Can I run containers via docker and podman at the same time?
Can I run Kubernetes on Fedora CoreOS?
CentOS Atomic Host will continue producing downstream rebuilds of RHEL Atomic Host and will align with the end-of-life. The Fedora CoreOS project will be the consolidation point for the community distributions. Users are encouraged to move there in the future.
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 https://github.com/coreos/fedora-coreos-tracker/issues/701[coreos/fedora-coreos-tracker#701] for more details.
dnsmasq is useful for running a DHCP/DNS/TFTP server for external clients (i.e. not local to the host), too, but that is something we'd prefer users to do in a container. Putting the service in a container insulates the hosted service from breakage as a result of host layer changes. For example, if NetworkManager and podman stopped using dnsmasq, we would remove it from the host and the service you depend on would cease to work.
Does Fedora CoreOS embrace the Container Linux Update Philosophy?
Does Fedora CoreOS replace Container Linux? What happens to CL?