[in USE]Webapplikationen automatisch installieren

[Achmed]

Das Php-Script soll die App-Spezifischen Sachen machen, die man nicht so Pauschalisieren kann.
Benutzer / Config-Daten in DB eintragen und so Sachen.
Das wird temporär nach htdocs kopiert und unter dem User aufgerufen, unter dem die Anwendung später laufen soll.
Ausserdem sind glaub ich mehr Leute in der Lage ein Php-Script zu schreiben, als ein Perl-Script.

Alternativ kann man natürlich jede noch so kleine Eventualität in der XML berücksichtgen, dann wird die aber ggf. sehr gross, genau wie das Perl-Script, daß die XML auswertet.

[Zothos]

Ich würde einen anderen weg gehen. Vielleicht sogar ein wenig einfacher.

Hier mal ein wenig wie es ablaufen sollte am bsp phpbb:

- Kopieren der htdocs daten aus dem packet nach /var/www/virtual/domain.tld/gewünschtesVerzeichnis
- chown/chmod nach vuxxxx und entsprechend der xml
- anpassen der config.php config.inc usw -> füllen mit den daten aus der xml + automatisch generierte (z.B der db name) pw könnte man einfach festlegen auf phpbb_vuxxxx ( das ganze per .patch? )
- die db wird erzeugt (random name?). die sql daten werden in die db geschoben

Wenn wir dynamisch sagen könnten, was er in welcher config.php usw ändern soll, wären wir flexibler als wenn wir mit einer art internen browser arbeiten müssten.

die xml wäre dann auch nicht ganz so groß.

[tango]

bis auf einem Punkt bin ich mit Zothos selbe Meinung, anstatt vorgegebenen DBuser bzw. DB namen sollte jeder die Möglichkeit haben, selber in ISPCP Panel einzugeben und dieses Wert sollte als Variable definiert werden und dann während der Installation die Variablen einfügen.

[Achmed]

Zothos Wrote:Ich würde einen anderen weg gehen. Vielleicht sogar ein wenig einfacher.

Hier mal ein wenig wie es ablaufen sollte am bsp phpbb:

- Kopieren der htdocs daten aus dem packet nach /var/www/virtual/domain.tld/gewünschtesVerzeichnis
- chown/chmod nach vuxxxx und entsprechend der xml
- anpassen der config.php config.inc usw -> füllen mit den daten aus der xml + automatisch generierte (z.B der db name) pw könnte man einfach festlegen auf phpbb_vuxxxx ( das ganze per .patch? )
- die db wird erzeugt (random name?). die sql daten werden in die db geschoben

Wenn wir dynamisch sagen könnten, was er in welcher config.php usw ändern soll, wären wir flexibler als wenn wir mit einer art internen browser arbeiten müssten.

die xml wäre dann auch nicht ganz so groß.

Das soll ja im Prinzip auch so passieren.

Das einzige Problem sind die Sachen, die in die DB eingefügt werden müssen, und die normal bei jeder App anders sind.
Nur dafür ist das Php-Script gut.

Da ein phpBB einen ganz anderen Tabellenaufbau hat als z.B. ein Joomla, wüsste ich nicht, wie wir die Insert-/Update-Anweisungen automatisieren könnten.

Es sei denn, die sind alle schon in der SQL-Datei drin, dann hat aber jedes phpBB das damit installiert wurde den gleichen Admin-Account mit dem gleichem Passwort. Die absoluten Pfadangaben wären überall gleich. Usw.

Das läßt sich nur durch ein externes Install-Script lösen. *denk*
Und zwar eines, was genau auf die Bedürfnisse der Applikation zugeschnitten ist.
Sonst hast du in der XML einen Haufen im Prinzip sinnloser Variablen drin.
Jede Tabelle und dazu jedes Feld das geändert wird müsste man so definieren.
Bei Joomla:
Tabelle users; Felder username, user_password, user_email
Tabelle KA (Hab mich noch nicht damit beschäftigt, was bei Joomla alles angepasst werden müsste in der DB.)
Bei phpBB:
Tabelle users; Felder username, password, email
Tabelle config; Felder ...
Da ist jedenfalls schon mal der Tabellenname gleich.
WBB hat wiederum in der Gratis-Variante keine Tabelle config, sondern eine Tabelle options....usw.

6 Felder updaten = 12 Variablen (Tabelle und Feld) + 6 Variablen für die neuen Werte. (Und es wird des Öfteren mehr als 6 Updates sein.)
Das dann über eine Schleife abarbeiten.
Ich fürchte halt, da blickt kein Schwein mehr durch.

Noch schlimmer wird es, wenn du eine Applikation upgraden willst.
Wenn es nur darum geht ein paar Dateien auszutauschen, ist das ja schnell automatisch gemacht (soll es ja auch).
Wenn dabei aber umfangreiche Änderungen an der DB vorgenommen werden, hast du so ziemlich verloren.

@ tango: Die DB-User sind nicht das Problem, die werden eh in ein config-file geschrieben. Das Problem sind die pers. Daten, die in die DB reinmüssen.

[Zothos]

bei joomla und phpbb brauchst du nicht die hauseigene install.php verwenden um es zum laufen zu bekommen. Da reicht es die daten zu kopieren, die leere tabellenstrucktur in die db zu schaufeln und die config anzupassen. Dann fehlt nur noch der admin user.

und nein, nicht jedes installierte joomla hätte dann den selben admin user usw. Man könnte einfach ein pw generieren und es dem user dann per mail zuschicken an die mailadresse welche hinterlegt ist. Das ist kein Problem. Gleiches für die pfadangaben.
Man müsste nur in der xml definieren das dieses feld das pw feld ist. Das selbe für das pfad feld. Diese Variablen würden dann während der installation bestimmt und vom installer (dein perl script z.b) mit den richtigen werten gefüllt.

Ein upgrade z.B von phpbb ist nicht das problem. Einfach alle dateien löschen bis auf die config.php, dann die neuen rüber kopieren chmodden chownen. Und dann als beispiel die uprade_2_0_13_to_2_0_14.sql in die db schubsen. Wobei ich fast sagen würde, für den ersten entwurf sehen wir nur install und deinstallation vor.

Die schwierigkeit liegt nur daran, die vielen verschiedenen applikationen über eine generische install routine dem kunden auf den space zu hauen. Das will wohl durchdacht sein. Die xml ist nur ein kleiner bestandteil der ganzen geschichte.
Schön zu wissen wäre es wie aps/asp (swsofts standard) das ganze gelöst hat.

[ZooL]

Zothos,

du hast recht in dem was du schreibts.. nur ich glaube Achmed meint im Moment noch etwas anderes in sachen verschiedene Packete sind wohl die Tabellen das Problem was er meint.
Wegen dem Dynamisch darstellen.

Besonders hat mir das hier an deinem Post ja gefallen.

Quote:Schön zu wissen wäre es wie aps/asp (swsofts standard) das ganze gelöst hat.

und da stimme ich im Moment wohl zu, als denkanstubser wäre das wohl
das richtige.. ich kann euch ein Komplettes programm zur verfügung
stellen das auch Applikationen in eine Oberfläche installiert es ist glaube
ich auf french oder Englisch gehalten sollte wohl kein problem sein
müsste ich jetzt nur nach gucken. bei interesse schicke ich es dir
Achmed oder Zothos.


mfg

[Achmed]

Zothos:
Ich glaube wir reden aneinander vorbei.
Ich will ja gar nicht die install.php aus dem phpbb-Paket laufen lassen.
Ich rede davon eine eigene php-Datei anzuschmeissen, bei der halt noch ein paar SQL-Querys verwurschtelt werden.
Ungefähr so:

PHP Code:

$query = "UPDATE config SET config_value = '".$email."' WHERE config_name = 'board_contact' OR config_name = 'board_email'";
$query = "UPDATE config SET config_value = '".$dmn_name."' WHERE config_name = 'server_name' OR config_name = 'cookie_domain'";
$query = "UPDATE config SET config_value = '".$pfad."' WHERE config_name = 'script_path'";
$query = "UPDATE users SET user_password = MD5('".$password."'), email = '".$email."' WHERE username = 'admin'"; 


Oben drüber noch den DB-Connect, zwischendrin die Querys ausführen.
Fertig.

Da man aber (je nach App) ganz unterschiedliche Felder und Tabellen updaten muss, weiss ich nicht, wie wir das über das Perl-Script mit Hilfe der XML-Daten sinnvoll automatisieren können.

Nochmal: Der ganze Rest (kopieren, config anlegen, Rechte setzen) seh ich überhaupt nicht als Problematisch an, nur eben diese paar DB updates.

P.S. Paketaufbei bei APS:

Code:

APP-META.XML

images/
    bild.png
    bild.png
    bild.png

htdocs/
    das Forum (Dateien)

scripts/
    ein paar php-Dateien
    ein paar SQL-Dateien
    config-Datei (Vorlage)

Die machen das wohl genauso.

Die lassen sogar noch die config-Datei über die PHP-Scripte erzeugen (hab grad mal reingeguckt), was ich aber eher mit dem Perl-Install-Script machen würde.:

Client wirft installation über GUI an ->
rqst-mngr wirft sw-mngr an ->
sw-mngr wertet xml aus ->
sw-mngr erstellt die config-Datei ->
sw-mngr füllt die Datenbank ->
sw-mngr startet die PHP-Datei (Änderungen an den Tabellen...s.o.) ->
sw-mngr verschiebt das nötige aus /tmp in das User-Verzeichnis ->
sw-mngr setzt die benötigten Zugriffsrechte ->
sw-mngr setzt die App in der ispcp-db auf "ok"
Fertig.

edit: Kleinigkeiten wie das Anlegen von Ziel-Foldern im User-Verzeichnis hab ich jetzt mal weggelassen.

[Zothos]

Ok, jetzt verstehen wir uns Haben tatsächlich aneinander vorbei geredet.

Mit der sql geschichte würde ich es anders bewerkstelligen. Den kompletten scripts/ Ordner von aps würde ich kippen, dafür entsprechende xml einträge ala

Code:

<install>
   <database>
       <name>automatic</name>
       <table>config</table>
            <field>email<field>
            <value>customer_email<value>
    </database>
</install>

jeder feld und value eintrag würde z.B "UPDATE fooo SET email = customer_email"
auslösen. So könnten wir das meiste zentral in der xml angeben. Und es würde entfallen das wir uns zu sehr über viele files verstreuen. Das kiss prinzip eben.

Am obigen beispiel sieht man auch gut was ich mit automatisch erzeugten values meine. Bei der db, der dbname ist auf automatic gestellt. Dieser wird vom sw-mngr generiert (anhand bestimmter regeln). Der sw-mngr erstellt dann auch die db, und den user. Customer_email ist ein platzhalter für die im panel hinterlegte eMail adresse.

So sollte es dann aussehen:

Client wirft installation über GUI an ->
rqst-mngr wirft sw-mngr an ->
sw-mngr wertet xml aus ->
sw-mngr erstellt die config-Datei ->
sw-mngr füllt die Datenbank ->
sw-mngr ändert die db anhand der xml ->
sw-mngr verschiebt das nötige aus /tmp in das User-Verzeichnis ->
sw-mngr setzt die benötigten Zugriffsrechte ->
sw-mngr setzt die App in der ispcp-db auf "ok"
Fertig.

Für den anfang wäre ich jedoch auch mit der aps idee zufrieden Dann könnte wir aber auch gleich den aps standard unterstützen. Sinnvoll wäre das definitiv. Würde uns unglaublich von den Restlichen Controlpanels abheben. Nur hier wäre vorher zu klären ob wir das überhaupt dürfen. Bin mir da immernoch nicht so ganz sicher.

[Achmed]

APS machen wir hinterher, wenn das "eigene" Format soweit zufriedenstellend funktioniert. *denk*
Ich werd das in der DB aber schon Mal berücksichtigen (Feld 'ispcp' 1/0).
Deine Idee wegen der SQL-Anweisungen in der XML werd ich mal so aufgreifen.

Die Config wollt ich nach Vorlage erstellen lassen:
Config-Vorlage Zeilenweise einlesen -> ersetzen von Platzhaltern durch "richtige" Werte -> >> config.php.
Oder aber mit sed direkt ersetzen.
Bei APS steht z.B. sowas in der Vorlage:

Code:

$dbname = '@@DB_MAIN_NAME@@';

DB dynamisch erstellen find ich aber nicht so gut.
Dann muss man ja die Arbeit doppelt machen (Überprüfung, ob der Client/Reseller noch weitere DB's anlegen darf.).
Ausserdem muss man die Passwörter irgendwie in der GUI unverschlüsselt anzeigen lassen, damit der Client die Möglichkeit hat Zugriff auf diese DB zu nehmen. (Find ich doof.)
Dann lieber eine feste Vorgabe, die der Client in der GUI vorgibt. Wenn er es dann vergisst, ist das sein Problem.
Beim Endverbraucher geh ich halt immer davon aus, daß er zu doof ist, ein Passwort aus dem Config-File zu holen.
Wenn er es nicht wäre, bräuchte er auch kein "Auto-Install".

[Zothos]

Zur config datei: Muss ich dir zustimmen. So ähnlich würde ich es auch machen.

Zur Db geschichte: Wir könnten ja die ganzen abfragen usw in die gui packen. Sprich, der user kann erst gar kein packet installieren wenn keine db mehr frei ist.
Und mit der problematik des pw/users. C-panel macht es jedenfalls so das man gefragt wird wohin das packet installiert werden soll und dann muss man packet spezifische angaben machen. Gewünschte db name, user, pw, email. Genauso würde ich es auch anpacken. Meine idee mit dem autogenerieren wäre zwar cool, aber würde mehr arbeit machen XD

Hier mal ein workflow:
Client wählt zu installierendes packet ->
Client wählt gewünschtes installatiosnverzeichnis ->
Client gibt gewünschten dbname/user/pw/mail ein (packet spezifisch)->
Client wirft installation über GUI an ->
rqst-mngr wirft sw-mngr an ->
sw-mngr wertet xml aus ->
sw-mngr erstellt die config-Datei ->
sw-mngr füllt die Datenbank ->
sw-mngr ändert die db anhand der xml ->
sw-mngr verschiebt das nötige aus /tmp in das User-Verzeichnis ->
sw-mngr setzt die benötigten Zugriffsrechte ->
sw-mngr setzt die App in der ispcp-db auf "ok"
Fertig.

Dabei müssten wir leider nur die Daten plain in der db speichern.

EDIT: dort wo (packet spezifisch) steht, müssten wir leider auch die xml auswerten.