Bug 846631

Summary: Postgresql fail to start on RHEL 5.8
Product: Red Hat Enterprise Linux 5 Reporter: Daniel Horák <dahorak>
Component: sudoAssignee: Daniel Kopeček <dkopecek>
Status: CLOSED ERRATA QA Contact: Zbysek MRAZ <zmraz>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 5.8CC: bugzilla, dapospis, dkopecek, ebenes, erinn.looneytriggs, j.k.vanamerongen, jlieskov, jpazdziora, ksrot, leonard-rh-bugzilla, lmiksik, mario.mikocevic, matt, mishu, mvadkert, pvrabec, redhat, rwf, sgraf, tgl, tmckay, ykinoshi
Target Milestone: rcKeywords: Regression, ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=818585
https://bugzilla.redhat.com/show_bug.cgi?id=841853
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-08 02:50:00 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 435010, 846974    
Attachments:
Description Flags
proposed sudo.spec changes none

Description Daniel Horák 2012-08-08 05:59:15 EDT
Description of problem:
  Postgresql fails to start on RHEL 5.8.

Version-Release number of selected component (if applicable):
  postgresql-server-8.1.23-5.el5_8.i386
  

How reproducible:
100%


Steps to Reproduce:
1. Install RHEL 5.8, register it to RHN
2. Install postgresql-server
  # yum install postgresql-server
3. Try to start postgres
  # service postgresql start
4. # tail -F /var/lib/pgsql/pgstartup.log
  
Actual results:
  Initializing database:                                     [  OK  ]
  Starting postgresql service:                               [FAILED]

  ...
  LOG:  could not translate host name "localhost", service "5432" to address: Name or service not known
  WARNING:  could not create listen socket for "localhost"
  FATAL:  could not create any TCP/IP sockets
  ...


Expected results:
  Initializing database:                                     [  OK  ]
  Starting postgresql service:                               [  OK  ]

Additional info:
  Setting SELinux to permissive mode have no effect.

  Note also that resolving localhost works with other programs, like ping:
  # ping localhost
    PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
    64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.160 ms
    64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.045 ms


It is similar to Bug 818585 - but it's look like it isn't related to SELinux.
Comment 1 Daniel Horák 2012-08-08 06:06:11 EDT
It's look like the problem is related to sudo-1.7.2p1-14.el5_8.2.
With sudo-1.7.2p1-13.el5.x86_64 it works properly, when i update it to sudo-1.7.2p1-14.el5_8.2, it fails.
Comment 2 RHEL Product and Program Management 2012-08-08 06:08:32 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 3 Leonard den Ottolander 2012-08-08 06:52:05 EDT
I can't reproduce that on CentOS 5:

# cat /etc/redhat-release
CentOS release 5.8 (Final)
# yum install postgresql-server
# service postgresql start
Initializing database:                                     [  OK  ]
Starting postgresql service:                               [  OK  ]
# rpm -q sudo
sudo-1.7.2p1-14.el5_8.2

I don't think this is related to sudo. How could it?

Looks more like a name resolution issue, perhaps http://www.question-defense.com/2009/09/17/log-could-not-translate-host-name-localhost-service-5432-to-address-name-or-service-not-known ? Are you sure sudo was the only package updated?

(Product management seems a bit rash to discard this assuming postgres really wouldn't start because of a bug...)
Comment 4 Daniel Horák 2012-08-08 07:56:30 EDT
I tried it again with following steps and from my point of view it's look like it is somehow related to sudo, but I don't know how:

1. install fresh RHEL 5.8
2. register it to RHN
3. update all packages except sudo (sudo remain in version 1.7.2p1-13.el5)
  # yum update --exclude=sudo
4. install postgresql-server
  # yum install postgresql-server
5. try to start postgresql => succeed 
  # service postgresql start
    Initializing database:                 [  OK  ]
    Starting postgresql service:           [  OK  ]
  # service postgresql restart
    Stopping postgresql service:           [  OK  ]
    Starting postgresql service:           [  OK  ]
  # service postgresql stop
    Stopping postgresql service:           [  OK  ]

6. update sudo
  # yum update
   ... truncated ...
 Skipping security plugin, no data
  --> Running transaction check
  ---> Package sudo.i386 0:1.7.2p1-14.el5_8.2 set to be updated
  --> Finished Dependency Resolution
  
  Dependencies Resolved
  =============================================================
   Package    Arch    Version              Repository            Size
  =============================================================
  Updating:
   sudo       i386    1.7.2p1-14.el5_8.2   rhel-i386-server-5   352 k
  
  Transaction Summary
  =============================================================
  Install       0 Package(s)
  Upgrade       1 Package(s)
  
  Total size: 352 k
  Is this ok [y/N]: y
    ... truncated ...
  Updated:
    sudo.i386 0:1.7.2p1-14.el5_8.2
  
  Complete!

7.  try to start postgresql => fail
  # service postgresql start
    Starting postgresql service:           [FAILED]

  # tail -3 /var/lib/pgsql/pgstartup.log 
    LOG:  could not translate host name "localhost", service "5432" to address: Name or service not known
    WARNING:  could not create listen socket for "localhost"
    FATAL:  could not create any TCP/IP sockets
Comment 5 Daniel Horák 2012-08-08 08:36:33 EDT
Problem is with regular permissions for /etc/nsswitch.conf (thanks Trevor).

# ls -l /etc/nsswitch.conf
-rw------- 1 root root 1717 Aug  8 13:45 /etc/nsswitch.conf

Investigating where its happened.
Comment 6 Trevor McKay 2012-08-08 09:09:59 EDT
Smoking gun?  /etc/nsswitch.conf permissions changed by update to sudo-1.7.2p1-14.el5_8.2

This is a cleanly installed RHEL 8 machine

root@blah:~# lsb_release -ir
Distributor ID:	RedHatEnterpriseServer
Release:	5.8


Last login: Wed Aug  8 14:47:01 2012 from blah
root@blah:~# ls -l /etc/nsswitch.conf 
-rw-r--r-- 1 root root 1716 Aug  8 14:42 /etc/nsswitch.conf
root@blah:~# rpm -q sudo
sudo-1.7.2p1-13.el5.i386
root@blah:~# 
root@blah:~# 
root@blah:~# yum update sudo
<snip>
--> Running transaction check
---> Package sudo.i386 0:1.7.2p1-14.el5_8.2 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================
 Package               Arch                  Version                               Repository                           Size
=============================================================================================================================
Updating:
 sudo                  i386                  1.7.2p1-14.el5_8.2                    rhel-i386-server-5                  352 k

Transaction Summary
=============================================================================================================================
Install       0 Package(s)
Upgrade       1 Package(s)

Total download size: 352 k
Is this ok [y/N]: y
Downloading Packages:
sudo-1.7.2p1-14.el5_8.2.i386.rpm                                                                      | 352 kB     00:00     

<snip, import a gpg key>

Is this ok [y/N]: y
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating       : sudo                                                                                                  1/2 
  Cleanup        : sudo                                                                                                  2/2 
Installed products updated.

Updated:
  sudo.i386 0:1.7.2p1-14.el5_8.2                                                                                             

Complete!
root@blah:~# ls -l /etc/nsswitch.conf 
-rw------- 1 root root 1717 Aug  8 14:53 /etc/nsswitch.conf
Comment 7 Trevor McKay 2012-08-08 09:15:43 EDT
Is it maybe because mktemp creates a file with permissions 600 (rw by owner) ?
Comment 8 Tom Lane 2012-08-08 10:57:00 EDT
In view of comment #6, reassigning to sudo.  (Or could it be a yum or rpm bug?)
Comment 9 Leonard den Ottolander 2012-08-08 18:40:36 EDT
I hadn't realized the recreation of nsswitch.conf is conditional. As there's no "sudoers" line in it on my system the file permissions survive here, which is why I couldn't reproduce the issue.

Seems this package is jinxed ;) First the selinux permissions twice, now this. I reckon all maintainers are being instructed to watch the updates they produce for file and selinux permission side effects?
Comment 10 Daniel Kopeček 2012-08-09 04:17:09 EDT
Now I regret that I didn't use sed -i... I'll fix this ASAP.
Comment 11 Daniel Kopeček 2012-08-09 04:18:08 EDT
*** Bug 846764 has been marked as a duplicate of this bug. ***
Comment 12 Daniel Kopeček 2012-08-09 05:03:22 EDT
*** Bug 846947 has been marked as a duplicate of this bug. ***
Comment 13 Daniel Kopeček 2012-08-09 05:05:29 EDT
*** Bug 846953 has been marked as a duplicate of this bug. ***
Comment 15 RHEL Product and Program Management 2012-08-09 05:18:11 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 16 Daniel Kopeček 2012-08-09 05:45:34 EDT
*** Bug 846772 has been marked as a duplicate of this bug. ***
Comment 18 Leonard den Ottolander 2012-08-09 06:13:31 EDT
Why is PM repeatedly telling us this issue will not be addressed? Afaict this is a blocker.
Comment 19 Daniel Kopeček 2012-08-09 06:30:34 EDT
Created attachment 603230 [details]
proposed sudo.spec changes
Comment 20 Daniel Kopeček 2012-08-09 06:31:57 EDT
(In reply to comment #18)
> Why is PM repeatedly telling us this issue will not be addressed? Afaict
> this is a blocker.

It's just a bot. We've got the necessary flags now.
Comment 21 Leonard den Ottolander 2012-08-09 06:44:12 EDT
For the casual visitor that is looking for a solution for their problem after having installed this update:

# chmod 644 /etc/nsswitch.conf

should fix things.
Comment 23 Rob Foehl 2012-08-09 10:45:49 EDT
(In reply to comment #19)
> Created attachment 603230 [details]
> proposed sudo.spec changes

Why are these scripts still making unnecessary changes to nsswitch.conf?  This is attempting to fix one of the issues and ignoring the rest.  Please take another look at the versions provided in bug 846764.
Comment 24 Stefan Neufeind 2012-08-13 11:54:48 EDT
according to a recent errata this is now fixed with sudo-1.7.2p1-14.el5_8.3 if I'm right. Please see:
http://rhn.redhat.com/errata/RHBA-2012-1160.html
Comment 26 Yoshifumi Kinoshita 2012-08-14 04:35:01 EDT
*** Bug 847235 has been marked as a duplicate of this bug. ***
Comment 27 W.C. Epperson 2012-08-14 08:15:05 EDT
(In reply to comment #24)
> according to a recent errata this is now fixed with sudo-1.7.2p1-14.el5_8.3
> if I'm right. Please see:
> http://rhn.redhat.com/errata/RHBA-2012-1160.html

Releasing an RHBA to correct an issue introduced by an RHSA presents a secondary problem for our environment, and probably others (judging from discussions on the satellite and spacewalk lists).

We are required by SLAs to apply RHSA errata on a controlled QA-then-prod basis.  Updates for non-security errata are done ad hoc by package, so those errata are not cloned into our patch channels (although the packages are).  So the regression introduced by the RHSA would be corrected only by specific package update rather than in the course of our patch cycle.

Although making this correction an RHBA appears to conform to RH errata policy, I'm bringing this up for consideration of whether that's the right thing to do.
Comment 28 Jan Lieskovsky 2012-08-14 10:26:46 EDT
(In reply to comment #27)
> Although making this correction an RHBA appears to conform to RH errata
> policy, I'm bringing this up for consideration of whether that's the right
> thing to do.

Hello,

  thank you for your feedback. Yes, issuing a correction for a non-security regression, found in security (RHSA) advisory, later via bug-fix (RHBA) advisory is in conformity with Red Hat policy (since security advisories can not contain corrections for non-security problems). Would the regression be of security nature (IOW it would be the new security flaw due incorrect fix for previous issue), that would be corrected via another / new security advisory.

Hope the above being helpful. Let us know if we can be of any further assistance.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team
Comment 29 W.C. Epperson 2012-08-14 12:44:22 EDT
(In reply to comment #28)

Thanks, Jan.  In my view the regression causes a DOS, and is thus security related, but I'm not going to belabor it further.  I've warned my team about the issue and what to do on an ad hoc basis.
Comment 33 errata-xmlrpc 2013-01-08 02:50:00 EST
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/RHBA-2013-0112.html