On Thu, 14.04.11 13:05, Chris Adams (cmadams@xxxxxxxxxx) wrote: > > Once upon a time, Lennart Poettering <mzerqung@xxxxxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
