Hi Team,

I’ve noticed that in recent automated PostgreSQL provisioning runs, the "pg_krb5.conf" file is no longer present on newly built instances.

From an SRE standpoint, this should not impact us since:

- Our primary authentication mechanism is SSL certificate-based.

- LDAP usage (in our case) does not rely on Kerberos/GSSAPI.

- "krb5.conf" is only required when Kerberos (GSSAPI) authentication is enabled via "pg_hba.conf".

Could you please confirm whether this removal is intentional?

Just want to ensure there are no implications for any edge cases or future auth integrations.

Thanks,

Nikhil

Hi Team,

I hope you’re doing well.

I wanted to highlight an observation from the recent PostgreSQL server provisioning runs (automated builds in our environment). I’ve noticed that the "pg_krb5.conf" file is no longer being provisioned on newly created instances.

As part of a quick technical review from the SRE perspective:

- Our authentication model is predominantly certificate-based (SSL client certs), which does not depend on Kerberos configuration.

- LDAP authentication is used occasionally, and standard LDAP (without GSSAPI/Kerberos binding) also does not require a "krb5.conf" file.

- The "krb5.conf" file becomes relevant only if GSSAPI/Kerberos authentication is enabled (e.g., "gss" entries in "pg_hba.conf") or if LDAP is configured with SASL/GSSAPI.

- In the absence of Kerberos-based authentication, the file should not have any functional impact on PostgreSQL connectivity.

That said, I wanted to confirm:

- Is the omission of "pg_krb5.conf" intentional as part of a security hardening or configuration simplification effort?

- Or should it still be provisioned for fallback / future Kerberos-based integrations?

Just seeking confirmation to ensure there are no unintended side effects in edge cases or future auth model changes.

Thanks in advance for the clarification.

Best regards,

Nikhil

Posted By Nikhil06:33

0

Continue Reading

 Meeting to Discuss Improving Aged Request Handling & Service Delivery

Hi [SDM Name],

I’d like to schedule a short meeting to discuss ways we can better manage aged requests, reduce escalations, minimize user follow-up emails, and enhance overall service delivery. Your insights will be valuable in shaping an effective approach.

Please let me know a suitable time for you.

Current scenario

Wait for user email

No concept of on hold review

DBA gets a change of work for a day.

Shift lead concept 

Not assigned to me, why I should work

Posted By Nikhil03:54

0

Continue Reading

 Your dedication, curiosity to learn, and proactive approach really help in building a strong reputation. I appreciate how you’re always eager to fix open issues, identify improvements, and address things straight to the point. Your efforts truly make a difference!

Posted By Nikhil03:21

0

Continue Reading

 Hi Team,

This ticket has been reassigned back to us twice without any comments. As this is a decommission/migration task, we understand it should be handled by IMS.

Could you please clarify the reason for the reassignment and confirm whether such tasks are no longer managed by IMS?

Thanks for your support.

Regards,

Nikhil

Posted By Nikhil18:56

0

Continue Reading

 Hi Team,

Hope you are doing well.

The mentioned ticket has been reassigned back to our queue twice by the migration team, but there were no comments or updates added to indicate the reason for the reassignment.

As per our understanding, this task falls under the migration/decommission activity and was expected to be handled by IMS. Could you please help clarify the reason for assigning it back to us?

Additionally, please confirm if such decommission tasks are no longer being performed by IMS, so we can align accordingly and plan the next steps.

Appreciate your support and clarification on this.

Thanks and regards,

Nikhil

Posted By Nikhil18:54

0

Continue Reading

 I’m currently working on the etcd upgrade activity for PostgreSQL clusters covering 39 servers. The plan is to execute this during the upcoming weekend maintenance window. Will keep you posted on progress.

Posted By Nikhil17:30

0

Continue Reading

 Great – here is the updated GitLab issue draft incorporating your inputs:

Title

etcd Upgrade for PostgreSQL Clusters – 39 Servers (Weekend Maintenance)

Description

We need to perform an upgrade of the etcd version used by PostgreSQL Patroni clusters across our environment to address security vulnerabilities and improve stability.

The current etcd version deployed on multiple clusters is outdated and requires upgrade to a supported and secure release.

This activity will cover validation and upgrade of 39 servers hosting etcd for PostgreSQL clusters.

Scope

Total servers in scope: 39

Environments: Production / Staging / Non-Production

Upgrade of etcd on all PostgreSQL Patroni clusters

Health validation of PostgreSQL services post-upgrade

Testing of failover and cluster stability

Reason for Upgrade

Mitigation of known vulnerabilities in existing etcd versions

Stability and performance improvements

Compatibility with recommended Patroni/PostgreSQL HA configurations

Alignment with global infrastructure standards

Reference:

https://dev.oud.ubc.net/bbs/fs/hosting/database/apac-db-reliability/issues/224�

Maintenance Window

Activity to be performed during weekend maintenance window

Exact schedule to be coordinated with application teams

Changes will be executed in a phased and controlled manner

Implementation Plan

Identify current etcd version on all 39 servers

Notify stakeholders and finalize maintenance schedule

Take configuration and data backups

Perform rolling upgrade of etcd nodes cluster by cluster

Validate:

etcd cluster health

Patroni status

PostgreSQL connectivity

Perform controlled failover tests

Post-upgrade monitoring and verification

Rollback Plan

Revert etcd to previous version if any instability occurs

Restore prior configuration backups

Revalidate cluster functionality

Teams Involved

Database Operations Team

Global Infrastructure Team

Respective Application Owners (for validation)

Acceptance Criteria

All 39 servers successfully upgraded to target etcd version

PostgreSQL clusters fully operational post upgrade

Patroni leader election and failover working as expected

No unplanned downtime or data inconsistency

Priority

High

Timeline

Planning and communication: 

Execution window: Weekend 

Post validation: Following business day

If you share the current etcd version and target version, I can refine the issue further with exact technical details 👍

Posted By Nikhil17:25

0

Continue Reading