Hi guys,
I have pushed initscripts-2012.07.3 to testing.
Summary of changes:
* Add support for systemd's crypttab syntax * Deprecate our old crypttab syntax, but keep supporting it * All variables in rc.conf can now be left unset and will default to something sensible * Deprecate all non-initscripts-specific settings from rc.conf, and remove them from the standard rc.conf. The standard rc.conf can now be used unchanged on a simple system (earlier this would give network errors). * Rework the rc.conf manpage, adding examples and suggestions for replacement for the deprecated settings * No longer hard-code Arch-specific welcome message (this is mostly so our various derivatives so they can use /etc/os-release rather than patching rc.sysinit) * Drop /etc/conf.d/wireless. It has been deprecated for a long time, so no longer ship the file * Several bugfixes
I'll leave it in testing for some time to make sure that the crypttab changes went smoothly.
I'll make sure to only push this to core after the next systemd is in core (it is not yet in testing, but has been released upstream), as that will add the keyfile-offset= option to crypttab.
If you agree, I'll post a news item about the change to the recommended config options in both crypttab and rc.conf.
Cheers,
Tom
On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen teg@jklm.no wrote:
[..]
- All variables in rc.conf can now be left unset and will default to
something sensible
I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.
The commit log for [1] lists the following as the main reasoning behind this change:
"Keeping everything in the manpage means we don't have to deal with .pacnew files when updating minor detals (such as default options)."
My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.
Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.
In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.
(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)
[1] https://projects.archlinux.org/initscripts.git/commit/?id=5b0626 [2] https://projects.archlinux.org/initscripts.git/commit/?id=70810a
Am 21.07.2012 08:48, schrieb Evangelos Foutras:
On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen teg@jklm.no wrote:
[..]
- All variables in rc.conf can now be left unset and will default to
something sensible
I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.
The commit log for [1] lists the following as the main reasoning behind this change:
"Keeping everything in the manpage means we don't have to deal with .pacnew files when updating minor detals (such as default options)."
My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.
Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.
In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.
(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)
[1] https://projects.archlinux.org/initscripts.git/commit/?id=5b0626 [2] https://projects.archlinux.org/initscripts.git/commit/?id=70810a
I already raised this 2 days ago, seems no other devs have opinions on this. If someone uses systemd you have to deal with systemd's config files, but if you deal with rc.conf I would like to keep rc.conf as it is for years or make a reference where to set the new options.
greetings tpowa
On Jul 21, 2012 9:46 AM, "Tobias Powalowski" < tobias.powalowski@googlemail.com> wrote:
Am 21.07.2012 08:48, schrieb Evangelos Foutras:
On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen teg@jklm.no wrote:
[..]
- All variables in rc.conf can now be left unset and will default to
something sensible
I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.
The commit log for [1] lists the following as the main reasoning behind this change:
"Keeping everything in the manpage means we don't have to deal with .pacnew files when updating minor detals (such as default options)."
My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.
Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.
In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.
(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)
[1] https://projects.archlinux.org/initscripts.git/commit/?id=5b0626 [2] https://projects.archlinux.org/initscripts.git/commit/?id=70810a
I already raised this 2 days ago, seems no other devs have opinions on
this.
If someone uses systemd you have to deal with systemd's config files, but if you deal with rc.conf I would like to keep rc.conf as it is for years or make a reference where to set the new options.
Just want to point out: existing users are free to keep the current rc.conf.
I really would like to at one point in the future only have one way of configuring the basic system regardless if what init system or even what distro you use.
This was meant to push everyone gently in this direction, and in particular make all new users use the new files, without forcing anyone. This is the same as we did with the network options (the old ones should still work).
Tom
On Jul 21, 2012 8:49 AM, "Evangelos Foutras" evangelos@foutrelis.com wrote:
On Sat, Jul 21, 2012 at 2:52 AM, Tom Gundersen teg@jklm.no wrote:
[..]
- All variables in rc.conf can now be left unset and will default to
something sensible
I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.
The commit log for [1] lists the following as the main reasoning behind this change:
"Keeping everything in the manpage means we don't have to deal with .pacnew files when updating minor detals (such as default options)."
My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.
Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.
In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.
(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)
[1] https://projects.archlinux.org/initscripts.git/commit/?id=5b0626 [2] https://projects.archlinux.org/initscripts.git/commit/?id=70810a
Before answering in detail 1) did you read the man page? E.g. the replacement for MODULES is explained there, and also the reasoning why several of the options cause problems. 2) is it clear that only the default changed and that you can keep your old rc.conf if you want?
Tom
On Sat, Jul 21, 2012 at 8:48 AM, Evangelos Foutras evangelos@foutrelis.com wrote:
I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.
I'm not going to revert them outright, but we can discuss individual options (some clearly must go, others are a matter of taste).
My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.
I guess I should have pointed out that I'd like a way to update the comments about each of the options frequently (mainly to add warnings or explanations as we realise them), but when the comments were in rc.conf that would create .pacnew files, which is annoying. I'd also like new users to have to read the manpage before they decide to use any of the discouraged options, so they will at least know the alternatives.
Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.
I agree that most people would want to configure /etc/locale.conf and /etc/vconsole.conf (or their equivalents in /etc/rc.conf). This is a matter of taste, but I'd really rather we start only using the two former files for this purpose. A benefit I did not mention yet is that they allow a lot more options than what rc.conf ever did.
As to modules: This should really not me necessary these days, and in the cases it is, it is something we should consider fixing. With kernel 3.5 the last of the mainline modules that I'm aware of (kvm) no longer needs to be specified manually.
In the case of virtualbox, I think the simplest solution here would be to load the needed modules whenever virtualbox is installed. I.e., ship a file with the virtualbox package (/usr/lib/modules-load.d/virtualbox.conf) containing
vboxnetadp vboxnetflt
(and whatever else is needed)
In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.
a) this is not the case. The current rc.conf contains several redundant and at least one harmful setting (HARDWARECLOCK).
b) fair enough, though does not seem like a major issue.
c) I'd like to do this in the long-run, but we can't just rip out the old support over night (see the old network settings or the crypttab changes for how I'd like these things to be done).
(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)
rc.conf(5) points to modules-load.d(5)[0].
-t
[0]: http://0pointer.de/public/systemd-man/modules-load.d.html
On 07/21/2012 12:51 PM, Tom Gundersen wrote:
On Sat, Jul 21, 2012 at 8:48 AM, Evangelos Foutras evangelos@foutrelis.com wrote:
I find removing most of the variables to be confusing and would suggest that [1] and [2] get reverted.
I'm not going to revert them outright, but we can discuss individual options (some clearly must go, others are a matter of taste).
My counterargument is the nonexistence, in the previous rc.conf, of default options that would need to be changed in a way that is transparent to the user.
I guess I should have pointed out that I'd like a way to update the comments about each of the options frequently (mainly to add warnings or explanations as we realise them), but when the comments were in rc.conf that would create .pacnew files, which is annoying. I'd also like new users to have to read the manpage before they decide to use any of the discouraged options, so they will at least know the alternatives.
Moreover, stuff like TIMEZONE, LOCALE and MODULES should be included in rc.conf; nobody really wants to run their system with the default LOCALE=C, and quite a few people will want to load extra modules (in my case vboxnetflt), without messing around with other files (/etc/locale.conf) or adding variables back into rc.conf, respectively.
I agree that most people would want to configure /etc/locale.conf and /etc/vconsole.conf (or their equivalents in /etc/rc.conf). This is a matter of taste, but I'd really rather we start only using the two former files for this purpose. A benefit I did not mention yet is that they allow a lot more options than what rc.conf ever did.
As to modules: This should really not me necessary these days, and in the cases it is, it is something we should consider fixing. With kernel 3.5 the last of the mainline modules that I'm aware of (kvm) no longer needs to be specified manually.
In the case of virtualbox, I think the simplest solution here would be to load the needed modules whenever virtualbox is installed. I.e., ship a file with the virtualbox package (/usr/lib/modules-load.d/virtualbox.conf) containing
vboxnetadp vboxnetflt
(and whatever else is needed)
In conclusion, a) the existing rc.conf is already stripped down to the essential system configuration options, b) I like having a default structure of these options in rc.conf instead of adding them back in at random places (in rc.conf), c) if we want to shift the task of configuring the hostname/locale/keymap/etc to external files, it might be preferable to remove them completely from rc.conf instead of having multiple points of truth.
a) this is not the case. The current rc.conf contains several redundant and at least one harmful setting (HARDWARECLOCK).
b) fair enough, though does not seem like a major issue.
c) I'd like to do this in the long-run, but we can't just rip out the old support over night (see the old network settings or the crypttab changes for how I'd like these things to be done).
(The above is my view on this change after spending 10 minutes trying to figure out how I can load modules through /etc/modprobe.d, after I noticed that MODULES was removed from rc.conf. In my defense, I thought it could be similar to the time MOD_BLACKLIST was dropped. :p)
rc.conf(5) points to modules-load.d(5)[0].
-t
I pretty much hate everything you have described here. We started from a simple and elegant, single file configuration to over 9k(not to mention that i have no freaking idea which one to edit)
Bring back the old rc.conf until we are switching to systemd or even better, kill initscripts right now and lets move to systemd.
I don't like the transition, we are in the middle and it's frustrating.
Am 21.07.2012 23:28, schrieb Ionut Biru:
I pretty much hate everything you have described here. We started from a simple and elegant, single file configuration to over 9k(not to mention that i have no freaking idea which one to edit)
Bring back the old rc.conf until we are switching to systemd or even better, kill initscripts right now and lets move to systemd.
I don't like the transition, we are in the middle and it's frustrating.
Did you even bother to read what Tom wrote? You can still use your old rc.conf. It is just recommend to use the new config files instead. This makes using initscripts and systemd in parallel easier. And there are not 9k config files but three.
So criticizing is all fine, but please keep it civil and based on facts.
Greetings,
Pierre
On 07/22/2012 12:40 AM, Pierre Schmitz wrote:
Am 21.07.2012 23:28, schrieb Ionut Biru:
I pretty much hate everything you have described here. We started from a simple and elegant, single file configuration to over 9k(not to mention that i have no freaking idea which one to edit)
Bring back the old rc.conf until we are switching to systemd or even better, kill initscripts right now and lets move to systemd.
I don't like the transition, we are in the middle and it's frustrating.
Did you even bother to read what Tom wrote? You can still use your old rc.conf. It is just recommend to use the new config files instead. This makes using initscripts and systemd in parallel easier. And there are not 9k config files but three.
sure i can use my old rc.conf but I'm about to install a new system and I don't like what I see.
There are more than 3, 1) at least 1 for loading modules in some creepy location 2) hostname 3) time 4) locale 5) fonts
At least 5 files that i have to edit in order to have the same benefit as I had with only editing 1 file.
So criticizing is all fine, but please keep it civil and based on facts.
Greetings,
Pierre
On Sat, Jul 21, 2012 at 11:28 PM, Ionut Biru ibiru@archlinux.org wrote:
I pretty much hate everything you have described here. We started from a simple and elegant, single file configuration to over 9k
Before rejecting everything, please explain why the problems I outlined are not real?
(not to mention that i have no freaking idea which one to edit)
I now added a comment to the standard rc.conf with pointers to all the files you could possibly want to edit.
Bring back the old rc.conf until we are switching to systemd or even better, kill initscripts right now and lets move to systemd.
I don't like the transition, we are in the middle and it's frustrating.
You can keep your old rc.conf, you can even use an old rc.conf when you setup a new system. Everything is clearly (I hope!) documented in the manpage. The only thing that changed was the defaults and the recommendations.
Forcing or not everyone to use systemd does not really change anything. At this stage both initscripts and systemd should support exactly the same config files.
I'm happy to revert specific things based on detailed technical feedback, but please make the effort to at least understand the issues before shooting down everything.
-t
On 07/22/2012 01:01 AM, Tom Gundersen wrote:
On Sat, Jul 21, 2012 at 11:28 PM, Ionut Biru ibiru@archlinux.org wrote:
I pretty much hate everything you have described here. We started from a simple and elegant, single file configuration to over 9k
Before rejecting everything, please explain why the problems I outlined are not real?
(not to mention that i have no freaking idea which one to edit)
I now added a comment to the standard rc.conf with pointers to all the files you could possibly want to edit.
Bring back the old rc.conf until we are switching to systemd or even better, kill initscripts right now and lets move to systemd.
I don't like the transition, we are in the middle and it's frustrating.
You can keep your old rc.conf, you can even use an old rc.conf when you setup a new system. Everything is clearly (I hope!) documented in the manpage. The only thing that changed was the defaults and the recommendations.
Forcing or not everyone to use systemd does not really change anything. At this stage both initscripts and systemd should support exactly the same config files.
I'm happy to revert specific things based on detailed technical feedback, but please make the effort to at least understand the issues before shooting down everything.
For one, I don't understand the logic behind.
The only logic i can see is that you want to force existing users to move to this "awesome" configurations schema but in the same time you say "don't do it because your old rc.conf still works"
You won't make me do this kind of transition to move to systemd compatibility.
-t
On Sun, Jul 22, 2012 at 12:09 AM, Ionut Biru ibiru@archlinux.org wrote:
The only logic i can see is that you want to force existing users to move to this "awesome" configurations schema but in the same time you say "don't do it because your old rc.conf still works"
I want to give the best possible advice to new users, and I want to alert current users to possible problems. I don't want to force anyone to do anything. All that changed was the default file and the advice given in the manpage, no functionality was or will be dropped.
I'm not insisting that the new rc.conf must be exactly like the one in testing, but please give arguments on a case-by-case basis, and if you suggest adding back variables that I have strongly recommended against please argue why my recommendations are wrong.
You won't make me do this kind of transition to move to systemd compatibility.
Ok. Then don't. We are committed to support all current and previous options forever (and if we can't we will alert users to this).
-t
What we need is someone to write a daemon that monitors rc.conf for changes and then write them to the appropriate configuration file. Also the opposite needs monitored, so when the separate configurations files are changed (probably by GUI stuff), the changes are made back to rc.conf.
(That was not a serious idea...)
While I do still like the idea of a single system configuration file, it is down the list of reasons I pick Arch. I also see why it is becoming more difficult to support, with various efforts to standardize the configuration of these standard system properties across distros so that nice GUIs can edit them... Following the use of these more standard configuration files instead of having broken behaviour in software that tries to edit them, or having to patch the software to work with Arch does seem the more Arch like approach to me.
I think Tom has done a good job in documenting the best practise and also supporting the old syntax (which is not "broken" in any way, but limited...). I have not moved to using the separate configuration files (and probably will not until we officially move to systemd or I do a new install) and everything seems to work.
Allan
I'm supporting all your effort to improve our boot process.
Arch was famous for its single rc.conf file configuration that now seems to fade away. While this may be done for good technical reasons I suggest to bring this up to some central point (hotplug/udev or systemd list ). I'd like to see something developed that we can call a common Linux early userspace configuration that would be equal in most distributions. Something like all is read from /etc/system/*
-Andy
On 22 July 2012 16:14, Andreas Radke andyrtr@archlinux.org wrote:
I'm supporting all your effort to improve our boot process.
Arch was famous for its single rc.conf file configuration that now seems to fade away. While this may be done for good technical reasons I suggest to bring this up to some central point (hotplug/udev or systemd list ). I'd like to see something developed that we can call a common Linux early userspace configuration that would be equal in most distributions. Something like all is read from /etc/system/*
-Andy
I'm a bit taken aback by this, but that's just a natural reaction to change. One central configuration file was always the thing I loved most, but that doesn't mean it was the best approach technically.
For eg., if I could shave off some seconds from offloading some things to upstream methods, then I could deal with a few more config files. We got rid of rc.conf variables one by one, as the need arose. Especially for module blacklisting, we couldn't continue to stick with the time-consuming shell logic we had back then.
The bottom line is performance and balance. If you give me performance, I'll take it. But of course, one second of removed boot time for 3 more configuration files is not "performance". There needs to be more of a tangible benefit from all this change. Otherwise, we might as well skip all helper scripts and config files and edit every single upstream-provided one.
-- GPG/PGP ID: C0711BF1
arch-dev-public@lists.archlinux.org