squash following commits:
- 32f5332b05a6064169e6cc07d9c4a60b6a3dc7c5
for configgitlab-pages/config
- f974a0197c74ca17343e5e3ff99a633347d8ad67
for config/gitlab-shell/config.yml
- 1104bacb29ed7f20bdf20015552299bd08ae7313
for config/gitlabhq/cable.yml
- 6ce37d8706cb289136385a7c498ad8c42faaab2c
for config/gitlabhq/resque.yml
- 7336e042728f63da2cc302b6fd6f975eb26566dc
for config/nginx/gitlab
- 1f39dcaabe7d3daa3b70ef0ae98ea8e30659e1e0
for config/nginx/gitlab-pages
- 76aaf571e992c6e5b970a437f8c46158d9867d65
for config/nginx/gitlab-ssl
- 549f717ec0810c8e11f30fb40f08997c0b84b5e3
for env-defaults but without KAS-related configs
(original: add WEBTOKEN secret, remove GITLAB_KAS_SECRET)
Add environment variable to set entry in secrets.yml related to
active record encryption
- active_record_encryption_primary_key (can be multiple)
- active_record_encryption_deterministic_key (can be multiple)
- active_record_encryption_key_derivation_salt
Reference for '32 characters length' recommendation:
https://gitlab.com/gitlab-org/gitlab/-/blob/v18.0.0-ee/config/initializers/2_secret_token.rb#L78-80
TODO: fix command line usage in documentation
On upstream, expected default value is `127.0.0.1/8`
and it is already listed in corresponding configuration.
`GITLAB_MONITORING_IP_WHITELIST` is used to allow monitoring from hosts other than loopback (localhost).
So just unset default value for it.
If the value is not set, the line specifying this "additional" IP range will be removed.
- It requires database is set up because
feature flags are stored to DB (table `application_settings`)
- Add configuration parameter GITLAB_FEATURE_FLAGS_ENABLE_TARGETS
and GITLAB_FEATURE_FLAGS_DISABLE_TARGETS
- Add ruby script to configure feature flags from command line
and invoke runtime (from configure_gitlab())
see sameersbn/docker-gitlab#2828
The current setup also accepts multiple hosts,
but the syntax is a bit strange.
The leading/trailing double quotes are embedded
in the configuration file itself,
so users should expect double quotes around the string they set.
In other words, when setting two hosts 0.0.0.0 and 1.1.1.1,
you will set the strings 0.0.0.0","1.1.1.1 in the
environment variables. This is not intuitive.
This commit removes double quote around corresponding config
and set backward compatibility fallback process
to surround whole with [], each host with double quote.
Also, validation script (written in ruby) will be executed during configuration.
Example docker-compose.yml
````yaml
services:
gitlab:
image: sameersbn/gitlab:latest
environment:
- RACK_ATTACK_WHITELIST='["127.0.0.1","0.0.0.0"]'
````
Co-authored-by: Mikhail Khadarenka <chodorenko@mail.ru>
There are many warnings like below
recorded in {GITLAB_LOG_DIR}/supervisord/sidekiq.log.
This can be avoided by simply increasing SIDEKIQ_MEMORY_KILLER_MAX_RSS.
----
{
"severity": "WARN",
"time": "[MASKED]",
"class": "Gitlab::SidekiqDaemon::MemoryKiller",
"pid": [MASKED],
"message": "Sidekiq worker RSS out of range",
"current_rss": 1009636,
"soft_limit_rss": 1000000,
"hard_limit_rss": [MASKED],
"memory_total_kb": [MASKED],
"reason": "current_rss(1009636) \u003e soft_limit_rss(1000000)",
"running_jobs": [],
"retry": 0
}
----
For sameersbn/gitlab, this parameter have been introduced with
following commit on May 21, 2015 and never updated until today:
e4008cc7ab9efd626511af4c43e52e2a9490d612
On upstream, the default setting documentation is updated here:
https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31682
but it is said "the documentation is outdated" at this time.
I could not find out when the value is increased.
At least, In omnibus-gitlab, this have been introduced in MR 2360
(release 11.10.0+ce.0 / 11.10.0+ee.0)
https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2360