Re: EXIM, LDAP and some pop3 stuff?
Maybe something like etcfs could be quite fun? -- Martin 'pisi' Paljak / freelancer consultant [EMAIL PROTECTED] / +37255600994 www.pisitek.com
Re: EXIM, LDAP and some pop3 stuff?
On Sun, 13 Jan 2002, Donovan Baarda wrote: [SNIP] > Note that backwards compatability with existing config files has lead to the > /etc directory changing roles. Once upon a time this dir contained files > that admins edited directly. Increasingly, editing these files directly is > becoming "not the right way to do it", with tools like adduser and > update-, becoming the new admin interface. I don't know > if these are helping much becase these tools themselves are not that > consistant. The /etc directory is becoming like an add-hock config database > with a mish-mash of storage formats and multiple inconsistant access API's. True. The problem with a lot of unix configuration files is that they were intended to only be *read* by the programs that use them, not *written*. And that still shows in their format, which is generally much easier to read than to update in an automated fashion. Also, a difficulty with line-oriented ASCII files is that their records have variable length, and updating such records is relatively hard. This of course stems from the fact that Unix only offers files as streams, not records - which is generally a good thing, IMHO, but it makes things a bit cumbersome in this case. The next problem is the general problem of different programs communicating together. If the program or package to which a configuration file belongs does not implement write support, and changing a configuration is done by a different program, then the configuration effectively file becomes a protocol. Sadly, most formats were not exactly designed with the robustness of a real protocol in mind. Defining a standard presentation for configuration data, so that readers and writers at least agree on syntax, is not a bad idea, I think. Of course, as with a real protocol, it should be relatively easy to write implementations. To *require* a particular library or API because implementation is complex will cause it to become an evolutionary dead end at some point. I definitely don't think we should have a fragile, binary heap of pointers - a filesystem-on-a-filesystem like the windows registry does *not* seem to be a good idea. Lots of small real files are not the fastest thing in the world on most Unix filesystems though, so it seems we need some compromise until everybody starts using ReiserFS or something like that. But again, I'd definitely object to having the whole configuration tree in a single file. That would be wasting a perfectly good hierarchical DB already offered by Unix - the filesystem. The modern cron.d / modutils / ip-up.d etc. approach over single files shows how much write support can already be made much easier by taking advantage of it. Perhaps DBM or something similar, like djb's cdb format could be an option. Using a separate file per 'table' lowers the risk of binary files a bit, and the filesystem could be used to store these tables in a nice hierarchical fashion. It's not that ideal perhaps, but IMHO better than a windows registry, XML or even LDAP. The latter is a nice idea, but I really think the configuration hierarchy should be reflected in the unix filesystem, not hidden inside a database. I'd like to manage data by simply copying it around, using tar, rsync, etc. In any case, I really think that this problem should be approached as designing a protocol: put the smarts in the data, not the code; make it robust and extensible, and easy to implement support for - from scratch if needed. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.xs4all.nl/~evbergen/
Re: EXIM, LDAP and some pop3 stuff?
Maybe something like etcfs could be quite fun? -- Martin 'pisi' Paljak / freelancer consultant [EMAIL PROTECTED] / +37255600994 www.pisitek.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EXIM, LDAP and some pop3 stuff?
On Sun, 13 Jan 2002, Donovan Baarda wrote: [SNIP] > Note that backwards compatability with existing config files has lead to the > /etc directory changing roles. Once upon a time this dir contained files > that admins edited directly. Increasingly, editing these files directly is > becoming "not the right way to do it", with tools like adduser and > update-, becoming the new admin interface. I don't know > if these are helping much becase these tools themselves are not that > consistant. The /etc directory is becoming like an add-hock config database > with a mish-mash of storage formats and multiple inconsistant access API's. True. The problem with a lot of unix configuration files is that they were intended to only be *read* by the programs that use them, not *written*. And that still shows in their format, which is generally much easier to read than to update in an automated fashion. Also, a difficulty with line-oriented ASCII files is that their records have variable length, and updating such records is relatively hard. This of course stems from the fact that Unix only offers files as streams, not records - which is generally a good thing, IMHO, but it makes things a bit cumbersome in this case. The next problem is the general problem of different programs communicating together. If the program or package to which a configuration file belongs does not implement write support, and changing a configuration is done by a different program, then the configuration effectively file becomes a protocol. Sadly, most formats were not exactly designed with the robustness of a real protocol in mind. Defining a standard presentation for configuration data, so that readers and writers at least agree on syntax, is not a bad idea, I think. Of course, as with a real protocol, it should be relatively easy to write implementations. To *require* a particular library or API because implementation is complex will cause it to become an evolutionary dead end at some point. I definitely don't think we should have a fragile, binary heap of pointers - a filesystem-on-a-filesystem like the windows registry does *not* seem to be a good idea. Lots of small real files are not the fastest thing in the world on most Unix filesystems though, so it seems we need some compromise until everybody starts using ReiserFS or something like that. But again, I'd definitely object to having the whole configuration tree in a single file. That would be wasting a perfectly good hierarchical DB already offered by Unix - the filesystem. The modern cron.d / modutils / ip-up.d etc. approach over single files shows how much write support can already be made much easier by taking advantage of it. Perhaps DBM or something similar, like djb's cdb format could be an option. Using a separate file per 'table' lowers the risk of binary files a bit, and the filesystem could be used to store these tables in a nice hierarchical fashion. It's not that ideal perhaps, but IMHO better than a windows registry, XML or even LDAP. The latter is a nice idea, but I really think the configuration hierarchy should be reflected in the unix filesystem, not hidden inside a database. I'd like to manage data by simply copying it around, using tar, rsync, etc. In any case, I really think that this problem should be approached as designing a protocol: put the smarts in the data, not the code; make it robust and extensible, and easy to implement support for - from scratch if needed. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.xs4all.nl/~evbergen/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EXIM, LDAP and some pop3 stuff?
On Sat, Jan 12, 2002 at 03:23:18PM +0100, Florian Bantner wrote: > On Sam, 12 Jan 2002, Peter Billson wrote: > > > > But I think this is an inherent UNIX / LDAP problem. LDAP seems > > > a very powerful tool doing for UNIX everything the 'Regestry' has > > > done for windows - and more. Whats missing here is some standardized > > > way of how to do it. > > > > Now there is something to strive for. One monolithic, incomprehensible > > mess that will cause your entire system to stop functioning if one byte > > is out of order. > > If using a Windows-like registry is "fixing" it, I'll keep the *nix's > > "broken" method, thank you. Unix might crap all over windoze for servers and server admin, but rather than just dis the oposition, it pays to focus on your own weaknesses and address them regardless. I thoroughly agree that the biggest problem at the moment with unix is a lack of consistancy. This affects everything right through from all the standard unix components, through servers, to desktop. I also believe that a "registry" is a good way to make configuration consistant, and does not deserve the bad name MS has given it. In typical Unix/Free/Open fashion, many have consiously or subconsiously recognised this and have created many implementations in various ways. The biggest problem is designing and introducing something without breaking all that has gone before... qmail. The following is a random list of some stuff that might be relevant. I have not used all of these and have only briefly looked at some . LDAP - a directory service that is the ideal place to store config info for networked access. debconf - on a deb-isp list everyone should know this one. Claims to be designed for various backends, so in theory could use LDAP backend. However, is probably not ready for multiple machines, which really needs things like host catagories/classes with deltas/inheritance for specific machines. gconf - The GNOME answer to the registry. Is primarily designed for desktop apps to store global and user prefs, but in theory could be used for other things. Probably has a nasty CORBA based interface, but should be well designed for network operation. cfengine - not really a registry service, but was designed for rapid configuration of multiple machines. I believe it's perl and works by using a centralised definition file for constants that are expanded in templates for standard config files. I think it allows for classes of hosts and only requires deltas for specific machines. Apparently it is difficult to set up, but once you have it makes configuring machines a breeze. webmin - also not a registry service, but provides a consistant modular web interface to manipulate standard config files. It does seem to have some multi-host support, but I'm not sure if it allows things like host classes and deltas. cvs/prcs - not a registry, but still a neat way to control configs for multiple machines. The whole /etc directory can be made a project, with different machines treated as different branches. In particular, prcs's easy branch/merge management makes it easy-ish treating different host classes as branches, merging common changes for different classes and hosts. Gives the added bonus of complete revision control. I think something like gconf with an LDAP backend, probaby using cfengine to generate the standard config files, would be ideal. Store the cfengine host class/delta info in LDAP, throw in revision control of the LDAP contents, add a web interface, and you'd have something really nice :-) Note that backwards compatability with existing config files has lead to the /etc directory changing roles. Once upon a time this dir contained files that admins edited directly. Increasingly, editing these files directly is becoming "not the right way to do it", with tools like adduser and update-, becoming the new admin interface. I don't know if these are helping much becase these tools themselves are not that consistant. The /etc directory is becoming like an add-hock config database with a mish-mash of storage formats and multiple inconsistant access API's. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key --
Re: xinetd /etc/host.deny ALL:PARANOID
On Sat, Jan 12, 2002 at 11:31:51AM +0100, Christian Kurz wrote: [ snip ] > > Everything that is possible is not necessarily a good idea. > > So far I agree with you. > > > However, I must admit I was talking from memory; I'm travelling at the > > moment and don't have time to read the RFCs, but I am sure you won't > > find the statement there. I am sure I read it somewhere, perhaps > > Cricket Liu's book, I don't remember. it made a strong impression on > > me as a "Best Practice". If you are offended by such a categorization > > ... > > It has nothing to do with categorization. But you talked about an > incorrectly set up DNS and that's wrong. The DNS example that Martin > used by not have been a good choice or good pratice, but it was correct > according to the RfCs. So I'm not offended by categorization, which also > should be avoided, but I was annoyed about your statement "you just set > up your DNS incorrectly". Ok, "you've done something stupid that is, however, allowed by the RFCs." Is that better? :) Regards, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpz1Vf10l9ro.pgp Description: PGP signature
Re: EXIM, LDAP and some pop3 stuff?
On Sat, Jan 12, 2002 at 03:23:18PM +0100, Florian Bantner wrote: > On Sam, 12 Jan 2002, Peter Billson wrote: > > > > But I think this is an inherent UNIX / LDAP problem. LDAP seems > > > a very powerful tool doing for UNIX everything the 'Regestry' has > > > done for windows - and more. Whats missing here is some standardized > > > way of how to do it. > > > > Now there is something to strive for. One monolithic, incomprehensible > > mess that will cause your entire system to stop functioning if one byte > > is out of order. > > If using a Windows-like registry is "fixing" it, I'll keep the *nix's > > "broken" method, thank you. Unix might crap all over windoze for servers and server admin, but rather than just dis the oposition, it pays to focus on your own weaknesses and address them regardless. I thoroughly agree that the biggest problem at the moment with unix is a lack of consistancy. This affects everything right through from all the standard unix components, through servers, to desktop. I also believe that a "registry" is a good way to make configuration consistant, and does not deserve the bad name MS has given it. In typical Unix/Free/Open fashion, many have consiously or subconsiously recognised this and have created many implementations in various ways. The biggest problem is designing and introducing something without breaking all that has gone before... qmail. The following is a random list of some stuff that might be relevant. I have not used all of these and have only briefly looked at some . LDAP - a directory service that is the ideal place to store config info for networked access. debconf - on a deb-isp list everyone should know this one. Claims to be designed for various backends, so in theory could use LDAP backend. However, is probably not ready for multiple machines, which really needs things like host catagories/classes with deltas/inheritance for specific machines. gconf - The GNOME answer to the registry. Is primarily designed for desktop apps to store global and user prefs, but in theory could be used for other things. Probably has a nasty CORBA based interface, but should be well designed for network operation. cfengine - not really a registry service, but was designed for rapid configuration of multiple machines. I believe it's perl and works by using a centralised definition file for constants that are expanded in templates for standard config files. I think it allows for classes of hosts and only requires deltas for specific machines. Apparently it is difficult to set up, but once you have it makes configuring machines a breeze. webmin - also not a registry service, but provides a consistant modular web interface to manipulate standard config files. It does seem to have some multi-host support, but I'm not sure if it allows things like host classes and deltas. cvs/prcs - not a registry, but still a neat way to control configs for multiple machines. The whole /etc directory can be made a project, with different machines treated as different branches. In particular, prcs's easy branch/merge management makes it easy-ish treating different host classes as branches, merging common changes for different classes and hosts. Gives the added bonus of complete revision control. I think something like gconf with an LDAP backend, probaby using cfengine to generate the standard config files, would be ideal. Store the cfengine host class/delta info in LDAP, throw in revision control of the LDAP contents, add a web interface, and you'd have something really nice :-) Note that backwards compatability with existing config files has lead to the /etc directory changing roles. Once upon a time this dir contained files that admins edited directly. Increasingly, editing these files directly is becoming "not the right way to do it", with tools like adduser and update-, becoming the new admin interface. I don't know if these are helping much becase these tools themselves are not that consistant. The /etc directory is becoming like an add-hock config database with a mish-mash of storage formats and multiple inconsistant access API's. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xinetd /etc/host.deny ALL:PARANOID
On Sat, Jan 12, 2002 at 11:31:51AM +0100, Christian Kurz wrote: [ snip ] > > Everything that is possible is not necessarily a good idea. > > So far I agree with you. > > > However, I must admit I was talking from memory; I'm travelling at the > > moment and don't have time to read the RFCs, but I am sure you won't > > find the statement there. I am sure I read it somewhere, perhaps > > Cricket Liu's book, I don't remember. it made a strong impression on > > me as a "Best Practice". If you are offended by such a categorization > > ... > > It has nothing to do with categorization. But you talked about an > incorrectly set up DNS and that's wrong. The DNS example that Martin > used by not have been a good choice or good pratice, but it was correct > according to the RfCs. So I'm not offended by categorization, which also > should be avoided, but I was annoyed about your statement "you just set > up your DNS incorrectly". Ok, "you've done something stupid that is, however, allowed by the RFCs." Is that better? :) Regards, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton msg04840/pgp0.pgp Description: PGP signature
