centralizing network configuration

[Bill McGonigle]

Wow, what a great, thoughtful response.

On May 28, 2007, at 11:56, Paul Lussier wrote:

>    host overpriced.foo.com {
>       # eth0
>       hardware ethernet 00:16:cb:97:67:55;
>       fixed-address overpriced;
>    }

oh, neat.  I didn't realize you could use a host name in fixed- 
address - that helps remove one duplication I have.

> Currently, all the hostnames and MAC addresses are tracked in a
> database and the DHCP config files are dynamically generated from a
> script which deals with the revision control aspect of the config
> files, and starts/stops the DHCP server.

That's a good idea.  I *love* 'live documentation' because if you  
break your documentation your stuff stops working.  This encourages  
good documentation!

>  - there's always (My,Postgre)SQL and a bunch of p(erl,ython) or  
> bash glue.

I love those kind of apps - when the system is done booting.

>  - As you mentioned, a single text file which describes everything for
>    each host, but one file seems a bit of a pain.  If you craft the
>    file to be dealt with only via scripts, then it becomes
>    unreadable/manageable by humans, but keeping it easily manageable
>    by humans makes it not easily parsable by scripts.

Yeah... this question never stops popping up, does it?  I want to  
like YAML, honestly, but...

> Obviously what you're doing here is mimicking
> the tables of a relational database, but without all the overhead (and
> none of the relational data integrity) that comes with using a
> database engine.

Hmm, I have to think about this some more, but the idea intrigues  
me.  It might be too confusing for the human users, though - not sure.

> And I'd certainly be very interested in learning more
> about the environment which you're trying to manage, since that might
> spur more ideas.

I basically see the same problem over and over again - a small  
business need a 'network manager'.  It needs to handle DHCP, DNS, and  
various network services (file sharing, mail, web site, webmail,  
network monitoring, etc.).  The management of it is usually done by  
somebody onsite who can understand what DHCP and DNS do, but isn't  
really going to edit the zone files by hand.  Webmin is sometimes a  
little too much, and tools like that often don't understand DNS views  
(where www.example.com gets one answer from the LAN or DMZ and a  
different answer from everywhere else).

Your idea of coming out of a database I think is touching on the  
right concept - that database describes 'our network' and things like  
dhcpd.conf and zone files are really just expressions of that  
information in the format a particular program likes for input.  It  
brings up all kinds of thoughts on how to store the data, how to  
interact with that data, multiple levels of users, how much can be  
auto-discovered, etc.  Maybe I really don't want to create a new  
Apache virtual host config file - maybe I want to tell an app to make  
me a new web service with 'these parameters'.  Some of that sounds  
like a GUI, but there's more to it than that - it's thinking of the  
traditional config files an an API between this-nebulous-undefined- 
thing and the time-proven core services that support things people  
want to do.

One thing I do know is that I never want to use a binary database  
store as my primary source of data - I've seen far too much  
corruption when people think they can pull this off (Mac, Windows).   
Oh, sure, a corruption proof-database would be fine (har, har, har).

I'm coming at this from a Lazy perspective, but I think the capital L  
is justified.

-Bill

-----
Bill McGonigle, Owner           Work: 603.667.4000
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf