DerRené im Prinzip hast Du ja recht, ich spare mir eben das "Monitoring",
lasse mich erinnern wenn es denn wieder mal Zeit ist die Zertifikate upzudaten, und sehe dann direkt ob die korrekt installiert wurden;
f. Dinge die gerade mal 4 mal im Jahr passieren einen cronjob zu machen ist f. mich dann doch etwas seltsam;
ich nutze auf einem vServer LE und am anderen Buypass, welche gleich nur 2 mal Jahr ablaufen;
aber ohne verlässliche Automatismen käme man doch zu nix anderem mehr als manuell ständig und überall Updates zu triggern / zu kontrollieren.
Du sagst es, es gibt halt keine verlässlichen Automatismen; 
weil sich darauf zu verlassen, dass einem da nix untergeschoben wird, was dann das Setup kaputt macht, und man dann mehr Ärger am Hals hat,
bringt ja auch nix; ich wills vorher wissen was upgedatet wird ..., und nicht hintenach die Erkenntnis haben, dass es besser nicht upgedated werden hätte sollen;
und das hintenach Kontrollieren der Logfiles kann auch ganz schön aufwendig sein ...
kommt sich wahrscheinlich auf das Selbe 'raus, ob man eine Nachtschicht einlegt od. am nächsten Tag die Komplikationen der automatischen Updates korrigiert; und im worst case evtl. längere Ausfallzeiten hat ...
Wenn ich mir allein nur vorstelle, auf all meinen Servern die LE Zertifikate manuell anzustoßen, bekomme ich Zuckungen.
wieso nicht auch das Erstellen der Zertifikate zentralisieren?
eigentlich unglaublich, dass Zertifikatsaustausch noch immer vergessen/händisch gemacht wird und wer nicht aller (jahrelang) Warnhinweise ignoriert
Beim Vorübersurfen die Verbrecher immer wieder mal notiert: Liste wird länger und länger ...
mal etwas halblang; die LE Geschichte ist strenggenommen nur ein Experiment;
denn vertrauen kann man eigentlich nur OV Zertifikaten, und es wäre absolut kein Problem derartiges auch f. OV Zertifikate zu implementieren;
aber dagegen sind die CAs die damit Unmengen an Geld scheffeln;
oder würdest Du Deiner Bank vertrauen, wenn da bei https://banking.deinebank.deinland/ irgend ein DV Zert. zum Vorschein käme?
Und hat man sowas nicht sowieso im Monitoring?
ja im certwatch-Mail
cltrmx ./cr-all.sh und ./upd.sh reicht doch
sprich des alle paar Monate per cronjob zu machen und dann irgendwelche Logs durchschauen zu müssen ob es denn überhaupt fehlerfrei geklappt hat,
is ma einfach zu kindisch, wenn ich es so direkt sehen kann
(ich bin auch ein Gegner irgendwas unbeaufsichtigt automatisiert updaten zu lassen)
des is ja spannend, es gibt ja des certwatch, des einem ein Mail schickt, wenn die Zertifikate x Tage vor dem Ablauf sind;
beginnen tut des bei 29 Tage vor Ablauf;
dass ma des in /etc/sysconfig/httpd einstellen kann,
auf des muss ma ja mal kommen, weil Zertifikate ja auch f. posfix, ... verwendet werden;
hab es jetzt auf 14 Tage eingestellt, Zeit genug die Let's Encrypt Dinger neu zu erstellen;
werden vier Platten genannt, ist das immer[*] die RAID10-Bruttokapazität
weiß das Deine Glaskugel?
ich würde meinen dass
die Angabe 4 x 120 GB SAS, RAID10 einfach 4 mal 120 GB SAS, RAID10 heißt, also 4 Platten und nicht eine einzige Platte
m_ueberall Du brauchst nicht "Brutto" od. "Netto" hinschreiben, es genügt einfach das wie bereits oben beschrieben auszubessern;
Dein 2ter Punkt ist Off-Topic, sage ja, dass es irrelevant ist, mit welchen SAS od. SSDs das RAID10 tatsächlich am Host aufgebaut ist;
darum sagte ich ja, ich hätte gerne die Variante mit 4 mal 120 GB SAS sprich 4 Devices im vServer;
m_ueberall ich denke Du hast da jetzt was falsch verstanden; verkauft werden 240 GByte nicht 4 mal 120 GByte was 480 GByte wären;
wenn Du Dir die Auflistung der einzelnen Angebote ansiehst, würde die Angabe 4 x 120 GB suggerieren, Du bekämst 4 Platten zu je 120 GB,
welche Du im vServer (hier ein RS) z.B. über die Linux devices /dev/sda, /dev/sdb, /dev/sdc, /dev/sdd ansprechen kannst ...
wie das RAID10 am Host organisiert ist, ist dem vServer ja egal;
wenn Du Dir z.B. den RS 1000 SAS G8 ansiehst, steht hier direkt 320 GB SAS, welche SAS-Platten hier zum Einsatz kommen steht nicht, und ist auch egal;
wobei ich kann mir nicht vorstellen, dass die SSD-Variante echt aus 4 'USB-Sticks' zu je 15 GB besteht, kann ich mir so gar nicht vorstellen;
(man kauft doch keine 15 GByte kleinen SSDs, oder?)
Hallo,
wäre es möglich, bei den Angeboten hier: https://www.netcup.de/vserver/uebers…bote.php#server
hier das 4 x 15 GB SSD bzw. 4 x 120 GB SSD
durch die tatsächliche Festplatte ersetzt?
30 GB SSD bzw. 240 GB SSD
ich hätt nämlich gerne die SAS Variante mit wirklich echten 4 x 120 GB
Fischer's Fritz fischt frische Fische
Frische Fische fischt Firscher's Fritze
is effektiver 
joas ist bei Dir der 2te Hop wie auch bei peterbo ebenfalls IPv6 2a00:11c0:47:3::32 bzw. bei IPv4 müsste es IP 144.208.211.10 sein; Danke Sascha98
nur um es logischer zu sehen, mal die Fragen: wo steht der Host mit dieser IP(v6)?
muss hier sämtlicher Traffic in diese "Richtung" durch?
hat das "Phänomen" wovon einige hier schreiben, einfach mit dem zu tun,
dass diese Kiste und/oder die angebundene Leitung hier an der Leistungsgrenze sind?
kann da hier [Anexia] Theo V. was dazu sagen?
Sieht auf allen Servern ähnlich aus. Aber momentan gibt es ja auch kein Problem im Netzwerk, daher sind die Pingzeiten wunderbar.
jetzt wirds schwierig, weiß ja nicht wann es diese Probleme geben wird;
eigentlich wollt ich darauf hinaus, das Problem evtl. einzugrenzen;
genau dann wenn der traceroute von netcup weg Probleme macht, und ein
ein ping6 2a00:11c0:47:3::32
dies ebenso anzeigt, dann muss doch der selbe ping6 auf einem anderen vServer bei netcup,
welcher vlt. sogar in einem anderen IPv4-Segment 'hängt' auch so sein, oder?
wenn nicht, würd mich das jetzt stark wundern;
hast eine PN wie Du z.B. von meinem vServer querprüfen kannst;
Ich bin mir nicht sicher, auf was Du genau hinaus möchtest.
kannst auf den vServer gehen von dem Du den IPv6-Trace weg von netcup gemacht hast,
dort die IPv6 2a00:11c0:47:3::32 anpingen und einen Ausschnitt vom Ergebnis hier posten
und als Kontrolle einen traceroute mit IPv6 von netcup weg machen?
peterbo in der Tat, aber was mir dennoch seltsam erscheint bei IPv6 ...
die Richtung von netcup weg hackt bei Dir da bereits beim 2ten Hop,
welchen ich ohne Probleme pingen kann ...
64 bytes from 2a00:11c0:47:3::32: icmp_seq=32 ttl=63 time=1.08 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=33 ttl=63 time=14.5 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=34 ttl=63 time=0.801 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=35 ttl=63 time=0.735 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=36 ttl=63 time=1.04 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=37 ttl=63 time=0.829 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=38 ttl=63 time=0.638 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=39 ttl=63 time=0.742 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=40 ttl=63 time=1.89 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=41 ttl=63 time=0.619 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=42 ttl=63 time=0.705 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=43 ttl=63 time=0.661 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=44 ttl=63 time=1.11 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=45 ttl=63 time=0.721 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=46 ttl=63 time=2.63 ms
64 bytes from 2a00:11c0:47:3::32: icmp_seq=47 ttl=63 time=1.06 msbei der Richtung zu netcup, hackt eigentlich nur der letzte Hop - Dein vServer?
peterbo kannst Du die selben Traces per IPv6 mal machen und vergleichen;
hier erlebt man oft Überraschungen;
decken sich die Routen?
sind die Latenzen andere oder korrelieren diese mit denen bei IPv4?
peterbo der Host mit '???' scheint ein schwarzes Loch zu sein;
ich denke nicht dass hier netcup/anexia dagegen was machen kann;
Okay, das ist lustig - Windows XP kann's, aber iOS 9 nicht :o
ja vor allem, weil iOS 9 erst zu einem Zeitpunkt erschien,
nachdem der Support von WinXP durch Microsoft bereits geendet hatte
liegt vlt. an der Verbreitung
Für den wird also das Internet kaputt gehen.
erst jetzt?
joergmschulz hier ist von Port 25 ausgehend die Rede;
und ohne dem stell ich mir ein Mailrelay etwas seltsam vor 
außer man will sicherheitshalber auf postmaster@ u.ä. Adressen auch dort lauschen
das verkompliziet aber das Mailsetup ungemein;
und DKIM ausgehend kann nicht schaden genau hier zu implementieren,
und mittels header_checks sämtliches an Received zu entfernen;
bei mir ist halt mein vServer hier bei netcup mein Mailrelay 
Microsoft ist sowieso ein Kaliber f. sich, wenn man sich die DNS-Einträge von Domains ansieht,
welche eben bei Microsoft im Zshg. mit Office/Outlook365 gehostet werden, dann fallen einem die Haare ab;
dass da x 1000 Datacenter inkludiert sind, ist sehr vertrauenserweckend;
Hand aufs Herz wer hat beim SPF-Eintrag ausschließlich die IP-Adressen stehen von denen er wirklich versendet,
und kein 'a' od. 'mx'?
perryflynn ja was hast f. eine Anforderung und mit welcher Skriptsprache¹ willst es basteln?
Du kannst auch ein C/C++, FORTRAN. MODULA, PASCAL od. PL/1 programm dafür bauen;
¹ BASH, KSH, TCSH, ...
Ein Agent reported nicht erst dann, wenn es zu spät ist, sondern wenn ein Ausfall droht.
unter der Voraussetzung es läuft alles, gebe ich Dir Recht;
aber einen Ausfall des Netzwerks od. gar ein Blackout hat noch kein Agent vorher gemeldet ...
Und das ist ja eigentlich auch der hauptsächliche Sinn des Monitoring.
bei echtem physischem Blech hat es schon was, vorher Bescheid zu bekommen,
dass z.B. eine Platte kurz vor dem Ausfall ist;
whoami0501 es hat hier weniger mit Kindergarten und so zu tun, sondern eher mit: was will man und was braucht man;
mir genügt das tägl. 'logwatch'-Mail;
ich unterstelle halt, dass die Monitoring Agents nicht weniger oder mehr fehlerfrei/-anfällig sind wie alles andere auch;
und im worst case es nicht ausgeschlossen ist, dass derartiges selbst ein Einfallstor darstellt; hat ja auch schon Antiviren gegeben,
welche bestimmte Schadsoftware erst ermöglichten
