10:05 <guesswhat> hello, i have troubles in podman 4.1.0 ( fcos 36 ),, sometimes, containers lose the ability to resolve themselfs ( same network bridge ), ping is working, but dns resolution does not, os restart is helping only temporarily. any ideas? thanks

10:57 <travier[m]> guesswhat: Can you file an issue with as much details as possible? Do you have a reproducer?

11:45 <guesswhat> travier[m]: i can not simulate this, waiting for another "dns" hickup

11:45 <guesswhat> some containers are resolvable, other arent...

12:07 <guesswhat> this one is internesting: Jul 15 12:05:34 ip-10-2-13-15 aardvark-dns[2286]: Unable to start server unable to start CoreDns server: Address already in use (os error 98)

15:17 <sgallagh> Is there a tool out there that would allow me to create my own custom OStree based on CoreOS (or IoT or Silverblue)? Essentially, I have a pattern where I'm regularly layering packages (in particular, those that relate to network-bound disk encryption) and I have to replicate this over a number of machines. I'd like to be able to just make this part of the OStree repo.

15:18 <aaradhak[m]> Hi travier , a question regarding this [PR](https://github.com/coreos/console-login-helper-messages/pull/111) for "steps to create a tag" , kindly let me know if we need to add it in `repo-templates`. I would like to get your thoughts on this.

15:21 <dustymabe> sgallagh: there are options here. so the answer may have multiple levels

15:21 <dustymabe> do you want to derive from FCOS or start from scratch?

15:23 <sgallagh> dustymabe: Let's start with FCOS

15:24 <dustymabe> sgallagh: if you want to derive from FCOS the two options are package layering (what you're doing today) or something new we've been calling `coreos layering` (could probably use a better name)

15:25 <dustymabe> this allows you to use a Dockerfile like "FROM: " approach to modifying disk images. You then store it in a container registry and point your machines at that

15:25 <dustymabe> the only problem with this approach is that right now it's not fully baked (i.e. your machines won't get updates unless you do new builds)

15:25 <dustymabe> we're working on finishing it up

15:26 <dustymabe> sgallagh: if you're doing development work then you might not care so much about updates so coreos layering might work well for you

15:26 <dustymabe> https://github.com/coreos/coreos-layering-examples

15:26 <bgilbert> aaradhak[m]: replied in https://github.com/coreos/console-login-helper-messages/pull/111#issuecomment-1185653185

15:27 <bgilbert> aaradhak[m]: short version: I don't think it _needs_ to go in repo-templates but other projects could benefit from putting it there

15:28 <sgallagh> dustymabe: I'll check it out.

15:28 <sgallagh> And what about the other approach (starting from scratch)?

15:29 <aaradhak[m]> bgilbert: I see your point there. That makes sense.

15:29 <aaradhak[m]> dustymabe shall we move this to `repo-templates` ?

15:29 <dustymabe> sgallagh: you'd basically use coreos-assembler and the configs repo to create your own - see https://github.com/coreos/coreos-assembler/blob/main/docs/building-fcos.md

15:30 <dustymabe> aaradhak[m]: it's up to you. Depends on your current tasks/priorities if you want to take on that extra task.

15:30 <bgilbert> aaradhak[m]: if you do move it, I'd recommend making it a proper Markdown checklist in .github/ISSUE_TEMPLATE

15:32 <sgallagh> dustymabe: Thanks again!

15:33 <sgallagh> I have two goals here: one to easily set up NBDE clients and another to create a minimized NBDE (tang) server system that could live on a low-powered, tamper-resistance device.

15:35 <lucab> Stephen Gallagher: perhaps I'm misunderstanding this but it sounds like neither of those cases strictly need a custom OS, maybe? Which packages/bits are you missing in a vanilla image?

15:35 <aaradhak[m]> bgilbert dustymabe : I will make the Markdown Checklist if its beneficial for future reference.

15:36 <bgilbert> aaradhak[m]: +1, thank you!

15:37 <sgallagh> lucab: For the clients, I need at minimum `dracut-clevis` and realistically also `cockpit-storaged` for the easy setup UI.

15:37 <bgilbert> sgallagh: clevis is already supported via Ignition

15:38 <bgilbert> sgallagh: https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_encrypted_storage_luks

15:38 <sgallagh> For the server, I could probably set that up in a container, it just seems like a lot of overhead for a tiny service

15:39 <sgallagh> bgilbert: I’m looking for a solution that would also work for Silverblue.

15:39 <bgilbert> ah, okay

15:39 <lucab> ah, that explains

15:39 <walters> (of course, ignition-for-silverblue relates to https://github.com/fedora-silverblue/issue-tracker/issues/244 )

15:40 <lucab> I'd personally put tang in a container, but at the same time I never had to manage such service in production

15:41 <sgallagh> The tang part is mostly about storage space.

15:41 <sgallagh> I’m looking at putting it on extremely storage-restricted devices.

15:42 <sgallagh> Likely built on Fedora IoT

17:27 <lucab> I'd like to land https://github.com/coreos/fedora-coreos-config/pull/1836 and keep going with the users/groups spring cleanings, if there are no concerns

17:29 <dustymabe> lucab: how risky is it?

17:30 <dustymabe> should we wait until after next week's releases cycle through?

17:30 <dustymabe> I mean theoretically if it passes tests it passes tests

19:24 <dustymabe> gursewak: want to update the description and title of the PR to match the new commit message? https://github.com/coreos/coreos-assembler/pull/2986

19:25 <gursewak> done

20:04 <dustymabe> gursewak: jlebon: mind a review on https://github.com/coreos/coreos-assembler/pull/2988 ?