Cette page a été traduite par l'API Cloud Translation.

4.19.06.10 - Notes de version d'Edge for Private Cloud

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Le 29 septembre 2020, nous avons lancé une nouvelle version d'Apigee Edge pour Private Cloud.

Mettre à jour la procédure

La mise à jour de cette version entraînera la mise à jour des composants répertoriés dans la liste suivante RPM:

edge-gateway-4.19.06-0.0.20094.noarch.rpm
edge-management-server-4.19.06-0.0.20094.noarch.rpm
edge-message-processor-4.19.06-0.0.20094.noarch.rpm
edge-postgres-server-4.19.06-0.0.20094.noarch.rpm
edge-qpid-server-4.19.06-0.0.20094.noarch.rpm
edge-router-4.19.06-0.0.20094.noarch.rpm
apigee-mtls-4.19.06-0.0.20189.noarch.rpm
apigee-mtls-consul-4.19.06-0.0.20128.noarch.rpm
apigee-cassandra-2.1.16-0.0.2508.noarch.rpm
edge-ui-4.19.06-0.0.20164.noarch.rpm
edge-management-ui-static-4.19.06-0.0.20018.noarch.rpm
apigee-sso-4.19.06-0.0.20080.noarch.rpm
apigee-setup-4.19.06-0.0.1122.noarch.rpm

Vous pouvez vérifier les versions de RPM actuellement installées à mettre à jour, en saisissant:

apigee-all version

Pour mettre à jour votre installation, procédez comme suit sur les nœuds périphériques:

Sur tous les nœuds périphériques:
1. Nettoyez les dépôts Yum:
```
sudo yum clean all
```
2. Téléchargez le dernier fichier bootstrap_4.19.06.sh Edge 4.19.06 pour /tmp/bootstrap_4.19.06.sh:
```
curl https://software.apigee.com/bootstrap_4.19.06.sh -o /tmp/bootstrap_4.19.06.sh
```
3. Installez l'utilitaire Edge 4.19.06 apigee-service et les dépendances:
```
sudo bash /tmp/bootstrap_4.19.06.sh apigeeuser=uName apigeepassword=pWord
```
  Où uName:pWord correspond au nom d'utilisateur et au mot de passe que vous avez reçus d'Apigee. Si vous omettez pWord, vous serez invité à le faire.
4. Mettez à jour l'utilitaire apigee-setup:
```
sudo /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
5. Utilisez la commande source pour exécuter le script apigee-service.sh:
```
source /etc/profile.d/apigee-service.sh
```
Mettez à jour tous les nœuds Cassandra:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
où configFile spécifie le fichier de configuration que vous avez utilisé pour installer Apigee Edge pour le cloud privé. Exemple :/opt/silent.conf
Sur tous les nœuds périphériques, exécutez le script update.sh pour edge processus. Pour ce faire, exécutez la commande suivante sur chaque nœud:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Mettre à jour l'interface utilisateur Edge:

/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile

Exécutez le script update.sh pour activer l'authentification unique sur tous les nœuds. Sur chaque nœud, exécutez la commande la commande suivante:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
```
Si vous utilisez la nouvelle expérience Edge, exécutez la commande suivante:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Si vous utilisez Apigee mTLS, suivez la procédure décrite dans Mettez à niveau Apigee mTLS.
Pour plus d'informations, voir Présentation d'Apigee mTLS

Logiciels compatibles

Aucune modification.

Abandons et suppressions

Pas de nouveaux abandons ni de suppressions.

Nouvelles fonctionnalités

Cette section répertorie les nouvelles fonctionnalités de cette version.

Chiffrer des mots de passe JMX

Vous pouvez désormais chiffrer les mots de passe JMX. Voir <ph type="x-smartling-placeholder"></ph> Activer le chiffrement des mots de passe JMX <ph type="x-smartling-placeholder"></ph> Pour en savoir plus, activez l'authentification JMX pour Cassandra. (150633039)

Bugs résolus

Le tableau suivant répertorie les bugs résolus dans cette version:

ID du problème	Description
159360654	Les certificats apigee-mtls n'étaient valides que pendant 30 jours. Les nouveaux certificats sont désormais valables un an. Pour mettre à niveau un ancien certificat de 30 jours avec un nouveau certificat, valable un an, voir Mettez à niveau Apigee MTLS.
147736003	Une bibliothèque obsolète sur enterprise.apigee.com provoquait la sécurité les problèmes de performances. La bibliothèque a été mise à jour.
150594487	Un ensemble de ressources Java au niveau de l'organisation entraînait l'échec des processeurs de messages pour charger les organisations.
149739904	Masquage des données pour les en-têtes HTTP était sensible à la casse. Ce problème a été corrigé: le masquage des données n'est plus sensible à la casse.
130416715	Faille potentielle due à "True-Client-IP" en-tête Cette version introduit un nouvel élément de stratégie de contrôle d'accès, `IgnoreTrueClientIPHeader`, qui résout le problème. Voir <ph type="x-smartling-placeholder"></ph> Élément IgnoreTrueClientIPHeader.
161858295	Certaines variables silencieuses ont été mal orthographiées. Variable d'installation silencieuse `SSO_JWT_SIGNING_KEY_FILEPATH` n'est plus mal orthographiée.
160951701	L'installation de mTLS échouait en raison d'un problème avec le serveur Consul. Le binaire Consul a été mis à niveau de la version 1.6.2 vers la dernière version stable, v1.8.0.
132654321	Les journaux d'audit n'affichaient pas les utilisateurs dont les rôles ont été mis à jour. Après avoir modifié les rôles d'utilisateurs existants ou ajouté un utilisateur existant à une organisation, le journal d'audit affiche "Update user undefined" ce qui empêchait de voir sur qui l'action a été effectuée.
160916451	L'installation de mTLS échouait en raison d'une version obsolète du binaire Consul. Le binaire Consul a été mis à niveau de la version 1.6.2 vers la dernière version version stable, v1.8.0. apigee-mtls gère désormais correctement les serveurs avec plusieurs interfaces réseau et des adresses IP externes.
161764596	apigee-tomcat n'était pas mis à jour lors de l'application de mises à jour de correctifs. Ce problème a été résolu.
133145969	La documentation sur la désactivation des protocoles dans l'interface utilisateur était manquante. Pour obtenir une nouvelle documentation, consultez <ph type="x-smartling-placeholder"></ph> Désactiver les protocoles TLS

Problèmes connus

Le tableau suivant répertorie les problèmes connus de cette version:

ID du problème Description

149245401

ID du problème	Description
149245401	Problème de pooling des connexions avec la règle LDAP Paramètres du pool de connexions LDAP configurés pour JNDI via la Ressource LDAP ne sont pas reflétés, et les valeurs par défaut de JNDI entraînent des connexions à usage unique à chaque fois. Par conséquent, des connexions sont ouvertes et fermé à chaque fois pour un usage unique, créant ainsi un grand nombre connexions par heure au serveur LDAP. Solution : Pour modifier les propriétés du pool de connexions LDAP, Procédez comme suit pour définir une modification globale pour toutes les règles LDAP. Créer un fichier de propriétés de configuration s'il n'existe pas encore: /opt/apigee/customer/application/message-processor.properties Ajoutez le code suivant au fichier (remplacez les valeurs de Propriétés JNDI (Java Naming and Directory Interface) en fonction des besoins de configuration des ressources LDAP). bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20 -Dcom.sun.jndi.ldap.connect.pool.prefsize=2 -Dcom.sun.jndi.ldap.connect.pool.initsize=2 -Dcom.sun.jndi.ldap.connect.pool.timeout=120000 -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl" Assurez-vous que le fichier `/opt/apigee/customer/application/message-processor.properties` correspond à appartenant à apigee:apigee. Redémarrez chaque processeur de messages. Pour vérifier que votre pool de connexions JNDI les propriétés de Google Cloud sont prises en compte, effectuer une commande tcpdump pour observer le comportement du pool de connexions LDAP au fil du temps. Remarque: Propriétés du pool de connexions spécifiées par la procédure ci-dessus sont mondiaux, tout comme applicable à toutes les connexions LDAP utilisant un pool de connexions Le processeur de messages s'installe.

Problème de pooling des connexions avec la règle LDAP

Paramètres du pool de connexions LDAP configurés pour JNDI via la Ressource LDAP ne sont pas reflétés, et les valeurs par défaut de JNDI entraînent des connexions à usage unique à chaque fois. Par conséquent, des connexions sont ouvertes et fermé à chaque fois pour un usage unique, créant ainsi un grand nombre connexions par heure au serveur LDAP.

Solution :

Pour modifier les propriétés du pool de connexions LDAP, Procédez comme suit pour définir une modification globale pour toutes les règles LDAP.

Créer un fichier de propriétés de configuration s'il n'existe pas encore:
```
/opt/apigee/customer/application/message-processor.properties
```

Ajoutez le code suivant au fichier (remplacez les valeurs de Propriétés JNDI (Java Naming and Directory Interface) en fonction des besoins de configuration des ressources LDAP).

bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
-Dcom.sun.jndi.ldap.connect.pool.prefsize=2
-Dcom.sun.jndi.ldap.connect.pool.initsize=2
-Dcom.sun.jndi.ldap.connect.pool.timeout=120000
-Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

Assurez-vous que le fichier /opt/apigee/customer/application/message-processor.properties correspond à appartenant à apigee:apigee.
Redémarrez chaque processeur de messages.

Pour vérifier que votre pool de connexions JNDI les propriétés de Google Cloud sont prises en compte, effectuer une commande tcpdump pour observer le comportement du pool de connexions LDAP au fil du temps.

4.19.06.11

4.19.06.09