Re: [gitorious] fatal errors in clone over ssh resulting from internal http errors

2011-05-30 Thread Christian Johansen 
>
>>>  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

2011-05-26 Thread hash 



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.



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).


--
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

2011-05-26 Thread ShaneOG 
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,  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

2011-05-26 Thread Christian Johansen 
On Mon, May 23, 2011 at 23:40,  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

2011-05-23 Thread hash 


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?)



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!


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_fix 
that 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 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.


--
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

2011-05-23 Thread Christian Johansen 
> 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)...
> 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

[gitorious] fatal errors in clone over ssh resulting from internal http errors

2011-05-23 Thread hash 

Hi folks,

I've spent the last few days getting gitorious installed on a server of 
mine, and I've got most of the bumps worked out with a liberal 
application of google and patience, but I've hit one now that's got me a 
bit stumped.


Here's what I'm trying to do: "git clone 
g...@appliance.exultant.us:house/wdev.git".  The connection works fine, 
keys are good, etc... Then I'm getting a fatal error from Gitorious.


gitorious_auth.log shows me this:

F, [2011-05-20 12:29:47#16687] FATAL -- : Net::HTTPBadResponse wrong 
status line: "": 
/usr/lib/ruby/1.8/net/http.rb:2026:in `read_status_line'

  /usr/lib/ruby/1.8/net/http.rb:2013:in `read_new'
  /usr/lib/ruby/1.8/net/http.rb:1050:in `request'
  /usr/lib/ruby/1.8/net/http.rb:772:in `get'
  [elided]/gitorious/script/../lib/gitorious/ssh/client.rb:84:in 
`configuration'
  [elided]/gitorious/script/../lib/gitorious/ssh/client.rb:58:in 
`real_path'
  [elided]/gitorious/script/../lib/gitorious/ssh/client.rb:72:in 
`to_git_shell_argument'

  /usr/bin/gitorious:63

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)... I fixed that with a 
terrible hack (i.e. just prefacing that query_url with "/git"); problem 
remains.


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.


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?


Thanks,
Eric Myhre

--
To post to this group, send email to gitorious@googlegroups.com
To unsubscribe from this group, send email to
gitorious+unsubscr...@googlegroups.com