500 error on initial login?

[esalberg]

Hi,

I just did a fresh install of Gitlab on RHEL 6.5 / Puppet 3.8.1 using the module, and I'm getting a 500 error when trying to access /users/sign_in (see below). I found a lot of references to this type of error for upgrades / database migrations, but less for new installations. I'm assuming that the "projects" table would be a default (since I don't have any data that I've added to gitlab yet)?

I'll keep digging, but I thought it was worth asking in case you've seen this error before after an install.

The production.log file says:

Started GET "/users/sign_in" for 127.0.0.1 at 2015-10-27 17:20:15 -0400
Processing by SessionsController#new as HTML
PG::UndefinedTable: ERROR: relation "projects" does not exist
LINE 5: WHERE a.attrelid = '"projects"'::regclass
^
: SELECT a.attname, format_type(a.atttypid, a.atttypmod),
pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = '"projects"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum

Completed 500 Internal Server Error in 15ms (ActiveRecord: 9.7ms)

---

When I tried to troubleshoot by running gitlab-ci-rake commands, it complained about not being able to load files under /opt/gitlab/etc/gitlab-ci - that directory does not appear to exist.

[root@linvm2346 gitlab-rails]# gitlab-ci-rake db:migrate:status
/usr/bin/gitlab-ci-rake error: could not load /opt/gitlab/etc/gitlab-ci/gitlab-ci-rc
Either you are not allowed to read the file, or it does not exist yet.
You can generate it with: sudo gitlab-ctl reconfigure

[root@linvm2346 gitlab-rails]# cd /opt/gitlab/etc
[root@linvm2346 etc]# ls -la
total 48
drwxrwxr-x 3 root root 4096 Oct 27 17:01 .
drwxrwxr-x 9 root root 4096 Oct 27 17:01 ..
drwx------ 3 git root 4096 Oct 27 17:01 gitlab-rails
-rw-rw-r-- 1 root root 35191 Oct 27 08:43 gitlab.rb.template

I tried running gitlab-ctl reconfigure by hand to look for errors, etc., but there weren't any obvious issues (and it still didn't create the gitlab-ci directory).

[esalberg]

Just realized why gitlab-ci-rake of course wouldn't work - here's the output of the correct command:

[root@linvm2346 etc]# gitlab-rake db:migrate:status
Schema migrations table does not exist yet.

[esalberg]

I figured out that I needed to have the following code run:

if is_hash($postgresql) {
  unless $postgresql[enable] {
    exec { 'gitlab_setup':
      command     => '/bin/echo yes | /usr/bin/gitlab-rake gitlab:setup',
      refreshonly => true,
      timeout     => 1800,
      require     => Exec['gitlab_reconfigure'],
      unless      => "/bin/grep complete ${git_data_dir}/postgresql.setup"
    }
    ->
    file { "${git_data_dir}/postgresql.setup":
      content => 'complete'
    }

I don't see anything in the module documentation as to what should be placed into the postgresql hash - I would have tried just using enable => true, but it looks like that would also keep the setup code from firing, which is a bit confusing - am I reading this incorrectly? Is there a basic postgresql hash that can be used for an install that wants to use the defaults but configure the provided postgres db?

Also, it looks like $git_data_dir should be set to /var/opt/gitlab/postgresql/data (when using the default install location from the omnibus / module)? It looks like it defaults to undef, which means that the postgresql.setup file won't be created anywhere useful. The init file doesn't provide much clarification.

I'm happy to make a doc PR after I have this all figured out - I just want to make sure whatever I submit is correct. Thanks!

[tobru]

Maybe we can ping @robbruce / @sd-robbruce, he did the implementation of this part in the module in #15

[tobru]

As I didn't hear back any news on this issue, I'll close it right now. Feel free to open a new one.

[LongLiveCHIEF]

I re-opened this, as I ran into this block of code while working on #159.

I'm going to remove this block entirely, as it's likely to cause problems, (specifically this will cause #195).

Running this command will rebuild authorized keys, and will migrate the db, and neither will be wanted by the admin.

With gitlab 10.4 onward, gitlab has built in support for HA, which has many scenarios where postgres in disabled on a node, but the postgresql hash still has configuration in it allowing the application_role, consul_role, and pgbouncer_role nodes to connect to the postgres database.