Posts by Paul

H6G wrote:

Wie steht es eigentlich um das angekündigte Guthaben System, damit bei stundenbasierten Servern alles glatt läuft und per API bestellt werden kann?

Vermutlich stellt sich darüberhinaus auch die Frage, ob so ein Guthabensystem nicht sogar mit Negativzinsen kommen wird, wenn es denn überhaupt kommt . Ich kann mir vorstellen, dass das gerade aus diesem Punkt momentan nicht mehr so einfach ist. Immerhin muss Netcup das Geld auch irgendwo parken und ob man da noch eine Bank findet, die das ohne Strafgebühren anbietet . Den 3. Geschäftsführer muss man jetzt ja auch irgendwie finanzieren. Ein Weihnachtsgeld will er vermutlich auch noch. Das erklärt dann auch die fehlenden Angebote dieses Jahr.

Aber ich will mal nicht ganz so gemein sein. Wenn es klappt, dann bestelle ich morgen auch wieder einen neuen Server.

Versteht denn jemand, warum man ein Produkt, das in unbegrenzter Stückzahl vorhanden ist, in einem extra Bestandskundenvorverkauf anbietet? Immerhin gibt es die morgen ja wieder - ebenfalls in unbegrenzter Stückzahl. Wo ist denn da der Vorteil? Ich hätte mir hier ehrlich gesagt einen dieser Aktions-VPS gewünscht, bei denen es ja tatsächlich ein Spiel mit der Zeit ist. So ist das gefühlt irgendwie nicht so das Besondere, das im Artikel beworben wurde. Aber ist vielleicht auch nur meine persönliche Ansicht.

Was für einen Server hast du denn?

Das spricht nicht unbedingt für BBB. Zumal Ubuntu 16.04 ja nur noch ein paar Monate Support erhält. Eine Neuinstallation mit diesem OS möchte man ja eigentlich jetzt nicht mehr unbedingt.

Bist du denn fachlich in der Lage einen eigenen Mailserver zu betreiben? Das gehört ja mit zu den unangenehmsten Aufgaben eines Admins (Stichwort Microsoft Blacklist, etc.). Wenn es da Zweifel gibt, würde ich lieber beim Webhosting bleiben oder einen externen Mailanbieter wählen. Den Mailserver setzt man nicht mal eben so auf. Da sollte man schon wissen, was man tut. Dies nur als kleinen Ratschlag. Automatisieren kann man das natürlich. Das würde ich aber wenn dann schon selbst machen, sonst weißt du später nicht, was da eigentlich genau passiert oder konfiguriert wurde. Gibt ja einige Tools, mit denen man das recht einfach machen kann (Ansible, Chef, ...).

Matthis wrote:

Niemand?

Oder nur untergegangen in der ganzen TOTP-Diskussion?

Caddy ist ja ähnlich wie nginx auch ein kompletter Webserver. Ich selbst würde als RP dann doch eher auf etwas "leichteres" setzen wie z.B. Traefik, wenn eh im Hintergrund nochmal ein eigener Webserver arbeitet. Gefällt mir persönlich etwas besser. Aber warum nicht einfach mal testen. Für einfache Aufgaben nehmen die sich alle nichts. Die API von Caddy scheint ja so ein bisschen der entscheidene Punkt zu sein, warum das wohl einsetzen möchte. Selbst habe ich Caddy aber auch noch nie im Einsatz gehabt.

Die Abrechnungsperiode kann sich zwar prinzipiell von der Mindestvertragslaufzeit unterscheiden, in diesem Fall beträgt es für die Plesk Produkte aber ebenfalls 12 Monate (siehe z.B. https://www.netcup.de/bestellen/produkt.php?produkt=842). Daher wird die Plesk Lizenz für 12 Monate im Voraus bezahlt. Das gilt auch für die .de Domain. Gilt im übrigen für alle anderen Domains auch, da diese immer mindestens für 12 Monate registriert werden müssen.

geekmonkey wrote:

Mal rein aus Interesse. Was spricht gegen www-data bzw. nginx als User?

Es ging ja in diesem Fall explizit um mehrere Webseiten auf dem gleichen Server. Da will man ja nicht, dass Seite 1 auf Daten von Seite 2 zugreifen kann, wenn diese nichts miteinander zu tun haben. Aber auch bei einer einzigen Seite würde ich einen eigenen User für die Applikation anlegen (was ich auch selbst immer mache). Der Webserver sollte nicht uneingeschränkt auf alle Daten zugreifen und sogar Schreibrechte auf die ganze Applikation haben. Daher empfehle ich immer, dass dann auch sauber zu trennen.

Cekirdek wrote:

Ein paar zusätzliche Fragen, die sich mir stellen:

• bin gerade am überlegen logwatch einzusetzen, um mir das log monitoring zu erleichtern(vlt hat jemand einen besseren Vorschlag)
• und sind rootkit erkennungs tools wie chkrootkit, oder rkhunter sinnvoll?
• sollte ich mehrere webseiten durch LXD container isolieren?

Wenn du auf dem System mehrere Webseiten betreibst, solltest du diese auf jeden Fall unter unterschiedlichen Usern laufen lassen und z.B. entsprechende PHP FPM Pools einrichten und nicht alles standardmäßig unter dem www-data User laufen lassen. LXC/Docker Container sind letztendlich auch einfach nur isolierte Prozesse auf dem Host. Beim Thema Sicherheit bringt das eigentlich keinen wirklichem Mehrwert.

Und was ist mit "Options +SymLinksIfOwnerMatch"? Das sollte eigentlich das gewünschte sein. Die erste Option mit "+FollowSymlinks" funktioniert aus Sicherheitsgründen nicht.

Hast du das mal getestet?

vmk wrote:

Interessant: Der heise Artikel "Ablösung nach 30 Jahren: Neue IT für die Bahn mit Kubernetes und AWS" bekommt nur negative Kommentare. Wo bleibt da die Troll-Arme die alles über den grünen Klee lobt?

Die Deutsche Bahn scheint ja auf Rancher (Kubernetes Distribution) zu setzen. Das ist doch super. Setze ich selbst seit dem ersten Tag ein. Da haben sie zumindest aus meiner Sicht genau auf das richtige Pferd gesetzt Aber aus meiner Sicht wird da viel zu viel hineininterpretiert. Am Ende zählt die Qualität der eigentlichen Applikationen. Ob das jetzt auf Kubernetes läuft oder nicht, spielt da eine eher untergeordnete Rolle. Eine ordentlich implementierte Applikation kann sicherlich von Kubernetes profitieren, aber eine schlechte Applikation wird nicht dadurch besser, dass man sie in einen Container steckt. Alles schon erlebt.

Aber da sitzen schon Leute, die wissen, was sie tun. Die Schweizer SBB geht ja einen ähnlichen Weg (in diesem Fall halt mit OpenShift).

Die größte Gefahr für deine Daten stellst immer du selbst da. Es ist für Hacker immer einfacher, den eigentlichen Client PC zu hacken als einen Server im Internet. Natürlich kann ein Hacker in die Google oder Microsoft Server einbrechen oder SSL Verschlüsselungen knacken und Daten mitlesen. Aber ist das realistisches Szenario, vor dem man sich schützen möchte? Wenn ja, Finger weg von irgendeinem Cloud Dienst. Egal welchem. Am besten gar nicht erst ins Internet.

Ich habe ein wenig den Eindruck, dass du auch in 10 Jahren noch fragen wirst, ob du deine Daten in Nextcloud, Onedrive oder Google Drive speichern sollst. Und du wirst vermutlich auch in 10 Jahren immer noch die gleichen Antworten erhalten wie heute. Daten, die nicht in die Cloud sollen, sollte man gar nicht erst hochladen. Von was für Daten reden wir hier eigentlich? Super geheime Regierungsdokumente? Urlaubsbilder? Vertragsunterlagen?

Microsoft, Google, Amazon, ... kochen alle mit dem gleichen Wasser. Du kannst Wasser aus deinem eigenen Brunnen nehmen (Nextcloud). Es bleibt immer noch Wasser. Hängt ganz von dir ab, ob du lieber anderen vertraust oder dir selbst oder wieviel Aufwand du investieren möchtest. Die Entscheidung kannst am Ende immer nur du selbst für dich treffen.

Olgsi wrote:

Aber Google Drive von den Servern sicherer als OneDrive? Im Bezug auf Hacker etc.

Nein.

whoami0501 wrote:

Interessant. Via IPv4 komme ich auf den Mindfactory Webshop, per IPv6 wird mir die Wartungsseite angezeigt.

Habt ihr das auch, wenn ihr auf https://www.mindfactory.de geht?

Funktioniert hier sowohl mit IPv6 als auch IPv4 einwandfrei.

Habe ich per Zufall gefunden und teile das hier einfach mal (unkommentiert). Vielleicht kann es ja der ein oder andere gebrauchen https://chrome.google.com/webs…cbeolbiflkjomlkcdapbegaff

dansch wrote:

Danke an alle, das hilft mir. Wir sind nur zwei Leute, die privat aber viele kleine git Repos brauchen. Bis jetzt habe ich die Repos immer per Konsole auf meinem VServer von der Konkurrenz angelegt. Das wurde mir zu mühselig. Außerdem sollte ein Wiki zu den Projekten.

Wenn es wirklich nur um Git Repos und Wikis geht, schau dir auch mal Gitea (https://gitea.io) an. Das läuft deutlich flüssiger, weil es viel weniger Ressourcen benötigt. Das kann man auch auf einem VPS 200 oder VPS 500 laufen lassen. Dafür reicht das allemal. Gitlab lohnt sich eigentlich nur, wenn man auch die Gitlab CI Funktionalität bzw. die Registry benötigt. Sonst ist der Overhead für den eigentlichen Nutzen etwas zu hoch. Lässt sich auch deutlich angenehmer "warten".

Ich habe hier Gitlab auf einem RS 1000 (G8) laufen. Das funktioniert soweit problemlos. Sind jetzt aber auch nicht so viele User. Sind mittlerweile etwa 200 Projekte, davon einige mit aktivierter CI. Die Runner dafür laufen in meinen Kubernetes Clustern. Hauptsächlich nutze ich das um Container Images zu bauen oder Latex Files zu kompilieren.

Die "großen" Daten habe ich soweit in einen S3 Object Store (Minio) ausgelagert, darunter auch die Registry (die am meisten Platz beansprucht). Das läuft zwar momentan auch auf dem gleichen Server wie die Gitlab Instanz, weil es von den Ressourcen aktuell locker ausreicht, so kann ich es aber jederzeit auslagern, falls es doch mal zu Engpässen kommen sollte. Das kann ich an dieser Stelle sehr empfehlen. So bleibt man direkt von Anfang an flexibel.

Ich überlege immer mal wieder, ob man das nicht auch irgendwie schlanker bauen könnte (Gitea, Drone.io, Registry), aber in Summe dürfte das nicht so viel weniger Ressourcen in Anspruch nehmen als ein Gitlab. Ich habe aber auch einige interne Dienste deaktiviert (Prometheus, Grafana, etc.), weil ich sie eh nie genutzt habe. Das hilft u.U. auch etwas. Daher bleibe ich dann doch lieber bei Gitlab. Eine zweite Gitea Instanz läuft hier sowieso (als Git Mirror, weil die kostenlose Version von Gitlab das nicht kann). Das ist dann gleichzeitig noch eine Art Backup, was so ganz nett ist.

Ich würde daher einen RS 1000 (G9) als Einstieg empfehlen. Der sollte sich ja dann bei Bedarf auch über das CCP problemlos upgraden lassen, wenn doch mal die Ressourcen knapp werden sollten. Ein RS sollte es meiner Meinung nach aber schon sein.

mainziman wrote:

Malware: FBI und NSA warnen vor russischem Linux-Rootkit

Das Rootkit soll sich tief in Linux-Systeme einnisten und von der russischen Hackergruppe APT28 verwendet werden.

https://www.golem.de/news/malw…-rootkit-2008-150264.html

Ein Rootkit, wofür man erstmal Root Rechte benötigt? Wenn ein Angreifer sowieso Root Rechte erlangt hat, hat man eh verloren. Entweder stehe ich da gerade auf dem Schlauch oder hier wird ein Fass aufgemacht, das eh schon offen war.

miednr wrote:

Hallo Dragon,

welchen Eintrag (1-9) meinst Du denn? Ich habe noch mail.meinedomain.com gar nicht über den Proxy geleitet, wenn ich das richtig sehe. Meinst Du Eintrag 3? Das ist ja ein Eintrag ohne die Subdomain "mail.".

Hallo miednr,

ich denke hier liegt ein Missverständnis vor. Weiter oben hast du ja geschrieben, dass sowohl webmail als auch mail über den Cloudflare Proxy laufen. Der MX Eintrag für die Hauptdomain zeigt ja aber auf die mail Subdomain. Der MX Eintrag ist ja aber erstmal nichts anderes als ein DNS Eintrag. Die eigentliche Verbindung der Email Clients läuft ja trotzdem über die Subdomain, auf die der MX Eintrag ja zeigt, sprich über Cloudflare in diesem Fall.

Die Lösung wäre als, die mail Subdomain eben nicht über den Cloudflare Proxy laufen zu lassen. Dann sollte es funktionieren.

aRaphael wrote:

Das ist ein wirklich schöner Freudscher Verschreiber.

Ups