15:00:12 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-08-22)
15:00:12 <zodbot> Meeting started Fri Aug 22 15:00:12 2014 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:17 <haraldh> <-
15:00:21 <pknirsch> #meetingname  Fedora Base Design Working Group
15:00:21 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:00:27 <pknirsch> heya haraldh :)
15:00:32 <haraldh> hey
15:00:47 <vpavlin> hey!
15:00:51 <haraldh> hah! sent two kernel patches today :)
15:00:53 <pknirsch> #chair haraldh vpavlin msekleta
15:00:53 <zodbot> Current chairs: haraldh msekleta pknirsch vpavlin
15:01:00 <pknirsch> #chair dgilmore masta
15:01:00 <zodbot> Current chairs: dgilmore haraldh masta msekleta pknirsch vpavlin
15:01:04 <msekleta> hey!
15:01:08 <pknirsch> heya everyone :)
15:01:25 * vpavlin just needs to lock the bike;)
15:01:33 <pknirsch> heh :)
15:01:50 <msekleta> haraldh, which subsystem?
15:02:01 <haraldh> efi
15:02:05 <pknirsch> nice haraldh !
15:02:08 <haraldh> and early microcode
15:02:14 <masta> hello
15:02:14 <pjones> that's a hell of a thing to say
15:02:15 * jreznik_q10 is here
15:02:23 <pknirsch> #chair jreznik_q10
15:02:23 <zodbot> Current chairs: dgilmore haraldh jreznik_q10 masta msekleta pknirsch vpavlin
15:02:49 <haraldh> pjones, well yeah... 5h of debugging, why the initramfs is not uncompressing
15:02:51 <pknirsch> ok, lets get started then. vpavlin asked me to pull the later 2 topics earlier as he was traveling
15:03:00 <pjones> ugh
15:03:03 <pknirsch> :/
15:03:13 <pknirsch> #topic Subpackage config file discussion
15:03:29 * masta notes pjones appears when one mentions efi
15:03:37 * pjones thought everybody knew that :P
15:03:41 <haraldh> :)
15:03:44 <pknirsch> alright, so first up the subpackage discussion for config file
15:04:15 <pknirsch> vpavlin i think wanted to send out an email about that. we discussed that in the hallway at Flock 1 1/2 weeks ago
15:04:32 <haraldh> have you seen what systemd now provides? a way to populate /etc and users with files from /usr
15:04:54 <pknirsch> ah
15:04:59 <vpavlin> yeah, sorry I wasn't able to do that yet..damn you Docker!
15:05:04 <pknirsch> heh :)
15:05:15 <haraldh> so, yeah
15:05:16 * pknirsch is running RHEL-7 docker images on RHEL-6 these days ;)
15:05:29 <haraldh> subpackage the /etc files and additionally add the systemd things to the main package
15:05:39 <dgilmore> hey all
15:05:45 <haraldh> you have my blessing for that
15:05:58 <pknirsch> haraldh, would that need additional changes to specfiles other than the subpackages?
15:06:03 * vpavlin nods
15:06:15 <haraldh> yes
15:06:19 <pknirsch> hm
15:06:27 <haraldh> but if you touch them, better only touch them once
15:06:32 <haraldh> in one go
15:06:33 <pknirsch> true dat
15:07:07 <poettering> haraldh: wassup?
15:07:12 <pknirsch> have you and vpavlin talked about the details? so when we send out that email to f-d people will understand :)
15:07:12 <haraldh> pknirsch, I invited poettering :)
15:07:18 <pknirsch> ah, cool, thanks poettering !
15:07:23 <pknirsch> and thanks haraldh
15:07:26 <vpavlin> we talked about this with haraldh on flock that we should do it as one thing and I agree
15:07:47 <haraldh> poettering, the new /etc and user populating mechanism of systemd
15:07:57 <haraldh> poettering, want to give a short summary?
15:08:05 <vpavlin> haraldh let's talk about it next week and I'll write it up and send
15:08:08 <haraldh> poettering, maybe also about the rpm macros you added?
15:08:23 <haraldh> doesn't hurt, if they are mentioned here
15:08:58 <dgilmore> dont forget rpm macros and changes here will need fpc arrpoval and packaging guideline changes
15:09:01 <haraldh> poettering, we want to subpackage the /etc files in "*-config" subpackages
15:09:06 <dgilmore> approval
15:09:07 * pknirsch nods to dgilmore
15:09:18 <poettering> hmm? "the /etc files"?
15:09:37 <haraldh> yeah, config files of packages
15:09:46 <poettering> dgilmore: tehre's already an fpc ticket for the rpm macros for sysuers, if those are what you are talking about?
15:10:02 <haraldh> poettering, if we touch those packages, we might also want to add your macros in one go
15:10:05 <poettering> haraldh: you want to split *all* rpms in two?
15:10:16 <poettering> haraldh: which macros precisely are you talking of?
15:10:21 <poettering> haraldh: the sysusers macros?
15:10:24 <haraldh> poettering, yes
15:10:27 <dgilmore> poettering: thats part of it. if we want to put config files in separate packages like haraldh is talking about that will need changes as well
15:10:31 <poettering> i am missing some context here apparently
15:10:39 <haraldh> poettering, and the factory mechanism
15:10:39 <pknirsch> ENOCONTEXT
15:10:45 <pknirsch> :)
15:10:48 <dgilmore> poettering: I thing all of us except for haraldh are
15:11:00 <haraldh> hmmm
15:11:03 <pknirsch> Maybe haraldh should do the summary then ;)
15:11:12 <poettering> i am not actually arguing for splitting up all RPMs in two, i think they should continue to ship the config
15:11:14 <haraldh> vpavlin, you go first :)
15:11:16 <vpavlin> poettering we would like to move config files stored in /etc to subpackages
15:11:29 <poettering> but we should also ship them in /usr/share/factory...
15:11:44 <haraldh> in the main package, if needed/wanted
15:11:48 <vpavlin> so that users can simply installed their *-config package to replace co figuration
15:12:02 <pknirsch> or package their own
15:12:08 <poettering> hmm, so suddenly i am the conservative here? ;-)
15:12:13 <pknirsch> hahahah
15:12:14 <haraldh> or remove them completly
15:12:27 <haraldh> and let s.th. else than rpm handle the config
15:12:28 <vpavlin> as long as the configs are in /usr they can stay in main pkg
15:12:42 <haraldh> vpavlin, right.. /usr/share/factory..
15:12:56 <haraldh> or as with systemd, are overridable with /etc
15:12:57 <poettering> does this really make sense? i mean, if people want to install without config, then maybe that should become an rpm switch, after all rpm knows already exactly what is config and what isn't due to %config
15:13:12 <pknirsch> good point
15:13:19 <pknirsch> like with %docs you mean?
15:13:20 <poettering> anyway, let me maybe summarize what i had in mind
15:13:22 <pknirsch> aka --nodocs?
15:13:34 <poettering> so, i want stateless systems
15:13:39 <poettering> so that we can boot up without /etc around
15:13:46 <poettering> and populate automatically what is necessary
15:13:51 <poettering> but only what is strictly necessary
15:13:54 <vpavlin> they want to install configs, but they have to override them by one shot scripts which is error prone
15:14:03 <poettering> we haven't figured out in all details how this all will map to fedora
15:14:11 <poettering> but what we do now is this:
15:14:28 <poettering> we want all RPMs to ship the pristine vendor configuration in /usr/share/factor/etc/*
15:14:40 <poettering> that we can easily diff vendor defaults with user changes
15:14:51 <poettering> simply by diffing /etc/ against /usr/share/factory/etc/
15:14:58 <dgilmore> poettering: that has some value
15:15:13 <poettering> but the main goal we have here is the "golden container" setup
15:15:18 <poettering> we want /usr to be fully self sufficient
15:15:19 * vpavlin agrees that having config in /usr would be awesome
15:15:21 <poettering> do replicate systems
15:15:34 <poettering> so, basically, if you want to "instantiate" an OS
15:15:57 <poettering> you just mount /usr as pristine vendor directory to some directory name /usr
15:16:01 <poettering> and then you can boot that up
15:16:05 <poettering> and /var and 7etc are added in
15:16:12 <poettering> now think about this, if you do this for 100x containers
15:16:19 <poettering> from the same /usr tree
15:16:34 <poettering> so, with systemd upstream this actually works pretty fine now
15:16:39 <poettering> at least with the basic sets of tools
15:16:49 <poettering> however, there are a couple of packages that currently are allergic to missing /etc
15:16:54 <poettering> atcually quite a few
15:17:05 <poettering> from the core OS that's most importantly dbus1 and pam
15:17:10 <jreznik_q10> how many? approximately
15:17:11 <poettering> dbus1 chokes on missing configuration
15:17:31 <poettering> and dbus1 is something we probably could move easily, the devs are friendly to our ideas
15:17:43 <poettering> but so far we didn't prep patches for that
15:17:58 <poettering> also becuase we mostly use kdbus now ;-)
15:18:03 <poettering> PAM is the bigger problem
15:18:18 <poettering> for PAM we prepped patches
15:18:26 <poettering> they are hanging since months in the PAM trac
15:18:40 <poettering> but i figure the pam maintainers are not so friendly to our ideas
15:18:49 <poettering> anyway, those are the two biggies from the basic OS
15:18:56 <haraldh> from my point of view, we can roll out the thing in two steps: first move config to subpackages and add the factory to the main package
15:19:06 <vpavlin> so you suggest to rather invest in moving things from /etc to /usr/share/factory and toss the subpackage thing, right
15:19:07 <poettering> we are fully aware that we cannot patch all software we ship to be compatible with empty /etc
15:19:10 <haraldh> then in the far future we just drop the subpackages
15:19:14 <poettering> wait i am not done yet
15:19:15 <poettering> please
15:19:16 <poettering> wait
15:19:30 <poettering> so, acknowledging the fact that a lot of software doesn't like /etc empty
15:19:39 <poettering> we beefed up tmpfiles a bit
15:19:57 <poettering> so that it is able to copy whole trees from /usr/share/factory to /etc
15:20:07 <poettering> you basically just add a line "C /etc/pam.d"
15:20:25 <poettering> and that means that /usr/share/factory/etc/pam.d" is copied → "/etc/pam.d" if it doesn't exist there yet
15:20:49 <poettering> it's our strategy to work-around upstream maitnainers who think empty /etc is stupid
15:20:56 <poettering> of coruse, we really see that as last resort only
15:21:06 <poettering> we really want softwrae to work without /etc by default
15:21:08 <walters> that also means that once you do an install, you'll never thereafter get any changes to the pam config dir that are made in the upstream defaults, right?
15:21:24 <masta> ok, so it sounds like rpm be made to default config install to the factory location path, and some sub-routine near the end copy them into /etc (possibly as rpmnew)
15:21:25 <poettering> but if we cannot have that, then we can just add a tmpfiles line to work around that, and copy if missing
15:21:45 <poettering> so, regarding updates
15:21:50 <poettering> it's actually a difficult problem
15:22:01 <haraldh> 3-way merge :)
15:22:02 <poettering> the "golden container" image thing i mentioned earlier is only half useful
15:22:06 <poettering> if we cannot actually update them
15:22:19 <poettering> so, we needed a strategy to facility "offline" updates
15:22:28 <poettering> where we can basically update a /usr tree with RPM somewhere
15:22:39 <poettering> and then, this gets replicated into the 100x instances of it
15:22:58 <poettering> for example, stuff like /etc/ld.cache and things need to be rebuild
15:23:03 <poettering> if /usr changes
15:23:11 <poettering> so, we added a very simple scheme for that
15:23:21 <poettering> howe certain tools can be run on a reboot
15:23:31 <poettering> if we figure out that /usr has changed since the last time we booted up
15:23:51 <poettering> the idea is then that we can update /usr at any time, in a snapshot kind of way
15:24:02 <poettering> then we simply restart the container instances with the new /usr version
15:24:07 * pknirsch nods
15:24:20 <poettering> and we run a handfull of additional services that will replicate changes to /etc and /var that we really have to do
15:24:38 <poettering> of course, we updated systemd itself to make use of that
15:24:49 <poettering> for example, we now ship an ldconfig service that rebuilds the cache
15:24:57 <poettering> and sysusers and stuff is run like this
15:25:00 <walters> but for the scenario of config files, are you thinking that say gdm would ship a systemd service that would compare its new config file versus the old and copy over manually if the config file hasn't been modified?
15:25:21 <poettering> so that if a package wants a new user to be added, it just adds the sysuser file, and on next reboot of the instances, we get the new user added to /etc in early boot
15:25:25 <pknirsch> shouldn't that be done by a general framework, walters ?
15:25:30 <poettering> this all is implemented using normal services btw
15:25:43 <walters> pknirsch, it's how ostree works
15:25:47 <poettering> but there's a new ConditionUpdateNeeded= that conditionalizes these services
15:26:13 <pknirsch> i don't think packagers would like the idea to modify all their packages to check for modified config files, something rpm has "taken care of" for them in the past
15:26:20 <poettering> walters: well, i really hope we never have to patch config files
15:26:23 <pknirsch> (arguably badly, but at least it did in some form)
15:26:44 <poettering> walters: but yeah, if we really really have to patch some, then there would have to be a service that is conditionalized on upgrades and does that
15:26:47 <walters> poettering, from this time forward, /etc/pam.d/cockpit should never change?
15:27:03 <poettering> walters: but in general, there shouldn't be a gdm config file anyway in /etc, right?
15:27:19 <poettering> walters: so if an admin adds one, then that coutns and we shouldn't fuck with it on upgrades
15:27:41 <poettering> walters: well, /etc/pam.d/cockpit should be /usr/lib/pam.d/cockpit or so
15:27:41 <walters> but you were suggesting the system copy /etc/pam.d, that's not the admin's doing
15:27:50 <poettering> and if people want to edit it, they copy it
15:27:54 <poettering> and edit it, and we won't fuck with it
15:28:06 <poettering> but the entire idea here is that /etc is minimal
15:28:12 <pknirsch> poettering: how could we then still notify the admin that the default config file changed though? so that he has a chance to actually check if he needs to do something about it? (see rpmsave resp rpmnew files previously)
15:28:26 <poettering> and vendor config is either built into programs, or lies around in /usr/share and /usr/lib
15:28:43 <poettering> and that /etc is really primarilly admin territory
15:28:49 <poettering> and we try to stay away from it
15:28:55 <poettering> and if the admin drops-in a file there
15:28:58 <poettering> that's the file that counts
15:29:04 <poettering> and we will not patch it
15:29:08 <poettering> or fuck it up otherwise
15:29:16 <poettering> pknirsch: well, that's what we have the factory stuff for
15:29:26 <poettering> pknirsch: we want a powerful diff tool
15:29:30 <pknirsch> ahh
15:29:31 <pknirsch> right
15:29:39 <poettering> that can inform users about differences between vendor config in factory
15:29:43 <poettering> and what he actually is running
15:29:44 * pknirsch nods
15:29:51 <poettering> systemd-delta in a way is already that
15:29:54 <pknirsch> that would be awesome actually
15:29:55 <walters> (as ostree can do today)
15:30:01 <poettering> but doesn't actually understand /usr/share/factory
15:30:03 <pknirsch> much better than the rpmsave crap we have
15:30:26 <poettering> but i figure we'll update systemd-delta accordingly to also diff all of /etc to /usr/share/factory
15:30:35 * pknirsch nods
15:30:40 <poettering> so, anyway, it's a lot of pieces of a puzzle to get right
15:30:43 <pknirsch> yea
15:30:51 <poettering> but i think in the end we have very clear definitions of what is in /etc
15:30:54 <poettering> and what is in /usr
15:31:06 <pknirsch> mhm
15:31:09 <poettering> we have nice tools for admins to figure out what chanegs they made
15:31:17 <poettering> we can replicate systems nicely
15:31:23 <vpavlin> so, what would you suggest tobdo from Fedora pov now, poettering?
15:31:25 <pknirsch> and services or apps that use subdirs for configuration would be even better of.
15:31:28 <poettering> we can "offline" update instances nicely, and so on
15:31:41 * pknirsch thinks about unmodified httpd.conf and http/conf subdirs
15:31:54 <poettering> first thing i would want from fedora
15:32:09 <poettering> is that RPM implicitly copies all files marked %config into /usr/share/etc
15:32:18 <poettering> that would already bring us a big step ahead
15:32:34 <haraldh> I asked ffesti to do that..
15:32:34 <poettering> also, we should get started making the most basic packages compatible with /etc being totally empty
15:32:37 <poettering> notable PAM
15:32:44 * vpavlin nods
15:32:47 <pknirsch> mhm
15:32:48 <poettering> oh, and one clarification
15:33:01 <haraldh> but I don't think we will get it in the next year... except pknirsch makes some pressure :)
15:33:02 <poettering> things like apache of course will not work without /etc containing their configs
15:33:21 <poettering> but i think that that is actually totally fine, since apache is one of those things that are not useful without admin config anyway
15:33:33 <poettering> so, we really should focus on packages that are supposed to "just work"
15:33:38 <pknirsch> right
15:33:39 <poettering> and that nobody installs explicitly
15:33:52 <walters> yeah, agreed with that
15:34:00 <poettering> there are a couple of non-obvious things that need to be made compatible with this scheme too
15:34:04 <poettering> like for example /etc/services
15:34:06 <pknirsch> how do you handle /etc/passwd and /etc/shadow ?
15:34:09 <walters> (note intersection with the issue of wheteher or not services start by default)
15:34:10 <dwalsh> Will require changes to SELinux. but it is something we have wanted to do for a while.
15:34:24 <poettering> /etc/services should move to /usr/share/services or so
15:34:41 <poettering> and glibc should first use /etc/services, and on ENOENT fall back to /usr/share/services
15:34:49 <poettering> so that admins can make changes
15:34:55 <poettering> even though probably nobody does anymore
15:35:07 <poettering> i mean, that's the good thing about /etc/services, nobody uses that anymore...
15:35:11 <haraldh> yeah, we should git grep through glibc and add fallbacks from /usr
15:35:13 <poettering> hence we can ignore it for a while
15:35:20 <poettering> but for full funcitonality we do need to cover that
15:35:26 <poettering> this means changes to glibc
15:35:26 <dwalsh> /etc/resolv.conf?
15:35:48 <dgilmore> poettering: it quite possibly means changes to a lot of packages
15:36:18 <haraldh> dgilmore, one way or the other... but better progress :)
15:36:58 <poettering> dgilmore: yupp!
15:37:00 <masta> yeah, I expect this to have a good bit of churn
15:37:09 <poettering> dgilmore: but then again, tmpfiles is a way out for the hard cases
15:37:20 <msekleta> however proposal for splitting config files to separate subpackages was in a way about something different, if I am not mistaken
15:37:29 <poettering> dgilmore: tmpfiles is basically our way how we can make this transition more slowly
15:37:44 <dgilmore> some configs are expected to never be edited
15:37:44 <vpavlin> msekleta you wouldn't need that if all goes well
15:37:44 <poettering> dwalsh: /etc/resolv.conf should be a symlink to some file in /run
15:37:52 <poettering> dwalsh: it's awful that NM touches /etc all the time
15:37:56 <dgilmore> perhaps we should have somewhere to put them
15:38:09 <poettering> dwalsh: /etc really should be considered read-only for services, unless they are configuration management daemons, which NM is not
15:38:28 <msekleta> vpavlin, so will not pursue this further and will focus on getting lennart's idea to work then?
15:38:45 <poettering> ah, here regarding RPM now
15:38:51 <dwalsh> poettering, I agree 100%
15:39:08 <poettering> i think actually, that most RPMs should continue to install their configuraation to /etc, since most admins expect that
15:39:11 <dgilmore> poettering: making /etc/resolv.conf breaks many many things and is going to have to be handled carefully
15:39:15 <walters> where should NM write state instead?  /var ?
15:39:31 <poettering> however, i think we should work on fixing these packages to not actually require them during runtime
15:39:50 <poettering> and the config files shoudl alaways end up in both /etc *and* in /usr/share/factory/etc
15:40:06 <poettering> and it might be nice to have an RPM mode, where it doesn't bother with dropping them in /etc
15:40:13 <poettering> and only puts them in /usr/share/factory/etc
15:40:21 <poettering> walters: /run
15:40:24 <dwalsh> Random tools/services writing random crap into /etc has been a bane to SELinux existance.
15:40:26 <poettering> walters: networkd already does that
15:40:37 <vpavlin> poettering do you thing it's possible to get it to F22? Of not, I'd still pursue subpackages..
15:40:38 <walters> poettering, er...i want to be able to have my wireless network choices be persistent
15:40:38 <poettering> walters: /run/systemd/resolved/resolve.conf
15:41:00 <dgilmore> walters: I agree there
15:41:15 <poettering> walters: ok, you are talking about those. they should probably be in /var for system-defined ones, and in $HOME for user-defined ones
15:41:21 <dgilmore> walters: and vpn connections
15:41:39 <walters> poettering, you do realize NM started out that way, and went through a *really* painful transititon to system connections
15:41:46 <poettering> walters: but honestly, the fact that NM currently stores wlan passwords unencrypted in /etc is really awful
15:42:14 <walters> well
15:42:14 <dgilmore> poettering: you do realise that NM is running in a legacy compat mode
15:42:22 <dgilmore> and was designed to do things differently
15:42:40 <walters> it turns out a lot of people want the ability to have their network connect before they've logged in
15:42:41 <poettering> walters: well, i am totally fine if NM stores wlans in /etc, if it wants to. what i am not fine about is that it keeps touching /etc/resolv.conf
15:42:53 <walters> yeah no one disagrees about resolv.conf
15:42:54 <poettering> walters: i mean, in a way if you connect to a *new* wlan, this is kinda configuration
15:42:59 <poettering> walters: hence writing to /etc might be fine
15:43:04 <walters> right
15:43:16 <poettering> walters: but when i reconnect to known networks, that's not configuration changes, that's just reconnecting
15:43:26 <poettering> and reconnecting should cause /etc to be modified
15:43:37 * vpavlin will have to go in 15mins :(
15:43:49 <poettering> anyway, that's kinda what i have in mind
15:43:58 <poettering> so, what i'd really like to see is:
15:44:09 <poettering> a) rpm populates /usr/share/factory by default
15:44:17 <poettering> b) rpm gets a new switch --noconfig or so
15:44:40 <poettering> c) we start fixing PAM, glibc to always look in /usr/lib if a file is missing in /etc
15:44:56 <poettering> d) we start working on adding tmpfiles snippets for the other packages
15:45:11 <poettering> but as mentioned, even without all this, things work surprisingly well already
15:45:19 <poettering> btw, i updated nspawn with some siwtches to test this all
15:45:43 <poettering> in the version in rawhide there is now a new switc --volatile
15:45:52 <poettering> it takes three values:
15:46:20 <poettering> --volatile=no is the default, an means you get /usr, /var, /etc from whatever you point it to
15:46:22 <vpavlin> haraldh - you said you are talking to rpm guys, right?
15:46:40 <poettering> --volatile=yes you get a tmpfs as /, and /usr mountd in from where you point it
15:46:45 <pknirsch> maybe it would help vpavlin if you talked with jzeleny, too
15:46:53 <dwalsh> Will /etc/machine-id be moving?
15:46:57 <vpavlin> sure thing
15:47:00 <pknirsch> coolio
15:47:01 <poettering> --volatile=state you get /usr and /etc from where you point it to, plus /var being tmpfs
15:47:20 <poettering> these three models are kinda what we want to focus on
15:47:31 <poettering> i also plan to add a kernel cmdline option to map this
15:47:31 <haraldh> vpavlin, I said, I was.... I am not constantly nagging..
15:47:39 <pknirsch> heh
15:47:39 <poettering> dwalsh: it already moved
15:47:45 <dwalsh> Where is it now?
15:47:48 <poettering> dwalsh: oops, sorry
15:47:51 <poettering> dwalsh: i am confused
15:47:52 <haraldh> vpavlin, nagging from different sides would definitely help :)
15:47:57 <poettering> /etc/machine-id actually stays where it is
15:48:06 <poettering> /etc/os-release howver moved to /usr/lib
15:48:13 <poettering> /etc/machine-id is inherently per-instance information
15:48:20 <poettering> it is the identity of a machine instance
15:48:23 <poettering> hence belongs in /etc
15:48:31 <vpavlin> haraldh ok:) I nag somebody all the time..no problem to add few more people;)
15:48:35 <walters> poettering, somewhat as an aside, i'd also like initramfs to be immutable, so it'd be quite nice if the machine id was a kernel commandline argument (or dracut knew how to pick it up from a secondary initramfs)
15:48:42 <poettering> we moved /etc/os-release however, since that realy just describes the OS as it is vendor-supplied in /usr
15:48:56 <dgilmore> walters: eww
15:49:03 <walters> (more generally, everything dracut computes locally and stashes in the initramfs were either a kernel cmdline, or a secondary initramfs)
15:49:10 <dgilmore> there is things in the initramfs I wish were not
15:49:11 <poettering> walters: if /etc is found empty, we will generate one add write it there
15:49:35 <poettering> walters: where "generate" means, either randomize it, or pull it out of qemu's bios supplied machine uuid, or nspawn's --uuuid= cmdline
15:50:06 <haraldh> dgilmore, like?
15:50:07 <dwalsh> How about a environment variable?
15:50:13 <poettering> walters: i mean, if we allow provisioning of the uuid via qemu's -uuid or nspawns --uuid= switch, then i figure we can also allow it on the kernel cmdline
15:50:19 <poettering> though i do wonder what your usecase is...
15:50:24 <dwalsh> Trying to figure a way to populate for docker images.
15:50:42 <poettering> dwalsh: i think docker should just implement the ContainerInterface stuff
15:50:51 <poettering> dwalsh: http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
15:50:57 <poettering> dwalsh: it should just set $container_uuid
15:51:02 <poettering> dwalsh: that's where we pick it up from
15:51:03 <dwalsh> poettering, Upstream is not very responsive :^(
15:51:13 <dgilmore> haraldh: all the mount info. ive had quite a few times changing disks and ive had to use a resuce environment to recover things, and by rescue booting media in rescue mode. as the rescue kernel initramfs have not worked
15:51:27 <dwalsh> Ok so we set container_uuid, systemd would populate.
15:51:39 <poettering> dwalsh: only when /etc/machine-id is missing!
15:51:47 <dwalsh> Right.
15:51:54 <dgilmore> dwalsh: our docker base images will not have systemd in them
15:51:55 <haraldh> dgilmore, install dracut-config-generic
15:51:55 <poettering> dwalsh: i.e. if you set container_uuid but there's already an /etc/machine-id from a previous one, we won't change it
15:52:17 <pknirsch> as that instance already has it's id
15:52:23 <dwalsh> Only last problem is the UUID of docker is much longer then /etc/machineid is allowed.
15:52:45 <haraldh> dgilmore, or use --no-hostonly-cmdline / hostonly_cmdline="no"
15:53:02 <poettering> dwalsh: hmm, then it's probably not a uuid
15:53:08 <poettering> dwalsh: uuids are always 128bit...
15:53:17 <poettering> dwalsh: but you can just truncate it
15:53:26 <poettering> dwalsh: but why would they ever use a longer one?
15:53:38 <dgilmore> poettering: because they can
15:53:57 <dwalsh> 00eece37864040d3f5ca77e51a779859908277f43bb98f8bb00685f77bae9b35
15:53:57 <poettering> i mean, do they really believe that they need mor docker containers than grains of sand on this world?
15:54:05 <poettering> they are stupid, if i may say so
15:54:09 <vpavlin> ok, I'll leave, I am not going to be here for next topic anyway..thanks for explanation poettering, I'll talk to jzeleny
15:54:28 <dwalsh> poettering, I'll pass that along.  :^)
15:54:29 <dgilmore> seeya vpavlin
15:54:34 <vpavlin> have a nic weekend all
15:54:37 <pknirsch> cya vpavlin !
15:54:52 <moben> have a nice weekend vpavlin!
15:55:34 <pknirsch> so  now that vpavlin is gone, we can all agree he's doing all the writeup of this, right? ;)
15:55:45 <masta> hehe
15:55:47 <poettering> anyway, so far our ideas
15:55:53 <poettering> or actually
15:55:57 <poettering> one more thing: sysuers
15:56:03 <poettering> we already had a discussion on fedora-devel
15:56:10 <poettering> which resulted in a couple of things
15:56:18 <poettering> which i all implemented in the most recent systemd
15:56:23 <poettering> now i just need to update the FPC bug
15:56:36 <poettering> there's one nasty thing there
15:56:36 <pknirsch> nice!
15:56:39 <poettering> which is this:
15:56:47 <poettering> sysusers is supposed to cover both usecases:
15:57:14 <poettering> "offline" updates as i decribed above, where a new file is dropped into /usr/lib/sysusers.d/, and then is worked on on next boot
15:57:30 <poettering> and "online" updaets as we always did them with RPM, i.e. create users from scriptlets
15:57:40 <poettering> now, for the latter case we actualy supply two RPM macros
15:57:45 <poettering> but there's the nastiness:
15:58:04 <poettering> we want to create these users based on definitions in the files we ship in /usr/lib/sysusers.d/
15:58:24 <poettering> but there might be files in the RPM that shall be owned by users that we want to create
15:58:33 <poettering> so there's a chicken and egg problem
15:58:35 <pknirsch> ugh
15:58:40 <poettering> we want to create the users based on files we just dropped in
15:58:54 <poettering> but before dropping in the files we want to create the users, so that the files can be owned by them
15:59:05 <poettering> so, this is awful
15:59:11 <poettering> we thought about this for quite a while now
15:59:16 <poettering> our proposed solution is this:
15:59:31 <poettering> we added a sysusers switch so that users can also be created based on the user defintions from stdin
15:59:46 <poettering> the idea is then that packages can choose between two macros:
15:59:57 <poettering> %sysusers_create()
16:00:18 <poettering> which should be added to %post, and which just adds in all users from the just-dropped-in sysuers files
16:00:28 <poettering> if you use that macro, you cannot make files owned by these users
16:00:38 <poettering> and then there's %sysusers_create_inline()
16:00:53 <poettering> where you can specify the precise "sysusers" line directly inside of the RPM macro invocation
16:01:00 <poettering> that's what people should use in %pre
16:01:09 <poettering> to create users before we drop in the first files
16:01:20 <poettering> thankfully, the number of packages that needs this is not thaaaat big
16:01:32 <poettering> most files owned by non-root in RPM are actually in /run and /var
16:01:53 <poettering> /run doesn't matter too much here i figure, since most files there should be %ghosted by now
16:02:20 <poettering> which leaves /var, where this is annoying, but we have to deal with it
16:02:24 <poettering> btw, speaking of /var
16:02:49 <poettering> while many packages are allergic to /etc being empty, packages in fedora are generally a lot more friendly regarding booting up with empty /var
16:03:00 <poettering> that pretty much just works with everything i tested
16:03:04 <poettering> it's kinda amazing
16:03:18 <poettering> anyway, i need to write up the new sysusers stuff and add it to the FPC ticket
16:03:18 <pknirsch> heheheh
16:03:24 <poettering> so that they can bless it or so
16:03:33 <poettering> unless anybody has a better diea
16:03:35 <poettering> idea
16:03:37 <pknirsch> thanks poettering for the very detailed explanation
16:03:51 <poettering> btw, i'll do a talk about all of this at linuxcon
16:03:58 <poettering> in düsseldorf in october
16:04:11 <pknirsch> and i think the split into 2 macros is necessary to split the chicken and egg problem
16:04:17 <pknirsch> cool
16:05:06 <walters> poettering, amazing, or I was starting that ~2 years ago and submitting patches...
16:06:44 <pknirsch> oki, any questions anyone after this? :)
16:07:04 * pknirsch thinks we've kinda run out of time today as quite a few need to leave already soonish :(
16:07:57 <pknirsch> ok, i think either no questions or everyone else fell asleep ;)
16:08:24 <walters> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e7add58aad1bb5eca28360c9c7a1a3956261c7df
16:08:26 <walters> for example
16:08:56 <pknirsch> mhm
16:09:14 <walters> https://bugzilla.redhat.com/show_bug.cgi?id=1097314 for a more recent one
16:09:48 <pknirsch> Ok, thanks again poettering for coming to our meeting today and going into so much detail. That'll make a more concrete writeup for vpavlin much easier and we can then see where we go from there
16:10:09 <pknirsch> Other topics will have to wait till next week i'm afraid, but thanks everyone for joining today!
16:11:56 <pknirsch> #endmeeting