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)
As a result, an Internet connection is no longer required
to use relative URLs.
To enable relative url, we execute `gitlab:assets:compile`.
This have been removed in official documentation in v10.0.0
(first committed to gitlab-foss, then ported to gitlab(-ee))
- EE: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1139/
- CE: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8831
An internet connection was required when enabling relative urls
to install the node modules required for compilation.
I reviewed the rake task `gitlab:assets:compile` and investigated
whether it was necessary to compile all assets
just because the relative url changed,
and found that this rake task is internally a separate rake task
`gitlab:assets :fix_urls` which rewrite the reference URL in the css.
I removed rake task `gitlab:assets:compile` at runtime
and confirmed that the gitlab application worked normally as before.
I have confirmed that at least the following functions work properly.
- Administrator password reset at first login
- Create empty project
- Edit/add and commit files using web IDE
- Create merge request/issue
- Attach files to comments
- Create empty group
- Move existing project to group
In addition, we no longer need to do following things
- persist node_modules, recompiled assets and caches
- apply patches to gitlab itself to avoid removing (symlink to) node_modules/
This change also reduces startup time in certain cases
when the relative URL feature is enabled
(when assets are compiled; for example,
when performing a version upgrade or changing the relative URL)
(on my environment, `gitlab:assets:fix_urls` took about 20 seconds)
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
Directories such as /etc/nginx/sites-{enabled, available and similar}
are not available for nginx package comes from official nginx repository.
Ubuntu source may create this directory
refer1 : ubuntu distributes nginx with a file "nginx-common.dirs"
which lists these directories
https://git.launchpad.net/ubuntu/+source/nginx/tree/debian/nginx-common.dirs?h=ubuntu/jammy-updates
By default, nginx recognizes configuration files in /etc/nginx/conf.d/
Just change the destination path to install nginx configuration files
instead of `find /usr/lib/postgresql -name pg_isready | sort | tail -n1`
for db readiness query command
To solve following error:
find /var/lib/postgresql : No such file or directory
I'm sure the directory is exists so I'm not sure why the error reported
Access to health check resources such as /-/liveness
is restricted to IPs specified in gitlab.monitoring.ip_whitelist
(`GITLAB_MONITORING_IP_WHITELIST`).
The name `localhost` is solved to IPv6 loopback address (::1)
that is not listed in the whitelist by default.
Possible alternate designs:
- Add IPv6 loopback to whitelist
- Disable IPv6 for gitlab container by specifying `net.ipv6.conf.all.disable_ipv6=1`
in docker-compose.yml for example
See https://github.com/sameersbn/docker-gitlab/issues/2766#issuecomment-2098030791
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.
When the healthcheck feature introduced, the script were generated on build time
and url was fixed to "http://localhost/-/liveness".
See pull request #2102
nginx is configured to redirect all http traffic to https when `GITLAB_HTTPS` is enabled.
(see https://github.com/sameersbn/docker-gitlab/blob/ac9e1fe/assets/runtime/config/nginx/gitlab-ssl#L41-L54),
`--location` option is set to follow the redirection.
See pull request #2165
Health check script generation has been ported to the runtime,
allowing us to dynamically generate health check URLs
while referencing configuration parameters.
See #2338
If configured correctly, the redirect will not occur and the option can be removed.
Original removal suggestion by @Gaibhne , additional (historical) research by @kkimurak.
Co-authored-by: Kazunori Kimura <kkimura@ims.ac.jp>
When generating the list of flags that would actually be enabled,
the value specified in the option was ANDed with the list of flags that actually existed.
At this time, I mistakenly performed a logical AND with the list
of "values to invalidate" specified in the option.
This mistake caused a problem in which some flags could not be enabled.
This commit fixes this to AND with the list of values you want to enable.
like below:
````
Configuring gitlab::feature_flags...
- Launching rails runner to set feature flags. This will take some time....
- Specified feature flags to be disabled:
--- "auto_devops_banner_disabled"
--- "invalid_flag_name"
- Specified feature flags to be enabled
--- "git_push_create_all_pipelines"
--- "another_invalid_flag_name"
- Following flags are probably invalid and have been ignored
--- invalid_flag_name
--- another_invalid_flag_name
- Apply user defined feature flags:
--- auto_devops_banner_disabled : off
--- git_push_create_all_pipelines : on
````
- Do not `puts` parsed options (formatted by ruby's `.to_s`),
`puts` each specified target with three hyphens instead
- `puts` each ignored target on each line with three hyphens instead of single line csv
- 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())
There was an issue that `ajv` is not installed by mistake.
This issue have been fixed on upstream, a few years ago.
Now, we can revert the change.
This commit partially reverts 985d57afb9673b2f5acb1f12cbc13f230f6ec074
See sameersbn/gitlab#1358
It seems that fix MR on upstream is https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14543
but we cannot check diff because source / target branch removed by mistake
Anyway, no need to add ajv as an explicit dependency with (at least) gitlab v11 or later
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>
Handle the case where the target does not exist
in the process of deleting unused clients.
Such a situation will not occur in newly launched containers,
but will occur if they are restarted.
During container restarts, container status are preserved.
If the unused database client was deleted in the last run,
grep will not match anything.
It returns non-zero code and the container stops there
because entrypoint sets option `-e`
(exit immediately on non-zero exit code excluding some special cases)
This commit make the uninstall process to handle the case
UNUSED_DB_CLIENTS is empty.
Unused clients are determinate by checking ~/.postgresqlrc
Uninstall logs like the following will appear in the docker log:
- Uninstalling unused version(s) of client: postgresql-client-12
It is intended to work even in environments without an internet connection.
- Use latest version of pg_isready on checking database connection
- Switch postgresql-client version checking server on startup
- If the server versions do not match exactly, use the latest installed client
and warn on docker log
From postgresql documentation:
https://www.postgresql.org/docs/15/app-pgdump.html#PG-DUMP-NOTES
> Also, it is not guaranteed that pg_dump's output can be loaded
> into a server of an older major version — not even if the dump
> was taken from a server of that version.
To switch client version, generate a file ~/.postgresqlrc with content like:
{server side major version} {server hostname}:{server port} {default database}
See detail on:
https://manpages.ubuntu.com/manpages/bionic/man5/postgresqlrc.5.html
Following messages appear on docker log:
- Detected server version: 140007
- Generating /home/git/.postgresqlrc
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
