Sds-hd nfs: Difference between revisions

From bwHPC Wiki
Jump to navigation Jump to search
(Redirected page to SDS@hd)
Tag: New redirect
 
(8 intermediate revisions by one other user not shown)
Line 1: Line 1:
#REDIRECT [[SDS@hd]]
= <b> Prerequisites </b> =

* '''Attention:''' To access data served by SDS@hd, You need a '''''Service Password'''''. See details [[Sds-hd_user_access]].

* Additionally the access to SDS@hd is currently only available inside the [https://www.belwue.de/netz/netz0.html 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 [https://www.eduroam.org/where/ eduroam] 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 [mailto:sds-hd-support@urz.uni-heidelberg.de?subject=SDS@hd%20nfs-Client%20Registration 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

* For Kerberos authentication to work, a correctly synchronized system time must be set on each nfs client (e.g. via [https://linux.die.net/man/8/ntpdate ntpdate] ntp01.urz.uni-heidelberg.de or [https://chrony.tuxfamily.org chrony])

= <b> Using NFSv4 for UNIX client </b> =

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''.

== configure kerberos environment for SDS@hd ==

=== kerberized nfs configuration ===

First you have to install kerberos and nfs packages in your system to provide a working kerberos environment. The exact names of the packages depending on you linux distribution (see examples below).

''Example RedHat/CentOS''
<pre>yum install krb5-workstation nfs-utils nfs4-acl-tools</pre>

''Example debian/ubuntu''
<pre>apt install krb5-user nfs-common nfs4-acl-tools nfs-server</pre>
On ubuntu server: nfs-kernel-server


After installing the packages you have to use the following kerberos parameters for connecting to SDS@hd:

* Default Realm = BWSERVICES.UNI-HEIDELBERG.DE
* KDC = bwservices.uni-heidelberg.de

So your kerberos configuration file (/etc/krb5.conf) should contain the following entries:
<pre>
[libdefaults]
default_realm = BWSERVICES.UNI-HEIDELBERG.DE

[realms]
BWSERVICES.UNI-HEIDELBERG.DE= {
kdc = bwservices.uni-heidelberg.de
admin_server = bwservices.uni-heidelberg.de
}
[domain_realm]
.uni-heidelberg.de = BWSERVICES.UNI-HEIDELBERG.DE
uni-heidelberg.de = BWSERVICES.UNI-HEIDELBERG.DE
</pre>

The keytab file of the machine, which you get from the [mailto:sds-hd-support@urz.uni-heidelberg.de SDS@hd Team], has to be stored as ''/etc/krb5.keytab'' in the system.

To enable kerberized NFSv4, you have to set the parameters:
<pre>
NEED_IDMAPD=yes
NEED_GSSD=yes
</pre>
in your nfs configuration.
You can find the configuration depending on your linux distribution, e.g.:
* RedHat/CentOS: <pre>/etc/sysconfig/nfs</pre>
* debian/ubuntu: <pre>/etc/default/nfs-common</pre>

=== ID Mapping ===

In order to be able to correctly resolve the ownership of files and folders, an ID mapping must be set up (assignment of uid/gid to uidNumbers/gidNumbers).

Therefor change the file ''/etc/idmapd.conf'' with the following lines, to enable id mapping for nfs mounts:
<pre>
in /etc/idmapd.conf:
[General]
Domain = urz.uni-heidelberg.de
Local-Realms = BWSERVICES.UNI-HEIDELBERG.DE
</pre>

The connection to SDS@hd LDAP Server is authenticated with the kerberos keytab of your nfs-Client. You can use any tool which supports GSSAPI with kerberos for authentication with the following parameters:
* uri: ldap://bwservices.uni-heidelberg.de
* search_base: dc=bwservices,dc=uni-heidelberg.de,dc=de
* sasl mech: GSSAPI Authentication
* krb5 Realm: BWSERVICES.UNI-HEIDELBERG.DE


==== Example sssd ====

Because [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system-level_authentication_guide/configuring_domains sssd] is one of the standard tools and it supports more than one ldap/identity provider on a system, we are showing here an example configuration for this tool.

First install the packages:
* RedHat/CentOS:
<pre>yum install sssd-client sssd-krb5 sssd-ldap</pre>
* debian/ubuntu:
<pre>apt install sssd sssd-krb5 sssd-ldap sssd-tools libnss-sss libsasl2-modules-gssapi-mit</pre>

Now create a sssd configuration file (/etc/sssd/sssd.conf) like this:

<span style="color:red">Attention: </span> '''Don't forget to update "ldap_sasl_authid" to the Hostname of your machine!'''
<pre>
[sssd]
domains = BWSERVICESAD
config_file_version = 2
services = nss

[domain/BWSERVICESAD]
id_provider = ldap
ldap_uri = ldap://bwservices.uni-heidelberg.de
ldap_search_base = dc=bwservices,dc=uni-heidelberg,dc=de
ldap_referrals = false

ldap_schema = ad
ldap_id_mapping = true
min_id = 100000

ldap_sasl_mech = GSSAPI
krb5_realm = BWSERVICES.UNI-HEIDELBERG.DE
ldap_sasl_authid = <your_hostname>$
ldap_krb5_keytab = /etc/krb5.keytab
krb5_server = bwservices.uni-heidelberg.de
ldap_sasl_canonicalize = false
krb5_canonicalize = false

use_fully_qualified_names = true
full_name_format = %3$s\%1$s

re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$)))
enumerate = false
</pre>

If another service for authentication or name resolution is allready be used on the machine, an additional domain block can be set up for this and should be added to the line "domains".

To enable sssd for id mapping in your system the lines "passwd" and "group" in file "/etc/nsswitch.conf" have to be extended by "sss", e.g.:
<pre>
passwd: compat sss
group: compat sss
</pre>

'''Note''': If you are using sssd you should not use "nscd" in parallel! Otherwise this could lead to undefined behaviour due to double caching passwd, group and netgroup entries.


Now you should enable and restart the services:

* systemctl enable sssd.service && systemctl restart sssd.service
* systemctl restart nfs-idmapd.service

== mount a nfs share ==
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. 2.1) you can mount your SDS@hd share with the following commands:
<pre>
> mkdir <mountpoint>
> mount -t nfs4 -o sec=krb5,vers=4.0 lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint>
</pre>

To enable the mounting after a restart, you have to add the following line to the file "/etc/fstab"
<pre>
lsdf02.urz.uni-heidelberg.de:/gpfs/lsdf02/ <mountpoint> nfs4 sec=krb5,vers=4.0 0 0
</pre>

== 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:
<pre>
> kinit hd_xy123
Password for hd_xy123@BWSERVICES.UNI-HEIDELBERG.DE:
</pre>
You can check afterwards your kerberos ticket with:
<pre>
> 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
</pre>

Afterwards you should be able to access the mountpoint, which contain all Speichervorhaben exported to your machine:
<pre>
> ls <mountpoint>
sd16j007 sd17c010 sd17d005
</pre>

== 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.
<pre>
> kinit -R
</pre>

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:
<pre>kdestroy</pre>

== automated kerberos tickets ==
<span style="color:red"><strong>'''Attention!''' Keep this generated Keytab safe and use it only in trusted environments!</strong></span>

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:''
<pre>
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
</pre>

''non-interactive way:''
<pre>
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
</pre>

With this keytab, you can fetch a kerberos ticket without an interactive password:
<pre>
kinit -k -t xy123.keytab hd_xy123
</pre>
<br>

[[Category:Sds-hd|NFS|Kerberos]]

Latest revision as of 16:49, 19 August 2022

Redirect to:

Retrieved from "https://wiki.bwhpc.de/wiki/index.php?title=Sds-hd_nfs&oldid=10887"