Agent startet nach Wechsel von OpenVZ zu LXC nicht mehr

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Agent startet nach Wechsel von OpenVZ zu LXC nicht mehr

      Hallo,

      seit dem Wechsel von OpenVZ zu LXC startet der Bloonix Agent nicht mehr auf v-Servern mit Debian 8.

      Source Code

      1. ~ # systemctl status bloonix-agent.service
      2. â— bloonix-agent.service - Bloonix Agent
      3. Loaded: loaded (/lib/systemd/system/bloonix-agent.service; enabled)
      4. Active: failed (Result: exit-code) since Sat 2017-04-29 09:29:43 CEST; 2s ago
      5. Process: 5792 ExecStartPre=/usr/lib/bloonix/bin/bloonix-pre-start /var/lib/bloonix /var/lib/bloonix/agent /var/log/bloonix /var/run/bloonix (code=exited, status=226/NAMESPACE)
      6. Apr 29 09:29:43 voice01 systemd[1]: Starting Bloonix Agent...
      7. Apr 29 09:29:43 voice01 systemd[1]: bloonix-agent.service: control process exited, code=exited status=226
      8. Apr 29 09:29:43 voice01 systemd[1]: Failed to start Bloonix Agent.
      9. Apr 29 09:29:43 voice01 systemd[1]: Unit bloonix-agent.service entered failed state


      Source Code

      1. Apr 29 09:29:43 voice01 systemd[1]: Starting Bloonix Agent...
      2. -- Subject: Unit bloonix-agent.service has begun with start-up
      3. -- Defined-By: systemd
      4. -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
      5. --
      6. -- Unit bloonix-agent.service has begun starting up.
      7. Apr 29 09:29:43 voice01 systemd[5792]: Failed at step NAMESPACE spawning /usr/lib/bloonix/bin/bloonix-pre-start: Permission denied
      8. -- Subject: Process /usr/lib/bloonix/bin/bloonix-pre-start could not be executed
      9. -- Defined-By: systemd
      10. -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
      11. --
      12. -- The process /usr/lib/bloonix/bin/bloonix-pre-start could not be executed and failed.
      13. --
      14. -- The error number returned while executing this process is 13.
      15. Apr 29 09:29:43 voice01 systemd[1]: bloonix-agent.service: control process exited, code=exited status=226
      16. Apr 29 09:29:43 voice01 systemd[1]: Failed to start Bloonix Agent.
      17. -- Subject: Unit bloonix-agent.service has failed
      18. -- Defined-By: systemd
      19. -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
      20. --
      21. -- Unit bloonix-agent.service has failed.
      22. --
      23. -- The result is failed.
      24. Apr 29 09:29:43 voice01 systemd[1]: Unit bloonix-agent.service entered failed state.
      Display All


      Irgendein einer eine Idee, woran das liegen kann?
      Den Agent habe ich schon probiert neu zu installieren. Hat aber leider auch nicht geholfen.

      Edit:
      Gleiche tritt auch mit einem frisch installierten Debian 8 Server auf.
      Template ist von "images.linuxcontainers.org/images"

      Viele Grüße
      Marvin

      The post was edited 1 time, last by NevaKee ().

    • Hi Marvin,

      ich versuch mich mal :)

      > Apr 29 09:29:43 voice01 systemd[5792]: Failed at step NAMESPACE spawning /usr/lib/bloonix/bin/bloonix-pre-start: Permission denied
      Wenn man google Glauben schenkt, zeigen viele Threads auf ein Permission Problem mit Verzeichnisrechten. Das Script `/usr/lib/bloonix/bin/bloonix-pre-start` ist sehr kurz und spricht dafür. Ich sehe dort mkdirs und chowns. Bitte führe das Script händisch aus und schreibe zuvor unter das #!/bin/bash ein `set -x` und schicke uns den Output.

      Ich bin mir nicht sicher ob ich da jetzt einen Religionskrieg starte :) imho überwacht man LXC / Docker Prozesse auf dem Host System, also dort, wo man `docker` oder `lxc` eingibt. LXC hatte ich lange nicht mehr in der Hand, bei Docker könnte ich jetzt genaueres erzählen. Nach meinem Verständnis startet man in Docker immer nur exakt einen service.

      Sagen wir, du hast in Deinem LXC einen PHP-FPM laufen. Diesen sieht man in /proc auch auf dem Hostsystem - d.h. ein Bloonix Agent auf dem Host sollte eigenltich ausreichen.

      Kannst Du uns beschreiben, welche Dienste geplant wie genau gehostet werden sollen?
      A service is only a service if its monitored.
    • Danke für die Antwort.

      pthurner wrote:

      Wenn man google Glauben schenkt, zeigen viele Threads auf ein Permission Problem mit Verzeichnisrechten. Das Script `/usr/lib/bloonix/bin/bloonix-pre-start` ist sehr kurz und spricht dafür. Ich sehe dort mkdirs und chowns. Bitte führe das Script händisch aus und schreibe zuvor unter das #!/bin/bash ein `set -x` und schicke uns den Output.

      Mit welchem Benutzer soll ich das ausführen? Als root oder bloonix ist die Ausgabe identisch.
      ~ # /usr/lib/bloonix/bin/bloonix-pre-start
      + USERNAME=bloonix
      + GROUPNAME=bloonix
      + CHECK_DIRS=
      + test '!' -z ''


      pthurner wrote:

      Kannst Du uns beschreiben, welche Dienste geplant wie genau gehostet werden sollen?

      In dem Fall ist es ein v-Server, auf dem mehrere Voiceserver laufen. Bis jetzt habe ich damit CPU, RAM, Festplatte, div. Dienste, Updates etc. überwacht.
      Mir ist jetzt keine Möglichkeit bekannt, dies alles über den Host abzufragen und bei Bloonix als eigenen Server zu hinterlegen.
      Viele Grüße
      Marvin
    • Um sicher zu sein, dass ich richtig verstanden habe: Du möchtest für jeden LXC Container in Bloonix einen Host anlegen?

      (hab mein altes Wissen grad ganz kurz ganz grob aufgefrischt) - LXC sind basically chroots mit cgroups - d.h. vom LXC Host aus kannst Du alles sehen was im Container passiert - im LXC container hast Du /proc, /sys usw vom Host durchgereicht.

      Du hast also sagen wir einen physischen Server bei Hetzner mit KVM VMs (oder eine Hetzner VM), und dort LXC - und in den LXC's laufen "voiceserver" (was für ein Programm genau)?

      PS: Möchtest Du die Limits IM Container überwachen - als das cgroup Limit für z.B. RAM, disk usw?
      A service is only a service if its monitored.
    • pthurner wrote:

      Um sicher zu sein, dass ich richtig verstanden habe: Du möchtest für jeden LXC Container in Bloonix einen Host anlegen?

      Ja, genau. Im Moment betrifft das nur 2 LXC Server.

      pthurner wrote:

      (hab mein altes Wissen grad ganz kurz ganz grob aufgefrischt) - LXC sind basically chroots mit cgroups - d.h. vom LXC Host aus kannst Du alles sehen was im Container passiert - im LXC container hast Du /proc, /sys usw vom Host durchgereicht.

      Das mag sein, aber die Bloonix Plugins können es nicht oder habe ich da was übersehen?

      pthurner wrote:

      Du hast also sagen wir einen physischen Server bei Hetzner mit KVM VMs (oder eine Hetzner VM), und dort LXC - und in den LXC's laufen "voiceserver" (was für ein Programm genau)?

      Proxmox 4.4 ist bei mir im Einsatz. Einige Server sind mit KVM angelegt und andere wiederum mit LXC.

      pthurner wrote:

      PS: Möchtest Du die Limits IM Container überwachen - als das cgroup Limit für z.B. RAM, disk usw?

      Ja, so ich es bei OpenVZ vorher auch gemacht habe, bzw. jetzt bei den Server, die nicht Systemd nutzen.


      Edit:
      Der Bloonix Satellite startet ebenfalls auf einem der LXC nicht. Fehlermeldung ist die selbe.
      Viele Grüße
      Marvin

      The post was edited 1 time, last by NevaKee ().

    • Wenn ich richtig verstanden habe, ist die geeigneteste Möglichkeit die LXC stats zu überwachen ein LXC Plugin für den Bloonix Agenten zu schreiben und den Output des lxc-monitor Kommandos zu parsen: lxc.sourceforge.net/man/lxc-monitor.html


      # will monitor the different states for container foo.
      lxc-monitor -n <container_name>


      Vom Host aus sind alle benötigten Daten einsehbar, ebenfalls die Prozesse, welche im LXC laufen (bzw eben ob sie überhaupt laufen). Wir machen das für Docker und haben (derzeit intern) ein solches Plugin für Docker Container.

      Ich habe mit OpenVZ leider nur sehr wenig Erfahrungen - ich habe bei Kunden gesehen, dass diese oftmals wie vollvirtualisierte VMs "behandelt" werden (im Sinne von jede "VM" hat eine IP auf der ein SSH Server lauscht usw). Nach meinem Verständnis ist dies nicht die richtige Herangehensweise für LXC und Docker. Man started dort (bei Docker bin ich mir extrem sicher) nur einen Service und freut sich über alle Features von Containerisierung - ganz besonders, dass man einfach ein "Image" hat und das "überall" einfach läuft (Bezug auf Docker, in der LXC Welt bin ich nicht so viel unterwegs).

      Möchtest Du Container (portierbare "images" (eine Datei), cgroups für "Prozessisolierung" (nicht security sondern Ressourcen)) oder lieber einfach "eine VM", auf der via apt-get installl alles stressfrei machbar ist?

      Für Container würde ich statt LXC dann eher Docker empfehlen. Es gibt dort extrem viele "Dockerfiles" die man für eigene Zwecke forken kann. Lernkurve bis production mindestens eine Woche jeden Tag ein bisschen Docker hacken :)

      Wenn ich Deinen Usecase richtig verstanden habe, würde ich die Installation Deiner Anwendungen in ein Dockerfile schreiben, daraus ein Image bauen, dieses N-Mal deployen und gut. LXC würde ich nicht nehmen da "die Community" grad einfach auf Docker ist und man da den besten Support (IRC, Doku, Foren, Stackoverflow Threads usw) für bekommt.

      Es gibt da noch spannende andere Containerisierungen mit Bezug auf Security, die z.B. die Syscalls einschränken usw :) Aber das führt hier zu weit. Wenn Paranoia dann imho XEN oder KVM.
      A service is only a service if its monitored.
    • Um den Thread abzurunden: Ich stelle in den Raum, dass die richtige Herangehensweise LXC Container zu überwachen (ob mit Bloonix, Nagios oder whatever) ist, lxc-monitor zu parsen und dafür ein Plugin zu bauen. Ich muss dazu sagen, dass mein LXC Wissen eher Halbwissen ist.
      Bei Docker kenne ich mich besser aus - da haben wir das so gemacht, und das war die richtige Herangehensweise ;)
      A service is only a service if its monitored.
    • Leider nein :(

      Der Agent muss /usr/lib/bloonix/bin/bloonix-pre-start ausführen dürfen und das auch als root. Das Skript sorgt dafür, dass ein paar Dinge existieren, die der Agent benötigt.

      Also wenn der Agent gestartet wird, passiert das ja eh als root. Dann mit root-Rechten wird das Skript ausgeführt, danach macht der Agent ein setgid + setuid und wird zu bloonix:bloonix.
    • Wenn das abschalten von PrivateTmp nicht hilft, schalt den LXC-Container mal in den previligierten Modus:
      Die entsprechende container-config muss dabei um den Eintrag 'lxc.aa_profile=unconfined' erweitert werden.

      Das Problem ist, dass für Bloonix ein extra NameSpace angelegt werden soll - unpreviligierte Containern gelingt das nicht, da AppAmor es verhindert.

      Ich hatte das Problem auch schon und ich glaube mich zu erinnern, dass das abschalten von PrivateTmp alleine nicht half.

      Eigentlich sollte das Log/Journal des Host eine entsprechende Meldung enthalten.
    • Moin zusammen,

      ich habe scheinbar eine Lösung gefunden.

      folgende Datei bearbeiten:

      Source Code

      1. ​nano /lib/systemd/system/bloonix-agent.service


      Hier sind die folgenden Parameter zu ändern.

      Source Code

      1. ​PrivateTmp=false
      2. NoNewPrivileges=yes


      Anschließen folgenden Befehl ausführen:

      Source Code

      1. ​systemctl daemon-reload


      Anschließen kann man den Agent starten, leider sind aber die möglichen Checks beschränkt.
      Alles was mittels Root (sudo) ausgeführt werden muss, kann nicht verwendet werden.

      Wenn also auf diese Checks verzichtet werden kann, wäre dies bei einem LXC Container ohne previligierten Modus.

      Gruß

      Björn