Fehlerbehebung bei der Ubuntu Pro-Registrierung


Gelegentlich werden PAYG-Ubuntu Pro-Lizenzen in der Compute Engine nicht automatisch registriert. In diesem Dokument wird beschrieben, wie Sie Probleme beheben, die beim Registrieren von Compute Engine-VM-Instanzen mit Ubuntu Pro-Lizenzen (Pay as you go) auftreten können.

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, sehen Sie eine Ausgabe ähnlich der folgenden 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 wurde, wird eine Meldung ähnlich der folgenden angezeigt:

This machine is not attached to an Ubuntu Pro subscription.

Lizenz manuell registrieren

Wenn die Ubuntu Pro-Lizenz nicht automatisch in der Compute Engine registriert wurde, können Sie die Lizenz manuell registrieren. Führen Sie dazu den folgenden Befehl aus:

sudo pro auto-attach

Die Ausgabe sieht in etwa so aus:

  • Erfolgreiche Registrierung:

    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, gehen Sie so vor, um das Problem zu beheben:

  1. 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 angeschlossenen Laufwerke zu prüfen:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/disks/" -H "Metadata-Flavor: Google"
    

    Die Ausgabe sieht in etwa so aus:

    0/
    1/
    2/
    

    Wenn in der Ausgabe nicht die Anzahl der an die VM angeschlossenen Laufwerke angezeigt wird, lesen Sie den Hilfeartikel Probleme mit dem Zugriff auf den Metadatenserver beheben.

  2. Prüfen Sie mit dem folgenden Befehl, ob der Google-Gastagent 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 Gastagent nicht installiert ist oder fehlschlägt, installieren oder installieren Sie die Gastumgebung neu.

  3. Prüfen Sie, ob der VM ein Dienstkonto zugewiesen ist, indem Sie den folgenden Befehl auf Ihrer lokalen Workstation ausführen:

    gcloud compute instances describe VM_NAME \
       --zone ZONE --format="table(serviceAccounts.email)"
    

    Ersetzen Sie Folgendes:

    • VM_NAME: der Name der VM
    • ZONE: die Zone, in der sich die VM befindet

    Die Ausgabe sieht in etwa so aus:

    EMAIL: ['XXXXXXXX-compute@developer.gserviceaccount.com']
    

    Notieren Sie sich die E-Mail-Adresse des Dienstkontos.

  4. Prüfen Sie, ob das Dienstkonto aktiviert ist, indem Sie die folgende Abfrage ausführen:

    gcloud logging read --freshness=90d "SERVICE_ACCOUNT_EMAIL protoPayload.methodName=google.iam.admin.v1.DisableServiceAccount"
    

    Ersetzen Sie SERVICE_ACCOUNT_EMAIL durch die E-Mail-Adresse, die mit dem Dienstkonto der VM verknüpft ist.

    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: principalemail@google.com
    principalSubject: user:pricipalemail@google.com
    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/-compute@developer.gserviceaccount.com
    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: -compute@developer.gserviceaccount.com
     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 noch einmal.

Nachdem Sie das Dienstkonto reaktiviert haben, versuchen Sie, die Lizenz zu registrieren. Folgen Sie dazu der Anleitung im Abschnitt Lizenz manuell registrieren dieses Dokuments.