Re: [gitorious] fatal error while accessing remotely

2012-12-11 Thread Marius Mårnes Mathiesen 
On Mon, Dec 10, 2012 at 07:54:50AM -0800, Jonathan wrote:
> I just installed a new gitorious server. From inside the LAN I'm able to
> pull\push without a problem. However from outside the LAN I get:
>
> == Gitorious: ==
> > fatal error
> > 
> > fatal: The remote end hung up unexpectedly
>
>
> I found the following error in `gitorious_auth.log`:
>
> FATAL -- : NoMethodError private method `gsub!' called for nil:NilClass:
> > /opt/bitnami/apps/gitorious/htdocs/script/../lib/gitorious/ssh/client.rb:34:in
> > `initialize'
>
>
> What does it mean and how can I fix it? How come it occurs only from
> remote access?

Jonathan,
The error you're seeing appears caused by the "strainer" Gitorious uses to
restrict which commands you're allowed to run over SSH not being set
up correctly. It uses OpenSSH's SSH_ORIGINAL_COMMAND environment
variable apparently not being set correctly.

When you mention that you connect from outside the LAN, I assume
you're using a different IP address than when connecting locally? Are
you running more than one SSH daemon? Does it work if you try
connecting to the external IP address on the same network?


Cheers,
- Marius

-- 
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] losing repos when transferring

2012-12-11 Thread Marius Mårnes Mathiesen 
On Mon, Dec 10, 2012 at 11:05:15AM -0700, Ken Dreyer wrote:
> Context: I've got an intranet Gitorious instance set up, with a couple
> self-managed teams.
>
> I just had some users lose access to some repos when they transferred
> the repos to a team. Even though these users were members of the group
> which was the "Owner", the users still had no admin rights to the
> repo. I had to explicitly add the team in the committership table in
> MySQL.
>
Ken,
The permission model in Gitorious uses a fancy join table to connect a
user/team and a repository, this "table" is represented in the
Committership class. For each committership (the connection between a
user/team and a repository), there's a permissions property (similar
to Unix file permissions) which determine what the user/team is
allowed to do with the repository.

> Should a "group owner" for a repo mean that everyone in the group
> implicitly has admin rights on that repo? I'm wondering if this is a
> bug or if it's intentional.

Now onwards to your question :-)
I would agree with you that a group owner should have admin rights to
that repository. Transferring ownership to a group involves calling
`change_owner_to!` on the Repository class, which *should* cause a
comittership to be created (`committerships.create_for_owner!`), which
would set up a committership with all permissions:

# app/models/committership.rb
  def self.create_for_owner!(an_owner)
cs = new({:committer => an_owner})
cs.permissions = (CAN_REVIEW | CAN_COMMIT | CAN_ADMIN)
cs.save!
cs
  end


However, there's an if clause around that call: `unless
committerships.any?{|c|c.committer == another_owner}` which means that
if the new owner already has access to the repository, a new
committership is not created. Could this be what happened on your
server? Whether it is or not, I would suggest that we change it to
either create a new committership or change the permissions to the
existing one, but I'd like to know if that was the cause or you found
another bug.

Cheers,
- Marius

-- 
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] Re: Ultrasphinx unknown task

2012-12-11 Thread Graziano Aliberti 
Thank you very much. You saved my life guys :)

Il giorno lunedì 10 dicembre 2012 09:54:26 UTC+1, Peter Kjellerstedt ha 
scritto:
>
> This is better:
>
>  
>
> 10 * * * * /var/www/gitorious/bin/rake ts:rebuild >/dev/null
>
>  
>
> First of all it only runs the task once an hour rather than once every 
> minute.
>
> Second, it utilizes the scripts in /var/www/gitorious/bin/ which make sure 
> the environment is correct.
>
> Third, it runs ts:rebuild which has been recommended by the Gitorious 
> developers for updating the index.
>
>  
>
> //Peter
>
>  
>
> *From:* gito...@googlegroups.com  [mailto:
> gito...@googlegroups.com ] *On Behalf Of *Graziano Aliberti
> *Sent:* den 10 december 2012 09:42
> *To:* gito...@googlegroups.com 
> *Subject:* [gitorious] Re: Ultrasphinx unknown task
>
>  
>
> Hy guys,
>
> thank you very much. Now everything works fine.
>
> So into the git's crontab I must insert this task, right?
>
> * * * * * cd /var/www/gitorious && /usr/bin/bundle exec rake 
> thinking_sphinx:index RAILS_ENV=production
>
>
> Regards,
>
> Graziano
>
> Il giorno sabato 8 dicembre 2012 16:45:29 UTC+1, Kevin Lyda ha scritto:
>
> On Friday, December 7, 2012 4:14:40 PM UTC, Graziano Aliberti wrote:
>
> I'm installing Gitorious on Ubuntu Server 12.04 64 bit following the 
> guideline http://coding-journal.com/installing-gitorious-on-ubuntu-11-04/but 
> when I must run this command
> export RAILS_ENV=production && \
> bundle exec rake db:create && \
> bundle exec rake db:migrate && \
> bundle exec rake ultrasphinx:bootstrap
> (in /var/www/gitorious)
> Please install RDoc 2.4.2+ to generate documentation.
> rake aborted!
> Don't know how to build task 'ultrasphinx:bootstrap'
>
>  
>
> I'm still in the process of doing my first install, but I think this is 
> due to ultrasphinx being replaced with thinking_sphinx.
>
>  
>
> You'll want to run
>
>  
>
> rake ts:conf
>
> rake ts:rebuild
>
>  
>
> Kevin
>
> -- 
> To post to this group, send email to gito...@googlegroups.com
> To unsubscribe from this group, send email to
> gitorious+...@googlegroups.com 
>

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

[gitorious] branch specific access problems

2012-12-11 Thread Jonathan 
This is an odd one...
Pulling any branch from any repository from a computer inside the 
gitorious' server's LAN works.
On any remote computer (not on the same LAN as the gitorious server), 
pulling master from any repository works, but pulling any other branch does 
not.
I know gitorious (thankfully) does not support branch specific permissions. 
Also the fact that within the LAN all the branches work must indicate 
something... what could it possibly be?!

This question is also tracked on 
stackoverflow

-- 
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] Re: LDAP Authentication problem

2012-12-11 Thread Graziano Aliberti 
Hi guys,

I don't know how the ldap authentication works for you but I really don't 
know how I must configure it.

Regards

Il giorno martedì 4 dicembre 2012 11:33:32 UTC+1, Graziano Aliberti ha 
scritto:
>
> Any news for me?
>
> Thank you very much
>
> Il giorno giovedì 29 novembre 2012 11:15:20 UTC+1, Graziano Aliberti ha 
> scritto:
>>
>> Hi,
>>
>> it doesn't work!! I've done all that you tell me to do.
>>
>> Regards
>>
>> Il giorno mercoledì 28 novembre 2012 17:41:05 UTC+1, Federico Don ha 
>> scritto:
>>>
>>> First backup to code.
>>> as root:
>>> cd /home
>>> cp -r ./git ./git.org
>>>
>>>
>>> update the existing code.
>>>
>>> cd /home/git/gitorious
>>> git add .
>>> git commit 
>>> (post a comment, save and exit)
>>> git pull
>>>
>>> (Pulling resolve merge error with 
>>> http://genomewiki.ucsc.edu/index.php/Resolving_merge_conflicts_in_Git)
>>>
>>> download:
>>>
>>> wget --no-check-certificate "
>>> https://gitorious.org/gitorious/mainline/blobs/raw/d85ec6785415775cfa51660af180dae42ec91b2d/lib/gitorious/authentication/ldap_authentication.rb
>>> "
>>> cp ldap_authentication.rb 
>>> /home/git/gitorious/lib/gitorious/authentication/ldap_authentication.rb
>>>
>>> Edit:
>>>
>>> vi 
>>> /home/git/gitorious/lib/gitorious/authentication/ldap_authentication.rb
>>>
>>> go to line 74 (def authenticate(username, password))
>>> Change and add with this: 
>>>
>>> def authenticate(credentials)
>>> username = credentials.username
>>> password = credentials.password
>>>
>>> save and exit
>>>
>>> repair permission:
>>>
>>> chown -R git:git /home/git/gitorious
>>>
>>> service httpd restart
>>>
>>> I hope your comment and Luck!
>>>
>>>
>>> 2012/11/28 Graziano Aliberti 
>>>
 Humm,

 I have the master of the mainline...what can I do? git pull origin 
 master? Do you think this can help me?

 Il giorno mercoledì 28 novembre 2012 16:33:40 UTC+1, Federico Don ha 
 scritto:
>
> do you have the ultimate version for gitorious?
>
> I had this problem and when i update to version the problem was solved!
>
>
> 2012/11/28 Graziano Aliberti 
>
>> Hi,
>>
>> my issue is that I've never seen "All good, your credential are 
>> correct"
>>
>> Always 
>>
>> Not there yet.
>> For debugging purposes, this is the DN we tried: 
>> uid=MyUser,OU=Something,O=**Something,C=it
>>
>> The user, obviously, exists
>>
>> Thank you,
>>
>> Graziano
>>
>> Il giorno mercoledì 28 novembre 2012 15:41:38 UTC+1, Federico Don ha 
>> scritto:
>>>
>>> Hello,
>>>
>>> if you run the script for test
>>>
>>> [root@gitorious gitorious]# bundle exec script/test_ldap_connection 
>>> USER PASSWORD
>>> All good, your credentials are correct
>>>
>>> what is your issue??
>>>
>>>
>>> 2012/11/28 Graziano Aliberti 
>>>
 Hi Federico,

 I've tried with your configuration (changing the server and the 
 base_dn) but it doesn't work!

 This is my configuration:


 production:
disable_default: true
methods:
   - adapter: Gitorious::Authentication::**LDA**PAuthentication
 host: ldap.something.it
 port: 389
 base_dn: OU=Something,O=Something,C=it 
 attribute_mapping:  
 mail: email
 login_attribute: uid
 encryption: none

 Il giorno venerdì 23 novembre 2012 20:30:59 UTC+1, Federico Don ha 
 scritto:
>
> could you try with this setup?
>
> production:
>   disable_default: false
>   methods:
> - adapter: Gitorious::Authentication::**LDAPAuthentication
>host: 172.17.195.115
>   port: 389 
>   base_dn: DC=example,DC=com   
>   bind_username: user_ldap_bind
>   bind_password: password_user_ldap_bind
>   user_filter: 
>   username_attribute: sAMAccountName
>   encryption: none
>   login_attribute: uid
>   distinguished_name_template: "uid={},OU=users,DC=example,**
> DC=com"   
>   attribute_mapping:   
>   mail: email
>
> I hope your comment!
>
> Regards,
>
>
> 2012/11/23 Graziano Aliberti 
>
>> How can I do that? I want just that only the authentication is 
>> handle by LDAP. 
>>
>> Il giorno venerdì 23 novembre 2012 15:13:42 UTC+1, anapsix ha 
>> scritto:
>>>
>>> I'm using Kerberos auth with our LDAP setup (openldap) and its 
>>> working great.. though you do need to edit the auth module code to 
>>> allow 
>>> for SSO.
>>
>>  -- 
>> T