Beiträge von Paul

Hallo Ben!

Wir reden hier von einer(!) Domain? Diese kann immer nur bei einem Mailprovider eingerichtet sein. Entweder bei Str... oder auf deinem Netcup Server. Das liegt schlicht an den DNS Einträgen. Was du aber machen kannst, ist für eine Subdomain die E-Mails auf dem Netcup Server betreiben und die eigentliche Hauptdomain weiterhin bei Stra... liegen lassen

user@domain.tld -> Stra...
user@sub.domain.tld -> Netcup

Wenn du die DNS Einträge auf den KVM Server umgeleitet hast, von welchen Einträgen sprechen wir denn da? (A, AAAA, MX?)

Gruß
Paul

Zitat von mainziman

weil das degradiert sonst zu 1FA;

Nein, nicht direkt. 2FA schützt nicht nur gegen Angriffe auf den User. Auch ein Servicebetreiber kann Passwörter "verlieren". Die können auf verschiedene Weise in falsche Hände geraten. Daher schützt dich das als Kunde durchaus vor Fälle, bei denen du selbst gar nicht beteiligt bist oder gar nichts dafür kannst, wenn diese kompromittiert wurden. Denn sind wir mal ehrlich, wenn jemand deinen Passwort Manager angreifen kann, kann er auch deine 2FA App angreifen. Das spielt keine so große Rolle. Irgendwo muss man dann auch realistisch sein. Wenn du deinem Mobile OS sowieso nicht so 100% vertrauen kannst, macht es rein aus Security Sicht keinen wirklichen Unterschied, ob man jetzt 1 App oder 2 Apps für den Login nutzt.

In der Theorie hast du natürlich recht. In der Praxis spielen aber so viele Faktoren eine Rolle, dass man hier die Risikobewertung nicht unter Laborbedingungen durchführen sollte.

Zitat von KB19

Paul Stand die eventuell mal öffentlich in Deinem Amazon Profil? Dafür gab es früher definitiv eine relativ gut versteckte Option. Das war bei mir schon einmal der Grund für so etwas, aber das ist einige Jahre her.

An Transportdienstleister wird die E-Mail-Adresse ebenfalls weitergeben, soweit ich weiß. Ich bekomme z.B. von der österreichischen Post bei Lieferung an eine Abholstation immer zwei Mails: An die von meinem Post-Account und an die von meinem Amazon-Account.

Danke für den Hinweis mit der Post. Daran hatte ich gar nicht gedacht. Das stimmt natürlich. Wenn DHL mit den E-Mail Adressen genauso sorgsam umgeht wie mit den Paketen, dann dürfte mich das jetzt nicht überraschen .

Habe heute eine interessante Spammail bekommen. Die E-Mail Adresse wird nur für Amazon verwendet. Sonst nirgends. Inhalt der Mail sieht auch täuschend echt aus. Nur der Absender halt nicht.

spam_amazon.jpg

Ich frage mich hier wirklich wie die an die Adresse gekommen sind. Evtl. über Amazon Marketplace? Werden da die E-Mail Adressen weitergegeben?

Habt ihr so etwas auch schon mal bekommen?

Zitat von gem

Gibt es bei den Open Source/Free Optionen auch etwas, das gleichermaßen (gut) Linux und Windows unterstützt?

Zabbix hat neben Linux und BSD recht guten Windows Support. Das wäre jetzt so auf Anhieb meine erste Wahl. Darüberhinaus muss man auch etwas zwischen Infrastruktur- und Performancemonitoring unterscheiden. Prometheus/Grafana ist in erster Linie für Metriken gut. Zabbix/Icinga & Co. sind primär Monitoringlösungen für die Infrastruktur. Selten kann ein Tool beides gut.

Vermutlich würde Bud als erste Handlung "seine" Tassen Domain zurückholen .

Hat da jemand tausende Neukunden geworben, weil das Partnerprogramm wieder funktioniert?

Man hätte es auch einfach "Österliche Resteverwertung: Alles muss raus 24" nennen können. Aber das wäre vermutlich etwas zu lang gewesen.

Zitat von extremmichi

Müsste hier nicht "Restarting": true, stehen?

oder kann ich das anderweitig überprüfen?

Nein, das ist schon korrekt. "State" ist hier der falsche Parameter. Das sagt nur in welchem Zustand sich der Container gerade befindet. Restarting wäre er tatsächlich nur während dem Restarting. Was du tatsächlich suchst ist die "RestartPolicy". Die sollte unter dem Punkt "HostConfig" zu finden sein.

Beispiel:

        "HostConfig": {
            [...]
            "RestartPolicy": {
                "Name": "unless-stopped",
                "MaximumRetryCount": 0
            }

Zitat von KB19

Dann fehlt nur noch netcup Warehouse Datacenter Deals, mit ausgedienten Systemen als Schnäppchen!

Ganz genau! Ich dachte auch schon an einen Netcup.de Club (ganz im Stile des bekannten Spirituosen Händlers, wo sich feine Geister treffen). Dafür gibt es dann einmal im Jahr einen speziellen Club Server zu bestellen.

Zitat von tab

Wenn ihr (Pluralis Majestatis? ) so ungeduldig darauf wartet, dann installiert doch von CD, die gibt es ja immerhin schon. Da seid ihr bestimmt schon Tage oder Wochen früher fertig. Vielleicht gibt es ja auch das Image fürs SCP am Dienstag als Schnäppchenangebot für 5,-€.

Wird Zeit für eine Netcup Prime Mitgliedschaft! Dann hat man einige Tage früher Zugriff auf neue Images und ISOs. Und auch die Versandkosten für gewisse Merchandise Artikel fallen dann weg.

Eine andere Möglichkeit wäre: Du bestellst einfach einen Server mit 12 monatiger Abrechnung, bezahlst die Rechnung und überträgst den Server mittels Inhaberwechsel. Falls du dann in einem Jahr den Server immer noch finanzieren willst, kann er kurz vor der Rechnung den Server wieder dir übertragen, du bezahlst die Rechnung und das Spiel geht wieder von vorne los. Falls du nämlich irgendwann selbst nicht mehr willst, kann das dann einfach auslaufen und der Server wird regulär gekündigt ohne dass du Schwierigkeiten bekommst.

Zitat von Win98SE4ever

Sehe ich diese Interpretationen zu eng oder wie hat sich das hier eingebürgert?

Du hast es ziemlich gut auf den Punkt gebracht. Die Enten Reaktion steht im Grunde für alles und kann alles bedeuten. In Österreich gibt es einen ähnlichen Ausdruck "Oida". Da können unsere österreichischen User sicher mehr zu sagen. Aber genau so könnte man die Ente sicherlich übersetzen.

Wenn du die Installation über die Command line mittels php-cli machst, kannst du dort das Limit selbst anpassen. Z.B.

php -d memory_limit=512M

Das unterscheidet sich nämlich in der Regel von dem gesetzten Wert, den man im FPM Pool oder im Apache Modul konfiguriert hat. Solche "Probleme" hat man öfter bei solchen PHP Applikationen. Nextcloud ist auch so ein Beispiel, wo man das manchmal benötigt.

IPv6-only Server waren ja schön öfter mal im Gespräch. Diese könnten stattdessen auch einfach günstiger angeboten werden als welche mit IPv4. Der Anbieter mit H hat ja genau so etwas auch im Sortiment. Ich kann mir aber vorstellen, dass dies technisch einfach noch nicht funktioniert, weil IPv4 für gewisse Funktionen (z.B. das Rettungssystem) noch zwingend nötig ist und daher nicht so einfach realisiert werden kann.

Zitat von p3nnyman

Ja, das mag wohl der Hauptgrund gewesen sein. Aber der Raspberry wäre ja auch ein mögliches Endgerät.
Welche wäre denn dann für einen ARMen-Server die zu präferierende Distri? Debian ARM oder ein BSD?

Aus Bequemlichkeit würde ich Debian nehmen Einfach weil es das als fertiges Image schon gibt und man so automatisiert auch seinen SSH Key direkt konfiguriert bekommt. Auch passt dann direkt die Netzwerkkonfiguration (ink. IPv6). Wenn der Aufwand keine Rolle spielt, kann ich auch Fedora wärmstens empfehlen. Sehr stabil und zuverlässig (sowohl amd64 als auch aarch64). Darauf setze ich z.B. bei meinen Systemen, die wirklich wichtig sind (z.B. Mailserver).

Wobei EndeavourOS eher ein reines Desktop OS ist. Und der Desktop Markt ist dann doch noch sehr stark von x86 dominiert. ARM findet man hier wirklich sehr selten. Daher hat es sich vermutlich einfach nicht gelohnt. Kann ja durchaus sein, dass sich das in Zukunft nochmal ändert. Der ARM Support in Archlinux ist generell noch so ein wenig dürftig. Da sind andere Distributionen deutlich weiter.

Zitat von tab

Schneller ist natürlich immer besser. Ab wann die IO zum Flaschenhals wird, kann man wohl nicht pauschal sagen. Werden die Seiten aus einem effektiven Cache ausgeliefert oder werden sie bei jedem Aufruf neu per PHP erzeugt? Ist open_basedir aktiviert (und damit der realpath-Cache deaktiviert)? Wie schnell ist der Core? Wie schnell ist die Netzwerkverbindung? Und und und ... Je nachdem wird die IO eben ab einem anderen Wert zum Flaschenhals.

Habe gestern Abend einige Erfahrungen sammeln dürfen, die auch hier reinspielen und über die ich erst mal nachdenken muss. Eine (aus Gründen) nicht gecachete Website habe ich auf unterschiedlichen Hostings und Servern mal durch Lighthouse gejagt und mir die Zeit für das Stammdokument angeschaut, das also bei jedem Aufruf neu berechnet wurde. Mit Abstand am schnellsten war der VC1-1 (120ms) , deutlich schneller als der ARM 2000 (320ms). Hmmm. Naja, der Core ist halt einfach schneller, YABS Singlecore ca 1400 vs 1100. Das allein reicht dafür aber wohl noch nicht. Ok... Netzwerkanbindung? Die IO ist es jedenfalls nicht, das verfügbare RAM auch nicht. open_basedir bei beiden inaktiv. Ich fürchte, damit hat der VC6-16 ein paar Pluspunkte dazugewonnen im Vergleich zum ARM 2000, der ihn eigentlich ersetzen soll. Das muss ich mir jetzt erst mal irgendwie schönreden

Steht dein ARM 2000 in Wien oder Nürnberg? Interessanterweise habe ich mit meinem neuen ARM 2000 ähnliche Beobachtungen gemacht. Gefühlt laden die Seite nicht merklich schneller und irgendwie wirkt alles etwas träge ohne es genau greifen zu können. Ok, der Steal ist recht konstant bei ~2%. Aber darauf alleine will ich es nicht schieben.

So pauschal lässt sich das natürlich schwer sagen. Die Brandbreite (MB/s) ist da auch weitestgehend egal (solange sie nicht völlig schlecht ist). Entscheidend sind da eher die Latenz der Lese und Schreibzugriffe und auch die IOPS Limits. Man sieht es wohl am ehestens daran, wenn die iowait Werte eines Servers hoch sind. Das zeigt, dass die CPU auf die Disk warten muss. Solange also der iowait Wert niedrig ist, sollte die Disk also nicht der Flaschenhals sein.

In den meisten Fällen dürften wir hier ja von einem Szenario ausgehen, bei dem man sowieso Vollzugriff auf das System hat, weil es man selbst dafür verantwortlich ist bzw. den Auftrag dazu hat. Ich melde mich hier einfach mal aus dem Lager der Befürworter der Root-Shell zu Wort. Persönlich nutze ich sudo nur um eine echte Root Shell (z.B. sudo -i) zu erhalten. Andere Befehle werden so gut wie nie mittels sudo ausgeführt. Das hat einen recht simplen Grund: Die Root Shell unterscheidet sich optisch (prompt) von der Shell eines normalen Users. Entweder weil das die Distribution schon so standardmäßig ausliefert (eher die Regel) oder weil man das selbst so konfiguriert hat. Daher wird hier ja gerne eine Warnfarbe (rot) genutzt. Ich sehe also direkt, dass ich hier in einer "gefährlichen" Umgebung arbeite. Gerade wenn man (wie ich z.B.) sehr viele Systeme administriert und es im Alltag daher schnell mal dazu kommt, dass man auch sehr viele Terminals offen hat, ist ein optischer Hinweis mehr als nützlich. Ein Befehl ist sonst sehr schnell in dem falschen Terminal eingegeben. Daher kann ich aus Erfahrung sagen, dass man sich manchmal auch am besten vor sich selbst schützt, wenn man optische Hinweise hat, die man nicht so einfach ignorieren kann. Das hat man halt nicht, wenn ich einfach nur vor jeden Befehl ein "sudo" setze. Das wird auch gerne mal zur Gewohnheit und man macht es, obwohl man es gar nicht bräuchte und hat dann auf einmal ganz andere Probleme.