学生ラボのUbuntuデスクトップでNISクライアントを実行しています。夏のプロジェクトの一環として、Ubuntu 18.04を1台のPCにインストールし、NISクライアントをそのPCにインストールしました。ドメインはすべて正常で、ypwhich
、ypcat
、およびyptest
はすべて正常に機能しています。
ただし、NISアカウント(ローカルホームまたはNFSホーム)を使用してログインすると、GDMとLightDM(両方を試しました)の両方がハングし、最終的にXがクラッシュします。ローカルアカウントとホームディレクトリで正常に動作します。
エラーログには次のメッセージのみが表示されます。
pam_systemd(sshd:session): failed to create session
端末だけを使用して同じNISログインを試みた場合(Ctrl+Alt+F1)私は認証できますが、bashシェル、ローカルまたはNFSが正しくマウントされているかどうかに関係なくホームディレクトリを提供する前に、セッションは約25秒間フリーズします。これは最終的にUbuntu 16.04でうまくいきました。 (systemdがrpc.bind: /bin/systemctl add-wants multi-user.target rpcbind.service
を起動するようにするには、次の行を追加する必要がありました。)Ubuntu 18.04でこれを試しましたが成功しませんでした。この問題を引き起こしている認証とセッションの作成の間に遅延があるように見えます。最新のアップデートなど、および彼の最新のapt-get
などをダウンロードしてインストールしました。
返信いただきありがとうございます。私はlightdmをインストールしようとしましたが、NISユーザーとしてXにログオンすることで少し成功しました。しかし、Xにログインしたり、Xにログインしたり、タイムアウトしたりすることがあるため、ラボでは使用できません。私は16.04を再びインストールしましたが、それはうまくいきましたので、18.04ベッドが少し下がるまでそのままにしておきました。パウロをやった後、あなたの返事を見ました! 18.04の再インストールを見て、Cheersを取り戻します
上記のようにパウロのチップを試してみました。残念ながら、Ubuntu 18.04で同じセットアップファイルをマップできませんでした(つまり、/ etc/systemd/system/systemd-login.service.dまたは/usr/lib/systemd/system/systemd-logind.serviceが見つかりませんでした) /etc/system/logind.conf。IPAddressAllowステートメントをそこに入れようとしましたが(言及もデフォルトもありませんでした)、認識されませんでした。また、同じディレクトリに自分の.confファイルを挿入しようとしました。同じ症状と非常に似ているか、ここでの私の知識不足かもしれません。もう一度見直しますが、当面、Ubuntuがこの問題をソートするアップデートまたはパッチをすぐにリリースすることを願っています
私もこれに影響され、最初はコメントアウトしてこの問題を解決しました
IPAdressDeny=Any
の/lib/systemd/system/systemd-logind.service
前述の多くの他の人のように。
ただし、これはセキュリティリスクであることに加えて、 Arch-Wiki で説明されているように、systemdツールチェーンの次の更新が展開されるまで機能しません。ウィキがあまりうまく説明していないのは、特定のアドレス範囲がホワイトリストに登録されるようにsystemd-logind.serviceの設定をextendする方法ですまた、これらの設定は更新後も存続します。 RHEL documentation (特にセクション10.6.4:既存のユニットファイルの変更)を読んだ後、次の解決策がうまくいきました:
/etc/systemd/system/
を含めて、拡張したいサービスとまったく同じ名前の.d
に新しいディレクトリを作成します。これは次のようになります:systemd-logind.service.d
新しく作成したディレクトリ内にchoose_an_appropriate_name.conf
(たとえばnis_open_network_interface.conf)を作成し、許可するIPまたはIP範囲を指定する次のコンテンツを追加します。
[Service]
IPAddressAllow=10.10.0.0/16
systemctl daemon-reload
を行う
systemctl cat systemd-logind.service
を使用して、新しい構成が実際にsystemd-logind.serviceユニットの一部であるかどうかを確認しますsystemctl restart systemd-logind.service
を再起動します(これにより、実行中のgnomeセッションから追い出され、再度ログインする必要があります。)他のファイルを変更する必要はありません!この時点で、システムがフリーズすることなく、NISユーザーで再度ログインできるはずです。ただし、これはまだ安全ではないと見なされ(IPアドレスのホワイトリスト登録)、systemd-logindのサンドボックス化された動作が必要であることに注意してください。 NIS/YPは一種の時代遅れですが、私は今でも頻繁に使用されています。また、これに言及したように、nscdまたはsssdを使用するネームキャッシングデーモンを含む、これに対するより良いソリューションがあるかもしれません systemd github issue 状況全体に対処します。しかし、これは現時点では私の範囲外です。
この回答は、以前の投稿からすべての断片を収集します。問題を解決するために、少し明確にしたいと思います。
乾杯
私は学生のために設定しているラボで同じ問題に直面していました。私の一時的な解決策は、17.10クライアントを使用することでした。サーバーが18.04であっても機能します。
しかし、今、私は家に帰って、 Arch Linux wiki について非常に興味深いコメントを見つけました。 2017年10月に行われたsystemdの変更に注意を促します。これは本当に問題のようです。また、NISサーバーをホワイトリストに登録する「/etc/systemd/system/systemd-logind.service.d/内に新しい.confファイルを作成することでこれを行うことができます」に基づくソリューションも提案しています。私は仕事に戻った月曜日にのみこれを試すことができます(または抵抗せずにsshで試します)。ただし、システムにアクセスできる場合は、試してレポートを返すことができます。
Ubuntu 18.04 LTSでは、行を削除するだけで問題を解決できるはずです。
IPAddressDeny=any
/lib/systemd/system/systemd-logind.service
から
あなたが説明したことを考えると、あなたの場合ではないようですが、接続しようとしているNISユーザーのホームディレクトリを持っている必要があることに注意してくださいNISサーバーへの接続には時間がかかる場合があります。
トムが言及している2番目の解決策が今でも私にとって完璧に機能することを確認できます(Hadntは間違ったパスに気づきました-ありがとう)。 Iveも最初の解決策を試しましたが、やはりうまくいかないようです。また、誤って/etc/systemd/system.confファイルを見つけましたが、
内部ネットワークエントリ(例:10.0.0.0/16)を入力しようとしましたが、有効にならないようです。 systemdの初心者です(ubuntu 14.04から来ています)。今のところ、ソリューション2は完璧であり、更新などを回避できますが、時間の許す限りオプション1をもう一度見るか、誰かがこれを解読するかもしれません。助けてくれてありがとう
Paulosのヒントを試してみましたが、リンクをたどると説明されている回避策にはさまざまな問題があります。
私が働いた2番目の解決策。彼らはちょうどubuntuの間違ったパスを持っています、ファイルはここにあります:
/lib/systemd/system/systemd-logind.service
私はこの行をコメントアウトしました:
# IPAddressDeny=any
そして、再起動後に動作しました。
ただし、最初の解決策が最善のように見えますが、私はさまざまな問題を発見し、構文を適切に取得できません。名前から始めることは間違っています。それは有効な名前ではないため、実際のファイルではなくシンボリックリンクである必要があります。作成する限り
/lib/systemd/system/open_nis_interface.service
そしてそれを埋める:
[Service]
IPAddressAllow=10.0.0.0/16
次にリンク:
mkdir /etc/systemd/system/systemd-logind.service.wants/
ln -s /lib/systemd/system/open_nis_interface.service /etc/systemd/system/systemd-logind.service.wants/
ファイルをロードしていますが、構文が正しくありません。 systemdを実行すると、okメッセージが表示されます。
dmesg | grep systemd
私が言ったように、システムファイルを単に上書きする2番目の方法は私にとってはうまくいきます。おそらく、誰かが最初の方法を終えることができます。
トム
同様の問題があり、17.10から18.04にアップグレードしました。ローカルユーザーでログインできましたが、セッションは再起動するまでそれほど長く続きませんでした。 GUIを再起動しないと、nisユーザーでログインできませんでした。
ディスプレイマネージャをlightdmに切り替えることで、問題を回避することができました。
Sudo apt install lightdm
Sudo dpkg-reconfigure gdm3
次に、マネージャーとしてlightdmを選択します。再起動すると、nisユーザーでログインできました。
ログインにかかる時間は解決されませんが、GUIを取得することはできます。