Re: [gitorious] fatal errors in clone over ssh resulting from internal http errors
First question would then be how to best make a unified go of it [...] I found this also brought up before in merge request #2219 and again quite a long time ago at https://groups.google.com/group/gitorious/browse_thread/thread/8e2f965733d5d56d/8c814f3baa5ebdf0?q=root_path+gitorious+sub+uri#8c814f3baa5ebdf0... and these led me to notice ~rlandrito/gitorious/rl-mainline:non_root_url, which I guess would be a good place to start not reinventing the wheel (if anyone else stumbles across this subject again and wants next steps). Hi, Yes, well https://gitorious.org/~rlandrito/gitorious/rl-mainline/commits/non_root_urlis a good start. Configuring it from gitorious.yml makes sense. But this branch does not (as far as I can tell) set the relative url on ActionController as suggested by Marius on the mailing list. I'd recommend you include that too. Other than that, if the tests pass, and you build new tests (I suggest integration tests that 'browse' gitorious) that shows sub uri's working, I don't have a lot of strong opinions as to how to solve the rest. -- MVH Christian -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] fatal errors in clone over ssh resulting from internal http errors
On Mon, May 23, 2011 at 23:40, h...@exultant.us wrote: Right. Am I understanding this correctly that you are not exposing Gitorious over HTTP at all? Only HTTPS? Just so. Is there a configuration option somewhere for this that I might have missed? (Actually, thb I'm a bit vague on why gitorious has this indirection at all -- I suppose I could write some more rules in apache config to allow http connections to those urls from localhost only, but it seems like there ought to be a more direct approach to all this than making HTTP requests after SSHing; gitorious can just call itself as ruby without rails/passenger at that point and get the job done that way, can't it?) We will probably move to doing this without HTTP, yes. As for your issue, see this thread: http://groups.google.com/group/gitorious/browse_thread/thread/36ad12033bbd651aIt's not actually clear to me if Marius' proposed fix worked, but if you could try it too and confirm I will push this to master. will there be any patches coming down the line for making sub-URI installs work a little more smoothly? There are currently no specific plans to do so, but I'm all for it. I don't think it will be a huge job. If anyone is up for doing it (remember tests!) I'll be happy to merge it in. (Another option is to fund development which would allow us to more easily prioritise it. Sorry for the blatant sell, but we're doing Gitorious for a living, and there's a lot to do, can't prioritise it all...) Well, I'm liable to throw some time into it when I get copious amounts of it free myself to come to grips with ruby, but I'm just a university researcher and I'm afraid I haven't got that budget, and even if I could repurpose some grant money I don't rightly think I've got a chance at selling it to my lab without the HTTPS issues all fixed and something along the lines of merge request 115 getting into mainline. Anyway! Sure, I thought I'd just mention it. Something along the lines of 115 will probably land some day, but currently this would require funding somehow, as we're not going to use it on gitorious.org. First question would then be how to best make a unified go of it, since there's not currently an entry for specifying the web URI in gitorious.yml, but quite a few parts of the system adapt just fine anyway. In other words, I don't think it'd take me too much time to hack some more string ops throughout, but it seems like it'd be in the best interest of the project to make sure there's a single idiom used consistently for this (and I don't think that's something it would be appropriate for me to be taking the lead on per se). I see at http://www.modrails.com/documentation/Users%20guide%20Apache.html#sub_uri_deployment_uri_fixthat Rails comes with some functions that help with this on the actual HTML generation side of things, but they appear to be radically overspecialized and not so useful as a result. I did some experimenting with Passenger sub urls a while ago. I concluded that it only solves part of the puzzle, but unfortunately I seem to have not taken any notes as to what the specific problems were. If we could make the Passenger route work that would probably be the cleanest solution. I guess the remaining problem is making sure Gitorious always gets its URLs from Rails. This is not the case for instance in the ssh client, which pieces together the URL as a string (because it runs without the Rails environment). So - I suspect we need a setting in gitorious.yml anyway. I do also have a couple tickets open at the lighthouse site that should be specific enough to make really short work of some low-hanging fruit for anyone already familiar with where things are in the codebase. I will take a look. Christian -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] fatal errors in clone over ssh resulting from internal http errors
Just to confirm that Marius' proposed fix didn't work - it led to other problems. I don't yet know enough about Ruby to debug this... On Thursday, 26 May 2011 12:17:24 UTC+1, Christian Johansen wrote: On Mon, May 23, 2011 at 23:40, ha...@exultant.us wrote: Right. Am I understanding this correctly that you are not exposing Gitorious over HTTP at all? Only HTTPS? Just so. Is there a configuration option somewhere for this that I might have missed? (Actually, thb I'm a bit vague on why gitorious has this indirection at all -- I suppose I could write some more rules in apache config to allow http connections to those urls from localhost only, but it seems like there ought to be a more direct approach to all this than making HTTP requests after SSHing; gitorious can just call itself as ruby without rails/passenger at that point and get the job done that way, can't it?) We will probably move to doing this without HTTP, yes. As for your issue, see this thread: http://groups.google.com/group/gitorious/browse_thread/thread/36ad12033bbd651aIt's not actually clear to me if Marius' proposed fix worked, but if you could try it too and confirm I will push this to master. will there be any patches coming down the line for making sub-URI installs work a little more smoothly? There are currently no specific plans to do so, but I'm all for it. I don't think it will be a huge job. If anyone is up for doing it (remember tests!) I'll be happy to merge it in. (Another option is to fund development which would allow us to more easily prioritise it. Sorry for the blatant sell, but we're doing Gitorious for a living, and there's a lot to do, can't prioritise it all...) Well, I'm liable to throw some time into it when I get copious amounts of it free myself to come to grips with ruby, but I'm just a university researcher and I'm afraid I haven't got that budget, and even if I could repurpose some grant money I don't rightly think I've got a chance at selling it to my lab without the HTTPS issues all fixed and something along the lines of merge request 115 getting into mainline. Anyway! Sure, I thought I'd just mention it. Something along the lines of 115 will probably land some day, but currently this would require funding somehow, as we're not going to use it on gitorious.org. First question would then be how to best make a unified go of it, since there's not currently an entry for specifying the web URI in gitorious.yml, but quite a few parts of the system adapt just fine anyway. In other words, I don't think it'd take me too much time to hack some more string ops throughout, but it seems like it'd be in the best interest of the project to make sure there's a single idiom used consistently for this (and I don't think that's something it would be appropriate for me to be taking the lead on per se). I see at http://www.modrails.com/documentation/Users%20guide%20Apache.html#sub_uri_deployment_uri_fixthat Rails comes with some functions that help with this on the actual HTML generation side of things, but they appear to be radically overspecialized and not so useful as a result. I did some experimenting with Passenger sub urls a while ago. I concluded that it only solves part of the puzzle, but unfortunately I seem to have not taken any notes as to what the specific problems were. If we could make the Passenger route work that would probably be the cleanest solution. I guess the remaining problem is making sure Gitorious always gets its URLs from Rails. This is not the case for instance in the ssh client, which pieces together the URL as a string (because it runs without the Rails environment). So - I suspect we need a setting in gitorious.yml anyway. I do also have a couple tickets open at the lighthouse site that should be specific enough to make really short work of some low-hanging fruit for anyone already familiar with where things are in the codebase. I will take a look. Christian -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
Re: [gitorious] fatal errors in clone over ssh resulting from internal http errors
I read into the source a little bit (though mind you I've never spoken a word of ruby before last night, so take all that I say with a grain of salt), and found a few things: client.rb:82 is not expecting sub-URI installs (which is what I've done; i.e. I installed gitorious to be accessible via appliance.exultant.us/git).http://appliance.exultant.us/git%29... I fixed that with a terrible hack (i.e. just prefacing that query_url with /git); problem remains. Eric, I think you did great for a first timer Ruby hacker :) Now I'm a bit stuck. I enabled the debugging statement around there when I try the clone command at the client again I get a message confirming that gitorious is Querying /git/house/wdev/config... and indeed, if I go to https://appliance.exultant.us/git/house/wdev/config in my browser I get a lovely little blast of yaml. I'm guessing at this point that the problem here is that gitorious is trying to get that url over port 443 as I instructed in config/gitorious.yml, but over HTTP -- with out the S -- which would indeed result in apache on my server giving a Bad Request page with that exact doctype on the first line. Right. Am I understanding this correctly that you are not exposing Gitorious over HTTP at all? Only HTTPS? If I'm reading into this correctly, how can I go about telling gitorious to use HTTPS there? And will there be any patches coming down the line for making sub-URI installs work a little more smoothly? There are currently no specific plans to do so, but I'm all for it. I don't think it will be a huge job. If anyone is up for doing it (remember tests!) I'll be happy to merge it in. (Another option is to fund development which would allow us to more easily prioritise it. Sorry for the blatant sell, but we're doing Gitorious for a living, and there's a lot to do, can't prioritise it all...) Cheers, Christian -- To post to this group, send email to gitorious@googlegroups.com To unsubscribe from this group, send email to gitorious+unsubscr...@googlegroups.com
