[Re: Fwd: Re: [turba] horde db shortcomings (fwd)]

----- Forwarded message from "Eric S. Johansson" <[email protected]> -----

Date: Fri, 31 Oct 2003 07:50:49 -0500
From: "Eric S. Johansson" <[email protected]>
Subject: Re: [doc] Fwd: Re: [turba] horde db shortcomings
To: Eric Rostetter <[email protected]>
Cc: [email protected]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.5) Gecko/20031013 Thunderbird/0.3

Eric Rostetter wrote:

>Quoting Chuck Hagenbuch <[email protected]>:
>
>
>Well, it is in your hands in that if you don't submit it, it won't be used. 
>;)
>But if you do submit it, and it is worth using, it will surely be used
>(eventually).

I was playing on sending it directly to the doc list after I had 
resolved the problems with logging which were keeping me from resolving 
the further problems I was having with turba.  I'm convinced it's all 
something really really simple that will be obvious as soon as a figure 
out what the heck it is. But I don't know enough about postgresql to 
know even what the questions should be which makes me *extremely* cranky 
 which I try not to share... too much.


>
>
>>---eric
>
>
>Good name :)
>
there does seem to be a plethora of Eric's in this field.  All of them 
opinionated.  ;-)

>>==============================
>>before creating the database, give the postgres account a password.
>>This will then be replicated into the database automatically.
>>
>>if something goes wrong with the database, you can simply delete it
>>and (on Red Hat) it will be re-created.
>
>
>That is rather OS and DB specific, so I'm not sure we can use it as-is.
>But an intro section (make sure you setup the software, configure it, etc)
>would be good, and we can try to mention some of this there.

I was thinking of this as more a postgresql specific help.  I think it 
is worth putting in as a note in the database specific documentation 
that OSes that are known to create the databases automatically.  for 
example, the init script on Red Hat looks like it has been created by 
the postgresql folks for general sysv init script usage.  maybe it could 
be phrased something like if your system uses the standard init script, 
the initial template databases will be created when postgresql is started.

I do agree an introduction section would make a lot of sense and I think 
that database specific introductions also makes a significant amount of 
sense.


>>run webmin.  It makes the process of verifying results an order of
>>magnitude easier.
>
>
>Too specific.  Might mention it as an option, but certainly won't require
>it.

agreed but it has made some of my exploration easier.

>>provide "you should see this at this point" markers at least at the
>>end of each table set up
>
>
>We can try to do something here, but I'm not sure what yet.

as you mention further down, there are some specific commands one can 
run to give a view of the database.  All I suggest is to run those 
commands at specific points, capture the output and put a bit of 
explanation around it in terms of what you need to do and what you need 
to see.

If you've ever built Heathkit project, you would know what I mean.

>>be explicit at each stage what user you should be running as.  My
>>experience shows that running as postgres is usually best for setting
>>up database features
>
>
>Yes, we can put that in the initial section mentioned above.

but also, don't forget to put brief reminders about the general context 
into the documentation for each of the subprojects.  When you're 
installing the system you tend to get tunnel vision.  I've seen this in 
myself and others countless times so you need to write documentation to 
deal with the installers mindset.  Putting in reminders or references to 
other documents when it's appropriate knowledge helps counteract that 
tunnel vision.

>
>
>>make sure your scripts work.
>
>
>Obviously.  And probably need to document what versions it is known to
>work with, and any changes between versions, etc.  In fact, the current
>scripts fail for me, but for totally different reasons/errors...

I don't know how to counteract this problem.  The script that stopped me 
cold for awhile (turba) looked like it was either very old or doing 
something special that was a compile time configuration option and this 
just happened to not be the right version of the database.  It's a 
bitch, no doubt about it so there needs to be enough information around 
the script to help the installer figure out other ways to solve the 
problem.  Maybe even just one alternative might be sufficient.

>>The psql tool does not show ownership of tables
>
>
>Yes, it does show ownership, but not other permissions.
>
>
>>when viewed by webmin, you get a different story.
>
>
>Maybe you want to try \dp instead of (or in addition to) \d or \dt?
>Or if you like single letters then try \z instead?

this is why I've been ranting about becoming a DBA.  I didn't even know 
to look for those options.  Something in the documentation told me to 
run \d and I was so focused on figuring out what I did wrong with my 
install of Horde & Co. that it never entered my mind to look at other 
options.  Like I said, tunnel vision.  And when someone was helping me 
off list, they never mentioned these other options either but pointed me 
to webmin.

this can be helped by step-by-step examples as we discussed above.  The 
different command options can be introduced at this time to give the 
installer more mastery over their environment.

---eric

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



----- End forwarded message -----

-- 
Jon Parise ([email protected]) :: The Horde Project (http://horde.org/)

-- 
Documentation mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]