Re: [systemd-devel] [PATCH] hostnamectl: correct IDs for remote hosts
On Sat, 31.05.14 18:21, Rico Sagner (sag...@b1-systems.de) wrote: Heya! I think that the two ids would probably be better exposed by PID 1 istelf, instead of hostnamed. It's a bit difficult to come up with a rule which props should be exposed from hostnamed and which ones from PID1, but I think the rule should be something along the lines of if it's more an automatically determined property than a user or vendor chosen one, and if PID 1 knows/caches it anyway then it belongs into PID 1... So, could you please move the machine/boot IDs into PID 1 instead of hostnamed, next to where the Virtualization/Architecture properties are defined? Also, please use ay instead of s as type for the property (i.e. a byte-array of the 16 raw uuid bytes instead of an ascii-formatted string). This is how we encoded UUIDs so far as bus properties, see machined's machine uuid property (src/machine/machine-dbus.c) for example. Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tty-ask-password-agent: Do tell what directory we failed to open
On Thu, 29.05.14 14:17, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
Applied! THanks!
---
src/tty-ask-password-agent/tty-ask-password-agent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 3203474..55a2215 100644
--- a/src/tty-ask-password-agent/tty-ask-password-agent.c
+++ b/src/tty-ask-password-agent/tty-ask-password-agent.c
@@ -501,7 +501,7 @@ static int show_passwords(void) {
if (errno == ENOENT)
return 0;
-log_error(opendir(): %m);
+log_error(opendir(/run/systemd/ask-password): %m);
return -errno;
}
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev-builtin-keyboard: do tell on which device EVIOCSKEYCODE failed.
On Fri, 30.05.14 13:16, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: Applied! Thanks! I am getting Error calling EVIOCSKEYCODE (scan code 0xc022d, key code 418): Invalid argument, the error message does not tell on which specific device the problem is, add that info. --- src/udev/udev-builtin-keyboard.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/udev/udev-builtin-keyboard.c b/src/udev/udev-builtin-keyboard.c index 614e44e..9b66bfd 100644 --- a/src/udev/udev-builtin-keyboard.c +++ b/src/udev/udev-builtin-keyboard.c @@ -143,7 +143,7 @@ static int builtin_keyboard(struct udev_device *dev, int argc, char *argv[], boo log_debug(keyboard: mapping scan code %d (0x%x) to key code %d (0x%x), map[i].scan, map[i].scan, map[i].key, map[i].key); if (ioctl(fd, EVIOCSKEYCODE, map[i]) 0) -log_error(Error calling EVIOCSKEYCODE (scan code 0x%x, key code %d): %m, map[i].scan, map[i].key); +log_error(Error calling EVIOCSKEYCODE on device node '%s' (scan code 0x%x, key code %d): %m, node, map[i].scan, map[i].key); } /* install list of force-release codes */ Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On 01/06/14 08:45, Lennart Poettering wrote: On Fri, 30.05.14 04:32, Michael Biebl (mbi...@gmail.com) wrote: 2014-05-30 4:26 GMT+02:00 Greg KH gre...@linuxfoundation.org: You update systemd but you don't update the kernel? How does that make any sense? There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided. To make this clear, we expect that systemd and kernels are updated in lockstep. We explicitly do not support really old kernels with really new systemd. So far we had the focus to support up to 2y old kernels (which means 3.4 right now), but even that should be taken with a grain of salt, as we already made clear that soon after kdbus is merged into the kernel we'll probably make a hard requirement on it from the systemd side. I am tempted to say that we should merge the firmware loader removal patch at the same time as the kdbus requirement is made. As that would be a clean cut anyway... Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. I've already set minimum kernel required to 2.6.39 in = 213, and I'd be fine setting it even higher. Talking only of the udev bit here. I don't like dropping support for old versions, but if that's what has to be done, I'll go with that. Please, don't use this as an excuse to drop support for MinimalBuilds as described in wiki in some manner. As in, if it's still possible to use some kernel, like kernel with kdbus, and even if it requires an userspace library like 'libsystemd-something' to go with it, and still get a udev one way or another, that can run standalone, we are all good. I'd really hate to be forced to fork (or carry huge patchset) unnecessarily (I'm not a systemd hater, I'm not a eudev lover, I'm simply working on what is provided to me by *you*, udev upstream) - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@suse.com) wrote:
I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
in particular that of a launcher idea on system to replace alternatives on the
ExecStart= line of a systemd service unit file, alternative ideas are of
course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
a little while ago with nothing concrete being recommended but instead a few
options being now archived as possibilities. I'm looking for a bit wider
review of the approaches and recomendations.
Some general background for non xen folks: old xen requires the launch of
a daemon which implements supports of the xenstore, which is the database
that xen uses for information about guests / dom0. There are two supported
daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
same thing. Right now old init lets you override which one you pick through
an environment variable on /etc/{sysconfig,default}/xencommons, the script
will use the appropriate on there. Systemd doesn't let you use variables on
the ExecStart line of a service unit file so alternatives are required.
The reason I'm being very careful here this could set a precedent and at
least for the launcher idea it'd require the usage of getenv() and execve(),
and secure alternatives for these (secure_getenv(), execve_nosecurity())
have either been merged or suggested before for Linux. The systemd discussion
is only specific to Linux but if we have a launcher we could consider it for
other supported OSes. All that said I'd like proper review of the security
implications of *all* strategies but obviously in particular the launcher
idea. I want to tread carefuly before setting precedents.
You can also just invoke a shell script from ExecStart=. I mean, we try
to deemphesize them in the boot process, but there's nothing wrong with
using shell, if you need to parse shell configuraiton fragments and just
want to execute on ot another program...
That said, I'd certainly make a clean cut and drop support for
/etc/sysconfig from any project I see, earlier rather than later, since
it's just cruft, a bad idea and should really just go away. But then
again, I would also just not do the thing with supporting two
implementations at the same time...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop the udev firmware loader
On Sun, 01.06.14 09:10, Samuli Suominen (ssuomi...@gentoo.org) wrote: Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. I've already set minimum kernel required to 2.6.39 in = 213, and I'd be fine setting it even higher. Talking only of the udev bit here. I don't like dropping support for old versions, but if that's what has to be done, I'll go with that. Please, don't use this as an excuse to drop support for MinimalBuilds as described in wiki in some manner. As in, if it's still possible to use some kernel, like kernel with kdbus, and even if it requires an userspace library like 'libsystemd-something' to go with it, and still get a udev one way or another, that can run standalone, we are all good. You need the userspace code to set up the bus and its policy and handle activation. That's not a trivial task. For us, that's what sytemd does in PID 1. You'd need to come up with an alternative for that. I'd really hate to be forced to fork (or carry huge patchset) unnecessarily (I'm not a systemd hater, I'm not a eudev lover, I'm simply working on what is provided to me by *you*, udev upstream) Oh god. You know, if you come me like this as blame me that I would force you to do something, then you just piss me off and make me ignore you. Anyway, as soon as kdbus is merged this i how we will maintain udev, you have ample time to figure out some solution that works for you, but we will not support the udev-on-netlink case anymore. I see three options: a) fork things, b) live with systemd, c) if hate systemd that much, but love udev so much, then implement an alternative userspace for kdbus to do initialiuzation/policy/activation. Also note that this will not be a change that is just internal between udev and libudev. We expect that clients will soonishly just start doing normal bus calls to the new udev, like they'd do them to any other system service instead of using libudev. Good luck, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options
On 1 Jun 2014 06:31, Lennart Poettering lenn...@poettering.net wrote: On Sat, 31.05.14 19:43, Samuli Suominen (ssuomi...@gentoo.org) wrote: On 31/05/14 17:10, Samuli Suominen wrote: On 31/05/14 14:14, Samuli Suominen wrote: 1. libsystemd_network_la_SOURCES = in Makefile.am includes src/libsystemd-network/network-internal.h and there is no anykind of #ifdef -logic behind it 2. src/libsystemd-network/network-internal.h has #include libkmod.h and there is no anykind of #ifdef -logic behind it so kmod is hardcoded dependency in systemd-213: This patch is a half-complete hack that only works with --disable-networkd, as it only covers the files that are outside of the #if NETWORKD in Makefile.am As in, I've used this patch only for the package within Gentoo that builds only udev, not rest of systemd, that uses --disable-networkd So consider this as proof of consept, not for inclusion - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I just realized configure.ac already has, AS_IF([test x$have_networkd = xyes -a x$have_kmod != xyes], [AC_MSG_ERROR([networkd requires kmod])]) So this patch should be considered for inclusion after all as-is. You should credit Mike Gilbert flop...@gentoo.org for the patch, not me. I'd prefer I we could fix this properly and allow networkd build without kmod. I am very cool on linking against kmod from networkd anyway (in particular since I want networkd to run without CAP_SYS_MODULE), so I think this could be the least we should be doing... We should be able to drop the whole kmod thing from networkd any day now (a fix is in net-next). Merging it was probably a mistake in the first place. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options
On Sun, 01.06.14 08:04, Tom Gundersen (t...@jklm.no) wrote: On 1 Jun 2014 06:31, Lennart Poettering lenn...@poettering.net wrote: On Sat, 31.05.14 19:43, Samuli Suominen (ssuomi...@gentoo.org) wrote: On 31/05/14 17:10, Samuli Suominen wrote: On 31/05/14 14:14, Samuli Suominen wrote: 1. libsystemd_network_la_SOURCES = in Makefile.am includes src/libsystemd-network/network-internal.h and there is no anykind of #ifdef -logic behind it 2. src/libsystemd-network/network-internal.h has #include libkmod.h and there is no anykind of #ifdef -logic behind it so kmod is hardcoded dependency in systemd-213: This patch is a half-complete hack that only works with --disable-networkd, as it only covers the files that are outside of the #if NETWORKD in Makefile.am As in, I've used this patch only for the package within Gentoo that builds only udev, not rest of systemd, that uses --disable-networkd So consider this as proof of consept, not for inclusion - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I just realized configure.ac already has, AS_IF([test x$have_networkd = xyes -a x$have_kmod != xyes], [AC_MSG_ERROR([networkd requires kmod])]) So this patch should be considered for inclusion after all as-is. You should credit Mike Gilbert flop...@gentoo.org for the patch, not me. I'd prefer I we could fix this properly and allow networkd build without kmod. I am very cool on linking against kmod from networkd anyway (in particular since I want networkd to run without CAP_SYS_MODULE), so I think this could be the least we should be doing... We should be able to drop the whole kmod thing from networkd any day now (a fix is in net-next). Merging it was probably a mistake in the first place. That's great news! What precisely was this needed for in the first place? Some tunnel modules? If it's just that itshould be Ok to simply drop this from networkd again, and ask people with old kernels to add this to /etc/modules-load.d/ instead... I'd be quite happy if we could run our network management daemon without the ability to load kernel modules! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options
On 01/06/14 10:04, Tom Gundersen wrote: On 1 Jun 2014 06:31, Lennart Poettering lenn...@poettering.net mailto:lenn...@poettering.net wrote: On Sat, 31.05.14 19:43, Samuli Suominen (ssuomi...@gentoo.org mailto:ssuomi...@gentoo.org) wrote: On 31/05/14 17:10, Samuli Suominen wrote: On 31/05/14 14:14, Samuli Suominen wrote: 1. libsystemd_network_la_SOURCES = in Makefile.am includes src/libsystemd-network/network-internal.h and there is no anykind of #ifdef -logic behind it 2. src/libsystemd-network/network-internal.h has #include libkmod.h and there is no anykind of #ifdef -logic behind it so kmod is hardcoded dependency in systemd-213: This patch is a half-complete hack that only works with --disable-networkd, as it only covers the files that are outside of the #if NETWORKD in Makefile.am As in, I've used this patch only for the package within Gentoo that builds only udev, not rest of systemd, that uses --disable-networkd So consider this as proof of consept, not for inclusion - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org mailto:systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I just realized configure.ac http://configure.ac already has, AS_IF([test x$have_networkd = xyes -a x$have_kmod != xyes], [AC_MSG_ERROR([networkd requires kmod])]) So this patch should be considered for inclusion after all as-is. You should credit Mike Gilbert flop...@gentoo.org mailto:flop...@gentoo.org for the patch, not me. I'd prefer I we could fix this properly and allow networkd build without kmod. I am very cool on linking against kmod from networkd anyway (in particular since I want networkd to run without CAP_SYS_MODULE), so I think this could be the least we should be doing... We should be able to drop the whole kmod thing from networkd any day now (a fix is in net-next). Merging it was probably a mistake in the first place. So, how about applying the patch from this thread to fix the immediate problem? (This reply isn't aimed specifically to you, but to anyone with such deciding/commit powers really.) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options
On Sun, Jun 1, 2014 at 8:15 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 01/06/14 10:04, Tom Gundersen wrote: On 1 Jun 2014 06:31, Lennart Poettering lenn...@poettering.net mailto:lenn...@poettering.net wrote: On Sat, 31.05.14 19:43, Samuli Suominen (ssuomi...@gentoo.org mailto:ssuomi...@gentoo.org) wrote: On 31/05/14 17:10, Samuli Suominen wrote: On 31/05/14 14:14, Samuli Suominen wrote: 1. libsystemd_network_la_SOURCES = in Makefile.am includes src/libsystemd-network/network-internal.h and there is no anykind of #ifdef -logic behind it 2. src/libsystemd-network/network-internal.h has #include libkmod.h and there is no anykind of #ifdef -logic behind it so kmod is hardcoded dependency in systemd-213: This patch is a half-complete hack that only works with --disable-networkd, as it only covers the files that are outside of the #if NETWORKD in Makefile.am As in, I've used this patch only for the package within Gentoo that builds only udev, not rest of systemd, that uses --disable-networkd So consider this as proof of consept, not for inclusion - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org mailto:systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I just realized configure.ac http://configure.ac already has, AS_IF([test x$have_networkd = xyes -a x$have_kmod != xyes], [AC_MSG_ERROR([networkd requires kmod])]) So this patch should be considered for inclusion after all as-is. You should credit Mike Gilbert flop...@gentoo.org mailto:flop...@gentoo.org for the patch, not me. I'd prefer I we could fix this properly and allow networkd build without kmod. I am very cool on linking against kmod from networkd anyway (in particular since I want networkd to run without CAP_SYS_MODULE), so I think this could be the least we should be doing... We should be able to drop the whole kmod thing from networkd any day now (a fix is in net-next). Merging it was probably a mistake in the first place. So, how about applying the patch from this thread to fix the immediate problem? (This reply isn't aimed specifically to you, but to anyone with such deciding/commit powers really.) I'll review and apply on Monday if no one beats me to it, I'm currently on holiday and don't have the access. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options
On Sun, Jun 1, 2014 at 8:15 AM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 01.06.14 08:04, Tom Gundersen (t...@jklm.no) wrote: On 1 Jun 2014 06:31, Lennart Poettering lenn...@poettering.net wrote: On Sat, 31.05.14 19:43, Samuli Suominen (ssuomi...@gentoo.org) wrote: On 31/05/14 17:10, Samuli Suominen wrote: On 31/05/14 14:14, Samuli Suominen wrote: 1. libsystemd_network_la_SOURCES = in Makefile.am includes src/libsystemd-network/network-internal.h and there is no anykind of #ifdef -logic behind it 2. src/libsystemd-network/network-internal.h has #include libkmod.h and there is no anykind of #ifdef -logic behind it so kmod is hardcoded dependency in systemd-213: This patch is a half-complete hack that only works with --disable-networkd, as it only covers the files that are outside of the #if NETWORKD in Makefile.am As in, I've used this patch only for the package within Gentoo that builds only udev, not rest of systemd, that uses --disable-networkd So consider this as proof of consept, not for inclusion - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I just realized configure.ac already has, AS_IF([test x$have_networkd = xyes -a x$have_kmod != xyes], [AC_MSG_ERROR([networkd requires kmod])]) So this patch should be considered for inclusion after all as-is. You should credit Mike Gilbert flop...@gentoo.org for the patch, not me. I'd prefer I we could fix this properly and allow networkd build without kmod. I am very cool on linking against kmod from networkd anyway (in particular since I want networkd to run without CAP_SYS_MODULE), so I think this could be the least we should be doing... We should be able to drop the whole kmod thing from networkd any day now (a fix is in net-next). Merging it was probably a mistake in the first place. That's great news! What precisely was this needed for in the first place? Some tunnel modules? If it's just that itshould be Ok to simply drop this from networkd again, and ask people with old kernels to add this to /etc/modules-load.d/ instead... Yeah, some tunell modules would not get autoloaded: https://lkml.org/lkml/2014/5/13/118. The modules load thing may indeed be a better solution until the fix is widespread. I'll request that this is backported to stable as well. I'd be quite happy if we could run our network management daemon without the ability to load kernel modules! Indeed. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] journald: Add UDP syslog listener
I would suggest people who need a syslogd to use syslogd. Specifically, rsyslog, which can also output to the journal using the 'omjournal' module, (besides the aforementioned normalization features). -- Mantas Mikulėnas graw...@gmail.com On Jun 1, 2014 8:26 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 28.05.14 22:30, Lubomir Rintel (lkund...@v3.sk) wrote: This is fairly simple, yet useful with netconsole. Remote socket address is not used to obtain hostname, it would be easy to fake it via UDP anyway, which is probably not desirable. If clients wish, they should identify themselves via identifier field in syslog packets. Disabled by default. Humm, I am really cool about this one... There are two problems: journald is highly priviliged because it must be able to read meta-data from /proc for all processes, and exposing such a process onto the network makes me feel very uncomfortable. So far our network-facing services either ran without any priviliges at all (such as systemd-journal-gatewayd), or with only the absolutely minimum they needed (such as timesyncd which only possesses CAP_SYS_TIME). But doing the same with journald is intensly hard since it needs all kinds of super powerful capabilities (such as CAP_SYS_PTRACE) for what it needs to do, because /proc is so weird in many ways.. I mean, I have recently changed the virtualization detection code, so that it can run with no capabilities at all, which should prepare us for changing networkd to run as normal user and only require the various CAP_NET_* caps, but no CAP_SYS_PTRACE or suchlike, which would make it quite a step up security-wise from NM and thelike. So, in many ways we are busy with limiting our attack surface and running things with fewer priviliges, but opening journald up to the internet would really be a step in the other direction here. The other big problem I see is that of normalization. syslog messages are very free-form, and there's very little general structure applied. As long as focus on only local messages (and that means glibc as sender), we can work around that this, as we know what format the client precisely chose. However, if we open this up to the Internet, then we suddenly have to deal with all kinds of formats, from all the router harwdare and whatnot that exists. Much of the complexity of rsyslog and suchlike stems from the fact that they try to normalize the myriad of formats. And I'm really not so keen on getting into that game... I'd be more open to this if this at least could be an independent little daemon (akin to systemd-journald-gatewayd) that runs at minimal priviliges. That would fix my major concern #1... Also, if we do this, then I'd prefer doing this for any number of udp sockets, not just one... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213 fails to compile without kmod, no way to fix it using ./configure options
Tom, I quickly looked at the patch and it seems ok. While glancing over Makefile.am I noticed that e.g. libsystemd_network links against $(KMOD_LIBS). That looks wrong to me (faulty commit is 679be2a74241a70028438217bace423a1a45faa6), only libsystemd-networkd-core really requires kmod 2014-06-01 9:54 GMT+02:00 Tom Gundersen t...@jklm.no: On Sun, Jun 1, 2014 at 8:15 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 01/06/14 10:04, Tom Gundersen wrote: On 1 Jun 2014 06:31, Lennart Poettering lenn...@poettering.net mailto:lenn...@poettering.net wrote: On Sat, 31.05.14 19:43, Samuli Suominen (ssuomi...@gentoo.org mailto:ssuomi...@gentoo.org) wrote: On 31/05/14 17:10, Samuli Suominen wrote: On 31/05/14 14:14, Samuli Suominen wrote: 1. libsystemd_network_la_SOURCES = in Makefile.am includes src/libsystemd-network/network-internal.h and there is no anykind of #ifdef -logic behind it 2. src/libsystemd-network/network-internal.h has #include libkmod.h and there is no anykind of #ifdef -logic behind it so kmod is hardcoded dependency in systemd-213: This patch is a half-complete hack that only works with --disable-networkd, as it only covers the files that are outside of the #if NETWORKD in Makefile.am As in, I've used this patch only for the package within Gentoo that builds only udev, not rest of systemd, that uses --disable-networkd So consider this as proof of consept, not for inclusion - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org mailto:systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I just realized configure.ac http://configure.ac already has, AS_IF([test x$have_networkd = xyes -a x$have_kmod != xyes], [AC_MSG_ERROR([networkd requires kmod])]) So this patch should be considered for inclusion after all as-is. You should credit Mike Gilbert flop...@gentoo.org mailto:flop...@gentoo.org for the patch, not me. I'd prefer I we could fix this properly and allow networkd build without kmod. I am very cool on linking against kmod from networkd anyway (in particular since I want networkd to run without CAP_SYS_MODULE), so I think this could be the least we should be doing... We should be able to drop the whole kmod thing from networkd any day now (a fix is in net-next). Merging it was probably a mistake in the first place. So, how about applying the patch from this thread to fix the immediate problem? (This reply isn't aimed specifically to you, but to anyone with such deciding/commit powers really.) I'll review and apply on Monday if no one beats me to it, I'm currently on holiday and don't have the access. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 ] hostnamectl: correct IDs for remote hosts
Hello
On 01.06.2014 08:01, Lennart Poettering wrote:
On Sat, 31.05.14 18:21, Rico Sagner (sag...@b1-systems.de) wrote:
Heya!
I think that the two ids would probably be better exposed by PID 1
istelf, instead of hostnamed. It's a bit difficult to come up with a
rule which props should be exposed from hostnamed and which ones from
PID1, but I think the rule should be something along the lines of if
it's more an automatically determined property than a user or vendor
chosen one, and if PID 1 knows/caches it anyway then it belongs into PID
1...
Sounds plausible
So, could you please move the machine/boot IDs into PID 1 instead of
hostnamed, next to where the Virtualization/Architecture properties are
defined?
Also, please use ay instead of s as type for the property (i.e. a
byte-array of the 16 raw uuid bytes instead of an ascii-formatted
string). This is how we encoded UUIDs so far as bus properties, see
machined's machine uuid property (src/machine/machine-dbus.c) for example.
I think that should fulfill the requested changes.
Let me know if there is something to improve.
- Rico
If hostnamectl is used with the --host option it does not
show the correct machine and boot IDs of the remote host.
The IDs are read by hostnamectl locally instead of querying
dbus on the remote host.
This patch makes systemd offer the IDs via dbus
and hostnamectl retrieve it this way.
---
src/core/dbus-manager.c| 38 ++
src/core/manager.c | 8
src/core/manager.h | 4
src/hostname/hostnamectl.c | 16
4 files changed, 58 insertions(+), 8 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 333c1d4..d28588a 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -317,6 +317,42 @@ static int property_get_system_state(
return sd_bus_message_append(reply, s,
manager_state_to_string(manager_state(m)));
}
+static int property_get_machineid(
+sd_bus *bus,
+const char *path,
+const char *interface,
+const char *property,
+sd_bus_message *reply,
+void *userdata,
+sd_bus_error *error) {
+
+Manager *m = userdata;
+
+assert(bus);
+assert(reply);
+assert(m);
+
+return sd_bus_message_append_array(reply, 'y', m-machineid, 16);
+}
+
+static int property_get_bootid(
+sd_bus *bus,
+const char *path,
+const char *interface,
+const char *property,
+sd_bus_message *reply,
+void *userdata,
+sd_bus_error *error) {
+
+Manager *m = userdata;
+
+assert(bus);
+assert(reply);
+assert(m);
+
+return sd_bus_message_append_array(reply, 'y', m-bootid, 16);
+}
+
static int property_set_runtime_watchdog(
sd_bus *bus,
const char *path,
@@ -1670,6 +1706,8 @@ const sd_bus_vtable bus_manager_vtable[] = {
SD_BUS_WRITABLE_PROPERTY(ShutdownWatchdogUSec, t,
bus_property_get_usec, bus_property_set_usec, offsetof(Manager,
shutdown_watchdog), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(ControlGroup, s, NULL, offsetof(Manager,
cgroup_root), 0),
SD_BUS_PROPERTY(SystemState, s, property_get_system_state, 0, 0),
+SD_BUS_PROPERTY(MachineId, ay, property_get_machineid, 0,
SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(BootId, ay, property_get_bootid, 0,
SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_METHOD(GetUnit, s, o, method_get_unit,
SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD(GetUnitByPID, u, o, method_get_unit_by_pid,
SD_BUS_VTABLE_UNPRIVILEGED),
diff --git a/src/core/manager.c b/src/core/manager.c
index 0cb2044..d33776b 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -491,6 +491,14 @@ int manager_new(SystemdRunningAs running_as, Manager **_m)
{
if (r 0)
goto fail;
+r = sd_id128_get_machine(m-machineid);
+if(r 0 )
+goto fail;
+
+r = sd_id128_get_boot(m-bootid);
+if(r 0 )
+goto fail;
+
m-udev = udev_new();
if (!m-udev) {
r = -ENOMEM;
diff --git a/src/core/manager.h b/src/core/manager.h
index f2c1b0d..9c74c57 100644
--- a/src/core/manager.h
+++ b/src/core/manager.h
@@ -273,6 +273,10 @@ struct Manager {
/* Reference to the kdbus bus control fd */
int kdbus_fd;
+
+sd_id128_t machineid;
+
+sd_id128_t bootid;
};
int manager_new(SystemdRunningAs running_as, Manager **m);
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index 267cd74..2c875f2 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -73,11 +73,11 @@ typedef struct StatusInfo {
char *os_cpe_name;
char
Re: [systemd-devel] [PATCH] hostnamectl: correct IDs for remote hosts
On Sun, Jun 1, 2014 at 9:01 AM, Lennart Poettering lenn...@poettering.net wrote: On Sat, 31.05.14 18:21, Rico Sagner (sag...@b1-systems.de) wrote: Heya! I think that the two ids would probably be better exposed by PID 1 istelf, instead of hostnamed. It's a bit difficult to come up with a rule which props should be exposed from hostnamed and which ones from PID1, but I think the rule should be something along the lines of if it's more an automatically determined property than a user or vendor chosen one, and if PID 1 knows/caches it anyway then it belongs into PID 1... So, could you please move the machine/boot IDs into PID 1 instead of hostnamed, next to where the Virtualization/Architecture properties are defined? Out of curiosity, wouldn't the existing org.freedesktop.DBus.Peer.GetMachineId() work here? Also, please use ay instead of s as type for the property (i.e. a byte-array of the 16 raw uuid bytes instead of an ascii-formatted string). This is how we encoded UUIDs so far as bus properties, see machined's machine uuid property (src/machine/machine-dbus.c) for example. Thanks! Lennart -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Restarting from inside systemd-nspawn container results in deactivation
Hi, I am using systemd 212 on Arch Linux 64-bit with the following patch applied: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d8e40d62ab871a87fde421c4b246bb45bc3cbe2d I have systemd-nspawn@mycontainer service enabled and started for my container. If I SSH into the container and run the reboot command, the container reboots successfully and I can SSH into it again. However if I run systemctl status systemd-nspawn@mycontainer on the host, I notice the Active status changes from Active: active (running) to Active: deactivating (stop-sigterm). After about a minute and a half, systemd kills the container and my SSH connection is lost. Any ideas on how to proceed with fixing it so the container isn't killed when reboot is issued inside the container? Regards, Jonathan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
