Mein Vorschlag, für webcfg die Wahl des Starttyps weg zu lassen, kommt mehr aus diesen Überlegungen:
- man sollte etwas da einschalten können, wo man es auch ausgeschaltet hat.
- Er zielt auf Basic-User, die freetz mehr von aussen betrachten und die Interna nicht kennen (warum auch immer).
- Solche kommen nicht auf die Idee, dass sie sich damit aussperren
- Sie benutzen webcfg, weil ihnen telnet und shell-Kommandos nicht geheuer sind. Damit würden sie versehentlich erst recht Unheil anrichten.
- Forscherdrang: Die Details vieler Funktionen findet man dadurch heraus, dass man sie ausprobiert. Und bei allen anderen Moduln kann man die Konfiguration problemlos wieder rückgängig machen, wenn einem das Resultat nicht gefällt.
- Robustheit: Das System muss den Benutzer nicht sofort bestrafen, wenn es nicht perfekt bedient wird.
Dass sich bisher keiner ausgesperrt hat, führe ich eher darauf zurück, dass sich bisher hauptsächlich Profis und Semi-Profis damit beschäftigen. Eben Leute, für die ein Web-GUI eher Komfort als Notwendigkeit ist und die natürlich einfach wissen, wie der richtige Befehl heisst.
Ich hoffe auf euer Verständnis.
Nachschlag:
Wenn man Starttyp auf
inetd stellt und später irgdenwann mal ein freetz baut, wo inetd nicht mehr drin ist (z. B. weil man gedacht hat, man könnte damit Platz sparen), dann ist man in die gleiche Falle getappt. Auch hier bitte ich um mehr Robustheit. Auch wenn es die interne Systematik stört: webcfg ist einfach kein Modul wie alle anderen. Manche sind eben gleicher
PS:
Auch ich habe nach einigen Stunden Forschung den Nutzen von
rc.webcfg start gefunden. Sonst hätte mein Beitrag die Überschrift: HILFE freetz hat mich ausgesperrt!
