[DOCS] Online documentation unclear about authentication defaults

2007-02-06 Thread bubblboy

Hi,

After following the postgresql tutorial for setting up a postgresql 
server [1] I noticed that I could log in without entering my password. 
The documentation did not tell me this (maybe I overlooked it), 
eventhough it does show you how to create roles with passwords. In my 
opinion it would be a good idea to include a warning like "the default 
installation trusts everybody that can make a connection to the 
database" because it could lead to some (problematic) confusions.


I didn't check extensively in the docs to see if there actually was such 
a warning, particularly because I felt that if there was, it was 
probably not prominent enough (or I would have noticed). Sorry if there 
was indeed a big warning splattered over the tutorial somewhere.


Greetings,
bb

[1] http://www.postgresql.org/docs/8.2/interactive/installation.html

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [DOCS] Online documentation unclear about authentication defaults

2007-02-07 Thread bubblboy

Alvaro Herrera wrote:

bubblboy wrote:

Hi,

After following the postgresql tutorial for setting up a postgresql 
server [1] I noticed that I could log in without entering my password. 
The documentation did not tell me this (maybe I overlooked it), 
eventhough it does show you how to create roles with passwords. In my 
opinion it would be a good idea to include a warning like "the default 
installation trusts everybody that can make a connection to the 
database" because it could lead to some (problematic) confusions.


I didn't check extensively in the docs to see if there actually was such 
a warning, particularly because I felt that if there was, it was 
probably not prominent enough (or I would have noticed). Sorry if there 
was indeed a big warning splattered over the tutorial somewhere.


The tutorial indeed neglects warning you about that, but initdb doesn't.
It outputs these lines

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.


Maybe this is not strong enough, or not scary enough?


Hmm,

You are right, I ran initdb a few weeks ago and continued today. 
Personally, I would say that it wouldn't be a bad idea to include a 
second warning in the documentation nonetheless, just to emphasize it 
(or maybe make the initdb message a little more prominent - who knows). 
I can imagine that I saw all that output and thought "oh well, I'm 
following the tutorial so this won't be very interesting", but maybe 
(probably) that's just plain stupid :)


Greetings,
bb

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [DOCS] should we have a separate page that clearly defines what a minor release is and why it's a good idea to keep up with them?

2007-02-21 Thread bubblboy

Andrew Hammond wrote:
> On 2/21/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>> > > > I think adding to the FAQ is the best solution.  What additional
>> > > > information to we need there?
>> > >
>> > > I think it's important enough (and unclear enough to a lot of 
people)
>> > > that it shuold have it's own non-FAQ section. Either as a page 
on the

>> > > website or as a page in the documentation.
>> >
>> > If you look at the developer documentation, you will see I overhauled
>> > the instructions for upgrading a minor release:
>> >
>> > 
http://momjian.us/main/writings/pgsql/sgml/install-upgrading.html

>> >
>> > I think that would be a good place to add more text.  What additional
>> > text do we need?  Something about how you are less likely to hit a new
>> > bug if you minor upgrade than if you stay on an older release?
>>
>> Something about how we put only critical fixes in back branches, and not
>> new features. How we *really* recommend that people should always be on
>> the latest release in a branch. How we will never (knowingly) change the
>> behaviour of anything in a back branch (without being *very* clear in
>> the release notes of what and why). More focus on how easy that part is.
>>
>> Mainly, I think people don't upgrade because (a) they don't know what
>> they gain, and (b) they're scared something will break. We need to
>> counter those two arguments.
>
> I think this exactly defines what I'm looking for. The most basic
> approach to risk management is "if it works, don't change it". What
> I'm looking for is something with which to convince people that the
> risk of breakage is so low that it's outweighed by the risk of
> remaining exposed to bugs which haven't caused them problems yet.
>
> Andrew

There is one thing I don't understand in this whole discussion; this
upgrading, it is not specific to PostgreSQL, is it? Is there not a page
somewhere on the web that already extensively discusses this issue, no
matter what the program is? "You should always upgrade because blah
blah", I ca not imagine nobody wrote such an article yet. And if not;
write one yourself :) Maybe linking to that article from the postgresql
documentation, if the need is felt...

Just my thoughts on this matter,
b^4

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