Beiträge von perryflynn

Zitat von perryflynn

Weiteres Monitoring hatte ich bisher nicht nötig.

Tja, hatte seit längerem eine VM über und habe aus Spaß in Check_MK das Distrubuted Monitoring ausprobiert. Nun habe ich eine externen Monitoring Knoten welcher meine Dienste auch "von außen" überwachen kann.

Erstaunlich wie einfach die Einrichtung lief. Debian Stretch installiert, VPN Tunnel zwischen den beiden Check_MK Knoten eingerichtet, Check_MK installiert, Auf der Offsite den Remote Zugriff aktiviert, die Offsite als Slave in mein vorhandenes Setup eingebunden, fertig.

Kann jetzt über ein zentrales GUI einstellen welche Hosts mit welcher Site überwacht werden sollen.

Nice, nur das Prompt passt nicht.

Zitat von perryflynn

Außerdem kann ein GET Parameter auch ein Array sein. Deswegen sollte man auch das abfangen.

Ha! Hecke29 da ists wieder.

Zitat von voja

das kann ich für das Playbook verwenden, dass die SSH Keys installiert und den SSH Dämon absichert

Ja genau dafür nutze ich das auch. Schau Dir auch mal die ganzen "become" Argumente an. Man kann so die komplette Authentifizierung, selbst wenn man den Umweg über sudo gehen muss via Argumente machen. Für das "Aufnahme-Playbook" sehr praktisch.

Zitat von julian-w

Du sprichst hier aber nicht über SSH, oder?

Nein, es handelt sich dabei um nen Webserver. An die Cooldown Phase hatte ich eben nicht gedacht. Daher passt mein Beispiel leider nicht ganz so gut.

Zitat von killerbees19

Das Auswerten von Logfiles kostet Ressourcen.

Ein Beispiel aus der Praxis: Eines meiner Projekte hat in 7 Tagen zirka 5 Millionen Hits. Hier habe ich versucht übermütige User mit Fail2ban auszufiltern. Kann man voll vergessen. Es kommen schneller Log Einträge dazu als sie analysiert werden können.

Das einzige was hier wirklich funktioniert sind Rate Limits. Und die müssen von der Firewall kommen oder tief im jeweiligen Service verankert sein, sodass man nicht den Umweg über eine Logdatei gehen muss.

Zitat von joas

mittels libpam-google-auth abgesichert.

Ja stimmt, das hab ich ganz vergessen. Bei Zugängen wo ich aus Bequemlichkeit auf einen Key verzichten will nutze ich das Plugin auch. Sehr schönes Ding.

Zitat von geekmonkey

Einzig und allein wegen Ansible hab ich nun mal SSH Keys eingesetzt

Was ja auch nicht nötig gewesen wäre. --user root --ask-pass sind hier Deine Freunde.

Habe das Verschieben des SSH Ports schon vor Jahren aufgegeben. Macht einfach keinen Sinn. Speziell wenn man über Internet Anschlüsse unterwegs ist, welche ne restriktive Firewall (Unternehmen, Arbeitgeber, etc) haben, ist das nur hinderlich.

Ansonsten habe ich vor kurzem via Ansible auf allen Systemen einen separaten Admin-User, sudo, eine sudo Gruppe, ein sicheres Passwort für den Admin-User und einen SSH Key ausgerollt. Zugriff via Passwort kann ausschließlich via OpenVPN Verbindung erfolgen (Stichwort Match Address Rule in sshd_config).

Mittelfristiger Plan ist es, Kennwort und Key alle paar Monate komfortabel austauschen zu können. Klappt soweit ganz gut.

Disclaimer: Bin noch ein Ansible Newbie. Keine Ahnung obs schöner geht.

Check_MK Agent an alle Debian Hosts ausrollen und das apt-get Check Plugin einbauen:

---
- 
    name: Install check_mk agent to all debian machines
    hosts: all
    become: yes
    become_method: sudo
    become_user: root
    remote_user: admin
    tasks:

        - 
            name: Install the newest check_mk agent package
            block:
                - copy:
                    src: pkg-debian/check-mk-agent_1.4.0p33-1_all.deb
                    dest: /tmp/check-mk-agent.deb
                    owner: root
                    group: root
                    mode: u=rw,go=-
                - apt:
                    name: xinetd
                    state: present
                - apt:
                    deb: /tmp/check-mk-agent.deb
                    state: present
                - file:
                    path: /tmp/check-mk-agent.deb
                    state: absent
            when: ansible_distribution == 'Debian'

        -
            name: Install check_mk apt plugin
            block:
                - file:
                    path: /usr/lib/check_mk_agent/local/43200/
                    state: directory
                    owner: root
                    group: root
                    mode: "u=rwx,go=rx"
                - copy:
                    src: pkg-debian/mk_apt
                    dest: /usr/lib/check_mk_agent/local/43200/mk_apt
                    owner: root
                    group: root
                    mode: u=rw,go=rx
            when: ansible_distribution == 'Debian'

Ja, einfach nach jedem connect im PHP Code anschließend das Query was Du auch im Terminal abgesetzt hast einbauen.

Typo3 z.B. hat dafür zum Beispiel eine Einstellung wo man "Initialisierungsqueries" angeben kann.

IMHO hilft git bei drei Dingen:

Versionierung

Sofern Du immer brav commits und tags erstellst, kannst Du deine Arbeiten in einzelne, kleine Änderungen (commits) aufteilen und jeden Release markieren (tag). Man erspart sich somit Dinge wie "ich mach von jeder Version ne zip".

Parallele Arbeiten

Man kann durch die branches mit der gleichen Code Basis an unterschiedlichen Projekten Arbeiten, ohne dass sich die Projekte gegenseitig in die quere kommen, weil Sie beide breaking changes auslösen. Hinterher können die branches dann in den Hauptzweig zurückgespielt werden, sodass beide Projekte live gehen können.

Kollaboration

Menschen können Deinen Code clonen, Änderungen vornehmen und bei Dir eine Anfrage auf Aufnahme in Deinen Code erstellen. Git erstellt dabei automatisch Patches. Wenn Du eine Plattform wie gitlab oder github nutzt, ist die Aufnahme der Änderungen in deinen Code meistens nur ein Click. Git macht den Rest von "alleine".

//edit: Noch ein Pro:

Verfolgbarkeit

Du kannst im nachhinein sehen, welche Änderungen wofür gemacht wurden. Wenn in einer älteren Version ein Bug eingeführt wurde, kann man sehen welcher Entwickler diesen eingebaut hat und mit diesem drüber sprechen. Finde ich sehr wichtig sowas. Schließlich lernt $Mensch nur durch Fehler, wenn dieser weiß dass sie passiert sind.

Zitat von geekmonkey

Bekomme ich das ohne Probleme unter Windows eingebunden? Werde mal die Docs durchblättern

Wollte gerade schon mit RTFM antworten.

Ja der macht Dinge simultan. Und via SSH. Und wie simultan kann man einstellen. Der entscheidende Vorteil ist aber, dass es für gefühlt alles fertige Module gibt.

Paket was es nicht als Quelle gibt installieren:

---
- 
    name: Apply defaults to hosts
    hosts: eisenbart
    remote_user: root
    tasks:
    - 
        name: Install the newest check_mk agent package
        block:
            - copy:
                src: pkg-debian/check-mk-agent_1.4.0p33-1_all.deb
                dest: /tmp/check-mk-agent.deb
                owner: root
                group: root
                mode: u=rw,go=-
            - apt:
                name: xinetd
                state: present
            - apt:
                deb: /tmp/check-mk-agent.deb
                state: present
            - file:
                path: /tmp/check-mk-agent.deb
                state: absent
        when: ansible_distribution == 'Debian'

Hinter "hosts: eisenbart" hängen um die 15 VMs. 11 Davon sind Debian. Und auf denen wird dann automatisch das Paket deployed.

Zusätzlich hat ansible die Template Engine jinja2 eingebaut mit der man Configs individuell für jeden einzelnen Host designen kann. Ist schon ein wenig besser als ein Bash Script.

Ansible selbst ist nur ein Programm was man sich normal installiert.

Was ansisble für einen machen soll definiert man mit YAML files. Nichts wildes, keine Gigabytes an Daten. Hab meine Playbooks einfach in mein privates gitlab eingecheckt.

Du meinst "Was brauche ich für den Betrieb von Ansible für Hardware?"

Ich habs einfach auf meiner Workstation laufen. Ist schließlich nur ne Handvoll Scripte und Textdateien.

Zitat von mainziman

besteht bei dieser Art der RAM-Einsparung nicht auch ein gröberes Sicherheitsrisiko?

Jop, ganz ohne Risiko scheint das ganze nicht zu sein:

https://en.wikipedia.org/wiki/Kernel_same-page_merging

Da es in meinem Fall aber um einen Homeserver geht, finde ich das jetzt nicht wirklich kritisch.

Zitat von geekmonkey

Hast du nen Root Server laufen

Das ist mein Homeserver. Blech mit Proxmox als Hypervisor. Habe Proxmox aber auch auf nem Root Server laufen. Hier das mit dem Netzwerk läuft hab ich hier verbloggt: https://anysrc.net/post/gnu-linux…ver-lxc-proxmox

Zitat von killerbees19

perryflynn Details?

KSM Sharing: https://pve.proxmox.com/wiki/Dynamic_Memory_Management

Mehr oder weniger werden alle Dings, welche von den VMs doppelt im RAM abgelegt werden zusammengefasst. Ich habe hier 11 Debian VMs laufen. Da entsteht viel Redundanz im RAM, welche der KSM Daemon beseitigt und zusammenfasst. Man spart RAM auf Kosten von ein wenig CPU Zeit. Merkt man aber im Realbetrieb nicht, da sich mein System langweilt.

Als Daemon nutzt Proxmox ksmtuned, welcher mit Debian mitkommt. Installieren und via systemd enablen und starten, fertig. Man könnte auch noch dran rumkonfigurieren, das habe ich aber nicht gemacht.

Dauert einige Stunden bis sich da was tut. Die Ersparnis ist ganz langsam auf 5 Gigabyte RAM angestiegen.

ksm.png

KSM Sharing bringt schon ne ganze Menge, wenn man viele VMs mit dem gleichen Basissystem im Einsatz hat.

https://anysrc.net/post/netzwerk/…review-20180606

Alles nur grob angerissen.

Wenn ich irgendwo genauer werden soll, bitte einfach Fragen.