Cron läuft nicht mehr / Aktualisierungen unmöglich

Wenn du nichts geändert hast und Poormanscron problemlos lief. Dann weißte ja bescheid, dass du an anderen Ecken zb den Webhoster schauen musst, ob er vielleicht was geändert hat.

----------------------------------------
Alle Angaben ohne Gewähr!!:D
http://www.tobiasbaehr.de/

Interessant ist das Datum.
Ich habe ebenfalls seit 25.12. Probleme mit Websites, Cron läuft auch nicht mehr durch. Zum Teil komme ich nicht mal mehr in den Admin-Bereich. Ist deine Site eventuell auch bei Strato gehostet?

---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Genau so ist es: Strato. Mittlerweile weiß ich, dass sie auf PHP 5.2.8 aktualisiert haben. Ob das die Ursache ist?
(Wobei, der Admin-Bereich an sich macht eigentlich keine Probleme. Aber Cron und die Aktualierierungen eben.)

Also wenn nur PHP akualisiert wurde, dann dürfte kein Fehler sein. Das nutze ich nämlich auch.

----------------------------------------
Alle Angaben ohne Gewähr!!:D
http://www.tobiasbaehr.de/

Bei mir geht es auch, wenn ich die Module Views, image, img_assist lösche (deaktivieren reicht nicht). Manchmal jedenfalls. Manchmal kriege ich dann eine Fehlermeldung von fckeditor.
Vermutlich müsste ich jetzt jedes Modul einzeln testen. Ich warte erst mal auf eine Antwort vom Strato Support. Ab und zu können die ganz hilfreich sein.
Kann man Drupal gefahrlos auf PHP 4 (letzte Version, weiß jetzt nicht auswendig, was das ist) "zurückstufen"? Wäre einen Versuch wert...

Hier sind alle meine Module, falls das irgendwie weiterhilft:
acl
backup_migrate
captcha
cck
contemplate
et_veranstalter
fckeditor
forum_access
guestbook
image
img_assist
indexpage
scheduler
thickbox
views

---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Wenn ihr nichts geändert habt, kein neues Modul oder sonst was, was eventuell zu viel oder den Rest Power nimmt. Und vorher die gleiche Website (ein Clon) alles lief .Dürfte es nicht an Drupal liegen.

Falls jedoch vorher php4 verwendet wurde sowie DB-Schnitstelle Mysql anstatt Mysqli, was bei PHP5 Standard ist. Dann würde ich dies in der settings.php bei der DB-Verbindung ändern auf mysqli.

----------------------------------------
Alle Angaben ohne Gewähr!!:D
http://www.tobiasbaehr.de/

Zum Verständnis: Auf Strato lief bis vor kurzem eine ältere Version von PHP 5 (vermutlich die, die bis 12.12. oder wann das war aktuell war)
Man kann allerdings über die .htaccess auch auf PHP 4.4.x umschalten. Ich müsste nur mal nachschauen, wie das geht. Und ich weiß nicht, ob es Drupal nicht völlig zerstört, wenn es auf einmal unangekündigt mit PHP 4 statt 5 zurechtkommen muss.
Mit PHP4 hätte ich jedenfalls sicher keine Probleme, die von der neuesten PHP 5-Version verursacht werden. ;-)

Ich warte aber erst mal noch auf die Antwort vom Strato-Support. Übrigens komme ich seltsamerweise wieder in den Admin-Bereich, auch Cron ist neulich mal durchgelaufen, und die Updates-Seite zeigt mir bei zwei Modulen verfügbare Updates an, bei den anderen steht aber "Keine verfügbaren Veröffentlichungen gefunden".
Immerhin läuft die Website für Benutzer ohne Störungen, nur die Administration ist betroffen. Das ist doch schon mal was.

---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

OK, hier ist die "Antwort" auf meine Anfrage.

Das war meine Mail:

Und das hier ist die Antwort vom Strato-Support:

Nun ja.
---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Hallo Leute,
so wie es aussieht, läuft Cron wieder durch, wenn ich Update Status deaktiviere.
Nun, ich werde wohl langsam mal den Provider wechseln müssen. Strato hat mich schon lange genervt, aber das ist jetzt echt das Ende der Fahnenstange.

---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Hi! Gehöre auch zum Kreis der Strato-Geplagten und komme seit Tagen, sobald ich ein Modul oder Theme aktiviere, nicht mehr in den Adminbereich. Auch Cron und Prüfung des Aktualisierungsstatus laufen nicht durch.

Die Antwort die weiter oben von Strato zu lesen war ist ne Frechheit.

Blöde Frage wahrscheinlich, aber wie/wo deaktiviere ich den Update-Status? Gibt es sonst noch irgendwelche Tipps, mit denen das Weiterarbeiten an der Seite ermöglicht wird? Hat jemand schon die Umstellung auf php 4.x ausprobiert?

Freue mich über sämtliche Tipps und wünsche weiterhin frohes Schaffen auf dem Super-Server ;-)

Das Kern-Module Update-Status allein dürfte keine Probleme machen. Erst wenn ihr den Cron ausführt und eurer Webpaket leider dadurch an seine Grenzen kommt.
Es ist aber sehr zu empfehlen dieses Modul zu verwenden, damit man erfährt wenn es neuere Versionen gibt.

Und Umstieg auf php 4.x? Du meinst wohl auf php 5 :D
Also seitens Drupal gibt es keine Problem mit php5 sogar Vorteile. Und wenn ihr die DB-Schnittstelle mySqli verwendet, die mit php 5 kam.

----------------------------------------
Alle Angaben ohne Gewähr!!:D
http://www.tobiasbaehr.de/

Hallo Spartacus,
ja genau, ohne "Update Status", was Cron ja doch ein wenig belastet, läuft Cron bei mir durch. Ist jetzt bei mir nicht so das Riesenproblem, wenn ich bei einer Drupal-Installation Update Status deaktiviere, denn die anderen (es sind noch ein paar in Vorbereitung) sagen mir ja sowieso, wenn es eine neue Version gibt.
Und doch, ich meinte ein Downgrade von PHP 5 auf PHP 4. Die Probleme treten nämlich auf, seit Strato auf die neueste Version 5.2.8 (?) umgestellt hat. Da allinkl, auf deren Server ich gerade teste, noch mit 5.2.6 arbeitet, bin ich mir nicht 100% sicher, dass es nur ein Strato-Problem ist.

@sunshine: Wenn du in den Abschnitt "Module" reinkommst (was ja nicht mehr selbstverständlich ist), kannst du Update Status bei der optionalen Kern-Modulen deaktivieren.

---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Hallo sunshine3577,

falls noch nicht geschehen, bitte schreib doch auch dem Strato-Support. Die sollen ruhig wissen, dass mehrere Kunden das Problem haben.

Gruß
mdatab

Hallo zusammen,

ich bin ebenfalls bei Strato und auch bei mir macht cron ein Problem, /admin/reports/updates läuft nach einiger Zeit auf "internal server error".
Ich nutze ebenfalls PHP 5, es gab keine Veränderungen an meiner Webseite seit Mitte Dezember (Content, Drupal, DB usw - nix).
Allerdings habe ich beim ersten Aufruf von /admin/reports/updates auch diese Meldung bekommen (siehe unten).
Es werden insgesamt 6 dieser Fehler im dblog angezeigt, allerdings kamen die nur beim ersten Aufruf, seitdem nicht mehr (nur noch - siehe oben - http error 500).

Da es ja scheinbar ein PHP-Update bei Strato gegeben hat kann es ja wohl nur daran liegen, also entweder
* an der Strato-Konfiguration von PHP
* an der PHP-Version selber, irgendwo in dieser Ecke.

Eventuell könnt's noch die Apache-Konfig sein, aber ich denke nicht, das die Ursachen wo anders liegen könnten...
Gruß
Jan

Duplicate entry 'themes/pushbutton/pushbutton.info' for key 1 query: INSERT INTO drupalsystem (name, owner, info, type, filename, status, throttle, bootstrap) VALUES ('pushbutton', 'themes/engines/phptemplate/phptemplate.engine', 'a:13:{s:4:\"name\";s:10:\"Pushbutton\";s:11:\"description\";s:52:\"Tabled, multi-column theme in blue and orange tones.\";s:7:\"version\";s:3:\"6.8\";s:4:\"core\";s:3:\"6.x\";s:6:\"engine\";s:11:\"phptemplate\";s:7:\"project\";s:6:\"drupal\";s:9:\"datestamp\";s:10:\"1229018427\";s:7:\"regions\";a:5:{s:4:\"left\";s:12:\"Left sidebar\";s:5:\"right\";s:13:\"Right sidebar\";s:7:\"content\";s:7:\"Content\";s:6:\"header\";s:6:\"Header\";s:6:\"footer\";s:6:\"Footer\";}s:8:\"features\";a:10:{i:0;s:20:\"comment_user_picture\";i:1;s:7:\"favicon\";i:2;s:7:\"mission\";i:3;s:4:\"logo\";i:4;s:4:\"name\";i:5;s:17:\"node_user_picture\";i:6;s:6:\"search\";i:7;s:6:\"slogan\";i:8;s:13:\"primary_links\";i:9;s:15:\"secondary_links\";}s:11:\"stylesheets\";a:1:{s:3:\"all\";a:1:{s:9:\"style.css\";s:27:\"themes/pushbutton/style.css\";}}s:7:\"scripts\";a:1:{s:9:\"script.js\";s:27:\"themes/pushbutton/script.js\";}s:10:\"screenshot\";s:32:\"themes/pushbutton/screenshot.png\";s:3:\"php\";s:5:\"4.3.5\";}', 'theme', 'themes/pushbutton/pushbutton.info', 0, 0, 0) in /mnt/web2/32/75/5109475/htdocs/drupal/modules/system/system.module in Zeile 830.

Ihr habt einfach zuwenig Power in der Hütte, nimmt ein besseres Paket mit mehr Leistung oder wechselt den Hoster. Seit gestern hab ich bei den Cron serverseitig laufen und wird/muss nicht mehr von mir angestoßen werden bzw. von einem Gast, was dann Poormanscon bisher ausführte.

Die Seite admin/status/updates führt automatisch ein Cron aus, falls es zu lange her ist.
----------------------------------------
Alle Angaben ohne Gewähr!!:D
http://www.tobiasbaehr.de/

Kannst Du mir erklären wieso Du das denkst?
IMHO macht Drupal eine Abfrage, und die geht - laut Webserver - schief. So schief, das der Webserver nichtmal weiß, was ihn eigentlich stört, denn sonst gäbe er eine anderen HTTP-Error-Code zurück.

Ich habe gerade mal zum Test die max_execution_time hochgesetzt: keine Änderung.
Das liegt aber hier dran:

Andererseits habe ich, um das mit der DB zu verifizieren, mysql.connect_timeout runter gesetzt. Mit dem Erfolg, das es es keinen Error 500 gab, die Seite korrekt neu lud, aber auch (fast) überall "Keine verfügbaren Veröffentlichungen gefunden". Umgekehrt habe ich den Parameter mal testweise auf 3 Minuten hoch gesetzt und - siehe da - nach ziemlich genau 3 Minuten gibt's wieder HTTP Error 500.

Das führt mich zu der Annahme, das Strato im Moment ein Problem mit der Schnittstelle von PHP zu MySQL hat.

Ich gehöre auch zu den Strato Geplagten .. seit geraumer Zeit allerdings schon.

Der oben beschriebene Fehler taucht ja immer wieder mal auf - insbesondere durch das DB-Problem wie es der nette Mitarbeiter von Strato ja beschrieben hat.
Auch nen Weg, Kunden auf einen dedizierten Server hinzuweisen .. *ggg - einfach mal 500er Fehler .. naja, lass ich das mal.

Ein Wechsel habe ich schon immer im Kopf gehabt - allerdings die Frage wohin und ist es da besser?

Ich wünschte es gäbe hier eine Statistik die ein paar Hinweise gäben. Vielleicht sollte man sowas ins Leben rufen.

---
http://www.soccer-wikki.info
http://salzkotten.saelzernet.de
http://www.saelzernet.de

Ich habe im Moment die Seite http://www.gochsheim-evangelisch.de auch noch auf einem Testserver bei all-inkl.de laufen unter http://test57345.test-account.com/ (gilt nur ein paar Tage)
Klick mal rein. Subjektiv geht es viel schneller. Und die Admin-Seiten erst recht. Dass ich noch keinen 500er Fehler hatte oder sonst irgendwas, ist natürlich klar.

---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Mir scheint ebenfalls das es bei all-inkl.de schneller geht...

Ich stehe auch kurz vor dem Wechsel. Neben all-inkl.com ist auch Host Europe in meiner engeren Wahl. Weiß dazu jemand etwas? Ists da ähnlich flott wie bei all-inkl.com?

Ich kann immer nur wieder Planet-Hosting.de empfehlen.

z.B. Planet.home - Paket
30GB Traffic
500MB Webspace
eigene CRON JOBS
php.ini konfigurierbar
PHP5
5 * MYSQL

Perfekt für ne 6er Drupalseite .... sechs Monate gratis und danach 2,49 Euronen im Monat. Und auch der Support ist flott per Mail zu erreichen. STRATO, SCHLUND etc. habe ich seit Jahren gekündigt und dorthin umgezogen ... und habs noch nie bereut!

Wie ist denn da die performance?

Wenn Du jetzt nicht gerade ein "Mörderangebot" hosten lassen willst, vollkommen ausreichend. Ich habe im Dezember mit einem wie von mir oben erwähnten Paket problemlos 800.000 PIs mit manchmal zeitgleichen 100 Usern geschafft. Ohne große Probleme.

Das hört sich grundsätzlich gut an .. doch wo nun?
Bei Europe Online ?

--
http://www.soccer-wikki.info
http://salzkotten.saelzernet.de
http://www.saelzernet.de

Für euch zur Info. Jeder möge daraus selber herauslesen, was er/sie meint.

---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Was mir an all-inkl sehr gut gefällt, ist dass sie praktisch keine Kündigungsfrist haben. Sagen wir so: Du kannst dir deine Vertragslaufzeit selber raussuchen, indem du Vorauszahlung wählst und dafür dann auch Rabatt bekommst. Mir ist all-inkl einfach von der Kundenfreundlichkeit sehr angenehm. Auf der anderen Seiten würde mir bei host-europe vermutlich schon das Paket für 2,99 für die private Website reichen. Bei Planethosting ist die Vertragslaufzeit 24 Monate, das finde ich schon happig. Auch wenns jetzt keine so Riesenbeträge sind. Ich weiß auch noch nicht. PS2000 wird jedenfalls heute im Auftrag der Vereinsvorsitzenden auf all-inkl umgestellt, ein komplett neues Paket mit 4 Domains wird noch diese Woche ebenfalls bei all-inkl eingerichtet.
---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Na das kann ich nicht stehen lassen, das ist ja nur ein "Sonderangebot" mit den 24 Monaten. Es gibt ja auch andere Pakete.
Ich vermute jetzt einfach mal, daß Dein Gochsheim-evangelisch.de sicherlich auch mit 2 GB Traffic und einer Datenbank auskommen kann - das kostet dann gerade mal 35 Cent im Monat mit dem Paket "fair" ...
Und auch wenns sichs sicherlich nicht so anhört, ich bin wirklich NUR Kunde, aber ein echt zufriedener *lach*

Nun ja, das nicht ganz, weil da noch 3 andere Domains und ca. 100 Email-Adressen dranhängen.
Wusste ich natürlich nicht, dass die 24 Monate nur bei dem Sonderangebot sind. Man muss echt immer alles vergleichen. Warum gibt es nur so viele verschiedene Angebote? ;-)

---
Drupal 6.8 auf http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Beide Anbieter sind doch überhaupt nicht vergleichbar. Wenn es um Sicherheit und Verfügbarkeit der Daten bzw. des Servers geht, dann bleibt nur Host Europe.
Einfach mal vergleichen, welcher Anbieter Backups anbietet, welche Verfügbarkeit garantiert wird, wer seine Anbindung offenlegt usw.
Ist halt alles eine Frage, was man will oder braucht, nur meist merkt man das erst, wenn es zu spät ist.

Ich stimme dir zu. Der Wechsel ist eingeleitet.

Na Jungs, dann lasst doch mal Details hören. Wie ist es denn um die Anbindung, Verfügbarkeit und Backup bei Host Europe bzw. all-inkl bestellt?
Ich könnte jetzt auch selber nachlesen, aber da Ihr es gerade parat habt...

Für allinkl geht das schnell, Backups werden nicht angeboten, Anbindung ist unbekannt - belegt ist aber, dass da nichts geht, wenn mal ein Switch ausfällt - und bei 99% vereinbarter Verfügbarkeit, sind das fast 4 Tage, die man nicht erreichbar sein könnte.

Ich habe jetzt gerade ein neues Paket bei all-inkl eingerichtet und bei der Gelegenheit eine Domain von einem anderen Inhaber übernommen.
Folgende Reaktionszeiten hatte ich heute beim Support:
- Telefon: dreimal "tüüt" bis ich eine kompetente und freundliche Person am Telefon hatte.
- Fax: Antwortmail nach 30 Minuten
- Mail: Vollzugsmeldung nach 14 Minuten

Wenns mir nicht passt, kann ich ja innerhalb von einem Monat wechseln. Die Kündigungsfrist ist jedenfalls extrem kundenfreundlich.

---
Drupal 6.8 auf http://www.citykirche-schweinfurt.de http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Wollte hier nur kurz dokumentieren, das bei uns nach der Weihnachtspause bei einer unserer Seiten (der einzigen Strato-Seite) das selbe Problem aufgetaucht ist. Auch wir haben daraufhin die Aktualisierung ausgeschaltet, danach ging der Rest problemlos ABER die Crons laufen nur, wenn man sie händisch startet. Dazu reicht es ja, auch, ausgeloggt einfach /cron.php einzugeben - tut. Jedoch Strato behauptet frech, das Skript laufe auch im 4-Stunden-Rythmus. Das stimmt aber nicht. Bei Skriptausgabe lese ich z.B.:

Na ja, wir haben das Problem bis heute zurückgestellt, da die Seite ohnehin noch nicht produktiv ist, aber jetzt maile ich Strato mal (so wie ich die kenne, verweisen die auf dieses Forum hier..)
Unser Paket ist "Premium Advanced"

Aber ganz generell ist das ja nicht das einzige, was Strato sich uns gegenüber geleistet hat. Mal abgesehen von der nicht aktzeptablen Geschwindigkeit lief´s am Anfang überhaupt nicht und musste kompliziert umkonfiguriert worden. Und der Support war schlichtweg frech. Das darf man einfach nicht als "Drupal ready" verkaufen. Ist es nämlich nicht. Sonst sind wir immer bei kleinen und teuren Premium-Edel-Hostern. Wenn ich denke, wieviel Ärger wir uns eingeholt haben, nur weil ich aufgrund dieses Spruches dachte, mal ausprobieren kann man ja...
==> Kann man nicht! Finger weg von Strato!

--
...nein, unsere EIGENE Seite ist immer noch nicht auf Drupal...

mimori, danke für den Erfahrungsbericht. Als Threadstarter möchte ich noch abschließend erwähnen, dass ich meine Webseiten nun zu Host Europe umgezogen habe. Alles funktoniert nun wieder problemlos. Und schneller. :) Als frech kann ich den Support von Strato nicht bezeichnen. Aber von Drupal ready kan wahrlich keine Rede sein. Allein die langsame Datenbankanbindung konnte einem den letzten Nerv rauben.

Da fehlt aber noch der Punkt, ob es auch wirklich erledigt wurde. Denn bei allinkl macht das schon ein Unterschied, die reine Vollzugsmeldung besagt erstmal gar nichts.
Achso, auf meine e-mail von gestern gibt es noch immer keine Antwort.

...manchmal sieht man den Wald vor lauter Bäumen nicht und steht sich selbst im Weg:

Ein kurzer Blick auf die cron-job-Eingabemaske hätte uns ja gezeigt, dass wir keinen Interpreter eingegeben hatten. Ich vermute mal, vor dem letzten Strato-Update war der php-Interpreter als default eingegeben, und danach eben nicht mehr.

Richtig muss man in die Maske also eingeben:

und schon tut`s.

Die Aktualisierung funktioniert deswegen noch lange nicht, aber das lassen wir jetzt einfach abgeschaltet.

Zum Strato-Service: Sicher gibt´s auch guten Support von Strato, ohne Frage. Aber definitiv auch andere. Wer wissen will, was Strato zum ja aktiv beworbenen Thema "Drupal ready" zu sagen, hat stellt sich in folgendem Clip einfach statt eines toten Papageis ein nicht funktionierendes Drupal-System auf einem Strato-Server vor:

http://de.youtube.com/watch?v=Mnmtpz_FCQg

--
...nein, unsere EIGENE Seite ist immer noch nicht auf Drupal...

Die cron.php sollte laut Handbuch nicht mit php, sondern mit einem Browser aufgerufen werden. Da wget bei meinem Hoster aus Sicherheitsgründen deaktiviert ist, mache ich das mit curl.

http://drupal.org/cron
http://www.drupalcenter.de/handbuch/8318

Bei unseren anderen Hostern nehmen wir curl. curl geht aber bei Strato nicht. Ich hab´s jetzt dort aber mal mit wget - tut.

--
...nein, unsere EIGENE Seite ist immer noch nicht auf Drupal...

Wollte Euch nur meine Antwort zur Verfügung stellen:

Diese Mail habe ich auch bekommen.
Leider hat die Datenbank offenbar mittlerweile Schaden genommen, und ein Backup lässt sich nicht einspielen. Jedenfalls erhalte ich keinerlei Zugriff auf irgendwelche Verwaltungsoptionen.
Ich habe jetzt ein einige Tage altes Backup auf eine freie Datenbank meines privaten Accounts bei hosteurope eingespielt und Zugriff von außen erlaubt. Seither geht meine letzte noch bei Strato verbliebene Homepage ( http://www.gochsheim-evangelisch.de ) wieder weitgehend (sind ja auch nur noch die Dateien bei Strato, die Datenbank nicht). Alle anderen sind umgezogen oder ziehen gerade um. Teils allinkl, teils host-europe, je nach Anforderungen der Website.

Update: Mittlerweile habe ich auch die Daten zu hosteurope verlagert, denn PHP hatte ständig Arbeitsspeichermangel und Time-Outs. Dann ging alles wieder prima, auch mit den ganzen Modulen, die ich mittlerweile gelöscht hatte.

---
Drupal 6.8 auf http://www.citykirche-schweinfurt.de http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Unter http://drupal.org/node/360645 hab ich mal eine entsprechende Info bei drupal.org gepostet.
Ein Poster dort scheint das Problem zu kennen, ich interpretiere die Antwort als "nicht unbedingt Strato bezogen":

Edit: Update Status causing Drupal to run very slowly: http://drupal.org/node/222073
Das Problem betrifftdoch einige User mehr als nur uns hier...

Ich bin ebenfalls der Meinung, das das Problem ehe rim Bereich der DB ziu suchen ist.
Schaut bitte mal auf Eure /admin/reports/status/sql und sucht unten nach den Werten, besonders:

Tja, bei mir ist das alles andere als zero...
Wie sieht's bei Euch aus?

Tja, das kann ich jetzt nicht mehr so genau nachvollziehen, denn ich bekam gerade diese Mail:

Das war die letzte von insgesamt 7 Domains, die ursprünglich mal bei Strato waren.

---
Drupal 6.9 auf http://www.citykirche-schweinfurt.de http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

ich hatte das gleiche Problem bei Strato und habe mich geschlagen gegeben, bin nach Host Europe gegangen und habe keinen Tag seit dem bereut.
Schneller, mehr Leistung und der Support freundlicher und meiner Meinung kompetenter.
Hätte ich das alles vorher gewusst hätte ich die Finger von Strato gelassen. Ich muss auch sagen das für normale Html Seite ich nie Probleme hatte, aber Drupal läuft meiner Meinung nicht gut bei Strato.

Mann, was war Drupal auf Strato für eine lahme Ente. Jetzt geht es wunderbar. Der Unterschied ist deutlich spürbar. Gilt übrigens auch die Website, die bei all-inkl gehostet ist.

---
Drupal 6.9 auf http://www.citykirche-schweinfurt.de http://www.gochsheim-evangelisch.de und http://www.ps2000-bayern.de/

Habe mir gestern bei Planet-Hosting eine Domain zum Testen geholt - geht wunderbar schell im Vergleich zu Strato.

Hoster: Planet-Hosting
Paket: Privat.fair
Kosten: 0,35 € / Monat (!)
Webspace: 100 MB
Traffic: 2GB
inklusiv POP, IMAP und einer de-Domain

htaccess: OK
mod_rewrite: OK (cleanurls geht)

PHP: 5.2.8 (oder 4.x)
Server API: CGI
memory_limit: 60M (voreingestellt)
max_execution_time: 500 bei PHP4, 20 bei PHP5 (beides voreingestellt)

safe_mode, register_globals, magic_quotes durch php.ini einstellbar (nicht getestet)

MySQL: 5.0.67
phpmyadmin: 2.11.9.2

... und dazu noch SSI, perl und python, hab ich aber nicht getestet.

Kontakt zum Support:
1x telefonisch: schnell und freundlich
1x per Mail: schnell und freundlich (haben mir CREATE TEMPORARY TABLE freigeschaltet)

Einfach Files und DB von Strato rüberkopiert, funzt alles ohne Probleme - nur schneller :-)

Bye-bye Strato...

Tatsache ist, dass update.drupal.org Anfragen von Stratoservern ignoriert. Das folgende Testscript:

wurde mit folgendem beantwortet:

Warning: fsockopen() [function.fsockopen]: unable to connect to updates.drupal.org:80 (Connection timed out) in /mnt/web1/20/82/52129182/htdocs/Drupal/TestAktualisierung.php on line 8
Warning: fwrite(): supplied argument is not a valid stream resource in /mnt/web1/20/82/52129182/htdocs/Drupal/TestAktualisierung.php on line 15
Warning: feof(): supplied argument is not a valid stream resource in /mnt/web1/20/82/52129182/htdocs/Drupal/TestAktualisierung.php on line 18
Warning: fread(): supplied argument is not a valid stream resource in /mnt/web1/20/82/52129182/htdocs/Drupal/TestAktualisierung.php on line 18
Warning: fclose(): supplied argument is not a valid stream resource in /mnt/web1/20/82/52129182/htdocs/Drupal/TestAktualisierung.php on line 21

Andere Server sind da kooperativer. Da aber ein ähnlicher Code in drupal_http_request() verwendet wird, wundert es nicht weiter, dass auch der kein Ergebnis liefert. Leider ist der Code an dieser Stelle dilettantisch programmiert:

common.inc 6.14:
457 $fp = @fsockopen($uri['host'], $port, $errno, $errstr, 15);
458 break;

Der Klammeraffe @ vor dem Funktionsnamen sorgt dafür, dass Fehlermeldungen unterdrückt werden. Das mag ja noch angehen, weil es jede Menge Gründe geben kann, warum fsockopen() böse werden könnte. Aber den Filepointer $fp danach nicht auf Null zu prüfen, sondern lustig weiterzumachen, ist eigentlich nur fahrlässig: Keine Fehlermeldung, kein Logeintrag, keine Aktualisierungsprüfung.

Jetzt bleibt noch die Frage: Wer ist der Administrator von update.drupal.org und wie bringt man ihn dazu, doch so nett zu sein, auch Anfragen von Strato Servern zu beantworten?

Wenn der überzeugung bist, dass hier was falsch läuft. Kannst du hier http://drupal.org/project/issues/infrastructure deine Schilderung in Englisch verfassen, aber ich kann Dir sagen das es Stratoserver gibt die davon nicht betroffen sind.

----------------------------------------

http://tobiasbaehr.de/
Gelöste Forenbeiträge mit [gelöst] im Titel ergänzen
Das Verhältnis anderen zu helfen muss höher sein, als von anderen Hilfe zu erfragen/erwarten.

dass meine Adresse bei Strato betroffen ist. Es nützt mir nichts, dass andere Strato Server von updates.drupal.org nicht geblockt werden. Ich möchte hier auch nicht über die vielfältigen Einstellungsmöglichkeiten eines Apache Servers philosophieren, sondern mit o.a. Skript denen helfen, die ebenfalls Probleme mit der Update Aktualisierung haben.

Ich habe mich in der Zwischenzeit an den Admin des updates.drupal.org Servers gewandt, einen gewissen Dries Buykaert, mit der Bitte mindestens meine IP wieder freizuschalten und ggf. die gesperrten Domains bzw. IPs zu veröffentlichen.

Damit scheint die Ursache geklärt zu sein. Es wurde also ein fehlerhaftes Update herausgebracht, was so etwas wie eine DOS Attacke auf den eigenen Server produzierte. Der Bug wurde schleunigst korrigiert. Damit der Update Server wieder normal arbeiten konnte, wurden die IP Adressen mit fehlerhaften Drupalinstallationen, die sich nicht upgedated haben, gesperrt.

Es ist mein persönliches Pech, dass ich die IP Adresse mit einer fehlerhaften Altinstallation teile.

Hallo zusammen!

Ich bin wohl von dem gleichen Problem betroffen. Leider geht aus den Antworten nicht hervor, was genau zur Lösung des Problems zu tun ist bzw. ob es überhaupt zu lösen ist...

Bitte um Hilfe! :-)

Zunächst gibt es noch eine Ungereimtheit, die ich mir nicht ohne weiteres erklären kann.

Ich habe festgestellt, dass mein Drupal von Strato aus keine Verbindung bekommt. Srato wiederum hat mir bestätigt, dass alle Abfragen von Strato nach draußen über die IP 81.169.145.88 erfolgen. Jetzt behaupten ein paar Vorposter, dass es Strato Accounts gäbe, die vom Updateserver akzeptiert werden. Das passt eigentlich nicht ins Bild, es sei denn sie haben einen Strato Account mit eigener IP Adresse. Das ist jedenfalls meine Vermutung.

Aber gehen wir einmal davon aus, dass der Schlamassel aus dem defekten Update herrührt. Strato müsste in diesem Fall vom Drupal Team unter server-abuse@strato.de angeschrieben werden, mit Einzelheiten über die defekte Software. Strato würde daraufhin seine Kunden informieren alte, fehlerhafte Drupalinstallationen upzudaten. Ich schätze das dauert, wenn es überhaupt je passiert.

Eine schmutzige Lösung besteht in der Benutzung eines Proxy Servers. Aber ich habe im Moment leider keine Zeit das zu realisieren. Vermutlich muss man dazu den Kern patchen; d.h. das muss auch nach jedem Drupal Update passieren. Eine Vorstellung, die mich anekelt.

Wenn das Drupal Team clever gewesen wäre, hätte es eine 2. Update Domain eingerichtet. Die alte, fehlerhafte Software kennt diese Domain nicht. Aber eine fehlerfreie Installation, die gesperrt ist, könnte auf die 2. Update Adresse zugreifen. Aber offensichtlich sind diese Leute nicht clever oder anders herum, es geht ihnen am A... vorbei, ob ein paar Leute mit Billigaccounts Probleme haben.

Ich werde für mich daher den Weg des geringsten Widerstands gehen: d.h. die eingesetzten Module in eine Drupal Installation auf meinem Heim-PC setzen. Da die DSL Leitung jeden Tag eine neue IP bekommt, gibt es mit dem Update keine Schwierigkeiten. Ich lade die zu aktualisierenden Module sowieso mit FTP hoch.

Hab gestern noch etwas weiter recherchiert & bin dabei über folgende Diskussion gestolpert http://drupal.org/node/549934

Hab meine IP gepostet und zwar noch keine direkte Rückmeldung erhalten, aber meine Updates funktionieren wieder.

bei mir läuft die Aktualisierung auch wieder. Vielen Dank.

Hat einen guten Monat bei mir funktioniert...jetzt nicht mehr.

Seid ihr auch wieder von dem gleichen Problem betroffen?

@Jazzy

Danke für Deinen Hinweis.

Du hast recht. Es ist wieder soweit. Strato muss draußen bleiben. Schade. Leider kann man da überhaupt nicht viel machen und nur hoffen, dass die Admins bei updates.drupal.org irgendwann ein einsehen haben.