Posts by Paul

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

Olgsi wrote:

Lassen wir die NSA mal raus, welcher der beiden Dienste sammelt weniger über mich, wenn ich die Datenschutzeinstellungen vornehme?

Auch da ist es ziemlich egal. Sowohl Microsoft als auch Google sammeln alles, was sie können. Windows ist ja mittlerweile auch voller Tracking "Funktionen". Die nehmen sich echt nicht viel. Da kann man einfach das nehmen, was einem besser gefehlt.

Ich habe ja auch selbst diverse Google bzw. Microsoft Accounts. So ist das nicht. Aber könnte ich die Dienste jemanden einfach so empfehlen? Eher nicht

Olgsi wrote:

Würdet Ihr zur Familien-Nutzung Google- oder Microsoftdienste empfehlen?

Völlig egal. Beides US Unternehmen. Für private bzw. Familiennutzung würde ich keines der beiden empfehlen.

eripek wrote:

(Tip an mich selbst: Bankaktien kaufen, sollen gerade billig sein - vor allem im Burgenland).

"Billig" ist genau das richtige Stichwort. Günstig sind sie nämlich nicht

Ich habe das bei mir jetzt auch mal ausprobiert. Die Meldung

"Das Programm qemu-guest-agent ist auf Ihrem Server nicht installiert. Wir empfehlen Ihnen, das Programm zu installieren. Der qemu-guest-agent ist unter anderem für ein sicheres Herunterfahren des Servers und andere Funktionen, welche das SCP nutzt, verantwortlich."

erscheint bei mir ebenfalls nun bei allen Servern, die noch nicht aufgrund der neuen KVM Version neugestartet worden sind. Bei einem Server, den ich eben testweise diesbezüglich mal über das SCP heruntergefahren und wieder gestartet habe, ist die Meldung verschwunden. Die Lösung hier ist wohl wirklich, dass man der Empfehlung im SCP lieber folgen sollte .

Ich empfehle und nutze immer gerne Fedora. Alternativ OpenSuse. Man merkt einfach, dass dort Firmen dahinter stehen, die hauptsächlich im Enterprise Umfeld aktiv sind. Dort hat man auf Dauer eine ganz andere Qualität/Stabilität und vor allem ein Qualitätsmanagement, das dafür sorgt, dass man das auch einfach mal laufen lassen kann. Klar haben Community Projekte (Archlinux, Debian, Alpine, ...) ihre Daseinsberechtigung und können jede Menge Spaß machen. Aber gerade die Bereiche, die nicht so viel Spaß machen, fallen dort gerne mal unter den Tisch.

Wenn man sich einmal anschaut, wer so alles zu den Projekte beiträgt, sind das oft nur eine handvoll Leute (bei den Community Projekten), die die Hauptarbeit machen. Gerade bei CentOS haben wir ja die letzten Wochen/Monate gesehen, dass es dadurch schnell mal vorkommen kann, dass es wochenlang keine Updates/Patches/Security Patches gibt. Damit muss man dann leben können. Auf meinem privaten Laptop wäre das halb so wild. Auf meinem Arbeitsgerät brauche ich einfach ein zuverlässiges System. Da ist für Spielereien nicht so viel Raum.

Hatte privat sehr lange Gentoo, anschließend Archlinux am Laufen. Aber wenn ich sowieso tagtäglich mit Fedora arbeite und mich dadurch mit diesem System in und auswendig auskenne, war es nur logisch, dass auch einfach privat einzusetzen.