COmanage Developers List

[Scott Koranda <>]

On Sat, Apr 26, 2014 at 10:20 AM, Scott Koranda 
<>
 wrote:
> Hi,
>
> This is fantastic. I have a question below and some input, but let me
> begin by saying this is fantastic.
>
> On Mon, Apr 21, 2014 at 9:30 PM, Benn Oshrin 
> <>
>  wrote:
>> I've just pushed a commit to develop for the HTCondor SSH use case. The
>> ldapPublicKey is now supported and fully usable... and admin can upload an
>> SSH key to a CO Person, enable the ldapPublicKey schema in the
>> LdapProvisioner, and write the key to LDAP.
>
> I have not gotten to that yet, but...
>
>>
>> posixAccount is a bit trickier. We should really have a UnixAccount model,
>
> I see that, yes, and I concur. Still...
>
>> but for now posixAccount pulls much of what it needs from the Identifiers
>> model (so you can auto-assign the relevant identifiers). To set this up,
>> create Extended Types for Identifiers called "gidNumber", "homeDirectory",
>> and "uidNumber" (case sensitive).
>
> That worked.
>
>>Populate these identifiers for your CO
>> Person (manually or via auto assignment)
>
> So the auto assignment was broken, again because of calculateImpliedCoId().
>
> I *think* the correct thing to do is add
>
>   public $requires_person = True;
>
> to IdentifiersController, and then in the assign() method add
>
> $this->requires_co = True;
>
> I did that and it allowed auto assignment to work.

So that was necessary and sufficient on my test box.

For the gw-astronomy.org deployment, however, where org identities are pooled
it was necessary but not sufficient.

The problem is that the Identifier.php model is calling
'validateExtendedType' to validate
the extended types and that method is not getting the CO Id because
the computation
is different when org identities are being pooled.

I don't have time to untangle that right now so for the demo I am just
turning off
the validation of extended types.

Should I capture this in a ticket or is it known this is part of an
existing JIRA ticket?


>
> The only "real" method for that controller is assign(), and the only
> thing being assigned as far as I can tell are identifiers on a CO
> Person. That implies a CO Person is required, hence requires_person
> should be true. The assing() method includes this comment
>
> // While the controller doesn't require_co, this method does.
>
> So I added
>
> $this->requires_co = True;
>
> right before the call to parseCOID.
>
> Does that sound correct? Should I commit it?
>
>> and enable the posixAccount schema
>> to write these to LDAP.
>
> It worked!
>
>> gecos is constructed from cn
>
> Good enough for now...
>
>> and loginShell is
>> hardcoded to /bin/tcsh.
>
> Ha! You are showing your age...
>
> I will work on the SSH key next...
>
> Thanks,
>
> Scott
>
>>
>> I should be able to get the homeDirectory provisioner stubbed out in the
>> next day or two, but in the mean time Scott, you should be able to make 
>> some
>> progress on connecting a VM to LDAP with these changes.
>>
>> Thanks,
>>
>> -Benn-