strange problem with kinit

[Paul Palacios]

You might also want to look into "mod_auth_kerb" for apache.
It may do all that you need and you can place setting in httpd.conf or 
equiv:

  <IfModule mod_auth_kerb.c>
            KrbAuthRealms XXX.COM
            KrbMethodNegotiate off
            KrbVerifyKDC off
            Krb5Keytab /etc/http/conf/krb5.keytab
  </IfModule> 

Rohit Kumar Mehta wrote:
> Thanks Kevin, using k5start and a keytab seems is a much better
> solution!  I did not know this existed.  This seems to
> work quite well.
>
> However, if my "echo password | kinit" script should work,
> it might be worthwhile to figure out where the problem is.
> I have done some more tests and saved the logs for gssd -vvvvvv
> in both not working and working states.  I did not notice anything
> in the logs (they are big!) that tipped me off to the problem, but
> if you like I can send them to you.
>
>
> Kevin Coffman wrote:
>   
>> I don't have an answer to why the cron thing fails.  However, running
>> gssd with -vvv will give a clue toward what credentials caches are
>> being considered.
>>
>> I would suggest using a keytab rather than keeping a password around
>> in a script, file, or wherever you are keeping it now.
>>
>> You might also want to look at kstart and krenew:
>>
>> http://www.eyrie.org/~eagle/software/kstart/
>> http://www.eyrie.org/~eagle/software/kstart/krenew.html
>>
>>
>> On Tue, Jun 24, 2008 at 4:17 PM, Rohit Kumar Mehta
>> <rohitm at engr.uconn.edu> wrote:
>>   
>>     
>>> Hi guys, is there any reason running kinit from a cronjob would have
>>> different
>>> results from running from the shell?
>>>
>>> Here is my problem in a nutshell:  We are trying to setup a webserver to
>>> serve
>>> NFS-mounted public_html directories with sec=krb5.   The apache process
>>> (running as nobody) needs some kerberos credentials to access these NFS
>>> exported files (perms 755). To solve this I create a crontab for nobody
>>> which
>>> issues a command like the following:
>>>
>>>    echo myPassword | kinit nobody at AD.ENGR.UCONN.EDU
>>>
>>> Before my cronjob runs, I su to nobody and run klist:
>>>
>>>    nobody at sumo2:/root$ klist
>>>    klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_65534)
>>>
>>>
>>>    Kerberos 4 ticket cache: /tmp/tkt65534
>>>    klist: You have no tickets cached
>>>
>>> If I do an "ls /home/rohitm/public_html", I get a "Permission denied"
>>> error, and see
>>> the following in my logs:
>>>
>>> Jun 24 15:44:43 sumo2 rpc.gssd[3968]: ERROR: GSS-API: error in
>>> gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide
>>> more information - No credentials cache found
>>> Jun 24 15:44:43 sumo2 rpc.gssd[3968]: WARNING: Failed to create krb5
>>> context for user with uid 65534 for server filesm.ad.engr.uconn.edu
>>>
>>> Now when the cronjob fires, I su to nobody and issue a klist:
>>>
>>>    nobody at sumo2:~$ klist -f
>>>    Ticket cache: FILE:/tmp/krb5cc_65534
>>>    Default principal: nobody at AD.ENGR.UCONN.EDU
>>>
>>>    Valid starting     Expires            Service principal
>>>    06/24/08 15:30:02  06/25/08 01:30:02
>>> krbtgt/AD.ENGR.UCONN.EDU at AD.ENGR.UCONN.EDU
>>>            renew until 06/25/08 15:30:02, Flags: FRIA
>>>    06/24/08 15:30:32  06/25/08 01:30:02
>>> nfs/filesm.ad.engr.uconn.edu at AD.ENGR.UCONN.EDU
>>>            renew until 06/25/08 15:30:02, Flags: FRA
>>>    06/24/08 15:30:32  06/25/08 01:30:02  FILESM$@AD.ENGR.UCONN.EDU
>>>            renew until 06/25/08 15:30:02, Flags: FRA
>>>
>>>
>>>    Kerberos 4 ticket cache: /tmp/tkt65534
>>>    klist: You have no tickets cached
>>>
>>> Now comes the confusing part.  At this point issuing a command like "ls
>>> -al /home/rohitm" *sometimes*
>>> succeeds, and other times it will continue to fail until the next time
>>> the cronjob trips or I
>>> run the kinit manually.  I am really not sure what is going on, but I
>>> did find this thread:
>>>
>>>    http://linux-nfs.org/pipermail/nfsv4/2007-October/006915.html
>>>
>>> and am trying out kkeepd.  In the meantime, does anyone know why my
>>> "echo password | kinit" seems
>>> to fail intermittently?
>>>
>>> --
>>> Rohit Mehta
>>> Computer Engineer
>>> University of Connecticut
>>> Engineering Computing Services
>>> 371 Fairfield Road Unit 2031
>>> Storrs, CT 06269-2031
>>>
>>> Office: (860) 486 - 2331
>>> Fax: (860) 486 - 1273
>>>
>>>
>>> _______________________________________________
>>> NFSv4 mailing list
>>> NFSv4 at linux-nfs.org
>>> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>>>
>>>
>>>     
>>>       
>>   
>>     
>
>
>   


-- 
Paul Palacios
paul at c-group.com