CoreOS custom repo for file changes?

Ask Fedora
,
1

Is it possible to layer my changes to a mirrored fedora ostree repo?
My use case is for example I have changes for firewall like nftables, the thing here is I don’t want to put it on a butane config then re-install coreos just with that change. And I must do this with every other server that the firewall config is installed to. Is it possible to stream my config similar to how upgrades work?

My thinking is as this is similar to git then I can just mirror the repo and rebase my changes then make it as primary. Is it possible?

2

You can achieve the goal using the new CoreOS Layering workflow. See GitHub - coreos/layering-examples and https://github.com/coreos/fedora-coreos-docs/pull/540. The drawback is you completely own your updates now (you’ll need to a do a new build each time there is a new update available). Check it out and let us know what you think.

1 Like
3

Is that the only way? That seems to be fairly complex for adding and modifying several files. I’m thinking, maybe I should create an empty ostree repo and just add it to remotes and create sync service.

And based on my research a ostree repo can be hosted on S3 bucket. The current for fedora coreos is maybe hosted on S3 with cloudfront.

I’ve re-read again the samples; it is aimed for containers. Will that work on bare metal installations?

4

I am having similar challenges. As @eabucay mentions, most of the examples tend towards the more common scenarios of running fcos in containers or virtual machines, but I am also in the same boat of running my fcos deployment on bare metal. It does not seem as easy to discover the “secret sauce” to persist the minimal changes we are making to the system. Ideally the mechanism would work in conjunction with zincati so that when an update occurs it could trigger the re-application of the small set of changes that were applied when the system was first installed.

5

The examples are showing you how to customize Fedora CoreOS. The examples use a container build, but they are in fact editing the content that will be delivered to the host (bare metal or VM) in an update.

6

I’m not sure I understand. Any changes you make to a system via Ignition (or even via SSH to edit files directly) should persist across updates without issue.

7

Yes, I have stuck to the method @dustymabe provided above. The only downside and cons are whenever there’s an update on upstream, I need to rebuild my images. Then rebase my rpm-ostree to the container image. Well, this is better than nothing. I have set up my own pipeline to rebuild and push whenever there’s an update on upstream, I just don’t know how to automate on the rebase side of rpm-ostree. Anyways, magnificent work guys on CoreOS!