Beiträge von Steini

    Nur "php" ist leider nicht eindeutig, da es ja verschiedene installierte PHP-Versionen auf dem System gibt. Die Version, die "php" auf der Konsole aufruft ist nicht zwingend die Version, die im Panel eingestellt ist. Am besten sollten hier also absolute Pfade verwendet werden. Deshalb der Einwand von vmk . "which php" liefert dir den kompletten Pfad zurück.

    In jedem Fall ist das ein Fehler, der von Netcup gefixt werden muss und dafür ist dein Ticket der richtige Weg. Hier im User-zu-User Forum können wir dir nur raten statt "php" eben "/usr/local/php71/bin/php" (entsprechend deiner gewünschten PHP-Version anpassen) zu nutzen.

    Über .jpg Bilder fürs Internet sollte man immer einmal jpegoptim drüber laufen lassen. Reduziert die Ladezeit meistens schon auf die Hälfte. Als Fotograph will man vielleicht die Optionen durchgehen, damit auch die gewollte Qualität bei rauskommt. Ansonsten reicht der Standard:

    Code
    jpegoptim -o -p --max=90 --strip-none --all-progressive *.jpg

    um alle .jpg Bilder im aktuellen Verzeichnis zu optimieren.

    => https://github.com/tjko/jpegoptim

    Ob man das unter Windows nutzen kann weiß ich allerdings nicht :/

    So, die letzten Dash Buttons die ich noch auf Lager hatte in mein Smart Home integriert. Ende des Monats schaltet Amazon die Buttons ja komplett ab. Schade eigentlich. So einfach kam man bisher nicht an billige Knöpfe die über WLAN funken. :(

    Den AWS IoT Button, der für diese Spielereien gedacht war wird es weiterhin geben: https://aws.amazon.com/iotbutton/

    Über den Preis kann man natürlich streiten, unter billigem Knopf läuft das dann nicht mehr :/8|

    kannst du mal ein Passworthash aus der alten Datenbank mit der neuen Datenbank vergleichen? Also einmal direkt nach dem importieren, einmal nach dem Passwort zurücksetzen und wieder auf das gleiche setzen.

    Oh man, ich war zu langsam mit dem Editieren, sry für den Doppelpost:

    Worauf ich mit den Hashes hinauswollte:

    Nextcloud benutzt ab PHP7.2 den argon2-hash. Das muss aber in PHP reinkompiliert sein. Ist es das nicht, fällt NC auf bcrypt zurück. Zu erkennen ist as an der 1 oder 2 am Anfang der Hashes. Es kann durchaus sein, dass deine alte PHP-Version das konnte und die Netcup PHP-Version nicht.

    Vielleicht kannst du im Webhostingpanel verschiedene PHP-Versionen ausprobieren. Es gibt da welche von Netcup kompiliert und welche aus den Paketquellen. Die Sury-Pakete sollten argon2 kompatibel sein

    kannst du mal ein Passworthash aus der alten Datenbank mit der neuen Datenbank vergleichen? Also einmal direkt nach dem importieren, einmal nach dem Passwort zurücksetzen und wieder auf das gleiche setzen. Hast du exakt die gleiche Nextcloud config file? Vermutlich musstest du einige Pfade anpassen, nicht dass dabei auch der passwordsalt oder die instanceid geändert wurde.

    Ich habe auf die Art schonmal eine Nextcloud Instanz umgezogen, das lief problemlos. Ich hatte aber auch exakt die gleiche Konfiguration des Datenbank (auch gleiche MariaDB version). Ich weiß nicht, wie das bei dir aussieht? Ich kann mir eigentlich nur ein Datenbankproblem vorstellen (oder du hast einen neuen Salt ("passwordsalt") oder Instanceid in der Konfigdatei von Nextcloud ;))

    Btw.: Beim Kopieren der Nutzerdaten darauf achten, dass sich der Timestamp nicht ändert, sonst laden alle clients die Daten erneut runter. (rsync mit -t)

    Je nach Einstellung übernimmt tar die Benutzer/Gruppen Einstellungen. Die sind dann auf dem neuen Webhosting natürlich falsch.

    Ich vermute, du benutzt sowas wie einen FTP Client dafür? Kannst du da die Berechtigungen und Benutzer setzen/sehen? Die Dateien die mit einem Punkt anfangen (z.b. .htaccess) sind unter Linux standardmäßig versteckt. Es kann sein, dass dein Programm das "übersehen" hat beim Rechteanpassen.

    Falls du per SSH auf den Server zugreifst, kannst du mal den Output von "ls -al" im Webverzeichnis posten?

    Grundsätzlich ist dein Vorhaben mit allen VPN Lösungen machbar, genau dafür ist VPN ja da: Ein virtuelles privates Netzwerk aufbauen.

    Was für dich das Beste ist, hängt von mehreren Dingen ab. Zum Beispiel: Womit hast du schon Erfahrung? Wie wichtig ist dir, dass der Client anonym bleibt / zerologs? Wie viele Clients bekommt das VPN? Bekommst du (z.B. für die Spiele) spontane neue Nutzer/Clients, die eingebaut werden müssen?

    StrongSwan kenne ich nicht, OpenVPN und Wireguard habe ich aber selbst im Einsatz (bzw. gehabt) und kann dir ein bisschen was dazu sagen. OpenVPN ist deutlich älter, etabliert, stabil und unglaublich mächtig. Wireguard dagegen ist der aktuell gehypte Aufsteiger, noch in der Testphase und zeichnet sich durch Geschwindigkeit und eine kleine Codebasis aus. Außerdem basiert es auf einer Peer-to-Peer-Architektur im Gegensatz zu allen anderen VPN Verfahren, die eine klassische Client-Server Architektur haben.

    Wireguard hat einige bestechende Vorteile: Es ist aktuell das schnellste VPN, ohne Abstriche bei der Sicherheit zu machen und (finde ich besonders Mobil toll) es ist Roamingfähig. Das Bedeutet, keinerlei Einbußen, wenn sich das Handy plötzlich zwischen WLAN, LTE oder GSM hin- und herwechselt. Ganz abgesehen davon, dass der Handshake unglaublich schnell ist. Bis OpenVPN den Server gesucht hat, ist Wireguard schon verbunden. Zudem ist die Konfiguration super simpel und daher weniger Fehleranfällig. Es funktioniert aber vom Prinzip her deutlich anders als bisherige VPN-Lösungen und verwirrt "alte Hasen" daher anfangs, wenn man sich nicht mit den Grundlagen beschäftigt (und vorher klar macht, dass es kein klassisches VPN ist und daher mit sowas wie OpenVPN nicht direkt vergleichbar ist).

    OpenVPN ist eine Server/Client Lösung, währen Wireguard eine Peer-to-Peer-Architektur hat. Natürlich kann man einen Peer als Server benutzen/definieren, aber das Aufsetzen verwirrt manchmal etwas, wenn man sich das nicht klar macht. Wireguard läuft über Public/Private Keys und ist quasi bidirektional, du bist gleichzeitig Server und Client (bzw. könntest es sein, je nach Einstellungen). Zudem unterstützt es IPv6 (ist für dich ja aber erst mal nicht wichtig).

    Es gibt aber auch gravierende Nachteile von Wireguard, die manche Einsatzzwecke verhindern. Zum Beispiel werden die IPs nicht dynamisch vergeben (weil nicht klassisch Server/Client, es ist also kein Server da, der die IPs vergeben könnte). Jeder Client muss also quasi eine eigene feste IP bekommen wodurch die sonst oft angestrebte Anonymität durch ein VPN nicht möglich ist. Auch sind dadurch natürlich die IP-Adressen und Bereiche begrenzt, man muss also Buch führen, welcher Peer welche IP hat und sollte sie nur einmal vergeben ;)

    Weiter geht Wireguard nur per UDP. Ob groß der Nachteil ist, muss jeder selbst entscheiden. Zumindest, wenn UDP-Ports geblockt werden, wie zum Beispiel in einigen Hotel-WLANs ist es unbrauchbar. Ich hatte früher einen OpenVPN-Server auf TCP Port 443 lauschen, der geht da immer durch (WLAN wäre ja unbrauchbar, wenn man Port 80/443 pauschel sperrt).

    Wenn du mit den Nachteilen leben kannst, würde ich zu Wireguard raten. Es wird als Netzwerkinterface eingerichtet und du sagst erst mal nur, zu welchen IP-Ranges der Traffic über dieses Interface gehen soll. Alles weitere regelt dann deine Firewall. Du kannst also sehr schön einstellen, welcher Traffic wohin geroutet wird, es ist super schnell (sowohl Durchsatz, als auch Verbindungsaufbau), es ist Roaming fähig, es gibt Software/Treiber für Linux, Windows, MacOS, iOS,..

    Ich hab mal ne Frage zum Pi, gibt ja einige Experten hier:

    Wie sehr in Echtzeit kann das Ding denn eigentlich Sensordaten erfassen? (Taster, Schalter, Drehpotis, Temperaturen usw.) Passiert das alles ohne Verzögerung, wenn ich etwa 10-20 Sensoren erfassen und gleichzeitig etwa 5-10 Schrittmotoren aktiv betreiben möchte. Dazu eben noch ne Anwendung, die das alles verwaltet und obendrauf noch das UI sowie ne umfassende Webschnittstelle.

    Packt der Pi das, nur mal so aus Interesse?

    (GPIO Pins würden über I2C Multiplexer und I2C Expander gespeist.)

    Von Haus aus macht der PI kein Echtzeit, da brauchst du Patches für. Brauchst du aber vermutlich garnicht. Echtzeit bedeutet an sich ja nur, dass eine bestimmte Operation nach einer festgelegten Zeit garantiert beendet ist.

    Das bedeutet für dich, dass du erst mal festlegen musst, was deine Echtzeitanforderungen sind. WIe oft pro Sekunde müssen die Sensoren für deinen Anwendungsfall ausgelesen werden? Am Ende kommt es natürlich auf die Programmierung an. Man ist auch vor 50 Jahren mit einem Bruchteil der Rechenleistung auf dem Mond gelandet. Aber da wurde natürlich kein Java oder Wordpress oder sonstige Performancekiller eingesetzt ...

    Grundsätzlich sehe ich da kein Problem. Der i2c bus macht selbst in der langsamsten Version 100kBit/s[1], was für 20 Sensoren ausreichen sollte, je nachdem wieviel Informationen du davon bekommst.

    Insgesamt klingt das Projekt für mich eher wie ein Arduino-Projekt. Der Mikrokontroller kann auch Echtzeit.

    [1] Auch 400kbit/s sollten kein Problem sein https://www.raspberrypi.org/documentation/…Peripherals.pdf

    Außer paar älteren CMS läuft auf dem Server nichts.

    Wenn du den Server nur für ein Webhosting benutzt, willst du ein Webhosting Paket buchen, da ist das alles für dich gemacht worden.

    Die logs zeigen deinen Apache und default host, nicht deinen vHost. Der hat wohl eigene logs.

    Die Fehlermeldung zeigt, dass das Rootverzeichnis deines vhosts für den Webservernutzer nicht lesbar ist.

    Grundsätzlich geht dein Setup, ich kann zumindest dein Froxlor aufrufen. Das Problem liegt also in der vhost config, in der du die Konfigurationsänderung, die H6G in Post 7 gepostet hat, durchführen musst.

    Die Änderung kannst du vermutlich in Froxlor machen (kenne Froxlor nicht, kann nichts dazu sagen) oder direkt in den Dateien unter /etc/apache2/sites-enabled/ vermutlich werden direkte Änderungen später aber wieder von Froxlor überschrieben

    Laut httpd.conf Begleittext ist das fehlende anführende / korrekt - Pfade mit fehlendem anführenden / werden immer durch den ServerRoot ergänzt, welcher /usr ist.

    Mag sein, dass es funktioniert. Ich finde es aber verwirrend und würde es nicht nutzen. Absolute Pfade sind in dem Fall deutlich weniger Fehleranfällig.

    Kann sein, dass dein LE Prozess keine Schreibrechte hat auf: /private/etc/apache2/httpd-le-ssl.conf ?

    Hat jemand hier ShareLatex im Einsatz und kann mir sagen, wieviel Ressourcen man in etwa einplanen sollte?

    Würde nur von mir genutzt, also einem User gleichzeitig.

    Ich habe ein Sharelatex im Einsatz, das von unserer Arbeitsgruppe verwendet wird. Last also auch überschaubar, nur zu manchen Zeiten sind vielleicht mal 2-3 Leute gleichzeitig drauf. Sharelatex an sich ist überschaubar, man muss aber bedenken, dass das auch Redis und Mongo mitbringt. Es ist aber schon auf relativ schlechter Hardware installierbar. Ob es nutzbar ist, probierst du am besten aus. Es wird bei uns halt relativ oft kompiliert, was für jeden Nutzer einzeln gemacht werden muss. Das braucht dann CPU Leistung. Wenn also mehrere Leute gleichzeitig dran arbeiten und das Dokument mehr hat als einfach zwei Seiten Text, dann kann das schon Zäh werden. Ich bin von einem RS2000 G7 auf einen G8 umgestiegen und habe schon deutliche Performancegewinne bemerkt (läuft aber auch noch eine Menge anderer Kram drauf). Das betrifft aber hauptsächlich das erste Öffnen bzw kompilieren. Während des Schreibens braucht es dann kaum Leistung.

    Es als Einzelnutzer zu benutzen macht aber imho kaum Sinn ;)

    Dann noch eine Antwort auf eine Frage, die du garnicht gestellt hast: ;)

    Spoiler anzeigen

    In der Docker Version wird noch ein altes Texlive mitgeliefert. Es gibt zwar Anleitungen zum upgraden, ich fand es aber aus diversen Gründen besser, das "lokale" Texlive zu verwenden (war sowieso schon installiert):

    In der docker-compose.yml ergänzen:

    volumes:

    - /var/lib/sharelatex/data:/var/lib/sharelatex

    - /var/run/docker.sock:/var/run/docker.sock

    - /usr/local/texlive:/usr/local/texlive

    Wenn Texlive in /usr/local/texlive installiert ist. (https://www.tug.org/texlive/quickinstall.html)

    - Wie würdet ihr beim PHP-Upgrade vorgehen? Mein pragmatischer Ansatz: PHP-Version hochsetzen, Website durchtesten - wenn etwas nicht klappt, notfalls erstmal downgraden. Funktioniert das? Würdet ihr es so oder anders angehen?

    Prinzipiell funktioniert das. Es kommt immer drauf an, wie wichtig dir die Erreichbarkeit deiner Seite ist und was da drauf läuft. Wenn es ein fertiges Paket ist, dann das upgraden und nachschauen ob die Kompatibilität mit 7.2/7.3 gegeben ist.

    Die vorsichtige Version wäre, das ganze mal woanders zu testen. Z.b. eine Subdomain erstellen, den Webinhalt kopieren und auf der Subdomain alles testen. Wenn es nicht so wichtig ist, einfach ausprobieren. Alle aktuellen Webprojekte laufen problemlos (bzw. besser) mit 7.2+

    Dein VPN client bekommt eine IP aus dem 10.1.1.0 Subnetz?

    Deine Serveranwendung lauscht auf dem Subnetz? Überprüfen mit netstat -tulpen

    Die Freigabe in der Firewall ist in der richtigen Reihenfolge und wird nicht von dem alles sperren überschrieben?

    Mit ufw kann ich dir leider nicht weiterhelfen. Vielleicht erst mal abschalten und ohne testen? Die ist ja eigentlich eh nur dafür da, dass eventuelle rootkits von außen nicht erreichbar sind. Oder für was soll das verwendet werden? Wenn einzelne Dienste nicht auf dem öffentlichen Interface erreichbar sein sollen, dann lässt man die nur auf dem gewünschten Interface lauschen.