Wish lists for enhancing the grml configuration system
Package: restore-config Severity: wishlist
Hi, Mika:
First of all, thanks for your hard works that releases grml 0.9-7, and grml-small 0.3-2 recently.
I hope the following minor enhancements to the grml configuration system can make into the 1.0 release.
- support reading configuration files from NTFS partitions. Don't know if it already possible, just list it here first.
- myconfig=scan. I know by default the booting process tries to mount a device labeled GRMLCFG, and do configuration from there.
The problem is that, in nowadays window$ world, the cooperate policy will most often prevent me from change my own disk label. You won't believe it, nowadays window$ world is so dummy-proof that in many places I can't even change my window$ desktop settings.
So I need another automatic way to specify the grml configuration device.
- 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.
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.
- Boot-Options scripts.d, same concept as config.d, for scripts.
- persistentroot. I don't know how comfortable you are about the union fs now, but I still think that a partition or a loopback device as a persistent root, i.e., not only persistent home, is a good idea.
To tell the truth, ever since installing grml 0.7 onto my HD, I didn't use/test the new grml iso files any more. Because I've put so much time & effort configuring the installed grml, that I don't want to waste my time again for a new iso versions. With persistentroot, the journey migrating to newer versions of grml can be a bit smoother.
Moreover, having a persistentroot can put the automatic installation of debian packages (from directory named debs) into real use, because I think the amount of debian packages that can be automatic installed is limited by ram space.
These are all small changes that will have big impacts. Much more flexibilities can be achieved by doing so.
Thanks
Tong
-- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (50, 'unstable'), (30, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-grml Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
* Tong Sun mlist4suntong@yahoo.com [20070422 06:15]:
First of all, thanks for your hard works that releases grml 0.9-7, and grml-small 0.3-2 recently.
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, we are in the bughunting process now and rc1 will be available soon. All the extra features have to be postponed therefore. I don't want to add any new features anymore because we have tons of new features already, all of them have to be carefully tested which requires lots of time.
- support reading configuration files from NTFS partitions. Don't know if it already possible, just list it here first.
I'm not aware of any filesystem limits regarding bootoption myconfig.
- myconfig=scan. I know by default the booting process tries to mount a device labeled GRMLCFG, and do configuration from there.
The problem is that, in nowadays window$ world, the cooperate policy will most often prevent me from change my own disk label. You won't believe it, nowadays window$ world is so dummy-proof that in many places I can't even change my window$ desktop settings.
So 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 and use it then?
- 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?
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?
- Boot-Options scripts.d, same concept as config.d, for scripts.
- persistentroot. I don't know how comfortable you are about the union fs now, but I still think that a partition or a loopback device as a persistent root, i.e., not only persistent home, is a good idea.
Persistent root is on our TODO list, see also http://bts.grml.org/grml/issue121 and http://bts.grml.org/grml/issue40
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...
regards, -mika-
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.
On Sun, 22 Apr 2007 20:24:26 +0000, - Tong - wrote:
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.
Same problem/request applies to "home=scan" too.
* - Tong - mlist4suntong@yahoo.com [20070422 23:15]:
On Sun, 22 Apr 2007 20:24:26 +0000, - Tong - wrote:
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.
Same problem/request applies to "home=scan" too.
So you want to be able to specify the name of "grml.img" on your own? Ok, will add to the todolist as well.
regards, -mika-
* - Tong - mlist4suntong@yahoo.com [20070422 23:15]:
On Sun, 22 Apr 2007 12:17:17 +0200, Michael Prokop wrote:
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]
Ok.
e.g.,
myconfig=scan my_real_fancy_config_file.ext
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That's not possible in this way because it's not an unique bootoption. ;) But:
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.
... in combination with another bootoption this shouldn't be a big deal anyway.
- 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.
Ok.
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.
Ok.
I'll add the above stuff to our TODO list and will work on it post grml 1.0.
regards, -mika-
On Mon, 23 Apr 2007 14:28:26 +0200, Michael Prokop wrote:
I'll add the above stuff to our TODO list and will work on it post grml 1.0.
Thanks a lot!
On Sun, 22 Apr 2007 12:17:17 +0200, Michael Prokop wrote:
So it would become:
| config.d => restore all tbz. files from directory /cdrom/config.d/
Thinking into the future, after this is done, if I want to exclude the /var/lib/dpkg/ from the CD and put it as /cdrom/config.d/00var.lib.dpkg.tbz, is it a good idea?
The reason that I want to do it is that, the /var/lib/dpkg/ directory alone is about 80~90M, which is rather expensive for the 50M grml-small. However, if I do that, I am worry about the memory limitation, because grml don't mount any swap partitions by default, what if I need to run such configured grml on a 128M memory PC?
* - Tong - mlist4suntong@yahoo.com [20070427 15:15]:
On Sun, 22 Apr 2007 12:17:17 +0200, Michael Prokop wrote:
So it would become:
| config.d => restore all tbz. files from directory /cdrom/config.d/
Thinking into the future, after this is done, if I want to exclude the /var/lib/dpkg/ from the CD and put it as /cdrom/config.d/00var.lib.dpkg.tbz, is it a good idea?
No.
The reason that I want to do it is that, the /var/lib/dpkg/ directory alone is about 80~90M, which is rather expensive for the 50M grml-small. However, if I do that, I am worry about the memory limitation, because grml don't mount any swap partitions by default, what if I need to run such configured grml on a 128M memory PC?
Mainly only overlay files (deriving from unionfs-feature) affect memory usage (unless you use the toram feature of course), so as long as you don't touch/modify the files it does not hurt.
grml-small works with >=32 MB of RAM, though 128M or more are recommended of course.
regards, -mika-
participants (3)
-
- Tong - -
Michael Prokop -
Tong Sun