Re: [systemd-devel] [ANNOUNCE] systemd v218
On 03/02/15 23:43, Lennart Poettering wrote: The way I understand /usr/local, it is the place where the admin himself places his own scripts and stuff, as extensions for the host OS. Yes, that view is consistent with the FHS (and e.g. Debian Policy's interpretation of the FHS). ./configure --prefix=/usr/local is meant to mostly work for most software, which means it should be possible to hook into systemd, dbus-daemon, etc. by dropping files into /usr/local. The way I understand /usr/local, it is the place where the admin himself places his own scripts and stuff, as extensions for the host OS. Where /opt is the stuff for 3rd party apps (app vendors), and /usr is for 2nd party stuff (OS vendor), /usr/local is for 1st party stuff (admin). That's one version. Many OSs (including Debian and derivatives) have a slightly different interpretation where /usr is the system package manager's territory, regardless of whether the package came from Debian or not - things that came in a .deb go in /usr or occasionally /opt, while things that the sysadmin installed by hand go in /usr/local or occasionally /opt. Installing a .deb is allowed to have arbitrary effects on /usr (subject to the usual policies about not breaking/overwriting other packages without the metadata saying so), but the only thing it's allowed to do in /usr/local is to create/remove empty directories in the maintainer scripts. On Fri, 12.12.14 14:25, Colin Guthrie (gm...@colin.guthr.ie) wrote: It feels very, very odd that /usr/local is being parsed at all here when the --prefix arg does not include it. There's plenty of precedent for including /usr/local/bin in $PATH, /usr/local/share/FOO in search paths, etc., usually before /usr so that local sysadmin changes can override what's provided in the OS. This comes with the obvious caveat that if the local sysadmin breaks things by installing incompatible versions in /usr/local, they get to solve it for themselves. The distinction between modules installed in /usr/local for software also installed in /usr/local and modules installed in /usr/local for software installed in /usr is not new either: in Debian and its derivatives, Python from python.deb looks for modules in .../dist-packages instead of the usual .../site-packages, so that .../site-packages can be reserved for modules that will be loaded into a copy of Python that the sysadmin installed from source. https://wiki.debian.org/Python#Deviations_from_upstream If the were experimenting, but ultimately didn't want to use it, it seems odd to me that the actual packaged version of system would read these files. If they were experimenting with a new version of thermald (picking a random example of something that I have installed in /usr/local in the past), but systemd didn't pick it up, that would be a fairly useless experiment, since it wouldn't actually start :-) If they were experimenting with it but decided not to keep it, that's a good time to remove it from /usr/local. Sysadmins who use /usr/local should really be looking at something like GNU stow to automate installation/removal (or preferably building their local stuff into a .deb/.rpm, at which point it can be in /usr instead). The whole thing is really not thought to the end though. Some folks have /usr/local on NFS, which we cannot handle, since we'll look into it already before NFS is mounted for some things, and never check it again... I think in general this should work, but your configuration is not a supported one is an acceptable response to that, tbh. If a sysadmin wants this badly enough, they can put a hook in their initramfs to mount /usr/local. -- Simon McVittie Collabora Ltd. http://www.collabora.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v218
On Fri, 12.12.14 14:25, Colin Guthrie (gm...@colin.guthr.ie) wrote: Lennart Poettering wrote on 11/12/14 00:16: * All systemd programs that read standalone configuration files in /etc now also support a corresponding series of .conf.d configuration directories in /etc/, /run/, /usr/local/lib/, /usr/lib/, and (if configured with --enable-split-usr) /lib/. In particular, the following configuration files now have corresponding configuration directories: system.conf user.conf, logind.conf, journald.conf, sleep.conf, bootchart.conf, coredump.conf, resolved.conf, timesyncd.conf, journal-remote.conf, and journal-upload.conf. Note that distributions should use the configuration directories in /usr/lib/; the directories in /etc/ are reserved for the system administrator. Hmmm, at what point is /usr/local/lib/systemd/journald.conf.d/foo.conf read? Does the journal start only after all local filesystems are mounted, I don't see anything that ensures this in the .service or .socket files for it (same applies to other tools, but journal is probably most at risk because it's started early with DefaultDependencies=no) It feels very, very odd that /usr/local is being parsed at all here when the --prefix arg does not include it. I mean this kinda conflicts with users doing their own compiles with --prefix=/usr/local and installing stuff there... If the were experimenting, but ultimately didn't want to use it, it seems odd to me that the actual packaged version of system would read these files. What's the argument for including /usr/local in all this stuff? Feels wrong to me. Well, /usr/local has very unclear semantics. Installing something into /usr/local if the stuff is never included in any search paths makes it pretty useless. The way I understand /usr/local, it is the place where the admin himself places his own scripts and stuff, as extensions for the host OS. Where /opt is the stuff for 3rd party apps (app vendors), and /usr is for 2nd party stuff (OS vendor), /usr/local is for 1st party stuff (admin). The whole thing is really not thought to the end though. Some folks have /usr/local on NFS, which we cannot handle, since we'll look into it already before NFS is mounted for some things, and never check it again... Note that even though this is not thought to the end, the current behaviour is perfectly in line with what the XDG basedir spec suggests, which says that /usr/local should be included in the search paths for things... So far we always included it. I can see reasons to keep it that way, I can see reasons way not including might also be a good choice. Currently I don't see strong enough reasons to make the change though. 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] [ANNOUNCE] systemd v218
On Fri, 12.12.14 15:57, Matthias Urlichs (matth...@urlichs.de) wrote: Hi, Colin Guthrie: What's the argument for including /usr/local in all this stuff? Feels wrong to me. +ME_TOO. /usr/local frequently has wider permissions than reasonable for something that can affect system startup. I can think of one argument in favor of this -- you can modify the system default that way, without touching /etc, so this would add local modifications to an image which you then use for system initialization. However, you can do the same thing by adding appropriate *.conf files to /usr/lib/systemd/**. /usr is OS vendor territory. /usr/local is admin territory. The admin should not modify /usr, ever. 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] [ANNOUNCE] systemd v218
On Wed, Dec 10, 2014 at 7:16 PM, Lennart Poettering lenn...@poettering.net wrote: Heya! Here's the next version of systemd, v218: http://www.freedesktop.org/software/systemd/systemd-218.tar.xz Hi Lennart, It looks like the tarball is missing units/user/systemd-consoled.service. make[2]: *** No rule to make target 'units/user/systemd-consoled.service.in', needed by 'units/user/systemd-consoled.service'. Stop. Please make sure you configure with --enable-terminal when creating the tarball. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v218
On Sun, Dec 14, 2014 at 10:32:42AM -0500, Mike Gilbert wrote: On Wed, Dec 10, 2014 at 7:16 PM, Lennart Poettering lenn...@poettering.net wrote: Heya! Here's the next version of systemd, v218: http://www.freedesktop.org/software/systemd/systemd-218.tar.xz Hi Lennart, It looks like the tarball is missing units/user/systemd-consoled.service. make[2]: *** No rule to make target 'units/user/systemd-consoled.service.in', needed by 'units/user/systemd-consoled.service'. Stop. Please make sure you configure with --enable-terminal when creating the tarball. Thanks for the report. Should be fixed in git. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v218
Hi, Colin Guthrie: What's the argument for including /usr/local in all this stuff? Feels wrong to me. +ME_TOO. /usr/local frequently has wider permissions than reasonable for something that can affect system startup. I can think of one argument in favor of this -- you can modify the system default that way, without touching /etc, so this would add local modifications to an image which you then use for system initialization. However, you can do the same thing by adding appropriate *.conf files to /usr/lib/systemd/**. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v218
On 12/12/2014 02:57 PM, Matthias Urlichs wrote: Hi, Colin Guthrie: What's the argument for including /usr/local in all this stuff? Feels wrong to me. +ME_TOO. /usr/local frequently has wider permissions than reasonable for something that can affect system startup. I can think of one argument in favor of this -- you can modify the system default that way, without touching /etc, so this would add local modifications to an image which you then use for system initialization. However, you can do the same thing by adding appropriate *.conf files to /usr/lib/systemd/**. I'm jumping on this bandwagon of agreements as well. Supporting this makes no sense... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd v218
Heya! Here's the next version of systemd, v218: http://www.freedesktop.org/software/systemd/systemd-218.tar.xz Many many bug fixes, some new features, and a lot of code cleanups! CHANGES WITH 218: * When querying unit file enablement status (for example via systemctl is-enabled), a new state indirect is now known which indicates that a unit might not be enabled itself, but another unit listed in its Alias= setting might be. * Similar to the various existing ConditionXYZ= settings for units there are now matching AssertXYZ= settings. While failing conditions cause a unit to be skipped, but its job to succeed, failing assertions declared like this will cause a unit start operation and its job to fail. * hostnamed now knows a new chassis type embedded. * systemctl gained a new edit command. When used on a unit file this allows extending unit files with .d/ drop-in configuration snippets or editing the full file (after copying it from /usr/lib to /etc). This will invoke the user's editor (as configured with $EDITOR), and reload the modified configuration after editing. * systemctl status now shows the suggested enablement state for a unit, as declared in the (usually vendor-supplied) system preset files. * nss-myhostname will now resolve the single-label host name gateway to the locally configured default IP routing gateways, ordered by their metrics. This assigns a stable name to the used gateways, regardless which ones are currently configured. Note that the name will only be resolved after all other name sources (if nss-myhostname is configured properly) and should hence not negatively impact systems that use the single-label host name gateway in other contexts. * systemd-inhibit now allows filtering by mode when listing inhibitors. * Scope and service units gained a new Delegate boolean property, which when set allows processes running inside the unit to further partition resources. This is primarily useful for systemd user instances as well as container managers. * journald will now pick up audit messages directly from the kernel, and log them like any other log message. The audit fields are split up and fully indexed. This means that journalctl in many ways is now a (nicer!) alternative to ausearch, the traditional audit client. Note that this implements only a minimal audit client, if you want the special audit modes like reboot-on-log-overflow, please use the traditional auditd instead, which can be used in parallel to journald. * The ConditionSecurity= unit file option now understands the special string audit to check whether auditing is available. * journalctl gained two new commands --vacuum-size= and --vacuum-time= to delete old journal files until the remaining ones take up no more the specified size on disk, or are not older than the specified time. * A new, native PPPoE library has been added to sd-network, systemd's library of light-weight networking protocols. This library will be used in a future version of networkd to enable PPPoE communication without an external pppd daemon. * The busctl tool now understands a new capture verb that works similar to monitor, but writes a packet capture trace to STDOUT that can be redirected to a file which is compatible with libcap's capture file format. This can then be loaded in Wireshark and similar tools to inspect bus communication. * The busctl tool now understands a new tree verb that shows the object trees of a specific service on the bus, or of all services. * The busctl tool now understands a new introspect verb that shows all interfaces and members of objects on the bus, including their signature and values. This is particularly useful to get more information about bus objects shown by the new busctl tree command. * The busctl tool now understands new verbs call, set-property and get-property for invoking bus method calls, setting and getting bus object properties in a friendly way. * busctl gained a new --augment-creds= argument that controls whether the tool shall augment credential information it gets from the bus with data from /proc, in a possibly race-ful way. * nspawn's --link-journal= switch gained two new values try-guest and try-host that work like guest and host,
