Kann sein, dass die Module deflate/expires nicht aktiviert sind? vServer oder Webhosting?
Ob die Module geladen sind, sollte dir die phpinfo sagen:
PHP
<?php
phpinfo();
?>Beiträge von Steini
-
-
Weil ich mit den user root zuerst den public key erstellen muss. Oder wie sonst?
Sagmal, liest du die Beiträge überhaupt?
Sorry, ich bin raus.
-
Sobald ich nach dem Loggin (in SSH) brandt eingebe und dann nach der Key-passphrase gefragt werde und die dann eingebe funktioniert sie nicht.
Hast du da vllt. eine Idee?
Ich habe so den Eindruck, du willst gar keine Hilfe. Du postest keine Logeinträge, obwohl oben sehr gut erklärt wurde, wie du die sowohl vom Server, als auch von Putty bekommst. Du erzählst nicht, was du gemacht hast und beantwortest Rückfragen nicht. "Funktioniert nicht" ist 'keine' Fehlermeldung.
Wenn du willst, dass dir das jemand für dich macht, musst du dafür bezahlen. Hier gibts nur Hilfe zur Selbsthilfe.
-
Ist doch Wurscht - man hat doch bei netcup mehr als ein Paket gebucht!? Dann registriert man halt über dieses Paket die Domains und macht das Webhosting auf einer anderen IP. DNS-Records kannst Du doch frei festlegen - siehe oben.
Wenn es dir nur um die Domains geht und du den Webspace nicht nutzen willst, hast du leider die Aktion zur Deutschen Einheit verpasst.
Da gab es Domains für 0,14€/Monat, also 25 für 3,5€/Monat. Wenn du so viele Domains brauchst, bist du mit dem Resellerzugang evtl auch günstiger dran.
Aber stimmt natürlich, in Verbindung mit dem Speicherplatz, den man ja auch als Backup benutzen kann, ein tolles Angebot
-
Ich habe es mal ausprobiert und hatte leider keinen Erfolg.
Mit dieser ausführlichen Fehlerbeschreibung kann ich leider nichts anfangen. Du schreibst, du hast den Rootserver neu aufgesetzt. Was hast du dann gemacht und was funktioniert nicht? Bist du nach einer Anleitung vorgegangen (welcher)?
1) In Putty ein Schlüsselpaar erzeugen (siehe Link oben)
2) Den Pubkey in deine authorized_keys file schreiben
3) In der sshd_config: Public key aktivieren, Passwort Authentifizierung ausstellen
4) SSHD daemon neu starten (service ssh restart)
Wieso habe ich es unter Debian 8 in unter 10Minuten (Bin Anfänger und habe ca. 10% Ahnung) geschafft die Public Key Authentifizierung zu erstellen (Die auch funktioniert hat) und bei Debian 9 nicht, das kann doch nicht war sein
Debian 8 und 9 unterscheiden sich da nicht. Sieht nach klassischem PEBCAC aus
Was ich gerade noch sehe: Du willst einen anderen Nutzer verwenden (brandt?). Dann muss der Pubkey natürlich auch in die authorized keys des Nutzers brandt (/home/brandt/.ssh) und nicht in /root/.ssh. Den Nutzer muss es geben und bei Putty musst du diesen einstellen. Am besten stellst du erst mal den SSH auf den Nutzer "brandt" um (Nutzer anlegen, Root login im sshd deaktivieren). Wenn das funktioniert dann den Key-Zugang einrichten.
-
Na, dann stimmt wohl der Key, den Putty an den Server schickt nicht
Wie hast du ihn denn erstellt? Du bist mit den Grundlegen von asymmetrischen Verschlüsselungsverfahren vertraut? => https://web-development.github.io/git/public-private-key/
In Kürze: Es gibt zwei Schlüssel. Was der eine verschlüsselt, kann der andere entschlüsseln und andersrum. Einer davon wird als "privater Schlüssel" definiert, der bleibt bei dir und sollte geheim gehalten werden. Der zweite ist der "öffentliche Schlüssel" (pub/public). Den gibt man dem Kommunikationspartner. Wenn jetzt mit deinem privaten Schlüssel etwas verschlüsselt wird, kann der öffentliche Schlüssel das entschlüsseln, und weiß, dass die Botschaft von dir kam, weil nur du das machen konntest (vorausgesetzt, niemand anderes hat deinen privaten Schlüssel).
Wie wird das jetzt bei SSH verwendet?
Du erstellst auf deinem Rechner zu Hause ein Schlüsselpaar. Den öffentlichen Schlüssel kopierst du auf den Server in die "authorized_keys", also die Datei für vertrauenswürdige Schlüssel.
Wenn du jetzt eine Verbindung mit Putty aufbaust, dann verschlüsselt Putty mit deinem privaten Schlüssel eine Botschaft und der Server schaut, ob er das mit einem der vertrauenswürdigen Schlüssel entschlüsseln kann. Geht das, lässt er dich rein.
Wenn ich deinen Post oben richtig interpretiere hast du schon falsch rum angefangen, als du auf dem Server die Schlüssel erzeugt hast und nicht auf dem Client. "Theoretisch" ginge das auch, wenn du den erzeugten öffentlichen Schlüssel (.pub) zu den authorized hinzufügst, und den privaten auf deinen Rechner in Putty lädst. Praktisch wäre das dämlich, weil der Sinn von asymetrischer Verschlüsselung ist, dass der private Schlüssel gerade 'nicht' über das Internet transferiert wird.
Ausführliche Anleitung:
-
kann ich den eintrag löschen, damit meine page wendlich wieder erreichbar ist? bzw. kann ich die ganze htaccess löschen? hatte die angelegt um bei wordpress das upload-limit zu erhöhen. stellte sich raus, das war nicht nötig...
Wenn du nicht weißt, was es tut, solltest du es vielleicht nicht einsetzen.
Das Problem sind die rewrite rules. Die Lösung dafür steht weiter oben im Thread. Du kannst natürlich auch die .htaccess löschen, aber das kann auch dazu führen, dass dein Wordpress nicht mehr geht. https://codex.wordpress.org/htaccess
Ich kenne weder dein Setup, noch deine Anforderungen (noch setze ich Wordpress ein) und kann deshalb nicht abschätzen, was das bei dir für Nebenwirkungen haben kann. Ich werde dir deshalb sicher nicht sagen, dass du Dinge, die du selbst nicht verstanden hast, einfach löschen kannst.
Ich denke immer noch, dass Netcup das durch einen entsprechenden Eintrag in der vhost Datei lösen sollte, wenn man als Hoster schon LetsEncrypt anbietet. Im Wiki steht auch nichts über das htaccess Problem, da lässt man Kunden bewusst ins Messer laufen.
-
ISPConfig 3 dürfte auch ganz ok sein. Hat das wer vielleicht im Einsatz?
Ich benutze das. Verwaltungstools gibts aber halt wie Sand am Meer. Ist letztendlich Geschmacksache und hängt davon ab, wie viel Komfort / Einstellungs- / Bastelmöglichkeiten man noch haben will. "Das Beste" gibt es in dem Bereich nicht.
-
aber ich habe keinerlei rewrite-rules in meiner htaccess.
Dann schau dir doch mal die ersten 9 Zeilen deiner .htaccess Datei nochmal genau an
Mal so nebenbei.
Eigentlich sollte der Validierungsprozess doch dem 301-Header zu https folgen können. Das mache ich zumindest auf meinen nginx-servern so. Auf port 80 überall "return 301 https://$server_name$request_uri;" und dann sämtliche Konfiguration auf port 443.
Funktioniert bisher Problemlos, solange der Host mit self-signed cert vorkonfiguriert ist. Mich würde es stark wundern, wenn das mit Apache nicht ginge.
Ja, das wundert mich auch ein bisschen. Es kommt wohl drauf an, wie man die Zertifikate erneuert. Der certbot geht nur auf Port 80:
HTTP-01 is defined by the ACME standard to require HTTP on port 80 (never HTTPS on port 443) for reasons that have to do with the defaults in some shared hosting environments, where the previously-proposed HTTPS-01 authentication method would have allowed some shared hosting users to obtain certificates for other users' domains.
Das Problem könnte Netcup aber eigentlich durch eine globale EInstellung in den vhost Datei lösen. Z.B. mit der Lösung von hier: https://community.letsencrypt.…ng-http-to-https/16984/14
-
Hast du denn sonst was in der .htaccess? Kannst du den Ordner ".well-known/acme-challenge" auf dem Server anlegen, eine Datei reinschreiben und nur mit "http" aufrufen?
Gibt es beim Webhosting eigentlich Fehlermeldungen bei fehlgeschlagenen Erneuerungsversuchen?
-
Bisher lautete meine komplette REWRITERULE folgendermaßen:
Apache ConfigurationRewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Die .htaccess wird von oben nach unten abgearbeitet. Die erste Zeile aktiviert mod_rewrite. Dann kommen die conditions (Bedingungen) von oben nach unten. Die angegebene Zeile (RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge) sagt, dass die aufgerufene URL 'nicht' (das !) "\.well-known/acme-challenge" sein soll. Ist das so, ist die Bedingung nicht erfüllt und die RewriteRule (Regel) wird nicht ausgeführt. Ansonsten wird die nächste Zeile überprüft. Trifft sie zu (in deinem Fall: aufruf nicht per HTTPS), wird die Regel angewendet (bei dir: leite mit Code 301 weiter auf https://Hostname/Pfad).
In kurz: Du musst die Ausnahme als erstes nach der "RewriteEngine On" schreiben:
Apache ConfigurationRewriteEngine On RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge RewriteCond %{HTTPS} !=on [NC] RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Aber eigentlich hätte dir Google die Antwort schneller geliefert, als ich den Beitrag geschrieben habe
-
Dann musst Du entsprechend für das Unterverzeichnis /.well-known/acme-challenge/ eine Ausnahme in Deine Umleitungen einbauen.
Völlig korrekt. Vielleicht etwas Hintergrund:
Wenn man ein Zertifikat bei LetsEncrypt beantragt (macht Netcup für dich, wenn du die Option gesetzt hast), muss LetsEncrypt überprüfen, ob die Domain wirklich dir gehört. Dafür gibt es das ACME Protokoll. Vereinfacht gesagt: Dein Server erstellt ein Zertifikat und verschlüsselt mit dem private Key eine Datei. LetsEncrypt läd die Datei von deinem Webserver, kann das mit dem public Key entschlüsseln und weiß dann, dass der Zertifikatsinhaber auch Zugriff auf die Domain hat. Dann wird das Zertifikat signiert und als vertrauenswürdig eingestuft.
Mehr Infos hier: https://letsencrypt.org/how-it-works/
Die Datei, die heruntergeladen wird, wird in ".well-known/acme-challenge" abgelegt. Damit das funktioniert ist im Apache Server eine globale Rewrite rule hinterlegt, damit LetsEncrypt, wenn es auf den Ordner zugreift die richtigen Daten zur Validierung bekommt. Wenn du diese Rewrite Rule durch eine eigene überschreibst, funktioniert die Validierung nicht mehr. Du musst den Ordner also in deinen eigenen Regeln als Ausnahme hinzufügen.
z.B. so:
Apache ConfigurationRewriteEngine On RewriteCond %{REQUEST_URI} !\.well-known/acme-challenge RewriteCond ... -
Zwei Möglichkeiten fallen mir ein:
1) Du hast deinen Browser geupdated (oder er sich selbst) und er mag jetzt keine selbstsignierten Zertifikate mehr.
2) Dein Zertifikat ist schlichtweg abgelaufen. Alle Zertifikate haben ein solches Ablaufdatum. Die kostenlosen meistens ein recht kurzes und müssen deshalb regelmäßig erneuert werden.
Ohne weitere Informationen kann man dir aber nicht weiterhelfen.
LG,
Johannes
-
ich habe eine sehr einfache, statische Seite erstellt (Jekyll) und daher Apache und PHP deaktiviert. Leider kann man scheinbar nginx kaum konfigurieren und biete in der Standard-Konfiguration kein gzip und caching policies. Gibt es eine Möglichkeit dies zu ändern? nginx.conf-Dateien kann ich über FTP/SSH nicht finden
Ich habe kein Webhosting Paket, kann es deshalb nicht prüfen. Aber wenn du Einstellungen haben willst, die das Webinterface nicht bietet, musst du dich an den Support wenden. In den meisten fällen wird das gemacht. (was du willst ist ja mit wenigen Zeilen erledigt)
ZitatBliebe als Ausweg dann nur, doch wieder auf Apache zu setzen, dort gzip und caching zu konfigurieren und nginx als Proxy davor setzen, sodass es dies übernimmt? Geht das? Oder ASCII-Dateien nicht mit nginx ausliefern und nur für binaries nutzen?
Wenn du den Apache mit gzip und caching aktiviert hast, brauchst du nginx ja nicht mehr. Der Apache kann auch statische Seiten ausgeben. Wenn PHP nicht aktiviert ist, kann er auch fast nichts anderes. Es geht da nur um Performance, aber die Frage ist, ob du das überhaupt brauchst? nginx beantwortet bei statischen Seiten etwa doppelt so viele Anfragen wie Apache pro Zeiteinheit. Was meistens nicht gemessen wird ist die Zeit, bis 1 Nutzer die erste Antwort bekommt. Hier sollten beide in etwa gleich sein. Wobei das natürlich immer von der Konfiguration abhängt. Ich vermute, dass Apache mit gzip und caching schneller ist als nginx ohne.
Bei dynamischen Inhalten (php-fpm) sind sowieso beide gleich performant, aber das hast du ja nicht
-
Lange stand es auf der ToDo-Liste, jetzt habe ich es endlich umgesetzt: Ansage der aktuellen Temperatur-/Luftfeuchtigkeitswerte am Telefon
Das geht mit Asterisk, AEL und Makros erstaunlich einfach. Der ruft einfach die Werte vom Munin-Master (mittels cURL über HTTPS; dort läuft ein PHP-Script) ab, ein wenig Validierung, Komma aufteilen und den Rest macht SayNumber() – sogar auf Deutsch. Vorhin habe ich noch schnell ein paar Texte für Raumbezeichnungen und allgemeine Erklärungen aufgenommen, die werden dazwischen einfach abgespielt.
Sehr nette Spielerei. Kommt bei mir auch mal auf die ToDo-Liste
Bisher hats nur für einen Telegram-Bot gereicht, der kann aber auch gleich den Temperaturverlauf als Bild verschicken. Das geht am Telefon halt schwer
-
Ein Serverumzug steht bei mir demnächst auch an (eigentlich wollte ich auf die vServer G8 warten ..).
Bekomme ich bei Clonezilla nicht Probleme, wenn die (simulierte?) Hardware-Architektur nicht stimmt?
-
SASL ist ja kein Dienst, der nach aussen "lauscht". Das ist ein Authentifizierungsframework, das von verschiedenen Diensten benutzt wird (SMTP/IMAP/POP/etc...)
fail2ban benutzt IPtables um anfragen zu blockieren. Bei IPtables gibt man den Port an, der gesperrt werden soll. In der fail2ban wird das über den "port =" gemacht. Welche Regel ausgeführt wird, wenn der fail2ban Algorithmus zuschlägt siehst du in deiner config unter "action ="
Die Files dazu sollten in
Code/etc/fail2ban/action.d/liegen. Meistens ist hier noch iptables-multiport eingestellt, was bedeutet, dass nur die angegebenen Ports gesperrt werden.
Angaben kannst du z.B. so machen:
port = 80 (einzelner Port)
port = 80,443 (Verschiedene Ports mit Kommata)
port = 8080:8090 (Port Range mit Doppelpunkt)
port = 80, 8080:8090 (Mischung aus beidem)Wenn bei deiner fail2ban-sasl Regel also der Port 4567 angegeben ist, dann wird der Port für die entsprechende IP gesperrt, wenn die Regel zuschlägt. Wenn der "angreifer" aber auf Port 5678 mit deinem Mailserver redet, der eine SASL abfrage macht, die fehlschlägt, wird er zwar nochmal für Port 4567 gesperrt, aber das juckt ihn ja nicht. Du musst also deine Ports im fail2ban an deine Serverkonfiguration anpassen (Wird z.B. bei SSH gerne vergessen, wenn die Nutzer den SSH Port ändern, aber die Regel nicht anpassen.)
Wenn du willst, dass eine IP für alle ports gesperrt wird, musst du iptables-allports wählen (wenn vorhanden im action.d Verzeichnis). (Vorsicht, damit sperrt man sich ganz gerne mal selbst aus)
LG,
Johannes
-
Wenn du SMTP login nicht brauchst, solltest du den Dienst stoppen. Nur nach außen Anbieten, was auch gebraucht wird.
Ohne dein Setup zu kennen:
Bei Postfix lässt du nur lokale Sender zu mit:
Codemynetworks = 127.0.0.0/8, [::1]/128 -
Irgendein skript braucht zu lange zum ausführen. Welches das ist, oder ob es an der php-fpm Version liegt ist schwer zu sagen. Da Wordpress aber von relativ vielen Leuten eingesetzt wird, sollte da was im Internet zu finden sein, wenn es öfters vorkommt. Ausser deinen anderen Posts gibt es da aber tatsächlich wenig. Ich würde also den Fehler tatsächlich bei einem von deinen Modulen vermuten, die sonst selten benutzt werden. Oder du überlastest den Tarif? Das sollte der Support aber ja bemerken.
Den "Tipp" fand ich besonders gut. "Wenn das Skript nach 90 Sekunden noch nicht fertig ist, lass es doch 120 laufen" ...
-
Habe das nur mit VDR am laufen. TVHeadend habe ich mir am Anfang angesehen. Fands zuerst sexy wegen des Webinterfaces. Da hier aber auch noch eine Schüssel "rumsteht", habe ich zum VDR gewechselt und es nie bereut.
Geht es denn, wenn du den Stream einfach per VLC aufrufst? Dann kommt zumindest bei deinem PC alles gut an
