Discussion:
[systemd-devel] Query regarding "EnvironmentFile"
Soumya Koduri
2015-12-09 12:57:57 UTC
Permalink
Hi,

I have created a systemd.unit(nfs-ganesha.service) file as below :

[Unit]

After=nfs-ganesha-config.service
Requires=nfs-ganesha-config.service
....

[Service]
EnvironmentFile=-/run/sysconfig/ganesha
ExecStart=/usr/bin/ganesha.nfsd $OPTIONS ${EPOCH}
........
.......



My intention is to execute/start nfs-ganesha-config.service always prior
to running nfs-ganesha.service (even during restart).

nfs-ganesha-config.service writes certain configuration values to
'/run/sysconfig/ganesha' which I would want nfs-ganesha.service to read
before starting ganesha.nfsd daemon.

But from my tests I see that nfs-ganesha.service picks up old
configuration values defined in '/run/sysconfig/ganesha' than the ones
generated by 'nfs-ganesha-config.service' at that point. So I am
assuming 'EnvironmentFile' gets loaded prior to running any dependent
services (which is 'nfs-ganesha-config.service' here).

Please confirm if that is the case. Also is there any way to load
'EnvironmentFile' only after executing all the dependent services.

Thanks,
Soumya
Lennart Poettering
2015-12-09 19:46:29 UTC
Permalink
Post by Soumya Koduri
Hi,
[Unit]
After=nfs-ganesha-config.service
Requires=nfs-ganesha-config.service
....
[Service]
EnvironmentFile=-/run/sysconfig/ganesha
ExecStart=/usr/bin/ganesha.nfsd $OPTIONS ${EPOCH}
........
.......
My intention is to execute/start nfs-ganesha-config.service always prior to
running nfs-ganesha.service (even during restart).
nfs-ganesha-config.service writes certain configuration values to
'/run/sysconfig/ganesha' which I would want nfs-ganesha.service to read
before starting ganesha.nfsd daemon.
But from my tests I see that nfs-ganesha.service picks up old configuration
values defined in '/run/sysconfig/ganesha' than the ones generated by
'nfs-ganesha-config.service' at that point. So I am assuming
'EnvironmentFile' gets loaded prior to running any dependent services (which
is 'nfs-ganesha-config.service' here).
Please confirm if that is the case. Also is there any way to load
'EnvironmentFile' only after executing all the dependent services.
EnvironmentFile= is processed immediately before forking off the
service process. The env vars the process will see are hence the
contents of that file after all deps with After= ran.

(But honestly, there's really no point in trying to dynamically
convert stuff into a file that is suitable for EnvironmentFile=. I
mean, if you want a shell script, then use a shell script, and invoke
that from the main daemon's ExecStart= line, and make it exec the real
daemon as last step. There's really no point in playing these
multi-service conversion games. Also /etc/sysconfig is a Redhatism
that should really go away, the whole concept is flawed. Adding a new
/run/sysconfig/ certainly makes that even worse.)

I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection.

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2015-12-10 00:08:34 UTC
Permalink
Post by Lennart Poettering
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection
i strongly disagree

it's the easiest way to not touch/copy the systemd-unit *and*
systemd-snippets for just adjust a simple variable - the point here is
simple

copy units and/or add own snippets has easily two side effects

* don't get well deserved updates for the units
* or snippets don't play well with later dist-versions of the unit

a EnvironmentFile supported by the distributions unit is well better for
simple adoptions
Andrei Borzenkov
2015-12-10 03:40:21 UTC
Permalink
Post by Reindl Harald
Post by Lennart Poettering
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection
i strongly disagree
it's the easiest way to not touch/copy the systemd-unit *and*
systemd-snippets for just adjust a simple variable - the point here is
simple
copy units and/or add own snippets has easily two side effects
* don't get well deserved updates for the units
* or snippets don't play well with later dist-versions of the unit
a EnvironmentFile supported by the distributions unit is well better for
simple adoptions
This may have been true in the past.

How is

[Service]
Environment=FOO=bar

snippet today worse than environment file that does exactly the same?
Lennart Poettering
2015-12-10 10:15:39 UTC
Permalink
Post by Reindl Harald
Post by Lennart Poettering
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection
i strongly disagree
it's the easiest way to not touch/copy the systemd-unit *and*
systemd-snippets for just adjust a simple variable - the point here is
simple
There are very few things that are easier than "systemctl edit" or
"systemctl edit --full"... Also, you have to do that anyway, if you
want to make any changes about the service itself, such as setting a
memory limit, or adding a dep.
Post by Reindl Harald
copy units and/or add own snippets has easily two side effects
* don't get well deserved updates for the units
Sometimes this is precisely what you want, hence you have the choice
between creating a drop-in ("systemctl edit") or copy/edit the full
file ("systemctl edit --full").
Post by Reindl Harald
* or snippets don't play well with later dist-versions of the unit
a EnvironmentFile supported by the distributions unit is well better for
simple adoptions
Nope, it's an ugly Redhatism... It defeats a good chunk of our
toolset, include systemctl edit to change things, systemctl cat to see
the current state or systemd-delta to diff the settings. Hence it
really was a bad idea to add in the first place.

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2015-12-10 10:41:53 UTC
Permalink
Post by Lennart Poettering
Post by Reindl Harald
Post by Lennart Poettering
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection
i strongly disagree
it's the easiest way to not touch/copy the systemd-unit *and*
systemd-snippets for just adjust a simple variable - the point here is
simple
There are very few things that are easier than "systemctl edit" or
"systemctl edit --full"... Also, you have to do that anyway, if you
want to make any changes about the service itself, such as setting a
memory limit, or adding a dep.
but that few things are fine
Post by Lennart Poettering
Post by Reindl Harald
copy units and/or add own snippets has easily two side effects
* don't get well deserved updates for the units
Sometimes this is precisely what you want, hence you have the choice
between creating a drop-in ("systemctl edit") or copy/edit the full
file ("systemctl edit --full").
and sometimes you just want something like
EnvironmentFile=-/etc/sysconfig/httpd

[***@testserver:~]$ cat /etc/sysconfig/httpd
OPTIONS="-D testserver"

to share the whole httpd config between multiple servers
Post by Lennart Poettering
Post by Reindl Harald
* or snippets don't play well with later dist-versions of the unit
a EnvironmentFile supported by the distributions unit is well better for
simple adoptions
Nope, it's an ugly Redhatism... It defeats a good chunk of our
toolset, include systemctl edit to change things, systemctl cat to see
the current state or systemd-delta to diff the settings. Hence it
really was a bad idea to add in the first place.
well, accept that people adopted that Redhatism long before systemd was
even planned, working only with RHEL/CentOS/Fedora and hence are happy
with it and don't need or want to use "systemctl edit" while they accept
that you like it
Kai Krakow
2015-12-21 21:18:05 UTC
Permalink
Am Thu, 10 Dec 2015 01:08:34 +0100
Post by Reindl Harald
Post by Lennart Poettering
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection
i strongly disagree
I disagree, too, about "should never have added". But I totally agree
with the point that packagers misunderstood the purpose of those files.
And this whole discussion perfectly shows it.
Post by Reindl Harald
it's the easiest way to not touch/copy the systemd-unit *and*
systemd-snippets for just adjust a simple variable - the point here
is simple
copy units and/or add own snippets has easily two side effects
* don't get well deserved updates for the units
* or snippets don't play well with later dist-versions of the unit
a EnvironmentFile supported by the distributions unit is well better
for simple adoptions
An environment file should never be used to configure the runtime
behavior of a service [1], e.g. trigger conditionals in config files in
a way that they are not propagated during a service reload.

Instead, they are very useful in service instantiation by using the
***@.service templating pattern. E.g. for nspawn services you
could create different configuration options that apply for container
boots but not during runtime. Or you could create different instances
of MySQL. Or, or, ... I'm sure you get the point. For me this is almost
the only valid point in using such files.

All other purposes are ugly remnants of sysvinit workarounds to cope
with completely unmaintainable and complex scripts.

So, environment variables should go into service overrides or
directly into config files which you edit instead of creating new config
files. If you apply your own config management, then well, go with an
environment file if you feel so. I think it's okay. But this should
never ever be shipped as a default distribution configuration (but it
could be valid as an example, with proper documentation of the
side-effects this can have). You still should or want to modify your
exec line because:

The problem with a purpose of not modifying the exec line is that
vanishing options may be silently ignored during upgrades while after
an upgrade the service may instead fail if you added a now
incompatible/deprecated option. And that is a good thing [tm]. The
latter way makes debugging upgrade problems a lot easier and makes
better upgrade paths. If you totally feel like not putting your
production server into problems (and you really should), you have a
staging server anyways where you apply updates first, then fix things,
then apply the upgraded configuration management to the farm along with
the package updates. Virtualization and/or containers make that easy
and cheap.

Concluding: The option should stay but please package maintainers
remove your ugly cruft. This is something I constantly struggle with
the way it is done in Gentoo for elasticsearch. But actually it's
encouraged that way by the developers probably - and that's now the
outcome of this pita.

Thus: Please maintainers and developers, remove it. Do not let Lennart
remove this useful option to force others into removing your shitty
cruft. A service file should always do the correct thing upon invoking
either reload or restart respectively. Let the admin break this rule if
she or he feels like doing so. But do not ship that broken behavior as
a default.

Regarding the OP and a few follow ups a German saying comes to my mind:
"Das kannst'e zwar so machen, is' aber scheiße" :-) So let's better
support him into fixing his configuration and doing it the proper way
instead of insisting who is right or who is wrong. The concept of
environments files is clearly misused in many cases. Nothing is really
bad about it.

[1]: Unless you know what you're doing - but as stated it should not
come by default and thus offer a way to easily screw your system.

--
Kai Krakow
2015-12-21 22:14:43 UTC
Permalink
Am Mon, 21 Dec 2015 22:41:04 +0100
Post by Kai Krakow
Thus: Please maintainers and developers, remove it. Do not let
Lennart remove this useful option to force others into removing
your shitty cruft.
This is exactly why systemd is the top one most hated piece of open
source software. We are not here to be educated about the one and only
right way of doing things.
Unix used to be about choice.
I'm not arguing about choice, neither I wrote anything against it. But
a distribution and upstreams should not ship with ugly concepts of
configuration or even tied to specifica of some distributions. How many
upstreams are out there who ship the debian concept as the one and
only, others ship the SuSE concept (sysconfig) which in turn is similar
but incompatible to Redhat.

Please tell me: Where is this about choice?

Choice is if you decide yourself (or your distribution) to adapt a
configuration concept. And that is why I'm pro keeping the
EnvironmentFile option. In essence, this means: You are still and will
stay in choice.

Please read the whole post before answering.
Too bad that we allowed this to be no longer the case. Linux is no
longer about choice. Linux nowadays is about what the systemd people
want.
That's wrong. You maybe just cannot adapt to new, more modern, and more
sane concepts and defaults. You are then probably also the type of
people which are forcing upstream to remove options so nobody can misuse
them any longer.

Systemd is vastly different from concepts we had for the last 50 years
(or so), but linux really needs this modernization. Many concepts are
broken in term of modern computing. Yes, it still works. Yes, never
break a working system. But we really need new concepts, we are the
generation of laying out the proper path and a solid foundation for
following generations of sysadmins. This also means that systemd will
stay in flux for a few more years.

Really... Don't get me wrong. I don't mean that personally. But I can
watch the same behavior among my workmates - and it's almost always a
problem of not willing to learn and handle new concepts.

Nobody is taking choice away, we just need to learn to apply it
properly and in a new way. And this forum should be of discussing a way
to do it instead of starting to hate each other because someone else
took our toys away.

If you are using systemd, it's time to rethink some of your concepts
and re-apply them in the most straight-forward way. Mixing runtime,
default, startup (etc etc) configuration with each other is really a
pain - and not the way to do. It has never been. Even in sysvinit. But
many distributions and upstreams weakened this separation.

And shipping default configurations that make it easy to miss issues
with deprecated custom configuration has ever been bad. I think this is
what the devs in this thread are talking about at its core.
Too bad that we gave the systemd people the power of forcing us to run
our systems their way.
Then, don't run systemd. Nobody forces you. It was your choice to use a
distribution which migrated to systemd as the one and only option.
Thus, it's not the systemd people forcing you. It's your distribution.
Complain there. Or switch to a distribution which allows for more
choice. Or put simply: Deal with it.

Systemd is also not overtaking upstreams. The concept allows to leave
out all the systemd bits. Configuration concepts may change, however.
Still, if systemd gets pulled in by packages, it's probably the
distributions "fault" (except for maybe Gnome, I don't use it so I
don't know about the options).

But we probably need to find ways to support configurations concepts
which cope with systemd and non-systemd installations. In the end, its
about choice.

I cannot see anything here in the thread which would disallow continue
using non-systemd installations.
--
Regards,
Kai

Replies to list-only preferred.
Kai Krakow
2015-12-21 23:16:08 UTC
Permalink
Am Mon, 21 Dec 2015 23:29:57 +0100
Post by Kai Krakow
I cannot see anything here in the thread which would disallow
continue using non-systemd installations.
The problem is that many concepts of systemd are really nice. Once
wants to have things like that.
I can totally second that.
The problem is that a minoriy of concepts and the attitude of the
makers make working with systemd a constant source of increased blood
pressure and a strong urge to break something expensive just to get
rid of the aggression.
Yep, I probably cannot deny that.

But to push forward a software like systemd and make it successful you
probably need that kind of attitude. And without this "hard course"
systemd wouldn't be what it is now - it wouldn't have those strong,
well-thought concepts but instead be some set of tools trying to do
everything somehow but almost nothing truly correct (correct in terms
of stability and reliability). Nobody would've noticed, few would have
adapted it, and probably no one would continue to use it.

Look at the kernel, with Linus. His attitude surely conflicts with one
or another person, probably even a lot of them. But his straight course
made the kernel a success. It is stable because it doesn't let everyone
introduce some broken concepts.

But one could argue that backwards compatibility is probably handled
different (but systemd is a new project while the kernel is not). Tho,
old binaries probably wont run under modern kernels - what is probably
related to glibc mostly or dropped aout support.

And getting to glibc, I remember there have been "attitude
compatibility issues" with the devs, too, in the past. And people who
forked the project... Yeah... I think many did not even notice. Glibc
just worked for them.

So, every project probably has this type of person or dev. And those
people are needed for the long-term success of the project. And given
the loudness of some people here I can totally understand Lennart
reacting in the one or other way - even if it hits people who don't
deserve it.

Back to concepts: I'm always trying to find my way through the new
ideas, trying to understand it instead of denying it, then re-apply my
workflow. If it doesn't fit, throw either that away, or the software.
Probably one of many reasons why I chose Gentoo, although I sometimes
play with the idea of trying Fedora. But in the end I would miss much
of the freedom I currently have (and make use of).
--
Regards,
Kai

Replies to list-only preferred.
Reindl Harald
2015-12-22 10:27:23 UTC
Permalink
Post by Kai Krakow
Back to concepts: I'm always trying to find my way through the new
ideas, trying to understand it instead of denying it, then re-apply my
workflow. If it doesn't fit, throw either that away, or the software.
Probably one of many reasons why I chose Gentoo, although I sometimes
play with the idea of trying Fedora. But in the end I would miss much
of the freedom I currently have (and make use of)
so i do, but for what i have *zero* understanding is deperecating and
removing features which are working just because someone thinks they
should not be used

it's one thing educating distributions, but it's another thing taking
capabilities away from users which made a decision how to implement
things because they feel comfortable with that way - it's nobodys
business to question why one feels comfortable with a way something is
configured and force to change it
Lennart Poettering
2015-12-23 00:43:35 UTC
Permalink
Post by Reindl Harald
Post by Kai Krakow
Back to concepts: I'm always trying to find my way through the new
ideas, trying to understand it instead of denying it, then re-apply my
workflow. If it doesn't fit, throw either that away, or the software.
Probably one of many reasons why I chose Gentoo, although I sometimes
play with the idea of trying Fedora. But in the end I would miss much
of the freedom I currently have (and make use of)
so i do, but for what i have *zero* understanding is deperecating and
removing features which are working just because someone thinks they should
not be used
Just to clarify that. I think EnvironmentFile= was a mistake, and I
explained why. But then again, I am not planning to remove it, and I
never suggested that.

(I also think you are misusing it in your examples, and there are
better ways to do what you want. Templates and stuff for
example...)

Lennart
--
Lennart Poettering, Red Hat
Jóhann B. Guðmundsson
2015-12-23 06:01:51 UTC
Permalink
Post by Lennart Poettering
Just to clarify that. I think EnvironmentFile= was a mistake, and I
explained why. But then again, I am not planning to remove it, and I
never suggested that.
What usescases do you see for it's existence.

FYI the longer you take fixing your mistakes the harder it will get.

Arguably you should have a deprecation policy that is aligned on par
with the feature introduction otherwise it can get nearly impossible
longer down the line with the building blocks of the core/baseOS to
deprecate anything.

Especially if you have fallen into the trap of "waiting for the right
time" since there exist no such thing.

JBG
Reindl Harald
2015-12-23 09:32:12 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
Just to clarify that. I think EnvironmentFile= was a mistake, and I
explained why. But then again, I am not planning to remove it, and I
never suggested that.
What usescases do you see for it's existence.
open your eyes - the ones you think you are in the position to force
people not using them - YOU ARE NOT
Post by Jóhann B. Guðmundsson
FYI the longer you take fixing your mistakes the harder it will get.
Arguably you should have a deprecation policy
arguably you shoulkd find another hobby than force *breaking things*
damned just because it is NOT YOUR BUSINESS to question users configs
Lennart Poettering
2015-12-23 15:10:36 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
Just to clarify that. I think EnvironmentFile= was a mistake, and I
explained why. But then again, I am not planning to remove it, and I
never suggested that.
What usescases do you see for it's existence.
open your eyes - the ones you think you are in the position to force people
not using them - YOU ARE NOT
Post by Jóhann B. Guðmundsson
FYI the longer you take fixing your mistakes the harder it will get.
Arguably you should have a deprecation policy
arguably you shoulkd find another hobby than force *breaking things* damned
just because it is NOT YOUR BUSINESS to question users configs
Tone it down, Reindl, or I'll put you on moderation, too (again!).

Lennart
--
Lennart Poettering, Red Hat
Lennart Poettering
2015-12-23 15:09:56 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Lennart Poettering
Just to clarify that. I think EnvironmentFile= was a mistake, and I
explained why. But then again, I am not planning to remove it, and I
never suggested that.
What usescases do you see for it's existence.
Well, the usecase that this is what's out there right now, and we have
to stay compatible. It's not precisely an exotic feature, we can
easily deprecated. It's unfortunately pretty popular.

Lennart
--
Lennart Poettering, Red Hat
Alex Crawford
2015-12-23 19:30:43 UTC
Permalink
Post by Lennart Poettering
Post by Jóhann B. Guðmundsson
What usescases do you see for it's existence.
Well, the usecase that this is what's out there right now, and we have
to stay compatible. It's not precisely an exotic feature, we can
easily deprecated. It's unfortunately pretty popular.
We use it within CoreOS to allow the user to inject dynamic data into the
service. For example, you may have a service like this:

$ cat etcd.service
[Unit]
Requires=metadata.service
After=metadata.service

[Service]
EnvironmentFile=/run/coreos/metadata
ExecStart=/usr/bin/etcd --public-ip=${COREOS_PRIVATE_IPV4}

where "metadata.service" populates /run/coreos/metadata with a bunch of info
about the system (like Facter from puppet). The user can then pick and choose
the appropriate variables to use (maybe they need the public address instead)
and override the ExecStart in a drop-in.

I like this model and I'm not sure how I would solve this if EnvironmentFile
didn't exist.

-Alex
Lennart Poettering
2015-12-23 19:48:15 UTC
Permalink
Post by Alex Crawford
Post by Lennart Poettering
Post by Jóhann B. Guðmundsson
What usescases do you see for it's existence.
Well, the usecase that this is what's out there right now, and we have
to stay compatible. It's not precisely an exotic feature, we can
easily deprecated. It's unfortunately pretty popular.
We use it within CoreOS to allow the user to inject dynamic data into the
$ cat etcd.service
[Unit]
Requires=metadata.service
After=metadata.service
[Service]
EnvironmentFile=/run/coreos/metadata
ExecStart=/usr/bin/etcd --public-ip=${COREOS_PRIVATE_IPV4}
where "metadata.service" populates /run/coreos/metadata with a bunch of info
about the system (like Facter from puppet). The user can then pick and choose
the appropriate variables to use (maybe they need the public address instead)
and override the ExecStart in a drop-in.
I like this model and I'm not sure how I would solve this if EnvironmentFile
didn't exist.
I see no reason why systemd should be involved with this. Just make
etcd a proper daemon, and read its config data directly, rather then
serializing it into the command line.

Lennart
--
Lennart Poettering, Red Hat
Jóhann B. Guðmundsson
2015-12-23 20:44:53 UTC
Permalink
Post by Lennart Poettering
I see no reason why systemd should be involved with this. Just make
etcd a proper daemon, and read its config data directly, rather then
serializing it into the command line.
In sys v initscript it started out as variable options, placed on top
for administrator ease of changeability then due the share size and
complexity of the sys v initscript it evolved it into environment files
which led to file location based fragmentation between distribution (
and is now hindering share-ability of type unit files between
distributions ) but never through all those decades did someone go and
fix the underlying problem which is as you point out lack of daemon
reading configuration file.

The same pattern has started to re-emerge in a form of an workaround in
systemd by using drop-ins containing [Service] Environment= or
EnviromentFile=, which I suspect they are doing based on his description
either themselves or they have administrators do that to overwrite those
entry's since they generate that metadata file ( which is more likely )

JBG
Manuel Amador (Rudd-O)
2015-12-26 18:39:43 UTC
Permalink
Post by Lennart Poettering
I see no reason why systemd should be involved with this. Just make
etcd a proper daemon, and read its config data directly, rather then
serializing it into the command line.
Lennart
Reading from environment / flagfiles / command line is super popular
these days, whether it be because Google did it that way and now
ex-Googlers are popularizing the pattern, or because of the 12-factor
application fad (which I admit, has quite a few merits).

This is why developers are frequently using systemd with EnvironmentFile
these days.

Of course, this breaks reload... but almost nobody is writing reload
code in their daemons these days anymore.
--
Rudd-O
http://rudd-o.com/
Jóhann B. Guðmundsson
2015-12-23 20:12:44 UTC
Permalink
Post by Alex Crawford
I like this model and I'm not sure how I would solve this if EnvironmentFile
didn't exist.
The usual underlying cause of usage of Environment or EnvironmentFile in
type units is more or less always due to the fact that the
daemon/service cannot read configuration file on startup thus the answer
is you would use a daemon that was written in a such manner it could
read configuration file, generate that file and get rid of the extra
administrator step of having administrators create and use drop-in's or
am I missing something?

JBG
Reindl Harald
2015-12-23 20:18:03 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Alex Crawford
I like this model and I'm not sure how I would solve this if
EnvironmentFile
didn't exist.
The usual underlying cause of usage of Environment or EnvironmentFile in
type units is more or less always due to the fact that the
daemon/service cannot read configuration file on startup thus the answer
is you would use a daemon that was written in a such manner it could
read configuration file, generate that file and get rid of the extra
administrator step of having administrators create and use drop-in's or
am I missing something?
and what's the difference between a config file or "EnvironmentFile"
besides you like the one for whatever reason more while both are config
files?
Jóhann B. Guðmundsson
2015-12-23 22:08:59 UTC
Permalink
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Post by Alex Crawford
I like this model and I'm not sure how I would solve this if
EnvironmentFile
didn't exist.
The usual underlying cause of usage of Environment or EnvironmentFile in
type units is more or less always due to the fact that the
daemon/service cannot read configuration file on startup thus the answer
is you would use a daemon that was written in a such manner it could
read configuration file, generate that file and get rid of the extra
administrator step of having administrators create and use drop-in's or
am I missing something?
and what's the difference between a config file or "EnvironmentFile"
besides you like the one for whatever reason more while both are
config files?
Environment entry's or files containing environment entries are not
configuration files.

Not by a mile even from a security perspective.

Why would you even think that and FYI environment variables are still
declared somewhere in a file so why not just create a config file which
is read within the processes and be on the safe side?

Sorry I dont grok how you come to the conclusion that both of these are
config files, treated the same or even what people think they are
gaining something using environment entry's that reside in a file over
configuration files in the first place.

JBG
Reindl Harald
2015-12-23 22:40:09 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Post by Alex Crawford
I like this model and I'm not sure how I would solve this if EnvironmentFile
didn't exist.
The usual underlying cause of usage of Environment or EnvironmentFile in
type units is more or less always due to the fact that the
daemon/service cannot read configuration file on startup thus the answer
is you would use a daemon that was written in a such manner it could
read configuration file, generate that file and get rid of the extra
administrator step of having administrators create and use drop-in's or
am I missing something?
and what's the difference between a config file or "EnvironmentFile"
besides you like the one for whatever reason more while both are
config files?
Environment entry's or files containing environment entries are not
configuration files.
Not by a mile even from a security perspective.
really?

you are not aware that systemd filters out existing env-vars except
EnvironmentFile / Environment
Post by Jóhann B. Guðmundsson
Why would you even think that and FYI environment variables are still
declared somewhere in a file so why not just create a config file which
is read within the processes and be on the safe side?
wrong question

why should i change anything in *my* configuartion *because* you don't
like it?
Post by Jóhann B. Guðmundsson
Sorry I dont grok how you come to the conclusion that both of these are
config files, treated the same or even what people think they are
gaining something using environment entry's that reside in a file over
configuration files in the first place
well, there are enough applications which can be used not only running
as service just by using CLI params, using them the same way as a
service where it makes sense is way better than have a systemwide and in
doubt conflicting config file

the main question is: who are you to educate the world while nobody is
forcing you to use "EnvironmentFile" - do what you want in your way and
just accept that others make their own decisions because they are not yours
Manuel Amador (Rudd-O)
2015-12-26 18:41:49 UTC
Permalink
Post by Reindl Harald
why should i change anything in *my* configuartion *because* you don't
like it?
Nobody is forcing you to change anything from your configuration. Even
though environment files are shit for configuration (the reasoning of
which has already been explained, but you don't seem to be listening).
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 18:44:12 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
why should i change anything in *my* configuartion *because* you don't
like it?
Nobody is forcing you to change anything from your configuration
Johann would if he had the power to do so
Post by Manuel Amador (Rudd-O)
though environment files are shit for configuration (the reasoning of
which has already been explained, but you don't seem to be listening)
i DON'T CARE about reload because "EnvironmentFile" don't change every
second
Manuel Amador (Rudd-O)
2015-12-26 18:50:47 UTC
Permalink
Post by Reindl Harald
Post by Manuel Amador (Rudd-O)
Nobody is forcing you to change anything from your configuration
Johann would if he had the power to do so
Aren't you glad he doesn't?
Post by Reindl Harald
Post by Manuel Amador (Rudd-O)
though environment files are shit for configuration (the reasoning of
which has already been explained, but you don't seem to be listening)
i DON'T CARE about reload because "EnvironmentFile" don't change every
second
Yes, you've established that, for your use case, shit config files are fine.

Nobody is taking away your candy, chillax.
--
Rudd-O
http://rudd-o.com/
Manuel Amador (Rudd-O)
2015-12-26 18:40:43 UTC
Permalink
Post by Reindl Harald
and what's the difference between a config file or "EnvironmentFile"
besides you like the one for whatever reason more while both are
config files?
It has already been explained that certain operations will not cause the
EnvironmentFile contents to propagate to the services run by the unit.
Reload is one of those operations.

Do you need a deeper explanation?
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 18:42:31 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
and what's the difference between a config file or "EnvironmentFile"
besides you like the one for whatever reason more while both are
config files?
It has already been explained that certain operations will not cause the
EnvironmentFile contents to propagate to the services run by the unit.
Reload is one of those operations.
Do you need a deeper explanation?
frankly there are few to no cases where that matters at all
and even if: it's my decision as syadmin and nobody elses
Alex Crawford
2015-12-24 00:48:35 UTC
Permalink
Post by Jóhann B. Guðmundsson
The usual underlying cause of usage of Environment or EnvironmentFile in
type units is more or less always due to the fact that the
daemon/service cannot read configuration file on startup thus the answer
is you would use a daemon that was written in a such manner it could
read configuration file, generate that file and get rid of the extra
administrator step of having administrators create and use drop-in's or
am I missing something?
We are effectively using the drop-in to allow the user to map command line
options to dynamic data. Since the user won't know things like IP addresses,
they cannot write a traditional configuration file:

$ cat static.conf
IP=1.2.3.4

They would instead have to write something like this:

$ cat dynamic.conf
IP=COREOS_PUBLIC_IPV4

Of course, the daemon would then need to understand how to follow this mapping
and do the substitution itself. We instead decided to piggy-back on systemd and
let it do the mapping for us.

-Alex
Andrei Borzenkov
2015-12-24 03:36:48 UTC
Permalink
Post by Alex Crawford
Post by Jóhann B. Guðmundsson
The usual underlying cause of usage of Environment or EnvironmentFile in
type units is more or less always due to the fact that the
daemon/service cannot read configuration file on startup thus the answer
is you would use a daemon that was written in a such manner it could
read configuration file, generate that file and get rid of the extra
administrator step of having administrators create and use drop-in's or
am I missing something?
We are effectively using the drop-in to allow the user to map command line
options to dynamic data. Since the user won't know things like IP addresses,
$ cat static.conf
IP=1.2.3.4
$ cat dynamic.conf
IP=COREOS_PUBLIC_IPV4
I do not follow. You said that you are using separate service to
generate file that contains correct

IP=1.2.3.4

How does it matter whether this file is now read by systemd or your
daemon directly?
Post by Alex Crawford
Of course, the daemon would then need to understand how to follow this mapping
and do the substitution itself. We instead decided to piggy-back on systemd and
let it do the mapping for us.
But systemd does not do any mapping - it simply passes along result of
mapping which another program has done.
Alex Crawford
2015-12-24 08:50:47 UTC
Permalink
Post by Andrei Borzenkov
I do not follow. You said that you are using separate service to
generate file that contains correct
IP=1.2.3.4
Not quite. The seperate "metadata" service generates a bunch of entries like:

COREOS_PRIVATE_IPV4=1.2.3.4
COREOS_PUBLIC_IPV4=5.6.7.8
Post by Andrei Borzenkov
Post by Alex Crawford
Of course, the daemon would then need to understand how to follow this mapping
and do the substitution itself. We instead decided to piggy-back on systemd and
let it do the mapping for us.
But systemd does not do any mapping - it simply passes along result of
mapping which another program has done.
The user then defines the mapping in the drop-in by specifying:

ExecStart=/usr/bin/etcd --ip=${COREOS_PRIVATE_IPV4}

or

ExecStart=/usr/bin/etcd --ip=${COREOS_PUBLIC_IPV4}

This way, the user doesn't bother with the contents of those variables and we
let systemd perform the substitution for us (or maybe the user knows these
addresses up front and doesn't bother with the variables at all).

-Alex
Manuel Amador (Rudd-O)
2015-12-26 18:38:03 UTC
Permalink
Post by Alex Crawford
We use it within CoreOS to allow the user to inject dynamic data into the
$ cat etcd.service
[Unit]
Requires=metadata.service
After=metadata.service
[Service]
EnvironmentFile=/run/coreos/metadata
ExecStart=/usr/bin/etcd --public-ip=${COREOS_PRIVATE_IPV4}
where "metadata.service" populates /run/coreos/metadata with a bunch of info
about the system (like Facter from puppet). The user can then pick and choose
the appropriate variables to use (maybe they need the public address instead)
and override the ExecStart in a drop-in.
This breaks reload.

But, of course, if etcd does not support reload, and it's planned that
one etcd node will fail to serve its clients while it is down /
restarting, then it's a fine use of EnvFile.
--
Rudd-O
http://rudd-o.com/
Manuel Amador (Rudd-O)
2015-12-26 18:35:30 UTC
Permalink
The problem is that a minoriy of concepts and the attitude of the
makers make working with systemd a constant source of increased blood
pressure and a strong urge to break something expensive just to get
rid of the aggression.
For that, there's therapy. Other human beings are not your punching bags.
--
Rudd-O
http://rudd-o.com/
Lennart Poettering
2015-12-23 00:20:21 UTC
Permalink
Post by Kai Krakow
Thus: Please maintainers and developers, remove it. Do not let Lennart
remove this useful option to force others into removing your shitty
cruft.
This is exactly why systemd is the top one most hated piece of open
source software. We are not here to be educated about the one and only
right way of doing things.
Unix used to be about choice.
Too bad that we allowed this to be no longer the case. Linux is no
longer about choice. Linux nowadays is about what the systemd people
want.
Too bad that we gave the systemd people the power of forcing us to run
our systems their way.
Man kann manchmal echt nicht genug essen wie man in dieser Welt kotzen
möchte.
You are now on moderation.

Please find a different forum for this systemd hate stuff,
systemd-devel is not it. I'll allow your technical mails onto the ML,
but not the hate BS, take that elsewhere.

Thanks,

Lennart
--
Lennart Poettering, Red Hat
Manuel Amador (Rudd-O)
2015-12-26 18:34:38 UTC
Permalink
This is exactly why systemd is the top one most hated piece of open
source software. We are not here to be educated about the one and only
right way of doing things.
Actually, you hate systemd because you don't like that systemd forces
you to learn new things. One of those things is how unmaintainable
environment and shell scripts really are, and how they often cause
problems on production (the reload problem is just one of them). But,
since you don't like to be told that the things you prefer are shit, you
instead project your anger on systemd and its developers.

Grow up.
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 18:46:01 UTC
Permalink
Post by Manuel Amador (Rudd-O)
This is exactly why systemd is the top one most hated piece of open
source software. We are not here to be educated about the one and only
right way of doing things.
Actually, you hate systemd because you don't like that systemd forces
you to learn new things. One of those things is how unmaintainable
environment and shell scripts really are, and how they often cause
problems on production (the reload problem is just one of them)
just because you don#t manage to maintain something don't mean it's
unmaintainable - BTW: what about pack your answers to days old posts in
a single reply?
Soumya Koduri
2015-12-10 05:36:06 UTC
Permalink
Post by Lennart Poettering
Post by Soumya Koduri
Hi,
[Unit]
After=nfs-ganesha-config.service
Requires=nfs-ganesha-config.service
....
[Service]
EnvironmentFile=-/run/sysconfig/ganesha
ExecStart=/usr/bin/ganesha.nfsd $OPTIONS ${EPOCH}
........
.......
My intention is to execute/start nfs-ganesha-config.service always prior to
running nfs-ganesha.service (even during restart).
nfs-ganesha-config.service writes certain configuration values to
'/run/sysconfig/ganesha' which I would want nfs-ganesha.service to read
before starting ganesha.nfsd daemon.
But from my tests I see that nfs-ganesha.service picks up old configuration
values defined in '/run/sysconfig/ganesha' than the ones generated by
'nfs-ganesha-config.service' at that point. So I am assuming
'EnvironmentFile' gets loaded prior to running any dependent services (which
is 'nfs-ganesha-config.service' here).
Please confirm if that is the case. Also is there any way to load
'EnvironmentFile' only after executing all the dependent services.
EnvironmentFile= is processed immediately before forking off the
service process. The env vars the process will see are hence the
contents of that file after all deps with After= ran.
(But honestly, there's really no point in trying to dynamically
convert stuff into a file that is suitable for EnvironmentFile=. I
mean, if you want a shell script, then use a shell script, and invoke
that from the main daemon's ExecStart= line, and make it exec the real
daemon as last step. There's really no point in playing these
multi-service conversion games. Also /etc/sysconfig is a Redhatism
that should really go away, the whole concept is flawed. Adding a new
/run/sysconfig/ certainly makes that even worse.)
Thanks again for the clarification and your inputs. I wanted to
understand the behavior before taking any other approach.

-Soumya
Post by Lennart Poettering
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection.
Lennart
Simon McVittie
2015-12-10 11:42:29 UTC
Permalink
Post by Lennart Poettering
Also /etc/sysconfig is a Redhatism
that should really go away, the whole concept is flawed.
This is by no means limited to Red Hat derivatives: /etc/default is a
Debianism which is basically the same as /etc/sysconfig.

I think Red Hat and Debian derivatives do both over-use their respective
EnvironmentFile directories (and in particular the START_DAEMON=0
anti-pattern, which was a workaround for how hard it traditionally was
to disable a service in sysvinit, needs to go away), but it can make
sense for the specific case of overriding non-system-integration-related
command-line options, to avoid situations like this:

* foobar version 1 has ExecStart=/usr/libexec/foobar --no-fork
* sysadmin overrides that to
ExecStart=/usr/libexec/foobar --no-fork --enable-uploads
* distribution or upstream changes version 2 to say
ExecStart=/usr/libexec/foobar --no-fork --use-syslog
(or some other new system-integration option)
* desired result: --no-fork --use-syslog --enable-uploads
* actual result if the sysadmin has used systemctl edit:
--no-fork --enable-uploads

by having "ExecStart=/usr/libexec/foobar --no-fork [--use-syslog]
$OPTIONS" instead.

Of course, it would be better for the underlying service to have a
configuration file (or, better, a .d directory) where the sysadmin could
enable uploads; but we have to work with what we have, not what we'd
like to have, and not all underlying services have that.

The approach I try to follow in dbus is that options that should be
changed by another package (such as default security policies) go in a
configuration file, or more recently a file in /usr/share; options that
should be changed by the sysadmin (such as security policies and
resource limits) also go in a configuration file; but system-integration
options (such as "use syslog" or "use systemd for activation") are
command-line options that can be forced to their
correct-for-this-distribution values by the ExecStart line in the
systemd unit, LSB init script or whatever. Unfortunately dbus doesn't
always follow this rule for historical reasons - <syslog/> is a
configuration-file option, but it shouldn't be.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
Manuel Amador (Rudd-O)
2015-12-26 18:49:34 UTC
Permalink
Post by Simon McVittie
The approach I try to follow in dbus is that options that should be
changed by another package (such as default security policies) go in a
configuration file, or more recently a file in /usr/share; options that
should be changed by the sysadmin (such as security policies and
resource limits) also go in a configuration file; but system-integration
options (such as "use syslog" or "use systemd for activation") are
command-line options that can be forced to their
correct-for-this-distribution values by the ExecStart line in the
systemd unit, LSB init script or whatever. Unfortunately dbus doesn't
always follow this rule for historical reasons - <syslog/> is a
configuration-file option, but it shouldn't be.
I like what the Genode folks are doing these days to solve this
problem. It truly is brilliant and I wish Linux had anything like it:

When a program starts, its creator "container" creates a ROM dataspace
(a chunk of read-only memory that gets mapped into the memory space of
the program) and then passes the dataspace as a capability to the
program. The program then reads its configuration from the dataspace.

When the configuration file on disk is changed, the creator notices,
creates a brand new ROM dataspace, and pushes it to the program via
IPC. The program then has automatically mapped the new ROM dataspace
into its address space, but the new ROM dataspace is not active -- it is
up to the program to do whatever is necessary to make the new ROM
dataspace take effect, whenever it decides to do so.

All of this works without restarts, completely transparently and
automatically, and it's actual library code that is automatically reused
among ALL Genode programs, uses actual capability-based IPC, and is
entirely secure in a way no Linux program can be.

Meanwhile, we're still in 1980 dicking around with EnvironmentFiles and
FlagFiles and such bullshit.

But I do think that Genode has a vaiuable lesson here. If, say, systemd
gained the capability to "compile" configurations and push them to
daemons via memfd, and daemons learned how to catch those memfds and
reconfigure themselves as they are received -- a similar, but less
secure concept than what Genode does -- then we would have invented the
perfect reload pattern. Heck, systemd could even compile that stupid
EnvironmentFile and ship it to the daemon without having to do any sort
of evaluation on ExecStart... and perhaps even automatically ship the
compiled configuration as soon as its source is detected to have
changed, much like Genode does today.

Ah, a man can dream.
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 18:54:29 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Meanwhile, we're still in 1980 dicking around with EnvironmentFiles and
FlagFiles and such bullshit
boy just don't use it if you don't like it

nobody is forcing you to use anything - on the other hand some systemd
people trying to force admins change working things for the sake of change
Jóhann B. Guðmundsson
2015-12-10 14:46:55 UTC
Permalink
Post by Lennart Poettering
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection.
The legacy sys initscripts in Fedora, more or less ( with the exception
of very few corner cases which got solved via templates ) where just
using environment files that resided under the /etc/sysconfig directory
that contained options to match $FOO="Yes" or "No" or Options="Bar"
which you override either via copy of the type unit file or via
overwrite snippet.

I personally never saw the reason why it existed in first place ( in
that context ) and I'm not aware of any other usecase for it's existence
and I have seen units in various upstreams repos' that contain that
/etc/sysconfig Fedora/RedHat-ism which at the same time makes them
incomparable with any other distro thus adds to the upstream/downstream
burden of maintaining those unit file(s).

If you are unaware of any other use case for it perhaps it's time to
start looking into obsoleting it.

JBG
Reindl Harald
2015-12-10 15:20:46 UTC
Permalink
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND

[***@testserver:~]$ cat /etc/sysconfig/httpd
OPTIONS="-D testserver"

Apache:
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>

and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or
*anything* else in the apache configuration
Post by Jóhann B. Guðmundsson
perhaps it's time to
start looking into obsoleting it
don't get me wrong but you sound once again like seek for changes to
break users configuration to later blame users why they did not fix
which ain't broken
Jóhann B. Guðmundsson
2015-12-10 15:44:28 UTC
Permalink
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or
*anything* else in the apache configuration
You apparently did not read or grasp what I said earlier.

This is something you do via unit overwrite configuration snipped in
conjunction with your Apache configuration changes not in an environment
file.
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
perhaps it's time to
start looking into obsoleting it
don't get me wrong but you sound once again like seek for changes to
break users configuration to later blame users why they did not fix
which ain't broken
You cannot be gotten right.

The follow up cleanup process in Fedora that I needed to conduct after
the unit migration was completed, would have among other things
obsoleted and removed those Fedora/RedHat specific environment files
since it became clear immediately at that time that they had been
obsoleted.

We would have done that immediately in F14/F15 when we started the
migration work but we had other political issues surrounding systemd to
deal with at that time without having to add the obsolete of those
legacy sysv initscripts environment files that Redhat holds so dear.

I even created specific git repository without that environment file
entry's specific to Redhat so that unit I migrated could be reused and
shared amongst other distributions at that time as well being more
likely to be accepted upstreams ( of those atleast I was in contact with
) only wanted to maintain a single unit file but cross distribution
compatibility and the importance of it is something you dont seem to be
capable of grasping since the only use cases that matters is the one
that is specific and relevant to you.

JBG
Reindl Harald
2015-12-10 15:47:03 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or
*anything* else in the apache configuration
You apparently did not read or grasp what I said earlier.
This is something you do via unit overwrite configuration snipped in
conjunction with your Apache configuration changes not in an environment
file.
this is something *i do not* with unit overwrite configuration by
intention because i DO NOT want to touch ExecStart on any machine
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
perhaps it's time to
start looking into obsoleting it
don't get me wrong but you sound once again like seek for changes to
break users configuration to later blame users why they did not fix
which ain't broken
You cannot be gotten right.
The follow up cleanup process in Fedora that I needed to conduct after
the unit migration was completed, would have among other things
obsoleted and removed those Fedora/RedHat specific environment files
since it became clear immediately at that time that they had been
obsoleted
cleanup whatever you want in Fedora, i don't use httpd or other server
packages from the distribution at all - by removing "EnvironmentFile"
from systemd you piss of users and sysadmins, not only distributions
Reindl Harald
2015-12-10 16:01:27 UTC
Permalink
Post by Jóhann B. Guðmundsson
only wanted to maintain a single unit file but cross
distribution compatibility and the importance of it
is something you dont seem to be capable of grasping
since the only use cases that matters is the one that
is specific and relevant to you"
no, but you don't grasp that options for systemd-units as well as units
itself are not only relevant for distributions or upstream but also
heavily used by sysadmins and that you have *no bussiness* to tell
somebody "something you do via"

you are free to do that when someone asks for new features, but not in
case of a planned regression - nothing else is taking features and
options away
Post by Jóhann B. Guðmundsson
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or
*anything* else in the apache configuration
You apparently did not read or grasp what I said earlier.
This is something you do via unit overwrite configuration snipped in
conjunction with your Apache configuration changes not in an environment
file.
this is something *i do not* with unit overwrite configuration by
intention because i DO NOT want to touch ExecStart on any machine
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
perhaps it's time to
start looking into obsoleting it
don't get me wrong but you sound once again like seek for changes to
break users configuration to later blame users why they did not fix
which ain't broken
You cannot be gotten right.
The follow up cleanup process in Fedora that I needed to conduct after
the unit migration was completed, would have among other things
obsoleted and removed those Fedora/RedHat specific environment files
since it became clear immediately at that time that they had been
obsoleted
cleanup whatever you want in Fedora, i don't use httpd or other server
packages from the distribution at all - by removing "EnvironmentFile"
from systemd you piss of users and sysadmins, not only distributions
Andrei Borzenkov
2015-12-11 03:56:37 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or
*anything* else in the apache configuration
You apparently did not read or grasp what I said earlier.
This is something you do via unit overwrite configuration snipped in
conjunction with your Apache configuration changes not in an environment
file.
Care to show example how it should be done from your point of view? So
that they can actully be compared?
Jóhann B. Guðmundsson
2015-12-11 14:45:15 UTC
Permalink
Post by Andrei Borzenkov
Care to show example how it should be done from your point of view?
So that they can actully be compared?
You just create an configuration snipped that replaces the ExecStart
line for the daemon in the unit file with startup options for the daemon
which contains the options you want to change or copy/edit the full unit
and replace it.

In his sample case above where he's using ExecStart=/usr/sbin/httpd
$OPTIONS -D FOREGROUND and the environment file /etc/sysconfig/httpd
you would create an configuration snippet which contains
"ExecStart=/usr/sbin/httpd -D testserver -D FOREGROUND" instead .

The only reason I can think of why distributions decided to split
configuration out of the legacy sys v initscripts to begin ( you used to
just tweak it there ) is because the legacy sysv initscript had become
such a mess that administrator ended up breaking them when they did but
perhaps someone else posses the historic knowledge why distributions
started doing that.

JBG
Reindl Harald
2015-12-11 14:59:54 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Andrei Borzenkov
Care to show example how it should be done from your point of view?
So that they can actully be compared?
You just create an configuration snipped that replaces the ExecStart
line for the daemon in the unit file with startup options for the daemon
which contains the options you want to change or copy/edit the full unit
and replace it.
In his sample case above where he's using ExecStart=/usr/sbin/httpd
$OPTIONS -D FOREGROUND and the environment file /etc/sysconfig/httpd
you would create an configuration snippet which contains
"ExecStart=/usr/sbin/httpd -D testserver -D FOREGROUND" instead
and that's exactly what i don't want to do for damned good reasons

* in the past i started httpd with type=forking
* it was just "/usr/sbin/httpd $OPTIONS"
* switch to "Type=simple" was change the untit in our own
maintained rpm-package and add "-D FOREGROUND" too

"distribute-updates.sh" and all machines in the cluster where changed,
you can't act that way when you have on each and every machine a snippet
to change

EnvironmentFile is a great way to make units flexible with sane defaults
and i am *not* talking about upstream or distributions here

so taking away that option gains you nothing but breaks things for no
valid reason - it would only confirm people which hesitate to adopt
systemd because the fear that they can't rely on capabilities it brings
now because they may flippantly disappear
Manuel Amador (Rudd-O)
2015-12-26 19:00:22 UTC
Permalink
Post by Reindl Harald
and that's exactly what i don't want to do for damned good reasons
* in the past i started httpd with type=forking
* it was just "/usr/sbin/httpd $OPTIONS"
* switch to "Type=simple" was change the untit in our own
maintained rpm-package and add "-D FOREGROUND" too
Hi. Here is how you solve the problem with the right tool for the job:

---
# configapache.yml
hosts: apacheservers
sudo: True
tasks:
- name: configure apache
template:
dest: /etc/httpd/conf/httpd.conf
src: httpd.conf.jinja2
notify: reload apache
- name: copy testserver stuff
copy:
dest: /etc/httpd/conf/local/testserver.conf
src: testserver.conf
notify: reload apache
handlers:
- name: reload apache
service: httpd state=reloaded

---
# httpd.conf.jinja2
...standard config...
{% if apache.testserver %}
Include "conf/local/testserver.conf"
{% endif %}

---
# host_vars/apache1.yml
apache:
testserver: True

---
# hosts
apache1
apache2
apache3
postfix1
postfix2

[apacheservers]
apache1
apache2
apache3

---
# your prompt
ansible-playbook -v configapache.yml

There you go -- a quick way to do proper Apache configuration without
dicking with EnvironmentFiles that *actually preserves the ability to
reload Apache with no downtime!*
--
Rudd-O
http://rudd-o.com/
Simon Peeters
2015-12-15 17:59:11 UTC
Permalink
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or *anything*
else in the apache configuration
Post by Jóhann B. Guðmundsson
perhaps it's time to
start looking into obsoleting it
don't get me wrong but you sound once again like seek for changes to break
users configuration to later blame users why they did not fix which ain't
broken
Why not do like normal people and use configmanagement to put the
right apache config on the right host?
This whole "-D testserver" and "<IfDefine testserver>" looks like an
ugly workaround for a lacking configmanagment system.

More preciesly conf/local/testserver.conf probably shouldn't even
exist on non testing mahines. (a simple "file {
'/etc/…/testserver.conf': ensure => absent }" in puppet or "file:
path='/etc/…/testserver.conf' state=absent" in ansable)
If you have that you could probably even hardcode an
"IncludeOptional", though i still would advice against it, and just
conditionalize the line in your configmanagement (usinge lineinfile or
so.)

Greetings

Simon.
Reindl Harald
2015-12-16 09:47:59 UTC
Permalink
Post by Simon Peeters
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or *anything*
else in the apache configuration
Post by Jóhann B. Guðmundsson
perhaps it's time to
start looking into obsoleting it
don't get me wrong but you sound once again like seek for changes to break
users configuration to later blame users why they did not fix which ain't
broken
Why not do like normal people
"normal people" - what's wrong with you?
Post by Simon Peeters
and use configmanagement to put the
right apache config on the right host?
because i know how to configure servers and don't need handholding tools
since i develop my own admin backends for many years and services
helping on repeatly needed taks but don't chain me to a limited subset
of the supported options
Post by Simon Peeters
This whole "-D testserver" and "<IfDefine testserver>" looks like an
ugly workaround for a lacking configmanagment system.
config managements fpr webservers are ugly workaround for lacking
knowledge and only fine for 08/15 setups but a no-go where you need
flexibility
Post by Simon Peeters
More preciesly conf/local/testserver.conf probably shouldn't even
exist on non testing mahines
guess why it's in the subfolder "local"
Post by Simon Peeters
'/etc/
/testserver.conf': ensure => absent }" in puppet
go away with that crap - only over my dead body besides Perl, PHP and
Python now Ruby and it's dependencies would make it to any server here
Simon Peeters
2015-12-16 16:11:43 UTC
Permalink
Post by Reindl Harald
Post by Simon Peeters
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or *anything*
else in the apache configuration
Post by Jóhann B. Guðmundsson
perhaps it's time to
start looking into obsoleting it
don't get me wrong but you sound once again like seek for changes to break
users configuration to later blame users why they did not fix which ain't
broken
Why not do like normal people
"normal people" - what's wrong with you?
Nothing really, all systems both at my direct employer and those at
our customers run perfectly fine, and everything is automated, so in
our relatively small team we have more than enough time left to de
some R&D on future and upcoming tech.
Post by Reindl Harald
Post by Simon Peeters
and use configmanagement to put the
right apache config on the right host?
because i know how to configure servers and don't need handholding tools
since i develop my own admin backends for many years and services helping on
repeatly needed taks but don't chain me to a limited subset of the supported
options
If you want to use your home grown configmanagement tool, then learn
it to decently manage your apache config.
Post by Reindl Harald
Post by Simon Peeters
This whole "-D testserver" and "<IfDefine testserver>" looks like an
ugly workaround for a lacking configmanagment system.
config managements fpr webservers are ugly workaround for lacking knowledge
and only fine for 08/15 setups but a no-go where you need flexibility
I think a lot of people disagree with you on that, including most of
the devops world.
Post by Reindl Harald
Post by Simon Peeters
More preciesly conf/local/testserver.conf probably shouldn't even
exist on non testing mahines
guess why it's in the subfolder "local"
Post by Simon Peeters
'/etc/…/testserver.conf': ensure => absent }" in puppet
go away with that crap - only over my dead body besides Perl, PHP and Python
now Ruby and it's dependencies would make it to any server here
Then use something else, like ansible, which is python, or cfengine,
or juju, or any other one in this list
https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software

My point being if you want to manage your apache config, manage your
apache config, intead of doing wierd workarounds with environment
variables and changing the ExecStart of your service.

In your case this is even flawed:
If the /etc/sysconfig/httpd file changes, then a systemctl reload
httpd wouldn't propagate the changes, while if you instead managed the
config directly it would.
Reindl Harald
2015-12-16 16:28:33 UTC
Permalink
Post by Simon Peeters
Post by Reindl Harald
Post by Simon Peeters
Why not do like normal people
"normal people" - what's wrong with you?
Nothing really, all systems both at my direct employer and those at
our customers run perfectly fine, and everything is automated, so in
our relatively small team we have more than enough time left to de
some R&D on future and upcoming tech.
so we do - 35 servers running Fedora and keep up-to-date from F9 to F23
while i do the development of the software running on top at the same
time and one additional team member helps out
Post by Simon Peeters
Post by Reindl Harald
Post by Simon Peeters
and use configmanagement to put the
right apache config on the right host?
because i know how to configure servers and don't need handholding tools
since i develop my own admin backends for many years and services helping on
repeatly needed taks but don't chain me to a limited subset of the supported
options
If you want to use your home grown configmanagement tool, then learn
it to decently manage your apache config.
it does exactly what it is supposed to do and all is runnign perfectly
fine as long not somebody breaks working things things by remove feautes
for no good reason
Post by Simon Peeters
Post by Reindl Harald
Post by Simon Peeters
This whole "-D testserver" and "<IfDefine testserver>" looks like an
ugly workaround for a lacking configmanagment system.
config managements for webservers are ugly workaround for lacking knowledge
and only fine for 08/15 setups but a no-go where you need flexibility
I think a lot of people disagree with you on that, including most of
the devops world.
most of that people are using LTS distributions where you don't have
major jumps - it's enough to care about major upgrades itself and i
don't need the burden "does config mgmt xyz support version a of
serversoftware b"

for my own development not rely on any 3rd party libraries i can
guarantee that there are no compatibility breaks and since that works
now over nearly 15 years inclduing a complete jump from Apple to Fedora
i am proven right

no, i don't say you or anybody else should do it the same way, do what
you want, in the area where i am responsible i do the things which are
proven to work with as less complexity and dependencies as possible
Post by Simon Peeters
Post by Reindl Harald
go away with that crap - only over my dead body besides Perl, PHP and Python
now Ruby and it's dependencies would make it to any server here
Then use something else, like ansible, which is python, or cfengine,
or juju, or any other one in this list
https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software
introducing another layer of complexity on a environment which works
relieable and rock stable over many years and everybody who needs to
touch it understands how and why things are working as they are supposed
to do would be stupid

KISS - keep it simple stupid
Post by Simon Peeters
My point being if you want to manage your apache config, manage your
apache config, intead of doing wierd workarounds with environment
variables and changing the ExecStart of your service.
If the /etc/sysconfig/httpd file changes, then a systemctl reload
httpd wouldn't propagate the changes, while if you instead managed the
config directly it would
well, you are talking about a no-problem since that file changed 3 times
in 8 years where a hard restart of httpd is a no-brainer just because
it's more often needed after PHP, zlib, pcre and what not updates
Manuel Amador (Rudd-O)
2015-12-26 19:02:10 UTC
Permalink
Post by Reindl Harald
"normal people" - what's wrong with you?
Us "normal people" use configuration management systems to properly do
what you do with ugly hacks.

It's 2015. cfengine is not the only game in town. Check my last
email. It took me two minutes to write an entire configuration system
that you could use today, to solve your problem *properly and with
proper change management* / version control.

Environment files... bah.
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 19:06:18 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
"normal people" - what's wrong with you?
Us "normal people" use configuration management systems to properly do
what you do with ugly hacks.
It's 2015. cfengine is not the only game in town. Check my last
email. It took me two minutes to write an entire configuration system
that you could use today, to solve your problem *properly and with
proper change management* / version control.
Environment files... bah
people needing handholding - bah - for version control etckeeper does a
damn good job, vhsot-configs are generated by templates and for the
basic host configuration i don't need tools since i got a brain

so do me a favour and creep away with your attitude press reply days and
weeks later to every single post on a topic
Manuel Amador (Rudd-O)
2015-12-26 19:19:42 UTC
Permalink
Post by Reindl Harald
people needing handholding - bah
See, your problem is more a limited mindset / perspective problem.

From your attitude, you believe it's demeaning to use the proper tool
for the job, taking it as a point of pride that you have deficient and
obsolete tools at your disposal.

From your attitude, you also believe everyone else is obligated to
maintain and support ugly workarounds that result in broken systems
(e.g. no properly working reload).
Post by Reindl Harald
- for version control etckeeper does a damn good job,
Your attitude also tells me that you don't understand the value of
proper version control, with branching, merging, and possibly code
reviews. In other words, that you don't see your infrastructure and
configuration as something to be managed as professionally as any other
software engineering project.
Post by Reindl Harald
vhsot-configs are generated by templates
Guess how Ansible works.
Post by Reindl Harald
and for the basic host configuration i don't need tools since i got a
brain
You'll be needing that brain since no configuration management tool
generates those base configs for you.
Post by Reindl Harald
so do me a favour and creep away with your attitude press reply days
and weeks later to every single post on a topic
No, I don't think I will be taking orders from you.

Here's what I think happened to you in the past. You learned a bit of
bash, SysVinit, and etckeeper. You decided this was going to be THE
THING for you -- your ultimate portfolio of skills -- forever for the
rest of your life.

Then us DevOps and systemd folks came crashing into your obsolescence party.

You resent that -- it's exceedingly obvious from your attitude that you
do. That's why you've treated other people badly here.

It's time to evolve. Arguably, it was time a few years ago. Dust up
your learning cap and re-learn how things are done now. Or pretty soon,
/you/ will be what becomes obsolete.
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 19:28:19 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
people needing handholding - bah
See, your problem is more a limited mindset / perspective problem.
From your attitude, you believe it's demeaning to use the proper tool
for the job, taking it as a point of pride that you have deficient and
obsolete tools at your disposal.
From your attitude, you also believe everyone else is obligated to
maintain and support ugly workarounds that result in broken systems
(e.g. no properly working reload).
DAMNED everybody else should use what he like

i just puke about the attitude of peole like Johann feeling the need to
demand changes and remove features all the time

there are no broken systems here - period
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
- for version control etckeeper does a damn good job,
Your attitude also tells me that you don't understand the value of
proper version control, with branching, merging, and possibly code
reviews. In other words, that you don't see your infrastructure and
configuration as something to be managed as professionally as any other
software engineering project.
my infrastructure is most likely better managed than anyone leses
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
so do me a favour and creep away with your attitude press reply days
and weeks later to every single post on a topic
No, I don't think I will be taking orders from you.
you are not in the position to give orders
Post by Manuel Amador (Rudd-O)
Here's what I think happened to you in the past. You learned a bit of
bash, SysVinit, and etckeeper. You decided this was going to be THE
THING for you -- your ultimate portfolio of skills -- forever for the
rest of your life.
bullshit - my portfolio of skills goes far above things you can imagine,
i just refuse to fix things which ain't broken becase i have a lot of
other work which is worth the time
Post by Manuel Amador (Rudd-O)
Then us DevOps and systemd folks came crashing into your obsolescence party.
You resent that -- it's exceedingly obvious from your attitude that you
do. That's why you've treated other people badly here.
bla
Post by Manuel Amador (Rudd-O)
It's time to evolve. Arguably, it was time a few years ago. Dust up
your learning cap and re-learn how things are done now. Or pretty soon,
/you/ will be what becomes obsolete
impressive what a arrgoant asshole you are while talking about "treated
other people badly here" - maybe you did not grok it - my main job is
software-developer *on top* of the perfect working infrastructure and
before people like me knowing to hanle and develop backends and
frontends for hundrets of customer over any service level hell freezes over
Manuel Amador (Rudd-O)
2015-12-26 19:39:20 UTC
Permalink
Post by Reindl Harald
my infrastructure is most likely better managed than anyone leses
So says the person with a limited perspective and a refusal to learn
modern tools and processes.
Post by Reindl Harald
you are not in the position to give orders
Did you just forget that it was YOU giving me an order, and not the
other way around?

Who are, you? https://reddit.com/r/KenM/ ? You gotta be Ken M.
Post by Reindl Harald
bullshit - my portfolio of skills goes far above things you can imagine,
https://reddit.com/r/iamverysmart/
Post by Reindl Harald
bla
Typical.
Post by Reindl Harald
impressive what a arrgoant asshole you are while talking about
"Arrogant" is the guy who refuses to accept new ways of doing things,
because he thinks that the way he does things is perfect and damn those
youngsters running on his lawn with their hand-holding helpers.

(That'd be you.)
Post by Reindl Harald
"treated other people badly here" - maybe you did not grok it - my
main job is software-developer *on top* of the perfect working
infrastructure and before people like me knowing to hanle and develop
backends and frontends for hundrets of customer over any service level
hell freezes over
With the two nines reliability you give them on account of not being
able to do outage-free reloads of Apache...

Ouch
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 19:46:56 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
impressive what a arrgoant asshole you are while talking about
"Arrogant" is the guy who refuses to accept new ways of doing things,
because he thinks that the way he does things is perfect and damn those
youngsters running on his lawn with their hand-holding helpers.
(That'd be you.)
which youngsters?

maybe you are one of the youngsters not able to make a difference
between well reasoned changes and doing things "the new ways" just for
the sake of change

i prefer to implement "new ways of doing" in my 24 hours day where it
actually makes sense and not where sombody with no business to speak up
at all says i have to do so
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
"treated other people badly here" - maybe you did not grok it - my
main job is software-developer *on top* of the perfect working
infrastructure and before people like me knowing to hanle and develop
backends and frontends for hundrets of customer over any service level
hell freezes over
With the two nines reliability you give them on account of not being
able to do outage-free reloads of Apache...
Ouch
DAMNED: i explained you often enough that "EnvironmentFile" don#t change
that often and so don't have any impact in outage-free reloads
Reindl Harald
2015-12-29 23:01:27 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
my infrastructure is most likely better managed than anyone leses
So says the person with a limited perspective and a refusal to learn
modern tools and processes
the person with a limited perspective yet converted cronjobs using a
sourced shell script for a update-system where base locations for every
server are defined by sourcing a shellscript just defining env-vars

that's part of a complex deplyoment and maintainance infrastrcuture for
some hundret webhosts on a dozen of servers

guess what: EnvironmentFile can reuse that file which needs still to be
there for configure a ton of CLI scripts for different tasks

reason for the change to a oneshot-systemd unit?
to restrict capabilities and write/read permissions more

there is a world outside "the daemon" at all1

EnvironmentFile=/scripts/cl-update-service.inc.sh
Type=oneshot
ExecStart=/path/to/cronscript
User=wwwcron
Group=apache
PrivateTmp=yes
PrivateDevices=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_KILL CAP_CHMOD CAP_FOWNER
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib
ReadOnlyDirectories=/proc
ReadOnlyDirectories=/sys
InaccessibleDirectories=-/boot
InaccessibleDirectories=-/home
InaccessibleDirectories=-/media
InaccessibleDirectories=-/root
InaccessibleDirectories=-/etc/dbus-1
InaccessibleDirectories=-/etc/modprobe.d
InaccessibleDirectories=-/etc/modules-load.d
InaccessibleDirectories=-/etc/postfix
InaccessibleDirectories=-/etc/ssh
InaccessibleDirectories=-/etc/sysctl.d
InaccessibleDirectories=-/run/console
InaccessibleDirectories=-/run/dbus
InaccessibleDirectories=-/run/lock
InaccessibleDirectories=-/run/mount
InaccessibleDirectories=-/run/systemd/generator
InaccessibleDirectories=-/run/systemd/system
InaccessibleDirectories=-/run/systemd/users
InaccessibleDirectories=-/run/udev
InaccessibleDirectories=-/run/user

Manuel Amador (Rudd-O)
2015-12-26 19:04:54 UTC
Permalink
Post by Reindl Harald
because i know how to configure servers and don't need handholding
tools since i develop my own admin backends for many years and
services helping on repeatly needed taks but don't chain me to a
limited subset of the supported options
Ah.

So the others were right -- you don't want to learn something new
because you're so set in your ways, you have your own in-house stuff
that you don't want to replace by learning something new.

Even the expression you use for professional systems -- "handholding
tools" -- reveals your contempt for what you don't know.

Sigh.

This is the perfect picture of the systemd hater.
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 19:10:02 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
because i know how to configure servers and don't need handholding
tools since i develop my own admin backends for many years and
services helping on repeatly needed taks but don't chain me to a
limited subset of the supported options
Ah.
So the others were right -- you don't want to learn something new
because you're so set in your ways, you have your own in-house stuff
that you don't want to replace by learning something new.
i learn enough new all the time
Post by Manuel Amador (Rudd-O)
Even the expression you use for professional systems -- "handholding
tools" -- reveals your contempt for what you don't know.
i know more than you can imagine
Post by Manuel Amador (Rudd-O)
This is the perfect picture of the systemd hater
systemd hater?

ah, that must be the reason why i migrated Fedora sysvinit-scripts long
before most maintainers on our installs and use systemd-features most
package maintainers even don't know and systemd-upstream don#t test well
(otherwise things like ReadOnlyDirectories=/var/lib combined with
ReadWriteDirectories=-/var/lib/smokeping would not have been broken
horrible in Fedora 21)
Lennart Poettering
2015-12-23 00:24:28 UTC
Permalink
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or *anything*
else in the apache configuration
Well, there's not much difference in touching weird env var files or
the unit files themselves. I fail to see what the benefit of not
touching the unit files could be...

Also, what you do above sounds like a job for unit file templates...

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2015-12-23 01:44:54 UTC
Permalink
Post by Lennart Poettering
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or *anything*
else in the apache configuration
Well, there's not much difference in touching weird env var files or
the unit files themselves. I fail to see what the benefit of not
touching the unit files could be...
Also, what you do above sounds like a job for unit file templates...
since the functionality already exists and i am not a distribution "i am
comfortable with it for years" should be enough - don't fix things which
ain't broken
Lennart Poettering
2015-12-23 15:08:53 UTC
Permalink
Post by Reindl Harald
Post by Lennart Poettering
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
If you are unaware of any other use case for it
EnvironmentFile=-/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
OPTIONS="-D testserver"
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or *anything*
else in the apache configuration
Well, there's not much difference in touching weird env var files or
the unit files themselves. I fail to see what the benefit of not
touching the unit files could be...
Also, what you do above sounds like a job for unit file templates...
since the functionality already exists and i am not a distribution "i am
comfortable with it for years" should be enough - don't fix things which
ain't broken
Well, the point I was making is that I am pretty sure EnvironmentFile=
*is* a broken concept... So yes, the distros should fix that, and stop
using it.

Lennart
--
Lennart Poettering, Red Hat
Manuel Amador (Rudd-O)
2015-12-26 18:52:50 UTC
Permalink
Post by Reindl Harald
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or
*anything* else in the apache configuration
This sounds like you're aching to use something like Ansible or
SaltStack. Dozens of machines, that means you're going to be managing
dozens of files. Use a proper configuration management system.

Also note that with your defines "system", service apache reload stops
working. If you wrote those things /properly in the config files/ (like
you could do with Ansible or SaltStack), then no-downtime reload becomes
possible again.
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 18:58:38 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
<IfDefine testserver>
Include "conf/local/testserver.conf"
</IfDefine>
and now you can use the same systemd-unit on a dozens of machines and
include specific config snippets WITOUT touch the systemd-unit or
*anything* else in the apache configuration
This sounds like you're aching to use something like Ansible or
SaltStack. Dozens of machines, that means you're going to be managing
dozens of files. Use a proper configuration management system
i am capable to write my configs by hand withoput babysitting by Puppet
or something else - why sould i introduce security holes and making
things more complex than needed all over my environment when i know what
i am doing?

https://www.google.com/search?q=puppet+cve
Post by Manuel Amador (Rudd-O)
Also note that with your defines "system", service apache reload stops
working. If you wrote those things /properly in the config files/ (like
you could do with Ansible or SaltStack), then no-downtime reload becomes
possible again
uhm - "EnvironmentFile" don't change often and so reload is possible all
the time
Manuel Amador (Rudd-O)
2015-12-26 19:07:36 UTC
Permalink
Post by Reindl Harald
uhm - "EnvironmentFile" don't change often and so reload is possible
all the time
I never said you couldn't reload. I said that reload would not enact
your environment file changes.

Are you having trouble understanding what I wrote, or is it the dogma
talking?
--
Rudd-O
http://rudd-o.com/
Reindl Harald
2015-12-26 19:12:04 UTC
Permalink
Post by Manuel Amador (Rudd-O)
Post by Reindl Harald
uhm - "EnvironmentFile" don't change often and so reload is possible
all the time
I never said you couldn't reload. I said that reload would not enact
your environment file changes.
Are you having trouble understanding what I wrote, or is it the dogma
talking?
you said "reload would be possible again" - maybe you have trouble
express yourself proper - just get out of my way kid!
Manuel Amador (Rudd-O)
2015-12-26 19:21:59 UTC
Permalink
Post by Reindl Harald
you said "reload would be possible again"
Let me spell that sentence out in context:

If you stopped using EnvironmentFile and starting actually assembling
proper configurations using a configuration management tool, then the
command "systemctl reload httpd.service" would work properly again, as
opposed to how it is broken now in your own systems.
Post by Reindl Harald
- maybe you have trouble express yourself proper
Look who's talking.
--
Rudd-O
http://rudd-o.com/
Manuel Amador (Rudd-O)
2015-12-26 19:09:36 UTC
Permalink
Post by Reindl Harald
i am capable to write my configs by hand withoput babysitting by
Puppet or something else
What a macho man!

Guess what: those of us who use configuration systems also write configs
by hand. We just aren't tied to deficient workarounds like the one
you're clinging so hard to.
Post by Reindl Harald
- why sould i introduce security holes and making things more complex
than needed all over my environment when i know what i am doing?
I never told you to use Puppet. I wouldn't use it myself.

The Ansible configuration I wrote here in another email for you, happens
to work perfectly for your use case, does not require to install any
sort of new daemons or services or cronjobs, and has the benefit that
you can version it like any other normal piece of code (because
configuration IS code, just not executable code).
--
Rudd-O
http://rudd-o.com/
Michael Biebl
2015-12-18 16:00:32 UTC
Permalink
Post by Lennart Poettering
Post by Soumya Koduri
Hi,
[Unit]
After=nfs-ganesha-config.service
Requires=nfs-ganesha-config.service
....
[Service]
EnvironmentFile=-/run/sysconfig/ganesha
ExecStart=/usr/bin/ganesha.nfsd $OPTIONS ${EPOCH}
(But honestly, there's really no point in trying to dynamically
convert stuff into a file that is suitable for EnvironmentFile=. I
mean, if you want a shell script, then use a shell script, and invoke
that from the main daemon's ExecStart= line, and make it exec the real
daemon as last step. There's really no point in playing these
multi-service conversion games. Also /etc/sysconfig is a Redhatism
that should really go away, the whole concept is flawed. Adding a new
/run/sysconfig/ certainly makes that even worse.)
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection.
I do think that overriding the complete ExecStart= line is usually
suboptimal and not what you want if you just want to pass additional
options to the daemon.

Maybe a good middle ground / recommendation for such daemons would be,
to ship a line

ExecStart=/usr/sbin/foobard $OPTS

and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz

bonus points if we could standardise the $OPTS var name across daemons.

Then distros like Fedora could do a one-time migration of their
settings in /etc/sysconfig/foobar and drop the file after the upgrade.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Tomasz Torcz
2015-12-20 13:34:15 UTC
Permalink
Post by Michael Biebl
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
How would I do the equivalent of systemctl edit with a declarative
configuration management tool like puppet?
You have to make sure directory /etc/systemd/system/nfs-ganesha.service.d/
exists, then inside you create something.conf file with above content.

Alternatively you can create /etc/systemd/system/nfs-ganesha.service file
with required customisation, using puppet.

Afterwards you need to issue "systemctl daemon-reload" (or send signal
to PID1) to have the changes read.
--
Tomasz Torcz Once you've read the dictionary,
xmpp: ***@chrome.pl every other book is just a remix.
Andrei Borzenkov
2015-12-20 17:26:24 UTC
Permalink
Post by Tomasz Torcz
Post by Michael Biebl
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
How would I do the equivalent of systemctl edit with a declarative
configuration management tool like puppet?
You have to make sure directory /etc/systemd/system/nfs-ganesha.service.d/
exists, then inside you create something.conf file with above content.
Is that the documented interface equivalent to systemctl edit? Does
the stability promise apply?
Yes to both. At the end that is exactly what "systemctl edit" does.
Post by Tomasz Torcz
Afterwards you need to issue "systemctl daemon-reload" (or send signal
to PID1) to have the changes read.
That's a regression over the old-fashioned way, but doable.
Greetings
Marc
Jóhann B. Guðmundsson
2015-12-21 11:40:10 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
Post by Soumya Koduri
Hi,
[Unit]
After=nfs-ganesha-config.service
Requires=nfs-ganesha-config.service
....
[Service]
EnvironmentFile=-/run/sysconfig/ganesha
ExecStart=/usr/bin/ganesha.nfsd $OPTIONS ${EPOCH}
(But honestly, there's really no point in trying to dynamically
convert stuff into a file that is suitable for EnvironmentFile=. I
mean, if you want a shell script, then use a shell script, and invoke
that from the main daemon's ExecStart= line, and make it exec the real
daemon as last step. There's really no point in playing these
multi-service conversion games. Also /etc/sysconfig is a Redhatism
that should really go away, the whole concept is flawed. Adding a new
/run/sysconfig/ certainly makes that even worse.)
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection.
I do think that overriding the complete ExecStart= line is usually
suboptimal and not what you want if you just want to pass additional
options to the daemon.
Maybe a good middle ground / recommendation for such daemons would be,
to ship a line
ExecStart=/usr/sbin/foobard $OPTS
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
bonus points if we could standardise the $OPTS var name across daemons.
Then distros like Fedora could do a one-time migration of their
settings in /etc/sysconfig/foobar and drop the file after the upgrade.
This makes no sense.

Here you are just adding an extra line with no value on top of requiring
some form of standardize the $OPTS var name across daemons ( as opposed
to administrators simply change the value of the line directly ).

Best practice and the least amount of work for administrator ( both in
editing and for other administrators to keep taps on changes made by
others ) is to copy/edit the entire unit.

Lennart can better explain what value he saw in introducing those
snippets compared to that since he introduced them in the first place.

JBG
Reindl Harald
2015-12-21 13:00:53 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Michael Biebl
ExecStart=/usr/sbin/foobard $OPTS
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
bonus points if we could standardise the $OPTS var name across daemons.
Then distros like Fedora could do a one-time migration of their
settings in /etc/sysconfig/foobar and drop the file after the upgrade.
This makes no sense.
for you!
Post by Jóhann B. Guðmundsson
Here you are just adding an extra line with no value on top of requiring
some form of standardize the $OPTS var name across daemons ( as opposed
to administrators simply change the value of the line directly ).
Best practice and the least amount of work for administrator ( both in
editing and for other administrators to keep taps on changes made by
others ) is to copy/edit the entire unit.
only when you think in a short-term

in a long term your service may break because you change the ExecStart
and so miss new or changed parameters of the distro-package for example
when a param is no longer supported and the new version fixes that with
the shipped unit
Post by Jóhann B. Guðmundsson
Lennart can better explain what value he saw in introducing those
snippets compared to that since he introduced them in the first place
nobody is taking that way, but the world is not black/white
Jóhann B. Guðmundsson
2015-12-21 13:23:29 UTC
Permalink
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Post by Michael Biebl
ExecStart=/usr/sbin/foobard $OPTS
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
bonus points if we could standardise the $OPTS var name across daemons.
Then distros like Fedora could do a one-time migration of their
settings in /etc/sysconfig/foobar and drop the file after the upgrade.
This makes no sense.
for you!
What he proposed is redundant and adds an extra line to the unit file
and in addition requires some distro's acceptance that upstream needs to
be aware of when it creates the unit for it's daemon/service.

His proposal

[Unit]
Description=Sample unit
# Unesseray line added
Environment=OPTS=FOO

[Service]
ExecStart=/path/to/daemon $OPTS

[Install]
WantedBy=multi-user.target

VS standard without any environment entry and does not require upstream
being aware of any standardization or lack there of in downstream
distributions.

[Unit]
Description=Sample unit

[Service]
ExecStart=/path/to/daemon FOO

[Install]
WantedBy=multi-user.target

By all means enlighten me the benefits of his proposal which makes sense
and does not add unnecessary line to the type unit file along with the
complexity it might bring ( think larger type units ).

JBG
Reindl Harald
2015-12-21 13:30:56 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
Post by Jóhann B. Guðmundsson
Post by Michael Biebl
ExecStart=/usr/sbin/foobard $OPTS
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
bonus points if we could standardise the $OPTS var name across daemons.
Then distros like Fedora could do a one-time migration of their
settings in /etc/sysconfig/foobar and drop the file after the upgrade.
This makes no sense.
for you!
What he proposed is redundant and adds an extra line to the unit file
and in addition requires some distro's acceptance that upstream needs to
be aware of when it creates the unit for it's daemon/service.
By all means enlighten me the benefits of his proposal which makes sense
and does not add unnecessary line to the type unit file along with the
complexity it might bring ( think larger type units )
by all means don't premature stop reading and press reply

in a long term your service may break because you change the ExecStart
and so miss new or changed parameters of the distro-package for example
when a param is no longer supported and the new version fixes that with
the shipped unit

i explained that already

Environment=OPTS=FOO could be a snippet

ExecStart=/path/to/daemon FOO would cut you from distro-changes in other
params and explained abvoe sooner or later lead in failing and could
even be security relevant depending on new options or removed options in
the distro-unit
Jóhann B. Guðmundsson
2015-12-21 14:08:32 UTC
Permalink
Post by Reindl Harald
ExecStart=/path/to/daemon FOO would cut you from distro-changes in
other params and explained abvoe sooner or later lead in failing and
could even be security relevant depending on new options or removed
options in the distro-unit
You do realize you have the exact same chances with an environment entry
line do you not?

The options being used there could be deprecated in the daemon startup
and for those daemon/services that are capable of reading their own
configuration files ( and thus those environment lines are not
applicable to ) are never changed on updates..

When an administrators makes a change to an configuration ( or in this
case type unit ) he is stating that he's deviating from the
distributions shipped defaults for that components and since there is no
reliable way for a system to detect and determine manual changes in
configuration, there is always the risk that an update will break
running system ( the administrators made changes ) which is why the
configuration files for a running daemon/service are saved as copy's and
the administrator who has made the deviation is expected to review and
apply those changes himself.

JBG
Reindl Harald
2015-12-21 14:15:02 UTC
Permalink
Post by Jóhann B. Guðmundsson
Post by Reindl Harald
ExecStart=/path/to/daemon FOO would cut you from distro-changes in
other params and explained abvoe sooner or later lead in failing and
could even be security relevant depending on new options or removed
options in the distro-unit
You do realize you have the exact same chances with an environment entry
line do you not?
similar, but no *the same*

overwrite "ExecStart" would also break services which changed from
"simple" to "forking" or the other direction
Post by Jóhann B. Guðmundsson
The options being used there could be deprecated in the daemon startup
and for those daemon/services that are capable of reading their own
configuration files ( and thus those environment lines are not
applicable to ) are never changed on updates..
yes they *could*
Post by Jóhann B. Guðmundsson
When an administrators makes a change to an configuration ( or in this
case type unit ) he is stating that he's deviating from the
distributions shipped defaults for that components and since there is no
reliable way for a system to detect and determine manual changes in
configuration, there is always the risk that an update will break
running system ( the administrators made changes ) which is why the
configuration files for a running daemon/service are saved as copy's and
the administrator who has made the deviation is expected to review and
apply those changes himself
and since you say this what is your business for taking
"EnvironmentFile" away from administrators area - my config, take your
hands from it instead propose to break it - nobody cares if you would
something do in a different way as long you are not trying to force
others change their setups for no good reason
Jóhann B. Guðmundsson
2015-12-21 16:11:18 UTC
Permalink
Post by Reindl Harald
and since you say this what is your business for taking
"EnvironmentFile" away from administrators area - my config, take your
hands from it instead propose to break it - nobody cares if you would
something do in a different way as long you are not trying to force
others change their setups for no good reason
Because environmental lines or files that are spesific to daemon startup
( not it's environment ) have no value being there in the first place
none what so ever and I'm saying this after going through and migrate
around 400 legacy sysv initscripts and inspecting about 200 more.

They might have served some value in the legacy sysv initscripts since
those where in the lines of hundreds ( the largest I migrated was about
800 - 900 lines long ) but for some reason distribution decided to move
the OPT= or OPTIONS= from the sysv scripts and into their own specific
environmental file instead ( you used to configure it directly in the
initscript itself and upstream could just ship it like that regardless
of the distribution most likely distribution did so due to the share
size of those legacy sysv initscripts ).

JBG
Michael Biebl
2015-12-21 15:17:38 UTC
Permalink
What he proposed is redundant and adds an extra line to the unit file and in
addition requires some distro's acceptance that upstream needs to be aware
of when it creates the unit for it's daemon/service.
His proposal
[Unit]
Description=Sample unit
# Unesseray line added
Environment=OPTS=FOO
[Service]
ExecStart=/path/to/daemon $OPTS
That's not what I proposed.

What I proposed was, that the ExecStart contains a $OPTS (which by
default would be empty).

This would allow the admin to extend the ExecStart line easily with a
drop-in snippet using Environment=

I didn't suggest adding a line Environment=OPTS=FOO by default.

The benefit of that instead of having to override the complete
ExecStart line should be obvious and has already be mentioned in this
very thread.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Jóhann B. Guðmundsson
2015-12-21 16:00:47 UTC
Permalink
Post by Michael Biebl
The benefit of that instead of having to override the complete
ExecStart line should be obvious and has already be mentioned in this
very thread.
No what's obvious is it does not add any value not et all and not all
daemons and service support additional environmental options added to
them et all so adding an empty environmental line just for the sake of
adding it makes even less sense,
Michael Biebl
2015-12-21 16:02:43 UTC
Permalink
Post by Jóhann B. Guðmundsson
No what's obvious is it does not add any value not et all
Well, I can reiterate the points, but I suggest you just read this thread again.

and not all
Post by Jóhann B. Guðmundsson
daemons and service support additional environmental options added to them
et all so adding an empty environmental line just for the sake of adding it
makes even less sense,
Obviously, if a daemon doesn't support command line (or env) args, you
would not add a $OPTS.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Jóhann B. Guðmundsson
2015-12-21 16:30:25 UTC
Permalink
Post by Michael Biebl
Post by Jóhann B. Guðmundsson
No what's obvious is it does not add any value not et all
Well, I can reiterate the points, but I suggest you just read this thread again.
and not all
Post by Jóhann B. Guðmundsson
daemons and service support additional environmental options added to them
et all so adding an empty environmental line just for the sake of adding it
makes even less sense,
Obviously, if a daemon doesn't support command line (or env) args, you
would not add a $OPTS.
It's an added work to add the environmental line to begin with and it's
an equal amount of work for administrators to change the environmental
line or the Exec= line(s) so the benefit is none
( note that I'm referring to systemd being the only initsystem ).

With environmental files administrators will have to keep tabs on two
files ( the unit file along with the associated environmental file ) as
well as their location ( due to distributions locating those files on
different places ) and upstream would have to support multiple
distribution specific unit as a results of that or downstream packagers
carry an additional patch which adds their distribution location to the
upstream unit file.

In a distribution that does or has to support multiple init systems
things look quite differently because there the component has to be
cross compatible with all the shipped/supported init system so you have
basically no other option but to include an environmental file reference
in the unit as well as specifying it in any other init system startup
script and have administrators make their changes there so those changes
can be retained ( on updates/upgrades ) regardless of which init system
is or was in use.

In Fedora the plan was to obsolete them altogether since those lines and
files did not add any benefits since systemd got introduced and
implemented as the only init system ( this became very clear in in F15 ) .

JBG
Michael Biebl
2015-12-21 16:36:17 UTC
Permalink
It's an added work to add the environmental line to begin with and it's an
That would be done once, by upstream ideally. The work would be negligible.
equal amount of work for administrators to change the environmental line or
the Exec= line(s) so the benefit is none
That is not true when considering upgrades.
With environmental files administrators will have to keep tabs on two files
I specifically didn't talk about EnvironmentFile=, but Environment=
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Jóhann B. Guðmundsson
2015-12-22 12:13:10 UTC
Permalink
Post by Michael Biebl
It's an added work to add the environmental line to begin with and it's an
That would be done once, by upstream ideally. The work would be negligible.
Still an added work either upstream/downstream + these still have to be
maintained/updated which people often neglect to take into consideration.
Post by Michael Biebl
equal amount of work for administrators to change the environmental line or
the Exec= line(s) so the benefit is none
That is not true when considering upgrades.
You are right but for that particular feature of systemd it's a question
for distribution/upstream whether it should not that it can.

Transparently updating type unit files on update/upgrades can break
running system/setups ( especially when it comes down to the security
options that systemd provides being added to those type unit files,
people have a hard time getting those right in general let alone taking
into considerations all the variants of setups out in the wild ) just
like upstream changes in configuration files for a set of
daemon/services ( httpd 2.2 vs 2.4 for example ).

Administrators on these parts want to have full control over their
systems since each downtime can cost significant amount of money for
their company or clients of their company so this feature is not even
considered a feature while hobby administrators, devops and plain end
users might consider this a feature since downtime is irrelevant or less
important to them and does not cost them money or even their job if it
happens.

Bottom line some people look at what you pointed out as con for using
environment to handle daemons startup options not as a feature while
others might.
Post by Michael Biebl
With environmental files administrators will have to keep tabs on two files
I specifically didn't talk about EnvironmentFile=, but Environment=
Right I was just pointing out that if the intent is to support multiple
init system then you must use EnvironmentFile=not Environment= to
achieve that goal.

JBG
Lennart Poettering
2015-12-23 00:32:46 UTC
Permalink
Post by Michael Biebl
I do think that overriding the complete ExecStart= line is usually
suboptimal and not what you want if you just want to pass additional
options to the daemon.
Maybe a good middle ground / recommendation for such daemons would be,
to ship a line
ExecStart=/usr/sbin/foobard $OPTS
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
bonus points if we could standardise the $OPTS var name across
daemons.
Well, I think the time would be better spent on fixing the daemons to
put their configuration in native config files, so that the process
command line becomes irrelevant.

In the httpd case, I figure it would make sense if Fedora would just
ship a ***@.service template whose instance name is used on a "-D"
switch or so... Multi-instantiable services are certainly a good idea
in many cases, in particular for web servers...

You know, I am fully aware that there will always be cases where
specific users want to change the cmdline of some random daemon. I
think the goal should be though that that's not the default case, but
very much the exception, and an exception where patching the command
line in the unit file is then fine. But introducing this $OPTS stuff
puts something in the focus of configuration that really shouldn't
be. If you regularly change the command line of a daemon on your
setups, then that's an indication that the daemon is misuing the
command line and should get better configuraiton files. And if you
only do it in exceptional cases, then editing the ExecStart= line is
completely fine and needs no concept of redirection.

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2015-12-23 01:45:56 UTC
Permalink
Post by Lennart Poettering
Post by Michael Biebl
I do think that overriding the complete ExecStart= line is usually
suboptimal and not what you want if you just want to pass additional
options to the daemon.
Maybe a good middle ground / recommendation for such daemons would be,
to ship a line
ExecStart=/usr/sbin/foobard $OPTS
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
bonus points if we could standardise the $OPTS var name across daemons.
Well, I think the time would be better spent on fixing the daemons to
put their configuration in native config files, so that the process
command line becomes irrelevant.
well, who would go out and change each and every upstream daemon
Lennart Poettering
2015-12-23 00:35:56 UTC
Permalink
Post by Michael Biebl
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
How would I do the equivalent of systemctl edit with a declarative
configuration management tool like puppet?
"systemctl edit" is just a helper that simplifies the following common
admin operation:

# mkdir -p /etc/systemd/system/foo.d
# vim /etc/systemd/system/foo.d/override.conf
# systemctl deamon-reload

The drop-ins logic (which this makes use of) is documented in the
man-pages, please have a look.

Lennart
--
Lennart Poettering, Red Hat
Manuel Amador (Rudd-O)
2015-12-26 19:10:38 UTC
Permalink
How would I do the equivalent of systemctl edit with a declarative
configuration management tool like puppet?
systemctl edit on a host
copy the file to your puppet server (ugh, don't use puppet, use ansible)
deploy file across hosts
--
Rudd-O
http://rudd-o.com/
Loading...