[base] installdir

[Christian Fenzl]

Hallo Prof.Mobilux

Ich bin gerade am Werken mit LoxBerry::System und hätt eine Frage zur general.cfg

Dort ist im Bereich BASE der INSTALLFOLDER mit /opt/loxberry definiert.
Wie ist das gedacht? Ich meine, für wen wird das benutzt?

Wenn das System startet, dann ist das loxberry-Home auf /opt/loxberry gesetzt.
Wer muss in Folge den INSTALLFOLDER auswerten?

lg, Christian

[Prof.Mobilux]

Ich wollte es ermöglichen den LoxBerry auch in ein anderes Basis-Verzeichnis zu installieren, damit es möglichst System-unabhängig ist. Denkbar wäre ja z. B. dass jemand ein Image für Windows bereitstellt und LoxBerry in c:\loxberry installiert. Dann bräuchte man "nur noch" einen Wrapper für apt-get bereitstellen.

Ob das jemals kommt weiß ich auch nicht so genau :-) Ich habe auf jeden Fall imer versucht keine harten Pfade zu verwenden. Aus dem gleichen Grund sind auch die Pfade zu den verschiedenen Binaries in der general.cfg.

[Christian Fenzl]

get_binaries in LoxBerry::System ist gerade fertig geworden :-)

[Christian Fenzl]

Ich hoffe, dass Wörsty nichts dagegen hat, aber jetzt ist indirekt miniserverbackup zum Testobjekt für LoxBerry::System geworden, weil ich das Passwort-Problem endgültig lösen möcht.

[Prof.Mobilux]

Das ist cool :-) Am Miniserverbackup haben sowieso schon soviele herumgespielt - da kommt's jetzt auf einen mehr oder weniger auch nicht mehr drauf an :-)

Ich bastel gerade an einem neuen Plugin, um meine Stromzähler auszulesen. Dabei habe ich meine ganzen "Altlasten" mal über Bord geworfen und ein "Best Practise" index.cgi entworfen. Das könnte die Basis für ein neues Sample Plugin werden, natürlich dann noch gespickt mit LoxBerry::System, was ich noch nicht drin habe. Das Ganze könnte man dann im Detail im Wiki mal erklären (was macht was und warum).

Ich poste das später mal separat zur Diskussion.

[Christian Fenzl]

Die Frage ist, darf LoxBerry::System das Homedir den Plugins bereitstellen, oder muss es mit dem homedir erst in die General.cfg gehen und das installdir lesen. Ich spar mir aktuell initial den Weg ins Config und verwende direkt das Homedir.

[Prof.Mobilux]

Ich denke Du kannst das Homedir direkt den Plugins zur Verfügung stellen. Was machen wir denn in den Plugins heute?

use File::HomeDir;
my $home = File::HomeDir->my_home;
$cfg = new Config::Simple("$home/config/system/general.cfg");
$installfolder = $cfg->param("BASE.INSTALLFOLDER");

Damit musst Du Dir sowieso schon helfen, um überhaupt BASE.INSTALLFOLDER auslesen zu können. Damit ist es dann auch obsolete und Du könntest gleich folgendes machen:

use File::HomeDir;
my  $installfolder = File::HomeDir->my_home;

[Christian Fenzl]

Passt, genauso passiert's in LoxBerry::System.

[Christian Fenzl]

Für die ganzen IO-Tests bräuchte es fast einen Test-Miniserver. Ich muss die ganze Zeit mein Haus "rebooten", wenn ich verschiedene Passwörter teste.
Vielleicht sollten wir uns sowas mal anschaffen, irgendwo freigegeben.

[svethi]

Genau, der braucht ja keine funktionsfähigen Relays etc.

[Peter B]

Ich hätte noch einen übrigen Reserve Go MS soll Ich euch den aufstellen mit Portforwarding?

[Christian Fenzl]

Peter B Das wäre natürlich sehr cool!
Mit CloudDNS, dann könnte ich das MSBackup selbst testen. Du musst aber wirklich aufpassen, dass alles sicher konfiguriert ist.
Lg, Christian

[svethi]

Wenn man den Loxberry in eine anderes Verzeichnis haben möchte, dann gibt's eh Rechteproblem und es müsste eh am Besten wieder das Home von loxberry sein.
Wir hatten die Diskussion ja jetzt erst wieder mit der Installation auf anderen Systemen. Ich verstehe das Ganze ja so, dass mit dem Loxberry Leute, die keine Ahnung von Linux etc. haben eine einfache Möglichkeit zu bieten Zusatzfunktionen für den MiniServer verwenden zu können. Daher sollte das Hauptaugenmerk ja darauf liegen. Dies ist mit dem Image für die Installation gegeben. In diesem Image wird stets das loxberry-Homedir auch das Installdir sein. Warum das Ganze verkomplizieren? Der Loxberry ist im Grunde nur eine Scriptsammlung und läuft eigentlich auf jedem Linux so wie es ist. Es lässt sich daher über das Installscript auch auf bestehende Systeme installieren. Allerdings sind hier dann auch die bestehenden Installationen zu beachten und dass können und wollen wir gar nicht abdecken. Wenn jemand ein bestehendes System um Loxberry erweitern will, dann kennt er auch sein bisheriges System und sollte wissen was er tut. Wenn er es dann auch noch in einen anderen Ordner haben will, bitte, kann er ja machen, dann kann er es aber auch selbst anpassen. Windows ist hier noch was ganz was Anderes. Das sind dann noch ganz andere Sachen anzupassen und ich glaube nicht, dass irgendeiner hier Support dafür leisten möchte, oder?
Christian Fenzl gibt es schon Informationen zum Loxberry::System? Ich hatte ja angefangen mit dem Loxberry Backup sowie Auslagern auf externe Platte etc. Ich bin noch nicht sehr weit. Meinst Du, ich könnte/sollte mich gleich schon damit beschäftigen??

Im Übrigen halte ich mich mal aus dem MiniServer-Backup raus :-)
Oder, ich könnte eine Funktion gebrauchen ;-). Christian, mit lftp kann man auch zurückspielen. Cool wäre, wenn man zumindest die SVG's wieder herstellen könnte. Die werden nämlich von der Config auch ausgelassen wenn sie im Backup vorhanden sind.

[Prof.Mobilux]

svethi Mir geht's eher darum, dass es eventuell später mal eine offizielle Portierung auf irgendein anderes System geben könnte. So wie es die VM-Version ja auch schon gibt. Mir geht es nicht darum, ob hier jemand den Loxberry auf seinem bestehenden System installieren möchte.

Wir sollten solche Dinge nicht verbauen, wenn es nicht unbedingt sein muss. Mehr möchte ich doch gar nicht ;-)

[svethi]

Okay, verstehe. Dann ist es aber vielleicht doch nicht so gut am Homdir festzuhalten, denn die Ordnerstruktur und komplette Rechtegeschichte wäre ja dann unter Windows ganz anders.
Habe mir die Bash unter Windows noch nicht angesehen. Keine Ahnung, ob man die dazu gebrauchen könnte. Wäre natürlich einfacher 😀

[Wörsty]

Das mit den SVG muss unbedingt rein! Das nervt mich schon ewig. Am Besten als eigenes Feature / Plugin.
Was haltet ihr von einem SVG-Icon-Save&Restore Plugin
"ICON-SAM" - ICON and Svg Admin Module *lol*
Vielleicht sogar mit Anzeige der Icons und deren Namen.
Viel später möglicherweise mit Administration und hinzufügen von Icons.

[Christian Fenzl]

Bezüglich LoxBerry::System: Da ich das gerade ins MSBACKUP einbaue und implizit Fehlerbehebung/Testing mache, ist es um etwa 2-3 Tage zu früh. In der aktuellen Implementierung (in meinem Fork von Michaels LoxBerry bei GitHub) ist mein aktueller Stand, wo ich im Stundentakt was raufspiele :-)

LoxBerry::System verwendet jetzt primär die System-Umgebungsvariable LBHOMEDIR (das geht auch unter Windows), Fallback 1 ist homedir, Fallback 2 ist /opt/loxberry (hardcoded).

Es wäre zu überlegen, wenn LoxBerry::System und LoxBerry::Web halbwegs stabil ist, das in einem 0.2.4-Update nachzuschießen, bevor es 0.3 gibt.

PS: Doku zu LoxBerry::System ist im Wiki.

[Christian Fenzl]

Auch bezüglich LoxBerry::System: Ich hab noch nicht durchschaut, was es mit den Routinen rund um CloudDNS auf sich hat. Was genau muss da speziell behandelt werden?

[Prof.Mobilux]

Christian Fenzl Wenn ein Miniserver als CloudDNS definiert ist (USECLOUDDNS=1 in der general.cfg), dann findest Du unter CLOUDURL dort die Mac-Adresse. Um dann die IP-Adresse herauszufinden, hatte ich das Skript ~/bin/showclouddns.pl geschrieben.

Wenn Du also die IP-Adresse des Miniservers über einen Aufruf zurückliefern möchtest, müsstest Du prüfen ob es ein lokaler Miniserver oder ein externer ist. Dann entsprechend entweder ~/bin/showclouddns.pl im Modul integrieren oder aber das Skript aus dem Modul heraus nutzen.

[svethi]

Hab das jetzt mal hier gepostet.
Für das Verzeichnisproblem hätte ich folgenden Vorschlag. Die general.cfg ist immer im homedir von loxberry. Also von mir aus auch im Unterordner config oder so. Auch würde ich bei Installation den kompletten Tree da so aufbauen. System.pm kann dann die Pfade ermitteln. Optional kann man dann in der general.cfg für die einzelnen Zweige spezielle Pfade konfigurieren. Z.B. Für data etc. So gibt es grundsätzlich erst einmal eine klare Struktur und wenn man es speziell haben möchte, geht das auch.
Was haltet Ihr davon??

[Christian Fenzl]

svethi Ich weiß ehrlich gesagt nicht, was du genau meinst.

Wenn eine neue LB-Version die Pfade (log, data usw.) in der general.cfg festlegt, und ein Benutzer ändert den Pfad, sind auf einen Schlag alle 24 Plugins kaputt. Die Verzeichnisstruktur lässt sich nur noch über Symlinks ändern, wenn nicht 24 Plugins überarbeitet werden sollen.

Aus meiner Sicht ist das Hauptproblem jetzt eigentlich nur noch, dass die Pfad-Basis das homedir vom User loxberry ist. Bei Daemon und Scripts, die mit anderem User laufen, funktioniert das nicht. Ist der Pfad als Systemvariable gesetzt, hat diese jeder Benutzer im Zugriff.

[svethi]

Es ging mir ganz einfach darum, dass Prof.Mobilux das ja flexibel anlegen wollte, damit die Pfade optional ändern kann wenn man will. Um dem gerecht zu werden und dennoch per Loxberry::System (oder auch generell) die Pfade ermitteln kann, muss es eine feste Größe geben. Der Apache läuft als loxberry und die daemons als root. Also hast Du eigentlich nur mit 2 Usern zu tun. Beide können problemlos und einfach das homedir von Loxberry ermitteln. Ich habe Dir dazu einen Pullrequest geschickt. Damit kennst Du das Installdir und den Pfad zur Konfig. Ist klar, in der jetzigen Version ist die Struktur klar. Es geht ja aber um neue Versionen und Loxberry::System. Auf dem Loxberry läuft standardmäßig miniDNLA und Samba. Ebenso MySQL und was es so an Plugins gibt. Es gibt den Pluginwunsch für externe Datenspeicherung. Was spricht denn dagegen optional das Datadir auf einen externe Platte zu legen? Sicher, man kann das reinlinken, doch da sind dann auch die Inhalte weg (oder merged der die bei ln) bei einem Mountpoint zumindest nicht. Ist klar, wenn das Verzeichnis umgebogen wird, müssen die vorhandenen Daten übertragen werden. Ob nun vom User per Hand, oder durch ein Plugin. Wenn die Verwendung des Modules mal standard ist, gibt dieses dann den aktuelle Dataordner heraus und die Plugins laufen genauso weiter.