Backup/Restore failing on projects created after GitLab 8.7 update

I ran backup on one computer and restored to a new server.

On the new server all projects created after the 8.7 update are showing 500 errors.

Below is the content from the production log

Started GET "/NAMESPACE/PROJECT" for 127.0.0.1 at 2016-04-28 08:18:42 -0700
Processing by ProjectsController#show as HTML
Parameters: {"namespace_id"=>"NAMESPACE", "id"=>"PROJECT"}
Completed 500 Internal Server Error in 35ms (ActiveRecord: 3.7ms)
OpenSSL::Cipher::CipherError (bad decrypt):
app/models/project.rb:419:in `import_url'
app/models/project.rb:449:in `external_import?'
app/models/project.rb:441:in `import?'
app/models/project.rb:457:in `import_in_progress?'
app/controllers/projects_controller.rb:93:in `show'
lib/gitlab/middleware/go.rb:16:in `call'

I'm experiencing exactly the same issue, downgrading for now, but this does not seem to be related to projects created after 8.7 version, i've just done backup on 8.0.2, then on local computer migrated to 8.7, backuped that, and then restored 8.7 backup on cluster.

I am experiencing this issue after upgrading from 8.7 to 8.7.1. Getting a 500 error whenever I try too access /

$user/$

project and the production log has:

`Started GET "/

$user/$

project" for 127.0.0.1 at 2016-05-04 15:23:28 +1000 Processing by ProjectsController#show as HTML Parameters: {"namespace_id"=>"

$user", "id"=>"$

project"} Completed 500 Internal Server Error in 70ms (ActiveRecord: 13.8ms)

OpenSSL::Cipher::CipherError (bad decrypt): app/models/project.rb:419:in 'import_url' app/models/project.rb:449:in 'external_import?' app/models/project.rb:441:in 'import?' app/models/project.rb:457:in 'import_in_progress?' app/controllers/projects_controller.rb:93:in 'show' lib/gitlab/middleware/go.rb:16:in 'call'`

I have replaced user and project names with variables in the above log.

Any help with this?

mentioned in issue #17269 (closed)

I looked a little closer at this. The error only occurs on the project main page:

https://donmainame.com/namespace/project

Does not work.

https://donmainame.com/namespace/project/activity
https://donmainame.com/namespace/project/issues
https://donmainame.com/namespace/project/wiki 

And others do work.

I have one project where everything works except for viewing the variables section. then the 500 error.

I have a hand full of other projects that are showing all of the symptoms listed here.
they are all showing up on the file level with different permissions than the rest of the projects.
The ones that work are showing 770 for perms. The ones that do not have 755..

I've had exactly the same symptoms as @brians1196 on a single project. After turning the logging level up a notch I saw that it failed after doing a select from the project_import_data table. So after trying somethings I found that setting the project_id field to NULL for project which failed to load the project page worked as a work-around. So far we've not encountered anything missing in the project but it surely has to affect something, so keep a backup of the original values in case thing do go missing.

My environment: Arch with an existing AUR gitlab installation which got 'migrated' to the community repos (with different configuration sadly). Which caused plenty of file-rights issues so this is likely another one.

mentioned in issue #17486 (closed)

I have this too (same as @brians1196): A single project is 500'ing, while others work fine. I just upgraded from 8.7.2 to 8.7.5. Production log shows the same stack:

Started GET "/Internal/pxeboot" for 127.0.0.1 at 2016-05-20 21:46:33 +0200
Processing by ProjectsController#show as HTML
  Parameters: {"namespace_id"=>"Internal", "id"=>"pxeboot"}
Completed 500 Internal Server Error in 48ms (ActiveRecord: 3.3ms)

OpenSSL::Cipher::CipherError (bad decrypt):
  app/models/project.rb:419:in `import_url'
  app/models/project.rb:449:in `external_import?'
  app/models/project.rb:441:in `import?'
  app/models/project.rb:457:in `import_in_progress?'
  app/controllers/projects_controller.rb:93:in `show'
  lib/gitlab/middleware/go.rb:16:in `call'

When upping log level to debug, I get the same pattern as @Johnnei: it fails right after a SELECT "project_import_data".* FROM "project_import_data" WHERE "project_import_data"."project_id" = $1 LIMIT 1. I haven't been in the postgresql to fix it like Johan did though. The most important part (being able to push and pull) still works.

I'm having the same issue after importing my backup into a new installation if 8.7.3.ee. Possible linked with #17873 (closed)

Solution in #17873 (closed) worked for my omnibus backup to another machine.

First, copy db_key_base in /etc/gitlab/gitlab-secrets.json from the old instance to the new.

Then run:

sudo gitlab-rails runner  "Project.where.not(import_url: nil).each { |p| p.import_data.destroy if p.import_data }"

mentioned in issue #13749 (closed)

Added backup-restore label

mentioned in issue #21564 (moved)

Mentioned in issue #24458 (closed)

Thanks @pstieber it helped me, had the same issue

moved to gitlab#4791

Hey! 👋

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue