[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: new network config (was: Re: network configuration)

On Sat, Feb 06, 1999 at 01:32:54PM +0100, Miquel van Smoorenburg wrote:
> In article <cistron.19990206094148.P12960@taz.net.au>,
> Craig Sanders  <cas@taz.net.au> wrote:
> >On Fri, Feb 05, 1999 at 11:28:44PM +0100, Miquel van Smoorenburg wrote:
> >> > > Config files with fixed fields are evil. Really evil.
> >> > 
> >did you see the second colon-delimited format i suggested?
> >
> >three fixed fields (ip, domain, username) followed by a comma-delimited
> >"flags" field.
> Craig, I just wated to say that it's usually better to do the right
> thing straight from the start. 

yep, that's true.

i must confess i have an ulterior motive for preferring single-line
records in config files: it's very easy to copy and edit a line in vi
when each record is almost identical.

with the way i set up things, adding a new thingy (whatever that
"thingy" might be, a mailing list, virtual host, whatever) is usually
as simple as editing my meta-config file with vi, typing something like
"Yp<move cursor>cw<text>ESC:x" and then typing "make" at the command
line. nearly all of my effort goes into figuring out how to do it
properly ONCE, and then writing scripts to automate that (and write
README files for my assistants, of course :-). this is particularly
important for complicated stuff that i don't do every day, but would
otherwise have to remember how to do once/week or 3 times/month.

i can see the benefits of a more structured conf file, but it does take
much longer for me to edit, say, /etc/named.conf than it takes me to
edit the old style /etc/named.boot.  I also seem more prone to making
dumb typing/editing mistakes with that format - i think because it's
harder to see "the big picture".

of course, there is a lot more flexibility and more features possible
with the new style so it is certainly appropriate to use in bind. for
simpler things, it can be better to use a simpler single-line format.

> I do have a lot of experience with shell scripting, and it'd be easy
> for me to write a simple shell script that can parse the formats I
> proposed without any external tools.
> If you are interested in this I'd be happy to help out with the
> scripts.  If you decide to go with the format you proposed, that's
> also fine with me.

i'm always interested in learning new ways of doing things :-)

> One other thing that migh be important. Check out how RedHat does
> it- if we're going to redesign the network setup we might want to be
> compatible with them

having had to work with redhat's network setup scripts, my reaction is
that that is the LAST thing we want to do. ugly...really ugly. that's
partly because they are overly complicated for the task at hand - they
seem badly evolved (cruft piled on top of cruft) rather than designed.
and partly because it is really dangerous to edit the text files by
hand....i've had several RH configs blown away by clients carelessly
using RH's GUI network configurator.

we should learn from their mistakes, not copy them.

> Oh well I wrote a sample shell script and still would like to show off
> with it so I'm including it anyway :)

thanks, that's cool.

i'm going to be concentrating on generating config file "fragments" for
virtual host services (apache, proftpd)...not the netbase interface
setup. i'll probably write all or most of it in perl, but i may have
some use for your example shells script (if not in this project then
certainly in other ones :)


craig sanders

Reply to: