Neues Projekt: Grepostats + Grepomaps + vieles mehr als eigenständiges Programm

Das Problem liegt nicht darin, wie das Tool die Daten speichert, sondern darin, den Download der Weltdaten neuerdings von einer https-addresse durchführen zu müssen.

Aber ja klar - ich könnte nun auch ein externes Tool mit dem Download beauftragen und diese dann lokal zwischenspeichern. Das ist in meinen Augen aber dann wirklich etwas oversized, denn normale Http-Downloads waren ja bisher kein Problem. Grepotool macht genau das, was Du da mit der Datenbank vorschlägst. Es läd die aktuellen Weltdaten runter und pflegt sie in eine lokale Datenbank ein.

Das Problem liegt nicht im Quelltext des Tools selbst begründet. Eher ist der Grund, dass die Qt-Bibliothek, die ich benutze anscheinend by default ohne SSL-Support ausgeliefert wird. SSL-Support braucht man aber anscheinend für https. Daher brauche ich wahrscheinlich lediglich ein special build der QtNetwork.dll.

Freut mich aber, dass da mal noch jemand anderes den Code überfliegt!
 

DeletedUser22147

Gast
Das Problem liegt nicht darin, wie das Tool die Daten speichert, sondern darin, den Download der Weltdaten neuerdings von einer https-addresse durchführen zu müssen.
Wieso denn neuerdings, also was hat sich denn da wieso geändert??
 

DeletedUser22147

Gast
Meine Frage ist, wieso erst seit neuerdings?

Was wurde denn da geändert, bzw. wieso wurde es überhaupt verändert, das es jetz mit https durchzuführen ist?
 
Diese Änderung von http zu https wurde wohl erst vor kurzem eingefügt.

Warum es geänderrt wurde? Weiß ich nicht

Musst du mal in der Chefetage von Inno fragen
 

DeletedUser22147

Gast
Das Grepo Tool ist mit Abstand ein Tool, was sogut wie jeder nutzt, der AFler...ebenso normale einfache Spieler, aber gerade für jede AF zur Planung und zwecks der Übersicht ist es unverzichtbar und einzigartig.

Bei der Änderung zu https, hätte man dies Bedenken müssen und erstmal das anpassen, bevor man es einfach ändert, ohne ein nen Statement zu hinterlassen!

Denn eins ist fakt...Grepo Maps ist !§#$%&?! Und sonst gibts glaub kein Programm, was die Inseln so geniel übersichtlich darstellen kann, wie Grepo Tool!
 
Das Grepo Tool ist mit Abstand ein Tool, was sogut wie jeder nutzt, der AFler...ebenso normale einfache Spieler, aber gerade für jede AF zur Planung und zwecks der Übersicht ist es unverzichtbar und einzigartig.

Bei der Änderung zu https, hätte man dies Bedenken müssen und erstmal das anpassen, bevor man es einfach ändert, ohne ein nen Statement zu hinterlassen!

Denn eins ist fakt...Grepo Maps ist !§#$%&?! Und sonst gibts glaub kein Programm, was die Inseln so geniel übersichtlich darstellen kann, wie Grepo Tool!
wird dort eh nur bis Mittag gedacht..
 
@.Pete. das ganze ist einfacher als gedacht. Ich hab vor längerem schonmal den Code zum kompilieren gebracht, bei mir unter Windows und mingw. Im Prinzip musste ich nur die Weltdaten-URI umbiegen und ein paar dlls von openssl in das Suchpfad legen, den Rest hat QtNetwork von sich aus gemacht. Ich hab' das Ganze allerdings unter Qt 5.3 gebaut. Problem bei dem ganzen mingw-Gefrickel ist, daß einige Lauzeitabhängigkeiten (pthreads, std++...) dynamisch eingebunden wurde und ich deswegen noch einen Rattenschwanz an weiteren dlls dazu packen mußte.

  • libssl32.dll
  • libeay32.dll
  • ssleay.dll

Da hab ich den Hinweis her...
http://www.qtcentre.org/threads/29007-QUrl-and-https


Generell noch etwas zum http-Umstieg:

Das ganze Web stellt aktuell begründeterweise auf https um, so auch Inno. Die bleiben nur am Zahn der Zeit. Außerdem haben die einen sauberen redirect eingerichtet, nur das Tool kommt damit nicht klar. Es ist Opensource, jeder kann das anpassen wenn er wünscht. Inno macht hier alles richtig.
 
Zuletzt bearbeitet:
@.Pete. das ganze ist einfacher als gedacht. ...
ja grundsätzlich schon, wenn man das Tool selbst kompilieren kann. Die Quellen sind ja frei verfügbar. Das Laden von HTTPS-URLs erfordert leider die installation von OpenSSL und eine Version der Qt-Binaries, die für die Benutzung OpenSSL compiliert sind.
Ich muss mich aber korrigieren, was den Quelltext des Tools angeht. Da sind doch ein paar Änderungen erforderlich. Das Tool erlaubt aktuell keine Redirects bei den Weltdaten. Also entweder die URLs anpassen oder Redirects erlauben. Ich mach mal beides.

Generell noch etwas zum http-Umstieg:

Das ganze Web stellt aktuell begründeterweise auf https um, so auch Inno. Die bleiben nur am Zahn der Zeit. Außerdem haben die einen sauberen redirect eingerichtet, nur das Tool kommt damit nicht klar. Es ist Opensource, jeder kann das anpassen wenn er wünscht. Inno macht hier alles richtig.
Tja - so ist es wohl. Aber ob das auch immer sinnvoll oder wirklich begründet ist, wage ich zu bezweifeln. Ich weiß auch nicht wirklich, wo nun SSL nötig ist, um das Herunterladen der Grepo-Weltdaten zusätzlich abzusichern. (wogegen überhaupt?) Aber nun stellt alle Welt auf https um und alle müssen da mitziehen oder eben draußen bleiben. Es ist müßig, sich hier querzustellen oder zu schimpfen.

Dein Wortbild finde ich übrigens ganz lustig - den Zahn der Zeit kenne ich eigentlich nur im Zusammenhang mit der zeitbedingten Zersetzung und dem Verfall von etwas. Diesem gilt es doch stets entgegenzuwirken statt ihm auch noch zu folgen ...
 
Tja - so ist es wohl. Aber ob das auch immer sinnvoll oder wirklich begründet ist, wage ich zu bezweifeln. Ich weiß auch nicht wirklich, wo nun SSL nötig ist, um das Herunterladen der Grepo-Weltdaten zusätzlich abzusichern. (wogegen überhaupt?) Aber nun stellt alle Welt auf https um und alle müssen da mitziehen oder eben draußen bleiben. Es ist müßig, sich hier querzustellen oder zu schimpfen.
Versuche das mal nicht nur aus dem einen Use-Case zu sehen (und da gebe ich Dir voll recht, die Weltdaten sind sowas von öffentlich) sondern aus Sicht von deren Infrastruktur. Die stellen alles auf https um, d.h. deren Administration hat aktuell bei der Bedienung deutlich mehr zu tun und zu Überwachen. Im kleinen ist das nur ein bischen Webserver-Konfiguration, aber im Großen - und davon gehe ich bei Inno jetzt einfach mal davon aus - ist das deutlich mehr. Ich schließe da von meinem Unternehmen auf Inno ;)
Und da macht es deutlich weniger Arbeit nur eine Variante pflegen zu müssen. Und man kann in der Firewall direkt mal Port 80 komplett eingehend sperren...

Eine Sandbox zum Testen der Community vorher bereitzustellen (wobei ich jetzt nicht weis, ob das getan wurde) wäre bei der Migration sicherlich sinnvoll gewesen, gibt deutlich weniger Reibung.


Dein Wortbild finde ich übrigens ganz lustig - den Zahn der Zeit kenne ich eigentlich nur im Zusammenhang mit der zeitbedingten Zersetzung und dem Verfall von etwas. Diesem gilt es doch stets entgegenzuwirken statt ihm auch noch zu folgen ...
Wenn Du das auf den Anspruch an Sicherheit beziehst paßt der Vergleich ungewollt sogar zu Deinem Verständnis. Ich habe das am eigenen Laib erlebt, wie nach ein paar Sony-Hacks, poodle, SSLv3, SHA2 auf einmal jeder davon ausgeht, daß man in "Sicherheit" einfach mal so reininvestiert. Sachen wie https-only werden auf einmal zur Selbstverständlichkeit, obwohl man als Kunde dafür keinen Cent berappt. Daß mal so ein bischen Hardware fällig ist wie ein Enterprise Loadbalancer der mit entsprechender SSL-Beschleunigerkarte locker mal 80 Steine kostet (natürlich ein Päärchen, man will ja HA) hat dabei keiner so recht auf der Rechnung, erst dann wenn man besagte stellt ;)
Und daran kann man erst mal nagen ;)

Aber zurück zum Thema, ich hab abgesehen von den Windows-MinGW-Anpassungen (mag keine inline Funktionen und so) nur in der GtServer.h dataUrl anpassen müssen, und Openssl unter Windows installieren müssen und es lief (war ja kein redirect mehr nötig). Meines Wissens baust Du das unter Linux, richtig? Ist dort die Anbindung von OpenSSL so schwierig? Klar, das Ganze läuft nicht mehr Standalone, aber daran ist ja eher die Lizenz von OpenSSl schuld.
 
Hihi - ja für den Admin von Inno ist's so wahrscheinlich einfacher zu warten. Bei mir läuft auch alles schon wieder zufriedenstellend.

Bei der Installation des Tools sind notwendigerweise vorcompilierte Windows-Binaries der Qt-Bibliotheken dabei. Das muss leider so, wenn man eigene Qt-Apps auf anderen Rechnern installieren will. Nun sind meine Binaries anscheinend ohne OpenSSL-support compiliert gewesen.

Also musste ich mir die nötigen Qt-Dlls eben selbst bauen. Ich arbeite hauptsächlich unter Windows 32Bit mit MS-VC2008. Das hat in meinen Augen die komfortabelste Entwicklungsumgebung. Unter Linux arbeite ich da nur sporadisch. Diabhoil hat aber z.B. das Tool unter Linux compiliert und ich habe bereits einige seiner Änderungen in meine lokalen Quellen übernommen. Er berichtete über ähnliche Probleme mit inline-Statements. MingW ist ja auch ein Windows-Port des GCC, oder?

Nun muss ich mir auf meinem Rechner wieder die ganzen Dlls zusammensuchen, die für ein erfolgreiches Deployment unter windows nötig sind, daraus ne ZIP-Datei frickeln und das Ganze auf SourceForge hochladen. Dann sollte alles wieder funzen... (theoretisch)

Ja und die notwendige zusätzliche Installation von OpenSSL wird jeder nutzer des Tools selbst durchführen müssen. Die drei Dlls darf ich leider nicht in meinem Deployment von Grepotool mitliefern.
 
Bei der Installation des Tools sind notwendigerweise vorcompilierte Windows-Binaries der Qt-Bibliotheken dabei. Das muss leider so, wenn man eigene Qt-Apps auf anderen Rechnern installieren will. Nun sind meine Binaries anscheinend ohne OpenSSL-support compiliert gewesen.
Hab jetzt keine Ahnung wann der Kram reinkam, aber mit meiner 5.3er Version hier hat es funktioniert. Was ich gemacht habe ist lokal eine Distribution so aufzubauen wie Du sie auslieferst, sprich meine selbst kompilerte Version vom Grepotool und all die Qt-dlls, die Du auch auslieferst - frisch aus meiner 5.3er distro herauskopiert, das hat funktioniert (in meinem Fall sind da etliche dlls aus mingw noch
mit dabei, weil leider dynamisch gelinkt). Das zusammen mit nem installierten openssl läuft dann.

MinGW ist mehr als nur ein Port des GCC, liefert quasi eine Linux-Laufzeitumgebung ohne daß die cygwin.dll nötig wird, da alles auf WinAPI-Calls direkt umgebrochen wird. Gibts den Source eigentlich auch irgendwo verwaltbarer abgelegt als ein Zip bei Sourceforge? Wäre doch was nettes für github.

Wegen MinGW Kompatibilität des Sources würde ich ein Compiler-Flag vorsehen (falls es nicht eh schon eines gibt, das ein mingw-gcc automatisch setzt).
 
Hmm - also wenn du das selbst kompilierst, dann brauchst du eigentlich keine QT-Dlls in deinem grepotool/bin Verzeichnis mehr. Dein System sollte dann alles aus Deiner Umgebung korrekt laden.
 
Ok - ich habe mal ein neues Zip-File hochgeladen und brauche nun Freiwillige, die das mal ausprobieren. Einfach den Anweisungen im 1. Post folgen, bitte...
 

DeletedUser22147

Gast
ähm....kann nicht gestartet werden, weil dieses widgets fehlt....kannst du mir das mal für dumme erklären bitte, damit es bei mir läuft