Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   ArchLinux Development (http://www.linux-archive.org/archlinux-development/)
-   -   initscripts config (http://www.linux-archive.org/archlinux-development/686210-initscripts-config.html)

Tom Gundersen 07-22-2012 02:59 PM

initscripts config
 
Hi guys,

The controversy of the recent change to rc.conf took me by surprise
(silly me). So, let appologise for not taking this to arch-dev-public
first and let me go back in time, and present an RFC, so we can all
agree on what to do and I'll make whatever changes necessary and push
a new version to testing.

It seems that there was no opposition to the change to crypttab
(except for some minor details being discussed at arch-projects), so I
won't comment on that.

Current state of affairs:

rc.conf is the central configuration file for all Arch-specific
settings. It is emphatically not the only configuration file for basic
system configuration (locale.gen, hosts, fstab, crypttab and inittab
spring to mind).

Some of the configuration in rc.conf already have their own
configuration files shipped by upstream (HARDWARECLOCK and TIMEZONE in
particular). The fact that these variables are configured in two
places, which can get out of sync (most of the time without the admin
even knowing about the second place) causes endless minor bugs.

The systemd project has been working towards providing a common set of
configuration files for all distributions (regardless of what init
daemon they use). This has been done by taking input from all the
distros that contribute to systemd, and trying to pick the good things
from each distro and leaving out the bad. I have been making sure that
these configuration files can support whatever setups our old
configuration files currently do. Most recently I added support for
keyfile-offset to the systemd crypttab format as that was the last
blocker (in my opinion) before systemd's crypttab format could replace
Arch's. I'd like to point out that getting these sorts of changes into
the systemd project has been surprisingly easy.

Initscripts and systemd both now support the same configuration
formats (i.e. we can read the systemd format, and systemd can read
ours).

rc.conf is documented in its own manpage, cross-referenced with the
systemd configuration files' manpages.

What I propose:

1) Support all current and past configuration options in rc.conf in
perpetuity (if for whatever reason something must be dropped, this
will of course be announced in the normal way). This is for instance
what we did with the old network syntax, that should still work just
fine, even if it is marked as deprecated for a long time. This
perpetual support will at least be the case in initscripts, I have no
strong opinions about whether or not this should be done in systemd as
well (probably not).

2) Deprecate the "harmful" configuration options from rc.conf (i.e.
the ones that cause bugs), as they are clearly not Arch-specific, and
have their own configuration files. The deprecation means removing
them from the standard rc.conf and recommending against their use in
rc.conf(5) as well as explaining how they should be configured
instead.

3) Remove esoteric configuration options from rc.conf and only
document them in the manpage. I don't feel strongly about this at all,
and would be happy to revert it if people object. My reasoning here is
that only experts should be changing them, so nothing a new user
should need to be faced with. As I said, not a big deal.

4) This is (apparently) the controversial one, and this one I do feel
strongly about: Embrace the systemd configuration files
(/etc/vconsole.conf, /etc/locale.conf, /etc/hostname and
/etc/modules-load.d/) fully and declare them to be the recommended
standard. This means removing KEYMAP, CONSOLEFONT, CONSOLEMAP, LOCALE
and HOSTNAME from the default rc.conf and recommending the alternative
format in rc.conf(5). We would of course still support the old
options.

Justification of (4):
a) This is in line with (at least my take on) the aim of rc.conf:
these options are no longer Arch-specific, but rather something shared
with many other distros.
b) This is more KISS (of course this is purely subjective, but I'll
put it out there anyway): one configuration file per type of options
is simpler than mixing them all together. Why should networking and
locale be configured in the same file? If we mix that, why don't we
also add in fstab and the rest?
c) The difference between the new and the old format for an end user
is truly trivial. I appreciate people not liking this change, but
anyone who claims that this is a major regression will not be taken
seriously. Sorry.
d) The new format does not require a bash interpreter to be read. This
means that lots of things which were previously impossible will now be
possible (reading and writing the configs from programs can now be
done in a sound way).
e) People who use more than one distro don't have to learn more than one format.
f) Guides, howtos, documentation will now apply equally well to Arch
as to the other major distros.
g) Having a huge ecosystem working on and agreeing on these formats
should be an obvious benefit.
h) The major one: systemd is here to stay, more and more Arch devs and
users switch to systemd and we will increasingly struggle to get
enough testers and reviewers for initscripts. However, I really want
to support initscripts as long as I can. To make this doable for me,
we need to unify. We need to share code, configuration and behavior to
make initscripts sustainable even with very few testers. You might
argue that what we should do is to block systemd in order to support
initscripts. However, I think that would be a huge error as systemd is
simply too superior in every way, so preventing our users from using
it is not doing anyone any favors.

I must admit I'm a bit exasperated by the shortsightedness of most of
the flames on BBS/IRC/MLs. So if you are going to veto this, please
also outline an alternative long-term plan.

Cheers,

Tom

Rashif Ray Rahman 07-22-2012 03:43 PM

initscripts config
 
On 22 July 2012 22:59, Tom Gundersen <teg@jklm.no> wrote:
> e) People who use more than one distro don't have to learn more than one format.
> f) Guides, howtos, documentation will now apply equally well to Arch
> as to the other major distros.

I support your position, Tom. Especially the two above are very strong
points for me, personally. I think this got resistance simply because
it was not out in the open for discussion *long enough*. You will also
have resistance because some would like Arch to be "unique", even by
some illogical means.


--
GPG/PGP ID: C0711BF1

Tom Gundersen 07-22-2012 03:45 PM

initscripts config
 
On Sun, Jul 22, 2012 at 5:43 PM, Rashif Ray Rahman <schiv@archlinux.org> wrote:
> I think this got resistance simply because
> it was not out in the open for discussion *long enough*.

Yeah, that was a mistake.

-t

Yclept Nemo 07-23-2012 04:24 AM

initscripts config
 
3) Personally this depends on the final rc.conf, is [1] or [2] going
to be it? I don't enjoy visually collating options across rc.conf
(terminal #1,vim) and rc.conf(5) (terminal #2,man). So if after
actions (2), and (4), nothing remains but "esoteric" options, then
sure, go ahead and do whatever you wish: remove them all or include
everything.

[1] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e561517815c07330b2b7d5ee5de2f6dc 7
[2] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97018871b1f91c0b22d27ae900f 7


4.1) Are we going to ship default (possibly empty) replacement
configuration files, which currently may not exist on many systems,
and add these to the backup array? This includes (/etc/vconsole.conf,
/etc/locale.conf, /etc/hostname).
4.2) To be clear, is there going to be a separate configuration for
the HARDWARECLOCK and TIMEZONE variables?

>>>d) The new format does not require a bash interpreter to be read

4.d) I think this is a terrible justification. A programming language
embedded in a configuration system grants a lot of possibilities. That
in and of itself can generate much controversy. On one hand, it might
be better to enforce a strict separation between configuration and
code, thus requiring the removal of code into wrapper scripts. On the
other hand, blurring such a line could while providing extensibility,
in certain situations encourage faux-pas configurations better suited
to wrapper scripts. Then is the faux-pas inherent to the programming
language or the context of the configuration file? In my defense, I
refer to [3] which lists many incorrect idioms.

Also there is a sound way to read configuration files written in a
programming language - simply evaluate the code.

In any case, to preserve compatibility with systemd, the new files
(/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not
contain bash.

[3] mywiki.wooledge.org/BashFAQ/

5) With the plethora of changes, each for different reasons, I think
there is justifcation for a comprehensive news item summarizing
changes to each variable:
LOCALE -> /etc/locale.conf
HARDWARECLOCK -> deprecated
USE_BTRFS -> esoteric, removed for cosmetic reasons
etc...

Tom Gundersen 07-23-2012 10:46 AM

initscripts config
 
On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo <orbisvicis@gmail.com> wrote:
> 3) Personally this depends on the final rc.conf, is [1] or [2] going
> to be it?
> [1] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e561517815c07330b2b7d5ee5de2f6dc 7
> [2] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97018871b1f91c0b22d27ae900f 7

At the moment it is [1], so if no one tells me otherwise, that's it.

> 4.1) Are we going to ship default (possibly empty) replacement
> configuration files, which currently may not exist on many systems,
> and add these to the backup array? This includes (/etc/vconsole.conf,
> /etc/locale.conf, /etc/hostname).

I'd be against it, as it seems pointless. But it would be Dave's decision.

> 4.2) To be clear, is there going to be a separate configuration for
> the HARDWARECLOCK and TIMEZONE variables?

There already are. That's the problem. HARDWARECLOCK is configured in
the third line of /etc/adjtime (see hwclock(8)), TIMEZONE is
configured by pointing the /etc/localtime symlink at what you want.

>>>>d) The new format does not require a bash interpreter to be read
>
> 4.d) I think this is a terrible justification. A programming language
> embedded in a configuration system grants a lot of possibilities.

It also makes it impossible to reason about. Or to parse from another
language than what it was defined in.

> Also there is a sound way to read configuration files written in a
> programming language - simply evaluate the code.

But there is no sound way to then change the options and write them back.

> In any case, to preserve compatibility with systemd, the new files
> (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not
> contain bash.

These files can all be read by bash, but are strictly defined. This
means we can know their format and update them in a sound way.

> 5) With the plethora of changes, each for different reasons, I think
> there is justifcation for a comprehensive news item summarizing
> changes to each variable:
> LOCALE -> /etc/locale.conf
> HARDWARECLOCK -> deprecated

Sure.

> USE_BTRFS -> esoteric, removed for cosmetic reasons

Won't kill this one, but I get your point.

-t

Leonid Isaev 07-23-2012 03:48 PM

initscripts config
 
On Mon, 23 Jul 2012 12:46:52 +0200
Tom Gundersen <teg@jklm.no> wrote:

> On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo <orbisvicis@gmail.com> wrote:
> > 3) Personally this depends on the final rc.conf, is [1] or [2] going
> > to be it?
> > [1]
> > http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e561517815c07330b2b7d5ee5de2f6dc 7
> > [2]
> > http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97018871b1f91c0b22d27ae900f 7
>
> At the moment it is [1], so if no one tells me otherwise, that's it.
>
> > 4.1) Are we going to ship default (possibly empty) replacement
> > configuration files, which currently may not exist on many systems,
> > and add these to the backup array? This includes (/etc/vconsole.conf,
> > /etc/locale.conf, /etc/hostname).
>
> I'd be against it, as it seems pointless. But it would be Dave's decision.
>
> > 4.2) To be clear, is there going to be a separate configuration for
> > the HARDWARECLOCK and TIMEZONE variables?
>
> There already are. That's the problem. HARDWARECLOCK is configured in
> the third line of /etc/adjtime (see hwclock(8)), TIMEZONE is
> configured by pointing the /etc/localtime symlink at what you want.

I wonder if there a need for TIMEZONE as a config variable at all (whereever
it is located, as opposed to an install-time setting), especially if it is
recommended to be left empty?

>
> >>>>d) The new format does not require a bash interpreter to be read
> >
> > 4.d) I think this is a terrible justification. A programming language
> > embedded in a configuration system grants a lot of possibilities.
>
> It also makes it impossible to reason about. Or to parse from another
> language than what it was defined in.
>
> > Also there is a sound way to read configuration files written in a
> > programming language - simply evaluate the code.
>
> But there is no sound way to then change the options and write them back.
>
> > In any case, to preserve compatibility with systemd, the new files
> > (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not
> > contain bash.
>
> These files can all be read by bash, but are strictly defined. This
> means we can know their format and update them in a sound way.
>
> > 5) With the plethora of changes, each for different reasons, I think
> > there is justifcation for a comprehensive news item summarizing
> > changes to each variable:
> > LOCALE -> /etc/locale.conf
> > HARDWARECLOCK -> deprecated
>
> Sure.
>
> > USE_BTRFS -> esoteric, removed for cosmetic reasons
>
> Won't kill this one, but I get your point.
>
> -t



--
Leonid Isaev
GnuPG key: 0x164B5A6D
Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Menachem Moystoviz 07-24-2012 08:12 PM

initscripts config
 
On Mon, Jul 23, 2012 at 6:48 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
> On Mon, 23 Jul 2012 12:46:52 +0200
> Tom Gundersen <teg@jklm.no> wrote:
>
>> On Mon, Jul 23, 2012 at 6:24 AM, Yclept Nemo <orbisvicis@gmail.com> wrote:
>> > 3) Personally this depends on the final rc.conf, is [1] or [2] going
>> > to be it?
>> > [1]
>> > http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e561517815c07330b2b7d5ee5de2f6dc 7
>> > [2]
>> > http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c97018871b1f91c0b22d27ae900f 7
>>
>> At the moment it is [1], so if no one tells me otherwise, that's it.
>>
>> > 4.1) Are we going to ship default (possibly empty) replacement
>> > configuration files, which currently may not exist on many systems,
>> > and add these to the backup array? This includes (/etc/vconsole.conf,
>> > /etc/locale.conf, /etc/hostname).
>>
>> I'd be against it, as it seems pointless. But it would be Dave's decision.
>>
>> > 4.2) To be clear, is there going to be a separate configuration for
>> > the HARDWARECLOCK and TIMEZONE variables?
>>
>> There already are. That's the problem. HARDWARECLOCK is configured in
>> the third line of /etc/adjtime (see hwclock(8)), TIMEZONE is
>> configured by pointing the /etc/localtime symlink at what you want.
>
> I wonder if there a need for TIMEZONE as a config variable at all (whereever
> it is located, as opposed to an install-time setting), especially if it is
> recommended to be left empty?
>
>>
>> >>>>d) The new format does not require a bash interpreter to be read
>> >
>> > 4.d) I think this is a terrible justification. A programming language
>> > embedded in a configuration system grants a lot of possibilities.
>>
>> It also makes it impossible to reason about. Or to parse from another
>> language than what it was defined in.
>>
>> > Also there is a sound way to read configuration files written in a
>> > programming language - simply evaluate the code.
>>
>> But there is no sound way to then change the options and write them back.
>>
>> > In any case, to preserve compatibility with systemd, the new files
>> > (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not
>> > contain bash.
>>
>> These files can all be read by bash, but are strictly defined. This
>> means we can know their format and update them in a sound way.
>>
>> > 5) With the plethora of changes, each for different reasons, I think
>> > there is justifcation for a comprehensive news item summarizing
>> > changes to each variable:
>> > LOCALE -> /etc/locale.conf
>> > HARDWARECLOCK -> deprecated
>>
>> Sure.
>>
>> > USE_BTRFS -> esoteric, removed for cosmetic reasons
>>
>> Won't kill this one, but I get your point.
>>
>> -t
>
>
>
> --
> Leonid Isaev
> GnuPG key: 0x164B5A6D
> Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

I have no problem with removing the options, however I agree with Yclept in that
decreasing the expressive power of the configuration file is both unnecessary
and counterproductive. While a bash script may not be the best configuration
format, moving to an ini-style format would hurt those who require being able
to dynamically specify configuration variables.
Note - I myself wouldn't be affected by decreasing the power of the format,
but I can well imagine people raising a hue and cry over it.

Just my 2c

M

Tom Gundersen 07-25-2012 04:16 PM

initscripts config
 
On Jul 25, 2012 2:04 PM, "Stéphane Gaudreault" <stephane@archlinux.org>
wrote:
> I do not use systemd, but I support and appreciate your efforts to
> improve our initscript. However, I think that most of dissatisfaction
> that was recently expressed is caused by the lack of clarity surrounding
> our plans about systemd.
>
> My understanding is that systemd is truly superior and will inevitably
> become our default system. On the other hand, our traditional init will
> need to lose some of his "personality" during a transition that might be
> short or long (not clear). In this context, I wonder why don't we avoid
> duplication of effort and move to systemd right away?
>
> If we consider that systemd is not yet ready for Arch, I wouldbe more
> comfortable if we had a clear plan and timeline for the future transition.

If there is a consensus to move to systemd, I would support that. However,
I don't want to force a move.

If a move should happen, I suggest waiting a bit longer until more unit
files have been added to our various packages. And to allow some more time
to see if problems crop up.

Regardless of that, I think the current unification is the right thing to
do. Even if we never switch to systemd, this greatly reduces the
maintenance burden for me in the long run.

Should we switch to systemd soon, I still think this has been worth while
as it means the change will be more gentle on our users, and most
importantly, it has given us the chance to verify that no functionality is
lost.

Are there any objections or suggestions for improvements to the current
rc.conf+man page in testing?

I'll wait a bit longer before pushing a final version (there are some minor
improvements in git I'd like to include).

Cheers,

Tom

Stéphane Gaudreault 07-26-2012 12:00 PM

initscripts config
 
Le 2012-07-22 10:59, Tom Gundersen a écrit :
> h) The major one: systemd is here to stay, more and more Arch devs and
> users switch to systemd and we will increasingly struggle to get
> enough testers and reviewers for initscripts. However, I really want
> to support initscripts as long as I can. To make this doable for me,
> we need to unify. We need to share code, configuration and behavior to
> make initscripts sustainable even with very few testers. You might
> argue that what we should do is to block systemd in order to support
> initscripts. However, I think that would be a huge error as systemd is
> simply too superior in every way, so preventing our users from using
> it is not doing anyone any favors.
>
> I must admit I'm a bit exasperated by the shortsightedness of most of
> the flames on BBS/IRC/MLs. So if you are going to veto this, please
> also outline an alternative long-term plan.
>
> Cheers,
>
> Tom

I am joining the party a little late.

I do not use systemd, but I support and appreciate your efforts to
improve our initscript. However, I think that most of dissatisfaction
that was recently expressed is caused by the lack of clarity surrounding
our plans about systemd.

My understanding is that systemd is truly superior and will inevitably
become our default system. On the other hand, our traditional init will
need to lose some of his "personality" during a transition that might be
short or long (not clear). In this context, I wonder why don't we avoid
duplication of effort and move to systemd right away?

If we consider that systemd is not yet ready for Arch, I wouldbe more
comfortable if we had a clear plan and timeline for the future transition.

Cheers,

Stéphane

Tom Gundersen 07-26-2012 10:20 PM

initscripts config
 
On Sun, Jul 22, 2012 at 4:59 PM, Tom Gundersen <teg@jklm.no> wrote:
> What I propose:
>
> 1) Support all current and past configuration options in rc.conf in
> perpetuity (if for whatever reason something must be dropped, this
> will of course be announced in the normal way). This is for instance
> what we did with the old network syntax, that should still work just
> fine, even if it is marked as deprecated for a long time. This
> perpetual support will at least be the case in initscripts, I have no
> strong opinions about whether or not this should be done in systemd as
> well (probably not).
>
> 2) Deprecate the "harmful" configuration options from rc.conf (i.e.
> the ones that cause bugs), as they are clearly not Arch-specific, and
> have their own configuration files. The deprecation means removing
> them from the standard rc.conf and recommending against their use in
> rc.conf(5) as well as explaining how they should be configured
> instead.
>
> 3) Remove esoteric configuration options from rc.conf and only
> document them in the manpage. I don't feel strongly about this at all,
> and would be happy to revert it if people object. My reasoning here is
> that only experts should be changing them, so nothing a new user
> should need to be faced with. As I said, not a big deal.
>
> 4) This is (apparently) the controversial one, and this one I do feel
> strongly about: Embrace the systemd configuration files
> (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname and
> /etc/modules-load.d/) fully and declare them to be the recommended
> standard. This means removing KEYMAP, CONSOLEFONT, CONSOLEMAP, LOCALE
> and HOSTNAME from the default rc.conf and recommending the alternative
> format in rc.conf(5). We would of course still support the old
> options.
>
> Justification of (4):
> a) This is in line with (at least my take on) the aim of rc.conf:
> these options are no longer Arch-specific, but rather something shared
> with many other distros.
> b) This is more KISS (of course this is purely subjective, but I'll
> put it out there anyway): one configuration file per type of options
> is simpler than mixing them all together. Why should networking and
> locale be configured in the same file? If we mix that, why don't we
> also add in fstab and the rest?
> c) The difference between the new and the old format for an end user
> is truly trivial. I appreciate people not liking this change, but
> anyone who claims that this is a major regression will not be taken
> seriously. Sorry.
> d) The new format does not require a bash interpreter to be read. This
> means that lots of things which were previously impossible will now be
> possible (reading and writing the configs from programs can now be
> done in a sound way).
> e) People who use more than one distro don't have to learn more than one format.
> f) Guides, howtos, documentation will now apply equally well to Arch
> as to the other major distros.
> g) Having a huge ecosystem working on and agreeing on these formats
> should be an obvious benefit.
> h) The major one: systemd is here to stay, more and more Arch devs and
> users switch to systemd and we will increasingly struggle to get
> enough testers and reviewers for initscripts. However, I really want
> to support initscripts as long as I can. To make this doable for me,
> we need to unify. We need to share code, configuration and behavior to
> make initscripts sustainable even with very few testers. You might
> argue that what we should do is to block systemd in order to support
> initscripts. However, I think that would be a huge error as systemd is
> simply too superior in every way, so preventing our users from using
> it is not doing anyone any favors.

As the objections to my proposal were relatively muted, I'll take that
as a consensus ;-)

At Thomas' suggestion I added a new manpage: ArchLinux(7), which will
point people to all the (old and new) config files people should be
setting up on a first install. It is very rudimentary now, but I think
it is best to just get it out there, and any patches to improve it for
the next release will be very gratefully received at
arch-projects@archlinux.org. The same goes, of course for the rc.conf
manpage, which I changed quite a bit since the last release as well.

To those who helped and gave feedback: thanks a lot! And to those who
ended up in the flaming cross-fire, my apologies :-)

Cheers,

tom


All times are GMT. The time now is 11:54 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.