Do not claim default_server in the smartcard nginx vhost

devilking7xrequested to merge
devilking7x/omnibus-gitlab:mr-20261011-smartcard-default-server into master

Closes #9518

Problem

With Smartcard authentication enabled and nginx['redirect_http_to_https'] = true, gitlab-ctl reconfigure renders an invalid service_conf/gitlab-smartcard.conf and nginx fails to start:

[emerg] a duplicate default server for 0.0.0.0:80 in /var/opt/gitlab/nginx/conf/service_conf/gitlab-smartcard.conf:35

The smartcard vhost reuses the shared nginx-gitlab-rails.conf.erb template. Commit 264daf92 ("Add nginx['default_server_enabled'] configuration parameter", shipped in 18.5) made the template emit default_server on the :80 redirect block as well as the SSL block. The smartcard config is a secondary server block, so its :80 redirect listener now duplicates the main vhost's default_server on :80 and nginx refuses to start. In 18.4 the smartcard config contained no default_server at all.

Solution

Set default_server_enabled to false in gitlab_rails_smartcard_nginx_vars (files/gitlab-cookbooks/gitlab/recipes/nginx.rb), restoring the pre-18.5 rendering for the smartcard vhost while the main vhost keeps its default_server. Specs updated accordingly, plus a regression spec asserting the smartcard config never contains default_server when redirect_http_to_https is enabled.

Testing

  • Fork pipeline runs 0 jobs by design, so this could not be executed in CI here.
  • Change verified by inspection: the smartcard template variables now force default_server_enabled off, matching the pre-regression (18.4) output shown in the issue.
  • New ChefSpec regression test (spec/chef/cookbooks/nginx/recipes/nginx_spec.rb) covers the exact reported scenario (smartcard_enabled: true + redirect_http_to_https: true) and asserts no default_server appears in the smartcard config while the main vhost keeps its own.

Merge request reports