Re: Linuxconf

[Philip Hands]

"matthew.r.pavlovich.1" <[EMAIL PROTECTED]> wrote:
> what is the current status of linuxconf and debian?

I made a package up, which is currently in experimental because it breaks 
booting, and doesn't understand includes in /etc/named, among other things.

If people would like to have a look at it, with an eye to working out how 
we're going to get it to sit alongside all our normal stuff, I'd appreciate 
suggestions.

The problem is that it is too all encompassing, and wants to be in charge of 
things that it has no rights over on a Debian system.  For it to work well in 
a debian environment, much of it needs to be split into separate modules 
which depend upon the thing they configure.

For example, by default it assumes that you are running sendmail, and tries
to make sure that files that should be present if sendmail were installed,
are present and set to the right permissions.

I've disabled (some of) this in the Debian package, but really it needs to
be put in a linuxconf- sub-package.

There's loads of this sort of thing, and it's a little difficult to work out 
where to start, especially when it's not entirely clear what the original 
intent was, not being a RedHat user.

I could do with someone who knows how the RedHat init scripts work to tell
me what the original intent behind some of the boot menu setup is, so that
we can look at translating it into something worthwhile under debian.

Anyone that's interested, and has a machine they don't mind trashing just a 
little, feel free to grab a copy and see if you can work out what we need to 
do with it.

Remember though, there's a reason its in project/experimental.

Cheers, Phil.

Re: Linuxconf

[Rob Browning]

Raul Miller <[EMAIL PROTECTED]> writes:

> But you can do a lot with a decent parser.

But what do you do about config files that are just perl, or python,
or elisp?  There's no way you can write a parser that can predict what
the code in the file will do in the general case, and we can't really
mandate what upstream developers do just to accomodate our choice of
configuration engine.

Also, does linuxconf handle nested syntaxes like lisp or html, or just
key/value pairs?

Using a tagged template scheme like Craig proposed wouldn't completely
solve the problem either, but it might make it a lot more
straightforward to handle most of the cases.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Jaakko Niemi]

>> From [EMAIL PROTECTED]  Wed Jun  3 18:19:21 1998
>> Resent-Date: 2 Jun 1998 17:03:22 -
>> Resent-Cc: recipient list not shown: ;
>> X-Envelope-Sender: [EMAIL PROTECTED]
>> Date: Tue, 2 Jun 1998 19:34:11 +0300 (IDT)
>> X-Sender: [EMAIL PROTECTED]
>> X-Mailer: Windows Eudora Pro Version 2.1.2
>> Mime-Version: 1.0
>> Content-Type: text/plain; charset="us-ascii"
>> To: Craig Sanders <[EMAIL PROTECTED]>, Jules Bean <[EMAIL PROTECTED]>
>> From: Shaya Potter <[EMAIL PROTECTED]>
>> Subject: Re: Linuxconf
>> Cc: Raul Miller <[EMAIL PROTECTED]>, David Engel <[EMAIL PROTECTED]>,
>> John Goerzen <[EMAIL PROTECTED]>, debian-devel@lists.debian.org,
>> "Rev. Joseph Carter" <[EMAIL PROTECTED]>
>> Resent-Message-ID: <"Pvu8dC.A.zgG.aBDd1"@murphy>
>> Resent-From: debian-devel@lists.debian.org
>> X-Mailing-List:  archive/latest/5816
>> X-Loop: debian-devel@lists.debian.org
>> Precedence: list
>> Resent-Sender: [EMAIL PROTECTED]
>> 
>> At 12:36 AM 6/3/98 +1000, Craig Sanders wrote:
>> >On Tue, 2 Jun 1998, Jules Bean wrote:
>> >
>> >> Of course it's viable.  It just becomes a package maintainer
>> >> responsibility.  In the vast majority of cases, the package maintainer
>> >> ought to be able to use the *same code* as the package itself for
>> >> parsing config files.
>> >>
>> >> In many well factored cases, this will be as simple as extracting
>> >> config.c or some similarly named file from the distribution and making
>> >> a few changes to it.
>> >
>> >no, it's not that simple.
>> >
>> >it needs to read and parse the config file, allow the user to manipulate
>> >it, and then write it back out again (if the user chooses to save any
>> >changes) WITHOUT losing any information, including comments and the
>> >order of the comments.
>> >
>> 
>> I believe linuxconf will error out if it can't parse the config file.
>> 
>> Craig, would you be happy if there was a built in exception handeling
>> mechanism into linuxconf that would give a nice error when linuxconf
>> couldn't parse a file.

 Or better: it would prompt the adminster that is this what you want (y/n/edit 
with vi or emacs 
 or the built-in editor :)) ?

--j




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Tools the Parse config files (was Re: Linuxconf)

[Martin Schulze]

On Tue, Jun 02, 1998 at 02:52:50PM +0300, Shaya Potter wrote:

> For the fact that we would need to write a parser for all our conf files. I
> think that might be overkill, as many of our conf files are probably just
> some files with a variable or two.  i.e. the structure of the config file is
> constant just with a change in the "variables".  It shouldn't be too hard to
> set up a example linuxconf module that shows how to set up a simple form
> that accepts input and place them into the proper slots in a model config
> file.  This example module could be easily modfiable for all the appropriate
> uses.  Other things are obviously more complicated, but that might knock off
> a big chunk of our conf files.

Actually there's another pov.  Back in Cologne Winni Truemper described his
view of configuration files - as tables, tables with certain delimitors and
certain formats and tables within tables.  How does one process tables
nowardays?  Right: Use some SQL for accessing and modifying it.  Ok, it
needs some definitions first, but mainly you don't have to write a parser
for everything but define it generally.  We'll see if and how this is
practical.

Regards,

Joey

-- 
  / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
 / http://home.pages.de/~joey/
/  VFS: no free i-nodes, contact Linus  -- finlandia, Feb '94   /


pgpyAlOTLDrJS.pgp
Description: PGP signature

Re: Linuxconf not losing info.

[Martin Alonso Soto Jacome]

Craig Sanders <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Jun 1998, Shaya Potter wrote:

> > I believe linuxconf will version every change that it makes, i.e. if you
> > make changes w/ linuxconf and see that it didn't work, you can go back to
> > your previous configuration or any one of many previous configurations, this
> > will probably work if you edited it outside of linuxconf, you then edited
> > the file manually, and then went into linuxconf, somehow or another
> > linuxconf messed up the file (though when I was playing with it last year,
> > it couldn't grok our dns setup, and just complained, didn't mess with it),
> > you should theoreticly be able to go back to the version you modified by
> > hand, because linuxconf should have saved it before modifying the file.
> 
> good.  i like the sound of that.

Yes, I like it too.  I've always think that versioning would really
improve dpkg's handling of config files.  I've always dreamt about
dpkg merging original package config files with local ones using
common ancestor merge.  Or running one of those nice file mergers
instead of asking you to press some key to leave dpkg and fix the
situation by hand.  That would be really neat, I'm sure...

> does it use RCS or similar to store the previous versions? if not, how
> hard would it be to make it do so?

>From what I heard in the Linuxconf mailing list some time ago (I'm not
subscribed these days) it thing yes, it uses RCS.  It seems to me it
is able of doing things as nice as letting you keep many different
sets of config files for different purposes, and change between them
on the fly with automatic activation and deactivation of the affected
daemons.  Way cool.

Regards,

M. S.




Martin A. Soto J.   Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes  [EMAIL PROTECTED]



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf not losing info.

[Craig Sanders]

On Wed, 3 Jun 1998, Shaya Potter wrote:

> > does it use RCS or similar to store the previous versions? if not,
> > how hard would it be to make it do so?
>
> don't know, as it's been a year since I've played with it on debian.
> However, that was one of the big things I requested, and from reading
> the linuxconf web pages, it seems he has added it, though I'm not
> sure how it does it.  Why RCS? if it uses it's own system of just
> versioning the files, wouldn't that be good enough as well?

if it works, then yeah it's fine.

however, why re-invent a perfectly good wheel which happens to have lots
of compatible utilities?  e.g. various diff utils like rcsdiff and tkdiff. 

i prefer incremental, evolutionary growth built upon existing tools. 
sometimes (rarely) you have to throw out the old stuff and start afresh,
but usually not.

it's unfortunately very common for wheels to be re-invented simply because
people don't know that they already exist or how to use them, or it never
occurs to them that a tool which is well-known for one particular use
(e.g. make) is also very useful for another (e.g.  building and managing
config files instead of compiling programs) 


craig

--
craig sanders


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Tools the Parse config files (was Re: Linuxconf)

[Rev. Joseph Carter]

On Wed, Jun 03, 1998 at 07:43:22AM +0300, Shaya Potter wrote:
> > Shaya> Also, linuxconf shouldn't be used to configure a user's
> > Shaya> personal information, such as .bashrc, .pinerc, those should
> > Shaya> be left to either the program itself like in pine, or to a
> > Shaya> package like the dotfile generator for a program like bash or
> > Shaya> procmail.
> >
> > Why not use linuxconf? I am not contradicting you, just asking
> > for clarification.
> 
> I don't feel Linuxconf is suited for that.  It's just my gut feeling, it
> could probably be extended to do it, but it seems to me like it would be
> good if there was a seperation b/w the program the configures the system,
> and the program that configures the user. Not technicall reasons, just looks.

This doesn't mean that user config can't be done with the same kinda
interface.  liblinuxconf, anyone?


pgpR29FrDyoCP.pgp
Description: PGP signature

Re: Linuxconf not losing info.

[Shaya Potter]

At 10:44 AM 6/3/98 +1000, Craig Sanders wrote:
>On Tue, 2 Jun 1998, Shaya Potter wrote:
>
>> Sorry for not responding directly, I only get debian-devel-digest, so I can
>> only respond to what I catch.
>> 
>> I believe linuxconf will version every change that it makes, i.e. if you
>> make changes w/ linuxconf and see that it didn't work, you can go back to
>> your previous configuration or any one of many previous configurations, this
>> will probably work if you edited it outside of linuxconf, you then edited
>> the file manually, and then went into linuxconf, somehow or another
>> linuxconf messed up the file (though when I was playing with it last year,
>> it couldn't grok our dns setup, and just complained, didn't mess with it),
>> you should theoreticly be able to go back to the version you modified by
>> hand, because linuxconf should have saved it before modifying the file.
>
>good.  i like the sound of that.
>
>does it use RCS or similar to store the previous versions? if not, how
>hard would it be to make it do so?

don't know, as it's been a year since I've played with it on debian.
However, that was one of the big things I requested, and from reading the
linuxconf web pages, it seems he has added it, though I'm not sure how it
does it.  Why RCS? if it uses it's own system of just versioning the files,
wouldn't that be good enough as well?

Shaya


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Tools the Parse config files (was Re: Linuxconf)

[Shaya Potter]

At 12:46 PM 6/2/98 -0500, Manoj Srivastava wrote:
>Hi,
>>>"Shaya" == Shaya Potter <[EMAIL PROTECTED]> writes:
>
> Shaya> Also, linuxconf shouldn't be used to configure a user's
> Shaya> personal information, such as .bashrc, .pinerc, those should
> Shaya> be left to either the program itself like in pine, or to a
> Shaya> package like the dotfile generator for a program like bash or
> Shaya> procmail.
>
>   Why not use linuxconf? I am not contradicting you, just asking
> for clarification.

I don't feel Linuxconf is suited for that.  It's just my gut feeling, it
could probably be extended to do it, but it seems to me like it would be
good if there was a seperation b/w the program the configures the system,
and the program that configures the user. Not technicall reasons, just looks.

Shaya


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Craig Sanders]

On Tue, 2 Jun 1998, Joel Klecker wrote:

> At 07:40 -0700 1998-06-02, Craig Sanders wrote:
> > BTW, the fact that you don't understand sendmail doesn't prevent
> > others from doing so. sendmail really isn't that difficult, and is
> > simpler in some ways because you don't have multiple config files
> > scattered across multiple directories.
>
> FUD, exim also uses only one configuration file.
>
> I'm sure I could understand sendmail if necessary, but I have the
> luxury of not needing to, and since I don't want to, I don't have to.

i may be confusing exim's config with smail.  when i (very briefly) looked
at it last year, it seemed to be "smail done right".  i don't like smail
(even when it is done right) so gave up on it after a few days.

i also looked at zmailer.  now that definitely has zillions of config files
scattered over zillions of directories.  ok, "zillions" is a slight
exaggeration, but not by much :-).  looked to have some nice ideas, but not
my cup of tea.



qmail was the only "alternative" mailer i looked at that i actually
liked.  It's the only one i would even consider as a replacement for
sendmail.  I'd be running it now except for two things:  1. the license,
2. the Qmail Attitude Problem (QAP).

Actually, there are two QAPs.  The first is the unbearable and
unjustifiable defensive arrogance on the part of the author and certain
over-zealous users.

The second is the attitude that "your legacy systems are a crock of
shit, throw it all out and do it the Qmail Way"e.g.
getting majordomo to work with it is a major pain in the arse - and
the fact that ezmlm exists is irrelevant if i've got 83 users with 83
different majordomo lists which they have been running for years.  

Right now, all but one of my systems is running sendmail.  I have one
box running qmail (being used as an outbound relay...my main sendmail
box at works relays all non-local mail via the qmail box to take
advantage of qmail's faster queueing and delivery).



i'm waiting for vmail to come out of vapourwarethen i'll check that
out too. it *sounds* good.



craig

--
craig sanders


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf not losing info.

[Craig Sanders]

On Tue, 2 Jun 1998, Shaya Potter wrote:

> Sorry for not responding directly, I only get debian-devel-digest, so I can
> only respond to what I catch.
> 
> I believe linuxconf will version every change that it makes, i.e. if you
> make changes w/ linuxconf and see that it didn't work, you can go back to
> your previous configuration or any one of many previous configurations, this
> will probably work if you edited it outside of linuxconf, you then edited
> the file manually, and then went into linuxconf, somehow or another
> linuxconf messed up the file (though when I was playing with it last year,
> it couldn't grok our dns setup, and just complained, didn't mess with it),
> you should theoreticly be able to go back to the version you modified by
> hand, because linuxconf should have saved it before modifying the file.

good.  i like the sound of that.

does it use RCS or similar to store the previous versions? if not, how
hard would it be to make it do so?

craig

--
craig sanders


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Joel Klecker]

At 07:40 -0700 1998-06-02, Craig Sanders wrote:
>BTW, the fact that you don't understand sendmail doesn't prevent others
>from doing so. sendmail really isn't that difficult, and is simpler in
>some ways because you don't have multiple config files scattered across
>multiple directories.

FUD, exim also uses only one configuration file.

I'm sure I could understand sendmail if necessary, but I have the luxury of
not needing to, and since I don't want to, I don't have to.
--
Joel "Espy" Klecker
Debian GNU/Linux Developer




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Rev. Joseph Carter]

On Tue, Jun 02, 1998 at 12:32:53PM -0500, Manoj Srivastava wrote:
>  Jules> The solution is to switch to a better designed mailer (exim
>  Jules> springs to mind) with easier to manage configuration.
> 
>   This seems to imply that linuxconfig should drop support for
>  sendmail (which still is an industry standard smtp daemon) in favour
>  of simpler to configure replacements. I guess we can live with that. 
> 
>   Of course, switching MTA's involves other decision parameter
>  than a simplistic pointy clickey configuration, but I shall not go
>  into that.

Linuxconf does use modules for everything.  It would be as simple as NOT
using the sendmail module and instead using an exim module.  Not a big issue
here.


pgpO78AiuSOlG.pgp
Description: PGP signature

Re: Tools the Parse config files (was Re: Linuxconf)

[Rev. Joseph Carter]

On Tue, Jun 02, 1998 at 12:46:02PM -0500, Manoj Srivastava wrote:
>  Shaya> Also, linuxconf shouldn't be used to configure a user's
>  Shaya> personal information, such as .bashrc, .pinerc, those should
>  Shaya> be left to either the program itself like in pine, or to a
>  Shaya> package like the dotfile generator for a program like bash or
>  Shaya> procmail.
> 
>   Why not use linuxconf? I am not contradicting you, just asking
>  for clarification.

Mostly because Linuxconf is not designed for the task.  Perhaps it could be
made to work with a module based on the dotfile generator, but that's not
how it works NOW..


pgpjgpC9K9E3Q.pgp
Description: PGP signature

Re: Linuxconf

[Raul Miller]

Craig Sanders <[EMAIL PROTECTED]> wrote:
> BTW, the fact that you don't understand sendmail doesn't prevent others
> from doing so.

The problem with sendmail isn't that it's difficult to understand, it's
that it rewrites headers, by default.  This introduces a whole class of
rather subtle bugs that later become support issues.

-- 
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Rev. Joseph Carter]

On Tue, Jun 02, 1998 at 03:59:22PM +0100, Jules Bean wrote:
> > yes, that's a perfect solution.for those who choose to use exim.  it
> > does absolutely nothing at all for those who prefer to use sendmail.
> 
> True.  But I was answering the suggestion (chopped, unfortunately, which
> was foolish of me) that a user-friendly front-end to sendmail would solve
> one of Linux's (and Debian's in particular) PR problems.   I was simply
> pointing out that if simple mail configuration *in particular* is a goal,
> then sendmail may not be the best MTA.  I certainly would support efforts
> for a sendmail.cf configuration utility.

You misunderstood then.  With all the toys in sendmail, it could be a PR
boost, IF people could configure these toys easily.  sendmailconfig doesn't
do too well with that at the moment.


pgpXpmPd5AWk4.pgp
Description: PGP signature

Re: Tools the Parse config files (was Re: Linuxconf)

[Manoj Srivastava]

Hi,
>>"Shaya" == Shaya Potter <[EMAIL PROTECTED]> writes:

 Shaya> Also, linuxconf shouldn't be used to configure a user's
 Shaya> personal information, such as .bashrc, .pinerc, those should
 Shaya> be left to either the program itself like in pine, or to a
 Shaya> package like the dotfile generator for a program like bash or
 Shaya> procmail.

Why not use linuxconf? I am not contradicting you, just asking
 for clarification.

manoj
-- 
 "These patriots don't mince words... Okay, sure, they *are*
 dangerous, hopelessly ignorant, inbred, retarded borderline lunatics
 with an insatiable lust for the blood of sinners -- but at least
 they're *honest* about it." Reverend Ivan Stang, cofounder of the
 Church of the Subgenius, about a group known as Free Love Ministries,
 in his book _High Weirdness By Mail_
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Jules Bean]

On 2 Jun 1998, Manoj Srivastava wrote:

> Hi,
> >>"Jules" == Jules Bean <[EMAIL PROTECTED]> writes:
> 
>  Jules> This sounds foolish to me.
> 
>   Hmm, provocative words.
> 
>  Jules> The solution is to switch to a better designed mailer (exim
>  Jules> springs to mind) with easier to manage configuration.
> 
>   This seems to imply that linuxconfig should drop support for
>  sendmail (which still is an industry standard smtp daemon) in favour
>  of simpler to configure replacements. I guess we can live with that. 

*grin*

provocative, apparently.

That's the second time I've been misunderstood, so I'll explain..

The initial post was suggesting (I'm sorry, I don't have the exact words)
that somehow a linuxconf front-end was the correct solution to the fact
that Linux email is hard to manage because sendmail.cf is hard to
configure.  I was suggesting that the correct answer to *that* problem was
to change MTAs.

To summarise *my* opinion:

1) I don't think we should stop supporting sendmail.

2) I don't think we should discourage a linux-conf front-end to sendmail.

3) I do, however, both personally and professionally recommend exim over
sendmail for work involving many email addresses at many domains.  

4) I do recognise that not everyone will agree ;-)

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Manoj Srivastava]

Hi,
>>"Jules" == Jules Bean <[EMAIL PROTECTED]> writes:

 Jules> This sounds foolish to me.

Hmm, provocative words.

 Jules> The solution is to switch to a better designed mailer (exim
 Jules> springs to mind) with easier to manage configuration.

This seems to imply that linuxconfig should drop support for
 sendmail (which still is an industry standard smtp daemon) in favour
 of simpler to configure replacements. I guess we can live with that. 

Of course, switching MTA's involves other decision parameter
 than a simplistic pointy clickey configuration, but I shall not go
 into that.

manoj
-- 
 To be is to program. Calvin Keegan
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Shaya Potter]

At 12:36 AM 6/3/98 +1000, Craig Sanders wrote:
>On Tue, 2 Jun 1998, Jules Bean wrote:
>
>> Of course it's viable.  It just becomes a package maintainer
>> responsibility.  In the vast majority of cases, the package maintainer
>> ought to be able to use the *same code* as the package itself for
>> parsing config files.
>>
>> In many well factored cases, this will be as simple as extracting
>> config.c or some similarly named file from the distribution and making
>> a few changes to it.
>
>no, it's not that simple.
>
>it needs to read and parse the config file, allow the user to manipulate
>it, and then write it back out again (if the user chooses to save any
>changes) WITHOUT losing any information, including comments and the
>order of the comments.
>

I believe linuxconf will error out if it can't parse the config file.

Craig, would you be happy if there was a built in exception handeling
mechanism into linuxconf that would give a nice error when linuxconf
couldn't parse a file.

Shaya


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Jules Bean]

On Wed, 3 Jun 1998, Craig Sanders wrote:

> On Tue, 2 Jun 1998, Jules Bean wrote:
> 
> > > The solution of course is to extend the m4 stuff to support all the
> > > things linuxconf does, but that's not so easy.  Also, note that
> > > slackware didn't at last look have m4 sendmailconfig.  Another
> > > example of where slackware is doing more harm than good these days
> > > by not adopting things the rest of the world has... =p
> >
> > This sounds foolish to me.
> >
> > The solution is to switch to a better designed mailer (exim springs to
> > mind) with easier to manage configuration.
> 
> yes, that's a perfect solution.for those who choose to use exim.  it
> does absolutely nothing at all for those who prefer to use sendmail.
> 

True.  But I was answering the suggestion (chopped, unfortunately, which
was foolish of me) that a user-friendly front-end to sendmail would solve
one of Linux's (and Debian's in particular) PR problems.   I was simply
pointing out that if simple mail configuration *in particular* is a goal,
then sendmail may not be the best MTA.  I certainly would support efforts
for a sendmail.cf configuration utility.

> 
> BTW, the fact that you don't understand sendmail doesn't prevent others
> from doing so. sendmail really isn't that difficult, and is simpler in
> some ways because you don't have multiple config files scattered across
> multiple directories.
> 

Thanks for the advice.  Actually, I understand sendmail very well indeed,
and it is on the basis of that understanding that I suggest exim is an
improvement.

My expertise, I confess, is limited to the use of an MTA as a delivery
agent for an organisation catering for a very large number of domains, and
I have no experience with setting up an MTA in a single-user, dynamic IP
situation (although my instincts suggest that sendmail is not entirely
appropriate in this case either).  

> sendmail.mc and the sendmailconfig script are mind-bogglingly simple to
> use, and will get a working configuration for 99% of cases in a minute
> or two.

As far as I am aware, the 'out-of-the-box' exim configuration works.  It
did for me.  I didn't have to configure it at all initially - I have now
done so, to support some other domains, and I'm impressed by the clear and
simple design.

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Craig Sanders]

On Tue, 2 Jun 1998, Rev. Joseph Carter wrote:

> > RE: sendmail.cf
> > 
> > IMO, linuxconf should manage sendmail.mc rather than sendmail.cf. 
> 
> That would be more reasonable, however not all that sendmail can do is
> supported with the m4 rules and such.  Not at the moment at least.

anything you can do in sendmail.cf can also be done in sendmail.mc. you
can put any sendmail rulesets you like in the m4 file.

sendmail.mc is actually a very good example of a template-style
configuration tool.  it greatly increases the ease-of-use, WITHOUT losing
*any* of the flexibility and power of the previous "arcane" way of
configuring sendmail.


> Sendmail is their selling point because of how complex it is, how
> little m4 helps and how much they can do with it.  The motivation for
> the project is that sendmail if easy to configure could sell linux and
> the opensource paradigm to a few people.  This is good.

but sendmail is already trivial to configure using the m4 macros, for
nearly all common setups.

the only time you need to hack sendmail rulesets manually is when you're
doing something truly weird / non-standard with sendmail.  The m4 macros
cover just about any configuration requirement you could think of.

> The solution of course is to extend the m4 stuff to support all the
> things linuxconf does, but that's not so easy.

no, the solution would be to make linuxconf a front-end for the m4 stuff
rather than mess with sendmail.cf directly.

whoever wrote the sendmail module for linuxconf should take a good look
at debian's sendmailconfig script and see what can be done using just
a shell script. it asks a dozen or so simple questions and uses the
answers (with sensible defaults) to build a sendmail.mc file, which is
then piped into m4 to produce sendmail.cf.


> Also, note that slackware didn't at last look have m4 sendmailconfig.
> Another example of where slackware is doing more harm than good these
> days by not adopting things the rest of the world has... =p

IMO, slackware doesn't matterit's a zombie OS (dead as a dodo, but
just doesn't realise it yet).


craig

--
craig sanders

Re: Linuxconf

[Craig Sanders]

On Tue, 2 Jun 1998, Jules Bean wrote:

> > The solution of course is to extend the m4 stuff to support all the
> > things linuxconf does, but that's not so easy.  Also, note that
> > slackware didn't at last look have m4 sendmailconfig.  Another
> > example of where slackware is doing more harm than good these days
> > by not adopting things the rest of the world has... =p
>
> This sounds foolish to me.
>
> The solution is to switch to a better designed mailer (exim springs to
> mind) with easier to manage configuration.

yes, that's a perfect solution.for those who choose to use exim.  it
does absolutely nothing at all for those who prefer to use sendmail.


BTW, the fact that you don't understand sendmail doesn't prevent others
from doing so. sendmail really isn't that difficult, and is simpler in
some ways because you don't have multiple config files scattered across
multiple directories.

sendmail.mc and the sendmailconfig script are mind-bogglingly simple to
use, and will get a working configuration for 99% of cases in a minute
or two.


craig


--
craig sanders


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Craig Sanders]

On Tue, 2 Jun 1998, Jules Bean wrote:

> >> So support the full grammar of the file.
> > 
> > debian currently has 1956 packages. most of them require a config file.
> > do you think having that many individual parsers is viable?
> 
> Ooh.. debian has 1956 packages.  Do you think having that many postrm
> scripts is viable?

postinst scripts are rarely anywhere near as complicated as a config
file parser. 

the majority of packages don't even have any {pre,post}{rm,inst}
scripts, and most of those that do don't do anything particularly
complicated.


> Of course it's viable.  It just becomes a package maintainer
> responsibility.  In the vast majority of cases, the package maintainer
> ought to be able to use the *same code* as the package itself for
> parsing config files.
>
> In many well factored cases, this will be as simple as extracting
> config.c or some similarly named file from the distribution and making
> a few changes to it.

no, it's not that simple.

it needs to read and parse the config file, allow the user to manipulate
it, and then write it back out again (if the user chooses to save any
changes) WITHOUT losing any information, including comments and the
order of the comments.


craig

--
craig sanders


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Tools the Parse config files (was Re: Linuxconf)

[Shaya Potter]

Ok, I see their has been a lot of talk on if the way linuxconf does its
thing is good for debian.

first things first, a user doesn't have to use linuxconf.  If a user wants
to edit the file by hand they can use the existing tools that we have.  Even
those aren't perfect, if I edit my sendmail.cf by hand, then run
sendmailconfig, I can blow away what I just added.  I believe we have to aim
for a tool that will make most peoples lives easier in admin'ing their
system, while not taking away any of the functionality of editing the files
directly. i.e. The packages will work and be configurable easily without
linuxconf, but if you use linuxconf you are agreeing to a compromise of some
sort, in that we can't guarantee that if you are an "edit the file directly"
kind of person, that linuxconf will be able to parse what you wrote.  
-We will work towards being able to parse what you have written, but we
aren't aiming linuxconf at you.  
-If their is something that you what to do that linuxconf can't do, file a
bug report and we'll try to add that to linuxconf

Also, linuxconf shouldn't be used to configure a user's personal
information, such as .bashrc, .pinerc, those should be left to either the
program itself like in pine, or to a package like the dotfile generator for
a program like bash or procmail.  Essentially, for system wide daemons and
servers, use linuxconf, for user level tools use the examples I gave for
bash/pine.  Something like cron falls in the middle, and I'd be willing to
put that in linuxconf as cron can be both configured on the user level and
system level.

For the fact that we would need to write a parser for all our conf files. I
think that might be overkill, as many of our conf files are probably just
some files with a variable or two.  i.e. the structure of the config file is
constant just with a change in the "variables".  It shouldn't be too hard to
set up a example linuxconf module that shows how to set up a simple form
that accepts input and place them into the proper slots in a model config
file.  This example module could be easily modfiable for all the appropriate
uses.  Other things are obviously more complicated, but that might knock off
a big chunk of our conf files.

Shaya


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Rev. Joseph Carter]

On Tue, Jun 02, 1998 at 11:14:45AM +0100, Jules Bean wrote:
> > The solution of course is to extend the m4 stuff to support all the things
> > linuxconf does, but that's not so easy.  Also, note that slackware didn't at
> > last look have m4 sendmailconfig.  Another example of where slackware is
> > doing more harm than good these days by not adopting things the rest of the
> > world has...  =p
> 
> This sounds foolish to me.
> 
> The solution is to switch to a better designed mailer (exim springs to
> mind) with easier to manage configuration.

Nah.  The biggest reason to use sendmail is that it's standard and all.  I'm
not likely to give up qmail anytime soon, but you could in theory have the
sendmail module not there and replace it with an exim module in Linuxconf if
you wanted.  I doubt with qmail's non-free state this will happen, but if it
happens with exim I might be tempted to try it.

Fact is that I couldn't figure out with smailconfig how to set up my dynamic
ip system and exim used very close to the same config program.  The first
one that did exactly what I wanted was qmail.

Granted there's fair to good chance that I could go back now and get exim to
do what I want--I've learned a few (thousand) things about smtp daemons on
*nix boxen since then.  But as easy as Linuxconf made sendmail, I know I
could configure that.  Only problem is that sendmail has still only two
modes: slow but queued and fast but not queued.  qmail and I think exim both
support queues of all messages and delivery is essentially instant.  With
qmail in fact, you can't stop messages from being queued---save a disk crash
you won't lost mail accepted by the system.  sendmail still can't promise
that, though it's gotten better.


pgp1L6hSJFpZ9.pgp
Description: PGP signature

Re: Linuxconf

[Jules Bean]

On Tue, 2 Jun 1998, Rev. Joseph Carter wrote:
> > IMO, linuxconf should manage sendmail.mc rather than sendmail.cf. 
> 
> That would be more reasonable, however not all that sendmail can do is
> supported with the m4 rules and such.  Not at the moment at least.  Sendmail
> is their selling point because of how complex it is, how little m4 helps and
> how much they can do with it.  The motivation for the project is that
> sendmail if easy to configure could sell linux and the opensource paradigm
> to a few people.  This is good.
> 
> The solution of course is to extend the m4 stuff to support all the things
> linuxconf does, but that's not so easy.  Also, note that slackware didn't at
> last look have m4 sendmailconfig.  Another example of where slackware is
> doing more harm than good these days by not adopting things the rest of the
> world has...  =p

This sounds foolish to me.

The solution is to switch to a better designed mailer (exim springs to
mind) with easier to manage configuration.

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Linuxconf

[Rev. Joseph Carter]

On Tue, Jun 02, 1998 at 05:24:10PM +1000, Craig Sanders wrote:
> > > if a program edits it too, it should do it in a way which does
> > > not interfere at all with that human's right to put whatever s/he
> > > desires in the file. if it can not guarantee that 100% then it
> > > should not edit the file.
> >
> > With the exception of sendmail.cf, linuxconf does this.
> 
> so i can make any arbitrary change to any config file which linuxconf can
> work with, and linuxconf will:
> 
>   - not freak out because of some weirdness i did
>   - not freak out because of some perfectly sensible thing i did
>   - not lose any information (not a single byte), including comments and
> the order/location of comments in the file

Yes.  And if it does lose info (again, sendmail is currently the exception)
it's a bug to be fixed, not a design limit to live with.


> if that is the case, then i withdraw my objection against linuxconf
> editing config files directly.

It was my second objection---the first was the X requiremet (which I find
out wasn't the case either)


> RE: sendmail.cf
> 
> IMO, linuxconf should manage sendmail.mc rather than sendmail.cf. 

That would be more reasonable, however not all that sendmail can do is
supported with the m4 rules and such.  Not at the moment at least.  Sendmail
is their selling point because of how complex it is, how little m4 helps and
how much they can do with it.  The motivation for the project is that
sendmail if easy to configure could sell linux and the opensource paradigm
to a few people.  This is good.

The solution of course is to extend the m4 stuff to support all the things
linuxconf does, but that's not so easy.  Also, note that slackware didn't at
last look have m4 sendmailconfig.  Another example of where slackware is
doing more harm than good these days by not adopting things the rest of the
world has...  =p

But that's another argument.


pgpZxWGLg02Dj.pgp
Description: PGP signature

Re: Linuxconf

[Jules Bean]

--On Tue, Jun 2, 1998 11:18 am +1000 "Craig Sanders" <[EMAIL PROTECTED]> wrote:


> On Mon, 1 Jun 1998, Raul Miller wrote:
> 
>> > > The proper solution would be to fix the parser.
>> >
>> > unfortunately, this means placing arbitrary restrictions on the
>> > config filesanything which hasn't been programmed into the
>> > parser can not be handled by it, and will get blown away by the
>> > pretty GUI config tool next time it is run.
>>
>> So support the full grammar of the file.
> 
> debian currently has 1956 packages. most of them require a config file.
> do you think having that many individual parsers is viable?

Ooh.. debian has 1956 packages.  Do you think having that many postrm
scripts is viable?

Of course it's viable.  It just becomes a package maintainer responsibility.
 In the vast majority of cases, the package maintainer ought to be able to
use the *same code* as the package itself for parsing config files.

In many well factored cases, this will be as simple as extracting config.c
or some similarly named file from the distribution and making a few changes
to it.

Then, when a new upstream comes along, the maintainer checks to see if
config-file format has changed.

Of course, it *would* be nice to see packages slowly migrating towards a
standard configuration engine... and I imagine that may well happen with
time.

Note that not all packages need to move to linux conf straight away...

Jules

/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka |   |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]