Installieren des Agenten für IBM AIX, Linux (x64) und PowerPC 64 LE (Java)

Wichtig! Diese Installationsanweisungen gelten ausschließlich für die Installation von Agenten für IBM AIX, Linux x64 und PowerPC 64 LE. Installationsanweisungen für andere UNIX-Agenten finden Sie unter Installieren des Agenten auf anderen UNIX-Plattformen.

Die Java-Agenten erfordern eine JRE (Version 17 oder höher).

Diese Seite führt Sie durch die Installation eines Java-basierten Agenten für IBM AIX, Linux (x64) und PowerPC 64 LE in einem AE-System ohne Authentifizierung. Wenn Sie eine der verfügbaren Authentifizierungsmethoden verwenden möchten, müssen Sie weitere Installationsschritte durchführen. Weitere Informationen finden Sie unter Authentifizierung von Agenten.

Überprüfen Sie die compatibility matrix um zu erkennen, welche Version mit Ihrem System kompatibel ist. Weitere Informationen finden Sie unter Kompatibilitätsinformationen.

Tipp! Diese Seite bezieht sich nur auf den manuellen Installationsprozess. Anweisungen zum Installieren eines Container-UNIX-Agenten finden Sie unter Container-UNIX-Agenten installieren.

Übersicht

Der Agent besteht aus zwei Komponenten:

• Einer Launcher-Anwendung mit dem Namen ucxja64 (für AIX), ucxjlx6 (für Linux x64) oder ucxjlpl (für PowerPC 64 LE)

• Einem Java-Archiv (JAR-Datei mit dem Namen ucxjoss.jar)

Beide befinden sich im bin-Verzeichnis des Agenten. Der Launcher erkennt und startet eine verfügbare Java-Laufzeitumgebung (Java Runtime Environment, JRE) und lädt dann die in der JAR-Datei bereitgestellte Anwendung.

Wichtig! Verwenden Sie nur den Launcher, um den Agenten zu starten. Versuchen Sie NICHT, die JAR-Datei manuell in eine JRE zu laden, da er Launcher wichtige Vorbereitungen durchführt, damit der Agent richtig funktioniert.

Jede unterstützte UNIX-Variante hat einen dreistelligen Code, der Teil des Dateinamens des Agenten ist. In diesem Thema wird der spezifische Code durch "???" ersetzt.

Jobs, die für die Ausführung auf UNIX-Agenten eingeplant sind, können kundenspezifische Scripts enthalten. Wenn eines dieser Scripts die Umgebungsvariable LD_LIBRARY_PATH ändert, während der Loader ausgeführt wird, bleibt die Änderung in der Shell-Umgebung. Wenn die Messenger-Binärdatei danach ausgeführt wird, schlägt das Laden fehl und die Jobausführung wird abgebrochen. Weitere Informationen finden Sie unter Fehlerbehebung - LD_LIBRARY_PATH überschrieben.

Hinweis: Sie müssen eine eigene UNIX-Benutzer-ID für die Automation Engine erstellen (Standard: uc4, Home = /opt/uc4).

Die Agenten für IBM AIX, Linux x64 und PowerPC 64 LE unterstützen das Senden von E-Mails über SMTP und SMTPS. Weitere Informationen finden Sie unter Einrichten von E-Mail-Verbindungen.

Wichtige Hinweise

Die folgenden Abschnitte beschreiben einige wichtige Themen, die Sie beim Installieren und Konfigurieren des Agenten berücksichtigen müssen.

Java Java-Laufzeitumgebung (JRE)

Der Agent erfordert eine JRE (Version 17 oder höher). Sie können sie entweder durch eine systemübergreifende Java-Installation oder über eine erforderliche Mindestversion der JRE zur Verfügung stellen.

Beim Starten sucht die Launcher-Anwendung des Agenten mithilfe der folgenden Methoden nach der JRE:

1. Suchen und Starten der JRE über das Unterverzeichnis jre im bin-Verzeichnis des Agenten. Das jre-Verzeichnis wird entweder von CAU bereitgestellt oder kann manuell installiert werden.

2. Verwenden der Umgebungsvariablen JAVA_HOME.

3. Ausführen des Befehls java -XshowSettings:properties, um eine geeignete Java-Installation zu finden. Der Launcher verwendet die Umgebungsvariable PATH, um die ausführbare Datei zu finden. Wenn dieser Befehl erfolgreich ist (d. h. die JVM wird gestartet), wird der Pfad der ausgeführten JVM aus der Ausgabe des Befehls abgerufen.

Der Launcher startet dann die JRE und lädt die jar-Datei des Agenten.

Bereitstellung von Standardbibliotheken in UNIX-Systemen

Die Standardbibliotheken (libstdc++.so und libgcc_s.so) sind nicht mehr Teil der .tar-Balls des Agenten, des Service Manager und der Dienstprogramme. Sie werden jetzt mit dem Angebot unter External.Resources/unix_libraries/unix_libraries.tar.gz bereitgestellt.

Wichtig! Wenn der dynamische Linker des Betriebssystems die erforderlichen Bibliotheken in den Suchpfaden der Bibliothek nicht finden kann, startet die Komponente nicht. In solch einem Fall können Sie die Bibliotheken manuell im Bin-Verzeichnis der Komponente installieren.

Führen Sie folgende Schritte durch:

1. Gehen Sie zum Angebots-Bundle und entpacken Sie die Datei External.Resources/unix_libraries/unix_libraries.tar.gz.

2. Kopieren Sie die für Ihr System relevanten Bibliotheken (libstdc++.so.6 und libgcc_s.so.1) (berücksichtigen Sie das Betriebssystem, Typ der Hardware) in das Bin-Verzeichnis der jeweiligen Komponente.

Anmerkung: Da die Bibliotheken, die im Bin-Verzeichnis vorhanden sind, sehr häufig geladen werden, würden alte oder falsche Bibliotheksversionen im Bin-Verzeichnis verhindern, dass die Komponente gestartet wird.

Privilegierter und unprivilegierter Modus

Der Agent für UNIX-Betriebssysteme kann so installiert werden, dass er entweder als privilegierter oder als unprivilegierter Prozess ausgeführt wird. Jedoch kann der Agent nur mit voller Funktionalität arbeiten, wenn er als privilegierter Prozess installiert wird.

Sie können drei verschiedene Methoden verwenden, um den Agenten mit Root-Berechtigungen zu starten:

1. Starten Sie den Agenten direkt unter dem Benutzer root.

2. Definieren Sie root als Eigentümer, weisen Sie die Gruppe zu, in der der Startbenutzer Mitglied sein muss, und setzen Sie die SetUID (s-bit) für den Besitzer der Agenten-Datei.

   Beispiel für IBM AIX

   • chown root ucxja64

   • chgrp admin ucxja64

   • chmod 4755 ucxja64

   Beispiel für Linux x64

   • chown root ucxjlx6

   • chgrp admin ucxjlx6

   • chmod 4755 ucxjlx6

   Beispiel für PowerPC 64 LE

   • chown root ucxjlpl

   • chgrp admin ucxjlpl

   • chmod 4755 ucxjlpl

   Wenn Sie den UNIX-Agenten für Solaris verwenden, ist es nicht möglich, Bibliotheken aus benutzerdefinierten Ordnern als root zu laden, es sei denn, der Agent wird von root gestartet. Das bedeutet, dass ein regulärer Benutzer mit dem Flag SetUID den Agenten nicht starten kann. Deshalb müssen Sie das Laden von Bibliotheken aus benutzerdefinierten Ordnern als root ausdrücklich erlauben, um den Agenten mit SetUID aus einem benutzerdefinierten Ordner laden zu können. Dazu können Sie crle-Befehle verwenden. Beispiel: sudo crle -64 -s <absoluter Pfad zum bin-Verzeichnis des Agenten> -u.

3. Trennen Sie die Berechtigungen.

   Der Agent verwendet das Programm user_service, das dafür zuständig ist, Anfragen wie zum Beispiel "Datei erstellen", "Verzeichnis wechseln" oder "Prozess starten" als anderer Benutzer an das Betriebssystem zu senden. Es ist auch verantwortlich für das Einrichten der richtigen Sicherheitsumgebung für Ressourcen, zum Beispiel über "Eigentümer anpassen" oder Standardberechtigungen. Das Programm wird im Hintergrund mit den für diesen Benutzer spezifischen Zugangsdaten gestartet. Es wird vom Agenten ausschließlich auf Anfrage gestartet und bleibt aktiv, bis das Inaktivitätstimeout erreicht ist.

   Der Abschnitt [AUTHORIZATION] in der INI-Datei des Agenten enthält den Parameter agentUser, der für das Downgraden des Agentenprozesses verwendet wird. Das heißt: Nachdem der Agent gestartet wurde (mit höheren Berechtigungen), ändert er seine eigene Identität in den Benutzer, der in diesem Parameter angegeben wurde, damit die lauschenden Ports nicht über den privilegierten Benutzer gestartet und bedient werden.

   Der Agent versucht immer, mit getrennten Berechtigungen zu starten, wenn möglich. Wenn das nicht möglich ist, startet der Agent über denselben Benutzer, ohne Trennung der Berechtigungen.

   Die folgenden Regeln gelten:

   • Regel 1: Der Agent wird mit dem nativen Launcher (./ucxja64 für AIX, ./ucxjlx6 für Linux x64 oder ./ucxjlpl für PowerPC 64 LE) unter Verwendung eines Sticky Bit (UID = 0) gestartet.

     In diesem Fall versucht der Agent, seine Identität in den im Parameter agentUser definierten Benutzer zu ändern. Wenn der Parameter keine Definition hat (Standardeinstellung), ändert der Agent die angewendete Benutzer-ID in die tatsächliche Benutzer-ID (Trennung von Berechtigungen).

   • Regel 2: Der Agent wird mit dem nativen Launcher (./ucxja64 für AIX, ./ucxjlx6 für Linux x64 oder ./ucxjlpl für PowerPC 64 LE) ohne Sticky Bit gestartet.

     In diesem Fall versucht der Agent, seine Identität in den im Parameter agentUser definierten Benutzer zu ändern. Wenn der Parameter keine Definition hat (Standardeinstellung), bleibt die Identität des Agenten unverändert.

     Abhängig von der Definition der Einstellungen unter login_Check ist der Funktionsumfang möglicherweise eingeschränkt.

   Hinweis: Die Identität des Agenten kann nicht in den Benutzer nobody! geändert werden. Dies würde Sicherheitsprobleme verursachen und der Agent würde keine Verbindung zur Automation Engine herstellen können.

Warum sind Root-Berechtigungen erforderlich?

Der UNIX-Agent führt eine Vielzahl von Aufgaben unter der Kontrolle der Automation Engine aus. Diese Aufgaben müssen unter Benutzern ausgeführt werden, die den Aufgaben zugeordnet sind. Um Aufgaben als andere Benutzer als der UNIX-Agent-Startbenutzer starten zu können, prozessübergreifende Kommunikationen als andere Benutzer als der UNIX-Agent-Startbenutzer durchzuführen oder auf Dateien als anderer Benutzer als der UNIX-Agent-Startbenutzer zuzugreifen, benötigt der UNIX-Agent Root-Rechte, um den Benutzerkontext wechseln zu können.

Welche Aufgaben werden für welche Benutzer durchgeführt?

In Automation Engine-Jobs werden für bestimmte Benutzer FileTransfers, Dateiereignisse oder sogar verschiedene Automation Engine scripting language-Befehle definiert. Die Benutzer-Anmeldeinformationen werden in den Login-Objekten in der Automation Engine definiert.

Welche Einschränkungen gibt es, wenn der UNIX-Agent im unprivilegierten Modus betrieben wird?

Sie arbeiten im unprivilegierten Modus, wenn der Agent nicht als "root" gestartet wurde und "root" keinem anderen Benutzer Root-Berechtigungen erteilt hat. Als unprivilegierter Prozess kann der UNIX-Agent nur als Agentenstartbenutzer arbeiten. Aus diesem Grund können Jobs oder Dateizugriffe nur als Agentenstartbenutzer durchgeführt werden.

Welche Konfiguration ist erforderlich, um einen UNIX-Agenten im unprivilegierten Modus auszuführen?

Da der Agent keine Benutzerkontextwechsel durchführen kann, muss der Agent auch im anonymen Modus betrieben werden. Um den anonymen Modus zu aktivieren, setzen Sie den Parameter login_check in der Konfigurationsdatei (INI) auf no. Setzen Sie auch die Parameter ANONYMOUS_FT/ANONYMOUS_JOB/ANONYMOUS_FE nach Bedarf in der Variablen UC_HOSTCHAR_*, die dem Agenten zugeordnet ist. Weitere Informationen finden Sie unter UC_HOSTCHAR_DEFAULT - Host-Charakteristika.

Wichtig! Unabhängig davon, in welchem Modus Sie einen UNIX-Agenten ausführen, können Sie die Berechtigungen für die agentenspezifischen Unterverzeichnisse in der INI-Datei des Agenten konfigurieren. Siehe Agent Unix.

Agentenvariablen und Ordnerberechtigungen

Während oder nach der Agenten-Installation müssen Sie einige Agenten-spezifische Variablen konfigurieren, die den Zugriff auf die folgenden Ordner steuern:

• backup

  Agenten-spezifischer Ordner, der erstellt wird, wenn der Agent gestartet wird. Er ist für das dateibasierte Rollback vorgesehen und steht für Jobs und Dateiübertragungen zur Verfügung. Sie definieren seinen Pfad und die entsprechenden Berechtigungen in der Agenten-Variablen UC_EX_PATH_BACKUP.

  Um das dateibasierte Rollback zu nutzen, benötigen den Betriebssystem-Benutzer, unter welchem die Jobs und FileTransfers dafür gestartet werden, sowie Schreibrechte auf das Backup-Verzeichnis.

• temp

  Agenten-spezifischer Ordner, der erstellt wird, wenn der Agent gestartet wird. Hier speichert der Agent generierte Jobs vorübergehend. Sie definieren seinen Pfad und die entsprechenden Berechtigungen in der Agenten-Variablen UC_EX_PATH_TEMP.

• resources

  Agenten-spezifischer Ordner, der erstellt wird, wenn der Agent gestartet wird. Hier werden mandantenweite Ressourcen gespeichert. Sie definieren seinen Pfad und die entsprechenden Berechtigungen in der Agenten-Variablen UC_EX_PATH_CACHE.

Standardmäßig ist der Zugriff auf diese Ordner NICHT eingeschränkt und sie können von jedem Benutzer geändert werden. Sie konfigurieren spezifische Berechtigungen für jeden Ordner im Abschnitt [MISC] der INI-Datei des Agenten.

Beispiel

[MISC]
...
; angegebener Name oder ID des Benutzers (bei Angabe der ID wird diese als UID und GID verwendet), der zum Besitzer des Ordners wird
; Standard ist der Benutzer, der den Agenten ausgeführt
FolderOwner=osgrp
;FolderOwner_backup=
;FolderOwner_cache=
;FolderOwner_temp=
; die angegebenen Berechtigungsmasken sind festgelegt
; Standard ist ein beliebiger Zugriff für alle Benutzer für neu erstellte Ordner.
; vorhandene Ordnerberechtigungen werden nicht geändert
FolderPermissionMask=rwxrwxrwx
;FolderPermissionMask_backup=
;FolderPermissionMask_cache=
;FolderPermissionMask_temp=
...

Weitere Informationen finden Sie hier:

• Liste der Agentenvariablen

• Agent Unix – INI-Datei

Wichtig! Aus Sicherheitsgründen wird die Ereignisdatei im Verzeichnis HOME des Benutzers erstellt, wenn ein Login in der Script-Funktion PREP_PROCESS angegeben wurde. Wenn kein Login angegeben ist, geht das System davon aus, dass der nachfolgende Ereignisjob mit Agentenberechtigungen ausgeführt wird. Daher erstellt PREP_PROCESS den Dateinamen mit dem temporären Pfad des Agenten. Weitere Informationen finden Sie unter PREP_PROCESS.

Zum Zeitpunkt der Verarbeitung von PREP_PROCESS weiß das System nicht, ob der Job einen Login verwenden wird. Aus technischer Sicht ist dies derzeit nicht umsetzbar, da der Ereignis-Job den Login auch dynamisch angeben könnte (mit der Script-Anweisung :PUT_ATT; siehe :PUT_ATT).

Es gibt zwei mögliche Lösungen:

1. Geben Sie ein Login in PREP_PROCESS (empfohlene und sichere Lösung) an.
2. Weisen Sie dem Benutzer, der im Ereignis-Job definiert ist, Lese- und Schreibrechte für das temp-Verzeichnis des Agenten zu.

Berechtigungen für Dateien vom Typ jobreport werden mit dem Parameter ReportMode= der INI-Datei des UNIX-Agenten angegeben. Weitere Informationen finden Sie unter Agent Unix.

Jobausführungslimits für Benutzer festlegen

Sie können die Bibliothek pam_limit.so verwenden, um Jobausführungslimits für Benutzer festzulegen. Stellen Sie dazu sicher, dass die Bibliothek pam_limit.so in Ihrem System verfügbar ist. Andernfalls kann der Agent die Limits nicht richtig festlegen.

Hinweis: Sie benötigen nur die Bibliothek pam_limit.so; Sie müssen PAM nicht installieren und konfigurieren.

Der Agent bindet die Bibliothek dynamisch. Wenn die Bibliothek nicht bereitgestellt wird oder das System sie nicht finden kann, wird die Jobausführung ohne Fehler ausgeführt, aber der Agent kann keine Jobausführungslimits für Benutzer anwenden. In diesem Fall schreibt das System die folgende Meldung in das Agentenlog: "U02003081 - PAM module 'pam_limits.so' was not found, limits for new process will be not set properly." (U02003081 – "pam_limits.so" für das PAM-Modul wurde nicht gefunden. Die Limits für den neuen Prozess werden nicht richtig festgelegt.).

Das System sucht die Bibliothek pam_limit.so in der Umgebungsvariablen LD_LIBRARY_PATH und in den folgenden Verzeichnissen:

• /lib/security

• /lib64/security

• /lib/x86_64-linux-gnu/security

• /usr/lib/x86_64-linux-gnu/security

Wenn die Bibliothek verfügbar ist, legt der Agent die Limits standardmäßig für alle neuen Prozesse fest. Sie können dieses Verhalten unter Verwendung des Parameters use_limits im Abschnitt [PAM] der INI-Datei des Agenten ändern.

Herstellen einer Verbindung zur Automation Engine

Die Automation Engine und die Windows-, UNIX- und Java-Agenten kommunizieren unter Verwendung von TLS/SSL. Diese Agenten richten eine Verbindung zum Java-Kommunikationsprozess (JCP) ein, der vertrauenswürdige Zertifikate verwendet, um ihre Identität gegenüber anderen Kommunikationspartnern nachzuweisen.

Wichtig! Sie sollten mit TLS/SSL und der Zertifikatimplementierung vertraut sein, bevor Sie die entsprechende Komponente installieren bzw. aktualisieren. Weitere Informationen finden Sie hier:

• Hinweise zu TLS/SSL für Automic Automation

• Verbindungen zur AE sichern (TLS/SSL)

Wenn Sie von einer Zertifizierungsstelle signierte Zertifikate verwendet haben, werden die Zertifikate standardmäßig im entsprechenden Java- oder Betriebssystemspeicher gespeichert: dem Java Trust Store für Java-Komponenten und Java-Agenten, dem Windows-Betriebssystemspeicher für Windows-Agenten und dem TLS/SSL-Speicher für UNIX-Agenten. In diesem Fall müssen Sie nur prüfen, ob die Root-Zertifikate bereits im jeweiligen Speicher sind.

Wenn sich die relevanten Zertifikate nicht dort befinden und Sie sie importieren möchten, können Sie für diesen Zweck für das Betriebssystem oder Java spezifische Tools verwenden, wie zum Beispiel Keytool, cert-manager, OpenSSL usw. Weitere Informationen zur Verwendung dieser Tools finden Sie in der entsprechenden Produktdokumentation.

Wenn Sie nicht den Standardspeicherort für die oben aufgeführten Komponenten und Agenten verwenden möchten, stellen Sie sicher, dass Sie die Parameter trustedCertFolder=, agentSecurityFolder= und keyPassword= (falls zutreffend) in der entsprechenden Konfigurationsdatei (INI) verwenden, um den Pfad zum Ordner zu definieren, in dem die vertrauenswürdigen Zertifikate gespeichert sind.

Hinweis: Die TLS/SSL-Implementierung gilt nicht für den HP-UX-Agenten, da er in dieser Version nicht mehr unterstützt wird.

Der Agent sucht in den gängigsten TLS/SSL-Speichern nach Zertifikaten. Wenn Sie keinen Standardspeicherort verwenden, ist es bei UNIX-Agenten außerdem erforderlich, dass Sie die Parameter SSLCertDir= und SSLCertFile= definieren, um die Zertifikate aus dem TLS/SSL-Speicher zu laden.

Standard: SSLCertDir

• /etc/ssl/certs

  Plattformen: Debian/Ubuntu

• /etc/pki/tls/certs

  Plattformen: Fedora/RHEL/CentOS

• /usr/local/share/certs

  Plattformen: FreeBSD

• /etc/openssl/certs

  Platfformen: NetBSD

• /var/ssl/certs

  Plattformen: AIX

• /etc/certs/CA directory

  Plattformen: Solaris

Standard: SSLCertFile

• /etc/ssl/certs/ca-certificates.crt

  Plattformen: Debian/Ubuntu

• /etc/pki/tls/certs/ca-bundle.crt

  Plattformen: Fedora/RHEL 6/CentOS

• /etc/ssl/ca-bundle.pem

  Plattformen: OpenSUSE

• /etc/pki/tls/cacert.pem

  Plattformen: OpenELEC

• /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

  Plattformen: CentOS/RHEL 7

• /etc/ssl/cert.pem

  Plattformen: Alpine Linux

• /etc/certs/ca-certificates.crt

  Plattformen: Solaris

Wenn der Agent keine Zertifikate findet oder die Pfade nicht in Ihrem System existieren, dann kann der Agent keine Verbindung zur Automation Engineherstellen.

Sie können verschiedene Befehle verwenden, um nach den Zertifikaten in Ihrem System zu suchen. Nur ein privilegierter Benutzer, wie beispielsweise Root, kann diese Ordner durchsuchen.

Beispiele – SSL_CERT_DIR

sudo find /etc/ssl/ -name '*DigiCert*'

sudo find /etc/ -name 'DigiCert_Global_Root_CA.pem'

Beispiele – SSL_CERT_FILE

sudo grep -R "DigiCert" /etc/ssl/

sudo grep -R "DigiCert Global Root CA" /etc/

Wichtig! TLS/SSL-Agenten (in Containern und vor Ort) sowie das TLS Gateway, wenn sie für die Automic Automation Kubernetes Edition verwendet werden, stellen eine Verbindung zu einem Ingress-/HTTPS-Load-Balancer her, der zur Authentifizierung ein Zertifikat anfordert.

Stellen Sie sicher, dass die Adresse des Load Balancers auf beiden Seiten definiert ist: in der Automation Engine und auf dem Agenten/TLS Gateway, und dass Ihr HTTPS-Load-Balancer die erforderlichen Zertifikate zur Nutzung besitzt. Weitere Informationen finden Sie unter Eine Verbindung zum AWI, die JCP- und REST-Prozesse über einen Ingress herstellen.

Installieren des Agenten

Führen Sie die folgenden Schritte durch, um den Agenten zu installieren.

1. Übertragen Sie die TAR-Dateien auf den Host und richten Sie die Systemumgebung ein.

   Führen Sie auf dem Host die folgenden Schritte durch:

   1. Registrieren Sie sich mit der AE-Benutzer-ID.

   2. Übertragen Sie die TAR-Datei ucxj???.tar.gz.

   3. Entpacken der TAR-Datei

      gzip -d ucxj???.tar.gz oder gunzip ucxj???.tar.gz

      tar -xvf ucxj???.tar

      (Linux: tar -zxvf ucs???.tar.gz)

      Die entpackten Dateien werden angezeigt. Achten Sie auf TAR-Meldungen und überprüfen Sie, ob alle Dateien korrekt entpackt wurden. Nach dem Entpacken können Sie die TAR-Datei löschen.

      Stellen Sie außerdem sicher, dass AE der Eigentümer aller Dateien ist und dass der Gruppeneintrag dem Wert AE entspricht. Nur ein privilegierter Benutzer, wie beispielsweise Root, kann diese Änderungen vornehmen.

      chown AE * ändert die Eigentümer aller Dateien auf AE.

      chgrp Gruppenname * ändert die Benutzergruppen aller Dateien.

   4. Für den eigentlichen Betrieb können Sie dem Programm ucxj??? die Berechtigungen eines privilegierten Benutzers wie Root erteilt werden.

      chown root ucxj??? ändert "owner" in "root".

      chmod 4755 ucxj??? Setzt das S-Bit (Set-Userid).

   5. Passen Sie die INI-Datei des UNIX-Agenten mit einem Editor wie vi an. Sie können die INI-Datei auch auf dem Admin-Computer bearbeiten und per FTP übertragen. Das Programm ucxj???? und die INI-Datei müssen sich im selben Verzeichnis befinden (siehe Agent Unix).

      TLS und Zertifikate

      1. Wenn Sie von einer Zertifizierungsstelle signierte Zertifikate verwendet haben, werden die Zertifikate standardmäßig im entsprechenden Java- oder Betriebssystemspeicher gespeichert: dem Java Trust Store für Java-Komponenten und Java-Agenten, dem Windows-Betriebssystemspeicher für Windows-Agenten und dem TLS/SSL-Speicher für UNIX-Agenten. In diesem Fall müssen Sie nur prüfen, ob die Root-Zertifikate bereits im jeweiligen Speicher sind.

         Wenn sich die relevanten Zertifikate nicht dort befinden und Sie sie importieren möchten, können Sie für diesen Zweck für das Betriebssystem oder Java spezifische Tools verwenden, wie zum Beispiel Keytool, cert-manager, OpenSSL usw. Weitere Informationen zur Verwendung dieser Tools finden Sie in der entsprechenden Produktdokumentation.

         Wenn Sie nicht den Standardspeicherort für die oben aufgeführten Komponenten und Agenten verwenden möchten, stellen Sie sicher, dass Sie die Parameter trustedCertFolder=, agentSecurityFolder= und keyPassword= (falls zutreffend) in der entsprechenden Konfigurationsdatei (INI) verwenden, um den Pfad zum Ordner zu definieren, in dem die vertrauenswürdigen Zertifikate gespeichert sind.

         Weitere Informationen finden Sie unter Verbindungen zur AE sichern (TLS/SSL).

      2. Wenn Sie die Standardspeicherorte nicht verwenden möchten, ist es für UNIX-Agenten zusätzlich erforderlich, dass Sie die Parameter SSLCertDir= und SSLCertFile= im Abschnitt [AUTHORIZATION] der INI-Datei definieren (siehe Agent Unix), um die Zertifikate aus dem SSL-Speicher zu laden. Die Dateien können entweder in einer Datei pro Zertifikat oder als alle Zertifikate in einer .pem-Datei gespeichert werden.

         • SSLCerDir= Speicherort der vertrauenswürdigen CA-Zertifikate mit jedem Zertifikat in einer separaten Datei, zum Beispiel /etc/ssl/certs/

         • SSLCertFile= Speicherort der .pem-Datei mit allen vertrauenswürdigen CA-Zertifikaten, z. B. /etc/pki/tls/certs/ca-bundle.crt

         Der Agent liest die INI-Datei und verwendet die dort definierten Speicherorte. Wenn sie nicht definiert sind, kann der Agent keine Verbindung herstellen und protokolliert dies entsprechend.

         Sie können verschiedene Befehle verwenden, um nach den Zertifikaten in Ihrem System zu suchen. Nur ein privilegierter Benutzer, wie beispielsweise Root, kann diese Ordner durchsuchen.

         Beispiele – SSL_CERT_DIR

         sudo find /etc/ssl/ -name '*DigiCert*'

         sudo find /etc/ -name 'DigiCert_Global_Root_CA.pem'

         Beispiele – SSL_CERT_FILE

         sudo grep -R "DigiCert" /etc/ssl/

         sudo grep -R "DigiCert Global Root CA" /etc/

      Agenten-Funktionen einschränken

      Im Abschnitt [AUTHORIZATION] der INI-Datei (siehe Agent Unix) können Sie die folgenden Parameter verwenden, um die Agentenfunktionen im Zielsystem einzuschränken:

      • ft_source= Der Agent kann die Quelle einer Dateiübertragung sein.

      • ft_target= Der Agent kann das Ziel einer Dateiübertragung sein.

      • Execute= Der Agent kann Jobs ausführen.

      • CAU_enabled= Der Agent kann mit CAU aktualisiert werden.

      Standardmäßig ist der Agent berechtigt, alle diese Funktionen durchzuführen.

      Berechtigungen

      Sobald der Agent installiert ist, werden beim Starten des Agenten automatisch einige Unterverzeichnisse erstellt. Diese Ordner haben keine Einschränkungen. Sie können den Zugriff auf diese Ordner in der INI-Datei des Agenten einschränken. Weitere Informationen finden Sie unter Agentenvariablen und Ordnerberechtigungen.

      Fork/Batch

      Sie können Jobs entweder mit der Fork-Funktion oder dem Batch-Befehl starten. Verwenden Sie den Parameter start_type= in der INI-Datei des Agenten, um den Wert zu definieren. Abhängig von der Definition gelten die folgenden Regeln für den Agenten:

      • fork: Wenn der Agent mit einer Benutzer-ID mit Root-Rechten gestartet wird, können Jobs unter einer beliebigen Benutzer-ID gestartet werden. Andernfalls müssen Jobs unter der Benutzer-ID ausgeführt werden, die zum Starten des Agenten verwendet wird. Der Agent verwendet execle, um den Job mit minimalen Umgebungseinstellungen zu erzeugen, im Gegensatz zu su -, womit die vollständige Benutzerumgebung geladen wird.

      • batch: Der Agent muss unter einer Benutzer-ID mit Root-Rechten gestartet werden. Um ein unerwartetes oder nicht zuverlässiges Verhalten zu verhindern, sollte su - nicht verwendet werden, weil die vollständige Shell-Umgebung geladen wird.

   Passen Sie auf dem Administrator- oder Servercomputer HEADER.UNIX, TRAILER.UNIX und RESTART.UNIX an, falls erforderlich. Weitere Informationen finden Sie unter Ausführen von Jobs.

2. Konfigurieren Sie optional auf dem Host die PAM-Authentifizierung (Pluggable Authentication Modules). Diese Authentifizierung wird für die UNIX-Plattform-Agenten Solaris, Linux und AIX unterstützt.

   • Installation der PAM-Bibliothek

     Die PAM-Bibliothek muss auf Ihrem System installiert sein (abhängig von der verwendeten Plattform).

   • Konfiguration der PAM-Bibliothek

     Der Konfigurationsprozess hängt von der von Ihnen verwendeten UNIX-Plattform ab. Normalerweise verwenden Sie dazu die Dateien /etc/pam.d oder /etc/pam.conf. Der Name des Service entspricht dem Namen der ausführbaren Agenten-Datei (ucxj???).

   • Agenten-Konfiguration

     Setzen Sie in der INI-Datei des Agenten den Parameter authentication= im Abschnitt [MISC] auf pam.

     [MISC] authentication=pam

3. Starten Sie den Agenten. Stellen Sie sicher, dass AE ausgeführt wird. Weitere Informationen finden Sie unter Multi-Server-Betrieb.

   Folgende Optionen stehen zur Verfügung:

   • Agenten-Launcher über die Kommandozeile aufrufen

   • Über das Windows-Startmenü. Öffnen Sie dazu das Startmenü, navigieren Sie zum Ordner Automic und klicken Sie auf den Windows-Agenten.

   • Mit dem ServiceManager

   Über die Kommandozeile oder bei Verwendung von ServiceManager können Sie die folgenden Parameter übergeben:

   • -i<ini-file>: Startet den Agenten mit einer bestimmten INI-Datei.

   • -svc%port%: Wenn angegeben, zeigt der ServiceManager den Verbindungsstatus zusammen mit dem Agentennamen an.

     Beispiele für Service Manager

     ucxjlx6 -svc%port% -Ic:\Agent\Agent-Unix.ini

     ucxjlpl -svc%port% -Ic:\Agent\Agent-Unix.ini

     ucxja64 -svc%port% -Ic:\Agent\Agent-Unix.ini

     Hinweis: Der Parameter -svc sollte weggelassen werden, wenn Sie direkt über die Kommandozeile starten.

   • --console: Ermöglicht es Ihnen, Probleme während der Startphase des Agenten zu erkennen. Die Ausgabe wird im Fenster der Windows-Kommandozeile angezeigt.

     Beispiele für die CLI

     ucxjlx6 --console

     ucxjlpl --console

     ucxja64 --console

   • --vm:<JRE Location> Ermöglicht Ihnen die Angabe der Java-Installation, die der Agent verwenden soll. Der hier angegebene Pfad sollte auf das Verzeichnis verweisen, in dem Java installiert ist, z. B. durch die Variable $JAVA_HOME.

     Beispiel

     Dieses Beispiel startet den Agenten mithilfe der Java-Installation im Verzeichnis /usr/lib/jvm/java-17-openjdk-amd64.

     /ucxjlx6 -vm:/usr/lib/jvm/java-21-openjdk-amd64

   Unabhängig von der Option, die Sie verwenden, um den Agenten zu starten, wird automatisch ein Agentenobjekt in Mandant 0 erstellt und im Ordner HOST gespeichert. Sie können Zugriffsberechtigungen für diese Ordner konfigurieren. Weitere Informationen finden Sie unter Agentenvariablen und Ordnerberechtigungen.

   Vergewissern Sie sich in AWI, Mandant 0, dass der Agent bei der Automation Engine angemeldet ist.

   Neu eingeloggte Agenten werden einem Mandanten nicht automatisch zugewiesen und können nur in Mandant 0 angezeigt werden. Sobald Sie sich bei Mandant 0 eingeloggt haben, greifen Sie auf die Administration-Perspektive zu und wählen Sie Agenten und Gruppen aus.

   Sie können den neuen Agenten nun über die Agentenobjektdefinition Mandanten mit den erforderlichen Rechten zuordnen. Weitere Informationen finden Sie auf der Seite Definieren der Seite "Berechtigungen".

Agent herunterfahren

Sie können den ServiceManager nicht nur verwenden, um den Agenten als Dienst zu starten, sondern auch, um ihn zu beenden. Weitere Informationen finden Sie unter ServiceManager.

Alternativ können Sie den Agenten über eine der folgenden Optionen herunterfahren:

• Agent normal beenden: kill -TERM pid.

• In AWI: Klicken Sie im Abschnitt Agenten der Administration-Perspektive mit der rechten Maustaste auf den Agenten und wählen Sie Stop aus.

• Den Agenten in Notfällen abbrechen (Netzwerkverbindungen sind nicht ordnungsgemäß geschlossen): kill -KILL pid oder kill -9 pid

Siehe auch:

• Agenten installieren
• Agent Unix
• Installieren des Agenten auf anderen UNIX-Plattformen