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