des is kein Wörterbuch
dot Mainzelmännchen gibts eben auch net
Beiträge von Paul
-
-
Der Vollständigkeit halber verlinke ich auch nochmal auf das entsprechende RFC: https://tools.ietf.org/html/rfc2487
Bin auch erst dank der guten Postfix Dokumentation drauf gekommen.Gibt auch einige Fluggesellschaften, die ihre Boardkarten über etwas veraltete Mailserver versendet. Da hatte ich mal in den Ferien unschöne Erfahrungen gemacht, weil ich mal für meine Mailserver die gleichen TLS Sicherheitseinstellungen genutzt hatte wie für meine Webserver. Seit dem bin ich da vorsichtig
-
Also bei den Mailservern wäre ich mit den SSL Ciphers und Protokollen nicht so streng. Es gibt einfach so viele alte Mailserver da draußen. Lieber eine TLSv1 Verbindung zugelassen als komplett unverschlüsselt kommuniziert (was laut RFC nicht abgeschaltet werden darf!).
-
Betreibt hier zufällig jemand eine Nextcloud hinter einem nginx reverse Proxy und mag mir mal seine nginx Config (also des rev. Proxys) zum Vergleichen zeigen?
Ich habe irgendwie das Gefühl, dass ich das aktuell nicht so ganz richtig mache...
https://docs.nextcloud.com/ser…l/installation/nginx.html
Das sollte eigentlich alles beantworten
-
Wenn du einen Netcup Mailservice möchtest, müsstest du aber auch zunächst mal einen buchen.Bei einem reinen Server ist der natürlich so erstmal nicht mit dabei, es sei denn, du betreibst ihn selbst.
Als mögliche Optionen bieten sich an:
* https://www.netcup.de/groupware/
* https://www.netcup.de/hosting/ -
Was empfiehlt sich denn eigentlich am ehesten als Reverse Proxy?
Auskennen tu ich mich bisher nur mit Apache2, aber der soll wohl nicht so prall von der Performance her sein... ich hätte an sich kein Problem mich in nen anderen Server einzulesen, aber würde sich das lohnen?
nginx ist eigentlich mit so der beliebteste RP, weil er nochmal einen eigenen Cache hat und besser SSL terminieren kann. Da hat Apache einfach ein paar Schwächen, vor allem wenn man viel Load hat.
Wenn es aber ein reiner Proxy werden soll, kann ich auch Traefik sehr empfehlen. Den nutze ich sehr gerne, nicht nur im Container Umfeld, weil die Config so schön simpel und er nicht so überladen ist.
Ansonsten natürlich auch noch der Klassiker: Haproxy. -
Bildschirmfoto zu 2019-10-02 14-24-38.png Als ob man das braucht
In der eigenen Gitea/Gogs Instanz darf man das
-
Was mir direkt auffällt, es sollten unbedingt inhaltlich sinnvolle Git Commit Messages gepflegt werden. Jeder, der das nutzen möchte, möchte ja auch nachvollziehen können, was sich an den Skripten geändert hat. Idealerweise sollten auch Tags/Releases gepflegt werden, damit Installationen reproduzierbar werden.
-
Die Datenbankgrößen in MB: 0.45444775, 1.01562500, 3.51562500, 3.84199810, 4.82812500, 4.88529301, 5.78125000, 6.31250000, 7.06389046, 10.21206188, 13.34994888, 16.79687500
Also bei solchen Daten lohnt es sich überhaupt nicht, die Datenbank auszulagern. Lass sie ruhig mit auf dem Server laufen (vorausgesetzt, die Applikation läuft mit der neueren MariaDB Version, die mit CentOS8 mitkommt) - aber selbst in diesem Fall sollte man eher die Applikation aktualisieren
https://en.wikipedia.org/wiki/Unix_domain_socket
<-- ist ca. 30 mal schneller als das Loopback Device, deswegen laufen alle Application und Datenbankdienste zusammen, es sei denn man muss clustern.
Aber selbst da läuft die Replik auf dem Applicationserver, mindestens aber der Router zum Cluster sollte da lokal laufen.
Zumindest theoretisch. In der Praxis merkt man diesen Unterschied allerdings kaum.
Man verwendet das VLAN auch nicht dazu, um TLS auf offener Strecke abzulösen.
Um vor Zugriffen zu schützen, gibt es iptables - und auf TLS sollte man auch im VLAN nicht verzichten.
Es kann dir keiner garantieren, dass da nicht mal Pakete woanders lang huschen. Da reicht es bereits einen Server von dir zu übernehmen und ganz frech auf ARP Requests zu reagieren, und schon bekomme ich eine Kopie deiner Pakete, die du ja jetzt nicht mehr verschlüsselst.
Die kann dir nicht nur KB19 erzählen. Diese ganze YaSSL Geschichte ist einfach nur zum Hände über den Kopf schlagen.
Es macht schon einen Unterschied, ob die Zugriffe über das VLAN laufen oder über die Public IPs. Ich halte es durchaus für eine gute Alternative (anstatt Public IP + SSL), gerade weil du ja auch schon richtig angedeutet hast, dass SSL Implementationen oft nicht ganz so super umgesetzt wurden (jetzt konkret für diesen Fall gesprochen, ich möchte hier nicht generell SSL schlecht reden).
Wenn wir jetzt aber bei dem Beispiel des TE bleiben, dann hat er sowieso verloren, wenn einer der Server übernommen wurde. Wurde der Webserver übernommen, hat der Angreifer Zugriff auf die DB (dank der Credentials, die ja irgendwo auf dem Webserver zu finden sind), hat er Zugriff auf den DB Server, hat er den Zugriff ebenfalls. Recht hast du natürlich, wenn unzählige Server in dem VLAN laufen, die eigentlich sonst nichts miteinander zu tun haben. Das ist dann aber wieder eine andere Geschichte. -
Ich würde das hauptsächlich von der Last auf dem Server bzw. der Größe der Datenbank abhängig machen, da man im Hintergrund auch immer ein wenig die Kosten berücksichtigen muss. Hast du hierzu ein paar Daten? Aber prinzipiell ist die Trennung von Datenbank und Webserver eine gute Idee. Dank dem kostenlosen Cloud VLAN bei Netcup kann man den Zugriff auch prima schützen. Vorher musste man da SSL Zertifiakte verwenden, was nicht immer einfach gewesen war bzw. ist( KB19 hat da auch ein paar nette Geschichten zu erzählen, wenn ich mich richtig erinnere).
Bei mir laufen die meisten Datenbanken mittlerweile als Container. Das hat vor allem die ganze Update Geschichte stark verändert und vereinfacht. Bei einigen kleinen Projekten läuft die Datenbank aber weiterhin mit auf dem gleichen Server. Hier spielt die DB Version im Grunde keine Rolle und die Zugriffe auf die DB sind recht überschaubar. Hier würde sich ein separater DB Server überhaupt nicht lohnen. Es kommt also immer etwas darauf an.
-
Hallo Weizenfuchs,
wenn dieser Fehler schon bei einem "php -v" auftritt, solltest du dies am besten direkt dem Netcup Support melden (zusammen mit der Webhosting ID). Das klingt ganz nach dem Fehler, den schon andere hier hatten. Da kann dann bzw. muss der Support tätig werden.
-
Es geht in erster Linie auch um die Datenhoheit. Du bist zwar noch der Eigentümer/Urheber der Daten, aber nicht mehr der eigentliche Besitzer, da der direkte Zugriff auf die Daten beim Anbieter liegt. Du hast zwar noch eine Art Nutzungsrecht, verlierst aber im Endeffekt die Hoheit über diese Daten. Es ist und bleibt natürlich immer eine Risikoabschätzung. Wenn du im Zweifel bereit bist, alle Passwörter zu verlieren, dann kann man das schon machen.
-
Passwörter gehören nicht in fremde Hände. Punkt. Ohne Ausnahme. Finger weg von irgendwelchen Cloud Diensten. Wenn eine Synchronisation gewünscht ist, sollte die über eigene Server oder offline stattfinden. Wenn die privaten Urlaubsbilder im Netz auftauchen, ist das eine Sache, bei einer Passwort Datenbank was etwas anderes.
Auf der einen Seite haben wir die völlig am Rad drehende EU (https://www.golem.de/news/eugh…r-nutzer-1910-144187.html) und auf der anderen Seite Nutzer, die all ihre Daten, inklusive Passwörter auf US Server laden. Schade, dass wir uns so von der Vernunft verabschiedet haben. Wir waren eigentlich mal auf einem ganz guten Weg... -
...
Mir ist noch nicht so wirklich klar, worauf du eigentlich hinaus willst. Wenn du in einer VM ohne vmx Flag eine Vollvirtualisierung (z.B. VirtualBox oder Proxmox mit KVM VMs) betreibst, hast du natürlich eine viel höhere Last, weil die Emulierung entsprechend Leistung kostet. Daher buchen die meisten, die so etwas nutzen, auch das Flag hinzu, weil es ohne praktisch nicht nutzbar ist.
Wenn man allerdings keine Vollvirtualisierung nutzt, dann ist das Fehlen des Flags recht irrelevant. -
Das natürlich schon. Aber sowohl LXC als auch Docker arbeiten ja auf Basis von cgroups und namespaces im Linux Kernel. Hier laufen die Prozesse im Grunde direkt auf dem Host System. Docker in LXC bzw. Docker in Docker oder LXC in LXC belasten hier das Host System nicht wirklich mehr, da es in dem Sinne gar keine "Virtualisierung" ist, sondern eher eine Art Sandbox.
-
Docker benötigt kein vmx Flag. Das brauchst du im Grunde nur bei einer Vollvirtualisierung wie z.B. KVM/QEMU. Daher kannst du das ruhig so machen.
-
Ich habe ihn heruntergefahren, das Live-Rettungssystem aktiviert, und ihn gestartet - und er bootet automatisch wieder auf meinen Linux-Server, obwohl steht dass das Rettungssystem "aktiviert" ist laut Banner im SCP.
Auch wenn ich dann bei dem Boot Vorgang über "Bildschirm" das Rescue CentOS 7 auswähle bootet er normal in meinen Linux Server.
Ich glaube das Rettungssystem geht nicht da es ja aus dem Netzwerk bootet, mein Server aber keine Netzwerkverbindung hat, da weder Gateway noch DNS pingbar ist
Hast du denn die Boot Reihenfolge in den Einstellungen entsprechend angepasst, so dass "Netzwerk" vor "Hard Disk" steht?
-
Hast du dich denn schonmal ins SCP eingeloggt und über die Webconsole nachgeschaut, was auf dem Server gerade passiert? Ohne dass du mal im Rettungssystem das Problem reproduziert hast, wird dir der Support da auch nicht direkt weiterhelfen können.
Wir können hier natürlich auch versuchen das Problem zu lösen, aber da wären etwas mehr Informationen notwendig.
Eine kostenpflichtige Notfall Hotline gibt es natürlich auch: https://www.netcup.de/kontakt/telefonsupport.php -
Alles anzeigen
äh jetzt ist es aber irgendwie strange, bei dem Test vorhin mit dem Speicherräuber CentOS 8 und dem CentOS 7
hatte ich es soeben mit CentOS 6 auf dem selben vServer gemacht
CentOS 6
Code[root@v2201711509255xxxx ~]# uname -a Linux v2201711509255xxxx.luckysrv.de 2.6.32-754.23.1.el6.x86_64 #1 SMP Thu Sep 26 12:05:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@v2201711509255xxxx ~]# cat /proc/meminfo MemTotal: 1019840 kB MemFree: 868472 kB ..wieso ist hier bei 'MemTotal' der Wert nochmal ein klein wenig größer als bei CentOS 7?
was sollte dieser Wert tatsächlich aussagen?
bei einer physikalischen Kiste sollte es doch das f. das OS zur Verfügung stehende RAM sein, oder nicht?
der Wert 'MemAvailable' fehlt hier ...
Meminfo zeigt immer nur den im Userspace verfügbaren Speicher an, nicht den physikalisch verbauten oder virtuell zugeteilten. Der Kernel nimmt sich hier immer einen gewissen Anteil für sich. Ich bin da auch schon drauf rein gefallen.
-
Ich würde einfach sagen: Sämtliche Zusatzdienstleistungen (Extra IPs, Dedizierte NICs) die an dem gekündigten Produkt hängen sollten automatisch mit gekündigt werden. Mitnahme nur bei kostenpflichtigen Transfer, wie bisher auch. Problem gelöst.
Andere Zusatzdienstleistungen wie Failover IPs, Storagespaces, SLA+ und Cloud vLANs sollten sowieso unabhängig sein und an keinem Produkt hängen.
Aus Kundensicht hast du da natürlich vollkommen recht. Nur wird Netcup die Preise ja auch anhand der Mindestvertragslaufzeit berechnen. Daher müsste der monatliche Preis für die Zusatz IP zwangsläufig höher werden, damit es sich in der Gesamtrechnung wieder lohnt. Je länger man sich an ein Produkt binden möchte, desto günstiger wird es in der Regel.
Rein wirtschaftlich ist das schon nachvollziehbar, was Netcup da macht. Alternativ könnte man natürlich auch die zusätzlichen Produkte fest an das Elternprodukt knüpfen, das würde aber bedeuten, dass sich die Kosten für die zusätzlichen Produkte (wie z.B. die zusätzliche IP) von Server zu Server unterscheiden. Hat man einen Server mit einer Mindestvertragslaufzeit von 12 Monaten gemietet, könnte man weiter die Zusätzliche IP für 1€/Monat buchen. Bei einem VPS, der stündlich gekündigt werden kann, würde der Preis vermutlich auf 4-5€/Monat steigen müssen. Oder sogar noch höher, weil ja die Failover IP schon 5€ im Monat kostet und diese hat auch schon eine Mindestvertragslaufzeit von 12 Monaten.
Bei den (nicht negativ gemeinten) Discounter Preisen von Netcup ist das halt mit einer der Abstriche, die man machen muss Wir reden hier schließlich von 1€/Monat.
