Masters of the list - Fw: Mail failure

[Thor Heinrichs-Wolpert <th...@Echidna.net>]

Someone's internal mailforwarding is failing.
Can they be removed from the list, or notified of the problem?

Thanks,
Thor HW
----- Original Message -----
From: CGF/BGH/POSTMASTER <IM...@po2.bgh.edu>
To: Thor Heinrichs-Wolpert <th...@Echidna.net>
Sent: Wednesday, July 14, 1999 2:36 PM
Subject: Mail failure


>
> [005] The mail retry count was exceeded sending to BGHNETWORK/BGHPOSTOFF.
>
>
> --------------------------------------------------------------------------
--
> --
> Microsoft Mail v3.0 (MAPI 1.0 Transport) IPM.Microsoft Mail.Note
> From: Thor Heinrichs-Wolpert
> To:  ebayeh@us.ibm.com
>      general@jakarta.apache.org
> Subject:  Re: Apache Configuration - was I volunteer!
> Date: 1999-07-14 16:48
> Priority: 3
> Message ID: 8C895CA60D3AD311826F00600837857D
>
>
>
>
> Agreed, and that's why I think it's important to NOT embed functionality
in
> the XML files that must be done through an applet.
>
> Things like encrypted values, or hidden dependencies and logic.  There are
> servers I deal with that have way cool GUIs, but the files cannot be
> reproduced without the applets.  I can still hack the files, but there is
> system info that cannot be reporduced directly with an ascii editor.
>
> SO, just saying the data is stored in an XML document doesn't prevent
> someone from making it only useable via an API.
>
> Thor HW
>  ----- Original Message -----
> From: <eb...@us.ibm.com>
> To: <ge...@jakarta.apache.org>; Thor Heinrichs-Wolpert
<th...@echidna.net>
> Sent: Wednesday, July 14, 1999 1:07 PM
> Subject: Re: Apache Configuration - was I volunteer!
>
>
> >
> >
> >
> > >A GUI is fine for anyone managing a single server, but most of the ISPs
I
> > >deal with want to have ascii files they can work with.  When you are
> > >managing a few hundred servers, it's nice to be able to apply some
> generic
> > >scripts to do active chores, or roll info from one system to another.
> >
> > I think an XML config file gives you both.... You can still edit the
> config file
> > as a standalone text file, (or use some editor that supportd XML
editing);
> You
> > could send the file as a stream to a client (If the client understands
XML
> (IE5
> > or an applet));  or you could use a servlet or JSP to process the data
on
> the
> > server and send it to any web browser as HTML.  And every administrator
> will use
> > the method of their choice.
> >
> > Cheers,
> > -Elias
> >
> >
> >
> >
> >
> > "Thor Heinrichs-Wolpert" <th...@echidna.net> on 07/14/99 03:54:48 PM
> >
> > Please respond to general@jakarta.apache.org; Please respond to "Thor
> >       Heinrichs-Wolpert" <th...@echidna.net>
> >
> > To:   general@jakarta.apache.org
> > cc:    (bcc: Elias Bayeh/Raleigh/IBM)
> > Subject:  Re: Apache Configuration - was I volunteer!
> >
> >
> >
> >
> >
> > A GUI is fine for anyone managing a single server, but most of the ISPs
I
> > deal with want to have ascii files they can work with.  When you are
> > managing a few hundred servers, it's nice to be able to apply some
generic
> > scripts to do active chores, or roll info from one system to another.
> >
> > I tend to use both, depending on what I want to do.
> >
> > Thor HW
> > ----- Original Message -----
> > From: David Joham <dj...@criadvantage.com>
> > To: <ge...@jakarta.apache.org>
> > Sent: Wednesday, July 14, 1999 12:26 PM
> > Subject: Apache Configuration - was I volunteer!
> >
> >
> > >
> > > <<But, anyhow from what I have experienced, seasoned system
> > > administrators will almost always go straight for the configuration
> > > files. Take apache for instance, how many administrators use a fancy
> > > gui to configure httpd.conf, none - AFAIK.>>
> > >
> > > My apologies if this is a stupid question, but does Apache even have a
> > > sophisticated GUI configurator? I've been playing with the
configuration
> > > files and getting it to do what I want, but that's been taking time
away
> > > from what I want to be using the tool for, which is developing
> > applications
> > > to serve web pages.
> > >
> > > I agree that seasoned admins generally do go for the config files.
> > However,
> > > not all of us are at that point. Take Samba for example. I'm not a
Samba
> > > expert so I generally let SWAT do my work for me. Then I go into the
> files
> > > and see what it did. Presto: a new learning tool.
> > >
> > > One idea would be to make the configuration tool pure HTML that hits a
> > > JSP/Servlet back-end. This would serve two purposes. One: a nice HTML
> > > interface can be built to accommodate the largest number of browsers
and
> > > admins like me who actually like GUIs. Two: This application can serve
> as
> > > example code and documentation for the Apache/Java/XML? engine(s).
> > >
> > >
> > > David
> > >
> > > -----Original Message-----
> > > From: Jan-Henrik Haukeland [mailto:hauk@tildeslash.com]
> > > Sent: Wednesday, July 14, 1999 1:09 PM
> > > To: general@jakarta.apache.org
> > > Subject: Re: I volunteer!
> > >
> > >
> > > "Carreira, Jason" <Ja...@usa.xerox.com> writes:
> > >
> > > > Another idea for the lower-tech end would be the configuration
> applets.
> > >
> > > Oh no, not applets for server configuration, please. IMHO, Applets in
> > > this context are to inflexible to work with, both for developers and
> > > for the end users to use.
> > >
> > > ATG's Dynamo application server is a good model for how to do
> > > configuration. I.e. use serverside Java and HTML forms on the
> > > browser. Then, one can concentrate on doing _one_ good server side
> > > application that supports the maximum numbers of browsers.
> > >
> > > But, anyhow from what I have experienced, seasoned system
> > > administrators will almost always go straight for the configuration
> > > files. Take apache for instance, how many administrators use a fancy
> > > gui to configure httpd.conf, none - AFAIK.
> > >
> > > --
> > > Jan-Henrik Haukeland
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
>
>  ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>