Openerp-server: Initscript is broken ($USER)

Bug #352299 reported by Z
8
Affects Status Importance Assigned to Milestone
openerp-server (Baltix)
New
Undecided
Unassigned
openerp-server (Debian)
Fix Released
Unknown
openerp-server (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: openerp-server

1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu.
  Description: Ubuntu jaunty (development branch)
  Release: 9.04

2) The version of the package you are using, via 'apt-cache policy packagename' or by checking in Synaptic.
  openerp-server:
    Installiert: 5.0.0-3-1ubuntu2
    Kandidat: 5.0.0-3-1ubuntu2
    Versions-Tabelle:
   *** 5.0.0-3-1ubuntu2 0
          500 http://mirror.sunstrom.priv jaunty/universe Packages
          100 /var/lib/dpkg/status

3) What you expected to happen
Start of openerp-server
4) What happened instead
Could not conntect to database, ident sameuser auth fails

Details:

After working around the python-xml issue (bug 337759), i tried starting openerp via
  service openerp-server restart
which didn't work:
[2009-03-31 12:40:21,231] INFO:server:version - 5.0.0
[2009-03-31 12:40:21,238] INFO:server:addons_path - /usr/lib/openerp-server/addons
[2009-03-31 12:40:21,250] INFO:server:database hostname - localhost
[2009-03-31 12:40:21,251] INFO:server:database port - 5432
[2009-03-31 12:40:21,251] INFO:server:database user - openerp
[2009-03-31 12:40:21,251] INFO:objects:initialising distributed objects services
[2009-03-31 12:40:21,831] INFO:dbpool:Connecting to openerp
[2009-03-31 12:40:21,855] ERROR:dbpool:Unable to connect to openerp: FATAL: Ident-Authentifizierung für Benutzer »openerp« fehlgeschlagen

The funny thing is that starting /usr/bin/openerp-server worked like a charm.

I tried playing with pg_hba.conf, but couldn't fix it.

Google pointed me to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516348#15

and the same bug (comment #15) is present in the ubuntu package: $USER is used for the chuid parameter in the init-script, but never defined/initialized.

Adding USER=openerp fixed the issue for me.

(The following settings must point to the same user (for ident sameuser in pg_hba.conf) to work:
* database user in PostgreSQL (see README.Debian)
* db_user in /etc/openerp-server.conf
* $USER in /etc/init.d/openerp
)

Changed in openerp-server (Debian):
status: Unknown → New
Revision history for this message
Schmirrwurst (schmirrwurst) wrote :

I've the same issue,
After adding USER=openerp, the init.d script is not running anymore, the logs from openerp are empty...
When copying the start-stop-daemon command from the init.d and running it manually, then it is working... but I have an error because the openerp user have no right to write the pid file in /var/run, why ?

Revision history for this message
Schmirrwurst (schmirrwurst) wrote :

I've tried without "USER=openerp", and to put --chuid openerp (instead of --chuid {$USER} )
the server is starting, but still not connecting at the db (ident sameuser issue)
I've then make a ps -x -u, and it appears that the binary is executed by root, is it normal ?

Revision history for this message
Schmirrwurst (schmirrwurst) wrote :

For now my workaround is to add
local all openerp trust
to my /etc/postgresql/8.3/main/pg_hba.conf

Is it necessary to run the server as another user than root for security issues ? As I noticed, postgres is also running as root, or am I wrong ?

Revision history for this message
Schmirrwurst (schmirrwurst) wrote :

I've submitted an update from the package that should correct this, you can try it, I hope some motu will commit it...
https://bugs.launchpad.net/ubuntu/+source/openerp-server/+bug/337759

Changed in openerp-server (Ubuntu):
status: New → Confirmed
Changed in openerp-server (Debian):
status: New → Fix Released
Revision history for this message
Laurent Bigonville (bigon) wrote :

looks fixed in 5.0.1-0-1

Changed in openerp-server (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.