Re: [systemd-devel] [ANNOUNCE] systemd v218

2015-02-04 Thread Simon McVittie

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

2015-02-03 Thread Lennart Poettering
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

2015-02-03 Thread Lennart Poettering
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

2014-12-14 Thread Mike Gilbert
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

2014-12-14 Thread Dave Reisner
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

2014-12-12 Thread Matthias Urlichs
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

2014-12-12 Thread J├│hann B. Gu├░mundsson


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

2014-12-10 Thread Lennart Poettering
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,