Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
On Monday 2013-01-07 15:26, Lennart Poettering wrote: BTW, Kay and I were thinking about coming up with a simple scheme that could pre-initialize a couple of files in /etc and /var that cannot really sensibly be dropped. For example, UID assignemnts unfortunately cannot be shipped in packages from the distro, As an NSS module that autovivifies a user entry when first looked up, or as a boot oneshot service? they must happen dynamically on the local system, due to their limited 32bit namespace (wouldn't it be awesome to have 128bit IDs like a certain other OS?) I do not see a reason to start using 128-bit GUIDs unless you plan to hand out static IDs to system services (e.g. the user for apache2) again. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
Hi, Just thinking outload here as dealing with some packages where stuff in /etc was marked in the spec as %config and it really shouldn't be (I'm thinking dbus policy files and rootcerts mainly but there are do doubt countless other examples where this is true also). I was thinking, is it a general stated aim that we should be able to boot with an empty /etc? I know this isn't true today, but with appropriate effort is that where we should be aiming? I guess the same should be true of /var too probably (i.e. packages should be able to cope with initing themselves on first use and not rely on doing it at package install). Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
On Mon, 07.01.13 11:48, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Just thinking outload here as dealing with some packages where stuff in /etc was marked in the spec as %config and it really shouldn't be (I'm thinking dbus policy files and rootcerts mainly but there are do doubt countless other examples where this is true also). I was thinking, is it a general stated aim that we should be able to boot with an empty /etc? I know this isn't true today, but with appropriate effort is that where we should be aiming? I guess the same should be true of /var too probably (i.e. packages should be able to cope with initing themselves on first use and not rely on doing it at package install). The stuff we design in systemd should work fine with an empty /etc. And I think it would be a nice goal to achieve this for the whole platform. That said, it's kinda unrealistic to achieve that anytime soon. On Android you can drop the configuration partition to do a firmware reset and we should really try to implement something similar with our /etc. There's a currently a lot of stuff in /etc though that really doesn't belong there. For example databases such as /etc/services or /etc/protocols really should live in /usr/share or so. It's fine allowing people to override these databases in /etc, but the upstream databse should not be considered primary configuration that should live in /etc. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
'Twas brillig, and Lennart Poettering at 07/01/13 13:37 did gyre and gimble: On Mon, 07.01.13 11:48, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Just thinking outload here as dealing with some packages where stuff in /etc was marked in the spec as %config and it really shouldn't be (I'm thinking dbus policy files and rootcerts mainly but there are do doubt countless other examples where this is true also). I was thinking, is it a general stated aim that we should be able to boot with an empty /etc? I know this isn't true today, but with appropriate effort is that where we should be aiming? I guess the same should be true of /var too probably (i.e. packages should be able to cope with initing themselves on first use and not rely on doing it at package install). The stuff we design in systemd should work fine with an empty /etc. And I think it would be a nice goal to achieve this for the whole platform. That said, it's kinda unrealistic to achieve that anytime soon. On Android you can drop the configuration partition to do a firmware reset and we should really try to implement something similar with our /etc. There's a currently a lot of stuff in /etc though that really doesn't belong there. For example databases such as /etc/services or /etc/protocols really should live in /usr/share or so. It's fine allowing people to override these databases in /etc, but the upstream databse should not be considered primary configuration that should live in /etc. Cool, that's all basically matching my general feelings also. So now that most of the distros are nicely working on CoreOS stuff a bit more closely these days (with special kudos to the Arch folk I think!) we can probably all keep this in mind as we march forward. Getting the dbus stuff out of there would be a nice start me thinks :) Cheers! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
I was thinking, is it a general stated aim that we should be able to boot with an empty /etc? I know this isn't true today, but with appropriate effort is that where we should be aiming? I have been thinking about this too, and I am even planning on doing some experiments with this. Currently there are a couple of issues: - Some software just fails if they can't read there config file - Most software does not allow for a separate distribution and local configuration like systemd does - A lot of software does not have any sensible default behavior when there config file is missing. - Some files are needed quiet hard (passwd, group, shadow ,...) The first three should be fixed upstream. The last point is something i would fix with a systemd generator overriding default.target with setup.target if one of these files are missing. I guess the same should be true of /var too probably (i.e. packages should be able to cope with initing themselves on first use and not rely on doing it at package install). I personally think /var is easier than /etc, since most programs already do there initing partially, the only problem is that they don't create there own directories so they fail with an empty /var. But this can easily be fixed using systemd-tmpfiles. There is on my system only one problem in /var: rpm (which if it depended on me belongs in /usr somewhere) Once both /etc and /var can be empty, the only things needed to boot a new machine are a kernel, /bin, /lib and /usr. This would also mean that (together with /bin, /sbin and /lib being symlinks) all packages except those involving /boot should be contained within /usr (which can be ro during normal operation) Simon PS: nice to know other people are thinking in the same direction ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
On Mon, 07.01.13 09:13, Colin Walters (walt...@verbum.org) wrote: On Mon, 2013-01-07 at 11:48 +, Colin Guthrie wrote: H I was thinking, is it a general stated aim that we should be able to boot with an empty /etc? Definitely quite useful for my plan: https://live.gnome.org/OSTree/MultipleRoots I guess the same should be true of /var too probably (i.e. packages should be able to cope with initing themselves on first use and not rely on doing it at package install). Yes: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e7add58aad1bb5eca28360c9c7a1a3956261c7df http://git.gnome.org/browse/gdm/commit/?id=b18a7464095fa724b8160ebe2388f925558be5da ...and others. BTW, Kay and I were thinking about coming up with a simple scheme that could pre-initialize a couple of files in /etc and /var that cannot really sensibly be dropped. For example, UID assignemnts unfortunately cannot be shipped in packages from the distro, they must happen dynamically on the local system, due to their limited 32bit namespace (wouldn't it be awesome to have 128bit IDs like a certain other OS?). What we were thinking of is that RPMs could ship minimal manifest files that include information about which users need to be recreated if /etc is dropped and which file owenerships they must match. After flushing /var and /etc, playing back these manifests should execute the minimal operations to get pack /etc with passwd/group initialized and match the UIDs used on the fs and maybe a few other things. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
On Mon, 2013-01-07 at 15:26 +0100, Lennart Poettering wrote: BTW, Kay and I were thinking about coming up with a simple scheme that could pre-initialize a couple of files in /etc and /var that cannot really sensibly be dropped. For example, UID assignemnts unfortunately cannot be shipped in packages from the distro, they must happen dynamically on the local system, I ship them statically: http://git.gnome.org/browse/gnome-ostree-integration/tree/src/lib-passwd But I don't have packages - there is no ability to dynamically mutate your root filesystem while it's running. (Note also that gnome-ostree has both /etc/passwd and /lib/passwd, via https://github.com/aperezdc/nss-altfiles ) (wouldn't it be awesome to have 128bit IDs like a certain other OS?). Yep, but not a small change... What we were thinking of is that RPMs could ship minimal manifest files that include information about which users need to be recreated if /etc is dropped and which file owenerships they must match. After flushing /var and /etc, playing back these manifests should execute the minimal operations to get pack /etc with passwd/group initialized and match the UIDs used on the fs and maybe a few other things. Well note in the gnome-ostree split-password model, dropping /etc only deletes users for /home, not the OS. But dynamically allocating system users per-boot and ensuring that /etc and /var matches would still be interesting. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
On Mon, 07.01.13 09:36, Colin Walters (walt...@verbum.org) wrote: On Mon, 2013-01-07 at 15:26 +0100, Lennart Poettering wrote: BTW, Kay and I were thinking about coming up with a simple scheme that could pre-initialize a couple of files in /etc and /var that cannot really sensibly be dropped. For example, UID assignemnts unfortunately cannot be shipped in packages from the distro, they must happen dynamically on the local system, I ship them statically: http://git.gnome.org/browse/gnome-ostree-integration/tree/src/lib-passwd But I don't have packages - there is no ability to dynamically mutate your root filesystem while it's running. (Note also that gnome-ostree has both /etc/passwd and /lib/passwd, via https://github.com/aperezdc/nss-altfiles ) Ah, this is cool, I think it would make a ton of sense for general purpose distros to move all the fixed assignments into /usr/lib. Of course, such a solution only solves half the problem since it cannot cover for uids allocated for 3rd party packages. Well note in the gnome-ostree split-password model, dropping /etc only deletes users for /home, not the OS. So you basically say that stuff you install on gnome-ostree never can allocate its own UIDs, right? But dynamically allocating system users per-boot and ensuring that /etc and /var matches would still be interesting. Uh, yeah, there's still the question out there what to do with fully dynamic throw-away UIDs, for example so that gdm could allocate a UID for each seat when showing login prompts dynamically. This is going to be really hard, since after dropping a UID again one needs a good way to drop all files and other objects the user created before handing out the same UID again, and I do not see how we could deal with that properly. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
On Mon, Jan 07, 2013 at 02:54:49PM +0100, Peeters Simon wrote: - Some files are needed quiet hard (passwd, group, shadow ,...) That's not really true, as any consumer of those files should go through getpwname() and similar functions. And glibc implementation of those functions could be made to check some distro-default accounts in /usr/share ... Something like this is done by tcb (http://www.openwall.com/tcb/). tcb is quite cool, by the way, it replaces /etc/shadow with bunch of files accessible by respective users. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] CoreOS Goal Question: Should we be aiming to be able to boot with an empty /etc?
On Mon, Jan 07, 2013 at 07:35:54PM +0100, Lennart Poettering wrote: But dynamically allocating system users per-boot and ensuring that /etc and /var matches would still be interesting. Uh, yeah, there's still the question out there what to do with fully dynamic throw-away UIDs, for example so that gdm could allocate a UID for each seat when showing login prompts dynamically. This is going to be really hard, since after dropping a UID again one needs a good way to drop all files and other objects the user created before handing out the same UID again, and I do not see how we could deal with that properly. It smells similar to what Android is doing - separate UID per app. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
