Hallo Cranvil, danke für deinen Einsatz im Wiki!
Wir sollten zunächst unterscheiden, was in diesem Artikel relevant ist für eine Verschiebung ins Wiki. Optimieren geht immer, das können wir als Wikiteam ein Lied davon singen ☺
noisefloor hatte den Artikel ja als ok fürs Wiki genannt. Mein Vorschlag wäre, das zunächst abzuschließen (hier gibt es IMHO keinen Show-Stopper mehr) und dir den Artikel danach in eine separate Baustelle zur Optimierung zu schieben. Wäre das ok für dich?
Zu deinen Anmerkungen:
Die Anforderungen 🇬🇧 von Snipe-IT informieren uns, dass PHP mindestens in Version 7.1.2 vorliegen muss, was einen Test unter 16.04 mit den distributionseigenen Paketen mangels Herstellerunterstützung aus meiner Sicht unnötig macht. Dieser Zusammenhang sollte im Wiki erwähnt werden.
Das hab ich jetzt leider nicht verstanden. Könntest du das bitte nochmal in kürzeren Sätzen schreiben, was du damit meinst?
Eine Alternative hierzu wäre die Ergänzung des Artikels um eine Installation neuerer PHP-Versionen, z.B. aus Ondřej Surýs PPA. In diesem PPA werden die neuesten noch unterstützten Versionen von PHP für die neuesten noch unterstützten Versionen von Ubuntu bereitgestellt. Hier ist dann allerdings noch die obligatorische Fremdquellen-Warnung einzupflegen. Ich habe diese Möglichkeit nicht getestet, gehe jedoch davon aus, dass es genauso problemlos wie bei der 18.04er Version klappt. Vielleicht ergänze ich den Artikel dann später noch. ☺
Das gehört dann aber bitte in den Artikel PHP mit entsprechender Verlinkung hier.
Nach meinem Geschmack sollte die Paketliste tatsächlich eine Liste sein.
Du meinst zeilengetrennt statt Leerzeichen-getrennt im Quelltext ? Wäre sicher gut lesbar.
Das Paket unzip ist nach meinem Kenntnisstand Teil der Grundinstallation, hier also nicht unbedingt zusätzlich zu installieren.
Stört aber auch nicht, wenn es für das Programm wichtig ist. Sowas ist z.B. für die Installation in einem Container interessant (auch wenn wir das bisher im Wiki nicht berücksichtigen).
Darüber hinaus bin ich immer unentschlossen, ob nun die explizite Version angegeben werden soll oder nicht.
Das kommt ganz darauf an. Wenn ein Programm bzw. Wiki-Artikel für mehrere Ubuntu-Versionen getestet ist und man die Installationsanleitung über die Metapakte abfangen kann (also ohne die Versionsnummer) ist diese Variante IMO zu bevorzugen. Aktuell ist das ja nicht der Fall, von daher so i.O. Wie gesagt, optimieren geht immer ☺
Wie läuft das bei einem dist-upgrade? Würde der dann erstmal keine Aktualisierungen vornehmen und ich muss diese Pakete von Hand nachziehen?
Das kann ich aktuell nicht sagen.
Eines der php7.2 Pakete in der Liste ist nicht notwendig.
Welches?
Ich frage mich allerdings, ob das vielleicht von früher ein phpx.y-mcrypt-Artefakt ist, wobei es Pakete dieser Art auch nicht mehr gibt. Nicht getestet habe ich, was passiert, wenn ich das Paket mcrypt nicht installiere.
mcrypt ist IMO nach Pecl 🇬🇧 oder sowas gewandert.
Ein Mangel, den ich auch in der Snipe-IT-Dokumentation sehe: Es wird ein simples git clone ... verwendet, ohne später eine bestimmte Version auszuchecken oder wenigstens darauf hinzuweisen. Wenn man nach dem klonen des Repositories in selbiges wechselt, lässt sich mit
sehr schnell feststellen, dass wir bereits jetzt ein paar Commits von der letzten als stabil markierten (getaggten) Version entfernt sind. Es mag sein, dass deren Entwicklungsmodell so gestrickt ist, dass der master-Branch immer stabil ist. Allerdings weiß dann der Leser, der gemäß Anleitung installiert, gar nicht, dass er eben nicht die aktuellste stabile Version hat - oder ggf. der Helfer, der drei Commits vorher installiert hat.
Man könnte ja nach dem clone in den entsprechenden tag wechseln, wenn die stable-releases darüber abgebildet werden. Das könnte ich mir hier im Wiki als Ergänzung gut vorstellen.
Zusätzlich zur Installation ist es hier ggf. auch nochmal wichtig, die Aktualisierung von Snipe-IT via
zu behandeln. Und was da sonst noch so mitkommen muss (Aktualisierung von Abhängigkeiten via Composer z.B.).
Hier wäre mein Anspruch, das möglichst kurz zu halten und dann auf die entsprechenden Abschnitte in Git und Composer verlinken. sobald es beide Artikel im Wiki gibt, sollten die wohl sowieso noch in die Wissensbox.
Im Bereich der Anleitung vielleicht etwas besser Herausstellen, dass der Haken zum Aktivieren/Deaktivieren von Benutzern im Dialog/Bildschirm zur Erstellung oder Bearbeitung eines Benutzerkontos zu finden ist. Ich habe eine gute Zeit nach einem Menü gesucht.
Darfst du dann gerne machen.
Ich finde es sehr gut, dass es auch ein Kapitel zum Deinstallieren gibt - da sollte ich in Zukunft auch mal dran denken. Nachdem während der Installation so viel Wert darauf gelegt wurde, die Standardseite von Apache zu deaktivieren (ggf. ist dort auch nochmal ein Hinweis sinnvoll, was man da überhaupt mit welchen Folgen tut), ist es hier im Gegenzug sinnvoll, diese wieder zu aktivieren - nachdem man im Datenverzeichnis aufgeräumt hat.
+1
Zusätzlich zum Löschen der Datenbank ist es gewiss auch nicht schlecht, den Datenbankbenutzer zu entfernen, um wirklich alles aufgeräumt zu haben. 😉
+1
Das war es erstmal an Anmerkungen. Wie eingangs erwähnt, funktioniert der Artikel als solches sowohl technisch (Snipe-IT läuft in der 18.04-VM) als auch von dem kleinen Anwendungsbeispiel her.
... und kann damit wohl ins Wiki, was ich jetzt gleich mache, da ihm sowieso schon der Baustellen-Hinweis geklaut wurde.
@Cranvil willst du dann den Artikel für eine Ergänzung gleich wieder in der Baustelle? Oder @krrhh wollt ihr euch da ggf. gar zusammen tun?
Viele Grüße
BillMaier
