Re: Honesty about some exim mistakes
Greg Folkert wrote: Here is just a few options I am supporting currently available: Sounds nice :) You must have spent tremendous amounts of time into developing such a thing. If you see the beauty of the seperate files for what it is intended to do, its like magically everything comes into view. Hm, I don't see it with exim-config. What I see is only a mess of files and two large, unreadable files (template and config), which keep me from setting up Exim4. I use it so I don't have to worry about multiple access to hyarge config file. I can manipulate each file (based on a naming scheme and service level) without worry if those changes would get on multiple simultaneous commits, where last one to write wins. But you do never know what's actually configured and if it is set up the way you wanted it. Well, I guess you have a point, but if you make an attempt understand why Debian really chooses to do this like this it makes a ton of sense, when you look at thing from an Easily adding and removing components, without screwing everything else up point of view. Flexibility wasn't the demand, but efficiently setting things up in the way they should work was. I could have spent months on finding out how exim-config is supposed to be used to achieve the setup I wanted and spent even more time on developing some system that would allow me to know what's going on. But that won't have been efficient. Also, allows me to find and fix individual domain problems (should they arise) and fix them plus add in the syntax for checking that problem for the system. Sort of like what Jalopy does for CVS. It is much easier to have one human readable configuration file that a mess of unreadable files with dubious interrelationships to check when problems arise. Yes, it comes down to someone understanding what needs to be done and how to do it. If I were you, there is a big lesson to be learned. Learning to do things in Multiple ways (sometimes 50 different ways) is a good thing. Locking yourself into a Straight and Narrow is a sure path to being obsoleted. If my life were mabye 1000 times longer and time not an issue at all, I could do that. As things are, it will end soon because of a lack of medication. GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Honesty about some exim mistakes
listrcv wrote: Greg Folkert wrote: [...] If you see the beauty of the seperate files for what it is intended to do, its like magically everything comes into view. Hm, I don't see it with exim-config. What I see is only a mess of files and two large, unreadable files (template and config), which keep me from setting up Exim4. [...] From /usr/share/doc/exim4-base/README.Debian.gz: I still don't like it. I want one monolithic file. -- No problem. Take your file and install it as /etc/exim4/exim4.conf. Exim will use that file. /var/lib/exim4/config.autogenerated, the file generated by update-exim4.conf, is ignored in that case. HTH Sumo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Honesty about some exim mistakes
Greg Folkert wrote: If you do a bit of reading, you'll see that the multi-config files setup is very flexible. It might be flexible, but it's utterly hard to get and to maintain an overview of what is actually being configured. I didn't manage to find that out, and getting to the configuration you want becomes impossible. It's not only the splitting of the configuration across a multitude of files, but using macros and/or replacements within the actual configuration file created thereof makes it totally unreadable. Exim becomes like sendmail with this :( It's a very big mistake to do it that way in the first place. It has made it so I can use Exim4 with C-Panel and Plesk, rather than shudder the default. Yes, I have a heavily invested time into it... but it works and I don't care. What are c-panel and plesk? I have also invested a lot of time into configuring mail servers. Many years ago I kicked sendmail because it's not configurable and switched to qmail on Suse distributions. When switching to Debian, Exim was proposed as the default MTA, and I decided to give it a try. I found out that Exim is just great because it's easy to configure and has lots of nice features. But later, a switch from Exim3 to Exim4 was made (which was overdue), and Debain-Exim4 started out with the automagic configuration. I had more than enough trouble to get the simplest setup with that on my system at home, and I still don't have the functionality I had before yet because I gave up on the sucking autoconfig and haven't had time to get it anew yet. Recently, I had to renew our company mail server, and it was obvious that I wont be able to set things up with the autoconfig. So I just started with the example config provided along the docs, and it became very easy to get to the required setup within a few minutes. All I had to learn about is new features like ACLs and other small changes to the config options. There's no way to get that with the autoconfig, and anything you get out of it is an unreadable config file that _might_ do what it should, but you won't know because you can't read it. So I keep saying the autoconfig sucks. Fortunately, you don't have to use it if you don't want to, and if it's helpful for others, than it is a good thing. Just think how nice it would be to be able to drop a template file into a directory for a domain (virtual) and then allow the owner to have control over it through a svn merge. So that it can be reverted. It'd be hell to do that with the single config. Hm, I have never dealt with virtual domains, so I can't think about it. I just keep hoping that we won't get forced to use the autoconfig at some time. And I can only recommend not to use it because it makes things much more difficult once you want more than the standard options you are provided with when setting up a system. But if you don't want more than that, you won't ask here :) GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Honesty about some exim mistakes
Virtual domains are a big concern to me..I may be brand new at this but I'm stuck with the task and I need an enterprise-size mail server.cpanel: http://www.cpanel.net/ is used for site config and mgmt plesk: server mgmt for web hosting. think webmin, but bigger.I think my greatest hate of exim-config thus far has actually been my lack of experience with DEBCONF, and thus all the debconf replacements in the otherwise easy to read config. It should also be noted that the multi-file config is more like The Debian Way tmAs you can see with apache, includes of directories of files is easier for dropping in a new section and version managing an existing config. I do this also! On 3/28/06, listrcv [EMAIL PROTECTED] wrote: Greg Folkert wrote: If you do a bit of reading, you'll see that the multi-config files setup is very flexible.It might be flexible, but it's utterly hard to get and to maintain anoverview of what is actually being configured. I didn't manage to find that out, and getting to the configuration you want becomes impossible.It's not only the splitting of the configuration across a multitude offiles, but using macros and/or replacements within the actual configuration file created thereof makes it totally unreadable.Exim becomes like sendmail with this :( It's a very big mistake to do itthat way in the first place. It has made it so I can use Exim4 with C-Panel and Plesk, rather than shudder the default. Yes, I have a heavily invested time into it... but it works and I don't care.What are c-panel and plesk?I have also invested a lot of time into configuring mail servers. Many years ago I kicked sendmail because it's not configurable and switchedto qmail on Suse distributions. When switching to Debian, Exim wasproposed as the default MTA, and I decided to give it a try. I found out that Exim is just great because it's easy to configure and has lots ofnice features. But later, a switch from Exim3 to Exim4 was made (whichwas overdue), and Debain-Exim4 started out with the automagicconfiguration. I had more than enough trouble to get the simplest setup with that on my system at home, and I still don't have the functionalityI had before yet because I gave up on the sucking autoconfig and haven'thad time to get it anew yet. Recently, I had to renew our company mail server, and it was obvious that I wont be able to set things up with theautoconfig. So I just started with the example config provided along thedocs, and it became very easy to get to the required setup within a few minutes. All I had to learn about is new features like ACLs and othersmall changes to the config options. There's no way to get that with theautoconfig, and anything you get out of it is an unreadable config file that _might_ do what it should, but you won't know because you can'tread it. So I keep saying the autoconfig sucks.Fortunately, you don't have to use it if you don't want to, and if it'shelpful for others, than it is a good thing. Just think how nice it would be to be able to drop a template file into a directory for a domain (virtual) and then allow the owner to have control over it through a svn merge. So that it can be reverted. It'd be hell to do that with the single config.Hm, I have never dealt with virtual domains, so I can't think about it.I just keep hoping that we won't get forced to use the autoconfig atsome time. And I can only recommend not to use it because it makes things much moredifficult once you want more than the standard options you are providedwith when setting up a system. But if you don't want more than that, you won't ask here :)GH--To UNSUBSCRIBE, email to [EMAIL PROTECTED]with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Honesty about some exim mistakes
Drake Mobius wrote: Virtual domains are a big concern to me..I may be brand new at this but I'm stuck with the task and I need an enterprise-size mail server. cpanel: http://www.cpanel.net/ is used for site config and mgmt plesk: server mgmt for web hosting. think webmin, but bigger. Hm, that seems like tools needed by/suited to ISPs. That's totally different from what I need. I think my greatest hate of exim-config thus far has actually been my lack of experience with DEBCONF, and thus all the debconf replacements in the otherwise easy to read config. yeah It should also be noted that the multi-file config is more like The Debian Way tm As you can see with apache, includes of directories of files is easier for dropping in a new section and version managing an existing config. I do this also! Yes, such a way to configure things has great advantages when you want to do things automatically. The problem is that automatical things tend not to be suited that much for human intervention, so it becomes difficult to find a way allowing for both, manual configuration and automated. The automated configuration introduces additional learning overhead when humans want to interfere --- and be it just to get what they want --- and exim-config is a nice example of the problems arising from that. But still, when questions come up like 'How do I configure a mail server/my mail to have virus scanning and SPAM checking?', they are probably not being asked by ISPs who need flexibility but by users/admins who just want what they ask for and who will (want to) end up with a static and reliable setup for their mail system. The autoconfig is imho not suited for that. Maybe it will include options to set these things up at a later stage, but that will still leave users alone in case something fails. That is what Windoze does, except that it leaves them alone long before ... If they know what they do, they are able to help themselfes :) GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Honesty about some exim mistakes
On Tue, 2006-03-28 at 17:24 +0200, listrcv wrote: Drake Mobius wrote: Virtual domains are a big concern to me..I may be brand new at this but I'm stuck with the task and I need an enterprise-size mail server. cpanel: http://www.cpanel.net/ is used for site config and mgmt plesk: server mgmt for web hosting. think webmin, but bigger. Hm, that seems like tools needed by/suited to ISPs. That's totally different from what I need. Yes, think large multi-domain e-mail/webserving/PHP-Perl-Python-CGI/postgresql-mysql setups. Each of the ones I am hosting each get what they want, when they want it. All through a web-interface that I have made so that they can request a feature not currently available. Their config is also manually editable, but verified when they commit it. If it fails, they get an error back telling them what failed. And suggesting they use the check boxes. Here is just a few options I am supporting currently available: * Full POP3, POP3S, IMAP, IMAPS service, (all, any or none) * Inline Spam-Assassin, with Pyzor, Razor, RulesDuJour and others, optional. Can be either receive(incoming) and/or sending(outgoing) or both or not at all. * ACLs per Virtual Domain, Aliases, Mailforwarding, server side mail sorting (procmail or maildrop) * Inline ClamAV Virus Scanning, with rejection based on either defaults or customized rules, or allowing the files through but being flagged as infected. * Full Apache2 configs, (with tons of available modules) with manual editing available and syntax checking on commit with feedback as to which one is bad. (so as to not blow-up apache) * PHP, Perl, Python capability with or with out a DB connection, with manual editing and syntax checking on commit (so as to not blow-up apache) * Tomcat 5.5, JBOSS and other a application serving. * Three different blog systems (all, any or none) * Database usage, BSDdb, MySQL and PostgresQL. Other DBs are allowed, but additional charges are required (much additional in some cases) * DNS with Bind using a templating system. Supporting any record types. Of course linted before commit, serials automagically updated. * Virtual Machines, varying size using products available. * Build Environments (chroot'd or not) for those that would rather pay for CPU used rather than always having it available on site. I don't do Windows, unless my Lively-hood depends on it, which it doesn't anymore. I think my greatest hate of exim-config thus far has actually been my lack of experience with DEBCONF, and thus all the debconf replacements in the otherwise easy to read config. yeah Its just a fact of understand the way Marc, Andreas and others have used what is available from Debconf. They have followed the rules. If you see the beauty of the seperate files for what it is intended to do, its like magically everything comes into view. I use it so I don't have to worry about multiple access to hyarge config file. I can manipulate each file (based on a naming scheme and service level) without worry if those changes would get on multiple simultaneous commits, where last one to write wins. It should also be noted that the multi-file config is more like The Debian Way tm As you can see with apache, includes of directories of files is easier for dropping in a new section and version managing an existing config. I do this also! Yes, such a way to configure things has great advantages when you want to do things automatically. Not really, I use it so that all changes are captured and not over-written by multiple accesses and writes can occur. The problem is that automatical things tend not to be suited that much for human intervention, so it becomes difficult to find a way allowing for both, manual configuration and automated. The automated configuration introduces additional learning overhead when humans want to interfere --- and be it just to get what they want --- and exim-config is a nice example of the problems arising from that. Well, I guess you have a point, but if you make an attempt understand why Debian really chooses to do this like this it makes a ton of sense, when you look at thing from an Easily adding and removing components, without screwing everything else up point of view. IOW, I can add and delete domains just by dropping files in or removing them in the the router and transport directories, Changing (adding or removing or editing) ACLs for those domains by dropping files or removing files in the acl directory makes it possible to allow config for every single Virtual Domain seperately. Also, allows me to find and fix individual domain problems (should they arise) and fix them plus add in the syntax for checking that problem for the system. Sort of like what Jalopy does for CVS. But still, when
Re: Honesty about some exim mistakes
Drake Mobius wrote: Now I've got my mail server running, and all it took was an hour and a half of complete idiocy and associated frustation! Yeah, the automagical configuration of Exim4 is a horrible mess! You have no chance to get a clue what's actually configured and what not. Just ignore exim-config, copy over the example config from the docs directory, adapt it to your needs and make Exim use it. 15 minutes of fun, and you got it running. GH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Honesty about some exim mistakes
Nah, I just used apt-get remove --purge then reinstalled and it allowed me to reconfigure properly. In fact I'm only using this address because gmail is SO good at dealing with lists. On 3/27/06, listrcv [EMAIL PROTECTED] wrote: Drake Mobius wrote: Now I've got my mail server running, and all it took was an hour and a half of complete idiocy and associated frustation!Yeah, the automagical configuration of Exim4 is a horrible mess! You have no chance to get a clue what's actually configured and what not.Just ignore exim-config, copy over the example config from the docsdirectory, adapt it to your needs and make Exim use it. 15 minutes of fun, and you got it running.GH
