Skip site navigation (1) Skip section navigation (2)

Re: New project

From: Ed Sawicki <ed(at)alcpress(dot)com>
To: "David A(dot) Gibbons" <david(at)dgibbons(dot)net>
Cc: pdxpug(at)postgresql(dot)org
Subject: Re: New project
Date: 2007-03-09 19:16:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pdxpug
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 ( uses a similiar model, having a 'daemon' script that polls
 > the database every few minutes from a crontask and checks to see if 
 > 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

In response to

pdxpug by date

Next:From: Mark WongDate: 2007-03-11 17:13:06
Subject: Fwd: [pgcon-announce] PGCon - Schedule/Registration
Previous:From: David A. GibbonsDate: 2007-03-09 18:15:36
Subject: Re: New project

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group