Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #219151 > unrolled thread

help with gitlab on buster

Back to article view | Back to linux.debian.user

Contents

  help with gitlab on buster Graham Seaman <graham@theseamans.net> - 2020-02-14 18:20 +0100
    Re: help with gitlab on buster john doe <johndoe65534@mail.com> - 2020-02-14 18:50 +0100
      Re: help with gitlab on buster deloptes <deloptes@gmail.com> - 2020-02-14 19:40 +0100
      Re: help with gitlab on buster Graham Seaman <graham@theseamans.net> - 2020-02-17 00:00 +0100
        Re: help with gitlab on buster john doe <johndoe65534@mail.com> - 2020-02-17 07:40 +0100
          Re: help with gitlab on buster Graham Seaman <graham@theseamans.net> - 2020-02-17 16:30 +0100
            Re: help with gitlab on buster David Wright <deblis@lionunicorn.co.uk> - 2020-02-17 23:50 +0100
              Re: help with gitlab on buster Graham Seaman <graham@theseamans.net> - 2020-02-18 11:20 +0100
                Re: help with gitlab on buster john doe <johndoe65534@mail.com> - 2020-02-18 12:30 +0100
                  Re: help with gitlab on buster Andrei POPESCU <andreimpopescu@gmail.com> - 2020-02-19 09:10 +0100
                    Re: help with gitlab on buster john doe <johndoe65534@mail.com> - 2020-02-19 09:20 +0100
                    Re: help with gitlab on buster <tomas@tuxteam.de> - 2020-02-19 10:00 +0100

#219151 — help with gitlab on buster

I run a debian house server for firewall, routing etc. The last few 
years I've also run gitlab on it, which I use to manage text files I 
work on from an assortment of laptops/PCs; I have a lot of these files 
(currently around 12 Gb) and really don't want to lose them. After the 
initial setup I didn't do anything with the gitlab code and don't even 
remember what version it was.

So this week, without thinking particularly about gitlab, I upgraded 
from stretch to buster. No complaints during the upgrade, but gitlab no 
longer worked (now dependent on a directory called 'embedded' which I 
don't have). So I followed the recommendation on 
https://wiki.debian.org/gitlab to update gitlab using buster-fastrack. 
This installed an alarmingly huge number of ruby and node dependencies, 
then failed informing me that I the database changes were too big to go 
straight from my old version to the current debian one, and that I need 
to transition through version 11.11.0 first.

There is no debian package for this, and 11.11.0 is only available from 
gitlab.com as a docker install, but I'm running directly on my host.

Can anyone suggest how to get myself a working gitlab again. without 
losing the current data? I could live with a command-line only version, 
if I couldn't get the web side working again.

Thanks for any advice

Graham

[toc] | [next] | [standalone]

#219152

On 2/14/2020 5:42 PM, Graham Seaman wrote:
> I run a debian house server for firewall, routing etc. The last few
> years I've also run gitlab on it, which I use to manage text files I
> work on from an assortment of laptops/PCs; I have a lot of these files
> (currently around 12 Gb) and really don't want to lose them. After the
> initial setup I didn't do anything with the gitlab code and don't even
> remember what version it was.
>
> So this week, without thinking particularly about gitlab, I upgraded
> from stretch to buster. No complaints during the upgrade, but gitlab no
> longer worked (now dependent on a directory called 'embedded' which I
> don't have). So I followed the recommendation on
> https://wiki.debian.org/gitlab to update gitlab using buster-fastrack.
> This installed an alarmingly huge number of ruby and node dependencies,
> then failed informing me that I the database changes were too big to go
> straight from my old version to the current debian one, and that I need
> to transition through version 11.11.0 first.
>
> There is no debian package for this, and 11.11.0 is only available from
> gitlab.com as a docker install, but I'm running directly on my host.
>

Cant' you use docker on an other host, for example, in a VM?

> Can anyone suggest how to get myself a working gitlab again. without
> losing the current data? I could live with a command-line only version,
> if I couldn't get the web side working again.
>

First off, backup your data! :)

Basically, my idea would be to find a way to follow the correct upgrade
procedure.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#219153

john doe wrote:

> First off, backup your data! :)

also no one upgrades production stuff without testing the procedure -
right?!

[toc] | [prev] | [next] | [standalone]

#219205

On 14/02/2020 17:39, john doe wrote:
> On 2/14/2020 5:42 PM, Graham Seaman wrote:
>> I run a debian house server for firewall, routing etc. The last few
>> years I've also run gitlab on it, which I use to manage text files I
>> work on from an assortment of laptops/PCs; I have a lot of these files
>> (currently around 12 Gb) and really don't want to lose them. After the
>> initial setup I didn't do anything with the gitlab code and don't even
>> remember what version it was.
>>
>> So this week, without thinking particularly about gitlab, I upgraded
>> from stretch to buster. No complaints during the upgrade, but gitlab no
>> longer worked (now dependent on a directory called 'embedded' which I
>> don't have). So I followed the recommendation on
>> https://wiki.debian.org/gitlab to update gitlab using buster-fastrack.
>> This installed an alarmingly huge number of ruby and node dependencies,
>> then failed informing me that I the database changes were too big to go
>> straight from my old version to the current debian one, and that I need
>> to transition through version 11.11.0 first.
>>
>> There is no debian package for this, and 11.11.0 is only available from
>> gitlab.com as a docker install, but I'm running directly on my host.
>>
> Cant' you use docker on an other host, for example, in a VM?
I've tried that, but never having used docker before found I was just 
mystified at how to use the install to reformat the existing data, as 
would happen during a normal upgrade. I think this route is probably a 
dead end for me, I just don't have the knowledge to do it.
>> Can anyone suggest how to get myself a working gitlab again. without
>> losing the current data? I could live with a command-line only version,
>> if I couldn't get the web side working again.
>>
> First off, backup your data! :)

Of course, though this would be easier if I was more sure where 
everything was. But the data's no use without the software to read it.

> Basically, my idea would be to find a way to follow the correct upgrade
> procedure.

I've found that version 11.11.8 is available from fasttrack.debian.org. 
Not quite the one (11.11.0) the upgrade process advised to use, but 
maybe close enough - I can't find any older versions.  This fails with 
two dependencies on old packages, ruby-prof, which I've now downgraded 
ok, and ruby-gitaly-proto, which I can't find a trace of anywhere.

'apt-cache madison ruby-gitaly' returns

golang-gitaly-proto | 0.123.0+dfsg-2 | http://ftp.uk.debian.org/debian 
buster/main Sources

I don't suppose this golang version would satisfy the dependency, but it 
doesn't install anyway:

  apt install golang-gitaly-proto=0.123.0+dfsg-2 returns 'Unable to 
locate package golang-gitaly-proto'.

So I'm stuck on this route too. Any suggestions? Although I've been 
using debian for ages (thanks everyone) it's very much only as an end 
user, and since normally upgrades 'just work' for me I get really 
unstuck when I run into quite basic upgrade problems.

Graham


> --
> John Doe
>

[toc] | [prev] | [next] | [standalone]

#219209

On 2/16/2020 11:45 PM, Graham Seaman wrote:
>
> On 14/02/2020 17:39, john doe wrote:
>> On 2/14/2020 5:42 PM, Graham Seaman wrote:
>>> I run a debian house server for firewall, routing etc. The last few
>>> years I've also run gitlab on it, which I use to manage text files I
>>> work on from an assortment of laptops/PCs; I have a lot of these files
>>> (currently around 12 Gb) and really don't want to lose them. After the
>>> initial setup I didn't do anything with the gitlab code and don't even
>>> remember what version it was.
>>>
>>> So this week, without thinking particularly about gitlab, I upgraded
>>> from stretch to buster. No complaints during the upgrade, but gitlab no
>>> longer worked (now dependent on a directory called 'embedded' which I
>>> don't have). So I followed the recommendation on
>>> https://wiki.debian.org/gitlab to update gitlab using buster-fastrack.
>>> This installed an alarmingly huge number of ruby and node dependencies,
>>> then failed informing me that I the database changes were too big to go
>>> straight from my old version to the current debian one, and that I need
>>> to transition through version 11.11.0 first.
>>>
>>> There is no debian package for this, and 11.11.0 is only available from
>>> gitlab.com as a docker install, but I'm running directly on my host.
>>>
>> Cant' you use docker on an other host, for example, in a VM?
> I've tried that, but never having used docker before found I was just
> mystified at how to use the install to reformat the existing data, as
> would happen during a normal upgrade. I think this route is probably a
> dead end for me, I just don't have the knowledge to do it.
>>> Can anyone suggest how to get myself a working gitlab again. without
>>> losing the current data? I could live with a command-line only version,
>>> if I couldn't get the web side working again.
>>>
>> First off, backup your data! :)
>
> Of course, though this would be easier if I was more sure where
> everything was. But the data's no use without the software to read it.
>

https://docs.gitlab.com/ee/raketasks/backup_restore.html

>> Basically, my idea would be to find a way to follow the correct upgrade
>> procedure.
>
> I've found that version 11.11.8 is available from fasttrack.debian.org.
> Not quite the one (11.11.0) the upgrade process advised to use, but
> maybe close enough - I can't find any older versions.  This fails with
> two dependencies on old packages, ruby-prof, which I've now downgraded
> ok, and ruby-gitaly-proto, which I can't find a trace of anywhere.
>
> 'apt-cache madison ruby-gitaly' returns
>
> golang-gitaly-proto | 0.123.0+dfsg-2 | http://ftp.uk.debian.org/debian
> buster/main Sources
>
> I don't suppose this golang version would satisfy the dependency, but it
> doesn't install anyway:
>
>  apt install golang-gitaly-proto=0.123.0+dfsg-2 returns 'Unable to
> locate package golang-gitaly-proto'.
>
> So I'm stuck on this route too. Any suggestions? Although I've been
> using debian for ages (thanks everyone) it's very much only as an end
> user, and since normally upgrades 'just work' for me I get really
> unstuck when I run into quite basic upgrade problems.
>

Don't Gitlab has some kind of forum/mailing list?

This will not help you for now but the following could be useful in the
future:

If you have VMs available, I would suggest you to have a clone of your
production "server" and to first on this VM how the upgrade process goes.

Also, Gitlab seems overkill in your situation, if you need Git, simply
use the Git package and a frontend if you like.


As I don't use Gitlab myself, that's all I can help you with.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#219222

On 17/02/2020 06:30, john doe wrote:
> On 2/16/2020 11:45 PM, Graham Seaman wrote:
>
>> Of course, though this would be easier if I was more sure where
>> everything was. But the data's no use without the software to read it.
>>
> https://docs.gitlab.com/ee/raketasks/backup_restore.html
Thanks - bit embarassing I didn't know that existed (I don't think there 
was a backup option when I first installed it). But I've done pretty 
much the same, but manually - rsyncing off the data files, psql_dump, etc.
> Don't Gitlab has some kind of forum/mailing list?

Yes, it has many forums. I was just hoping someone working on the debian 
side might pick up on this - the debian layout seems rather different 
from the vanilla one(s), though maybe just because the version I had was 
so old.

> This will not help you for now but the following could be useful in the
> future:
>
> If you have VMs available, I would suggest you to have a clone of your
> production "server" and to first on this VM how the upgrade process goes.

I hadn't thought of running a VM clone of the server - might be 
generally useful. But the server's main jobs are as a router, firewall, 
dnsmasq, mail server, which is where the main problems usually are in 
upgrades, and I think it would be hard to duplicate the low-level comms 
stuff meaningfully in a VM

> Also, Gitlab seems overkill in your situation, if you need Git, simply
> use the Git package and a frontend if you like.

Definitely. I think I might abandon gitlab and go with something much 
simpler like gitweb. Ideally something I'm sure will be long-term 
supported.

> As I don't use Gitlab myself, that's all I can help you with.

Kind of you to reply as a non-gitlab user! Thanks.

Graham


> --
> John Doe
>

[toc] | [prev] | [next] | [standalone]

#219236

On Mon 17 Feb 2020 at 15:27:06 (+0000), Graham Seaman wrote:
> On 17/02/2020 06:30, john doe wrote:
> > On 2/16/2020 11:45 PM, Graham Seaman wrote:
> > 
> > > Of course, though this would be easier if I was more sure where
> > > everything was. But the data's no use without the software to read it.
> > > 
> > https://docs.gitlab.com/ee/raketasks/backup_restore.html
> Thanks - bit embarassing I didn't know that existed (I don't think
> there was a backup option when I first installed it). But I've done
> pretty much the same, but manually - rsyncing off the data files,
> psql_dump, etc.
> > Don't Gitlab has some kind of forum/mailing list?
> 
> Yes, it has many forums. I was just hoping someone working on the
> debian side might pick up on this - the debian layout seems rather
> different from the vanilla one(s), though maybe just because the
> version I had was so old.
> 
> > This will not help you for now but the following could be useful in the
> > future:
> > 
> > If you have VMs available, I would suggest you to have a clone of your
> > production "server" and to first on this VM how the upgrade process goes.
> 
> I hadn't thought of running a VM clone of the server - might be
> generally useful. But the server's main jobs are as a router,
> firewall, dnsmasq, mail server, which is where the main problems
> usually are in upgrades, and I think it would be hard to duplicate the
> low-level comms stuff meaningfully in a VM

Would it be possible to run a live stretch system (or install one)
on another machine, onto which you copy the files from your server.
You should be able to install a version of gitlab old enough to
handle your old data. (If necessary, for stretch, read jessie.)

You might not know which non-Debian files *are* necessary for gitlab
to run but presumably you know which trees of files you *don't* need
on this system: anything to do with the "main jobs" you mentioned,
for example.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#219241

On 17/02/2020 22:41, David Wright wrote:
> On Mon 17 Feb 2020 at 15:27:06 (+0000), Graham Seaman wrote:
>> I hadn't thought of running a VM clone of the server - might be
>> generally useful. But the server's main jobs are as a router,
>> firewall, dnsmasq, mail server, which is where the main problems
>> usually are in upgrades, and I think it would be hard to duplicate the
>> low-level comms stuff meaningfully in a VM
> Would it be possible to run a live stretch system (or install one)
> on another machine, onto which you copy the files from your server.
> You should be able to install a version of gitlab old enough to
> handle your old data. (If necessary, for stretch, read jessie.)
>
> You might not know which non-Debian files *are* necessary for gitlab
> to run but presumably you know which trees of files you *don't* need
> on this system: anything to do with the "main jobs" you mentioned,
> for example.
>
I decided John Doe was right, and gitlab is really overkill for what I 
need and likely to lead to extra work every time there's an upgrade as 
well (rails based apps always seem to have been a problem for me that 
way).  So I've extracted the git data and abandoned the gitlab part, and 
now I'm just using git from the command line, which is mostly what I was 
doing anyway. I might look at using gitweb in the future if I feel a 
need to get a web frontend back.

Graham

[toc] | [prev] | [next] | [standalone]

#219242

On 2/18/2020 11:14 AM, Graham Seaman wrote:
>
> On 17/02/2020 22:41, David Wright wrote:
>> On Mon 17 Feb 2020 at 15:27:06 (+0000), Graham Seaman wrote:
>>> I hadn't thought of running a VM clone of the server - might be
>>> generally useful. But the server's main jobs are as a router,
>>> firewall, dnsmasq, mail server, which is where the main problems
>>> usually are in upgrades, and I think it would be hard to duplicate the
>>> low-level comms stuff meaningfully in a VM
>> Would it be possible to run a live stretch system (or install one)
>> on another machine, onto which you copy the files from your server.
>> You should be able to install a version of gitlab old enough to
>> handle your old data. (If necessary, for stretch, read jessie.)
>>
>> You might not know which non-Debian files *are* necessary for gitlab
>> to run but presumably you know which trees of files you *don't* need
>> on this system: anything to do with the "main jobs" you mentioned,
>> for example.
>>
> I decided John Doe was right, and gitlab is really overkill for what I
> need and likely to lead to extra work every time there's an upgrade as
> well (rails based apps always seem to have been a problem for me that
> way).  So I've extracted the git data and abandoned the gitlab part, and
> now I'm just using git from the command line, which is mostly what I was
> doing anyway. I might look at using gitweb in the future if I feel a
> need to get a web frontend back.
>

Glad to hear that you found a way out of this situation! :)

If you need readonly access to your or some of your repositories, look
at git-daemon and the git protocol.

That is, you still push using SSH but you can fetch/pull using SSH or
the git protocol.

P.S.

Don't forget that the repositories on a server/remote repositories are
to be 'bare' and 'ending with '.git'.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#219257

[Multipart message — attachments visible in raw view] — view raw

On Ma, 18 feb 20, 12:25:40, john doe wrote:
> 
> Don't forget that the repositories on a server/remote repositories are
> to be 'bare' and 'ending with '.git'.

Using a bare as remote has some advantages in case you don't actually 
need a working tree "there", it is however not a requirement.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#219258

On 2/19/2020 9:03 AM, Andrei POPESCU wrote:
> On Ma, 18 feb 20, 12:25:40, john doe wrote:
>>
>> Don't forget that the repositories on a server/remote repositories are
>> to be 'bare' and 'ending with '.git'.
>
> Using a bare as remote has some advantages in case you don't actually
> need a working tree "there", it is however not a requirement.
>

Or you could clone from that bare repository using the local protocol.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#219260

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 19, 2020 at 10:03:04AM +0200, Andrei POPESCU wrote:
> On Ma, 18 feb 20, 12:25:40, john doe wrote:
> > 
> > Don't forget that the repositories on a server/remote repositories are
> > to be 'bare' and 'ending with '.git'.
> 
> Using a bare as remote has some advantages in case you don't actually 
> need a working tree "there", it is however not a requirement.

No, but still highly recommended. Pushing to a non-bare repo is...
possible but finicky (a non bare repo has always a "checked out"
branch: now imagine that one isn't clean. What's to happen?

See e.g. [1] for some discussion.

I'd recommend: always use bares as remotes (unless you really know
what you're doing -- or equivalently: unless you're into... learning).

Cheers

[1] https://stackoverflow.com/questions/1764380/how-to-push-to-a-non-bare-git-repository

-- t

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web