Grundsätzlich ein Großteil der Dinge, die in "init base" passieren, werden optional werden. Da bin ich gerade bei. Man bekommt während der Installation dann entsprechende abfragen, ob man z.B. Advantage Tools deinstallieren möchte oder nicht. Das selbe gilt für snap.
solltest du es _dringend_ ausführlich dokumentieren
Bin ich dran. Jede Option, jeder Parameter, jede Aktion des Tools wird dokumentiert werden.
aus welchem Grund das Skript snaps automatisch deaktiviert und entfernst
Weil ich mich persönlich gegen Snap als Paketmanager entschieden habe und mich um Abhängigkeiten und dergleichen selbst kümmern möchte. Dies wird später noch optional. Man kann quasi entscheiden, ob man snap behalten möchte oder nicht.
warum du die Ubuntu Advantage Tools deinstallieren willst / musst.
Wie bereits erwähnt, dass wird noch optional. In meinem Fall benötige ich es nicht und wer es nicht brauch, kann es eben entfernen.
Und wenn du schon snap entfernen willst: dann mach' es doch ordentlich.
Ich deaktiviere erstmal alle systemd services die es gibt und anschließend wird jedes Paket, dass "snap" ENTHÄLT entfernt. Also eben auch snapd. Das findet per purge statt, sodass hier komplett abgeräumt wird. Ein autoremove für liegengebliebene Abhängigkeit mit einzusetzen, nehme ich mal mit auf meine Liste.
Sowas wie source /root/gcli/conf/env hat auch in einem Script das andere verwenden sollen nichts zu suchen, /root ist das home vom root, da gehört garnichts hin.
Da ich was meine Kenntnisse noch nicht so weit bin, eigene deb Pakete zu bauen, liegt es aktuell noch im /root Verzeichnis. Ich bin aktuell am Abwägen, ob ich - unabhängig von der Paketerstellung, das Script in /usr/local/ einsortiere und config files (wie das env file) unter /etc/. Oder was wäre da best-practice?
Warum fummelt das Ding an der /etc/skel rum
Warum wird .ssh/authorized_keys per /etc/skel verteilt?
Überbleibsel von privatem Setup. Fliegt raus. War für mein privates Home-Setup um alle Benutzer, auch neu-erstellte über den selben SSH Key zu erreichen da PasswordAuthentication aus ist. Und ansonsten für die Prompt, damit alle user die selbe Prompt haben...Siehe beim nächsten Zitat.
Und was an der .bashrc von root?
Eine hilfreichere Prompt (mit RC, Zeitstempel, workdir, hostname, $/#) und dafür das komplette "default" styling der prompt raus
Und was geht dem Tool meine sshd_config an?
Macht im Endeffekt nichts anderes als X11Forwarding aus, Password-Auth aus, root Login aus, PrivKeyAuth an, authorized_keys Pfad definieren und steht im Zusammenhang mit der Erstellung des sudo-Users. Warum? Viele v/Cloud Server Anbieter haben nur den root-User und fügen keinen sudo-User hinzu. Soll in Richtung mehr Sicherheit für den SSH Server schubsen.
Dein Problem wurde z.B. von Ansible & Co schon gelöst
Spiele tatsächlich auch schon mit der Überlegung, die komplette Einrichtung (Base, LAMP+Mail) über Ansible stattfinden zu lassen. Da ja eben das Tool eigentlich nur das CLI Tool für den LAMP+Mail Stack werden soll - unabhängig ob du dich eben für/gegen Snap/Advantage Tool entschieden hast. Der LAMP+Mail Stack müsste dann aber halt eben übers Ansible PlayBook installiert werden, damit das CLI Tool kompatibel ist (gerade im Bezug auf Mail).
Im Endeffekt soll es ein CLI Tool zur Verwaltung eines LAMP Stacks+Mailserver werden. Das "init base" quasi ein kleine "Überarbeitung" des Base Systems bei dem nahezu alles optional wird. (raus was man nicht braucht, Prompt Styling, SSH auf Public Key mit passenden sudo-User)
Der eigentliche Teil kommt dann erst mit den CLI Commands für die Dienste, die Einrichtung z.B. einer Domain, eines Proxy, einer neuen E-Mail Adresse etc. pp. erleichtern soll.
