|
Home > Archive > Debian Developers > March 2004 > Re: Configuration (File) System
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Configuration (File) System
|
|
| Oliver Kurth 2004-03-18, 1:37 pm |
| On Thu, 2004-03-18 at 01:48, Jens Hermans wrote:
> Currently I'm working on a technology to be able to represent
> configuration files as filesystems. The whole thing is outlined at
> http://users.pandora.be/paranet/CFS.htm , but I'll try to sumarize it
> shortly in here. (Note: the source is not online, I'll try to upload it
> someday near to developer.berlios.de , project CFS)
>
> Basic concept of the whole thing is that you can mount for example your
> apache config as a filesystem and then be able to edit your config just
> by using FS functions (open/read/write/..). The configs will be parsed
> and converted into a directory structure, in which files represent
> single configuration parameters. Comments & whitespacing will off course
> be preserved, to prevent cluttering up your custom config too much.
> (more details, visit the above url)
>
> I think this could be an interesting technology to use in combination
> with debconf, eg. get rid of all those "search & replace in config file"
> configurations that are used atm.
>
> I welcome all your comments, thoughts and participation on cfs.
I have a very similar idea, see
http://advogato.org/person/oku/diary.html?start=4
I did not think about a filesystem in first place, though, although it
should be possible as a future addition. But I want to represent the
structure of a conf file as a tree, very similar to a filesystem. Also,
do keep the parsers easy, I try to preserve as much of the structure of
a conf file as possible, it is then the task of an app that uses it to
find the correct entries. See the example for /e/n/i on the link above.
Also, very important for me is that the parser does not have to
understand each single option, so that future versions will (mostly)
work, and that comments are preserved. I have extra nodes ".comment",
".empty", and ".unparsed".
Many configuration files use similar syntaxes, so parsers can be shared.
Eg. /etc/fstab and /etc/hosts are just tables, if you tell the parser
the titles of the coloumns, you can use the same parser.
So far, I have written parsers for /etc/network/interfaces, simple shell
scripts that just assign values, tables and key/values pairs (eg.
/etc/resolv.conf).
I will put the code only next week, when I have more time.
Greetings,
Oliver
| |
| Jean Pierre LeJacq 2004-03-18, 1:37 pm |
| On Thu, 18 Mar 2004, Oliver Kurth wrote:
> On Thu, 2004-03-18 at 01:48, Jens Hermans wrote:
>
> I have a very similar idea, see
> http://advogato.org/person/oku/diary.html?start=4
Have you considered the possibility XCAP or ACAP both of which are
IETF draft standards. They seem very close to what you are looking
for. A summary is available at:
http://xml.coverpages.org/ni2003-05-29-a.html
Along the same lines, wouldn't ldap be a more generic solution than
a new file system?
--
Jean Pierre
Quoin Inc
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Murat Demirten 2004-03-18, 1:37 pm |
| I'm just thinking about future of Gnu/Linux desktop systems. We have to store
some package specific metadata into filesystems. Package management must be
done in filesystem level (probably a network file system). If file foo
belongs to package bar, filesystem must be aware of this. There may be lots
of advantages, just an example: You are a desktop user, and Openoffice is not
installed on your system. You've got an email, which contains an excel
document, and you have to see it as soon as possible. What must we do?
Downloading whole Openoffice package about 50+ MB? But your friend near by
you, has openoffice installed. You just want to an excel viewer. So, why we
can't use excel viewer of your friend? It can be done automatically (with
proper authentication setup) and your Gnu/Linux system browse the whole local
network, finds installed excel viewer applications and downloads them,
install them and you can look at the excel document. Or, if finds any excel
viewer, it does not necessary to install, it opens the document on your
friend's computer and it takes only X output.
murat,
On Thursday 18 March 2004 16:14, Jens Hermans wrote:
> On Thu, 2004-03-18 at 12:14, Murat Demirten wrote:
>
> I think what you describe comes fairly close to the utility's that
> enable you to mount tar's (and tar.gz's, ...). Just browse inside the
> tar, without ever really extracting a file to disk. Do the same with
> .deb's and get rid of "installing" packages.
>
> With or without such filesystem based package management, cfs would come
> in handy anyway, since all software tends to use their own format for
> configuring instead of a standard.
>
> Maybe I'm completely missing your point, it's your turn now :p, maybe
> you can give an example of how you think the ideal package management
> enabled fs would work.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Matt Zimmerman 2004-03-18, 1:37 pm |
| On Thu, Mar 18, 2004 at 07:40:06PM +0200, Murat Demirten wrote:
> If file foo belongs to package bar, filesystem must be aware of this.
> There may be lots of advantages, just an example: You are a desktop user,
> and Openoffice is not installed on your system. You've got an email, which
> contains an excel document, and you have to see it as soon as possible.
> What must we do? Downloading whole Openoffice package about 50+ MB? But
> your friend near by you, has openoffice installed. You just want to an
> excel viewer. So, why we can't use excel viewer of your friend? It can be
> done automatically (with proper authentication setup) and your Gnu/Linux
> system browse the whole local network, finds installed excel viewer
> applications and downloads them, install them and you can look at the
> excel document. Or, if finds any excel viewer, it does not necessary to
> install, it opens the document on your friend's computer and it takes only
> X output.
None of what you describe here requires extensions to the filesystem, nor do
I see any significant advantages to implementing them that way. What do you
have in mind?
--
- mdz
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Oliver Kurth 2004-03-18, 2:35 pm |
| On Thu, 2004-03-18 at 09:40, Jean Pierre LeJacq wrote:
> On Thu, 18 Mar 2004, Oliver Kurth wrote:
>
>
> Have you considered the possibility XCAP or ACAP both of which are
> IETF draft standards. They seem very close to what you are looking
> for. A summary is available at:
>
> http://xml.coverpages.org/ni2003-05-29-a.html
Well, Jens explains on his page why he does not want to use xml. I do
not want either, though it would be possible to add an xml interface,
for both input and output - once there is a tree, you can make xml out
of it easily.
> Along the same lines, wouldn't ldap be a more generic solution than
> a new file system?
Same arguments would apply to ldap as for xml.
At least my goal (cannot speak for Jens), was to have it _simple_, with
as low overhead as possible, because I am also thinking about embedded
systems. Something that can be used by package scripts, without them
having too many dependencies.
Greetings,
Oliver
| |
| Jens Hermans 2004-03-18, 2:35 pm |
| On Thu, 2004-03-18 at 18:36, Oliver Kurth wrote:
> On Thu, 2004-03-18 at 09:40, Jean Pierre LeJacq wrote:
>
> Well, Jens explains on his page why he does not want to use xml. I do
> not want either, though it would be possible to add an xml interface,
> for both input and output - once there is a tree, you can make xml out
> of it easily.
>
>
> Same arguments would apply to ldap as for xml.
>
> At least my goal (cannot speak for Jens), was to have it _simple_, with
> as low overhead as possible, because I am also thinking about embedded
> systems. Something that can be used by package scripts, without them
> having too many dependencies.
>
> Greetings,
> Oliver
I must agree with Kurth, keep it simple, everyone can use filesystems.
Remember that other programmers will use cfs and that they probably
don't want to spend a lot of time on learning new stuff.
I've quickly read the document about xcap, and it involves an xml
repository, accessible through http (or just as files if local). Maybe
this is good in large systems/clusters, but it's definetly overkill for
the average home system. If this thing should become an industry
standard, an interface might be added to cfs for this, it's not that
difficult i suppose to export the existing fs to xml instead of to the
fuse kernel module. Atm i prefer using the simple method, since it'll
probably get more acceptance than a rather difficult system like xcap
(compared to fs's).
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jean Pierre LeJacq 2004-03-18, 2:35 pm |
| On Thu, 18 Mar 2004, Oliver Kurth wrote:
> On Thu, 2004-03-18 at 09:40, Jean Pierre LeJacq wrote:
>
> Well, Jens explains on his page why he does not want to use xml. I do
> not want either, though it would be possible to add an xml interface,
> for both input and output - once there is a tree, you can make xml out
> of it easily.
>
> ...
>
> At least my goal (cannot speak for Jens), was to have it _simple_, with
> as low overhead as possible, because I am also thinking about embedded
> systems. Something that can be used by package scripts, without them
> having too many dependencies.
Hmmm, I wouldn't get sidetracked by XML. ACAP and ldap are not XML
based. Their primary characteristic's are 1) hierchical data
structure (exactly what you spec out); 2) server based; 3)
existing standards. I suggest that there are significant advantages
to going with a server based solution. Lastly, I couldn't say
Whether a server based solution is more complex than a file based
system.
Just my 2 cents. Good luck on this project.
--
JP
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Enver ALTIN 2004-03-18, 3:35 pm |
| On Thu, 2004-03-18 at 19:40 +0200, Murat Demirten wrote:
> I'm just thinking about future of Gnu/Linux desktop systems. We have to store
> some package specific metadata into filesystems. Package management must be
> done in filesystem level (probably a network file system). If file foo
> belongs to package bar, filesystem must be aware of this. There may be lots
> of advantages, just an example: You are a desktop user, and Openoffice isnot
> installed on your system. You've got an email, which contains an excel
> document, and you have to see it as soon as possible. What must we do?
> Downloading whole Openoffice package about 50+ MB? But your friend near by
> you, has openoffice installed. You just want to an excel viewer. So, why we
> can't use excel viewer of your friend? It can be done automatically (with
> proper authentication setup) and your Gnu/Linux system browse the whole local
> network, finds installed excel viewer applications and downloads them,
> install them and you can look at the excel document. Or, if finds any excel
> viewer, it does not necessary to install, it opens the document on your
> friend's computer and it takes only X output.
A short overview of what we have been discussing in desktop-devel-list
at GNOME is, the filesystem layer in current UNIX implementation is not
ready to do so. And actually, current implementation of MIME system
worldwide is not designed to handle this (your mail agent will need to
include more `metadata` about the file attached to the message you will
be sending). So it's just, you know, the future 
Anyway, probably future will bring more, as it did in the past.
Hopefully Internet will be _A LOT_ faster, so there'll be no difference
between downloading the file from your friend and a Debian mirror on the
Internet. Just like the processing power evolution, communication speed
will probably increase, dramatically.
--
__________
| |
| | Enver ALTIN (a.k.a. skyblue)
| | Software developer, IT consultant
| FRONT |
|==========| FrontSITE Bilgi Teknolojisi A.Ž.
|_____SITE_| http://www.frontsite.com.tr/
| |
| Murat Demirten 2004-03-18, 4:34 pm |
| Hi,
Actually, key point in this example is not an effective bandwidth usage method
(preventing whole Openoffice download). Making decisions about needs for an
helper application to view the document and getting from around, more
important. Its just an example and there are more complex scenerios you
know I'm just trying to say that, we've lots of experience in Gnu/Linux
systems and package management systems so important. It is not necessary to
develop a new filesystem to improve the package manager as M. Zimmerman said.
But, in my view, such a file system helps a lot to package manager, and made
it transparent from the higher levels (think that, you're using debian and
your VFS brings a binary from redhat system, this operation not triggered by
package manager or a user). Maybe its time to start thinking about future's
Gnu/Linux systems (not in the debian-devel list
murat,
On Thursday 18 March 2004 21:37, Enver ALTIN wrote:
> On Thu, 2004-03-18 at 19:40 +0200, Murat Demirten wrote:
>
> A short overview of what we have been discussing in desktop-devel-list
> at GNOME is, the filesystem layer in current UNIX implementation is not
> ready to do so. And actually, current implementation of MIME system
> worldwide is not designed to handle this (your mail agent will need to
> include more `metadata` about the file attached to the message you will
> be sending). So it's just, you know, the future
>
> Anyway, probably future will bring more, as it did in the past.
> Hopefully Internet will be _A LOT_ faster, so there'll be no difference
> between downloading the file from your friend and a Debian mirror on the
> Internet. Just like the processing power evolution, communication speed
> will probably increase, dramatically.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Pasi Kärkkäinen 2004-03-18, 5:34 pm |
| On Thu, Mar 18, 2004 at 10:48:14AM +0100, Jens Hermans wrote:
>
> Currently I'm working on a technology to be able to represent
> configuration files as filesystems. The whole thing is outlined at
> http://users.pandora.be/paranet/CFS.htm , but I'll try to sumarize it
> shortly in here. (Note: the source is not online, I'll try to upload it
> someday near to developer.berlios.de , project CFS)
>
> Basic concept of the whole thing is that you can mount for example your
> apache config as a filesystem and then be able to edit your config just
> by using FS functions (open/read/write/..). The configs will be parsed
> and converted into a directory structure, in which files represent
> single configuration parameters. Comments & whitespacing will off course
> be preserved, to prevent cluttering up your custom config too much.
> (more details, visit the above url)
>
> I think this could be an interesting technology to use in combination
> with debconf, eg. get rid of all those "search & replace in config file"
> configurations that are used atm.
>
> I welcome all your comments, thoughts and participation on cfs.
>
Does CFS take care of config file versioning?
Biggest problem with the configuration files today is that you can't track
the changes.. if you don't set them up in the cvs or so.
Distributions should make some kind of versioning setup for the config files
to the default installation.. IMHO.
-- Pasi Kärkkäinen
^
. .
Linux
/ - \
Choice.of.the
.Next.Generation.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jens Hermans 2004-03-19, 9:38 am |
|
> Does CFS take care of config file versioning?
>=20
> Biggest problem with the configuration files today is that you can't trac=
k
> the changes.. if you don't set them up in the cvs or so.=20
>=20
> Distributions should make some kind of versioning setup for the config fi=
les
> to the default installation.. IMHO.
>=20
> -- Pasi K=E4rkk=E4inen
It doesn't atm, but this is definetly an interesting feature to include.=20
Since it's a filesystem you can always use a tool like diff or even cvs
to be able to rollback your changes, although built-in support for this
would be easier.=20
| |
| martin f krafft 2004-03-19, 9:39 am |
| also sprach Martin Waitz <tali@admingilde.org> [2004.03.18.1305 +0100]:
>
> you should have a look at the work hans reiser envisions with future
> versions of his reiserfs file system: http://www.namesys.com
Also, you may be interested in the qmail configuration mechanism,
which uses filesystems for configuration.
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
| |
| Robert Collins 2004-03-19, 9:39 am |
| On Fri, 2004-03-19 at 18:02, Jens Hermans wrote:
>
> It doesn't atm, but this is definetly an interesting feature to include.
> Since it's a filesystem you can always use a tool like diff or even cvs
> to be able to rollback your changes, although built-in support for this
> would be easier.
IMO the only builtin support should be transaction boundaries. I.e. a
change to a set of related files should all be completed, or none.
But for versioning and rollbacks of configs across multiple packages
etc, let the user choose their own VCS, don't invent a new one, or lock
them into one blessed one.
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
| |
| Amit Shah 2004-03-19, 12:34 pm |
| Oliver Kurth wrote:
> I have a very similar idea, see
> http://advogato.org/person/oku/diary.html?start=4
Plan 9 also uses a very similar approach. I don't have the links handy right
now, but just take a look at their filesystem namespace docs.
--
Amit Shah
http://amitshah.nav.to/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Pedro M. 2004-03-19, 6:36 pm |
| Amit Shah escribió:
>Oliver Kurth wrote:
>
>
>
>
>Plan 9 also uses a very similar approach. I don't have the links handy right
>now, but just take a look at their filesystem namespace docs.
>
>
>
This a very logical and good ideal. And an improvement comparing it with
Windows.
Do it ;)
Regards.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Tilo Schwarz 2004-03-20, 2:35 pm |
| On Thursday 18 March 2004 10:48, Jens Hermans wrote:
> Currently I'm working on a technology to be able to represent
> configuration files as filesystems. The whole thing is outlined at
> http://users.pandora.be/paranet/CFS.htm , but I'll try to sumarize it
> shortly in here. (Note: the source is not online, I'll try to upload it
> someday near to developer.berlios.de , project CFS)
>
> Basic concept of the whole thing is that you can mount for example your
> apache config as a filesystem and then be able to edit your config just
> by using FS functions (open/read/write/..). The configs will be parsed
> and converted into a directory structure, in which files represent
> single configuration parameters. Comments & whitespacing will off
> course be preserved, to prevent cluttering up your custom config too
> much. (more details, visit the above url)
>
> I think this could be an interesting technology to use in combination
> with debconf, eg. get rid of all those "search & replace in config
> file" configurations that are used atm.
>
> I welcome all your comments, thoughts and participation on cfs.
>
>
> tia,
>
> J. Hermans
Why not using the filesystem instead of a config file in the first place
to store key - value (or key - list of values) pairs? I think of
something like (content of the file in parentheses as example)
/etc/myfancypackage/buffersize (1024)
/etc/myfancypackage/maintaineremail (hugo@willi.org)
/etc/myfancypackage/makebackups (yes)
.... and so on.
(Think of /proc/sys/kernel as an example, too).
Then everything is in one (filesystem-) namespace and no fancy "config
file parsing" is needed. This "one namespace" is one of the ideas behind
reiserfs (see www.namesys.com).
Regards,
Tilo
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jens Hermans 2004-03-21, 5:33 pm |
| > Why not using the filesystem instead of a config file in the first place
> to store key - value (or key - list of values) pairs? I think of
> something like (content of the file in parentheses as example)
>
> /etc/myfancypackage/buffersize (1024)
> /etc/myfancypackage/maintaineremail (hugo@willi.org)
> /etc/myfancypackage/makebackups (yes)
> ... and so on.
>
> (Think of /proc/sys/kernel as an example, too).
>
> Then everything is in one (filesystem-) namespace and no fancy "config
> file parsing" is needed. This "one namespace" is one of the ideas behind
> reiserfs (see www.namesys.com).
>
> Regards,
>
> Tilo
Since these things are basicly up to the programmer of the software in
question. It would be a good thing to make filesystem configs easier
(code some library for it?), but it's still up to the developer to use
it.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2004-03-22, 5:34 pm |
| Jens Hermans wrote:
> It doesn't atm, but this is definetly an interesting feature to include.
> Since it's a filesystem you can always use a tool like diff or even cvs
> to be able to rollback your changes, although built-in support for this
> would be easier.
If I understand you correctly, CVS doesn't work because there are lots
of autogenerated files.
These autogenerated files break merging, which is a very common
operation (merging from the "default" branch to the "current
configuration" branch is even supported by dpkg).
What I'd like to see is a dpkg hook which allows to commit default
configuration changes to a separate branch and merge them later into the
current configuration branch, supported by the versioning tool.
--
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, freenet.de, hotmail.com,
libero.it, netscape.net, postino.it, tiscali.co.uk, tiscali.cz,
tiscali.it, voila.fr, wanadoo.fr, yahoo.com.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|