url in config, application.cfg deprecated?

Status
Für weitere Antworten geschlossen.

EL Duderino

Benutzer
Mitglied seit
02. Okt 2012
Beiträge
62
Punkte für Reaktionen
0
Punkte
0
Aus dem Wiki-Eintrag geht es nicht hervor, aber application.cfg ist deprecated?

Das Feld url in der config-Datei: Wie wird es vom DSM interpretiert? Der Developer Guide ist etwas knausrig :cool: und die Angabe im wiki relativ zu /usr/syno/synoman stimmt definitiv nicht, oder nicht ganz. Bisher habe ich diese Beisiele gesehen:
  • absolute URL
  • relativ zu /usr/syno/synoman
  • relativ zu /var/services/web
Gibt es da eine Regel, z.B. mehrere Verzeichnisse werden in einer bestimmten Reihenfolge durchsucht, wenn es nicht absolut ist?
 

nageniil

Benutzer
Mitglied seit
18. Aug 2009
Beiträge
207
Punkte für Reaktionen
4
Punkte
18
Ich weiß nur, dass die alte Methode mit der application.cfg immer noch einwandfrei funktioniert.
Ob deprecated oder nicht, ist mir bei meinen selbstgeschriebenen Moddings von früher also relativ wurscht...
 

gigon

Benutzer
Mitglied seit
20. Mai 2011
Beiträge
51
Punkte für Reaktionen
0
Punkte
0
Was nirgendswo Offiziell Dokumentiert ist:
Wenn man die tags port und protocol hinzufügt bekommt man einen pfad relativ zur jetzt geöffneten url
also man ist auf https://192.168.0.1:5001 im DSM und klickt einen link mit den tags
"protocol": "http",
"url": "/owncloud/index.php",
"port": "80"
wird http://192.168.0.1:80/owncloud/index.php geöffnet
ist man wiederum per dyndns drin wird die ip durch den dyndns Pfad ersetzt und man öffnet immer den richtigen link (Portfreigabe natürlich vorausgesetzt)

das Ganze wird z.B. im offiziellen phpMyAdmin Paket verwendet (habs daher geklaut ;) )
 
Zuletzt bearbeitet:

EL Duderino

Benutzer
Mitglied seit
02. Okt 2012
Beiträge
62
Punkte für Reaktionen
0
Punkte
0
[…]
das Ganze wird z.B. im offiziellen phpMyAdmin Paket verwendet (habs daher geklaut ;) )
Dank Dir, ich hatte es von Deinem owncloud-Paket weitergeklaut :cool:

Da könnte Synology aber ruhig mal mehr ins Detail gehen, aber in dem Abschnitt des Developer Guide ist dann ja auch plötzlich die Rede von application.cfg, obwohl es mit einer config-Datei angefangen hatte :confused:
Dafür haben wir jetzt endlich Unterstützung für DRM und bezahlte Pakete :rolleyes:
 

QTip

Super-Moderator
Teammitglied
Mitglied seit
04. Sep 2008
Beiträge
2.341
Punkte für Reaktionen
13
Punkte
84
Aus dem Wiki-Eintrag geht es nicht hervor, aber application.cfg ist deprecated?

Das Feld url in der config-Datei: Wie wird es vom DSM interpretiert? Der Developer Guide ist etwas knausrig :cool: und die Angabe im wiki relativ zu /usr/syno/synoman stimmt definitiv nicht, oder nicht ganz. Bisher habe ich diese Beisiele gesehen:
  • absolute URL
  • relativ zu /usr/syno/synoman
  • relativ zu /var/services/web
Gibt es da eine Regel, z.B. mehrere Verzeichnisse werden in einer bestimmten Reihenfolge durchsucht, wenn es nicht absolut ist?
Du solltest application.cfg und config nicht vermischen, denn im Wiki Eintrag wird nur auf die application.cfg eingegangen.

Auch solltest du den kompletten Eintrag im Wiki lesen, denn dort steht weiterhin... "Bei Adressen, die den User-Apachen benutzen oder nicht auf die Diskstation zeigen, wird der Pfad ausgehend vom Parameter "adress" angegeben." Es ist also immer abhängig, für welchen Apachen die Url bestimmt ist. Es wird auch immer genau der angegebene Pfad benutzt, da gibt es keine priorisierte Suche nach dem richtigen Pfad.

/var/services/web ist ein symbolischer Link auf /volume(x)/web und ist das Webroot für den User-Apachen
[/usr/syno/synoman ist das Root für den System-Apachen
 

EL Duderino

Benutzer
Mitglied seit
02. Okt 2012
Beiträge
62
Punkte für Reaktionen
0
Punkte
0
Du solltest application.cfg und config nicht vermischen, denn im Wiki Eintrag wird nur auf die application.cfg eingegangen.
Habe ich auch nicht, soweit ich sehe, bist Du der erste in diesem Thread, der das macht.

Auch solltest du den kompletten Eintrag im Wiki lesen, […]
Ich hatte nach dem url-Feld in der config-Datei gefragt, nicht nach Sachen in application.cfg.

[…] Es ist also immer abhängig, für welchen Apachen die Url bestimmt ist. Es wird auch immer genau der angegebene Pfad benutzt, da gibt es keine priorisierte Suche nach dem richtigen Pfad.
OK, dann verstehe ich jetzt aber nicht (und jetzt weder für application.cfg noch für config ;)), nach welcher Regel ausgewählt wird, ob der system- oder der user-Apache die Anfrage bedient. Wenn das feststeht, ist url in config resp. path in application.cfg immer relativ zum Wurzelverzeichnis des erwählten Apachen, oder verstehe ich
/var/services/web ist ein symbolischer Link auf /volume(x)/web und ist das Webroot für den User-Apachen
[/usr/syno/synoman ist das Root für den System-Apachen
falsch?

Nachtrag: Es würde natürlich Sinn machen, den Apachen zu wählen, der auf dem angegebenen port (in beiden Dateien gleich) lauscht, oder? Und ist application.cfg von Synology eigentlich als deprecated eingestuft (und man sollte für neue Projekte lieber ein config anlegen), oder ist die offizielle Regelung nur, daß config zuerst probiert wird?
 

QTip

Super-Moderator
Teammitglied
Mitglied seit
04. Sep 2008
Beiträge
2.341
Punkte für Reaktionen
13
Punkte
84
Habe ich auch nicht, soweit ich sehe, bist Du der erste in diesem Thread, der das macht.

Ich hatte nach dem url-Feld in der config-Datei gefragt, nicht nach Sachen in application.cfg.
Du hast im 2. Satz geschrieben: "Das Feld url in der config-Datei: Wie wird es vom DSM interpretiert?" Ich ging davon aus, das du mit config auch die "config" meinst und nicht ein alias für "application.cfg". Da du anschließend aus dem Wiki zitierst, dort aber nur "application.cfg" behandelt wird, kam mein Einwand.

OK, dann verstehe ich jetzt aber nicht (und jetzt weder für application.cfg noch für config ;)), nach welcher Regel ausgewählt wird, ob der system- oder der user-Apache die Anfrage bedient. Wenn das feststeht, ist url in config resp. path in application.cfg immer relativ zum Wurzelverzeichnis des erwählten Apachen, oder verstehe ich falsch?
Das ist korrekt. Der Systemapache antwortet ja bekanntlich nicht auf Port 80, insofern kann man das einfach auseinanderhalten. Ausserdem befinden sich Webseiten für den User-Apachen immer in /var/services/web.[/QUOTE]

Nachtrag: Es würde natürlich Sinn machen, den Apachen zu wählen, der auf dem angegebenen port (in beiden Dateien gleich) lauscht, oder? Und ist application.cfg von Synology eigentlich als deprecated eingestuft (und man sollte für neue Projekte lieber ein config anlegen), oder ist die offizielle Regelung nur, daß config zuerst probiert wird?
Wenn eine config existiert, dann wird diese bevorzugt benutzt. Auf DSM unter 3.x ist die config unbekannt.
 

EL Duderino

Benutzer
Mitglied seit
02. Okt 2012
Beiträge
62
Punkte für Reaktionen
0
Punkte
0
Du hast im 2. Satz geschrieben: "Das Feld url in der config-Datei: Wie wird es vom DSM interpretiert?" Ich ging davon aus, das du mit config auch die "config" meinst und nicht ein alias für "application.cfg". Da du anschließend aus dem Wiki zitierst, dort aber nur "application.cfg" behandelt wird, kam mein Einwand.
Das war vielleicht wegen dem verlinkten wiki-Beitrag mißverständlich, aber auch im config-Artikel ist unter url angegeben
die Aufrufadresse der Anwendung, relativ zu /usr/syno/synoman
und das hatte ich zitiert :)

Das ist korrekt. Der Systemapache antwortet ja bekanntlich nicht auf Port 80, insofern kann man das einfach auseinanderhalten. Ausserdem befinden sich Webseiten für den User-Apachen immer in /var/services/web.
OK. Dann könnte eine Regelkunde zur URL also etwa so lauten:
  1. URL ist absolut -> Es wird nichts vom NAS geliefert
  2. URL ist relativ bzw. fängt mit '/' an --> es hängt von port ab, bzw. vom Apachen, der an port hängt, was geliefert wird: Die URL wird dann als Verzeichnis relativ zur Document Root des Apache interpretiert
  3. Ist kein port angegeben, wird entweder 5000/5001 oder der aktuelle Port übernommen

Edit: Ich habe es vorläufig schon mal ins wiki eingepflegt
 
Zuletzt bearbeitet:

QTip

Super-Moderator
Teammitglied
Mitglied seit
04. Sep 2008
Beiträge
2.341
Punkte für Reaktionen
13
Punkte
84
beginnt die relative url mit /webman/3rdparty/... , dann ist es in jedem Fall der System-Apache, ansonsten der User-Apache oder eine 3. Instanz (eigener Webserver wie z.B. bei webmin) - dann wird evtl. noch zusätzlich eine Protocol/Port Angabe benötigt.
 

EL Duderino

Benutzer
Mitglied seit
02. Okt 2012
Beiträge
62
Punkte für Reaktionen
0
Punkte
0
beginnt die relative url mit /webman/3rdparty/... , dann ist es in jedem Fall der System-Apache, ansonsten der User-Apache oder eine 3. Instanz (eigener Webserver wie z.B. bei webmin) - dann wird evtl. noch zusätzlich eine Protocol/Port Angabe benötigt.

Woher weißt Du das? Ich habe es mal ausprobiert. Bei port 443 kam bei der URL /webman/3rdparty/…/index.html 404. Nachdem ich port auf 5001 gesetzt hatte, wurde die von mir unter /webman/3rdparty/…/index.html hinterlegte Seite auch angezeigt.

Bis zum Beweis des Gegenteils gehe ich davon aus, daß die URL relativ zum Document Root des auf port lauschenden Webservers interpretiert wird; oder absolut ist (wohlgemerkt bei einer config-Datei, nicht appl.cfg).
 

QTip

Super-Moderator
Teammitglied
Mitglied seit
04. Sep 2008
Beiträge
2.341
Punkte für Reaktionen
13
Punkte
84
/webman/3rdparty gehört zum System-Apachen und der lauscht nicht auf 443, deswegen die Meldung.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat 

 
 
  AdBlocker gefunden!

Du bist nicht hier, um Support für Adblocker zu erhalten. Dein Adblocker funktioniert bereits ;-)

Klar machen Adblocker einen guten Job, aber sie blockieren auch nützliche Funktionen.

Das Forum wird mit hohem technischen, zeitlichen und finanziellen Aufwand kostenfrei zur Verfügung gestellt. Wir zeigen keine offensive Werbung und bemühen uns um eine dezente Integration.

Bitte unterstütze dieses Forum, in dem du deinen Adblocker für diese Seite deaktivierst.

Du kannst uns auch über unseren Kaffeautomat einen Kaffe ausgeben oder ein PUR Abo abschließen und das Forum so werbefrei nutzen.

Vielen Dank für Deine Unterstützung!