Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Problembehandlung bei der Mehrbenutzerintegration mit Active Directory
Dieser Abschnitt ist relevant für Cluster, die in ein Active Directory integriert sind.
Wenn die Active Directory-Integrationsfunktion nicht wie erwartet funktioniert, können die SSSD Protokolle nützliche Diagnoseinformationen liefern. Diese Protokolle befinden sich /var/log/sssd
auf Clusterknoten. Standardmäßig werden sie auch in der CloudWatch Amazon-Protokollgruppe eines Clusters gespeichert.
Themen
- Active Directory-spezifische Fehlerbehebung
- Debug-Modus aktivieren
- Wie wechselt man von LDAPS zu LDAP
- Wie deaktiviere ich die Überprüfung von LDAPS Serverzertifikaten
- Wie melde ich mich mit einem SSH Schlüssel statt mit einem Passwort an
- Wie setze ich ein Benutzerpasswort und abgelaufene Passwörter zurück
- Wie verifiziert man die beigetretene Domäne
- Wie behebt man Probleme mit Zertifikaten
- Wie kann überprüft werden, ob die Integration mit Active Directory funktioniert
- Wie behebt man Probleme bei der Anmeldung bei Rechenknoten
- Bekannte Probleme mit SimCenter CCM Star+-Jobs in einer Mehrbenutzerumgebung
- Bekannte Probleme bei der Auflösung von Benutzernamen
- Wie löst man Probleme beim Erstellen von Home-Verzeichnissen
Active Directory-spezifische Fehlerbehebung
Dieser Abschnitt ist relevant für die Problembehandlung, die für einen Active Directory-Typ spezifisch ist.
Simple AD
-
Der
DomainReadOnlyUser
Wert muss mit der Basissuche im Simple AD AD-Verzeichnis für Benutzer übereinstimmen:cn=ReadOnlyUser,cn=Users,dc=
corp
,dc=example
,dc=com
Hinweis
cn
fürUsers
. -
Der Standard-Admin-Benutzer ist
Administrator
. -
Ldapsearch
erfordert BIOS den Netznamen vor dem Benutzernamen.Ldapsearch
Die Syntax muss wie folgt lauten:$
ldapsearch -x -D "corp\\Administrator" -w
"Password"
-H ldap://192.0.2.103
\ -b "cn=Users,dc=corp
,dc=example
,dc=com
"
AWS Managed Microsoft AD
-
Der
DomainReadOnlyUser
Wert muss mit der Basissuche im AWS Managed Microsoft AD Verzeichnis für Benutzer übereinstimmen:cn=ReadOnlyUser,ou=Users,ou=CORP,dc=
corp
,dc=example
,dc=com
-
Der Standard-Admin-Benutzer ist
Admin
. -
Ldapsearch
Die Syntax muss wie folgt lauten:$
ldapsearch -x -D "Admin" -w
"Password"
-H ldap://192.0.2.103
\ -b "ou=Users,ou=CORP,dc=corp
,dc=example
,dc=com
"
Debug-Modus aktivieren
Debug-Protokolle von SSSD können nützlich sein, um Probleme zu beheben. Um den Debug-Modus zu aktivieren, müssen Sie den Cluster mit den folgenden Änderungen an der Clusterkonfiguration aktualisieren:
DirectoryService: AdditionalSssdConfigs: debug_level: "0x1ff"
Wie wechselt man von LDAPS zu LDAP
LDAPEs wird davon abgeraten, von LDAPS (LDAPmitTLS/SSL) nach zu wechseln, da dies LDAP allein keine Verschlüsselung bietet. Dennoch kann es für Testzwecke und zur Fehlerbehebung nützlich sein.
Sie können die vorherige Konfiguration des Clusters wiederherstellen, indem Sie den Cluster mit der vorherigen Konfigurationsdefinition aktualisieren.
Um von LDAPS zu wechselnLDAP, müssen Sie den Cluster mit den folgenden Änderungen in der Clusterkonfiguration aktualisieren:
DirectoryService: LdapTlsReqCert: never AdditionalSssdConfigs: ldap_auth_disable_tls_never_use_in_production: True
Wie deaktiviere ich die Überprüfung von LDAPS Serverzertifikaten
Zu Test- oder Problembehandlungszwecken kann es nützlich sein, die LDAPS Serverzertifikatsverifizierung auf dem Hauptknoten vorübergehend zu deaktivieren.
Sie können die vorherige Konfiguration des Clusters wiederherstellen, indem Sie den Cluster mit der vorherigen Konfigurationsdefinition aktualisieren.
Um die Überprüfung des LDAPS Serverzertifikats zu deaktivieren, müssen Sie den Cluster mit den folgenden Änderungen in der Clusterkonfiguration aktualisieren:
DirectoryService: LdapTlsReqCert: never
Wie melde ich mich mit einem SSH Schlüssel statt mit einem Passwort an
Der SSH Schlüssel wird erstellt, /home/$user/.ssh/id_rsa
nachdem Sie sich zum ersten Mal mit einem Passwort angemeldet haben. Um sich mit dem SSH Schlüssel anzumelden, müssen Sie sich mit Ihrem Passwort anmelden, den SSH Schlüssel lokal kopieren und ihn dann wie gewohnt SSH ohne Passwort verwenden:
$
ssh -i
$LOCAL_PATH_TO_SSH_KEY $username@$head_node_ip
Wie setze ich ein Benutzerpasswort und abgelaufene Passwörter zurück
Wenn ein Benutzer den Zugriff auf einen Cluster verliert, ist sein AWS Managed Microsoft AD Passwort möglicherweise abgelaufen.
Um das Passwort zurückzusetzen, führen Sie den folgenden Befehl mit einem Benutzer und einer Rolle aus, die über Schreibberechtigungen für das Verzeichnis verfügen:
$
aws ds reset-user-password \ --directory-id
"d-abcdef01234567890"
\ --user-name"USER_NAME"
\ --new-password"NEW_PASSWORD"
\ --region"region-id"
Wenn Sie das Passwort für DirectoryService/zurücksetzen DomainReadOnlyUser:
-
Achten Sie darauf, das DirectoryService/PasswordSecretArnSecret mit dem neuen Passwort zu aktualisieren.
-
Aktualisieren Sie den Cluster für den neuen geheimen Wert:
-
Stoppen Sie die Rechenflotte mit dem
pcluster update-compute-fleet
Befehl. -
Führen Sie den folgenden Befehl innerhalb des Cluster-Hauptknotens aus.
$
sudo /opt/parallelcluster/scripts/directory_service/update_directory_service_password.sh
-
Nach dem Zurücksetzen des Kennworts und dem Cluster-Update sollte der Clusterzugriff des Benutzers wiederhergestellt werden.
Weitere Informationen finden Sie unter Benutzerpasswort zurücksetzen im AWS Directory Service Administratorhandbuch.
Wie verifiziert man die beigetretene Domäne
Der folgende Befehl muss von einer Instanz aus ausgeführt werden, die mit der Domäne verknüpft ist, nicht vom Hauptknoten aus.
$
realm list corp.example.com \ type: kerberos \ realm-name: CORP.EXAMPLE.COM \ domain-name: corp.example.com \ configured: kerberos-member \ server-software: active-directory \ client-software: sssd \ required-package: oddjob \ required-package: oddjob-mkhomedir \ required-package: sssd \ required-package: adcli \ required-package: samba-common-tools \ login-formats: %U \ login-policy: allow-realm-logins
Wie behebt man Probleme mit Zertifikaten
Wenn die LDAPS Kommunikation nicht funktioniert, kann dies an TLS Kommunikationsfehlern liegen, die wiederum auf Probleme mit Zertifikaten zurückzuführen sein können.
Hinweise zu Zertifikaten:
-
Das in der Clusterkonfiguration angegebene Zertifikat
LdapTlsCaCert
muss ein Bündel von PEM Zertifikaten sein, das die Zertifikate für die gesamte Zertifizierungskette (CA) enthält, die Zertifikate für die Domänencontroller ausgestellt hat. -
Ein Bündel von PEM Zertifikaten ist eine Datei, die aus der Verkettung von Zertifikaten besteht. PEM
-
Ein Zertifikat im PEM Format (das normalerweise in Linux verwendet wird) entspricht einem Zertifikat im DER Base64-Format (normalerweise von Windows exportiert).
-
Wenn das Zertifikat für Domänencontroller von einer untergeordneten Zertifizierungsstelle ausgestellt wird, muss das Zertifikatspaket das Zertifikat sowohl der untergeordneten Zertifizierungsstelle als auch der Stammzertifizierungsstelle enthalten.
Schritte zur Fehlerbehebung bei der Überprüfung:
Bei den folgenden Überprüfungsschritten wird davon ausgegangen, dass die Befehle vom Cluster-Hauptknoten aus ausgeführt werden und dass der Domänencontroller unter erreichbar ist
.SERVER
:PORT
Gehen Sie wie folgt vor, um ein Problem im Zusammenhang mit Zertifikaten zu beheben:
Schritte zur Überprüfung:
-
Überprüfen Sie die Verbindung zu den Active Directory-Domänencontrollern:
Stellen Sie sicher, dass Sie eine Verbindung zu einem Domänencontroller herstellen können. Wenn dieser Schritt erfolgreich ist, ist die SSL Verbindung zum Domänencontroller erfolgreich und das Zertifikat wird überprüft. Ihr Problem hat nichts mit Zertifikaten zu tun.
Wenn dieser Schritt fehlschlägt, fahren Sie mit der nächsten Überprüfung fort.
$
openssl s_client -connect
SERVER
:PORT
-CAfilePATH_TO_CA_BUNDLE_CERTIFICATE
-
Überprüfen Sie die Überprüfung des Zertifikats:
Stellen Sie sicher, dass das lokale Zertifizierungsstellenzertifikatpaket das vom Domänencontroller bereitgestellte Zertifikat validieren kann. Wenn dieser Schritt erfolgreich ist, hängt Ihr Problem nicht mit Zertifikaten zusammen, sondern mit anderen Netzwerkproblemen.
Wenn dieser Schritt fehlschlägt, fahren Sie mit der nächsten Überprüfung fort.
$
openssl verify -verbose -CAfile
PATH_TO_CA_BUNDLE_CERTIFICATE
PATH_TO_A_SERVER_CERTIFICATE
-
Überprüfen Sie das von den Active Directory-Domänencontrollern bereitgestellte Zertifikat:
Stellen Sie sicher, dass der Inhalt des von den Domänencontrollern bereitgestellten Zertifikats den Erwartungen entspricht. Wenn dieser Schritt erfolgreich ist, haben Sie wahrscheinlich Probleme mit dem CA-Zertifikat, das zur Überprüfung der Controller verwendet wird. Fahren Sie mit dem nächsten Schritt zur Fehlerbehebung fort.
Schlägt dieser Schritt fehl, müssen Sie das für die Domänencontroller ausgestellte Zertifikat korrigieren und die Schritte zur Fehlerbehebung erneut ausführen.
$
openssl s_client -connect
SERVER
:PORT
-showcerts -
Überprüfen Sie den Inhalt eines Zertifikats:
Stellen Sie sicher, dass der Inhalt des von den Domänencontrollern bereitgestellten Zertifikats den Erwartungen entspricht. Wenn dieser Schritt erfolgreich ist, haben Sie wahrscheinlich Probleme mit dem CA-Zertifikat, das zur Überprüfung der Controller verwendet wird. Fahren Sie mit dem nächsten Schritt zur Fehlerbehebung fort.
Schlägt dieser Schritt fehl, müssen Sie das für die Domänencontroller ausgestellte Zertifikat korrigieren und die Schritte zur Fehlerbehebung erneut ausführen.
$
openssl s_client -connect
SERVER
:PORT
-showcerts -
Überprüfen Sie den Inhalt des lokalen CA-Zertifikatspakets:
Stellen Sie sicher, dass der Inhalt des lokalen Zertifizierungsstellenzertifikatpakets, das zur Überprüfung des Zertifikats der Domänencontroller verwendet wird, den Erwartungen entspricht. Wenn dieser Schritt erfolgreich ist, haben Sie wahrscheinlich Probleme mit dem Zertifikat, das von den Domänencontrollern bereitgestellt wird.
Wenn dieser Schritt fehlschlägt, müssen Sie das für die Domänencontroller ausgestellte CA-Zertifikatspaket korrigieren und die Schritte zur Fehlerbehebung erneut ausführen.
$
openssl x509 -in
PATH_TO_A_CERTIFICATE
-text
Wie kann überprüft werden, ob die Integration mit Active Directory funktioniert
Wenn die folgenden beiden Prüfungen erfolgreich sind, funktioniert die Integration mit dem Active Directory.
Prüfungen:
-
Sie können Benutzer finden, die im Verzeichnis definiert sind:
Aus dem Hauptknoten des Clusters heraus, als
ec2-user
:$
getent passwd
$ANY_AD_USER
-
Sie können SSH in den Hauptknoten gelangen und das Benutzerpasswort eingeben:
$
ssh
$ANY_AD_USER@$HEAD_NODE_IP
Wenn Prüfung eins fehlschlägt, gehen wir davon aus, dass auch Prüfung zwei fehlschlägt.
Zusätzliche Prüfungen zur Fehlerbehebung:
-
Stellen Sie sicher, dass der Benutzer im Verzeichnis vorhanden ist.
-
Aktivieren Sie die Debug-Protokollierung.
-
Erwägen Sie, die Verschlüsselung vorübergehend zu deaktivieren, indem Sie von LDAPS zu wechseln LDAP, um Probleme auszuschließenLDAPS.
Wie behebt man Probleme bei der Anmeldung bei Rechenknoten
Dieser Abschnitt ist relevant für die Anmeldung bei Rechenknoten in Clustern, die in Active Directory integriert sind.
Mit AWS ParallelCluster sind Kennwortanmeldungen an Cluster-Rechenknoten standardmäßig deaktiviert.
Alle Benutzer müssen ihren eigenen SSH Schlüssel verwenden, um sich bei Rechenknoten anzumelden.
Benutzer können ihren SSH Schlüssel nach der ersten Authentifizierung (z. B. Anmeldung) im Hauptknoten abrufen, sofern dies in der Clusterkonfiguration aktiviert GenerateSshKeysForUsersist.
Wenn sich Benutzer zum ersten Mal auf dem Hauptknoten authentifizieren, können sie SSH Schlüssel abrufen, die automatisch für sie als Verzeichnisbenutzer generiert werden. Home-Verzeichnisse für den Benutzer werden ebenfalls erstellt. Dies kann auch passieren, wenn ein Sudo-Benutzer zum ersten Mal zu einem Benutzer im Hauptknoten wechselt.
Wenn sich ein Benutzer nicht am Hauptknoten angemeldet hat, werden keine SSH Schlüssel generiert und der Benutzer kann sich nicht bei Rechenknoten anmelden.
Bekannte Probleme mit SimCenter CCM Star+-Jobs in einer Mehrbenutzerumgebung
Dieser Abschnitt ist relevant für Jobs, die mit der Computational Fluid Dynamics Software Simcenter Star CCM + von Siemens in einer Mehrbenutzerumgebung gestartet wurden.
Wenn Sie Star CCM + v16-Jobs ausführen, die für die Verwendung der integrierten Intel konfiguriert sindMPI, erfolgt der Bootstrapping der MPI Prozesse standardmäßig über. SSH
Aufgrund eines bekannten Slurm Aufgrund eines Fehlerserror setting up the bootstrap proxies
. Dieser Fehler betrifft nur die AWS ParallelCluster Versionen 3.1.1 und 3.1.2.
Um dies zu verhindern, zwingen Sie Intel MPI zur Verwendung Slurm als MPI Bootstrap-Methode. Exportieren Sie die Umgebungsvariable I_MPI_HYDRA_BOOTSTRAP=slurm
in das Jobskript, das Star CCM + startet, wie in der MPIoffiziellen Dokumentation von Intel
Bekannte Probleme bei der Auflösung von Benutzernamen
Dieser Abschnitt ist relevant für das Abrufen von Benutzernamen innerhalb von Jobs.
Aufgrund eines bekannten Fehlers in Slurmnobody
wenn Sie einen Job ohne ausführen. srun
Dieser Fehler betrifft nur die AWS ParallelCluster Versionen 3.1.1 und 3.1.2.
Wenn Sie den Befehl beispielsweise sbatch --wrap 'srun id'
als Verzeichnisbenutzer ausführen, wird der richtige Benutzername zurückgegeben. Wenn Sie den jedoch sbatch --wrap 'id'
als Verzeichnisbenutzer ausführen, wird nobody
möglicherweise der Benutzername zurückgegeben.
Sie können die folgenden Problemumgehungen verwenden.
-
Starten Sie Ihren Job
'sbatch'
, wenn möglich, mit'srun'
statt mit. -
Aktivieren Sie die SSSD Enumeration, indem Sie die AdditionalSssdConfigsCluster-Konfiguration wie folgt festlegen.
AdditionalSssdConfigs: enumerate: true
Wie löst man Probleme beim Erstellen von Home-Verzeichnissen
Dieser Abschnitt ist relevant für Probleme bei der Erstellung von Home-Verzeichnissen.
Wenn Sie Fehler wie den im folgenden Beispiel gezeigten sehen, wurde kein Home-Verzeichnis für Sie erstellt, als Sie sich zum ersten Mal am Hauptknoten angemeldet haben. Oder es wurde kein Home-Verzeichnis für Sie erstellt, als Sie zum ersten Mal im Hauptknoten von einem Sudoer zu einem Active Directory-Benutzer wechselten.
$
ssh AD_USER@$HEAD_NODE_IP
/opt/parallelcluster/scripts/generate_ssh_key.sh failed: exit code 1 __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ Could not chdir to home directory /home/PclusterUser85: No such file or directory
Der Fehler beim Erstellen des Home-Verzeichnisses kann durch die oddjob
im oddjob-mkhomedir
Cluster-Hauptknoten installierten UND-Pakete verursacht werden.
Ohne ein Home-Verzeichnis und einen SSH Schlüssel kann der Benutzer keine Jobs einreichen oder SSH in die Clusterknoten einsteigen.
Wenn Sie die oddjob
Pakete in Ihrem System benötigen, stellen Sie sicher, dass der oddjobd
Dienst ausgeführt wird, und aktualisieren Sie die PAM Konfigurationsdateien, um sicherzustellen, dass das Home-Verzeichnis erstellt wurde. Führen Sie dazu die Befehle im Hauptknoten aus, wie im folgenden Beispiel gezeigt.
sudo systemctl start oddjobd sudo authconfig --enablemkhomedir --updateall
Wenn Sie die oddjob
Pakete in Ihrem System nicht benötigen, deinstallieren Sie sie und aktualisieren Sie die PAM Konfigurationsdateien, um sicherzustellen, dass das Home-Verzeichnis erstellt wurde. Führen Sie dazu die Befehle im Hauptknoten aus, wie im folgenden Beispiel gezeigt.
sudo yum remove -y oddjob oddjob-mkhomedir sudo authconfig --enablemkhomedir --updateall