Fedora Linux Support Community & Resources Center
  #16  
Old 5th May 2012, 03:50 AM
stevea Offline
Registered User
 
Join Date: Apr 2006
Location: Ohio, USA
Posts: 8,816
linuxfirefox
Re: Setup a Mail server

Quote:
Originally Posted by jpollard View Post
You evidently have not done much application generation
Did it for a living sweet-cheeks. Try revising autoconf file for cross compiles sometime if you want to see what is wrong with this approach.

Quote:
autoconf does exactly that - it is a preprocessor that generates C header files (frequently, not always) for compilation. No difference. Oh, and it uses m4 as well.

But if you want complexity... try modifying a medium sized autoconf file... the macros expanded can be a real mess.
A/ NO it is not "exactly that", your failure to read accurately is legend. I said you have to tweak a bale of C - but that's different than tweaking a massive autoconf file.
B/ I am fully aware autoconf - much earlier there were packages configured to use snobol (yes really). Both are bad approaches by design.
C/ You are making MY case - these sorts of config approaches are brain-dead - too complex and arcane.

No - I DON'T want to modify your hypothetical "medium sized autoconf file" - I've done it 50 times in the past and it's a nightmare. One always expect you are breaking the pkg on some other architecture. The complexity and lack of consistency is the problem - it requires a very different framework if you want to build the same package on an ancient BSD to Solaris to a recent Linux. But to be fair, your example (autoconf) addresses a very different problem then the one on this thread. We are talking about configuring app(sendmail) features NOT configuring the app-build for the environment - two very different things - but thanks for the red-herring fallacy and digression.

Maybe you lost your way in this discussion - my point is that all these "too complex for mortals" approaches to app config are stupid. So your off-topic examples of autoconf are not relevant.



Quote:
Haskell may be clearer, but it is much less portable, and less available. You would do better to use python.
WOW - could you be be any dumber ? I can no longer make excuses for inability to read. I never literally suggested Haskell. I said the a language/macro approach is dumb (like M4) . That IF you had a gun to my head I would choose a "a functional language like haskell" where the declarative non-procedural description has good properties.. Note "like haskell" does NOT mean "Haskell" literally.

Since you seem ignorant on the topic - and have clearly missed my point let me expand. Including ANY common language (M4, C, Snobol) into the app (not environment) config is stupid and wrongheaded. These aren't designed for the purpose and have a lot of obvious flaws when used for this sort of application. Lisp, Haskell, APL and 'make' are functional languages - and I DO NOT suggest any of these be used directly. I DO SUGGEST that IF simple declaration of constants is insufficient (rare and unlikely)- then some functional-language approach be applied. That is it should have a syntax to define rule - not a way to write procedures.

Quote:
But note - your configuration tool is now treating python as a macro preprocessor....
No - I clearly said "None of the above" to macros and other languages, yet you constantly try to insert my ideas into your ill-conceived viewpoint.

Quote:
And it doesn't matter if that configuration tool is GUI based or not. And it gets more complicated on each round, because now you also have to maintain your application configuration tool in addition to maintaining the application.
And you believe that's been a real show-stopper for the Linux kernel and buildtools and crosstools-ng and .... ? LOL, No -the GUI is no cure-all but it can help manage complexity. It does NOT have to be a support-sink.


Quote:
The only advantage m4 really has is that it is nonspecific. It is a small program that doesn't require the application developer to maintain.
And the main disadvantage is that the language syntax and the config design stink like a dirty hippie from the same era
Code:
# strip group: syntax (not inside angle brackets!) and trailing semicolon
R$*                     $: $1 <@>                       mark addresses
R$* < $* > $* <@>       $: $1 < $2 > $3                 unmark <addr>
R@ $* <@>               $: @ $1                         unmark @host:...
R$* [ IPv6 : $+ ] <@>   $: $1 [ IPv6 : $2 ]             unmark IPv6 addr
R$* :: $* <@>           $: $1 :: $2                     unmark node::addr
R:include: $* <@>       $: :include: $1                 unmark :include:...
R$* : $* [ $* ]         $: $1 : $2 [ $3 ] <@>           remark if leading colon
R$* : $* <@>            $: $2                           strip colon if marked
R$* <@>                 $: $1                           unmark
R$* ;                      $1                           strip trailing semi
R$* < $+ :; > $*        $@ $2 :; <@>                    catch <list:;>
R$* < $* ; >               $1 < $2 >                    bogus bracketed semi
utter cr*p, but then .....
Code:
# handle virtual users
R$+                     $: <!> $1               Mark for lookup
R<!> $+ < @ $={VirtHost} . >    $: < $(virtuser $1 @ $2 $@ $1 $: @ $) > $1 < @ $2 . >
R<!> $+ < @ $=w . >     $: < $(virtuser $1 @ $2 $@ $1 $: @ $) > $1 < @ $2 . >
R<@> $+ + $+ < @ $* . >
                        $: < $(virtuser $1 + + @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $* < @ $* . >
                        $: < $(virtuser $1 + * @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $* < @ $* . >
                        $: < $(virtuser $1 @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $+ < @ $+ . > $: < $(virtuser + + @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $* < @ $+ . > $: < $(virtuser + * @ $3 $@ $1 $@ $2 $@ +$2 $: @ $) > $1 + $2 < @ $3 . >
R<@> $+ + $* < @ $+ . > $: < $(virtuser @ $3 $@ $1 $@ $2 $@ +$2 $: ! $) > $1 + $2 < @ $3 . >
R<@> $+ < @ $+ . >      $: < $(virtuser @ $2 $@ $1 $: @ $) > $1 < @ $2 . >
R<@> $+                 $: $1
R<!> $+                 $: $1
R< error : $-.$-.$- : $+ > $*   $#error $@ $1.$2.$3 $: $4
R< error : $- $+ > $*   $#error $@ $(dequote $1 $) $: $2
R< $+ > $+ < @ $+ >     $: $>Recurse $1
Anyone sane should recognize the above as a strong reason to avoid using M4 - ever.


Quote:
The sendmail m4 macros encapsulate the rules for features. Most of them are of the "uncomment if you want the feature" variety, with a few "set the value if you want". One of the reasons for the macros is that optional features can affect other features so that they can be implemented properly.
Then we agree that the design is not disjoint, has side-effects - therefore bad. Lack of side-effects is why Haskell-like declarations are a good idea IF they are even needed for an MTA config(unlikely).
__________________
None are more hopelessly enslaved than those who falsely believe they are free.
Johann Wolfgang von Goethe

Last edited by stevea; 5th May 2012 at 03:54 AM.
Reply With Quote
  #17  
Old 5th May 2012, 04:36 AM
jpollard Online
Registered User
 
Join Date: Aug 2009
Location: Waldorf, Maryland
Posts: 6,831
linuxfirefox
Re: Setup a Mail server

You still ignore the goal of the rules.

You are not required to read them, unless you are developing a new extension.

that would be like reading and configuring a Java system by modifying the bytecodes.

And in the kernel case, it IS a support-sink. That is why there was such a rejection of several configuration tools that should have made things better... Now, they have to maintain something like 4 configuration environments, depending on things not related to the kernel, or the configuration tool(s).

Of course, if all else fails (as they can do when porting to a new environment) you can always edit the .config file manually, if you can identify all the options...

Just as you can with the sendmail configuration.

The final configuration CAN be modified directly. You are not supposed to do it, but most of the necessary options are well identified in the qf file. The message about not editing used to follow the parameter header... which end just before the "# Format of headers #" line. If the sendmail.mc file has additional features added, then their configuration options would/should show up in the first part of the file. Nowdays, the configuration has been simplified - and the sendmail.mc file is what you configure. And as you seem to want, a relatively simple configuration file that identifies the features desired, and options to set.

Personally, I would prefer a Perl based preprocessor just because the syntax would be more familiar. But m4 was available, and Perl was not.

Sucks - but try editing the details of postfix configurations... oh right-can't. You have to have a complete development environment to add to the rules, to then have a local fork of the application, and the extra support when patches are to be applied.

I have had to modify the sendmail config file before. Didn't like it, but it was necessary at the time.

No need to rebuild sendmail. Just select the features, and modify the one for local requirements. Yes, it was a bit of a pain, but no need for a local fork of the application.

The mc files are the source. M4 is the translator. The macros are the runtime. The sendmail application is the interpreter. Think of it that way and it is no worse than any other java application that has to be configured.

Your examples are nothing but extracts of part of the rules. And those rules really are recursive - they have to be. They are also the "bytecode" interpreted by the sendmail application.
Reply With Quote
  #18  
Old 5th May 2012, 05:14 AM
stevea Offline
Registered User
 
Join Date: Apr 2006
Location: Ohio, USA
Posts: 8,816
linuxfirefox
Re: Setup a Mail server

Quote:
Originally Posted by jpollard View Post
You still ignore the goal of the rules.

You are not required to read them, unless you are developing a new extension.
However is was necessary to read an understand them to comprehend what was going wrong - undebuggable mess. Design fail.


Quote:
that would be like reading and configuring a Java system by modifying the bytecodes.
No -= it wouldn't be like that at all. You analogies are comically wrong.


Quote:
And in the kernel case, it IS a support-sink. That is why there was such a rejection of several configuration tools that should have made things better... Now, they have to maintain something like 4 configuration environments, depending on things not related to the kernel, or the configuration tool(s).
You can't even make a coherent argument. You said a gui config too was a major support nightmare and impediment. You failed to show the kernel support effort was significant or in any way impede the project.

Quote:
Of course, if all else fails (as they can do when porting to a new environment) you can always edit the .config file manually, if you can identify all the options...
Which is one of several reasons why a UI tool makes this better.

Quote:
Just as you canmust with the sendmail configuration.
There is no current gui tool for sendmail AFAIK.

Quote:
The final configuration CAN be modified directly. You are not supposed to do it, but most of the necessary options are well identified in the qf file. The message about not editing used to follow the parameter header... which end just before the "# Format of headers #" line. If the sendmail.mc file has additional features added, then their configuration options would/should show up in the first part of the file. Nowdays, the configuration has been simplified - and the sendmail.mc file is what you configure. And as you seem to want, a relatively simple configuration file that identifies the features desired, and options to set.
Man - you are just heading deeper into the swamp. The config on sendmail is badly designed, too complex. So your solution is to edit the resulting files ? You may as well argue that revising the source-code is a good obvious method of configuring a service. No, no, no - the person doing the config must understand the issues and be willing to make decisions. The package config should have a clear and obvious way of implementing the admins decision.

Quote:
Personally, I would prefer a Perl based preprocessor just because the syntax would be more familiar. But m4 was available, and Perl was not.
So you still believe that you only ned a hammer since every problem looks like a nail to you ? You just prefer a different hammer ? The sendmail devs have had 3+ decades to revise the config or bolt a new front end on. That better config interface is not M4 and not perl. It needs to match the application.



Quote:
I have had to modify the sendmail config file before. Didn't like it, but it was necessary at the time.
And I and a friend had to understand in detail as part of a review long ago - it's junk.

Quote:
No need to rebuild sendmail. Just select the features, and modify the one for local requirements. Yes, it was a bit of a pain, but no need for a local fork of the application.

The mc files are the source. M4 is the translator. The macros are the runtime. The sendmail application is the interpreter. Think of it that way and it is no worse than any other java application that has to be configured.
It's very different ! Mc becomes a configuration language and there are zero debugging features to that language - so when the resulting config doesn't act as expected it's common to need to read and understand the macros. That's a garbage design.


I'm not a sendmail hater - it's a venerable old and strong tool, but the config-interface was designed by a herd of cats with diarrhea.
__________________
None are more hopelessly enslaved than those who falsely believe they are free.
Johann Wolfgang von Goethe

Last edited by stevea; 5th May 2012 at 05:21 AM.
Reply With Quote
  #19  
Old 5th May 2012, 07:35 AM
vsaua Offline
Registered User
 
Join Date: Aug 2009
Location: Ukraine, Kiev
Age: 32
Posts: 55
linuxfirefox
Re: Setup a Mail server

Hi! To very fast start look at the Fedora manual:

http://docs.fedoraproject.org/en-US/...l_Servers.html

Postfix is more simple to understand and configure than Sendmail.
Reply With Quote
Reply

Tags
mail, server, setup

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to setup mail server kyungmin002 Servers & Networking 2 10th August 2007 11:53 AM
Mail server - setup virtual mail boxes satimis Linux Chat 0 10th February 2007 04:00 PM
Web and/or Mail Server setup process when using a Windows Server 2003 for DNS and IP FarmBoy Servers & Networking 0 14th December 2006 05:48 PM
how to setup pop mail clietns for local mail server? shams Servers & Networking 7 19th July 2006 09:05 AM
Setup a Mail Server? pureFlamez Servers & Networking 12 28th October 2004 03:10 PM


Current GMT-time: 07:06 (Wednesday, 03-09-2014)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat