Why doesn't system respect FSH? What is its benefit? Cite man 7 hier ...... /usr/lib Object libraries, including dynamic libraries, plus some executables which usually are not invoked directly. More complicated pro‐ grams may have whole subdirectories there. ...... i.e. man systemd-sysctl systemd-sysctl.service is an early-boot service that configures sysctl(8) kernel parameters. See sysctl.d(5) for information about the configuration of this service.
man sysctl.d NAME sysctl.d - Configure kernel parameters at boot SYNOPSIS /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf DESCRIPTION At boot, systemd-sysctl.service(8) reads configuration files from the above directories to configure sysctl(8) kernel parameters.
# ll /etc/sysctl.conf -rw-r--r--. 1 root root 225 Mar 26 14:55 /etc/sysctl.conf # ll /etc/sysctl.d/ total 0 lrwxrwxrwx. 1 root root 14 Apr 3 09:17 99-sysctl.conf -> ../sysctl.conf # cat /etc/sysctl.conf # System default settings live in /usr/lib/sysctl.d/00-system.conf. # To override those settings, enter new settings here, or in an /etc/sysctl.d/<name>.conf file # # For more information, see sysctl.conf(5) and sysctl.d(5). [root@szigeti-6560b ~]# cat /usr/lib/sysctl.d/00-system.conf ...
# man -k sysctl|grep systemd systemd-sysctl (8) - Configure kernel parameters at boot systemd-sysctl.service (8) - Configure kernel parameters at boot
man systemd-sysctl.service NAME systemd-sysctl.service, systemd-sysctl - Configure kernel parameters at boot SYNOPSIS systemd-sysctl.service /usr/lib/systemd/systemd-sysctl DESCRIPTION systemd-sysctl.service is an early-boot service that configures sysctl(8) kernel parameters. See sysctl.d(5) for information about the configuration of this service. SEE ALSO systemd(1), sysctl.d(5), sysctl(8),
I think, the config files should store in /etc instead of everywhere else. The chroot applications are exceptions. It cause we MUST mount /usr in / (root) partion.
Balint
On Tue, 22 Jul 2014 12:26:57 +0100 Balint Szigeti balint.szgt@gmail.com wrote:
Why doesn't system respect FSH? What is its benefit?
[snip]
I think, the config files should store in /etc instead of everywhere else. The chroot applications are exceptions. It cause we MUST mount /usr in / (root) partion.
The _New_Way_ of looking at config files is the following: the *default*, rpm-provided config files should reside somewhere in /usr, while the *customized*, manually tweaked (portions of) config files should reside in /etc. This way there is a clear demarcation between the package manager territory (/usr) and admin's territory (/etc).
In such a setup the yum update of a given package can update the default configuration without destroying your customizations. It will also make /etc much cleaner, easier to examine, fix, migrate, backup, and so on.
There is a general push to make this happen for all apps, not just systemd, and you should get used to seeing it all over the place. I wouldn't be surprised if the near-future Fedora releases have clean installs with an almost-empty /etc, waiting for you to put your customizations in it. Personally, I think it's a good idea, and it will certainly make my own machines much easier to maintain.
Whether this is FSH-compliant or not, I don't know. Some people say it is, some people say it is not, most of the people don't really care. :-)
HTH, :-) Marko
On 07/22/2014 02:42 PM, Marko Vojinovic wrote:
Whether this is FSH-compliant or not, I don't know. Some people say it is, some people say it is not, most of the people don't really care. :-)
The difference is: Files outside of /etc are not supposed to modified by users or admins.
I.e. shipping "config-files" out-side of /etc is compliant to the FHS if they can be overriden else where below /etc.
In that sense files below /usr aren't user/admin-config files, they are package/application defaults.
A package, which does not provide a means to override configuration files from below /etc, or requires users to modify files below /usr is broken by design.
Ralf
On Tue, 22 Jul 2014 15:03:39 +0200 Ralf Corsepius rc040203@freenet.de wrote:
A package, which does not provide a means to override configuration files from below /etc, or requires users to modify files below /usr is broken by design.
Agreed, but I don't seem to fully understand your point here. Are you suggesting that there are packages which are currently broken in this way? Do you know of any examples? If not, why did you raise this point?
Best, :-) Marko
Ralf Corsepius rc040203@freenet.de writes:
A package, which does not provide a means to override configuration files from below /etc, or requires users to modify files below /usr is broken by design.
Both python and perl come with mechanisms to add their respective native packages under /usr/lib/... Do you consider those packages broken? PHP comes with pecl, that installs native packages under /usr/share/php, so the same question applies there.
Hi
On Tue, Jul 22, 2014 at 3:26 PM, Anders Wegge Kelle wrote:
Ralf Corsepius writes:
A package, which does not provide a means to override configuration files from below /etc, or requires users to modify files below /usr is broken by design.
Both python and perl come with mechanisms to add their respective native packages under /usr/lib/... Do you consider those packages broken? PHP comes with pecl, that installs native packages under /usr/share/php, so the same question applies there.
Not really. Ralf is talking about configuration in /usr and not other type of data (ie) the configuration in /usr is just fine as long as there is a way for the user to override it. systemd does provide a number of options to do that.
Rahul
On 07/22/2014 12:26 PM, Anders Wegge Keller wrote:
Ralf Corsepius rc040203@freenet.de writes:
A package, which does not provide a means to override configuration files from below /etc, or requires users to modify files below /usr is broken by design.
Both python and perl come with mechanisms to add their respective native packages under /usr/lib/... Do you consider those packages broken? PHP comes with pecl, that installs native packages under /usr/share/php, so the same question applies there.
Are you talking about the packages or the configuration files?
Joe Zeff joe@zeff.us writes:
On 07/22/2014 12:26 PM, Anders Wegge Keller wrote:
Ralf Corsepius rc040203@freenet.de writes:
A package, which does not provide a means to override configuration files from below /etc, or requires users to modify files below /usr is broken by design.
Both python and perl come with mechanisms to add their respective native packages under /usr/lib/... Do you consider those packages broken? PHP comes with pecl, that installs native packages under /usr/share/php, so the same question applies there.
Are you talking about the packages or the configuration files?
The specific wording: "requires users to modify files below /usr".
Hi
On Tue, Jul 22, 2014 at 4:39 PM, Anders Wegge Keller wrote:
The specific wording: "requires users to modify files below /usr".
I am not sure picking up some words without the context is useful. If you read the full email, it was obviously talking about configuration files.
Rahul
Rahul Sundaram metherid@gmail.com writes:
Hi
On Tue, Jul 22, 2014 at 4:39 PM, Anders Wegge Keller wrote:
The specific wording: "requires users to modify files below /usr".
I am not sure picking up some words without the context is useful. If you read the full email, it was obviously talking about configuration files.
Instead of having to guess at the meaning, why not just state the intention without the absolutism? And depending on the definition of what a configuration file actually is, even that statement brings at least the kernel source and texlive-* into bad standing.
Hi
On Wed, Jul 23, 2014 at 2:14 PM, Anders Wegge Keller wrote:
Instead of having to guess at the meaning, why not just state the intention without the absolutism?
I don't think anyone else was confused about what the meaning was.
And depending on the definition of what a configuration file actually is, even that statement brings at least the kernel source and texlive-* into bad standing.
Don't see how.
Rahul
Rahul Sundaram metherid@gmail.com writes:
Hi
On Wed, Jul 23, 2014 at 2:14 PM, Anders Wegge Keller wrote:
Instead of having to guess at the meaning, why not just state the intention without the absolutism?
I don't think anyone else was confused about what the meaning was.
Neither am I. I just have a general distate for unwarranted absolutims.
And depending on the definition of what a configuration file actually is, even that statement brings at least the kernel source and texlive-* into bad standing.
Don't see how.
make menuconfig will modify a configuration file, placed below /usr. Similar for texlive, where you can hardly install anything without affecting the kpathsea database, which is a configuration file of sorts.
Hi
On Thu, Jul 24, 2014 at 9:21 AM, Anders Wegge Keller wrote:
make menuconfig will modify a configuration file, placed below /usr.
That isn't a RPM package placing those configuration files however. So the need to override it just isn't there.
Similar for texlive, where you can hardly install anything without affecting the kpathsea database, which is a configuration file of sorts.
A database isn't plain configuration from a FHS perspective. Those can live in /var/lib
Rahul
Rahul Sundaram metherid@gmail.com writes:
Hi
On Thu, Jul 24, 2014 at 9:21 AM, Anders Wegge Keller wrote:
make menuconfig will modify a configuration file, placed below /usr.
That isn't a RPM package placing those configuration files however. So the need to override it just isn't there.
Similar for texlive, where you can hardly install anything without affecting the kpathsea database, which is a configuration file of sorts.
A database isn't plain configuration from a FHS perspective. Those can live in /var/lib
The original, too-widely formulated statement was:
"... or requires users to modify files below /usr is broken by design."
Hi
On Thu, Jul 24, 2014 at 10:33 AM, Anders Wegge Keller wrote:
The original, too-widely formulated statement was:
"... or requires users to modify files below /usr is broken by design."
It is just restating what FHS tries to convey that all user modified configuration should live in /etc. databases aren't included in that since you aren't directly modifying them.
Rahul
-
Anders Wegge Keller -
Balint Szigeti -
Joe Zeff -
Marko Vojinovic -
Rahul Sundaram -
Ralf Corsepius