Slurmを用いる計算機クラスターの設定

• クラスタ内部ネットワーク用のインターフェースを firewall の trusted ゾーンに設定する。

nmcli connection modify <interface name> connection.zone trusted
nmcli connection down <interface name>; nmcli connection up <interface name>

firewall-cmd --reload

• インターフェース名は、ip a コマンドで確認できる。

• firewall-cmd --get-active-zones として、設定が反映されているか確認する。

HTTP ブートでは、BIOS や UEFI においてネットワーク起動が指定された計算機では、起動時にネットワークを介して DHCP サーバに対して IP アドレスの付与および起動プログラム（ブートローダー）の置き場所の通知リクエストをブロードキャストする。このブロードキャストを受け取った DHCP サーバのうち、返答が最も早かったものが用いられる。したがって、HTTPブートを行う場合には、起動時に計算機が接続されているネットワーク内に DHCP サーバは 1 つだけあるような状況が望ましい。

・HTTPサーバの設定

• HTTPとは、Hyper Text Transfer Protocolのこと。

• プログラムの準備

systemctl status httpd として、httpdサーバに必要なプログラムがインストールされているか確認する。インストールされていなければ、
dnf install -y @web-server
でインストールする。

• 設定ファイル：/etc/httpd/conf/httpd.conf

• HTTP のルートディレクトリは 設定ファイル中の "DocumentRoot"オプションで指定する。デフォルトでは "DocumentRoot /var/www/html" と記載されている。 

• httpd を起動する。同時に、システム起動時に httpd が起動するよう設定する。
  systemctl enable --now httpd 

• htmlディレクトリの SELinux コンテキストを復元しておく。
  restorecon -FvvR /var/www/html

・DHCPサーバの設定

• DHCP とは、Dynamic Host Configuration Protocol のこと。

• プログラムの準備

小規模ネットワーク向けの DNSサーバ、DHCPサーバ、TFTPサーバの機能を提供する dnsmasq というプログラムを用いる。

systemctl status dnsmasq として、dhcp サーバに必要なプログラムがインストールされているか確認する。インストールされていなければ、
dnf install -y @network-server
でインストールする。

• 設定ファイル：/etc/dnsmasq.conf

DHCP サーバの設定ファイルには、サーバへの接続を許可するネットワークと、HTTPブートする計算機（クライアント）が用いる起動プログラム（ブートローダー）のパスを記載する必要がある。そこで以下のように、設定ファイルにネットワーク（subnet …）と起動プログラムのパス（filename …） を記載する。

設定ファイル内での 0.0.0.0 は、dnsmasq を実行しているサーバ自身を指す。 

# /etc/dnsmasq.conf

# 以下では、cat /etc/dnsmasq.conf | grep -v '#' | grep -v '^$' でコメントアウトされていない部分のみ抜粋した結果を記載する。

user=dnsmasq

group=dnsmasq

interface=<interface name>

# DHCPサーバの設定

dhcp-range=<MIN IP address to assign>,<MAX IP address to assign>,12h

dhcp-option=option:router,0.0.0.0 

dhcp-option=option:dns-server,0.0.0.0

dhcp-option=option:ntp-server,0.0.0.0

dhcp-match=set:efi-x86_64,option:client-arch,7

dhcp-boot=tag:efi-x86_64,<path of "BOOTX64.EFI" relative to tftp-root>

dhcp-match=set:bios-x86,option:client-arch,0

dhcp-boot=tag:bios-x86,<path of "pxelinux.0" relative to tftp-root>

dhcp-authoritative

# TFTPサーバの設定

enable-tftp

tftp-root=/var/lib/tftpboot

conf-dir=/etc/dnsmasq.d,.rpmnew,.rpmsave,.rpmorig

上記の設定では、TFTPサーバのルートを tftp-server パッケージ（dnsmasq は tftp サーバの機能も提供するので、今回の構成では tftp-server パッケージは用いなていない）の標準である /var/lib/tftpboot に設定している。このディレクトリは自動的には作られないので、dnsmasq を起動する前に
mkdir -p /var/lib/tftpboot
として作成しておく。

• dnsmasq を起動する。同時に、システム起動時に dnsmasq が起動するよう設定する。

systemctl enable --now dnsmasq

• DNSとは、Domain Name Systemのこと。DNS サーバの設定を行うと、サーバにアクセスできる計算機で IP アドレスが必要になった際、ホスト名で代用できるようになる。例えば、ssh でアクセスする際、本来なら ssh <username>@<IP address> と入力しなければならない所を、ssh <username>@<hostname> でアクセスできるようになる。この置き換えは、ssh に限らず NFS などの他のプログラムを用いる際にも有効になるため、ここで DNS サーバを設定しておく。

• プログラムの準備
  DNSサーバの機能は、UEFI PXEブート用サーバの設定の際に用いた dnsmasq に含まれている。そのため、dnsmasq パッケージをインストールしていれば追加のパッケージをインストールする必要はない。

• 設定ファイル：/etc/hosts

デフォルトの設定では、dnsmasq の DNS サーバは /etc/hosts に書かれた情報を読み取って動作する。そこで、/etc/hosts に以下の情報をクラスタ内の計算機全てについて記載する。

<IP address> <hostname>

と設定する。

• 以下のコマンドで　dnsmasqを再起動して設定を反映させる。

systemctl restart dnsmasq

• NTPとは、Network Time Protocol のこと。NTP サーバを設定すると、クラスタ内の計算機間で時刻を同期させることができる。時刻の同期は、クラスタ間で通信を行う際に用いる認証プロトコルやバックアップの作成など rsync でファイルをやり取りする際に必要になる。また、時刻を同期しておくことで、異なる計算機のログを見比べるのが容易になるため、ここで設定しておく。

• プログラムの準備

systemctl status chronyd として、httpdサーバに必要なプログラムがインストールされているか確認する。インストールされていなければ、
dnf install -y @base
でインストールする。

• 設定ファイル：/etc/chrony.conf

ファイル冒頭に server <基準とするNTPサーバのアドレス> を記載する。また、子ノードからのアクセスを許可するため、allow <アクセスを許可するネットワークアドレス> を記載する。

# /etc/chrony.conf
server <IP address of a reference NTP server>

# Use public servers from the pool.ntp.org project.

# Please consider joining the pool (http://www.pool.ntp.org/join.html).

# pool 2.almalinux.pool.ntp.org iburst

# Record the rate at which the system clock gains/losses time.

driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates

# if its offset is larger than 1 second.

makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).

rtcsync

# Enable hardware timestamping on all interfaces that support it.

#hwtimestamp *

# Increase the minimum number of selectable sources required to adjust

# the system clock.

#minsources 2

# Allow NTP client access from local network.

allow <IP address of the clients>

# Serve time even if not synchronized to a time source.

#local stratum 10

# Specify file containing keys for NTP authentication.

keyfile /etc/chrony.keys

# Get TAI-UTC offset and leap seconds from the system tz database.

leapsectz right/UTC

# Specify directory for log files.

logdir /var/log/chrony

# Select which information is logged.

#log measurements statistics tracking

• chronyd を起動する。同時に、システム起動時に chronyd が起動するよう設定する。

systemctl enable --now chronyd

• NTP サーバとクライアントで date コマンドを実行して、時刻が同期されていれば設定完了である。

• プログラムの準備

systemctl status squid として proxy サーバに必要なプログラムがインストールされているか確認する。インストールされていなければ、

dnf install -y squid

でインストールする。

• 設定ファイル：/etc/squid/squid.conf

冒頭部分に、acl localnet src <内部ネットワークのIPアドレス範囲>   を記載する。
プロキシ接続用のポートは http_port で設定されている。

# /etc/squid/squid.conf

#

# Recommended minimum configuration:

#

# Example rule allowing access from your local networks.

# Adapt to list your (internal) IP networks from where browsing

# should be allowed

acl localnet src 0.0.0.1-0.255.255.255  # RFC 1122 "this" network (LAN)

acl localnet src 10.0.0.0/8     # RFC 1918 local private network (LAN)

acl localnet src 100.64.0.0/10      # RFC 6598 shared address space (CGN)

acl localnet src 169.254.0.0/16     # RFC 3927 link-local (directly plugged) machines

acl localnet src 172.16.0.0/12      # RFC 1918 local private network (LAN)

acl localnet src <IP address of the local private network>  # RFC 1918 local private network (LAN)

acl localnet src fc00::/7           # RFC 4193 local private network range

acl localnet src fe80::/10          # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443

acl Safe_ports port 80      # http

acl Safe_ports port 21      # ftp

acl Safe_ports port 443     # https

acl Safe_ports port 70      # gopher

acl Safe_ports port 210     # wais

acl Safe_ports port 1025-65535  # unregistered ports

acl Safe_ports port 280     # http-mgmt

acl Safe_ports port 488     # gss-http

acl Safe_ports port 591     # filemaker

acl Safe_ports port 777     # multiling http

acl CONNECT method CONNECT

#

# Recommended minimum Access Permission configuration:

#

# Deny requests to certain unsafe ports

http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports

http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost

http_access allow localhost manager

http_access deny manager

# We strongly recommend the following be uncommented to protect innocent

# web applications running on the proxy server who think the only

# one who can access services on "localhost" is a local user

#http_access deny to_localhost

#

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

#

# Example rule allowing access from your local networks.

# Adapt localnet in the ACL section to list your (internal) IP networks

# from where browsing should be allowed

http_access allow localnet

http_access allow localhost

# And finally deny all other access to this proxy

http_access deny all

# Squid normally listens to port 3128

http_port <Port that the proxy server listens to>

# Uncomment and adjust the following to add a disk cache directory.

#cache_dir ufs /var/spool/squid 100 16 256

# Leave coredumps in the first cache dir

coredump_dir /var/spool/squid

#

# Add any of your own refresh_pattern entries above these.

#

refresh_pattern ^ftp:       1440    20% 10080

refresh_pattern ^gopher:    1440    0%  1440

refresh_pattern -i (/cgi-bin/|\?) 0 0%  0

refresh_pattern .       0   20% 4320

• squid を起動する。同時に、システム起動時に squidが起動するよう設定する。

systemctl enable --now squid

• NFSとは、Network File System のこと。NFS により、NFS サーバにあるディレクトリをネットワーク内で共有することができる。今回の構成では、/home ディレクトリを共有する。

• プログラムの準備

systemctl status nfs-server として nfs サーバに必要なプログラムがインストールされているか確認する。インストールされていなければ、

dnf install @file-server

でインストールする。

• 設定ファイル：/etc/exports
  共有するディレクトリ（/export/home）を、mkdir -p /export/home として作成する。このディレクトリを NFS 共有するための NFS サーバーの設定は以下の通り。

# /etc/exports (nfs version 4)

/export       192.168.1.0/255.255.255.0(rw,fsid=0,no_root_squash,async)

/export/home  192.168.1.0/255.255.255.0(rw,nohide,no_root_squash,async)

NFS version4 では、オプションに fsid=0 と指定したディレクトリがルートディレクトリとなる。上の例では /export がNFSのルートディレクトリになる。そして、NFSサーバの/export/home にアクセスしたい場合、NFSクライアントからは <NFSサーバのIPアドレス>:/home のようにアクセスする。
もし、/export 配下でないディレクトリを共有したい場合には、/export 以下にマウントポイントを作成した後、そこにNFS共有したいディレクトリをバインドマウントすれば良い。
今回はバインドマウントを用いずに /export/home をNFSで共有する方法を用いる。

• nfs-server を起動する。同時に、システム起動時に nfs-server が起動するよう設定する。

systemctl enable --now nfs-server

• NFSサーバで公開されたディレクトリは、NFSクライアントから mount コマンドや automount でマウントできるようになる。
  今回の構成では、automount を用いて NFSサーバにある /export/home を各計算ノードの /home ディレクトリにマウントして共有する。

公式マニュアル
LDAPとSSSDを用いた認証システムの設定

sudo, automount, sshの公開鍵なども一元管理できる。今回の設定では、以下の情報を管理する。

• posixアカウント

• ssh

• sudo

• automount

     a) LDAPサーバの設定

参考記事：https://qiita.com/y-araki-qiita/items/0c954c3ae25d4ed9dbb8
参考記事：https://www.belbel.or.jp/opensuse-manuals_ja/cha-security-ldap.html#sec-security-ldap-server-sssd

• LDAPとは、Lightweight Directory Access Protocolのこと。

• プログラムの準備

RHEL8 から OpenLDAP による LDAP サーバ構築が非推奨になったので、代わりに 389 Directory Server を用いて LDAP サーバを構築する。

systemctl status sssd として sssd 認証に必要なプログラムがインストールされているか確認する。インストールされていなければ、

dnf module -y enable 389-ds
dnf install -y 389-ds-base

でインストールする。

• 設定ファイルの準備

初期設定用ファイルのテンプレートを作成する。
dscreate create-template /root/ldap/ds01.inf

作成したテンプレートファイルを修正する。修正内容は以下のとおり。
;instance_name = localhost → instance_name = <Instance name>

;suffix → suffix = <Base domain name>
ここで、<Base domain name> は例えば dc=uedagp,o=riken.go.jp のように設定すれば良い。また、<Instance name>は任意の名前を用いて良い。

; /root/ds01.inf

;

; This is a version 2 ds setup inf file.

; It is used by the python versions of setup-ds-*

; Most options map 1 to 1 to the original .inf file.

; However, there are some differences that I envision

; For example, note the split backend section.

; You should be able to create, one, many or no backends in an install

;

; The special value {instance_name} is substituted at installation time.

;

; By default, all configuration parameters in this file are commented out.

; To use an INF file with dscreate, you must at least set the parameters

; flagged with [REQUIRED].

[general]

# defaults (str)

# Description: Directory Server enables administrators to use the default values for cn=config entries from a specific version. If you set this parameter to "999999999", which is the default, the instance always uses the default values of the latest version. For example, to configure that the instance uses default values from version 1.3.5, set this parameter to "001003005". The format of this value is XXXYYYZZZ, where X is the major version, Y the minor version, and Z the patch level. Note that each part of the value uses 3 digits and must be filled with leading zeros if necessary.

# Default value: 999999999

;defaults = 999999999

# full_machine_name (str)

# Description: Sets the fully qualified hostname (FQDN) of this system. When installing this instance with GSSAPI authentication behind a load balancer, set this parameter to the FQDN of the load balancer and, additionally, set "strict_host_checking" to "false".

# Default value: <hostname>

;full_machine_name = <hostname>

# start (bool)

# Description: Starts the instance after the install completes. If false, the instance is created but not started.

# Default value: True

;start = True

# strict_host_checking (bool)

# Description: Sets whether the server verifies the forward and reverse record set in the "full_machine_name" parameter. When installing this instance with GSSAPI authentication behind a load balancer, set this parameter to "false". Container installs imply "false".

# Default value: False

;strict_host_checking = False

[slapd]

# instance_name (str)

# Description: Sets the name of the instance. You can refer to this value in other parameters of this INF file using the "{instance_name}" variable. Note that this name cannot be changed after the installation!

# Default value: localhost

instance_name = <Instance name>

# ldapi (str)

# Description: Sets the location of socket interface of the Directory Server.

# Default value: /run/slapd-{instance_name}.socket

;ldapi = /run/slapd-{instance_name}.socket

# port (int)

# Description: Sets the TCP port the instance uses for LDAP connections.

# Default value: 389

;port = 389

# root_password (str)

# Description: Sets the password of the "cn=Directory Manager" account ("root_dn" parameter).You can either set this parameter to a plain text password dscreate hashes during the installation or to a "{algorithm}hash" string generated by the pwdhash utility. The password must be at least 8 characters long.  Note that setting a plain text password can be a security risk if unprivileged users can read this INF file!

# Default value: Directory_Manager_Password

root_password = <Root password for LDAP administrator>

# secure_port (int)

# Description: Sets the TCP port the instance uses for TLS-secured LDAP connections (LDAPS).

# Default value: 636

;secure_port = 636

# self_sign_cert (bool)

# Description: Sets whether the setup creates a self-signed certificate and enables TLS encryption during the installation. The certificate is not suitable for production, but it enables administrators to use TLS right after the installation. You can replace the self-signed certificate with a certificate issued by a Certificate Authority. If set to False, you can enable TLS later by importing a CA/Certificate and enabling 'dsconf <instance_name> config replace nsslapd-security=on'

# Default value: True

;self_sign_cert = True

# self_sign_cert_valid_months (int)

# Description: Set the number of months the issued self-signed certificate will be valid.

# Default value: 24

;self_sign_cert_valid_months = 24

[backend-userroot]

# create_suffix_entry (bool)

# Description: Set this parameter to "True" to create a generic root node entry for the suffix in the database.

# Default value: False

;create_suffix_entry = False

# require_index (bool)

# Description: Set this parameter to "True" to refuse unindexed searches in this database.

# Default value: False

;require_index = False

# sample_entries (str)

# Description: Set this parameter to 'yes' to add latest version of sample entries to this database.  Or, use '001003006' to use the 1.3.6 version sample entries.  Use this option, for example, to create a database for testing purposes.

# Default value: no

;sample_entries = no

# suffix (str)

# Description: Sets the root suffix stored in this database.  If you do not uncomment and set the suffix attribute the install process will NOT create the backend/suffix.  You can also create multiple backends/suffixes by duplicating this section.

# Default value:

suffix = <Base domain name>

• LDAP サーバのインスタンスの作成

作成した初期設定用ファイルから、LDAP サーバのインスタンスを作成する。作成と同時に LDAP サーバが起動する。

chmod 600 /root/ldap/ds01.inf
dscreate from-file /root/ldap/ds01.inf

LDAP サーバのインスタンスが正常起動したことを確認する。

systemctl status dirsrv@<Instance name>

LDAP サーバへ接続できることを確認する。

LDAPサーバと同一のホストから：

ldapsearch -x -W -D "cn=Directory Manager" -b cn=config

LDAPサーバとは別のホストから：

ldapsearch -H ldap://<IP address of the server> -x -W -D "cn=Directory Manager" -b cn=config

• LDAP サーバのインスタンスの初期化およびプラグインの有効化

LDAPサーバに種々の情報を登録する前に、インスタンスの初期化を行う必要がある。コマンドは以下の通り

dsidm -b "<Base domain name>" <Instance name> initialise

389 Directory Server には、情報の管理を助けるプラグインが用意されている。以下ではその内のいくつかを有効化する。

dsconf -D "cn=Directory Manager" ldap://localhost plugin memberof enable

dsconf -b "<Base domain name>" <Instance name> plugin memberof set --scope <Base domain name>

dsconf -D "cn=Directory Manager" <Instance name> plugin attr-uniq add "uidNumber uniqueness" --attr-name uidNumber --subtree <Base domain name>

dsconf <Instance name> plugin attr-uniq enable "uidNumber uniqueness"

既存エントリにmemberOfプラグインを適用するには、以下のコマンドを実行する。

dsconf -b "<Base domain name>" <Instance name> plugin memberof fixup -f '(objectClass=*)' ou=people,<Base domain name>

systemctl restart dirsrv@<Instance name>; systemctl status dirsrv@<Instance name>

• 情報の登録

• グループの作成

以下のコマンドを打ち込んだ後、指示に従って情報を入力する。
dsidm -b "<Base domain name>" <Instance name> posixgroup create  

• ユーザーの作成

以下のコマンドを打ち込んだ後、指示に従って情報を入力する。
dsidm -b "<Base domain name>" <Instance name> user create 

ユーザーパスワードは、以下のコマンドからリセットできる。コマンドを打ち込んだ後、指示に従ってパスワードをリセットするユーザの情報を入力すれば良い。
dsidm -b "<Base domain name>" <Instance name> account reset_password 

• /etc/shadow からのパスワード移行

ローカルマシンにあるアカウントを LDAP に移行するには、同名のユーザを LDAP で作成した後、以下のコマンドでローカルマシンに登録されているものと同じパスワードを設定すれば良い。
dsidm -b "<Base domain name>" <Instance name> user modify <uid> add:userPassword:'{CRYPT}<Hash of the password>'
ここで、<uid> は LDAP サーバに登録されているものを用いる。これは ldapsearch -H ldap://localhost -b "ou=people,<Base domain name>" -x  として確認できる。また、<Hash of the password> は /etc/shadow に記載されているものをコピーして貼り付ければ良い。

• エントリの確認および変更

dsidmで管理できるエントリの情報確認は、以下のようにしてできる。
dsidm -b "<Base domain name>" <Instance name> user get  

情報の変更は、以下のようにしてできる。

dsidm -b "<Base domain name>" <Instance name> user modify <uid> replace:gidNumber:100

dsidm -b "<Base domain name>" <Instance name> user modify <uid> add:objectclass:nsmemberof

• sudoの設定

• automountの設定

5) SSSDの設定

• SSSDとは、System Security Services Daemonのこと。これを用いることで、LDAP で管理されているユーザー情報を用いて ssh ログインや sudo 権限の管理、automount 設定の読み込みができるようになる。

• プログラムの準備

systemctl status sssd として sssd 認証に必要なプログラムがインストールされているか確認する。インストールされていなければ、

dnf install -y @base

でインストールする。

• 設定ファイル：/etc/sssd/sssd.conf

389 Directory Server を用いた LDAP サーバで、以下のコマンドを実行して得られる /etc/sssd/sssd.conf を編集する。

dsidm -b "<Base domain name>" <Instance name> client_config sssd.conf > /etc/sssd/sssd.conf

この設定ファイルで、設定が必要な項目は以下の通り：

• ldap_uri を設定する。

• ldap_tls_reqcert = never とするかTLS認証の設定を行う。以下では ldap_tls_reqcert = never とする。

• ldap_access_filter を設定する。ldapsearch -b "<Base domain name>" -x "<filter>" として、ログインを許可したいユーザが表示されれば良い。

• enumerate = True とする。

• 2つ目の access_provider をコメントアウトする。

• [sssd] services に autofs を追加する。

# /etc/sssd/sssd.conf

#

# sssd.conf

# Generated by 389 Directory Server - dsidm

#

# For more details see man sssd.conf and man sssd-ldap

# Be sure to review the content of this file to ensure it is secure and correct

# in your environment.

[domain/ldap]

# Uncomment this for more verbose logging.

# debug_level=3

# Cache hashes of user authentication for offline auth.

cache_credentials = True

id_provider = ldap

auth_provider = ldap

access_provider = ldap

chpass_provider = ldap

ldap_schema = rfc2307bis

ldap_search_base = <Base domain name>

ldap_uri = ldap://<IP address of the LDAP server>

# If you have DNS SRV records, you can use the following instead. This derives

# from your ldap_search_base.

# ldap_uri = _srv_

ldap_tls_reqcert = <set one of "never", "allow", "try", or "demand">

# To use cacert dir, place *.crt files in this path then run:

# /usr/bin/openssl rehash /etc/openldap/certs

# or (for older versions of openssl)

# /usr/bin/c_rehash /etc/openldap/certs

ldap_tls_cacertdir = /etc/openldap/certs

# Path to the cacert

# ldap_tls_cacert = /etc/openldap/certs/ca.crt

# Only users who match this filter can login and authorise to this machine. Note

# that users who do NOT match, will still have their uid/gid resolve, but they

# can't login.

ldap_access_filter = (&(objectClass=posixAccount)(objectClass=nsPerson))

enumerate = True 

# access_provider = ldap

ldap_user_member_of = memberof

ldap_user_gecos = cn

ldap_user_uuid = nsUniqueId

ldap_group_uuid = nsUniqueId

# This is really important as it allows SSSD to respect nsAccountLock

ldap_account_expire_policy = rhds

ldap_access_order = filter, expire

# Setup for ssh keys

# Inside /etc/ssh/sshd_config add the lines:

#   AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys

#   AuthorizedKeysCommandUser nobody

# You can test with the command: sss_ssh_authorizedkeys <username>

ldap_user_ssh_public_key = nsSshPublicKey

# This prevents an issue where the Directory is recursively walked on group

# and user look ups. It makes the client faster and more responsive in almost

# every scenario.

ignore_group_members = False

[sssd]

debug_level = 7

services = nss, pam, ssh, sudo, autofs

config_file_version = 2

domains = ldap

[nss]

homedir_substring = /home

• 以下のように権限を適切に設定して sssd を起動する。権限の設定が間違っていると sssd が起動しないので注意。

chown root:root /etc/sssd/sssd.conf

chmod 600 /etc/sssd/sssd.conf

systemctl enable --now sssd

• 設定ファイルの置き場所

EFIブートの設定ファイルは、EFI ブートローダ（BOOTX64.EFI）と同じディレクトリに置く。EFI ブートローダの置き場所は「3) インストールソースおよびブートローダの用意」で説明する。クライアント毎に異なる設定ファイルを用いる場合は、設定ファイル名を grub.cfg-<MAC address of the client> とする。

• 設定ファイルの内容

以下に AlmaLinux 8.9を自動インストールした際の設定ファイルを記載する。
<Config file of kickstart>を次節で説明するキックスタート設定ファイルのパスに置き換える。

# grub.cfg-<MAC address of the client> 

set default="Install AlmaLinux 8.9 Automatically"

function load_video {

  insmod efi_gop

  insmod efi_uga

  insmod video_bochs

  insmod video_cirrus

  insmod all_video

}

load_video

set gfxpayload=keep

insmod gzio

insmod part_gpt

insmod ext2

set timeout=5

set timeout_style=countdown

### END /etc/grub.d/00_header ###

# search --no-floppy --set=root -l 'AlmaLinux-8-9-x86_64-dvd'

### BEGIN /etc/grub.d/10_linux ###

menuentry 'Boot local drive' {

exit

}

menuentry 'Install AlmaLinux 8.9 Automatically' --class fedora --class gnu-linux --class gnu --class os {

linuxefi /images/AlmaLinux8.9/vmlinuz inst.ks=http://<IP address of the HTTP server>/httpboot/ks/<Config file of kickstart> inst.selinux=0 quiet

initrdefi /images/AlmaLinux8.9/initrd.img

}

menuentry 'Install AlmaLinux 8.9 Manually' --class fedora --class gnu-linux --class gnu --class os {

linuxefi /images/AlmaLinux8.9/vmlinuz inst.repo=http://<IP address of the HTTP server>/httpboot/AlmaLinux8.9/ inst.selinux=0 quiet

initrdefi /images/AlmaLinux8.9/initrd.img

}

menuentry 'Test this media & install AlmaLinux 8.9' --class fedora --class gnu-linux --class gnu --class os {

linuxefi /images/AlmaLinux8.9/vmlinuz inst.repo=http://<IP address of the HTTP server>/httpboot/AlmaLinux8.9/ inst.selinux=0 rd.live.check quiet

initrdefi /images/AlmaLinux8.9/initrd.img

}

submenu 'Troubleshooting -->' {

menuentry 'Install AlmaLinux 8.9 in basic graphics mode' --class fedora --class gnu-linux --class gnu --class os {

linuxefi /images/AlmaLinux8.9/vmlinuz ip=dhcp inst.repo=http://<IP address of the HTTP server>/httpboot/AlmaLinux8.9/ nomodeset quiet

initrdefi /images/AlmaLinux8.9/initrd.img

}

menuentry 'Rescue a AlmaLinux system' --class fedora --class gnu-linux --class gnu --class os {

linuxefi /images/pxeboot/vmlinuz ip=dhcp inst.repo=http://<IP address of the HTTP server>/httpboot/AlmaLinux8.9/ inst.rescue quiet

initrdefi /images/AlmaLinux8.9/initrd.img

}

}

• ここで、"inst.ks=..." には、次節で説明するキックスタートファイルのパスを記載する。自動インストール時にはここで設定したキックスタートファイルが読み込まれ、その内容にしたがってインストールが行われる。

  • • linuxefi および initrdefi に記載するパスは、TFTPサーバのルートからの相対パスで読み込まれる。今回の設定では、TFTPサーバのルートは /var/lib/tftpboot である。したがって、上記設定ファイルに記載されている /images/AlmaLinux8.9/vmlinuz および /images/AlmaLinux8.9/initrd.img は、TFTPサーバにおいてはそれぞれ
      /var/lib/tftpboot/images/AlmaLinux8.9/vmlinuz
      /var/lib/tftpboot/images/AlmaLinux8.9/initrd.img
      に置かれている。

• PXEブート時には、ブート設定ファイルの set default に指定した menuentry のコマンドが実行される。上の例では、set default="Install AlmaLinux 8.9 Automatically" となっているため、PXEブート時に、menuentry 'Install AlmaLinux 8.9 Automatically' に記載されているコマンドに従って OS の自動インストールが始まる。
  次節で説明するキックスタート設定ファイルにおいて、自動インストール完了後に
  set default="Install AlmaLinux 8.9 Automatically" → set default="Boot local drive"
  と書き換えるコマンドを記載することで、OS インストール後に再起動した場合に再び OS インストールが始まるのを防ぎ、計算機のローカルディスクにインストールされた OS から起動されるようにする。

OSの自動インストール時には、キックスタートファイルに記載した内容に沿ってインストールが行われる。
キックスタートファイルの置き場所は、ブート設定ファイルの inst.ks=... に記載した場所にする。今回の構成では <HTTPルート>/httpboot/ks/ ディレクトリ以下に配置する。

キックスタートファイルを作成する最も簡単な方法は、いずれかの計算機を用いて一度 OS を手動インストールすることである。OS をインストールすると /root/anaconda-ks.cfg にインストール時の設定を反映したキックスタートファイルが自動生成されている。これを基に変更を加えることで、他の計算機への OS インストールに用いるキックスタートファイルを比較的簡単に用意することができる。

以下にキックスタートファイルに記載すべき内容を挙げる。

• • 自動 OS インストール後の処理の記載

OS インストール後に実行されるコマンドは、キックスタートファイル内において

%post --logfile=/root/setup.log
<実行するコマンド群>
%end

と記載する。

1. デフォルトブートオプションの変更

自動 OS インストール後の再起動時に再び自動 OS インストールが始まらないようにするためには、自動 OS インスールの最終ステップにおいて、

set default="Install AlmaLinux 8.9 Automatically"  →  set default="Boot local drive"
と書き換える必要がある。これは以下のステップで行う。

1. tftpコマンドを用いて、TFTPサーバからブート設定ファイルをダウンロードする。

2. sedコマンドを用いて、ダウンロードしたブート設定ファイルを書き換える。

3. tftpコマンドを用いて、変更したブート設定ファイルをTFTPサーバにアップロードする。

キックスタートファイル内で実際にこれを記載した箇所は以下の通り。

# Change defaults of the bootloader menu to prevent the system from repeating the installation after reboot.

echo "Downloading tftp://<TFTPサーバのIPアドレス>/AlmaLinux8.9/EFI/BOOT/<ブート設定ファイル>"

tftp -v <TFTPサーバのIPアドレス> -c get /AlmaLinux8.9/EFI/BOOT/<ブート設定ファイル> /root/<ブート設定ファイル>

sed -i -e 's/^set default="Install AlmaLinux 8.9 Automatically"/set default="Boot local drive"/g' /root/<ブート設定ファイル>

echo "Uploading /root/<ブート設定ファイル> to tftp://<TFTPサーバのIPアドレス>/AlmaLinux8.9/EFI/BOOT/<ブート設定ファイル>"

tftp -v <TFTPサーバのIPアドレス> -c put /root/<ブート設定ファイル> /AlmaLinux8.9/EFI/BOOT/<ブート設定ファイル>

echo

• • ネットワーク設定の記載

OSインストール後に計算ノードにネットワークからアクセスできるようにするため、以下のようにキックスタートファイル内にネットワーク設定を記載しておく。

# Network information

network --bootproto=static --device=<MACwithCOLON> --ip=<IPADDRESS> --netmask=255.255.255.0 --gateway=<IP address of gateway server> --nameserver=<IP address of DNS server> --hostname=<HOSTNAME> --activate

ここで、<MACwithCOLON> はネットワーク接続に用いるインターフェースの MACアドレスをコロン区切りで記載したものにする。<HOSTNAME>は計算ノードのホスト名として使用したいものを設定する。

• OSインストールソースの記載

計算機がインターネットに接続されていない場合、OS公式ページなどに用意されているOSインストールに必要なリポジトリにアクセスすることができない。そこで、これらの必要なリポジトリを HTTP サーバなどに用意しておき、インストールソースとしてその場所を指定する必要がある。

例えば、ISOイメージを <HTTPルート>/httpboot/AlmaLinux8.9 以下に展開した場合、キックスタートファイル内に以下のようにインストールソースを記載する必要がある。

url --url="http://<HTTPサーバのIPアドレス>/httpboot/AlmaLinux8.9/" --noverifyssl

repo --name="BaseOS"    --baseurl=http://<HTTPサーバのIPアドレス>/httpboot/AlmaLinux8.9/BaseOS
repo --name="AppStream" --baseurl=http://<HTTPサーバのIPアドレス>/httpboot/AlmaLinux8.9/AppStream

• SSSD認証の設定

今回の構成では、ユーザ認証に LDAP + SSSD を用いる。この認証方法を用いるためには、authselect コマンドで設定を行う必要があるが、これをキックスタート時に行うため以下の内容を記載する。

# System authorization information

authselect select sssd with-sudo with-mkhomedir --force

ここで "with-sudo with-mkhomedir" を指定することにより、LDAPによる sudoer の管理および LDAP に登録されたユーザのホームディレクトリの作成が行えるようになる。

SSSD認証を用いるためには、さらに SSSD の設定ファイル /etc/sssd/sssd.conf を適切に用意する必要があるが、これに関しては OS インストール後に行う。

• NTPサーバの設定

計算機が参照する NTP サーバの設定は、以下のコマンドで行う。

# System timezone

timezone Asia/Tokyo --isUtc --ntpservers=<IP address of NTP server>

• rootパスワードの設定

rootユーザのパスワードをキックスタート時に行うには、キックスタートファイルに以下を記載する。

# Root password

rootpw --iscrypted <Hash of root password>

ここで、<Hash of root password> は /etc/shadow に記載されているものを用いる。

• • 実際に AlmaLinux 8.9 をインストールした際のキックスタートファイルは以下の通り。
    以下で、"<ブート設定ファイル>" は OS をインストールする計算機に読み込ませるブート設定ファイルのパスに置き換える。

# /var/www/html/httpboot/ks/<Config file of kickstart>

#version=RHEL8

# License agreement

eula --agreed

# Reboot after instllation

reboot

# Use text mode install

text

%post --logfile=/root/setup.log

set -x

date

echo

# Change defaults of the bootloader menu to prevent the system from repeating the installation after reboot.

echo "Downloading tftp://<TFTPサーバのIPアドレス>/AlmaLinux8.9/EFI/BOOT/<ブート設定ファイル>"

tftp -v <TFTPサーバのIPアドレス> -c get /AlmaLinux8.9/EFI/BOOT/<ブート設定ファイル> /root/<ブート設定ファイル>

sed -i -e 's/^set default="Install AlmaLinux 8.9 Automatically"/set default="Boot local drive"/g' /root/<ブート設定ファイル>

echo "Uploading /root/<TFTPサーバのIPアドレス> to tftp://<TFTPサーバのIPアドレス>/AlmaLinux8.9/EFI/BOOT/<ブート設定ファイル>"

tftp -v <TFTPサーバのIPアドレス> -c put /root/<ブート設定ファイル> /AlmaLinux8.9/EFI/BOOT/<ブート設定ファイル>

echo

%end

%packages

@^graphical-server-environment

@container-management

@debugging

@development

@graphical-admin-tools

@infiniband

@network-file-system-client

@performance

@rpm-development-tools

@scientific

@system-tools

kexec-tools

tftp

%end

# Keyboard layouts

keyboard --xlayouts='us'

# System language

lang en_US.UTF-8

# Firewall configuration

firewall --disabled

# Network information

network --bootproto=static --device=<MACwithCOLON> --ip=<IPADDRESS> --netmask=255.255.255.0 --gateway=<IP address of gateway server> --nameserver=<IP address of DNS server> --hostname=<HOSTNAME> --activate

# Use network instllation

url --url="http://<HTTPサーバのIPアドレス>/httpboot/AlmaLinux8.9/" --noverifyssl

repo --name="BaseOS"    --baseurl=http://<HTTPサーバのIPアドレス>/httpboot/AlmaLinux8.9/BaseOS
repo --name="AppStream" --baseurl=http://<HTTPサーバのIPアドレス>/httpboot/AlmaLinux8.9/AppStream

# System authorization information

authselect select sssd with-sudo with-mkhomedir --force

# Run the Setup Agent on first boot

firstboot --disable

# SELinux configuration

selinux --permissive

# Do not configure the X Window System

skipx

# System bootloader configuration

bootloader --append="biosdevname=0 crashkernel=auto" --location=mbr --timeout=15 --leavebootorder

# Clear the Master Boot Record

zerombr

# Partition clearing information

autopart --type=lvm

clearpart --all --initlabel

# System timezone

timezone Asia/Tokyo --isUtc --ntpservers=<IP address of NTP server>

# Root password

rootpw --iscrypted <Hash of root password>

%addon com_redhat_kdump --enable --reserve-mb='auto'

%end

%anaconda

pwpolicy root --minlen=6 --minquality=1 --notstrict --nochanges --notempty

pwpolicy user --minlen=6 --minquality=1 --notstrict --nochanges --emptyok

pwpolicy luks --minlen=6 --minquality=1 --notstrict --nochanges --notempty

%end

前節でも述べたように、OSを自動インストールしたい計算機がインターネットに接続されていない場合、OS公式ページなどに用意されているOSインストールに必要なリ1ポジトリにアクセスすることができない。そこで、これらの必要なリポジトリをローカルネットワーク内の HTTP サーバなどに用意しておく。

これは RHELの公式ページ に基づいて以下のようにできる。

1. OSの公式ページなどから iso イメージをダウンロードする。

2. isoイメージをファイルシステムにマウントし、isoイメージの内容を /var/www/html/httpboot 以下にコピーする。

mkdir /mnt/AlmaLinux8.9/
mount -o loop,ro -t iso9660 <path of ISO image> /mnt/AlmaLinux8.9/
cp -r /mnt/AlmaLinux8.9/ /var/www/html/httpboot/AlmaLinux8.9/

3. .treeinfoファイルまで含めて全てコピーされたことを確認する。

ls -a /var/www/html/httpboot/AlmaLinux8.9/

また、今回用いるネットワークを介したOSの自動インストールでは、計算機の起動に必要なブートローダを DHCP サーバの指定するパスに配置しておく必要がある。今回の構成では、dnsmasq の提供するDHCP サーバ機能を用いており、ブートローダは dnsmasq の提供する TFTP サーバから読み込まれるため、TFTPサーバのルートディレクトリ（今回の設定では /var/lib/tftpboot）以下にブートローダを配置する。ブートローダは isoイメージに含まれているため、それを以下のようにして TFTP サーバにコピーする。

mkdir -p /var/lib/tftpboot/AlmaLinux8.9

cp -r /var/www/html/httpboot/AlmaLinux8.9/EFI    /var/lib/tftpboot/AlmaLinux8.9/

cp -r /var/www/html/httpboot/AlmaLinux8.9/images /var/lib/tftpboot

キックスタートファイルを含めた HTTP サーバのファイル構成は以下の通り。

/var/www/html/

└── httpboot

    ├── ks

    │   ├── <Config file of kickstart of node 1>

    │   ├── <Config file of kickstart of node 2>

    │   :

    │   └── <Config file of kickstart of node n>

    └── AlmaLinux8.9

        ├── .treeinfo

        ├── .discinfo

        ├── AppStream

        ├── BaseOS

        ├── EFI

        ├── EULA

        ├── extra_files.json

        ├── GPL

        ├── images

        ├── isolinux

        ├── media.repo

        ├── RPM-GPG-KEY-AlmaLinux

        └── TRANS.TBL

ブートローダ設定ファイルを含めた TFTP サーバのファイル構成は以下の通り。

/var/lib/tftpboot

├── AlmaLinux8.9

│   └── EFI

│       └── BOOT

│           ├── BOOT.conf

│           ├── BOOTIA32.EFI

│           ├── BOOTX64.EFI

│           ├── grubia32.efi

│           ├── grubx64.efi

│           ├── mmia32.efi

│           ├── mmx64.efi

│           ├── TRANS.TBL

│           ├── fonts

│           ├── grub.cfg

│           ├── grub.cfg-<MAC addres of node 1>

│           ├── grub.cfg-<MAC addres of node 2>

│           :

│           └── grub.cfg-<MAC addres of node n>

└── images

    └── AlmaLinux8.9

        ├── initrd.img

        └── vmlinuz

準備中

準備中

• • 公式ページ にしたがって、パッケージマネージャ（dnf ）を用いて NVIDIA driver と CUDA toolkit をインストールする。

  • 実際に用いたコマンドは以下の通り。

# /root/software/Install_oneAPI.sh

#!/bin/bash

# Install Intel OneAPI

# Reference: https://www.intel.com/content/www/us/en/docs/oneapi/installation-guide-linux/2024-1/yum-dnf-zypper.htm

tee > /tmp/oneAPI.repo << EOF

[oneAPI]

name=Intel® oneAPI repository

baseurl=https://yum.repos.intel.com/oneapi

enabled=1

gpgcheck=1

repo_gpgcheck=1

gpgkey=https://yum.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB

EOF

mv /tmp/oneAPI.repo /etc/yum.repos.d

dnf install -y intel-basekit intel-hpckit

• • 子ノードに Intel oneAPI toolkit をインストールするには、
    echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} rsync -avh -e 'ssh' /root/software {}:/root
    として上記のスクリプトを配布した後、
    echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} zsh -c "ssh {} /root/software/Install_oneAPI.sh 2>&1 > {}.oneAPIinstall.log"
    として子ノード上でスクリプトを実行する。

  • 環境変数を設定するため、/etc/profile.d 以下に次のファイルを置く。

# /etc/profile.d/oneAPI.sh

source /opt/intel/oneapi/setvars.sh

このファイルを、子ノードの同じ場所にも配布する。

• • 公式ページ にしたがって、パッケージマネージャ（dnf ）を用いて NVIDIA driver と CUDA toolkit をインストールする。

  • 実際に用いたコマンドは以下の通り。

# /root/software/Install_CUDA.sh

#!/bin/bash

# Install NVIDIA CUDA toolkit & drivers

distro=rhel8

arch=x86_64

dnf install -y kernel-devel-$(uname -r) kernel-headers-$(uname -r)

dnf install -y epel-release

rpm --erase gpg-pubkey-7fa2af80* 2>/dev/null

dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/$distro/$arch/cuda-$distro.repo

dnf clean expire-cache

dnf module install -y nvidia-driver:latest-dkms

dnf install -y cuda-toolkit

dnf install -y nvidia-gds

• • 子ノードに CUDA toolkit をインストールするには、
    echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} rsync -avh -e 'ssh' /root/software {}:/root
    として上記のスクリプトを配布した後、
    echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} zsh -c "ssh {} /root/software/Install_CUDA.sh 2>&1 > {}.CUDAinstall.log"
    として子ノード上でスクリプトを実行する。

  • スクリプトを実行後、各ノードを再起動してドライバの更新を反映させる。

  • 環境変数を設定するため、/etc/profile.d 以下に次のファイルを置く。

# /etc/profile.d/CUDA.sh

export CUDADIR=/usr/local/cuda

export PATH=${CUDADIR}/bin${PATH:+:${PATH}}

export LD_LIBRARY_PATH=${CUDADIR}/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

このファイルを、子ノードの同じ場所にも配布する。

公式ページを参考に設定する。

• 要件

  • LDAP + SSSD 認証の設定が済んでいること

  • NTPサーバの設定が済んでいること

  • 管理ノード上に /etc/munge/munge.key が存在すること

1.  Slurmのインストール

パッケージマネージャ（dnf ）を用いて Slurm をインストールする。実際に用いたコマンドは以下の通り。

# /root/software/Install_Slurm.sh
#!/bin/bash

# Install Slurm

# Reference: https://www.intel.com/content/www/us/en/docs/oneapi/installation-guide-linux/2024-1/yum-dnf-zypper.htm

dnf config-manager --set-enabled powertools

dnf install -y slurm slurm-slurmd

# 管理ノードでは以下も実行する

# dnf install -y slurm-slurmctld slurm-slurmdbd

子ノードに Slurm をインストールするには、

echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} rsync -avh -e 'ssh' /root/software {}:/root

として上記のスクリプトを配布した後、

echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} zsh -c "ssh {} /root/software/Install_Slurm.sh 2>&1 > {}.SlurmInstall.log"
として子ノード上でスクリプトを実行する。

2. slurm 用ユーザの作成

今回はユーザの管理に LDAP+SSSDを用いているので、LDAPサーバに slurm デーモン実行用のユーザを作成する。そのために、slurm ユーザとグループを記載した以下の ldif ファイルを作成しLDAPサーバに読み込ませる。

# slurm_posixAccount.ldif

# Slurm group

dn: cn=slurm,ou=groups,<Base domain name>

objectClass: top

objectClass: groupOfNames

objectClass: posixGroup

objectClass: nsMemberOf

cn: slurm

gidNumber: 64030

# Slurm account

dn: uid=slurm,ou=services,<Base domain name>

objectClass: top

objectClass: nsAccount

objectClass: posixAccount

uid: slurm

cn: slurm

uidNumber: 64030

gidNumber: 64030

homeDirectory: /etc/slurm

loginShell: /bin/nologin

LDAPサーバで以下のコマンドを実行し、情報を登録する。

ldapadd -x -D "cn=Directory Manager" -W -f slurm_posixAccount.ldif

389 Directory Server のデフォルトの設定では、ou=services に作成した posixAccount は匿名ユーザから検索できない設定になっている。そこで以下のように aci を設定する。

# services_aci.ldif

dn: ou=services,<Base domain name>

changetype: modify

add: aci

aci: (targetattr="objectClass || description || nsUniqueId || uid || loginShell || uidNumber || gidNumber || homeDirectory || cn || memberOf || nsAccountLock || userCertificate")(targetfilter="(objectClass=posixaccount)")(version 3.0; acl "Enable anyone service account read"; allow (read, search, compare)(userdn="ldap:///anyone");)

ファイルを作成したら以下のコマンドで変更を適用する。

ldapmodify -x -D "cn=Directory Manager" -W -f services_aci.ldif

以下のコマンドで、上で作成した slurmユーザとslurmグループが見えれば良い。

ldapsearch -H ldap://localhost -b "<Base domain name>" -x "(gidNumber=64030)"

上記の検索が正常に行えておりSSSDの設定も正しくできているなら、id slurm で作成したslurmユーザの情報が得られるはずである。

3. munge認証の設定

slurm はホスト間通信の暗号化に munge というプログラムを用いている。dnf でslurmをインストールした際に munge はインストールされているはずであるので、getent passwd | grep munge で munge  用のユーザとグループが作成されていることを確認する。作成されていなければ、dnf install -y munge で munge をインストールする。
munge を用いるには、ホスト間接続の暗号化に用いる munge.key を全てのノードで共有する必要がある。そのため、まず管理ノードで以下のコマンドを実行しmunge.keyを作成する。

/usr/sbin/create-munge-key

作成した鍵は /etc/munge/munge.key にあるはずである。この鍵の所有者が munge:munge であることと、権限が400であることを確認した後、これを全ての子ノードに配布する。

echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} rsync -avh -e 'ssh' /etc/munge/ {}:/etc/munge/

コピーした鍵の所有者が munge:munge であり権限が400であること、/etc/mungeの所有者が munge:munge で権限が700であることを確認しておく。

鍵を配布したら、各ノード上でmunge.service を起動する。また、計算機起動時に munge.service が自動で立ち上がるように設定する。

systemctl enable --now munge.service
echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} ssh {} systemctl enable --now munge.service

4. 時刻の同期

mungeの動作には通信するノード間で時刻を同期させる必要がある。dateコマンドなどで時刻が同期されているか確認する。されていない場合、NTCサーバやNTCクライアントの設定を確認して、時刻が同期するようにする。

5. slurm 設定ファイルの作成

slurm設定ファイル作成ツールを用いつつ管理ノードの /etc/slurm.conf に各計算ノードの情報を記入する。設定内容は、各ノード上で

/usr/sbin/slurmd -C

を実行して得られる内容を記載する。

slurmをroot以外のユーザで実行する場合は、ログファイルのパスなどを適切に変更する必要がある。例えば、デフォルトでSlurmctldやSlurmdのログが置かれるディレクトリ /var/log や /var/spool/slurm には、管理者権限がないと書き込めないので、

mkdir -p /var/log/slurm; chown slurm:slurm /var/log/slurm
chown slurm:slurm /var/spool/slurm

とした上で、slurm.conf の該当箇所を以下のように変更する。

SlurmctldLogFile=/var/log/slurm/slurmctld.log

SlurmdLogFile=/var/log/slurm/slurmd.log

また、slurm設定ファイル作成ツール のTask Launchで Cgroup を選択した場合、/etc/cgroup.conf の中にある ConstrainCores および ConstrainRAMSpace をyesに設定する必要がある。
加えて、slurm設定ファイル作成ツール では設定されない SelectTypeParameters の設定も必須である。セットできる値は公式ドキュメントを参照。

6. slurmctld の起動

設定ファイルを更新したら、管理ノード上で slurmctld を再起動する。

systemctl restart slurmctld

slurmctld が起動していなければ、

systemctl enable --now slurmctld

とする。

7. slurm 設定ファイルの配布および slurmd の起動

各計算ノードに slurmd の設定ファイルを配置する。また、/var/log/slurm の所有者を slurm: slurm に変更する。これには、管理ノード上で

echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} rsync -avh -e 'ssh' /etc/slurm/ {}:/etc/slurm

echo <子ノードのIPアドレスのリスト> | xargs -L 1 -P0 -I{} ssh {} chown slurm:slurm /var/log/slurm

とすれば良い。

slurmd 設定ファイルの配置が終わったら、各計算ノード上で 

systemctl enable --now slurmd

を実行し、slurmd を起動する。slurmd が正しく起動してノード間通信が正常に行われていれば、slurm 管理ノードで sinfo コマンドを実行した時計算ノードの状態が表示されるはずである。

root権限がない場合、Podman は NFS などのローカルマシンにないファイルシステムにアクセスできない。したがって、NFSクライアント等から podman を用いると、

% podman pull docker.io/hello-world:latest

Error: a network file system with user namespaces is not supported.  Please use a mount_program: backing file system is unsupported for this graph driver

のようなエラーが出る。これは、rootless podman ではストレージパスのデフォルトが "$HOME/.local/share/containers/storage" に設定されているため、/home を NFS 共有していると rootless podman からアクセスできないためである。そこで各計算ノードにおいて、/etc/containers/storage.conf の rootless_storage_path を修正してローカルマシンのファイルシステム上の場所を指すようにする。

# /etc/constainers/storage.conf

...
rootless_storage_path="/opt/podman/$USER/containers/storage"

...

rootless_storage_path で指定したルートディレクトリ（上の例では /opt/podman）を作成し、一般ユーザが自身のディレクトリ（上の例では /opt/podman/$USER）を作成できるよう、権限を777に設定する。

mkdir -p /opt/podman

chmod 777 /opt/podman

上記の変更で、非管理者ユーザからも

podman pull docker.io/hello-world:latest

podman run docker.io/hello-world:latest

ができるようになるはずである。しかし、Dockerfile を用いてイメージをビルドしようとすると、

% podman build .

...

Error: creating build container: writing blob: adding layer with blob "sha256:6e3729cf69e0ce2de9e779575a1fec8b7fb5efdfa822829290ab6d5d1bc3e797": processing tar file(potentially insufficient UIDs or GIDs available in user namespace (requested 0:42 for /etc/gshadow): Check /etc/subuid and /etc/subgid if configured locally and run "podman system migrate": lchown /etc/gshadow: invalid argument): exit status 1

のようなエラーが出る。これは、今回設定したユーザ認証方法（LDAP + SSSD）では /etc/subuid や /etc/subgid が共有されないことによる。

そこで、/etc/subuid や /etc/subgid ファイルを手動で用意する。

for n in $(seq 1 99); do echo $((1000 + n)):$((n * 100000)):65536 > /etc/subuid

cat /etc/subuid > /etc/subgid

として uid が 1001 から 1099 の範囲のユーザに subid を割り当てる。

準備中

インストール
https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html#installing-with-yum-or-dnf

設定
https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/cdi-support.html