Re: New project

David A. Gibbons wrote:
> ----- "Ed Sawicki" <ed(at)alcpress(dot)com> wrote:
>> I've started a new project that involves the management
>> of network infrastructure (DNS, DHCP, Web, etc.) that
>> has a database at its core rather than a filesystem as
>> most similar programs do. I've chosen Postgres for
>> numerous reasons but the inspiration for considering it
>> are the IPv4, IPv6, and MAC address data types.
>
> Ed,
>
> Alot of these also have the ability to talk directly to postgresql, I know postfix does, courier-imap does, powerdns does.
> Not to get boo'd off the list here but you also might want to look into using LDAP as a backend, I've been amazed at how many services have LDAP hooks.
> PowerDNS can do ldap or postgres, postfix can do postgresql or ldap, PAM can do LDAP (there's a postgresql module but i've had limited sucess getting anywhere with it), DHCP can do ldap.. Without knowing what services "etc" are, It's hard to go on listing but i think you get my point ;)

When I referred to "similar programs" above, I was not
referring to the daemons that were ultimately being
controlled but rather management programs that allow
users to configure the daemons. Nagios seems to me to
be the best example of a network management application
crying out for a database but crippled by
database-phobic designers.

Yes, whenever possible I use daemons that do talk to
a database. PowerDNS is one of the better examples.
But many customers choose their daemons based on
popularity - BIND being the most obvious example;
and the most problematic.

Interesting that you mention LDAP. I realize you were
suggesting using LDAP instead of a database but I've
been wondering about the feasibility of slapping an
LDAP interface onto Postgres and how I would do it.
The impedance mismatch between the relational and
hierarchical worlds may make this a silly idea.

>
>
>> 4. The database must "interface" with Linux daemons that
>> have no ability to talk to the database but look to the
>> filesystem for their configuration files. I'm going to
>> handle this initially with shell scripts that use psql.
>> Later, this functionality may be moved to servlets.
>
> VHCS (www.vhcs.net) uses a similiar model, having a 'daemon' script that polls
> the database every few minutes from a crontask and checks to see if
anything
> needs to be done. I think it's implementation kinda sucks but that if
you have
> to write out system files this is going to be your best option if you
want to
> keep the setup standard (applications and configurations in normal
places on the
> system) as most likely these files will have to be written as root,
and you don't
> want to be running your interface or serverlets as root. The only
alternative is
> to provide a chroot-like location with all the services being owned
by one user.
> But that can make upgrading and adoptation kinda painful, zimbra does
this with
> specialized version of all it's parts (postfix, java, apache, mysql)
running as a
> "zimbra" user. It lets it write to all it's files but when you come
in and try to
> modify things, without having a full understanding of the special
layout, things can be painful.

For the servers that we control, most things run chrooted;
bind mounts and filesystem extended attributes usually give
us what we need. I haven't yet explored whether this can be
done with servlets securely.
But many customers control their own servers, so the problem
you mention is a real one. I'll look into vhcs. Thanks

>
> I had been thinking about doing something similiar myself, there are no real good
> web hosting control panels at the moment, the free ones all suck and
are written
> in php/perl and use mysql. I was thinking rubyonrails with ldap
and/or postgres
> as a backend but havent' gotten time to really research it too carefully.

>> Ed Sawicki
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 9: In versions below 8.0, the planner will ignore your desire to
>> choose an index scan if your joining column's datatypes do not
>> match
>