Hallo
Nachdem ich just for fun ein CMS(pagekit) auf meinem Webhost installiert habe, wollte ich bischen deren Doku und API lesen. Beim Punkt Themes stand da: Der einfachste weg ein Theme zu erzeugen ist über die Kommandozeile.
cd path/pagekit
php pagekit themes:generate THEME_NAME
Ok nun verstehe ich das nicht. Wo soll ich das eingeben? Die dateien sind doch auf dem Webserver? Oder habe ich ganz was falsch verstanden.
In der Kommandozeile? Steht doch da.
Ja aber bestimmt nicht lokal auf meinem pc? Ich habe doch nichts lokal laufen.
nun stellt sich die Frage: Hast Du ein Hosting Paket oder einen eigenen (V)Server?
Das php in der Kommandozeile bezieht sich auf eine ausführbare Datei (unter windows z.B. php.exe)!
Du musst dich mit ssh auf deinem Webserver einloggen, in das Verzeichnis gehen und dort den Befehl ausführen
Doch lokal auf deinem pc!
Das du nichts lokal laufen hast ist ja gerade das Problem.
Nur blutige Anfänger, Idioten oder absolute Experten geben diese Befehle über ssh ein. Letztere würden einem tendenziell eher davon abraten dies zu tun.
Lokal XAMP einrichten. php-cli installieren. PHP-Projekt dort entpacken. Per SCM (z.B. git) versionieren.
Dann Befehle lokal ausführen. Testen. Bei Erfolg versionieren und mit release taggen.
Und erst dann lokale Version der Projekt-Dateien per ftp oder rsync auf den Webserver übertragen auf dem die Anwendung laufen soll.
Ist die DB involviert, vor dem Übertragen Backup der Daten erstellen (z.B. phpMyAdmin), Migrationsskript (Neue Tabellen, Neue Spalten) erstellen und ausführen.
Und warum?
In den meisten Fällen ist nach ausführen eines Befehls die Suppe noch nicht gelöffelt und es liegt ein halbgares Skript auf dem Server das den Produktivbetrieb stören kann.
Der genannte Befehl erstellt ja nur ein Grundgerüst eines Templates, dass noch mit Leben gefüllt werden will.
Und in den anderen Fällen wünscht man sich dass man den Befehl schnellstmöglich ohne größeren Schaden wieder Rückgängig machen kann.
Die Experten die Befehle über ssh absetzen machen das in der Regel auf einem Entwicklungssystem,
Und Preisträger des Darwin-Awards gehen noch einen Schritt weiter wenn Sie keinen ssh-Zugang haben:
Ein PHP-Skript erstellen mit eben jenem Befehl um dieses dann über den Browser aufzurufen!
[quote=Unregistered]Und Preisträger des Darwin-Awards gehen noch einen Schritt weiter wenn Sie keinen ssh-Zugang haben:
Ein PHP-Skript erstellen mit eben jenem Befehl um dieses dann über den Browser aufzurufen![/quote]
Da oben steht "just for fun"
Der brauchst sich nicht lokal den ganzen Schrott installieren, git aufsetzen und dann eine Unterhose mit “Release” taggen - der kann den Befehl direkt am Server ausprobieren
IMHO: Ich finde nicht, dass SSH nur etwas für absolute Profis da ist. Wenn man z.B. eine neue produktiv Software einsetzen möchte, sollte man sowieso zuerst - nachdem man sie auf der Entwicklerumgebung getestet hat - die Möglichkeit nutzen die Software auf den Server zu testen (Bestenfalls in einem Ordner mit Passwortschutz). Punkt ist, dass sich die Entwickler-Umgebung meist von der Serverumbegung unterscheidet und ein Direkt-Deploy über rsync oder ftp dabei nicht empfehlenswert wäre. Vor allem wenn es Probleme auf der Produktiv-Umgebung gibt, kann es ernsthafte Konsequenzen nach sich ziehen.
Jedenfalls würde ich auch keinem Menschen ernsthaft empfehlen FTP als Übertragungsprotokoll zu verwenden, da Passwörter standardmäßig unverschlüsselt ins Netz übertragen werden. Hier ein kleiner Tipp für einen empfehlenswerter Hoster, der kein FTP, sondern nur SSH und SFTP anbietet: Uberspace.de.
[QUOTE=Unregistered]Doch lokal auf deinem pc!
// den Rest mal weggekürzt[/QUOTE]
Woah. Mal bitte ganz Sachte Kollege. Sicher, es war eine Anfänger-Frage, aber das wurde auch vorab erwähnt.
Wie du darauf komst erstmal direkt zu sagen “lokal” verschweigt sich mir. Es wurde klar gesagt : läuft auf einem Webspace. Die Doc liefert : “der einfachste Weg ist über die CLI”.
Klar, auch ich denk mir erstmal : WTF ? Wie wärs ein passendes Admin-Panel zu bauen? Aber ok …
CLI wäre für mich kein Thema : SSH und ab dafür. Aber ich würde trotzdem deine drei Gruppen rauswerfen.
Anfänger haben meist nur Webspace, nicht gleich (v)Root mit SSH-Zugang, wissen also meist nicht mal was davon.
Idioten: denen sollte man sowas wegnehmen, denn die machen meist den Fehler sowas über Telnet laufen zu lassen.
absolute Experten: öhm, what? SSH ist seit dessen Entwicklung ein quasi-Standard für die remote-Administration von Unix-Servern. Jeder Fortgeschrittene auf dem Gebiet der dann auch in Richtung (v)Root geht wird sich zwangsläufig damit befassen und dies nutzen.
Beim Darwin-Award geb ich dir nur teilweise in sofern recht als das es halt eben besser gehen würde die Befehle direkt ausführen statt ein weiteres Script über CLI zu callen.
Auf diese aberwitzige Idee mit dem umständlichen local-build und publish über Versionierung. Mag sicher eine gute Variante sein, aber für ein Simples CMS doch wohl absoluter Overkill.
Vielen Dank @Sen-Mithrarin für deinen Beitrag.
Also diesen hier http://forum.byte-welt.net/sonstiges/software/17161-collaboration-groupware-wie-citadel-oder-kolab-post121952.html#post121952
Das ist es was ich gemeint habe, als ich vor ssh warnte. Es kann ganze Systeme zerstören, wenn man nicht weiss was man tut oder denkt “es hät schon immar jut gegang”. Aber auf die Idee erstmal in einer VM zu testen kommst du ja relativ schnell, aber dennoch zu spät was ich der “Neuinstallation” entnehme.
Aber was macht eigentlich der Aufruf?
php pagekit themes:generate THEME_NAME
Es werden ein paar Dateien erstellt, evtl. ein paar Datenbanktabellen und spalten, ein paar Datenbankeinträge und es könnten noch ein paar Dateien verändert werden.
Aber wie macht man diesen Befehl rückgängig?
Eben! Und deshalb ist es heute nicht mehr State-of-Art sein System mit SSH zu kompromitieren.
Heute baut man komplette Images, testet diese und fährt dann bei Erfolg die nötigen Maschinen (virtuell oder pysisch) mit diesen Images hoch.
SSH kann man dann nutzen um per top die Last und so spielerein aufzurufen oder Logs zu durchsuchen oder einen Blick auf die DB zu werfen. Aber nichts was das System verändert.
Backups. Backups. Backups. Bitte macht Backups bevor ihr kritische Sachen umsetzen wollt. Im besten Fall sollte man bei einer Migration zu einer neueren Linux-Distribution nicht versuchen das System upzugraden. Stattdessen sollte man sich einen Server mit der neueren Linux-Distribution schnappen und dort versuchen seine benutzte Software installieren. So kann gewährleistet werden, dass diese Software auf jedenfall funktioniert.
bitte mal als eigenes Thema ausklinken da nichts mehr mit der eigentlichen Frage zu tun
[spoiler]
[ot]@unregistered
Weder kann ich dir folgen noch den Bezug zum anderen Topic nachvollziehen.
Ich weis zwar was du sagen willst, aber mir fällt es schwer ein Beispiel in der Praxis zu finden wo das so auch wirklich umgesetzt wird. Möchte nicht wissen mit was für verdorbenen Systemen du arbeitest, aber ich glaube kaum dass irgendein halbwegs produktiver Admin nur für eine kleine Änderung ein ganzes Testsystem mitlaufen lässt nur um dann bei dieser Änderung das ganze Paket neu zu deployen. Du hast ganz schön komische Vorstellung von SSH und wie man remote auf einer Server-tty arbeitet. Als simpler Resource-Monitor wird es sicher nicht missbraucht, dafür gibts besseres.
Aber was auch immer. Du lebst in deiner Welt und ich in meiner. Möchte mal sehen wie du deine Idee bei nem großen Cluster umsetzen willst wo die Module nicht mal eben abgeschaltet und re-deployed werden können. Vor allem wenn das Test-System nicht ausreicht.[/ot][/spoiler]