Re: help with gitlab on buster
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.
Reply to: