Für eine Individuelle Linux Installation genügt es schon, wenn man eine Live-CD wie z.b. archlinux oder eben ein optimiertes Rescue image booten kann, das mit provisionierten ssh-key daher kommt.
Ab da steht es, dann jeden frei, wie er sich sein kram partitioniert und installiert. Was ich insgesamt neben fertig Images als ausreichend empfinden würde.
KVM sehe ich maximal für eine Windows installation, aber mit Linux ist das überflüssig.
Mal ketzerisch gefragt, wenn du heute keine Kapazitätsplanung machst, wann ungefähr fängst du mit ihr an?
Dein Beitrag gibt mir leider den Eindruck, als das es Sinnvoller wäre, deine Strategie zu Überdenken, als ein einfaches System zuverkomplizieren, um an einem anderen Ende Zeit/Flexibilität zu gewinnen die es nie gab.
Fakt ist das man in der IT Grundsätzlich nie ein Perfektes Ausgangsszenario haben wird. Man kann zu klein, aber auch zu groß planen. Die Erfahrung zeigt aber das zu klein, immer die schlechteste Ausgangslage ist. Zudem muss man auch die ganze Komplexität hinterfragen, die mit LVM plötzlich in die Konstruktion Einzug gewinnt.
Ich gestalte meine Systeme mittlerweile so das 8GB (2G,boot,vfat;6G,root,btrfs+xxhash) das OS stellen und alles was Applikation ist, weit weg auf eigenen Disks/Partitionen residiert. Damit habe ich klare Abgrenzung zwischen einem relativ Statischen Datenberg und einem dynamischen der mit seinen Herausforderungen wächst.
Vorteil? Mein OS kann einfach als template mit cloud-init repliziert werden. Meine Anwendungen sind klar distanziert dazu und haben Ressourcen die sie wirklich benötigen und können jederzeit um den gestiegenen Bedarf erweitert werden.
Da ich für die Applikation oder einen Pool dessen, nur eine Partition mit btrfs + xxhash checksum habe. Lässt sich diese jederzeit online vergrößern ohne Kopfschmerzen und downtime. Das macht auch sämtliche deklarationen in allen Tools einfacher, vom Deployment bis zum Backup.
Das ganze kommt natürlich mit dem Knackpunkt das man seine Anwendungen, dann richtig konfigurieren muss, damit diese im korrekten Verzeichniss arbeitet. Was entsprechend zum lesen der Dokumentation anregt und zum Schluss zu einem besseren Verständnis führt.
Eine Platte zuverkleinern, sollte einfach nie in Betracht gezogen werden.
Zwar jetzt Offtopic, aber ich bin beruhigt das das Management bei Nextcloud sicherstellt das die User-Experience auch konstant gleich bleibt und das über Jahre hinweg. Von ihrem Plugin Ecosystem, absolut kaputten Crypto und Update Quality wollen wir garnicht erst Anfangen.
Meine Entscheidung Nextcloud gegen Seafile zu traden war einfach eine gute Entscheidung. Performance auf Hardware bzw. Netzwerk Niveau, jedes Update ist ein schönes Update. docker compose pull && docker compose up -d und schon geht die Party fehlerfrei weiter. Ach ja das alles natürlich verschlüsselt, auf dem Client, im Transport und im Lager. Ordentliche Clients die funktionieren, und das nach jedem Update. Ich bin ja schon still..
MTU 1420 ist doch eigentlich der Default Wert des wg Interface. Zumindest bei mir.
Ohne MTU Parameter in der Konfigurationsdatei des VPS Servers sieht es so aus:
Coderoot@vxxx:~# ip -d -s -s -h address show wg0 wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none promiscuity 0 allmulti 0 minmtu 0 maxmtu 2147483552 wireguard numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 tso_max_size 65536 tso_max_segs 65535 gro_max_size 65536 inet 10.x.x.x/24 brd 10.x.x.255 scope global wg0 valid_lft forever preferred_lft forever inet6 fc00:10:x::x/64 scope global valid_lft forever preferred_lft forever RX: bytes packets errors dropped missed mcast 10.1M 103k 458 0 0 0 RX errors: length crc frame fifo overrun 0 0 458 0 0 TX: bytes packets errors dropped carrier collsns 165M 139k 0 0 0 0 TX errors: aborted fifo window heartbt transns 0 0 0 0 0Mein wg0 Interface hat ja auch paar RX Fehler. Eine Änderung der MTU Größe auf z.B. 1380 hat diese aber nicht beseitigt. Muss ich mir nochmal mit tcpdump anschauen, was das verursacht. Auf den Datendurchsatz haben diese Fehler aber bislang keine Auswirkung. Vielleicht laufen diese Fehler auch im IPv6 auf, was ich aber nicht verwende.
Kannst du ggf. kurz dein Setup erläutern?
Naja, der lädt seinen Code halt auch irgendwo im Internet runter. Ich muss ihn mal bei Microsoft fragen, was 2+3*4 gibt. Hoffentlich benutzt er nicht den Microsoft Rechner im Standard-Modus. Die haben ja die Operatorpräzedenz bis heute nicht in den Standard-Modus eingepflegt, so komplizierte Berechnungen sind halt im Standard nicht vorgesehen. Im Modus "Wissenschaftlich" funktioniert es dann aber immerhin richtig.
Mir wäre neu das ein LLM etwas herunterlädt um dir zu erzählen. Das Modell wurde einfach mit Code der verfügbar ist / war trainiert. CodePilot und JetBrains AI machen nur um welten einen besseren Job als ChatGPT, nichts destotrotz brauchst man Programmier wissen, da der Code zum Teil absoluter Müll ist, aber an manchen Tagen sind die Snippets auch Timesaver.
Ich weiß nicht ob dir das auch weiter hilft, aber für dieses durchaus kleine und unkomplizierte Setup würde ich dir einfach zu einem Caddy Webserver raten.
Ganze Konfiguration die du dafür brauchst:
nodehub.de {
reverse_proxy 127.0.0.1:8080
}Generell würde ich dir empfehlen dein Setup in ein Docker Compose zu überführen. Das macht am Ende in der administration einfach mehr Spass. Da kannst du dann auch Caddy einfach als Container mit reinwerfen und in der Caddy Config einfach auf den Container Namen + Port verweisen und das wars, dann muss dein Trillium auch nichts exposen.
Wenn du in einem Mehrparteinhaus lebst und dein Paketbote seit Jahren die Namensschilder nicht lesen kann, dann weißt du was leiden heißt...
Für mich ist es ja nur das Highlight das wir zwei verschiedene Eingänge (2 Parteien Haupteingang) (1 Partei Nebeneingang) haben und es nur eine Frage der Zeit ist bis jemand einfach mein Paket am Haupteingang kaputt tritt, weil man sowas auch direkt vor die Tür mittig in den Weg legt... am besten noch unter die Sohlen kleben... Manchmal weiß ich einfach nicht weiter.
Scheinbar ist an der ipv4 und ipv6 wohl wirklich etwas dran. Zumindest laut dem Forenbeitrag:
Ich glaube aber das dir die Erneuerung nicht geglückt ist, weil IPv6 wohl am Webspace nicht mehr erreichbar ist.
Du siehst in deinem Screenshot <deine-domain> zu deiner <ip-adresse> das ist quasi die Auflösung Vorwärts und Reverse bedeutet Rückwärts quasi in diesem Fall bedeute deine IP-Adresse löst zu deiner Domain auf. Wie sowas beim Webspace möglich ist und nicht, durchaus interessante Frage.
Nur mal so aus fachlicher Sicht, du weißt was du da planst?
Ich betreibe zwar bei mir intern einen redundanten PowerDNS Auth, PowerDNS Rec, dnsdist, PDNS-Admin Stack, aber ich weiß auch das das Zeug niemals die Welt sehen sollte. Nicht weil es nicht toll funktioniert sondern, weil DNS einfach so unglaublich komplex ist, und ich jetzt mal mutmaße das du genauso wenig Operational Knowledge im public Betrieb zu sowas hast wie ich. Ausser du beabsichtigst das nur Intern zu verwenden, dann kannst du das eigentlich auch auf bestehende Server einfach drauf werfen und gut ist. PowerDNS Auth reicht für sowas z.B. vollkommen aus und braucht keine Ressourcen da ist sogar dein piko Server schon absolut overkill.
Mein Stack ist ein alpine linux virt mit docker compose und braucht ohne den PDNS-Admin vielleicht <256Mb Arbeitsspeicher.
Das Hause Skulduggery empfiehlt, ja ich weiß, dd over ssh, oder DDoSSH!
Ist getestet hab damit letztes einen Virtuelle Maschine von einem Cloud Anbieter auf meinen Root Server umgezogen.
Ja. Vermutlich sind IPv4 und IPv6 unterschiedlich eingerichtet.
Wie man das schafft, erkläre mir.
Ich sehe zwar deine Konkrete Meldung nicht, aber Sie wäre auf jeden Fall durch aus korrekt. Dein Webserver liefert ein Abgelaufenenes Plesk Self-Signed Zertifikat aus.
Ich würde für die Seite einfach Mal alle Zertifikate die du findest löschen und ein sauberes neues per Let's Encrypt machen lassen.
Ich weiß nicht welchen Einfluss du auf die Cipher nehmen kannst, den ich gehe bei Plesk davon aus das es sich um ein Webspace handelt, aber hier kann man auch noch eine Menge machen.
Mein aktuelles Namenskonzept sieht folgendermaßen aus:
ip-127-<standort-id>-0-1.hosting.<unloco/stadt>.<unloco/land>.localdomain -> A Record, Grundsätzlich jeder Server der einen Dienst anbietet
ip-127-<standort-id>-0-1.management.<unloco/stadt>.<unloco/land>.localdomain -> A Record, Grundsätzlich jedes Management Interface
<service>.localdomain -> CNAME auf A Record, Grundsätzlich der Name unter der eine Anwendung vom Benutzer aufgerufen wird
https://unece.org/trade/cefact/unlocode-code-list-country-and-territory
Probleme damit? Persönlich nein, Andere ja.
So mancher (möchtegern) E-Mail Anbieter hat scheinbar eine Allergie gegen sowas, weil nur SpAmEr solche Namen wohl nutzen, bzw. davon ausgegangen wird das der Administrator des Server mit dem provisonierten Hostnamen des Anbieters losgegurkt, Verzeiung, ich meinte losgewatschelt ist.
Nachdem ich beruflich seltsame Dinge als Open Source Monitoring Consultant mache, tendiere ich aktuell dazu Zabbix zu empfehlen. Die haben das alles recht simple in Docker verpackt, ja ihre compose ist ein kleines Chaos, aber Sie muss nur einmal angepasst werden, dann läuft die Bude wie am Schnürchen. Sonst hat es zwar auch so seine kleinen Eigenheiten, aber im gesamt Paket spielen Sie am Puls der Zeit mit und entwickeln sich auch mit jeden Major Realse prächtig weiter.
Sonst kann man noch check_mk in den Ring werfen, aber das habe ich zuletzt vor 8 Jahren angeschaut. Wenn deren komplette Check Bibilotek auch in der Free Version enthalten ist, dann ist es schon übermächtig für ein Homelab. lul.
Icinga 2 habe ich mal gemacht, aber für mich macht das Projekt einfach keine zielführenden Fortschritte mehr. Zumindest habe ich irgendwann keinen Icinga Director mehr verwendet, sonder nur noch alles per Konfigurationsdatei mit bisschen Automation. Zudem hat Icinga 2 so einwenig das Problem das es davon lebt das Menschen Plugins produzieren und allen voran pflegen. Dadurch das wir hier von Open Source (ja ich weiß, es gibt auch Pay2Use Plugins) reden, ist entsprechend die Erfahrung, das die Plugins mit der Zeit sterben werden, wenn sich keine große Nutzerschaft findet mit ein paar Pflegern. Allen voran wurden viele Plugins in Perl geschrieben, was stellenweise die Portabillität auf neue Systeme zu einem Abenteuer machen kann. Die Nagios/Monitoring Plugins die über die Paketverwaltung kommen kann man sowieso vergessen, die muss man sich mittlerweile mit deren Github Repo ohnehin selbst kompilieren. Da kann man nur noch die Empfehlung ausprechen zu prüfen ob man die Nagios Plugins komplett über Board wirft und sich einmal die Mühe macht die centreon-plugins komplett für Icinga 2 zu implementieren. Da ist man dann auf lange sicht auf dem guten Zweig unterwegs wenn es Icinga 2 sein muss. Ich rate wie gesagt davon ab da Sie im Grunde den Punkt vermasselt haben sich von ihrer Nagios Kompatibilität zu trennen und das zu machen wofür diese 2 am Ende eigentlich gedacht war. Ausserdem ist die Skalierung so ein Thema die man jetzt hier im Forum wohl ehr weniger erreicht, eine Thematik für sich selbst. Selbst die IcingaDB macht das denke ich nicht zwangsläufig besser sondern erhöht die komplexität ohnehin ins unnötige weiter.
Kleiner Nachtrag:
Wenn jemand ein CentOS/RHEL benutzt, hat seit 2021-11-12 keine öffentlichen Icinga 2 Pakete mehr. Diese wurden von der Icinga GmbH hinter einen "Paywall" geparkt und hierzu muss ein "Vertrag" oder "Abo" gekauft werden. Fedora ist wohl unberührt davon. Die Spec Dateien für das bauen von CentOS/RHEL Paketen kann man, aber auf ihren öffentlichen Gitlab Server einsehen und sich damit selbst Pakete bauen, nur halt ohne "Support".
Das ist meine unbiased Meinung zu dem Thema.
MongoDB ist perfekt fürs Clustering und Sharding mit mehreren Szenarios. (Hash, Hot / Cold, Geografisch).
Die Treiber haben bereits einen Read / Write Split integriert.
Klar, dass was bei MongoDB durch die Treiber abgedeckt wird, machen bei Cassandra die Server - aber MongoDB ist meine goto Datenbank und hat mir noch nie einen Datenverlust beschert. Evtl. hast du das Manuel nicht gelesen oder suchst zwecks CAP-Theorem nach dem falschen Tool, aber der Vergleich mit /dev/null? Wie kommt der zu stande?
Nebst komplett andere CAP Architektur und NoSQL Architektur ist MongoDB im Ranking deutlich vor Cassandra: https://db-engines.com/de/ranking
Mag sein das für dich MongoDB eine GoTo Sache ist, für mich ist es einfach nichts und gemessen an den Applikationen die ich mit MonogDB schon getestet oder teilweise betrieben habe, will ich es einfach nicht haben. Das ist nix ganzes und nix halbes.
Nein, keine gute Idee.
Warum soll den eine SQLite keine gute Idee sein? Meiner Meinung nach muss man nicht alles direkt auf eine Full Feature RDMS schmeissen ohne zu wissen ob es überhaupt ein Problem mit kleineren feineren Implemenationen gegeben hätte. Gerade diese Full Feature RDMS und NoSQL Technologien fügen plötzlich ein Komplexitäts Layer hinzu das es vielleicht garnicht gebraucht hätte. Einfach bauen und schauen wann sich wirklich Probleme ergeben und dann diese entsprechend lösen. Von Theorien über Probleme behindert man sich mehr beim Coden als einfach zu machen und dann die realen Probleme zu lösen.
Aber wir hatten ja schon das Thema mit:
Sehr sehr viel Meinung.
Warum braucht man da jetzt einen Message Broker? Es geht hier um eine Datenbank und nicht um einen Crashkurs in Micro-Service Architektur.
Naja du scheinst ja auch voreingenommen zu sein von dem her lass ich das auch mal so stehen. Ich hab meine Meinung zu PHP/MySQL Stacks und du hast deine Meinung zu Architekturen die einem das Leben unter Umständen einfacher machen.
Nachdem ich schon mal mit einem Request Tracker in der Größen Ordnung +2TB gespielt habe, kann ich nur versuchen dich davon abzuhalten, denn das Ende vom Lied war das man Regelmäßig per Skript, das vom RT Mitgeliefert wurde, die Anhänge auf nen NFS Share weggeschoben hat.
Die Antwort lautet auf jeden Fall nicht Relationale Datenbank. Die sind in sich per Design ein SPoF den du nur mit deiner Applikation sinnvoll lösen kannst. Ja man kann ein Galera Cluster betreiben und ich kann dir sagen das dieses RT von dem ich da oben spreche, vorher auf einem Galera lief und am Ende auf ein Master-Slave Blech setup migriert wurde, weil es absolut scheisse skaliert. Galera schickt erst dann ein ack für deinen write wenn alle ihn geschieben habe. Backups mit Galera in der Größen Ordnung kannst du praktisch komplett vergessen. MySQL/MariaDB hingegen gehen noch mit mysqldump.
Ich würde dir für solche Datenmengen ehrlich gesagt alles andere als PHP mit MySQL als Stack empfehlen, weil das einfach schon per se zum scheitern verurteilt ist. Als Beispiel finde ich das Nextcloud es schon fantastisch zeigt wie man es einfach nicht machen sollte, aber die haben noch mehr Probleme als nur ihr Stack.
MongoDB kann man auch kostengünstig gegen /dev/null ersetzen.
Wenn dir ein verteiltes System wichtig ist das skalieren kann, kann man über Cassandradb durchaus nachdenken. Es ist zumindest eine Lösung die gewisse Probleme im Datenbankbereich in der Frage Verteilung/Skalierung gut löst.
Wie man merkt habe ich eine Abneigung gegen PHP und MySQL und das leider irgendwie mit Erfahrungswerten.
Ich bin ein großer Fan von C# geworden nachdem die viel richtig machen. PostgreSQL wäre im Relationalen Bereich mittlerweile mein Standard nachdem die viele nette Erweiterungen bieten wie z.B. TimeScaleDB und richtig top durch optimiert werden können. Fang am Besten mal mit einer SQLite an und schau wie weit du kommst.
Wenn ich mir einen Traum Stack bauen könnte der so einiges kann, würde ich auf C#/Elixir/Rust mit Kafka und CassandraDB setzen um wirklich alles abzudecken was mir nur passieren kann in Frage Skalierung/Verteilung/Integrität.
Ich will aber auch sagen das wir hier nicht von einem Stack reden der Mal eben gebaut wird. Dafür sollte man wirklich ernsthafte Programmierung Erfahrung haben damit das Design von Grund auf zumindest solide ist. Perfekt wird sowas sowie so nie, aber man kann sich schon gut den Weg zum soliden Zustand verbauen.
OpenProject soll eine sehr dezente Wiki Funktion bieten.
Naja 10Gbit über RJ-45 ist auch mehr probieren als studieren. Wirklich funktionieren tut das meist nur unter sehr optimistisch optimalen Bedingungen auf kurzen Strecken.
Angeblich soll Cat6a mit den Frequenzen laut Spezifikation klar kommen, Cat7 entsprechend besser und den Stecker sollten wir auch nicht vergessen.
Bei ernstgemeinten 10Gbit Anwendungen würde ich ehr auf SFP+ Module mit DAC oder AOC als RJ45 leider setzen. Zu Mal dein Switch / Netzwerkkarte da deutlich Relevanter sind.
Würde auch Veeam for free in die Runde werfen. Hat nach KISS Schema einfach funktioniert bis jetzt.
KosMos Ich würde dir empfehlen in diesem Thread einfach Mal eine Runde Aussetzen zu spielen.
yunus Dein Vorhaben wirkt in vielen Punkten für mich irgendwie einfach nicht schlüssig.
Einfach Mal 10 Desktops an der Ressourcengrenze 24/7 zu Betreiben, um "aufgezeichnete Bewegungsmuster" in einem "Google Sheet" zu verarbeiten hört sich einfach absolut Sinnbefreit an.
Für dieses Projekt würde ich mir entweder inhouse was hinstellen oder dediziertes Blech mieten. Abgesehen davon das es deutlich bessere Testsoftware als click and run Spaghetti Software für Windows Benutzer.
Nachdem du quasi irgendwas in deiner Fantasie mit Linux und irgend einer Software gemalt hast, ohne es offentsichtlich einfach selbst zu können, wird das nur in einer Achterbahn-Schaukel enden.
Entweder machst du richtig krumme Sachen oder bist absolut Beratungsresistent gegen Intelligente Vorschläge oder etwas ganz großem auf der Spur.
