ECS : Utilisation de la commande curl de l’API
Summary: Comment utiliser la commande curl de l’API (Application Programming Interface) avec des exemples GET et PUT.
Instructions
Cet article de la base de connaissances montre comment utiliser les commandes curl pour l’utilisation de l’API ECS.
Des exemples d’utilisation de l’API avec des commandes curl sont proposés dans les guides de l’utilisateur tels que le Guide d’administration d’ECS ou le Guide d’accès aux données.
Cette section montre comment utiliser la commande curl pour GET et PUT sur une API. Dans cet exemple, l’API de certificat LDAPS par KB ECS : Comment configurer et accepter tous les certificats sur LDAPS sur ECS.
Exemple de curl : exemple d’API de certificat LDAPS :
L’API de certificats LDAPS utilise l’adresse IP de gestion et n’autorise pas l’accès à emcmonitor, mais l’utilisateur root. Voici un exemple d’utilisation de l’API ECS. L’API de certificat LDAPS se trouve dans le "/vdc/truststore". Votre API peut être différente et se trouver à un autre emplacement.
Pour examiner les paramètres ECS concernant les paramètres de certificat LDAPS, commencez par obtenir une adresse IP de gestion des nœuds à utiliser. S’il existe une séparation réseau pour la gestion de l’interface utilisateur, le message «getrackinfo -n« a des valeurs « mgmt ». Utilisez l’adresse IP public.mgmt des nœuds, la réplication et la séparation du réseau de données ne sont pas nécessaires pour ces étapes :
# getrackinfo -n Named networks ============== Node ID Network Ip Address Netmask Gateway VLAN Interface 1 repl 10.xxx.xxx.11 255.255.254.0 xxx.xxx.xxx.xxx 14 public 1 mgmt 10.xxx.xxx.21 255.255.254.0 xxx.xxx.xxx.xxx 13 public 1 data 10.xxx.xxx.31 255.255.254.0 xxx.xxx.xxx.xxx 15 public 2 repl 10.xxx.xxx.12 255.255.254.0 xxx.xxx.xxx.xxx 14 public 2 mgmt 10.xxx.xxx.22 255.255.254.0 xxx.xxx.xxx.xxx 13 public 2 data 10.xxx.xxx.32 255.255.254.0 xxx.xxx.xxx.xxx 15 public 3 repl 10.xxx.xxx.13 255.255.254.0 xxx.xxx.xxx.xxx 14 public 3 mgmt 10.xxx.xxx.23 255.255.254.0 xxx.xxx.xxx.xxx 13 public 3 data 10.xxx.xxx.33 255.255.254.0 xxx.xxx.xxx.xxx 15 public 4 repl 10.xxx.xxx.14 255.255.254.0 xxx.xxx.xxx.xxx 14 public 4 mgmt 10.xxx.xxx.24 255.255.254.0 xxx.xxx.xxx.xxx 13 public 4 data 10.xxx.xxx.34 255.255.254.0 xxx.xxx.xxx.xxx 15 public
S’il n’existe aucune séparation public.mgmt du réseau sur le VDC, utilisez plutôt l’adresse IP publique du nœud. Notez que l’adresse de séparation réseau public.mgmt est prioritaire si elle est définie.
# getrackinfo Node private Node Public BMC Ip Address Id Status Mac Ip Address Mac Ip Address Node Name =============== ====== ====== ================= ================= ================= ================= ========= 192.1XX.2XX.1 1 MA a4:bf:xx:xx:xx:74 10.xx.xx.1 a4:bf:xx:xx:xx 192.1XX.2XX.101 provo-red 192.1XX.2XX.2 2 SA a4:bf:xx:xx:xx:c8 10.xx.xx.2 a4:bf:xx:xx:xx 192.1XX.2XX.102 sandy-red 192.1XX.2XX.3 3 SA a4:bf:xx:xx:xx:e0 10.xx.xx.3 a4:bf:xx:xx:xx 192.1XX.2XX.103 orem-red 192.1XX.2XX.4 4 SA a4:bf:xx:xx:xx:56 10.xx.xx.4 a4:bf:xx:xx:xx 192.168.219.104 ogden-red
Utilisez l’adresse IP de gestion acquise pour obtenir le jeton de l’utilisateur root, le mot de passe de l’utilisateur root est requis :
# curl -s -k -v -u root https://<NodeManagementIP>:4443/login 2>&1
Exemple :
# curl -s -k -v -u root https://10.xxx.xxx.21:4443/login 2>&1 Enter host password for user 'root': ...... < HTTP/1.1 200 OK < Date: Thu, 14 Jan 2021 13:51:24 GMT < Content-Type: application/xml < Content-Length: 93 < Connection: keep-alive < X-SDS-AUTH-TOKEN: BAAcdWhGbnVRVjd1WlpmR0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxAgAC0A8= < X-SDS-AUTH-USERNAME: root < X-SDS-AUTH-MAX-AGE: 28800 < * Connection #0 to host 10.xxx.xxx.21 left intact root
Si le résultat n’est pas « HTTP/1.1 200 OK », vérifiez le mot de passe et l’adresse IP, vérifiez s’il existe une séparation du réseau de gestion de l’interface utilisateur à partir de la commande «getrackinfo -n». Avec le jeton de l’utilisateur root, créez une variable de jeton. Un jeton valide doit être mis à jour dans une nouvelle session CLI :
# export TOKEN='X-SDS-AUTH-TOKEN: BAAcdWhGbnVRVjd1WlpmR0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxAgAC0A8='
Pour tester la valeur du jeton, vous pouvez exécuter une commande curl :
# curl -k -X GET -H "$TOKEN" https://10.xxx.xxx.21:4443/object/capacity | xmllint --format - % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 176 100 176 0 0 249 0 --:--:-- --:--:-- --:--:-- 250 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <cluster_capacity> <totalFree_gb>100657</totalFree_gb> <totalProvisioned_gb>447005</totalProvisioned_gb> </cluster_capacity>
L’objectif des étapes ci-dessus est d’utiliser le jeton de l’utilisateur root pour obtenir un accès curl au magasin de confiance de l’interface utilisateur ECS. Consultez le guide d’administration d’ECS pour plus d’informations sur l’ajout d’un certificat LDAP personnalisé. Dans cet exemple d’utilisation de l’API ECS, l’API de certificat LDAPS se trouve dans le "/vdc/truststore". Votre API peut se trouver à un autre emplacement.
Curl GET example :
Obtenez les paramètres du magasin de confiance à l’aide de la commande curl GET :
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://<NodeManagementIP>:4443/vdc/truststore/settings
Exemple :
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":false}
Dans l’exemple ci-dessus, le truststore "accept_all_certificates" est défini sur false. Cela signifie que seuls les certificats LDAPS téléchargés qui correspondent à un certificat de serveur AD/LDAP sont autorisés à être approuvés par ECS. Un utilisateur peut vouloir définir ce paramètre sur true ou false en fonction de ses besoins. Pour tester la connexion LDAPS, la définir sur true et tester la connexion des utilisateurs peut valider.
Créez un fichier json pour modifier les paramètres du truststore à l’aide d’une commande curl avec une charge utile json :
# sudo vi truststoresettings.json
# sudo cat truststoresettings.json
{"accept_all_certificates": "true"}
Le module json.tool sur python peut valider un format de fichier json. En cas d’erreur, il se peut que le fichier ne soit pas un fichier json. Dans cet exemple, il n’y a pas d’erreur et le fichier est édité, il s’agit donc d’un fichier json formaté :
# python -m json.tool truststoresettings.json
{
"accept_all_certificates": "true"
}
Curl PUT example :
Exécutez une commande curl avec un fichier json comme charge utile avec une commande curl PUT :
# curl -s -k -X PUT -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://:4443/vdc/truststore/settings -d @truststoresettings.json
Pour vérifier qu’elle est mise à jour, exécutez la commande curl GET :
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":true}