Re: help with gitlab on buster
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 signature.asc Description: Digital signature
Re: help with gitlab on buster
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
Re: help with gitlab on buster
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 signature.asc Description: PGP signature
Re: help with gitlab on buster
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 (+), 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
Re: help with gitlab on buster
On 17/02/2020 22:41, David Wright wrote: On Mon 17 Feb 2020 at 15:27:06 (+), 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
Re: help with gitlab on buster
On Mon 17 Feb 2020 at 15:27:06 (+), 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.
Re: help with gitlab on buster
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
Re: help with gitlab on buster
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
Re: help with gitlab on buster
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
Re: help with gitlab on buster
john doe wrote: > First off, backup your data! :) also no one upgrades production stuff without testing the procedure - right?!
Re: help with gitlab on buster
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
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
Re: Help with gitlab
On 27/10/2018 05.20, Dennis Wicks wrote: Anybody know the secret command to get the source in some usable format? I always use 'git ' directly. Install it from the Debian repos if necessary. On GitLab there's usually a box with the git url, but it's probably just https://gitlab.com/username/reponame.git. Then do 'git clone ' and you'll have a local git repository, with all the files. (This works with other online git repos too.) -- John
Help with gitlab
Greetings; So far everything I have wanted to get from git has had a button for "download zip file" and everything worked great. I am trying to get a package that doesn't have a download link. Anybody know the secret command to get the source in some usable format? I have tried the regular rt-clk approach and a download manager but it seems the files are actually html! Any hints, tips, or examples appreciated! TIA, Dennis
