Komplettes Forum crawlen

[BurnerR]

Wie archiviere ich am besten ein Forum?
Ich habe das mal mit wget gemacht, aber das ist wenig zufriedenstellend da es sehr lange dauert und sehr viel traffic generiert - mehrere GiB und zehntausende Dateien. Scrapy wurde jüngst in den Raum geworfen, das ist vermutlich higher-level?
Wird so ein Vorgang üblicherweise vom Boardbetreiber oder Serverbetreiber wahrgenommen, leuchten da red flags auf? Wenn ja/vielleicht: Wie lässt sich das effektiv verhindern -> vermutlich einfach langsamer crawlen? xD.
Das Forum benötigt einen Login. Ist ja kein Hindernisgrund (Cookie, POST,..).

TL;DR: Wie könnte ich theoretisch das ngb crawlen, ohne das ihr das merkt (nein, das ist nicht was ich vorhabe ).

[darksider3]

Scrapy musste Dir halt als "Framework" in Python dafür vorstellen. Es ist nicht higher-level, sondern ein komplettes Framework dazu. Mit Scrapy kannst Du direkt Daten extrahieren, z.B. anhand von XPath&CSS, diese Abspeichern in verschiedenen Formaten und dann direkt weiterverarbeiten. Wäre im gegebenen Fall zwar sinnvoll(forum.giga.de), aber die paar MB einsparung die man dadurch hat, sind den Aufwand IMHO in dem Fall hier nicht Wert, weil das Ding eh bis zum 16. gescraped sein muss. Wenn man da ein, zwei Tage mehr für hätte, wäre es wohl die beste Option, neben wget. Hab aber noch nichts mit scrapy gemacht, deshalb ist alles was ich hier von mir gebe, eh nur ein "ich habs mal angeguckt, aber bisher nicht mehr damit gemacht"-Erfahrung...

(BTW, nimmt wget nicht mittlerweile die Link-Struktur mit? Sprich, Smilies und JS/CSS das eh überall verwendet wird, wird sowieso nur einmal gespeichert...?)

EDIT: Wenn ich mir den output von wget gerade angucke, sind mögliche Einsparung ATM vorallem im Template vom Forum eingearbeitete JS-Sachen(Tapatalk, Yahoo-Search-Engine und Session-Zeug). Das wäre die mögliche Ersparnis von ~10kB/Seite. ^^ Achja, und natürlich verschiedene Index-Ansichten. Die sind natürlich auch ein wenig... obsolet.

[BurnerR]

Danke schonmal für die Ausführung. Das mit scrapy klingt in der tat ganz gut. Das bisschen python was man da vermutlich braucht bringe ich mir sicherlich on the fly bei.
Assets werden bei wget in der Tat nur einmalig gespeichert, das Problem besteht darin, dass ein Forum zu einem Großteil aus dynamisch generierten Inhalten besteht wget aber nur statische Seiten kennt. Das führt dazu, dass zu jeder Thread-Seite dutzende Dateien angelegt werden, nämlich für jeden Link der auf irgendeiner anderen Seite auf diese Seite zeigt.

Mir geht es konkret um ein Board, wo mal viel Geld für den Zutritt bezahlt wurde, das aber mitlerweile eingeschlafen ist und womöglich eines Tages abgeschaltet wird, was sehr schade um den Content wäre.


PS.: Ich kann mir das mit den ganzen Dateien gerade auch nicht mehr so ganz erklären . Werde mir das nochmal zuhause anschauen wo ich mein altes crawling-Ergebnis habe.
War evtl. eine Besonderheit bei der Forensoftware. Hier im ngb sind die Links ja anscheinend alle identisch wenn sie auf den selben Content verweisen.

[darksider3]

Da bei Scrapy prinzipiell jeder Download "programmierbar" ist, gehe ich stark davon aus dass das möglich ist, Index- und Thread-Ansichten zu filtern und nur einmal mitzunehmen. Außerdem kann Scrapy auch Logins per FormRequest. Sich die einzelnen Contents per XPath zu holen ist auch drin, wie oben bereit beschrieben(\\p[@postcontent] für einen Filter der A) nur <p> berücksichtigt, und B) nur <p> mit Klasse postcontent mitnimmt). Auch parsen kann man bei Scrapy hooken, btw.

EDIT: StackOverflow für den Login ^^ https://stackoverflow.com/questions/...n-user-session

--- [2018-04-12 15:17 CEST] Automatisch zusammengeführter Beitrag ---

Der einzige Weg, abseits mehrer Maschinen das Problem des Traffics zu umgehen, ist wohl wirklich einfach langsamer zu crawlen, so traurig es sich anhört.

[theSplit]

Bei dynamischen Inhalten, gibt es sicherlich dennoch einen festen Aufbau der Seite, so das Seiten sich durch "Name Forum: "+ "Titel" + "Seite 1 von X" unterscheiden bzw. auch gleichen.

Grundsätzlich würde ich dir aber raten, speichere das gesamte HTML und fang nicht an vor zu filtern! - Natürlich kannst du Angaben im Vornherein herausfiltern, die nicht "wirklich relevant sind" oder zu dir als User gehören, im Falle vom NGB könnten das die Aktionsleiste unter dem Post sein wie "Antworten at", "zititeren", "bedanken" oder andere Buittons wie "Antworten", "Erweitert" oder die Aktionsleist "oben" oder ähnliches.
Damit wirst du vermutlich das Datenvolumen etwas reduzieren was du speichern mußt. Auch würde ich nicht blind allen URLs (zum Beispiel externen folgen) oder Bilder downloaden... die nicht auf dem Board selbst liegen wie Avatatre, Smileys oder ähnliches.

Anderer Punkt, du kannst die Datenrate beim crawlen nicht wirklich minimieren, du kannst in einer DB zum Beispiel den Dokumentitel speichern +- URL um damit abzugleichen. Aber ich glaube kaum das es ein Forum ist, wo für jeden User eigene URLs generiert werden, ein fixer Aufbau muß eigentlich bestehen, sonst könnte man es nicht einmal verlinken.

Ansonsten zum langsamen crawlen, ja, gute Idee, aber Pro-Tip - mach einen Zufallsgenerator mit von X (Millisekunden/Sekunde(n) bis Y Sekunden. Das fällt weniger auf, als wenn du 100 Requests mit 350ms Zeitverzögerung raushaust.

[BurnerR]

Ok, also einfach langsam crawlen meint ihr ist ein guter Ansatz. Gut das ihr das bestätigt.

Habe grad mal nachgeschaut. Das Forum das ich damals kopiert habe hat wirklich für jeden Scheiß einen seperaten Link generiert.
Zum Beispiel konnte man mit "Nächstes Thema" und "Vorheriges Thema" durch die Threads scrollen, aber das war dann nicht threadlink.html, sondern "threadlink-prevtopic.html" und "threadlink-nexttopic.html"
Der Footer weist phpBB in unbekannter Version aus.

[theSplit]

Damit du bei so etwas wie "prev" und "next" Thread auf nen grünen Ast kommst, würde ich die Dokumenttitel einlesen, speichern und anhand derer überprüfen. Also haben wir den Titel in einer DB bzw. einer Datei gespeichert oder nicht. Und darauf reagieren.

Aber grundsätzlich würde ich diese "Funktionen" (vorheriges, nächstens) rausnehmen, wenn sie nicht wirklich relevant sind, und diese Links nicht crawlen, sondern nur die Forenübersicht + Themenübersichten, Postseiten der Themen. Wichtig ist nur das du die Zeiten der Themen umwandelst bzw. erst mal einliest, anhand derer kannst du dir selbst das mit dem Vor und zurück basteln, wenn du die Inhalte mal korrekt einliest bzw. verarbeitest, wenn mehr Zeit ist.

Auch brauchst du sowieso nen kleinen Filter, damit du nicht alle "a href" ausliest und folgst, also keine Userprofile URLs?, keine dynamischen Links wie Vor- und Zurück zu neuen/alten Themen in dem Bereich, kein Bearbeiten, kein Antworten, kein "was auch immer" du nicht brauchst und was keine Daten bringt.

Das beste wäre natürlich, du würdest die Datenbank von dem Owner bekommen um das Projekt weiterzuführen. Dann könnte man Fragen, die Lage und Bedenken schildern... und eventuell nen DB Dump ohne User bekommen, mit nur Content vielleicht.... und alles anonymisieren.

[darksider3]

Vor allem bräuchte man eines: Zeit. Aber das in 4 Tagen runterzubrechen und alles an Content mitzunehmen ist IMHO nicht drin, wenn der Webserver schon bei 50+ Verbindungen in die Knie geht. ^^'' Bei BurneR klingt es so oder so nicht überaus dringend, eher so "dahindümpelnd". Wenn er möchte, kann er ja mal nen Link verteilen, oder ne allg. Struktur zeigen, anhand derer man vorallem in seinem Fall gucken kann..

[theSplit]

Man kann auch anders crawlen, 50 Requests "so schnell wie möglich" 25 Requests mit 2 Sekunden wartezeit, 15 mit 3 Sekunden.... und dann wieder von vorne mit 50...

Nur "unauffällig wäre langsam" crawlen...

[BurnerR]

Das beste wäre natürlich, du würdest die Datenbank von dem Owner bekommen um das Projekt weiterzuführen.

Wäre schön, aber manchmal halt nicht drin .

Damit du bei so etwas wie "prev" und "next" Thread auf nen grünen Ast kommst, würde ich die Dokumenttitel einlesen, speichern und anhand derer überprüfen.

Naja, ich denke ich schaue mir einfach an, wie die Links aufgebaut sind und whiteliste nur threadlink.html threadlink-1.html,... für die einzelnen Seiten und sowas.


Sind ja grad zwei Anwendungsfälle. Beim Gigaforum will man / muss man lieber schnell sein, in meinem fall will ich möglichst sneaky und unsichtbar sein.

[darksider3]

Sicher, kann man. Wie gesagt, da stellt sich aber immernoch die Frage: Wieviel Zeit hat man zur Verfügung für welche Menge an voraussehbaren Daten? In diesem Fall hier würde ich einfach mal auf den Burner warten, und gucken was der sagt, wie die Struktur ungefähr aussehen soll, von dem, was er da überhaupt crawlen will.

Randomisierte Sleep-timer sind keine neue Technik...

[theSplit]

@darksider3: Random Sleep Timer bietet selbst Wget an.

[darksider3]

@theSplit: selbst wget, so ist es. Habe niemals was anderes behauptet

Hast Du Dir eigentlich mittlerweile die Docs zu Scrapy näher angesehen? Finde recht spannend, das man dafür Python nimmt. Aber man hat beim crawlen wrsl. weniger CPU-Intensives als einfach nur I/O.

[theSplit]

@darksider3: - das meinte ich nicht böse - wollte damit nur sagen, auch das Programm hat die Option.

Wenn natürlich ein IP Limit pro Stunde gesetzt ist an "gesammelten" Requests in einer Log, sieht es eh mau(er) aus. Aber dafür müssten IPs gespeichert werden. Aber ein neu verbinden beim Provider würde da Abhilfe schaffen, wenn nicht der Account vorher gesperrt wird.

[darksider3]

IP-Sperren sind eh kacke, in dem Fall hier. Deshalb ist man ja eben gezwungen überhaupt auf Timer zurückzugreifen. Die meisten "Anti-DDoS"-Geschichten analysieren minütlichen Traffic(so wie hier im Forum übrigens auch^^) und sperren etwaige "starkverbraucher" ziemlich schnell. Bei Giga ist der Download-Durchsatz wrsl zu niedrig das da überhaupt nicht genug Traffic zusammenkommen kann.
Bei BurnerRs Seite muss man aber wohl davon ausgehen das der Durchsatz höher ist oder der Dienst aggresiver eingestellt ist. Ich würde nicht mal 50 Requests die Sekunde nehmen, sondern eher sowas wie 200-500/Minute um auf der sicheren Seite zu sein. Wie gesagt: Wenn er die Zeit hat.

EDIT: Im Schnitt komme ich bei Giga nichtmal über die 60KiB/s raus. Wie gesagt: Viele kleine Dateien, daher viele Requests, aber eben wenig durchsatz.^^

[theSplit]

Auch wenn es in 2 Threads gerade besprochen wird, wie läuft es BurnerR?

Mich würde interessieren ob du vorankommst mit deinem gewagten Vorhaben!

[BurnerR]

Ich habe leider gerade keinen Zugang zu dem Forum, den muss ich mir erst wieder besorgen. Sobald sich was tut sage ich bescheid.
Höchstwahrscheinlich crawle ich das Forum dann über nen VPN, nur um sicher zu gehen.

[theSplit]

(BTW, nimmt wget nicht mittlerweile die Link-Struktur mit? Sprich, Smilies und JS/CSS das eh überall verwendet wird, wird sowieso nur einmal gespeichert...?)

Ich glaube dazu kann ich etwas sagen: Im Falle von Wget werden Ressourcen die bereits existieren, nicht erneut heruntergeladen, also ja.
Im Falle von Smileys, JS, CSS oder solchen Sachen - so fern diese bereits hinterlegt sind. Also würde das schon wie ein Filter fungieren.

Wichtig wäre nur die Switches "-k" und "-p" zu verwenden, "k" konvertiert Links um zu lokalen Links auf der eigenen Platte (relativ zur Ursprungsadresse), "p" sammelt Ressourcen wie Bilder, CSS, JS, Fonts und ähnliches die verwendet werden.

--- [2018-04-14 11:25 CEST] Automatisch zusammengeführter Beitrag ---

@BurnerR: Bin gespannt.

Sollte mir auch mal das Forum ansehen, vielleicht fällt mir auch noch etwas ein, wo du sparen könntest.

[BurnerR]

Sollte mir auch mal das Forum ansehen

Das werde ich nicht verlinken, sorry, aber ohne login sieht man da auch eh nichts.
Aber ich werde schauen, welche Software sie einsetzen und welche Version, mir ein Testforum aufsetzen und einige Tests machen und diese hier dokumentieren, ebenso wie das Ergebnis. Und bei den Tests bin ich natürlich sehr dankbar für Feedback :-).

[theSplit]

Ach so, dachte es geht um das eine... - dann nix für Ungut, dann will ich die URL auch gar nicht wissen. Und die kannst du für dich behalten!

[Roin]

Ach so, dachte es geht um das eine...

Dass du schon wieder nur an das eine denken konntest...

Hat alles geklappt BurneR?

[theSplit]

Ja, @Roin, Daten

[BurnerR]

Hat alles geklappt BurneR?

Es geht voran. Habe mir die korrekte Version besorgt. Muss ich noch auf Malware prüfen (Jemand Tipps? Habe noch nie web software / php prüfen lassen) und dann präpariere ich eine kleine VM wo ich das installiere.. und dann kann das herumspielen losgehen .
Wird diese Woche vermutlich nichts mehr, kommende Woche hoffentlich.