Installieren des Agenten für Linux (x64) (Java)

Wichtig! Diese Installationsanweisungen gelten nur für die Installation von Java-basierten Agenten für Linux (x64). Installationsanweisungen für andere UNIX-Agenten finden Sie unter Installieren des Agenten auf anderen UNIX-Plattformen.

Diese Seite führt Sie durch die Installation eines Java-basierten Agenten für Linux (x64) 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 Agenten-Authentifizierung.

Sehen Sie sich die compatibility matrix an, 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.

Sehen Sie sich das Video an: UNIX-Agenten installieren

Übersicht

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).

Der Agent für Linux (x64) unterstützt 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.

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 die Bibliotheken nicht richtig installiert werden, wird die jeweilige Komponente nicht ordnungsgemäß starten. Deshalb müssen Sie sicherstellen, dass alle Standardbibliotheken verfügbar sind, damit der Agent, das Dienstprogramm und/oder der ServiceManager sie verwenden kann.

Navigieren Sie dazu zum Angebots-Bundle und rufen Sie die Bibliotheken libstdc++.so.6 und libgcc_s.so.1 ab. Sobald Sie den TAR-Ball (unix_libraries.tar.gz) entpackt haben, können Sie die Bibliotheken, die Sie aus dem Bundle heruntergeladen haben, in das Verzeichnis "bin" der jeweiligen Komponente kopieren. Dann können Sie das Kommando ln -s ./libstdc++.so.6 verwenden, um symbolische Verknüpfungen im Verzeichnis "bin" zu erstellen.

Privilegierter/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

   • chown root ucxjlx6

   • chgrp admin ucxjlx6

   • chmod 4755 ucxjlx6

   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 (./ucxjlx6) unter Verwendung des Sticky-Bits gestartet (UID = 0).

     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 systemeigenen Launcher (./ucxjlx6) gestartet, ohne Sticky-Bit.

     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.

   • Regel 3: Der Agent wird mit java -jar gestartet.

     In diesem Fall ist das Verhalten das gleiche wie in Regel 2.

   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.

Wofür werden Root-Rechte benötigt?

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?

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-Agent ausführen, können Sie die Berechtigungen für die Agenten-spezifischen Unterverzeichnisse in der INI-Datei des Agenten konfigurieren.

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.

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

Weitere Informationen finden Sie hier:

• Liste der Agentenvariablen

• Agent Unix – INI-Datei

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=

...

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 keine Anmeldung angegeben ist, geht das System davon aus, dass der nachfolgende Ereignisjob mit Agentenrechten 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 möglich, da der Ereignis-Job das Login auch dynamisch (mit der Script-Anweisung PUT_ATT) angeben könnte.

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.

Eine Verbindung zur Automation Engine herstellen

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

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

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

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 der 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. Beachten Sie alle TAR-Meldungen und überprüfen Sie, ob alle Dateien korrekt entpackt sind. Sie können die TAR-Datei nach dem Entpacken löschen.

        Stellen Sie sicher, dass alle Dateien den richtigen Eigentümer und Gruppeneintrag haben. AE muss der Eigentümer sein. Die Gruppe muss mit dem Code übereinstimmen, AE. 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.

        • Eigentümer in Root ändern

          chown root ucxj???

        • S-Bit setzen (Set-Userid)

          chmod 4755 ucxj???

     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 gleichen Verzeichnis befinden(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. In diesem Fall müssen Sie nur prüfen, ob die Root-Zertifikate bereits im jeweiligen Speicher sind.

           Wenn Sie nicht den Standardspeicherort für diese Komponente 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 des Agenten (siehe Agent Unix) definieren, 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 Agent-Funktionen 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 Jobs ausführen.

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. Verwenden Sie den Parameter libname= im Abschnitt [PAM], um den Pfad und den Dateinamen der PAM-Bibliothek anzugeben:

     [MISC]
     authentication=pam
     [PAM]
     libname=/usr/lib/libpam.so

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

   Es gibt verschiedene Optionen, um den Agenten zu starten:

   • (Empfohlen) Im Hintergrund über das Verzeichnis $HOME/bin (./ucxjlx6).

     Hinweis: Wenn Sie den Agenten zum Testen im Dialogfeld starten, ist das Beenden mit der Taste ENTF nur ab Version 1.20 möglich, und wenn der entsprechende Parameter in der INI-Datei definiert wurde. Setzen Sie diesen Parameter nicht, sondern beenden Sie ihn von einem anderen Terminal aus mit dem kill -TERM.

     Wenn das Verzeichnis $HOME/bin in der Systemumgebung PATH festgelegt ist, geben Sie den folgenden Befehl ein:

     nohup ucxj???1> ucxj???.log 2>&1 &

     Wenn das Verzeichnis $HOME/bin nicht in der Systemumgebung PATH festgelegt wurde,, geben Sie die folgenden Befehle ein:

     nohup ./ucxj???1> ucxj???.log 2>&1 &

     Sie können auch andere Kommandos verwenden, beispielsweise:

     • pid, um die angezeigte Prozess-ID zu sehen

     • ps -ppid für Informationen über den Prozess (nicht immer verfügbar)

     • ps -ef | grep ucx für Informationen über alle UCX-Prozesse

     • ps -e für Informationen über alle Prozesse

   • Als Java-Anwendung mit dem folgenden Kommando:

     java -jar ucxjoss.jar

     Das System sucht zuerst in der Umgebungsvariablen JAVA_HOME. Falls sie nicht festgelegt ist, sucht es in der Umgebungsvariablen JAVA_PATH nach der ausführbaren Java-Datei.

     Optional können Sie für zusätzliche Optimierung oder zu Diagnosezwecken auch andere Parameter (z. B. -Xverbose oder -Xloggc) direkt an die Java-VM übergeben.

   • Mit dem ServiceManager. Sie können ./ucxjlx6 oder java -jar ucxjoss.jar über die Kommandozeile verwenden, um den Agenten zu starten und verschiedene Parameter zu übergeben:

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

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

       Beispiel für Service Manager

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

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

     • -v: Gibt die Version des Agenten in der Ausgabe aus.

       Beispiel für CLI

       java -jar ucxjoss.jar -v

   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 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 - INI-Datei
• Installieren des Agenten auf anderen UNIX-Plattformen