Systemd unit file implementation questions (ypbind)

[Lennart Poettering]

On Thu, 14.04.11 13:05, Chris Adams (cmadams at hiwaay.net) wrote:

> 
> Once upon a time, Lennart Poettering <mzerqung at 0pointer.de> said:
> > The place for system configuration is /etc. I have yet to see a really
> > convincing example why /etc/sysconfig/ or /etc/default would win us
> > anything.
> 
> /etc/sysconfig is essentially configuration for the init system managing
> daemons.  Command-line options, which sub-bits to run, etc. that are not
> settable in the daemon configuration files themselves.

Yes, but all of that can be configured in a much nicer way in systemd: 

Copy /lib/systemd/system/foobar.service to
/etc/systemd/system/foobar.service, and edit it there. You will have a
short, easy to understand, super-flexible, very well documented way to
edit service defaults. You can edit command lines, you may set a
specific user id to run something as, you may set the CPU affinity or
you can adjust the capability bounding set as you wish (among a lot of
other stuff). You have the full range of configuration options systemd
offers you, all in a very simple ini file.

Now, let's look at /etc/sysconfig/xxx. What you see is that only options
that the init script explicitly supports you can change. On one service
you might be able to change the command line arguments with this, on a
different one you may change the user id, on a third one you may change
the CPU affinity and a fourht one might allow you to the caps bounding
set. But you do not find a single sysconfig file where you could
actually configure all of these options. Also, the options tend to have
different names even if they do the same, and slightly different
behaviour.

systemd streamlines this. If you want to change the configuration of a
specific service, you can do so with very minimal effort and great
flexibility, and all of that without creating a completely new
configuration language for it, or without needing specific support in
the service startup logic. The configuration language for the admin and
for upstream is the *same*.

Looking at the history of this: the reason /etc/sysconfig/xxx was
created in the first place is that while /etc/init.d/xxx was initially
more like configuration (and thus located in /etc) it ended up being
more like actual code (which it is after all). So in order to avoid
having to edit code to make configuration changes, and to not confuse
the package manager /etc/sysconfig/xxx was split out of the actual sysv
init scripts. In systemd that split is not necessary, and we should just
embrace that instead of keeping /etc/sysconfig/xxx alive without need.

> I think having them in a sub-directory is much cleaner (and makes them
> easier to distinguish from the "regular" daemon config files).  I don't
> think /etc/default is a good name (if that indeed is what Debian uses),
> because they are options you change to get non-default behavior.

I have trouble seeing in which way /etc/nsswitch.conf was in any way
more "regular" than /etc/nsswitch.conf, 

> > I am pretty sure that the vast majority of files in there are
> > pretty much unnecessary and their configuration could be solved in a
> > different way much nicer.
> 
> I've used a bunch of them to change the ways various daemons run, so I
> would definately say they are not "pretty much unnecessary".  They are
> also shell scripts that are sourced by init scripts, so there is
> flexibility to make changes that may not have even been anticipated by
> the init script authors.

Yeah, and that's the nice thing in systemd, if you want to make a change
to a service file, just take it, edit it and enjoy the full power that
systemd puts in your hands! 

> Since they are config files (unlike the init scripts themselves),
> changing them doesn't leave you with RPM wanting to replace them on
> every package update either.

Yupp, and this is much much prettier in systemd. After you copied the
service file from /lib to /etc they are out of the package manager
territory and will always override what has been configured by the
distro packager. And if you want to return to the default settings you
can just remove your file from /etc again and voila! 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.