Beiträge von julian-w

    Was verstehst du unter Cloud Cluster?

    Das Angebot für 452€ (Cloud R640 1K) ist ein leistungsstarker Server, auf dem die Virtualisierungs-Lösung von netcup läuft die du selbst nutzen kannst, um selbst VMs zu erstellen und verwalten. Sofern du nur ein Produkt buchst hast du auch kein "Cluster" im eigentlichen Sinne.

    Die RS8000 sind "einfach nur" virtuelle Server, mit einer entsprechenden Software kann man daraus ein Cluster bauen, wobei man meist 3 Server (bzw. eine ungerade Anazahl) nutzen sollte, da es sonst z.B. zum Split Brain und ähnlichen kommen kann.

    Von daher: Cloud R640 1K und RS8000 sind komplett verschiedene Produkte und ein Cloud Cluster ist wieder was anderes, was willst du denn erreichen :/

    Edit:

    hat von euch jemand Erfahrung mit einem Cloud Cluster hier bei Netcup?

    Jap, haben ganz viele hier mich eingeschlossen, häufig wird wohl ein MariaDB/PostgreSQL Cluster betrieben, ich habe noch ein GlusterFS Cluster. Gibt auch berichte über Ceph Cluster hier im Forum, wobei dafür netcup wohl nicht ganz ideal zu seinen scheint. Im Grunde könnte man auch mehrere DNS-Server als Cluster bezeichnen :/ Im großen und ganzen ist, vor allem in Verbindung mit einem vLAN, der Betrieb eines Cluster (entsprechende Software/Kenntnisse vorausgesetzt) bei netcup problemlos möglich 8)

    Auch ist das mein bisher erster Public-Server. Schon nach weniger als einem Halben Tag Betrieb habe ich eine ordentliche Menge an Einträgen in der fail2ban.log...

    Das ist aber normal. Sicherheit ist halt am Anfang das oberste Gebot, bevor überhaupt irgendein Service auf dem System läuft. Anleitung gibt es im Internet oder auch hier im Forum mehr wie genug, einfach die Suche benutzten.

    Die Web-API fände ich eine gute Funktion, da ich für Monitoringfunktionen auf dem Host ja wieder Listening Port(s) aufmache und sich dann sofort die ganzen Sicherheitsfragen stellen.

    Nicht unbedingt, es kommt auf das verwendete System an etc. Es gibt z.B. auch ein kostenloses vLAN bei netcup um mehrere Server abgeschottet vom Internet zu verbinden. Zudem ist VPN oftmals auch eine Lösung. Oder man lässt das Monitoring lokal laufen wenn man eh nur einen Server hat.

    laut Dokumentation gibt es eine Webservice-Methode "getVServerLoad". Leider ist dazu wenig dokumentiert. Ich vermute mal, dass man die CPU-Last zurück bekommt.

    Bitte die ganze Dokumentation lesen:

    Hinweis: Diese Funktion ist ausschließlich für vServer basierend auf Linux-VServer gültig.

    Auf allen neueren vServer Produkten die auf KVM basieren funktioniert dies nicht. vServer auf Linux-VServer gibt es seit gefühlten 10 Jahre nicht mehr bei netcup. Von daher ist die Funktion bei dir höchstwahrscheinlich nicht verfügbar.

    Mich interessiert diese Frage, da ich damit eine rudimentäres DoS Monitoring aufsetzen könnte.

    Vermutlich eher nicht selbst wenn es diese Funktion gäbe, davon ab betreibt netcup für dich einen DDoS-Filter bereits ;) Davon ab, was willst du machen wenn ein DDoS auf dich gefahren wird, nullrouten oder ähnliches kannst du sowieso nicht. Den Angriff am Server abzuwehren ist meist nicht möglich, da die Bandbreite nur über 1 GBit/s sein muss und schon hast du keine Chance mehr. Daher muss der DDoS-Filter vor deinem vServer installiert sein, was er auch ist. Siehe hier

    Falls du CPU-Load etc. monitoren willst, empfehlen sich Tools wie munin oder Telegrapher/influxDB/Grafana oder ähnliches, gibt unzählige Monitoring Tools 8)

    Eine Website ist sofort zu sehen "Hier entsteht eine neue Website" das ist aber die "lokale" Site aus Netcup....

    Die eigentliche site ist eine Musikband...:)

    Bei mir erschien gestern schon die Google Site, also alles in Ordnung nur etwas Geduld :) Ist wirklich nur ein alter gecachter Eintrag bei dir. Prinzipiell kann man, wenn DNS Änderungen anstehen, vorher die TTL zwei Tage vorher auf einen niedrigeren Wert stellen, dann sollte ein DNS Update schneller vonstatten gehen.

    Also gehe ich mal davon aus das es an Netcup liegt zumal wir 4Jahre lang keine Probleme hatten

    Google danach, du findest viele Leidtragende. Microsoft tut nach Lust und Laune IP-Bereiche ablehnen, in den SPAM verschieben oder - wost case - blackholen. Ich persönliche benutzt für Microsoft-Adressen den Amazon SES, kostet zwar Geld (ist aber der billigste), funktioniert aber in 95% der Fälle, zumindest Blackholing konnte ich noch nicht beobachten.

    Kann sein das ihr bei einem anderen Anbieter mehr Glück habt, kann aber auch nicht so sein.

    Microsoft will einfach Kohle sehen für E-Mails hab ich das Gefühl, wenn man die Ihnen nicht gibt ist man wohl der gelackmeierte ||

    Das unterstreicht auch die die Verschwendung.

    Wobei man dazu sagen muss, ein /32er-Netz entspricht "quasi" einer IPv4-Adresse, dann relativiert sich das alles auch wieder etwas ^^ (ich weiß ist natürlich etwas ungenau, da nur ein kleiner Teil von IPv6 geroutet wird etc., aber gibt einem ein ungefähres Gefühl)

    Am Beispiel von netcup: netcup hat zwei /32er-Netzte für sich beantragt (und eines für einen Kunden wohl) und laut he.net 61,184 IPv4-Adressen verteilt auf 46 Prefixe. Der Faktor 2 gegen 61.184 ist extrem. Auch 2 Einträge in der Routing-Tabelle gegen 46, wobei es sicherlich noch krassere Fälle gibt.

    da aus dem Zwang mehr als nur ein /64 zuzuweisen zu müssen,

    Der existiert nicht, sonst würden Endkunden nicht (fast) immer /64 bekommen ^^ Große Firmen brauchen natürlich mehr.

    f. den Aufwand sind 28-bit nicht wirklch die Welt ...

    Die Rechnung verstehe ich nicht ganz, aber du meinst 28 Bit sind effektiv nutzbar. Sonderadressen machen übrigens weniger wie 2% aus (Quelle Wiki). Ich bin mal so frei und sage: wir gewinnen nur 16 bit (im Vergleich zu IPv4) dazu, du gingst ja scheinbar von 28bit aus.

    Bei 48 bit ergeben sich grob 2,8 * 1014 komplette Netzte... reicht doch und das ist noch eine schwere Untertreibung in Wirklichkeit sind es viel mehr. Und man muss bedenken wir reden hier nicht von Adressen, sondern von Netzen. Der Adressraum ist einfach so unvorstellbar groß, daher tut es nicht weh /64er als kleinste Einheit anzusehen. Wenn man selbst etwas rumrechnet merkt man dies, dann muss man diese "Verschwendung" (die keine ist) einfach akzeptieren. Lieber zu viel wie zu wenig Adressen ;)

    Bislang wird im Internet sowieso "nur" 2000::/3 geroutet (RFC4291), der Rest ist reserviert, z.B. für den Fall das man merkt man war doch zu verschwenderisch, hat man noch ganz schön viele Adressen auf Halde. Aber alleine in diesem /3er Netz sind so viele 64er-Netzte enthalten (2,3 * 1018)... das kann man sich nicht vorstellen 8| Selbst wenn 99% für Infrastruktur drauf geht ist immer noch mehr wie genug da. Jedes BIt mehr verdoppelt die Anzahl verfügbarer Adressen.

    julian-w versteht es leider nicht, daß es einfach kompletter Quark ist, daß ein /64-Prefix als "kleinste Einheit" zu sehen ist

    weil unter diesem Gesichtspunkt in der Annahme er liege richtig, hast gerade ein paar Bits mehr als bei IPv4 und da ist es nur logisch

    daß viele auf IPv6 'pfeiffen' ..

    und es mehr Sinn macht sich was sauber zu überlegen, an Stelle von Design-Fehlern durchzudrücken ...

    Ein paar Bits mehr heißt konkret: aus grob 4 Milliarden IPv4-Adressen werden bei IPv6 1,8 * 1019 Subnetze (NICHT Adressen), die alle quasi unendlich viele Geräte beinhalten können (ebenfalls 1,8 * 10.19). Natürlich sind dies nicht alle nutzbar, einige sind reserviert für link-local, broadcast etc.

    Aber ich denke die Dimensionen werden damit klar, es sind nicht "ein paar Bits mehr", sondern eher soviel mehr Netzte das man diese unmöglich verbrauchen kann. Und wie oben erwähnt is der Sinn hinter diesen gigantischen Netzte die globale Routingtabelle so klein und einfach wie möglich zu halten.

    Edit:

    Und die saubere Überlegung ist im Beitrag oben drüber: "unendlich" große Subnetzte -> nie mehr wird ein Subnetz voll weil zu viele Clients darin sind; Extrem große Blöcke -> Routingtabelle bleibt klein und sauber. Und man hat genug Adressen/Netze für immer und ewig. Drei große Vorteile für IPv6 zu IPv4.

    Ihr sprecht valide Punkte an, aber der Ton dieser Diskussion driftet mir persönlich etwas zu sehr ab.

    [Ironie]Ja aber...aber... ich wurde hier als erste als Käse-Redner beschimpft ;( Okay gut eigentlich wollte ich mich auch ganz raushalten :( [/Ironie]

    Aber was will Lieschen Müller mit einem /56er oder /64er Netz?

    Die Idee ist "verschwenderisch" zu sein. IPv6 wurde auch nicht für Lieschen Müller designed, sondern eher für größere Anwendungen. Gerade mit IPv4, wenn man für ein Subnetz nur ein /26er-Netz hatte, wurde dies unter Umständen mal voll, dann musste man den Netzplan erst mal über den Haufen werfen. Gerade an der Uni gibt es bei uns immer mal wieder Probleme das Arbeitsgruppen wachsen und dann die IPs nicht mehr ausreichend sind. Daher hat man bei IPv6 das kleinste Subnetz als /64er-Netz definiert, dieses Netz sollte wirklich niemals niemals voll werden. Damit ist das Problem ein für alle mal gelöst.

    Da ein /64er-Netz nun die kleinste Einheit ist, gibt man Endkunden z.B. ein /56er-Netz sodass jeder Endkunde dieses Netz noch untergliedern kann, in verschiedene /64er-Netze. Lieschen Müller braucht das eher nicht, daher geben fast alle ISP an Privatkunden auch nur ein einzelnes /64er-Netz heraus.

    Die gigantischen Blöcke sollen es hinterher auch ermöglichen, dass die globale Routingtabelle viel viel kleiner wird. Man schaut sich nur mal die verschiedenen AS an und die zugeordneten IPs. Bei IPv4 herrscht das "reinste Chaos", von überall her gibt es IP happen, gerade durch den Mangel fragmentiert der IPv4-Raum extrem. Bei IPv6 wirkt das ganze sehr geordnet. Da die IPv6 Blöcke unglaublich groß sind und auch sehr viele Subnetzte beinhalten, werden die auch eine ganze Zeit lang reichen (für "immer", bis die Menschheit ausstirbt? Wer weiß...).

    Daher ist es nicht tragisch wenn Lieschen Müller in ihrem /64er-Netz oder gar in einem /56er-Netz nur ein oder zwei Geräte hat. Hauptsache die globale Routingtabelle bleibt klein, und Adressen sind mehr wie genug da :)

    Hier mal am Beispiel von netcup:

    https://bgp.he.net/AS197540#_prefixes

    https://bgp.he.net/AS197540#_prefixes6

    IPv6: 3 Einträge

    IPv4: nicht gezählt, aber so 20-40 :/

    Edit:

    simple Rechnung: IPv6 wird meist als /32er Block zugewiesen. Daraus kann man 232 /64er-Blöcke machen, d.h. mit einer Zuweisung erhält ein Provider/Hoster/... direkt mal 4.294.967.296, also etwa 4 Milliarden 64er-Netze. Damit kommt man eine gute Zeit lang aus, bzw. man hat soviel 64er-Netzte wie es IPv4-Adressen gibt... ich denke damit dürften die meisten nur noch ein oder zwei Einträge in der globalen Routing-Tabelle brauchen und nicht mehr unzählige, Ausnahmen bestätigten die Regel ;)

    besser etwas nicht vestehen wollen - ich

    als etwas nicht verstehen in der Lage zu sein - Du.:P

    Aus deinem geschrieben würde ich behaupten ich hab mehr Ahnung von IPv6 oder anders formuliert: ich akzeptiere die Fakten. Du wärst vielleicht (?) in der Lage IPv6 zu verstehen, willst aber einige Design-Entscheidungen nicht akzeptieren und stempelst diese einfach als "Fehler im Desing" ab bzw. willst "dein Ding" durchziehen oder arbeitest nach dem Motto "das hab ich schon immer so gemacht, was soll der neumodische scheiß". So funktioniert es natürlich nicht. Wenn man sich nicht auf IPv6 einlässt, funktioniert IPv6 nicht und einige Dinge sind halt anders wie in IPv4.

    Du hast auch bei einem ganzen /64 mit SLAAC nicht die Chance zu definieren, aus welchem Teil davon die IPv6-Adressen generiert werden ...

    Warum sollte man das wollen? IPv6 sieht das nicht vor und es ist auch nicht notwendig, akzeptiere das oder halte dich aus IPv6 raus, das hat nichts mit meinem "Privatkäse" zu tun. Wenn du dich fragst warum das so ist: Im Internet sind die Antworten mehrfach enthalten. In IPv4 gibt es halt nichts vergleichbares (zumindest fällt mir auf die schnelle nix ein), daher ist diese Design-Entscheidung für dich vermutlich nicht nachvollziehbar. Die letzten 64 Bits stehen dem Client "frei" zur Verfügung im Falle von SLAAC. "Maximal kleine" Subnetze gibt es nur in IPv4, was zu Problemen führt wie rasend wachsenden Routingtabellen.

    Man muss akzeptieren das (prinzipiell) ein /64er-Netz die "kleinste Einheit" ist, ein kleineres Subnetz ist nicht möglich (im Gegensatz zu IPv4 das man quasi maximal klein machen konnte).

    Die Antwort: Gar nicht, weil es nicht gewollt ist in IPv6... der Client darf aus dem ganzen /64er-Netz seine IPv6 berechnen. Darüber zu Streiten ist eine sinnlose Grundsatzdiskussion die du so sehr liebst und das ganze hat nix mit "Fehler im Design" zu tun...

    Over and Out :rolleyes:

    Ach der Mainzimann der will es nicht verstehen... Damit haben wir ja schon fast alles zusammen: die klassische "Gegenfrage", irgendwas in die Richtung "du redest Käse"... fehlt nur noch das irgendwann einem das Wort im Mund umgedreht wird, er per Zitate auch von anderen Usern darauf hingewiesen wird und danach ist i.d.R. Ruhe von ihm ^^


    Aber zum Thema wie ich mir das klar gemacht habe mit IPv6 und dem /64er-Netz:

    Man muss akzeptieren das (prinzipiell) ein /64er-Netz die "kleinste Einheit" ist, ein kleineres Subnetz ist nicht möglich (im Gegensatz zu IPv4 das man quasi maximal klein machen konnte). Die Gründe dafür sind jetzt erst mal egal, es ist nun einmal so. Und das ist auch kein "Fehler im Design", sondern aus (guten) Gründen so gewollt. Wenn man vorher ein genug großes Netz hat das sich entsprechend "zerkleinern" lässt, ist das alles im großen und ganzen kein Problem, man darf halt nur nicht versuchen die /64er noch zu zerlegen 8)

    Was geht denn daran kaputt?

    Man kann es zu Hause nicht ("nativ") weiter strikt unterteilen, z.B. in ein Gast-Netzwerk und Privat-Netzwerk, ohne die automatische Konfiguration, sei es Stateful oder Stateless, kaputt zu machen. Natürlich geht es irgendwie über krudes IPv6-NAT oder sonst was, man kann die IPs alle statisch konfigurieren, oder per VLAN und dann besonderen Firewallregeln was basteln, sowas ist aber sicherlich nicht schön oder gewollt. IPv6 bietet schöne Möglichkeiten, aber als Privatkunde ist es nicht immer leicht diese zu nutzen.

    Eigentlich bieten sich z.B. /56er Endkundennetze an, nur leider sind viele Privatkunden-Anbieter so knausrig was Netzte angeht, bzw. wollen (mehr) Geld haben X/ Als Telekom-Kunde hat man da etwas Glück 8)

    dass dies ein Fehler im Design ist, kommt Dir nicht?;)

    Du redest hier über Enterprise, ich über Privatkunden, also hat nichts mit dir zu tun und deiner "Logik über Fehler im Design" :P

    Wenn ein "Enterprise"-Netzwerk nur ein /64er-Netz hat, haben die sowieso ganz krass was falsch gemacht, ist wie wenn man nur "eine" IPv4 für hunderte Arbeitsplätze hätte. Entweder wurde da Geld gespart ohne Ende oder jemand hatte absolut keine Ahnung, und beides ist nicht ein "Fehler im Design". Da ist die Telekom zu Privatkunden besser, die geben mindest ein /56er-Netz und "richtige" ISPs geben noch viel größere Netze raus an Geschäftskunden. Im Privatkunden-Bereich bekommt man bei IPv4 bei vielen (z.B. im Kabel) ja auch keine echte IPv4-Adresse mehr, sondern nur noch so ein CG-NAT gedöns womit man von außen schon nicht mehr erreichbar ist, deswegen ist IPv4 ja auch nicht "broken by design" sondern eher "broken bei Profitgier der ISPs" (wobei irgendwie doch, die Adressen gehen aus^^)

    Ach ja wieder eine lustige Diskussion mit den Mainzelmännchen, der Klassiker der Gegenfrage wurde auch schon gebracht... diesmal halte ich mich aber wirklich raus, auch wenn es mir in den Fingern juckt :saint:

    douzer bleib stark ^^

    Nur so am Rande: in Deutschland gibt es bereits viele die natives IPv6 anbieten (teilweise dafür nur verkrüppeltes IPv4, besonders im Kabelnetz...), Ausnahmsweise ist die Telekom vorne dabei und als gutes Beispiel zu nennen mit echtem DualStack im (V)DSL-Bereich und DSLite im Mobilfunk. Zudem vergibt die Telekom (zumindest) im (V)DSL-Bereich ein /56er-Netz, wodurch man selbst wunderschöne 255 eigene Netze einrichten kann die problemlos funktionieren, sind zum Glück nicht alle so knausrig und geben nur ein /64er-Netz was sich dann nicht mehr unterteilen lässt ohne das man IPv6 kaputt macht, was meiner Ansicht nach der größte "failure" ist der aber bei den ISPs liegt X/

    Ich habe so ein Buch und behersche auch das was ich brauche, nur die Funktionen und andere Komplexe Verknüpfungen versteh ich nicht

    Dann beherrscht du halt doch noch nicht alles was du brauchst ;)

    Und das hat nichts mit "Nextcloud Programmierer werden" zu tun, du musst dir ja nur ein paar grundlegende Dinge anschauen wie man mit Nextcloud interagiert, das ist alles sehr ordentlich dokumentiert inklusive Beispiel, ich denke mehr helfen kann man dir nicht ohne dir den Code vorzukauen.

    Um mal ehrlich zu sein habe ich 0. Sicherheitsvorkehrungen getroffen, ich habe dasselbe passwort für root und hauptnutzer und sudo geht ohne passwort, mir ist trotzdem nie was passiert

    Mit der Einstellung zum Thema Sicherheit würde ich es unterlassen am Nextcloud Code "rumzupfuschen", vor allem wenn es um User-Authentifizierung geht =O

    Falls du es wirklich nicht sein lassen kannst, gibt es z.B. hier hinweise wie man für Nextcloud eine eigene "App" schreibt:

    https://docs.nextcloud.com/server/stable/developer_manual/

    zum Thema User gibt es z.B. das Kapitel:

    https://docs.nextcloud.com/server/stable/…/User/User.html

    Auf gar keinen Fall würde ich aber was am SourceCode ändern, beim nächsten Update fliegt dir das vielleicht um die Ohren, wenn nicht schon vorher weil du die Sicherheit durch deine Änderungen kompromittierst.

    Apticron spamt dich nur zu, erstellt dir lieber selbst eine Update routine und achte drauf, dass alles up to date ist.

    Das finde ich aber gerade gut, gerade bei System wo ich selbst updates einspielen will, weil dann mach ich das auch wirklich damit der "Spam" aufhört ^^

    ClamAV als Antivir

    Das kannst du dir schenken, außer du willst Windows Viren finden. Für Linux gibt es faktisch keine, seit den Jahrzehnten wo Linux existiert wurden eine handvoll Viren/Trojaner/... entwickelt, aber all diese sind schon uralt und die Lücken längst gefixt, von daher schadet der Schritt nicht, bringt aber auch nichts (in Bezug auf Sicherheit für deinen Server).

    Danke für die vielen Antworten. Jetzt noch einmal auf z.B. Ubuntu umzusteigen wäre nicht meine präferierte Lösung. Ich würde lieber auf 7.2 updaten. Welches Package wäre denn jetzt "besser": packages.sury.org oder package.dotdeb.org ?

    Es steht nur packages.sury.org zur Auswahl, dotdeb.org bietet keine Pakete für Stretch an und hat auch nur php7.0.