Re: [systemd-devel] Question about the cross session dependence
On Sun, Apr 21, 2013 at 6:49 PM, Li, Min A min.a...@intel.com wrote: Hi systemd experts, I have a question about the dependence of user and system session. At system session, there is a service which need to be started after X(user session). At first I added “After=xorg.target” at this service, but It is said that the dependence of cross session is not work. Is that true? The user session instance does not know anything about the state of system services. So yes. If Yes, what’s the solution for this kind of issue? If you start your xorg through systemd --system, you will have to find an alternative way to tell the systemd --user how to determine that the service is ready. You can make a hack with a path unit, or write a user session service that uses IPC to communicate with the system session in some way. Nobody has looked at that, afaik. This is why user-session-units starts the X server from within the systemd --user environment - it removes that problem entirely. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: link systemd-static-nodes.service
--- man/systemd-tmpfiles.xml|2 ++ units/systemd-static-nodes.service.in |1 + units/systemd-tmpfiles-clean.service.in |2 +- units/systemd-tmpfiles-clean.timer |2 +- units/systemd-tmpfiles-setup.service.in |2 +- 5 files changed, 6 insertions(+), 3 deletions(-) diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml index 22744c7..0e22915 100644 --- a/man/systemd-tmpfiles.xml +++ b/man/systemd-tmpfiles.xml @@ -47,6 +47,7 @@ refnamesystemd-tmpfiles-setup.service/refname refnamesystemd-tmpfiles-clean.service/refname refnamesystemd-tmpfiles-clean.timer/refname +refnamesystemd-static-nodes.service/refname refpurposeCreates, deletes and cleans up volatile and temporary files and directories/refpurpose /refnamediv @@ -59,6 +60,7 @@ parafilenamesystemd-tmpfiles-setup.service/filename/para parafilenamesystemd-tmpfiles-clean.service/filename/para parafilenamesystemd-tmpfiles-clean.timer/filename/para +parafilenamesystemd-static-nodes.service/filename/para /refsynopsisdiv refsect1 diff --git a/units/systemd-static-nodes.service.in b/units/systemd-static-nodes.service.in index 3553226..f029285 100644 --- a/units/systemd-static-nodes.service.in +++ b/units/systemd-static-nodes.service.in @@ -7,6 +7,7 @@ [Unit] Description=Create static device nodes in /dev +Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) DefaultDependencies=no Before=sysinit.target systemd-udevd.service ConditionCapability=CAP_MKNOD diff --git a/units/systemd-tmpfiles-clean.service.in b/units/systemd-tmpfiles-clean.service.in index a288232..a5b5acb 100644 --- a/units/systemd-tmpfiles-clean.service.in +++ b/units/systemd-tmpfiles-clean.service.in @@ -7,7 +7,7 @@ [Unit] Description=Cleanup of Temporary Directories -Documentation=man:tmpfiles.d(5) +Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) DefaultDependencies=no Wants=local-fs.target After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target diff --git a/units/systemd-tmpfiles-clean.timer b/units/systemd-tmpfiles-clean.timer index fac4ee3..9975dcf 100644 --- a/units/systemd-tmpfiles-clean.timer +++ b/units/systemd-tmpfiles-clean.timer @@ -7,7 +7,7 @@ [Unit] Description=Daily Cleanup of Temporary Directories -Documentation=man:tmpfiles.d(5) +Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) [Timer] OnBootSec=15min diff --git a/units/systemd-tmpfiles-setup.service.in b/units/systemd-tmpfiles-setup.service.in index dbd6bfb..4a3441c 100644 --- a/units/systemd-tmpfiles-setup.service.in +++ b/units/systemd-tmpfiles-setup.service.in @@ -7,7 +7,7 @@ [Unit] Description=Recreate Volatile Files and Directories -Documentation=man:tmpfiles.d(5) +Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) DefaultDependencies=no Wants=local-fs.target After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target -- 1.7.2.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: link systemd-static-nodes.service
On Mon, Apr 22, 2013 at 3:16 PM, Umut Tezduyar u...@tezduyar.com wrote: --- man/systemd-tmpfiles.xml|2 ++ units/systemd-static-nodes.service.in |1 + units/systemd-tmpfiles-clean.service.in |2 +- units/systemd-tmpfiles-clean.timer |2 +- units/systemd-tmpfiles-setup.service.in |2 +- 5 files changed, 6 insertions(+), 3 deletions(-) diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml index 22744c7..0e22915 100644 --- a/man/systemd-tmpfiles.xml +++ b/man/systemd-tmpfiles.xml @@ -47,6 +47,7 @@ refnamesystemd-tmpfiles-setup.service/refname refnamesystemd-tmpfiles-clean.service/refname refnamesystemd-tmpfiles-clean.timer/refname +refnamesystemd-static-nodes.service/refname Hmm, why should we list a specific user of this tool in its doc section, the ones listed there are so far all part of the tool itself? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: link systemd-static-nodes.service
Hi, The way I see it is systemd-tmpfiles-setup.service is no different than systemd-static-nodes.service except later is restricted to /dev and runs before udev. Due to this similarity I thought man:systemd-tmpfiles is the best place to mention of systemd-static-nodes.service. If that is not the case, then systemd-static-nodes.service still needs to be listed somewhere in man list. On Mon, Apr 22, 2013 at 5:03 PM, Kay Sievers k...@vrfy.org wrote: On Mon, Apr 22, 2013 at 3:16 PM, Umut Tezduyar u...@tezduyar.com wrote: --- man/systemd-tmpfiles.xml|2 ++ units/systemd-static-nodes.service.in |1 + units/systemd-tmpfiles-clean.service.in |2 +- units/systemd-tmpfiles-clean.timer |2 +- units/systemd-tmpfiles-setup.service.in |2 +- 5 files changed, 6 insertions(+), 3 deletions(-) diff --git a/man/systemd-tmpfiles.xml b/man/systemd-tmpfiles.xml index 22744c7..0e22915 100644 --- a/man/systemd-tmpfiles.xml +++ b/man/systemd-tmpfiles.xml @@ -47,6 +47,7 @@ refnamesystemd-tmpfiles-setup.service/refname refnamesystemd-tmpfiles-clean.service/refname refnamesystemd-tmpfiles-clean.timer/refname +refnamesystemd-static-nodes.service/refname Hmm, why should we list a specific user of this tool in its doc section, the ones listed there are so far all part of the tool itself? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about the cross session dependence
On Mon, 22.04.13 01:49, Li, Min A (min.a...@intel.com) wrote: Hi systemd experts, I have a question about the dependence of user and system session. At system session, there is a service which need to be started after X(user session). At first I added After=xorg.target at this service, but It is said that the dependence of cross session is not work. Is that true? Yes, it is. If Yes, what's the solution for this kind of issue? The idea is that system services get socket or bus activated, so that clients can just connect to them, and if the services are not running yet they would be started and if they are already being starte that the client wouldn't have to know. In the case of X this would mean adding socket activation support to it. This has been discussed many times, and the X folks are open to it. It's probably not useful for the desktop case, but for most emebdded cases it is. Doing socket-activated X isn't even that hard, it's just that somebody has to sit down and hack it up. By doing socket activation for X you not only get rid of any explicit dependencies, but you also get performance wins via the best possible parallelization, and the thing even becomes more robust, too. Porting X to socket activation is just a matter of patching it to use sd_listen_fds() instead of directly binding the listening socket. There's plenty documentation for it, just google for it! 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] Question about the cross session dependence
On Mon, 22.04.13 00:58, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Sun, Apr 21, 2013 at 6:49 PM, Li, Min A min.a...@intel.com wrote: Hi systemd experts, I have a question about the dependence of user and system session. At system session, there is a service which need to be started after X(user session). At first I added “After=xorg.target” at this service, but It is said that the dependence of cross session is not work. Is that true? The user session instance does not know anything about the state of system services. So yes. If Yes, what’s the solution for this kind of issue? If you start your xorg through systemd --system, you will have to find an alternative way to tell the systemd --user how to determine that the service is ready. You can make a hack with a path unit, or write a user session service that uses IPC to communicate with the system session in some way. Nobody has looked at that, afaik. This is why user-session-units starts the X server from within the systemd --user environment - it removes that problem entirely. The much nicer way it to simply teach X11 socket activation. Then you can run it either from the system instance of systemd, or the user instance, and things would just work... 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] [PATCH] man: link systemd-static-nodes.service
On Mon, Apr 22, 2013 at 5:13 PM, Umut Tezduyar u...@tezduyar.com wrote: The way I see it is systemd-tmpfiles-setup.service is no different than systemd-static-nodes.service except later is restricted to /dev and runs before udev. Hm, if we want to take that view, then it might make sense to rename it systemd-tmpfiles-setup-dev.service (or something like that). I don't have a strong opinion either way. Kay? -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: link systemd-static-nodes.service
On Mon, Apr 22, 2013 at 6:27 PM, Tom Gundersen t...@jklm.no wrote: On Mon, Apr 22, 2013 at 5:13 PM, Umut Tezduyar u...@tezduyar.com wrote: The way I see it is systemd-tmpfiles-setup.service is no different than systemd-static-nodes.service except later is restricted to /dev and runs before udev. Hm, if we want to take that view, then it might make sense to rename it systemd-tmpfiles-setup-dev.service (or something like that). I don't have a strong opinion either way. Yeah, I think that makes sense. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: add various journal enhancements
On Thu, Apr 18, 2013 at 12:42:38AM +0200, Kay Sievers wrote: On Thu, Apr 18, 2013 at 12:28 AM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett j...@joshtriplett.org wrote: + - Provide one or more FUSE filesystems: +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for all writes rather than limiting permissions That sounds like overkill. We should surely externalize the creation of the files from systemd and make it optional to support legacy stuff, otherwise these files should rather be phased out, than emulated, I think. Separate, external, and optional, definitely; no sense running it if you have no tools around that read or write the format directly. But given that the glibc API (and corresponding expectations about the file format) will exist forever, it seems sensible to have a way to support that without actually having the files on the filesystem. I don't know what *forever* means here, I kind of doubt that. It's pure legacy stuff that needs that, and that works with current systemd. Most systems out there should not need these silly files at all, and the use will surely not grow in the future. Every terminal emulator, display manager, screen/tmux/etc program, or other program that needs to embed an interactive shell should log to utmp and family. The glibc API represents the standard way to do so. So either the glibc API needs to directly support logging to (and reading from) journald, or some compatibility shim like this needs to exist. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: link systemd-static-nodes.service
On Mon, Apr 22, 2013 at 6:37 PM, Kay Sievers k...@vrfy.org wrote: On Mon, Apr 22, 2013 at 6:27 PM, Tom Gundersen t...@jklm.no wrote: On Mon, Apr 22, 2013 at 5:13 PM, Umut Tezduyar u...@tezduyar.com wrote: The way I see it is systemd-tmpfiles-setup.service is no different than systemd-static-nodes.service except later is restricted to /dev and runs before udev. Hm, if we want to take that view, then it might make sense to rename it systemd-tmpfiles-setup-dev.service (or something like that). I don't have a strong opinion either way. Yeah, I think that makes sense. Ok. I pushed the rename. Umut, if you post a rebase of your patch I'll apply it. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: link systemd-static-nodes.service
On Mon, Apr 22, 2013 at 03:16:44PM +0200, Umut Tezduyar wrote: --- man/systemd-tmpfiles.xml|2 ++ units/systemd-static-nodes.service.in |1 + units/systemd-tmpfiles-clean.service.in |2 +- units/systemd-tmpfiles-clean.timer |2 +- units/systemd-tmpfiles-setup.service.in |2 +- 5 files changed, 6 insertions(+), 3 deletions(-) Please run 'make all update-man-list' and include the changes made to Makefile-man.am in the patch. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC PATCH] systemd-python: add SYSLOG_IDENTIFIER to JournalHandler
Otherwise, we get SYSLOG_IDENTIFIER=python or something similar, which is completely useless. --- Thoughts? Specifically, I'm not sure if is worthwhile to allow overriding SYSLOG_IDENTIFIER per message. Maybe this ability should be removed. Zbyszek src/python-systemd/journal.py | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/python-systemd/journal.py b/src/python-systemd/journal.py index 6c740b0..39db4bb 100644 --- a/src/python-systemd/journal.py +++ b/src/python-systemd/journal.py @@ -469,9 +469,15 @@ class JournalHandler(_logging.Handler): The following journal fields will be sent: `MESSAGE`, `PRIORITY`, `THREAD_NAME`, `CODE_FILE`, `CODE_LINE`, `CODE_FUNC`, `LOGGER` (name as supplied to getLogger call), -`MESSAGE_ID` (optional, see above). +`MESSAGE_ID` (optional, see above), `SYSLOG_IDENTIFIER` (optional). +def __init__(self, level=_logging.NOTSET, SYSLOG_IDENTIFIER=None): +super(JournalHandler, self).__init__(level) +self._SYSLOG_IDENTIFIER = (_sys.argv[0] + if SYSLOG_IDENTIFIER is None + else SYSLOG_IDENTIFIER) + def emit(self, record): Write record as journal event. @@ -485,8 +491,11 @@ class JournalHandler(_logging.Handler): msg = self.format(record) pri = self.mapPriority(record.levelno) mid = getattr(record, 'MESSAGE_ID', None) +sid = getattr(record, 'SYSLOG_IDENTIFIER', + self._SYSLOG_IDENTIFIER) send(msg, MESSAGE_ID=mid, + SYSLOG_IDENTIFIER=sid, PRIORITY=format(pri), LOGGER=record.name, THREAD_NAME=record.threadName, -- 1.8.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] systemd-python: add SYSLOG_IDENTIFIER to JournalHandler
On 22/04/13 21:31, Zbigniew Jędrzejewski-Szmek wrote: Otherwise, we get SYSLOG_IDENTIFIER=python or something similar, which is completely useless. --- Thoughts? Specifically, I'm not sure if is worthwhile to allow overriding SYSLOG_IDENTIFIER per message. Maybe this ability should be removed. Zbyszek src/python-systemd/journal.py | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/python-systemd/journal.py b/src/python-systemd/journal.py index 6c740b0..39db4bb 100644 --- a/src/python-systemd/journal.py +++ b/src/python-systemd/journal.py @@ -469,9 +469,15 @@ class JournalHandler(_logging.Handler): The following journal fields will be sent: `MESSAGE`, `PRIORITY`, `THREAD_NAME`, `CODE_FILE`, `CODE_LINE`, `CODE_FUNC`, `LOGGER` (name as supplied to getLogger call), -`MESSAGE_ID` (optional, see above). +`MESSAGE_ID` (optional, see above), `SYSLOG_IDENTIFIER` (optional). +def __init__(self, level=_logging.NOTSET, SYSLOG_IDENTIFIER=None): +super(JournalHandler, self).__init__(level) +self._SYSLOG_IDENTIFIER = (_sys.argv[0] + if SYSLOG_IDENTIFIER is None + else SYSLOG_IDENTIFIER) + def emit(self, record): Write record as journal event. @@ -485,8 +491,11 @@ class JournalHandler(_logging.Handler): msg = self.format(record) pri = self.mapPriority(record.levelno) mid = getattr(record, 'MESSAGE_ID', None) +sid = getattr(record, 'SYSLOG_IDENTIFIER', + self._SYSLOG_IDENTIFIER) send(msg, MESSAGE_ID=mid, + SYSLOG_IDENTIFIER=sid, PRIORITY=format(pri), LOGGER=record.name, THREAD_NAME=record.threadName, How about having the value as `__name__`, but`_sys.argv[0]` if `__name__ == __main__`? -- Steven Hiscocks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] systemd-python: add SYSLOG_IDENTIFIER to JournalHandler
On Mon, Apr 22, 2013 at 09:53:55PM +0100, Steven Hiscocks wrote: +self._SYSLOG_IDENTIFIER = (_sys.argv[0] + if SYSLOG_IDENTIFIER is None + else SYSLOG_IDENTIFIER) How about having the value as `__name__`, but`_sys.argv[0]` if `__name__ == __main__`? __name__ would always be 'journal'. We could use __main__.__name__, but I don't think it makes much of a difference, since it is set from sys.argv[0] anyway. And there's one case where it's less useful: when __name__ == '__main__'. Current code will use SYSLOG_IDENTIFIER='', and journald will add SYSLOG_IDENTIFIER=python on it's own, which looks OK. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] systemd-python: add SYSLOG_IDENTIFIER to JournalHandler
On 22/04/13 22:15, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Apr 22, 2013 at 09:53:55PM +0100, Steven Hiscocks wrote: +self._SYSLOG_IDENTIFIER = (_sys.argv[0] + if SYSLOG_IDENTIFIER is None + else SYSLOG_IDENTIFIER) How about having the value as `__name__`, but`_sys.argv[0]` if `__name__ == __main__`? __name__ would always be 'journal'. We could use __main__.__name__, but I don't think it makes much of a difference, since it is set from sys.argv[0] anyway. And there's one case where it's less useful: when __name__ == '__main__'. Current code will use SYSLOG_IDENTIFIER='', and journald will add SYSLOG_IDENTIFIER=python on it's own, which looks OK. Zbyszek Oh yeah, lol. I don't think I thought that one through :) -- Steven Hiscocks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote: On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote: On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote: --- TODO |5 + 1 file changed, 5 insertions(+) diff --git a/TODO b/TODO index eb482d0..6cf632a 100644 --- a/TODO +++ b/TODO @@ -679,6 +679,11 @@ External: - put bootcharts in the journal - kernel cmdline bootchart option for simplicity? +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Allows installing users without maintainer scripts, and makes + UID namespaces easier to manage. How would that happen? How do you pre-allocate the numbers in a tiny 32bit number range. We do not have UUIDs for that like some real operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. Sorry, I lost you. I have really no idea what you are looking for. Care to start at the beginning again, I read all that again but I don't get it. :) 1) Leave only root in /etc/passwd and /etc/group. 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs. 3) When new users or groups show up, dynamically allocate new IDs for them, and record them in a separate persistent name-number mapping used by the PAM module. Keep them there as long as the .d file exists, or as long as anything on the system (file or process) uses the UID. 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse. 5) In the same daemon managing this, optionally support minting small numbers of ephemeral UIDs/GIDs for use in containers, when they don't need to map to any useful persistent privileges on the host system. Also optionally support creating new non-ephemeral UIDs/GIDs, for persistent use on the host. 6) Eventually move to a big enough ID space that reuse becomes irrelevant, and then allow users to obtain larger blocks of IDs for container use. Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
Am 22.04.2013 23:53, schrieb Josh Triplett: 1) Leave only root in /etc/passwd and /etc/group why? 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs to break any compatibility? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse oh yeah - break any known user management hence there are networks where admins since forever take care that user-id's uniqe all over the machine and you propose reuse? well, you have a solution in search of a problem signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett j...@joshtriplett.org wrote: 1) Leave only root in /etc/passwd and /etc/group. Not commenting on the overall idea, but if you are going to do something like this, at least allow the the files not to exist at all, and in this case a default entry for the root user to be assumed. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 3:26 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 22.04.2013 23:53, schrieb Josh Triplett: 1) Leave only root in /etc/passwd and /etc/group why? 2) Add passwd.d and group.d directories in /etc and under /usr, which accept one record per file (with name given by the filename) and which do not include UIDs or GIDs to break any compatibility? 4) When the .d file goes away, and nothing uses the UID or GID anymore, throw it at the back of the list of IDs to reuse oh yeah - break any known user management hence there are networks where admins since forever take care that user-id's uniqe all over the machine and you propose reuse? well, you have a solution in search of a problem It's ok if you don't understand the proposal, but there's no reason to post random uninformed criticism, now you're creating a rumor that something like this, if implemented, would break all user management. You don't know this. It doesn't exist yet. Maybe it will be 100% backward compatible. Why wouldn't it be? Maybe it won't even go anywhere because people who do understand the topic can assess it's viability. Can you please just wait and see if this goes anywhere concrete first? Thanks, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd: fall back to mounting /sys/fs/cgroup sans xattr
xattrs on cgroup fs were added back in v3.6-rc3-3-g03b1cde. But
we support kernels = 2.6.39, and we also support kernels compiled
w/o xattr support, so it's better to fall back to mounting without
xattr support.
---
Hi Colin,
in follow up to our IRC discussion, could you check if this works for
you? I tested it with Fubuntu 3.4.11 kernel (rpm.pbone.net FTW!), and
I didn't see any adverse effects. It would be great to know that it
also fixes the problem you were observing.
At debug level, a message will be printed, but I think that's fine.
src/core/mount-setup.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index 56d358b..a0fd7a0 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -68,12 +68,6 @@ typedef struct MountPoint {
* other ones we can delay until SELinux and IMA are loaded. */
#define N_EARLY_MOUNT 5
-#ifdef HAVE_XATTR
-# define FS_XATTR_OPT ,xattr
-#else
-# define FS_XATTR_OPT
-#endif
-
static const MountPoint mount_table[] = {
{ proc, /proc, proc, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
@@ -93,7 +87,11 @@ static const MountPoint mount_table[] = {
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ tmpfs, /sys/fs/cgroup,tmpfs, mode=755,
MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
NULL, MNT_IN_CONTAINER },
-{ cgroup, /sys/fs/cgroup/systemd,cgroup,
none,name=systemd FS_XATTR_OPT, MS_NOSUID|MS_NOEXEC|MS_NODEV,
+#ifdef HAVE_XATTR
+{ cgroup, /sys/fs/cgroup/systemd,cgroup,
none,name=systemd,xattr, MS_NOSUID|MS_NOEXEC|MS_NODEV,
+ NULL, MNT_IN_CONTAINER },
+#endif
+{ cgroup, /sys/fs/cgroup/systemd,cgroup,
none,name=systemd, MS_NOSUID|MS_NOEXEC|MS_NODEV,
NULL, MNT_IN_CONTAINER },
{ pstore, /sys/fs/pstore,pstore, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
NULL, MNT_NONE },
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
On Mon, Apr 22, 2013 at 02:53:50PM -0700, Josh Triplett wrote: +* Support passwd.d and group.d; accumulate a persistent name/number map, to + preserve UID/GID assignments without requiring assignment of unique IDs at + adduser time. Hmm, how is that related to systemd code? Sounds more like a glibc shipped feature/plugin? It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. Don't you want tcb, then? http://docs.altlinux.org/manpages/tcb.5.html -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d
]] Josh Triplett Effectively, treat ID numbers as magic rotating implementation details that nobody should care about, and names as the primary identifier. There's this pesky thing called file systems which are pretty reliant on UID and GID numbers. Also, if this is to be done, just put it in a separate NSS module, there's no need for integration with systemd here, AFAICS? (I don't really get what problem you're trying to solve, but that might just be me..) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
