[Gnumed-devel] Re: (Another) Install of GnuMed (this time on Debian "Sarge")

[Andreas Tille]

On Tue, 15 Jun 2004, Michael Bonert wrote:

> --------------------------------------------------
> GnuMed Install Notes
>
> Operating System: Debian GNU/Linux 'Sarge' / KDE 3.2.2
> Hardware: Toshiba Satellite A-20
> Date: June 15, 2004.
> --------------------------------------------------
>
> Older Debian install notes are here:
> http://lists.gnu.org/archive/html/gnumed-devel/2004-01/msg00047.html
> http://lists.gnu.org/archive/html/gnumed-devel/2004-01/msg00011.html
> (These notes borrow a bit from the above)
Hi Michael,

you quoted your initial mails from your previous install reports.  Both
caused some kind of discussion.  I'm not sure whether you are subscribed to
this list because you did not answered to any of these mails.

> # apt-get install cvs
>
>
> $ cvs -z3 -d michaelb @ subversions.gnu.org:/cvsroot/gnumed checkout gnumed
>     ALTERNATE:
>     $ cvs -z3 -d:ext:anoncvs @ subversions.gnu.org:/cvsroot/gnumed checkout 
> gnumed
>       no spaces before and after '@'
It's fine to do it this way but as I wrote in

   http://lists.gnu.org/archive/html/gnumed-devel/2004-04/msg00115.html

it is better to use

   ~> wget http://people.debian.org/~tille/packages/gnumed/debian/rules
   ~> make -f rules get-orig-source

to get all things you need from CVS.  It uses the same code which was provided
by Karsten Hilbert to check out the CVS but strips some unneded files and builds
a tarball from the checkout.

> # apt-get install postgresql
> Success. The database server should be started automatically.
> If not, you can start the database server using:
>     /etc/init.d/postgresql start
>
>
> # apt-get install python-pgsql
> # apt-get install libwxgtk2.4-python
> # apt-get install pgaccess    # not required but nice to have
BTW, did you ever tried the pgadmin3 package?  I guess you will like it.

> CHANGING POSTGRES PASSWORD
> $ su
> # passwd postgres
>         (enter new passwd)
Have you ever read

   http://lists.gnu.org/archive/html/gnumed-devel/2004-01/msg00021.html   ???

PLEASE DO NOT DO THAT!

> $vi postgresql.conf
>         changed "#port = 5432" to "port = 5432"
Does no harm but is not necessary.  This is the default port.

> MODIFICATIONS TO "/etc/postgresql/pg_hba.conf"
> --------------
> #
> # TYPE  DATABASE    USER        IP-ADDRESS        IP-MASK           METHOD
> #
> #host    all         all         127.0.0.1         255.255.255.255   trust
>
> local   template1   postgres                                        ident 
> sameuser
> local   template1   all                                             md5
> local   gnumed      all                                             md5
> host    gnumed      all         127.0.0.1         255.255.255.255   md5
>
> --------------
> ALL OTHER LINES ARE COMMENTED-OUT
Not so bad as in your first suggestion but why don't you use the configuration
which I suggested and tested?  Did you tried my suggestion?  Was there any 
problem
for you?

> $ su
> # kill [pid for postmaster]
> # su postgres
> $ /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data/       &
>       # restarts postmaster    --- not elegant... but it works
Have you ever read the "Ohhhhh noooo." - part of

   http://lists.gnu.org/archive/html/gnumed-devel/2004-01/msg00021.html

You write that it is not elegant but why do you refuse the hint to

         /etc/init.d/<service> [start|stop|restart|...]

which works for each service in Debian especially for

         /etc/init.d/postgresql restart

???

> COMMENTS -
> The bootstrapping procedure is messy at the moment.  Reason: one has to be
> user 'postgres' ... it is 'cause of Debian I've been told--Debian forces
> the use of "IDENT" in the 'pg_hba.conf'.
Sorry, this is WRONG and I have explained in my mail quotet above how to
do it right.

> THE UGLY HACK - If the ownership of the files isn't changed from 'michael'
> to 'postgres' the bootstrapping craps-out because it doesn't have the
> required permissions.
Your first ugly hack requires further ones.

> WHAT TO DO?
> My proposed solution is more clearly dividing the components that belong to
> (1) the server, and
> (2) the client
> Dividing up the components more clearly will make packaging easier
> (Andreas will be happy).
Andreas needs only more time.  Technically the separation of the components
is well done.  Thanks for your intend to help but the most help would be if
you would at first try what I have done and report to me what not worked.
The only explanation for me is that you have not recived the list mails.
Please read again what I wrote and try to do what I suggested.  Your input
of problems you detected in this procedure would be really appreciated but
please do not misslead people with hints you call yourself "not elegant" like
restarting postmaster the wrong way because all this is hidden from the
user by the packaging stuff.

> Also, it will allow us to write a little script
> that copies all the files required by the server for bootstraping to a
> postgres (user) subdirectory.
No, we do not need this.

> (Required files are sql files, bootstrapping
> files and what they these files depend on (a few modules)).
These veiw modules are sorted out for a long time and are separated in the
gnumed-snapshot-common package which is automatically installed by the
dependencies of gnumed-snapshot-server.  So this Problem is solved for
over a year.

> Copying the
> files into a postgres subdirectory will avoid that the bootstrapping
> craps-out and make the install relatively seemless for the people
> working from the CVS version.
If you really need the CVS version try the hint I gave in

    http://lists.gnu.org/archive/html/gnumed-devel/2004-04/msg00115.html

This way you have good chances to get "semi-working" packages.  Tell me
*all* problems which occure when you do so and I will care immediately.
Even if I have currently time constraints to develop new things I feel
responsible for all things I've done in the past and will sort out
problems.  But please do not try to reinvent the wheel to save your
time.

Kind regards and thanks anyway (even if I might have sounded hard - it's
all technical analysis and no offense)

         Andreas.