Joomla-Update funktioniert nicht

[medice]

also alle "webprodukteigenen updatefunktionen", die mir bisher untergekommen sind, setzen eine passende Konfiguration der benötigten Software und Umgebung voraus. Php-einstellungen sind ein heißer Tipp für Fehlfunktionen, aber auch Rechte- bzw Besitzverhältnisse einzelner oder gar aller Dateien.
Je nach Know-How, Zugriffsmöglichkeit sowie Klarheit der Fehlermeldungen dürften dabei viele an ihre Grenzen stoßen

ich weiß nicht mehr welches Teil das war, aber das hat beim Update via Webinterface das passende tar/rar vom Herstellerserver runter-, bzw i.d. RAM geladen, dann via FTP auf den eigenen Server transferiert, entpackt und weiterverarbeitet. Was da schon alles schieflaufen kann

[preiti]

also alle "webprodukteigenen updatefunktionen", die mir bisher untergekommen sind, setzen eine passende Konfiguration der benötigten Software und Umgebung voraus. Php-einstellungen sind ein heißer Tipp für Fehlfunktionen, aber auch Rechte- bzw Besitzverhältnisse einzelner oder gar aller Dateien.
Je nach Know-How, Zugriffsmöglichkeit sowie Klarheit der Fehlermeldungen dürften dabei viele an ihre Grenzen stoßen

Nach einer Anfrage per Mail bekam ich Links zu den aktuellen Install-Paketen auf Deutsch und zur FAQ-Seite des Webhosters. Dort fand ich die Info, die Recht der Datei configuration.php zu ändern.

ich weiß nicht mehr welches Teil das war, aber das hat beim Update via Webinterface das passende tar/rar vom Herstellerserver runter-, bzw i.d. RAM geladen, dann via FTP auf den eigenen Server transferiert, entpackt und weiterverarbeitet. Was da schon alles schieflaufen kann

Da ich nur die Zip-Datei des Paketes habe, habe ich die in einen Ordner entpackt und lade die ganze Sache grade per FTP hoch. Wäre vielleicht mit anders gepackten Paketen leichter gegangen(direkter upload), aber mir ist wichtig das es funktioniert.

[jutta]

> aber auch Rechte- bzw Besitzverhältnisse einzelner oder gar aller Dateien.

daher finden sich in den faq oder den hilfe-foren auch so tipps wie "alles auf 777 setzen"
(unter anderem bei gallery, iirc)

[medice]

daher finden sich in den faq oder den hilfe-foren auch so tipps wie "alles auf 777 setzen"
(unter anderem bei gallery, iirc)

bereits das kann ein Problem werden, wenn der hoster chmod-spielchen nicht erlaubt
(von der high-risk Idee mal abgesehen )

[preiti]

> aber auch Rechte- bzw Besitzverhältnisse einzelner oder gar aller Dateien.

daher finden sich in den faq oder den hilfe-foren auch so tipps wie "alles auf 777 setzen"
(unter anderem bei gallery, iirc)

Nein, der Tipp lautete die Rechte auf 644 setzten. Die Rechte waren vorher auf 444 gesetzt, k.A. was das genau bedeutet.

Das Update hat inzwischen mit den geänderten Rechten auf die Datei funktioniert.
Die Rechte habe ich jetzt wieder zurückgesetzt.

[medice]

der Tipp lautete die Rechte auf 644 setzten. Die Rechte waren vorher auf 444 gesetzt, k.A. was das genau bedeutet.

http://de.wikipedia.org/wiki/Unix-Dateirechte

[jutta]

444 = alle dürfen lesen
644 = eigentümer darf lesen und schreiben, alle übrigen nur lesen.

777 = alle dürfen alles. deshalb der daneben. 777 erleichtert vieles. aber nicht nur dir, sondern auch jedem, der absichtlich oder unabsichtlich in deinen files rumpfuscht. man soll nicht glauben, wie oft sich das in anleitungen findet, und zwar *ohne* den hinweis, dass man die dateirechte nachher wieder zurueckaendern muss.

[preiti]

der Tipp lautete die Rechte auf 644 setzten. Die Rechte waren vorher auf 444 gesetzt, k.A. was das genau bedeutet.

http://de.wikipedia.org/wiki/Unix-Dateirechte

Das war mir klar, nur welche Ziffer für welche Gruppe/User/Root steht ist mir nicht ganz klar.

444 = alle dürfen lesen
644 = eigentümer darf lesen und schreiben, alle übrigen nur lesen.

777 = alle dürfen alles. deshalb der daneben. 777 erleichtert vieles. aber nicht nur dir, sondern auch jedem, der absichtlich oder unabsichtlich in deinen files rumpfuscht. man soll nicht glauben, wie oft sich das in anleitungen findet, und zwar *ohne* den hinweis, dass man die dateirechte nachher wieder zurueckaendern muss.

Ist ja am "leichtesten" wenn man alles machen kann/darf

[penguinforce]

darum hat joomla ja versucht, den ftp-layer einzuführen - IMO lobenswert, aber noch nicht ausgereift (es gibt zuviele legacy- und/oder unsaubere anwendungen, die die api noch nicht nutzen).

das 444 wirst übrigens deshalb haben, weil du sicher den schreibschutz für die configuration.php im backend aktiviert hast, gell?

aber wie medice schon anmerkte, ist das abhängig vom webserver und dessen konfiguration.

[jutta]

>> 777
> bereits das kann ein Problem werden, wenn der hoster chmod-spielchen nicht erlaubt

da lautet der naechste tipp dann meistens: "such dir einen gscheiten hoster"

[preiti]

darum hat joomla ja versucht, den ftp-layer einzuführen - IMO lobenswert, aber noch nicht ausgereift (es gibt zuviele legacy- und/oder unsaubere anwendungen, die die api noch nicht nutzen).

das 444 wirst übrigens deshalb haben, weil du sicher den schreibschutz für die configuration.php im backend aktiviert hast, gell?

aber wie medice schon anmerkte, ist das abhängig vom webserver und dessen konfiguration.

Die Rechte für die configuration.php auf 444 ist bei meinem Webhoster anscheinend die Standard-Konfiguration. In den FAQs steht für Updates soll man die Rechte auf 644 setzen.
Ich habe, so wie es in den FAQs steht, die Rechte mit FileZilla ausgelesen, geändert und nach dem Update auch wieder zurück gesetzt. Eine andere Möglichkeit(chmod,....) habe ich nicht probiert.

>> 777
> bereits das kann ein Problem werden, wenn der hoster chmod-spielchen nicht erlaubt

da lautet der naechste tipp dann meistens: "such dir einen gscheiten hoster"

K.A ob ich einen gscheiten Webhoster habe.
Für mich ist der Preis OK, der Firmenstandort ist nicht weit weg von mir und bisher lief alles recht unkompliziert ab.

[jutta]

> K.A ob ich einen gscheiten Webhoster habe.

das merkt man meistens erst mit der zeit.

falls das nicht deutlich genug rausgekommen sein sollte: meine bemerkung war ironisch gemeint. bei hostern, die auf ihren servern keinerlei einschraenkungen haben, sind die chancen sehr gross, dass die website frueher oder spaeter gehackt oder sonstwie zerstoert wird.

klar ist es fuer die anbieter eine gratwanderung, denn eine sichere serverkonfiguration bedeutet, dass manches nicht auf anhieb funktioniert und dementsprechend viel support-anfragen. aber alles erlauben und alles freigeben ist auch keine ideal-loesung.