Bug 1079903

Details:

Current code expects the exact following line in pg_hba.conf:

local   all         all                               md5

If it finds it (supposedly left over from a previous 3.2 setup), it changes the last word to 'ident', to allow connecting as user 'postgres' without a password.

If this line is not found, we do not change the file, and if the first 'local' line does use 'md5', connecting as postgres will still ask for a password and setup will fail.

We should be able to find this line even if the number of spaces between fields was changed, e.g. manually by a user.

We need to decide if to fix this issue in zstream 3.3 only, not a issue with 3.4.
Please read and let us know what you think.



Yaniv

Yaniv, what's changed in 3.4 that makes this not impact 3.4?

(In reply to Arthur Berezin from comment #4)
> Yaniv, what's changed in 3.4 that makes this not impact 3.4?
We moved to otopi setup that doesn't have this bug.

(In reply to Yaniv Dary from comment #5)
> (In reply to Arthur Berezin from comment #4)
> > Yaniv, what's changed in 3.4 that makes this not impact 3.4?
> We moved to otopi setup that doesn't have this bug.

Thanks Yaniv, so yes, 3.3.z only.

readding 3.4.0, since we want to test this even if no fix is required.



Yaniv

Should be fixed in otopi setup, please test.



Yaniv

Verification fails on av6.1:


rhevm-3.4.0-0.13.beta3.el6ev.noarch
rhevm-dwh-3.4.0-6.el6ev.noarch
rhevm-reports-3.3.2-3.el6ev.noarch
jasperreports-server-pro-5.5.0-6.el6ev.noarch


# "local" is for Unix domain socket connections only
local    all          all                                md5
host    rhevmreports    engine_reports  0.0.0.0/0               md5

changed ident to md5 i 1st raw and added an extra space between each pair.

installation stick at:

[ INFO  ] Backing up database localhost:ovirt_engine_history to '/var/lib/ovirt-engine-dwh/backups/dwh-20140410000818.cKMbZE.sql'.
[ INFO  ] Creating/refreshing DWH database schema

Created attachment 884621 [details]
setup log + hba file

Anpther try on the same VM, with the same env, managed to pass.

Not sure what's the exact policy regarding what is or isn't in the release notes and requires (or not) doc_text. I personally think that any bug that was fixed in version X.Y.Z, for whatever value of Z, should not appear again in X.(Y+1).0 .

I expect 3.3.3 to be released before 3.4.0, therefore do not see a need for doc text on this one, as bug #1084760 (z-stream clone) will be in 3.3.3.

Hi Yedidyah,

We have had several like this come up in the errata queues for 3.4. Since no requires_doc_text flags have been set, we are currently providing doc text for all bugs, unless otherwise indicated.

I can see the logic that something fixed in 3.3.3 should not appear again in 3.4. In this case, I will set the doc text flag to - and remove the text. If there are other bugs that you feel do not require text, please set the requires_doc_text flag to -.

Thanks.

As customers tend to consume errata as individual objects, especially from release to release, we will have to repeat ourselves if necessary. The question isn't about whether the doc text should be included in more than one errata if necessary (it should) but whether the issue itself warrants a specific tech note at all.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2014-0601.html