It is documented in rc.subr(8) that setting ${name}_env will supply the indicated values to the environment of the command being run by the rc scripts. The port-supplied rc script, however, starts the postmaster with `su -l`, which discards the environment variables set by rc.subr. This is the right thing, but it prevents the administrator's settings from being passed through to the postmaster. One possible fix is to change the postgresql_command function to simply pass postgresql_env into the command being run under `su`, although this does not help if postgresql_env_file is being used instead. It would be sufficient for my use case, however. This looks like: ${su_cmd} -l ${postgresql_user} -c "${postgresql_env} exec ${command} ${command_args} ${rc_arg}" and I have confirmed (with `ps e`) that the right values are being passed into the environment.
Which environment variables would you like to pass in this fasion? Just thinking, perhaps the feature or setting can be set using some other method?
(In reply to Palle Girgensohn from comment #1) We need specifically to set KRB5_CLIENT_KTNAME and KRB5CCNAME.
Ah ok. I think there are more problems to using the current postgresql port with Kerberos. I'll have a look at the general problem of getting kerberos working first, and hopefully there will be a fix that includes a way to set the kerberos config parameters.
(In reply to Palle Girgensohn from comment #3) Most users will never need to set these environment variables. They are required specifically in the case of one database server making an outgoing connection to another e.g. for replication (which is what we need it for). For a server accepting only incoming connections, so long as the package is built with GSSAPI support. We have a separate patch (that is probably still in bugzilla in a separate bug) that fixes the makefile (it's been broken since about 9.6 but we've been puling it forward). (That patch just reenables the *_KRB5 radio buttons and disables a buggy check for KRB5_HOME.)
Created attachment 250560 [details] Our current patch for regular MIT_KRB5 builds This patch is necessary to make standard Kerberized postgresql ports build in poudriere but not sufficient for Kerberized replication.