[turba] solution found

[Eric S. Johansson]

> Message: 2 Date: Sun, 2 Nov 2003 13:07:01 -0500 From: Chuck Hagenbuch <chuck at horde.org> Subject: Re: [turba] turning attention to undefined indices To: turba at lists.horde.org Cc: doc at lists.horde.org Message-ID: <20031102130701.z6tshusw0wcg4s88 at marina.horde.org> Content-Type: text/plain; charset="ISO-8859-1" [cc:ing the doc list on this in case someone is inspired to turn it into something postable/included in the Turba docs.] Quoting "Eric S. Johansson" <esj at harvee.org>:
> 
  > Well, mostly those requests were answered by telling people to fix their
> configuration files, since the root of the problem is that two of your config
> files don't match up.

as I've learned, I'm sure they were.  Unfortunately, with answers never 
made it to the archives.

> 
> However, for posterity, the lists, etc., here's what's going on.
> 
> Turba has a system of defining what is in a directory/addressbook/whatever you
> want to call it that is necessarily complicated by reason that it is flexible
> enough to map to pretty much anything with zero code changes, only config
> tweaks.

...

> Is this a problem with the default config files, you're going to ask me? Well,
> yes - for a while, the default sources.php included an example that used
> attributes that weren't in the default attributes.php. This has since been
> fixed, but it was possibly after the last stable release.
> 
> Why isn't it in the documentation somewhere, you ask? Well, the comments at the
> top of the two files in question try to document it, but basically because no
> one had the time to try and write something like this up, make sure it was
> understandable (which it still might not be), and put it somewhere useful. I'm
> still actually not sure where it should live - probably on the Turba website, I
> guess.

the vast majority of what you wrote would have been wonderful if it had 
been in the FAQs.  It answered my question in a way that allow me to 
solve the problem.  As you can well imagine, I found a few other 
"issues" but I've recorded them and will send them on as well to the doc 
list.

may suggest you edit it down a little bit to fit FAQ format and style 
and just stick in there before another poor soul is tortured.

> So, hope that helps.

sure did.  Here are some more raw notes and then I get to go to the 
kronolith list and ask why their database setup script is less than ideal:

----
TCP connections:
user: postgres
file: postgresql

turn on TCP connections in postgresql.conf.  Look for the section
labeled connection parameters and you should find:

#tcpip_socket = false

make the line read:

tcpip_socket = true

also uncomment (mandatory) and adjust (optional):
Max_connections
superuser_reserved_connections
port
hostname_lookup
show_source_port

the user should leave port alone because it's a standard port for
access but this is not a hard and fast rule.

permissions:
user: postgres
file: pg_hbba

in pg_hbba there is a line near the end of the file that defines the
trust relationship between client IP address and server.  Uncomment
the line that looks like:

host    all         all         127.0.0.1         255.255.255.255   trust

if one is running the database client and server on the same machine.
If they are running on different machines or on a multiple user
machine you'll need to the tighten up the access requirements.  See
the postgresql administrative guide at www.postgresql.com

more guidance on modifying sources.php would be helpful as
would improvements on error messages such as "failed to connect to
specified directory".  What specified directory?

a more explicit partitioning of the sources.php file would help.  Before 
I realize I had to delete three-quarters of it I was trying to access 
LDAP servers all over the planet including a couple that did not exist. 
  This gave me the error above and it took a bit of thinking to realize 
that multiple definitions of data sources in sources.php was causing the 
problem.

---eric

-- 
Speech recognition in use.  Incorrect endings, words, and case is
closer than it appears