Re: [systemd-devel] Fedora NFS systemd units
On 06/05/13 06:29, Jóhann B. Guðmundsson wrote: On 05/06/2013 09:27 AM, Colin Guthrie wrote: Hi, Just trying to work out a few problems on our (Mageia's) NFS packages. As with a lot of things we often take the units from Fedora (we will soon have a nicer way to share units I hope - need to get release out the way before I can help and put my bit of the work into this tho'). However I'm a bit confused by the latest units. Steve did not pull in all the units a while back [1] ( which I had broken into special nfs target ) so I honestly expect nfs implemenation to be utterly broken ( as it used to be ) in Fedora + the units need to be rewritten and necessary changes done to dracut for root on nfs4 to work ( which I did not test or have in mind when creating them ). JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=769879 I just did... https://bugzilla.redhat.com/show_bug.cgi?id=769879#c11 Please verify that everything that is needed is there... steved. ___ 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] Fedora NFS systemd units
On 06/05/13 15:36, Guillaume Rousse wrote: Le 06/05/2013 11:27, Colin Guthrie a écrit : Also, It is my understanding (and feel free to correct me here) but nfs-idmap is often needed on client systems also? I'm sure I had to configure a client in the past to ensure idmap was running in order to avoid permissions problems and users getting mapped to the 65k uid that means nobody. I had to force this by setting NEEDS_IDMAP=yes in the old sysconfig file /etc/sysconfig/nfs-common (I'm pretty sure we had the same sysvinit setup as Fedora in the past). We didn't :) I stole the nfs-common sysvinit script from Debian, to hide the complexity of the gazillion different daemons needed. AFAIK, Fedora always used single-executable-services. And indeed idmapd is needed both sides for NFSv4. This is no longer the case on the client. The kernel now calls the nfsidmap(5) command to do the idmapping, which is the reason rpc.idmapd is only started on the server side. steved. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora NFS systemd units
On 06/05/13 05:27, Colin Guthrie wrote: Hi, Just trying to work out a few problems on our (Mageia's) NFS packages. As with a lot of things we often take the units from Fedora (we will soon have a nicer way to share units I hope - need to get release out the way before I can help and put my bit of the work into this tho'). However I'm a bit confused by the latest units. nfs-server.service:[Unit] nfs-server.service:Description=NFS Server nfs-server.service:Requires=proc-fs-nfsd.mount var-lib-nfs-rpc_pipefs.mount rpcbind.service nfs-server.service:Requires=nfs-idmap.service nfs-mountd.service nfs-rquotad.service nfs-server.service:After=network.target named.service nfs-server.service:[Service] nfs-server.service:Type=oneshot nfs-server.service:RemainAfterExit=yes nfs-server.service:StandardError=syslog+console nfs-server.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-server.service:ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig nfs-server.service:ExecStartPre=/usr/sbin/exportfs -r nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT nfs-server.service:ExecStartPost=-/usr/lib/nfs-utils/scripts/nfs-server.postconfig nfs-server.service:ExecStop=/usr/sbin/rpc.nfsd 0 nfs-server.service:ExecStopPost=/usr/sbin/exportfs -f nfs-server.service:[Install] nfs-server.service:WantedBy=multi-user.target This is the main server unit. It requires the idmap, mountd and rquotad services. It has After=named.service. Should this not be After=nss-lookup.target instead? Bind/named might not be the only thing that does name lookups after all and nss-lookup.target is meant to encapsulate this does it not? (e.g. ldap could factor in here). I didn't know a nss-lookup.target existed... would that be better than After=named.service? nfs-idmap.service:[Unit] nfs-idmap.service:Description=NFSv4 ID-name mapping daemon nfs-idmap.service:BindTo=nfs-server.service nfs-idmap.service:After=nfs-server.service nfs-idmap.service:[Service] nfs-idmap.service:Type=forking nfs-idmap.service:StandardError=syslog+console nfs-idmap.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-idmap.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS nfs-idmap.service:[Install] nfs-idmap.service:WantedBy=nfs.target This unit is bound to nfs-server so it will follow it's start/stop cycle. Yet it is also wanted by nfs.target. What purpose does nfs.target actually serve here? It was request from https://bugzilla.redhat.com/show_bug.cgi?id=769879 Its not clear why a nfs.target is needed either but it does not break anything so I went with it.. Ditto for the mountd and rquotad units which are similarly structured. Also, It is my understanding (and feel free to correct me here) but nfs-idmap is often needed on client systems also? I'm sure I had to configure a client in the past to ensure idmap was running in order to avoid permissions problems and users getting mapped to the 65k uid that means nobody. No, As (I believe) f17 rpc.idmapd is no longer needed on the client. The kernel now uses the nfsidmap(5) command to to do the idmapping. steved. I had to force this by setting NEEDS_IDMAP=yes in the old sysconfig file /etc/sysconfig/nfs-common (I'm pretty sure we had the same sysvinit setup as Fedora in the past). This being the case should idmap be enablable as an independent unit for client systems (same as nfs-lock.service). Again, feel free to correct me here if I'm wrong. If this is the case the BindTo would have to be dropped, but the Require could still be kept. The install rule would have to be made independant of nfs.target. To aid sysadmin clarity, it would make sense to have the nfs-server.service's [Install] section to have an Also= directive so that the relevant unit's enabled/disabled status's are shown more clearly to sysadmins. If mountd and rquotad make no sense to run separately then they should just have their [Install] sections nuked (more comments about rquoatad below tho'). nfs.target:[Unit] nfs.target:Description=Network File System Server nfs.target:Requires=var-lib-nfs-rpc_pipefs.mount proc-fs-nfsd.mount rpcbind.service nfs.target:After=network.target named.service nfs.target:[Install] nfs.target:WantedBy=multi-user.target If nfs.target is Network File Systemd Server, and the units are already set to be BindTo AND Require, then I really don't grok what nfs.target is for. It's not like it provides any additional level of isolation or configurability. In fact, enabling/disabling idmap, mountd and rquotad services will have no effect anyway due to them being requires/bound to nfs-server.service. Should this target just be dropped? nfs-rquotad.service:[Unit] nfs-rquotad.service:Description=NFS Remote Quota Server nfs-rquotad.service:BindTo=nfs-server.service nfs-rquotad.service:After=nfs-server.service nfs-rquotad.service:[Service] nfs-rquotad.service:Type=forking
[systemd-devel] Patch for Smack labelling support in udev
Hi, This is the patch for review for enabling smack labelling for device nodes. The functionality and reasoning is inside. I will be happy to answer any questions. Best Regards, Elena. 0001-Adding-Smack-support-for-udev-nodes-labelling.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora NFS systemd units
'Twas brillig, and Steve Dickson at 08/05/13 11:58 did gyre and gimble: On 06/05/13 05:27, Colin Guthrie wrote: Hi, Just trying to work out a few problems on our (Mageia's) NFS packages. As with a lot of things we often take the units from Fedora (we will soon have a nicer way to share units I hope - need to get release out the way before I can help and put my bit of the work into this tho'). However I'm a bit confused by the latest units. nfs-server.service:[Unit] nfs-server.service:Description=NFS Server nfs-server.service:Requires=proc-fs-nfsd.mount var-lib-nfs-rpc_pipefs.mount rpcbind.service nfs-server.service:Requires=nfs-idmap.service nfs-mountd.service nfs-rquotad.service nfs-server.service:After=network.target named.service nfs-server.service:[Service] nfs-server.service:Type=oneshot nfs-server.service:RemainAfterExit=yes nfs-server.service:StandardError=syslog+console nfs-server.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-server.service:ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig nfs-server.service:ExecStartPre=/usr/sbin/exportfs -r nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT nfs-server.service:ExecStartPost=-/usr/lib/nfs-utils/scripts/nfs-server.postconfig nfs-server.service:ExecStop=/usr/sbin/rpc.nfsd 0 nfs-server.service:ExecStopPost=/usr/sbin/exportfs -f nfs-server.service:[Install] nfs-server.service:WantedBy=multi-user.target This is the main server unit. It requires the idmap, mountd and rquotad services. It has After=named.service. Should this not be After=nss-lookup.target instead? Bind/named might not be the only thing that does name lookups after all and nss-lookup.target is meant to encapsulate this does it not? (e.g. ldap could factor in here). I didn't know a nss-lookup.target existed... would that be better than After=named.service? It's more generic. So if things other than bind provide name lookups they should hold up nss-lookup.target to allow for such ordering. It's not failsafe, but it's likely a better fit and named.service directly IMO (others please feel free to correct me here). nfs-idmap.service:[Unit] nfs-idmap.service:Description=NFSv4 ID-name mapping daemon nfs-idmap.service:BindTo=nfs-server.service nfs-idmap.service:After=nfs-server.service nfs-idmap.service:[Service] nfs-idmap.service:Type=forking nfs-idmap.service:StandardError=syslog+console nfs-idmap.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-idmap.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS nfs-idmap.service:[Install] nfs-idmap.service:WantedBy=nfs.target This unit is bound to nfs-server so it will follow it's start/stop cycle. Yet it is also wanted by nfs.target. What purpose does nfs.target actually serve here? It was request from https://bugzilla.redhat.com/show_bug.cgi?id=769879 Its not clear why a nfs.target is needed either but it does not break anything so I went with it.. Yeah, but the current units are quite different from the ones submitted in that bug. All of the ones from the bug have WantedBy=nfs.target. In your packages git repo http://pkgs.fedoraproject.org/cgit/nfs-utils.git/tree/ most units have WantedBy=multi-user.target instead, along with various other modifications. While some modifications are good, the confusion for me now lies in what needs to be enabled when etc. FYI, here are my tidyups (which should mostly apply to your files I think): http://svnweb.mageia.org/packages?view=revisionrevision=412429 http://svnweb.mageia.org/packages?view=revisionrevision=412433 The main bit is removing the option from sysadmins for components they shouldn't need to care about (i.e. removing several [Install] sections). Systemd will start them automatically when required and the sysadmin doesn't have to get the magic recipe to make things work). I think this gets them in a better state, but some work is still needed to make it first class and as automatic as our previous solution (more below). Ditto for the mountd and rquotad units which are similarly structured. Also, It is my understanding (and feel free to correct me here) but nfs-idmap is often needed on client systems also? I'm sure I had to configure a client in the past to ensure idmap was running in order to avoid permissions problems and users getting mapped to the 65k uid that means nobody. No, As (I believe) f17 rpc.idmapd is no longer needed on the client. The kernel now uses the nfsidmap(5) command to to do the idmapping. Ahh that might be a difference between you and us then I guess. I believe we still require it (we certainly did in Mageia 2), but perhaps not. Will have to investigate. My changes above assume it's needed, but it would be trivial to leave it out (basically just remove PartOf=nfs.target and add BindTo=nfs-server.service in nfs-idmap.service and remove the Require=nfs-idmap.service from nfs.target and add Require=nfs-idmap.service to nfs-server.service - all assuming the
Re: [systemd-devel] Fedora NFS systemd units
On 05/08/2013 10:58 AM, Steve Dickson wrote: It was request fromhttps://bugzilla.redhat.com/show_bug.cgi?id=769879 Its not clear why a nfs.target is needed either but it does not break anything so I went with it.. Unit and administrative simplification JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patch for Smack labelling support in udev
On Wed, 2013-05-08 at 11:16 +, Reshetova, Elena wrote: The functionality and reasoning is inside. I will be happy to answer any questions. Why is this different from how SELinux works? There from what I can see there's a centralized API to look up the expected label for a given filename (selabel_lookup_raw), and then set the target label for newly created files in the current thread (setfscreatecon). That way we're ensuring the file is created atomically with that label. So why is is SMACK different here, and could it fit into what already exists in src/shared/label.c ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] analyze: show generators on plot
---
src/analyze/systemd-analyze.c | 42
src/core/dbus-manager.c |8 ++
src/core/manager.c|2 +
src/core/manager.h|2 +
4 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/src/analyze/systemd-analyze.c b/src/analyze/systemd-analyze.c
index bb86ec7..df3d307 100644
--- a/src/analyze/systemd-analyze.c
+++ b/src/analyze/systemd-analyze.c
@@ -78,6 +78,8 @@ struct boot_times {
usec_t initrd_time;
usec_t userspace_time;
usec_t finish_time;
+usec_t generators_start_time;
+usec_t generators_finish_time;
};
struct unit_times {
char *name;
@@ -303,7 +305,17 @@ static int acquire_boot_times(DBusConnection *bus, struct
boot_times **bt) {
/org/freedesktop/systemd1,
org.freedesktop.systemd1.Manager,
FinishTimestampMonotonic,
-times.finish_time) 0)
+times.finish_time) 0 ||
+bus_get_uint64_property(bus,
+/org/freedesktop/systemd1,
+org.freedesktop.systemd1.Manager,
+GeneratorsStartTimestampMonotonic,
+times.generators_start_time) 0 ||
+bus_get_uint64_property(bus,
+/org/freedesktop/systemd1,
+org.freedesktop.systemd1.Manager,
+GeneratorsFinishTimestampMonotonic,
+times.generators_finish_time) 0)
return -EIO;
if (times.finish_time = 0) {
@@ -459,7 +471,8 @@ static int analyze_plot(DBusConnection *bus) {
svg(svg width=\%.0fpx\ height=\%.0fpx\ version=\1.1\
xmlns=\http://www.w3.org/2000/svg\;\n\n,
-80.0 + width, 150.0 + (m * SCALE_Y));
+80.0 + width, 150.0 + (m * SCALE_Y) +
+4 * SCALE_Y /* legend */);
/* write some basic info as a comment, including some help */
svg(!-- This file is a systemd-analyze SVG file. It is best rendered
in a --\n
@@ -480,6 +493,7 @@ static int analyze_plot(DBusConnection *bus) {
rect.firmware { fill: rgb(150,150,150); fill-opacity:
0.7; }\n
rect.loader { fill: rgb(150,150,150); fill-opacity:
0.7; }\n
rect.userspace{ fill: rgb(150,150,150); fill-opacity:
0.7; }\n
+ rect.generators { fill: rgb(102,204,255); fill-opacity:
0.7; }\n
rect.box { fill: rgb(240,240,240); stroke:
rgb(192,192,192); }\n
line { stroke: rgb(64,64,64); stroke-width: 1; }\n
//line.sec1 { }\n
@@ -495,8 +509,6 @@ static int analyze_plot(DBusConnection *bus) {
svg(text x=\20\ y=\30\%s %s (%s %s) %s/text,
isempty(osname) ? Linux : osname,
name.nodename, name.release, name.version, name.machine);
-svg(text x=\20\ y=\%.0f\Legend: Red = Activating; Pink =
Active; Dark Pink = Deactivating/text,
-120.0 + (m *SCALE_Y));
svg(g transform=\translate(%.3f,100)\\n, 20.0 + (SCALE_X *
boot-firmware_time));
svg_graph_box(m, -boot-firmware_time, boot-finish_time);
@@ -521,8 +533,9 @@ static int analyze_plot(DBusConnection *bus) {
svg_text(true, boot-initrd_time, y, initrd);
y++;
}
-svg_bar(userspace, boot-userspace_time, boot-finish_time, y);
-svg_text(left, boot-userspace_time, y, userspace);
+svg_bar(active, boot-userspace_time, boot-finish_time, y);
+svg_bar(generators, boot-generators_start_time,
boot-generators_finish_time, y);
+svg_text(left, boot-userspace_time, y, systemd);
y++;
for (u = times; u times + n; u++) {
@@ -544,6 +557,23 @@ static int analyze_plot(DBusConnection *bus) {
svg_text(b, u-ixt, y, %s, u-name);
y++;
}
+
+/* Legend */
+y++;
+svg_bar(activating, 0, 30, y);
+svg_text(right, 40, y, Activating);
+y++;
+svg_bar(active, 0, 30, y);
+svg_text(right, 40, y, Active);
+y++;
+svg_bar(deactivating, 0, 30, y);
+svg_text(right, 40, y, Deactivating);
+y++;
+svg_bar(generators, 0, 30, y);
+svg_text(right, 40, y, Generators);
+y++;
+
+
svg(/g\n\n);
svg(/svg);
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 56b02a1..c932437 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -275,6 +275,10 @@
property name=\UserspaceTimestampMonotonic\ type=\t\
Re: [systemd-devel] [PATCH 1/2] analyze: show generators on plot
Attached! Had too much time :) Feel free to dismiss it.
On Wed, May 8, 2013 at 6:03 PM, Umut Tezduyar u...@tezduyar.com wrote:
---
src/analyze/systemd-analyze.c | 42
src/core/dbus-manager.c |8 ++
src/core/manager.c|2 +
src/core/manager.h|2 +
4 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/src/analyze/systemd-analyze.c b/src/analyze/systemd-analyze.c
index bb86ec7..df3d307 100644
--- a/src/analyze/systemd-analyze.c
+++ b/src/analyze/systemd-analyze.c
@@ -78,6 +78,8 @@ struct boot_times {
usec_t initrd_time;
usec_t userspace_time;
usec_t finish_time;
+usec_t generators_start_time;
+usec_t generators_finish_time;
};
struct unit_times {
char *name;
@@ -303,7 +305,17 @@ static int acquire_boot_times(DBusConnection *bus,
struct boot_times **bt) {
/org/freedesktop/systemd1,
org.freedesktop.systemd1.Manager,
FinishTimestampMonotonic,
-times.finish_time) 0)
+times.finish_time) 0 ||
+bus_get_uint64_property(bus,
+/org/freedesktop/systemd1,
+org.freedesktop.systemd1.Manager,
+GeneratorsStartTimestampMonotonic,
+times.generators_start_time) 0 ||
+bus_get_uint64_property(bus,
+/org/freedesktop/systemd1,
+org.freedesktop.systemd1.Manager,
+GeneratorsFinishTimestampMonotonic,
+times.generators_finish_time) 0)
return -EIO;
if (times.finish_time = 0) {
@@ -459,7 +471,8 @@ static int analyze_plot(DBusConnection *bus) {
svg(svg width=\%.0fpx\ height=\%.0fpx\ version=\1.1\
xmlns=\http://www.w3.org/2000/svg\;\n\n,
-80.0 + width, 150.0 + (m * SCALE_Y));
+80.0 + width, 150.0 + (m * SCALE_Y) +
+4 * SCALE_Y /* legend */);
/* write some basic info as a comment, including some help */
svg(!-- This file is a systemd-analyze SVG file. It is best
rendered in a --\n
@@ -480,6 +493,7 @@ static int analyze_plot(DBusConnection *bus) {
rect.firmware { fill: rgb(150,150,150);
fill-opacity: 0.7; }\n
rect.loader { fill: rgb(150,150,150);
fill-opacity: 0.7; }\n
rect.userspace{ fill: rgb(150,150,150);
fill-opacity: 0.7; }\n
+ rect.generators { fill: rgb(102,204,255);
fill-opacity: 0.7; }\n
rect.box { fill: rgb(240,240,240); stroke:
rgb(192,192,192); }\n
line { stroke: rgb(64,64,64); stroke-width: 1;
}\n
//line.sec1 { }\n
@@ -495,8 +509,6 @@ static int analyze_plot(DBusConnection *bus) {
svg(text x=\20\ y=\30\%s %s (%s %s) %s/text,
isempty(osname) ? Linux : osname,
name.nodename, name.release, name.version, name.machine);
-svg(text x=\20\ y=\%.0f\Legend: Red = Activating; Pink =
Active; Dark Pink = Deactivating/text,
-120.0 + (m *SCALE_Y));
svg(g transform=\translate(%.3f,100)\\n, 20.0 + (SCALE_X *
boot-firmware_time));
svg_graph_box(m, -boot-firmware_time, boot-finish_time);
@@ -521,8 +533,9 @@ static int analyze_plot(DBusConnection *bus) {
svg_text(true, boot-initrd_time, y, initrd);
y++;
}
-svg_bar(userspace, boot-userspace_time, boot-finish_time, y);
-svg_text(left, boot-userspace_time, y, userspace);
+svg_bar(active, boot-userspace_time, boot-finish_time, y);
+svg_bar(generators, boot-generators_start_time,
boot-generators_finish_time, y);
+svg_text(left, boot-userspace_time, y, systemd);
y++;
for (u = times; u times + n; u++) {
@@ -544,6 +557,23 @@ static int analyze_plot(DBusConnection *bus) {
svg_text(b, u-ixt, y, %s, u-name);
y++;
}
+
+/* Legend */
+y++;
+svg_bar(activating, 0, 30, y);
+svg_text(right, 40, y, Activating);
+y++;
+svg_bar(active, 0, 30, y);
+svg_text(right, 40, y, Active);
+y++;
+svg_bar(deactivating, 0, 30, y);
+svg_text(right, 40, y, Deactivating);
+y++;
+svg_bar(generators, 0, 30, y);
+svg_text(right, 40, y, Generators);
+y++;
+
+
svg(/g\n\n);
svg(/svg);
diff --git
Re: [systemd-devel] [PATCH] condition, man: Add support for ConditionSecurity=smack
On Wed, May 08, 2013 at 11:42:34AM -0700, Kok, Auke-jan H wrote: On Tue, May 7, 2013 at 5:29 AM, Karol Lewandowski k.lewando...@samsung.com wrote: On 05/07/2013 01:32 PM, Lennart Poettering wrote: On Tue, 07.05.13 13:21, Karol Lewandowski (k.lewando...@samsung.com) wrote: Heya, Hmm, does that directory always exist? Or only if AppArmor is actually runtime enabled? /sys/fs/smackfs is only registered when smack lsm is actually enabled: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/smack/smackfs.c?id=e93072374112db9dc86635934ee761249be28370#n2179 I.e. this check should ideally only return true if SMACK is not only built into the kernel, but actually really enabled during runtime. That's what the SELinux check does and what the most useful semantics are. Ok, I see that libselinux will consider selinux to be disabled also when policy is not loaded: http://userspace.selinuxproject.org/trac/browser/libselinux/src/enabled.c#L12 I guess we could do something similar (inspect /proc/self/attr/current) but honestly, I don't think it's really needed. Rafał, could you correct me if I'm wrong? smack is different as in that it can function without any loaded policies, so looking at policies isn't the right thing for smack. So likely looking at the presence of smackfs is exactly the same as looking at the preference of /proc/self/attr/current, except the latter is more complex, so less desirable imho. Applied, with a commit message based on this explanation. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
