Vertretungsplan (mal wieder...)

Hallo mal wieder!

Seit dem (leider nicht problemlos durchgelaufenen Update) funktioniert der automatische Upload (oder nur die Anzeige?) des V-Plans nicht mehr. Der Client läuft nach wie vor und meldet auch Erfolg beim Hochladen, allerdings zeigt schule-intern den Plan nicht an; Suche per FTP hat ergeben, dass sowohl im Ordner "arb-intern" (unsere Instanz) als auch im Ordner "www" ein Ordner "plan" liegen, dort wiederum die 4 Ordner für Lehrer/Schüler heute/morgen. Allerdings landet der per Client aktualisierte Plan in keinem der Ordner... jemand ne Idee, wo das Problem liegen könnte? In welchem Ordner müssten die aktuellen Pläne in der Version 1.4.2 landen?

Vielen Dank im voraus und viele Grüße

Sebastian

Danke, Chris! Den Ordner arb-intern konnt ich schadlos umbennen, das System läuft nach wie vor

Ich befürchte nur, dass ich beim Client keine Zielverzeichnisse angeben kann - oder müssen die hinter das Argument xxxPrefix? Hier der Auszug aus den dortigen Settings (updateKey stimmt natürlich so nicht :

updateTimerInMilliSeconds = 60000

dirSchuelerMorgen = S:\\2_Schule_Organisation_Sachaufwand\\203_Stunden- Vertretungsplan\\dsb\\aula_morgen

schuelerMorgenPrefix =

dirSchuelerHeute = S:\\2_Schule_Organisation_Sachaufwand\\203_Stunden- Vertretungsplan\\dsb\\aula_heute

schuelerHeutePrefix =

dirLehrerHeute = S:\\2_Schule_Organisation_Sachaufwand\\203_Stunden- Vertretungsplan\\dsb\\lz_heute

lehrerHeutePrefix =

dirLehrerMorgen = S:\\2_Schule_Organisation_Sachaufwand\\203_Stunden- Vertretungsplan\\dsb\\lz_morgen

lehrerMorgenPrefix =

urlToSchuleIntern = http://www.arb-intern.de

updateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

filetype = htm

useProxy = 0

proxyHost = 10.1.1.1

proxyPort = 8080

proxyUsername = sss

proxyPassword = 0000

isService = 0

Nächster Schritt:

Manuell die V-Pläne (.htm) per FTP in die entsprechenden Ordner geschoben, werden aber nach wie vor nicht im System angezeigt - unabhängig davon, ob ich den orig. Dateinamen aus Untis belasse (irgendwas mit subst.htm) oder so benenne, wie die Dateien die dort schon lagen (seite1.htm)... kann das noch mit dem schiefgelaufenen Update zusammenhängen?

Das wiederum klappt bei uns schon, die Anzeige ist dann halt sehr rudimentär und ein Graus, wenn man es anders gewöhnt ist

@Pierre: das ist ja komisch...

Also Stand jetzt werden durch den Update-Client weder die aktualisierten Pläne ins Verzeichnis www/vplan/... hochgeladen noch die dort händisch abgelegten Pläne im Portal angezeigt

Chrisland : unsere Tabelle "vplan_Data" ist leer, ist das normal? In der Tabelle "vplan" stehen zwar in "vPlanContent" die V-Pläne als HTML-Code, aber nicht die aus dem Ordner www/vplan sondern nur die, die wir notgedrungen als GPU014.txt in der Administration des Moduls Vertretungsplan hochgeladen haben...

Nachtrag: Jetzt warst Du ein paar Sekunden schneller als ich Deine URL hat leider nix gebracht, nach wie vor der händisch hochgeladene. Hatt mir schon gedacht, dass die Daten aus /www/vplan erst irgendwie verdaut werden müssen... in den Cronjobs hab ich nix dazu gefunden, wär super wenn Du rauskriegen könntest welches Script das erledigen sollte und wie wir es wieder zum Laufen kriegen...

Zitat von Chrisland

Konnte ich eben nicht testen aber vll die richtige url:
/index.php?page=vplan&mode=finishUpload

Das hat leider nix geholfen, aber immer her mit den Vorschlägen

Ich bin leider noch immer nicht weitergekommen...der Vplan-Updater meldet Erfolg - das tut er aber sogar, wenn ich in der config-Datei den Key ändere so dass er eigentlich keinen Zugriff mehr auf den Server haben sollte 😕

Leider ist nicht dokumentiert, wohin er die Dateien genau schieben sollte: in der spartanischen Config lässt sich nur die URL zur Instanz angeben.

Vll. könnte Christian sich hierzu mal äußern? Das würde mir evtl helfen, das Problem weiter einzugrenzen.

Vll könnte Christian auch ein bisschen den Vorgang des Vplan-Updates erklären: was genau geschieht wann und welches Skript verarbeitet welche Dateien, die wo liegen müssen?

Und: wie lange überschreibt der manuelle Upload der GPU014.txt den V-Plan?

Würd mir/uns helfen, das System besser zu verstehen und künftige Probleme besser in den Griff zu kriegen.

Vielen Dank schonmal im voraus an alle, die hierzu was beitragen können

LG,

Sebastian

Vielen Dank Jens - das schaut bei uns eigentlich genauso aus

Landen die 4 Vpläne bei jedem Sync in den jeweiligen Ordnern in /www/vplan?

Das passiert nämlich bei uns schon nicht. Und wenn ich sie händisch reinschiebe, werden sie vom System nicht verarbeitet ☹️

Ich vermute, dass das abgebrochene Update bei uns doch noch irgendwo Spuren hinterlassen hat.

Nur wie krieg ich das wieder zum Laufen?

Danke für die ausführliche Antwort, Chris! Zu Deinen Punkten:

- Ja, Java-Script läuft, aber was es tut ist leider nicht ersichtlich

- Ja, kein Fehler zu finden und auch der Update-Key ist identisch mit dem im Portal/der DB

- vplan hat 777, die Unterordner dann aber nur 755 - passt das so? Zudem liegt im Ordner vplan eine htaccess mit "Deny from all". Das war aber, soweit ich mich erinnern kann, bei unserer vorherigen Installation auch schon so.

- Wenn das Skript die URL zum Verarbeiten nur aufruft, wenn das Script nicht fehlerfrei läuft, ist das Verhalten erklärbar. Wenn es aber nur periodisch prüft ob neue Dateien in den Ordnern liegen (so tief durchblicke ich den Code nicht), dann hätte es aber auch meine manuell dort hochgeladenen Dateien verarbeiten müssen...

Vielen Dank auf jeden Fall, ich hab das Gefühl wir kommen der Sache näher

So, endlich ein Fortschritt: nachdem der Sync-Client auf einem anderen Verwaltungsrechner (ebenfalls Win 10) ebenfalls nicht funktioniert hat, hab ich ihn gestern mal auf einem (leicht veralteten) Server laufen lassen - und siehe da: der Vplan in arb-intern war verschwunden! Also war auf jeden Fall schonmal was passiert Nachdem ich dann in der config des Clients die URL auf https (statt http) verändert hatte, wurde der Vplan korrekt hochgeladen und auch wieder richtig im Portal angezeigt!

Am Montag schau ich mir die Sache auf dem Vplan-Rechner nochmal genauer an, ich befürchte aber dass irgendein Windows-Update da (hatten wir ja schonmal...) was im Hintergrund blockiert. Immerhin schaut es so aus, als wäre das Problem doch nicht in unserer schule-intern-Installation zu suchen

Um das Problem in Zukunft schneller eingrenzen zu können, wäre ein Debug-Modus beim Client sehr hilfreich - nur für den Fall, dass hier jemand fit ist in Java-Script und den Client (liegt ja auch im GitHub) in die Richtung erweitern kann und will.

Bin auf jeden Fall optimistisch, dass ich das Problem nächste Woche weiter eingrenzen kann und dann in den Griff krieg. Vielen Dank nochmal für Eure Unterstützung und Hilfe bei der Problemlösung!

LG

Sebastian