Strato Problem: Drupal meldet Fehler beim Updatecheck von Modulen
![](http://www.drupalcenter.de/files/noavatar_mini.gif)
am 14.04.2013 - 08:13 Uhr in
Hallo Leute,
mich plagt seit gestern ein sehr merkwürdiges Problem.
Und zwar gibt es ja im Drupal die Möglichkeit, alle Module und themes auf Updates zu prüfen.
bisher funktionierte das immer problemlos. Seit gestern jedoch bekomme ich ständig folgende Meldung.
Fehlermeldung
Fehler beim Prüfen von Daten über verfügbare Aktualisierungen für xx Projekte.
wobei xx für die Anzahl Projekte , also Themes, und Module, steht.
Wenn ich mir im Bereich "Aktualisieren" die Module im Registerreiter "Liste" ansehe, sind alle Module grau eingefärbt, wo sie sonst immer grün für aktuell, bzw. gelb bzw. rot für "updates verfügbar" eingefärbt waren.
An der Konfiguration habe ich nichts verändert, daher verwundert mich die nicht mehr funktionierende Funktionalität für den updatecheck.
habt ihr ne Idee, woran das liegen könnte?
- Anmelden oder Registrieren um Kommentare zu schreiben
Vielleicht
am 14.04.2013 - 09:42 Uhr
Hallo,
heute Morgen hatte ich das auch mal kurz, aber nach zwei oder drei weiteren Anläufen gings dann wieder.
Ansonsten könnte es auch an deinem Webspaceanbieter liegen, sodass drupal keinen Zugriff mehr auf externe Webressourcen hat.
Ich hoffe ich konnte dir weiterhelfen.
Es wird sich vermutlich um
am 14.04.2013 - 09:57 Uhr
Es wird sich vermutlich um Netzwerkprobleme und dadurch bedingte Timeouts handeln. Ich hatte z.B. letzte Woche das Problem, das ich keine US-Verbindungen aufbauen konnte. Das war ein Problem bei meinem Internetprovider. Auf meinem Server bei einem Hoster kommt es immer mal wieder vor, daß es für einzelne Domains solche Meldungen gibt, aber das löst sich meist von selbst.
Beste Grüße
Werner
Halloich habe seit dem 13.4.
am 15.04.2013 - 14:01 Uhr
Hallo
ich habe seit dem 13.4. das gleiche Problem.
Hoster ist Strato (Shared Hosting). Kein eigener Server.
Hoffe es geht bald wieder, wie die Anderen Poster berichten.
cityboarding.de
am 14.04.2013 - 11:31 Uhr
Hallo
ich habe seit dem 13.4. das gleiche Problem.
Hoster ist Strato. Kein eigener Server.
Hoffe es geht bald wieder, wie die Anderen Poster berichten.
Bei mir ebenfalls Strato...
werde das mal via twitter Support melden, damit die Herren das fixen.
jedenfalls beruhigt es mich, dass es unwahrscheinlich ist dass ich irgend n Fehler in der DB oder ähnliches habe.
Das Problem kann auch ich
am 14.04.2013 - 12:00 Uhr
Das Problem kann auch ich bestätigen, meine eigenen Server haben keine Probleme beim Laden der Updatestati, bei Strato (Shared Hosting) hingegen werden keine Updatedaten geladen. Das Problem besteht seit gut 3-4 Tagen.
Ich habe gerade mit Strato
am 15.04.2013 - 14:00 Uhr
Ich habe gerade mit Strato telefoniert. Denen ist noch kein Problem bekannt und es gab wohl auch keine Umstellungen bei denen.
Die werden jetzt das Problem überprüfen und hoffentlich lösen.
Darüber werde ich per eMail benachrichtigt.
Antwort/Ergebnis werde ich hier posten.
Hoffe das es bald wieder funktioniert, drücke Euch auch die Daumen.
Gruß Marcus
Hmm, hatte das Problem dem
am 15.04.2013 - 14:10 Uhr
Hmm, hatte das Problem dem Support auch schon gemeldet ... A weiss mal wieder nicht was B macht ... ist ja immer das Gleiche
Bei mir das gleiche Problem
am 16.04.2013 - 17:40 Uhr
Hi,
ich habe auch seit Tagen das gleiche Problem unter einem Strato Power Web Paket. Lokal läuft bei identischer Einstellung alles einwandfrei.
Ich wurde eben am Telefon von der Strato Mitarbeiterin damit "abgefertigt", dass bei Denen nichts geändert wurde und es ein Drupualseitiges Problem sein muss.
Da ist es dann aber doch komisch, dass lokal alles einwandfrei funktioniert. Habe extra zusätzlich eine kleine Installation mit nur wenigen Modulen getestet, auch hier geht es unter Strato nicht.
Ich habe daher eben noch einmal eine Mail an den Support geschrieben und auf diesen Beitrag verwiesen in der Hoffnung das man sich dem Problem dann mal annimmt.
Besteht bei Euch das Problem auch noch, bzw. habt Ihr schon eine Reaktion von Strato bekommen?
Ich will echt ungern den Anbieter wechseln, aber so kann ich damit auf Dauer nicht leben. Im Moment mache ich die updates lokal und lade die neuen Module dann über FTP zu Stato hoch.
Viele Grüße
Antonia
Habe gestern das Problem
am 16.04.2013 - 19:33 Uhr
Habe gestern das Problem gemeldet aber bisher noch keinerlei Feedback von Strato erhalten.
habe aber auch diesen Fred hier verlinkt
Ich hatte mich in diesen
am 16.04.2013 - 19:10 Uhr
Ich hatte mich in diesen Thread eingeklingt und das funktioniert soweit
http://www.drupalcenter.de/node/34938
Ansonsten ist das Problem unter admin/reports/updates mit manuell überprüfen eigentlich auch behoben.
Grüße Jenna
Bei mir funktioniert unter Strato auch manuell seit Tagen nichts
am 16.04.2013 - 19:25 Uhr
Ich versuche schon seit Tagen das update manuell zu starten. Auch das geht absolut gar nicht!
muss ich leider zustimmen. es
am 16.04.2013 - 19:31 Uhr
muss ich leider zustimmen. es fühlt sich so an, als würde Drupal hängen. der Fortschrittsbalken der sich füllt beim manuellen Updatecheck bewegt sich keinen Millimeter, bis er irgendwann (vermutlich wegen timeout) ein Problem meldet (siehe Ausgangspost) und 29 Projekte nicht aktualisiert werden konnten.
Leider findet sich auch keinerlei zusätzliche Info in den Database logging modul einträgen...
So habe heute noch einmal mit
am 16.04.2013 - 23:57 Uhr
So habe heute noch einmal mit Strato telefoniert. Meine Meldung von gestern war nicht mehr vorhanden. Die haben also rein garnichts gemacht.
Heute dann aber eine Ticket Nr. erhalten mit der ich hoffentlich auf dem laufenden gehaltern werde.
Ich benutze Drupal 7.22
Corn durchgeführt. bringt nichts.
berichte/verfügbare aktuallisierungen (gedrückt) danch alle module grau.
manuell überprüfen, fortschritsbalken kommt mit darunter steht Fehlern beim prüfen.
Den Tip von Jenna habe ich ausprobiet. Danach war meine Seite nicht mehr erreichbar. Daher rückgängig gemacht.
Da ich die Seite sicher brauche, werde ich wohl den Hoster wechseln müssen.
Sollte sich noch was tuen, melde ich mich.
Gruß Marcus
habe bei allinkl gerade eben
am 17.04.2013 - 05:39 Uhr
habe bei allinkl gerade eben solches problem. mit der fehlermeldung.
allerdings wenn ich dann die modulliset ansehe ist alles grün...
Strato arbeitet laut Email daran.
am 17.04.2013 - 16:45 Uhr
Hallo,
ich habe heute eine Email Antwort erhalten, dass Strato jetzt an dem Problem arbeitet:
vielen Dank für Ihre Anfrage, die ich Ihnen gerne beantworte.
Entschuldigen Sie die Umstände, das Problem ist uns bekannt und wir sind bereits dabei umgehend eine Lösung zu finden.
Gruß
Antonia
Hi habe um 17:38 auch eine
am 17.04.2013 - 20:36 Uhr
Hi
habe um 17:38 auch eine Antwort erhalten.
"ich möchte Sie mit dieser E-Mail über den Bearbeitungsstand Ihres Troubleticket informieren.
Sie haben uns mitgeteilt, dass es beim Update von Drupal zu Unregelmäßigkeiten gekommen ist.
Die Drupal-Update-Server prüfen wohl auf welchen Server die Dupal-Version installiert ist und filtert demzufolge die Updatemöglichkeit.
Bedauerlicherweise können wir dahingegen keine Änderung herbeiführen, da die Programmierung und auch die Update-Server von Drupal adminstriert werden. Wenden Sie sich dazu bitte an den Support von Drupal unter http://drupal.org/support
Für Ihre Mithilfe bei der Problemlösung möchten wir uns vorab schon bei Ihnen bedanken.
Mit freundlichen Grüßen"
An der Antwort kann man erkennen das der Support leider nicht zuhört.
Ich hoffe das bei Antonia was anderes raus kommt.
Gruß Marcus
caw schriebhabe bei allinkl
am 17.04.2013 - 21:07 Uhr
habe bei allinkl gerade eben solches problem. mit der fehlermeldung.
allerdings wenn ich dann die modulliset ansehe ist alles grün...
über Module/Aktualisieren steht auch bei mir erstmal das alles Aktuell ist. Drücke ich auf der Seite aber auf Manuell überprüfen erscheint wieder die Fehlermeldung: Fehler beim Prüfen von Daten über verfügbare Aktualisierungen für xxxx Projekte.
Schade.
Bei drupal.org habe ich nach diesem Fehler gesucht. Ich bin nicht fündig geworden.
Gruß Marcus
Meine Antwort ist von 13:30 Uhr...
am 17.04.2013 - 21:09 Uhr
Ich hoffe auch das die tatsächlich noch was machen! Meine Antwort ist von einem früheren Zeitpunkt.
Also, wenn es am Server liegt heißt das jetzt, die haben meine Installationen alle auf einen anderen Server umgezogen oder an dem Server die Einstellungen geändert? Schließlich ging es ja die ganze Zeit davor und ich kann selbst nichts an den Server Einstellungen ändern.
Also gut, es bleibt zu hoffen.
Gruß
Antonia
Es kann nur an Strato liegen,
am 18.04.2013 - 08:52 Uhr
Es kann nur an Strato liegen, denn auf meinem Root-Server (nicht Strato) funktioniert alles einwandfrei und die Daten werden geladen, nur der Strato Shared-Host macht Probleme beim Laden der Updatestati.
Wollen mal hoffen, dass da noch was passiert, ist nämlich echt nervig wenn man nicht weiss wie der Status der Module und des Cores ist.
Natürlich liegts an
am 18.04.2013 - 09:34 Uhr
Natürlich liegts an Strato.
1. trat der Fehler erst letzte Woche auf
2. haben mehrere Strato Kunden das Problem
3. existiert das Problem auf nicht-Strato Hosts inkl. localhosts einfach nicht.
bei mir hat sich jetzt der Support gemeldet und hat um Freigabe des Kundencenters gebeten, damit die sich das ansehen können.
Die kopieren sich dann den Content und testen das wohl auf ner local testumgebung, wollen wir hoffen das die genauso streikt wie die shared hosts... da die ansonsten sagen das das problem nich existent sei
es scheint also was zu passieren.
Hi Rikibu das klingt ja schon
am 18.04.2013 - 18:00 Uhr
Hi Rikibu
das klingt ja schon mal gut. Ich war schon auf der Suche nach einem anderen Hoster.
Hoffe das Problem lässt sich lösen. Ich muß sonst umziehen.
Gruß Marcus
Ich auch
am 18.04.2013 - 19:03 Uhr
Hallo an alle,
ich habe das Problem auch seit dem update auf 7.22 - vorher gings auf dem Strato-Paket. Strato bietet ja selbst auch drupal als app an, aber die nutzen noch 7.20 und spätestens wenn die auch auf 7.22 updaten, werden die Fehler dort bemerkt und hoffentlich beseitigt.
Das update 7.22 hat 3 neue Tabellen geschrieben, daran wird es liegen. Leider kann man jetzt nicht mehr rückwärts auf 7.20 zurück, da wäre das Problem nicht mehr. Vielleicht findet ja jemand die neuen Einträge in der Datenbank und kann diese definieren?
Hallo willipuh leider kann
am 18.04.2013 - 19:10 Uhr
Hallo willipuh
leider kann ich Deine Vermutung nicht bestätigen. Ich habe am 3.4. auf 7.22 upgedatet und hatte keine Probleme mit meinen Updates. Erst ab dem 13.4.
Sonst hätte man einfach downgraden können.
Gruß Marcus
Die Problematik ist
am 18.04.2013 - 19:16 Uhr
Die Problematik ist vollkommen unabhängig welche 7er Version von Drupal eingesetzt wird.
Ich habe sowohl eine 7.17er Appwizard Installation (welche sich partout nicht auf die neueste im Kundencenter verfügbar gezeigte Version updaten lässt)...
als auch eine manuell eingerichtete 7.22er Version mit der selben (geupdateten von 7.17er) Datenbank getestet...
Dritter und aussagekräftigster TEst war, ein neues Drupal von Stratos Appwizard einzurichten (glaube 7.20 oder 7.21) - dann bewusst ein älteres Modul eingespielt, um die Updateverfügbarkeit zu testen... und auch hier zeigte sich beschriebenes Problem.
Folglich komme ich dank meiner 3 Tests zu dem Schluss, dass der Fehler nicht an Drupal selbst liegt, weil alle 3 Installationen lokal auf meinem xampp die Updateprozedur problemlos meistern...
hier liegt sicher irgend ein Routing Problem oder DNS Fehler oder was auch immer vor. Leider gibts ja keine weiteren Infos in den logfiles...
Hab heute diese Antwort vom support bekommen
am 19.04.2013 - 14:59 Uhr
Sehr geehrter Herr Kahle,
vielen Dank für Ihre Anfrage, die ich Ihnen gerne beantworte.
Sie haben uns mitgeteilt, dass Sie bei der Drupal Aktualisierung Einschränkungen wahrnehmen.
Gern habe ich Ihr Anliegen überprüft und konnte keine serverseitige Einschränkung feststellen.
Die Drupal-Update-Server prüfen wohl auf welchen Server die Drupal-Version installiert ist und filtert demzufolge die Updatemöglichkeit.
Bedauerlicherweise können wir dahingegen keine Änderung herbeiführen, da die Programmierung und auch die Update-Server von Drupal administriert werden. Wenden Sie sich dazu bitte an den Support von Drupal unter http://drupal.org/support
Für Ihre Mithilfe bei der Problemlösung möchten wir uns vorab schon bei Ihnen bedanken.
Hallo ich habe noch mal mit
am 19.04.2013 - 15:37 Uhr
Hallo
ich habe noch mal mit Strato Telefoniert.
Das Problem ist schon mal bekannt.
Laut meinem Gesprächspartner: Schaut unsere jeweilige Drupal Installation bei drupal.org nach ob updates vorliegen. Drupal.org hat anscheinend Strato Hosting Pakete ( können anhand der ip Adressen erkannt werden) vom update ausgeschlossen.
Strato ist anscheinend auch schon im Kontakt mit drupal.org um die updates wieder zu ermöglichen.
Ich hoffe noch ein wenig weiter.
Gruß Marcus
klingt erstmal plausibel, da
am 19.04.2013 - 17:04 Uhr
klingt erstmal plausibel, da es ja nur bei strato auftritt. aber aus welchem grund sollte drupal auf diese Weise die Nutzung seines Systems quasi unattraktiver machen?
Strato Drupal Update überprüfung Fehlerhaft
am 22.04.2013 - 14:00 Uhr
Hallo
Habe noch etwas weiter recherchiert.
Auf http://drupal.org/project/issues/drupal nach update gesucht. Dies habe ich gefunden.
Habe dann diesen Lösungsweg gefunden: http://drupal.org/node/1547522
Wenn das jemand für Laien übersetzen könnte wäre das vielleicht hilfreich.
Passend dazu habe ich unter Berichte/statusbericht folgende Meldung erhalten:
HTTP-Anfragestatus Fehlgeschlagen
Ihre System oder Netzwerk-Konfiguration erlaubt Drupal keinen Zugriff auf andere Web-Seiten, wodurch die Funktionalität eingeschränkt ist. Damit werden Informationen zu verfügbaren Updates geladen, RSS-Feeds bezogen, die Anmeldung über OpenID durchgeführt u.ä. Wenn Sie sicher sind, dass Drupal auf andere Web-Seiten zugreifen kann, aber Sie sind immer noch diese Nachricht sehen, können Sie die Prüfung unterdrücken, indem Sie $conf['drupal_http_request_fails'] = FALSE; in der zweiten Hälfte Ihrer settings.php Datei hinzufügen.
Ich habe versucht Stato darüber in kenntniss zu setzen, hatte aber leider diesmal pech mit dem Mitarbeiter. Es klang so als wäre nichts weiter geschehen. Er fragte mich wieso Sie Kontakt zu Drupal aufnehmen sollten? (siehe mein letzes Posting)
Vielleicht um das Problem zu lösen?
Gruß Marcus
Angeblich bestehen keine
am 23.04.2013 - 18:46 Uhr
Angeblich bestehen keine Fehler an der Strato Serverkonfiguration...
Ich habe soeben einen Info von unserer Technik erhalten:
Bezüglich dessen, dass Sie die direkten Module nicht updaten konnten, konnte unsere Technik nicht feststellen, dass der Fehler im Adminbereich an unseren Hostingpaketen, am App-Wizard liegt.
das kann doch nicht deren ernst sein, diesen Zustand so belassen zu wollen.
cityboarding.de
am 23.04.2013 - 21:11 Uhr
Hallo
ich habe noch mal mit Strato Telefoniert.
Das Problem ist schon mal bekannt.
Laut meinem Gesprächspartner: Schaut unsere jeweilige Drupal Installation bei drupal.org nach ob updates vorliegen. Drupal.org hat anscheinend Strato Hosting Pakete ( können anhand der ip Adressen erkannt werden) vom update ausgeschlossen.
Strato ist anscheinend auch schon im Kontakt mit drupal.org um die updates wieder zu ermöglichen.
Ich hoffe noch ein wenig weiter.
Gruß Marcus
Das hoffe ich auch!
Ich meine die bewerben auf Ihrer Seite ja, dass Drupal da läuft:
Welche CMS unterstützt STRATO?
Die populärsten CMS-Systeme, wie Wordpress, Drupal, Joomla, PHPBB oder Typo3 werden serverseitig ausgeführt. Das bedeutet, dass Sie ein Hosting-Paket mit bestehender Unterstützung von serverseitigen Scriptsprachen (PHP ab Version 5) besitzen müssen oder alternativ einen eigenen Webserver betreiben. Für die Nutzung der Software ist zudem eine bestehende MySQL5-Datenbank notwendig.
Die STRATO Hosting Pakete (ab PowerWeb Starter) unterstützen folgende CMS-Standards: Wordpress, Joomla, Drupal, phpbb, TYPO3 und Contao und bietet diese über den AppWizard als 1-Click Installation an.
Wenn drupal.org jetzt bewusst diese Strato-Pakete ausschließt, dann muss Strato drupal ja wohl mit irgendwas verärgert haben. Vermutlich müssen die für diese 1-Click Installation Lizenzgebühren zahlen und Strato und drupal sind sich nicht einig in welcher Höhe? Ansonsten fällt mir kein plausiebler Grund ein wieso die Strato Kunden aussprerren sollten. Echt ärgerlich und auf jeden Fall von Strato und nicht von uns Usern zu lösen! Es werden wohl kaum fünf Strato User drupal so verägert haben, dass die dann alle Strato User sperren, da wird wohl eher Stato irgendwas nicht zur Zufriedenheit von drupal erledigt haben.
Es bleibt ab zu warten und zu hoffen!
Gruß
Antonia
Lizenzgeobühr für Open Source
am 23.04.2013 - 21:24 Uhr
Lizenzgeobühr für Open Source software? Eher nicht...eher ein proxyfehler intern bei strato oder sowas
Hab' noch mal nach gefragt, soll mich an drupal wenden
am 25.04.2013 - 16:53 Uhr
Hallo,
ich habe heute folgende Antwort bekommen
vielen Dank für Ihre Anfrage, die ich Ihnen gerne beantworte.
Ich habe mich eben noch mal erkundigt.
Aktuell sieht es so aus, als wäre es erforderlich, dass Sie sich beim Drupal Support melden, damit diese den Block entfernen.
Wir haben leider keinen Drupal Support, geben lediglich an, dass unser Webspace mit dem CMS kompatibel ist.
Es tut mir leid, dass ich Ihnen keine positivere Meldung geben kann.
Für weitere Fragen stehen Ihnen meine Kollegen und ich jederzeit gern zur Verfügung.
Na toll, hat sich schon Einer von Euch direkt an drupal gewendet?
Gruß
Antonia
Ich wüsste nich wo man sich
am 25.04.2013 - 17:25 Uhr
Ich wüsste nich wo man sich da hin wenden soll. Ich würde ja Anfragen aber mein englisch is schlecht
Mein Englisch ist auch schlecht, aber ich versuche es jetzt mal
am 25.04.2013 - 17:39 Uhr
Mein Englisch ist auch ziemlich schlecht, aber ich probiere es jetzt mal unter bugs beim Core.
http://drupal.org/node/1979796
Gruß
Antonia
Hier im Fred wurde doch schon
am 25.04.2013 - 17:45 Uhr
Hier im Fred wurde doch schon irgendwie son issue Ding gepostet, vielleicht da dranhängen
Ich geb's echt langsam auf...
am 25.04.2013 - 19:16 Uhr
So jetzt hatte ich Strato noch mal geschrieben das es schon schön wäre, wenn die sich um das Problem kümmern, da Sie ja schließlich angeben das drupal bei Ihnen läuft und das Problem nur bei Ihnen auftaucht, eine nette, aber absolut nicht das Problem ändernde Antwort:
Es gibt hierbei noch eine weitere Möglichkeit, die dabei helfen kann, dass die update.php wieder funktioniert. Sie können Ihre Drupal Installation mit einem manuellen Update versehen. Ich habe Ihnen eine Anleitung herausgesucht, die diesen Vorgang genau beschreibt.
http://www.drupalcenter.de/handbuch/upgrade
Bitte führen Sie vorher eine ausführliche Sicherung Ihrer Seite durch.
Ich freue mich, wenn ich Ihnen weiterhelfen konnte.
Sollten Sie weitere Unterstützung benötigen, stehen Ihnen meine Kollegen und ich gerne zur Verfügung.
Tipp: Nutzen Sie auch gerne eine der größten deutschsprachigen FAQ-Datenbanken unter www.strato-faq.de mit über 2.000 Anleitungen und Antworten auf häufig gestellte Fragen.
Selbstverständlich haben Sie auch die Möglichkeit uns telefonisch zu kontaktieren um Ihr Anliegen persönlich mit uns zu besprechen. Sie erreichen uns von Mo-Fr von 07:00-23:00 Uhr und Sa-So von 10:00-18:30 Uhr unter 030-300 146 22.
Ich sende Ihnen Grüße aus Berlin und wünsche noch einen schönen Tag.
Tja, also manuell updaten indem ich das ganze über FTP-upload mache kann ich auch und so löse ich das Probleme ja im Moment auch schon seit dem es aufgetaucht ist:
Update.php lokal laufen lassen und dann die neuen Module per FTP nach Strato hoch laden. ABER das ist ja wohl keine Lösung! Zumal meine lokales drupal ja nun nicht automatisch meldet wenn ein wichtiges update da ist! Heißt ich muss jetzt jeden Tag manuell nach gucken ob es vielleicht kritische upates gibt? Oh man... ich hoffe das sich da echt noch was ändert. Ich habe so was von keine Lust mit meinen Seiten um zu ziehen. Aber wenn sich das nicht ändert werde ich es wohl tun müssen. Also ich verlange dann auf jeden Fall die Möglichkeit ohne Einhaltung der Kündigungsfirst aus dem Stato-Vertrag raus zu kommen. Schließlich halten die nicht was Sie versprechen. drupal läuft im Moment NICHT vernünftig unter Strato!
Gruß
Antonia
Hab mal folgenden Sachen
am 26.04.2013 - 10:52 Uhr
Hab mal folgenden Sachen ausprobiert:
<?php
// Connection timout
var_dump(file_get_contents('http://updates.drupal.org/'));
?>
<?php
// Funktioniert einwandfrei
var_dump(file_get_contents('http://www.google.com'));
?>
Ich habe somit die Vermutung, dass Strato geblockt wird
Ich habe nun einen Eintrag in
am 26.04.2013 - 11:14 Uhr
Ich habe nun einen Eintrag in den Webmaster Issues auf drupal.org angelegt, vielleicht kommentiert der eine oder andere das Ganze dort auch einmal. http://drupal.org/node/1980352
hab mich mal mit
am 26.04.2013 - 12:53 Uhr
hab mich mal mit reingehängt... ma sehn obs was bringt.
ich kann auf dem kundenhost
am 26.04.2013 - 12:57 Uhr
ich kann auf dem kundenhost nur kein traceroute ausführen, da ich keinen SSH-Zugang habe, kannst Du das vielleicht mal checken und posten
Bin leider auch nur shared
am 26.04.2013 - 13:42 Uhr
Bin leider auch nur shared host Kunde
Bei den meisten Paketen ist
am 26.04.2013 - 14:12 Uhr
Bei den meisten Paketen ist aber ein SSH-Zugang verfügbar. Ich kann nur nicht darauf zugreifen weil ich generell keinen Zugang zum Kundenmenü habe um das Ganze einrichten zu können.
mmmh, ich schaue mal... habe
am 26.04.2013 - 15:40 Uhr
mmmh, ich schaue mal...
habe tatsächlich ssh-Zugang. nur was ich da eintippen muss, weiß ich nicht.
habe mich jetzt auf ssh.strato.de eingeloggt, meine Domain als Nutzername und Masterpasswort eingeklimpert...
und nun?
was für Kommandos muss ich da reintippen?
traceroute updates.drupal.org
am 26.04.2013 - 15:50 Uhr
traceroute updates.drupal.org
mmmh... der findet das
am 26.04.2013 - 18:21 Uhr
mmmh... der findet das kommando nicht
nutze das Mac OS Terminal... damit ist ja ssh möglich.
Hi Sense habe dieses dazu
am 26.04.2013 - 18:26 Uhr
Hi Sense
habe dieses dazu gefunden:
http://drupal.org/node/549934
ist zwar alles schon was älter, sieht aber stark nach unserer Porblematik aus.
Leider verstehe ich nicht alles was dort steht, bin leider kein Serverprofi.
Vieleicht kann jemand was dort steht so zusammenfassen, das auch nicht Profis dieses nachvollziehen können.
Ich hatte übrigens noch mal mit Strato Telefoniert, weil die mein Tiket schon wider mit der Standart Antwort geschlossen hatten. Soll nun ans Produktmanagement weitergeleitet werden. Mit einer Antwort kann ich innerhalb von 4 Wochen rechnen. Mal sehen.
Bei dem Telefonat habe ich auch schon meine baldige Kündigung wegen nicht Vertragserfüllung erwähnt, da ja Drupal Funktionalität zugesagt wird. Laut Mitarbeiter gilt dies aber nur wenn Drupal mit der Automatikinstallation von Strato vorgenommen wurde. Ich habe Drupal per FTP aufgeset.
Gruß Marcus
Ich kann dich beruhigen,
am 26.04.2013 - 18:36 Uhr
Ich kann dich beruhigen, Drupal funktioniert mit der Appwizard Installation genausowenig was die automatischen Updates angeht.
Die wollen nur, dass man das appwizard zeuch verwendet, was aber
a) total veraltet ist
b) sich in meinem fall von 7.17 nicht updaten lässt, obwohl im kundencenter ne neue Version angezeigt wird
das alles soll nur supportaufwand minimieren...
so richtig verantwortlich scheint sich aber niemand zu fühlen.
cityboarding.de schrieb Hi
am 26.04.2013 - 18:44 Uhr
Hi Sense
habe dieses dazu gefunden:
http://drupal.org/node/549934
ist zwar alles schon was älter, sieht aber stark nach unserer Porblematik aus.
Leider verstehe ich nicht alles was dort steht, bin leider kein Serverprofi.
Vieleicht kann jemand was dort steht so zusammenfassen, das auch nicht Profis dieses nachvollziehen können.
dt. Übersetzung des Links - siehe Zitat
Am 13. August habe ich begonnen festzustellen, dass meine Cronjobs anfingen hängenzubleiben und ewig brauchen. Nach Nachforschungen fand ich heraus, dass der update Status nicht funktionierte und ich in meinen Logdateien "Nicht möglich Informationen über verfügbare updates und releases" fand.
Dann führte ich folgendes Kommando auf meinem Server aus, auf dem meine Seiten liegen
"wget http://updates.drupal.org/release-history/notofy/6.x"
Das Ergebnis war, dass es sich auffing, auch nach mehreren Versuchen.
Wenn ich das Kommando von einem anderen Server aus ausführe, lässt sich das xml File ohne Probleme herunterladen.
….
Ja wir benötigen von einem
am 26.04.2013 - 21:51 Uhr
Ja wir benötigen von einem der Server eine "traceroute", es scheint so das irgendwo der ganze Request "hängen" bleibt und nicht weitergeleitet wird, warum auch immer.
ich würde ja mit ssh die
am 27.04.2013 - 08:17 Uhr
ich würde ja mit ssh die traceroute hier posten, aber die Mac OS Terminal Anwendung kennt den Befehl traceroute nicht - oder der ist seitens Strato gesperrt.
ich öffne ein Terminal Fenster, gebe
ssh ssh.strato.de -l benutzername (der die domain ist) ein
anschließend Masterpasswort
nun kann ich offensichtlich ssh commands eingeben.
gebe ich nun "traceroute updates.drupal.org" ein
so steht da
traceroute: command not found
und ich lande wieder am prompt, wo mein nutzername (also domainname) vorne steht
eigentlich mach ich doch nix falsch, oder?
ssh
am 28.04.2013 - 14:34 Uhr
Hallo,
traceroute benötigt root -Rechte und dann muß man schon einen eigenen Server haben.
Hat denn schon jemand versucht updates über einen Proxy zu beziehen?
Grüße,
Jens
wie soll das denn gehen über
am 28.04.2013 - 17:22 Uhr
wie soll das denn gehen über nen proxy?
wenn strato hosts bei drupal geblockt werden, dann werden die doch auch über den proxy geschickt und demzufolge auch geblockt...
oder denke ich falsch?
Wenn ein Datenpaket von
am 29.04.2013 - 18:07 Uhr
Wenn ein Datenpaket von Strato über einen Proxy geht, ist der Absender der Proxy und eben nicht Strato. Nur kann das auch, wenn überhaupt möglich, ein Sicherheitsrisiko sein.
Nur so langsam könnte da mal was von Drupal kommen. Es kann nicht sein, das von einem der größten deutschen Webhoster Datenanfragen geblockt werden.
Grüße
Strato Drupal 7.x
am 30.04.2013 - 12:30 Uhr
Hi @ all,,
ich betreue mehrere Seiten mit Drupal 7.x bei Strato. Eure Probleme sind auch meine. Und es kann nur an Strato liegen.
Denn ich habe noch eine mit Drupal 7.x und gleichen Standes bei T-Online und da geht es wunderbar.
LG Revere
mmmh, offfenbar noch immer
am 30.04.2013 - 19:08 Uhr
mmmh, offfenbar noch immer keine Lösung. Drupal selbst is auch stumm wie n Fisch...
und zu allem Überfluss ist derzeit die Performance meines strato shared hosts unter aller Sau...
Ich denke nicht, dass das
am 01.05.2013 - 00:03 Uhr
Ich denke nicht, dass das Problem bei Strato liegt. Wir hosten einige Kunden Sites in der Acquia Cloud und auch da taucht das gleiche Problem auf. Und das seit D 7.22, wenn ich nichts übersehen habe.
Manuell funktioniert es.
es funktioniert aber bei uns
am 01.05.2013 - 07:43 Uhr
es funktioniert aber bei uns strato geplagten nicht mal manuell... der request kommt einfach nicht durch.
Nochmal bei Strato angefragt
am 03.05.2013 - 11:24 Uhr
Habe vorhin einen Screenshot des Update-Problems bei einer erst minutenalter AppWizard-Installation per Kundenservice-Formular nochmal an Strato gesendet, mit Hinweis auf eine weitere andere Installation (auch bei Strato, selbes Problem) und auf diesen Thread hier.
Vielleicht macht's die Masse ja.... schaunmermal
Antwort von Strato :)
am 06.05.2013 - 08:59 Uhr
Sehr geehrter Herr ,
vielen Dank für Ihre Anfrage, die ich Ihnen gerne beantworte.
Sie haben uns mitgeteilt, dass Sie bei der Drupal Aktualisierung Einschränkungen wahrnehmen.
Gern habe ich Ihr Anliegen überprüft und konnte keine serverseitige Einschränkung feststellen.
Die Drupal-Update-Server prüfen wohl auf welchen Server die Drupal-Version installiert ist und filtert demzufolge die Updatemöglichkeit.
Bedauerlicherweise können wir da hingegen keine Änderung herbeiführen, da die Programmierung und auch die Update-Server von Drupal administriert werden. Wenden Sie sich dazu bitte an den Support von Drupal unter http://drupal.org/support
Eine weitere Möglichkeit, die dabei helfen kann, dass die update.php wieder funktioniert, ist es Ihre Drupal Installation mit einem manuellen Update zu versehen. Ich habe Ihnen eine Anleitung herausgesucht, die diesen Vorgang genau beschreibt.
http://www.drupalcenter.de/handbuch/upgrade
Bitte führen Sie vorher eine ausführliche Sicherung Ihrer Seite durch.
Ich freue mich, wenn ich Ihnen weiterhelfen konnte.
Viele Grüße aus Berlin und eine schöne Woche für Sie.
Ihre Meinung über unseren Kundenservice ist uns sehr wichtig!
Bitte nehmen Sie sich etwas Zeit für unseren Fragebogen - damit wir zukünftig noch besser auf Ihre Wünsche eingehen können.
Link zum Bewertungssystem: https://www.strato-mailcenter.com...................DAS HABE ICH GEMACHT !!!!
Mit freundlichen Grüßen
Thomas Jahnke
STRATO Customer Care
Das ist das allerletzte die lesen die Mails nicht richtig und schieben alles auf Drupal. Ist nur komisch das eine fast Identische Seite bei T.Online läuft ????????????????
Was nun ????????
Jetzt werde ich aber langsam
am 06.05.2013 - 17:37 Uhr
Jetzt werde ich aber langsam rasend. Ist es nicht Stratos Pflicht dass die dafür sorgen, dass deren beworbene Features wie Drupal und co. auch so funktionieren wie beworben?
Ist doch mittlerweile sehr schnell nachweisbar, dass Strato blockiert wird, selbst wenn man ein knackfrisches appwizard drupal installiert...
sollte Strato nicht daran gelegen sein, dass deren Produkte selbst wenn sie von drittanbietern stammen, auch funktionieren?
Hätte eine Nachfrage seitens Strato nicht mehr Druck dahinter als die paar Anfragen von vermeintlichen Privatnutzern mit kleinem Licht?
Kann diese ziemlich arrogante Haltung absolut nicht nachvollziehen, stattdessen wird man mit dem Problem alleine gelassen...
Sehe ich genauso!
am 06.05.2013 - 19:00 Uhr
Ich sehe es genauso, dass Strato sich mit Drupal in Verbindung setzen müsste!
Wir sind wohl nicht genug Kunden die sich darüber beschweren.
Vor Jahren gab es wohl schon mal ähnliche Probleme mit Strato. Ich weiß nicht wie die das Problem damals gelöst haben.
Gruß
Antonia
Updatecheck fehlerhaft
am 06.05.2013 - 19:00 Uhr
Hallo
bin auch bei Strato und habe da mal nachgefragt .Dieses Problem schein sehr bekannt zu sein leider gibt´s noch keine Lösung .Wie schon mal von anderen erwähnt versuchen sie Drupal die Schuld zu geben. Als Antwort bekam ich " Bitte warten..... " Fragt sich nur wie lange ....:(
Hallo, und das sehe ich etwas
am 06.05.2013 - 20:05 Uhr
Hallo,
und das sehe ich etwas anders, wenn man jetzt schon Strato braucht, um Drupal in Bewegung zu setzen, na dann "Gute Nacht". Das ist zumindest keine gute Werbung für Drupal. Was soll denn Strato an seinen Einstellungen ändern? Drupal blockt update-Anfragen mit Strato_Absendern und das ist wohl so.
Warum das so ist, weiß auch keiner, oder?
Wer kennt die Hintergründe?
am 06.05.2013 - 20:21 Uhr
und das sehe ich etwas anders, wenn man jetzt schon Strato braucht, um Drupal in Bewegung zu setzen, na dann "Gute Nacht". Das ist zumindest keine gute Werbung für Drupal.
Das sehe ich genauso. Strato scheint hier bei Drupal auf einer Black-List gelandet zu sein. Dafür gibt es sicher Gründe. Das jetzt aber die Strato-Kunden keinen Drupal-Support mehr haben sollen, scheint mir der falsche Weg von Drupal zu sein.
Drupal blockt update-Anfragen mit Strato_Absendern und das ist wohl so.
Warum das so ist, weiß auch keiner, oder?
Das ist wohl die richtige Frage. Wer weiß es und wie kann man das ändern? Ich habe mein Paket erst im Februar zu Strato umgezogen und mich dort für 24 Monate gebunden. Soll ich jetzt die Support-Einbußen haben? Dann wüßte ich gerne, warum. Wenn mir es plausibel erscheint, dann kann ich damit leben, ansonsten fühle ich mich schlichtweg im Stich gelassen.
Es gibt doch im Team von Drupalcenter.de sicher ein paar Leute, die näheren Kontakt zu Drupal.org haben. Kann da mal jemand nachhaken und für die Allgemeinheit eine Erklärung geben. So ist das ja wohl kein Zustand - sieht man schon an der zunehmenden Länge des Threads und auch wohl an der zunehmenden Aggressivität der Postings.
Prinzipiell ist Strato mein
am 06.05.2013 - 21:28 Uhr
Prinzipiell ist Strato mein Vertragspartner und daher auch mein erster Ansprechpartner bei Problemen. Erst recht wenn der Betrieb von Drupal beworben wird, der derzeit einfach nur unbefriedigend möglich ist da tendentiell sicherheitsgefährdet.
Auch die Frage, ob Strato nicht hier im Zugzwang ist, dieser Blockerei bei Drupal mal vorstellig zu werden - versaut ja beiden gewissermaßen die Tour .
Indem sich Strato jetzt so positioniert von wegen "an unseren Servern und Einstellungen liegt es nicht, fragt mal bei Drupal" hat man die Sache schön abgewälzt, was einfach nicht sein kann, da doch Strato im Interesse zufriedener Kunden selbst bei Drupal das Problem das sich ohne großen Aufwand reproduzieren lässt, vortragen könnte...
Dass das ein Imageproblem werden könnte, sowohl für Drupal sowie Strato, die einfach unbequeme Supportgeschichten an die Anwender zurückschieben, obwohl selbige nur die versprochen geglaubten Features versuchen zu nutzen, ist kein Geheimnis.
Fakt ist, es wird nix gelöst. Der Endkunde mit seinem Shared Host kann nur bedingt Aussagen dazu machen zu den Fragen die auf den Drupal Support Seiten von den Verantwortlichen abgefragt werden. Genasowenig wie man als selbst engagierter Anwender mit ssh irgendwelche traceroutes auswerten wollen würde, dies aber nicht kann weil die Rechte dazu fehlen usw. Hier kann nur Strato helfen - keiner sonst. Dazu müsste man aber seitens strato mal Kontakt mit Drupal aufnehmen und die Sache eben nicht aussitzen...
Indem man wie gesagt die Verantwortung weiterschiebt stellt man sich auch ein Armutszeugnis aus...
Schließlich kann nur Strato argumentativ untermauert dafür sorgen, von Drupal nicht mehr geblockt zu werden. Was soll ich kleiner user da ausrichten? als würden die Drupalaner auf mich hören (ich hab nich ma ne lösung für das problem)
uns bleibt wohl nur die Möglichkeit den Support mit Anfragen zu fluten bis es dem letzten supportmitarbeiter zu blöd wird und die direkt bei Drupal mal anfragen.
Ist schließlich nicht mein problme wieso die Infrastruktur von nem Anbieter geblockt wird, ich darf nur mit den Konsequenzen und dem Unwillen eines kostenpflichtigen Dienstleisters leben, und das ist ein scheißgefühl so hängen gelassen zu werden.
es sagt ja auch keiner das bei strato die Server fehlerhaft konfiguriert sind. Sie werden aus unerfindlichen Gründen von Drupal geblockt - und hier muss strato mal ran, obs denen passt oder nicht. Schließlich tritt dieser Fehler nur bei strato auf.
also ich habe auch zwei
am 07.05.2013 - 05:46 Uhr
also ich habe auch zwei kunden bei strato. bei einem läuft das problemlos, bei zwei anderen installationen komischerweise nicht.
beide male das gleiche paket. eines allerdings existiert schon länger!! und dort funktioniert es und komischerweise funkioniert die automatische übersetzungsaktualiserung auf allen installationen!
ich habe den unterschied gefunden: die php versionen. bei der funktionierenden ist es 5.2, bei der es nicht funkioniert 5.3...!!!
habe dann auf php 5.2 umgestellt. keine änderung. einziger unetrschied:
nicht funkionierende installation: "The timezone has been set to Europe/Berlin. Der erste Tag der Woche wurde auf Sonntag eingestellt."
funkionierende installation: "The timezone has been set to Europe/Berlin. Der erste Tag der Woche muss auf Montag gesetzt werden."
und das obwohl ich den auf montag gesetzt habe!!!
habe den eintrag in der nicht funktionierenden (date_first_day) in der db gelöscht. wurde dann aber automatisch auf sonntag gesetzt!
hat alles nichts geholfen..
hier die liste der unterschiede der phpinfo mit winmerge (und quellcode..).
zuerst die nicht funktionierende installation:
<tbody><tr><td class="e">System </td><td class="v">SunOS localhost 5.10 Generic_139556-08 i86pc </td></tr>
<tr><td class="e">Build Date </td><td class="v">Nov 21 2011 15:39:04 </td></tr>
<tr><td class="e">cURL Information </td><td class="v">libcurl/7.21.1 OpenSSL/0.9.8x zlib/1.2.5 libidn/1.14 </td></tr>
<tr><td class="e">iconv library version </td><td class="v">1.11 </td></tr>
<tr><td class="e">OpenSSL Version </td><td class="v">OpenSSL 0.9.8r 8 Feb 2011 </td></tr>
<tr><td class="e">UNIQUE_ID </td><td class="v">UYh9G8CoKYAAABiOUrIAAAFC </td></tr>
<tr><td class="e">RZ_n </td><td class="v">53379448 </td></tr>
<tr><td class="e">RZ_a </td><td class="v">:media:php=52:Rproxy:Cpremium:quota=6000MB: </td></tr>
<tr><td class="e">RZ_path </td><td class="v">webi/b0/48/53379448 </td></tr>
<tr><td class="e">SCRIPT_URL </td><td class="v">/admin/reports/status/php </td></tr>
<tr><td class="e">RZ_php </td><td class="v">52 </td></tr>
<tr><td class="e">HTTP_COOKIE </td><td class="v">has_js=1;
__utma=245039062.1983622859.1367898132.1367898132.1367898132.1;
__utmb=245039062.1.10.1367898132; __utmc=245039062;
__utmz=245039062.1367898132.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
SESS75f1911d1eda966771f0ce1a32a6d8bf=9WDsRmLX9EO2LJ_6ozNdgMz0tbr0biIEPX8XAUoYlFc
</td></tr>
<tr><td class="e">SCRIPT_FILENAME </td><td class="v">/home/strato/http/premium/rid/94/48/53379448/htdocs/bbt/index.php </td></tr>
<tr><td class="e">REMOTE_PORT </td><td class="v">50123 </td></tr>
<tr><td class="e">_REQUEST["__utma"]</td><td class="v">245039062.1983622859.1367898132.1367898132.1367898132.1</td></tr>
<tr><td class="e">_REQUEST["__utmb"]</td><td class="v">245039062.1.10.1367898132</td></tr>
<tr><td class="e">_REQUEST["__utmc"]</td><td class="v">245039062</td></tr>
<tr><td class="e">_REQUEST["__utmz"]</td><td class="v">245039062.1367898132.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)</td></tr>
<tr><td class="e">_REQUEST["SESS75f1911d1eda966771f0ce1a32a6d8bf"]</td><td class="v">9WDsRmLX9EO2LJ_6ozNdgMz0tbr0biIEPX8XAUoYlFc</td></tr>
<tr><td class="e">_COOKIE["__utma"]</td><td class="v">245039062.1983622859.1367898132.1367898132.1367898132.1</td></tr>
<tr><td class="e">_COOKIE["__utmb"]</td><td class="v">245039062.1.10.1367898132</td></tr>
<tr><td class="e">_COOKIE["__utmc"]</td><td class="v">245039062</td></tr>
<tr><td class="e">_COOKIE["__utmz"]</td><td class="v">245039062.1367898132.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)</td></tr>
<tr><td class="e">_COOKIE["SESS75f1911d1eda966771f0ce1a32a6d8bf"]</td><td class="v">9WDsRmLX9EO2LJ_6ozNdgMz0tbr0biIEPX8XAUoYlFc</td></tr>
<tr><td class="e">_SERVER["UNIQUE_ID"]</td><td class="v">UYh9G8CoKYAAABiOUrIAAAFC</td></tr>
<tr><td class="e">_SERVER["RZ_n"]</td><td class="v">53379448</td></tr>
<tr><td class="e">_SERVER["RZ_a"]</td><td class="v">:media:php=52:Rproxy:Cpremium:quota=6000MB:</td></tr>
<tr><td class="e">_SERVER["RZ_path"]</td><td class="v">webi/b0/48/53379448</td></tr>
<tr><td class="e">_SERVER["RZ_php"]</td><td class="v">52</td></tr>
<tr><td class="e">_SERVER["HTTP_COOKIE"]</td><td class="v">has_js=1;
__utma=245039062.1983622859.1367898132.1367898132.1367898132.1;
__utmb=245039062.1.10.1367898132; __utmc=245039062;
__utmz=245039062.1367898132.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
SESS75f1911d1eda966771f0ce1a32a6d8bf=9WDsRmLX9EO2LJ_6ozNdgMz0tbr0biIEPX8XAUoYlFc</td></tr>
<tr><td class="e">_SERVER["REMOTE_PORT"]</td><td class="v">50123</td></tr>
<tr><td class="e">_SERVER["REQUEST_TIME"]</td><td class="v">1367899420</td></tr>
<tr><td class="e">_ENV["UNIQUE_ID"]</td><td class="v">UYh9G8CoKYAAABiOUrIAAAFC</td></tr>
<tr><td class="e">_ENV["RZ_n"]</td><td class="v">53379448</td></tr>
<tr><td class="e">_ENV["RZ_a"]</td><td class="v">:media:php=52:Rproxy:Cpremium:quota=6000MB:</td></tr>
<tr><td class="e">_ENV["RZ_path"]</td><td class="v">webi/b0/48/53379448</td></tr>
<tr><td class="e">_ENV["RZ_php"]</td><td class="v">52</td></tr>
<tr><td class="e">_ENV["HTTP_COOKIE"]</td><td class="v">has_js=1;
__utma=245039062.1983622859.1367898132.1367898132.1367898132.1;
__utmb=245039062.1.10.1367898132; __utmc=245039062;
__utmz=245039062.1367898132.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
SESS75f1911d1eda966771f0ce1a32a6d8bf=9WDsRmLX9EO2LJ_6ozNdgMz0tbr0biIEPX8XAUoYlFc</td></tr>
<tr><td class="e">_ENV["REMOTE_PORT"]</td><td class="v">50123</td></tr>
und hier die funktionierende:
<tbody><tr><td class="e">System </td><td class="v">SunOS localhost 5.10 Generic_142900-13 sun4v </td></tr>
<tr><td class="e">Build Date </td><td class="v">Nov 9 2011 15:17:08 </td></tr>
<tr><td class="e">cURL Information </td><td class="v">libcurl/7.21.1 OpenSSL/0.9.8k zlib/1.2.5 libidn/1.14 </td></tr>
<tr><td class="e">iconv library version </td><td class="v">1.9 </td></tr>
<tr><td class="e">OpenSSL Version </td><td class="v">OpenSSL 0.9.8o 01 Jun 2010 </td></tr>
<tr><td class="e">UNIQUE_ID </td><td class="v">UYh9IcCoKVQAACT5ZYYAAAEq </td></tr>
<tr><td class="e">RZ_n </td><td class="v">5329322 </td></tr>
<tr><td class="e">RZ_a </td><td class="v">:media:php=44:sparc:Rproxy:Cpremium:quota=6000MB: </td></tr>
<tr><td class="e">RZ_path </td><td class="v">webh/b3/22/5329322 </td></tr>
<tr><td class="e">RZ_php </td><td class="v">44 </td></tr>
<tr><td class="e">REMOTE_PORT </td><td class="v">50129 </td></tr>
<tr><td class="e">_SERVER["UNIQUE_ID"]</td><td class="v">UYh9IcCoKVQAACT5ZYYAAAEq</td></tr>
<tr><td class="e">_SERVER["RZ_n"]</td><td class="v">5329322</td></tr>
<tr><td class="e">_SERVER["RZ_a"]</td><td class="v">:media:php=44:sparc:Rproxy:Cpremium:quota=6000MB:</td></tr>
<tr><td class="e">_SERVER["RZ_path"]</td><td class="v">webh/b3/22/5329322</td></tr>
<tr><td class="e">_SERVER["RZ_php"]</td><td class="v">44</td></tr>
<tr><td class="e">_SERVER["REMOTE_PORT"]</td><td class="v">50129</td></tr>
<tr><td class="e">_SERVER["REQUEST_TIME"]</td><td class="v">1367899426</td></tr>
<tr><td class="e">_ENV["UNIQUE_ID"]</td><td class="v">UYh9IcCoKVQAACT5ZYYAAAEq</td></tr>
<tr><td class="e">_ENV["RZ_n"]</td><td class="v">5329322</td></tr>
<tr><td class="e">_ENV["RZ_a"]</td><td class="v">:media:php=44:sparc:Rproxy:Cpremium:quota=6000MB:</td></tr>
<tr><td class="e">_ENV["RZ_path"]</td><td class="v">webh/b3/22/5329322</td></tr>
<tr><td class="e">_ENV["RZ_php"]</td><td class="v">44</td></tr>
<tr><td class="e">_ENV["REMOTE_PORT"]</td><td class="v">50129</td></tr>
und nch etwas: die nicht funktionierende installation ließ sich anfangs auch automatisch updaten. der fehler trat glaube ich nach dem core update auf....
Neuer Status: Antwort von Strato
am 08.05.2013 - 12:22 Uhr
Hi zusammen,
ich klinke mich nun auch mal ein, da wir ebenfalls seit April das Problem haben und auch mit Strato in Kontakt sind.
Hier die aktuellste Antwort von Strato, in der klar steht, dass die Problematik auf deren Seite liegt, da die Strato-IPs derzeitig blockiert werden:
Sehr geehrter Herr,
ich möchte Sie mit dieser E-Mail über den Bearbeitungsstand Ihres Troubleticket informieren.
Sie haben uns mitgeteilt, dass es beim Update von Drupal zu Unregelmäßigkeiten gekommen ist.
Der Drupal-Update-Server prüft auf welchen Server die Drupal-Version installiert ist und filtert demzufolge die Updatemöglichkeit. Unsere IP-Adresse wird vom Drupal-Update-Server aktuell blockiert, daher wird Ihnen die Updatemöglichkeit verwehrt.
Wir sind mit Drupal in Kontakt und die Funktion wird Ihnen in Kürze wieder zur Verfügung stehen.
Aktuell ist jedoch eine genauere Terminangabe der Funktion noch nicht möglich.
Eine weitere Möglichkeit, die dabei helfen kann, dass die update.php wieder funktioniert, ist es Ihre Drupal Installation mit einem manuellen Update zu versehen. Ich habe Ihnen eine Anleitung herausgesucht, die diesen Vorgang genau beschreibt.
http://www.drupalcenter.de/handbuch/upgrade
Bitte führen Sie vorher eine ausführliche Sicherung Ihrer Seite durch.
Für Ihre Mithilfe bei der Problemlösung möchten wir uns vorab schon bei Ihnen bedanken.
Bleibt nun zu hoffen, dass das Ganze bald gelöst wird.
Bei weiteren News werde ich hier wieder entsprechend informieren.
Ich drücke uns allen die Daumen!
Grüße
Strato Antwort Nr. 2
am 08.05.2013 - 17:47 Uhr
geht doch. Ist zwar keine Lösung aber eine ehrliche Antwort. :)))
Sehr geehrter Herr xxx,
vielen Dank für Ihre Anfrage, die ich Ihnen gerne beantworte.
Sie haben uns mitgeteilt, dass es beim Update von Drupal zu Unregelmäßigkeiten gekommen ist.
Wir bedauern die Unannehmlichkeiten natürlich sehr und bitten dies zu entschuldigen.
Der Drupal-Update-Server prüft auf welchen Server die Drupal-Version installiert ist und filtert demzufolge die Update-möglichkeit. Unsere IP-Adresse wird vom Drupal-Update-Server aktuell bedauerlicherweise blockiert, daher wird Ihnen die Update-möglichkeit verwehrt.
Wir sind mit Drupal im engem Kontakt um Ihnen die Funktion in Kürze wieder zur Verfügung stellen zu können.
Ich bedauere sehr Ihnen aktuell jedoch keine genauere Terminangabe geben zu können
Eine weitere Möglichkeit, die dabei helfen kann, dass die update.php wieder funktioniert, ist es Ihre Drupal Installation mit einem manuellen Update zu versehen. Ich habe Ihnen eine Anleitung herausgesucht, die diesen Vorgang genau beschreibt.
http://www.drupalcenter.de/handbuch/upgrade
Bitte führen Sie vorher eine ausführliche Sicherung Ihrer Seite durch.
Ich hoffe, ich konnte Ihnen damit weiterhelfen und wünsche noch eine angenehme Woche.
Ihre Meinung über unseren Kundenservice ist uns sehr wichtig!
Bitte nehmen Sie sich etwas Zeit für unseren Fragebogen - damit wir zukünftig noch besser auf Ihre Wünsche eingehen können.
Link zum Bewertungssystem: https://www.strato-mailcenter.com/quality?ident=bd391e7c-f6943d-17c259-4...
Mit freundlichen Grüßen
Marcel Rosnau
STRATO Customer Care
-------------------------------------------------------------------------------
Na das hört sich doch
am 08.05.2013 - 18:57 Uhr
Na das hört sich doch vielversprechend an.
Merkwürdig nur, dasss andere Leute (ich) obwohl sie den selben Fehler gemeldet haben, mittlerweile gar nix mehr hören über den Status des gemeldeten Problems.
aber gut das du uns auf dem Laufenden hälst.
Strato lässt Drupal-Nutzer im Regen stehen
am 08.05.2013 - 23:12 Uhr
Strato-Antwort vom 5.5.2013:
"Bitte beachten Sie die Kerninformation von meinen Kollegen:
'Laut meinen Kenntnissen, scheint der Drupal Update Server die STRATO IP zu blocken.
Darauf haben wir leider keinen Einfluss und ich würde Sie bitten sich an den Drupal Support zu wenden.'
Wenn Sie hierzu andere Informationen haben, teilen Sie mir diese bitte mit.
Vielen Dank für Ihre Mühe & Verständnis"
Schön fand ich, dass ein Link zum Bewertungssystem beigefügt war.
Pikant wird dies m. E., da die Anfrage im Tenor nicht "geht nicht, macht was!" war, sondern dass ich die Haltung von Strato angesprochen habe:
(...) Inhaltlich kann ich die von Ihnen geäußerte Haltung jedoch nicht
nachvollziehen. Einerseits "schmückt" sich Strato mit dem CMS DRUPAL -
an vielerlei Stellen.
Für viele Nutzer wird dies sicherlich auch ein Argument PRO Strato sein.
Nun, da ein erhebliches Problem autaucht, erhalte ich als einer von
zahlreichen Kunden die Antwort, dass es keinen "CMS-Support" geben kann.
Es handelt sich hierbei doch um keinen "CMS-Support", auch um keinen
Einzelfall, sondern um das Beheben eines technischen Problems, der, der
sich auf alle Strato-Nutzer bezieht, die das Ihrerseits beworbene CMS
Drupal verwenden möchten.
Als einer der größten Provider in Deutschland wäre es doch aus vielen
Gründen sicher angebracht, dass Strato sich dieses Problems annimmt,
statt seine Drupal-Nutzer "im Regen stehen zu lassen", oder?
Über weitere Antwort freue ich mich."
Auf drupal.org gepostet
am 09.05.2013 - 00:06 Uhr
Hi!
Da auf Antonias Post bei drupal.org nichts Gehaltvolles mehr folgte, wohl aber ein anderer Thread eröffnet wurde, ist meine Frage
(siehe drupal http://drupal.org/node/1980352#comment-7392816)
W E R kümmert sich nun um das Problem? W E R zeigt Verantwortungsbewusstsein?
Möglichkeit A: Strato kennt den Grund des IP-Blockings NICHT; Verantwortung wäre dann bei drupal.org; warum werden Strato-hosted Websites geblockt?
Möglichkeit B: Strato KENNT den Grund des IP-Blockings sehr wohl; Verantwortung wäre dann bei Strato; warum werden Drupal-Nutzer im Regen stehen gelassen?
Grüße!
Mark
PS: Zum Glück ist dieser von mir beauftragte Strato-Vertrag noch keine 14 Tage alt - Widerruf ick hör dir trapsen! =)
Ich habe nun via Twitter
am 10.05.2013 - 09:58 Uhr
Ich habe nun via Twitter @STRATO_hilft das Problem mitgeteilt und warte mal ab was hier passiert.
bin auch gespannt, der
am 10.05.2013 - 10:39 Uhr
bin auch gespannt, der twitter support sagt dir nur das du an twitter@strato.de oder so ne Mail mit deinem Anliegen schreiben sollst, was die dann weiterleiten.
bei mir isses dann versandet... bisher null reaktion , kein zwischenstand, kein "wir wissen das es hakt, wir kümmern uns"
Strato-Problem vllt. mit Proxy lösen
am 10.05.2013 - 19:46 Uhr
Hallo Zusammen,
also vorweg, Drupal und die Infrastruktur von Drupal.org wird von der Community getragen und Strato ist ein Tochter-Unternehmen der Telekom. Dies sollten meiner Meinung nach bitte alle Betroffenen dieser Situation berücksichtigen, insbesondere bei Ihren Forderungen gegenüber der Open Source Community und den fleißigen Helfen auf Drupal.org.
Wie schon erwähnt wurde wird auch von Strato unter anderem mit dem Betrieb diverser CMS inkl. Drupal geworben. So wie ich das Problem verstanden habe, wurden wahrscheinlich aus diversen Gründen eine oder einige IPs in der Infrastruktur von Drupal.org gesperrt. Ich gehe mal davon aus, daß dies auch eine Folge des Umstands ist, daß es sich bei Strato um einen Massen-Hoster handelt bei der viele Projekte auf wenigen IPs betrieben werden. Darunter befinden sich sehr wahrscheinlich auch Nutzer die zum Teil auch Unsinn machen. Trotz der Knappheit von IPv4 Adressen sollte es einem Unternehmen wie Strato möglich sein, eine Lösung zu erstellen wie z.B. den Betroffenen mit anderen IPs zu versorgen.
Andere Lösungs-Idee: In den aktuellen Drupal 7 Versionen kann man Proxy-Server angeben. Ich nehme an, daß dies dann auch für besagte Update-Funktion hilfreich ist. Ich habe gerade keinen Proxy zur Hand um das zu testen. Aber ich kann mir vorstellen, daß es für die gigantische IT-Abteilung von Strato wohl möglich sein sollte einen solchen Proxy vllt. auch nur zum Überbrückung der aktuellen Situation bereit zustellen.
Vielleicht wäre es künftig auch sinnvoll insgesamt die Update-Server von Drupal bei großen Providern zu spiegeln, wie es z.B. für diverse Linux-Update-Libraries z.B. Ubuntu gibt. Dafür bräuchte es aber eine Lösung auf Seiten des Drupal-Systems, die es wahrscheinlich noch nicht gibt. Das habe ich aber noch nicht recherchiert.
Mich selbst betrifft das ganze nicht, da ich meine eigenen Projekte woanders hoste und zur Zeit auch kein Kundenprojekt bei Strato betreue, insbesondere nicht in einer shared Hosting Umgebung. aber vllt. sollten sich die Strato-Drupal-Kunden hier mal ein wenig sammeln um vllt. gemeinsam auf Ihr Problem aufmerksam machen zu können?
Abschließend: Könnte der Thread-Eröffner bitte im Titel dieses Threads deutlich machen, daß es sich um eine Strato-Problem handelt.
Viele Grüße,
Carsten
"If you can see this your IP is not blocked."
am 10.05.2013 - 19:54 Uhr
Nur mal so zur Info, wenn man http://updates.drupal.org/ aufruft bekommt die Meldung: "If you can see this your IP is not blocked."
Ich nehme mal an, daß es nötig ist in der drupal.org Infrastruktur IP-Adresse auch zu blockieren allein schon gegen Denial of Service Attacks. Das Risiko innerhalb eines Shared Hostings in diese Situation zu gelangen steigt mit der Anzahl der Projekte, die unter eine Domain betreiben werden bis hin zum "Massen-Hosting".
Test-http-request an http://updates.drupal.org...
am 10.05.2013 - 20:40 Uhr
... von einem 1&1-Webspace aus: läuft, Anzeige "If you can see this your IP is not blocked."
... von einem Strato-Webspace aus: läuft nicht, keine , Anzeige "If you can see this your IP is not blocked.", q. e. d. ;)
Von Strato erhielt ich übrigens nach einer "gepfefferten" Mail mit dem Tenor "als großer Provider einerseits mit Drupal werben, und die Nutzer bei Problemen ist eine doch ziemlich verantwortungslose Haltung..."
wiederum eine faire "sorry, haben Drupal dbzgl. kontaktiert, sind dran, dauert noch"-Antwort von Strato, im Übrigen jedoch nahezu wortgleich mit der Antwort in http://www.drupalcenter.de/node/46107#comment-163437
Sagen wir mal, einigen dort sollte das Problem mittlerweile sehr bewusst sein.
Wenn ich Carstens Kommentare richtig verstehe, "büßen" einige Nutzer von Shared-Hosting-Paketen, dass andere von Ihrem Strato-Webspace aus Missbrauch betrieben haben, woraufhin Drupal verständlicherweise Strato-IPs blockiert?! Interessant, danke.
Meinerseits habe ich "Glück": den Vertrag mit Strato habe ich nun widerrufen, da er noch so frisch war.
IP nicht geblockt, geht trotzdem nicht unter Strato
am 10.05.2013 - 20:52 Uhr
Ich bekomme unter der Seite die Meldung:
"Hi there!
If you can see this your IP is not blocked."
Trotzdem habe ich den Fehler, dass selbst bei manuellem Update alles grau bleibt.
Die IP scheint dann zumindest bei mir nicht der Grund für den Fehler zu sein?!
Gruß
Antonia
Wie doof von mir..
am 10.05.2013 - 20:58 Uhr
Habe meine IP ohne Strato getestet. Also einfach nur den Link angeklickt.
Wie kann ich das jetzt über mein Strato Hosting testen?
Probier's mal so...
am 10.05.2013 - 21:12 Uhr
dies in einer irgendwas.php auf Deinen Strato-Webspace laden und aufrufen...
<?php
//gets the data from a URL
function get_url($url)
{
$ch = curl_init();
if($ch === false)
{
die('Failed to create curl object');
}
$timeout = 5;
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
$data = curl_exec($ch);
curl_close($ch);
return $data;
}
echo get_url('http://updates.drupal.org');
?>
boshaftes Hacking oder evtl. Folge der "Masse"
am 10.05.2013 - 22:47 Uhr
"büßen" einige Nutzer von Shared-Hosting-Paketen, dass andere von Ihrem Strato-Webspace aus Missbrauch betrieben haben, woraufhin Drupal verständlicherweise Strato-IPs blockiert?!
Das müssen nicht unbedingt die Kunden der jeweiligen Webspace-Pakete sein. Es kann sich auch um gehackte Webanwendungen aller Art handeln, die vllt. teilweise nicht auf so solider Basis wie Drupal stehen oder nicht sorgfältig mit Sicherheits-Update versorgt wurden ...
Oder – und da wäre Strato wieder mit im Boot – unter Umständen nicht in optimal gesicherten Umgebungen betrieben werden. Bei vielen Hostern gibt es z.B. nur ein Benutzer zum Betrieb einer Web-Anwendung. Ich selbst bevorzuge zwei. Einen Application-Owner (oft FTP-User, bzw, besser SSH-User) und einen Webserver-Benutzer.
Aber was evtl. eine zu klärende Frage ist: Vllt. treffen auch einfach aufgrund der Masse an Drupal-Installationen hinter bestimmten IPs manchmal auch einfach zu viele Update-Abfragen auf einmal auf update.drupal.org ein. Dies könnte dazu führen, daß automatisierte Firewall-Regeln (wie ich sie auch zu diesem Zweck einsetze), diese Anfragen als Denial of Service Angriff "interpretieren" und sicherheitshalber automatisiert diese IPs vorübergehend oder dauerhaft sperren. Leider zwingen boshafte Internet-Nutzer die Betreiber von Netzwerken und Servern zu solchen Abwehr-Strategien, die auch mal eigentlich gut gemeinte Anfragen blockieren.
Erziehungsmaßnahme
am 11.05.2013 - 04:45 Uhr
Hallo,
Dies sollten meiner Meinung nach bitte alle Betroffenen dieser Situation berücksichtigen, insbesondere bei Ihren Forderungen gegenüber der Open Source Community und den fleißigen Helfen auf Drupal.org.
... der Spruch mußte ja mal kommen.
Im Moment sind das alles nur Vermutungen. Was ich nicht verstehe, dass die Drupal-Community sich nicht klar äußert. So eine Mauschelei. Das kann nicht sein.
Die einzige machbare Lösung, wäre wohl updates über ein Proxy zu beziehen. Strato wird nichts an seinem System ändern. Na ja, jede Revolution fordert halt seine Opfer. Oder ist es doch eine Erziehungsmaßnahme?
Grüße
Momentan mache ich meine
am 11.05.2013 - 08:03 Uhr
Momentan mache ich meine Updates über ne lokale Installation der auf Strato befindlichen Seite. ich lass den Updatecheck durchlaufen und die dann angezeigten Updates lade ich dann manuell und klimper die ein. is zwar mega nervig, aber immer noch besser als Versionsnummern manuell zu prüfen.
Knatterpeng schrieb Carsten
am 11.05.2013 - 14:01 Uhr
Dies sollten meiner Meinung nach bitte alle Betroffenen dieser Situation berücksichtigen, insbesondere bei Ihren Forderungen gegenüber der Open Source Community und den fleißigen Helfen auf Drupal.org.
... der Spruch mußte ja mal kommen.
...
Grüße
An dem "Spruch" ist ja auch nichts verkehrt.
Wir haben hier zwei Seiten:
1. drupal.org - Die stellen weltweit kostenlos eine Infrastruktur, mit den verschiedensten Diensten, zur Verfügung. U.A. eben die automatische Überprüfung auf mögliche Aktualisierungen.
2. strato - Die stellen ein kostenpflichtiges Hosting zur Verfügung und machen dafür u.A. Werbung - http://www.strato.de/hosting/app/cms-drupal/ -, dass sie auf ihren Servern auch Drupal zur Verfügung stellen und unterstützen.
Jetzt werden von d.o. sehr wahrscheinlich IPs von Strato geblockt. Um etwas tun zu können, müssten die d.o Leute jetzt eine dieser IPs kennen, um herausfinden zu können, woran das liegt.
Darauf hat killes auf d.o auch mehrfach hingewiesen. Wenn Strato keine IP nennt, wird sich an der Situation nichts ändern
Zwei Möglichkeiten ein Traceroute zu bekommen
am 11.05.2013 - 17:19 Uhr
Hallo Zusammen,
ich habe gerade zwei Möglichkeiten zu einem Traceroute auch in einer shared Hosting Umgebung zu kommen auf d.o gepostet:
http://drupal.org/node/1980352#comment-7401984
Ich habe leider keinen Zugang zu einem Strato-Shared System somit kann ich das dort nicht evaluieren.
Mein kleines Script hat zumindest in meinem Shared Setup und in einem von Hosteurope geklappt.
Viel Erfolg,
Carsten
mmhh
am 11.05.2013 - 20:28 Uhr
Hallo,
1. drupal.org - U.A. eben die automatische Überprüfung auf mögliche Aktualisierungen.
..ebend nicht.
2. strato - Die stellen ein kostenpflichtiges Hosting zur Verfügung und machen dafür u.A. Werbung - http://www.strato.de/hosting/app/cms-drupal/ -, dass sie auf ihren Servern auch Drupal zur Verfügung stellen und unterstützen.
... Drupal läuft. Nur kann Drupal sich nicht mit updates versorgen, vermutlich weil Drupal die Geschäftspraxis von Strato nicht passt.
Grüße
Hm, deine Meinung ist also,
am 11.05.2013 - 21:31 Uhr
Hm, deine Meinung ist also, dass die Infrastruktur auf d.o keine "automatische Überprüfung auf mögliche Aktualisierungen" zur Verfügung stellt.
So interpretiere ich jedenfalls dein "ebend nicht".
Und du glaubst, dass sich "Drupal", um die Geschäftspraktiken irgendeines Providers auf der Welt kümmern kann? Bzw. sich an dessen Geschäftspraktiken stört?
Wieviele Provider gibt es wohl weltweit? Da hätte die Drupal Association, die ist für drupal.org verantwortlich, viel zu tun.
Die Aussage "weil Drupal die Geschäftspraxis von Strato nicht passt." ist grundsätzlich falsch. Drupal ist nicht drupal.org oder die Drupal Association.
Man sollte sich mit diesen Sachverhalten schon auskennen, bevor man solche Aussagen trifft.
Hier die Antwort auf meine
am 13.05.2013 - 23:10 Uhr
Hier die Antwort auf meine Twitteranfrage:
Wir stehen in Kontakt mit Drupal und dabei sind, den Fehler einzugrenzen. Woran es liegt, ist noch nicht ganz eindeutig. ^sb
Hallo zusammen, wir haben
am 14.05.2013 - 10:48 Uhr
Hallo zusammen,
wir haben mehr als 20 Drupalsysteme auf mehreren (verschiedenen) Strato-Systemen und wir hatten bisher noch kein Problem damit.
Es kann sich also wirklich ausschließlich nur um Strato-Shared-Hosting handeln.
Meine Vermutung wäre, das die Shared-Hosting-Systeme unter einem bestimmten IP-Block abgelegt sind.
Jetzt gehen wir mal davon aus, 5000 Kunden haben Drupal auf den Shared-Hosting-Bereichen von Strato liegen.
Dann werden (je nach Croneinstellungen) mehrere tausend abfragen stündlich bei Drupal.org eingehen (aus dem gleichen IP-Block).
Da liegt es für mich sehr nahe, das Drupal.org diesen IP-Block sperrt, da von diesem eine sehr hohe Last für die eigenen Server eingeht bzw. verursacht wird.
Da wäre zumindest meine Idee.... (da ich das aus Sicherheitsgründen genauso machen würde, bis ich geklärt habe, woher diese Anfragen kommen).
Drupal.org hatte ja Anfang des Jahres einige Hackerangriffe gegen sich und hat deswegen vielleicht die Sicherheit verschärft...
Viele Grüße
Bjoern
Neues Drupal auf Strato lässt sich Datenbank nicht einrichten
am 14.05.2013 - 12:53 Uhr
Hallo,
ich habe gestern versucht eine neue Drupal Installation auf zu setzen.
Das lief immer in Fehler 500 und selbst die automatische Strato Installation lief nicht sauber zu Ende.
Kann das am gleichen Problem liegen?
Habt Ihr auch dieses Problem?
Gruß
Antonia
Das mit dem Fehler 500 liegt
am 14.05.2013 - 12:57 Uhr
Das mit dem Fehler 500 liegt an einem Problem zwischen Plesk 11 und Ubuntu 12.04 LTS.
Dazu ist bereits ein Ticket bei Strato auf (Da muss in deren Serverimage eine Anpassung erfolgen)...
Viele Grüße
bjoern
Updatecheck
am 14.05.2013 - 17:07 Uhr
An alle Strato Kunden updatecheck funtioniert wieder :)
gruß
sheriff
yo, soll laut Strato
am 14.05.2013 - 17:23 Uhr
yo, soll laut Strato Nachricht wieder gehen, nur ist jetzt der shared host so ausgelastet, dass ich auf meine Präsenz nich draufkomm.... aaaaah
Endlich!
am 14.05.2013 - 17:30 Uhr
Soeben kam die Email das update vorliegen.... :-)
Super, klappt
am 14.05.2013 - 19:18 Uhr
jetzt bei mir auch wieder - und ich bekam keine Status-Nachricht, obwohl ich das Problem auch gemeldet hatte. Danke für die Rückmeldung hier!
Es geht wieder.
am 14.05.2013 - 19:49 Uhr
Hi.
Bei mir geht das Update auch wieder.
Rückblickend habe ich ganz klar eine zeitnahere Reaktion von Strato erwartet. Freue mich aber das es nun wieder funktioniert.
Gruß Marcus
geht wieder :)
am 15.05.2013 - 09:19 Uhr
Sie sind hier
Startseite » Verwaltung » Berichte
Statusmeldung
Daten über verfügbare Aktualisierungen wurden für 29 Projekte überprüft.
Hier befinden sich Informationen über verfügbare Aktualisierungen der installierten Module und Themes. Zu beachten ist, dass jedes Modul Teil eines „Projektes“ ist, welches den gleichen oder einen anderen Namen wie das Modul hat.
Neues Modul oder Theme installieren
Zuletzt überprüft: vor 2 Sekunden (Manuell überprüfen)
Bis dann mal wieder hoffe das es hält und das man daran arbeitet so Fehler schneller löst und zu diesen auch steht.
LG Revere
Ich warte noch auf ein
am 15.05.2013 - 09:25 Uhr
Ich warte noch auf ein Feedback auf meine Twitteranfrage, was genau der Fehler nun eigentlich war und poste dann hier entsprechend die Antwort
Auch ich kann bestätigen, dass die Updates wieder geladen werden