Hay,
dann mach doch eine .htaccess (bzw. ergänze sie, falls vorhanden) in das httpdocs-Stammverzeichnis mit dem Inhalt:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^94\.16\.122\.171$
RewriteRule ^(.*)$ https://www.setoy.eu/$1 [L,R=301]Das sollte dann alles sein.
CU, Peter
Weil es mich nicht einschlafen ließ... 10.8.0.0/24 ist doch richtig.
-s 10.8.0.0/24 ?
Und sicher, dass es diese Netz ist? Ist es in der Standardkonfig nicht 10.0.8.0/24 das Netz?
Egal wie, ich bin ins Bett lol.
Hay,
Ist ein bißchen spät, kann sein, dass ich selbst einen Denkfehler mache 
Das VPN / tun-Interface hat doch eine eigene IP-Adresse bzw. ein Netzwerk, je nachdem wie Du das konfiguriert hast (beide Seiten vom VPN!). Das musst Du für die Regel nehmen - localhost macht zwar nichts kaputt, aber auch nicht fürs VPN erreichbar.
CU, Peter
Hay,
jetzt nur interessehalber... und ein mv logfile /dev/null? Ich möchte es jetzt nicht ausprobieren nur des Spaßes wegen 
Kann mir aber vorstellen, dass das auch nicht die Bindung an die Datei bzw. filenode löst.
CU, Peter
Hay,
94.16.122.586
von der IP Adresse überhaupt nicht, weil es solche IP-Adressen nur im Fernsehen gibt.
Allerdings verstehe ich selbst bei valider ipv4-Adresse die Frage nicht zu 100%.
Ist die IP-Adresse die von Deinem Server?
Wenn Du willst, dass man die Domain aufruft und dann auf dem Server mit der IP-Adresse landet, dann musst Du nur einen A-Record im CCP - Domain - Lupe neben Domain klicken - DNS zu setzen.
Wenn unter der IP-Adresse ein Webserver normal antwortet und Du möchtest dann, dass die Domain aufgerufen wird, dann sollte das in der .htaccess (mod_rewrite vorausgesetzt) die Aufgabe erfüllen:
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^12\.34\.56\.789$
RewriteRule ^(.*)$ https://www.domainname.com/$1 [L,R=301](bzw. http: in der letzten Zeile wenn Du kein Cert installierst hat)
CU, Peter
Hay,
Nutzt du wenigstens ein SSL-Zertifikat für deinen vHost?
das ist ein anderer Angriffsvektor. Es ist ja keine "geheime" Subdomain, sondern ein vhost ohne DNS-Eintrag (wenn ich es richtig verstanden habe). Insofern kann da auch kein Letsencrypt-Zertifikat erstellt werden, da der Server nicht verifiziert werden kann...
CU, Peter
Hay,
Liefert bbclone auf dem netcup Server installiert lesbare Namen?
Davon gehe ich aus, denn die Lösung ist trivial (siehe unten). Und das machen übrigens die meisten Statistikprogramme wie auch Matomo (ehem. Piwik) genauso, dazu braucht es kein bbclone (das ich übrigens nicht kenne).
Wenn man jeden Webseiten-Aufruf sowieso mit einem PHP-Script beantwortet, kann man das noch einfacher realisieren.
Einfach am Anfang des Scripts folgenden Code einbinden... und man hat in $host den Hostnamen, den man möchte und kann mit diesem machen, was man möchte. Das macht insofern weniger Streß, da man den DNS-Aufruf auf den einzelnen Seitenaufruf beschränken kann (wenn man dann die ip-Adresse noch cached und bei einem Reload oder dem Aufruf einer anderen Seite überprüft, ob es noch dieselbe ist (oder in der Session mitführt), dann beschränkt man den DNS-Stress auf den einzelnen Visit.
/* IP bestimmen */
$ip = getenv("REMOTE_ADDR");
/* IP auflösen und Host bestimmen */
$host = gethostbyaddr($ip);
Läuft bei mir übrigens genau so schon seit 2000 im Beispielscript: http://www.peterkleemann.de/scripts/myip.php.
Ein andere Umweg wäre darüber, eine Zählpixel auf der Seite zu installieren, der eigentlich ein PHP-Aufruf ist und ein Bild in der Größe 1x1 Pixel generiert (GD lib / http://php.net/manual/de/book.image.php) ist und der im Hintergrund und unsichtbar die Sache mit der IP-Adresse erledigt. Das geht dann auch z.B. aus Wordpress heraus, da Wordpress ohne spezielles Plugin ein recht "krudes" Sessionmanagement hat.
CU, Peter
Hay,
das würde ich nicht empfehlen, weil der Apache sonst für jeden Logfile Eintrag einen DNS-Lookup machen müsste. Das wird dann problematisch, wenn der DNS langsam antwortet - und das muss nicht unbedingt Schuld vom netcup-DNS sein... irgendwann kommt der Server in einen lock, weil er vor lauter wartenden DNS-Anfragen kein Logfile mehr schreiben kann. Darum gibt es bei den wichtigen Befehlen wie netstat den -n Paramenter.
Mach doch mal spaßeshalber auf der Shell einen "netstat -a" (mit Namensauflösung) und nimm die Stoppuhr, bis er fertig ist und dann mal einen "netstat -na" (ohne Namensauflösung) mit Stoppuhr. Du wirst ganz schnell etwas feststellen ... 
Abgesehen davon... wenn man es genau nimmt, dürftest Du genau diese Information mit der IP-Adresse nicht nutzen (neue DSGVO), es ist wahrscheinlich, dass die Logfiles anonymisert werden müssen...
Aber nach meinem Gemeckere jetzt die Info, die wirklich willst (aber mit noch mehr Gemecker): https://www.heise.de/ix/artikel/Schnellloeser-505888.html mit einer Lösungsmöglichkeit.
CU, Peter
Hay,
was habe ich schon "geheime" Seiten gefunden... nur ein Szenario, was passieren kann... Du installierst ein Flash Update (oder Acrobat Reader) und Du vergisst, die "optionalen Angebote" wegzuklicken. Angenommen, da ist die google Toolbar dabei und die wird installiert. Du surfst Deine interne Seite an und die Toolbar (weil sie ja jedem das Leben leichter macht), bewertet diese "interne" Seite als "relevant", weil Du vorher eine andere ähnliche Seite angesurft bist oder weil Du auf einen Link dieser internen Seite klicht... und nimmt den Link und die referenzierende Seite in den search index auf. Kann passieren.
Jemand sucht nach einer Information, die Du aus dem Internet hast und findet, dass Du eine Link dahin plaziert hast (dazu gibt es Abfragemöglichkeiten). Den kann er nicht aufrufen, aber meist genügt demjenigen schon die Info, "dass da was ist" um den Trick zu entschlüsseln.
Oder alternativ - der Serverbetreiber des von Dir besuchten Links macht eine Auswertung des referrers und sieht, woher Du kommst. Da nützt es wenig, wenn du "do not track" aktiviert hast, im Logfile taucht das auf, außer Du hast das Announcement für den Referrer komplett abgeklemmt, Du surfst über einen Anonymisierungsprox o.ä.
D.h. selbst bei Obfuscation muss man noch viel, viel mehr beachten als bloß den vhost nicht auffindbar zu machen.
Also .htaccess und .htpasswd, selbst eine basic authentification reicht, sofern Du nicht auch noch Angst vor man-in-the-middle-Attacken hast.
CU, Peter.
Hay,
Logdateien kommen auch ohne logrotate neu. Logrotate macht ja auch nichts anderes, als die Dateien umzubenennen und ggf. zu packen, logrotate macht da keine neue Datei hin - aber der Dienst, der das Logfile schreibt, spätestens nachdem er nach dem Logrotate neu gestartet wird und feststellt, dass er keine Logdatei mehr hat.
Also genügt es ggf. den Dienst neu zu starten, also Apache. Wenn danach nichts kommt, ist wirklich etwas entweder falsch eingestellt oder kaputt.
CU, Peter
Hay,
ch habe momentan einen Webhoster mit 4 Webseiten am laufen, der aber langsam an seine Grenzen kommt.
Bitte definiere "an seine Grenzen kommt" - Welche Grenzen sind das, woran merkst Du das?
Das wichtigste Kriterium ist aber, ob Du es Dir zutraust, den Server wirklich sicher zu machen - Plesk alleine reicht da nicht aus und selbst da lauern Fallen.
CU, Peter
Hay,
ich glaube ich ahne, wo das Mißverständnis ist...
ip route add default via [Neue IP]
Du änderst hier Dein Default Gateway auf Deine neue IP-Adresse? Also Deinen Server himself? Default Gateway ist IMMER die IP-Adresse des Routers, also des "anderen Endes" - des nächsten Hops im Netzwerk, wohin alle Adressen geroutet werden, für die Du keine statische Route gesetzt hast. Sofern die IP-Adresse für ens3:1 im selben Netzwerksegement (255.255.252.0) liegt wie die ens3, musst Du
a) das bisherige Netzwerk der ens3 durch das neue Interface routen
b) das Default Gateway durch das neue Interface routen
Das Default Gateway bleibt aber jeweils die IP, die Du bereits jetzt als Default Gateway hast.
Wenn die neue IP nicht in diesem Netzwerksegment liegt (glaube ich aber nicht), müsstest Du eigentlich eine zu diesem Netzwerksegment passende Maske und ein anderes Default Gateway erhalten haben - dann stimmt z.B. schon die Netzwerkmaske in ../interfaces zu ens3:1 nicht.
CU, Peter
Hay,
Du musst die Kommandos als Superuser / root ausführen:
ifup ens3:1->
sudo ifup ens3:1CU, Peter
Hay,
Hat da jemand eine Idee wie ich das Problem loesen koennte? Vielen Dank!
Eigentlich klassische "ich habe sudo vergessen"-Fehlermeldungen ...?
CU, Peter
Hay,
ja.
Du kannst sogar weitestgehend die Funktion testen - indem Du auf deinem (unterstellt) Windows-Desktop die c:\windows\system32\drivers\etc\hosts änderst und domain und ip dort einträgst, dann wird für die domain kein lookup zum Nameserver gemacht.
also
123.456.789.012 http://www.meinedomain.de
Nach Umzug aber nocht vergessen, das wieder rauszuholen.
CU, Peter
Hay,
1) hast Du das ftp-Backup mit demselben User ausgeführt wie das Test-Kommando? Wenn Du z.B. einen cron-Job ausführst, kann der andere Rechte haben als ein (ev. sogar root-) Konsolennutzer.
--oder--
2) das Testkommando legt ein Verzeichnis und eine Datei an und löscht sie wieder. Das heißt zumindest, dass der ftp-Nutzer Schreibrechte im Verzeichnis hat - das muss aber nicht bedeuten, dass er das Recht hat, das "partial file" (oder was durch den Backup-Prozess erzeugte) File zu löschen - also der erzeugende Prozess (der Backup-Datei) hat exklusivere Rechte als der ftp-User.
CU, Peter
Hay,
ich schreib Dir mal eine E-Mail... ist meine andere denn angekommen? Bin etwas unsicher, da kein Feedback 
CU, Peter
Hay,
noch mit btrfs/zfs
OffTopic-Hinweis: Von btrfs war ich anfangs ziemlich begeistert - aber seit dem ich mir unmerklich zweimal wichtige Filesysteme von Servern unreparierbar zerschossen habe, kommt mir das nicht mehr in die Tüte. Sind zwar jetzt 1,5 Jahre vergangen, aber ... einmal verbrannt, nie mehr wieder. ZFS ist wesentlich stabiler aus meiner Sicht heraus.
CU, Peter
Hay,
Könntest du denn im heimischen WLAN nur mal schauen, ob sich das ganze von alleine aktiviert.
das nützt nichts, da ich KEINE Mobiltelefonie auf dem Gerät habe. Ich habe IMMER eine VoIP-Verbingung über das von Android automatisch hergestellte Netz zu meiner Telefonanlage und sonst nichts.
CU, Peter