Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 20:39 schrieb Manuel Amador (Rudd-O):

On 12/26/2015 07:28 PM, Reindl Harald wrote:


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



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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/26/2015 06:44 PM, Reindl Harald wrote:
>
>
> Am 26.12.2015 um 19:41 schrieb Manuel Amador (Rudd-O):
>> On 12/23/2015 10:40 PM, Reindl Harald wrote:
>>
>> 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?

>
>> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/10/2015 11:42 AM, Simon McVittie wrote:
> 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 -  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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/26/2015 06:58 PM, Reindl Harald wrote:
>
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/26/2015 07:06 PM, Reindl Harald wrote:
> 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).

> - 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.

> vhsot-configs are generated by templates

Guess how Ansible works.

> 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.

>
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/23/2015 07:30 PM, Alex Crawford wrote:
> 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.
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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 19:41 schrieb Manuel Amador (Rudd-O):

On 12/23/2015 10:40 PM, Reindl Harald wrote:

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


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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/21/2015 10:29 PM, Marc Haber wrote:
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/21/2015 09:41 PM, Marc Haber wrote:
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/10/2015 03:20 PM, Reindl Harald wrote:
>
> Apache:
> 
> Include "conf/local/testserver.conf"
> 
>
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 19:49 schrieb 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





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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/26/2015 07:12 PM, Reindl Harald wrote:
> 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.

> - maybe you have trouble express yourself proper

Look who's talking.

-- 
Rudd-O
http://rudd-o.com/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/23/2015 08:18 PM, Reindl Harald wrote:
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/23/2015 10:40 PM, Reindl Harald wrote:
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 19:34 schrieb Manuel Amador (Rudd-O):

On 12/21/2015 09:41 PM, Marc Haber wrote:

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?




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/11/2015 02:59 PM, Reindl Harald wrote:
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 20:02 schrieb Manuel Amador (Rudd-O):

On 12/16/2015 09:47 AM, Reindl Harald wrote:

"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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/26/2015 06:58 PM, Reindl Harald wrote:
>
>
> Am 26.12.2015 um 19:52 schrieb Manuel Amador (Rudd-O):
>
> 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.

> - 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 20:04 schrieb Manuel Amador (Rudd-O):

On 12/16/2015 09:47 AM, Reindl Harald wrote:

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


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


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)




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/20/2015 01:30 PM, Marc Haber wrote:
>
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 20:19 schrieb Manuel Amador (Rudd-O):

On 12/26/2015 07:06 PM, Reindl Harald wrote:

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


- 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


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


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



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


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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/23/2015 07:48 PM, Lennart Poettering wrote:
> 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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 19:52 schrieb Manuel Amador (Rudd-O):

On 12/10/2015 03:20 PM, Reindl Harald wrote:


Apache:

Include "conf/local/testserver.conf"


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


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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 20:07 schrieb Manuel Amador (Rudd-O):

On 12/26/2015 06:58 PM, Reindl Harald wrote:


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!




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Manuel Amador (Rudd-O)]

On 12/26/2015 07:28 PM, Reindl Harald wrote:
>
> 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.

>
> 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.

>
> bullshit - my portfolio of skills goes far above things you can imagine,

https://reddit.com/r/iamverysmart/

> bla

Typical.

>
> 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.)

> "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/




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 26.12.2015 um 20:39 schrieb Manuel Amador (Rudd-O):

On 12/26/2015 07:28 PM, Reindl Harald wrote:

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



"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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Wed, 23.12.15 10:32, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 23.12.2015 um 07:01 schrieb Jóhann B. Guðmundsson:
> >On 12/23/2015 12:43 AM, Lennart Poettering wrote:
> >>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
> 
> >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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Wed, 23.12.15 02:44, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 23.12.2015 um 01:24 schrieb Lennart Poettering:
> >On Thu, 10.12.15 16:20, Reindl Harald (h.rei...@thelounge.net) wrote:
> >>
> >>Am 10.12.2015 um 15:46 schrieb 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
> >>
> >>[root@testserver:~]$ cat /etc/sysconfig/httpd
> >>OPTIONS="-D testserver"
> >>
> >>Apache:
> >>
> >>Include "conf/local/testserver.conf"
> >>
> >>
> >>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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Wed, 23.12.15 06:01, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:

> 
> 
> On 12/23/2015 12:43 AM, Lennart Poettering wrote:
> >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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Alex Crawford]

On 12/23, Lennart Poettering wrote:
> On Wed, 23.12.15 06:01, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
> > 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


signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Alex Crawford]

On 12/23, Jóhann B. Guðmundsson wrote:
> 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


signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Andrei Borzenkov]

24.12.2015 03:48, Alex Crawford пишет:
> On 12/23, Jóhann B. Guðmundsson wrote:
>> 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
> 

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?

> 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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 23.12.2015 um 21:12 schrieb Jóhann B. Guðmundsson:

On 12/23/2015 07:30 PM, Alex Crawford wrote:

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?




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 23.12.2015 um 23:08 schrieb Jóhann B. Guðmundsson:



On 12/23/2015 08:18 PM, Reindl Harald wrote:



Am 23.12.2015 um 21:12 schrieb Jóhann B. Guðmundsson:

On 12/23/2015 07:30 PM, Alex Crawford wrote:

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



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?



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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Wed, 23.12.15 11:30, Alex Crawford (alex.crawf...@coreos.com) wrote:

> On 12/23, Lennart Poettering wrote:
> > On Wed, 23.12.15 06:01, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
> > > 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.

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/23/2015 07:48 PM, Lennart Poettering wrote:

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 23.12.2015 um 07:01 schrieb Jóhann B. Guðmundsson:

On 12/23/2015 12:43 AM, Lennart Poettering wrote:

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



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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Mon, 21.12.15 22:41, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> On Mon, Dec 21, 2015 at 10:18:05PM +0100, Kai Krakow wrote:
> > 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Fri, 18.12.15 17:00, Michael Biebl (mbi...@gmail.com) wrote:

> 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 httpd@.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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Thu, 10.12.15 16:20, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> Am 10.12.2015 um 15:46 schrieb 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
> 
> [root@testserver:~]$ cat /etc/sysconfig/httpd
> OPTIONS="-D testserver"
> 
> Apache:
> 
> Include "conf/local/testserver.conf"
> 
> 
> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 23.12.2015 um 01:32 schrieb Lennart Poettering:

On Fri, 18.12.15 17:00, Michael Biebl (mbi...@gmail.com) wrote:


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



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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Sun, 20.12.15 14:30, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:

> On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote:
> > 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Tue, 22.12.15 11:27, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 22.12.2015 um 00:16 schrieb 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 23.12.2015 um 01:24 schrieb Lennart Poettering:

On Thu, 10.12.15 16:20, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 10.12.2015 um 15:46 schrieb 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

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

Apache:

Include "conf/local/testserver.conf"


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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 22.12.2015 um 00:16 schrieb 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





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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/21/2015 04:36 PM, Michael Biebl wrote:

2015-12-21 17:30 GMT+01:00 Jóhann B. Guðmundsson :

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.





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.





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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/23/2015 12:43 AM, Lennart Poettering wrote:

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Kai Krakow]

Am Thu, 10 Dec 2015 01:08:34 +0100
schrieb Reindl Harald :

> Am 09.12.2015 um 20:46 schrieb 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.

> 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
servicename@.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.

-- 


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Kai Krakow]

Am Mon, 21 Dec 2015 22:41:04 +0100
schrieb Marc Haber :

> On Mon, Dec 21, 2015 at 10:18:05PM +0100, Kai Krakow wrote:
> > 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.

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Marc Haber]

On Mon, Dec 21, 2015 at 11:14:43PM +0100, Kai Krakow wrote:
> 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.

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.


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Marc Haber]

On Mon, Dec 21, 2015 at 10:18:05PM +0100, Kai Krakow wrote:
> 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.

Merry Christmas.

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Kai Krakow]

Am Mon, 21 Dec 2015 23:29:57 +0100
schrieb Marc Haber :

> On Mon, Dec 21, 2015 at 11:14:43PM +0100, Kai Krakow wrote:
> > 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.

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/21/2015 01:30 PM, Reindl Harald wrote:
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

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 21.12.2015 um 15:08 schrieb Jóhann B. Guðmundsson:

On 12/21/2015 01:30 PM, Reindl Harald wrote:

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



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*


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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 21.12.2015 um 14:23 schrieb Jóhann B. Guðmundsson:



On 12/21/2015 01:00 PM, Reindl Harald wrote:



Am 21.12.2015 um 12:40 schrieb Jóhann B. Guðmundsson:

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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/18/2015 04:00 PM, Michael Biebl wrote:

2015-12-09 20:46 GMT+01:00 Lennart Poettering :

On Wed, 09.12.15 18:27, Soumya Koduri (skod...@redhat.com) wrote:


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}

(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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 21.12.2015 um 12:40 schrieb Jóhann B. Guðmundsson:

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!


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



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



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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/21/2015 01:00 PM, Reindl Harald wrote:



Am 21.12.2015 um 12:40 schrieb Jóhann B. Guðmundsson:

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Michael Biebl]

2015-12-21 17:30 GMT+01:00 Jóhann B. Guðmundsson :
> 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/21/2015 04:02 PM, Michael Biebl wrote:

2015-12-21 17:00 GMT+01:00 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

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Michael Biebl]

2015-12-21 14:23 GMT+01:00 Jóhann B. Guðmundsson :
> 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/21/2015 02:15 PM, Reindl Harald wrote:


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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/21/2015 03:17 PM, Michael Biebl wrote:

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,

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Michael Biebl]

2015-12-21 17:00 GMT+01:00 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
> 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Tomasz Torcz]

On Sun, Dec 20, 2015 at 02:30:30PM +0100, Marc Haber wrote:
> On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote:
> > 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 TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Marc Haber]

On Sun, Dec 20, 2015 at 02:34:15PM +0100, Tomasz Torcz wrote:
> On Sun, Dec 20, 2015 at 02:30:30PM +0100, Marc Haber wrote:
> > On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote:
> > > 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?

>   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

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Marc Haber]

On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote:
> 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?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Marc Haber]

On Tue, Dec 15, 2015 at 05:59:11PM +, Simon Peeters wrote:
> Why not do like normal people and use configmanagement to put the
> right apache config on the right host?
> This whole "-D testserver" and ""  looks like an
> ugly workaround for a lacking configmanagment system.

And what is your business in deliberately breaking those ugly setups?
If you want to educate people, be a teacher. If you want to bully
people into doing things your way, be a team leader.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Marc Haber]

On Fri, Dec 11, 2015 at 03:59:54PM +0100, Reindl Harald wrote:
> 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

Amen.

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Andrei Borzenkov]

20.12.2015 16:47, Marc Haber пишет:
> On Sun, Dec 20, 2015 at 02:34:15PM +0100, Tomasz Torcz wrote:
>> On Sun, Dec 20, 2015 at 02:30:30PM +0100, Marc Haber wrote:
>>> On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote:
 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.

>>   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
> 

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Michael Biebl]

2015-12-09 20:46 GMT+01:00 Lennart Poettering :
> On Wed, 09.12.15 18:27, Soumya Koduri (skod...@redhat.com) wrote:
>
>> 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}
>
> (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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Simon Peeters]

2015-12-16 9:47 GMT+00:00 Reindl Harald :
>
>
> Am 15.12.2015 um 18:59 schrieb Simon Peeters:
>>
>> 2015-12-10 15:20 GMT+00:00 Reindl Harald :
>>>
>>>
>>> Am 10.12.2015 um 15:46 schrieb 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
>>>
>>> [root@testserver:~]$ cat /etc/sysconfig/httpd
>>> OPTIONS="-D testserver"
>>>
>>> Apache:
>>> 
>>> Include "conf/local/testserver.conf"
>>> 
>>>
>>> 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
>>>
 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 on future and upcoming tech.

>> 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.

>> This whole "-D testserver" and ""  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.

>> More preciesly conf/local/testserver.conf probably shouldn't even
>> exist on non testing mahines
>
>
> guess why it's in the subfolder "local"
>
>> '/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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 15.12.2015 um 18:59 schrieb Simon Peeters:

2015-12-10 15:20 GMT+00:00 Reindl Harald :


Am 10.12.2015 um 15:46 schrieb 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

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

Apache:

Include "conf/local/testserver.conf"


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


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?


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



This whole "-D testserver" and ""  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



More preciesly conf/local/testserver.conf probably shouldn't even
exist on non testing mahines


guess why it's in the subfolder "local"


'/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





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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Simon Peeters]

2015-12-10 15:20 GMT+00:00 Reindl Harald :
>
> Am 10.12.2015 um 15:46 schrieb 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
>
> [root@testserver:~]$ cat /etc/sysconfig/httpd
> OPTIONS="-D testserver"
>
> Apache:
> 
> Include "conf/local/testserver.conf"
> 
>
> 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
>
>> 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 ""  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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/11/2015 03:56 AM, Andrei Borzenkov wrote:

10.12.2015 18:44, Jóhann B. Guðmundsson пишет:


On 12/10/2015 03:20 PM, Reindl Harald wrote:

Am 10.12.2015 um 15:46 schrieb Jóhann B. Guðmundsson:

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 11.12.2015 um 15:45 schrieb Jóhann B. Guðmundsson:

On 12/11/2015 03:56 AM, Andrei Borzenkov wrote:

10.12.2015 18:44, Jóhann B. Guðmundsson пишет:


On 12/10/2015 03:20 PM, Reindl Harald wrote:

Am 10.12.2015 um 15:46 schrieb Jóhann B. Guðmundsson:

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





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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Thu, 10.12.15 01:08, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 09.12.2015 um 20:46 schrieb 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.

> 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").

> * 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 10.12.2015 um 11:15 schrieb Lennart Poettering:

On Thu, 10.12.15 01:08, Reindl Harald (h.rei...@thelounge.net) wrote:




Am 09.12.2015 um 20:46 schrieb 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


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

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

to share the whole httpd config between multiple servers


* 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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Simon McVittie]

On 09/12/15 19:46, Lennart Poettering wrote:
> 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 -  is a
configuration-file option, but it shouldn't be.

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Andrei Borzenkov]

10.12.2015 18:44, Jóhann B. Guðmundsson пишет:
> 
> 
> On 12/10/2015 03:20 PM, Reindl Harald wrote:
>>
>> Am 10.12.2015 um 15:46 schrieb 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
>>
>> [root@testserver:~]$ cat /etc/sysconfig/httpd
>> OPTIONS="-D testserver"
>>
>> Apache:
>> 
>> Include "conf/local/testserver.conf"
>> 
>>
>> 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 10.12.2015 um 16:44 schrieb Jóhann B. Guðmundsson:

On 12/10/2015 03:20 PM, Reindl Harald wrote:


Am 10.12.2015 um 15:46 schrieb 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

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

Apache:

Include "conf/local/testserver.conf"


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



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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

> 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


Am 10.12.2015 um 16:47 schrieb Reindl Harald:

Am 10.12.2015 um 16:44 schrieb Jóhann B. Guðmundsson:

On 12/10/2015 03:20 PM, Reindl Harald wrote:


Am 10.12.2015 um 15:46 schrieb 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

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

Apache:

Include "conf/local/testserver.conf"


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


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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/09/2015 07:46 PM, Lennart Poettering wrote:

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 10.12.2015 um 15:46 schrieb 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

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

Apache:

Include "conf/local/testserver.conf"


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



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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Jóhann B . Guðmundsson]

On 12/10/2015 03:20 PM, Reindl Harald wrote:


Am 10.12.2015 um 15:46 schrieb 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

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

Apache:

Include "conf/local/testserver.conf"


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.





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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Reindl Harald]

Am 09.12.2015 um 20:46 schrieb 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




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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Soumya Koduri]

On 12/10/2015 01:16 AM, Lennart Poettering wrote:

On Wed, 09.12.15 18:27, Soumya Koduri (skod...@redhat.com) wrote:


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.


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


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


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

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Andrei Borzenkov]

10.12.2015 03:08, Reindl Harald пишет:
> 
> 
> Am 09.12.2015 um 20:46 schrieb 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Query regarding "EnvironmentFile"

[Lennart Poettering]

On Wed, 09.12.15 18:27, Soumya Koduri (skod...@redhat.com) wrote:

> 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.

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel