Falscher Hostname in XML-Sitemap-URLs

[hatbanger]

Hi,

ich betreibe eine TL 2.7.0-Installation auf einem Server mit Shared Hosting.

Bei der XML-Sitemap, die ich eingerichtet habe, kommt es hin und wieder vor, dass der Hostname sämtlicher URLs darin von http://meine-domain.tld durch einen offenbar kundenspezifischen Hostnamen nach dem Muster http://kundennummer.mein-provider.de ersetzt wird. Dieses Verhalten ist für mich bisher leider überhaupt nicht reproduzierbar und taucht anscheinend nur alle paar Tage mal auf, was es aber quasi unmöglich für mich macht, einzuschätzen, wo genau das Problem liegen könnte.

Die URLs aus der Sitemap selbst funktionieren übrigens und die Website wird korrekt vom TYPOlight-Frontend angezeigt, aber dummerweise streiken die Google-Webmastertools bei einem abweichenden Hostnamen.

Um die Hostnamen wieder zu korrigieren, reicht es übrigens aus, im Backend unter "Wartung" die alte XML-Sitemap zu löschen. Danach ist wieder ein paar Tage Ruhe.

Hat jemand eine Idee, wo hier die Ursache begraben sein könnte?

Benjamin

[Nina]

Bei welchem Webhoster passiert das?

[hatbanger]

Da das über eine Webagentur läuft, die als Reseller eines Anbieters fungiert, kann ich da nur Mutmaßungen anhand eines Whois auf den Hostnamen anstellen. Das wäre dann "WebhostOne e.K." (ich nehme an, http://webhostone.de).

[matze]

Typolight verwendet ja für den Aufbau der Sitemap URL nicht etwa die Domain, die man im Seitenstartpunkt angegeben hat sondern die, von der Aufruf kam, als das Script die URLs erstellt hat.
Da die Sitemaps ich glaube wöchentlich neu erstellt werden, kann es also sein, dass zu diesem Zeitpunkt gerade der Aufruf über die falsche Seite kam.

[hatbanger]

Hi,

danke für die technischen Informationen.

Da die Sitemaps ich glaube wöchentlich neu erstellt werden, kann es also sein, dass zu diesem Zeitpunkt gerade der Aufruf über die falsche Seite kam.

Ich kann das jetzt wohl nicht ohne größere Recherchearbeit reproduzieren, da ich nicht weiß, wo ich schrauben muss, um das Regenerieren auf einen Frontend-Request hin zu forcieren.

Ich habe allerdings mal durch die Logs geschaut und dabei bemerkt, dass täglich um 03:40 morgens ein Request auf die cron.php stattfindet - und zwar auf dem falschen Hostnamen und von einer anderen IP im gleichen Subnetz des Providers aus. User-Agent ist "Wget/1.10.2" und es ist der einzige Zugriff dieser Art pro Tag.

Da ich nun weder einen Cronjob o.ä. eingerichtet habe, noch irgendwelchen Robotern den Zugriff auf die cron.php erlaubt habe und der Request auch nicht indirekt durch dieses Bildchen im Template

<img src="<?php echo $this->base; ?>cron.php" alt="" class="invisible" />

zustande kam (sonst hätte ich ja mehrere Logeinträge), sondern direkt, bin ich nun versucht zu glauben, dass TYPOlight selbst dafür verantwortlich ist. Ich kann mir nur keinen Grund dafür vorstellen, und auch nicht, an welcher Stelle ich suchen muss.

Benjamin

[matze]

Da hast du auf jeden Fall schon mal den Grund für die falschen Sitemaps.
Aber das Typolight für diese Aufrufe verantwortlich ist, stimmt nicht.
Woher soll das System denn bitte deinen falschen Hostnamen kennen? Für mich sieht das sehr nach Cron Job aus. Vorallem dadurch, dass es immer um die selbe Zeit stattfindet. Das kann TL zum Beispiel gar nicht, da TL eine reine Webapplikation ist. Also immer von extern aufgerufen werden muss.

[hatbanger]

Hi,

erstmal: Problem wahrscheinlich gelöst. Danke für die Hilfe.

Aber das Typolight für diese Aufrufe verantwortlich ist, stimmt nicht.
Woher soll das System denn bitte deinen falschen Hostnamen kennen? Für mich sieht das sehr nach Cron Job aus. Vorallem dadurch, dass es immer um die selbe Zeit stattfindet. Das kann TL zum Beispiel gar nicht, da TL eine reine Webapplikation ist. Also immer von extern aufgerufen werden muss.

Ich hatte zunächst auf einen Zusammenhang mit der Logdatei-Rotation getippt, auch deshalb, weil es nicht immer sekundengenau um 03:40 ist, aber die Einträge befinden sich nicht immer am Anfang oder Ende der Logdatei. Dass irgendeine Art regelmäßig ausgeführter Task wie ein Cronjob verantwortlich sein muss, war mir natürlich auch klar, ich habe aber tatsächlich nichts dergleichen eingerichtet (es existieren weder in der crontab noch in dem etwas merkwürdigen Kundenbereich des Providers irgendwelche Einträge). Es ergab daher alles keinen Sinn für mich.

Ich wurde dann aber auf die Idee gebracht, dass es sich bei dem Request um eine etwas eigene Art des Providers handeln könnte, dem Kunden "Cronjobs" zu ermöglichen. Nach einem Umbenennen der cron.php und der Bildreferenz darauf bestätigte sich das dann offenbar auch heute früh - der Request findet immer noch statt, wird aber halt jetzt mit einem 404 beantwortet. Ich freu mich schon jetzt auf den Spaß beim nächsten Update...

Benjamin

[andreas.schempp]

Hallo Benjamin,

Hast du denn in der Root-Seite eine Domain eingetragen? Zumindest in 2.7 (da habe ich nachgeschaut) würde diese Domain nämlich im Sitemap übernommen. Wenn du nichts eingetragen hast ist klar, dann wird einfach die Domain des Aufrufes genommen.

PS: Die cron.php sollte schon von Zeit zu Zeit ausgeführt werden, sonst laufen ja die Jobs nicht mehr

[hatbanger]

Hi,

ja, nun, ich hatte zwar ebenfalls kurz im Source nachgeschaut und daraufhin dieses Feld im Backend gesucht, aber anscheinend muss ich es irgendwie übersehen haben... :-)

Noch eins zur cron.php: Ich habe natürlich nicht nur die Datei selbst umbenannt, sondern auch die Stellen in den Templates geändert, in denen sie referenziert wird (ein grep über den gesamten TL-Source hatte mir genau zwei Stellen genannt) - daher hielt ich das auch nicht für ein echtes Problem, von den Updates mal abgesehen. Mit der Domain in der Root-Seite kann ich das dann ja wohl aber wieder rückgängig machen - danke!

Benjamin