On Sun, 22 Apr 2007 12:17:17 +0200, Michael Prokop wrote:
I hope the following minor enhancements to the grml configuration system can make into the 1.0 release.
Preface: 1.0 is already feature freezed...
Oh, I didn't know that. Sure, postpone to later version then.
- myconfig=scan. ...
I need another automatic way to specify the grml configuration device.
So what exactly are you requesting here? You mean you want to get a 'myconfig=scan' which searches through all available partitions for a file config.tbz [in the root directory] and use it then?
Yep, that will do. Or, it can be as fancy as:
myconfig=scan [config_file]
e.g.,
myconfig=scan my_real_fancy_config_file.ext
One of the reason that I need to specify my own config_file name is that I could sneak in a config file in a publicly shared machine. I would name it as close to a window$ system file as possible in order to prevent it from being deleted by some bored users.
- Boot-Options config.d, i.e., please define a grml configuration directory. On booting all the .tbz files from within the defined directory or from the config.d option, will be restored, in the order by their names.
You mean like the config bootoption which does:
| restore configuration using file config.tbz from directory /cdrom/config/
(see http://grml.org/config/grml-config.html for more details) but not only use *one* config.tbz but *all* the available tbz files from the directory?
So it would become:
| config.d => restore all tbz. files from directory /cdrom/config.d/
That's what you want?
Exactly! restore them in the order of their names.
The save-config generated configuration, the plain bzip2 compressed tar archives is a good thing. But I don't like the fact that all related or unrelated files are all stuffed into this same file. I hope that I can group related files into different .tbz files. It is much more easy to manage than a single file.
You can name your config.tbz like you want (even when generating it with save-config), see the config=config_foobar.tbz stuff at http://grml.org/config/grml-config.html
AFAICS all that has to be done for this feature is the config.d stuff, right?
Exactly.
Why I delayed the "persistent root via unionfs" stuff is simple: unionfs is under heavy development (including some dropped features) and aufs is the current stable solution I prefer. I want to have things settle down before I write code for it, so let's see whether unionfs hits vanilla kernel...
Oh, I didn't know about the stable alternative aufs, thanks for explanation, mika.