Do you have hostname associated with the IP address so when you do a reverse lookup it resolves the hostname?
Jeremy On Thu, Feb 27, 2020, 11:41 AM Steve Brasier <[email protected]> wrote: > Thanks Jeremy. I will file a bug - I've confirmed that if I'm actually > ssh'd in as root then `keyctl read` can read the keys created by `mount -t > lustre ... -o skpath=<securedir>`. So that's definitely an issue. > > However, using this workaround of actually logging in as root I now get > the following when trying to mount: > > lustre-admin lgss_keyring: [11142]:ERROR:lgss_get_service_str(): cannot > resolve hostname from nid 20001c0a8290a > > The only reference <https://jira.whamcloud.com/browse/LU-10593>I can find > to this error is IB networks where the interconnect doesn't have an IP. > That's not the issue here and I can `lnetctl ping` the mgs by NID. > > Is there some config I'm missing? > > many thanks > Steve > > http://stackhpc.com/ > Please note I work Tuesday to Friday. > > > On Wed, 26 Feb 2020 at 00:42, Jeremy Filizetti <[email protected]> > wrote: > >> This is a known issue. I've had this issue pop up after several days for >> no apparent reason. At this point I'm thinking the keyring will need to be >> configurable to provide a workaround. Ideally the keys would be added to a >> Lustre specific keyring so everything would be cleaned up when the modules >> are removed However, the problem there is they need to be loaded before >> the mount system call. >> >> Please file a bug if you have a chance. >> >> Jeremy >> >> On Tue, Feb 25, 2020 at 6:18 AM Steve Brasier <[email protected]> >> wrote: >> >>> Hi all, >>> >>> I'm trying to configure a lustre 2.12.2 system with SSK and I believe I >>> have a problem with kernel keys which I'd be grateful for any suggestions >>> on. >>> >>> Essentially I have followed the instructions/examples in the docs for >>> SSK except that: >>> - A host "lustre-storage" hosts the MGS, MDT and OST with the fileystem >>> "test_fs1". >>> - A host "lustre-client1" is in a nodeset "lustre_client1". >>> - cli2ost and cli2mdt rules set as skn >>> (happy to provide more details if required but I think that's the major >>> differences from the examples) >>> >>> Trying to mount the filesystem from the client fails: >>> >>> [centos@lustre-client1 ~]$ sudo mount -t lustre 192.168.41.10@tcp1:/test_fs1 >>> -o skpath=/etc/lustre /mnt/lustre/test_fs1/ >>> mount.lustre: mount 192.168.41.10@tcp1:/test_fs1 at >>> /mnt/lustre/test_fs1 failed: Connection refused >>> >>> Looking in /var/log/messages I can see: >>> >>> lustre-client1 lgss_keyring: [18756]:ERROR:sk_create_cred(): >>> keyctl_read() failed for key 1073636326: Permission denied >>> >>> And in fact there is a problem reading this key: >>> [centos@lustre-client1 ~]$ sudo keyctl list @u >>> 1 key in keyring: >>> 1073636326: --alswrv 0 0 user: lustre:test_fs1 >>> [centos@lustre-client1 ~]$ sudo keyctl read 1073636326 >>> keyctl_read_alloc: Permission denied >>> >>> If I try to create a key myself I can see it has the same permissions >>> as 1073636326, and again reading it fails. Some googling led me to this >>> <https://mjg59.dreamwidth.org/37333.html> which suggests there's a >>> fundamental problem using sudo with kernel keys *. I can't be the only >>> person to try to deploy lustre using sudo though surely? So there must be >>> something I'm missing here to make this work. >>> >>> To work around this I tried including "user" in the /etc/fstab options >>> then mounting as a normal user but that fails: >>> [centos@lustre-client1 ~]$ mount /mnt/lustre/test_fs1/ >>> mount.lustre: mount 192.168.41.10@tcp1:/test_fs1 at >>> /mnt/lustre/test_fs1 failed: Operation not permitted >>> >>> and in fact it appears lustre doesn't support the user option? >>> Feb 25 11:12:27 lustre-client1 kernel: LustreError: 152-6: Unknown >>> option 'user', won't mount. >>> >>> >>> As I said any help appreciated! >>> >>> Steve >>> >>> * Although that link says key possession is tied to the original user, >>> which would suggest that the key should show up in centos's keyring, which >>> it doesn't. >>> >>> http://stackhpc.com/ >>> Please note I work Tuesday to Friday. >>> >>>> _______________________________________________ >>> lustre-discuss mailing list >>> [email protected] >>> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org >>> >>
_______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
