/|\

Welcome to the Slackware Documentation Project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
howtos:misc:lxc [2018/10/19 22:00 (UTC)]
mralk3
howtos:misc:lxc [2019/12/28 02:28 (UTC)] (current)
montagdude Move running GUI applications section out of Configuration section
Line 145: Line 145:
 ==== Custom Container Boot Process ==== ==== Custom Container Boot Process ====
  
-In order to customize the boot process you can add or modify the init scripts listed in **/usr/share/lxc/scripts/slackware**.  Any changes you make to the existing scripts will be copied to **/etc/rc.d/** in each freshly created LXC container.  This will allow you to easily customize the boot process if you create many LXC containers.  A good example is if you add a custom rc.inet1.conf.  It can become a bit tedious if you wish to create several LXC containers that all use DHCP network addressing.  The solution is to create your own rc.inet1.conf, set **USE_DHCP[0]="yes"**, named it **rc.inet1.conf.lxc**, and save it in **/usr/share/lxc/scripts/slackware**.  Your custom rc.inet1.conf will be copied to each new container.+In order to customize the boot process you can add or modify the init scripts listed in /usr/share/lxc/scripts/slackware.  Any changes you make to the existing scripts will be copied to /etc/rc.d/ in each freshly created LXC container.  This will allow you to easily customize the boot process if you create many LXC containers.  A good example is if you add a custom rc.inet1.conf.  It can become a bit tedious if you wish to create several LXC containers that all use DHCP network addressing.  The solution is to create your own rc.inet1.conf, set **USE_DHCP[0]="yes"**, named it rc.inet1.conf.lxc, and save it in /usr/share/lxc/scripts/slackware.  Your custom rc.inet1.conf will be copied to each new container.
  
 ==== Sharing Directories with the Host ==== ==== Sharing Directories with the Host ====
Line 156: Line 156:
  
 Note that the second path intentionally lacks a leading slash. This is because it is a relative path -- relative to the container's rootfs. Once you start the container again and log in, you should see that the directory has been mounted at /home/container_user/foo. In general, it is best if the username on the host is the same as the container's username, because it avoids any conflicts in file ownership between the host and container user. Note that the second path intentionally lacks a leading slash. This is because it is a relative path -- relative to the container's rootfs. Once you start the container again and log in, you should see that the directory has been mounted at /home/container_user/foo. In general, it is best if the username on the host is the same as the container's username, because it avoids any conflicts in file ownership between the host and container user.
 +
 +===== Running GUI Applications =====
 +
 +Without taking additional steps, it will not be possible to run GUI applications installed in the container. The simplest way to accomplish this is to run them using SSH with X forwarding to the host. However, there are still a few steps required to make this happen. In the container, in /etc/ssh/sshd_config, set the following:
 +
 +<code>
 +X11Forwarding yes                                                                                                                      
 +X11UseLocalhost yes
 +</code>
 +
 +This will allow X forwarding via SSH from the container. (Note: X11UseLocalhost yes is required; otherwise X will give an error about the DISPLAY not existing.) It is also necessary to bind-mount the host's /tmp/.X11-unix directory in the container. Add this line to the container's config file ($lxcpath/container_name/config):
 +
 +<code>
 +lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir
 +</code>
 +
 +Next, restart the container. Upon restart, use `lxc-ls --fancy` to determine the container's IP address. You can then run GUI apps from the container as follows:
 +
 +<code>
 +ssh -Y user@IP appname
 +</code>
 +
 +This is probably the simplest way to run GUI apps in the container. However, more advanced usage is possible, including using LXC to "sandbox" applications in an unprivileged container and/or running GUI applications directly in the container without connecting over SSH. For more information, the following page is a good start:
 +
 +[[https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/|LXC 1.0: GUI in containers [9/10]]]
  
 ====== See Also ====== ====== See Also ======
Line 166: Line 191:
  
 [[https://www.linuxquestions.org/questions/slackware-14/starting-lxc-container-in-slackware-14-2-a-4175614421/|LQ thread]] [[https://www.linuxquestions.org/questions/slackware-14/starting-lxc-container-in-slackware-14-2-a-4175614421/|LQ thread]]
 +
 +[[https://stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/|LXC 1.0: GUI in containers [9/10]]]
  
 ====== Sources ====== ====== Sources ======

In Other Languages
QR Code
QR Code howtos:misc:lxc (generated for current page)