AdminTool AdminTool und DSM >= 5

[QTip]

Wie rufst du denn den DSM mit 127.0.0.1 auf? Ganz davon abgesehen kann 127.0.0.1 noch nie funktioniert haben, da diese IP sich nicht in der Ausnahmeliste vom AdminTool befindet. Benutze die IP der Diskstation, dann sollte es funktionieren.

 

[frogy]

Ich rufe das mit 127.0.0.1 auf da ich nicht im gleichen Netz bin und per SSH aus der Ferne zugreife.

Würde es reichen 127 als Ausnahme in der adm.php hinzuzufügen?

 

[QTip]

Kannst es ja erstmal selbst versuchen.
Öffene die Datei adm.php, in Zeile 19 steht

if (($ip == '203' || $ip == '198' || $ip == '192' ||  $ip == '172' || $ip == '10.') && $user != ''){

erweitere sie, dass sie nun so aussieht

if (($ip == '203' || $ip == '198' || $ip == '192' ||  $ip == '172' || $ip == '10.' || $clientIP == '127.0.0.1') && $user != ''){

$clientIP deshalb, da $ip nur noch das 1. Oktet der IP enthält, kannst es aber gerne auch mit $ip == '127' probieren.

 

[frogy]

Ich habe das in der /volume1/@appstore/adm/adm.php wie folgt ergänzt

if (($ip == '203' || $ip == '127' || $ip == '198' || $ip == '192' || $ip == '172' || $ip == '10.') && $user != ''){

muss man das noch an einer anderen Stelle ergänzen?

Ich werde immer noch geblockt.

 

[frogy]

Auch mit der $clientIP klappt das nicht. Steht da denn 127.0.0.1 drin? Oder übermittelt der Browser die lokale IP aus dem Firmennetzwerk wo ich mich grad befinde?

 

[frogy]

Scheint an FireFox zu liegen mit Chrome klappt es jetzt. Danke für den Tip

 

[QTip]

Welche IP übermittelt wird, kann ich dir leider nicht sagen. Alle IP Bereiche sind ja in der Zeile abgedeckt, sollte also ausreichen. Evtl. ist die IP aber auch leer, müsste man mal debuggen. Das Log wird leider nicht beschrieben, da es nicht angelegt wurde. Bitte mal den Befehl zum Anlegen des Log's auf der DS absetzen,

touch /var/log/adm.log

dann AdminTool aufrufen und im Log schauen welche IP mitgeliefert wird.

 

[Tommes]

Hey QTip!

Also erstmal... bei mir läuft das AdminTool unter DSM 6 Final, aber...

... ich hab mir über das Paketzentrum den Midnight Commander und Nano installiert und wollte dann über das AdminTool die /etc/profile editieren um Nano zu meinem Standardeditor im System als auch im mc zu deklarieren. Gesagt getan, die zwei Scriptzeilen in die /etc/profile eingefügt und bin dann auf speichern (das Disketten-Symbol) gegangen.

Und schwupps... war die /etc/profile leer!!! *schluck*

Ich hab mir dann aus der /etc.defaults/profile wieder den Inhalt geholt um die /etc/profile damit zu füttern. Scheinbar hat das auch funktioniert, oder hast du diesbezüglich irgenwelche Einwände? Wie auch immer...

Ich glaub, da stimmt etwas nicht beim AdminTool, was das speichern angeht. Kannst du das Verhalten evtl. bei dir reproduzieren?

EDIT: Hab grad mal ein paar .txt Dateien auf der Konsole erstellt und mit Testdaten gefüllt. Dann über das AdminTool versucht die Dateien zu editieren. Beim speichern das gleiche Phänomen... Dateiinhalt weg. Ist bei mir also reproduzierbar. Nicht gut!!!


Tommes

 

[QTip]

Ich schau mir das morgen mal an, da ich das AdminTool selbst nicht benutze ist mir das vermutlich nie aufgefallen.

 

[Tommes]

Mach dir kein Stress.
Ich hatte es unter DSM 5.2 zuletzt auch nicht mehr verwendet, da ich aktuell i.d.R. mit mc und nano arbeite, Hab das aber grade mal unter DSM 5.2 getestet und auch hier tritt der gleiche Fehler auf. Das ist schon ein ziemlich heftiges Problem... wie ich finde.

Tommes

 

[QTip]

Hab grad mal mit der /etc/profile und einer anderen Testdatei in /root probiert...konnte alle Daten schreiben und es ist nichts verschwunden. Habe das gleiche dann noch mit einem Nichtadmin (Berechtigung in Systemsteuerung eingestellt) durchgeführt, gleiches Resultat - es funktioniert. Nun müßte man mal rausfinden, was bei dir anders ist und was passiert, wenn die Datei geschrieben wird.

Achso, zum Schreiben wird Perl benötigt, das Synology Perl sollte ausreichen. Daran könnte es natürlich liegen, ich werde das mal nachstellen.

*Edit* Tja, Perl wird tatsächlich benötigt und das an mehreren Stellen. Keine Ahnung wieso er für diese einfache Aufgabe Perl benutzt hat, ich werde die Abhängigkeit in das Paket einbauen.

 

[Tommes]

Au weia, ich Seppel

Ich hab vergessen "Perl" zu installieren, auf beiden Maschinen. Jetzt läuft alles, sowohl unter DSM 5.2 als auch unter DSM 6. Blöder Fehler meinerseits, sorry!

Tommes

 

[QTip]

AdminTool 0.99g2

• Fehler beim Sichern von Dateien behoben, zusätzlich zu Init_3rdparty ist Perl notwendig
• Abhängigkeit Perl dem Paket hinzugefügt

Da am AdminTool selbst keine Veränderungen durchgeführt wurden, habe ich die Hauptversionierung nicht hochgezählt und zur Unterscheidung zur Vorversion einen Zähler angehangen.
Die neue Version 0.99g2 gibt es im Anhang, wie immer seid ihr für euer Tun veranwortlich.

 

[Tommes]

Prima, so kann es dann solchen Seppels wie mir auch nicht mehr passieren, sein System mal eben auf's Kreuz zu legen

Dankeeeee

 

[Alfons403]

Scheint an FireFox zu liegen mit Chrome klappt es jetzt. Danke für den Tip

Jau.
läuft mit Chrome, Opera und Edge!
Uups und jetzt auch mit Firefox, durch Zufall was von init 3rdparty
gelesen = Browsercache gelöscht und es geht!

 

[NeroRS]

Bei mir läufts auch wieder ganz hervorragend . Auch mit DSM 6
Danke für die neue Version...
Gruß Bernd

 

[meaki96]

Hallo

Kann es sein das es den Ordenr /rc.d unter DSM 6 nich mehr giebt ?
(/usr/syno/etc.defaults/rc.d)

Markus

 

[QTip]

ja, ist nun hauptsächlich in /etc/init

 

[NeroRS]

/usr/syno/synoman/ sollte schon existieren, sonst würdest du gar keine Weboberfläche haben. Wie hast du denn geprüft, dass /usr/syno/synoman/ nicht existiert, welchen User hast du benutzt?

Bei mir ist der da! Und auch jede Menge Inhalt...


In den Ordner sollte man auch ohne Adminrechte kommen und sollte ihn auch sehen können...

 

[bredok]

Hallo,

immer wieder klasse! Vielen Dank für die Modifizierungen und Ergänzungen.