Hi Pawel, thanks for reaching out. I had already signed off yesterday.

Happy to connect today — just let me know a time that works for you, and I’ll be around.

Posted By Nikhil01:41

0

Continue Reading

 Hi Team,

Thank you for raising the change request for the database switchover as part of your BCM plan.

As per the standard process, BCM switchovers are executed via automation. We request you to please raise one RITM ticket (Automated – BCM Database Switchover). Once submitted, this will trigger the automation workflow and provide you with the required control to initiate the database switchover independently.

You can find the detailed steps and process documentation here:

[Insert Link Here]

Kindly ensure the RITM is raised well in advance of the planned implementation window to avoid any delays.

During the day of implementation, if you encounter any issues while executing the BCM activity, the Database Team will be available on #channel-name for immediate support.

Please let us know once the RITM is raised.

Posted By Nikhil17:33

0

Continue Reading

 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