From alexey.chebotar at gmail.com  Tue Jun  1 14:27:52 2010
From: alexey.chebotar at gmail.com (Alexey Chebotar)
Date: Tue, 1 Jun 2010 21:27:52 +0300
Subject: [activeldap-discuss] Moving Objects To New Container
In-Reply-To: <20100530.193528.2192893794132001902.kou@cozmixng.org>
References: <134379404.37561.1271456771516.JavaMail.root@zcs10.wiu.edu>
	<2130192278.37605.1271456949825.JavaMail.root@zcs10.wiu.edu>
	<20100530.193528.2192893794132001902.kou@cozmixng.org>
Message-ID: <D2C86D19-043C-43B9-B8B4-352B201B930C@gmail.com>


30 ??? 2010, ? 13:35, Kouhei Sutou ???????(?):

> Hi,
> 
> In <2130192278.37605.1271456949825.JavaMail.root at zcs10.wiu.edu>
>  "Re: [activeldap-discuss] Moving Objects To New Container" on Fri, 16 Apr 2010 17:29:09 -0500 (CDT),
>  Matt Mencel <MR-Mencel at wiu.edu> wrote:
> 
>> I took a look at Alexey's Ruby/LDAP code on github.  No idea if this would work....but the PERL examples I've seen put newsuperior before deleteoldrdn in the params list.  Just wondering if all it takes is a patch submission?
> 
> ActiveLdap needs Ruby/LDAP new_superior support to move an
> entry to a new container. Alexey, could you consider to
> support new_superior?
> 

Hi Kou,

Sorry for the silence. I'll have time after June 12.
Looking at ldap.h out of old openldap 2.4.16, I saw that all ldap_modrdn was deprecated, and they does not support newSuperior attribute.

I hope I can implement ldap_rename functionality. My knowledge of C language is still very bad. :(

/*
 * in modrdn.c:
 */
LDAP_F( int )
ldap_rename LDAP_P((
	LDAP *ld,
	LDAP_CONST char *dn,
	LDAP_CONST char *newrdn,
	LDAP_CONST char *newSuperior,
	int deleteoldrdn,
	LDAPControl **sctrls,
	LDAPControl **cctrls,
	int *msgidp ));

LDAP_F( int )
ldap_rename_s LDAP_P((
	LDAP *ld,
	LDAP_CONST char *dn,
	LDAP_CONST char *newrdn,
	LDAP_CONST char *newSuperior,
	int deleteoldrdn,
	LDAPControl **sctrls,
	LDAPControl **cctrls ));

#if LDAP_DEPRECATED
LDAP_F( int )
ldap_rename2 LDAP_P((	/* deprecated, use ldap_rename */
	LDAP *ld,
	LDAP_CONST char *dn,
	LDAP_CONST char *newrdn,
	LDAP_CONST char *newSuperior,
	int deleteoldrdn ));

LDAP_F( int )
ldap_rename2_s LDAP_P((	/* deprecated, use ldap_rename_s */
	LDAP *ld,
	LDAP_CONST char *dn,
	LDAP_CONST char *newrdn,
	LDAP_CONST char *newSuperior,
	int deleteoldrdn ));

LDAP_F( int )
ldap_modrdn LDAP_P((	/* deprecated, use ldap_rename */
	LDAP *ld,
	LDAP_CONST char *dn,
	LDAP_CONST char *newrdn ));

LDAP_F( int )
ldap_modrdn_s LDAP_P((	/* deprecated, use ldap_rename_s */
	LDAP *ld,
	LDAP_CONST char *dn,
	LDAP_CONST char *newrdn ));

LDAP_F( int )
ldap_modrdn2 LDAP_P((	/* deprecated, use ldap_rename */
	LDAP *ld,
	LDAP_CONST char *dn,
	LDAP_CONST char *newrdn,
	int deleteoldrdn ));

LDAP_F( int )
ldap_modrdn2_s LDAP_P((	/* deprecated, use ldap_rename_s */
	LDAP *ld,
	LDAP_CONST char *dn,
	LDAP_CONST char *newrdn,
	int deleteoldrdn));
#endif

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ruby-activeldap-discuss/attachments/20100601/3b81683f/attachment.html>

From joerg at oiml.at  Wed Jun  2 07:41:03 2010
From: joerg at oiml.at (=?iso-8859-1?Q?J=F6rg?= Herzinger)
Date: Wed, 2 Jun 2010 13:41:03 +0200
Subject: [activeldap-discuss] GSSAPI connection problems
In-Reply-To: <20100530072716.GA21139@oiml.at>
References: <20100530072716.GA21139@oiml.at>
Message-ID: <20100602114103.GC21139@oiml.at>

I found the problem and was able to fix it. Ruby/LDAP was missing, after that was installed and built correctely everything worked as expected. Here my puppet recipie for the depends. I guess its quite easy to understand/read for those unfamiliar with puppet. System is Ubuntu 9.10, but I guess it works for and Debian machine.

   package { "RubyGEM depends":
    name => ["rubygems","ruby-dev","libsasl2-dev","libldap2-dev"],
    ensure => installed,
  }

  package { ["activeldap","ruby-ldap"]:
    provider => gem,
    ensure => present,
    require => Package["RubyGEM depends"],
  }

  package { ["libsasl2-modules","libsasl2-modules-gssapi-mit"]:
    ensure => present,
  }

so long,
    J?rg

From kou at cozmixng.org  Sun Jun  6 01:34:52 2010
From: kou at cozmixng.org (Kouhei Sutou)
Date: Sun, 06 Jun 2010 14:34:52 +0900 (JST)
Subject: [activeldap-discuss] Moving Objects To New Container
In-Reply-To: <D2C86D19-043C-43B9-B8B4-352B201B930C@gmail.com>
References: <2130192278.37605.1271456949825.JavaMail.root@zcs10.wiu.edu>
	<20100530.193528.2192893794132001902.kou@cozmixng.org>
	<D2C86D19-043C-43B9-B8B4-352B201B930C@gmail.com>
Message-ID: <20100606.143452.42212234329884827.kou@cozmixng.org>

Hi,

In <D2C86D19-043C-43B9-B8B4-352B201B930C at gmail.com>
  "Re: [activeldap-discuss] Moving Objects To New Container" on Tue, 1 Jun 2010 21:27:52 +0300,
  Alexey Chebotar <alexey.chebotar at gmail.com> wrote:

>     ActiveLdap needs Ruby/LDAP new_superior support to move an
>     entry to a new container. Alexey, could you consider to
>     support new_superior?
> 
> Hi Kou, Sorry for the silence. I'll have time after June 12. Looking at ldap.h
> out of old openldap 2.4.16, I saw that all ldap_modrdn was deprecated, and they
> does not support newSuperior attribute. I hope I can implement ldap_rename
> functionality. My knowledge of C language is still very bad. :(

Alexey, thanks for your answer.
Please don't apologize. We have our life and you also have
your life. We can't use all time for LDAP. :-)


Thanks,
--
kou

From joerg at oiml.at  Thu Jun 10 07:22:26 2010
From: joerg at oiml.at (=?iso-8859-1?Q?J=F6rg?= Herzinger)
Date: Thu, 10 Jun 2010 13:22:26 +0200
Subject: [activeldap-discuss] Small bug with deleting groups
Message-ID: <20100610112226.GI21139@oiml.at>

Hi, I found some particularly evil behavior in ActiveLDAP. 
When I try to add some groups for a user via user.groups=Array the user first gets removed from these groups and is then added again. This is really evil for me, because I do have a group ldapadmins that is allowed to administrate my LDAP and once I get removed from this group I can't add myself anymore.
Ok, I avioded this problem, by first checking which groups the user should be removed from and which he should be added to. Adding is quite easy via:

groups_he_should_be_added_to = [ "group1", "group2" ]
user.groups.concat( groups_he_should_be_added_to - groups_he_is_currently_member_of )

but deleting groups does not work with the groups cn names:

(groups_he_should_be_removed_from & groups_he_is_currently_member_of).each { |g| user.groups.delete(g) }

which fails with:
/var/lib/gems/1.8/gems/activeldap-1.2.1/lib/active_ldap/association/collection.rb:30:in `delete': undefined method `new_entry?' for "groupname":String (NoMethodError)

one instead has to use user.groups.delete(Group.find(g)). I think this should be fixed to keep everything consistent.

so long,
    Joerg

From kou at cozmixng.org  Tue Jun 29 10:19:15 2010
From: kou at cozmixng.org (Kouhei Sutou)
Date: Tue, 29 Jun 2010 23:19:15 +0900 (JST)
Subject: [activeldap-discuss] Small bug with deleting groups
In-Reply-To: <20100610112226.GI21139@oiml.at>
References: <20100610112226.GI21139@oiml.at>
Message-ID: <20100629.231915.875958547440588922.kou@cozmixng.org>

Hi,

In <20100610112226.GI21139 at oiml.at>
  "[activeldap-discuss] Small bug with deleting groups" on Thu, 10 Jun 2010 13:22:26 +0200,
  J?rg Herzinger <joerg at oiml.at> wrote:

> Hi, I found some particularly evil behavior in ActiveLDAP. 
> When I try to add some groups for a user via user.groups=Array the user first gets removed from these groups and is then added again. This is really evil for me, because I do have a group ldapadmins that is allowed to administrate my LDAP and once I get removed from this group I can't add myself anymore.
> Ok, I avioded this problem, by first checking which groups the user should be removed from and which he should be added to. Adding is quite easy via:
> 
> groups_he_should_be_added_to = [ "group1", "group2" ]
> user.groups.concat( groups_he_should_be_added_to - groups_he_is_currently_member_of )
> 
> but deleting groups does not work with the groups cn names:
> 
> (groups_he_should_be_removed_from & groups_he_is_currently_member_of).each { |g| user.groups.delete(g) }
> 
> which fails with:
> /var/lib/gems/1.8/gems/activeldap-1.2.1/lib/active_ldap/association/collection.rb:30:in `delete': undefined method `new_entry?' for "groupname":String (NoMethodError)
> 
> one instead has to use user.groups.delete(Group.find(g)). I think this should be fixed to keep everything consistent.

Thanks for your suggestion.
I've fixed it in trunk.

Thanks,
--
kou