[OpenAFS-devel] Accomodating daemons

[Erik Osterman]

It would appear that openvpn is started before openafs-client. In 
addition, I've restarted the openafs-client several times after reboot 
with no avail.

openvpn         0:off   1:off   2:off   3:off   4:on    5:off   6:off
openafs-client  0:off   1:off   2:on    3:on    4:on    5:on    6:off

rc.d/rc4.d/S24openvpn
rc.d/rc4.d/S50openafs-client


Though after a reboot, I realize "fs getclientaddrs" no longer lists our 
internal 10 ip, but just our public IP.


Should I have OpenVPN call "/etc/init.d/openafs-client start" when the 
link comes up, instead of relying on the rc.d init order?


Regards,

Erik Osterman



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