[OpenAFS-devel] Accomodating daemons

[Erik Osterman]

Thank you all for the thoughtful responses I've been receiving. kstart 
seemed like the most secure solution, but ultimately, we've decided to 
go the OpenVPN route since other parts of our application would benefit 
from this private/secured network. We can always move to kstart once our 
architecture is more defined. OpenVPN was a snap to setup and I'm able 
to communicate over the network (10.0.0.0)

I am totally dumbfounded, however, why I am unable to get OpenAFS to 
communicate via the VPN 10.0.0.0; it always communicates via the public IP.

CellServDB:
 >ourdomain.com # Ourcompany
10.0.0.1    #ourmachine

ThisCell:
ourdomain.com

/usr/vice/etc/CellServDB is linked to /usr/afs/CellServDB
/usr/vice/etc/ThisCell is linked to /usr/afs/ThisCell

I am trying to connect 10.0.0.6 to 10.0.0.1, the AFS (1.4.2) server. I 
have purged the /usr/vice/cache directory. I have restarted the 
openafs-client. I have even rebooted the machine.

I ran,

pts createuser 10.0.0.0
pts adduser 10.0.0.0 -group ourgroup

If I list /afs/ourcompany.com from 10.0.0.6, I get permission denied.

If 1.2.3.4 is our public IP (on the same machine as 10.0.0.6), and I run

pts createuser 1.2.3.0
pts adduser 1.2.3.0 -group ourgroup

then list /afs/ourcompany.com it works as expected. This would mean that 
ourgroup is properly configured, but for some reason the OpenAFS client 
is not communicating using the 10 network.

If anyone has any ideas what could be happening here, I'd appreciate to 
hear from you!

Best Regards,

Erik Osterman


Russ Allbery wrote:
> Erik Osterman <e@osterman.com> writes:
>
>   
>> I have a question I've seen asked many times before. My problem is, I
>> haven't been able to find a solution that works for us.
>>     
>
>   
>> Scenario: a cluster of VMs assigned dynamic IPs from shared networks,
>> where each VM is a closed system running daemons that need access to a
>> private OpenAFS cell.  We are unable to grant access based on subnets,
>> since any subnet other than /32 cannot be trusted on the shared network.
>>     
>
>   
>> One solution I've seen is to wrap the process with an aklog system call
>> to obtain a token. Problem with this is that the token expires after a
>> maximum of 100 hours, which means every 100 hours we must restart the
>> processes on the node. If the daemon process forks off another process,
>> I'm not sure if the token is inherited; more over, if these are CGIs it
>> might be non-trvial to add the token request.
>>     
>
> This is the reason why we wrote kstart at Stanford.  See:
>
>     <http://www.eyrie.org/~eagle/software/kstart/>
>
> and:
>
>     <http://www.stanford.edu/services/afs/sysadmin/userguide/web-pages.html>
>
> for some somewhat older documentation on various approaches.  Since then,
> I've added to kstart the ability to run a command given on its command
> line in a PAG with AFS tokens, which is a better solution in many cases.
>
>