Re: [systemd-devel] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

2019-05-13 Thread František Šumšal
On 5/13/19 8:20 AM, Ulrich Windl wrote:

>> "systemd‑analyze verify" exists. Since a long long time.
> 
> Not really: You can't verify a unit file while it's not "installed". Comare it
> to validating an XML file, for example.
> 

That's actually not true. The argument for `systemd-analyze verify` is a file 
name,
so you verify an arbitrary file for correctness:

$ cat > test.service << EOF
> [Unit]
> Description=test unit
> 
> [Service]
> ExecStrt=/bin/true
> EOF
$ systemd-analyze verify test.service 
File /usr/lib/systemd/system/systemd-udevd.service:26 configures an IP firewall 
(IPAddressDeny=any), but the local system does not support BPF/cgroup based 
firewalling.
Proceeding WITHOUT firewalling in effect! (This warning is only shown for the 
first loaded unit using IP firewalling.)
/tmp/./test.service:4: Unknown lvalue 'ExecStrt' in section 'Service'
test.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Unit test.service has a bad unit file setting.
$ systemctl status test.service
Unit test.service could not be found.


-- 
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

2019-05-13 Thread Reindl Harald


Am 13.05.19 um 08:20 schrieb Ulrich Windl:
>> Note that "/var/run" is a legacy alias for "/run". It's highly
>> recommended not to use the former anymore.
> 
> It it because you don't like sub-directories, or is it to save four bytes?
> ;-)


stop it - if you would have read IT news (golem/heise) the last 7 years
or so you would know about /run and why it is a top-directory

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

/run

Run-time variable data: Information about the running system since last
boot, e.g., currently logged-in users and running daemons. Files under
this directory must be either removed or truncated at the beginning of
the boot process; but this is not necessary on systems that provide this
directory as a temporary filesystem (tmpfs).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

2019-05-13 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 09.05.2019 um 17:20
in
Nachricht <20190509152036.GB5854@gardel-login>:
> On Do, 09.05.19 12:22, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> I had to subscribe to this list, even though I'm no systemd
>> fan. Still I'll have to deal with it as the distribution we use
>> switched to systemd...
> 
> Fantastic lead‑in. This is a perfect intro if you are asking for help,
> it creates the outmost desire in everyone who could help you to do so
> right‑away.

It just keeps the balance in the universe after all those "systemd is sooo
great" enthusiasm ;-)
Maybe you can make me change my mind...

> 
>> I'm porting my LSB code to systemd, and I'm having some
>> trouble. Cause of the trouble (and possible reason for systemd's
>> unpopularity) seems to be rather arbitrary restrictions without
>> reasoning (which is completely against the GNU spirit of seeking for
>> limitless software).
> 
> Hmm, the second paragaph even manages to improve upon the first. Your
> reader is now as enthusiastic as they could be to help your ASAP!

Yes, that's the "introduction to my personal frustration". I kept out the fact
that the list has a non-working "-request" address. That might add to the
overall impression I git so far...

> 
>> To be concrete: Why isn't it allowed to use an absolute path for
>> RuntimeDirectory, and wy isn't even a relative path allowed? In my
>> case I have a multi‑instance daemon, where the instances can be zero
>> to many. To avoid namespace conflicts, I created a /var/run/
>> directroy where all the instances put their stuff (in separate
>> directories each)
> 
> The "Runtime" in "RuntimeDirectory" should clarify that /run is where
> such dirs are created, hence we don't accept absolute dirs: the prefix
> must be /run, hence why specify it. If you want systemd to create a
> dir elsewhere, use StateDirectory= (which creates it in /var/lib) or
> CacheDirectory= (which creates it in /var/cache) or
> ConfigurationDirectory= which creates it in /etc.

Yes I got that once I understoood what the error message is acutally trying to
tell me ("absolute paths not allowed", you explained that earlier to me).

> 
> These four options map to the four main locations to place service
> data resources in. Well organized services only use those four places,
> since they come with clear life‑cycle and semantical definitions, and
> get first class support via the four settings. It's a gentle push that

Please let the admin decide what "well-organized" is.

> the various services follow established standards and place their
> stuff there and don't make up entirely random dirs outside of the
> typical hierarchy.

There's a difference between "random dirs" and subdirectories.

> 
> Before systemd v235 the RuntimeDirectory= setting did not support
> relative paths with "/" included. Starting with 235 it will accept
> them. Hence, please consider updating, you apparently run an older
> systemd version.

OK, so I wasn't that wrong with my claim. Unfortunately with an enterprise
distribution you don't want to install updates that make you loose support.
(The current most-recent SLES 15 is at systemd v234, unfortunately)

> 
> Note that "/var/run" is a legacy alias for "/run". It's highly
> recommended not to use the former anymore.

It it because you don't like sub-directories, or is it to save four bytes?
;-)

> 
>> Despite of that I'm missing a "systemctl validate ..." command. That
>> way I wouldn't need to execute start, status, stop, just to find out
>> that some settings are rejected.
> 
> "systemd‑analyze verify" exists. Since a long long time.

Not really: You can't verify a unit file while it's not "installed". Comare it
to validating an XML file, for example.

Regards,
Ulrich

> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

2019-05-12 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 09.05.2019 um 16:54 in
Nachricht <399aa684-a6bf-af19-dd09-bd670ec60...@gmail.com>:
> 09.05.2019 13:22, Ulrich Windl пишет:
>> Hi!
>> 
>> I had to subscribe to this list, even though I'm no systemd fan. Still I'll

> have to deal with it as the distribution we use switched to systemd...
>> 
>> I'm porting my LSB code to systemd, and I'm having some trouble. Cause of 
> the trouble (and possible reason for systemd's unpopularity) seems to be 
> rather arbitrary restrictions without reasoning (which is completely against

> the GNU spirit of seeking for limitless software).
>> 
>> To be concrete: Why isn't it allowed to use an absolute path for 
> RuntimeDirectory,
> 
> Wild guess - RuntimeDirectory is about security and permitting arbitrary
> path here rather contradicts this goal.

So root can run any program, but the PID of it may not be stored in a
subdirectory for security reasons???

> 
>> and wy isn't even a relative path allowed? In my case I have a 
> multi-instance daemon, where the instances can be zero to many. To avoid 
> namespace conflicts, I created a /var/run/ directroy
> 
> systemd does it for you.

That's irrelevant, bacause you are not allowed to use the directory, whoever
creates it.

> 
>> where all the instances put their stuff (in separate directories each)
>> 
>> Trying "RuntimeDirectory=/%i" inside @.service isn't
"accepted". 
> Still the instances start, can be checked and stopped, but there is a
message 
> when stopped saying
>> systemd[1]: [/usr/lib/systemd/system/@.service:12] Runtime
directory 
> is not valid, ignoring assignment: /%i
> 
> This works here; use of multilevel paths is even documented; granted,
> ability to use specifiers is not that obvious from manual page.

WHich version do you use, and how does your unit file look like?

> 
>> 
>> As "mkdir -p" exists for at least 25 years, I wonder what this is all
about.
>> 
> 
> I tentatively suspect that being less aggressive may actually help ...

If a program tells where I have to store my files creates frustration, and
that must go out...

> 
>> Despite of that I'm missing a "systemctl validate ..." command. That way I

> wouldn't need to execute start, status, stop, just to find out that some 
> settings are rejected.
>> 
>> Regards,
>> Ulrich
>> 
>> 
>> 
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org 
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 
>> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel