Question How to install Gitlab

[one-eyed-king]

Are you sure the user has the matching id_rsa in the ~/.ssh (linux) or %userprofile%/.ssh (windows)?
The only reason left can be either a missmatch between the private key on the client machine and the public key in the Gitlab profile or that the git actions are executed for a different user (after sudo -i for instance).

 

[keyxmakerx]

But again, if I'm able to do it when i'm on the same network as my NAS wouldn't that mean the key is valid and correct?

And yes, I just validated it. I mean i'm doing this via crostini on a chromebook, but i can't imagine that matters in this instance.
Also verified i am using linuxkeymaker, not root. And there is no other accounts on this device.

 

[one-eyed-king]

Good point. Did you set your forward in the router as TCP? Is there nothing in the chain between router and the mapped container port?

Like i wrote earlier: ssh is not domain aware. The ssh port is either reachable and accepts connections or it doesnt.

 

[keyxmakerx]

Yea, I don't think it's a DNS issue, I know it's pointing to the right IP. I mean if I hit 30002 it doesn't work it just times out. So i'm certain it's hitting it to say the least. I just don't know why the server would be denying me. Again it's ported in the router as a TCP range of 30000-30001, and 30000 is the webpage which works just fine.

linuxkeymaker@penguin:~$ ssh [email protected] -p 30002
ssh: connect to host keyxmakerx.synology.me port 30002: Connection timed out
linuxkeymaker@penguin:~$ ssh [email protected] -p 30001
ssh_exchange_identification: Connection closed by remote host

Hm, I haven't tried https yet. Again, used to ssh, but since it's giving me problems let me see what I can do about using that.

 

[one-eyed-king]

The problem can only be somewhere in the chain between the router and the mapped container port. Is the syno firewall disabled for the sake of testing?

Working with git and https sucks big time. It is usalier easier to setup but a nightmare later on - unless you have added a password store. Even though the password store is automaticly integrated in the windows git client, i never wrapped my head arround how to use it with the linux git client.

 

[keyxmakerx]

The problem can only be somewhere in the chain between the router and the mapped container port. Is the syno firewall disabled for the sake of testing?

Working with git and https sucks big time. It is usalier easier to setup but a nightmare later on - unless you have added a password store. Even though the password store is automaticly integrated in the windows git client, i never wrapped my head arround how to use it with the linux git client.

Haha, okay well lets stick with ssh.

Yes, the synology firewall is disabled.

 

[keyxmakerx]

I was trying to check for logs, but for docker it looks like you need rsyslogd, but when i try to install it, it says no candidtate found. I'm not sure why though.

 

[one-eyed-king]

Due to the weird-synology logging driver, I am not sure if the logs are visible in Portainer. But they are visible in the Syno UI.

As you already said: ssh auth works using the Hostname/IP, but does not if access from your WAN. Your WAN connection seem not to even reach the sshd port of the container. Except checking your WAN ports for available with Open Port Check Tool -- Verify Port Forwarding on Your Router and verifiying that your synology.me ip and your wan ip are identical, there is not much left to suggest.

I used to use Gitlab based on sameersbn's compose-file and had no problem to access the repos with ssh.

The only difference in your and my setup is: I have a wildcard domain name pointing to man WAN IP, which gets updated by my routers dyndns capabilites and a container, I do run on a vps, that updates the ip of my wildcard domain via DNS-API of my provider. But I can't imagine how the synology.me adress could be the problem - unless it acts as a reverse proxy.

 

[keyxmakerx]

So, did a port check just to be sure. And what do you know, it wasn't working. Come to find out, when I did a edit on the firewall to allow 30001, it didn't change the port outgoing to, so i had to readd the rule in the firewall and behold it works...

Thanks again for all the help. I've gotten a better grasp into docker, but I am curious. Where would I put the .yml file if I was doing CLI? And i just need to rune docker-compose run command?

 

[one-eyed-king]

congratz!

From the cli, you can put the yml file wherever you want (i would suggest somewhere inside the docker share). I used to have mine in /volumex/docker/{myuser}/{app name}/docker-compose.yml. To start the stack you either cd into the folder /volumex/docker/{myuser}/{app name} and then use docker-compose up -d to start the stack OR use docker-compose -f /volumex/docker/{myuser}/{app name}/docker-compose.yml up -d

After doing changes to the yml file, you just have to execute the command docker-compose up -d to let docker-compose figure out which container needs to be recreated with the new parameters - meanwhile the unchanged containers are kept running.

 

[one-eyed-king]

btw. there is an error in the user-defined script:
portainer_container_id=$(docker ps --filter name=watchtower -qa)

should be:
portainer_container_id=$(docker ps --filter name=portainer -qa)

Due to --restart always the Portainer container will be stopped on NAS shutdown and restarted when the NAS is started again. Since --name portainer is used when the container is created the docker run command will only succeed to create the container once. Though, without the fix it would try and fail to create another container instance, which is a little messy, as it may populate your logs with entries about a failed task.

 

[keyxmakerx]

Thanks for catching that! I've gotten it updated.