Beiträge von Stricted

danke für das preview

ich versuche es hier nocheinmal, könnten die folgenden änderungen in die nächste version mit aufgenommen werden?

diff --git a/nginx.lua b/nginx.lua
index 64d68a7..49f71bd 100644
--- a/nginx.lua
+++ b/nginx.lua
@@ -997,6 +997,10 @@ local function writePHPconfig(fh, opts, php, phpVersionsFCGI)
     fh:write("\t\ttry_files $fastcgi_script_name =404;\n")
     fh:write("\t\tfastcgi_split_path_info ^(.+\\.php)(/.*)$;\n")
     fh:write("\t\tinclude /etc/nginx/fastcgi_params;\n")
+    if LC.fs.is_file(opts.path .. "/conf/fastcgi_params.conf") then
+      fh:write("\t\t# Include customer-specific configuration options:\n")
+      fh:write("\t\tinclude ", opts.path, "/conf/fastcgi_params.conf;\n")
+    end
     fh:write("\t\tset $path_info $fastcgi_path_info;\n")
     fh:write("\t\tfastcgi_param PATH_INFO $path_info;\n")
     fh:write("\t\tfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n")
@@ -1019,6 +1023,10 @@ local function writePHPconfig(fh, opts, php, phpVersionsFCGI)
         fh:write("\t\ttry_files $fastcgi_script_name =404;\n")
         fh:write("\t\tfastcgi_split_path_info ^(.+\\.php)(/.*)$;\n")
         fh:write("\t\tinclude /etc/nginx/fastcgi_params;\n")
+        if LC.fs.is_file(opts.path .. "/conf/fastcgi_params.conf") then
+          fh:write("\t\t# Include customer-specific configuration options:\n")
+          fh:write("\t\tinclude ", opts.path, "/conf/fastcgi_params.conf;\n")
+        end
         fh:write("\t\tset $path_info $fastcgi_path_info;\n")
         fh:write("\t\tfastcgi_param PATH_INFO $path_info;\n")
         fh:write("\t\tfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n")
@@ -1340,6 +1348,10 @@ function configureVHost(cfg, opts, cnames)
               end
               fh:write("\tlocation / {\n")
               fh:write("\t\tset $proxy_host ", host, ";\n")
+              fh:write("\t\tproxy_set_header\tHost\t$host;\n")
+              fh:write("\t\tproxy_set_header\tX-Real-IP\t$remote_addr;\n")
+              fh:write("\t\tproxy_set_header\tX-Forwarded-For\t$proxy_add_x_forwarded_for;\n")
+              fh:write("\t\tproxy_set_header\tX-Forwarded-Proto\t$scheme;\n")
               fh:write("\t\tproxy_pass\t", proto, "://$proxy_host", path, "$request_uri;\n")
               fh:write("\t}\n")
             end

kk wäre es möglich dass die folgenden nginx.lua Änderungen mit in die nächste Version aufgenommen werden?

nginx.lua  | 12 ++++++++++++
 1 files changed, 12 insertions(+)


diff --git a/nginx.lua b/nginx.lua
index 83a1129..f4d7f93 100644
--- a/nginx.lua
+++ b/nginx.lua
@@ -1007,6 +1007,10 @@ local function writePHPconfig(fh, opts, php, phpVersionsFCGI)
     fh:write("\t\ttry_files $fastcgi_script_name =404;\n")
     fh:write("\t\tfastcgi_split_path_info ^(.+\\.php)(/.*)$;\n")
     fh:write("\t\tinclude /etc/nginx/fastcgi_params;\n")
+    if LC.fs.is_file(opts.path .. "/conf/fastcgi_params.conf") then
+      fh:write("\t\t# Include customer-specific configuration options:\n")
+      fh:write("\t\tinclude ", opts.path, "/conf/fastcgi_params.conf;\n")
+    end
     fh:write("\t\tset $path_info $fastcgi_path_info;\n")
     fh:write("\t\tfastcgi_param PATH_INFO $path_info;\n")
     fh:write("\t\tfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n")
@@ -1029,6 +1033,10 @@ local function writePHPconfig(fh, opts, php, phpVersionsFCGI)
         fh:write("\t\ttry_files $fastcgi_script_name =404;\n")
         fh:write("\t\tfastcgi_split_path_info ^(.+\\.php)(/.*)$;\n")
         fh:write("\t\tinclude /etc/nginx/fastcgi_params;\n")
+        if LC.fs.is_file(opts.path .. "/conf/fastcgi_params.conf") then
+          fh:write("\t\t# Include customer-specific configuration options:\n")
+          fh:write("\t\tinclude ", opts.path, "/conf/fastcgi_params.conf;\n")
+        end
         fh:write("\t\tset $path_info $fastcgi_path_info;\n")
         fh:write("\t\tfastcgi_param PATH_INFO $path_info;\n")
         fh:write("\t\tfastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n")
@@ -1341,6 +1349,10 @@ function configureVHost(cfg, opts, cnames)
               end
               fh:write("\tlocation / {\n")
               fh:write("\t\tset $proxy_host ", host, ";\n")
+              fh:write("\t\tproxy_set_header\tHost\t$host;\n")
+              fh:write("\t\tproxy_set_header\tX-Real-IP\t$remote_addr;\n")
+              fh:write("\t\tproxy_set_header\tX-Forwarded-For\t$proxy_add_x_forwarded_for;\n")
+              fh:write("\t\tproxy_set_header\tX-Forwarded-Proto\t$scheme;\n")
               fh:write("\t\tproxy_pass\t", proto, "://$proxy_host", path, "$request_uri;\n")
               fh:write("\t}\n")
             end

Zitat von antondollmaier

*sign*

Chroots erzeugen mehr Aufwand und größere Probleme, als sie letztendlich nützen.

Zumal, wie Herr Keppler schon schrieb, man über PHP/Python/CGI sowieso genau das auch ausführen kann, was man über SSH machen könnte.
"Einsperren" mag über open_basedir und den safe_mode mit PHP 5.x noch funktionieren, wird mit PHP7 aber schwer und mit Python gar unmöglich.

Ganz abgesehen davon, dass open_basedir von PHP zwar einen Call von fopen() oder file_get_contents() verifiziert. Den identischen Aufruf von "system('cat ...');" hingegen nicht.

Warum also den Benutzer bei SSH künstlich einschränken und den Aufwand bei der Pflege erhöhen, gleichzeitig aber die Webserver-Umgebung weiterhin "offen" lassen?

Alles anzeigen

dem stimme ich komplett zu, ich hatte mal die idee das jailkit zu modifizieren um ssh user einzusperren den webserver aber normal weiter laufen zu lassen

hatte damit auch angefangen https://github.com/Stricted/jailkit

habe die ganze idee am ende aber wieder verwofen weil es ein viel zu großer aufwand ist das ganze zu pflegen
zudem kommen die oben angesprochenen probleme mit den php funktionen exec/shell_exec/system

Zitat von thopoh

Die Updates die Regelmäßig kommen mache ich schon alle mit, das heißt aber doch nicht, das ich jedesmal den Server komplett neu starten muss? In den Updates sind ja auch die Kernel-Updates mit dabei.

Ich denke doch das braucht man bei einem Linux System nur ganz selten. Jedenfalls was ich von Systemadministratoren so gesagt bekomme (Hetzner,Antagus,Host Europe, etc.). Bin ganz stolz das ein Server von mir schon 732 Tage läuft ohne Mukken und immer alle Updates mitgemacht

Hoffe ich bring jetzt nichts durcheinander?

MnG
thopoh

Alles anzeigen

im grunde hast du die updates heruntergeladen und installiert, diese sind aber nicht immer direkt aktiv
z.b. bei einem kernel update empfiehlt es sich neuzustarten um ganz sicher den neuen kernel zu benutzen

hässlich wirds wenn libc geupdated wird, ich denke nicht dass du nach einem update alles auf dem server manuell neustartest damit es die neu installierte libc version nutzt

apcu-bc wäre auch noch hilfreich wenn schon apcu angeboten wird https://github.com/krakjoe/apcu-bc

Zitat von aziegler

dass man dann wieder von Apache/nginx abhängig ist.
ich finde das einen entscheidenen Vorteil, dass das getrennt ist.

wenn es brennt kommst du doch immernoch über den port an lc
wenn der webserver am abkacken ist wird es dem kunden höchst warscheinlich nicht wichtig sein das er auf lc kommt (der kann dann sowieso nichts machen)

Zitat von kk

Wenn Speedport "offiziell" die Einstellung anderer DynDNS-Anbieter erlaubt, werden wir uns gerne ein Testgerät anschaffen und die Konfiguration dokumentieren.

zumindest im Speedport Hybrid ist das eine offizielle funktion

der hinweiß auf z.b. eine fritzbox zu wechseln ist nicht hilfreich da es von avm keinen hbrid router gibt

ein per acme ausgestelltes zertifikat konnte nicht erneuert werden

meldung im log

[2016/11/26 09:05:40.520383] [30328|24636] ACME: sceduling renewal of SSL certificate for 'domain.net'
[2016/11/26 09:05:41.160963] [30328|24636] ACME: newCert() failed. Status=403, response={
  "type": "urn:acme:error:unauthorized",
  "detail": "Error creating new cert :: Authorizations for these names not found or expired: domain.net, www.domain.net",
  "status": 403
}

nun ist die frage warum? das zertifikat wurde über liveconfig ausgestellt, scheint so als hätte liveconfig einfach vergessen dass es dieses zertifikat gibt...

habe das entsprechende zertifikat jetzt gelöscht und lasse es neu ausstellen

btw. sollte "sceduling" nicht besser "scheduling" heißen?

wird php-fpm noch kommen?
habe irgendwie die hoffnung aufgegeben scheint so als würde man nginx irgendwie neben liegen lassen

kk könnte man den entsprechenden X-Real-IP header für nginx in die aktuelle preview noch mit reinnehmen?

Zitat von WebService4U

Ja, Anton, dann hat man aber das Problem, wenn ein Passwort-Reset angefordert wird, dass sich dann in der Passwort-Reset-Mail ein Link zum LC mit Port 8443 befindet...

lässt sich ebenfalls beeinflussen
hier mal der auszug aus meiner liveconfig.conf

http_proxy_ip_from = 127.0.0.1,::1
http_proxy_ip_header = X-Real-IP
http_proxy_url = https://lc.meine-domain.net

dann passt auch die url in den mails

auch in die custom.lua mit eingetragen?

Zitat

Database connection error (1): The MySQL adapter 'mysql' is not available.Database connection error (1): The MySQL adapter 'mysql' is not available.

liegt daran dass die mysql extension aus php entfernt wurde die zuvor in php5 als veraltet markiert wurde
entweder auf php5 bleiben oder das cms an mysqli oder pdo anpassen

nachdem ich eben ein bisschen getestet habe konnte ich das problem mit einem
chmod 0755 /etc/init.d/nginx-php-fcgi
und
systemctl enable nginx-php-fcgi
lösen

nach einem reboot werden die fcgi prozesse nicht automatisch gestartet
um diese wieder ins leben zu holen muss ich auf den kunden gehen und eine domain bearbeiten

Zitat von kk

Um das abzukürzen: es gibt keinen Workaround, da LiveConfig in diesem Fall nur die IP des Proxies sieht. Mit dem nächsten Update kommen aber zwei neue Konfigurationsparameter (http_proxy_ip_header und http_proxy_ip_from) über die man LiveConfig explizit anweisen kann, die IP aus einem bestimmten Header-Feld (z.B. "X-Forward-IP" o.ä.) zu übernehmen.

Viele Grüße

-Klaus Keppler

Hallo herr Keppler, ich habe gerade dass problem dass ich versuche mittels nginx einen proxy einzurichten
leider funktioniert es nicht da der nginx keinen header mit der eigentlichen ip mitgibt (ich erstelle eine subdomain im hosting vertrag und gebe dort als weiterleitung proxy an)
somit kann ich auch in liveconfig mittels http_proxy_ip_header die ip des nutzers nicht abfangen
hilfreich wäre es wenn in die configs "proxy_set_header X-Real-IP $remote_addr;" mit übernommen werden würde

allgemein wäre es schön wenn die komplette funktionalität von liveconfig auf der api abgebildet wäre, dann könnte mann einige sachen in seinen eigenen systemen besser automatisieren (z.b. komplett eigene verwaltungs software die dann u.a. eben auch liveconfig ansprechen kann oder eine desktop applikation für die eigene lc instanz...)

Zitat von kk

Auch das ist mit Let's Encrypt kein Problem
Im TLSA-Record kann man festlegen, ob man einen Hash über den Key oder über das Zertifikat veröffentlicht. http://www.liveconfig.com läuft mit DANE/TLSA über den Public Key, signiert mit Let's Encrypt.

hm ok das war mir neu, hatte diesbezüglich bisher nur mit dem hash des zertifikates gearbeitet

wieder was gelernt danke

Zitat von kk

Das ist falsch - es wird ja der Hash vom Key veröffentlicht, und nicht der vom Zertifikat. Wie lange der Key gültig bleibt kann im Grunde jeder selber entscheiden... HPKP ist also durchaus mit Let's Encrypt möglich.

sry hatte es gerade mit dane/tlsa vertauscht

Zitat von aziegler

nevertheless, nachdem man schon LE hat, würde ich das Thema weeeeiit hinten priorisieren)

ich nicht, ich bevorzuge startssl (das schon seit jahren mit class 2)
einfach weil die zertifikate eine längere laufzeit haben (klar wenn es automatisiert ist macht es keinen unterschied)
allerdings kannst du mit den le zertifikaten sowas wie hpkp nicht gescheit umsetzten (lange lebenszeit des headers (wird empfohlen) ist nicht möglich)

zum anderen sind alternativen nie verkehrt