I checked the latest docs (v. 10) regarding the PostgreSQL user account, and I did not see mention of running it as an LDAP account (in the User Account section).
I have done this on RHEL 6 using VAS integration with Active Directory, using <domain>\postgres, as the service account and it worked fine.
A Linux Sys Admin reported to me a problem on RHEL 7, described below.
I would appreciate feedback on this potential issue. Is this true, that we should not run Postgres as an AD account on RHEL 7? Is it okay to run Postgres as an AD account on any Linux distro?
I assumed that since we run MySQL, Oracle, and SQL Server with AD service accounts that we should be able to do the same with Postgres, but I am having difficulty finding explicit documentation for this.
Sys Admin Description of problem on RHEL7:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"I’m running into a problem with RHEL7 where the /var/run/postresql directory doesn’t get created and this appears to be due to the fact that it is built much earlier via systemd, before VAS runs, so the postgres user is not found at run time.
Either I need to remove the postgres AD account or run postgres under a different account that I set up locally."
"Running postgres on RHEL 7 using the postgres user account in AD doesn’t work. What happens is that there’s a process that runs at boot time to create /var/run/postgresql, but on RHEL7 using a directory account, this fails because the system cannot find the ID as it runs before VAS starts. And because Postgres does not have a run directory for the pid file, it also fails to start."
I asked him to investigate if this can be addressed using RHEL 7 systemd and service manager to control service dependencies and startup order? This RHEL doc is what I am referring to: https://access.redhat.com/articles/754933
His response was:
"It doesn’t work on our RHEL7 test server. We just never rebooted it, so we never saw the problem. I just rebooted test server and if you look now in /var/run, there is no postgres directory for the pid.
[sys-admin@tst-server run]$ sudo systemctl status systemd-tmpfiles-setup.service
[sudo] password for sys-admin:
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2017-05-04 10:52:05 EDT; 5min ago
Docs: man:tmpfiles.d(5)
man:systemd-tmpfiles(8)
Process: 828 ExecStart=/usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=1/FAILURE)
Main PID: 828 (code=exited, status=1/FAILURE)
May 04 10:52:05 tst-server.com systemd[1]: Starting Create Volatile Files and Directories...
May 04 10:52:05 tst-server.com systemd-tmpfiles[828]: [/usr/lib/tmpfiles.d/ppas-9.5.conf:1] Unknown user 'postgres'.
May 04 10:52:05 tst-server.com systemd-tmpfiles[828]: [/usr/lib/tmpfiles.d/ppas-9.5.conf:2] Unknown user 'postgres'.
May 04 10:52:05 tst-server.com systemd-tmpfiles[828]: [/usr/lib/tmpfiles.d/ppas-9.5.conf:3] Unknown user 'postgres'.
May 04 10:52:05 tst-server.com systemd[1]: systemd-tmpfiles-setup.service: main process exited, code=exited, status=1/FAILURE
May 04 10:52:05 tst-server.com systemd[1]: Failed to start Create Volatile Files and Directories.
May 04 10:52:05 tst-server.com systemd[1]: Unit systemd-tmpfiles-setup.service entered failed state.
May 04 10:52:05 tst-server.com systemd[1]: systemd-tmpfiles-setup.service failed.
I tried adjusting the order of services, but the systemd-tmpfiles-setup service has to run before sysinit.target, which is very early in the boot process. If you attempt to make this start after VAS, it breaks and then doesn’t create any of the tmpfile directories.
The big issue here is that Postgresql uses the default postgres user as both an OS account and the default database user account. The OS account needs to be local, not in AD.
Either I need to remove the postgres AD account or run postgres under a different account that I set up locally."
"Running postgres on RHEL 7 using the postgres user account in AD doesn’t work. What happens is that there’s a process that runs at boot time to create /var/run/postgresql, but on RHEL7 using a directory account, this fails because the system cannot find the ID as it runs before VAS starts. And because Postgres does not have a run directory for the pid file, it also fails to start."
I asked him to investigate if this can be addressed using RHEL 7 systemd and service manager to control service dependencies and startup order? This RHEL doc is what I am referring to: https://access.redhat.com/
His response was:
"It doesn’t work on our RHEL7 test server. We just never rebooted it, so we never saw the problem. I just rebooted test server and if you look now in /var/run, there is no postgres directory for the pid.
[sys-admin@tst-server run]$ sudo systemctl status systemd-tmpfiles-setup.service
[sudo] password for sys-admin:
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
Loaded: loaded (/usr/lib/systemd/system/
Active: failed (Result: exit-code) since Thu 2017-05-04 10:52:05 EDT; 5min ago
Docs: man:tmpfiles.d(5)
man:systemd-tmpfiles(8)
Process: 828 ExecStart=/usr/bin/systemd-
Main PID: 828 (code=exited, status=1/FAILURE)
May 04 10:52:05 tst-server.com system
May 04 10:52:05 tst-server.
May 04 10:52:05 tst-server.com systemd-tmpfiles[828]: [/usr/lib/tmpfiles.d/ppas-9.5.
May 04 10:52:05 tst-server.com systemd-tmpfiles[828]: [/usr/lib/tmpfiles.d/ppas-9.5.
May 04 10:52:05 tst-server.com systemd[1]: systemd-tmpfiles-setup.
May 04 10:52:05 tst-server.com systemd[1]: Failed to start Create Volatile Files and Directories.
May 04 10:52:05 tst-server.com systemd[1]: Unit systemd-tmpfiles-setup.service entered failed state.
May 04 10:52:05 tst-server.com systemd[1]: systemd-tmpfiles-setup.service failed.
I tried adjusting the order of services, but the systemd-tmpfiles-setup service has to run before sysinit.target, which is very early in the boot process. If you attempt to make this start after VAS, it breaks and then doesn’t create any of the tmpfile directories.
The big issue here is that Postgresql uses the default postgres user as both an OS account and the default database user account. The OS account needs to be local, not in AD.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thanks for reading!
David
