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. disclaimer I have not used all of these and have only briefly looked at some /disclaimer. 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-somethingoranother, 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: 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-somethingoranother, 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?
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 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. disclaimer I have not used all of these and have only briefly looked at some /disclaimer. 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-somethingoranother, 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: 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-somethingoranother, 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
Re: EXIM, LDAP and some pop3 stuff?
On Sam, 12 Jan 2002, Kevin Littlejohn wrote: Seems to me so, too. I wonder if this problem is so far of that there are no 'standard' ways of doing it. Every MTA has it's way, every IMAP/POP3 MDA has it's own way - where mta1 only works with mda2 and mta3 only with mda1. Worst of all the IMAP server who promote their own protocol and see LDAP as its disabled stepbrother. 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. Got a little of topic, sorry. Look to using pam for pop3 passwords, and configure pam to use ldap. That's the most likely way to make it work. KJL On Sat, 2002-01-12 at 10:47, Florian Bantner wrote: Seems I'm really to stupid to find my piece of information by myself, but: First things first. I'm switching to doing mail-handling with LDAP in order to get rid of the 'dead' users in my passwd. Configuring EXIM with LDAP should just work fine. Enter the users in LDAP under some domain-branches, let exim look there for it's delivery and put mail under /var/mail/domain/user. Here we go. Problem is now: How to get the mail delivered to the users via pop3. None of the pop3-daemons I managed to find supports LDAP by heart even if it seems so simple: Lookup user/pass in LDAP, find mail-directory and deliver. Am I looking at the wrong place? btw. using potato. Regards, Florian Bantner -- -- Florian Bantner AXON-E Interaktive Medien Tel. +49-941-599 854 4 Fax. +49-941-599 854 1 Mail [EMAIL PROTECTED] Key http://www.axon-e.de/gpg/f.bantner.key 1191 0C87 D9DB 3217 ABBA 5223 6D74 AB19 5C9D FC49 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EXIM, LDAP and some pop3 stuff?
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. Pete Billson -- http://www.elbnet.com ELB Internet Services, Inc. Web Design, Computer Consulting, Internet Hosting -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EXIM, LDAP and some pop3 stuff?
On Sun, 2002-01-13 at 00:18, Florian Bantner wrote: On Sam, 12 Jan 2002, Kevin Littlejohn wrote: Seems to me so, too. I wonder if this problem is so far of that there are no 'standard' ways of doing it. Every MTA has it's way, every IMAP/POP3 MDA has it's own way - where mta1 only works with mda2 and mta3 only with mda1. Worst of all the IMAP server who promote their own protocol and see LDAP as its disabled stepbrother. 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. Got a little of topic, sorry. Look to using pam for pop3 passwords, and configure pam to use ldap. That's the most likely way to make it work. KJL I don't actually see it as that non-standard. I've got a woody-based system I look after using LDAP for pretty much everything, via standard debian packages, and it's pretty simple once you get over the first hurdle of understanding how to lay out the info in an LDAP database - PAM handles most everything, certain modules have their own specific LDAP auth handlers that provide a touch more flexibility than PAM (eg. apache). The only nasty gotchya I ran into was MySQL - if nscd isn't running, and mysql's user is served out of LDAP instead of in the /etc/passwd file, mysql chokes badly on trying to retrieve username from uid (or something near there, I didn't look too much further than realising that nscd wasn't running and mysql was attempting to make queries of that type). I'm using, for reference, courier-imap, delivering into that from postfix (I like maildir, but dislike qmail). Courier uses it's own ldap auth module, postfix uses it's own LDAP module. ssh uses PAM, apache uses it's own module (for added flexibility), Zope uses it's own LDAP auth (because it does wierd and wonderful things with user info), I don't do POP or ftp thankfully but I'd imagine PAM support for both of those would be fine. passwd and su also lean on PAM, nscd/nsswitch understands to use LDAP for getpwnam type lookups. Each package that provides it's own module for LDAP seems to want specific extra info out of the LDAP database - or support specific extras. Each will, as far as I can tell, also use PAM if you really want to keep things centralised - the extended modules are pretty much optional, but worthwhile. I doubt you'll ever get a single centralised way of managing things, tho - and truth be told, even in Windows you don't get that - different packages will handle their own config info in different ways, if they're written by different people. Some packages abuse the registry, some keep all their config to themselves, and so on and so forth. Certainly, the various games I have under Windows don't all have a standard way of configuring them, for what little configuration they might have. Hell, programs even differ in where to find the configuration info (control panel vs. file/configuration vs. view/properties vs. whatever else a given author may have thought was intuitive) :) Now I'm way off topic ;) KJL -- Internet techieObsidian Consulting Group Phone: +613 9653 9364Fax: +613 9354 2681 http://www.obsidian.com.au/ [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EXIM, LDAP and some pop3 stuff?
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. Sorry when I offended you. But I think you intentionally missunderstood me. I'm definitively not trying and/or looking forward to using the windows-registry under linux. Hell, I don't whant a crippled system, too, and I was very happy when I got rid of it. But lets face it: Before Windows introduced the Reg it had (feel its unix-like or not) configuration information scattered around the system. It wasn't even (really) possible to store per-user information where you could find it again. How did you get system-configuration from one system to another? How did you make a backup of all your configs? For Windows-Terms the Registry was a big step. Nevertheless, the Regestry was a way against the windows problems. (and not the worst one). Using it for unix-problems is like putting a car trailer in order to extend the capacity of a freighter. What I'm looking for is a way to tidy up the freighter a little. For example: I'm dealing with many apaches on different hosts and different configurations. Why shouldn't it be possible to store all of the apaches configuration (and not only the auth-info) in one centralized configuration? Add the interface-/dns-configuration and I could easily move one web-presenz from one host to another. It is true: Even now this is possible using some fancy shell-scrips and generating configs etc. from ldap-information. But: Everyone who would want to do so, would invent it by its own. What a silly concept, hundreds of people inventing one and the same system to store config-information in (not exactly, but nearly) the same way in the directory. And configuring apache is only one thing. Imaging nearly every service you have running on more than one server. Add distributed user-configuration for client-management. Add backup- and fail-over capabilities. Use it to remote-control distant-hosts. What I want is to have here some standart-way of doing it. Perhaps a rfc or a 'ldap standartization project' equivalent to the linux file-system standardization. What you get is an easy way of system (which is indeed different from service) configuration, and that in nearly no time. Again: I don't what to copy windows-errors. I want to improve. Regards, Florian -- -- Florian Bantner AXON-E Interaktive Medien Tel. +49-941-599 854 4 Fax. +49-941-599 854 1 Mail [EMAIL PROTECTED] Key http://www.axon-e.de/gpg/f.bantner.key 1191 0C87 D9DB 3217 ABBA 5223 6D74 AB19 5C9D FC49 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EXIM, LDAP and some pop3 stuff?
On Sam, 12 Jan 2002, Kevin Littlejohn wrote: Seems to me so, too. I wonder if this problem is so far of that there are no 'standard' ways of doing it. Every MTA has it's way, every IMAP/POP3 MDA has it's own way - where mta1 only works with mda2 and mta3 only with mda1. Worst of all the IMAP server who promote their own protocol and see LDAP as its disabled stepbrother. 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. Got a little of topic, sorry. Look to using pam for pop3 passwords, and configure pam to use ldap. That's the most likely way to make it work. KJL On Sat, 2002-01-12 at 10:47, Florian Bantner wrote: Seems I'm really to stupid to find my piece of information by myself, but: First things first. I'm switching to doing mail-handling with LDAP in order to get rid of the 'dead' users in my passwd. Configuring EXIM with LDAP should just work fine. Enter the users in LDAP under some domain-branches, let exim look there for it's delivery and put mail under /var/mail/domain/user. Here we go. Problem is now: How to get the mail delivered to the users via pop3. None of the pop3-daemons I managed to find supports LDAP by heart even if it seems so simple: Lookup user/pass in LDAP, find mail-directory and deliver. Am I looking at the wrong place? btw. using potato. Regards, Florian Bantner -- -- Florian Bantner AXON-E Interaktive Medien Tel. +49-941-599 854 4 Fax. +49-941-599 854 1 Mail [EMAIL PROTECTED] Key http://www.axon-e.de/gpg/f.bantner.key 1191 0C87 D9DB 3217 ABBA 5223 6D74 AB19 5C9D FC49 --
Re: EXIM, LDAP and some pop3 stuff?
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. Pete Billson -- http://www.elbnet.com ELB Internet Services, Inc. Web Design, Computer Consulting, Internet Hosting
Re: EXIM, LDAP and some pop3 stuff?
On Sun, 2002-01-13 at 00:18, Florian Bantner wrote: On Sam, 12 Jan 2002, Kevin Littlejohn wrote: Seems to me so, too. I wonder if this problem is so far of that there are no 'standard' ways of doing it. Every MTA has it's way, every IMAP/POP3 MDA has it's own way - where mta1 only works with mda2 and mta3 only with mda1. Worst of all the IMAP server who promote their own protocol and see LDAP as its disabled stepbrother. 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. Got a little of topic, sorry. Look to using pam for pop3 passwords, and configure pam to use ldap. That's the most likely way to make it work. KJL I don't actually see it as that non-standard. I've got a woody-based system I look after using LDAP for pretty much everything, via standard debian packages, and it's pretty simple once you get over the first hurdle of understanding how to lay out the info in an LDAP database - PAM handles most everything, certain modules have their own specific LDAP auth handlers that provide a touch more flexibility than PAM (eg. apache). The only nasty gotchya I ran into was MySQL - if nscd isn't running, and mysql's user is served out of LDAP instead of in the /etc/passwd file, mysql chokes badly on trying to retrieve username from uid (or something near there, I didn't look too much further than realising that nscd wasn't running and mysql was attempting to make queries of that type). I'm using, for reference, courier-imap, delivering into that from postfix (I like maildir, but dislike qmail). Courier uses it's own ldap auth module, postfix uses it's own LDAP module. ssh uses PAM, apache uses it's own module (for added flexibility), Zope uses it's own LDAP auth (because it does wierd and wonderful things with user info), I don't do POP or ftp thankfully but I'd imagine PAM support for both of those would be fine. passwd and su also lean on PAM, nscd/nsswitch understands to use LDAP for getpwnam type lookups. Each package that provides it's own module for LDAP seems to want specific extra info out of the LDAP database - or support specific extras. Each will, as far as I can tell, also use PAM if you really want to keep things centralised - the extended modules are pretty much optional, but worthwhile. I doubt you'll ever get a single centralised way of managing things, tho - and truth be told, even in Windows you don't get that - different packages will handle their own config info in different ways, if they're written by different people. Some packages abuse the registry, some keep all their config to themselves, and so on and so forth. Certainly, the various games I have under Windows don't all have a standard way of configuring them, for what little configuration they might have. Hell, programs even differ in where to find the configuration info (control panel vs. file/configuration vs. view/properties vs. whatever else a given author may have thought was intuitive) :) Now I'm way off topic ;) KJL -- Internet techieObsidian Consulting Group Phone: +613 9653 9364Fax: +613 9354 2681 http://www.obsidian.com.au/ [EMAIL PROTECTED]
Re: EXIM, LDAP and some pop3 stuff?
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. Sorry when I offended you. But I think you intentionally missunderstood me. I'm definitively not trying and/or looking forward to using the windows-registry under linux. Hell, I don't whant a crippled system, too, and I was very happy when I got rid of it. But lets face it: Before Windows introduced the Reg it had (feel its unix-like or not) configuration information scattered around the system. It wasn't even (really) possible to store per-user information where you could find it again. How did you get system-configuration from one system to another? How did you make a backup of all your configs? For Windows-Terms the Registry was a big step. Nevertheless, the Regestry was a way against the windows problems. (and not the worst one). Using it for unix-problems is like putting a car trailer in order to extend the capacity of a freighter. What I'm looking for is a way to tidy up the freighter a little. For example: I'm dealing with many apaches on different hosts and different configurations. Why shouldn't it be possible to store all of the apaches configuration (and not only the auth-info) in one centralized configuration? Add the interface-/dns-configuration and I could easily move one web-presenz from one host to another. It is true: Even now this is possible using some fancy shell-scrips and generating configs etc. from ldap-information. But: Everyone who would want to do so, would invent it by its own. What a silly concept, hundreds of people inventing one and the same system to store config-information in (not exactly, but nearly) the same way in the directory. And configuring apache is only one thing. Imaging nearly every service you have running on more than one server. Add distributed user-configuration for client-management. Add backup- and fail-over capabilities. Use it to remote-control distant-hosts. What I want is to have here some standart-way of doing it. Perhaps a rfc or a 'ldap standartization project' equivalent to the linux file-system standardization. What you get is an easy way of system (which is indeed different from service) configuration, and that in nearly no time. Again: I don't what to copy windows-errors. I want to improve. Regards, Florian -- -- Florian Bantner AXON-E Interaktive Medien Tel. +49-941-599 854 4 Fax. +49-941-599 854 1 Mail [EMAIL PROTECTED] Key http://www.axon-e.de/gpg/f.bantner.key 1191 0C87 D9DB 3217 ABBA 5223 6D74 AB19 5C9D FC49 --
EXIM, LDAP and some pop3 stuff?
Seems I'm really to stupid to find my piece of information by myself, but: First things first. I'm switching to doing mail-handling with LDAP in order to get rid of the 'dead' users in my passwd. Configuring EXIM with LDAP should just work fine. Enter the users in LDAP under some domain-branches, let exim look there for it's delivery and put mail under /var/mail/domain/user. Here we go. Problem is now: How to get the mail delivered to the users via pop3. None of the pop3-daemons I managed to find supports LDAP by heart even if it seems so simple: Lookup user/pass in LDAP, find mail-directory and deliver. Am I looking at the wrong place? btw. using potato. Regards, Florian Bantner -- -- Florian Bantner AXON-E Interaktive Medien Tel. +49-941-599 854 4 Fax. +49-941-599 854 1 Mail [EMAIL PROTECTED] Key http://www.axon-e.de/gpg/f.bantner.key 1191 0C87 D9DB 3217 ABBA 5223 6D74 AB19 5C9D FC49 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
