SEO

As a PostgreSQL admin or developer, you may be asked to deploy a Linux
Apache PHP PostgreSQL application. As you know, and simplifying things
a great deal here, the pg_hba.conf file can be edited in approximately
7 different ways:

* locked down -- no access at all (usually the default)
* trust local access, any user
* trust local access, specific users
* trust remote access, any user
* trust remote access, specific users

And all of the above with or without a password, and with various kinds
of password types, thus 7 different ways, roughly.

As I think about building an installation program, can you help me
decide on how to make my LAPP installations easier in these various
kinds of arrangements? Are there more preferred practices that you can
share?

I was thinking of an install for my web app where someone downloads a
*.tar.gz file, expands it into a web directory, then connects to an
index.php in a subdirectory called "install". From there, they follow
PHP pages to do what they need in setting this up.

If I can improve this process, then a developer can download my web
app, try it out rapidly, comparing it against others, and hopefully
decide on mine because I have made it easy to get started and easy to
customize to their tastes.

Mike.....

> If I can improve this process, then a developer can download my web app,
> try it out rapidly, comparing it against others, and hopefully decide on
> mine because I have made it easy to get started and easy to customize to
> their tastes.

If it's a Linux-Apache-PHP-PostgreSQL web app you only need one user, the
one your PHP script logs in as. Then maybe you could put the same
randomly generated password in both postgres and the PHP script.

Or even have the user name be randomly generated, with or without a
password.

The default would be local access, just to try it out. If remote access
is wanted it could be a question on the setup script. Or even done
manually - I don't think anybody will be setting it up across two or more
machines without being pretty sure they want to install your app
permanently.

Just some thoughts off the top of my head.....

brew

================================================== ========================
Strange Brew (brew@theMode.com)
Check out my Stock Option Covered Call website http://www.callpix.com
and my Musician's Online Database Exchange http://www.TheMode.com
================================================== ========================


---------------------------(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

On Sat, Aug 06, 2005 at 07:59:06PM -0700, Google Mike wrote:
> As a PostgreSQL admin or developer, you may be asked to deploy a Linux
> Apache PHP PostgreSQL application. As you know, and simplifying things
> a great deal here, the pg_hba.conf file can be edited in approximately
> 7 different ways:
>
> * locked down -- no access at all (usually the default)
> * trust local access, any user
> * trust local access, specific users
> * trust remote access, any user
> * trust remote access, specific users

I'd never trust remote access, not even for specific IPs, out of fear
that somebody might be able to inject malicious commands using IP
spoofing. SSL is a must in that situation.

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
Y una voz del caos me habló y me dijo
"Sonríe y sé feliz, podría ser peor".
Y sonreí. Y fui feliz.
Y fue peor.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

brew@theMode.com wrote:

>Mike.....
>
>
>
>>If I can improve this process, then a developer can download my web app,
>>try it out rapidly, comparing it against others, and hopefully decide on
>>mine because I have made it easy to get started and easy to customize to
>>their tastes.
>>
>>
>
>If it's a Linux-Apache-PHP-PostgreSQL web app you only need one user, the
>one your PHP script logs in as. Then maybe you could put the same
>randomly generated password in both postgres and the PHP script.
>
>
Who says? I sometimes require that the PHP app logs into the database
with the username/password suppled by the user. This makes it easier to
manage permissions. Of course you cannot use connection pooling in this
case without a partial rewrite of your app...

Best Wishes,
Chris Travers
Metatron Technology Consulting

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Chris.....

> >If it's a Linux-Apache-PHP-PostgreSQL web app you only need one user, the
> >one your PHP script logs in as.

> Who says? I sometimes require that the PHP app logs into the database
> with the username/password suppled by the user. This makes it easier to
> manage permissions. Of course you cannot use connection pooling in this
> case without a partial rewrite of your app...

I said that.

Let me rephrase it. As a minimum, the way website PHP scripts typically
connect to PostgreSQL, you only need one user.

Conversely, you could trust anybody on the machine. If you are on a
dedicated machine and nobody else has access it's as secure as the
machine. However, some potential users of the app won't have secure
dedicated machines, so I think that would be a bad idea.

OTOH, you could have many postgresql user/password logins, like some of
your (Chris') websites.

How common is it to have the website user names carry through to the
postgresql user login? I don't see the advantage to it, I just have a web
username table in the database, but my websites are fairly simple, you
either have access to a private area or you don't.

brew

================================================== ========================
Strange Brew (brew@theMode.com)
Check out my Stock Option Covered Call website http://www.callpix.com
and my Musician's Online Database Exchange http://www.TheMode.com
================================================== ========================


---------------------------(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

>>>>> "Google" == Google Mike <googlemike@hotpop.com> writes:

Google> As a PostgreSQL admin or developer, you may be asked to deploy a Linux
Google> Apache PHP PostgreSQL application.

Not me. I'll be deploying an OpenBSD, Apache, PostgreSQL, Perl server.

o/~ you down with O-A-P-P? (yeah you know me!)
get down with OAPP! (yeah you know me!) o/~

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Randal L. Schwartz wrote:
> >>>>> "Google" == Google Mike <googlemike@hotpop.com> writes:
>
> Google> As a PostgreSQL admin or developer, you may be asked to deploy a Linux
> Google> Apache PHP PostgreSQL application.
>
> Not me. I'll be deploying an OpenBSD, Apache, PostgreSQL, Perl server.
>
> o/~ you down with O-A-P-P? (yeah you know me!)
> get down with OAPP! (yeah you know me!) o/~
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

You know, Randal, the funny thing is -- I once took a Perl class from
you in Boulder. At the time, I was clueless and loved Windows and VB5.
Go figure. Now I'm a LAPP fan (Linux, Apache, PostgreSQL, PHP) and you
can't put me anywhere near Windows. I complained about the difficulty
with Perl and you said Gezunteit or something like that. You probably
don't remember me.