[OpenAFS-devel] Accomodating daemons

[Derrick J Brashear]

Did the vpn net come up after OpenAFS was started?

On Sun, 26 Nov 2006, Erik Osterman wrote:

> 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.
>> 
>> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
>