Gelegentlich registriert Compute Engine PAYG Ubuntu Pro-Lizenzen nicht automatisch. In diesem Dokument wird beschrieben, wie Sie Probleme bei der Registrierung von Compute Engine-VM-Instanzen beheben, auf denen "Pay as you go"-Ubuntu Pro-Lizenzen (PAYG-Ubuntu Pro-Lizenzen) ausgeführt werden.
Registrierungsstatus prüfen
Um zu prüfen, ob Ihre Lizenz registriert ist, stellen Sie eine Verbindung zur VM her und führen Sie den folgenden Befehl aus:
sudo ua status
Wenn die Registrierung erfolgreich war, sieht die Ausgabe in etwa so aus und es sind keine weiteren Maßnahmen erforderlich:
SERVICE ENTITLED STATUS DESCRIPTION cc-eal yes disabled Common Criteria EAL2 Provisioning Packages cis yes disabled Security compliance and audit tools esm-apps yes enabled Expanded Security Maintenance for Applications esm-infra yes enabled Expanded Security Maintenance for Infrastructure fips yes disabled NIST-certified core packages fips-updates yes disabled NIST-certified core packages with priority security updates livepatch yes enabled Canonical Livepatch service
Wenn die Registrierung fehlgeschlagen ist und Ubuntu Pro nicht registriert ist, wird eine Meldung wie die folgende angezeigt:
This machine is not attached to an Ubuntu Pro subscription.
Lizenz manuell registrieren
Wenn Compute Engine Ihre Ubuntu-Pro-Lizenz nicht automatisch registrieren konnte, können Sie die Lizenz mit dem folgenden Befehl manuell registrieren:
sudo pro auto-attach
Die Ausgabe sieht in etwa so aus:
Registrierung erfolgreich:
This machine is already attached to PROJECT_ID To use a different subscription first run: sudo pro detach.
Fehler bei der Anmeldung:
Internal Server Error
Fehlerbehebung bei der Lizenzregistrierung
Wenn Sie eine Ubuntu Pro-Lizenz nicht manuell registrieren konnten, beheben Sie das Problem so:
Prüfen Sie, ob die VM den Metadatenserver erreichen kann. Führen Sie dazu den folgenden Befehl aus, um die Anzahl der an die VM angehängten Laufwerke zu prüfen:
curl "http://metadata.google.internal/computeMetadata/v1/instance/disks/" -H "Metadata-Flavor: Google"
Die Ausgabe sieht ähnlich aus wie die folgende, die die Anzahl der an die VM angehängten Laufwerke anzeigt:
0/ 1/ 2/
Wenn in der Ausgabe nicht die Anzahl der an die VM angehängten Laufwerke angezeigt wird, lesen Sie die Informationen unter Fehlerbehebung bei Problemen mit dem Metadatenserver-Zugriff.
Prüfen Sie mit dem folgenden Befehl, ob der Google-Gast-Agent ausgeführt wird:
systemctl status google-guest-agent.service
Die Ausgabe sieht in etwa so aus:
● google-guest-agent.service - Google Compute Engine Guest Agent Loaded: loaded (/lib/systemd/system/google-guest-agent.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2023-04-20 16:35:11 PDT; 2h 12min ago Main PID: 4582 (google_guest_ag) Tasks: 10 (limit: 9525)
Wenn der Gast-Agent nicht installiert ist oder fehlgeschlagen ist, installieren Sie die Gastumgebung oder installieren Sie sie neu.
Prüfen Sie, ob ein Dienstkonto an die VM angehängt ist. Führen Sie dazu den folgenden Befehl auf Ihrer lokalen Workstation aus:
gcloud compute instances describe VM_NAME \ --zone ZONE --format="table(serviceAccounts.email)"
Ersetzen Sie Folgendes:
VM_NAME
: der Name der VMZONE
: die Zone, in der sich die VM befindet
Die Ausgabe sieht in etwa so aus:
EMAIL: ['[email protected]']
Notieren Sie sich die E-Mail-Adresse des Dienstkontos.
Prüfen Sie mit der folgenden Abfrage, ob das Dienstkonto aktiviert ist:
gcloud logging read --freshness=90d "SERVICE_ACCOUNT_EMAIL protoPayload.methodName=google.iam.admin.v1.DisableServiceAccount"
Ersetzen Sie
SERVICE_ACCOUNT_EMAIL
durch die mit dem Dienstkonto der VM verknüpfte E-Mail-Adresse.Die Ausgabe sieht in etwa so aus:
insertId: 1ne5thkf13sxec logName: projects/testproject/logs/cloudaudit.googleapis.com%2Factivity protoPayload: '@type': type.googleapis.com/google.cloud.audit.AuditLog authenticationInfo: principalEmail: [email protected] principalSubject: user:[email protected] authorizationInfo: granted: true permission: iam.serviceAccounts.disable resource: projects/-/serviceAccounts/XXXXXXXXXXXXXX resourceAttributes: name: projects/-/serviceAccounts/XXXXXXXXXXXXXXXX methodName: google.iam.admin.v1.DisableServiceAccount request: '@type': type.googleapis.com/google.iam.admin.v1.DisableServiceAccountRequest name: projects/testproject/serviceAccounts/
[email protected] requestMetadata: destinationAttributes: {} requestAttributes: auth: {} time: '2024-01-25T21:37:55.748811275Z' resourceName: projects/-/serviceAccounts/XXXXXXXXXX response: '@type': type.googleapis.com/google.protobuf.Empty serviceName: iam.googleapis.com status: {} receiveTimestamp: '2024-01-25T21:37:56.409675900Z' resource: labels: email_id: [email protected] project_id: testproject unique_id: 'XXXXXXXXXXXXXXXX' type: service_account severity: NOTICE timestamp: '2024-01-25T21:37:55.721215307Z' Wenn das Dienstkonto nicht aktiviert ist, aktivieren Sie es wieder.
Nachdem Sie das Dienstkonto wieder aktiviert haben, versuchen Sie, die Lizenz zu registrieren. Folgen Sie dazu der Anleitung im Abschnitt Lizenz manuell registrieren in diesem Dokument.