Greetings all: 

Is the following normal (not seeing /coda/coda.realm when doing ls /coda): 

[root_at_sandbox3 ~]# ll /coda/coda.realm
total 0
[root_at_sandbox3 ~]# ll /coda/
total 0
[root_at_sandbox3 ~]# ll /coda/coda.realm/
total 0
[root_at_sandbox3 ~]# ll -d /coda/coda.realm
drwxr-xr-x 1 root 65534 2048 2010-01-15 06:55 /coda/coda.realm
[root_at_sandbox3 ~]# ll /coda/
total 0
[root_at_sandbox3 ~]# ll /coda/ -a
total 6
dr-xr-xr-x  1 root 65534 2048 2010-01-15 06:10 .
drwxr-xr-x 22 root root  4096 2010-01-15 06:09 ..
[root_at_sandbox3 ~]# touch /coda/coda.realm/file
[root_at_sandbox3 ~]# echo hi >/coda/coda.realm/file
[root_at_sandbox3 ~]# cat /coda/coda.realm/file
hi
[root_at_sandbox3 ~]# 

It looks ok, although with the "stock" coda I could look at /coda and see 
/coda/coda.realm.  Is this "normal" or is something still broken? 


I am working on implementing multiple coda volumes -- we need complete 
isolation of data between environments/groupings of servers, and having a 
volume for each seems the most thorough means of doing it.  Is there any 
logistical problems or limitations to doing this?  Otherwise any insights on 
how to limit use of users to specific volumes would be greatly appreciated. 


And, of course, thanks again for the very active and knowledgable support 
community.  It is far and above what I had dared to hope for. 


Regards,
 -Don
{void} 


root writes: 

> Greetings all:  
> 
> 
>>> Next, try to auth using clog from client host:   
>>> 
>>> [root_at_sandbox3 ~]# clog -method codapassword coda_admin_w_pw_at_coda.realm 
>>> -tokenserver sandbox2.host.domain 370
>>> Password for coda_admin_w_pw/default_at_coda.realm: [random_known_pw]
>> 
>> This should work. It does not complain either.  
>> 
>>> [root_at_sandbox3 ~]# ctokens   
>>> 
>>> Tokens [local user id: root]   
>>> 
>>> [root_at_sandbox3 ~]#
>> 
>> Let you try "ctokens coda.realm", otherwise ctokens tries to read /coda
>> to guess the realms you are intereseted in. This may be wrong for
>> different reasons.
> 
> That was it!  The ctokens line needs the domain to work correctly:  
> 
> [root_at_sandbox3 ~]# ctokens coda.realm  
> 
> Tokens [local user id: root]  
> 
> U_GetLocalTokens: Transport endpoint is not connected
> [root_at_sandbox3 ~]# clog -method kerberos5 coda_admin_user_at_coda.realm 
> -tokenserver sandbox2.host.domain 370 -krealm KERBEROS.REALM -kdc 
> sandbox2.host.domain -servprinc coda/coda.realm
> Password for admin/default_at_coda.realm:
> [root_at_sandbox3 ~]# ctokens coda.realm  
> 
> Tokens [local user id: root]  
> 
>   @coda.realm
>       Coda user id:    coda_admin_uid
>       Expiration time: Sat Jan 23 10:29:15 2010  
> 
> 
>>> ll /coda
>>> total 0
>>> [root_at_sandbox3 ~]# ll /coda/coda.realm
>>> lrw-r--r-- 1 root 65534 16 2010-01-20 21:12 /coda/coda.realm -> 
>>> #@coda.realm
>> 
>> This indicates some problem while traversing the root volume mount point.
>> As the root volume has been created automatically, it should be healthy.  
>> 
>> Let you double check the DNS SRV records for coda.realm.
> 
> Looks like something is certainly still wrong:  
> 
> [root_at_sandbox3 ~]# ls /coda/
> [root_at_sandbox3 ~]# ll /coda/coda.realm
> lrw-r--r-- 1 root 65534 16 2010-01-20 21:12 /coda/coda.realm -> 
> #@coda.realm  
> 
> 
> DNS has the following coda related entries (ported into bind-esque 
> format):  
> 
> _codasrv._udp SRV "10 10 2432 sandbox2.host.domain"
> _codaauth2._udp SRV "10 10 370 sandbox2.host.domain"
> _codaauth2._tcp SRV "10 10 370 sandbox2.host.domain"  
> 
> Note the extra "10".  I must have forgotten to strip out the leading '10' 
> and place it in the priority column.  Fixed it to look like (again, 
> pseudo-bind format):  
> 
> _codasrv._udp SRV 10 "10 2432 sandbox2.host.domain"
> _codaauth2._udp SRV 10 "10 370 sandbox2.host.domain"
> _codaauth2._tcp SRV 10 "10 370 sandbox2.host.domain"  
> 
> 
> Attempted the following:  
> 
> [root_at_sandbox3 ~]# ll /coda/coda.realm
> total 0
> [root_at_sandbox3 ~]# ll /coda/
> total 0
> [root_at_sandbox3 ~]# ll /coda/coda.realm/
> total 0
> [root_at_sandbox3 ~]# ll -d /coda/coda.realm
> drwxr-xr-x 1 root 65534 2048 2010-01-15 06:55 /coda/coda.realm
> [root_at_sandbox3 ~]# ll /coda/
> total 0
> [root_at_sandbox3 ~]# ll /coda/ -a
> total 6
> dr-xr-xr-x  1 root 65534 2048 2010-01-15 06:10 .
> drwxr-xr-x 22 root root  4096 2010-01-15 06:09 ..
> [root_at_sandbox3 ~]# touch /coda/coda.realm/file
> [root_at_sandbox3 ~]# echo hi >/coda/coda.realm/file
> [root_at_sandbox3 ~]# cat /coda/coda.realm/file
> hi
> [root_at_sandbox3 ~]#  
> 
> 
> It looks ok, although with the "stock" coda I could look at /coda and see 
> /coda/coda.realm.  Is this "normal" or is something still broken?  
> 
> Regardless, I'll start converting my command line into codaauth2.conf (and 
> perhaps .codafs/clog/pref if it's worth doing).  
> 
> 
> Oh, and thank you for your assistance.  Really.  I cannot express this 
> adequately enough through email.  You have potentially saved me days worth 
> of trial and error.  
> 
> 
> I've created a user on codawiki so I can create a simple howto on a basic 
> coda+kerberos (w/modular clog) setup -- I'll even use codaauth/. ;)  I'll 
> post the URL here when complete.  Possibly this weekend.  Perhaps others 
> in my situation will find my insights useful.  
> 
> 
> Regards,
> -Don
> {void}  
> 
>