Hi, I'm new here to the forums and to TurnKey Linux. From what I've been reading, this is a great community! And TurnKey Linux is awesome! But anyway...

I'm running an OpenVZ container with GitLab on Proxmox version 2.2. I downloaded the template from Proxmox, and I've downloaded it from here as an OpenVZ container. I've followed the steps to enable the OpenVZ console, so that's not a problem. I can get to the GitLab login page, and login with username/email - 'admin@example.com' and password - 'turnkey'. I tried creating a new project, but I'm asked by GitLab to create an SSH key (which the appliance does for us.) So I went to 'My profile', then 'Add public key.' I pasted in the key I found in '/home/git/gitlab.pub' and removed the line breaks. The key is added successfully (or so it says). I am then instructed by GitLab to 'push the repository.' So I go to the IP that GitLab is given followed by ':12320' for the web shell. At this point, (GitLab has already created the repo) I cd into '/home/git/repositories/example.git'. I try a 'git status', gives some error, so I type 'git init' to initialize an 'empty branch'. I then type, 'git remote add origin git@git.example.com:example.git'. That goes okay. I type 'git push -u origin master' and it prompts for a password. I've put in every password I know of and it does not work. I typed 'ssh -vvv git@git.example.com' and it gives me some output that looks like it's looking for the key in '/root/.ssh/ida_rsa' and doesn't find it there. Any ideas?

 

In advance, I apologize for this obscenely large post. :)

Forum: 
Jeremy Davis's picture

All OVZ containers need to be initialised prior to first use:

tunkey-init

Hopefully that will solve your issues!?

I have been using the GitLab appliance and don't recall having to go though the steps you are talking about (although I did have to add my key to be able to push to the server from my laptop). I have used it only externally though - as in how you would use GitHub - not from within the GitLab appliance (as it sound like you are).

Doing 'turnkey-init' seems to have broken it. The GitLab service doesn't exist anymore and now nginx gives a '502 Bad Gateway' message. I should have mentioned that I tried another way as well. I used tkliso2ovz to convert the GitLab ISO into an OpenVZ Container and that seems to run 'turnkey-init' on first boot. All of the ways I've tried, I get the original result. Adding the SSH key and then I am unable to push a repo because it doesn't like any password I give it. I should also add at this point that if I try 'ssh-add' it says 'Could not open a connection to your authentication agent.' And when I try 'pgrep ssh' nothing appears so I'm assuming there isn't an SSH process running. Also, I add the SSH key through the GitLab web interface and it takes it just fine. I just can't push a repo which then complains the password isn't right. Doing 'ssh -vvv git@git.example.com:example.git' complains that it can't connect either.

Jeremy Davis's picture

I think that is a good sign. Let me guess, you are running it with less than 1GB RAM? The fact that you get a 502 and the service isn't running is because it stalls due to not enough RAM. Or at least that's what I've experienced.

I am running the TKL OVZ build direct from within the PVE UI (which is the build that is hosted on SourceForge). When I was mucking around trying to update it I launched about 6 instances of it and it just worked OOTB (when given 1GB RAM and after running 'turnkey-init'). Although in fairness I never tested pushing to any of the 6 test instances I created (just the first that I used). I do recall having to manually start shh via the host console on very first boot.

When I get a chance tonight I'll try a fresh instance ang see how it goes...

Well, I was unaware that there were 2 'create project' buttons. The one that works for me is in the 'admin' section. I didn't realize I had to add a key if you use the other one. As far as the SSH thing, that would be ignorance on my part. I generated the key IN the appliance and tried to use it IN the appliance. So that would explain why it wouldn't work correctly. I'm pretty new to version control and SSH. Anyway, Thanks Jeremy for all your help. I really appreciate it.

Jeremy Davis's picture

Glad to hear that you got it sorted and that you are all go! :)

Jeremy Davis's picture

As v14.0 is a totally fresh install of the latest version; built on top of the latest version of Debian it is highly unlikely that any issue with v14.0 will be relevant to old issues... Hence best to start a new thread...

Anyway, in response to your question...:

After a bit of troubleshooting I can confirm that there is a pretty serious issue with v14.0 GitLab app. Not only does the inithook not work to setup the admin account; it seems that doing it via the commandline doesn't work either...

So sorry but at this point GitLab is broken with no easy fix :(

I have lodged a bug report: https://github.com/turnkeylinux/tracker/issues/465

Jeremy Davis's picture

We will update the appliance itself soon but in the meantime there is a fix available. To install the fix, do this from the commandline within your GitLab server:
URL=https://raw.githubusercontent.com/JedMeister/gitlab/anton-inithook_fix
wget $URL/gl_fix
chmod +x gl_fix
./gl_fix
Then follow the prompts to reset your admin password, admin user email and domain name.

Note: There seems to be some minimum password complexity requirements but I'm not 100% sure what they are. A 6 character password using only lowercase was accepted but I couldn't login. I didn't exhaustively test it but it appears that a password with at least 8 characters including a number will work.

It will take a while for the script to complete but you should then be able to log in using your email and the new password. If you get a 504 error when you try to log in it means that the GitLab process hasn't finished starting so just wait and try again (when testing I just closed the browser window, reopened it and it was working).

Jeremy Davis's picture

Are you running in a container? If so that is a known bug as contianers don't have systemd. We hope to resolve this ASAP. We probably should pull the container version for now though.

In the meantime you'll need to use one of the other build types (in a VM rather than a container). FWIW the appliance (in other builds e.g. ISO, OVA, etc) has been fixed and re-released (so should work OOTB now).

Jeremy Davis's picture

Thanks for the initial report and also thanks for confirming that the fix worked for you too...

Add new comment