[5465] in Moira

home help back first fref pref prev next nref lref last post

Re: Problems with krb4-less update server/client

daemon@ATHENA.MIT.EDU (Evan Broder)
Tue Aug 4 00:11:29 2009

Message-ID: <4A77B4CE.2090502@mit.edu>
Date: Mon, 03 Aug 2009 21:10:54 -0700
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Garry Zacheiss <zacheiss@mit.edu>
CC: "moiradev@mit.edu" <moiradev@mit.edu>, Debathena <debathena@mit.edu>
In-Reply-To: <4A6F254A.4010607@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

By the way, could you let us know when you've had a chance to deploy
this code on the DCM side? We'd like an opportunity to check the new
update_server before we push the packages we have in testing into
production.

Thanks,
 - Evan

Garry Zacheiss wrote:
> Evan Broder wrote:
>   
>> A few issues with the krb5 pieces of the update code.
>>
>> get_mr_krb5_update_ticket currently takes a krb5_data as the second
>> argument; it should take a krb5_data * (which is what mr_send_krb5_auth
>> passes to it). It looks like this was causing krb5 auth to always fail
>> for both DCMs and update_test. That was fine, since it would always fall
>> back on krb4, except that Debathena is planning to start building Moira
>> without krb4 support soon.
>>
>> Second, I #ifdefed out the auth_002 method from the update_server
>> dispatch table in my original path. That was unnecessary, since auth_002
>> is already #ifdefed to return MR_NO_KRB4 if it's being built without
>> krb4, and that's a better error than MR_UNKNOWN_PROC.
>>
>> I've tested that update_test with this patch against an update_server
>> with this patch (both built without krb4) was able to send a file and
>> execute /bin/ls.
>>
>>     
>
> Thanks.  I've checked this in; I also noted an additional problem: in
> the no krb4 case, auth_002() was return'ing MR_NO_KRB4 but is declared
> void; it needs to send_int(conn, MR_NO_KRB4) to have the desired effect.
>
> Garry
>   

home help back first fref pref prev next nref lref last post