Nous dépannons une défaillance WebGISDR dans un déploiement ArcGIS Enterprise 11.5 sur Linux et avons isolé le problème au serveur fédéré ArcGIS Notebook Server exportSite opération.
WebGISDR reçoit HTTP 500 lors de l'exportation du Notebook Server. Nous avons reproduit le problème indépendamment de WebGISDR en effectuant une requête authentifiée directement à l'API Admin exportSite du Notebook Server :
POST /notebooks/admin/exportSite
L'opération retourne systématiquement :
HTTP 500 - Échec de l'opération d'exportation. null
Avec la journalisation DEBUG temporaire activée, le Notebook Server réussit à :
- démarrer l'opération d'exportation ;
- créer
/opt/arcgis/notebookserver/temp/tmp-carbon-export-* ; - créer le magasin de configuration temporaire ;
- mettre à jour les propriétés système de l'API Admin ; et
- copier la configuration du site dans le magasin de configuration temporaire.
Immédiatement après, l'exportation échoue avec :
java.lang.NullPointerException
at java.util.Objects.requireNonNull(...)
at sun.nio.fs.UnixFileSystem.getPath(...)
at java.nio.file.Path.of(...)
at java.nio.file.Paths.get(...)
at com.esri.arcgis.carbon.common.FileUtil.copyFile(FileUtil.java:652)
at com.esri.arcgis.carbon.admin.SiteManager.exportSite(SiteManager.java:2027)
at com.esri.arcgis.carbon.admin.rest.site.SiteResource.exportSite(SiteResource.java:329)
Nous avons capturé le répertoire temporaire tmp-carbon-export-* avant que le Notebook Server ne le supprime. Il contient backupRestoreInfo.json et le magasin de configuration substantiel du Notebook Server, incluant la configuration machine, les répertoires serveur, les définitions/manifests d'exécution des notebooks, la configuration de sécurité, la configuration du Web Adaptor, le keystore des certificats et les métadonnées des conteneurs.
La comparaison entre le magasin de configuration en direct et celui capturé lors de l'export n'a montré que les fichiers attendus .lock omis ; aucun fichier de configuration substantiel n'était manquant.
Nous avons également testé si le problème était lié au fait qu'il s'agisse d'un Notebook Server nouvellement déployé/non utilisé auparavant. Un notebook Standard a été créé, sauvegardé et exécuté avec succès. Cela a initialisé un conteneur Notebook en cours d'exécution, des artefacts d'espace de travail et peuplé les enregistrements des tâches système du Notebook Server.
Comme test fonctionnel supplémentaire, le notebook a exécuté avec succès du code ArcGIS API for Python utilisant :
from arcgis.gis import GIS
gis = GIS("home")
print("Connecté à :", gis.properties.name)
print("URL du portail :", gis.url)
print("Connecté en tant que :", gis.users.me.username)
print("Version du portail :", gis.properties.currentVersion)
Le notebook s'est authentifié avec succès auprès du portail fédéré et a retourné :
Connecté à : ArcGIS Enterprise
URL du portail : https://gis.xyz.com/portal
Connecté en tant que : siteadmin
Version du portail : 2025.1
Cela confirme que l'exécution normale du conteneur Notebook Server, l'exécution de l'ArcGIS API for Python, l'authentification au portail et la communication avec le portail fédéré fonctionnent correctement.
Après avoir créé, sauvegardé et exécuté le notebook, nous avons testé à nouveau l'opération directe exportSite du Notebook Server. Elle échoue toujours de manière identique avec :
HTTP 500 - Échec de l'opération d'exportation. null
Par conséquent, l'échec ne semble pas être causé par l'absence de notebooks utilisateur, un manque d'initialisation au premier usage, une incapacité à démarrer les conteneurs Notebook ou une incapacité des notebooks à communiquer avec le portail.
Nous avons également validé :
- fédération/configuration Portal 14 Notebook Server
- connectivité URL Portal configurée 14 Notebook Server
- connectivité TLS
- démarrage et exécution réussis du conteneur Notebook
- exécution réussie de l'ArcGIS API for Python et authentification au portail
- répertoires et chemins enregistrés du Notebook Server
- permissions système de fichiers et espace disque disponible
- artefacts certificat/keystore du Notebook Server
- création et utilisation du répertoire temporaire d'exportation
- création réussie de
backupRestoreInfo.json - copie réussie du magasin de configuration substantiel du Notebook Server
L'échec semble donc se produire après que la configuration du site ait été copiée, lorsque SiteManager.exportSite()'appelle FileUtil.copyFile()' avec ce qui semble être un chemin nul.
Questions :
- 'S'agit-il d'un problème connu d'ArcGIS Notebook Server 11.5
'exportSite',' ?',' field 83':'Quel fichier ou artefact supplémentaire ',' field 84':'SiteManager.exportSite()',' tente-t-il de copier à ce stade de l'exportation ?',' field 85':'Existe-t-il un moyen pris en charge pour déterminer quel chemin source passé à ',' field 86':'FileUtil.copyFile()',' est nul ?',' field 87':'Existe-t-il un correctif ou une solution prise en charge pour ce problème ?',' field 88':'Environnement :',' field 89':' ArcGIS Enterprise 11.5, ArcGIS Notebook Server 11.5, Linux, serveur Notebook fédéré.'}}} issue? - What additional file or artifact does
SiteManager.exportSite() attempt to copy at this stage of the export? - Is there a supported way to determine which source path passed to
FileUtil.copyFile() is null? - Is there a patch or supported workaround for this issue?
Environment: ArcGIS Enterprise 11.5, ArcGIS Notebook Server 11.5, Linux, federated Notebook Server.
