LXC

Verzeichnisse

• Container: /var/lib/lxc
• Cache für Systeminstallationen: /var/cache/lxc

Debian Container unter Ubuntu bis 14.10

Direkt nach dem Erstellen lässt sich der Container nicht starten. Es erscheint folgende Fehlermeldung:

Failed to mount cgroup at /sys/fs/cgroup/systemd: Permission denied

Fehlerbehebung: In der "config"-Datei des Containers (normalerweise /var/lib/lxc/CONTAINER/config) folgende Zeile eintragen:

lxc.aa_profile = unconfined

Credits

Container startet ohne IP-Adresse

Womöglich läuft dnsmasq auf der virtuellen Schnittstelle (Standard: lxcbr0) nicht.

Lösung: Entweder dnsmasq zum Laufen bringen oder andere virtuelle Schnittstelle verwenden. In der "config"-Datei des Containers lautet die Einstellung dazu "lxc.network.link". Eventuell lässt sich virbr0 verwenden.

lxcbr0 verschwindet

Möglicherweise gibt es einen Konflikt mit eimem bereits laufenden DNS Server. Ich habe bind9 am Laufen und Folgendes hilft:

service bind9 stop
service lxc-net restart
service bind9 start

Container von einem Host zu einem anderen verschieben

• Container anhalten: lxc-stop -n containername
• In /var/lib/lxc folgendes Kommando ausführen: tar --numeric-owner -czf containername.tar.gz containername
• containername.tar.gz von einem Host zu anderen kopieren (zum Beispiel mit scp, rsync, curl oder wget, oder über SSHFS ein Verzeichnis der Gegenseite einbinden)
• Auf dem Zielhost muss die Datei in /var/lib/lxc landen
• In /var/lib/lxc muss tar --numeric-owner -xzf containername.tar.gz ausgeführt werden
  • Optional: tar-Datei mittels rm containername.tar.gz entfernen
• Container mit lxc-start -d -n containername starten
• In den Container mit lxc-attach -n containername -- bash einsteigen und dort eine Kommandozeile erhalten
• Prüfen, ob alle Dienste laufen (zum Beispiel mit netstat -tulpn oder die Ausgabe von systemctl status (wenn systemd zum Einsatz kommt) oder ps axf inspizieren)

Troubleshooting

Dies sollte nicht notwendig sein, wenn "--numeric-owner" ans tar-Kommando übergeben wurde.

Beispiel: MySql ist installiert, aber nach dem Verschieben startet das Service nicht mehr.

Im Originalcontainer könnte ps axf | grep mysql eine Zeile wie die folgende ausgeben:

 1531 ?        Sl     0:40  \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306

Wird das selbe Kommando im verschobenen Container ausgeführt, könnte die Ausgabe wie folgt aussehen:

171112 17:50:01 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
171112 17:50:01 [Note] /usr/sbin/mysqld (mysqld 5.5.57-0+deb7u1) starting as process 2140 ...
171112 17:50:01 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
171112 17:50:01 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
171112 17:50:01 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
171112 17:50:01 InnoDB: The InnoDB memory heap is disabled
171112 17:50:01 InnoDB: Mutexes and rw_locks use GCC atomic builtins
171112 17:50:01 InnoDB: Compressed tables use zlib 1.2.7
171112 17:50:01 InnoDB: Using Linux native AIO
171112 17:50:01 InnoDB: Initializing buffer pool, size = 128.0M
171112 17:50:01 InnoDB: Completed initialization of buffer pool
171112 17:50:01  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.

Wenn man ls -lh ./var/lib/mysql/mysql/plugin.frm ausführt könnte etwa folgende Ausgabe erscheinen:

-rw-rw---- 1 106 110 8,4K Aug 14 09:28 ./var/lib/mysql/mysql/plugin.frm

• Was ist das Problem? An der Stelle, an der normalerweise der Besitzer und die besitzende Gruppe der Datei stehen, steht "106" und "110".
• Wie konnte das passieren? Das tar-Kommando konnte die Besitzerinformationen nicht richtig auflösen. Das ist eine bekannte Falle in Linux und anderen Unix-artigen Systemen: der Benutzer "mysql" könnte auf jedem System eine andere UID haben (id -u mysql zeigt die UID dazu an). Desweiteren wurde das tar-Kommando auf dem LXC host ausgeführt, welcher im vorliegenden Fall keinen Benutzer "mysql" hatte.

Mit "cd /" wechselt man ins Root-Verzeichnis des Dateisystems und führt folgende Befehle aus:

find -uid 106 -exec chown mysql {} \;
find -gid 110 -exec chgrp mysql {} \;

Wenn das obere ls-Kommando andere Werte als 106 und 110 ausgegeben hat müssen die Werte entsprechend ersetzt werden.

Links

• Containers: Just Because Everyone Else is Doing Them Wrong, Doesn't Mean You Have To
• LXC in ubuntuusers.de (German)
• LXC in Debian Wiki