Re: [systemd-devel] [PATCH] Drop ConditionCapability=CAP_MKNOD from *udev* units
Le mercredi 24 juillet 2013 à 18:41 -0300, Gerardo Exequiel Pozzi a écrit : Signed-off-by: Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar --- units/systemd-udev-settle.service.in | 1 - units/systemd-udev-trigger.service.in | 1 - units/systemd-udevd-control.socket| 1 - units/systemd-udevd-kernel.socket | 1 - 4 files changed, 4 deletions(-) What do you expect to fix with this patch ? This will just break distro containers (nspawn / lxc) since it will cause udev to be started there. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop ConditionCapability=CAP_MKNOD from *udev* units
Am 25.07.2013 10:18, schrieb Frederic Crozat: Le mercredi 24 juillet 2013 à 18:41 -0300, Gerardo Exequiel Pozzi a écrit : Signed-off-by: Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar --- units/systemd-udev-settle.service.in | 1 - units/systemd-udev-trigger.service.in | 1 - units/systemd-udevd-control.socket| 1 - units/systemd-udevd-kernel.socket | 1 - 4 files changed, 4 deletions(-) What do you expect to fix with this patch ? This will just break distro containers (nspawn / lxc) since it will cause udev to be started there. If these units should not be started in containers, this should be reflected with ConditionVirtualization. ConditionCapability is not related to containers at all. 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] Drop ConditionCapability=CAP_MKNOD from *udev* units
Le jeudi 25 juillet 2013 à 10:45 +0200, Thomas Bächler a écrit : Am 25.07.2013 10:18, schrieb Frederic Crozat: Le mercredi 24 juillet 2013 à 18:41 -0300, Gerardo Exequiel Pozzi a écrit : Signed-off-by: Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar --- units/systemd-udev-settle.service.in | 1 - units/systemd-udev-trigger.service.in | 1 - units/systemd-udevd-control.socket| 1 - units/systemd-udevd-kernel.socket | 1 - 4 files changed, 4 deletions(-) What do you expect to fix with this patch ? This will just break distro containers (nspawn / lxc) since it will cause udev to be started there. If these units should not be started in containers, this should be reflected with ConditionVirtualization. ConditionCapability is not related to containers at all. Kay changed from ConditionVirtualizaton to ConditionCapability with commit 9371e6f3e04b03692c23e392fdf005a08ccf1edb (Date: Wed Oct 12 02:02:16 2011 +0200) -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop ConditionCapability=CAP_MKNOD from *udev* units
'Twas brillig, and Frederic Crozat at 25/07/13 09:54 did gyre and gimble: Le jeudi 25 juillet 2013 à 10:45 +0200, Thomas Bächler a écrit : Am 25.07.2013 10:18, schrieb Frederic Crozat: Le mercredi 24 juillet 2013 à 18:41 -0300, Gerardo Exequiel Pozzi a écrit : Signed-off-by: Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar --- units/systemd-udev-settle.service.in | 1 - units/systemd-udev-trigger.service.in | 1 - units/systemd-udevd-control.socket| 1 - units/systemd-udevd-kernel.socket | 1 - 4 files changed, 4 deletions(-) What do you expect to fix with this patch ? This will just break distro containers (nspawn / lxc) since it will cause udev to be started there. If these units should not be started in containers, this should be reflected with ConditionVirtualization. ConditionCapability is not related to containers at all. Kay changed from ConditionVirtualizaton to ConditionCapability with commit 9371e6f3e04b03692c23e392fdf005a08ccf1edb (Date: Wed Oct 12 02:02:16 2011 +0200) I guess the fact that the udev units no longer need CAP_MKNOD (with that functionality moving to kmod and tmpfiles) means that this condition seems rather wrong these days. Perhaps the ConditionVirtualization may be the more appropriate one again these days? 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] /etc/systemd/system/darkice.service
'Twas brillig, and Kai Hendry at 25/07/13 06:22 did gyre and gimble: Going back to the timeout, I started the PI without a network. Waited a minute or two. Then I started pingtest.service manually. I was surprised that network-online.target doesn't turn active. I had to manually start it. http://ix.io/6RD These targets are effectively static synchronisation points. The problem here is that you're trying to map a very dynamic concept (networks coming and going) to a static one (targets being reached). You could turn such a thing into something more dynamic by writing a deamon which actively monitors the network status and starts/stop the network-online.target accordingly. Service units could then Requires network online and be automatically stopped when it was stopped. But this creates a lot more problems. Units would have to be changed to have WantedBy=network-online.target (as opposed to the more common multi-user.target) and to also have a Requires=network-online.target as mentioned above. This seems like it might be good at first, but the problem is you lose all state information. If you stop several enabled services manually (and deliberately) then at some point later the network has a blip and the target is stopped (stopping all services that require it) but then comes back again, then *all* enabled services will be started again, including the ones manually stopped by the administrator. There are several other problems that arises here too. Such as the definition of what network up actually is. Different daemons work on different definitions and thus we'd have to have a whole bunch of targets with fine-grained names to capture all the combinations and have monitoring daemons for each. Then there are some services that only care about one interface working, not the whole network so you need targets and monitors for that too. Some daemons only want a local network and not a public internet so you add another factor to the combinations with that too. Before long (and long before this point) it becomes obvious the whole things is just totally unmanageable like this. Really the network-online.target is just a hack. It represents a best effort point in time that was also provided (equally badly) by previous init systems. The only *real* way to fix this problem is for the daemons themselves to properly deal with networks coming and going. Only the daemons with their config files can know what is important to them, which interfaces matter, whether an external network is needed or whether this is a purely local one etc. etc. The services themselves need to behave properly in a dynamic environment and not assume it's static. See the What does this mean for me, a Developer? section on this page which basically says exactly this: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Hope this explains it to you a little. 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
[systemd-devel] Does systemd have points to spend many times to complete its process?
Hello I'm Tony Seo. I've analyzed a plot resulted in systemd-analyze plot. As you can see an attached image file, I got this image from my systemd. While I have analyzed it, I have several questions. 1. what is -.mount ? when I first saw -.mout, I was confused how to configure it. 2. I doubt that there are critical points which make systemd more delayed for several reasons. I have tried to test my systemd for optimization in perspective of time consume. So, I changed the order of unit dependency and sequence among units. But I found that I may not reduce the time to activate getty.target, multi-user.target and graphical.target. And I doubt that there are critical points or span of stage to make the systemd more delayed. I want to know whether I'm wrong or not. what do you think about it? If you know some tip to improve a systemd in optimize perspective, could you give some tips to make my systemd more fast? 3. I need a clear knowledge about transaction stage. I read a manpage which introduces a few contents of transaction, but I would like to get more information about it. Thanks, Tony Seo ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Udev rule question
Hello,
we have been using Udev without systemd (currently tracking version 205)
and we have a problem. The rule that worked some time ago (can't
remember when) doesn't work anymore.
It's alsa-utils rule for restoring the volume at boot using Udev rule.
This is the current rule which doesn't work:
ACTION==add, SUBSYSTEM==sound, KERNEL==controlC*,
KERNELS!=card*, GOTO=alsa_restore_go
GOTO=alsa_restore_end
LABEL=alsa_restore_go
TEST!=/etc/alsa/state-daemon.conf, RUN+=/usr/sbin/alsactl restore
$attr{number}
TEST==/etc/alsa/state-daemon.conf, RUN+=/usr/sbin/alsactl nrestore
$attr{number}
LABEL=alsa_restore_end
The rule was changed in 1.0.27 release. Before 1.0.27 release it was
like this:
ACTION==add, SUBSYSTEM==sound, KERNEL==controlC*, KERNELS==card*, \
RUN+=/usr/sbin/alsactl restore $attr{number}
Unfortunately, none of these work anymore. I don't know if something is
wrong with rules. If so, please say what and I'll report it to upstream.
Also, I presume that driver is built in into kernel, but similar rule
for rtc clock saving/restoring is working fine with rtc driver builtin.
And no, systemd+udev is not an option (I've tried my best, sorry).
Everything else appears to work.
Looking forward to any advice. Thanks in advance.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does systemd have points to spend many times to complete its process?
Hello, 'Twas brillig, and Tony Seo at 25/07/13 11:49 did gyre and gimble: I've analyzed a plot resulted in systemd-analyze plot. As you can see an attached image file, I got this image from my systemd. No image attached. THe mailing list likely stripped it out because it was too large. As requested previously, please post it somewhere and include a link here. While I have analyzed it, I have several questions. 1. what is -.mount ? when I first saw -.mout, I was confused how to configure it. This is you / mount point. It's synthesised from your fstab (all fstab entries will have .mount units) 2. I doubt that there are critical points which make systemd more delayed for several reasons. I have tried to test my systemd for optimization in perspective of time consume. So, I changed the order of unit dependency and sequence among units. But I found that I may not reduce the time to activate getty.target, multi-user.target and graphical.target. And I doubt that there are critical points or span of stage to make the systemd more delayed. I want to know whether I'm wrong or not. I really don't know what you mean by the above and it's hard to see without comparisons of different setups and options and their corresponding plot outputs. If you know some tip to improve a systemd in optimize perspective, could you give some tips to make my systemd more fast? Perhaps this: http://freedesktop.org/wiki/Software/systemd/Optimizations/ 3. I need a clear knowledge about transaction stage. I read a manpage which introduces a few contents of transaction, but I would like to get more information about it. Again, I don't really know what you are asking here... 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
[systemd-devel] [PATCH] dbus: use _cleanup_free_ instead of freeing ourself
---
src/core/dbus-execute.c | 3 +--
src/core/dbus-job.c | 11 ++-
src/core/dbus-manager.c | 14 +++---
src/core/unit.c | 48 ++--
4 files changed, 28 insertions(+), 48 deletions(-)
diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c
index 73590c8..2402e8c 100644
--- a/src/core/dbus-execute.c
+++ b/src/core/dbus-execute.c
@@ -77,12 +77,11 @@ static int
bus_execute_append_oom_score_adjust(DBusMessageIter *i, const char *p
if (c-oom_score_adjust_set)
n = c-oom_score_adjust;
else {
-char *t;
+_cleanup_free_ char *t = NULL;
n = 0;
if (read_one_line_file(/proc/self/oom_score_adj, t) = 0) {
safe_atoi(t, n);
-free(t);
}
}
diff --git a/src/core/dbus-job.c b/src/core/dbus-job.c
index a85d318..4ab88d0 100644
--- a/src/core/dbus-job.c
+++ b/src/core/dbus-job.c
@@ -60,7 +60,7 @@ static DEFINE_BUS_PROPERTY_APPEND_ENUM(bus_job_append_type,
job_type, JobType);
static int bus_job_append_unit(DBusMessageIter *i, const char *property, void
*data) {
Job *j = data;
DBusMessageIter sub;
-char *p;
+_cleanup_free_ char *p = NULL;
assert(i);
assert(property);
@@ -75,12 +75,9 @@ static int bus_job_append_unit(DBusMessageIter *i, const
char *property, void *d
if (!dbus_message_iter_append_basic(sub, DBUS_TYPE_STRING,
j-unit-id) ||
!dbus_message_iter_append_basic(sub, DBUS_TYPE_OBJECT_PATH, p)) {
-free(p);
return -ENOMEM;
}
-free(p);
-
if (!dbus_message_iter_close_container(i, sub))
return -ENOMEM;
@@ -136,7 +133,7 @@ static DBusHandlerResult
bus_job_message_handler(DBusConnection *connection, DBu
/* Be nice to gdbus and return introspection data for our
mid-level paths */
if (dbus_message_is_method_call(message,
org.freedesktop.DBus.Introspectable, Introspect)) {
-char *introspection = NULL;
+_cleanup_free_ char *introspection = NULL;
FILE *f;
Iterator i;
size_t size;
@@ -169,7 +166,6 @@ static DBusHandlerResult
bus_job_message_handler(DBusConnection *connection, DBu
if (ferror(f)) {
fclose(f);
-free(introspection);
goto oom;
}
@@ -179,12 +175,9 @@ static DBusHandlerResult
bus_job_message_handler(DBusConnection *connection, DBu
goto oom;
if (!dbus_message_append_args(reply, DBUS_TYPE_STRING,
introspection, DBUS_TYPE_INVALID)) {
-free(introspection);
goto oom;
}
-free(introspection);
-
if (!bus_maybe_send_reply(connection, message, reply))
goto oom;
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index e1a169c..75e2e45 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -413,7 +413,7 @@ static int bus_manager_set_log_target(DBusMessageIter *i,
const char *property,
}
static int bus_manager_append_log_level(DBusMessageIter *i, const char
*property, void *data) {
-char *t;
+_cleanup_free_ char *t = NULL;
int r;
assert(i);
@@ -426,7 +426,6 @@ static int bus_manager_append_log_level(DBusMessageIter *i,
const char *property
if (!dbus_message_iter_append_basic(i, DBUS_TYPE_STRING, t))
r = -ENOMEM;
-free(t);
return r;
}
@@ -1191,7 +1190,7 @@ static DBusHandlerResult
bus_manager_message_handler(DBusConnection *connection,
goto oom;
} else if (dbus_message_is_method_call(message,
org.freedesktop.DBus.Introspectable, Introspect)) {
-char *introspection = NULL;
+_cleanup_free_ char *introspection = NULL;
FILE *f;
Iterator i;
Unit *u;
@@ -1217,7 +1216,7 @@ static DBusHandlerResult
bus_manager_message_handler(DBusConnection *connection,
fputs(INTROSPECTION_BEGIN, f);
HASHMAP_FOREACH_KEY(u, k, m-units, i) {
-char *p;
+_cleanup_free_ char *p = NULL;
if (k != u-id)
continue;
@@ -1225,12 +1224,10 @@ static DBusHandlerResult
bus_manager_message_handler(DBusConnection *connection,
p = bus_path_escape(k);
if (!p) {
Re: [systemd-devel] [IDEA] systemd as basis for HA clusters
On Sun, 21.07.13 06:36, Jan Engelhardt (jeng...@inai.de) wrote: On Saturday 2013-07-20 02:05, Pablo Nehab Hess wrote: Hi all, I was wondering how much systemd could add to current high availability cluster setups. [...] Does this idea even make sense? Is it too one systemd to rule them all? If it means we can principally get rid of the OCF scripts (they are as ugly as sysvinit scripts). However, as always, the systemd is going to be even fatter argument might come up again if it enlarges /usr/lib/systemd/systemd. Could you elaborate on what OCF scripts precisely are and do? 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] [IDEA] systemd as basis for HA clusters
On Fri, 19.07.13 21:05, Pablo Nehab Hess (pa...@hess.net.br) wrote: Hi all, I was wondering how much systemd could add to current high availability cluster setups. Today systemd is used on HA clusters as just an init replacement. However, there are systemd features that might come in handy and improve the overall performance and even reliability of such clusters: * watchdog functionality as in http://0pointer.de/blog/projects/watchdog.html is the most evident feature; * tcp-based dbus communication could be used to exchange information between cluster members; Also, I believe systemd functionality could be extended so it would take into consideration other nodes' systemd instances in order to make sure each service is always alive somewhere -- call it floating units if you will. :-) Does this idea even make sense? Is it too one systemd to rule them all? Well, I don't really know what exactly HA clusters would need. However, note that we actually do try to draw the line somewhere where systemd ends... I have the suspicion the HA cluster stuff something which could make great use of systemd's comprehensive bus interfaces, but I am not convinced such a project should sit in systemd itself. 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] Drop ConditionCapability=CAP_MKNOD from *udev* units
On Wed, 24.07.13 18:41, Gerardo Exequiel Pozzi (vmlinuz...@yahoo.com.ar) wrote: We generally try to make conditions specific to a feature rather than an execution environment. Containers should run without CAP_MKMNOD, and as udev originally was in the business of creating device nodes we hence bound it to this capability. Now, since very recently udev doesn'#t create a single device node anymore (it's all done by the kernel in devtmpfs/container manager and tmpfiles now), so it probably would make sense to change the capability check, but certainly not remove it. (I'd vote by replacing it by ConditionPathIsReadWrite=/sys since sane container managers mount that read-only.) Anyway, I don't get what you are trying to achieve by your patch please elaborate. Signed-off-by: Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar --- units/systemd-udev-settle.service.in | 1 - units/systemd-udev-trigger.service.in | 1 - units/systemd-udevd-control.socket| 1 - units/systemd-udevd-kernel.socket | 1 - 4 files changed, 4 deletions(-) diff --git a/units/systemd-udev-settle.service.in b/units/systemd-udev-settle.service.in index 037dd9a..148aa9d 100644 --- a/units/systemd-udev-settle.service.in +++ b/units/systemd-udev-settle.service.in @@ -16,7 +16,6 @@ DefaultDependencies=no Wants=systemd-udevd.service After=systemd-udev-trigger.service Before=sysinit.target -ConditionCapability=CAP_MKNOD [Service] Type=oneshot diff --git a/units/systemd-udev-trigger.service.in b/units/systemd-udev-trigger.service.in index 604c369..ea3cb62 100644 --- a/units/systemd-udev-trigger.service.in +++ b/units/systemd-udev-trigger.service.in @@ -12,7 +12,6 @@ DefaultDependencies=no Wants=systemd-udevd.service After=systemd-udevd-kernel.socket systemd-udevd-control.socket Before=sysinit.target -ConditionCapability=CAP_MKNOD [Service] Type=oneshot diff --git a/units/systemd-udevd-control.socket b/units/systemd-udevd-control.socket index ca17102..12a66d2 100644 --- a/units/systemd-udevd-control.socket +++ b/units/systemd-udevd-control.socket @@ -10,7 +10,6 @@ Description=udev Control Socket Documentation=man:systemd-udevd.service(8) man:udev(7) DefaultDependencies=no Before=sockets.target -ConditionCapability=CAP_MKNOD [Socket] Service=systemd-udevd.service diff --git a/units/systemd-udevd-kernel.socket b/units/systemd-udevd-kernel.socket index 4b8a5b0..64e6f63 100644 --- a/units/systemd-udevd-kernel.socket +++ b/units/systemd-udevd-kernel.socket @@ -10,7 +10,6 @@ Description=udev Kernel Socket Documentation=man:systemd-udevd.service(8) man:udev(7) DefaultDependencies=no Before=sockets.target -ConditionCapability=CAP_MKNOD [Socket] Service=systemd-udevd.service 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] Drop ConditionCapability=CAP_MKNOD from *udev* units
On Thu, 25.07.13 10:45, Thomas Bächler (tho...@archlinux.org) wrote: Am 25.07.2013 10:18, schrieb Frederic Crozat: Le mercredi 24 juillet 2013 à 18:41 -0300, Gerardo Exequiel Pozzi a écrit : Signed-off-by: Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar --- units/systemd-udev-settle.service.in | 1 - units/systemd-udev-trigger.service.in | 1 - units/systemd-udevd-control.socket| 1 - units/systemd-udevd-kernel.socket | 1 - 4 files changed, 4 deletions(-) What do you expect to fix with this patch ? This will just break distro containers (nspawn / lxc) since it will cause udev to be started there. If these units should not be started in containers, this should be reflected with ConditionVirtualization. ConditionCapability is not related to containers at all. CAP_MKNOD certainly is related to containers. It's generally available on hosts but not in containers. 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] [206] Randomly on shutdown, stop timeout for user@.service
On Wed, 24.07.13 14:50, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: El 24/07/13 14:07, Gerardo Exequiel Pozzi escribió: Hello I am using Arch Linux, and testing systemd-206 with linux-3.10.2 on shutdown, sometimes randomly there is a long delay until user@0.service timeouts then systemd kills it. I am seeing a similar behaviour here, but it hangs shutting down the session-1.scope unit. So for this one I have an idea what happens. I figure inside that scope unit you have a bash running? The bash ignores SIGTERM, and requires SIGHUP instead for a clean termination. logind knew that and always sent both. Since we moved everything to scope units it's now PID1's job to kill the processes, and it doesn't explicitly send SIGHUP right now. I figure we need to update the PID 1 scope kill logic to optionally send both SIGTERM and SIGHUP to the cgroup members. 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 SecureBits / NoNewPrivileges
On Sat, 20.07.13 04:06, Reindl Harald (h.rei...@thelounge.net) wrote: Hi i try to secure the Apache-Webserver (mpm-prefork) as much as possible am i right that with the following settings in the systemd-unit after the child-process is forked with the apache user and the capabilities are reduced as below even a potential root exploit would have no success? SecureBits=noroot fails i guess because it even disallows the parent-process to run as root after start IIRC combining NoNewPrivileges with CAP_SETUID doesn't really make much sense as the latter is one way how to gain new privs, but the former doesn't allow this. 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 SecureBits / NoNewPrivileges
Am 25.07.2013 20:00, schrieb Lennart Poettering: On Sat, 20.07.13 04:06, Reindl Harald (h.rei...@thelounge.net) wrote: Hi i try to secure the Apache-Webserver (mpm-prefork) as much as possible am i right that with the following settings in the systemd-unit after the child-process is forked with the apache user and the capabilities are reduced as below even a potential root exploit would have no success? SecureBits=noroot fails i guess because it even disallows the parent-process to run as root after start IIRC combining NoNewPrivileges with CAP_SETUID doesn't really make much sense as the latter is one way how to gain new privs, but the former doesn't allow this well, but httpd needs CAP_SETUID to *lower* the privileges after start for the child-processes and needs root at startup as well as for the master-prcoess which opens logfiles and othe filehandles not allowed to do for the user apache that is why my idea of the setting is OK, once you dropped your privileges nothing will allow to get back root permissions signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shell-completion: fix zsh completion installation
Moved zsh shell completion to shell-completion/zsh/_systemd for
automake's sake. Also allow users to specify where the files should go
with::
./configure --with-zshcompletiondir=/path/to/some/where
and by default going to `$datadir/zsh/site-functions`
---
Honestly, this is my first foray into autotools, hence the simple rename
instead of some logic in the Makefile.am or configure.ac. I also think it
cleans up the shell-completion dir a bit. The 'systemd-zsh-completion.zsh'
name always seemed a bit off compared to the bash names.
Makefile.am | 7 ++-
configure.ac | 6 ++
shell-completion/{systemd-zsh-completion.zsh = zsh/_systemd} | 0
3 files changed, 12 insertions(+), 1 deletion(-)
rename shell-completion/{systemd-zsh-completion.zsh = zsh/_systemd} (100%)
diff --git a/Makefile.am b/Makefile.am
index 7933de6..4e8a3f1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -68,6 +68,7 @@ pkgconfigdatadir=$(datadir)/pkgconfig
pkgconfiglibdir=$(libdir)/pkgconfig
polkitpolicydir=$(datadir)/polkit-1/actions
bashcompletiondir=@bashcompletiondir@
+zshcompletiondir=@zshcompletiondir@
rpmmacrosdir=$(prefix)/lib/rpm/macros.d
sysvinitdir=$(SYSTEM_SYSVINIT_PATH)
sysvrcnddir=$(SYSTEM_SYSVRCND_PATH)
@@ -342,6 +343,9 @@ dist_bashcompletion_DATA = \
shell-completion/bash/systemd-analyze \
shell-completion/bash/udevadm
+dist_zshcompletion_DATA = \
+ shell-completion/zsh/_systemd
+
dist_sysctl_DATA = \
sysctl.d/50-default.conf
@@ -4238,7 +4242,7 @@ EXTRA_DIST += \
docs/var-log/README.in
EXTRA_DIST += \
- shell-completion/systemd-zsh-completion.zsh
+ shell-completion/zsh/_systemd
SOCKETS_TARGET_WANTS += \
systemd-initctl.socket \
@@ -4354,6 +4358,7 @@ DISTCHECK_CONFIGURE_FLAGS = \
--with-dbussystemservicedir=$$dc_install_base/$(dbussystemservicedir) \
--with-dbusinterfacedir=$$dc_install_base/$(dbusinterfacedir) \
--with-bashcompletiondir=$$dc_install_base/$(bashcompletiondir) \
+ --with-zshcompletiondir=$$dc_install_base/$(zshcompletiondir) \
--with-pamlibdir=$$dc_install_base/$(pamlibdir) \
--with-rootprefix=$$dc_install_base \
--disable-split-usr
diff --git a/configure.ac b/configure.ac
index 759073a..3028028 100644
--- a/configure.ac
+++ b/configure.ac
@@ -911,6 +911,10 @@ AC_ARG_WITH([bashcompletiondir],
with_bashcompletiondir=${datadir}/bash-completion/completions
])])
+AC_ARG_WITH([zshcompletiondir],
+AS_HELP_STRING([--with-zshcompletiondir=DIR], [Zsh completions
directory]),
+[], [with_zshcompletiondir=${datadir}/zsh/site-functions])
+
AC_ARG_WITH([rootprefix],
AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix for
config files and kernel modules]),
[], [with_rootprefix=${ac_default_prefix}])
@@ -955,6 +959,7 @@ AC_SUBST([dbussessionservicedir],
[$with_dbussessionservicedir])
AC_SUBST([dbussystemservicedir], [$with_dbussystemservicedir])
AC_SUBST([dbusinterfacedir], [$with_dbusinterfacedir])
AC_SUBST([bashcompletiondir], [$with_bashcompletiondir])
+AC_SUBST([zshcompletiondir], [$with_zshcompletiondir])
AC_SUBST([pamlibdir], [$with_pamlibdir])
AC_SUBST([rootprefix], [$with_rootprefix])
AC_SUBST([rootlibdir], [$with_rootlibdir])
@@ -1032,6 +1037,7 @@ AC_MSG_RESULT([
D-Bus system dir:${with_dbussystemservicedir}
D-Bus interfaces dir:${with_dbusinterfacedir}
Bash completions dir:${with_bashcompletiondir}
+Zsh completions dir: ${with_zshcompletiondir}
Extra start script: ${RC_LOCAL_SCRIPT_PATH_START}
Extra stop script: ${RC_LOCAL_SCRIPT_PATH_STOP}
Debug shell: ${SUSHELL} @ ${DEBUGTTY}
diff --git a/shell-completion/systemd-zsh-completion.zsh
b/shell-completion/zsh/_systemd
similarity index 100%
rename from shell-completion/systemd-zsh-completion.zsh
rename to shell-completion/zsh/_systemd
--
1.8.3.4.1180.ge27c933
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] unused translations in git
On Mon, 22.07.13 05:51, Michael Biebl (mbi...@gmail.com) wrote: Hi, so it seems to me, we use gettext to translate the PolicyKit policy files, but we do not actually enable/ship them, as the po files are not added to po/LINGUAS. Admittedly, it's currently only a single translation (Polish), so I was wondering what the intention here is. Do we want systemd to be translated? If so, should we reach out to translator get a broader coverage of languages? Well, I guess translation of the tools and PK policies is probably inevitable. We should be careful though, for example, I'd rather not see gettext being used within PID 1. l10n isn't really something I personally care about too much, so we rely on community patches to make this work. Patches welcome. I am a bit afraid of eventually having to merge a large stream of translation patches however. Would love to the use some platform like Transifex for this, but given that they don't properly attribute their git commits to the original authors (or has that changed now?) I am not sure it would be a good idea as-is. 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] [IDEA] systemd as basis for HA clusters
On Thu, Jul 25, 2013 at 06:51:21PM +0200, Lennart Poettering wrote: On Fri, 19.07.13 21:05, Pablo Nehab Hess (pa...@hess.net.br) wrote: Hi all, I was wondering how much systemd could add to current high availability cluster setups. Today systemd is used on HA clusters as just an init replacement. However, there are systemd features that might come in handy and improve the overall performance and even reliability of such clusters: * watchdog functionality as in http://0pointer.de/blog/projects/watchdog.html is the most evident feature; * tcp-based dbus communication could be used to exchange information between cluster members; Also, I believe systemd functionality could be extended so it would take into consideration other nodes' systemd instances in order to make sure each service is always alive somewhere -- call it floating units if you will. :-) Does this idea even make sense? Is it too one systemd to rule them all? Well, I don't really know what exactly HA clusters would need. However, note that we actually do try to draw the line somewhere where systemd ends... I have the suspicion the HA cluster stuff something which could make great use of systemd's comprehensive bus interfaces, but I am not convinced such a project should sit in systemd itself. The RH Cluster suite cares about running services, and restarting services when they fail. Just like systemd. Main difference is that you can select on which host to run this service. It could be implemented in some daemon synchronising state between remote systemd's. Every time I use ”clustat” I feel like I'm should be looking at ”systemctl status” listing. When I enable services using ”clusvcadm -e foo” I feel like it should be ”systemctl enable foo”. There's a quite big overlap between cluster suite and systemctl. -- Tomasz TorczFuneral in the morning, IDE hacking xmpp: zdzich...@chrome.plin the afternoon and evening. - Alan Cox ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] unused translations in git
On Thu, Jul 25, 2013 at 09:20:35PM +0200, Lennart Poettering wrote: On Mon, 22.07.13 05:51, Michael Biebl (mbi...@gmail.com) wrote: Hi, so it seems to me, we use gettext to translate the PolicyKit policy files, but we do not actually enable/ship them, as the po files are not added to po/LINGUAS. I guess the polish-speaking-systemd-community, which is surprisingly large, could try to update the Polish translation, and start shipping it in the next release and see what happens. Admittedly, it's currently only a single translation (Polish), so I was wondering what the intention here is. Do we want systemd to be translated? If so, should we reach out to translator get a broader coverage of languages? Well, I guess translation of the tools and PK policies is probably inevitable. We should be careful though, for example, I'd rather not see gettext being used within PID 1. l10n isn't really something I personally care about too much, so we rely on community patches to make this work. Patches welcome. I am a bit afraid of eventually having to merge a large stream of translation patches however. Frankly, I don't see too much of a problem. The worse that can happen is that some language has inferior translations. We already have large patches with hwdb updates. Would love to the use some platform like Transifex for this, but given that they don't properly attribute their git commits to the original authors (or has that changed now?) I am not sure it would be a good idea as-is. Something like that would be great. Zbyszek -- they are not broken. they are refucktored -- alxchk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [IDEA] systemd as basis for HA clusters
On Thursday 2013-07-25 18:52, Lennart Poettering wrote: On Sun, 21.07.13 06:36, Jan Engelhardt (jeng...@inai.de) wrote: I was wondering how much systemd could add to current high availability cluster setups. [...] Does this idea even make sense? Is it too one systemd to rule them all? If it means we can principally get rid of the OCF scripts (they are as ugly as sysvinit scripts). However, as always, the systemd is going to be even fatter argument might come up again if it enlarges /usr/lib/systemd/systemd. Could you elaborate on what OCF scripts precisely are and do? LSB-like scripts; they implement start, stop and a handful of other actions. Introductory reading material at http://linux-ha.org/wiki/OCF_Resource_Agents . ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [IDEA] systemd as basis for HA clusters
On Thu, 25.07.13 21:21, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Thu, Jul 25, 2013 at 06:51:21PM +0200, Lennart Poettering wrote: On Fri, 19.07.13 21:05, Pablo Nehab Hess (pa...@hess.net.br) wrote: Hi all, I was wondering how much systemd could add to current high availability cluster setups. Today systemd is used on HA clusters as just an init replacement. However, there are systemd features that might come in handy and improve the overall performance and even reliability of such clusters: * watchdog functionality as in http://0pointer.de/blog/projects/watchdog.html is the most evident feature; * tcp-based dbus communication could be used to exchange information between cluster members; Also, I believe systemd functionality could be extended so it would take into consideration other nodes' systemd instances in order to make sure each service is always alive somewhere -- call it floating units if you will. :-) Does this idea even make sense? Is it too one systemd to rule them all? Well, I don't really know what exactly HA clusters would need. However, note that we actually do try to draw the line somewhere where systemd ends... I have the suspicion the HA cluster stuff something which could make great use of systemd's comprehensive bus interfaces, but I am not convinced such a project should sit in systemd itself. The RH Cluster suite cares about running services, and restarting services when they fail. Just like systemd. Main difference is that you can select on which host to run this service. Well we have -H already. What more do you need? It could be implemented in some daemon synchronising state between remote systemd's. Every time I use ”clustat” I feel like I'm should be looking at ”systemctl status” listing. When I enable services using ”clusvcadm -e foo” I feel like it should be ”systemctl enable foo”. There's a quite big overlap between cluster suite and systemctl. So these tools will walk the cluster and get the status of the respective service on all machines? 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] [Feature request] A way to native import /proc/cmdline within unit
On Sat, 20.07.13 16:37, Gerardo Exequiel Pozzi (vmlinuz...@yahoo.com.ar) wrote: Hello I am maintainer of Archiso project (The Arch Linux live ISO creator). I like a feature for systemd within unit files, mainly for importing /proc/cmdline in initramfs stage, or in a generic form for any other file with a similar format. Something like ImportOneLineFile=, like current EnvironmentFile=. In this way, we can use/pass parameters to Exec*= directives if needed. So you awant to import kernel cmdline arguments into your environment? Note that you can do that already with the systemd.setenv= kernel command line option. What else do you need? 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] /etc/systemd/system/darkice.service
On Mon, 22.07.13 17:48, Kai Hendry (hen...@iki.fi) wrote: On 19 July 2013 01:29, Lennart Poettering lenn...@poettering.net wrote: It is certainly surprising at first, but it makes a lot of sense. In systemd ordering deps and requirement deps are truly orthogonal. This is useful in many cases, because sometimes you just want to pull something else in, but not imply any ordering, sometimes you want to order without actually pulling it in, and often you want to do both. Of course, not all deps make sense in all combinations, but I think it's easy enough to grasp. What happens in the range of error cases when a user puts a Wants= line under the (wrong) [Install] heading? We generally generate warnings about invalid lines and proceed. Aftre we parsed everything we then do a couple of checks whether a unit still makes sense with the stuff that was correctly parsed, and only if the unit does't pass that check we will fail it. I tried it and network-online.target was loaded inactive dead, so it failed IIUC. No warning that Wants= line is in the wrong place. This sucks quite a lot imo. loaded inactive dead does not indicate any error, just that the thing didn't get started. I enabled the above as pingtest.service and added Wants=network-online.target under the [Unit] heading in darkice.service. Still I don't understand how pingtest.service can fail here with exit 2 and even more confusingly network-online.target is reached!? http://ix.io/6Nv Does it work if you run it from the command line? WantedBy= means that a unit is pulled in but it is not relevant whether it succeed to reach a target. There's also RequiredBy= which is the stronger option where that does matter. Generally, for robustness reasons we suggest people to use WantedBy rather than RequiredBy, but it's up to you. This will timeout after 60 seconds. Isn't this better controlled by systemd itself? And not be a command line switch in the exec? We currently don't support Timeouts on type=oneshot services, but we should fix it. It's hacky, generates awful traffic, and has quite some latency, but it should do what you asked for... Awful traffic? One successful ping and we continue IIUC. Well, you still bombard the local network if the internet connection is sewered far away... This doesn't really scale to more than a few sysem. A lot of routers IIUC do a heart beat type ping to ensure it's up. And if not it would switch to another route or something. If routers are doing this, why can't my device? Is it really that expensive?? They usually use exponentially increasing intervals, to avoid flooding. 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] Drop ConditionCapability=CAP_MKNOD from *udev* units
On Thu, Jul 25, 2013 at 7:00 PM, Lennart Poettering lenn...@poettering.net wrote: I'd vote by replacing it by ConditionPathIsReadWrite=/sys since sane container managers mount that read-only.) A change like that sounds great to me. Keying-off access to /sys is probably more appropriate for today's udev than the ability creating device nodes. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop ConditionCapability=CAP_MKNOD from *udev* units
On 07/25/2013 02:00 PM, Lennart Poettering wrote: On Wed, 24.07.13 18:41, Gerardo Exequiel Pozzi (vmlinuz...@yahoo.com.ar) wrote: We generally try to make conditions specific to a feature rather than an execution environment. Containers should run without CAP_MKMNOD, and as udev originally was in the business of creating device nodes we hence bound it to this capability. OK Now, since very recently udev doesn'#t create a single device node anymore (it's all done by the kernel in devtmpfs/container manager and tmpfiles now), so it probably would make sense to change the capability check, but certainly not remove it. (I'd vote by replacing it by ConditionPathIsReadWrite=/sys since sane container managers mount that read-only.) Exactly. Anyway, I don't get what you are trying to achieve by your patch please elaborate. My thought was simple: Hey! what is doing CAP_MKNOD here since is not needed anymore for udev, remove them!. Ok course, I did not think in containers, my bad. Anyway, this should be changed to something more obvious thing for testing about running environment. Q: If udev should not run in container why not udevd itself check about this? Thanks for your feedback. Signed-off-by: Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar --- units/systemd-udev-settle.service.in | 1 - units/systemd-udev-trigger.service.in | 1 - units/systemd-udevd-control.socket| 1 - units/systemd-udevd-kernel.socket | 1 - 4 files changed, 4 deletions(-) diff --git a/units/systemd-udev-settle.service.in b/units/systemd-udev-settle.service.in index 037dd9a..148aa9d 100644 --- a/units/systemd-udev-settle.service.in +++ b/units/systemd-udev-settle.service.in @@ -16,7 +16,6 @@ DefaultDependencies=no Wants=systemd-udevd.service After=systemd-udev-trigger.service Before=sysinit.target -ConditionCapability=CAP_MKNOD [Service] Type=oneshot diff --git a/units/systemd-udev-trigger.service.in b/units/systemd-udev-trigger.service.in index 604c369..ea3cb62 100644 --- a/units/systemd-udev-trigger.service.in +++ b/units/systemd-udev-trigger.service.in @@ -12,7 +12,6 @@ DefaultDependencies=no Wants=systemd-udevd.service After=systemd-udevd-kernel.socket systemd-udevd-control.socket Before=sysinit.target -ConditionCapability=CAP_MKNOD [Service] Type=oneshot diff --git a/units/systemd-udevd-control.socket b/units/systemd-udevd-control.socket index ca17102..12a66d2 100644 --- a/units/systemd-udevd-control.socket +++ b/units/systemd-udevd-control.socket @@ -10,7 +10,6 @@ Description=udev Control Socket Documentation=man:systemd-udevd.service(8) man:udev(7) DefaultDependencies=no Before=sockets.target -ConditionCapability=CAP_MKNOD [Socket] Service=systemd-udevd.service diff --git a/units/systemd-udevd-kernel.socket b/units/systemd-udevd-kernel.socket index 4b8a5b0..64e6f63 100644 --- a/units/systemd-udevd-kernel.socket +++ b/units/systemd-udevd-kernel.socket @@ -10,7 +10,6 @@ Description=udev Kernel Socket Documentation=man:systemd-udevd.service(8) man:udev(7) DefaultDependencies=no Before=sockets.target -ConditionCapability=CAP_MKNOD [Socket] Service=systemd-udevd.service Lennart -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] build: allow specifying a custom pam session name
for distribution now wanting to use systemd-shared
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
Makefile.am| 1 +
configure.ac | 10 ++
units/u...@.service.in | 2 +-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index d013dfd..8030c5f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4072,6 +4072,7 @@ substitutions = \
'|udevlibexecdir=$(udevlibexecdir)|' \
'|SUSHELL=$(SUSHELL)|' \
'|DEBUGTTY=$(DEBUGTTY)|' \
+ '|PAM_NAME=$(PAM_NAME)|' \
'|KILL=$(KILL)|' \
'|KMOD=$(KMOD)|' \
'|MKDIR_P=$(MKDIR_P)|' \
diff --git a/configure.ac b/configure.ac
index 759073a..c1d2dac 100644
--- a/configure.ac
+++ b/configure.ac
@@ -404,6 +404,15 @@ AC_SUBST(PAM_LIBS)
AM_CONDITIONAL([HAVE_PAM], [test x$have_pam != xno])
#
--
+AC_ARG_WITH([pam-name],
+AS_HELP_STRING([--with-pam-name=NAME],
+[Specify the PAM session name to set up a session as]),
+[PAM_NAME=$withval],
+[PAM_NAME=systemd-shared])
+
+AC_SUBST(PAM_NAME)
+
+#
--
AC_ARG_ENABLE([acl],
AS_HELP_STRING([--disable-acl],[Disable optional ACL support]),
[case ${enableval} in
@@ -1027,6 +1036,7 @@ AC_MSG_RESULT([
Installation Python: ${PYTHON_BINARY}
firmware path: ${FIRMWARE_PATH}
PAM modules dir: ${with_pamlibdir}
+PAM session name:${with_pam_name}
D-Bus policy dir:${with_dbuspolicydir}
D-Bus session dir: ${with_dbussessionservicedir}
D-Bus system dir:${with_dbussystemservicedir}
diff --git a/units/u...@.service.in b/units/u...@.service.in
index 8f9a3b3..ce53d31 100644
--- a/units/u...@.service.in
+++ b/units/u...@.service.in
@@ -11,7 +11,7 @@ After=systemd-user-sessions.service
[Service]
User=%I
-PAMName=systemd-shared
+PAMName=@PAM_NAME@
Type=notify
ExecStart=-@rootlibexecdir@/systemd --user
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
--
1.8.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Feature request] A way to native import /proc/cmdline within unit
On 07/25/2013 05:06 PM, Lennart Poettering wrote: On Sat, 20.07.13 16:37, Gerardo Exequiel Pozzi (vmlinuz...@yahoo.com.ar) wrote: Hello I am maintainer of Archiso project (The Arch Linux live ISO creator). I like a feature for systemd within unit files, mainly for importing /proc/cmdline in initramfs stage, or in a generic form for any other file with a similar format. Something like ImportOneLineFile=, like current EnvironmentFile=. In this way, we can use/pass parameters to Exec*= directives if needed. So you awant to import kernel cmdline arguments into your environment? Yes, in a particular unit. Note that you can do that already with the systemd.setenv= kernel command line option. What else do you need? Yes. But doing in this way: * Makes each variable passed, global to all units. * For each parameter that I need to process I need to prefix them. So for example archisobasedir=arch archisolabel=ARCH_201307 checksum=y becomes: systemd.setenv=archisobasedir=arch systemd.setenv=archisolabel=ARCH_201307 systemd.setenv=checksum=y And if booting via PXE, think about automatic cmdline appended by ip=... PXELINUX/IPAPPEND... The other solution that I have is using a service+script for parsing/dumping cmdline in a file, then import with EnvironmentFile= but does not look good. Other way maybe is using a generator, but they run too early and I need to wait for some things happens before generating units in a dynamic way. Lennart Thanks for your attention. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1 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] shell-completion: fix zsh completion installation
2013/7/25 William Giokas 1007...@gmail.com: Moved zsh shell completion to shell-completion/zsh/_systemd for automake's sake. Also allow users to specify where the files should go with:: ./configure --with-zshcompletiondir=/path/to/some/where and by default going to `$datadir/zsh/site-functions` I was told [1], the directory for 3rd party packages would be /usr/share/zsh/vendor-completions. But I'm not a zsh user, so I'm just paroting what I read there. Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717540#15 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [IDEA] systemd as basis for HA clusters
'Twas brillig, and Lennart Poettering at 25/07/13 20:59 did gyre and gimble: On Thu, 25.07.13 21:21, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Thu, Jul 25, 2013 at 06:51:21PM +0200, Lennart Poettering wrote: On Fri, 19.07.13 21:05, Pablo Nehab Hess (pa...@hess.net.br) wrote: Hi all, I was wondering how much systemd could add to current high availability cluster setups. Today systemd is used on HA clusters as just an init replacement. However, there are systemd features that might come in handy and improve the overall performance and even reliability of such clusters: * watchdog functionality as in http://0pointer.de/blog/projects/watchdog.html is the most evident feature; * tcp-based dbus communication could be used to exchange information between cluster members; Also, I believe systemd functionality could be extended so it would take into consideration other nodes' systemd instances in order to make sure each service is always alive somewhere -- call it floating units if you will. :-) Does this idea even make sense? Is it too one systemd to rule them all? Well, I don't really know what exactly HA clusters would need. However, note that we actually do try to draw the line somewhere where systemd ends... I have the suspicion the HA cluster stuff something which could make great use of systemd's comprehensive bus interfaces, but I am not convinced such a project should sit in systemd itself. The RH Cluster suite cares about running services, and restarting services when they fail. Just like systemd. Main difference is that you can select on which host to run this service. Well we have -H already. What more do you need? It could be implemented in some daemon synchronising state between remote systemd's. Every time I use ”clustat” I feel like I'm should be looking at ”systemctl status” listing. When I enable services using ”clusvcadm -e foo” I feel like it should be ”systemctl enable foo”. There's a quite big overlap between cluster suite and systemctl. So these tools will walk the cluster and get the status of the respective service on all machines? Not sure if it's a walk as such, but the outcome is exactly that yes. I've not used clustat and such for a while tho', so am a bit rusty. 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] unused translations in git
2013/7/25 Lennart Poettering lenn...@poettering.net: On Mon, 22.07.13 05:51, Michael Biebl (mbi...@gmail.com) wrote: Hi, so it seems to me, we use gettext to translate the PolicyKit policy files, but we do not actually enable/ship them, as the po files are not added to po/LINGUAS. Admittedly, it's currently only a single translation (Polish), so I was wondering what the intention here is. Do we want systemd to be translated? If so, should we reach out to translator get a broader coverage of languages? Well, I guess translation of the tools and PK policies is probably inevitable. We should be careful though, for example, I'd rather not see gettext being used within PID 1. l10n isn't really something I personally care about too much, so we rely on community patches to make this work. Patches welcome. Apparently we already have a translation, so I was curious, why we don't ship that in the tarball. Is that simply an oversight or does it have other reasons? Michael -- 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] build: allow specifying a custom pam session name
On Fri, Jul 26, 2013 at 12:28 AM, Marc-Antoine Perennou marc-anto...@perennou.com wrote: for distribution now wanting to use systemd-shared Could you explain a bit more why this needs to be configurable? What's the usecase? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: allow specifying a custom pam session name
On 26 July 2013 01:10, Tom Gundersen t...@jklm.no wrote: On Fri, Jul 26, 2013 at 12:28 AM, Marc-Antoine Perennou marc-anto...@perennou.com wrote: for distribution now wanting to use systemd-shared Could you explain a bit more why this needs to be configurable? What's the usecase? Cheers, Tom Oh, there is obviously a typo, it should be not and not now. It will allow distribution to use their already available pam session, like login-local or such, for example. + I don't think systemd-shared is really an explicit name for a pam session ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] shell-completion: fix zsh completion installation
Moved zsh shell completion to shell-completion/zsh/_systemd for
automake's sake. Also allow users to specify where the files should go
with::
./configure --with-zshcompletiondir=/path/to/some/where
and by default going to `$datadir/zsh/vendor-functions`
---
Makefile.am | 7 ++-
configure.ac | 6 ++
shell-completion/{systemd-zsh-completion.zsh = zsh/_systemd} | 0
3 files changed, 12 insertions(+), 1 deletion(-)
rename shell-completion/{systemd-zsh-completion.zsh = zsh/_systemd} (100%)
diff --git a/Makefile.am b/Makefile.am
index 7933de6..4e8a3f1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -68,6 +68,7 @@ pkgconfigdatadir=$(datadir)/pkgconfig
pkgconfiglibdir=$(libdir)/pkgconfig
polkitpolicydir=$(datadir)/polkit-1/actions
bashcompletiondir=@bashcompletiondir@
+zshcompletiondir=@zshcompletiondir@
rpmmacrosdir=$(prefix)/lib/rpm/macros.d
sysvinitdir=$(SYSTEM_SYSVINIT_PATH)
sysvrcnddir=$(SYSTEM_SYSVRCND_PATH)
@@ -342,6 +343,9 @@ dist_bashcompletion_DATA = \
shell-completion/bash/systemd-analyze \
shell-completion/bash/udevadm
+dist_zshcompletion_DATA = \
+ shell-completion/zsh/_systemd
+
dist_sysctl_DATA = \
sysctl.d/50-default.conf
@@ -4238,7 +4242,7 @@ EXTRA_DIST += \
docs/var-log/README.in
EXTRA_DIST += \
- shell-completion/systemd-zsh-completion.zsh
+ shell-completion/zsh/_systemd
SOCKETS_TARGET_WANTS += \
systemd-initctl.socket \
@@ -4354,6 +4358,7 @@ DISTCHECK_CONFIGURE_FLAGS = \
--with-dbussystemservicedir=$$dc_install_base/$(dbussystemservicedir) \
--with-dbusinterfacedir=$$dc_install_base/$(dbusinterfacedir) \
--with-bashcompletiondir=$$dc_install_base/$(bashcompletiondir) \
+ --with-zshcompletiondir=$$dc_install_base/$(zshcompletiondir) \
--with-pamlibdir=$$dc_install_base/$(pamlibdir) \
--with-rootprefix=$$dc_install_base \
--disable-split-usr
diff --git a/configure.ac b/configure.ac
index 759073a..a7e03b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -911,6 +911,10 @@ AC_ARG_WITH([bashcompletiondir],
with_bashcompletiondir=${datadir}/bash-completion/completions
])])
+AC_ARG_WITH([zshcompletiondir],
+AS_HELP_STRING([--with-zshcompletiondir=DIR], [Zsh completions
directory]),
+[], [with_zshcompletiondir=${datadir}/zsh/vendor-functions])
+
AC_ARG_WITH([rootprefix],
AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix for
config files and kernel modules]),
[], [with_rootprefix=${ac_default_prefix}])
@@ -955,6 +959,7 @@ AC_SUBST([dbussessionservicedir],
[$with_dbussessionservicedir])
AC_SUBST([dbussystemservicedir], [$with_dbussystemservicedir])
AC_SUBST([dbusinterfacedir], [$with_dbusinterfacedir])
AC_SUBST([bashcompletiondir], [$with_bashcompletiondir])
+AC_SUBST([zshcompletiondir], [$with_zshcompletiondir])
AC_SUBST([pamlibdir], [$with_pamlibdir])
AC_SUBST([rootprefix], [$with_rootprefix])
AC_SUBST([rootlibdir], [$with_rootlibdir])
@@ -1032,6 +1037,7 @@ AC_MSG_RESULT([
D-Bus system dir:${with_dbussystemservicedir}
D-Bus interfaces dir:${with_dbusinterfacedir}
Bash completions dir:${with_bashcompletiondir}
+Zsh completions dir: ${with_zshcompletiondir}
Extra start script: ${RC_LOCAL_SCRIPT_PATH_START}
Extra stop script: ${RC_LOCAL_SCRIPT_PATH_STOP}
Debug shell: ${SUSHELL} @ ${DEBUGTTY}
diff --git a/shell-completion/systemd-zsh-completion.zsh
b/shell-completion/zsh/_systemd
similarity index 100%
rename from shell-completion/systemd-zsh-completion.zsh
rename to shell-completion/zsh/_systemd
--
1.8.3.4.1180.ge27c933
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop ConditionCapability=CAP_MKNOD from *udev* units
On Fri, Jul 26, 2013 at 12:19 AM, Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar wrote: Anyway, I don't get what you are trying to achieve by your patch please elaborate. My thought was simple: Hey! what is doing CAP_MKNOD here since is not needed anymore for udev, remove them!. Ok course, I did not think in containers, my bad. Note, that you did not remove/dropped the given CAP, you removed the *match* on the existence of it. It's not needed, but after removing the match, it will still have the CAP. :) Anyway, this should be changed to something more obvious thing for testing about running environment. Q: If udev should not run in container why not udevd itself check about this? It does exactly that, I think. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop ConditionCapability=CAP_MKNOD from *udev* units
On Thu, 25.07.13 19:19, Gerardo Exequiel Pozzi (vmlinuz...@yahoo.com.ar) wrote: Anyway, I don't get what you are trying to achieve by your patch please elaborate. My thought was simple: Hey! what is doing CAP_MKNOD here since is not needed anymore for udev, remove them!. Ok course, I did not think in containers, my bad. Anyway, this should be changed to something more obvious thing for testing about running environment. Q: If udev should not run in container why not udevd itself check about this? It's an optimization. ConditionCapability= means we don't even bother with forking off the udev process when running in a container. 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] unused translations in git
On Fri, 26.07.13 00:44, Michael Biebl (mbi...@gmail.com) wrote: 2013/7/25 Lennart Poettering lenn...@poettering.net: On Mon, 22.07.13 05:51, Michael Biebl (mbi...@gmail.com) wrote: Hi, so it seems to me, we use gettext to translate the PolicyKit policy files, but we do not actually enable/ship them, as the po files are not added to po/LINGUAS. Admittedly, it's currently only a single translation (Polish), so I was wondering what the intention here is. Do we want systemd to be translated? If so, should we reach out to translator get a broader coverage of languages? Well, I guess translation of the tools and PK policies is probably inevitable. We should be careful though, for example, I'd rather not see gettext being used within PID 1. l10n isn't really something I personally care about too much, so we rely on community patches to make this work. Patches welcome. Apparently we already have a translation, so I was curious, why we don't ship that in the tarball. Is that simply an oversight or does it have other reasons? Oversight. 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 v2] shell-completion: fix zsh completion installation
On Fri, Jul 26, 2013 at 12:41:11AM +0200, Michael Biebl wrote: I was told [1], the directory for 3rd party packages would be /usr/share/zsh/vendor-completions. But I'm not a zsh user, so I'm just paroting what I read there. Was there a zsh developer (not a Debian packager of zsh) that says this is where things should go? Not that I want to go against Debian, but I don't want to just do what Debian says, I would rather do what the zsh developers so. You can specify a directory for this, so if a distro wants it in a separate place, they can do that. On Thu, Jul 25, 2013 at 06:25:03PM -0500, William Giokas wrote: Moved zsh shell completion to shell-completion/zsh/_systemd for automake's sake. Also allow users to specify where the files should go with:: ./configure --with-zshcompletiondir=/path/to/some/where and by default going to `$datadir/zsh/vendor-functions` Please disregard this until things are worked out. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgphvRWWPH7md.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] shell-completion: fix zsh completion installation
On Thu, Jul 25, 2013 at 07:02:14PM -0500, William Giokas wrote: On Fri, Jul 26, 2013 at 12:41:11AM +0200, Michael Biebl wrote: I was told [1], the directory for 3rd party packages would be /usr/share/zsh/vendor-completions. But I'm not a zsh user, so I'm just paroting what I read there. Was there a zsh developer (not a Debian packager of zsh) that says this is where things should go? Not that I want to go against Debian, but I don't want to just do what Debian says, I would rather do what the zsh developers so. You can specify a directory for this, so if a distro wants it in a separate place, they can do that. Just looking at what Fedora/CentOS and Arch provide, nothing installs to '/usr/share/zsh/vendor-functions/'. I'm going to say to disregard the v2 and go with the v1 patch. If Debian wants to put it somewhere special, they can use the configure flag. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpfgaqYVIvFe.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
