Re: [systemd-devel] Unwants
On Thu, 22.01.15 13:54, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: Is there a way to remove / override wants that are specified via .wants directory, .d snippet with Wants=, or wants specified in the unit itself? Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? When we designed this initially this way I wasn't sure this would suffice, but I kinda like the simplicity of this, and interestingly you are the first one who wants to reset dependencies again. Which makes me wonder if we canot find a better solution for this? I thought that creating a symlink to /dev/null from a higher up directory would disable wants dependency but it didn't: e.g.: I was expecting for /run/systemd/system/getty.target.wants/getty@tty1.service - /dev/null Wat precisely is the reason for trying to do this? What are you trying to do here, and why? So, is there a way to unwant something, as an override? Nope, currently there isn't. 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] Unwants
On 27 January 2015 at 12:42, Lennart Poettering lenn...@poettering.net wrote: On Thu, 22.01.15 15:16, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 22 January 2015 at 14:46, Michael Biebl mbi...@gmail.com wrote: 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com: At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it That's indeed a tough problem. The upstream recommendation is, to run systemctl preset during the initial installation. If there are changes to the default in the unit files, those changes are *not* applied on package upgrades. Presets are good, however they do not have a format to specify extra .wants and .requires. And in my case unwants and unrequires. Extra .wants and .requires? What would those entail? I mean, the unit files can store extra deps in their [Install] section... So at the moment I'm playing around with - unconditionally running preset on my preset file, and directing users to write (override) own preset file in /etc/systemd/system-preset if they want to modify the default proposed integration. I don't think that's a particularly compelling solution. In Debian, we introduced a helper called i-s-h [1], which keeps some additional state and tries to apply such changes on updates. Well, if systemctl enable/disable/add-requires/add-wants would write things into /etc/systemd/system-preset instead of modifying things in /etc, then it would be alright. As essentially the full set of presets would be the state of system-defaults + user overrides. Also it seems like preset is a bit of templating hack at the moment, as they are not loaded by systemd but rarther are simply used to generate files/symlinks on disk under /etc. I don't follow. Presets are the recommended vendor configuration, and as such static and immutable. It is supposed to be applied once, during first installation of a pacakge. From that point on things are user configuration and presets will not be applied. The end result of preset commands is the same as running a series of enable/disable commands interactively. Which means it is never possible to tell apart differences between: admin changes, current vendor configuration, original vendor configuration at install-time. Nor upgrade to new vendor defaults. Thus preset files simply scrip a list of enable/disable commands to run. It is not supposed to be applied only once, but rather it has no way to distinguish user modifications vs old vendor config and thus cannot be re-run again without loosing admin changes/choices. E.g. for my use-case it would be awesome if preset commands would generate symlinks in e.g. /var/lib/systemd/preset-system/ That way preset files is the current vendor configuration, /var/lib/systemd/preset-system has symlinks as to how the system was configured at install time. Later when system is upgraded and e.g. vendor presets change, I would like to enable user to upgrade the install time config to the current one (by running preset command again, which would update symlinks in /var/lib/systemd/preset-system based on the new preset configuration) Or something like that. I'm working on a system which has a policy of units enabled by default, with packaging discouraged from shipping files in /etc. /etc is end-user modifiable however and is supported to store overrides over what is shipped in /usr. Patching preset files during runtime is really against what they were designed for. Quite frankly, I have trouble following at all what is being attempted here... I think i'll need to start again, or show/expain what I mean on Friday. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persisting sriov_numvfs
- Original Message - From: Lennart Poettering lenn...@poettering.net To: Martin Polednik mpoled...@redhat.com Cc: Andrei Borzenkov arvidj...@gmail.com, systemd-devel@lists.freedesktop.org, ibar...@redhat.com Sent: Tuesday, January 27, 2015 2:21:21 PM Subject: Re: [systemd-devel] persisting sriov_numvfs On Tue, 27.01.15 07:35, Martin Polednik (mpoled...@redhat.com) wrote: Hmm, I see. In many ways this feels like VLAN setup from a configuration PoV, right? i.e. you have one hw device the driver creates, and then you configure a couple of additional interfaces on top of it. This of course then raises the question: shouldn't this functionality be exposed by the kernel the same way as VLANs? i.e. with a rtnetlink-based API to create additional interfaces, instead of /sys? In systemd I figure the right way to expose this to the user would be via .netdev files, the same way as we expose VLAN devices. Not however that that would be networkd territory, No, this is not limited to NICs. It is generic feature that can be in principle used with any hardware and there are e.g. FC or FCoE HBAs with SR-IOV support. It is true that today it is mostly comes with NICs though. Any general framework for setting it up should not be tied to specific card type. Well, I doubt that there will be graphics cards that support this right? I mean, it's really only network connectivity that can support a concept like this easily, since you can easily merge packet streams from multiple VMs on one connection. However, I am not sure how you want to physically merge VGA streams onto a single VGA connector... If this is about ethernet, FC, FCOE, then I still think that the network management solution should consider this as something you can configure on physical links like VLANs. Hence networkd or NetworkManager and so on should cover it. Lennart Afaik some storage cards support this, for GPU's it's possibly for the GPUPU applications and such - where you don't care about the physical output, but the processing core of gpu itself (but I'm not aware of such implementation yet, nvidia seems to be doing something but the details are nowhere to be found). Hmm, so there are three options I think. a) Expose this in networkd .netdev files, as I suggested originally. This would be appropriate if we can add and remove VFs freely any time, without the other VFs being affected. Can you clarify whether going from let's say 4 to 5 VFs requires removing all VFs and recreating them? THis would be the nicest exposure I think, but be specific to networkd. Removing and recreating the VFs is unfortunately required when changing the number of them (both ways - increasing and decreasing their count). https://www.kernel.org/doc/Documentation/PCI/pci-iov-howto.txt b) Expose this via udev .link files. This would be appropriate if adding/removing VFs is a one-time thing, when a device pops up. This would be networking specific, not cover anything else like GPU or storage or so. Would still be quite nice. Would probably the best option, after a), if VFs cannot be added/removed dynamically all the time without affecting the other VFs. c) Expose this via udev rules files. This would be generic, would work for networking as well as GPUs or storage. This would entail writing our rules files when you want to configure the number of VFs. Care needs to be taken to use the right way to identify devices as they come and go, so that you can apply configuration to them in a stable way. This is somewhat uglier, as we don't really think that udev rules should be used that much for configuration, especially not for configuration written out by programs, rather than manually. However, logind already does this, to assign seat identifiers to udev devices to enable multi-seat support. A combination of b) for networking and c) for the rest might be an option too. I myself would vote for b) + c) since we want to cover most of the possible use cases for SR-IOV and MR-IOV, which hopefully shares the interface; adding Dan back to CC as he is the one to speak for network. 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] logind vs CAP_SYS_ADMIN-lessness
On Tue, 27.01.15 10:53, Christian Seiler (christ...@iwakd.de) wrote: LXC predates systemd by about 2 years. (And at the very beginning, systemd didn't support containers out of the box, so it predates systemd's container support by even more.) And at that time, doing that was a way to sysvinit containers with no or minimal modification to /etc/inittab. So instead of saying that LXC breaks systemd's assumptions, you could also say systemd breaks LXC's assumptions. As I said: bubbles. ;-) Well, LXC breaks everbody's assumptions, not just systemd's. /dev/tty[1-6] refers to the VT, and TERM=linux is the right $TERM for it. However, if you actually have a pty and an xterm behind it then these settings will be incorrect for a ton of programs. Now I'm not going to argue with you that the method of doing $container_ttys= isn't vastly superior to what was there previously, because it is. So I don't disagree with the long-term solution at all. Note that $container_ttys= is actually just a frontend for dynamically instantiating console-getty@.service instances for the specified ptys. You can just enable them statically too. (And 'machinectl login' actually even instantiateds them during runtime to allow dynamic logins to an local container that registers with it...) But LXC 1.0 just doesn't support this yet, so the question is what to do in the mean time. If I do what I described: - logind can't open /dev/tty0, so all VT management in there is disabled anyway - within systemd: vt_disallocate can't open /dev/tty0, so it just returns an error, but that error code is never checked in core/execute.c, so it just behaves as if the directive never had been there - getty@.service statically enabled just runs agetty, so really only $TERM is wrong Well, it's also conditionalized to /dev/tty0. Instead of patching the unit file you could as well just instantiate container-getty@.service in /etc, get the right $TERM and be done with it. Speaking of, isn't there a bug in container-getty@.service?[*] It uses ConditionPathExists=/dev/pts/%I, starts agetty on pts/%I but sets TTYPath=/dev/%I instead of /dev/pts/%I... And having the utmp specifier be just a number (%I) instead of pts/%I is also probably weird. True, and true! Thanks for the pointer. Fixed in git! Fair enough[#], but did you receive my patches for the part about skipping on missing perms? Yes, I have a huge backlog of unprocessed mail, and am currently wading through it backwards in time. Sorry for the delay! 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] Unwants
On 27 January 2015 at 12:38, Lennart Poettering lenn...@poettering.net wrote: On Thu, 22.01.15 14:08, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: In any case, /etc overrides /run, so your example can never work. Oh, ok. But any combination of the two. E.g. for /etc to unwant from /run then, or for /etc to unwant from /usr. At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it I am not grokking this. If you remove the package with the symlinks in /usr, then den deps are gone, so why do you need something in /etc or /run still? For the case when one cannot remove the package at runtime (i.e. /usr is read only) or there is no mechanism to remove packages at all (no package manager). -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persisting sriov_numvfs
On 01/27/2015 12:40 PM, Tom Gundersen wrote: Hi Dan, On Mon, Jan 19, 2015 at 3:18 PM, Dan Kenigsberg dan...@redhat.com wrote: I'm an http://oVirt.org developer, and we plan to (finally) support SR-IOV cards natively. Working on this feature, we've noticed that something is missing in the platform OS. If I maintain a host with sr-iov cards, I'd like to use the new kernel method of defining how many virtual functions (VFs) are to be exposed by each physical function: # echo 3 /sys/class/net/enp2s0f0/device/sriov_numvfs This spawns 3 new devices, for which udev allocated (on my host) the names enp2s16, enp2s16f2 and enp2s16f4. I can attach these VFs to virtual machines, but I can also use them as yet another host NIC. Let's assume that I did the latter, and persisted its IP address using initscripts in /etc/sysconfig/network-scripts/ifcfg-enp2s16f4. However, on the next boot, sriov_numvfs is reset to 0, there's no device named enp2s16f4, and certainly no IP address asigned to it. The admin can solve his own private issue by writing a service to start after udev allocats device names but before network services kick in, and re-apply his echo there. But it feels like something that should be solved in a more generic fashion. It is also not limitted to network device. As similar issue would affect anything that attempts to refer to a VF by its name, and survive reboot. How should this be implemented in the realm of systemd? Sorry for the delay in getting back to you. My understanding is that the number of vfs must be basically set once and not changed after that? It seems that it is possible to change it, but only at the cost of removing all of them first, which I guess is not really an option in case they are in use. Enabling this stuff via module parameter manually or via .conf file has been deprecate and users are encourage to use the pci sysfs interface instead. If that is the case, and what you essentially want is to just override the kernel default (0 VFs), then I think we can add a feature to udev's .link files to handle this. This means the VFs will be allocated very early during boot, as soon as the PF appears. On the downside, there is no mechanism to nicely update this setting during run-time (which may not be a problem if that is not really supported anyway), you would have to reinsert the PF or reboot the machine for the .link file to be applied. You can create number of VF to the cards maximum per PF via| |# echo number /sys/bus/pci/devices/\:01\:00.0/sriov_numvfs # echo number /sys/bus/pci/devices/\:01\:00.1/sriov_numvfs ... etc. ( these should be able to be matched in link files via Path as in Path=pci-:01:00.0-* for the above sample right ? ) Then you can tweak the VF settings To set the vNIC MAC address on the Virtual Function # ip link set pf vf vf_index mac vnic_mac # ip link set em1 vf 0 mac 00:52:44:11:22:33 It's common to set fixed mac address instead of randomly generated ones via bash script at startup To turn HW packet source mac spoof check on or off for the specified VF # ip link set pf vf vf_index spoofchk on|off # ip link set em1 vf 0 spoofchk on Change the link state as seen by the VF # ip link set pf vf vf_index state auto|enable|disable # ip link set em1 vf 0 state disabled To set a VLAN and priority on Virtual Function # ip link set dev down # ip link set pf vf vf_index vlan vlan id qos priority # ip link set dev up Here for example is em1 is the PF (physical function) , em2 is the interface assigned to VF 0. # ip link set em2 down # ip link set em1 vf 0 vlan 2 qos 2 # ip link set em2 up If someone ships you those cards you can verify configuration use ip link show command like so # ip link show dev em1 And it's output be something like this 7: em1: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:02:c9:e6:01:12 brd ff:ff:ff:ff:ff:ff vf 0 MAC mac, vlan id, spoof checking off, link-state auto vf 1 MAC mac, vlan id, spoof checking on, link-state enable vf 2 MAC mac, vlan id, spoof checking off, link-state disable etc... Moreover, .link files are specific to network devices, so this will not help you with other kinds of PFs. I think that may be ok, depending on how common it is to use this for non-network hardware. If that is a niche usecase, it will always be possible to write an udev rule to achieve the same result as the .link file (for any kind of hardware), it is just a bit more cumbersome. If I'm not mistaken some of those cards can support for example infiniband,fc and etherenet at the same time ( which used to be configured when the module was loaded ) But what's missing from link files here? set the number of VF ? ( Note the maximum number of VFs that you can create and the maximum number of VFs that you can use for passthrough can be different.) That said it's probably best to get the Intel guys on board on this since a) Intel
Re: [systemd-devel] [PATCH v2 1/2] systemd.unit(5): add examples for common tasks
On Tue, 27.01.15 17:45, Christian Seiler (christ...@iwakd.de) wrote: Add examples for (a) making units enableable and (b) overriding vendor settings to the man page. I am not a native english speaker, but I am not sure there's a word like enableable in the english language. Maybe rephrase this as allowing units to be enabled? +linking to the actual unit will be created. It +tells systemd to pull in the unit when starting +filenamemulti-user.target/filename. The +converse commandsystemctl disable/command +will remove that symlink again./para +/example converse? shouldn't it be reverse or inverse? +programlisting[Unit] +Description=Some HTTP server +After=network.target remote-fs.target sqldb.service Given the fact that network.target is so vaguely defined, and not even necessary in most cases, I'd really suggest removing this bit fromt the After= line. +[Service] +Type=notify +ExecStart=/usr/sbin/some-fancy-httpd-server +TimeoutStartSec=5 I think the default timeout should be fine. THere's usually no good reason to change it. +paraThe first possibility is to copy the unit +file to + filename/etc/systemd/system/httpd.service/filename +and change the chosen settings:/para + +programlisting[Unit] +Description=Some HTTP server +After=network.target remote-fs.target sqldb.service emphasismemcached.service/emphasis +Requires=sqldb.service emphasismemcached.service/emphasis +ConditionPathExists=emphasis/srv/www/emphasis I wonder if the example should better use AssertionXYZ rather than ConditionXYZ for this? Looks great otherwise! 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] libudev-monitor: ensure proper string termination
On 01/27/15 00:19, Lennart Poettering wrote:
On Sun, 25.01.15 07:10, Topi Miettinen (toiwo...@gmail.com) wrote:
On 01/25/15 03:34, Zbigniew Jędrzejewski-Szmek wrote:
On Sat, Jan 24, 2015 at 10:39:56AM +0200, Topi Miettinen wrote:
Leave space for the terminating zero when reading and make sure
that the last byte is zero. This also makes the check for long packets
equivalent to code before 9c89c1ca: reject also packets with size 8192.
---
src/libudev/libudev-monitor.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
index 4cfb2f6..b7fc031 100644
--- a/src/libudev/libudev-monitor.c
+++ b/src/libudev/libudev-monitor.c
@@ -590,7 +590,7 @@ retry:
if (udev_monitor == NULL)
return NULL;
iov.iov_base = buf;
-iov.iov_len = sizeof(buf);
+iov.iov_len = sizeof(buf) - 1; /* Leave space for terminating
zero */
memzero(smsg, sizeof(struct msghdr));
smsg.msg_iov = iov;
smsg.msg_iovlen = 1;
@@ -642,6 +642,8 @@ retry:
if (udev_device == NULL)
return NULL;
+buf.raw[sizeof(buf.raw) - 1] = '\0';
+
if (memcmp(buf.raw, libudev, 8) == 0) {
/* udev message needs proper version magic */
if (buf.nlh.magic != htonl(UDEV_MONITOR_MAGIC)) {
A buffer only needs to be terminated by a zero in certain cases: usually if
it
is passed to a function which expectes that. iovecs can contain binary data,
and have an explicit size field, so they do not need to be zero-terminated.
Is there a reason why the buffer has to be zero-terminated in this case?
String functions strcmp, strlen and strstr, used a few lines later,
expect null byte terminated strings. Alternatively they could be changed
to strncmp and friends where the scope can be limited to only the buffer.
But the data comes from the kernel (and that's verified, securely),
hence I am wondering what kind of vulnerability you have precisely in
mind. If we don't trust the kernel, then we'll have quite a problem...
Right, I didn't look at the context. In that case, this would be just
defensive programming.
-Topi
Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timesyncd: tighten unit file
On 01/27/15 01:54, Lennart Poettering wrote: On Sun, 25.01.15 12:23, Topi Miettinen (toiwo...@gmail.com) wrote: There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER. Hmm, that's not true, is it? load_clock_timestamp() is invoked before we drop privs in the daemon. And it certainly calls fchmod() and fchown(), so that it can later on still access the clock touch file. What am I missing? It works for me because the file exists already with correct owner and permissions. I'd put CAP_CHOWN and CAP_FOWNER back for now. Maybe the clock file could reside in a separate subdirectory, then the directory owner and permissions could be set up already at installation? No new privileges are needed, especially no setuid fixups are expected. Yeah, we should probably set this for most of our daemons, not just timesyncd. I am not entirely sure how NoNewPrivileges= and no-setuid-fixup actually relate to each other. I.e. what does one do that the other doesn't? And if they do different things, isn't NoNewPrivileges= kinda a superset of no-setuid-fixup, and thus makes setting the latter redundant? I think NoNewPrivileges (prctl(PR_SET_NO_NEW_PRIVS)) prevents any kind of uid/gid changes, while no-setuid-fixup does not restrict uid change but does not elevate the capability set. Reading through Documentation/prctl/no_new_privs.txt in the kernel sources I found this paragraph: Be careful, though: LSMs might also not tighten constraints on exec in no_new_privs mode. (This means that setting up a general-purpose service launcher to set no_new_privs before execing daemons may interfere with LSM-based sandboxing.) This kinda suggests that SELinux and friends might not like NoNewPrivileges=, hence I am not entirely sure it is really the right option for us. Hence I am wondering if no-setuid-fixup (and -locked) might be the better option for us to enable everywhere? I don't think timesyncd is executing any helper programs, especially set-uid or with file system capabilities, so both should work fine. Device policy can be closed, timesyncd does not access any devices. Note that we set PrivateDevices=yes already, which implies DevicePolicy=closed. Timesyncd only needs write access to /var/lib/systemd/clock. There's no need to access /boot nor most API filesystems. Well, /boot is already covered by ProtectSystem=full actually (but this wasn't documented, admittedly. Updated the man page now in gate.) I am a bit concerned about listing by default all these directories in the unit file. I mean, the reason why ProtectSystem=, ProtectHome= and suchlike exists is precisely to break this down to a few booleans (or boolean-like enums), instead of listing all directories in all unit files all the time. I mean, it's great if people do this on their local systems, but to make this palatable generically upstream I created ProtectSystem= and ProtectHome= to hide the directory lists away. The problem with these lists is that we need to be really conservative with them, since many of the libs we use (including glibc) use different interface behind our back, and thus writing generally valid rules, that work on all archs, on all distros, on all glibc/libary versions is hard. This is what SELinux policy does, but I *really* didn't want to create another implementation of such a finegrained policy, if you follow what I mean. I'm not sure. Shouldn't we then ship a SELinux policy file then? Would you be interested in AppArmor profile for timesyncd, I have one? Also, if a distro uses weird SELinux policies or setuid helpers at every possible opportunity, shouldn't they have some responsibility of fixing their setup? Install a system call filter, generated with 'strace -c'. Hmm, I am a bit concerned about this part, I am not sure we can really do this upstream. Different glibc and other library versions we use invoke different syscalls. Moreover, different archs use different syscalls, too. This makes it really difficult putting together syscall filters upsteram that work generically, on all downstream versions. I think SystemCallFilter= is something that end-users can use on their systems, but I am not sure we can use this upstream. :-( Right, this was generated on x86_64. Only one additional process is needed. Hmm, LimitNPROC=2 unfortunately doesn't do what we want it to do: since the daemon drops the to the systemd-timesync user on its own, PID 1 invokes it as root, not as the the systemd-timesync user, which makes the excercise pointless... We should probably handle this better though, and warn, instead of silently accepting it. Added that to the TODO list now. This probably applies to other limits too? I have now changed the timesyncd code to do the right thing on its own after dropping privs. During runtime RLIMIT_NPROC=2 should now be set. Mounts should not propagate back, so set the
Re: [systemd-devel] PrivateDevices with more than basic set of devices?
On 01/26/15 23:46, Lennart Poettering wrote: But independently of the PrivateDevices thing, would you think tmpfiles.d could be extended to be usable for unit specific cases instead of just one global setup? I think there could be more uses, for example, creating directories and links inside a unit's RuntimeDirectory. I am not sure how this could work and what kind of integration you precisely are looking for there? Note that tmpfiles exists mostly for two reasons: a) to deal with old software that wasn't capable of creating its own subdirs/stuff below its runtime directory; and b) to deal with software whose main program was running unpriviliged all the time (for example by using User=), and hence lacked the priviliges to set up its subdir in /run. a) was exactly my case, auditd doesn't have a way to specify where to put the pid file yet, so it ends up in /run/auditd.pid. Now, to deal with case b) we nowadays have RuntimeDirectory=. And for a) I think the long story must be to make it set up its own stuff in /run, and I don#t see how tmpfiles could break any benefit there... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - TODO configure.ac man/systemd.link.xml units/container-ge...@.service.m4.in units/systemd-resolved.service.in
On Tue, Jan 27, 2015 at 09:30:16AM -0800, Lennart Poettering wrote: TODO |6 +- configure.ac |8 +--- man/systemd.link.xml | 16 +++- units/container-ge...@.service.m4.in |4 ++-- units/systemd-resolved.service.in|1 + 5 files changed, 24 insertions(+), 11 deletions(-) New commits: commit e611755d98ac6b213f39426359c3a94defc6a029 Author: Lennart Poettering lenn...@poettering.net Date: Tue Jan 27 18:29:33 2015 +0100 man: mention that 99-default.link is shipped by default, and users hence need to install a lexically earlier .link file for it to be honoured What's up with those commit subjects getting longer and longer? It's hard to read, especially when skimming a long list of commit subjects, and our tools don't really support this: gitk, file names generated by git format patch, cia, git log in a non-terribly-wide window... Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 1/2] systemd.unit(5): add examples for common tasks
On Tue, 27.01.15 19:26, Christian Seiler (christ...@iwakd.de) wrote: I know, but I wanted to have something that was easily understandable at first glance that was already set in the original unit that would then be overridden. I'll use Nice= instead, that's more likely to be used. Yeah, sounds like the better option. +paraThe first possibility is to copy the unit +file to + filename/etc/systemd/system/httpd.service/filename +and change the chosen settings:/para + +programlisting[Unit] +Description=Some HTTP server +After=network.target remote-fs.target sqldb.service emphasismemcached.service/emphasis +Requires=sqldb.service emphasismemcached.service/emphasis +ConditionPathExists=emphasis/srv/www/emphasis I wonder if the example should better use AssertionXYZ rather than ConditionXYZ for this? A right, that's new, I'll use that instead. Will send second patch after your response to my question. Uh, which question are you precisely referring to? 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 v2 1/2] systemd.unit(5): add examples for common tasks
Am 27.01.2015 um 19:12 schrieb Lennart Poettering: On Tue, 27.01.15 17:45, Christian Seiler (christ...@iwakd.de) wrote: Add examples for (a) making units enableable and (b) overriding vendor settings to the man page. I am not a native english speaker, but I am not sure there's a word like enableable in the english language. Maybe rephrase this as allowing units to be enabled? Drat. I've read that in technical contexts often enough, and for safety I typed it into google. There were enough results there to make me think 'oh, ok, it's a real word'. A quick look in a dictionary disagrees with that assessment. Oh well. (Although the urban dictionary does have that word, but my guess is you won't accept that as a canonical source for the English language. ;-)) I'll change it. +linking to the actual unit will be created. It +tells systemd to pull in the unit when starting +filenamemulti-user.target/filename. The +converse commandsystemctl disable/command +will remove that symlink again./para +/example converse? shouldn't it be reverse or inverse? Hmm, converse was the first word that popped into my head, but inverse is probably better, yes. +programlisting[Unit] +Description=Some HTTP server +After=network.target remote-fs.target sqldb.service Given the fact that network.target is so vaguely defined, and not even necessary in most cases, I'd really suggest removing this bit fromt the After= line. Ok. +[Service] +Type=notify +ExecStart=/usr/sbin/some-fancy-httpd-server +TimeoutStartSec=5 I think the default timeout should be fine. THere's usually no good reason to change it. I know, but I wanted to have something that was easily understandable at first glance that was already set in the original unit that would then be overridden. I'll use Nice= instead, that's more likely to be used. +paraThe first possibility is to copy the unit +file to + filename/etc/systemd/system/httpd.service/filename +and change the chosen settings:/para + +programlisting[Unit] +Description=Some HTTP server +After=network.target remote-fs.target sqldb.service emphasismemcached.service/emphasis +Requires=sqldb.service emphasismemcached.service/emphasis +ConditionPathExists=emphasis/srv/www/emphasis I wonder if the example should better use AssertionXYZ rather than ConditionXYZ for this? A right, that's new, I'll use that instead. Will send second patch after your response to my question. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] logind: chown+chmod /run/user/$UID if mount(tmpfs) fails with EPERM
Am 27.01.2015 um 19:02 schrieb Lennart Poettering: Merged this one too, made some changes first howver. I reworked this to use our chmod_and_chown() helper, and removed the bit that checks whether the mount point actually was a mount point after umount2(). I really prefer if we can just check the return value of the syscall and decide on that. Looks much nicer, yes. Please check if this all works for you now! Yes, works for me, directory gets created, chown/chmod is applied, XDG_RUNTIME_DIR is set and loginctl shows the session. Thanks! Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] systemd.unit(5): add examples for common tasks
Am 27.01.2015 um 19:32 schrieb Lennart Poettering: On Tue, 27.01.15 19:26, Christian Seiler (christ...@iwakd.de) wrote: Will send second patch after your response to my question. Uh, which question are you precisely referring to? Forget it, I answered that question myself and forgot to edit out the last sentence of my mail. ;-) I've attached git format-patch's output for the revised manpage. Christian From 4d251d71bfa5eb19a7d14392d34357e0e3e859cc Mon Sep 17 00:00:00 2001 From: Christian Seiler christ...@iwakd.de Date: Sat, 24 Jan 2015 14:04:03 +0100 Subject: [PATCH] systemd.unit(5): add examples for common tasks Add examples for (a) how to allow units to be enabled and (b) overriding vendor settings to the man page. --- man/systemd.unit.xml | 165 +++ 1 file changed, 165 insertions(+) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index e820b33..9704d6f 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -1574,6 +1574,171 @@ /refsect1 refsect1 +titleExamples/title + +example +titleAllowing units to be enabled/title + +paraThe following snippet (highlighted) +allows a unit (e.g. +filenamefoo.service/filename) to be +enabled via +commandsystemctl enable/command:/para + +programlisting[Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +emphasis[Install]/emphasis +emphasisWantedBy=multi-user.target/emphasis/programlisting + +paraAfter running +commandsystemctl enable/command, a symlink +filename/etc/systemd/system/multi-user.target.wants/foo.service/filename +linking to the actual unit will be created. It +tells systemd to pull in the unit when starting +filenamemulti-user.target/filename. The +inverse commandsystemctl disable/command +will remove that symlink again./para +/example + +example +titleOverriding vendor settings/title + +paraThere are two methods of overriding +vendor settings in unit files: copying the unit +file from +filename/usr/lib/systemd/system/filename +to filename/etc/systemd/system/filename and +modifying the chosen settings. Alternatively, +one can create a directory named +filenamereplaceableunit/replaceable.d//filename +within +filename/etc/systemd/system/filename and +place a drop-in file +filenamereplaceablename/replaceable.conf/filename +there that only changes the specific settings +one is interested in. Note that multiple such +drop-in files are read if present./para + +paraThe advantage of the first method is +that one easily overrides the complete unit, +the vendor unit is not parsed at all anymore. +It has the disadvantage that improvements to +the unit file by the vendor are not +automatically incorporated on updates./para + +paraThe advantage of the second method is +that one only overrides the settings one +specifically wants, where updates to the unit +by the vendor automatically apply. This has the +disadvantage that some future updates by the +vendor might be incompatible with the local +changes./para + +paraNote that for drop-in files, if one wants +to remove entries from a setting that is parsed +as a list (and is not a dependency), such as +varnameConditionPathExists=/varname (or +e.g. varnameExecStart=/varname in service +units), one needs to first clear the list +before re-adding all entries except the one +that is to be removed. See below for an +example./para + +paraThis also applies for user instances of +systemd, but with different locations for the +unit files. See the section on unit load paths +for further details./para + +
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
Hi Alin, Thanks for working on this. I think the main concepts here make sense, but I have some comments on the implementation. So the main ideas are: 1) a notion of groups of links 2) a notion of up- and downlinks 3) configuring downlinks if and only if at least one uplink in the group has a carrier Comments: Maybe we should not restrict the naming to UFD, as the grouping may be useful for other things in the future (would be great if you could comment on Holger's email for instance). In fact Lennart suggested we introduce the concept of 'tags' instead of groups, and these will be similar to tags in udev rules. I.e., introduce a new directive called Tag= in .network files, and this could then be used for different things in the future. I don't think we should introduce a netdev kind for groups, as this really does not correspond to a netdev in the kernel. And I don't think we should list the ifnames in the configuration of the groups, but rather configure the group name in the .network file (see how bonding and bridging currently works). It looks to me that we don't even need (yet) configuration files for the groups, they can just be made implicitly from their name as given in .network files. Using the idea of Tags should give you this. If possible we should not wait for all links to appear before handling a group, but be tolerant to not knowing upfront precisely which links will be on a system. It looks to me that this shouldn't be a problem, but maybe I missed something? Also here see how bridging and bonding currently works. Could you comment a bit on how you decide when an uplink should be considered failed? Is it jut when it does not have a carrier? Is this the end of the story, or do you imagine extending this with other notions in the future? Lastly, Lennart also pointed out that there is not really a need for grouping the downlinks, only the uplinks. We could then simply have a new directive BindToCarrier= which is set in downlinks and which takes a list of tags, meaning that this link will only be configured once at least one tag has a link with a carrier. What do you think? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - TODO configure.ac man/systemd.link.xml units/container-ge...@.service.m4.in units/systemd-resolved.service.in
On Tue, 27.01.15 19:14, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Jan 27, 2015 at 09:30:16AM -0800, Lennart Poettering wrote: TODO |6 +- configure.ac |8 +--- man/systemd.link.xml | 16 +++- units/container-ge...@.service.m4.in |4 ++-- units/systemd-resolved.service.in|1 + 5 files changed, 24 insertions(+), 11 deletions(-) New commits: commit e611755d98ac6b213f39426359c3a94defc6a029 Author: Lennart Poettering lenn...@poettering.net Date: Tue Jan 27 18:29:33 2015 +0100 man: mention that 99-default.link is shipped by default, and users hence need to install a lexically earlier .link file for it to be honoured What's up with those commit subjects getting longer and longer? It's hard to read, especially when skimming a long list of commit subjects, and our tools don't really support this: gitk, file names generated by git format patch, cia, git log in a non-terribly-wide window... Well, gitk reveals the full commit subject when i click on the item. I mean, that's not worse then if I'd shorten the subject and put the rest in the body, right? you'd have to click on the thing, to see it in full.. In general I believe that we don't live in times of 80ch terminals anymore. Our coding style doesn't suggest breaking lines that early, and I don't think we should do that either for git commits. That said, I'll try to keep it shorter, 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] PrivateDevices with more than basic set of devices?
On 01/26/15 21:04, Lennart Poettering wrote: On Mon, 26.01.15 17:07, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 12:41, Simon McVittie wrote: On 24/01/15 10:09, Topi Miettinen wrote: For example, smartd only needs access to /dev/sd*. Let me spell that differently: smartd only needs the ability to make arbitrary filesystem changes, defeating any possible configurable security mechanism. Not exactly: it only needs read access. Depending on the system, that could be very different from being able to make arbitrary filesystem changes. Sending SMART requests requires the same priviliges as issue direct low-level write requests to my knowledge, hence I'd say simon is right. CAP_SYS_RAWIO, yes. Only read access is needed otherwise: DevicePolicy=closed DeviceAllow=block-sd r DeviceAllow=/dev/sda r DeviceAllow=/dev/sdb r works fine here. Probably CAP_SYS_RAWIO can be used to circumvent the lack of write access, though. -Topi Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness
On a general note: the stuff I mentioned that I did to modify the
container was just taken from the lxc-debian template that comes with
LXC 1.0, and I didn't have time to look at it thoroughly to see what's
actually needed there. The stuff I mentioned was more along the lines of
'what I did to get where I was if somebody wanted to reproduce it'
instead of 'I recommend doing that'.
Am 27.01.2015 um 03:08 schrieb Lennart Poettering:
- explicitly enable getty@tty{1,2,3,4}.service
Why?
Ah, it's nice to see we all live in our own bubbles. :-)
LXC predates systemd by about 2 years. (And at the very beginning,
systemd didn't support containers out of the box, so it predates
systemd's container support by even more.) And at that time, doing that
was a way to sysvinit containers with no or minimal modification to
/etc/inittab. So instead of saying that LXC breaks systemd's
assumptions, you could also say systemd breaks LXC's assumptions. As I
said: bubbles. ;-)
Now I'm not going to argue with you that the method of doing
$container_ttys= isn't vastly superior to what was there previously,
because it is. So I don't disagree with the long-term solution at all.
But LXC 1.0 just doesn't support this yet, so the question is what to do
in the mean time. If I do what I described:
- logind can't open /dev/tty0, so all VT management in there is
disabled anyway
- within systemd: vt_disallocate can't open /dev/tty0, so it just
returns an error, but that error code is never checked in
core/execute.c, so it just behaves as if the directive never had
been there
- getty@.service statically enabled just runs agetty, so really only
$TERM is wrong
- but that was wrong already with sysvinit containers, and I never had
any major issues because of that
So yeah, it's not pretty, it shouldn't stay in the long run, I
completely agree with your reasoning why you don't like it, but
currently it does seem to 'work'.
That being the case, thinking about it, I actually don't use this
feature myself (with kernels = 3.12 or so, lxc-attach works quite well,
so I never actually had the need to use a console to log in to a
container, for normal purposes I use SSH anyway), so maybe I'm just
going to deactivate the whole thing in my local config anyway.
Speaking of, isn't there a bug in container-getty@.service?[*] It uses
ConditionPathExists=/dev/pts/%I, starts agetty on pts/%I but sets
TTYPath=/dev/%I instead of /dev/pts/%I... And having the utmp specifier
be just a number (%I) instead of pts/%I is also probably weird.
[*]
http://cgit.freedesktop.org/systemd/systemd/tree/units/container-ge...@.service.m4.in
- mask systemd-udevd.service (haven't tested if that's actually needed,
the lxc-debian template also does this however)
There's no point in doing that. udev uses
ConditionPathIsReadWrite=/sys anyway, and is automatically skipped
hence when /sys is read-only.
Ah, good point, so it is in fact not needed. No idea why that's in there
then. Perhaps from a historic attempt when systemd didn't have that
Condition in there?
- touch /etc/fstab if you debootstrap it directly
You can just remove it. You don't need it in containers (and not even
on most hosts, unless you actually need to refer to external
partitions that cannot be auto-configured.
Ah, indeed, just tried it. Interesting, why did I write that? No idea...
I am tempted to just
change nspawn to mount a private tmpfs into /run/user, too, as it
already mounts /run anyway.
That would solve /run-quota issues for CAP_SYS_ADMIN-less containers,
but is unnecessary (although harmless) for those that do have it.
I decided against doing this after all. [...] Hence, we either do
something (possibly skipping it it on missing perms) or, we don't do
it at all, [...]
Fair enough[#], but did you receive my patches for the part about
skipping on missing perms?
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027343.html
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027344.html
[#] One could probably always do --tmpfs=/run/lock:options with nspawn
anyway, if one wants to explicitly do this.
Christian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation
Hey Lennart, Lennart Poettering [2015-01-27 0:55 +0100]: Hmm? I don't see how mount propagation would break 60-cdrom_id... The eject ioctl operates on the device node, and does not care for mounts. This problem sounds made-up to me. Right now cdrom_id indeed wouldn't be affected as it doesn't unmount a CD which is about to ejected. That's the very problem that was recently discussed here: http://lists.freedesktop.org/archives/systemd-devel/2015-January/026948.html The two proposed solutions were to either teach cdrom_id --eject to umount the device or just call the actual eject program which gets this pretty much right. But neither would work because of the unshared mount ns in udev. Moreover, if you want to do mounts or umounts on plug or play, then use a proper daemon, like udisks. udisks actually used to have both the CD-ROM polling (which since then moved into the kernel) and the post-eject cleanup. If we want to keep the udev mount unsharing, we could put it back into udisks; but that wouldn't be that robust as udisks isn't guaranteed to actually run, both because it's a D-BUS activated service and a lot of server-ish machines or lightweight desktops don't even have it. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemd.unit(5): add examples for common tasks
On Tue, 27.01.15 19:44, Christian Seiler (christ...@iwakd.de) wrote: Am 27.01.2015 um 19:32 schrieb Lennart Poettering: On Tue, 27.01.15 19:26, Christian Seiler (christ...@iwakd.de) wrote: Will send second patch after your response to my question. Uh, which question are you precisely referring to? Forget it, I answered that question myself and forgot to edit out the last sentence of my mail. ;-) I've attached git format-patch's output for the revised manpage. Thanks! Applied! 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] Added UFD (Uplink failure detection) support to networkd
On Tue, 27.01.15 19:54, Tom Gundersen (t...@jklm.no) wrote: Hi Alin, Thanks for working on this. I think the main concepts here make sense, but I have some comments on the implementation. So the main ideas are: 1) a notion of groups of links 2) a notion of up- and downlinks 3) configuring downlinks if and only if at least one uplink in the group has a carrier Comments: Maybe we should not restrict the naming to UFD, as the grouping may be useful for other things in the future (would be great if you could comment on Holger's email for instance). In fact Lennart suggested we introduce the concept of 'tags' instead of groups, and these will be similar to tags in udev rules. Taking this one step further we could even simplify further: maybe the entire concept of tags our groups is unnecessary. Instead, let's just introduce a single new setting: BindCarrier= Which takes a list of interface names, and supports globbing. Now, with this functionality in place, and a good naming regime we could implement such uplink/download behaviour too, right? I mean, let's say you name all your uplink interfaces uplink0, uplink1, uplink2, and your downlink interfaces downlink0, downlink1, and so on. Now, in the .network file for the downlink, we'd simply say BindCarrier=uplink*, which would then mean that the port is only configured if at least one interface matching that name, with a carrier is found. Alin, wouldn't this be sufficient for you? I kinda prefer this solution due to its simplicity, and as it does not introduce any new concepts, and only a single new setting... 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] PrivateDevices with more than basic set of devices?
On 01/27/15 20:52, Lennart Poettering wrote: On Tue, 27.01.15 18:51, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 21:04, Lennart Poettering wrote: On Mon, 26.01.15 17:07, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 12:41, Simon McVittie wrote: On 24/01/15 10:09, Topi Miettinen wrote: For example, smartd only needs access to /dev/sd*. Let me spell that differently: smartd only needs the ability to make arbitrary filesystem changes, defeating any possible configurable security mechanism. Not exactly: it only needs read access. Depending on the system, that could be very different from being able to make arbitrary filesystem changes. Sending SMART requests requires the same priviliges as issue direct low-level write requests to my knowledge, hence I'd say simon is right. CAP_SYS_RAWIO, yes. Only read access is needed otherwise: DevicePolicy=closed DeviceAllow=block-sd r DeviceAllow=/dev/sda r DeviceAllow=/dev/sdb r works fine here. You should be able to reduce this to simply: DeviceAllow=block-sd r This should suffic since DevicePolicy=closed is implied if there's at least one DeviceAllow= specified. And DeviceAllow=block-sd r enables access to all /dev/sd* access, which includes /dev/sda and /dev/sdb, of course. In general yes, but I didn't want to allow SMART requests to /dev/sdc, it's a DVD-ROM drive and there are useless errors if accessed with SMART. Probably CAP_SYS_RAWIO can be used to circumvent the lack of write access, though. Yes, it can. I think in general though that sandboxing should be done even if there are ways to circumvent it. It might still protects from accidental mishaps even if it doesn't prevent attackers to exploit things. That said, as mentioned in my earlier mail smartd will probably not be happy with accessing only /dev/sd*, it wants access to all kinds of other devices. For example it has special support for certain SCSI RAID drivers and such, which are not accessed via /dev/sd*... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateDevices with more than basic set of devices?
On 01/27/15 21:40, Lennart Poettering wrote: On Tue, 27.01.15 21:38, Topi Miettinen (toiwo...@gmail.com) wrote: CAP_SYS_RAWIO, yes. Only read access is needed otherwise: DevicePolicy=closed DeviceAllow=block-sd r DeviceAllow=/dev/sda r DeviceAllow=/dev/sdb r works fine here. You should be able to reduce this to simply: DeviceAllow=block-sd r This should suffic since DevicePolicy=closed is implied if there's at least one DeviceAllow= specified. And DeviceAllow=block-sd r enables access to all /dev/sd* access, which includes /dev/sda and /dev/sdb, of course. In general yes, but I didn't want to allow SMART requests to /dev/sdc, it's a DVD-ROM drive and there are useless errors if accessed with SMART. Well, don't you just get a different error then? Embarrassingly it looks like I actually fixed the error by editing smartd.conf and not with the unit file... -Topi That said, if this is really what you want, then you should really remove the DeviceAllow=block-sd r line, since that opens up access to /dev/sdc, too... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PrivateDevices with more than basic set of devices?
On Tue, 27.01.15 19:04, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 23:46, Lennart Poettering wrote: But independently of the PrivateDevices thing, would you think tmpfiles.d could be extended to be usable for unit specific cases instead of just one global setup? I think there could be more uses, for example, creating directories and links inside a unit's RuntimeDirectory. I am not sure how this could work and what kind of integration you precisely are looking for there? Note that tmpfiles exists mostly for two reasons: a) to deal with old software that wasn't capable of creating its own subdirs/stuff below its runtime directory; and b) to deal with software whose main program was running unpriviliged all the time (for example by using User=), and hence lacked the priviliges to set up its subdir in /run. a) was exactly my case, auditd doesn't have a way to specify where to put the pid file yet, so it ends up in /run/auditd.pid. Hmm, but that's fine, no? What would you put in tmpfiles for auditd? 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] PrivateDevices with more than basic set of devices?
On 01/27/15 20:48, Lennart Poettering wrote: On Tue, 27.01.15 19:04, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 23:46, Lennart Poettering wrote: But independently of the PrivateDevices thing, would you think tmpfiles.d could be extended to be usable for unit specific cases instead of just one global setup? I think there could be more uses, for example, creating directories and links inside a unit's RuntimeDirectory. I am not sure how this could work and what kind of integration you precisely are looking for there? Note that tmpfiles exists mostly for two reasons: a) to deal with old software that wasn't capable of creating its own subdirs/stuff below its runtime directory; and b) to deal with software whose main program was running unpriviliged all the time (for example by using User=), and hence lacked the priviliges to set up its subdir in /run. a) was exactly my case, auditd doesn't have a way to specify where to put the pid file yet, so it ends up in /run/auditd.pid. Hmm, but that's fine, no? What would you put in tmpfiles for auditd? I'd want it to put the pid file somewhere else, like RuntimeDirectory. L/run/auditd.pid ---- /run/auditd/auditd.pid This is probably a bad example as pid files could be deleted by the daemon at exit. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Tue, 27.01.15 15:45, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Hmm, I am open to allowing to override the symlinks with symlinks, if you follow what I mean. But i'd be careful with allowing to override stuff listed in Wants= in a unit file in /usr, with a symlink in a .wants/ dir in /etc, if you follow what I mean. But yeah, allowing symlinks to override symlinks makes sense, a patch for that would be good. 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] PrivateDevices with more than basic set of devices?
On Tue, 27.01.15 21:38, Topi Miettinen (toiwo...@gmail.com) wrote: CAP_SYS_RAWIO, yes. Only read access is needed otherwise: DevicePolicy=closed DeviceAllow=block-sd r DeviceAllow=/dev/sda r DeviceAllow=/dev/sdb r works fine here. You should be able to reduce this to simply: DeviceAllow=block-sd r This should suffic since DevicePolicy=closed is implied if there's at least one DeviceAllow= specified. And DeviceAllow=block-sd r enables access to all /dev/sd* access, which includes /dev/sda and /dev/sdb, of course. In general yes, but I didn't want to allow SMART requests to /dev/sdc, it's a DVD-ROM drive and there are useless errors if accessed with SMART. Well, don't you just get a different error then? That said, if this is really what you want, then you should really remove the DeviceAllow=block-sd r line, since that opens up access to /dev/sdc, too... 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] PrivateDevices with more than basic set of devices?
On Tue, 27.01.15 18:51, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 21:04, Lennart Poettering wrote: On Mon, 26.01.15 17:07, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 12:41, Simon McVittie wrote: On 24/01/15 10:09, Topi Miettinen wrote: For example, smartd only needs access to /dev/sd*. Let me spell that differently: smartd only needs the ability to make arbitrary filesystem changes, defeating any possible configurable security mechanism. Not exactly: it only needs read access. Depending on the system, that could be very different from being able to make arbitrary filesystem changes. Sending SMART requests requires the same priviliges as issue direct low-level write requests to my knowledge, hence I'd say simon is right. CAP_SYS_RAWIO, yes. Only read access is needed otherwise: DevicePolicy=closed DeviceAllow=block-sd r DeviceAllow=/dev/sda r DeviceAllow=/dev/sdb r works fine here. You should be able to reduce this to simply: DeviceAllow=block-sd r This should suffic since DevicePolicy=closed is implied if there's at least one DeviceAllow= specified. And DeviceAllow=block-sd r enables access to all /dev/sd* access, which includes /dev/sda and /dev/sdb, of course. Probably CAP_SYS_RAWIO can be used to circumvent the lack of write access, though. Yes, it can. I think in general though that sandboxing should be done even if there are ways to circumvent it. It might still protects from accidental mishaps even if it doesn't prevent attackers to exploit things. That said, as mentioned in my earlier mail smartd will probably not be happy with accessing only /dev/sd*, it wants access to all kinds of other devices. For example it has special support for certain SCSI RAID drivers and such, which are not accessed via /dev/sd*... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] systemd.service(5): add some simple examples
Am 27.01.2015 um 21:45 schrieb Lennart Poettering: On Tue, 27.01.15 17:45, Christian Seiler (christ...@iwakd.de) wrote: +paraNote that systemd assumes here that the +program will continue running in the foreground +as long as it's active. If the program I think foreground vs. background here is probably something to avoid. These are services after all, and hence kinda background in all cases. I am not sure how to explain this better though... Maybe clarify that the program does not fork on its own, and that the process systemd starts stays running until the very end of the daemon, or so. Yes, you are completely right. I've kept the use of 'background' at some places, but specifically avoided foreground, since that is really, really misleading. I've also rephrased the paragraph in question. I hope that's better. +paraNote that systemd will consider the unit +to be in the state 'starting' until the program +has terminated, so ordered dependencies will +wait for the program to finish before starting +themselves. The unit will revert to the +'inactive' state after the execution is +done. That means another request to start the +unit will perform the action again./para It might be worth also mentioning here that the the unit this way will never actually be active. It will go directly from activating to inactive, which might be surprising! Thanks for the pointer, done! Now I also mentioned something about multiple ExecStart= for oneshot units, which might be useful there. +paraSimilarly to the oneshot services, there +are sometimes units that need to execute a +program to set up something and then execute +another to shut it down, but no process remains +active while they are considered +'started'. Network configuration can sometimes +fall into this category./para Another reason to use RemainAfterExit= are services that shall not execute again and again when they are pulled in, but only the first time... Mentioned that, thanks! varnameRemainAfterExit=/varnameoptiondbus/option Typo. Should be Type=, not RemainAfterExit= *hehe* fixed. +example +titleDeferred (idle) services/title Hmm, I wonder if we maybe should remove this part. Idle services are kinda exotic, and I figure people might be tempted to misuse them. I think this might be something to document at the description of Type=, but not push people towards using this beyond that. When I started writing this, I didn't just want to copy the getty service (people can look that up anyway), so I decided to come up with something else. However, once I wrote that unit, I realized that this could have easily just been a Type=oneshot, RemainAfterExit=yes, After=multi-user.target unit and have the same effect, and be a lot more consistent with the rest of the way of doing things... Type=idle is basically really just for gettys or something extremely similar (like other interactive apps on VTs) that also get automatically restarted. Since these examples are supposed to provide a starting point for people on how to write services, I've removed the section completely, and I think this kind of special internal thing should remain in the reference documentation. v3 attached, I also fixed one or two other minor typos I noticed. Christian From ff44c16a173b36695e4844b36fbd10ac977bf4a3 Mon Sep 17 00:00:00 2001 From: Christian Seiler christ...@iwakd.de Date: Tue, 27 Jan 2015 17:38:02 +0100 Subject: [PATCH] systemd.service(5): add some simple examples Add a couple of exampels, at least one for each service type that include some explanations and pointers to various relevant options. --- man/systemd.service.xml | 296 1 file changed, 296 insertions(+) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 4c890df..f33e8df 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -1358,6 +1358,302 @@ ExecStart=/bin/echo $ONE $TWO $THREE/programlisting /refsect1 refsect1 +titleExamples/title + +example +titleSimple service/title + +paraThe following unit file creates a service +that will execute +filename/usr/sbin/foo-daemon/filename. +Since no varnameType=/varname is specified, +the default +varnameType=/varnameoptionsimple/option +will
Re: [systemd-devel] [PATCH v3] systemd.service(5): add some simple examples
On Tue, 27.01.15 22:10, Christian Seiler (christ...@iwakd.de) wrote: Thanks a ton! Applied! Am 27.01.2015 um 21:45 schrieb Lennart Poettering: On Tue, 27.01.15 17:45, Christian Seiler (christ...@iwakd.de) wrote: +paraNote that systemd assumes here that the +program will continue running in the foreground +as long as it's active. If the program I think foreground vs. background here is probably something to avoid. These are services after all, and hence kinda background in all cases. I am not sure how to explain this better though... Maybe clarify that the program does not fork on its own, and that the process systemd starts stays running until the very end of the daemon, or so. Yes, you are completely right. I've kept the use of 'background' at some places, but specifically avoided foreground, since that is really, really misleading. I've also rephrased the paragraph in question. I hope that's better. +paraNote that systemd will consider the unit +to be in the state 'starting' until the program +has terminated, so ordered dependencies will +wait for the program to finish before starting +themselves. The unit will revert to the +'inactive' state after the execution is +done. That means another request to start the +unit will perform the action again./para It might be worth also mentioning here that the the unit this way will never actually be active. It will go directly from activating to inactive, which might be surprising! Thanks for the pointer, done! Now I also mentioned something about multiple ExecStart= for oneshot units, which might be useful there. +paraSimilarly to the oneshot services, there +are sometimes units that need to execute a +program to set up something and then execute +another to shut it down, but no process remains +active while they are considered +'started'. Network configuration can sometimes +fall into this category./para Another reason to use RemainAfterExit= are services that shall not execute again and again when they are pulled in, but only the first time... Mentioned that, thanks! varnameRemainAfterExit=/varnameoptiondbus/option Typo. Should be Type=, not RemainAfterExit= *hehe* fixed. +example +titleDeferred (idle) services/title Hmm, I wonder if we maybe should remove this part. Idle services are kinda exotic, and I figure people might be tempted to misuse them. I think this might be something to document at the description of Type=, but not push people towards using this beyond that. When I started writing this, I didn't just want to copy the getty service (people can look that up anyway), so I decided to come up with something else. However, once I wrote that unit, I realized that this could have easily just been a Type=oneshot, RemainAfterExit=yes, After=multi-user.target unit and have the same effect, and be a lot more consistent with the rest of the way of doing things... Type=idle is basically really just for gettys or something extremely similar (like other interactive apps on VTs) that also get automatically restarted. Since these examples are supposed to provide a starting point for people on how to write services, I've removed the section completely, and I think this kind of special internal thing should remain in the reference documentation. v3 attached, I also fixed one or two other minor typos I noticed. Christian From ff44c16a173b36695e4844b36fbd10ac977bf4a3 Mon Sep 17 00:00:00 2001 From: Christian Seiler christ...@iwakd.de Date: Tue, 27 Jan 2015 17:38:02 +0100 Subject: [PATCH] systemd.service(5): add some simple examples Add a couple of exampels, at least one for each service type that include some explanations and pointers to various relevant options. --- man/systemd.service.xml | 296 1 file changed, 296 insertions(+) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 4c890df..f33e8df 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -1358,6 +1358,302 @@ ExecStart=/bin/echo $ONE $TWO $THREE/programlisting /refsect1 refsect1 +titleExamples/title + +example +titleSimple service/title + +paraThe following unit file creates a service +that will execute +
Re: [systemd-devel] PrivateDevices with more than basic set of devices?
On Tue, 27.01.15 21:32, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/27/15 20:48, Lennart Poettering wrote: On Tue, 27.01.15 19:04, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 23:46, Lennart Poettering wrote: But independently of the PrivateDevices thing, would you think tmpfiles.d could be extended to be usable for unit specific cases instead of just one global setup? I think there could be more uses, for example, creating directories and links inside a unit's RuntimeDirectory. I am not sure how this could work and what kind of integration you precisely are looking for there? Note that tmpfiles exists mostly for two reasons: a) to deal with old software that wasn't capable of creating its own subdirs/stuff below its runtime directory; and b) to deal with software whose main program was running unpriviliged all the time (for example by using User=), and hence lacked the priviliges to set up its subdir in /run. a) was exactly my case, auditd doesn't have a way to specify where to put the pid file yet, so it ends up in /run/auditd.pid. Hmm, but that's fine, no? What would you put in tmpfiles for auditd? I'd want it to put the pid file somewhere else, like RuntimeDirectory. L/run/auditd.pid ---- /run/auditd/auditd.pid This is probably a bad example as pid files could be deleted by the daemon at exit. I think it would be better to fix this in auditd itself and make it use a proper dir below /run, rather than store its stuff in /run itself... 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] Unwants
On Tue, Jan 27, 2015 at 10:30:48PM +0100, Lennart Poettering wrote: On Tue, 27.01.15 15:45, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Hmm, I am open to allowing to override the symlinks with symlinks, if you follow what I mean. But i'd be careful with allowing to override stuff listed in Wants= in a unit file in /usr, with a symlink in a .wants/ dir in /etc, if you follow what I mean. Yes, exactly. But yeah, allowing symlinks to override symlinks makes sense, a patch for that would be good. Lennart Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation
On Tue, 27.01.15 17:22, Lennart Poettering (lenn...@poettering.net) wrote: On Tue, 27.01.15 16:24, Martin Pitt (martin.p...@ubuntu.com) wrote: Well, again, the right answer then is to handle it with .mount units, How would that look like, on a very high level? Create .mount units on the fly with udev rules when devices appear, and asking systemd to unmount them via a remove uevent, instead of having cdrom_id do the umount directly? The .mount units of device nodes already have a BindsTo= dependency on their respective backing .device units. This should have the effect that systemd will take the .mount units down if the .device units are removed. Are you saying that doesn't work? So I figure the bit that is missing here is the fact that the .device units for CD drives and USB card readers don't care for media sense right now. The .device units for CD drives and USB card readers are available as long as the CD drive or USB card reader is plugged in, it doesn't care for any media being in it. That means that automatic unmounting by systemd due to the device going away will only happen if you actually unplug the CD driver or the USB card, but not already when the media is ejected. However, I think it would make a ton of sense to change that, and set SYSTEMD_READY=0 on all block devices where the media sensing suggests that no medium is in it. This would mean that these devices don't show up as systemd units until you actually put a medium in it. That would be a change of semantics, but I think a useful one. What do you think? 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 v3] sysv-generator: Handle .sh suffixes when translating Provides:
On Wed, 21.01.15 14:55, Martin Pitt (martin.p...@ubuntu.com) wrote: Martin Pitt [2015-01-21 9:49 +0100]: One more adjustment to master, considering a recent change in the sysv-generator tests. Thomas and Michael both reviewed this patch, it's quite straightforward, and it fixes quite a severe regression, so I pushed it now. I don't want to push the other one without some review, though, as it's much less clear what the right solution is. Which one is the other one you refer to? 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] Unwants
On Tue, 27.01.15 16:18, Christian Seiler (christ...@iwakd.de) wrote: Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. it's more complex than that, since dependencies can come from both sides, and are generated automatically even. If we really wanted this to work, we'd have store precisely if a dep belongs to the soource or the destaination of the dep, if a dep comes from configuration, or is automatically created, and that we never coalesce deps. But I am not I like the complexity of that, and in particular the fact that we couldn't coalesce anymore... 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] sysv-generator: Handle .sh suffixes when translating Provides:
On Tue, 20.01.15 17:44, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey all, the recent fix for sysv-generator's Provides: handling [1] caused, or rather uncovered, another bug which now creates symlinks to itself foo.service - foo.service for any /etc/init.d/foo.sh. The generator would output an error message like Failed to create unit file path.../foo.service: File exists instead of creating the actual foo.service file. I. e. this completely breaks translating init scripts with .sh. Hmm, we already had code that checks this in place, didn#t we? I mean sysv_translate_facility() already filters out the case where the service name is identical to the provided name. Hence, why do you need a second check for this? I think your patch tapes over a bug somewhere else. I wonder if the simple fix could just be to change this: } else if (filename streq(name, filename)) to this } else if (filename streq(n, filename)) Or so, in that function? 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] timesyncd: tighten unit file
On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/27/15 01:54, Lennart Poettering wrote: On Sun, 25.01.15 12:23, Topi Miettinen (toiwo...@gmail.com) wrote: There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER. Hmm, that's not true, is it? load_clock_timestamp() is invoked before we drop privs in the daemon. And it certainly calls fchmod() and fchown(), so that it can later on still access the clock touch file. What am I missing? It works for me because the file exists already with correct owner and permissions. I'd put CAP_CHOWN and CAP_FOWNER back for now. Well, but this also means CAP_DAC_OVERRIDE is required, as otherwise we won't be able to access the file while we are still root, and have not dropped privileges anymore. Note that timesyncd actually drops all remaining caps when changng to the systemd-timesync user, with the exception of CAP_SYS_TIME. This means that the caps configured in the unit file don't matter too much as they only are in effect for the short time when timesyncd is initializing and hasn't dropped all the remaining caps except for CAP_SYS_TIME yet. Maybe the clock file could reside in a separate subdirectory, then the directory owner and permissions could be set up already at installation? Well, to enable stateless systems I think it is a good idea to write services in a way that they can rebuild what they need in /var on their own, should it be missing, so that /var can be flushed out and things will just work when the machine is then booted again. All our daemons are written in a style where /var is reconstructed implicitly if it is missing, and timesyncd really should work the same way. I am not entirely sure how NoNewPrivileges= and no-setuid-fixup actually relate to each other. I.e. what does one do that the other doesn't? And if they do different things, isn't NoNewPrivileges= kinda a superset of no-setuid-fixup, and thus makes setting the latter redundant? I think NoNewPrivileges (prctl(PR_SET_NO_NEW_PRIVS)) prevents any kind of uid/gid changes, while no-setuid-fixup does not restrict uid change but does not elevate the capability set. The PR_SET_NO_NEW_PRIVS docs say explicitly it only applies to execve(). To be honest, I am still very puzzled about this. The docs are awful about this... Reading through Documentation/prctl/no_new_privs.txt in the kernel sources I found this paragraph: Be careful, though: LSMs might also not tighten constraints on exec in no_new_privs mode. (This means that setting up a general-purpose service launcher to set no_new_privs before execing daemons may interfere with LSM-based sandboxing.) This kinda suggests that SELinux and friends might not like NoNewPrivileges=, hence I am not entirely sure it is really the right option for us. Hence I am wondering if no-setuid-fixup (and -locked) might be the better option for us to enable everywhere? I don't think timesyncd is executing any helper programs, especially set-uid or with file system capabilities, so both should work fine. Well, the way I read the paragraph above if we set PR_SET_NO_NEW_PRIVS after forking, but before execing systemd-timesyncd, and that binary has an selinux label on it, that the selinux label would be ignore, and things would continue to run with the same label as we forked off. This pretty much renders SELinux usesless, since all services where we set the bit for would then run as init_t... and that's something we really shouldn't do. The problem with these lists is that we need to be really conservative with them, since many of the libs we use (including glibc) use different interface behind our back, and thus writing generally valid rules, that work on all archs, on all distros, on all glibc/libary versions is hard. This is what SELinux policy does, but I *really* didn't want to create another implementation of such a finegrained policy, if you follow what I mean. I'm not sure. Shouldn't we then ship a SELinux policy file then? Would you be interested in AppArmor profile for timesyncd, I have one? Also, if a distro uses weird SELinux policies or setuid helpers at every possible opportunity, shouldn't they have some responsibility of fixing their setup? Well, SELinux policy is managed in a central selinux policy database that is shipped in one big RPM. My selinux-fu is not good enough to maintain the policy file in systemd, and i am not sure this even is generic enough to be able to ship the same selinux policy that works across all distros that do selinux. If Apparmor policies are standardized and stand-alone enough, and there's a clear way to install them, and you are willing to look after it, then yes, I'd merge a patch that adds apparmor profiles to systemd upstream. Hmm, LimitNPROC=2 unfortunately doesn't do what we want it to do: since the daemon drops the to the systemd-timesync user on
Re: [systemd-devel] [PATCH] timesyncd: tighten unit file
On 01/27/15 21:16, Lennart Poettering wrote: On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/27/15 01:54, Lennart Poettering wrote: On Sun, 25.01.15 12:23, Topi Miettinen (toiwo...@gmail.com) wrote: There's no need for CAP_CHOWN, CAP_DAC_OVERRIDE or CAP_FOWNER. Hmm, that's not true, is it? load_clock_timestamp() is invoked before we drop privs in the daemon. And it certainly calls fchmod() and fchown(), so that it can later on still access the clock touch file. What am I missing? It works for me because the file exists already with correct owner and permissions. I'd put CAP_CHOWN and CAP_FOWNER back for now. Well, but this also means CAP_DAC_OVERRIDE is required, as otherwise we won't be able to access the file while we are still root, and have not dropped privileges anymore. Note that timesyncd actually drops all remaining caps when changng to the systemd-timesync user, with the exception of CAP_SYS_TIME. This means that the caps configured in the unit file don't matter too much as they only are in effect for the short time when timesyncd is initializing and hasn't dropped all the remaining caps except for CAP_SYS_TIME yet. Maybe the clock file could reside in a separate subdirectory, then the directory owner and permissions could be set up already at installation? Well, to enable stateless systems I think it is a good idea to write services in a way that they can rebuild what they need in /var on their own, should it be missing, so that /var can be flushed out and things will just work when the machine is then booted again. All our daemons are written in a style where /var is reconstructed implicitly if it is missing, and timesyncd really should work the same way. Nice, but the directories could be created with tmpfiles.d then? I am not entirely sure how NoNewPrivileges= and no-setuid-fixup actually relate to each other. I.e. what does one do that the other doesn't? And if they do different things, isn't NoNewPrivileges= kinda a superset of no-setuid-fixup, and thus makes setting the latter redundant? I think NoNewPrivileges (prctl(PR_SET_NO_NEW_PRIVS)) prevents any kind of uid/gid changes, while no-setuid-fixup does not restrict uid change but does not elevate the capability set. The PR_SET_NO_NEW_PRIVS docs say explicitly it only applies to execve(). To be honest, I am still very puzzled about this. The docs are awful about this... Reading through Documentation/prctl/no_new_privs.txt in the kernel sources I found this paragraph: Be careful, though: LSMs might also not tighten constraints on exec in no_new_privs mode. (This means that setting up a general-purpose service launcher to set no_new_privs before execing daemons may interfere with LSM-based sandboxing.) This kinda suggests that SELinux and friends might not like NoNewPrivileges=, hence I am not entirely sure it is really the right option for us. Hence I am wondering if no-setuid-fixup (and -locked) might be the better option for us to enable everywhere? I don't think timesyncd is executing any helper programs, especially set-uid or with file system capabilities, so both should work fine. Well, the way I read the paragraph above if we set PR_SET_NO_NEW_PRIVS after forking, but before execing systemd-timesyncd, and that binary has an selinux label on it, that the selinux label would be ignore, and things would continue to run with the same label as we forked off. This pretty much renders SELinux usesless, since all services where we set the bit for would then run as init_t... and that's something we really shouldn't do. seccomp_filter.txt on the other hand says that Prior to use, the task must call prctl(PR_SET_NO_NEW_PRIVS, 1) or run with CAP_SYS_ADMIN privileges in its namespace. If these are not true, -EACCES will be returned. This requirement ensures that filter programs cannot be applied to child processes with greater privileges than the task that installed them. Does this mean that SELinux and seccomp are mutually exclusive? Awful design if so. The problem with these lists is that we need to be really conservative with them, since many of the libs we use (including glibc) use different interface behind our back, and thus writing generally valid rules, that work on all archs, on all distros, on all glibc/libary versions is hard. This is what SELinux policy does, but I *really* didn't want to create another implementation of such a finegrained policy, if you follow what I mean. I'm not sure. Shouldn't we then ship a SELinux policy file then? Would you be interested in AppArmor profile for timesyncd, I have one? Also, if a distro uses weird SELinux policies or setuid helpers at every possible opportunity, shouldn't they have some responsibility of fixing their setup? Well, SELinux policy is managed in a central selinux policy database that is shipped in one big RPM. My
Re: [systemd-devel] PrivateDevices with more than basic set of devices?
On 01/27/15 21:35, Lennart Poettering wrote: On Tue, 27.01.15 21:32, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/27/15 20:48, Lennart Poettering wrote: On Tue, 27.01.15 19:04, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/26/15 23:46, Lennart Poettering wrote: But independently of the PrivateDevices thing, would you think tmpfiles.d could be extended to be usable for unit specific cases instead of just one global setup? I think there could be more uses, for example, creating directories and links inside a unit's RuntimeDirectory. I am not sure how this could work and what kind of integration you precisely are looking for there? Note that tmpfiles exists mostly for two reasons: a) to deal with old software that wasn't capable of creating its own subdirs/stuff below its runtime directory; and b) to deal with software whose main program was running unpriviliged all the time (for example by using User=), and hence lacked the priviliges to set up its subdir in /run. a) was exactly my case, auditd doesn't have a way to specify where to put the pid file yet, so it ends up in /run/auditd.pid. Hmm, but that's fine, no? What would you put in tmpfiles for auditd? I'd want it to put the pid file somewhere else, like RuntimeDirectory. L/run/auditd.pid ---- /run/auditd/auditd.pid This is probably a bad example as pid files could be deleted by the daemon at exit. I think it would be better to fix this in auditd itself and make it use a proper dir below /run, rather than store its stuff in /run itself... Fully agree. -Topi Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 2/2] systemd.service(5): add some simple examples
On Tue, 27.01.15 17:45, Christian Seiler (christ...@iwakd.de) wrote: +titleExamples/title + +example +titleSimple service/title + +paraThe following unit file creates a service +that will execute +filename/usr/sbin/foo-daemon/filename. +Since no varnameType=/varname is specified, +the default +varnameType=/varnameoptionsimple/option +will be assumed. systemd will assume the unit +to be started immediately after the program has +begun executing./para + +programlisting[Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +[Install] +WantedBy=multi-user.target/programlisting + +paraNote that systemd assumes here that the +program will continue running in the foreground +as long as it's active. If the program I think foreground vs. background here is probably something to avoid. These are services after all, and hence kinda background in all cases. I am not sure how to explain this better though... Maybe clarify that the program does not fork on its own, and that the process systemd starts stays running until the very end of the daemon, or so. +paraNote that systemd will consider the unit +to be in the state 'starting' until the program +has terminated, so ordered dependencies will +wait for the program to finish before starting +themselves. The unit will revert to the +'inactive' state after the execution is +done. That means another request to start the +unit will perform the action again./para It might be worth also mentioning here that the the unit this way will never actually be active. It will go directly from activating to inactive, which might be surprising! +/example + +example +titleStoppable oneshot service/title + +paraSimilarly to the oneshot services, there +are sometimes units that need to execute a +program to set up something and then execute +another to shut it down, but no process remains +active while they are considered +'started'. Network configuration can sometimes +fall into this category./para Another reason to use RemainAfterExit= are services that shall not execute again and again when they are pulled in, but only the first time... +example +titleDBus services/title + +paraFor services that acquire name on the +DBus system bus, use + varnameRemainAfterExit=/varnameoptiondbus/option Typo. Should be Type=, not RemainAfterExit= +example +titleDeferred (idle) services/title Hmm, I wonder if we maybe should remove this part. Idle services are kinda exotic, and I figure people might be tempted to misuse them. I think this might be something to document at the description of Type=, but not push people towards using this beyond that. Looks great otherwise! Thanks a ton for putting this together, much appreciated! 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] systemd-udevd.service: restore mount propagation
On Tue, 27.01.15 23:20, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey Lennart, Lennart Poettering [2015-01-27 22:46 +0100]: So I figure the bit that is missing here is the fact that the .device units for CD drives and USB card readers don't care for media sense right now. Indeed, I had a similar thought on my evening walk: This works well for USB sticks and the like, but the /dev/sr0 node for CDs always stays around after eject. IOW, you get a change event, not a remove one. This is also why the cleanup in udisks 1.x (probably) didn't actually work. However, I think it would make a ton of sense to change that, and set SYSTEMD_READY=0 on all block devices where the media sensing suggests that no medium is in it. This would mean that these devices don't show up as systemd units until you actually put a medium in it. That would be a change of semantics, but I think a useful one. That sounds good indeed! I can sit down at qemu tomorrow and simulate some CD insertions/removals, and come up with an udev rule for this. That would be great. It would really just be a matter of setting SYSTEMD_READY=0 for block devices where media sense suggests that no media is in the drive. Probably a one line fix... 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] Swap gets activated twice (through fstab and gpt generators)
On Tue, 27.01.15 23:31, Lennart Poettering (lenn...@poettering.net) wrote: On Fri, 23.01.15 10:18, Martin Pitt (martin.p...@ubuntu.com) wrote: So perhaps the more robust fix would be to make the gpt generator not generate swap units if fstab already configures any swap device? I. e. auto-discovery and swaps in fstab are mutually exclusive then. Hmm, so there's something fishy here. systemd should already handle this nicely, and I thought I tested this successfully. The logic here is that when we enumerate through /proc/swaps we already check udev to not only then set the device listed in there to active, but also all .swap units that are defined by any of its symlink names. This means, activating a swap partition should result in a number of .swap devices to go active, not just one. THis is visible if you type systemctl -a -t swap, which should show a number of .device units for the same actual swap device... Now, if two jobs are queued to up a swap device, using different names for it, like an entry in fstab, and a GPT auto-discovered partition might do it, then this should mean that one of the jobs should be removed by the effect of the other, i.e. the later job should be immediately succeed, since the other job already caused the swap device to go active. There must be a bug somewhere with this... Any chance you can boot in debug mode and check how the .swap units change states during the boot, and when the jobs for it are enqueued? Hmm, thinking a bit more about this. The problem is probably this one: when the jobs are queued we cannot know that the devices they are queued by are actually the same, hence both are queued. Now, if the .device unit backing the two .swap units, both .swap units are suddenly runnable, and hence systemd forks off swapon for both of them immediately. it will then eventually see that both .swap devices are now active from /proc/swaps, but at that time it already had forked off both mkswap's, and one of them will then fail... I wonder what we can do about this. One approach could be to say that automatically discovered mounts and swaps are always dispatched before the ones from /etc/fstab. By serializing things it would be guaranteed that one of the mkswaps runs first, thus brining up both .swap units, so that the second mkswap would not be done, since the .swap would already be up... That said, it would of course be nicer if we wouldn't have to serialize here... 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] timesyncd: tighten unit file
On Tue, Jan 27, 2015 at 1:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote: I'm not sure. Shouldn't we then ship a SELinux policy file then? Would you be interested in AppArmor profile for timesyncd, I have one? Also, if a distro uses weird SELinux policies or setuid helpers at every possible opportunity, shouldn't they have some responsibility of fixing their setup? Well, SELinux policy is managed in a central selinux policy database that is shipped in one big RPM. My selinux-fu is not good enough to maintain the policy file in systemd, and i am not sure this even is generic enough to be able to ship the same selinux policy that works across all distros that do selinux. If Apparmor policies are standardized and stand-alone enough, and there's a clear way to install them, and you are willing to look after it, then yes, I'd merge a patch that adds apparmor profiles to systemd upstream. A good idea would be to set the apparmor profile(s) to warn-only mode for some period of time, and then let distros patch (this would be a one liner) that to be in enforce mode if they want to test it out. One possible issue is that AppArmor profiles are installed in /etc. Will that be a problem WRT the whole stateless system initiative, or is it an acceptable exception to the only comments in /etc rule? Cheers, -- Cameron ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On 01/28/2015 12:24 AM, Lennart Poettering wrote: On Tue, 27.01.15 17:17, Chris Murphy (li...@colorremedies.com) wrote: The problem is simply that we cannot know in advance that /dev/sda7 and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will eventually refer to the same device. Are these just scary looking warnings? It should be unproblematic, but it looks scary right now. The swapon will only succeed once, and fail the second time, and that doesn't look pretty, but the kernel should do the right thing and not get confused by this. I can confirm it does and I simply remove the swap entry in fstab to make it go away when I encountered it. That said are there any real practical benefits of using swap et al in today's age or are people just still creating it out of habit? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Replace Provides: symlinks with real units
On Wed, 21.01.15 19:56, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote: So I expect if it gets dropped upstream, a lot of distros (and all the major ones) will have to bring that back; it's IMHO better to just maintain it upstream by the distro maintainers. Exactly. Dropping it would be just busy work for everyone. General purpose distributions need to carry it for the forseeable future. That argument does not hold water since there are systemd and core/baseOS consumers that want the other side of that coin and have to patch out all the legacy stuff. Arguably upstream should be leading everybody into the future not dwelling on the past and having to maintain it in the process. If you compile systemd and pass empty strings for the sysv rc and scripts paths, then this turns off all sysv support in systemd, and all that old cruft goes away. Today. 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] failing boot start jobs delay reboot
On Mon, 19.01.15 17:59, Felix Miata (mrma...@earthlink.net) wrote: Has anything been done in more recent releases about this? I do a lot of cloning, and sometimes produce typos on grub cmdlines and fstab lines. This produces long delays in init followed by emergency mode when the non-essential mount fails and fstab for that device does not include the nofail option. When I recognize early in init that I have made a fstab typo, I try to CAD to choose another boot choice that isn't broken and fix the typo, but that produces yet another start job wait for the same broken job, often followed by a gazillion failed to save sound card state messages from holding down CAD. openSUSEes, Mageias Fedoras (including Factories, Cauldrons Rawhides) comprise most of my installations subject to these self-inflicted delays that I can't recall being a problem with sysvinit. Hmm, so there has been a long-standing TODO list item to show some job data when C-a-d is pressed 3 times within 1s, and reboot the machine immediately on 3 times within 10s or so. I figure that would already make you happy? 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] failing boot start jobs delay reboot
On Mon, 19.01.15 23:03, Felix Miata (mrma...@earthlink.net) wrote: Andrei Borzenkov composed on 2015-01-20 06:35 (UTC+0300): Mon, 19 Jan 2015 17:59:41 -0500 Felix Miata composed: Has anything been done in more recent releases about this? I do a lot of cloning, and sometimes produce typos on grub cmdlines and fstab lines. This produces long delays in init followed by emergency mode when the non-essential mount fails and fstab for that device does not include the nofail option. When I recognize early in init that I have made a fstab typo, I try to CAD to choose another boot choice that isn't broken and fix the typo, but that produces yet another start job wait for the same broken job, often followed by a gazillion failed to save sound card state messages from holding down CAD. openSUSEes, Mageias Fedoras (including Factories, Cauldrons Rawhides) comprise most of my installations subject to these self-inflicted delays that I can't recall being a problem with sysvinit. Self inflicted delays during boot or during Ctrl-Alt-Del? Both. When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Often the start job is on account of a volume label that has been replaced, usually along with a UUID, because the clone is a partition on the same HD. Fedora is particularly frustrating by embedding dependent root volume label and not obeying root= on cmdline (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run dracut. Hmm, Fedora doesn't obey root=? That sounds like a bug. Harald? -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failing boot start jobs delay reboot
On Wed, 28.01.15 02:02, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 19.01.15 17:59, Felix Miata (mrma...@earthlink.net) wrote: Has anything been done in more recent releases about this? I do a lot of cloning, and sometimes produce typos on grub cmdlines and fstab lines. This produces long delays in init followed by emergency mode when the non-essential mount fails and fstab for that device does not include the nofail option. When I recognize early in init that I have made a fstab typo, I try to CAD to choose another boot choice that isn't broken and fix the typo, but that produces yet another start job wait for the same broken job, often followed by a gazillion failed to save sound card state messages from holding down CAD. openSUSEes, Mageias Fedoras (including Factories, Cauldrons Rawhides) comprise most of my installations subject to these self-inflicted delays that I can't recall being a problem with sysvinit. Hmm, so there has been a long-standing TODO list item to show some job data when C-a-d is pressed 3 times within 1s, and reboot the machine immediately on 3 times within 10s or so. I figure that would already make you happy? So, I actually implemented this now. Or actually, I only implemented the part about C-A-D triggering a reboot. I picked 7x per 2s as limit though, seemed easier to me. It should be easy to extend this to show information about running jobs after 3x too. http://cgit.freedesktop.org/systemd/systemd/commit/?id=2e5c94b9aaefce46835b623e800cfc168995ea3f Hope this is useful, 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] Making udev emit a signal when it is done loading modules
On Sat, 17.01.15 17:03, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Sat, Jan 17, 2015 at 09:44:00AM +0100, Hans de Goede wrote: We would like udev to emit a signal (ABI to be discussed) when it is done trying to load modules for everything which was already enumerated when it starts, iow when there are no new device events pending anymore when udev does its initial hotplug replay. I think you can just create a unit like: # disable-new-hardware.service [Unit] After=systemd-udev-settle.service systemd-modules-load.service Wants=systemd-udev-settle.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/local/bin/ping-the-kernel So the question to you is would you be willing to include such functionality in udev? I don't think udevd has enough knowledge. But a systemd unit like the one above should work. To clarify this: if people do this, then this pulls in systemd-udev-settle.service, which slows down boot. Every service that does that is hence a majour source of slowness. It's a hack to use this, not a solution. 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-commits] 5 commits - man/journalctl.xml man/tmpfiles.d.xml src/console src/import src/journal src/libudev src/shared src/tmpfiles
On Sun, 18.01.15 16:13, Zbigniew Jędrzejewski-Szmek (zbys...@kemper.freedesktop.org) wrote: commit 302fbdf29eb0ad4ca1fe8ee18755edad7db11b37 Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl Date: Tue Jan 6 01:58:31 2015 -0500 man: reindent tmpfiles.d(5) Reindent to 2 spaces, use more markup. So, hmm, maybe we should make up our minds on this. Currently half ot he man pages is 2ch indented, the other half 8ch indented. I would prefer if all files would either be one or the other... I can see why 8ch indenting is not as nice and useful for XML as it is for C. So I'd be open to changing everything to 2ch. Maybe it's time to run some sed script over the man pages to fix everything to 2ch? 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] Swap gets activated twice (through fstab and gpt generators)
On Tue, Jan 27, 2015 at 5:28 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 01/28/2015 12:24 AM, Lennart Poettering wrote: On Tue, 27.01.15 17:17, Chris Murphy (li...@colorremedies.com) wrote: The problem is simply that we cannot know in advance that /dev/sda7 and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will eventually refer to the same device. Are these just scary looking warnings? It should be unproblematic, but it looks scary right now. The swapon will only succeed once, and fail the second time, and that doesn't look pretty, but the kernel should do the right thing and not get confused by this. I can confirm it does and I simply remove the swap entry in fstab to make it go away when I encountered it. That said are there any real practical benefits of using swap et al in today's age or are people just still creating it out of habit? For those who have hibernation working, it's needed. And there's a case for it on baremetal servers, it's sometimes better that they slow down instead of totally face planting. And it can be useful if you don't have enough memory to do a full fsck on a large file system, especially if swap is on an SSD it's not as slow as on a HDD. But otherwise, maybe not. Over on that other OS that begins with W, it looks like they aren't using swap directly. Instead there's a separate Intel Rapid Start specific partition (it has it's own GPT partition type GUID) that puts some kind of hibernation like file there on normal shutdown. Cold boot times are insanely fast, like 3-4 seconds from pushing the button. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/journal
On Mon, 19.01.15 10:43, Zbigniew Jędrzejewski-Szmek (zbys...@kemper.freedesktop.org) wrote: src/journal/journalctl.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) New commits: commit 40f0b71b063da6a36b8d7ec75ef20103abd18243 Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl Date: Mon Jan 19 13:42:34 2015 -0500 journalctl: trim --help to fit in 80 columns Terminals tend to be 80 columns wide by default, and the help text is only supposed to be a terse reminder anyway. Hmm, maybe we should add a test target to the makefile that runs all our tools with --help and checks that the output it generates is identical to the output pssed through fold -w 79 or so? (I added this to the TODO list for now) 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 04/11] tmpfiles: attach an array of items to each path
On Mon, 19.01.15 01:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
The data structure used by tmpfiles is changed: instead of hashmaps
mapping {path → Item*} we now have hashmaps containing
{path - ItemArray}, where ItemArray contains a pointer
to an array of Items.
I figure one of those days we really should add a proper MultiHashmap
type or so, that can map one key to multiple values. There are quite a
few cases we could have used this so far, and this is the next one.
So far we usually resorted to using a hashmap that points to a linked
list of items, using the LIST_FIELDS macros for the list. That has the
nice effect that ignoring the list makes the this multi-map behave
exactly like a normal map, i.e. it points to one valid object...
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] sysv-generator: Replace Provides: symlinks with real units
On Wed, 21.01.15 11:08, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey Jóhann, Jóhann B. Guðmundsson [2015-01-21 9:59 +]: Seems like a corner case as administrator should fix himself by not backing up files in the /etc/init.d directory so arguably this broken behaviour is expect. With SysV init this isn't broken at all. As long as you don't actually enable the backup files in rcN.d/, this is perfectly valid. The effect is that systems with such backup files work fine under SysV init and even under systemd up to 218, but will fail to boot under systemd 219 onwards (i. e. with current master). I call this a regression. That said at one point or another we need to drop legacy sysv initscript support and have downstream the generator themselves if they intend on supporting legacy sysv initscripts. If upstream wants to drop it at some point that's their prerogative of course. I'd advise against it though, as LSB compliant systems need to support SysV init scripts, it's still the lowest common denoniator, and tons of third-party software still ship with init.d scripts. I. e. it's not enough to port the distro packages. Just to clarify: I have zero intention to drop LSB script support any time soon. 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] sysv-generator: Replace Provides: symlinks with real units
On Wed, 21.01.15 10:46, Martin Pitt (martin.p...@ubuntu.com) wrote: A similar case can also happen if one init.d script Provides: the name of another init.d script (arguably this is at least questionable, but it might happen in practice -- e. g. /etc/init.d/mariad might very well Provides: mysql as it's kind of a drop-in replacement). I wrote some more tests which reproduce these failures, and a proposed patch. It's not exactly nice due to the TOCTOU (which shouldn't cause any practical problem though, it's just a bit unclean), but I can't think of a better solution which covers all corner cases. I am not a fan of this stuff either. I really don't like the TOCTOU behaviour I must say... If this is really just about .bak, then we can add it to the list of suffixes in hidden_files()... I think a much better fix for all of this would be to first read in all sysv scripts, and only then start creating aliases. So far we read everything in, and while doing so already create symlinks, while defering creation of the unit files to the end. If we moevd the symlink creation part to the end too we could easily check in the sysv script hashtable if we have a real script for a name before writing out an alias symlink for this. 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] failing boot start jobs delay reboot
On Tue, 20.01.15 11:24, Andrei Borzenkov (arvidj...@gmail.com) wrote: When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Yes, that's the problem. For once, traditional workflow of - stop in emergency shell when mount fails - fix /etc/fstab - ^D to continue boot no more works, because /etc/fstab is not reevaluated so systemd will still try the same broken mount again. Yeah, systemd will require a systemctl daemon-reload first. It might be a good idea if distros would mention that in a comment in the default fstab file they install. 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] timedated: support split usr v3
On Sun, 18.01.15 10:53, Shawn Landden (sh...@churchofgit.com) wrote: From: Shawn Paul Landden sh...@churchofgit.com The current Debian solution to this is really ugly, and I would rather have them use the correct patch even if split usr is dumb. Again, I really don't grok what the point of this is. The right fix is to mount /usr from the initrd. It's certainly not to add hacks to systemd. Sorry, but there's no way this will get in. 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-216 breaks combined ReadOnlyDirectories / ReadWriteDirectories
On Tue, 20.01.15 13:48, Reindl Harald (h.rei...@thelounge.net) wrote: after upgrade to Fedora 21 with new systemd namespaces like below no longer works which breaks *all my systemd-units* why? ReadOnlyDirectories=/var/lib ReadWriteDirectories=/var/lib/mysql I cannot reproduce this issue with systemd upstream. This appears to work fine. Any chance you can try to reproduce this with current upstream? Do you have any other namespace-related settings in the unit file that triggers this? Like ProtectSystem= or so? Can you paste the entire unit file? 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] logind vs CAP_SYS_ADMIN-lessness
Am 27.01.2015 um 14:46 schrieb Lennart Poettering: Note that $container_ttys= is actually just a frontend for dynamically instantiating console-getty@.service instances for the specified ptys. You can just enable them statically too. No, I can't, because you only support PTY numbers in that interface and I can't predict which ones will get assigned. Oh, I see now, I can use ../ in the statically enabled, and that actually works. If I now combine that with LXC's feature to add a subdir to the ttys, I can do the following: - tell LXC to create /dev/lxc/ttyN instead - statically enable container-getty@..-lxc-ttyN.service - just tried it: works Thanks! Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Examples in man pages
Just a heads-up: while reading the Unwants thread I noticed that dependencies are the only types of lists in unit files that can't be reset, so my example in there actually doesn't work, so please don't commit my patch just now. I'm writing more examples and will resubmit anyway. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: On Thu, 22.01.15 13:54, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: Is there a way to remove / override wants that are specified via .wants directory, .d snippet with Wants=, or wants specified in the unit itself? Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. For --user mode this is actually the only unprivileged way to achieve complete overriding of system supplied units, so I'm convinced we should allow this. Zbyszek When we designed this initially this way I wasn't sure this would suffice, but I kinda like the simplicity of this, and interestingly you are the first one who wants to reset dependencies again. Which makes me wonder if we canot find a better solution for this? I thought that creating a symlink to /dev/null from a higher up directory would disable wants dependency but it didn't: e.g.: I was expecting for /run/systemd/system/getty.target.wants/getty@tty1.service - /dev/null Wat precisely is the reason for trying to do this? What are you trying to do here, and why? So, is there a way to unwant something, as an override? Nope, currently there isn't. 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] Unwants
Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Additionally, not considering .wants/ but drop-ins: currently, all[*] lists except dependencies can be overridden in drop-ins by resetting them first. So if I write ConditionPathExists=/foo in the unit file, and then ConditionPathExists= ConditionPathExists=/bar in a snippet, that will work as expected. Not so for dependencies. The problem here is I think a bit in the parsing logic: when parsing a unit file, dependencies are immediately added to the unit in question. If you were to first collect them as a set and then only after all drop-ins / etc. of a unit file are parsed you would add them to the unit's dependencies, this would immediately solve the problem. Also note that if b.service as Before=a.service, I would NOT expect and empty After= in a.service to override that, it would be weird. This is another good reason to first collect stuff locally (and only do overrides on that level) before adding the global state at the end of parsing. Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. Just my 2 cents. Christian [*] Probably, I haven't checked. ;-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timesyncd: tighten unit file
On Tue, 27.01.15 21:58, Topi Miettinen (toiwo...@gmail.com) wrote:
Well, to enable stateless systems I think it is a good idea to write
services in a way that they can rebuild what they need in /var on
their own, should it be missing, so that /var can be flushed out and
things will just work when the machine is then booted again.
All our daemons are written in a style where /var is reconstructed
implicitly if it is missing, and timesyncd really should work the same
way.
Nice, but the directories could be created with tmpfiles.d then?
Well, we could. But I really like robust deamons that just work on
their own, I must say...
Well, the way I read the paragraph above if we set PR_SET_NO_NEW_PRIVS
after forking, but before execing systemd-timesyncd, and that binary
has an selinux label on it, that the selinux label would be ignore,
and things would continue to run with the same label as we forked
off. This pretty much renders SELinux usesless, since all services
where we set the bit for would then run as init_t... and that's
something we really shouldn't do.
seccomp_filter.txt on the other hand says that
Prior to use, the task must call prctl(PR_SET_NO_NEW_PRIVS, 1) or
run with CAP_SYS_ADMIN privileges in its namespace. If these are not
true, -EACCES will be returned. This requirement ensures that filter
programs cannot be applied to child processes with greater privileges
than the task that installed them.
Does this mean that SELinux and seccomp are mutually exclusive? Awful
design if so.
Well, no it doesn't mean that. If systemd sets up a seccomp filter it
has CAP_SYS_ADMIN, hence all is good. And it can leave
PR_SET_NO_NEW_PRIVS off, and thus not break selinux.
If Apparmor policies are standardized and stand-alone enough, and
there's a clear way to install them, and you are willing to look after
it, then yes, I'd merge a patch that adds apparmor profiles to systemd
upstream.
Well, I'm no expert on AppArmor policies. This is what I have:
#include tunables/global
/lib/systemd/systemd-timesyncd {
#include abstractions/nameservice
capability setgid,
capability setuid,
capability sys_time,
capability setpcap,
this is missing the three fs related caps at least...
/etc/ld.so.cache r,
/etc/systemd/timesyncd.conf r,
/lib/systemd/systemd-timesyncd mr,
/lib/x86_64-linux-gnu/libattr.so.* mr,
/lib/x86_64-linux-gnu/libc-*.so mr,
/lib/x86_64-linux-gnu/libcap.so.* mr,
/lib/x86_64-linux-gnu/libm-*.so mr,
/lib/x86_64-linux-gnu/libnsl-*.so mr,
/lib/x86_64-linux-gnu/libpthread-*.so mr,
/lib/x86_64-linux-gnu/libresolv-*.so mr,
/proc/cmdline r,
/proc/sys/kernel/random/boot_id r,
/run/systemd/netif/state r,
This is not sufficient, as it also wants to read the networkd
confguration, to get NTP servers from it, if networkd is running.
Anyway, if this is cleaned up, and overlooked by somebody who knows
apparmor, and is properly installed by automake, i'd take a patch for
this. However, as i have no clue of Apparmor and can't test this I'd
fully rely on contributions for this one.
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] systemd-udevd.service: restore mount propagation
On Tue, 27.01.15 23:33, Martin Pitt (martin.p...@ubuntu.com) wrote:
Lennart Poettering [2015-01-27 22:46 +0100]:
However, I think it would make a ton of sense to change that, and set
SYSTEMD_READY=0 on all block devices where the media sensing suggests
that no medium is in it.
Thinking about it again, we already know that this rule in
60-cdrom_id.rules still works:
ENV{DISK_EJECT_REQUEST}==?*, RUN+=cdrom_id --eject-media $devnode,
GOTO=cdrom_end
Could we not simply add the ENV{SYSTEMD_READY}=0 there, and then
reset it (to 1) in the following rule?
Well, in that case it would only be set when somebody actually
presses the eject button. I am pretty sure though we should also set
the flag when a cdrom drive appears first and has no medium in it...
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] Swap gets activated twice (through fstab and gpt generators)
On 01/27/2015 10:48 PM, Lennart Poettering wrote: Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. Is not the problem here that we are using two generators to parse this? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, 27.01.15 23:48, Lennart Poettering (lenn...@poettering.net) wrote: That said, it would of course be nicer if we wouldn't have to serialize here... Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. I implemented a different logic now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=37cf8fee46025d704660a9fc1d1349fe7d0b139d With this change we'll now dispatch only one mkswap per device node, regardless which symlinked alias is used to refer to it. I have only given this very light testing, and I am not sure this solves the original problem you reported, hence I'd be thankful if you could check if this makes the problem go away. 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 v3] sysv-generator: Handle .sh suffixes when translating Provides:
Lennart Poettering [2015-01-27 23:11 +0100]: Which one is the other one you refer to? That was http://lists.freedesktop.org/archives/systemd-devel/2015-January/027249.html Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, 27.01.15 23:40, Lennart Poettering (lenn...@poettering.net) wrote: On Tue, 27.01.15 23:31, Lennart Poettering (lenn...@poettering.net) wrote: On Fri, 23.01.15 10:18, Martin Pitt (martin.p...@ubuntu.com) wrote: So perhaps the more robust fix would be to make the gpt generator not generate swap units if fstab already configures any swap device? I. e. auto-discovery and swaps in fstab are mutually exclusive then. Hmm, so there's something fishy here. systemd should already handle this nicely, and I thought I tested this successfully. The logic here is that when we enumerate through /proc/swaps we already check udev to not only then set the device listed in there to active, but also all .swap units that are defined by any of its symlink names. This means, activating a swap partition should result in a number of .swap devices to go active, not just one. THis is visible if you type systemctl -a -t swap, which should show a number of .device units for the same actual swap device... Now, if two jobs are queued to up a swap device, using different names for it, like an entry in fstab, and a GPT auto-discovered partition might do it, then this should mean that one of the jobs should be removed by the effect of the other, i.e. the later job should be immediately succeed, since the other job already caused the swap device to go active. There must be a bug somewhere with this... Any chance you can boot in debug mode and check how the .swap units change states during the boot, and when the jobs for it are enqueued? Hmm, thinking a bit more about this. The problem is probably this one: when the jobs are queued we cannot know that the devices they are queued by are actually the same, hence both are queued. Now, if the .device unit backing the two .swap units, both .swap units are suddenly runnable, and hence systemd forks off swapon for both of them immediately. it will then eventually see that both .swap devices are now active from /proc/swaps, but at that time it already had forked off both mkswap's, and one of them will then fail... I wonder what we can do about this. One approach could be to say that automatically discovered mounts and swaps are always dispatched before the ones from /etc/fstab. By serializing things it would be guaranteed that one of the mkswaps runs first, thus brining up both .swap units, so that the second mkswap would not be done, since the .swap would already be up... That said, it would of course be nicer if we wouldn't have to serialize here... Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. 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] Swap gets activated twice (through fstab and gpt generators)
On Tue, 27.01.15 23:29, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 01/27/2015 10:48 PM, Lennart Poettering wrote: Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. Is not the problem here that we are using two generators to parse this? No, not at all. The problem is simply that we cannot know in advance that /dev/sda7 and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will eventually refer to the same device. We hence have to enqueue jobs to activate both, but finally, when the device actually appears and we realize both names actually refer to the same device, we need to handle this gracefully, instead of actually invoking mkswap on both of them. 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] timesyncd: tighten unit file
On Tue, 27.01.15 15:12, Cameron Norman (camerontnor...@gmail.com) wrote: Lennart: if you really want to test the profile, you just need to spin up an OpenSuSE, Ubuntu, or Debian VM (on debian you need to install and enable apparmor, which takes a short while). Well, I have no personal interest in AppArmor, and I really have enough stuff to do. If AA shall be supported in systemd, then I am happy to merge stuff for it, if it is reviewed properly, but I am not the one to test it. Sorry... 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] systemd-udevd.service: restore mount propagation
Lennart Poettering [2015-01-27 22:46 +0100]:
However, I think it would make a ton of sense to change that, and set
SYSTEMD_READY=0 on all block devices where the media sensing suggests
that no medium is in it.
Thinking about it again, we already know that this rule in
60-cdrom_id.rules still works:
ENV{DISK_EJECT_REQUEST}==?*, RUN+=cdrom_id --eject-media $devnode,
GOTO=cdrom_end
Could we not simply add the ENV{SYSTEMD_READY}=0 there, and then
reset it (to 1) in the following rule?
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, Jan 27, 2015 at 5:05 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 27.01.15 23:29, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 01/27/2015 10:48 PM, Lennart Poettering wrote: Another idea might be to simply accept that activating the swap by two names at the same time can happen concurrently, and teach mkswap in some way to handle this gracefully. For example, mkswap could learn a new switch --idempotent or so, which we could always pass from systemd. If set and if activating the swap fails with EBUSY because the swap is already activated it would eat that up and return success. Is not the problem here that we are using two generators to parse this? No, not at all. The problem is simply that we cannot know in advance that /dev/sda7 and /dev/disk/by-uuid/c0e7978b-f82b-4b7f-b72b-6717f6909abc will eventually refer to the same device. Are these just scary looking warnings? Or is swapon actually listing the same device twice, as if it's activated twice? That'd seem to be a bug. What if the fstab listed the same swap twice, either duplicate lines or one line with /dev/sdXY and one line with UUID for the same device? I thought /dev/sdXY is considered sufficiently unreliable that it shouldn't be used for static configuration files anymore.? Patient: Doctor, when I bend my arm like this it hurts! Doctor: I suggest not bending your arm that way. It's probably not what people want to hear because it doesn't really solve the problem, but the problem is created by an unreliable practice in the first place. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation
Hey Lennart, Lennart Poettering [2015-01-27 22:46 +0100]: So I figure the bit that is missing here is the fact that the .device units for CD drives and USB card readers don't care for media sense right now. Indeed, I had a similar thought on my evening walk: This works well for USB sticks and the like, but the /dev/sr0 node for CDs always stays around after eject. IOW, you get a change event, not a remove one. This is also why the cleanup in udisks 1.x (probably) didn't actually work. However, I think it would make a ton of sense to change that, and set SYSTEMD_READY=0 on all block devices where the media sensing suggests that no medium is in it. This would mean that these devices don't show up as systemd units until you actually put a medium in it. That would be a change of semantics, but I think a useful one. That sounds good indeed! I can sit down at qemu tomorrow and simulate some CD insertions/removals, and come up with an udev rule for this. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Fri, 23.01.15 10:18, Martin Pitt (martin.p...@ubuntu.com) wrote: So perhaps the more robust fix would be to make the gpt generator not generate swap units if fstab already configures any swap device? I. e. auto-discovery and swaps in fstab are mutually exclusive then. Hmm, so there's something fishy here. systemd should already handle this nicely, and I thought I tested this successfully. The logic here is that when we enumerate through /proc/swaps we already check udev to not only then set the device listed in there to active, but also all .swap units that are defined by any of its symlink names. This means, activating a swap partition should result in a number of .swap devices to go active, not just one. THis is visible if you type systemctl -a -t swap, which should show a number of .device units for the same actual swap device... Now, if two jobs are queued to up a swap device, using different names for it, like an entry in fstab, and a GPT auto-discovered partition might do it, then this should mean that one of the jobs should be removed by the effect of the other, i.e. the later job should be immediately succeed, since the other job already caused the swap device to go active. There must be a bug somewhere with this... Any chance you can boot in debug mode and check how the .swap units change states during the boot, and when the jobs for it are enqueued? 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] timesyncd: tighten unit file
On Tue, Jan 27, 2015 at 1:58 PM, Topi Miettinen toiwo...@gmail.com wrote:
Well, I'm no expert on AppArmor policies. This is what I have:
#include tunables/global
/lib/systemd/systemd-timesyncd {
I am not sure how that would be done, but this needs to handle
timesyncd being in /usr/lib/systemd as well as /lib.
Also, adding `flags=(complain)` just before the curly brace puts the
profile into complain mode by default.
#include abstractions/nameservice
capability setgid,
capability setuid,
capability sys_time,
capability setpcap,
/etc/ld.so.cache r,
/etc/systemd/timesyncd.conf r,
/lib/systemd/systemd-timesyncd mr,
/lib/x86_64-linux-gnu/libattr.so.* mr,
/lib/x86_64-linux-gnu/libc-*.so mr,
/lib/x86_64-linux-gnu/libcap.so.* mr,
/lib/x86_64-linux-gnu/libm-*.so mr,
/lib/x86_64-linux-gnu/libnsl-*.so mr,
/lib/x86_64-linux-gnu/libpthread-*.so mr,
/lib/x86_64-linux-gnu/libresolv-*.so mr,
Use the variable `@{multiarch}` in place of `x86...`. Also, it is
probably desirable to add `{,usr/}` between the / and lib in these
lines for distros like Arch that have made the /usr merge.
/proc/cmdline r,
/proc/sys/kernel/random/boot_id r,
@{PROC} rather than /proc, so `@{PROC/cmdline r,`.
/run/systemd/netif/state r,
I have seen compatibility for pre-/run distros (i.e. adding `{,var/}`
before the run but after the slash), but probably not relevant for a
systemd daemon.
/var/lib/systemd/clock w,
}
Then post to appar...@lists.ubuntu.com asking for a review.
Lennart: if you really want to test the profile, you just need to spin
up an OpenSuSE, Ubuntu, or Debian VM (on debian you need to install
and enable apparmor, which takes a short while).
Cheers,
--
Cameron Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timesyncd: tighten unit file
On Tue, 27.01.15 14:58, Cameron Norman (camerontnor...@gmail.com) wrote: On Tue, Jan 27, 2015 at 1:16 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 27.01.15 19:47, Topi Miettinen (toiwo...@gmail.com) wrote: I'm not sure. Shouldn't we then ship a SELinux policy file then? Would you be interested in AppArmor profile for timesyncd, I have one? Also, if a distro uses weird SELinux policies or setuid helpers at every possible opportunity, shouldn't they have some responsibility of fixing their setup? Well, SELinux policy is managed in a central selinux policy database that is shipped in one big RPM. My selinux-fu is not good enough to maintain the policy file in systemd, and i am not sure this even is generic enough to be able to ship the same selinux policy that works across all distros that do selinux. If Apparmor policies are standardized and stand-alone enough, and there's a clear way to install them, and you are willing to look after it, then yes, I'd merge a patch that adds apparmor profiles to systemd upstream. A good idea would be to set the apparmor profile(s) to warn-only mode for some period of time, and then let distros patch (this would be a one liner) that to be in enforce mode if they want to test it out. One possible issue is that AppArmor profiles are installed in /etc. Will that be a problem WRT the whole stateless system initiative, or is it an acceptable exception to the only comments in /etc rule? Well, there's support for copying data from /usr to /etc on first boot using tmpfile's C lines. However, that's supposed to be used only as temporarily glue. Ideally all softare would work fine without /etc around and do the right thing on its own. Also, apparmor probably should operate before tmpfiles has run. So yeah, apparmor working like that is not compatible withe stateless systems that shall be able to boot up without /etc around. 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] ConditionNeedsUpdate date comparison
Hi, On Tue, Jan 27, 2015 at 1:35 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 26.01.15 14:00, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, condition_test_needs_update() wants the timestamp of /usr to be newer than what is being checked. Is there a reason why we don't check for /usr != Condition.parameter? Well, when I hacked that up, I didn't think of this case. What are you saying ConditionNeedsUpdate=/usr is supposed to even mean? We are not on the same page. I never meant ConditionNeedsUpdate=/usr. Not that we explicitly document that /etc and /var are the only valid parameters currently (because we only manage those stamp files with systemd-update-done.service). Hence, ConditionNeedsUpdate=/usr is undefined currently, and it's not clear to me what is should mean? It makes sense to check for /usr Condition.parameter in a package managed linux but our embedded system is upgrading the entire /usr partition. ConditionNeedsUpdate=/etc is working fine when we upgrade our image but it fails when we downgrade it since the timestamp of /usr is older than /etc/.updated. Well, this stuf is not intended to support downgrades. I don't think that can ever work... But anyway, I don't really understand what you are trying to say I must admit. Could you please elaborate? Sure. Pretty much what I am saying is we wan't to use ConditionNeedsUpdate=/etc for downgrade case. Why do you think it won't work? Instead of IF time(/usr) time(/etc/.updated), we can check IF time(/usr) != time(/etc/.updated). Umut 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-commits] src/journal
On Wed, 28.01.15 03:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Wed, Jan 28, 2015 at 01:53:17AM +0100, Lennart Poettering wrote: On Mon, 19.01.15 10:43, Zbigniew Jędrzejewski-Szmek (zbys...@kemper.freedesktop.org) wrote: src/journal/journalctl.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) New commits: commit 40f0b71b063da6a36b8d7ec75ef20103abd18243 Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl Date: Mon Jan 19 13:42:34 2015 -0500 journalctl: trim --help to fit in 80 columns Terminals tend to be 80 columns wide by default, and the help text is only supposed to be a terse reminder anyway. Hmm, maybe we should add a test target to the makefile that runs all our tools with --help and checks that the output it generates is identical to the output pssed through fold -w 79 or so? (I added this to the TODO list for now) Done. Hmm, your commit checks for 80 chars, right? Shouldn't we rather check for 79? Many terminals that are 80 chars wide will leave one line free if you output 80 consecutive chars plus one newline... 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-commits] src/journal
On Wed, Jan 28, 2015 at 03:50:42AM +0100, Lennart Poettering wrote: On Wed, 28.01.15 03:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Wed, Jan 28, 2015 at 01:53:17AM +0100, Lennart Poettering wrote: On Mon, 19.01.15 10:43, Zbigniew Jędrzejewski-Szmek (zbys...@kemper.freedesktop.org) wrote: src/journal/journalctl.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) New commits: commit 40f0b71b063da6a36b8d7ec75ef20103abd18243 Author: Zbigniew J??drzejewski-Szmek zbys...@in.waw.pl Date: Mon Jan 19 13:42:34 2015 -0500 journalctl: trim --help to fit in 80 columns Terminals tend to be 80 columns wide by default, and the help text is only supposed to be a terse reminder anyway. Hmm, maybe we should add a test target to the makefile that runs all our tools with --help and checks that the output it generates is identical to the output pssed through fold -w 79 or so? (I added this to the TODO list for now) Done. Hmm, your commit checks for 80 chars, right? Shouldn't we rather check for 79? Many terminals that are 80 chars wide will leave one line free if you output 80 consecutive chars plus one newline... Are you sure? I though this was fixed already. A quick test with the linux console, urxvt, konsole, systemd-subterm, and xterm all DTRT. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Mon, Jan 26, 2015 at 10:08:02AM +0100, Martin Pitt wrote: Peter Mattern [2015-01-23 14:03 +0100]: According to man (http://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html, see section Description) systemd-gpt-auto-generator is supposed to behave like this by now already. Supposed yes, but I don't see anything in gpt-auto-generator.c which would actually check fstab. The only check I see is path_is_mount_point() in probe_and_add_mount(), but as the generators all run during very early boot where most of the mounts did not happen yet, this doesn't help. What the man page really means is that if you have a units with the same name, the one from the generator will have lower priority. Unfortunately does not help at all for the case at hand. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored (was: failing boot start jobs delay reboot)
On Tue, Jan 27, 2015 at 10:58 PM, Felix Miata mrma...@earthlink.net wrote: Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Felix Miata wrote: Both. When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Often the start job is on account of a volume label that has been replaced, usually along with a UUID, because the clone is a partition on the same HD. Fedora is particularly frustrating by embedding dependent root volume label and not obeying root= on cmdline (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run dracut. Hmm, Fedora doesn't obey root=? That sounds like a bug. I'm not sure what it means, Fedora doesn't obey root=. Since a long time it uses root=UUID= and this has worked for me. I think it's only a problem due to Fedora's configuration of its Dracut hostonly option used by default. AFAICR, its rescue initrds have always worked. The problem(s) with Fedora rescue initramfs: 1. It behaves differently depending on whether its /lib/modules have been deleted because the originally installed kernel has been removed due to yum.conf installonly_limit=3 being reached. If deleted, user gets dropped to a dracut prompt. And if not they get a complete boot to a login prompt. It's better than a kernel panic, but the inconsistency is not a good UX. 2. rescue is a generic term, but this nohostonly initramfs is really meant to get a close to full boot when changing hardware such that the hostonly initramfs does't work. So the use case is not really rescue. 3. A user might think rescue is for fsck or something basic. But that can be done with rd.break=cmdline it doesn't require the rescue initramfs. 4. Confusion with rescue.target and emergency.target. Both of which require a root password, and Fedora now doesn't require a root password at install or setup time, so the user can actually get stuck being unable to access rdsosreport.txt because they can't login. So... it's slightly ickey right now for these edge cases. Anyway, room for improvement. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, Jan 27, 2015 at 8:19 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: You also need swap if you want to use all of your memory. If you have no swap, allocating close to 100% RAM becomes very dangerous, because any overflow will result in oom. Yes that makes sense too. Maybe zram will work out such that it effectively slows things to a craw until pressure instead of implosion, and swap on disk can mostly be obviated for the ordinary cases. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Swap gets activated twice (through fstab and gpt generators)
On Tue, Jan 27, 2015 at 10:25:32PM -0700, Chris Murphy wrote: On Tue, Jan 27, 2015 at 8:19 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: You also need swap if you want to use all of your memory. If you have no swap, allocating close to 100% RAM becomes very dangerous, because any overflow will result in oom. Yes that makes sense too. Maybe zram will work out such that it effectively slows things to a craw until pressure instead of implosion, and swap on disk can mostly be obviated for the ordinary cases. Certainly not for all cases. zram can give compression on the order of 50% max, so it allows you to trade some CPU for RAM, but does not help at all for the case I described, since my data is noncompressible and cpus are maxed out anyway. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored (was: failing boot start jobs delay reboot)
Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Felix Miata wrote: Both. When they occur during init they repeat during shutdown. Even when I let init complete and succeed to fix the typo or oversight, the init failure gets remembered and repeated at shutdown. Often the start job is on account of a volume label that has been replaced, usually along with a UUID, because the clone is a partition on the same HD. Fedora is particularly frustrating by embedding dependent root volume label and not obeying root= on cmdline (openSUSE obeys root=). Those typos usually have to be fixed by chroot to run dracut. Hmm, Fedora doesn't obey root=? That sounds like a bug. I think it's only a problem due to Fedora's configuration of its Dracut hostonly option used by default. AFAICR, its rescue initrds have always worked. I can't remember now, but it may possibly be Mageia with hostonly enabled disobeys root= too, locking onto root's UUID when the initrd was built. It's never been a problem I've observed in openSUSE, which let dracut evolve a lot longer before switching to it from mkinitrd. Harald? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 2/2] systemd.service(5): add some simple examples
Add a couple of exampels, at least one for each service type that include some explanations and pointers to various relevant options. --- man/systemd.service.xml | 332 1 file changed, 332 insertions(+) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 4c890df..5ccbba0 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -1358,6 +1358,338 @@ ExecStart=/bin/echo $ONE $TWO $THREE/programlisting /refsect1 refsect1 +titleExamples/title + +example +titleSimple service/title + +paraThe following unit file creates a service +that will execute +filename/usr/sbin/foo-daemon/filename. +Since no varnameType=/varname is specified, +the default +varnameType=/varnameoptionsimple/option +will be assumed. systemd will assume the unit +to be started immediately after the program has +begun executing./para + +programlisting[Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +[Install] +WantedBy=multi-user.target/programlisting + +paraNote that systemd assumes here that the +program will continue running in the foreground +as long as it's active. If the program +backgrounds/daemonizes/forks itself, please use +varnameType=/varnameoptionforking/option +instead./para + +paraSince no varnameExecStop=/varname was +specified, systemd will send SIGTERM to all +processes started from this service, and after +a timeout also SIGKILL. This behavior can be +modified, see + citerefentryrefentrytitlesystemd.kill/refentrytitlemanvolnum5/manvolnum/citerefentry +for details./para + +paraNote that this unit type does not include +any type of notification when a service has +completed initialization. For this, you should +use other unit types, such as +varnameType=/varnameoptionnotify/option +if the service understands systemd's +notification protocol, +varnameType=/varnameoptionforking/option +if the service can background itself or +varnameType=/varnameoptiondbus/option +if the unit acquires a DBus name once +initialization is complete. See below./para +/example + +example +titleOneshot service/title + +paraSometimes units should just execute an +action without keeping active processes, such +as a filesystem check or a cleanup action on +boot. For this, +varnameType=/varnameoptiononeshot/option +exists. Units of this type will wait until the +process specified terminates and then fall back +to being inactive. The following unit will +perform a clenaup action:/para + +programlisting[Unit] +Description=Cleanup old Foo data + +[Service] +Type=oneshot +ExecStart=/usr/sbin/foo-cleanup + +[Install] +WantedBy=multi-user.target/programlisting + +paraNote that systemd will consider the unit +to be in the state 'starting' until the program +has terminated, so ordered dependencies will +wait for the program to finish before starting +themselves. The unit will revert to the +'inactive' state after the execution is +done. That means another request to start the +unit will perform the action again./para +/example + +example +titleStoppable oneshot service/title + +paraSimilarly to the oneshot services, there +are sometimes units that need to execute a +program to set up something and then execute +another to shut it down, but no process remains +active while they are considered +'started'. Network configuration can sometimes +fall into this
[systemd-devel] [PATCH v2 1/2] systemd.unit(5): add examples for common tasks
Add examples for (a) making units enableable and (b) overriding vendor settings to the man page. --- man/systemd.unit.xml | 164 +++ 1 file changed, 164 insertions(+) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index e820b33..8714f70 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -1574,6 +1574,170 @@ /refsect1 refsect1 +titleExamples/title + +example +titleMaking a unit enableable/title + +paraThe following snippet (highlighted) makes +a unit (e.g. filenamefoo.service/filename) +enableable via +commandsystemctl enable/command:/para + +programlisting[Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +emphasis[Install]/emphasis +emphasisWantedBy=multi-user.target/emphasis/programlisting + +paraAfter running +commandsystemctl enable/command, a symlink + filename/etc/systemd/system/multi-user.target.wants/foo.service/filename +linking to the actual unit will be created. It +tells systemd to pull in the unit when starting +filenamemulti-user.target/filename. The +converse commandsystemctl disable/command +will remove that symlink again./para +/example + +example +titleOverriding vendor settings/title + +paraThere are two methods of overriding +vendor settings in unit files: copying the unit +file from +filename/usr/lib/systemd/system/filename +to filename/etc/systemd/system/filename and +modifying the chosen settings. Alternatively, +one can create a directory named +filenamereplaceableunit/replaceable.d//filename +within +filename/etc/systemd/system/filename and +place a drop-in file + filenamereplaceablename/replaceable.conf/filename +there that only changes the specific settings +one is interested in. Note that multiple such +drop-in files are read if present./para + +paraThe advantage of the first method is +that one easily overrides the complete unit, +the vendor unit is not parsed at all anymore. +It has the disadvantage that improvements to +the unit file by the vendor are not +automatically incorporated on updates./para + +paraThe advantage of the second method is +that one only overrides the settings one +specifically wants, where updates to the unit +by the vendor automatically apply. This has the +disadvantage that some future updates by the +vendor might be incompatible with the local +changes./para + +paraNote that for drop-in files, if one wants +to remove entries from a setting that is parsed +as a list (and is not a dependency), such as +varnameConditionPathExists=/varname (or +e.g. varnameExecStart=/varname in service +units), one needs to first clear the list +before re-adding all entries except the one +that is to be removed. See below for an +example./para + +paraThis also applies for user instances of +systemd, but with different locations for the +unit files. See the section on unit load paths +for further details./para + +paraSuppose there is a vendor-supplied unit + filename/usr/lib/systemd/system/httpd.service/filename +with the following contents:/para + +programlisting[Unit] +Description=Some HTTP server +After=network.target remote-fs.target sqldb.service +Requires=sqldb.service +ConditionPathExists=/srv/webserver + +[Service] +Type=notify +ExecStart=/usr/sbin/some-fancy-httpd-server +TimeoutStartSec=5 + +[Install] +WantedBy=multi-user.target/programlisting + +paraNow one wants to change some settings as +an administrator: firstly, in the
Re: [systemd-devel] Unwants
On Tue, Jan 27, 2015 at 03:50:49PM +, Dimitri John Ledkov wrote: On 27 January 2015 at 15:18, Christian Seiler christ...@iwakd.de wrote: Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Additionally, not considering .wants/ but drop-ins: currently, all[*] lists except dependencies can be overridden in drop-ins by resetting them first. So if I write ConditionPathExists=/foo in the unit file, and then ConditionPathExists= ConditionPathExists=/bar in a snippet, that will work as expected. Not so for dependencies. The problem here is I think a bit in the parsing logic: when parsing a unit file, dependencies are immediately added to the unit in question. If you were to first collect them as a set and then only after all drop-ins / etc. of a unit file are parsed you would add them to the unit's dependencies, this would immediately solve the problem. Also note that if b.service as Before=a.service, I would NOT expect and empty After= in a.service to override that, it would be weird. This is another good reason to first collect stuff locally (and only do overrides on that level) before adding the global state at the end of parsing. Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. Just my 2 cents. Well i thought that if below are implemented: http://lists.freedesktop.org/archives/systemd-devel/2014-December/026026.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026042.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026076.html Yeah, I think I dozed off at the of that discussion there, thank you for digging up the links. It seems everybody is in agreement about overriding .wants/.requires symlinks with /dev/null. ... Whilst: bar.service: [Unit] Wants=!foo.service foo.service: [Install]WantedBy=!bar But this isn't in the mails you linked. Let's get the link-overriding part done first. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation
On Tue, Jan 27, 2015 at 05:33:06PM +0100, Martin Pitt wrote: Lennart Poettering [2015-01-27 17:22 +0100]: The .mount units of device nodes already have a BindsTo= dependency on their respective backing .device units. This should have the effect that systemd will take the .mount units down if the .device units are removed. Are you saying that doesn't work? It's been ages since I've had a CD drive with an eject button, so I can't say myself. But given the recent reports on the list from Robert Milasan and Dave Reiser it seems that *something* here is still broken? Well, my test case was flawed and the mount namespacing in udevd isn't actually relevant to the problem. I've since found myself uninterested in solving this particular problem. dR ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation
On Tue, 27.01.15 09:40, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey Lennart, Lennart Poettering [2015-01-27 0:55 +0100]: Hmm? I don't see how mount propagation would break 60-cdrom_id... The eject ioctl operates on the device node, and does not care for mounts. This problem sounds made-up to me. Right now cdrom_id indeed wouldn't be affected as it doesn't unmount a CD which is about to ejected. That's the very problem that was recently discussed here: http://lists.freedesktop.org/archives/systemd-devel/2015-January/026948.html The two proposed solutions were to either teach cdrom_id --eject to umount the device or just call the actual eject program which gets this pretty much right. But neither would work because of the unshared mount ns in udev. So, why is this a new problem, and why do you say that MountFlags=slave broke anything? I mean, cdrom_id cannot do unmounts (and it really shouldn't), And an eject invocation was never part of the udev rules, so there was really nothing that broke. So, these things never worked, and MountFlags=slave didn't change anything about it. There's some part of the story that I am missing, or something makes no sense at all... Moreover, if you want to do mounts or umounts on plug or play, then use a proper daemon, like udisks. udisks actually used to have both the CD-ROM polling (which since then moved into the kernel) and the post-eject cleanup. Why was the removed, and with what was it replaced when it was? If we want to keep the udev mount unsharing, we could put it back into udisks; but that wouldn't be that robust as udisks isn't guaranteed to actually run, both because it's a D-BUS activated service and a lot of server-ish machines or lightweight desktops don't even have it. Well, again, the right answer then is to handle it with .mount units, which can correctly deal with partitioned block devices and other file systems mounted on top of these pluggable block devices. In general though I don't think people should expect that pluggable devices are handled nicely if you uninstall the daemon that deals with pluggable devices... 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] persisting sriov_numvfs
On Tue, 27.01.15 07:35, Martin Polednik (mpoled...@redhat.com) wrote: Hmm, I see. In many ways this feels like VLAN setup from a configuration PoV, right? i.e. you have one hw device the driver creates, and then you configure a couple of additional interfaces on top of it. This of course then raises the question: shouldn't this functionality be exposed by the kernel the same way as VLANs? i.e. with a rtnetlink-based API to create additional interfaces, instead of /sys? In systemd I figure the right way to expose this to the user would be via .netdev files, the same way as we expose VLAN devices. Not however that that would be networkd territory, No, this is not limited to NICs. It is generic feature that can be in principle used with any hardware and there are e.g. FC or FCoE HBAs with SR-IOV support. It is true that today it is mostly comes with NICs though. Any general framework for setting it up should not be tied to specific card type. Well, I doubt that there will be graphics cards that support this right? I mean, it's really only network connectivity that can support a concept like this easily, since you can easily merge packet streams from multiple VMs on one connection. However, I am not sure how you want to physically merge VGA streams onto a single VGA connector... If this is about ethernet, FC, FCOE, then I still think that the network management solution should consider this as something you can configure on physical links like VLANs. Hence networkd or NetworkManager and so on should cover it. Lennart Afaik some storage cards support this, for GPU's it's possibly for the GPUPU applications and such - where you don't care about the physical output, but the processing core of gpu itself (but I'm not aware of such implementation yet, nvidia seems to be doing something but the details are nowhere to be found). Hmm, so there are three options I think. a) Expose this in networkd .netdev files, as I suggested originally. This would be appropriate if we can add and remove VFs freely any time, without the other VFs being affected. Can you clarify whether going from let's say 4 to 5 VFs requires removing all VFs and recreating them? THis would be the nicest exposure I think, but be specific to networkd. b) Expose this via udev .link files. This would be appropriate if adding/removing VFs is a one-time thing, when a device pops up. This would be networking specific, not cover anything else like GPU or storage or so. Would still be quite nice. Would probably the best option, after a), if VFs cannot be added/removed dynamically all the time without affecting the other VFs. c) Expose this via udev rules files. This would be generic, would work for networking as well as GPUs or storage. This would entail writing our rules files when you want to configure the number of VFs. Care needs to be taken to use the right way to identify devices as they come and go, so that you can apply configuration to them in a stable way. This is somewhat uglier, as we don't really think that udev rules should be used that much for configuration, especially not for configuration written out by programs, rather than manually. However, logind already does this, to assign seat identifiers to udev devices to enable multi-seat support. A combination of b) for networking and c) for the rest might be an option too. 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] persisting sriov_numvfs
- Original Message - From: Lennart Poettering lenn...@poettering.net To: Andrei Borzenkov arvidj...@gmail.com Cc: Martin Polednik mpoled...@redhat.com, systemd-devel@lists.freedesktop.org, ibar...@redhat.com Sent: Tuesday, January 27, 2015 1:21:32 PM Subject: Re: [systemd-devel] persisting sriov_numvfs On Tue, 27.01.15 06:47, Andrei Borzenkov (arvidj...@gmail.com) wrote: Hmm, I see. In many ways this feels like VLAN setup from a configuration PoV, right? i.e. you have one hw device the driver creates, and then you configure a couple of additional interfaces on top of it. This of course then raises the question: shouldn't this functionality be exposed by the kernel the same way as VLANs? i.e. with a rtnetlink-based API to create additional interfaces, instead of /sys? In systemd I figure the right way to expose this to the user would be via .netdev files, the same way as we expose VLAN devices. Not however that that would be networkd territory, No, this is not limited to NICs. It is generic feature that can be in principle used with any hardware and there are e.g. FC or FCoE HBAs with SR-IOV support. It is true that today it is mostly comes with NICs though. Any general framework for setting it up should not be tied to specific card type. Well, I doubt that there will be graphics cards that support this right? I mean, it's really only network connectivity that can support a concept like this easily, since you can easily merge packet streams from multiple VMs on one connection. However, I am not sure how you want to physically merge VGA streams onto a single VGA connector... If this is about ethernet, FC, FCOE, then I still think that the network management solution should consider this as something you can configure on physical links like VLANs. Hence networkd or NetworkManager and so on should cover it. Lennart Afaik some storage cards support this, for GPU's it's possibly for the GPUPU applications and such - where you don't care about the physical output, but the processing core of gpu itself (but I'm not aware of such implementation yet, nvidia seems to be doing something but the details are nowhere to be found). -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persisting sriov_numvfs
On Tue, 27.01.15 06:47, Andrei Borzenkov (arvidj...@gmail.com) wrote: Hmm, I see. In many ways this feels like VLAN setup from a configuration PoV, right? i.e. you have one hw device the driver creates, and then you configure a couple of additional interfaces on top of it. This of course then raises the question: shouldn't this functionality be exposed by the kernel the same way as VLANs? i.e. with a rtnetlink-based API to create additional interfaces, instead of /sys? In systemd I figure the right way to expose this to the user would be via .netdev files, the same way as we expose VLAN devices. Not however that that would be networkd territory, No, this is not limited to NICs. It is generic feature that can be in principle used with any hardware and there are e.g. FC or FCoE HBAs with SR-IOV support. It is true that today it is mostly comes with NICs though. Any general framework for setting it up should not be tied to specific card type. Well, I doubt that there will be graphics cards that support this right? I mean, it's really only network connectivity that can support a concept like this easily, since you can easily merge packet streams from multiple VMs on one connection. However, I am not sure how you want to physically merge VGA streams onto a single VGA connector... If this is about ethernet, FC, FCOE, then I still think that the network management solution should consider this as something you can configure on physical links like VLANs. Hence networkd or NetworkManager and so on should cover it. 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] Unwants
On Thu, 22.01.15 14:08, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: In any case, /etc overrides /run, so your example can never work. Oh, ok. But any combination of the two. E.g. for /etc to unwant from /run then, or for /etc to unwant from /usr. At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it I am not grokking this. If you remove the package with the symlinks in /usr, then den deps are gone, so why do you need something in /etc or /run still? 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] Unwants
On Thu, 22.01.15 15:16, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 22 January 2015 at 14:46, Michael Biebl mbi...@gmail.com wrote: 2015-01-22 15:08 GMT+01:00 Dimitri John Ledkov dimitri.j.led...@intel.com: At the moment, I'm looking at packaging symlinks in .wants directories under /usr and then allow to uninstall such a package as a means to override the default config. Since I would like to update how the default config is setup, without doing in /etc where I'd have to answer is this my old config, or user modified it and I shouldn't touch it That's indeed a tough problem. The upstream recommendation is, to run systemctl preset during the initial installation. If there are changes to the default in the unit files, those changes are *not* applied on package upgrades. Presets are good, however they do not have a format to specify extra .wants and .requires. And in my case unwants and unrequires. Extra .wants and .requires? What would those entail? I mean, the unit files can store extra deps in their [Install] section... So at the moment I'm playing around with - unconditionally running preset on my preset file, and directing users to write (override) own preset file in /etc/systemd/system-preset if they want to modify the default proposed integration. I don't think that's a particularly compelling solution. In Debian, we introduced a helper called i-s-h [1], which keeps some additional state and tries to apply such changes on updates. Well, if systemctl enable/disable/add-requires/add-wants would write things into /etc/systemd/system-preset instead of modifying things in /etc, then it would be alright. As essentially the full set of presets would be the state of system-defaults + user overrides. Also it seems like preset is a bit of templating hack at the moment, as they are not loaded by systemd but rarther are simply used to generate files/symlinks on disk under /etc. I don't follow. Presets are the recommended vendor configuration, and as such static and immutable. It is supposed to be applied once, during first installation of a pacakge. From that point on things are user configuration and presets will not be applied. Patching preset files during runtime is really against what they were designed for. Quite frankly, I have trouble following at all what is being attempted here... 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] Unwants
On 27 January 2015 at 15:18, Christian Seiler christ...@iwakd.de wrote: Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Additionally, not considering .wants/ but drop-ins: currently, all[*] lists except dependencies can be overridden in drop-ins by resetting them first. So if I write ConditionPathExists=/foo in the unit file, and then ConditionPathExists= ConditionPathExists=/bar in a snippet, that will work as expected. Not so for dependencies. The problem here is I think a bit in the parsing logic: when parsing a unit file, dependencies are immediately added to the unit in question. If you were to first collect them as a set and then only after all drop-ins / etc. of a unit file are parsed you would add them to the unit's dependencies, this would immediately solve the problem. Also note that if b.service as Before=a.service, I would NOT expect and empty After= in a.service to override that, it would be weird. This is another good reason to first collect stuff locally (and only do overrides on that level) before adding the global state at the end of parsing. Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. Just my 2 cents. Well i thought that if below are implemented: http://lists.freedesktop.org/archives/systemd-devel/2014-December/026026.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026042.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026076.html the logic would be: bar.service: [Unit] Wants=foo.service foo.service: [Install]WantedBy=bar bar.service.wants/foo.service - ***/foo.service Add a dependency type want from bar - to foo. Whilst: bar.service: [Unit] Wants=!foo.service foo.service: [Install]WantedBy=!bar bar.service.wants/foo.service - /dev/null Would remove a dependency link from bar - to foo, if and only if it already exists. The ! syntax is for e.g. overriding symlinks via .d/*.conf files or when unit is copied into a higher level configuration path and edited. Thus everything is still coalescing, in the order that configuration directories are transversed, but proposed to be additive and subtractive in nature. (and will thus allow adding/removing dependencies at each configuration level) e.g. distro ships user level unit that gpg-agent is enabled by default in the user sessions global user override by admin sets gnome-keyring to be the default agent for user sessions (Wants=gnome-keyring-gpg !gpg-agent) user overrides the admin to make gpg-agent enabled by default back (Wants=!gnome-keyring-gpg gpg-agent) where wants are either .d snippets with lines as in brackets or (valid | dev-null) symlinks in appropriate .wants directories at respective configuration levels. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation
Lennart Poettering [2015-01-27 13:52 +0100]: So, why is this a new problem, and why do you say that MountFlags=slave broke anything? I didn't say that. :-) I just said that due to this the two proposed solutions of cleaning up the mounts after CD ejection won't work. I mean, cdrom_id cannot do unmounts (and it really shouldn't), And an eject invocation was never part of the udev rules, so there was really nothing that broke. So, these things never worked, and MountFlags=slave didn't change anything about it. Correct. udisks actually used to have both the CD-ROM polling (which since then moved into the kernel) and the post-eject cleanup. Why was the removed, and with what was it replaced when it was? So udisks 1.x had a force_removal() function which was called on a remove uevent and cleaned up stale mounts. Apparenlty that never made it into the udisks 2.x rewrite unless I'm missing something. But as it obviously doesn't seem to work right now (i. e. CD mounts are kept stale), I guess it's due to that. Well, again, the right answer then is to handle it with .mount units, How would that look like, on a very high level? Create .mount units on the fly with udev rules when devices appear, and asking systemd to unmount them via a remove uevent, instead of having cdrom_id do the umount directly? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Examples in man pages
On Tue, Jan 27, 2015 at 03:19:51PM +0100, Christian Seiler wrote: Just a heads-up: while reading the Unwants thread I noticed that dependencies are the only types of lists in unit files that can't be reset, so my example in there actually doesn't work, so please don't commit my patch just now. I'm writing more examples and will resubmit anyway. So the thread is still on... Things are likely to change again. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] persisting sriov_numvfs
On Tue, 27.01.15 08:41, Martin Polednik (mpoled...@redhat.com) wrote: b) Expose this via udev .link files. This would be appropriate if adding/removing VFs is a one-time thing, when a device pops up. This would be networking specific, not cover anything else like GPU or storage or so. Would still be quite nice. Would probably the best option, after a), if VFs cannot be added/removed dynamically all the time without affecting the other VFs. c) Expose this via udev rules files. This would be generic, would work for networking as well as GPUs or storage. This would entail writing our rules files when you want to configure the number of VFs. Care needs to be taken to use the right way to identify devices as they come and go, so that you can apply configuration to them in a stable way. This is somewhat uglier, as we don't really think that udev rules should be used that much for configuration, especially not for configuration written out by programs, rather than manually. However, logind already does this, to assign seat identifiers to udev devices to enable multi-seat support. A combination of b) for networking and c) for the rest might be an option too. I myself would vote for b) + c) since we want to cover most of the possible use cases for SR-IOV and MR-IOV, which hopefully shares the interface; adding Dan back to CC as he is the one to speak for network. I have added b) to our TODO list for networkd/udev .link files. c) should probably be done outside of systemd/udev. Just write a tool (or even documenting this might suffice), that creates udev rules in /etc/udev/rules.d, matches against ID_PATH and then sets the right attribute. 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] Unwants
On 27 January 2015 at 16:47, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Jan 27, 2015 at 03:50:49PM +, Dimitri John Ledkov wrote: On 27 January 2015 at 15:18, Christian Seiler christ...@iwakd.de wrote: Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Additionally, not considering .wants/ but drop-ins: currently, all[*] lists except dependencies can be overridden in drop-ins by resetting them first. So if I write ConditionPathExists=/foo in the unit file, and then ConditionPathExists= ConditionPathExists=/bar in a snippet, that will work as expected. Not so for dependencies. The problem here is I think a bit in the parsing logic: when parsing a unit file, dependencies are immediately added to the unit in question. If you were to first collect them as a set and then only after all drop-ins / etc. of a unit file are parsed you would add them to the unit's dependencies, this would immediately solve the problem. Also note that if b.service as Before=a.service, I would NOT expect and empty After= in a.service to override that, it would be weird. This is another good reason to first collect stuff locally (and only do overrides on that level) before adding the global state at the end of parsing. Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. Just my 2 cents. Well i thought that if below are implemented: http://lists.freedesktop.org/archives/systemd-devel/2014-December/026026.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026042.html http://lists.freedesktop.org/archives/systemd-devel/2014-December/026076.html Yeah, I think I dozed off at the of that discussion there, thank you for digging up the links. It seems everybody is in agreement about overriding .wants/.requires symlinks with /dev/null. cool. ... Whilst: bar.service: [Unit] Wants=!foo.service foo.service: [Install]WantedBy=!bar But this isn't in the mails you linked. Let's get the link-overriding part done first. Yeah, that's my new proposal as extension to above, to keep .d as capable as .wants/.requires. Sure, I'll keep this open for discussion/agreement and will not be implementing just yet. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
