web-dev-qa-db-ja.com

ユーザーモードでsystemdを使用してKinit

ユーザーのホームディレクトリ$HOME/client.keytabの下にkeytabファイルを作成しました。認証キャッシュファイルは、デフォルトの場所/tmp/krb5cc_%U（％UはUID）にあります。これで、サービスを起動して認証キーを取得するためのこの単純なsystemdunitファイルができました。

[Unit]
Description=Initializes, caches and renews Kerberos tickets for user
After=default.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/usr/bin/kdestroy -q -c /tmp/krb5cc_%U
ExecStart=/usr/bin/kinit -V -l 30d -r 365d -k -t %h/client.keytab -c /tmp/krb5cc_%U %[email protected]
ExecStartPost=/usr/bin/krenew -b -K 60 -k /tmp/krb5cc_%U
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=KerberosTicketing

[Install]
WantedBy=default.target

これは完全に機能し、Afterがdefault.targetを指している場合、Kerberos認証チケットを作成して保存します。しかし、なぜdefault.target？それは起動プロセスのかなり遅い段階です。生成されたチケットを使用して、パブリック/プライベート認証を受け入れないサーバーからリモートファイルシステムをマウントできるように、multi-user.targetで動作させたいと思います。

[〜＃〜] edit [〜＃〜]：Afterがdefault.target以降の場合、kinitはエラーkinit: Cannot find KDC for realm "EXAMPLE.COM" while getting initial credentialsで失敗します。

私は基本的にこれを達成しようとしています： Kerberos（GSSAPI）を使用したFSTABを介したSSHFS自動マウント 。

systemdsshfskerberos
1
Kartik

systemd --userユニットの場合、ここから時間が始まります。 -user manager全体ブートプロセスの後半に開始します–これはsystemd-logindによって開始されるシステムサービス（user @ .service）であり、それ自体は常にレイトブート中に開始されます。

以前のユニット（remote-fs.targetなど）に対してサービスを注文するには、これをsystemサービスに変換する必要があります。そうすれば、.mountユニット（またはfstabエントリ）もサービスへの依存関係を指定できるようになります。

WantedBy = しないユニットがいつキューに入れられるかを定義することに注意してください（逆の方法で）。代わりに、それは（暗黙的および明示的な）Before =/After =オプションによって定義されます。 「WantedBy = multi-user.target」だけでなく、「DefaultDependencies = no」および「Before = remote-fs.target」を持つユニットを持つことは完全に可能であり、一般的です。

補足として、しないでください ExecStartPost =を介してkrenew -Kなどのデーモンを実行します。 '公式に'長時間実行プロセスを許可する（そしてRestart =などの機能を提供する）唯一の場所はメインのExecStart =であるため、定期的な更新が必要な場合は、そこにkrenew -Kを配置します。

Kinitを2番目のExecStartPre =として実行するか、k5start -Kを使用して、手動でkinitする必要をなくすことができます。

ExecStart=/usr/bin/k5start -L -b -K 30 -f %h/client.keytab -k /tmp/krb5cc_%U -u %[email protected]
2
user1686