Alternative zu power off / restart system

In der v6 wurden die Button (Funktionen) für restart system und power off entfernt.

Nicht jeder Nutzer ist so webaffin oder computerorientiert oder kann mit /auf der Console via ssh umgehen.
Aber gerade für diese Zielgruppe war bislang pihole auf Grund der Einfachheit und Nutzerfreundlichkeit eine Möglichkeit, das Heimnetz zu schützen.

Nun gibt es immer Situationen, in den selbst für diese Nutzergruppe notwendig sein wird, entweder das System (z.B. einen Raspi) neu zu starten oder auszuschalten. Und wenn es z. B nur darum geht die SD Card zu tauschen (warum auch immer...)

Einfach den Netzstecker zu ziehen verbietet sich bei jedem OS, also auch beim OS, auf dem pihole läuft.
Warum muss hier sicher nicht erklärt werden.

Spätestens nach größeren Updates/Upgrades des RaspiOS (also aktuell Debian/Bookworm) wird allgemein ein reboot des System angeraten. Auch das wird Konsens sein.

Frage:
Welche Möglichkeit hat der unbedarfte Nutzer sein System zu rebooten bzw. auszuschalten?
Was ist in dieser Hinsicht bei der v6-Entwicklung berücksichtigt worden.

Danke

(Sorry for answer in English. If you like you can ask for a German speaking user or moderator to answer again)

You need to access the Pi-hole host machine via ssh and use:

sudo reboot
sudo shutdown -h now

For security reasons Pi-hole v6 web interface cannot execute commands using elevated privileges.
Both buttons would need sudo to execute the commands. This is impossible now.
You need to use the normal commands from the operating system, explained above.

Können wir uns darauf einigen, dass wir im deutschsprachigen Teil auch in deutsch kommunizieren?
Danke...

Abgesehen davon wurde das Problem nicht verstanden:
Ich weiß natürlich, wie ich auf der Console agieren kann. Es ging aber darum, dass man bislang nutzerfreundlich reboot und restart auch via UI machen konnte. Stichwort: UX
Aber offensichtlich wurde auch hierbei ohne nachzudenken ein sinnvolles Feature wegrationalisiert.

Gern:
In der v6 wurden die Button (Funktionen) für restart system und power off entfernt.

Nicht jeder Nutzer ist so webaffin oder computerorientiert oder kann mit /auf der Console via ssh umgehen.
Aber gerade für diese Zielgruppe war bislang pihole auf Grund der Einfachheit und Nutzerfreundlichkeit eine Möglichkeit, das Heimnetz zu schützen.

Nun gibt es immer Situationen, in den selbst für diese Nutzergruppe notwendig sein wird, entweder das System (z.B. einen Raspi) neu zu starten oder auszuschalten. Und wenn es z. B nur darum geht die SD Card zu tauschen (warum auch immer...)

Einfach den Netzstecker zu ziehen verbietet sich bei jedem OS, also auch beim OS, auf dem pihole läuft.
Warum muss hier sicher nicht erklärt werden.

Spätestens nach größeren Updates/Upgrades des RaspiOS (also aktuell Debian/Bookworm) wird allgemein ein reboot des System angeraten. Auch das wird Konsens sein.

Frage:
Welche Möglichkeit hat der unbedarfte Nutzer sein System zu rebooten bzw. auszuschalten?
Was ist in dieser Hinsicht bei der v6-Entwicklung berücksichtigt worden.

Danke

Pi-hole v5 lief unter einem privilegierten Nutzer, was ein Sicherheitsrisiko darstellte.

Pi-hole v6 läuft nicht länger als privilegierter Nutzer, so dass eine Ansteuerung von Funktionen, die priviligierte Berechtigungen benötigen, nicht möglich ist.

Um den Rechner neu zu starten oder herunterzufahren, lassen sich die von @rdwebdesign genannten bekannten Kommandos nutzen:

Da der "unbedarfte" User (so wie ich) idR auch ein GUI installieren wird, kann er dort die entsprechenden Aktionen auslösen.

1 Like

Kannst Du bitte mal einen screenshot posten, wo die Button für diese Funktionen zu sehen sind.

Im change log liest sich anders:

Remove "Power off" and "Restart System" buttons by @yubiuser in #2664

Danke...

Danke für die Erklärung.
Dass man jetzt auch ein "sudo" für das update benötigt, hatte ich schon bemerkt.
Ich nehme die Begründung erst einmal zur Kenntnis.

@MasterOfDisaster
Du gehst davon aus, dass PiHole von Normalen Usern benutzt werden soll UND (logisch betrachtet) ein Raspberry Pi niemals Updates oder einen Reboot braucht. Hier muss der Admin mit seiner Console ran, ansonsten sind Sicherheitsprobleme zu erwarten - oha. Wie haben wir nur bis zu 5er Version überlebt?

Nun, ich bin sicher, dass niemand PiHole in Produktiv-Netzwerken im Mittelstand oder Großkonzernen einsetzt, weil das gar nicht erlaubt sein dürfte. Also sprechen wir doch eher um Heimnetze, in denen die Eltern die Admins sind, die selbstredend ihre Surfkids draußen halten müssen. Das Sicherheitsrisiko ist im Heimnetz also beachtlich und muss eliminiert werden, weshalb PiHole abgeriegelt werden muss.

Sei es drum. Ich erwarte keine lösungsorientierte Antworten, es gibt keine. Der falsche Weg steckt im Design. Das ist nur meine Meinung, jeder darf denken und resümieren wie er mag und kann.

Hallo, mein Freund :slight_smile:

Nöööö.... ganz im Gegenteil. Auch der normale User muss zwingend hin und wieder z. B. seinen Raspi neu booten. Aber das schrieb ich ja eigentlich in meinem Post:

Aber egal...

Guckst Du :slight_smile:

DNS Server aus Deutschland

Da war ich schon erstaunt.

Wir werden sonst alle störben... :slight_smile:

Oder "Der Irrweg steckt im falschen Design". Yepp!

Eine schöne Wocher Allerseits

1 Like

Das Temperatur Thema ist nun vorzeitig geschlossen worden. Die Dynamik ist wohl zu groß und der Wille zur Änderung zu klein. Aber das ist nur eine Vermutung.

Deine Umfragen finde ich praktisch und konstruktiv, nur dort findet und liest sie keiner. Auch ist die deutsche Sprache für viele hier nicht ihre Wahl.

Sei es drum. Meine Erwartungen sind niedrig, insofern ist die Enttäuschung marginal.

Es gibt immer mehr IoT Geräte und auch Heimnetzwerke werden immer umfangreicher. Damit steigen auch Sicherheitsrisiken. Die Entscheidung, v6 ohne privilegierte Rechte laufen zu lassen, finde ich daher nachvollziehbar.

Offenbar siehst du die Notwendigkeit von Updates ja ein. Dann erkläre aber bitte, wie das ohne ssh funktionieren soll? Wer per ssh Updates durchführen kann, sollte auch noch ein Neustart oder Herunterfahren hinbekommen. Somit konstruierst du da ein Problem, das in der Praxis gar keines ist.

3 Likes

Na, die Argumentation hinkt dann doch massiv.

Natürlich kann jeder einen Neustart per Terminal anstoßen, der auch ein Update initiieren kann.

Aber: Sicherheit gibt es bei anderen Netzwerkprodukten auch per Webgui. Beispiele sind diverse kommerzielle NAS Systeme und sogar ein OMV, die sogar OS Updates über den Browser starten können.

Ein Benutzermanagement machts möglich.
Dieses fehlt bei pihole, weshalb man sich quasi selbst eingemauert hat.

Andere Ideen sind willkommen.

Das war hier nicht der Punkt. @MasterOfDisaster hat bemängelt, dass in der neuen Version Restart System und Power off entfernt wurden. Diese beiden Funktion machen ohne die Möglichkeit, weitere Verwaltungsaufgaben und Updates über den Browser durchzuführen, aber wenig Sinn. Eben diese Optionen gab es auch unter Pi-hole v5 schon nicht. Die Entfernung der beiden Optionen aus dem Webinterface macht daher keinen greifbaren Unterschied zu v5 für die Wartung.

@Remixer
Ich kann dir bestätigen, dass der Restart und Power off nach den Gravity Updates und DNS Anpassungen, ganz besonders bei der v6, zu den häufigsten Funktionen von mir gehört.

Es geht um Usability, nicht um technisches Gefrickel, mit dem sich die meisten Anwender nicht auskennen. Wenn ich die Gui betrachtet, würde ich mich freuen, individuelle Anpassungen machen zu können (Container, Widgets z.B.). Auch hier finde ich verspielte Funktionen, die für mich keine echte Monitor-Funktion haben.

Aber das Thema ist weit und hier nicht mit einem Konsens zu diskutieren.
Anwender stehen den Devs gegenüber und wer hier am längeren Hebel sitzt, ist offensichtlich. Es hat noch nie geschadet, weder commercial noch non-commercial, Anwender in die Entwicklung einzubeziehen.

@wd9895 Ich nehme wahr, dass du scheinbar allgemein unzufrieden mit Pi-hole, der Version 6 und den Entwicklern zu sein scheinst. Vielleicht wollen wir aber trotzdem beim Thema bleiben.

Es geht um das Fehlen der restart system und power off Funktionen in der Version 6 (im Vergleich zu Version 5) und die Implikationen davon für Nutzer ohne ssh-Kenntnisse. Darauf bezog sich meine Argumentation und ich sehe bis jetzt nicht, warum die hinken sollte?

Dann erkläre ich es dir noch einmal. Vielleicht habe ich mich mißverständlich ausgedrückt.

  1. Ich bin nicht unzufrieden mit der v6, denn sie tut, was sie primär soll. Mir fehlen Funktionen, die vorher da waren und weitere, die nicht nur ich als nützlich und praktikabel empfinden. Wenn du oder der Support nun auf die Feature-Request Liste verweisen, halte ich die sehr mangelnde Sichtbarkeit dieses Unterforums entgegen. Da schaut eh kaum jemand hinein.

  2. Eine Unsicherheit durch die Möglichkeit von OS oder Applikations-Updates oder Restarts zu argumentieren, ist weit hergeholt, siehe genannte Beispiele. Wir befinden uns mit Pi-Hole in einem non-public Netzwerk, es würde reichen, die Gui über ein PW und https Zugang abzusichern. Oder erwartest du Angriffe aus deinem eigenen Netz?

Ich frage mich inzwischen, warum hier Kritik und Vorschläge so vehement abgebügelt werden. Perfekt ist die Software sicher nicht, denn das ist keine Software, aber man kann sie verbessern. Nicht nur technisch, sondern auch in den Funktionen. Es geht ja nicht darum, einen Live-Monitor für den Pi nachzubauen, sondern simple Funktionen, die konfigurierbar sind und den Anwender interessieren.

Ok. Habe ich dann falsch wahrgenommen.

Völlig legitim.

Habe ich nicht.

Das dürfte immer auf das individuelle Setting ankommen und die individuelle Priorisierung von Sicherheitsaspekten. Ich z. B. verwende die genannte Funktionen in der Weboberfläche nie und freue mich über jeden kleinen Baustein, der für mehr Sicherheit beiträgt.

Nimmst du das so wahr?

Korrigiere mich, wenn ich das falsch sehe, aber dir geht es in erster Linie um Nutzererfahrung und einfache Bedienung? Ist legitim, aber darum ging es an dieser Stelle einfach nicht. Im Sinne einer konstruktiven Diskussion bringt es wenig, Argumente durcheinander zu werfen, die auf unterschiedliche Zielsetzungen ausgerichtet sind. Natürlich hinkt mein Argument für dein Anwendungsszenario. Darauf war es aber auch gar nicht ausgerichtet, da es von anderen Grundannahmen und Zielsetzungen ausgeht.

Ich könnte sagen, ein kleines Zweisitzerauto sei toll, weil man in der Stadt leicht einen Parkplatz bekommt. Das ist natürlich richtig, überzeugt aber nicht die Autofahrer, die 4 Kinder haben und damit in den Urlaub fahren wollen. Verstehst du, was ich meine?

Danke für deine Antwort.

Ja, ich nehme es so wahr. Bisher wurde jeder Vorschlag, auch andere, einfach abgelehnt, das Thema umgehend geschlossen. Immer ging es um Usability, auch schon bei der v5. Schau dir bei Gelegenheit die Gui von Openmediavault an und du bekommst ein Gefühl, was ich meine.

Eigentlich hat mich das Konzept des PiHoles sehr überzeugt, insofern ist der Ansatz, es für mehr Anwender verfügbar zu machen und in die Horizonale anstatt die Vertikale (Techies) zu fokussieren, durchaus legitim. Dazu braucht es eine intuitive Gui mit Funktionen, die Anwender verstehen und Funktionen, die helfen können, das System auf dem Laufenden zu halten. An Lakalisierungen denke ich dabei noch gar nicht, wäre aber auch wichtig.

Wenn keine oder kaum neue Anwender(-gruppen) angesprochen werden sollen, bleibt PiHole eine Nische, wenn auch eine sehr praktische, für ein paar Tastatur-Linux-Junkies. Das ist okay für mich, aber widerspricht etwas meinem Anspruch eines nachhaltig gutem Produkt für ein größeres Publikum.

So, nun ist der Beitrag vollends gekapert. Ich hoffe, wir kommen noch zu einer Lösung zu der eigentlichen Frage von MoD.

Ich bin jetzt verwundert, dass Du das nicht so wahrnimmst. :slight_smile: Es hagelt doch an an allen Ecken Kritik, was letztlich auch schon in anderen Posts thematisiert wurde. Und das müsste nicht nur @wd9895 und mir aufgefallen sein.
Die Reaktionen der Entwickler nach dem Motto "Aus! Basta! Wir mach es, wie wir WIR wollen!" lassen doch gar keinen anderen Schluss zu. Kein Zugehen auf die Nutzer.

Ich vermute, jeder User freut sich über leicht bedienbare und gut verständliche Bedienoberflächen. Wenn sie auch noch intutiv zu verwenden sind, steht einer positiven UX nichts im Wege. Positive Nutzererfahrung ist eigentlich der Schlüssel zum Erfolg von Tools, Software oder komplexen Anwendungen.

Man kann aber bei der Entwicklung darauf verzichten, wenn man ein kleines oder großes Monopol hat. Oder das zu haben glaubt.

Die Zielsetzung "Sicherheit" ist sicher richtig. Die Frage ist, wie man Sicherheit und UX in Einklang bringt.
Und dass es auch anders geht, als nur über eine ssh Session, hat @wd9895 schon genannt. Für das Update der Synology DSM auf v7 musste ich ja auch nicht über die Console gehen.

Und bei der v6 stellt sich mir die Frage, was denn überhaupt die Zielsetzung war. Gut - Sicherheit hätte man zusätztlich in die v5 einbauen können. Aber alle anderen Spielereien? Die weggefallenen, liebgewonnenen und nützlichen Feature? Was war da das erklärte Ziel?

Kaum.:slight_smile: Mit dem Hinweis auf die vermeintlich dringend nötige Sicherheit ist die Frage ja beantwortet. Sicherheit + UX können die Entwickler nicht (oder wollen nicht).
Außerdem ist natürlich das Argument "wer Updates kann, kann auch reboot und shutdown" nicht von der Hand zu weisen. Ob es ein Totschlagargument ist, mag jeder anders sehen.

Mir fällt gerade ein: Wozu muss ich mich eigentlich auf der WebUI unter /admin einloggen, wenn sicherheitsrelevante Funktionen doch nicht möglich sind? Ich frage für einen Freund :slight_smile:

Anmerkung:
Auch wenn die Diskussion nun vom eigentlichen Thema wegführt, glaube ich, dass es sehr wichtig ist, diesen grundsätzlichen Gedankenaustausch zu führen.

1 Like