Sds-hd nfs: Difference between revisions
Line 6: | Line 6: | ||
* The access via nfs protocol is machine-based, which means '''new nfs-Clients have to be registered''' on SDS@hd. During this registration each machine gets a keytab file, which allows mounting SDS@hd. |
* The access via nfs protocol is machine-based, which means '''new nfs-Clients have to be registered''' on SDS@hd. During this registration each machine gets a keytab file, which allows mounting SDS@hd. |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
= <b> Using NFSv4 for UNIX client </b> = |
= <b> Using NFSv4 for UNIX client </b> = |
Revision as of 10:46, 21 April 2020
Prerequisites
- Attention: To access data served by SDS@hd via CIFS, You need a Service Password. See details Sds-hd_user_access.
- Additionally the access to SDS@hd is currently only available inside the belwue-Network. This means you have to use the VPN Service of your HomeOrganization, if you want to access SDS@hd from outside the bwHPC-Clusters (e.g. via edoroam or from your personal Laptop)
- The access via nfs protocol is machine-based, which means new nfs-Clients have to be registered on SDS@hd. During this registration each machine gets a keytab file, which allows mounting SDS@hd.
- Currently you have to send an email for Clientregistration to SDS@hd Team with the following information:
- hostname of the new nfs-Client
- IP address
- short description
- location
- acronym of the Speichervorhabens which should be available on this machine
Using NFSv4 for UNIX client
The authentication for data access via NFSv4 is performed using Kerberostickets. This requires a functioning Kerberos environment on the client!
The following parameters of kerberos tickets are set on server side:
- max. Lifetime of a Serviceticket: 10 hours
- max. Lifetime of a Userticket: 24 hours
- max. Renewaltime for Usertickets: 10 days
The properties (e.g. lifetimes, encryption, ...) of the kerberos tickets can be changed on client site with different kinit parameters (see manpages of kinit) or via /etc/krb5.conf.
The usual restrictions for mounting drives under Linux apply. Usually this can only be done by the superuser "root". For detailed information, please contact the system administrator of your system.
After successfull configuration (s. Prequisites) you can mount your SDS@hd share with the following commands:
> mkdir <mountpoint> > mount -t nfs4 -o sec=krb5 lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint>
To enable the mounting after a restart, you have to add the following line to the file "/etc/fstab"
lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint> nfs4 sec=krb5 0 0
access your data
Attention! The access can not be done as root user, because root uses the Kerberosticket of the machine, which does not have data access!
To access your data on SDS@hd you have to fetch a valid kerberos ticket with your SDS@hd user and Servicepassword:
> kinit hd_xy123 Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:
You can check afterwards your kerberos ticket with:
> klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE Valid starting Expires Service principal 20.09.2017 04:00:01 21.09.2017 04:00:01 krbtgt/BWSERVICES.UNI-HEIDELBERG.DE@BWSERVICES.UNI-HEIDELBERG.DE renew until 29.09.2017 13:38:49
Afterwards you should be able to access the mountpoint, which contain all Speichervorhaben exported to your machine:
> ls <mountpoint> sd16j007 sd17c010 sd17d005
renew a kerberos ticket
Because a kerberos ticket has a limited lifetime (default: 10 hours, maximum 24 hours) for security reasons, you have to renew your ticket before it expires to prevent access loss.
> kinit -R
This renewal could only be done for maximum time of 10 Days and as long as the current kerberos ticket is still valid. For renewal of an expired ticket, you have to use again your Servicepassword.
destroy kerberos ticket
Even if kerberos tickets are only valid for a limited period of time, a ticket should be destroyed as soon as access is no longer needed to prevent misuse on multi-user systems:
kdestroy
automated kerberos tickets
Attention! Keep this generated Keytab safe and use it only in trusted environments!
If your workflow needs a permanent access to SDS@hd for longer than 10 Days, you can use ktutil to encrypt your Service Password into a keytab file:
interactive way:
ktutil ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: ktutil: addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE: ktutil: wkt xy123.keytab ktuitl: quit
non-interactive way:
echo -e "addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e rc4-hmac\n<your_servicepasword>\n addent -password -p hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE -k 1 -e aes256-cts\n<your_servicepasword>\nwkt xy123.keytab" | ktutil
With this keytab, you can fetch a kerberos ticket without an interactive password:
kinit -k -t xy123.keytab hd_xy123