You are here
KEITH SHU - Mon, 2023/11/20 - 23:33
I've migrated my v12.x Redmine appliance data to the current release (v17.x) and all appears to (mostly) be good.
However, the HTTP/HTTPS Git Protocol doesn't seem to be working for the redmine image. What areas should I check?
I've tried this:
git -c http.sslVerify=false clone http://xxx.tklapp.com/git/helloworld.git
and
git -c http.sslVerify=false clone https://xxx.tklapp.com/git/helloworld.git
but got repository not found.
Any advice?
Keith
Forum:
Hi Keith, I can reproduce your experience
Hi Keith, I can reproduce your experience. However, that is expected as by default our Redmine appliance doesn't include OOTB pre-configured support for git access via http/https.
It does include git access via SSH OOTB, although I note that the URL shown on Confconsole is incorrect. A bit of trial and error helped me discover the correct URL to use (and I've opened an issue to fix it in the next release). The URL to use is:
E.g.:
The Redmine docs suggest creating a cron job to update the repo(s) on Redmine from a remote git repo.
If you want to use git via http/https, currently you'll need to configure that yourself. There is a Redmine wiki page that covers that. I can't vouch that it will "just work", but after a quick glance over it, it seems pretty reasonable to me. Although please note that it was explicitly written for/from CentOS v6 - so may be a little dated and/or may require some adjustment for Debian/TurnKey ). I have opened a second issue related to include that config by default. It would certainly be nice to include that OOTB (and I've pinned the issue to the next release), but currently we're pretty snowed under and running behind schedule, so no promises...
Actually, while googling to find resources to share with you I came across a Redmine plugin called Redmine Git Hosting which looks like it might also be relevant to you? (Edit: I've also opened a issue for that too).
As something of an aside, TurnKey's Confconsole includes a "Let's Encrypt" plugin - to get free "proper" CA signed SSL/TLS certs. In v17.x appliances it does require public access to port 80 (so is only relevant for publicly accessible servers) but v18.x (see the announcements on our blog) includes a method to get a cert via DNS (currently a bit buggy but should be fixed really soon).
It's probably not much use to you (assuming that you already have project data in Redmine) and I don't want to encourage people away from Redmine (as it's a really awesome software project management tool) but for anyone reading who is looking for a git hosting solution, http/https git access works OOTB on our Gitea appliance.
Thanks for the pointers.
Hi Jeremy
1. Thanks for the pointers. I recall reading in the docs/other forums that GIT HTTP access is expected to work OOTB. It seems to work for SVN. as https://xxx.tklapp.com/svn/helloworld is accessible.
2. We have been using the ssh access all this time (over 10 years). However we have a new scenario now that requires us to connect via a socks proxy. That's a whole can of worms. We thought a HTTPS protocol might have an easier time. I'll try Redmine Git hosting plugin your recommended and report back with results.
3. Regarding the let's encrypt plugin. I actually tried that using webmin before this, but it made webmin inaccessible. I got a PR_CONNECT_RESET_ERROR after applying. Maybe I did it wrong but i dont know how to recover. Luckily from your comments, I find out theres a confconsole so maybe i'll try that to get it back.
4. If all else fails, I don't mind using gitea. Does the gitlab appliance also have HTTPS out of the box?
Thanks
You're welcome.
1. Hmm, it is interesting that SVN via http/https "just works" and I must admit that I wasn't consciously aware of that. Although after having a closer look at the Redmine appliance build code, I can see that we're installing the Apache mod_svn package and there is also additional SVN specific Apache conf.
Now I'm looking at it, I vaguely recall that our Redmine appliance did used to include "git://" access (which should allow access via http/https), but it broke at some point and IIRC there wasn't a clean/clear obvious way to resolve that at the time, so we just removed it - and you are the first to notice (or at least report it). I reckon that the way for us to go for the next release would be to configure and use the "git-smart-http" protocol (provided by the git binary via Apache mod_cgi).
2. Good luck and please do let me know how you go... And/or if you hit any issues, please don't hesitate to ask. I'm no Redmine expert, but as you'd expect, I'm fairly intimate with TurnKey (and Debian) in general.
3. Yeah, enabling Let's Encrypt via Webmin will break Webmin. When I said Confconsole, I meant open a terminal and type "confconsole".
The reason that getting a LE cert via Webmin will cause issues is that since ~v14.x and up to and including v17.x, Webmin is behind stunnel (in v18.0 it's now accessible directly). So when Webmin configures it's own SSL/TLS cert it breaks the connection between stunnel (available externally via port 12321) and Webmin itself (available via localhost only on port 10000) - leading to the issue you reported.
I initially I intended to disable the Webmin Let's Encrypt module in v18.0 to ensure that no one would hit that. But then when we removed stunnel and I thought that we may bve able to retain it (when available directly, it should "just work"). However, whilst it works ok for Webmin itself; because it uses different paths for the cert (to what we use) and without patching the code, it still doesn't "just work" (without refactoring heaps of our existing code).
So instead I have just disabled it in v18.x.
4. If you wanted to retain Redmine, you could just use Gitea for pushing/pulling code and set up a cron job to pull the changes into Redmine?
GitLab would also be an option and I'm almost certain that git via http/https should "just work" on that too. Although be warned, GitLab is a heavy beast of thing and it needs a fair few resources to run at all, and heaps to run smoothly. Also the current appliance has a fairly major bug which you'd need to address.
We got git with ssh over proxy to work
We got git with ssh over proxy to work. The proxy had a transfer limit that was being exceeded causing the SSH connection to be terminated. Increasing the limit resolved this.
So we're kicking the HTTPS can down the road. Thanks for the help!
Add new comment