L’équipe support joue un rôle essentiel, car elle constitue le point de contact principal entre l’entreprise et ses clients.
Sa mission ne se limite pas à résoudre les problèmes techniques. Une équipe support efficace permet ainsi d’assurer la continuité des services, de renforcer la confiance des clients et de soutenir la croissance de l’entreprise.
C’est pourquoi on a décidé de vous faire un TOP 7 des demandes les plus courantes avec notre équipe support concernant la solution de transferts de fichiers GoAnywhere MFT.
1. Erreur de configuration de la police d’écriture
java.lang.reflect.InvocationTargetException
at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:86)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
at java.desktop/java.awt.Font.getFont2D(Font.java:497)
Vous voyez ce message apparaitre ?
Cette erreur indique que votre environnement d’exécution Java (Java Runtime Environment) n’est pas configuré correctement pour gérer les polices. Java ne fournit plus de configurations de polices pour Linux et Solaris. Ces systèmes d’exploitation doivent avoir les bibliothèques de polices installées, et Java doit être activé pour détecter et utiliser ces polices.
Comment résoudre cette erreur ?
Suivez les étapes ci-dessous pour permettre à Java de détecter et d’utiliser les polices :
- Installez Freetype et Fontconfig.
- Installez des paquets de polices pris en charge. DejaVu est une famille de polices incluse dans la plupart des distributions Linux et Solaris.
Si vous avez un environnement de bureau installé sur votre système, ces paquets devraient déjà être présents. Utilisez les commandes suivantes pour installer les paquets :
-
-
Debian/Ubuntu/Mint: apt-get install libfreetype6 fontconfig fonts-dejavu -
RHEL/CentOS/Fedora: yum install freetype fontconfig dejavu-sans-fonts -
SLES/OpenSUSE: zypper install libfreetype6 fontconfig dejavu-fonts -
Solaris: pkg install system/library/freetype-2 and pkg install font/truetype/dejavu
-
2. Échec de connexion en mode passif via FTP ou FTPS après la mise à jour vers la version 7.4
Par mesure de sécurité, l’adresse de données fournie dans la réponse passive n’est plus considérée comme FIABLE par défaut. Par conséquent, GoAnywhere utilisera l’adresse de contrôle pour créer le canal de données.
Comment résoudre cette erreur ?
Pour faire confiance aux adresses dans une réponse passive, définissez la propriété suivante dans le fichier de configuration de GoAnywhere :
org.apache.commons.net.ftp.ipAddressFromPasvResponse=true
Chemin : [répertoire_d'installation]/config/system.properties.
Cela nécessite un redémarrage de GoAnywhere.
3. Échec de la construction du chemin PKIX
PKIX path building failed: java.security.cert.CertPathBuilderException: unable to find valid certification path to requested target
Cette erreur « PKIX path building failed » se produit lorsque GoAnywhere rencontre un certificat SSL qu’il ne considère pas comme fiable.
Comment résoudre cette erreur ?
Pour corriger cette exception, suivez les instructions suivantes :
- Obtenez le certificat racine ainsi que le certificat de l’autorité de certification intermédiaire (CA), si nécessaire, depuis l’hôte auquel vous tentez de vous connecter.
- Importez les certificats dans le Key Vault système de GoAnywhere. Pour plus d’informations sur l’importation d’un certificat, consultez la section Gestion des certificats.
4. Impossible de rejoindre le cluster : le système ‘systemname’ possède déjà un enregistrement dans la table des systèmes actifs
Impossible de rejoindre le cluster : le système ‘systemname’ possède déjà un enregistrement dans la table des systèmes actifs et semble être actif.
Les causes les plus fréquentes de cette erreur sont les suivantes :
- Le même nom de système est défini dans le fichier cluster.xml pour deux nœuds (ou plus) de GoAnywhere.
- Le nom du système est toujours présent dans la table dpa_active_system de la base de données. Cela peut se produire si le système a été arrêté de manière inattendue et que le nœud n’a pas pu envoyer les commandes d’arrêt appropriées à la base de données. Par exemple, un redémarrage brutal du serveur GoAnywhere.
Comment résoudre cette erreur ?
- Pour résoudre cette exception dans le premier cas, renommez votre fichier cluster.xml avec un nom unique. Il est recommandé de choisir un nom facilement identifiable, comme un nom DNS.
- Pour résoudre cette exception dans le deuxième cas, assurez-vous que chaque nœud peut atteindre les autres nœuds sur le port de liaison du cluster, tel que défini dans le fichier cluster.xml. Une façon de le tester est d’utiliser la commande telnet d’un nœud vers le port de liaison de l’autre nœud du cluster.
- Pour résoudre cette exception dans le troisième cas, vous devrez consulter votre administrateur de base de données afin de supprimer la ligne correspondant au système inactif.
5. Les connexions SQL Server échouent après la mise à niveau vers GoAnywhere 7.7.0
Des connexions SQL Server qui fonctionnaient auparavant (vers la base de données principale, des ressources ou des tâches de projet) échouent désormais.
Comment résoudre cette erreur ?
Le pilote JDBC SQL Server a été mis à jour vers la version 12.8 dans GoAnywhere 7.7.0.
La propriété de connexion encrypt est désormais définie par défaut sur true lors de la connexion à une base de données SQL Server, que ce soit pour la base de données principale de GoAnywhere, une ressource ou une tâche de projet.
Si le certificat de la base de données SQL Server n’est pas présent dans le KMS (ou dans le magasin de confiance cacerts du JVM), la connexion échouera.
Deux solutions possibles :
- Ajouter encrypt=false à l’URL de connexion
- Ou importer le certificat de la base de données SQL Server dans le KMS
6. Erreur « End of IO Stream Read » lors d’un échange via SFTP
Ce problème est directement lié à la mise à niveau vers la version 7.7.0.
Dans cette version, deux nouveaux algorithmes ont été ajoutés pour les ressources SFTP :
-
curve25519 256 bits -
curve25519-sha256@libssh.org (algorithmes d’échange de clés)
Le problème est que ces deux algorithmes peuvent ne pas être pris en charge par certains serveurs SFTP.
Comment résoudre cette erreur ?
La solution, dans ce cas, est de les désactiver sur les ressources concernées.
Pour cela, accédez à la ressource, allez dans l’onglet Algorithmes, puis modifiez la section Échange de clés (Key Exchange).
Vous pouvez l’adapter si vous avez déjà désactivé certains algorithmes.
L’objectif est d’avoir ces deux-là dans la colonne de gauche.
7. Message d’erreur “Invalid privatekey”
Ce type d’erreur est typique d’un problème de format de votre clé.
Le format actuel de cette clé peut être supporté par le KMS, vous pouvez donc l’importer, mais pas par la ressource, d’où l’erreur.
Ces deux modules utilisent des bibliothèques Java différentes.
Comment résoudre cette erreur ?
Pour éviter cela, vous devez toujours convertir votre clé au format « pem » avant de l’importer dans GoAnywhere.
Vous pouvez utiliser différents outils pour cela.
Par exemple, vous pouvez utiliser la commande suivante :
ssh-keygen -p -f [votre clé privée] -m pem
Importez ensuite la clé convertie et modifiez votre ressource.
