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