AMBROSIA60 Portal  

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

Project: PHP-Nuke - 05. FileBase to Download Import - Umsetzung Ticker

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 5 - Umsetzung des TIC Imports




[29.1.06]
Weiterentwicklung wieder aufgenommen ....

  • *** Solution mit existierender DLIMP DB
    * php script to read fareas.fix into sql table
    * record length: 2535

    h1line_=readblock[2535]
     
    ltag_=asc( substr(h1line_,1,1) )
    tag_=substr(h1line_,2,ltag_)
    lcomment_=asc( substr(h1line_,55,1) )
    comment_=substr(h1line_,56,lcomment_)
     
    group_=asc(substr(h1line_,111,1))
     
    lpath_=asc( substr(h1line_,117,1) )
    path_=substr(h1line_,118,lpath_)
     
    ///
     
    do while not eof()
     
     readrecord()
     
     extract()
     
     suche path in dlimp:physicalpath
     get ownid
     
     save in dlimp2
       *AID
       areatag
       areadesc
       physicalpath
       grouptag
       cid
    enddo
  • TIC Import
    ==========
    -------------------------------------------------------------------------------------
    Created by HTick, written by Gabriel Plutzar
    File net2411.upd
    Area TEST
    Areadesc Pointlist-Updates for Net 2:2411
    Desc Net 2:2411 Pointlist Update
    Replaces net2411.upd
    From 2:2411/525
    To 2:244/1120
    Origin 2:2411/525
    Size 2445
    Crc FA32DE35
    Path 2:2411/525 1138291501 Thu Jan 26 16:05:01 2006 UTC HTick/lnx 1.3.0-cur 06-02-03
    Seenby 2:244/1120
    Seenby 2:2411/525
    Pw 12345678
    -------------------------------------------------------------------------------------
    
    read tic line by line
    
    $tcount = 0
    do while not eof
      do case
      case 'Area'
         query dlimp2  for areatag, get cid, physicalpath
         query dlimp   for ownid    get l1, l2                erweitern um FBA?
         $cid                                                 Noe, OWNID ist produktiv
         $path                                                FBA nur in Step 2
         $tcount = $tcount + 1                                phpnuke admin-console
      case 'File'                                             Bei der Definition
         $filename
         $tcount = $tcount + 2
      case 'Desc'
         $description
         $tcount = $tcount + 4
      case 'Size'
         $size
         $tcount = $tcount + 8
      endcase
    enddo
    version = version(filename,description)
    submitter = DLTIC v1.00
    if $tcount = 15 and (OWNID > 0 or FBA > 0)
    
      existiert file bereits?!?
    
      update _downloads with New*LID, cid, title (file+desc), url?, desc, date, name, email,
              submitter, filesize, version, homepage
      update _dlmgmt with New*LNO, lid, cid, l1, l2, fe
    endif
    
    
    Weiterhin: Update FILES.BBS size / crc, Update Num. Files in Area, Update Sum FSize in Area
     in _DLIMP
    
    
  • *** Gibt es eine Solution _OHNE_ existierende DLIMP DB ... ?
    ... wo DLIMP durch die Allfix Gruppen und Area Konfiguration neu
    aufgebaut wird? => Nein.

    Die DOWNLOADS Untergruppierung kann durch eine Allfix Groups Definition
    nachgebildet werden. Alle Areas die der Allfix Gruppe zugeordnet sind
    können in DOWNLOADS abgebildet werden.

    Problematisch wird es erst bei einem Verzeichnis Sharing mehrerer Allfix Areas
    (i.e. Areas: NODEDIFA, NODEDIFZ, POINT4D Einspeicherung auf Verzeichnis: Q:\SERVICE).

    Aus der Filebase Implementation sind Verzeichnisse Unique in der DLIMP DB vorliegend.
    Ein Verzeichnis Sharing aus Allfix Areas wäre durch eine weitere Tabelle, die
    eine n:1 Zuordnung von AFIX Areas zu FileBase Verzeichnissen enthält möglich.

    Daraus ergibt sich folgendes:
    Eine AFIX Umsetzung erzeugt eine zusätzliche Tabelle zu der bereits existierenden
    DLIMP (FileBase) Tabelle, in der die Allfix Konfiguration in die FileBase
    'übersetzt' wird. Die DLIMP Konfiguration muss bereits vor einer AFIX Umsetzung
    existieren. Eine Standalone Version des AFIX Pakets kann es aufgrund der
    zuvor genannten Vorraussetzungen nicht geben.


    Beim Übertragen der AFIX Konfiguration in die DLIMP Umgebung muss eine
    Prüfung des DLIMP Bestands durchgeführt werden. Entweder in der Form,
    dass AFIX Areas nur dann 'aktiviert' werden, wenn ein DLIMP Verzeichnis
    vorhanden ist, oder wenn der DLIMP Datenbestand 'vollständig' ist.

    Einige Fragen die die weitere Vorgehensweise beeinflussen könnten bzw. eine
    Erweiterung des Systems nach sich ziehen könnten:
    1. Wann ist ein DLIMP Datenbestand vollständig?
    2. Was ist mit inaktiven AFIX Areas deren Pfade in DLIMP nicht existieren?
    3. Was ist mit i.e. administrativen AFIX Areas, die nicht nach DLIMP überführt werden sollen?

    Aus Frage 1. ergibt sich schon fast zwangsläufig eine Report Lösung anzustreben.
    Erst einmal versuchen alle AFIX Areas zu übertragen. Wenn kein passendes Verzeichnis
    in DLIMP gefunden wird Generierung eines Reports:

        Area XYZ, Path ABC, Path not found in DLIMP

    Area wird zwar in die zusätzliche Tabelle übernommen, aber auf Status 'inaktiv' gesetzt,
    so dass bei einem Import die Area übersprungen wird.

    Mit dieser Lösung wäre auch bereits Frage 2 beantwortet.

    Frage 3 ist dagegen vielschichtiger. Was wenn der Pfad bereits aus der Filebase
    nach DLIMP übertragen wurde, die Area aber nicht für die aktive DOWNLOADS Sections
    aktiviert wurde?
    Aktive DOWNLOADS Area definiert sich durch OWNID > 0 or FBA > 0.
    Wenn OWNOD = 0 and FBA = 0 dann ist per Definition die Area zwar in DLIMP aufgeführt
    aber inaktiv.

                $block_act = 0;
                if ($dlaoid > 0 OR $dlafba >0) { 
                    //if ($dlapid == 0) {
                    if ($dlaipa > 0 ) {
                       if ($dlaipa == 1) {
                          // requested DEACTIVATE
                          $active = ""._REQINACTIVE."";
                       } else {
                          $active = _ACTIVE;
                          $block_act = 1;
                       }
                    } else {
                       $active = _ACTIVE;
                       $block_act = 1;
                    }
    	    } else {
                    //  augenblicklicher Status INACTIVE, REQ Activate
                    // or REQ Inactivate, option aktivieren,
                    // dektivieren
    

    Beim Auslesen von DLIMP muss dies also für den späteren Import Prozess berücksichtigt werden.


[4.2.06]
Nachdem das Einlesen der Allfix Groups- und FileArea Konfiguration abgeschlossen ist, und nun die Bearbeitung in der PHP-Nuke Admin Console ansteht, habe ich zunächst einmal nur einen Ansichtsmodus erstellt.

Screenshot DLIMP PHP-Nuke Admin Console v1.10 incl. AFIX Config:
Screenshot PHP-Nuke DLIMP Admin Console Module v1.10 incl. AFIX Config

Sofern eine bereits existierende AreaID in DOWNLOADS existiert, kann der Status der AFIX Konfiguration geändert werden (-> Active/Inactive).
Mit Details können erweiterte Informationen zu der zugeordneten DOWNLOADS Area und der entsprechenden AFIX Area abgerufen werden:


Screenshot DLIMP PHP-Nuke Admin Console v1.10 incl. AFIX Config, AFIX Config Details:
Screenshot Admin Console incl. AFIX Config Details

Existiert zu einer Allfix Area keine Entsprechung in DOWNLOADS (keine Übereinstimmung des Pfads), könnte aus den Allfix Konfigurationsinformationen recht einfach eine neue DOWNLOADS Area erstellt werden. Das ist besonders dann Interessant wenn neue FileEchoes automatisch in Allfix erstellt wurden.
Weiter oben habe ich zwar eine automatische Übernahme der Allfix-Konfiguration nach PHP-Nuke Downloads ausgeschlossen (siehe auch "Die DLIMP Konfiguration muss bereits vor einer AFIX Umsetzung existieren"), das gilt aber nur für die Initialisierung, Erstellung einer Basiskonfiguration. Existiert dagegen bereits ein DLIMP Datenbestand und liegen bereits genügend Allfix Informationen vor, können mit der Sammlung all dieser Informationen die fehlenden Informationen bei der Erstellung einer neuen Area unter DLIMP herangezogen werden. Die Zuordnung der übergeordneten Kategorie und die Aktivierung der Area unter PHP-Nuke Downloads unterliegt aber weiterhin der Entscheidung des Sysops, der hier interaktiv tätig werden muss.
Zwar wird, die übergeordneten Kategorie betreffend eine Voranalyse laufen gelassen (wie wurden andere vergleichsweise konfigurierten Areas zugeordnet?), die letztendliche Zuordnung muss aber immer noch der Sysop treffen.

Screenshot DLIMP PHP-Nuke Admin Console v1.10 incl. AFIX Config, AFIX Config Details, Erstelle neue DOWNLOADS Area:
Screenshot Admin Console incl. AFIX Config Details, Add New Area



[5.2.06]
Erstellen einer neuen FileArea mittels AFIX Konfigurations Daten ist nun implementiert. Die neue FileArea wird in Downloads nun automatisch aktiviert (entgegen der DLIMP Konfiguration Speichern Methode). Änderungen die in der DLIMP Umgebung getätigt wurden, werden dabei allerdings nicht berücksichtigt. Allerdings gehen auch keine Informationen verloren (i.e. Request Activate Area). Jeddoch muss um diese Änderungen auch zu übernehmen noch zusätzlich die Funktion Aktiviere DLIMP Konfiguration aufgerufen werden (siehe auch DLIMP Sonderfunktionen).

Änderung der Allfix Area Beschreibung:
Zur Änderung der Area Beschreibung muss zunächst mit der AFIX Konfiguration - Details - Funktion: Neue FileBase Area anlegen die neue Area Konfiguration in Downloads aktiviert werden.
Anschliessend kann unter DLIMP Konfiguration eine Änderung an der Area Konfiguration vorgenommen werden. U.a. Änderung der Area Beschreibung (siehe auch DLIMP Area überarbeiten).
This behavior is by design.

Problem: In der Testumgebung sind beim Speichern der DLIMP Konfiguration die BASEPATH und HOMEPAGE Definitionen verschwunden.
Die Basepath und Homepage Konfiguration kann nun noch an einer Stelle erfolgen. In der DLIMP Übersicht gibt es am unteren Rand die Einstellmöglichkeit für diese beiden Parameter. Die Speicherung dieser beiden Parameter erfolgt nun noch mit einer Funktion. Beim Speichern der Angaben erfolgt nun eine Validitätsprüfung (siehe auch DLIMP Sonderfunktionen).
Status: Fixed.

[16.2.06] Im Zusammenhang der Vorbereitungen für den Ticker Import bin ich auf die Problematik gestossen entweder die Angaben zum Tickern (wo finde ich die Tic Files, von welcher AKA und mit welchem Password kommen die Tics, an welche Addresse werden die geschickt?) manuell im Rahmen der DLIMP2 Überarbeitung mit einzugeben, oder aber im Areas.Fix Import Schritt aus der Allfix Setup.Fix Konfiguration auszulesen, so dass nur noch die Angabe der eigenen Downlink AKA fehlt, für den das Päckchen vom Uplink zur Verfügung gestellt wird. Sprich: In Step 2, PHP-Nuke Admin Console sollte nur noch die AKA einzutragen sein, die für den PHP-Nuke-Ticker benutzt werden soll. Alle anderen Angaben wie Tic Filepath, Maileroutbound, Downlink Konfiguration sollte aus dem Allfix Setup.Fix ausgelesen werden.

Da in der bisherigen Analyse die Analyse des Setup.Fix nicht vorkam, bin ich nun seit 3 Tagen daran zu versuchen die Setup.Fix Struktur zu entschlüsseln. Trotz der Struktur Informationen gestaltet sich das äusserst schwierig, da eine komplette Umsetzung aus der Pascal Notation zu absoluten File Positionen stattfinden muss um die Setup.Fix mit PHP einlesen und verarbeiten zu können. Da sämtliche Daten sequentiell Parameter für Parameter aneinandergeklatscht sind, die Datentypen aber ständig wechseln, bin ich immer wieder auf Fixpunkte angewiesen, von Einträgen die ich identifizieren konnte. Dazu gehören vor allem eindeutige Textpassagen. Noch bin ich auf so Merkwürdigkeiten gestossen, dass ein Datentyp LongInt 68 bytes ausmacht (!!!). Entweder habe ich mich irgendwo verzählt, die Angaben in der Definition sind nicht völlig korrekt oder aber es sind tatsächlich 68 bytes ....

Bislang habe ich ca. 15K der 18K Daten entschlüsselt. Aber es zieht sich noch ein wenig hin. Weiterhin ergibt sich ein weiterer Zwischenschritt im Gesamtprojekt (Import Allfix Setup.Fix).

[19.2.06] Nachdem das Allfix Setup.Fix nun entschlüsselt ist, kann ich mir nun Gedanken machen welcher der Informationen ich in DLTIC benötige.

  • Im wesentlichen geht es einmal um den Binkley Outbound, in dem die Flow Files zu finden sind, die den Link zum vertic'tem File und dem dazugehörigen Tic File liefert.
  • Der TicPath wird an sich nicht benötigt, da die Tic File Informationen aus den Flow Files ausgelesen werden.
  • Für die DLTIC Konfiguration wäre die Überprüfung der Allfix Version eventuell von Bedeutung, wenn sich mit einer Revisionsänderung auch eine Strukturveränderung ergibt.
  • Falls auch noch die Nodemanager Konfiguration ausgewertet werden sollte, wird auf alle Fälle der Parameter FEnumSystems benötigt, um die Struktur Dimension des Konfigurationsfiles ermitteln zu können.
  • Für das Auslesen der Tic Files wird auf alle Fälle zur Überprüfung des Uplinks die Liste der AKAs (NetAddress) benötigt, von denen eine Weiterverarbeitung erfolgen soll.
  • Um auch noch an das Tic Password zu gelangen, müsste sofern der Eintrag im Allfix Nodemanager bereits erfolgt ist auch noch das NodeFile.Fix ausgelesen werden. Da ich hierbei nicht mit Sicherheit von ausgehen kann, muss ich die Annahme treffen, das die Information nicht vorliegt (daher bislang noch nicht vorgesehen). Demzufolge muss die Eingabe der AKA und des Tic-Passwords für die DLIMP Konfiguration manuell erfolgen.

Hier nun die Parameter im Einzelnen und die jeweiligen absoluten Fixpositionen der Informationen zur Basis 1 (1 = 1tes Byte aus der Datei Setup.Fix)
In der PHP String Verarbeitung müsste zu den angegebenen Fix-Positionen immer -1 abgezogen werden.

Eine Auswahl der benötigten SETUP.FIX Content Informationen

Allfix v5.13 build 4
Basis 1

                                 [position,length]
                                 len     content
                                -------- ---------------------------------------
TicPath     : Q:\PT13\           490,1   491,60
OutBound    : H:\BINK\OUT\OUT\   917,1   918,60
Sysop       : Ulrich Schroeter   1100,1  1101,30
AFIXversion : 5.13                       ptr1: 9442,1 + '.' + ptr2: 9443,1
AFIXbuild   : 4                          9444,1
FEnumSystems: 255                        15119,1

Offset: [17105]  [0..40]
NetAddress  : 2:244/1120.0               zone ptr1: offset,1   ptr2: offset+1,1
NetAddress  : 2:244/1120.0               net  ptr3: offset+2,1 ptr4: offset+3,1
NetAddress  : 2:244/1120.0               node ptr5: offset+4,1 ptr6: offset+5,1
NetAddress  : 2:244/1120.0               pnt  ptr7: offset+6,1 ptr8: offset+7,1
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0               offset = offset + 8
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0                  ( ptrB * 256 ) + ptrA
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 2:244/1120.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0
NetAddress  : 0:0/0.0


Wie schon weiter oben beschrieben, werden einige zusätzliche Informationen benötigt, die so nicht aus der Allfix Setup.Fix Konfiguration auszulesen sind und daher in der DLTIC Konfiguration manuell eingegeben werden müssen:
  AKA bzw. NetAddress (Point-AKA)
  Tic-Password (zum Uplink)

Falls die Tic und Files in ein Spool Verzeichnis geschoben werden, müsste das aus Allfix übernommene Outbound Verzeichnis (Binkley Root Outbound Verzeichnis für die primäre Zone) überschreibbar sein. Beim Speichern der DLTIC Konfiguration muss darauf geprüft werden, ob das übernommene Verzeichnis das Binkley Outbound Verzeichnis oder ein anderes Verzeichnis ist, ob eine Umsetzung in der Directory Struktur erfolgen muss oder nicht (Spoolverzeichnis bleibt Flat, Binkley Outbound verzweigt in Unterverzeichnisse bei Point Konfigurationen (i.e. ..\00f40460.pnt\00000237.hlo).

Die Liste der NetAddresses kann auf Unique komprimiert werden, da nur die Liste der unterschiedlichen Addressen benötigt wird von denen Files geschickt werden können. Die Addressen 0:0/0.0 sind dabei zu ignorieren (NUL, N/A).

Nachdem nun die Allfix Uplink Parameter in DLIMPCFG eingelesen sind, hier nun der erste Screenshot von der zusätzlichen Uplink Konfigurations Seite:

Screenshot DLIMP PHP-Nuke Admin Console v1.10, AFIX Uplink Config:
Screenshot PHP-Nuke DLIMP Admin Console Module v1.10, AFIX Uplink Config

Von der Ablauflogik sind nun nacheinander 3 Submenüs verschachtelt.
Menü 1: DLIMP Filebase KonfigurationMenü1
Menü 2: DLIMP Allfix Konfiguration     Menü2
Menü 3: DLIMP Allfix Uplink Konfiguration         Menü3

wobei solange keine Allfix Uplink Informationen gespeichert wurden, das Menü 2 nicht aufgerufen werden kann und immer wieder in die Allfix Uplink Konfiguration verzweigt.
Hier muss mindestens die eigene AKA definiert werden, damit die weitere Konfiguration im Menü 2 getätigt werden kann.

[21.2.06] Bei der weiteren Analyse der Allfix Konfigurationsparameter bin ich im Allfix Setup über das Hold Directory das im Nodesmanager eingetragen werden kann gestolpert.
Das bietet Grund für unterschiedliche Verfahrensweisen bei der DLTIC Verarbeitung.
1. Benutze den regulären Binkley Outbound mit Flow-Files, aus denen die zu vertickenden Files auszulesen sind.
2. Benutze das Allfix Hold Directory für den DLIMP Downlink.
In beiden Fällen sind beim DLTIC unterschiedliche Vorgehensweisen vonnöten.
Im ersten Fall muss in der Binkley Outbound Struktur nach dem entsprechenden Flow-File gesucht werden und abgearbeitet werden. Ebenso muss ein Handling des Flow-Files selbst erfolgen.
Im zweiten Fall muss nur das Hold Directory nach TIC Files durchsucht werden. Die TIC Files ausgelesen werden und das zugehörige vertic'te File nach PHP-Nuke Downloads importiert werden.

Da hier zwei gänzlich unterschiedliche Verfahrensweisen zur Anwendung kommen, muss in der DLTIC Konfiguration dem Rechnung getragen werden. Nun besteht die Möglichkeit, diese Informationen automatisch aus der Nodesmanager Konfiguration von Allfix auszulesen oder aber diese Informationen händisch in die DLTIC Konfiguration einzutragen. Ersteres setzt vorraus, das die DLTIC Downlink Informationen bereits in Allfix eingetragen sind. Zweiteres bedeutet doppelte Arbeit und eine zusätzliche Fehlerquelle. Nur beim Erstaufruf der DLTIC Konfiguration ist die Downlinks-AKA noch unbekannt. Die Verknüpfung findet erst im Zuge der DLTIC Konfiguration statt und erst dann kann überprüft werden ob dazugehörige Informationen im Allfix Nodesmanager vorliegen. Fehlen die Angaben ist die DLTIC Konfiguration unvollständig. Sind die Angaben vorhanden, ist die DLTIC Konfiguration vollständig. Hierdurch können zweifelsohne Inkosistenzen entstehen.

Dem DLTIC kann es egal sein, ob bereits ein Eintrag in Allfix vorgenommen wurde oder nicht. Solange im Allfix Nodesmanager noch kein Eintrag für den DLTIC Downlink existiert, solange können auch noch keine Files vertic't werden. Erst wenn ein Eintrag im Allfix Nodesmanager für den DLTIC Downlink durchgeführt wurde, wird die Sache ernst. Beim DLTIC Import selbst kann aber eine Prüfung eingebaut werden, ob die DLTIC und Allfix Nodesmanager Konfiguration konsistent sind. Wenn Differenzen zwischen der DLTIC und der Allfix Downlinks Konfiguration zu finden sind (alternate Hold Directory oder Default Binkley Outbound), kann eine erneute DLTIC Konfiguration getriggert werden.

Eine Auswahl der benötigten NODEFILE.FIX Content Informationen

Allfix v5.13 build 4, Nodesmanager NODEFILE.FIX
Basis 1

Record Length:   388 bytes

                                 [position,length]
                                 len     content
                                -------- ---------------------------------------
NodeMGRrec  : 2:244/1120.888             1,8          ptrA             ptrB
                                                      ---------------- ----------------
                                                 zone ptr1: offset,1   ptr2: offset+1,1         
                                                 net  ptr3: offset+2,1 ptr4: offset+3,1
                                                 node ptr5: offset+4,1 ptr6: offset+5,1
                                                 pnt  ptr7: offset+6,1 ptr8: offset+7,1
                          
                                                 jeweils   ( ptrB * 256 ) + ptrA

Sysop       : DLIMP              9,1     10,35
Password    : ***************    45,1    46,20
Inactive    : FALSE                      99,1
TicFile     : Normal                     105,1   {None,Normal,Advanced} Basis 0
UseAka      : 0                          106,1
Archiver    : ZIP                        109,1   {ARC,ARJ,LHA,PAK,ZIP,SQZ,RAR,J,9,10} Basis 1
Forward     : TRUE                       110,1
MgrPassword : ***************    112,1   113,20
PackMode    : No packing                 134,1   {No packing,Pack TIC files,Pack ALL files,TIC + file}
                                                 Basis 0
SystemPath  : H:\BINK\OUT\DLIMP\ 204,1   205,60
PktPassword : ********           270,1   271,8

[23.2.06] Ich bin jetzt soweit gediehen, dass bei der DLTIC Uplink Konfiguration die notwendigen Allfix Informationen ausgelesen werden und mit zur Anzeige gebracht werden, sofern Downlink Informationen vorliegen. Schlussendlich muss an sich nur die Downlink AKA eingetragen werden. Alle weiteren Informationen holt sich das System aus den Informationen aus dem Import Stufe 1 (Allfix Rootpath, Outbound Path, Uplink-Sysop, usw.) und aus der Überprüfung der Allfix Nodemanager Konfiguration (TIC Password, Hold Directory, TIC Typ, usw.). Solange in der Allfix Nodemanager Konfiguration noch keine Downlink Informationen zu finden sind, solange bleibt auch die DLTIC Uplink Konfiguration unvollständig.

Screenshot DLIMP PHP-Nuke Admin Console v1.10, AFIX Uplink Config v2:
Screenshot PHP-Nuke DLIMP Admin Console Module v1.10, AFIX Uplink Config v2

Zur Installation und Einrichtung von DLIMP / DLTIC ergibt sich nun folgende Vorgehensweise:
  1. Installation und Konfiguration Gesamt DLIMP Filebase/Downloads System
  2. Allfix Setup Aufruf, Eintrag der DLTIC Downlink Informationen (AKA, Sysop, Passwort)
    Entweder als Standard Downlink Eintrag (mit regulärem Binkley Outbound) oder mit HoldDir Spoolpath
  3. Konfiguration DLTIC\includes\constants.php Eintrag Allfix Rootpath
  4. DLTIC1.php Aufruf zum Transfer der Groups und Areas von Allfix nach DLIMP
  5. Aufruf Admin Console, DLTIC Konfiguration
  6. Eingabe der zu verwendenden Downlink AKA
  7. Speichern
  8. Konfiguration DLTIC Areas
  9. Speichern
  10. Fortlaufender Aufruf des Tickers DLTIC3.php zum Importieren von TIC Files


[25.2.06]
Beim Test der TIC Import Funktion wollte ich die 3 Testareas, die im Allfix bereits konfiguriert waren in den PHP-Nuke Downloads Bereich aufnehmen. Hierzu musste ich eine der 3 Testareas zunächst neu hinzufügen (siehe auch Add Area). Hierbei gab es nun eine Schwierigkeit. Da alle 3 TIC Areas in ein und dasselbe Verzeichnis verweisen, wurde zwar eins der TIC Areas in PHP-Nuke Downloads aktiviert, aber die beiden anderen TIC Areas liessen sich, obwohl nun das Verzeichnis für Downloads existierte, nicht aktivieren.
Nachdem ich den Admin Consolen Script um eine Überprüfung beim Hinzufügen neuer Areas erweitert habe, indem auch alle anderen Areas die dieses Verzeichnis benutzen für die Aktivierung in PHP-Nuke Downloads freigeschaltet werden, stehen nun auch alle weiteren TIC Areas in der Admin Console für die Aktivierung zur Verfügung.
Status: fixed.

[25.2.06] BugTrack rep060225.001
Nach dem Hinzufügen neuer Areas im Zusammenhang mit TIC Areas kann eine Dateninkosistenz auftreten, hervorgerufen durch die asynchrone Verarbeitung durch den Synchronisationsprozess (DLIMP) und einer vorzeitigen Bearbeitung durch DLTIC.
Wenn in der Admin Console in der AFIX Areas Konfiguration eine Area hinzugefügt wird, in der bereits etliche Files in der realen Filebase existieren, werden beim DLTIC Import nur die neuen Files nach PHP-Nuke Downloads importiert. Alle älteren Files bleiben aussen vor. Da auch ein Update der Files.Bbs Informationen erfolgt kann somit bei einem späteren DLIMP Synchronisationslauf diese Area nicht mehr mit dem Status geändert erkannt werden. Ein automatisches Triggern einer DLIMP Synchronisation ist nicht so ohne weiteres möglich, da die Steuermechanismen (Semaphore File?) für die Synchronisation auf jedem System unterschiedlich sein können. Hierzu müsste dann zusätzlich in der DLIMP Konfiguration das zu verwendende Semaphore File definiert werden. Da auf manchen Systemen die Synchronisation aber auch ohne Semaphore File auskommen könnte, ergibt sich hieraus nun ein Dilemna.
Generell gilt: nach Anlegen einer neuen Area in der AFIX Areakonfiguration muss eine DLIMP Synchronisation angestossen werden, um die neue Area komplett nach PHP-Nuke Downloads zu importieren. Eine Möglichkeit würde jetzt noch bestehen: die Synchronisation einer Area in der DLIMP/DLTIC Admin Konsole nach dem Hinzufügen einer neuen Area nachzubilden.
[13.3.06]
Beim DLTIC Import werden nun beim Auswerten des TIC Files, nachdem der AreaTag festgestellt wurde, zusätzlich die Sync Informationen für DLIMP aus der DB ausgelesen und geprüft. Wird ein TIC zu einer bislang inaktiven Area verarbeitet, wird ein automatischer DLIMP UpdateArea() Aufruf für diese Area gezündet und abgearbeitet. Anschliessend wird das TIC zusätzlich in die Area mit aufgenommen. In diesem Zusammenhang habe ich sämtliche von DLIMP und DLTIC gemeinsam benutzte Funktionen in ein Include File includes\func_dli.php ausgelagert.
Status: fixed

[26.2.06]
Werden für den DLTIC Downlink TIC Files von inaktiven TIC Areas ins Spoolverzeichnis geschoben, behandelt DLTIC die Files wie folgt:
TIC Files werden in .BAD umbenannt. Die dazugehörigen vertickten Files verbleiben ebenfalls wie die BAD Files im Spoolverzeichnis.
Status: added

[26.2.06]
DLTIC über Downlink HoldDir fertig gestellt. Noch offen: Verarbeitung aus Binkley Outbound heraus mit Flowfile Handling.
Status: info only

[28.2.06]
DLTIC über Uplink Binkley Outbound Flowfiles fertig gestellt.
Flowfile Handling, Handling der TIC Files.
Status: info only

[28.2.06]
Problem Report: Im Unterschied zur FileBase Synchronisation wurden beim DLTIC Import Beschreibungen nur in Kurzform übernommen.
Beim Auswerten der TIC Files wird nun auch das Feld Ldesc ausgelesen. Sollte im TIC ein Feld Ldesc vorhanden sein, wird statt der Kurzform Desc die Langfassung der Beschreibung aus Ldesc importiert. In der AFIX Konfiguration erscheint nun beim entsprechenden TIC Typ nun zusätzlich ein Hinweis besser in den Advanced TIC file mode umzuschalten falls dieser auf None oder Normal gesetzt ist. Dies kann aber nur im ASETUP selbst umgeschaltet werden.
Status: fixed

[28.2.06]
Problem Report: Beim Wechsel von ASETUP Downlink HoldDir auf Binkley Outbound lieferte die DLIMP2.PHP Console im AFIX Konfigurationsmenü falsche Ergebnisse.
Zunächst blieb das HoldDir auf dem eingestelltem alternativem DLIMP Spoolpath. Nachdem ich das Feld DLTIC Alternatetives Spool Verzeichnis und Datei(en) auf den Default Wert von AFIX Uplink Binkley Primärer Zonen Outbound gesetzt habe, wurde der berechnete Spoolpath korrekt angezeigt und in die Konfiguration übernommen.
Fixed. Jetzt besteht aber die Möglichkeit, dass vergessen wird die neue Konfiguration zu speichern. Zwar wird der Path (Files) laut aktueller ASETUP Einstellung angezeigt. Das heisst aber nicht, dass auch die aktuellen Werte in der DLTIC Konfiguration gespeichert sind.
In Erweiterung erscheint nun neben der Anzeige von DLTIC Alternatives Spool Verzeichnis und Datei(en) solange ein Hinweis, bis die neue Konfiguration gespeichert wurde.
Status: fixed

[7.3.06] BugTrack rep060307.002
Versionsnummern Analyse macht nicht das was sie soll. Generelle Überarbeitung der Funktion ....
[12.3.06] Version() v2 arbeitet nun mit verschiedenen Mustererkennungen. i.e. v#.#, v.#.#, version #, usw.
Status: fixed









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