I’m testing out eosxd, and I was wondering if there was more documentation on how to configure it?
I’m using almost exactly the same config from the README.md, with the hostname and a couple other things changed. I can see the fuse mount showing up correctly, but I can’t write etc, and when I do
eos fusex ls nothing shows up. I think I’m having auth issues:
$ cat e/eos/test/proc/whoami
Virtual Identity: uid=99 (99) gid=99 (99) [authz:unix] host=eosxd.testnet
vid settings on the mgm should be correct (vid added host as gateway with sss), the eosxd host has the sss keytab, not sure what else I’m missing…
ps. I looked at the eos-docs page but it looks like it’s still mostly about eosd
I’ve also done some tests with fusex during last weeks.
I can confirm that the documentation is currently only in the Readme file you are pointing out, but it is quite sufficient for simple configuration.
About authentication, I’m not sure whether sss can be used with fusex. I’m using it with Kerberos, and it correctly works (and no need of eosfusebind anymore!)
One disturbing behavior I’m noticing is that when unmounting the fuse mount, the eosxd process doesn’t stop. It needs to be killed (sometimes with the KILL signal) so that further mounts can be created again.
just one word of warning. eosxd works correctly from the ‘dev’ branch builds since tuesday. Also the latest tag 4.2.24 misses many fixes. We discussed to merge everything into a new release.
About the daemon not exiting. You should use ‘umount -fl /eos/’ and then you can immedeatly remount if, even if there is still an application hanging on the previous one (that is reason it does not exit) e.g. you have a shell or something sitting on it.
For the ‘sss’ setup I have to look myself, I don’t remember what are the exact settings in the config. Should add that to the README.
The problem we’re facing is not linked to mount point being busy. In fact, unmount correctly succeeds, as well as subsequent mount command, but then access to mount point fails with
Transport endpoint is not connected. In fact, in the log we see that the new eosxd daemon didn’t start for the following reason, because previous daemon is still existing in process list :
180614 11:44:41 t=1528969481.406703 f=run l=WARN tid=00007efca9ff8c00 s=eosfuse:1278 eosxd stopped version 4.2.22 - FUSE protocol version 28
180614 11:44:41 t=1528969481.406724 f=run l=WARN tid=00007efca9ff8c00 s=eosfuse:1279 ********************************************************************************
180614 11:45:25 t=1528969525.588200 f=connect l=INFO tid=00007feceefcac00 s=RocksKV:67 Opening RocksKV store at local path /var/eos/fusex/md/contingency
180614 11:45:25 t=1528969525.589202 f=connect l=CRIT tid=00007feceefcac00 s=RocksKV:85 Could not open RocksKV store, error: IO error: While lock file: /var/eos/fusex/md/contingency/LOCK:
Resource temporarily unavailable
error: failed to open rocksdb KV cache - path=/var/eos/fusex/md/contingency180614 11:45:25 t=1528969525.589275 f=~EosFuse l=WARN tid=00007feceefcac00 s=eosfuse:103
I just tried also with version 4.2.24, it does the same. It might be linked to some configuration on our side, but it is observed on many different hosts.
You mentioned the dev branch might be more stable, we could try it. Are there some package repositories for this ?
Thanks Franck and Andreas!
I’ll keep an eye out for updates to the fusex README.md.