[in USE]Webapplikationen automatisch installieren

[Achmed]

Zothos Wrote: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

Jo, machen wir so.
Autogen kann man dann in einer späteren Version als Option mit anbieten.
Hab das meiste davon eh schon in der GUI drin (ist noch nicht im letzten Paket enthalten, was ich geuppt habe).

Zothos Wrote: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.

Workflow deckt sich mit meinen Vorstellungen.

PWD's plain in der DB seh ich nicht so als das Problem, weil die in der ispCP-DB gespeichert werden.
Wenn die da jemand auslesen kann, dann haben wir ganz andere Probleme als ein phpBB.

Zu deinem Edit:
Wenn das Paket geuppt wird, wird es sowieso schon entpackt und die XML ausgewertet.
Irgendwie muss die Beschreibung usw. ja in die Software-DB gelangen.
Da speichert man die benötigten Angaben eben gleich mit ab.

[Zothos]

Ich sehe ein licht am Horizont

Wobei ich mit meiner idee die änderungen der db auch in der xml nicht ganz zufrieden bin. Vielleicht sollten wir gescheiter so etwas machen:

<install>
<database>
<query>UPDATE config SET sitename = 'foobar'</query>
</database>
</install>

Den Query direckt in die xml schreiben. So haben wir ein wenig mehr freiheiten, wenn der Query ein wenig komplizierter wird. Und eben nicht noch zusätzliche install.php files.

Die Config wird über Platzhalter erzeugt, das ist weiterhin so ok. Doch jede andere änderung die irgendwo z.B bei phpbb gemacht werden muss. Würde ich über eine patch relaisieren.

<install>
<files>
<patch>setFooterToIspcp.patch</patch>
</file>
</install>

Dann haben wir eine rießige anzahl an Möglichkeiten. Das sollten wir mit aufnehmen.

Quote:Zu deinem Edit:
Wenn das Paket geuppt wird, wird es sowieso schon entpackt und die XML ausgewertet.
Irgendwie muss die Beschreibung usw. ja in die Software-DB gelangen.
Da speichert man die benötigten Angaben eben gleich mit ab.

ok, perfekt

Quote:Autogen kann man dann in einer späteren Version als Option mit anbieten.

nicht im ersten entwurf. Sowas wäre perfekt für die roadmap

Greez
Zothos

[Achmed]

Ok, hab mal ne neue XML erstellt.
Die wesentlichen Änderungen:

Code:

    <settings>
        <req-conf>true</req-conf>
        <req-patch>false</req-patch>
        <req-sql>true</req-sql>
        <req-ftp>false</req-ftp>
        <req-cgi>false</req-cgi>
        <req-account>true</req-account>
        <req-email>true</req-email>
        <req-path>false</req-path>
        <file-settings>
            <file>
                <path>/</path>
                <chmod>755</chmod>
            </file>
            <file>
                <path>/config.php</path>
                <chmod>444</chmod>
            </file>
            <file>
                <path>/cache/</path>
                <chmod>777</cache>
            </file>
            <file>
                <path>/images/avatars/upload/</path>
                <chmod>777</chmod>
            </file>
        </file-settings>
    </settings>

<req-patch> entscheidet darüber, ob nach <patch> geparsed wird, im Installations-Teil der XML.

Code:

    <install>
        <config-file>/config.php</config-file>
        <sql>
            <file>sql.sql</file>
        </sql>
        <sql-querys>
            <query>UPDATE @@database_prefix@@config SET config_value = '@@email@@' WHERE config_name = 'board_contact' OR config_name = 'board_email'</query>
            <query>UPDATE @@database_prefix@@config SET config_value = '@@dmn_name@@' WHERE config_name = 'server_name' OR config_name = 'cookie_domain'</query>
            <query>UPDATE @@database_prefix@@config SET config_value = '@@path@@' WHERE config_name = 'script_path'</query>
            <query>UPDATE @@database_prefix@@users SET user_password = MD5('@@password@@') WHERE username = 'admin'</query>
        </sql-querys>
        <vars>
            <var id="name">
                <value></value>
                <replace>@@name@@</replace>
            </var>
            <var id="password">
                <value></value>
                <replace>@@password@@</replace>
            </var>
            <var id="email">
                <value></value>
                <replace>@@email</replace>
            </var>
            <var id="database_type">
                <value>mysql</value>
                <replace>@@database_type@@</replace>
            </var>
            <var id="database_port">
                <value>3306</value>
                <replace>@@database_port@@</replace>
            </var>
            <var id="database">
                <value></value>
                <replace>@@database@@</replace>
            </var>
            <var id="database_user">
                <value></value>
                <replace>@@database_user@@</replace>
            </var>
            <var id="database_password">
                <value></value>
                <replace>@@database_password@@</replace>
            </var>
            <var id="database_host">
                <value>localhost</value>
                <replace>@@database_host@@</replace>
            </var>
            <var id="database_prefix">
                <value></value>
                <replace>@@database_prefix@@</replace>
            </var>
            <var id="dmn_name">
                <value></value>
                <replace>@@dmn_name@@</replace>
            </var>
            <var id="path">
                <value></value>
                <replace>@@path@@</replace>
            </var>
        </vars>
    </install>

Neu hinzugekomen sind die Querys und die <replace>-Angaben.
Dann kann jeder für seine Pakete eigene Ersetzungen vorgeben und ist nur an die <var id=""> gebunden.

Für die id's muss man sich aber zwangsläufig auf einen "Standard" einigen.
Irgendwie muss das Perl-Script ja zurechtkommen.
So dass z.B. die Pfadangabe immer unter <var id="path"> zu finden ist.

Hab mal die neue XML angehängt, diesmal aber ohne upgrade und remove.

Wenn das dann soweit für alle OK wäre, würd ich als nächstes die SQL-Tabellen anpassen (software-db) und mit dem perlen und der GUI anfangen.

[Zothos]

Fast perfekt:

&ouml; geht absolut nicht, codier die xml in utf-8 und nimm das gute alte ö Gleiches für alle anderen Umlaute usw XD

<config-file>/config.php</config-file> müsste das nicht dann
<config-file>./config.php</config-file> sein?

Code:

<var id="database_prefix">
                <value></value>
                <replace>@@database_prefix@@</replace>
            </var>

was hat denn das value zu bedeuten?

eine frage auch zu den <req-xxx> bereichen. Könntest du hier am besten zu jedem einen bsp eintrag machen? Und genauer erklären was diese bereiche bewirken?

Greez
Zothos

[Achmed]

Nur mal auf die Schnelle, weil ich weg muss.:

Zothos Wrote:&ouml; geht absolut nicht, codier die xml in utf-8 und nimm das gute alte ö :) Gleiches für alle anderen Umlaute usw XD

Ok, gibt halt nur Probleme bei Leuten, die DefaultCharset geändert haben. *denk*
Deshalb ja <![CDATA[, damit die Umlaute nicht von XML geparsed werden.

Zothos Wrote:<config-file>/config.php</config-file> müsste das nicht dann
<config-file>./config.php</config-file> sein?

Nein, das ist die Zieldatei.
Geht immer vom Zielordner aus, also im Forenhauptverzeichnis.

Zothos Wrote:

Code:

<var id="database_prefix">
                <value></value>
                <replace>@@database_prefix@@</replace>
            </var>

was hat denn das value zu bedeuten?

Wenn <value> leer ist, wird entsprechend der Wert aus der DB genommen. Wenn nicht, wird dies als Wert genommen.
Bsp:<var id="database_host">
Ist momentan immer localhost, da alles andere von ispCP eh noch nicht unterstützt wird.
Gleiches gilt für den DB-Port.
Also muss man beim Kunden auch keine Abfrage diesbezüglich machen.
In 10 Jahren dann, wenn es Möglich ist, alle Dienste auf extra Server auszulagern, kann value dann leer beleiben. ;)

Beim Prefix ist aber immer ein Wert in der DB vorhanden.
Entweder der Default-Wert (phpbb_) oder eben das Prefix, daß der Client vorgibt. Also bleibt value leer, dann weiss das Script dass es auf eine Var aus der DB zurückgreifen muss.

Zothos Wrote:eine frage auch zu den <req-xxx> bereichen. Könntest du hier am besten zu jedem einen bsp eintrag machen? Und genauer erklären was diese bereiche bewirken?

Greez
Zothos

<req-conf>true</req-conf>:
Im <install>-bereich wird nach <config-file> gesucht.

<req-patch>false</req-patch>:
Wie oben wird nach <patch> gesucht.

<req-sql>true</req-sql>:
Sucht nach sql-speziefischen Angaben im <install>-Bereich und sorgt dafür, dass entsprechende Abfragen (DB, DB-User, DB-Passwort) in der GUI erscheinen.

<req-ftp>false</req-ftp>:
Nur für die GUI wichtig.
Jommla 1.5 will z.B. einen FTP-Zugang. Da muss dann natürlich eine Abfrage in der GUI stattfinden.

<req-cgi>false</req-cgi>:
Wenn beim Client CGI nicht eingestellt ist, bekommt er dies angezeigt.
Ausserdem erwartet die XML dann auch eine Anweisung was in den cgi-Ordner kopiert werden muss. (In den <file-settings>).

<req-account>true</req-account>:
Ist ein Benutzername und ein Passwort notwendig? (GUI)

<req-email>true</req-email>:
s. <req-account>

<req-path>false</req-path>:
Sind noch zusätzliche Pfad-Angaben notwendig, die aus dem abs. Pfad generiert werden müssen?
Angaben dazu dann unter <settings> oder <install>

[Zothos]

ah perfekt

Gut, bin damit mehr als nur zufrieden. Als doku, sollten wir noch eine vollständig kommentierte xml erstellen. Und jetzt ran an die Arbeit

[ZooL]

das ist schön zu lesen, das ihr das konzept oder den weg der arbeit geklärt habt...
nun freue ich mich Persöhnlich auf ein Neues Produkt.

Braucht ihr eventuell eine Liste für die z.B von meinen leuten Geforderten Packete?
bin gerne bereit da eine kleine Liste zu erstellen was erstmal Wichtig wäre...

mfg

[Zothos]

Erstmal ist es wichtig das system ans laufen zu kriegen. Alles andere kommt sobald es stable ist

[Achmed]

Mal ne ganz doofe Sache, die mir grad noch eingefallen ist.:
Ich persönlich fände es gut, wenn sowohl der Admin als auch der Reseller Pakete anbieten können.

Der Admin setzt Pakete rein, die für alle zugänglich sind, und der Reseller eigene Pakete, die seiner Meinung nach noch fehlen.

Wir haben aber in Gegensatz zu APS keine zentrale Stelle, wo es die Pakete gibt, und somit eigentlich auch keine Möglichkeit der Zertifizierung / Validierung.

Bisher hatte ich das so gehandled, dass der Admin die Reseller-Pakete freischalten musste, und vorher noch die Möglichkeit hatte diese zur Kontrolle runterzuladen.

Find ich jetzt aber ein wenig umständlich.

Fällt Euch dazu noch was ein?

@ Zool: Wird nun auch noch ein paar Tage dauern.
Da ich gerade eben die SQL-Tabellen komplett umgestrickt hab, muss ich auch den Großteil der Gui wieder ändern.

[ZooL]

das ist ja kein problem,
nur ich glaube ich persöhnlich brauche mehr als 1. beispiel
packet um zu checken was ich zusammen schrauben muss um mir ein eigenes packet
zu bauen...
ansonsten Zothos fühl dich nicht unter Druck gesetzt oder sonst was hab es ja nur gut gemeint.

mfg