Re: [systemd-devel] Variables in the [Unit] section of a server

[Lennart Poettering]

On Tue, 02.02.16 11:05, Steve Dickson (ste...@redhat.com) wrote:

> > You can always use some kind of hackery in ExecStartPre, but I don't think 
> > that's
> > what anyone wants.
> > 
> Well its to bad ConditionPathExists is not part of the [Service] section
> so I could use a shell variable... 

env vars are only supported in ExecXYZ= lines, no others. This has
little to do with the [Service] section.

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] Variables in the [Unit] section of a server

[Steve Dickson]

On 01/23/2016 11:33 AM, Armin K. wrote:
> On 23.01.2016 17:28, Armin K. wrote:
>>> On 01/13/2016 10:51 AM, Steve Dickson wrote:
 Hello,

 Is is possible to set a variable in the [Unit]
 section of a service?

 For example in rpc-gssd.service there is
 ConditionPathExists=/etc/krb5.keytab

 but for some installation the krb5.keytab
 is in a different place. The rpc.gssd daemon
 can be told this by setting a command line
 argument from the EnvironmentFile.

 So people have to edit both the EnvironmentFile
 and the rpc-gssd.service to make this change. 

 So it would be nice if only the EnvironmentFile
 need to be edit and the change would happen
 in both places. 

 Possible?

 steved.
>>
>> I'm sorry I'm not responding to the original mail, as I just subscribed
>> yesterday to this list.
>>
>> I am not sure I fully understand what you want, but I think this might do it:
>>
>> [Unit]
>> Description=test
>>
>> [Service]
>> Type=oneshot
>> Environment=TEST=blah
>> EnvironmentFile=-/etc/systemd/system/test-env
>> ExecStart=/etc/systemd/system/test ${TEST}
>> TimeoutSec=0
>> RemainAfterExit=yes
>>
>> The /etc/systemd/system/test is a script that prints $1, depending on what is
>> being passed to it. When env file is not present, it prints the TEST from the
>> unit file. When env file is present, and TEST is set to something else, it
>> prints its value. Is that what you are looking for?
>>
>> Cheers
>>
> 
> Ugh, sorry. You asked for the [Unit] section, not the [Service] section.
> From what I see, it doesn't yet seem to be possible:
> 
> [/etc/systemd/system/test.service:2] Unknown lvalue 'Environment' in section 
> 'Unit'
> [/etc/systemd/system/test.service:4] Path in condition not absolute, 
> ignoring: $TEST
> 
> You can always use some kind of hackery in ExecStartPre, but I don't think 
> that's
> what anyone wants.
> 
Well its to bad ConditionPathExists is not part of the [Service] section
so I could use a shell variable... 

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

Re: [systemd-devel] Variables in the [Unit] section of a server

[Armin K.]

> On 01/13/2016 10:51 AM, Steve Dickson wrote:
>> Hello,
>>
>> Is is possible to set a variable in the [Unit]
>> section of a service?
>>
>> For example in rpc-gssd.service there is
>> ConditionPathExists=/etc/krb5.keytab
>>
>> but for some installation the krb5.keytab
>> is in a different place. The rpc.gssd daemon
>> can be told this by setting a command line
>> argument from the EnvironmentFile.
>>
>> So people have to edit both the EnvironmentFile
>> and the rpc-gssd.service to make this change. 
>>
>> So it would be nice if only the EnvironmentFile
>> need to be edit and the change would happen
>> in both places. 
>>
>> Possible?
>>
>> steved.

I'm sorry I'm not responding to the original mail, as I just subscribed
yesterday to this list.

I am not sure I fully understand what you want, but I think this might do it:

[Unit]
Description=test

[Service]
Type=oneshot
Environment=TEST=blah
EnvironmentFile=-/etc/systemd/system/test-env
ExecStart=/etc/systemd/system/test ${TEST}
TimeoutSec=0
RemainAfterExit=yes

The /etc/systemd/system/test is a script that prints $1, depending on what is
being passed to it. When env file is not present, it prints the TEST from the
unit file. When env file is present, and TEST is set to something else, it
prints its value. Is that what you are looking for?

Cheers



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] Variables in the [Unit] section of a server

[Armin K.]

On 23.01.2016 17:28, Armin K. wrote:
>> On 01/13/2016 10:51 AM, Steve Dickson wrote:
>>> Hello,
>>>
>>> Is is possible to set a variable in the [Unit]
>>> section of a service?
>>>
>>> For example in rpc-gssd.service there is
>>> ConditionPathExists=/etc/krb5.keytab
>>>
>>> but for some installation the krb5.keytab
>>> is in a different place. The rpc.gssd daemon
>>> can be told this by setting a command line
>>> argument from the EnvironmentFile.
>>>
>>> So people have to edit both the EnvironmentFile
>>> and the rpc-gssd.service to make this change. 
>>>
>>> So it would be nice if only the EnvironmentFile
>>> need to be edit and the change would happen
>>> in both places. 
>>>
>>> Possible?
>>>
>>> steved.
> 
> I'm sorry I'm not responding to the original mail, as I just subscribed
> yesterday to this list.
> 
> I am not sure I fully understand what you want, but I think this might do it:
> 
> [Unit]
> Description=test
> 
> [Service]
> Type=oneshot
> Environment=TEST=blah
> EnvironmentFile=-/etc/systemd/system/test-env
> ExecStart=/etc/systemd/system/test ${TEST}
> TimeoutSec=0
> RemainAfterExit=yes
> 
> The /etc/systemd/system/test is a script that prints $1, depending on what is
> being passed to it. When env file is not present, it prints the TEST from the
> unit file. When env file is present, and TEST is set to something else, it
> prints its value. Is that what you are looking for?
> 
> Cheers
> 

Ugh, sorry. You asked for the [Unit] section, not the [Service] section.
From what I see, it doesn't yet seem to be possible:

[/etc/systemd/system/test.service:2] Unknown lvalue 'Environment' in section 
'Unit'
[/etc/systemd/system/test.service:4] Path in condition not absolute, ignoring: 
$TEST

You can always use some kind of hackery in ExecStartPre, but I don't think 
that's
what anyone wants.



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] Variables in the [Unit] section of a server

[Steve Dickson]

Thank for the discussion... It was very helpful! 

steved. 

On 01/13/2016 10:51 AM, Steve Dickson wrote:
> Hello,
> 
> Is is possible to set a variable in the [Unit]
> section of a service?
> 
> For example in rpc-gssd.service there is
> ConditionPathExists=/etc/krb5.keytab
> 
> but for some installation the krb5.keytab
> is in a different place. The rpc.gssd daemon
> can be told this by setting a command line
> argument from the EnvironmentFile.
> 
> So people have to edit both the EnvironmentFile
> and the rpc-gssd.service to make this change. 
> 
> So it would be nice if only the EnvironmentFile
> need to be edit and the change would happen
> in both places. 
> 
> Possible?
> 
> steved.
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Variables in the [Unit] section of a server

[Tom H]

On Thu, Jan 14, 2016 at 3:58 PM, Lennart Poettering
 wrote:
> On Wed, 13.01.16 10:51, Steve Dickson (ste...@redhat.com) wrote:
>>
>> Is is possible to set a variable in the [Unit]
>> section of a service?
>>
>> For example in rpc-gssd.service there is
>> ConditionPathExists=/etc/krb5.keytab
>>
>> but for some installation the krb5.keytab
>> is in a different place. The rpc.gssd daemon
>> can be told this by setting a command line
>> argument from the EnvironmentFile.
>>
>> So people have to edit both the EnvironmentFile
>> and the rpc-gssd.service to make this change.
>>
>> So it would be nice if only the EnvironmentFile
>> need to be edit and the change would happen
>> in both places.
>>
>> Possible?
>
> Unit files are supposed to be configuration files, people can override
> and extend if they want to make changes. It's not recommended to use
> the EnvironmentFile= logic to externalise configuration. Instead, just
> keep the config in one place, in the unit files, to make things less
> opaque and more uniform.
>
> And no, unit files are not supposed to be a templating language and do
> not support generlized variable expansion and quite frankly I should
> never even have added the limited env var expansion via
> EnvironmentFile= that ExecStart= supports, since it invites people to
> externalise settings that way.

I understand that you'd prefer that we use drop-ins to set
"Environment=Foo=bar" or override "ExecStart=..." and it probably
works for most daemons - and should also be non-distro-specific.

But in the case of nfs, it would mean more messing around for admins
because there are many variables to set.

This is on Ubuntu 16.04 but RHEL and Fedora are similar because the
units are from upstream and distros simply have to modify
"/usr/lib/systemd/scripts/nfs-utils_env.sh":

root@localhost:/lib/systemd/system# grep Start= nfs-* rpc-*
nfs-blkmap.service:ExecStart=/usr/sbin/blkmapd $BLKMAPDARGS
nfs-config.service:ExecStart=/usr/lib/systemd/scripts/nfs-utils_env.sh
nfs-idmapd.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
nfs-kernel-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
nfs-mountd.service:ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
nfs-utils.service:ExecStart=/bin/true
rpc-gssd.service:ExecStart=/usr/sbin/rpc.gssd $GSSDARGS
rpc-statd-notify.service:ExecStart=-/sbin/sm-notify $SMNOTIFYARGS
rpc-statd.service:ExecStart=/sbin/rpc.statd --no-notify $STATDARGS
rpc-svcgssd.service:ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS

root@localhost:/lib/systemd/system# grep Env nfs-* rpc-*
nfs-idmapd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
nfs-kernel-server.service:EnvironmentFile=-/run/sysconfig/nfs-utils
nfs-mountd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
nfs-server.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-gssd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-statd-notify.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-statd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
rpc-svcgssd.service:EnvironmentFile=-/run/sysconfig/nfs-utils

root@localhost:/lib/systemd/system#

nfs-config.service runs "/usr/lib/systemd/scripts/nfs-utils_env.sh",
which sources "/etc/default/nfs-{common,kernel-server}"
("/etc/sysconfig/nfs" on RHEL and Fedora) and generates
"/run/sysconfig/nfs-utils". Setting the variables unit-by-unit would
be a PitA.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Variables in the [Unit] section of a server

[Reindl Harald]

Am 14.01.2016 um 21:44 schrieb Lennart Poettering:

On Thu, 14.01.16 19:52, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 14.01.2016 um 15:58 schrieb Lennart Poettering:

And no, unit files are not supposed to be a templating language and do
not support generlized variable expansion and quite frankly I should
never even have added the limited env var expansion via
EnvironmentFile= that ExecStart= supports, since it invites people to
externalise settings that way


again: it's fine externalise settings when you know what you are
doing


Nope, it's a really bad idea, because unnecessary indirection is bad,
and it defeats things like "systemd-delta" and similar concepts.


you preamture stopped reading

re-use / share things for many if not all deamos would be *good* because 
one would not need to re-invent the same namespaces and restricitions 
for each and every service with non-shareable snippets


you like that concepts, fine
myself and others don't use or need them


But anyway, Reindl, there's really no point in having this discussion
again. Supporting EnvironmentFile= was a bad idea. I know you love it,
but it was a mistake from a design PoV


no, only because you love other concepts

accept that not everyone love that concepts
not that i am in general against *a lot* of systemd-concepts

the opposite is true, i love a lot of them

but having different ways to do things is a good thing


P.S.:
i would even love to use way more systemd-features like namespaces 
everywhere but systemd-run don't work for that now on fedora nor does it 
support using it for cronjobs where you want implicit mail if *anything* 
goes to stdout/stderr



 Weitergeleitete Nachricht 
Betreff: [systemd-devel] systemd-run via crond: status=208/STDIN
Datum: Thu, 31 Dec 2015 17:23:00 +0100
Von: Reindl Harald 
Organisation: the lounge interactive design
An: Mailing-List systemd 

systemd-219-26.fc22.x86_64

* in a ssh shell on Fedora 22 the script below works fine
* called via /etc/crontab it fails
* Unknown assignment StandardInput=null

WHY?

the intention is finally spwan namespaces (sadly not possible with
F22/F23 and systemd-run at all) to protect the OS and replace direct
calls in /etc/crontab with such wrappers to get the well known cronmails
if there is any output (and no generate the mails in the scripts is no
valid option - they don#t have to call a MTA directly)
__

Dez 31 17:08:01 mail-gw.thelounge.net systemd[1]:
spamfilter-fetch-samples.service: main process exited, code=exited,
status=208/STDIN
Dez 31 17:08:01 mail-gw.thelounge.net systemd[1]: Failed to start
spamfilter-fetch-samples.
Dez 31 17:08:01 mail-gw.thelounge.net systemd[1]: Unit
spamfilter-fetch-samples.service entered failed state.
Dez 31 17:08:01 mail-gw.thelounge.net systemd[1]:
spamfilter-fetch-samples.service failed.
__

[root@mail-gw:~]$ cat /usr/local/bin/spamfilter-fetch-samples
#!/usr/bin/dash
/usr/bin/systemd-run -t --service-type=oneshot --quiet --nice=19
--unit=spamfilter-fetch-samples --description=spamfilter-fetch-samples
/usr/bin/php -d
open_basedir="/tmp:/scripts:/usr/local:/var/lib/spamass-milter/training"
/usr/local/bin/workers/spamfilter-fetch-samples.php

# Fedora 24: -p ProtectSystem=full,ProtectHome=yes



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] Variables in the [Unit] section of a server

[Lennart Poettering]

On Thu, 14.01.16 19:52, Reindl Harald (h.rei...@thelounge.net) wrote:

> Am 14.01.2016 um 15:58 schrieb Lennart Poettering:
> >And no, unit files are not supposed to be a templating language and do
> >not support generlized variable expansion and quite frankly I should
> >never even have added the limited env var expansion via
> >EnvironmentFile= that ExecStart= supports, since it invites people to
> >externalise settings that way
> 
> again: it's fine externalise settings when you know what you are
> doing

Nope, it's a really bad idea, because unnecessary indirection is bad,
and it defeats things like "systemd-delta" and similar concepts.

But anyway, Reindl, there's really no point in having this discussion
again. Supporting EnvironmentFile= was a bad idea. I know you love it,
but it was a mistake from a design PoV. 

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] Variables in the [Unit] section of a server

[Lennart Poettering]

On Thu, 14.01.16 20:37, Tom H (tomh0...@gmail.com) wrote:

> I understand that you'd prefer that we use drop-ins to set
> "Environment=Foo=bar" or override "ExecStart=..." and it probably
> works for most daemons - and should also be non-distro-specific.
> 
> But in the case of nfs, it would mean more messing around for admins
> because there are many variables to set.
> 
> This is on Ubuntu 16.04 but RHEL and Fedora are similar because the
> units are from upstream and distros simply have to modify
> "/usr/lib/systemd/scripts/nfs-utils_env.sh":
> 
> root@localhost:/lib/systemd/system# grep Start= nfs-* rpc-*
> nfs-blkmap.service:ExecStart=/usr/sbin/blkmapd $BLKMAPDARGS
> nfs-config.service:ExecStart=/usr/lib/systemd/scripts/nfs-utils_env.sh
> nfs-idmapd.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS
> nfs-kernel-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
> nfs-mountd.service:ExecStart=/usr/sbin/rpc.mountd $RPCMOUNTDARGS
> nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
> nfs-utils.service:ExecStart=/bin/true
> rpc-gssd.service:ExecStart=/usr/sbin/rpc.gssd $GSSDARGS
> rpc-statd-notify.service:ExecStart=-/sbin/sm-notify $SMNOTIFYARGS
> rpc-statd.service:ExecStart=/sbin/rpc.statd --no-notify $STATDARGS
> rpc-svcgssd.service:ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS
> 
> root@localhost:/lib/systemd/system# grep Env nfs-* rpc-*
> nfs-idmapd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
> nfs-kernel-server.service:EnvironmentFile=-/run/sysconfig/nfs-utils
> nfs-mountd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
> nfs-server.service:EnvironmentFile=-/run/sysconfig/nfs-utils
> rpc-gssd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
> rpc-statd-notify.service:EnvironmentFile=-/run/sysconfig/nfs-utils
> rpc-statd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
> rpc-svcgssd.service:EnvironmentFile=-/run/sysconfig/nfs-utils
> 
> root@localhost:/lib/systemd/system#
> 
> nfs-config.service runs "/usr/lib/systemd/scripts/nfs-utils_env.sh",
> which sources "/etc/default/nfs-{common,kernel-server}"
> ("/etc/sysconfig/nfs" on RHEL and Fedora) and generates
> "/run/sysconfig/nfs-utils". Setting the variables unit-by-unit would
> be a PitA.

Well, apparently the NFS daemons want to receive all their config via
the command line. I think that's a quite a poor choice, and they
better had proper configuration files.

To say this clearly: "EnvironmentFile=" is an awful replacement for
proper configuration files. systemd really isn't in the business of
faking configuration files for daemons that have none. If you do it
anyway, then this will be necessarily crappyish...

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] Variables in the [Unit] section of a server

[Reindl Harald]

Am 14.01.2016 um 15:58 schrieb Lennart Poettering:

And no, unit files are not supposed to be a templating language and do
not support generlized variable expansion and quite frankly I should
never even have added the limited env var expansion via
EnvironmentFile= that ExecStart= supports, since it invites people to
externalise settings that way


again: it's fine externalise settings when you know what you are doing

the opposite is true: i would need a ton of 
ReadOnlyDirectories/InaccessibleDirectories in a single file shared by 
most services on the systems for a customized baseline security which 
goes way over /etc and /usr


i have currently 4 nearly identical services on 4 different hosts 
managing cronjobs of 220 cms-installations, they need to share all the 
same environment variables (yes REALLY env-vars) and so share 
/etc/sysconfig/contentlounge


in no way you could do that without externalise

just because there are no cms systems out there which are able to be 
maintained for hundrets of instances centralized don't mean these things 
don't exist


in other words: there is no need that you try dictate how people 
configure things




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] Variables in the [Unit] section of a server

[Lennart Poettering]

On Wed, 13.01.16 10:51, Steve Dickson (ste...@redhat.com) wrote:

> Hello,
> 
> Is is possible to set a variable in the [Unit]
> section of a service?
> 
> For example in rpc-gssd.service there is
> ConditionPathExists=/etc/krb5.keytab
> 
> but for some installation the krb5.keytab
> is in a different place. The rpc.gssd daemon
> can be told this by setting a command line
> argument from the EnvironmentFile.
> 
> So people have to edit both the EnvironmentFile
> and the rpc-gssd.service to make this change. 
> 
> So it would be nice if only the EnvironmentFile
> need to be edit and the change would happen
> in both places. 
> 
> Possible?

Unit files are supposed to be configuration files, people can override
and extend if they want to make changes. It's not recommended to use
the EnvironmentFile= logic to externalise configuration. Instead, just
keep the config in one place, in the unit files, to make things less
opaque and more uniform.

And no, unit files are not supposed to be a templating language and do
not support generlized variable expansion and quite frankly I should
never even have added the limited env var expansion via
EnvironmentFile= that ExecStart= supports, since it invites people to
externalise settings that way.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Variables in the [Unit] section of a server

[Steve Dickson]

Hello,

Is is possible to set a variable in the [Unit]
section of a service?

For example in rpc-gssd.service there is
ConditionPathExists=/etc/krb5.keytab

but for some installation the krb5.keytab
is in a different place. The rpc.gssd daemon
can be told this by setting a command line
argument from the EnvironmentFile.

So people have to edit both the EnvironmentFile
and the rpc-gssd.service to make this change. 

So it would be nice if only the EnvironmentFile
need to be edit and the change would happen
in both places. 

Possible?

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

Re: [systemd-devel] Variables in the [Unit] section of a server

[Reindl Harald]

Am 13.01.2016 um 16:51 schrieb Steve Dickson:

Is is possible to set a variable in the [Unit]
section of a service?

For example in rpc-gssd.service there is
 ConditionPathExists=/etc/krb5.keytab

but for some installation the krb5.keytab
is in a different place. The rpc.gssd daemon
can be told this by setting a command line
argument from the EnvironmentFile.

So people have to edit both the EnvironmentFile
and the rpc-gssd.service to make this change.

So it would be nice if only the EnvironmentFile
need to be edit and the change would happen
in both places.

Possible?


sadly no, i would even have usescases to start ExecStart with var from 
an EnvironmentFile but see the latest discussion about EnvironmentFile 
and you can guess how much support you can expect...


http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/35157

https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg34887.html



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