Forum: 

[SOLVED] Problem with Gitlab in an OpenVZ container

Fibo's picture

(First post here, hope this is the right place)

I am getting mad trying to use a GitLab server I have installed in a OpenVZ container as available here from http://www.turnkeylinux.org/download?file=openvz/debian-7-turnkey-gitlab...

Everything seems to go fine on the server... but from my local client I cannot either pull or push to the repositories: I am asked for 'git' password... but giving its Unix password does not work.

In fact, when on the server I cd to the directory under /home/git/repositories/ which I presume to be a git repository, 'git status' just answers 'fatal: This operation must be run in a work tree'

Obviously I am doing something wrong... if only I knew what!

 

Jeremy Davis's picture

I will have a look when I get a chance...

If you haven't heard back in a day or so, please feel free to bumo this thread to give me a nudge! :)

Fibo's picture

Hi Jeremy,

As kindly suggested, just reminding you to have a look at my problem.

Since I am almost a complete newbie on Linux, I exepect I erred on a very simple step... but now I am just trapped with no very clear understanding of the direction I should dig...

B-)

 

Thx for your pateience and help

Bernard

Jeremy Davis's picture

I did install it but that was as far as i got...

I'll try to have a look ASAP and get back to you.

Sorry for the delay and thanks for your patience! :)

Jeremy Davis's picture

From a glance, it looks like you will need to set up your user (and password) in GitLab first (or use the default Administrator user and the corresponding password you set with the init scripts).

I haven't tested it but it looks to me like you'll also need to create the initial project in GitLab before you do anything else. I would assume that you should be able to pull publicly (assuming that you haven't set the repo/project as private) but it looks like you won't be able to push until you have added your relevant SSH key (which makes sense...)

If you have done all that and still having issues, let me know and I'll test a bit further...

Fibo's picture

SOLVED but this problem may happen to others using OpenVZ containers.

- If you want to use your container with a static IP, you need to define it BEFORE acessing to the machine with "vzctl enter xxx"

- You can define the MAC address of eth0 within Proxmox GUI, but not what is needed to define the static IP

- Happily, you can define that from the proxmox host shell: just edit /etc/network/interfaces in /var/lib/vz/private/xxx and change the default dhcp config for eth0 as

auto eth0
iface eth0 inet static
        address (container IP address)
        netmask 255.255.255.255
        broadcast (container IP address)

        post-up route add (host / bridge access) dev eth0
        post-up route add default (host / bridge access)
        post-down route del (host / bridge access) dev eth0
        post-down route del default gw (host / bridge access)

- You can now start the machine from Proxmox and from proxmox shell type "vzctl enter xxx": you will run thru the TKL init script

- I was used to edit /etc/network/interfaces after vzctl enter: with a TKL template this fails miserably because TKL expects to have a complete internet access, which it has not!;

Jeremy Davis's picture

My understanding is that the defacto-standard is to avoid using veth whenever possible, and preference usage of venet (which AFAIK requires that you set an IP, DNS, etc on creation - although maybe not? It's what I've always done...).

Past reading suggested that venet provides both a faster, more efficient network interface, plus is more secure. The only time I have ever required a veth is for my DHCP server, although I think it is also required if you wish to run a Samba server that broadcasts on the network... (and probably any other service that requires that it broadcast across the network).

TBH it never occurred to me that you would be using veth, my bad on that part...

Fibo's picture

I am not that "openvz-fluent"... so I use the recipes that have worked for me before.

I will dig the venet route you suggest.

Note that my containers are servers we access over the internet for web and some services: therefore we need fixed static IP since they are defined in the dns, and that also I restrict access by IP (rather than name) since these are usually robots testing access

Jeremy Davis's picture

venet is ideal for that IMO as you set the static IP on creation...

Post new comment