Stop marking the smartcard NGINX server as default_server
What does this MR do?
The smart card NGINX server is rendered from the Rails server's template, so since !8805 (merged) made the Rails server the default_server, the smart card server claims it too, and NGINX does not start when the two share a port:
- with
nginx['redirect_http_to_https'] = true, port 80 (the error in the issue); - with
smartcard_client_certificate_required_hostset andsmartcard_client_certificate_required_portat 443, port 443.
This sets default_server_enabled: false for the smart card server only. The Rails server keeps default_server, and the smart card server's listen lines render as they did before !8805 (merged). nginx -t passes in both cases, where master fails.
!9899 carries the same nginx.rb change and has had no review requested since it was opened in October.
How to validate locally
-
In
/etc/gitlab/gitlab.rb, with a certificate and key for the host in/etc/gitlab/ssl/and a CA file at/etc/gitlab/ssl/CA.pem:external_url 'https://gitlab.example.com' nginx['redirect_http_to_https'] = true gitlab_rails['smartcard_enabled'] = true -
Run
sudo gitlab-ctl reconfigure, thensudo gitlab-ctl status nginx. Before this change NGINX is down with the issue's error; with it, NGINX runs.
Specs and nginx -t
In ruby:3.3.12 with the project's bundle, at this branch rebased on master at 8afb888b:
$ bundle exec rspec spec/chef/cookbooks/nginx/recipes/nginx_spec.rb -e smartcard # this spec, master's nginx.rb
9 examples, 4 failures
$ bundle exec rspec spec/chef/cookbooks/nginx/recipes/nginx_spec.rb spec/chef/cookbooks/gitlab/recipes/nginx_disable_spec.rb spec/chef/cookbooks/gitlab/recipes/gitlab-rails/gitlab_yml/smartcard_spec.rb
117 examples, 0 failures
$ bundle exec rubocop files/gitlab-cookbooks/gitlab/recipes/nginx.rb spec/chef/cookbooks/nginx/recipes/nginx_spec.rb
2 files inspected, no offenses detectedThe four failures on master are the two new smart card examples and the two listen *:3444 expectations this MR changes back.
nginx -t with NGINX 1.31.4 built as config/software/nginx.rb builds it (VTS and security headers modules), on the files ChefSpec renders:
master, redirect: [emerg] a duplicate default server for 0.0.0.0:80 in .../gitlab-smartcard.conf:35
master, shared port 443: [emerg] a duplicate default server for 0.0.0.0:443 in .../gitlab-smartcard.conf:35
this branch, both: test is successfulWith the redirect, this branch also prints conflicting server name "gitlab.example.com" on 0.0.0.0:80, ignored. Master with the issue's workaround prints the same, so I left it alone. I did not test on a package install.
Related issues
Closes #9518
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion.
Required
- MR title and description are up to date, accurate, and descriptive.
- MR targeting the appropriate branch.
- Latest Merge Result pipeline is green.
- When ready for review, MR is marked as ready (not a draft) and a reviewer is requested. Pick the reviewer suggested by the reviewer roulette, or one of the project maintainers.
- The UBT version and corresponding checksum hash have been updated and referenced in the merge request if applicable. Not applicable: no software definition changes.
- UBT EE pipeline (
Trigger:ee-package-ubt) is green
- UBT EE pipeline (
For GitLab team members
If you don't have access to this, the reviewer should trigger these jobs for you during the review process.
- The manual
Trigger:ee-packagejobs have a green pipeline running against latest commit.- To debug QA failures, refer to the Investigate QA failures section.
- If
config/softwareorconfig/patchesdirectories are changed, make sure thebuild-package-on-all-osjob within theTrigger:ee-packagedownstream pipeline succeeded. - If you are changing anything SSL related, then the
Trigger:package:fipsmanual job within theTrigger:ee-packagedownstream pipeline must succeed. - If CI configuration is changed, the branch must be pushed to
dev.gitlab.orgto confirm regular branch builds aren't broken.
Expected (please provide an explanation if not completing)
- Test plan indicating conditions for success has been posted and passes. Checked with
nginx -ton the rendered configuration (details above). - Documentation created/updated. Not needed: no setting changes.
- Tests added.
- Integration tests added to GitLab QA. Not added: the specs cover the rendered configuration.
- Equivalent MR/issue for the GitLab Chart opened. Not applicable: the chart does not render these NGINX files.
- Validate potential values for new configuration settings. Formats such as integer
10, duration10s, URIscheme://user:passwd@host:portmay require quotation or other special handling when rendered in a template and written to a configuration file. Not applicable: no new setting.
Reviewer checklist
- As soon as you begin reviewing, select Start a review on your first comment so the MR shows Reviewer started review.