Websiteadministrator-Dashboard

Klicken Sie in der oberen rechten Ecke einer beliebigen Seite auf , um auf das Dashboard zuzugreifen.

Suche

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

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 Server 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.

Benutzerberichte

Schlüssel	Beschreibung
created_at	Zeitpunkt der Benutzerkontoerstellung (als ein ISO 8601-Zeitstempel)
id	Konto-ID für den Benutzer oder für die Organisation
login	Anmeldename des Kontos
E-Mail	Primäre E-Mail-Adresse des Kontos
Rolle	Gibt an, ob es sich um ein Administrator- oder um ein normales Benutzerkonto handelt
suspended?	Gibt an, ob das Konto gesperrt wurde
last_logged_ip	Neueste IP-Adresse für Kontoanmeldung
repos	Anzahl der dem Konto gehörenden Repositorys
ssh_keys	Anzahl der für das Konto registrierten SSH-Schlüssel
org_memberships	Anzahl der Organisationen, zu denen das Konto gehört
dormant?	Gibt an, ob das Konto inaktiv ist
last_active	Gibt den Zeitpunkt der letzten Kontoaktivität an (als ein ISO 8601-Zeitstempel)
raw_login	Unformatierte Anmeldeinformationen (im JSON-Format)
2fa_enabled?	Gibt an, ob der Benutzer die Zwei-Faktor-Authentifizierung aktiviert hat

Organisationsberichte

Schlüssel	Beschreibung
id	Organisations-ID
created_at	Zeitpunkt der Organisationserstellung
login	Anmeldename der Organisation
E-Mail	Primäre E-Mail-Adresse der Organisation
owners	Anzahl der Organisationsinhaber
members	Anzahl der Organisationsmitglieder
teams	Anzahl der Organisationsteams
repos	Anzahl der Organisations-Repositorys
2fa_required?	Gibt an, ob für die Organisation die Zwei-Faktor-Authentifizierung erforderlich ist

Repository-Berichte

Schlüssel	Beschreibung
created_at	Zeitpunkt der Repository-Erstellung
owner_id	ID des Repository-Inhabers
owner_type	Gibt an, ob das Repository einem Benutzer oder einer Organisation gehört
owner_name	Name des Repository-Inhabers
id	Repository-ID
name	Repository-Name
Transparenz/Sichtbarkeit	Gibt an, ob das Repository öffentlich oder privat ist
readable_size	Größe des Repositorys in einem visuell lesbaren Format
raw_size	Größe des Repositorys als eine Zahl
collaborators	Anzahl 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.

Reserved logins

Certain words are reserved for internal use in your GitHub Enterprise Server instance, which means that these words cannot be used as usernames.

For example, the following words are reserved, among others:

• verwalten
• Unternehmen
• login
• staff
• unterstützung

For the full list or reserved words, navigate to "Reserved logins" in the site admin dashboard.

Alle Benutzer

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

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.

• Erzwungene Push-Vorgänge an ein Repository blockieren
• Git Large File Storage konfigurieren
• Repositorys archivieren und deren Archivierung aufheben

Alle Benutzer

Here you can see all of the users on your GitHub Enterprise Server instance, and initiate an SSH key audit.

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.