AdminTool Admin Tool "Blocked" Problem

[Tagger]

Nachdem ich eine Weile (einige Monate) nichts mehr an der DS gemacht habe, sie läuft soweit zuverlässig, läuft das Admin Tool nicht mehr, oder besser, gibt nur noch einen "BLOCKED" PopUp.

Beim DSM (3.0) bin ich als "admin" im lokalen Netz (192.168.xxx.xxx) eingeloggt. Laut Packet Manager läuft das Admin Tool auch. Allerdings existiert unter "/var/log" keine "adm.log".

Ich habe schon die SuFu gequält, finde aber keine Lösung für das Problem.

 

[itari]

Lösch mal die Browser-Cookies und melde dich neu an.

Itari

 

[Tagger]

Hi itari, öhm auf die Cookies bin ich noch nicht gekommen.

Ich möchte aber ungern alle löschen, gibt es bestimmte, die hier eine Rolle spielen?

 

[jahlives]

dann such dir doch das entsprechende Cookie raus. Wird wohl deine LAN-IP im Namen haben

 

[Tagger]

Ja genau und ein paar 127-er. Hat aber leider noch nicht gereicht. Also muß ich wohl doch mal alle löschen.

Edit: Alle Cookies zu löschen bringt in diesem Fall leider auch nichts?

Hattest du irgendwo in deinem Code, die Möglichkeit den Login auf eine bestimmte IP zu fixieren, bin der Meinung in irgendeinem Post soetwas gelesen zu haben? Was mich auch wundert, ist, daß keine Log-Datei angelegt wird.

 

[amarthius]

Stoppe mal init_3rdparty und starte es neu und versuche danach mal das AdminTool zu öffnen.

 

[Tagger]

Stoppe mal init_3rdparty und starte es neu und versuche danach mal das AdminTool zu öffnen.

Scheint auch nicht zu helfen. Hatte ja ohnehin die DS inzwischen schon mehrfach neu gestartet.

Vielleicht wird ja irgendwas wichtiges vom Admin Tool nicht gestartet/geladen. Eventuell muß ich das Teil nochmal neu installieren. Wäre allerdings schade.

 

[amarthius]

Ich meinte nicht die DS, sondern das init_3rdparty Skript. Immer wenn ich die gleiche Meldung erhalten habe, half mir dies (Start/Stop). Falls das nicht ausreichend war langte eine Neuinstallation des AdminTools.

 

[Tagger]

Ich hatte dich schon verstanden und nur das Script gestoppt. Allerdings hatte ich vorher schon versucht die admin.php (und js) dahingehend zu ändern, das er mir mal den Benutzernamen bei der Fehlermeldung mit ausgibt, allerdings weigert er sich da ebenfalls. Daher die Neustarts.

Falls das nicht ausreichend war langte eine Neuinstallation des AdminTools.

Wie oft musstest du dieses Tool denn schon neu installieren. Bei mir hat es gleich beim ersten oder zweiten Mal geklappt, das es richtig lief - bis jetzt? Mhmm, ärgerlich.

Edit: Mir ist gerade beim "init_3rdparty" Skript aufgefallen, daß der auf Port 5002 (http) eingestellt ist, laut Angabe im Package Manager unter Url. Ist das korrekt, weil über diese Adresse ist nichts erreichbar? Muß dieser Port irgendwo freigeschaltet sein?

 

[Tagger]

Auch eine Neuinstallation des Admin-Tools hilft nicht.

Was genau wird eigentlich noch alles geprüft und benötigt, damit das Tool normal startet (die ersten drei IP-Teile und der user sind klar). Muß ich noch irgendwas bestimmtes im Apache checken? Hier scheint mir die einzig logische Fehlerquelle zu sein.

Der DSM läuft bei mir über "https://192.168.xxx.xxx:5001".

 

[itari]

Die Prüfungen sind in der adm.php und in der adm.js ... hierfür man muss am DS-Manager gültig angemeldet sein (damit auch das Browser-Cockie gesetzt ist).

Itari

 

[Tagger]

Bisher habe ich das Admin-Tool ausschließlich über den DSM aufgerufen, war also bereits dort angemeldet. Darum verstehe ich ja auch nicht, warum ich nicht weiterkomme. Ich hatte sogar schon die Prüfung in der adm.php auskommentiert, selbes Problem. Die adm.js war mir bisher zum Ändern zu schwer lesbar. Die schau ich mir aber nochmal genauer an.

Danke dir erstmal.

 

[Tagger]

Jetzt wird's wirklich mysteriös: folgende Änderung lässt mich endlich rein.

// $user = exec('/usr/syno/synoman/webman/modules/authenticate.cgi');
$user = 'admin';

Was ich jetzt aber nicht verstehe, wieso gibt die authenticate.cgi was anderes als "admin" zurück. Wenn das so wäre, wieso komme ich dann in den DSM? Oder is da irgendwas anders codiert? Kann man sich irgendwie im Klartext anzeigen lassen, was die authenticate.cgi zurückgibt?

Edit: Die cgi scheint garnichts zurückzugeben?!?

 

[itari]

Ja - schon mysteriös. Wenn das jetzt ein grundsätzlicher Fehler wäre, dann müsste ja hier die Hölle los sein. Es scheint aber wohl überall zu laufen ... zumindest bei meiner 1337-Version geht es.

Itari

 

[Tagger]

Komischerweise hatte ich das Admin-Tool erst nach dem Update des DSM auf 3.0 das erste Mal installiert und er lief ja dann auch bis jetzt ohne Probleme.

Verstehen tue ich das trotzdem nicht, denn wenn cgi nicht laufen würde, würde ich mich nicht mal an den DSM anmelden können. Da der DSM aber von außerhalb nicht erreichbar ist, ebenso das Admin-Tool, dürfte aber noch alles im grünen Bereich sein (sicherheits-mäßig), oder muß ich mir jetzt Sorgen machen?

 

[Psy87]

hab das problem jetzt auch, liegt das an der neuen DSM3.1 ?

 

[itari]

hab das problem jetzt auch, liegt das an der neuen DSM3.1 ?

Keine Ahnung, ich habe das neue DSM 3.1 nicht installiert

Itari

 

[Psy87]

wo find ich denn die adm.php oder .js um die abfrage auzuhebel? das spk entpacken oder auf der dsm suchen?

 

[itari]

/volume1/@applications/adm/...

Itari

 

[Psy87]

Jetzt wird's wirklich mysteriös: folgende Änderung lässt mich endlich rein.
Was ich jetzt aber nicht verstehe, wieso gibt die authenticate.cgi was anderes als "admin" zurück. Wenn das so wäre, wieso komme ich dann in den DSM? Oder is da irgendwas anders codiert? Kann man sich irgendwie im Klartext anzeigen lassen, was die authenticate.cgi zurückgibt?

Edit: Die cgi scheint garnichts zurückzugeben?!?

ging bei mir nicht. immernoch blocked

komisch dass das sonst bei niemandem ist. nunja, dann wohl ohne. danke soweit