Beiträge von KB19

Hmmm, ich frage mich gerade, wie viele Jahre ich Perl nicht mehr angerührt habe…

Ich bekomme gerade Aggressionen, fast wie bei Python. Aber nur fast, Perl ist noch erträglich!

/me programmiert sich gerade just4fun ein paar Munin-Plugins fürs Webhosting

Inspiriert durch diesen Thread: https://forum.netcup.de/anwendung/wcp-…ebhosting-8000/

(Sind im Endeffekt nur die normalen Shell-Plugins, die statt einem lokalen /proc z.B. ein externes PHP-Script abfragen.)

Zitat von timkoop

https://www.tknc.de/s/3PMssK6ffp3j8ZH

Funktioniert einwandfrei. Danke!

Was macht NC eigentlich, wenn der Ordner schon existiert bei Remote-Freigaben?

Verschieben in eigene Unterordner klappt wohl, aber umbenennen kann ich eine Remote-Freigabe ja nicht.

Kann mir mal jemand einen Test-Ordner in seiner Nextcloud freigeben?

Ich würde gerne das "Add to your Nextcloud" Feature testen…

Zitat von [netcup] Lucia

Es ist nicht geplant, dies umzusetzen. Der Sicherheitsmodus bleibt "web only".

Vorausgesetzt ich habe die Aussage richtig verstanden: Immerhin konsequent entschieden

Mein letzter Beitrag, mit dem ich in diesem Thread nerve…

Ich habe meine ganzen Nextcloud-Anpassungen nun in einem Git-Repository zusammengefasst, inkl. der Anpassungen für das CMS Pico: https://github.com/froonix/webhos…pdocs/nextcloud

Alle Patches (inkl. der config.php) sind automatisiert und sauber in Shell-Scripte verpackt. Der Cronjob patcht die Konfiguration nun automatisch, bevor occ ausgeführt wird. Die Nextcloud-Sourcen sind bei den Beispielen in /httpdocs/nextcloud/nextcloud abzulegen. Sollte ich noch was ändern oder erweitern, kündige ich das in diesem Thema nicht mehr an. Ein kleines PHP-Chunk-Upload-Tool für Nextcloud, das von den Argumenten als Drop-In-Replacement für cp gedacht ist, sollte auch bald fertig werden. Das landet in einem eigenen Repository.

Zitat von whoami0501

Schau mal hier *duck*

*bookmark*

Gibt es die Testdateien unter lg.netcup.net gar nicht mehr?

Schade, die habe ich immer sehr gerne für Speedtests genutzt

Muss ich mir wohl mal eigene Dateien auf den Server legen…

Zitat von Xenion

Weitere Ideen?

Wenn es manuell funktioniert und Du auch keine Fehlermeldung per E-Mail bekommst: Support kontaktieren

Mach das. Ich will nur ausschließen, dass es bei Deinem Server vielleicht generell "hängt". Dann können wir lange den Fehler beim Cron-Stil suchen

Funktioniert es, wenn Du nicht den Cron-Stil verwendest und z.B. stündlich auswählst?

btw: Ich habe es gerade geschafft, mich in Nextcloud auszusperren!

Wie? Weiß ich nicht mehr 100%. Aber das Ding hat behauptet, dass ich 2FA bei meinem Account erzwungen habe. Da kein nutzbarer 2FA-Provider aktiv war, konnte ich nicht mehr rein. Ich musste in der DB händisch herumpfuschen (oc_twofactor_providers Tabelle), um den Login wieder freizugeben. Sehr seltsame Sache.

RS 1000PS

Wisst ihr, was ich bei Nextcloud liebe? Die App cms_pico, da dadurch mein Lieblings-CMS für einfache Dinge direkt integriert wird. Leider habe ich es noch nicht geschafft, die Kurz-URLs so ans Laufen zu bekommen, wie das von den Entwicklern angedacht war. Ich habe es jetzt mit einem kleinen Hack gelöst, der besonders beim Webhosting einwandfrei läuft:

<?php

if(substr($_SERVER['REQUEST_URI'], 0, 9) === '/pico.php')
{
    header('Location: /');
    exit;
}

$site = preg_replace('#^/sites/#', '', $_SERVER['REQUEST_URI']);
$site = preg_match('#^($|\?)#', $site) ? 'default-site' : $site;
$_SERVER['REQUEST_URI'] = '/apps/cms_pico/pico_proxy/' . $site;
require_once(__dir__ . '/index.php');

Die .htaccess-Datei habe ich dafür geringfügig erweitert:

Zitat

<IfModule mod_rewrite.c>

Options -MultiViews

RewriteRule ^(sites($|/[^/]+))$ $1/ [L,R]

RewriteRule ^sites/ pico.php [L]

RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]

RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]

RewriteCond %{REQUEST_FILENAME} !\.(css|js|svg|gif|png|html|ttf|woff2?|ico|jpg|jpeg|map|webm|mp4)$

RewriteCond %{REQUEST_FILENAME} !core/img/favicon.ico$

RewriteCond %{REQUEST_FILENAME} !core/img/manifest.json$

RewriteCond %{REQUEST_FILENAME} !/remote.php

RewriteCond %{REQUEST_FILENAME} !/public.php

RewriteCond %{REQUEST_FILENAME} !/cron.php

RewriteCond %{REQUEST_FILENAME} !/core/ajax/update.php

RewriteCond %{REQUEST_FILENAME} !/status.php

RewriteCond %{REQUEST_FILENAME} !/ocs/v1.php

RewriteCond %{REQUEST_FILENAME} !/ocs/v2.php

RewriteCond %{REQUEST_FILENAME} !/robots.txt

RewriteCond %{REQUEST_FILENAME} !/updater/

RewriteCond %{REQUEST_FILENAME} !/ocs-provider/

RewriteCond %{REQUEST_FILENAME} !/ocm-provider/

RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*

RewriteCond %{REQUEST_FILENAME} !/pico.php

RewriteRule . index.php [PT,E=PATH_INFO:$1]

RewriteBase /

<IfModule mod_env.c>

SetEnv front_controller_active true

<IfModule mod_dir.c>

DirectorySlash off

</IfModule>

</IfModule>

</IfModule>

Alles anzeigen

Fett hervorgehobene Zeilen sind von mir. Das war eine schwere Geburt…

Zitat von Caspar

Ich würde auf kaputt tippen, localhost hat ich bei netcup noch nie bei einer DB

Zitat von tab

Also localhost hatte ich noch nie. Oder entsteht sowas vielleicht, wenn man eine der "Anwendungen" installiert?

Nein, keine installierte App. Das war jene DB, die ich vor einigen Wochen manuell für meine Nextcloud-Testinstallation angelegt habe. Alle neuen Datenbanken werden anders angelegt. Diese alte DB funktioniert jedenfalls einwandfrei. Ansprechbar über 127.0.0.1 und localhost (Unix Socket), sogar die Beschränkung nur auf lokale Verbindungen klappt hervorragend. Auch in phpMyAdmin sehe ich dazu passende Verbindungsinformationen.

Sieht wirklich wie ein Bug aus? Ich glaube die lösche ich nie…

Ich habe mir für meine finale Nextcloud Installation nun übrigens zwei eigene Wrapper in einem anderen Ordner angelegt:

#!/bin/bash
/home/etc/php/host/xyz.bin \
  -c /home/etc/php/host/xyz.ini \
  -f /httpdocs/nextcloud/occ \
  -- $@
exit $?

#!/bin/bash
/home/etc/php/host/xyz.bin \
  -c /home/etc/php/host/xyz.ini \
  -f /httpdocs/nextcloud/cron.php \
  -- $@
exit $?

• /home/etc/php/host/xyz.bin ist ein Symlink auf /usr/local/php74/bin/php.
• /home/etc/php/host/xyz.ini enthält eine angepasste PHP-Konfiguration, damit es sicherheitstechnisch den Restriktionen eines FCGI-Aufrufs entspricht.
• cron.sh lasse ich durch Plesk alle 5 Minuten als Befehl ausführen. (Pfad muss mit /httpdocs beginnen!)
• Für occ.sh habe ich mir ein Bash-Alias angelegt: alias occ="/foo/bar/occ.sh"

Sonst keine erwähnenswerten Anpassungen. Dürfte einwandfrei laufen…

Sagt mal, wieso habe ich beim Webhosting 8000 "unterschiedliche" Datenbankserver?

Die erste DB bzw. der User hatte noch localhost:3306, die zweite nun 10.35.46.74:3306.

Ist das Absicht oder ist da was kaputt?

Ein ganz tolles und großes HTTPS-Portal:

• Linkt auf HTTP-Unterseite (separate Anwendung)
• Diese enthält nur eine Javascript Weiterleitung

Ist man nun oberklug und blockiert Javascript, könnte man doch auf diese Idee kommen:

• Manueller Aufruf über HTTPS (sichererer ^^)

Doch jetzt wird es lustig:

• Gültiges Zertifikat
• Und Error 404

ABER: Die Fehlerseite sendet einen STS-Header!

Resümee: Der Link im Portal ist jetzt gänzlich hin und für den User nicht mehr erreichbar.

Wieso im Dreiteufelsnamen kommt man überhaupt auf die Idee, eine Weiterleitung ausschließlich über eine unverschlüsselte Verbindung zu realisieren? Das ist doch ein Supergau an dieser Stelle. Warum verlinkten die dann nicht gleich auf das korrekte Ziel? Und warum konfiguriert man einen HTTPS vHost, konfiguriert ihn aber kaputt? Woah! Einmal mit Profis bitte, mich wundert bei denen echt nichts mehr…

(Nein, ich werde nicht sagen, um wen oder was es geht.)

Der Traum aller Kunden, so schnell wie ihr arbeitet

Upsi! s/von/bin/

Zitat von timkoop

Still und heimlich liest man doch trotzdem die Nachrichten

Ja, leider wirklich.

Aber immerhin ist man dann DEUTLICH vorgewarnt.