Hostsharing Wiki - Benutzerbeiträge [de]

Bugtracker

2025-05-26T12:12:10Z

Tbf00: /* HSAdmin */ very minor ui issue

[[Kategorie:Bugtracker]]

Ein Bugtracker für hostsharing Infrastuktur
Um für die Anfragen und Veränderungen oder Probleme mit der Infrastruktur einen Ort zu bieten soll ein Bugtracker etabliert werden. Diese Seite (oder weitere in dieser [[:Kategorie:Bugtracker| Kategorie]]) dient in der Zwischenzeit als Ersatz.

== Fehlermeldungen ==
{{Textkasten|gelb|Bitte beachten|Hier keine sicherheitsrelevanten Bugs eintragen.}}
=== HSAdmin ===

* [minor] [ui] Im ersten Tab der englischen UI in Paketverwaltung ("Package") werden die Felder in der englischen UI als "Packet name/type/server" bezeichnet. Korrekt ist aber "Package name/type/server".

=== Webmail ===
=== Domainverwaltung ===
=== SSL / TLS ===
=== Spam Abwehr ===

== Feature-requests - Funktionsanfragen ==
=== HsAdmin ===
* Quickinstaller für SW wie Wordpress, Nextcloud etc.
* Modulweise Listen/Tabellen und Eingabemasken, mit sehr guter Filter- und Sortierfunktion (sonst findet man nichts, wenn man Reseller ist). Diese sollten nicht völlig "dämlich" sein. Dort wo, z.B. die Eingabe eines Domain-Admins erforderlich ist, sollte es neben eine (filterbaren) Auswahl auch einen Button für die Neuanlage des Objekts geben.
* Einrichtungsasssistenten für Einsteiger für gängige Funktionen (neue Domain einrichten, neue E-Mail-Adresse einrichten, neue Datenbank einrichten...) Diese Assistenten befreien Benutzer insbesondere davon viele Schritte ausführen zu müssen, um ein ein gängiges Ziel zu erlangen, z.B. erst die Mailbox, dann die Adresse. Sowas geht auch in einem Zug aka. Assistenten, ohne dass wir unsere Flexibilität aufgeben müssen.
* Statistische Auswertungen wie z.B. eine Abfrage auf Ausnutzung des Gesamtspeicherplatzes im Paket
* Hilfe durch HSAdmin-Benutzer editierbar

=== Gitea für HS-User ===
* Für die Sammlung von Skripten und Software zum Umgang mit dem HS-System in Git Repositories.

== Software zur Nutzung ==
Hierzu kann wohl [[Roundup]] genutzt werden, wofür bereits eine Installationsanleitung hier im Wiki vorliegt, andere Möglichkeiten wären:

* BugNet http://bugnet.codeplex.com/
* bugzilla https://www.bugzilla.org/download/
* fossil http://fossil-scm.org/index.html/doc/trunk/www/index.wiki
* mantis BT http://www.mantisbt.org/index.php
* phproject http://www.phproject.org/
* Redmine http://www.redmine.org/
* Request Tracker https://bestpractical.com/request-tracker
* Roundup http://roundup-tracker.org/
* trac https://trac.edgewall.org/
* WebIssues http://webissues.mimec.org/

== siehe auch ==
* https://usersnap.com/de/blog/open-source-bug-tracker/
* https://blog.capterra.com/top-free-bug-tracking-software/
* https://opensource.com/business/16/2/top-issue-support-and-bug-tracking-tools
* https://stackify.com/top-bug-tracking-tools/
* https://www.guru99.com/top-20-bug-tracking-tools.html

Gitolite installieren

2025-03-13T10:18:21Z

Tbf00:

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Gitolite (https://gitolite.com/gitolite/index.html) ist leichtgewichtiger Server für Git Repositories, der in einem HS Webpaket läuft, ohne dass ein Server (mit eigenem Daemon und Port etc.) installiert sein muss. Es macht in einem Webpaket gehostete Repos über SSH zugänglich. Gitolite ist gut geeignet,wenn eine überschaubare Anzahl Repos und User verwaltet werden soll, es wird gesteuert über ein einziges Configfile und Public-Keys die alle zusammen über Git versioniert sind.

== Gitolite einzurichten ist sehr einfach ==

Du brauchst ein SSH-Keypair extra für gitolite (z.B. id_gitolite_admin + id_gitolite_admin.pub), das dem Gitolite-Admin den Zugang ermöglicht. Das kannst Du mit ssh-keygen anlegen. Den Publickey kopiest Du in ~/.ssh/id_gitolite_admin.pub (oder einen anderen deskriptiven Namen).

Per SSH da eingeloggt, schreibst Du:

<syntaxhighlight lang=shell>
gitolite setup -pk ~/.ssh/id_gitolite_admin.pub
</syntaxhighlight>

Damit ist Gitolite in dem Webpaket bereits installiert. Es hat die Konfigurationsdatei '.gitolite.rc' und das Verzeichnis '/repositories' erstellt.

In '/repositories' sind bereits zwei Repos eingerichtet, gitolite-admin.git und testing.git.

Auf Deinem lokalen System kannst Du den Zugang für gitolite in der ~/.ssh/config konfigurieren

<syntaxhighlight>
Host xyz00gitadmin
Hostname xyz00.hostsharing.net
User xyz00
Identityfile ~/.ssh/id_gitolite_admin
</syntaxhighlight>

Dadurch lässt sich der Zugang im nächsten Schritt kürzer schreiben.

== Konfiguration ==

Du kannst nun von außerhalb das Admin Repo auf deinen Computer klonen:

<syntaxhighlight lang=shell>
git clone xyz00gitadmin:gitolite-admin
</syntaxhighlight>

Es ist wichtig nicht xyz00:repositories/gitolite-admin.git zu clonen, da es sonst gitolite umgeht.

In dem gitolite-admin repo finden sich die zwei Verzeichnisse ''conf'' und ''keydir''.

=== User ===

User entstehen durch gleichnamige Dateien (mit der Endung '.pub') mit den Public-Keys der User im Verzeichnis 'keydir':

<syntaxhighlight lang=shell>
me@on-my-computer ~/gitolite-admin » ls keydir
admin.pub anton.pub berta.pub jenkins.pub josef.pub
</syntaxhighlight>

=== Repositories und Zugriffsrechte ===

Die Konfiguration der Repos und der Zugriffsrechte schreibt man in conf/gitolite.conf, darin kann man auch Gruppen definieren (deren Namen beginnen mit '@'):

<syntaxhighlight lang=ini line>
# Gruppen
@programmierer = anton josef
@reader = jenkins gitweb anton

# Hier stehen die Repos

repo gitolite-admin
RW+ = admin

repo example.de
RW+ = @programmierer
R = @reader

repo example-data
R = @reader
RW+ = @programmierer

repo example-blog
RW+ = anton berta
</syntaxhighlight>

Man definiert also einfach ein neues Repo und die Zugriffsrechte mit
einem Eintrag in gitolite.conf.

=== Konfiguration versionieren und pushen ===

Das kann man nun wie in Git üblich committen und pushen:

<syntaxhighlight lang=shell>
git add -A
git commit -m "Start Gitolite Administration"
git push
</syntaxhighlight>

Und dann passiert folgendes: Gitolite packt die Keys der User in .ssh/authorized_keys mit einem Command voran, das die Gitolite Shell aufruft.

== Verwendung ==

Und je nachdem wie es in gitolite.conf definiert wurde, haben die User jetzt per SSH Zugriff auf die Repositories, sie können sich einloggen, bekommen aber nur ein Listing zu sehen, das ihre Repos zeigt.

Beachte den Verweis auf das Identity-file:

<syntaxhighlight lang=shell>
me@on-my-computer » ssh -i admin xyz00@xyz00.hostsharing.net
PTY allocation request failed on channel 0
hello admin, this is xyz@h00 running gitolite3 3.6.11-2 (Debian) on git 2.20.1

R W gitolite-admin
R W example.de
R W example-data
R W example-blog
Connection to deg01.hostsharing.net closed.
</syntaxhighlight>

Die User können die Repos klonen, und – wenn erlaubt – bearbeiten und wieder pushen.

Gitolite installieren

2025-03-13T09:24:57Z

Tbf00: /* Konfiguration */

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Gitolite (https://gitolite.com/gitolite/index.html) ist leichtgewichtiger Server für Git Repositories, der in einem HS Webpaket läuft, ohne dass ein Server (mit eigenem Daemon und Port etc.) installiert sein muss. Es macht in einem Webpaket gehostete Repos über SSH zugänglich. Gitolite ist gut geeignet,wenn eine überschaubare Anzahl Repos und User verwaltet werden soll, es wird gesteuert über ein einziges Configfile und Public-Keys die alle zusammen über Git versioniert sind.

== Gitolite einzurichten ist sehr einfach ==

Du brauchst ein SSH-Keypair extra für gitolite (z.B. id_gitolite_admin + id_gitolite_admin.pub), das dem Gitolite-Admin den Zugang ermöglicht. Das kannst Du mit ssh-keygen anlegen. Den Publickey kopiest Du in ~/.ssh/id_gitolite_admin.pub (oder einen anderen deskriptiven Namen).

Per SSH da eingeloggt, schreibst Du:

<syntaxhighlight lang=shell>
gitolite setup -pk .ssh/id_gitolite_admin.pub
</syntaxhighlight>

Damit ist Gitolite in dem Webpaket bereits installiert. Es hat die Konfigurationsdatei '.gitolite.rc' und das Verzeichnis '/repositories' erstellt.

In '/repositories' sind bereits zwei Repos eingerichtet, gitolite-admin.git und testing.git.

Auf Deinem lokalen System kannst Du den Zugang für gitolite in der ~/.ssh/config konfigurieren

<syntaxhighlight>
Host xyz00git
Hostname xyz00.hostsharing.net
User xyz00
Identityfile .ssh/id_gitolite_admin
</syntaxhighlight>

Dadurch lässt sich der Zugang im nächsten Schritt kürzer schreiben.

== Konfiguration ==

Du kannst nun von außerhalb das Admin Repo auf deinen Computer klonen (Achtung, ungeprüft):

<syntaxhighlight lang=shell>
git clone xyz00git:repositories/gitolite-admin.git
</syntaxhighlight>

In dem Repo finden sich die zwei Verzeichnisse ''conf'' und ''keydir''.

=== User ===

User entstehen durch gleichnamige Dateien (mit der Endung '.pub') mit den Public-Keys der User im Verzeichnis 'keydir':

<syntaxhighlight lang=shell>
me@on-my-computer ~/gitolite-admin » ls keydir
admin.pub anton.pub berta.pub jenkins.pub josef.pub
</syntaxhighlight>

=== Repositories und Zugriffsrechte ===

Die Konfiguration der Repos und der Zugriffsrechte schreibt man in conf/gitolite.conf, darin kann man auch Gruppen definieren (deren Namen beginnen mit '@'):

<syntaxhighlight lang=ini line>
# Gruppen
@programmierer = anton josef
@reader = jenkins gitweb anton

# Hier stehen die Repos

repo gitolite-admin
RW+ = admin

repo example.de
RW+ = @programmierer
R = @reader

repo example-data
R = @reader
RW+ = @programmierer

repo example-blog
RW+ = anton berta
</syntaxhighlight>

Man definiert also einfach ein neues Repo und die Zugriffsrechte mit
einem Eintrag in gitolite.conf.

=== Konfiguration versionieren und pushen ===

Das kann man nun wie in Git üblich committen und pushen:

<syntaxhighlight lang=shell>
git add -A
git commit -m "Start Gitolite Administration"
git push
</syntaxhighlight>

Und dann passiert folgendes: Gitolite packt die Keys der User in .ssh/authorized_keys mit einem Command voran, das die Gitolite Shell aufruft.

== Verwendung ==

Und je nachdem wie es in gitolite.conf definiert wurde, haben die User jetzt per SSH Zugriff auf die Repositories, sie können sich einloggen, bekommen aber nur ein Listing zu sehen, das ihre Repos zeigt.

Beachte den Verweis auf das Identity-file:

<syntaxhighlight lang=shell>
me@on-my-computer » ssh -i admin xyz00@xyz00.hostsharing.net
PTY allocation request failed on channel 0
hello admin, this is xyz@h00 running gitolite3 3.6.11-2 (Debian) on git 2.20.1

R W gitolite-admin
R W example.de
R W example-data
R W example-blog
Connection to deg01.hostsharing.net closed.
</syntaxhighlight>

Die User können die Repos klonen, und – wenn erlaubt – bearbeiten und wieder pushen.

Gitolite installieren

2025-03-13T09:23:53Z

Tbf00: /* Gitolite einzurichten ist sehr einfach */

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Gitolite (https://gitolite.com/gitolite/index.html) ist leichtgewichtiger Server für Git Repositories, der in einem HS Webpaket läuft, ohne dass ein Server (mit eigenem Daemon und Port etc.) installiert sein muss. Es macht in einem Webpaket gehostete Repos über SSH zugänglich. Gitolite ist gut geeignet,wenn eine überschaubare Anzahl Repos und User verwaltet werden soll, es wird gesteuert über ein einziges Configfile und Public-Keys die alle zusammen über Git versioniert sind.

== Gitolite einzurichten ist sehr einfach ==

Du brauchst ein SSH-Keypair extra für gitolite (z.B. id_gitolite_admin + id_gitolite_admin.pub), das dem Gitolite-Admin den Zugang ermöglicht. Das kannst Du mit ssh-keygen anlegen. Den Publickey kopiest Du in ~/.ssh/id_gitolite_admin.pub (oder einen anderen deskriptiven Namen).

Per SSH da eingeloggt, schreibst Du:

<syntaxhighlight lang=shell>
gitolite setup -pk .ssh/id_gitolite_admin.pub
</syntaxhighlight>

Damit ist Gitolite in dem Webpaket bereits installiert. Es hat die Konfigurationsdatei '.gitolite.rc' und das Verzeichnis '/repositories' erstellt.

In '/repositories' sind bereits zwei Repos eingerichtet, gitolite-admin.git und testing.git.

Auf Deinem lokalen System kannst Du den Zugang für gitolite in der ~/.ssh/config konfigurieren

<syntaxhighlight>
Host xyz00git
Hostname xyz00.hostsharing.net
User xyz00
Identityfile .ssh/id_gitolite_admin
</syntaxhighlight>

Dadurch lässt sich der Zugang im nächsten Schritt kürzer schreiben.

== Konfiguration ==

Du kannst nun von außerhalb das Admin Repo auf deinen Computer klonen (Achtung, ungeprüft):

<syntaxhighlight lang=shell>
git clone xyz00@xyz00.hostsharing.net:gitolite-adminadmin.git
</syntaxhighlight>

In dem Repo finden sich die zwei Verzeichnisse ''conf'' und ''keydir''.

=== User ===

User entstehen durch gleichnamige Dateien (mit der Endung '.pub') mit den Public-Keys der User im Verzeichnis 'keydir':

<syntaxhighlight lang=shell>
me@on-my-computer ~/gitolite-admin » ls keydir
admin.pub anton.pub berta.pub jenkins.pub josef.pub
</syntaxhighlight>

=== Repositories und Zugriffsrechte ===

Die Konfiguration der Repos und der Zugriffsrechte schreibt man in conf/gitolite.conf, darin kann man auch Gruppen definieren (deren Namen beginnen mit '@'):

<syntaxhighlight lang=ini line>
# Gruppen
@programmierer = anton josef
@reader = jenkins gitweb anton

# Hier stehen die Repos

repo gitolite-admin
RW+ = admin

repo example.de
RW+ = @programmierer
R = @reader

repo example-data
R = @reader
RW+ = @programmierer

repo example-blog
RW+ = anton berta
</syntaxhighlight>

Man definiert also einfach ein neues Repo und die Zugriffsrechte mit
einem Eintrag in gitolite.conf.

=== Konfiguration versionieren und pushen ===

Das kann man nun wie in Git üblich committen und pushen:

<syntaxhighlight lang=shell>
git add -A
git commit -m "Start Gitolite Administration"
git push
</syntaxhighlight>

Und dann passiert folgendes: Gitolite packt die Keys der User in .ssh/authorized_keys mit einem Command voran, das die Gitolite Shell aufruft.

== Verwendung ==

Und je nachdem wie es in gitolite.conf definiert wurde, haben die User jetzt per SSH Zugriff auf die Repositories, sie können sich einloggen, bekommen aber nur ein Listing zu sehen, das ihre Repos zeigt.

Beachte den Verweis auf das Identity-file:

<syntaxhighlight lang=shell>
me@on-my-computer » ssh -i admin xyz00@xyz00.hostsharing.net
PTY allocation request failed on channel 0
hello admin, this is xyz@h00 running gitolite3 3.6.11-2 (Debian) on git 2.20.1

R W gitolite-admin
R W example.de
R W example-data
R W example-blog
Connection to deg01.hostsharing.net closed.
</syntaxhighlight>

Die User können die Repos klonen, und – wenn erlaubt – bearbeiten und wieder pushen.