Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite kann noch im Gange sein. Die neuesten Informationen findest Du in der englischsprachigen Dokumentation. Informieren Sie uns bitte, falls auf dieser Seite ein Problem mit den Übersetzungen vorliegt.

Diese Version von GitHub Enterprise wurde eingestellt am 2020-11-12. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

Websiteadministrator-Dashboard

You can use the site admin dashboard to manage users, organizations, and repositories in your enterprise directly in GitHub Enterprise Server.

Inhalt dieses Artikels

Klicken Sie in der oberen rechten Ecke einer beliebigen Seite auf , um auf das Dashboard zuzugreifen.Raumschiffsymbol für den Zugriff auf die Einstellungen des Websiteadministrators

Lizenzinformationen und Suche

In diesem Abschnitt des Websiteadministrator-Dashboards können Sie Ihre aktuelle GitHub Enterprise-Lizenz überprüfen, nach Benutzern und Repositorys suchen und das Auditprotokoll abfragen.

Managementkonsole

Hier können Sie die Managementkonsole starten, um die Einstellungen der virtuellen Appliance zu verwalten, also beispielsweise die Domain, die Authentifizierung und SSL.

Erkunden

Die Daten für die Seite mit Trends für GitHub wird für Repositorys und Entwickler in täglichen, wöchentlichen und monatlichen Zeiträumen berechnet. Im Abschnitt Erkunden können Sie sehen, wann diese Daten letztmals zwischengespeichert wurden. Zudem können Sie darin neue Aufträge zur Berechnung von Trends in die Warteschlange versetzen.

Auditprotokoll

GitHub Enterprise speichert ein Ablaufprotokoll der überwachten Aktionen, die Sie abfragen können.

Das Auditprotokoll zeigt standardmäßig eine Liste sämtlicher überwachter Aktionen in umgekehrt chronologischer Reihenfolge an. Sie können diese Liste filtern. Geben Sie dazu im Textfeld Query (Abfragen) Schlüsselwertpaare ein, und klicken Sie anschließend auf Search (Suchen), wie dies unter „Auditprotokoll durchsuchen“ erläutert ist.

For more information on audit logging in general, see "Audit logging." For a full list of audited actions, see "Audited actions."

Berichte

Zum Abrufen von Informationen zu Benutzern, Organisationen und Repositorys in your GitHub Enterprise Server instance würden Sie normalerweise über die GitHub-API JSON-Daten abrufen. Leider stellt die API nicht alle gewünschten Daten bereit und erfordert ein gewisses technisches Know-how. Das Websiteadministrator-Dashboard bietet alternativ den Abschnitt Reports (Berichte). In diesem können Sie ohne Weiteres CSV-Berichte mit den meisten Informationen herunterladen, die Sie wahrscheinlich für Benutzer, Organisationen und Repositorys benötigen.

Insbesondere können Sie CSV-Berichte herunterladen, die Folgendes auflisten:

  • alle Benutzer
  • alle Benutzer, die im letzten Monat aktiv waren
  • alle Benutzer, die mindestens für einen Monat inaktiv waren
  • alle Benutzer, die gesperrt wurden
  • alle Organisationen
  • alle Repositorys

Darüber hinaus können Sie mit einem Websiteadministratorkonto über die HTTP-Standardauthentifizierung programmatisch auf diese Berichte zugreifen. Du musst ein persönliches Zugangs-Token mit dem „scope“ (Anwendungsbereich) site_admin verwenden. Weitere Informationen finden Sie unter "Erstellen eines persönlichen Zugriffstokens."

So würden Sie beispielsweise den Bericht „all users“ (alle Benutzer) mit der cURL herunterladen:

curl -L -u username:token http(s)://hostname/stafftools/reports/all_users.csv

Ersetzen Sie für den programmatischen Zugriff auf die anderen Berichte all_users durch active_users, dormant_users, suspended_users, all_organizations oder all_repositories.

Hinweis: Die anfängliche curl-Anforderung gibt eine 202 HTTP-Antwort zurück, wenn keine zwischengespeicherten Berichte verfügbar sind. Im Hintergrund wird ein Bericht generiert. Sie können eine zweite Anforderung senden, um den Bericht herunterzuladen. Sie können ein Passwort oder ein OAuth-Token mit dem Umfang site_admin anstelle eines Passworts verwenden.

Benutzerberichte

SchlüsselBeschreibung
created_atZeitpunkt der Benutzerkontoerstellung (als ein ISO 8601-Zeitstempel)
idKonto-ID für den Benutzer oder für die Organisation
loginAnmeldename des Kontos
E-MailPrimäre E-Mail-Adresse des Kontos
RolleGibt an, ob es sich um ein Administrator- oder um ein normales Benutzerkonto handelt
suspended?Gibt an, ob das Konto gesperrt wurde
last_logged_ipNeueste IP-Adresse für Kontoanmeldung
reposAnzahl der dem Konto gehörenden Repositorys
ssh_keysAnzahl der für das Konto registrierten SSH-Schlüssel
org_membershipsAnzahl der Organisationen, zu denen das Konto gehört
dormant?Gibt an, ob das Konto inaktiv ist
last_activeGibt den Zeitpunkt der letzten Kontoaktivität an (als ein ISO 8601-Zeitstempel)
raw_loginUnformatierte Anmeldeinformationen (im JSON-Format)
2fa_enabled?Gibt an, ob der Benutzer die Zwei-Faktor-Authentifizierung aktiviert hat

Organisationsberichte

SchlüsselBeschreibung
idOrganisations-ID
created_atZeitpunkt der Organisationserstellung
loginAnmeldename der Organisation
E-MailPrimäre E-Mail-Adresse der Organisation
ownersAnzahl der Organisationsinhaber
membersAnzahl der Organisationsmitglieder
teamsAnzahl der Organisationsteams
reposAnzahl der Organisations-Repositorys
2fa_required?Gibt an, ob für die Organisation die Zwei-Faktor-Authentifizierung erforderlich ist

Repository-Berichte

SchlüsselBeschreibung
created_atZeitpunkt der Repository-Erstellung
owner_idID des Repository-Inhabers
owner_typeGibt an, ob das Repository einem Benutzer oder einer Organisation gehört
owner_nameName des Repository-Inhabers
idRepository-ID
nameRepository-Name
Transparenz/SichtbarkeitGibt an, ob das Repository öffentlich oder privat ist
readable_sizeGröße des Repositorys in einem visuell lesbaren Format
raw_sizeGröße des Repositorys als eine Zahl
collaboratorsAnzahl der Repository-Mitarbeiter
fork?Gibt an, ob das Repository ein Fork ist
deleted?Gibt an, ob das Repository gelöscht wurde

Indizierung

Die GitHub-Features zur Codesuche werden von ElasticSearch unterstützt. Dieser Abschnitt des Websiteadministrator-Dashboards zeigt den aktuellen Status Ihres ElasticSearch-Clusters und stellt Ihnen verschiedene Tools bereit, mit denen Sie das Verhalten der Suchvorgänge und Indizierung steuern können. Diese Tools sind in die folgenden drei Kategorien unterteilt.

Codesuche

Dadurch können Sie Such- und Indizierungsvorgänge im Quellcode aktivieren oder deaktivieren.

Reparatur des Codesuche-Index

Dadurch wird gesteuert, wie der Index für die Codesuche repariert wird. Sie können

  • Indexreparaturaufträge aktivieren oder deaktivieren,
  • einen neuen Indexreparaturauftrag starten,
  • den gesamten Indexreparaturzustand zurücksetzen.

GitHub Enterprise verwendet Reparaturaufträge, um den Zustand des Suchindex mit den in einer Datenbank (Issues, Pull Requests, Repositorys und Benutzer) gespeicherten Daten und mit den in Git-Repositorys (Quellcode) gespeicherten Daten abzustimmen. Dies ist der Fall, wenn

  • ein neuer Suchindex erstellt wird,
  • fehlende Daten abgeglichen oder
  • alte Suchdaten aktualisiert werden müssen.

Reparaturaufträge werden demnach nach Bedarf gestartet und im Hintergrund ausgeführt. Sie werden nicht von Websiteadministratoren geplant.

Zudem verwenden Reparaturaufträge einen „Reparaturversatz“ zur Parallelisierung. Dies ist ein Versatz in der Datenbanktabelle für den abzustimmenden Datensatz. Anhand dieses Versatzes können mehrere Hintergrundaufträge die Arbeit synchronisieren.

Eine Fortschrittsanzeige zeigt den aktuellen Status eines Reparaturauftrags auf den gesamten Hintergrund-Workern an. Hierbei handelt es sich um die prozentuale Abweichung des Reparaturversatzes mit der höchsten Datensatz-ID in der Datenbank. Machen Sie sich keine Sorgen hinsichtlich des nach Abschluss eines Reparaturauftrags in der Fortschrittsanzeige angezeigten Werts. Dieser zeigt nämlich den Unterschied zwischen dem Reparaturversatz und der höchsten Datensatz-ID in der Datenbank. Der Wert wird kleiner, wenn mehr Repositorys zu your GitHub Enterprise Server instance hinzugefügt werden, auch wenn diese Repositorys tatsächlich indiziert sind.

Reparaturaufträge des Codesuche-Index können jederzeit gestartet werden. Diese verwenden eine einzelne CPU und stimmen den Suchindex mit den Datenbank- und Git-Repository-Daten ab. Versuchen Sie, einen Reparaturauftrag zunächst außerhalb der Hauptauslastungszeiten durchzuführen, um die Auswirkungen auf die E/A-Leistung zu minimieren und die Wahrscheinlichkeit von Betriebsunterbrechungen zu verringern. Mit einem Dienstprogramm wie top können Sie die durchschnittliche Auslastung und CPU-Auslastung Ihres Systems überwachen. Wenn Sie keine erheblichen Änderungen feststellen, können Sie einen Indexreparaturauftrag auch in Spitzenzeiten ohne Weiteres ausführen.

Indexreparatur für Issues

Dadurch wird gesteuert, wie der Issues-Index repariert wird. Sie können

  • Indexreparaturaufträge aktivieren oder deaktivieren,
  • einen neuen Indexreparaturauftrag starten,
  • den gesamten Indexreparaturzustand zurücksetzen.

Repositorys

Dies ist eine Liste der Repositorys auf your GitHub Enterprise Server instance. Sie können auf einen Repository-Namen klicken und auf Funktionen zum Verwalten des Repositorys zugreifen.

Alle Benutzer

Hier können Sie alle Benutzer auf Ihrer your GitHub Enterprise Server instance anzeigen und eine SSH-Schlüsselüberwachung initiieren.

Websiteadministratoren

Hier können Sie alle Administratoren auf Ihrer your GitHub Enterprise Server instance anzeigen und eine SSH-Schlüsselüberwachung initiieren.

Inaktive Benutzer

Hier können Sie alle inaktiven Benutzer auf your GitHub Enterprise Server instance anzeigen und sperren. In den folgenden Fällen wird ein Benutzerkonto als inaktiv angesehen:

  • Es besteht schon länger als die für your GitHub Enterprise Server instance festgelegte Inaktivitätsschwelle.
  • Es hat in diesem Zeitraum keine Aktivitäten generiert.
  • Es ist kein Websiteadministrator.

Die Inaktivitätsschwelle ist die Zeitspanne welche ein Benutzer inaktiv sein muss um als ruhend betrachtet zu werden. Die Standard-Inaktivitätsschwelle beträgt 90 Tage, Du kannst sie aber für your GitHub Enterprise Server instance anpassen. Weitere Informationen finden Sie unter „Inaktive Benutzer verwalten“.

Gesperrte Benutzer

Hier können Sie alle Benutzer anzeigen, die auf your GitHub Enterprise Server instance gesperrt wurden, und eine SSH-Schlüsselüberwachung initiieren.