%postrans scriptlet failed when installing gitlab-ce-17.0.1 behind a firewall with a rule to allow traffic only to the gitlab repositories

How to Use GitLab
1

Hi all,

I installed self-managed gitlab-ce-17.0.1 from rpm package fresh on a new RHEL 8.X server after successfully adding the GitLab repos, and I received the following error regarding a post installation script. I can’t confirm this because I’m not sure, but I believe the %posttrans scriptlet may have failed because I have not yet set up the Load Balancing service and the subdomain (gitlab17.domain.com) for example. I’m planning to set up the domain and the Load Balancing service today.

  1. Will this scriptlet execution failure effect my gitlab-ce installation?

  2. Do I need to rerun this post installation script after I’ve set up the subdomain and load Balancing service for gitlab?

I should mention that I am not familiar with letsencrypt and there is a firewall rule allowing this server to reach out to the gitlab repositories, so if this scriptlet is trying to reach out to another resource on the internet, that will fail every time unless I add another firewall rule.

Thank you for your help!

Running handlers:
[2024-07-02T16:18:33-04:00] ERROR: Running exception handlers
There was an error running gitlab-ctl reconfigure:

letsencrypt_certificate[gitlab17.domain.com] (letsencrypt::http_authorization line 6) had an error: Acme::Client::Error::Timeout: acme_certificate[staging] (letsencrypt::http_authorization line 43) had an error: Acme::Client::Error::Timeout: Acme::Client::Error::Timeout


Notes:
Default admin account has been configured with following details:
Username: root
Password: You didn't opt-in to print initial root password to STDOUT.

NOTE: Because these credentials might be present in your log files in plain text, it is highly recommended to reset the password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.

Running handlers complete
[2024-07-02T16:18:33-04:00] ERROR: Exception handlers complete
Infra Phase failed. 486 resources updated in 06 minutes 07 seconds

Notes:
Default admin account has been configured with following details:
Username: root
Password: You didn't opt-in to print initial root password to STDOUT.

NOTE: Because these credentials might be present in your log files in plain text, it is highly recommended to reset the password following https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password.

[2024-07-02T16:18:33-04:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/cinc-stacktrace.out
[2024-07-02T16:18:33-04:00] FATAL: ---------------------------------------------------------------------------------------
[2024-07-02T16:18:33-04:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT
[2024-07-02T16:18:33-04:00] FATAL: ---------------------------------------------------------------------------------------
[2024-07-02T16:18:33-04:00] FATAL: Acme::Client::Error::Timeout: letsencrypt_certificate[gitlab17.domain.com] (letsencrypt::http_authorization line 6) had an error: Acme::Client::Error::Timeout: acme_certificate[staging] (letsencrypt::http_authorization line 43) had an error: Acme::Client::Error::Timeout: Acme::Client::Error::Timeout
warning: %posttrans(gitlab-ce-17.0.1-ce.0.el8.x86_64) scriptlet failed, exit status 1

Error in POSTTRANS scriptlet in rpm package gitlab-ce
  Verifying        : gitlab-ce-17.0.1-ce.0.el8.x86_64                                                                                                                                                                         1/1
Installed products updated.

Installed:
  gitlab-ce-17.0.1-ce.0.el8.x86_64

Complete!
2

From what I see is the server cannot communicate with letsencrypt to be able to generate/renew an SSL certificate. So if you have restricted internet access, then you will need to allow access for your server to talk with letsencrypt. Either that or use purchased certificates already generated if you cannot allow access to generate dynamically with letsencrypt.

The server will most likely need to be accessible on the internet as well for the renewal to occur, since letsencrypt servers will want to verify connectivity as well during the renewal process.

More here on all that from Gitlab Docs: Configure SSL for a Linux package installation | GitLab