[DRE-maint] Bug#901379: gitlab: postinst script should not call psql if database is not managed by dbconfig-common
Package: gitlab
Version: 13.4.7-1~fto10+1
Followup-For: Bug #901379
Dear Maintainer,
attached you find a patch, that checks whether the configured database
host is "localhost".
The initialization procedure (which works only locally, at the moment)
is only executed if this check succeeds.
The proper solution would probably be to use a rake/rails tool for
sending the database initialization script (structure.sql), but this
does not seem to be possible at the momemnt (according to an IRC
discussion on #debian-gitlab).
Cheers,
Lars
--- /usr/lib/gitlab/scripts/rake-tasks.sh.orig 2020-12-12 19:27:28.938197472
+0100
+++ /usr/lib/gitlab/scripts/rake-tasks.sh 2020-12-12 19:11:29.465932077
+0100
@@ -13,8 +13,11 @@
runuser -u ${gitlab_user} -- sh -c '/usr/bin/bundle install --local'
# Check if the db is already present
+db_host=$(sed -n '/^production:$/,/^$/p' /etc/gitlab/database.yml | grep
"host:" | awk '{print $2}')
db_relations="$(LANG=C runuser -u postgres -- sh -c "psql gitlab_production -c
\"\d\"" 2>&1)"
-if [ "$db_relations" = "No relations found." ] || \
+if [ -n "$db_host" ] && [ "$db_host" != "localhost" ]; then
+ echo "gitlab_production database is remote ($db_host), assuming it is
already initialized"
+elif [ "$db_relations" = "No relations found." ] || \
[ "$db_relations" = "Did not find any relations." ]; then
echo "Initializing database..."
test -f ${gitlab_home}/db/structure.sql || \
___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] Bug#901379: gitlab: postinst script should not call psql if database is not managed by dbconfig-common
On Fri, 11 Dec 2020 23:53:27 +0100 wrote: > Hello, > > I encounter the same problem (psql directly used in postinst script) during > every package upgrade. > > The main problem (in my case) is the misdetection of an uninitialized database > (see "db_relations" in /usr/lib/gitlab/scripts/rake-tasks.sh). > The script checks via "psql" (locally), whether the database is already > populated. Since the database is empty, the initial database setup is started > (this time using rake for interacting with the configured external database). > This initialization fails, since the real database is not empty. > Thus postinst fails. > > My current workaround is to run the following loop in a separate shell: > > while sleep 1; do sed -i 's/db_relations"/db_relationsXXX"/' \ >/usr/lib/gitlab/scripts/rake-tasks.sh; done > > This overrides the test for an empty database. > Another approach could be to simply populate the local (unused) database. > > The proper solution would be to use the *configured* database connection > instead of running "psql" directly. Maybe this could be done via rake? > > If you could give me any hints in this direction, then I could propose a patch > for fixing the database accesses in the postinst other related scripts. We can read dbc_dbserver value from /etc/dbconfig-common/gitlab.conf and use psql -h $dbc_dbserver to check remotely. ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] Bug#901379: gitlab: postinst script should not call psql if database is not managed by dbconfig-common
Hello, I encounter the same problem (psql directly used in postinst script) during every package upgrade. The main problem (in my case) is the misdetection of an uninitialized database (see "db_relations" in /usr/lib/gitlab/scripts/rake-tasks.sh). The script checks via "psql" (locally), whether the database is already populated. Since the database is empty, the initial database setup is started (this time using rake for interacting with the configured external database). This initialization fails, since the real database is not empty. Thus postinst fails. My current workaround is to run the following loop in a separate shell: while sleep 1; do sed -i 's/db_relations"/db_relationsXXX"/' \ /usr/lib/gitlab/scripts/rake-tasks.sh; done This overrides the test for an empty database. Another approach could be to simply populate the local (unused) database. The proper solution would be to use the *configured* database connection instead of running "psql" directly. Maybe this could be done via rake? If you could give me any hints in this direction, then I could propose a patch for fixing the database accesses in the postinst other related scripts. Cheers, Lars ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] Bug#901379: gitlab: postinst script should not call psql if database is not managed by dbconfig-common
On Tue, 12 Jun 2018 11:56:45 +0200 Frederik Himpe wrote: > Package: gitlab > Version: 10.7.5+dfsg-2~bpo9+1 > Severity: normal > > Dear Maintainer, > > the gitlab.postinst script fails to enable the pg_trgm extension if > there is no locally running postgresql database: > > Setting up gitlab (10.7.5+dfsg-2~bpo9+1) ... > Creating/updating gitlab user account... > Making gitlab owner of /var/lib/gitlab... > Creating runtime directories for gitlab... > Updating file permissions... > Configuring hostname and email... > Configuring nginx with HTTPS... > Configuring gitlab with HTTPS... > Updating gitlab_url in gitlab-shell configuration... > Registering /usr/lib/tmpfiles.d/gitlab.conf via ucf > /etc/systemd/system/gitlab-mailroom.service.d/override.conf already > exist > /etc/systemd/system/gitlab-unicorn.service.d/override.conf already exist > /etc/systemd/system/gitlab-sidekiq.service.d/override.conf already exist > /etc/systemd/system/gitlab-workhorse.service.d/override.conf already > exist > Registering /etc/gitlab-shell/config.yml via ucf > Registering /etc/gitlab/gitlab.yml via ucf > Registering /etc/gitlab/gitlab-debian.conf via ucf > dbconfig-common: writing config to /etc/dbconfig-common/gitlab.conf > dbconfig-common: flushing administrative password > psql: could not connect to server: No such file or directory > Is the server running locally and accepting > connections on Unix domain socket > "/var/run/postgresql/.s.PGSQL.5432"? > dpkg: error processing package gitlab (--configure): >subprocess installed post-installation script returned >error exit status 2 > > I chose to not manage the postgresql database by dbconfig because I am using > an externally running database. In that case this command should not be run. > > > -- System Information: > Debian Release: 9.4 > APT prefers stable > APT policy: (600, 'stable'), (550, 'proposed-updates'), (500, 'oldstable'), > (450, 'oldstable-proposed-updates'), (420, 'testing'), (200, 'unstable'), > (160, 'experimental'), (150, 'oldoldstable'), (140, > 'oldoldstable-proposed-updates') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages gitlab depends on: > ii adduser3.115 > ii apache2 [httpd]2.4.25-3+deb9u4 > ii asciidoctor1.5.6.2-2~bpo9+1 > ii bc 1.06.95-9+b3 > ii bundler1.13.6-2 > ii dbconfig-pgsql 2.0.9~bpo9+1 ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] Bug#901379: gitlab: postinst script should not call psql if database is not managed by dbconfig-common
On Tue, 12 Jun 2018 11:56:45 +0200 Frederik Himpe wrote: > Package: gitlab > Version: 10.7.5+dfsg-2~bpo9+1 > Severity: normal > > Dear Maintainer, > > the gitlab.postinst script fails to enable the pg_trgm extension if > there is no locally running postgresql database: > > Setting up gitlab (10.7.5+dfsg-2~bpo9+1) ... > Creating/updating gitlab user account... > Making gitlab owner of /var/lib/gitlab... > Creating runtime directories for gitlab... > Updating file permissions... > Configuring hostname and email... > Configuring nginx with HTTPS... > Configuring gitlab with HTTPS... > Updating gitlab_url in gitlab-shell configuration... > Registering /usr/lib/tmpfiles.d/gitlab.conf via ucf > /etc/systemd/system/gitlab-mailroom.service.d/override.conf already > exist > /etc/systemd/system/gitlab-unicorn.service.d/override.conf already exist > /etc/systemd/system/gitlab-sidekiq.service.d/override.conf already exist > /etc/systemd/system/gitlab-workhorse.service.d/override.conf already > exist > Registering /etc/gitlab-shell/config.yml via ucf > Registering /etc/gitlab/gitlab.yml via ucf > Registering /etc/gitlab/gitlab-debian.conf via ucf > dbconfig-common: writing config to /etc/dbconfig-common/gitlab.conf > dbconfig-common: flushing administrative password > psql: could not connect to server: No such file or directory > Is the server running locally and accepting > connections on Unix domain socket > "/var/run/postgresql/.s.PGSQL.5432"? > dpkg: error processing package gitlab (--configure): >subprocess installed post-installation script returned >error exit status 2 > > I chose to not manage the postgresql database by dbconfig because I am using > an externally running database. In that case this command should not be run. > > > -- System Information: > Debian Release: 9.4 > APT prefers stable > APT policy: (600, 'stable'), (550, 'proposed-updates'), (500, 'oldstable'), > (450, 'oldstable-proposed-updates'), (420, 'testing'), (200, 'unstable'), > (160, 'experimental'), (150, 'oldoldstable'), (140, > 'oldoldstable-proposed-updates') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages gitlab depends on: > ii adduser3.115 > ii apache2 [httpd]2.4.25-3+deb9u4 > ii asciidoctor1.5.6.2-2~bpo9+1 > ii bc 1.06.95-9+b3 > ii bundler1.13.6-2 > ii dbconfig-pgsql 2.0.9~bpo9+1 ___ Pkg-ruby-extras-maintainers mailing list Pkg-ruby-extras-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers
[DRE-maint] Bug#901379: gitlab: postinst script should not call psql if database is not managed by dbconfig-common
Package: gitlab Version: 10.7.5+dfsg-2~bpo9+1 Severity: normal Dear Maintainer, the gitlab.postinst script fails to enable the pg_trgm extension if there is no locally running postgresql database: Setting up gitlab (10.7.5+dfsg-2~bpo9+1) ... Creating/updating gitlab user account... Making gitlab owner of /var/lib/gitlab... Creating runtime directories for gitlab... Updating file permissions... Configuring hostname and email... Configuring nginx with HTTPS... Configuring gitlab with HTTPS... Updating gitlab_url in gitlab-shell configuration... Registering /usr/lib/tmpfiles.d/gitlab.conf via ucf /etc/systemd/system/gitlab-mailroom.service.d/override.conf already exist /etc/systemd/system/gitlab-unicorn.service.d/override.conf already exist /etc/systemd/system/gitlab-sidekiq.service.d/override.conf already exist /etc/systemd/system/gitlab-workhorse.service.d/override.conf already exist Registering /etc/gitlab-shell/config.yml via ucf Registering /etc/gitlab/gitlab.yml via ucf Registering /etc/gitlab/gitlab-debian.conf via ucf dbconfig-common: writing config to /etc/dbconfig-common/gitlab.conf dbconfig-common: flushing administrative password psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? dpkg: error processing package gitlab (--configure): subprocess installed post-installation script returned error exit status 2 I chose to not manage the postgresql database by dbconfig because I am using an externally running database. In that case this command should not be run. -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (600, 'stable'), (550, 'proposed-updates'), (500, 'oldstable'), (450, 'oldstable-proposed-updates'), (420, 'testing'), (200, 'unstable'), (160, 'experimental'), (150, 'oldoldstable'), (140, 'oldoldstable-proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gitlab depends on: ii adduser3.115 ii apache2 [httpd]2.4.25-3+deb9u4 ii asciidoctor1.5.6.2-2~bpo9+1 ii bc 1.06.95-9+b3 ii bundler1.13.6-2 ii dbconfig-pgsql 2.0.9~bpo9+1 ii debconf [debconf-2.0] 1.5.61 ii git1:2.17.1-1~bpo9+1 ii gitlab-shell 7.1.2+dfsg-2~bpo9+1 ii gitlab-workhorse 4.2.1+debian-2~bpo9+1 ii init-system-helpers1.48 ii lsb-base 9.20161125 ii nodejs 8.11.1~dfsg-2~bpo9+1 ii npm1.4.21+ds-2~bpo9+1 ii openssh-client 1:7.4p1-10+deb9u3 ii postfix [mail-transport-agent] 3.1.8-0+deb9u1 ii postgresql-client 9.6+181+deb9u1 ii postgresql-client-9.6 [postgresql-client] 9.6.7-0+deb9u1 ii postgresql-contrib 9.6+181+deb9u1 ii rake 12.3.1-1~bpo9+1 ii redis-server 5:4.0.9-2~bpo9+1 ii ruby 1:2.3.3 ii ruby-ace-rails-ap 4.1.1-1 ii ruby-acts-as-taggable-on 5.0.0-2~bpo9+1 ii ruby-addressable 2.5.2-1~bpo9+1 ii ruby-akismet 2.0.0-1 ii ruby-allocations 1.0.3-1+b2 ii ruby-arel 6.0.4-1~bpo9+1 ii ruby-asana 0.6.0-1~bpo9+1 ii ruby-asciidoctor-plantuml 0.0.8-1~bpo9+1 ii ruby-asset-sync2.2.0-2~bpo9+1 ii ruby-attr-encrypted3.1.0-1~bpo9+1 ii ruby-babosa1.0.2-2 ii ruby-base320.3.2-3 ii ruby-batch-loader 1.2.1-1~bpo9+1 ii ruby-bcrypt-pbkdf 1.0.0-1~bpo9+1 ii ruby-bootstrap-form2.7.0-1~bpo9+1 ii ruby-bootstrap-sass3.3.5.1-5 ii ruby-browser 2.2.0-2 ii ruby-carrierwave 1.2.2-1~bpo9+1 ii ruby-charlock-holmes 0.7.5-1~bpo9+1 ii ruby-chronic 0.10.2-3 ii ruby-chronic-duration 0.10.6-1 ii ruby-commonmarker 0.17.9-1~bpo9+1 ii ruby-connection-pool
