AMBROSIA60 Portal  

 
| | News | Sitemap | Startseite | Kontakt | Impressum |

Project: PHP-Nuke - 02. FileBase to Download Import - Umsetzung Import

AMBROSIA60-Portal  FileBase to Download Import Project



PHP-Nuke Download Section vs. FileBase
How to import from Filebase ...




Übersicht:
Start....Übersicht
Section 1....Analyse I, Filebase Synchronisation
Section 2....Umsetzung der Filebase Synchronisationsprozedur
Section 3....FileBase Import, Allgemeine Beschreibung
Section 4....Analyse II, Ticker Import
Section 5....Umsetzung des TIC Imports
Section 6....TIC Import, Allgemeine Beschreibung
Section 7....Einbindung DLIMP / DLTIC in die Maintenance
Section 8....Hinweis zur FileBase Security
Section 9....Übersicht und Status Gesamtprojekt
Section 10....References
Section 11....Download
Section 12....Weiterentwicklungen, Fixes



  • Section 2 - Umsetzung der Filebase Synchronisationsprozedur



Erster Screenshot von der DLIMP PHP-Nuke Admin Console:
Screenshot PHP-Nuke DLIMP Admin Console Module

Und hier der zweite Versuch mit einer geordneten Liste (Screenshot DLIMP PHP-Nuke Admin Console v0.2):
Screenshot PHP-Nuke DLIMP Admin Console Module v0.2

Nach Umstellung der Datenstruktur Und Anpassung der Import Routing Definition und des Admin Modules um eine Reihenfolgen Steuerung vornehmen zu können, hier der dritte Screenshot (DLIMP PHP-Nuke Admin Console v0.3):
Screenshot PHP-Nuke DLIMP Admin Console Module v0.3

Funktionen, die in der Admin Konsole bereits umgesetzt sind:

  • Änderung des importierten Filearea Titels für PHP-Nukes Download Categorie oder Download Area.
  • Änderung der Reihenfolgen der Kategorien
  • Änderung der Reihenfolgen der Download Areas
  • Änderung der FileArea zu Kategorie Zuordnung
  • Aktivierung/De-Aktivierung von einzelnen oder allen Download/Fileareas
  • Zwischenspeicherung der obigen Änderungen
  • Fix von Reihenfolgen Konflikten
Die nächste Aufgabe wird sein:
  • Speicherung der DLIMP Konfigurationen zum Download Bereich
Damit wäre die Admin Konsole so ziemlich abgeschlossen.

Eine Erweiterung der Groups Import Routine liefert nun zusätzlich die Anzahl der Files in jeder Filearea damit "tote Areas" bereits in der Bearbeitung identifiziert werden und deaktiviert werden können.
Screenshot DLIMP PHP-Nuke Admin Console v0.31:
Screenshot PHP-Nuke DLIMP Admin Console Module v0.31

FILESIZE- und FILECRC32- Ermittlung der in den FileAreas gefundenen FILES.BBS für die spätere Fileimport Routine der DLIMP Tabelle hinzugefügt. Die Groups Import Routine liefert nun bereits eine Anzeige über die FILESIZE und FILECRC32 der Datei FILES.BBS der jeweiligen Filearea.
ACHTUNG: PHP benötigt hierfür die Extension extension=php_mhash.dll ! (edit php.ini, enable php_mhash.dll)
Nach Neustart des Apache2 kam hier noch die Fehlermeldung: impmhash.dll not found.
Da bei PHP4 wohl die angeforderte Datei nicht existiert, aus einem PHP5 Test aber sehr wohl die impmhash.dll Datei zu finden war, habe ich die Datei PHP4 einmal untergeschoben - und es lief !!!

Nach Abschluss und Speicherung der DLIMP Konfiguration werden die Daten in die *_CATEGORIES Tabelle eingetragen. Sowohl in der DLIMP Konfigurations Oberfläche, alsauch in der Download Section tauchen die zuvor transferierten Fileareas nun als Categories auf. Screenshot von der Download Section nach Speicherung der Konfiguration von DLIMP PHP-Nuke Admin Console v0.31:
Screenshot PHP-Nuke DLIMP Admin Console Module v0.31



[10.7.2005]
Da ich momentan beruflich ausgelastet bin, geht die DLIMP Entwicklung nur schleppend voran.
Die Demo Version bekomme ich momentan auf die Schnelle nicht zum Laufen (zu viele Admin-Abhängigkeiten).
Trotzdem möchte ich heute hier schon den Algorythmus für den Fileimport (Step 4) vorstellen:
Involvierte Tabellen:
  *_downloads_downloads
  *_downloads_dlimp
neue Tabelle:
  *_downloads_dlmgmt

Die neue Tabelle *_downloads_dlmgmt wird benötigt um die Area Verwaltung auf neue und gelöschte
Files zu ermöglichen. Man könnte die Tabellenstruktur *_downloads_downloads erweitern. Das hätte
aber zum Nachteil, dass bei einem Update die Tabellen nicht mehr kompatible wären. Daher habe ich
mich entschlossen die Verwaltung in eine zusätzliche Tabelle auszulagern.

Tabellenstruktur _downloads_dlmgmt
   l1           Verweis auf _dlimp L1
   l2           Verweis auf _dlimp L2
   lid          Verweis auf _downloads lid
   fe           File Exists?  True/False


Der Algorythmus in groben Zügen:

/************************************************************************/
* Copyright (c) 07/2005, All rights reserved by U.Schroeter
* http://ambrosia60.dd-dns.de
* This program is free software. You can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2, June 1991 of the License.
/************************************************************************/

function Main()
for i = 1 to max(l1)                             //  l1 aus *_dlimp
  for j = 1 to max(l2)                           //  l2 aus *_dlimp
     workarea = area(l1,l2)
     oldcrc = workarea[crc]                      //  aus tabelle *_dlimp
     crc = check files.bbs of area workarea      //  path aus tabelle *_dlimp
     if crc = oldcrc
          * keine Änderung, skip
     else
          updatearea(workarea,l1,l2)             //  update einzelner Area
     endif
  next
next
* end function main

function updatearea(workarea,l1,l2)
reset_dlmgmt(l1,l2)                              //  downloads, alle Files zuruecksetzen
flag = False                                     //  als waeren sie nicht mehr vorhanden
q0 = 0                                           //  danach mit aktuellem Status reaktivieren
q1 = array()                                     //   ->  FileExists -> Yes
read file workarea-path\files.bbs
do while not eof()
  line = readnextline(files.bbs)                 //  Files.Bbs Zeile fuer Zeile lesen
  if (not flag)
     if (line position 1 <> " ")                 //  naechste zu analysierende Datei
         filename = left(line,bis " ")           //  faengt an Position 1tem Zeichen an
         url = baseurl + workarea-path + filename  //  Url fuer Update mit Datenbank generieren
         found = sqlquery(downloads, url)        //  Datei in DB vorhanden?
         if (not found)                          //  Nein:  neue Datei gefunden, einspeichern
            *  neuer File
            Flag = True
            q0 = 0
            q1[q0] = line
         else                                    //  Ja: Datei bereits vorhanden, Status auf
            Flag = False                         //      FileExists True setzen
            update(dlmgmt,lid,FE=True)
         endif
     else
         * skip
     endif
  else
     if ((line position 1 <> " ") or (empty line))  // Abbruchbedingung fuer Datensammlung
         * vorheriges gefundenes File, infos in q1 array abarbeiten, speichern, FE = True
         q0 = 0
         q1 = array()                               // Infos zu neuer Datei zusammenstellen
         filename = left(line,bis " ")              // und speichern
         url = baseurl + workarea-path + filename
         found = sqlquery(downloads, url)
         if (not found)
            *  neuer File
            Flag = True
            q0 = 0
            q1[q0] = line
         else
            Flag = False
            update(dlmgmt,lid,FE=True)
         endif
     else
         q0 = q0 + 1
         q1[q0] = line
     endif
  endif
enddo
* check dlmgmt
result = sqlquery(dlmgmt, l1=l1, l2=l2, not FE)
* alle jetzt gefundenen Records sind nicht mehr in der Filebase vorhanden => Löschen
* end function updatearea


function reset_dlmgmt(l1,l2)
update * of _dlmgmt value FE=False
* end function reset_dlmgmt

/************************************************************************/

Anmerkung:  URLs mit Files sollten in _DOWNLOADS alle lower() or upper() gespeichert werden!

[19.7.05]
Die erste Einspeicherung von Files in die Downloads Sektion ist geglückt.
Jetzt bedarf es nur noch einiger, kleinerer Korrekturen.
[20.7.05]
Updating ohne Dupes funktioniert ebenfalls.
Als Gimmick habe ich eine Versions Extraktion eingebaut, da die Downloads Sektion ein Feld Version anbietet.
Aus den ersten 2 Description Zeilen des Files.Bbs Verzeichnisses zu einem File wird versucht eine Versionsangabe zu extrahieren. Zunächst wird im Dateinamen nach Versionsnummern gefandet, die ebenfalls in den nachfolgenden 2 Kommentarzeilen auftauchen können. Wird eine Zahlenkombination gefunden, ist mit grösster anzunehmender Sicherheit dies die Versionsangabe.
Eindeutiger wird es bei Angaben wie v1.00, 1.0-rc2, 0.9-beta2
Die Titel Angabe beim Import habe ich dahingehend noch einmal korrigiert, dass teilweise nur mit der ersten Zeile der Description kein eindeutiger Dateititel erstellt werden konnte.
Daher habe ich mich entschlossen, für den Titel eine Kombination aus Dateiname, Beschreibungstext aus der ersten Zeile der Files.Bbs Beschreibung heranzuziehen.
Da in den Testversuchen einige Dateien zwar noch in den Files.Bbs Files enthalten waren, die aber tatsächlich in der Filebase fehlten, habe ich an entsprechenden Stellen eine Abfrage if fileexists(importfile) hinzugefügt. Nun werden weder Dupes noch fehlende Dateilinks nach PHP-Nuke Downloads Sektion importiert.
PNTCV551.ARJ [00] PntlCvrt-Converter all formats v5.51
                           +Fake-, Boss-, Point, Poss-Format
                           +conversions between all formats
                           +all formats conditional split
                           +into subsegments, with Nodelist lookup
                           +Fixes: Zones > 5, ?-handl, Pvt-handl
                           +Multiple Regions, multi zone aware
                           +  y2k tested
                           +Fixed Pvt IP-Only Nodes handling
                           +Multiple segments input *.upd
                           +NPK mode for central inbound conversions
                           +Add auto strip zip code and simple
                           +dupe pointnumber test and fix.
                           +new Index Level G for UPDCHCK >=5.50
wird zu:
Datei: PNTCV551.ARJ
Titel: PNTCV551.ARJ, PntlCvrt-Converter all formats v5.51
Version: 5.51
Description: PntlCvrt-Converter all formats v5.51 Fake-, Boss-, Point, Poss-Format conversions between all formats all formats conditional split into subsegments, with Nodelist lookup Fixes: Zones > 5, ?-handl, Pvt-handl Multiple Regions, multi zone aware y2k tested Fixed Pvt IP-Only Nodes handling Multiple segments input *.upd NPK mode for central inbound conversions Add auto strip zip code and simple dupe pointnumber test and fix. new Index Level G for UPDCHCK >=5.50

[21.7.05]
Update funktionierte prinzipiell. Im besonderen gab es aber ein Problem.
In der Area Service sollte die Pr24diff.203 aka .z03 eingespeichert werden. Es gab aber bereits ein File PR24DIFF.Z03 aus dem Jahre 2004 das bei der Überprüfung des Filenamens gefunden wurde. Aufgrund des Algorythmus, der bislang nur den Dateinamen prüft, wurde nicht erkannt, dass es sich hierbei um ein anderes File handelt, als dasjenige, das eingespeichert werden sollte. Demzufolge wurde die Datei nicht in die Datenbank transferiert und die "alte" Datei auch nicht entfernt.
Der alte Link hätte zwar weiterhin funktioniert, aber der Titel und die Beschreibung wurde nicht aktuallisiert, so dass unter der Beschreibung der Datei aus 2004 nun die Datei vom heutigen Tag im Zugriff stand.
Nun wird eine Prüfung auf Dateiname und Titel durchgeführt. Da das eigentliche Filedatum nicht registriert wird, könnte allenfalls die Filesize noch als Unterscheidungskriterium herangezogen werden. Das ist aber auch zu unsicher, da sich auch die Filesize nicht zwangsläufig ändern muss. Status: fixed.
Das Entfernen alter Links funktionierte dagegen auf Anhieb einwandfrei.

[23.7.05]
Ein weiterer Problempunkt bei der Erkennung ob NEU oder ALT ist gegeben, wenn die importierten Files einen statischen Namen und eine statische Beschreibung enthalten. Beispiel Area NODELIST-LAST: Files.BBS Eintrag
NODELIST.ZIP [00] Aktuellste Fidonet NODELIST ZIP
NODE0002.ZIP [00] Aktuellste Fidonet NODELIST.###
                        +fuer CDP Freq.
                        +Magic 'NODE0002'
wird zu
Filename      Title
------------- ----------------------------------------------
NODELIST.ZIP  NODELIST.ZIP, Aktuellste Fidonet NODELIST ZIP
NODE0002.ZIP  NODE0002.ZIP, Aktuellste Fidonet NODELIST.###
In der nächsten Woche bleiben die Einträge genauso wieder stehen, ausser dass die Datei ersetzt wird, also aktueller ist. Beim Einspeicherungsdatum verbleibt aber das Ältere ....
Das wirft dann auch gleich das nächste Problem auf - wird die Area NODELIST-LAST dann überhaupt jemals aktuallisiert? Nach dem bisherigen Script lautet die Antwort dann sicherlich NEIN, da die CRC32 der Files.BBS sich ja auch nicht verändert, da statisch, würde das Überprüfen jedes einzelnen Files mit einer CRC32 Checksum alleine auch nichts bewirken, da die Main-Routine keine Änderung feststellen kann. Die Main-Routine wäre aber wichtig, dass der Script in endlicher Zeit ablaufen kann, und nicht jedesmal Stunden benötigt um sämtliche Files einer grossen Filebase zu überprüfen ... Die Tabelle *_Downloads_Downloads jedenfalls gibt nicht mehr viel her:
CREATE TABLE nuke_downloads_downloads (
  lid int(11) NOT NULL auto_increment,                      // lfd. Pointer
  cid int(11) NOT NULL default '0',                         // categorie ID
  sid int(11) NOT NULL default '0',                         // sub.categorie ID
  title varchar(100) NOT NULL default '',                   // Title, wird bereits geprueft
  url varchar(100) NOT NULL default '',                     // URL, wird bereits geprueft
  description text NOT NULL,                                // Description bleibt gleich
  date datetime default NULL,                               // Date ist hier Einspeicherungs-
  name varchar(100) NOT NULL default '',                    //   Datum und nicht Filedate !
  email varchar(100) NOT NULL default '',                   // Username+Email des Submitters
  hits int(11) NOT NULL default '0',                        // Wieviele Zugriffe
  submitter varchar(60) NOT NULL default '',                // Submitter Name
  downloadratingsummary double(6,4) NOT NULL default '0.0000', 
  totalvotes int(11) NOT NULL default '0',
  totalcomments int(11) NOT NULL default '0',
  filesize int(11) NOT NULL default '0',                    // Filesize, muss sich nicht
  version varchar(10) NOT NULL default '',                  // unbedingt veraendern ...
  homepage varchar(200) NOT NULL default '',
  PRIMARY KEY  (lid),
  KEY lid (lid),
  KEY cid (cid),
  KEY sid (sid),
  KEY title (title)
) TYPE=MyISAM;
Ich habe jetzt mal die Nodelisten und Points24 der letzten paar Wochen neu vertütet:
N133     ZIP       269.252 23.07.05   10:52
N140     ZIP       268.748 23.07.05   10:51
N147     ZIP       268.767 23.07.05   10:50
N154     ZIP       268.771 23.07.05   10:50
N161     ZIP       266.708 23.07.05   10:49
N168     ZIP       266.209 23.07.05   10:48
N175     ZIP       265.968 23.07.05   10:47
N182     ZIP       265.923 23.07.05   10:47
N189     ZIP       265.493 23.07.05   10:46
N196     ZIP       264.148 23.07.05   10:45
N203     ZIP       263.801 23.07.05   10:43


P014     ZIP        38.124 23.07.05   10:55
P021     ZIP        38.126 23.07.05   10:55

P070     ZIP        36.945 23.07.05   10:57
..
P091     ZIP        37.947 23.07.05   10:58

P154     ZIP        36.055 23.07.05   11:00
P161     ZIP        36.057 23.07.05   11:00

P189     ZIP        35.516 23.07.05   11:01
P196     ZIP        35.517 23.07.05   11:01
Bei den Points24 Archiven sind 4x an aufeinanderfolgenden Wochen ziemlich "naheliegende" Filesizes zustandegekommen, aber immer noch unterschiedlich, auch wenn nur eine Differenz von 1 oder 2 Byte, so doch ausreichend einen Unterschied feststellen zu können.
Gibt es mögliche Files, die identisch bleiben?
=> JA
1. Mögliches Szenario, die CDP Nodelisten ... die relativ statisch sind ... sich von Woche zu Woche nur seltenst ändern ...
2. Filelisten ... Filebase Fileliste, die zwar täglich aktuallisiert wird, bei der aber meist nur am Wochenende, wenn die ganzen Node- und Pointlisten eintrudeln sich ändern.

Was wären mögliche Alternativen?
Torsten Bamberg lieferte den "Ticker Ansatz" ...
Der im FTN-System laufende Fileticker "versendet" an eine imaginäre Point-AKA die eingehenden Files ....
Funktioniert nur solange, wie keine weiteren File-Einspeisungsquellen vorhanden sind.
Bei mir laufen aber noch mindestens 2 weitere Fileeinspeisungen, die vom Ticker System entkoppelt sind:
a) lokale Filelisten (werden nicht ver-tickt)
b) FTSC Mirror Download (regelmässig wird ein Abgleich der Dokumente auf FTSC.org durchgeführt, neue Files landen zwar in der Filebase, der Ticker bekommt davon aber nichts mit ...)
c) Pointlist Tools Mirror Download (wie b, nur andere Quelle)

Lösungsansatz?
Eine mögliche Lösung wäre eine Kombination aus Synchronisation UND Ticker.
Neue Files, können schnell über den Ticker-Ansatz eingespeist werden. Dazu wäre ggf. die DLIMP Tabelle um eine Spalte TIC-Areaname erweiterbar.
Parallel dazu kann während der täglichen System Maintenance ein Synchronisationslauf initiiert werden, der dann einen kompletten Abgleich der Filebase durchführt und somit die Files erfasst, die nicht durch den Ticker laufen. Hier wäre dann auch der Ansatz mit Filesize und File-CRC32 Überprüfung.
Status: offen

Siehe auch Umsetzung des TIC Imports ff.

[26.7.05]
Ein weiteres Problem. Beim MakeNl Upgrade in der Filebase gibt es ca. 7 Files mit mn32* beginnend. Alle 7 Files sind mit Kleinbuchstaben in die Filebase geschrieben, worauf entsprechende DB Einträge nicht in der Downloads Section auftauchen.
a) Teilweise waren Files in der Files.Bbs fälschlicherweise noch als mn325... statt mn326... bezeichnet. Die Dateien existierten auch nicht mehr und konnten daraufhin nicht importiert werden.
b) Datei Prüfung wird auf Grossbuchstaben ausgedehnt.
Status: Fixed

[28.7.05]
DLIMP Demo Aufruf für unter PHP-Nuke registrierte Benutzer endlich in Betrieb genommen.
Die Portierung des Admin Consolen Scripts hat mich weit längere Zeit aufgehalten, als das ich mir das vorgestellt habe. Nun können aber die ersten Ergebnisse auch livehaftig "erlebt" werden.
Anmeldung im Webinterface - Menüpunkt DLIMP Demo





AMBROSIA60 News RSS 2.0 feed [Valid RSS]
Future4Fido
[ Join Now | Ring Hub | Random | << Prev | Next >> ]

©WebRing Inc.
FidoNet World Wide WebRing
<< Prev | Ring Hub | Join | Rate| Next >>
www.CAcert.org
SSL Powered
© 2003-2017 by Ulrich Schroeter Besucherzaehler