Alpine Linux - User contributions [en]

LXC

2023-03-03T20:48:32Z

Juef: /* Creating a LXC container without modifying your network interfaces */ fix typo

[https://linuxcontainers.org/ Linux Containers (LXC)] provides containers similar to BSD Jails, Linux VServers and Solaris Zones. It gives the impression of virtualization, but shares the kernel and resources with the "host". You can use lxc directly or through [[LXD]].

== Installation ==
Install the required packages:
{{Cmd|apk add lxc bridge lxcfs lxc-download xz}}

If you want to create containers other than Alpine, you'll need lxc-templates:

{{Cmd|apk add lxc-templates}}

== Upgrading from 2.x ==

Starting with Alpine 3.9, we ship LXC version 3.1.
LXC 3.x has major changes which can and will break your current setup.
LXC 3.x will NOT ship with legacy container templates. Check your current container configs to see if you have any includes pointing to files that don't exist (shipped by legacy templates).
For example if you use Alpine containers created with the Alpine template, you'll need to install:

apk add lxc-templates-legacy-alpine

Also make sure you convert your LXC config files to the new 2.x format (this is now required).

lxc-update-config -c /var/lib/lxc/container-name/config

Make sure you have removed '''cgroup_enable''' from your cmdline as this will fail to mount cgroups and fail LXC service.

== Prepare network on host ==
Set up a [[bridge]] on the host. Example ''/etc/network/interfaces'':
<pre>
auto br0
iface br0 inet dhcp
bridge-ports eth0
</pre>

Create a network configuration template for the guests, ''/etc/lxc/default.conf'':
<pre>
lxc.net.0.type = veth
lxc.net.0.link = br0
lxc.net.0.flags = up
lxc.net.0.hwaddr = fe:xx:xx:xx:xx:xx
</pre>

== Create a guest ==

=== Picking from the list ===

{{Cmd|lxc-create -n guest1 -f /etc/lxc/default.conf -t download}}

And just pick from the list. lxc-download and xz can be uninstalled after you are done.

=== Alpine Template ===

{{Cmd|lxc-create -n guest1 -f /etc/lxc/default.conf -t alpine}}

This will create a ''/var/lib/lxc/guest1'' directory with a ''config'' file and a ''rootfs'' directory.

Note: by default, the alpine template '''does not have networking service on''', you will need to add it using lxc-console

If running on x64 compatible hardware, it is possible to create a 32bit guest:

{{Cmd|lxc-create -n guest1 -f /etc/lxc/default.conf -t alpine -- --arch x86}}

=== Debian template ===

In order to create a debian template container you'll need to install some packages:

{{Cmd|apk add debootstrap rsync}}

You'll need to turn off some grsecurity chroot options otherwise the debootstrap will fail:

{{Cmd|echo 0 > /proc/sys/kernel/grsecurity/chroot_caps
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chroot
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chmod
}}

Remember to turn them back on, or simply reboot.

Now you can run:
{{Cmd|SUITE{{=}}wheezy lxc-create -n guest1 -f /etc/lxc/default.conf -t debian}}

==== Setting a static IP ====
Since Debian Bullseye 11.3 you can't assign a static IP address using the lxc config file of the container [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009351 because of a systemd change].
To make it work with a configuration like the following

# grep net /var/lib/lxc/bullseye/config
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = virbr1
lxc.net.0.ipv4.address = 192.168.1.111/24
lxc.net.0.ipv4.gateway = 192.168.1.1

You have to attach to the container and run

{{Cmd|lxc-attach -n bullseye
systemctl stop systemd-networkd
systemctl disable systemd-networkd
reboot
}}

After the reboot the IP address should be set correctly. This can be confirmed using the lxc-ls command

{{Cmd|# lxc-ls -f
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
bullseye RUNNING 1 - 192.168.1.111 - false
}}

=== Ubuntu template ===

In order to create an ubuntu template container, you'll need to turn off some grsecurity chroot options:

{{Cmd|echo 0 > /proc/sys/kernel/grsecurity/chroot_caps
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chroot
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chmod
}}

Remember to turn them back on, or simply reboot.

Now you can run (replace %MIRROR% with the actual hostname, for example: http://us.archive.ubuntu.com/ubuntu/)

{{Cmd|lxc-create -n guest2 -f /etc/lxc/default.conf -t ubuntu -- -r xenial -a amd64 -u user --password secretpassword --mirror $MIRROR }}

{{Warning|Be sure to set systemd_container to yes in /etc/conf.d/lxc.CONTAINER. Otherwise, most functionality will be broken}}

=== Unprivileged LXC images (Alpine / Debian / Ubuntu / Centos etc..) ===

To enable unprivileged containers, one must create a uidgid map:

echo root:1000000:65536 | tee -a /etc/subuid
echo root:1000000:65536 | tee -a /etc/subgid

This creates a uid and gid map for the root user starting at 1000000 with a size of 65536.

To configure containers to use this mapping, add the following lines to the configuration:

lxc.idmap = u 0 1000000 65536
lxc.idmap = g 0 1000000 65536

This can be in the global or container-specific configuration.

To create an unprivileged lxc container, you need to use the download template. The download template must be installed:

{{Cmd|apk add gnupg xz lxc-download
lxc-create -n container-name -t download}}
choose the Distribution | Release | Architecture.

To be able to log in to a Debian container, you currently need to:
{{Cmd|rm /lib/systemd/system/container-getty\@.service}}

You can also [https://without-systemd.org/wiki/index_php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation/ remove Systemd from the container].

== Starting/Stopping the guest ==

First, you should enable the cgroup script:

{{Cmd|rc-update add cgroups}}

If you don't want to reboot, you can start the service by running

{{Cmd|rc-service cgroups start}}

Create a symlink to the ''/etc/init.d/lxc'' script for your guest.
{{Cmd|ln -s lxc /etc/init.d/lxc.guest1}}

You can start your guest with:
{{Cmd|/etc/init.d/lxc.guest1 start}}

Stop it with:
{{Cmd|/etc/init.d/lxc.guest1 stop}}

Make it autostart at boot-up with:
{{Cmd| rc-update add lxc.guest1}}

You can add to the container config: <code>lxc.start.auto = 1</code>

{{Cmd|rc-update add lxc}}

to autostart containers with the lxc service only.

== Connecting to the guest ==
By default, sshd is not installed. You'll have to attach to the container or connect to the virtual console. This is done with:

{{Cmd|lxc-attach -n guest1}}

Type exit to detach from the container again (please check the grsec notes above)

== Connect to virtual console ==

{{Cmd|lxc-console -n guest1}}

To disconnect, press {{key|Ctrl}}+{{key|a}} {{key|q}}

== Deleting a guest ==
Make sure the guest is stopped, then run:
{{Cmd|lxc-destroy -n guest1}}
This will erase everything, without asking any questions. It is equivalent to: {{Cmd|rm -r /var/lib/lxc/guest1}}

== Advanced ==

=== Creating a LXC container without modifying your network interfaces ===

The problem with bridging is that the interface you bridge gets replaced with your new bridge interface.
Let's say you have interface eth0 that you want to bridge. Your eth0 interface gets replaced with the br0 interface that you create. It also means that the interface you use needs to be placed into promiscuous mode to catch all the traffic that could be destined to the other side of the bridge, which may not be what you want.

The solution is to create a dummy network interface, bridge that, and set up NAT so that traffic out of your bridge interface gets pushed through the interface of your choice.

Let's create that dummy interface (thanks to ncopa for talking me out of macvlan and pointing out the dummy interface kernel module)

{{Cmd|modprobe dummy}}

This will create a dummy interface called dummy0 on your host. To create this interface on every boot, append "dummy" to /etc/modules:

Now we will create a bridge called br0

{{Cmd |brctl addbr br0
brctl setfd br0 0 }}

and then make that dummy interface one end of the bridge

{{Cmd | brctl addif br0 dummy0 }}

Next, let's give that bridged interface a reason to exist:

{{ Cmd | ifconfig br0 192.168.1.1 netmask 255.255.255.0 up}}

Create a file for your container. Let's say /etc/lxc/bridgenat.conf, with the following settings.

<pre>
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.name = eth1
lxc.net.0.ipv4.address = 192.168.1.2/24 192.168.1.255
lxc.net.0.ipv4.gateway = 192.168.1.1
lxc.net.0.veth.pair = veth-if-0
</pre>

and build your container with that file:

{{ Cmd | lxc-create -n alpine -f /etc/lxc/bridgenat.conf -t alpine }}

You should now be able to ping your container from your host, and your host from your container.

Your container needs to know where to push traffic that isn't within it's subnet. To do so, we tell the container to route through the bridge interface, br0
From inside the container run

{{ Cmd | route add default gw 192.168.1.1 }}

The next step is to push the traffic coming from your private subnet over br0 out through your internet facing interface, or any interface you chose

We are messing with your IP tables here, so make sure these settings don't conflict with anything you may have already set up.

Say eth0 was your internet facing network interface, and br0 is the name of the bridge you made earlier. We'd do this:

{{ Cmd | echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface br0 -j ACCEPT
}}

Now you should be able to route through your bridge interface to the internet facing interface of your host from your container, just like at home!

You could also have a dhcp server running on your host, and set it up to give IP addresses from your private subnet to any container that requests it, and then have one template for multiple alpine LXC containers, perfect for alpine development :)

=== Using static IP ===

If you're using static IP, you need to configure this properly on the guest /etc/network/interfaces. To stay in line with the above example, modify ''/var/lib/lxc/guest1/rootfs/etc/network/interfaces''

from

#auto lo
iface lo inet loopback
auto eth0
iface eth0 inet '''dhcp'''

to

#auto lo
iface lo inet loopback
auto eth0
iface eth0 inet '''static'''
address <lxc-container-ip> # IP which the lxc container should use
gateway <gateway-ip> # IP of gateway to use, mostly same as on lxc-host
netmask <netmask>

=== mem and swap ===

{{Cmd|vim /boot/extlinux.conf}}

{{Cmd|
APPEND initrd{{=}}initramfs-3.10.13-1-grsec root{{=}}UUID{{=}}7cd8789f-5659-40f8-9548-ae8f89c918ab modules{{=}}sd-mod,usb-storage,ext4 quiet cgroup_enable{{=}}memory swapaccount{{=}}1
}}

=== checkconfig ===
{{Cmd|lxc-checkconfig}}

{{Cmd|
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.10.13-1-grsec
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: missing
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: missing
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG{{=}}/path/to/config /usr/bin/lxc-checkconfig

}}

=== VirtualBox ===

In order for the network to work on containers, you need to set "Promiscuous Mode" to "Allow All" in VirtualBox settings for the network adapter.

[[File:VirtualBoxNetworkAdapter.jpg]]

[[Category:Virtualization]]

=== postgreSQL ===

Inside the container run: {{Cmd|chmod go+w /dev/null}} to fix {{Cmd|rc-service postgresql start}}

=== openVPN ===

see [[Setting_up_a_OpenVPN_server#openVPN_and_LXC]]

== LXC 1.0 Additional information ==

Some info regarding new features in LXC 1.0

https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/

== See also ==
* [[Howto-lxc-simple]]

LXC

2023-03-03T20:45:58Z

Juef: fix broken link

[https://linuxcontainers.org/ Linux Containers (LXC)] provides containers similar to BSD Jails, Linux VServers and Solaris Zones. It gives the impression of virtualization, but shares the kernel and resources with the "host". You can use lxc directly or through [[LXD]].

== Installation ==
Install the required packages:
{{Cmd|apk add lxc bridge lxcfs lxc-download xz}}

If you want to create containers other than Alpine, you'll need lxc-templates:

{{Cmd|apk add lxc-templates}}

== Upgrading from 2.x ==

Starting with Alpine 3.9, we ship LXC version 3.1.
LXC 3.x has major changes which can and will break your current setup.
LXC 3.x will NOT ship with legacy container templates. Check your current container configs to see if you have any includes pointing to files that don't exist (shipped by legacy templates).
For example if you use Alpine containers created with the Alpine template, you'll need to install:

apk add lxc-templates-legacy-alpine

Also make sure you convert your LXC config files to the new 2.x format (this is now required).

lxc-update-config -c /var/lib/lxc/container-name/config

Make sure you have removed '''cgroup_enable''' from your cmdline as this will fail to mount cgroups and fail LXC service.

== Prepare network on host ==
Set up a [[bridge]] on the host. Example ''/etc/network/interfaces'':
<pre>
auto br0
iface br0 inet dhcp
bridge-ports eth0
</pre>

Create a network configuration template for the guests, ''/etc/lxc/default.conf'':
<pre>
lxc.net.0.type = veth
lxc.net.0.link = br0
lxc.net.0.flags = up
lxc.net.0.hwaddr = fe:xx:xx:xx:xx:xx
</pre>

== Create a guest ==

=== Picking from the list ===

{{Cmd|lxc-create -n guest1 -f /etc/lxc/default.conf -t download}}

And just pick from the list. lxc-download and xz can be uninstalled after you are done.

=== Alpine Template ===

{{Cmd|lxc-create -n guest1 -f /etc/lxc/default.conf -t alpine}}

This will create a ''/var/lib/lxc/guest1'' directory with a ''config'' file and a ''rootfs'' directory.

Note: by default, the alpine template '''does not have networking service on''', you will need to add it using lxc-console

If running on x64 compatible hardware, it is possible to create a 32bit guest:

{{Cmd|lxc-create -n guest1 -f /etc/lxc/default.conf -t alpine -- --arch x86}}

=== Debian template ===

In order to create a debian template container you'll need to install some packages:

{{Cmd|apk add debootstrap rsync}}

You'll need to turn off some grsecurity chroot options otherwise the debootstrap will fail:

{{Cmd|echo 0 > /proc/sys/kernel/grsecurity/chroot_caps
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chroot
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chmod
}}

Remember to turn them back on, or simply reboot.

Now you can run:
{{Cmd|SUITE{{=}}wheezy lxc-create -n guest1 -f /etc/lxc/default.conf -t debian}}

==== Setting a static IP ====
Since Debian Bullseye 11.3 you can't assign a static IP address using the lxc config file of the container [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009351 because of a systemd change].
To make it work with a configuration like the following

# grep net /var/lib/lxc/bullseye/config
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = virbr1
lxc.net.0.ipv4.address = 192.168.1.111/24
lxc.net.0.ipv4.gateway = 192.168.1.1

You have to attach to the container and run

{{Cmd|lxc-attach -n bullseye
systemctl stop systemd-networkd
systemctl disable systemd-networkd
reboot
}}

After the reboot the IP address should be set correctly. This can be confirmed using the lxc-ls command

{{Cmd|# lxc-ls -f
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
bullseye RUNNING 1 - 192.168.1.111 - false
}}

=== Ubuntu template ===

In order to create an ubuntu template container, you'll need to turn off some grsecurity chroot options:

{{Cmd|echo 0 > /proc/sys/kernel/grsecurity/chroot_caps
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chroot
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chmod
}}

Remember to turn them back on, or simply reboot.

Now you can run (replace %MIRROR% with the actual hostname, for example: http://us.archive.ubuntu.com/ubuntu/)

{{Cmd|lxc-create -n guest2 -f /etc/lxc/default.conf -t ubuntu -- -r xenial -a amd64 -u user --password secretpassword --mirror $MIRROR }}

{{Warning|Be sure to set systemd_container to yes in /etc/conf.d/lxc.CONTAINER. Otherwise, most functionality will be broken}}

=== Unprivileged LXC images (Alpine / Debian / Ubuntu / Centos etc..) ===

To enable unprivileged containers, one must create a uidgid map:

echo root:1000000:65536 | tee -a /etc/subuid
echo root:1000000:65536 | tee -a /etc/subgid

This creates a uid and gid map for the root user starting at 1000000 with a size of 65536.

To configure containers to use this mapping, add the following lines to the configuration:

lxc.idmap = u 0 1000000 65536
lxc.idmap = g 0 1000000 65536

This can be in the global or container-specific configuration.

To create an unprivileged lxc container, you need to use the download template. The download template must be installed:

{{Cmd|apk add gnupg xz lxc-download
lxc-create -n container-name -t download}}
choose the Distribution | Release | Architecture.

To be able to log in to a Debian container, you currently need to:
{{Cmd|rm /lib/systemd/system/container-getty\@.service}}

You can also [https://without-systemd.org/wiki/index_php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation/ remove Systemd from the container].

== Starting/Stopping the guest ==

First, you should enable the cgroup script:

{{Cmd|rc-update add cgroups}}

If you don't want to reboot, you can start the service by running

{{Cmd|rc-service cgroups start}}

Create a symlink to the ''/etc/init.d/lxc'' script for your guest.
{{Cmd|ln -s lxc /etc/init.d/lxc.guest1}}

You can start your guest with:
{{Cmd|/etc/init.d/lxc.guest1 start}}

Stop it with:
{{Cmd|/etc/init.d/lxc.guest1 stop}}

Make it autostart at boot-up with:
{{Cmd| rc-update add lxc.guest1}}

You can add to the container config: <code>lxc.start.auto = 1</code>

{{Cmd|rc-update add lxc}}

to autostart containers with the lxc service only.

== Connecting to the guest ==
By default, sshd is not installed. You'll have to attach to the container or connect to the virtual console. This is done with:

{{Cmd|lxc-attach -n guest1}}

Type exit to detach from the container again (please check the grsec notes above)

== Connect to virtual console ==

{{Cmd|lxc-console -n guest1}}

To disconnect, press {{key|Ctrl}}+{{key|a}} {{key|q}}

== Deleting a guest ==
Make sure the guest is stopped, then run:
{{Cmd|lxc-destroy -n guest1}}
This will erase everything, without asking any questions. It is equivalent to: {{Cmd|rm -r /var/lib/lxc/guest1}}

== Advanced ==

=== Creating a LXC container without modifying your network interfaces ===

The problem with bridging is that the interface you bridge gets replaced with your new bridge interface.
Let's say you have interface eth0 that you want to bridge. Your eth0 interface gets replaced with the br0 interface that you create. It also means that the interface you use needs to be placed into promiscuous mode to catch all the traffic that could de destined to the other side of the bridge, which may not be what you want.

The solution is to create a dummy network interface, bridge that, and set up NAT so that traffic out of your bridge interface gets pushed through the interface of your choice.

Let's create that dummy interface (thanks to ncopa for talking me out of macvlan and pointing out the dummy interface kernel module)

{{Cmd|modprobe dummy}}

This will create a dummy interface called dummy0 on your host. To create this interface on every boot, append "dummy" to /etc/modules:

Now we will create a bridge called br0

{{Cmd |brctl addbr br0
brctl setfd br0 0 }}

and then make that dummy interface one end of the bridge

{{Cmd | brctl addif br0 dummy0 }}

Next, let's give that bridged interface a reason to exist:

{{ Cmd | ifconfig br0 192.168.1.1 netmask 255.255.255.0 up}}

Create a file for your container. Let's say /etc/lxc/bridgenat.conf, with the following settings.

<pre>
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.name = eth1
lxc.net.0.ipv4.address = 192.168.1.2/24 192.168.1.255
lxc.net.0.ipv4.gateway = 192.168.1.1
lxc.net.0.veth.pair = veth-if-0
</pre>

and build your container with that file:

{{ Cmd | lxc-create -n alpine -f /etc/lxc/bridgenat.conf -t alpine }}

You should now be able to ping your container from your host, and your host from your container.

Your container needs to know where to push traffic that isn't within it's subnet. To do so, we tell the container to route through the bridge interface, br0
From inside the container run

{{ Cmd | route add default gw 192.168.1.1 }}

The next step is to push the traffic coming from your private subnet over br0 out through your internet facing interface, or any interface you chose

We are messing with your IP tables here, so make sure these settings don't conflict with anything you may have already set up.

Say eth0 was your internet facing network interface, and br0 is the name of the bridge you made earlier. We'd do this:

{{ Cmd | echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface br0 -j ACCEPT
}}

Now you should be able to route through your bridge interface to the internet facing interface of your host from your container, just like at home!

You could also have a dhcp server running on your host, and set it up to give IP addresses from your private subnet to any container that requests it, and then have one template for multiple alpine LXC containers, perfect for alpine development :)

=== Using static IP ===

If you're using static IP, you need to configure this properly on the guest /etc/network/interfaces. To stay in line with the above example, modify ''/var/lib/lxc/guest1/rootfs/etc/network/interfaces''

from

#auto lo
iface lo inet loopback
auto eth0
iface eth0 inet '''dhcp'''

to

#auto lo
iface lo inet loopback
auto eth0
iface eth0 inet '''static'''
address <lxc-container-ip> # IP which the lxc container should use
gateway <gateway-ip> # IP of gateway to use, mostly same as on lxc-host
netmask <netmask>

=== mem and swap ===

{{Cmd|vim /boot/extlinux.conf}}

{{Cmd|
APPEND initrd{{=}}initramfs-3.10.13-1-grsec root{{=}}UUID{{=}}7cd8789f-5659-40f8-9548-ae8f89c918ab modules{{=}}sd-mod,usb-storage,ext4 quiet cgroup_enable{{=}}memory swapaccount{{=}}1
}}

=== checkconfig ===
{{Cmd|lxc-checkconfig}}

{{Cmd|
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.10.13-1-grsec
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: missing
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: missing
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG{{=}}/path/to/config /usr/bin/lxc-checkconfig

}}

=== VirtualBox ===

In order for the network to work on containers, you need to set "Promiscuous Mode" to "Allow All" in VirtualBox settings for the network adapter.

[[File:VirtualBoxNetworkAdapter.jpg]]

[[Category:Virtualization]]

=== postgreSQL ===

Inside the container run: {{Cmd|chmod go+w /dev/null}} to fix {{Cmd|rc-service postgresql start}}

=== openVPN ===

see [[Setting_up_a_OpenVPN_server#openVPN_and_LXC]]

== LXC 1.0 Additional information ==

Some info regarding new features in LXC 1.0

https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/

== See also ==
* [[Howto-lxc-simple]]

Installation

2018-02-25T17:23:48Z

Juef: /* Advanced */ remove double comma after Qemu

The following information will assist you with the installation of [http://alpinelinux.org/about Alpine Linux].
[[Image:hdd_mount.png|left|link=]]
<br />

== Installation Quick-Start in 3 Easy Steps ==
<div style="float:left; font-size:30px; font-weight:bold;">
1st
</div>
<div style="margin-left:65px; background-color:#EDF2F2; border-style:solid; border-color:#6F7C91; border-width:0px; border-left-width:5px; min-height:55px; padding:5px;">
[http://alpinelinux.org/downloads Download] the latest stable-release ISO.
</div>

<div style="float:left; font-size:30px; font-weight:bold;">
2nd
</div>
<div style="margin-left:65px; background-color:#E0E9E9; border-style:solid; border-color:#606A82; border-width:0px; border-left-width:5px; min-height:55px; padding:5px;">
If you have a CD drive from which you can boot, then [[Burning ISOs|burn the ISO onto a blank CD]] using your favorite CD burning software. Else [[Create a Bootable USB|create a bootable USB drive]].
</div>

<div style="float:left; font-size:30px; font-weight:bold;">
3rd
</div>
<div style="margin-left:65px; background-color:#9faecc; border-style:solid; border-color:#324065; border-width:0px; border-left-width:5px; min-height:55px; padding:5px;">
Boot from the CD or USB drive, login as root with no password, and voilà! Enjoy Alpine Linux!
</div>

{{Clear}}
One of the [[Installation#Post-Install|first commands you might want to use]] is <code>[[setup-alpine]]</code>.

== Installation Handbook ==
=== Basics ===
Alpine can be used in any of three modes:
<dl>
<dt>diskless mode
<dd>You'll boot from read-only medium such as the installation CD, a [[Create a Bootable USB|USB drive]], or a [[Create a Bootable Compact Flash|Compact Flash card]]. {{Tip| To prepare either a USB or Compact Flash card, you can use the <code>[[setup-bootable]]</code> script; see the pages linked above for details.}} When you use Alpine in this mode, you need to use [[Alpine local backup|Alpine Local Backup (lbu)]] to save your modifications between reboots. That requires some writable medium, usually removable. (If your boot medium is, for example, a USB drive, you can save modifications there; you don't need a separate partition or drive.) See also [[Local APK cache]].
{{Note| When the <code>[[setup-alpine]]</code> script asks for a disk, say "none". It will then prompt whether you'd like to preserve modifications on any writable medium.}}
<dt>data mode
<dd>As in diskless mode, your OS is run from a read-only medium. However, here a writable partition (usually on a hard disk) is used to store the data in {{Path|/var}}. That partition is accessed directly, rather than copied into a tmpfs; so this is better-suited to uses where large amounts of data need to be preserved between reboots. {{Note| The <code>[[setup-alpine]]</code> script handles installing Alpine in this mode, too, when you supply a writable partition instead of "none", and request mode "data".}} This mode may be used for mailspools, database and log servers, and so on.
<dt>sys mode
<dd>This is a [[Install to disk|traditional hard-disk install]] (see link for details).  Both the boot system and your modifications are written to the hard disk, in a standard Linux hierarchy. {{Note| The <code>[[setup-alpine]]</code> script handles installing Alpine in this mode, too, when you supply a writable partition instead of "none", and request mode "sys". By default, it will create three partions on your disk, for {{Path|/boot}}, {{Path|/}}, and {{Path|swap}}; however you can also [[Setting up disks manually|partition your disk manually]].
}} This mode may be used for desktops, development boxes, and virtual servers.

</dl>

=== Advanced ===
* [[Create UEFI boot USB]]
* [[Tutorials_and_Howtos#Storage|Setting up storage with RAID, LVM, LUKS encryption, iSCSI, or suchlike]]
* [[Setting up disks manually]]
* [[Partitioning and Bootmanagers]]
* [[Migrating data]]
* Details about [[Alpine setup scripts]]

* [[Installing Alpine on HDD dualbooting|Install to HDD with dual-boot]]
* [[Create A VirtualBox Guest with Grub and XFS]]
* [[Replacing non-Alpine Linux with Alpine remotely]]



* [[Bootstrapping Alpine Linux]]


* [[Installing Alpine Linux in a chroot]]
* [[Install Alpine on LXC]]
* [[Install Alpine on LXD|Install Alpine on Ubuntu with LXD]]
* Install Alpine on [[Install Alpine on VirtualBox|VirtualBox]], [[Install Alpine on VMware|VMware]], [[Install Alpine on coLinux|coLinux]], [[Qemu]],  [[Install Alpine on Amazon EC2|Amazon EC2]], or [[Install Alpine on Rackspace|RackSpace]]

* [[Xen Dom0]] ''(Setting up Alpine as a dom0 for Xen hypervisor)''
* [[Xen Dom0 on USB or SD]]
* [[Create Alpine Linux PV DomU]]
* [[Xen LiveCD]]

* [[Setting up a basic vserver]]
* [[Setting up the build environment on HDD]]
* [[Setting up a compile vserver]] for official or for [[Setting up a compile vserver for third party packages|third party]] packages


=== Post-Install ===



* [[Tutorials_and_Howtos#Networking|Setting up Networking]]
* [[Alpine Linux package management|Package Management (apk)]] ''(How to add/remove packages on your Alpine)''

* [[Alpine local backup|Alpine local backup (lbu)]] ''(Permanently store your modifications in case your box needs reboot)''
** [[Back Up a Flash Memory Installation|Back Up a Flash Memory ("diskless mode") Installation]]
** [[Manually editing a existing apkovl]]
* [[Alpine Linux Init System|Init System (OpenRC)]] ''(Configure a service to automatically boot at next reboot)''
** [[Multiple Instances of Services]]

* [[Alpine setup scripts#setup-xorg-base|Setting up Xorg]]

* [[Upgrading Alpine]]


* [[Setting up a ssh-server]] ''(Using ssh is a good way to administer your box remotely)''
* [[setup-acf]] ''(Configures ACF (webconfiguration) so you can manage your box through https)''
* [[Hosting services on Alpine]]''(Links to several mail/web/ssh server setup pages)''
* [[Changing passwords for ACF|Changing passwords]]


* [[Setting the timezone]] ''(Not needed for the default musl- or uClibc-based installs)''

=== Further Help and Information ===
* [[FAQ|FAQs]]
* [[Tutorials and Howtos]]
* [[Contribute|How to Contribute]]
* [[Developer Documentation]]

[[Category:Installation]]

Install Alpine on VMware Workstation

2018-02-23T17:49:26Z

Juef: fix a link

# Create a virtual machine (linux, other 3.x kernel 64 bit)
## add a minimal hard drive, 100MB for saving configs, (like an usb stick)
## add a cdrom to the vm that points to the alpine iso you downloaded (alpine-virt x86_64)
# boot into the vm
# press f2 on boot to enter the BIOS
## change the boot order so that it boots from cd, then hd, then floppy (or whatever - as long as cd is first)
# boot the machine
# now run the following commands:
## mkfs.vfat /dev/sda
## mount /dev/sda /media/usb (Or try: mount -t vfat /dev/sda /media/usb)
## grep /dev/sda /proc/mounts >> /etc/fstab
## setup-alpine (select no disk, save configs to 'usb')
## lbu ci usb

If the VM hangs at the boot prompt, reboot the VM, and when the boot prompt appears again, type <tt>pax_nouderef</tt> (i.e. append it to the kernel options) and press Enter. This should allow normal boot-up. <br />

Now you should be able to reboot and it should retain your settings because they were saved to your "usb"-disk.

For VMware Tools support you need to install the package [https://pkgs.alpinelinux.org/package/edge/main/x86_64/open-vm-tools open-vm-tools].

[[Category:Virtualization]]

LXC

2018-01-27T13:19:25Z

Juef: fix a typo

[https://linuxcontainers.org/ Linux Containers (LXC)] provides containers similar BSD Jails, Linux VServer and Solaris Zones. It gives the impression of virtualization, but shares the kernel and resources with the "host".

== Installation ==
Install the required packages:
{{Cmd|apk add lxc bridge}}

If you want to create containers other than alpine you will need lxc-templates:

{{Cmd|apk add lxc-templates}}

== Prepare network on host ==
Set up a [[bridge]] on the host. Example ''/etc/network/interfaces'':
<pre>
auto br0
iface br0 inet dhcp
bridge-ports eth0
</pre>

Create a network configuration template for the guests, ''/etc/lxc/lxc.conf'':
<pre>
lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.hwaddr = fe:xx:xx:xx:xx:xx
</pre>

== Grsecurity restrictions ==

Some restrictions will be applied when using a grsecurity kernel (Alpine Linux default kernel).
The most notable is the use of lxc-attach which will not be allowed because of GRKERNSEC_CHROOT_CAPS.
To solve this we will have to disable this grsec restriction by creating a sysctl profile for lxc.
Create the following file ''/etc/sysctl.d/10-lxc.conf'' and add:
<pre>
kernel.grsecurity.chroot_caps = 0
</pre>

There are a few other restrictions that can prevent proper container functionality.
When things do not work as expected always check the kernel log with dmesg to see if grsec prevented things from happening.

Other possible restrictions are:

<pre>
kernel.grsecurity.chroot_deny_chroot = 0
kernel.grsecurity.chroot_deny_mount = 0
kernel.grsecurity.chroot_deny_mknod = 0
kernel.grsecurity.chroot_deny_chmod = 0
</pre>

When you finished creating your new sysctl profile you can apply it by restarting sysctl service

<pre>
rc-service sysctl restart
</pre>

NOTE: Always consult the [https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options Grsecurity documentation] before applying these settings.

== Create a guest ==

=== Alpine Template ===

{{Cmd|lxc-create -n guest1 -f /etc/lxc/lxc.conf -t alpine}}

This will create a ''/var/lib/lxc/guest1'' directory with a ''config'' file and a ''rootfs'' directory.

Note that by default alpine template '''does not have networking service on''', you will need to add it using lxc-console

If running on x86_64 architecture, it is possible to create a 32bit guest:

{{Cmd|lxc-create -n guest1 -f /etc/lxc/lxc.conf -t alpine -- --arch x86}}

=== Debian template ===

In order to create a debian template container you will need to install some packages:

{{Cmd|apk add debootstrap rsync}}

Also you will need to turn off some grsecurity chroot options otherwise the debootstrap will fail:

{{Cmd|echo 0 > /proc/sys/kernel/grsecurity/chroot_caps
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chroot
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chmod
}}

Please remember to turn them back on, or just simply reboot the system.

Now you can run:
{{Cmd|SUITE{{=}}wheezy lxc-create -n guest1 -f /etc/lxc/lxc.conf -t debian}}

=== Ubuntu template ===

In order to create an ubuntu template container you will need to turn off some grsecurity chroot options:

{{Cmd|echo 0 > /proc/sys/kernel/grsecurity/chroot_caps
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chroot
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chmod
}}

Please remember to turn them back on, or just simply reboot the system.

Now you can run (replace %MIRROR% with the actual hostname, for example: http://us.archive.ubuntu.com/ubuntu/)

lxc-create -n guest2 -f /etc/lxc/default.conf -t ubuntu -- -r xenial -a amd64 -u user --password secretpassword --mirror $MIRROR

=== Unprivileged LXC images (Debian / Ubuntu / Centos etc..) ===

{{Cmd|apk add gnupg xz
lxc-create -n container-name -t download}}
& choose the Distribution | Release | Architecture.

To be able to login to a Debian container you currently need to:
{{Cmd|rm /lib/systemd/system/container-getty\@.service}}

You can also [http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installationers remove Systemd from the container].

== Starting/Stopping the guest ==
Create a symlink to the ''/etc/init.d/lxc'' script for your guest.
{{Cmd|ln -s lxc /etc/init.d/lxc.guest1}}

You can start your guest with:
{{Cmd|/etc/init.d/lxc.guest1 start}}

Stop it with:
{{Cmd|/etc/init.d/lxc.guest1 stop}}

Make it autostart on boot up with:
{{Cmd| rc-update add lxc.guest1}}

You can also add to the container config: <code>lxc.start.auto = 1</code>

& {{Cmd|rc-update add lxc}}

to autostart containers by the lxc service only.

== Connecting to the guest ==
By default sshd is not installed, so you will have to attach to the container or connect to the virtual console. This is done with:

=== Attach to container ===

{{Cmd|lxc-attach -n guest1}}

Just type exit to detach the container again (please do check the grsec notes above)

=== Connect to virtual console ===

{{Cmd|lxc-console -n guest1}}

To disconnect from it, press {{key|Ctrl}}+{{key|a}} {{key|q}}

== Deleting a guest ==
Make sure the guest is stopped and run:
{{Cmd|lxc-destroy -n guest1}}
This will erase everything, without asking any questions. It is equivalent to: {{Cmd|rm -r /var/lib/lxc/guest1}}

== Advanced ==

=== Creating a LXC container without modifying your network interfaces ===

The problem with bridging is that the interface you bridge gets replaced with your new bridge interface.
That is to say that say you have an interface eth0 that you want to bridge, your eth0 interface gets replaced with the br0 interface that you create. It also means that the interface you use needs to be placed into promiscuous mode to catch all the traffic that could de destined to the other side of the bridge, which again may not be what you want.

The solution is to create a dummy network interface, bridge that, and set up NAT so that traffic out of your bridge interface gets pushed through the interface of your choice.

So, first, lets create that dummy interface (thanks to ncopa for talking me out of macvlan and pointing out the dummy interface kernel module)

{{Cmd|modprobe dummy}}

This will create a dummy interface called dummy0 on your host.

Now we will create a bridge called br0

{{Cmd |brctl addbr br0
brctl setfd br0 0 }}

and then make that dummy interface one end of the bridge

{{Cmd | brctl addif br0 dummy0 }}

Next, let's give that bridged interface a reason to exists

{{ Cmd | ifconfig br0 192.168.1.1 netmask 255.255.255.0 up}}

Create a file for your container, let's say /etc/lxc/bridgenat.conf, with the following settings.

<pre>
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth1
lxc.network.ipv4 = 192.168.1.2/24
</pre>

and build your container with that file

{{ Cmd | lxc-create -n alpine -f /etc/lxc/bridgenat.conf -t alpine }}

You should now be able to ping your container from your hosts, and your host from your container.

Your container needs to know where to push traffic that isn't within it's subnet. To do so, we tell the container to route through the bridge interface br0
From inside the container run

{{ Cmd | route add default gw 192.168.1.1 }}

The next step is you push the traffic coming from your private subnet over br0 out through your internet facing interface, or any interface you chose

We are messing with your IP tables here, so make sure these settings don't conflict with anything you may have already set up, obviously.

Say eth0 was your internet facing network interface, and br0 is the name of the bridge you made earlier, we'd do this:

{{ Cmd | echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface br0 -j ACCEPT
}}

Now you should be able to route through your bridge interface to the internet facing interface of your host from your container, just like at home!

You could also have a dhcp server running on your host, and set it up to give IP addresses from your private subnet to any container that requests it, and then have one template for multiple alpine LXC containers, perfect for alpine development :)

=== Using static IP ===

If you're using static IP, you need to configure this properly on guest's /etc/network/interfaces. To stay on the above example, modify ''/var/lib/lxc/guest1/rootfs/etc/network/interfaces''

from

#auto lo
iface lo inet loopback
auto eth0
iface eth0 inet '''dhcp'''

to

#auto lo
iface lo inet loopback
auto eth0
iface eth0 inet '''static'''
address <lxc-container-ip> # IP which the lxc container should use
gateway <gateway-ip> # IP of gateway to use, mostly same as on lxc-host
netmask <netmask>

=== mem and swap ===

{{Cmd|vim /boot/extlinux.conf}}

{{Cmd|
APPEND initrd{{=}}initramfs-3.10.13-1-grsec root{{=}}UUID{{=}}7cd8789f-5659-40f8-9548-ae8f89c918ab modules{{=}}sd-mod,usb-storage,ext4 quiet cgroup_enable{{=}}memory swapaccount{{=}}1
}}

=== checkconfig ===
{{Cmd|lxc-checkconfig}}

{{Cmd|
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.10.13-1-grsec
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: missing
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: missing
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG{{=}}/path/to/config /usr/bin/lxc-checkconfig

}}

=== VirtualBox ===

In order for network to work on containers you need to set "Promiscuous Mode" to "Allow All" in VirtualBox settings for the network adapter.

[[File:VirtualBoxNetworkAdapter.jpg]]

[[Category:Virtualization]]

=== postgreSQL ===

Inside the container run: {{Cmd|chmod go+w /dev/null}} to fix {{Cmd|rc-service postgresql start}}

=== openVPN ===

see [[Setting_up_a_OpenVPN_server#openVPN_and_LXC]]

== LXC 1.0 Additional information ==

Some info regarding new features in LXC 1.0

https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/

== See also ==
* [[Howto-lxc-simple]]

LXC

2018-01-27T13:18:19Z

Juef: update link to LXC homepage

[https://linuxcontainers.org/ Linux Containers (LXC)] provides containers similar BSD Jails, Linux VServer and Solaris Zones. It gives the impression of virtualization, but shares the kernel and resources with the "host".

== Installation ==
Install the required packages:
{{Cmd|apk add lxc bridge}}

If you want to create containers other then type alpine you will need lxc-templates

{{Cmd|apk add lxc-templates}}

== Prepare network on host ==
Set up a [[bridge]] on the host. Example ''/etc/network/interfaces'':
<pre>
auto br0
iface br0 inet dhcp
bridge-ports eth0
</pre>

Create a network configuration template for the guests, ''/etc/lxc/lxc.conf'':
<pre>
lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.hwaddr = fe:xx:xx:xx:xx:xx
</pre>

== Grsecurity restrictions ==

Some restrictions will be applied when using a grsecurity kernel (Alpine Linux default kernel).
The most notable is the use of lxc-attach which will not be allowed because of GRKERNSEC_CHROOT_CAPS.
To solve this we will have to disable this grsec restriction by creating a sysctl profile for lxc.
Create the following file ''/etc/sysctl.d/10-lxc.conf'' and add:
<pre>
kernel.grsecurity.chroot_caps = 0
</pre>

There are a few other restrictions that can prevent proper container functionality.
When things do not work as expected always check the kernel log with dmesg to see if grsec prevented things from happening.

Other possible restrictions are:

<pre>
kernel.grsecurity.chroot_deny_chroot = 0
kernel.grsecurity.chroot_deny_mount = 0
kernel.grsecurity.chroot_deny_mknod = 0
kernel.grsecurity.chroot_deny_chmod = 0
</pre>

When you finished creating your new sysctl profile you can apply it by restarting sysctl service

<pre>
rc-service sysctl restart
</pre>

NOTE: Always consult the [https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options Grsecurity documentation] before applying these settings.

== Create a guest ==

=== Alpine Template ===

{{Cmd|lxc-create -n guest1 -f /etc/lxc/lxc.conf -t alpine}}

This will create a ''/var/lib/lxc/guest1'' directory with a ''config'' file and a ''rootfs'' directory.

Note that by default alpine template '''does not have networking service on''', you will need to add it using lxc-console

If running on x86_64 architecture, it is possible to create a 32bit guest:

{{Cmd|lxc-create -n guest1 -f /etc/lxc/lxc.conf -t alpine -- --arch x86}}

=== Debian template ===

In order to create a debian template container you will need to install some packages:

{{Cmd|apk add debootstrap rsync}}

Also you will need to turn off some grsecurity chroot options otherwise the debootstrap will fail:

{{Cmd|echo 0 > /proc/sys/kernel/grsecurity/chroot_caps
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chroot
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chmod
}}

Please remember to turn them back on, or just simply reboot the system.

Now you can run:
{{Cmd|SUITE{{=}}wheezy lxc-create -n guest1 -f /etc/lxc/lxc.conf -t debian}}

=== Ubuntu template ===

In order to create an ubuntu template container you will need to turn off some grsecurity chroot options:

{{Cmd|echo 0 > /proc/sys/kernel/grsecurity/chroot_caps
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chroot
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mount
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_mknod
echo 0 > /proc/sys/kernel/grsecurity/chroot_deny_chmod
}}

Please remember to turn them back on, or just simply reboot the system.

Now you can run (replace %MIRROR% with the actual hostname, for example: http://us.archive.ubuntu.com/ubuntu/)

lxc-create -n guest2 -f /etc/lxc/default.conf -t ubuntu -- -r xenial -a amd64 -u user --password secretpassword --mirror $MIRROR

=== Unprivileged LXC images (Debian / Ubuntu / Centos etc..) ===

{{Cmd|apk add gnupg xz
lxc-create -n container-name -t download}}
& choose the Distribution | Release | Architecture.

To be able to login to a Debian container you currently need to:
{{Cmd|rm /lib/systemd/system/container-getty\@.service}}

You can also [http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installationers remove Systemd from the container].

== Starting/Stopping the guest ==
Create a symlink to the ''/etc/init.d/lxc'' script for your guest.
{{Cmd|ln -s lxc /etc/init.d/lxc.guest1}}

You can start your guest with:
{{Cmd|/etc/init.d/lxc.guest1 start}}

Stop it with:
{{Cmd|/etc/init.d/lxc.guest1 stop}}

Make it autostart on boot up with:
{{Cmd| rc-update add lxc.guest1}}

You can also add to the container config: <code>lxc.start.auto = 1</code>

& {{Cmd|rc-update add lxc}}

to autostart containers by the lxc service only.

== Connecting to the guest ==
By default sshd is not installed, so you will have to attach to the container or connect to the virtual console. This is done with:

=== Attach to container ===

{{Cmd|lxc-attach -n guest1}}

Just type exit to detach the container again (please do check the grsec notes above)

=== Connect to virtual console ===

{{Cmd|lxc-console -n guest1}}

To disconnect from it, press {{key|Ctrl}}+{{key|a}} {{key|q}}

== Deleting a guest ==
Make sure the guest is stopped and run:
{{Cmd|lxc-destroy -n guest1}}
This will erase everything, without asking any questions. It is equivalent to: {{Cmd|rm -r /var/lib/lxc/guest1}}

== Advanced ==

=== Creating a LXC container without modifying your network interfaces ===

The problem with bridging is that the interface you bridge gets replaced with your new bridge interface.
That is to say that say you have an interface eth0 that you want to bridge, your eth0 interface gets replaced with the br0 interface that you create. It also means that the interface you use needs to be placed into promiscuous mode to catch all the traffic that could de destined to the other side of the bridge, which again may not be what you want.

The solution is to create a dummy network interface, bridge that, and set up NAT so that traffic out of your bridge interface gets pushed through the interface of your choice.

So, first, lets create that dummy interface (thanks to ncopa for talking me out of macvlan and pointing out the dummy interface kernel module)

{{Cmd|modprobe dummy}}

This will create a dummy interface called dummy0 on your host.

Now we will create a bridge called br0

{{Cmd |brctl addbr br0
brctl setfd br0 0 }}

and then make that dummy interface one end of the bridge

{{Cmd | brctl addif br0 dummy0 }}

Next, let's give that bridged interface a reason to exists

{{ Cmd | ifconfig br0 192.168.1.1 netmask 255.255.255.0 up}}

Create a file for your container, let's say /etc/lxc/bridgenat.conf, with the following settings.

<pre>
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth1
lxc.network.ipv4 = 192.168.1.2/24
</pre>

and build your container with that file

{{ Cmd | lxc-create -n alpine -f /etc/lxc/bridgenat.conf -t alpine }}

You should now be able to ping your container from your hosts, and your host from your container.

Your container needs to know where to push traffic that isn't within it's subnet. To do so, we tell the container to route through the bridge interface br0
From inside the container run

{{ Cmd | route add default gw 192.168.1.1 }}

The next step is you push the traffic coming from your private subnet over br0 out through your internet facing interface, or any interface you chose

We are messing with your IP tables here, so make sure these settings don't conflict with anything you may have already set up, obviously.

Say eth0 was your internet facing network interface, and br0 is the name of the bridge you made earlier, we'd do this:

{{ Cmd | echo 1 > /proc/sys/net/ipv4/ip_forward
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface br0 -j ACCEPT
}}

Now you should be able to route through your bridge interface to the internet facing interface of your host from your container, just like at home!

You could also have a dhcp server running on your host, and set it up to give IP addresses from your private subnet to any container that requests it, and then have one template for multiple alpine LXC containers, perfect for alpine development :)

=== Using static IP ===

If you're using static IP, you need to configure this properly on guest's /etc/network/interfaces. To stay on the above example, modify ''/var/lib/lxc/guest1/rootfs/etc/network/interfaces''

from

#auto lo
iface lo inet loopback
auto eth0
iface eth0 inet '''dhcp'''

to

#auto lo
iface lo inet loopback
auto eth0
iface eth0 inet '''static'''
address <lxc-container-ip> # IP which the lxc container should use
gateway <gateway-ip> # IP of gateway to use, mostly same as on lxc-host
netmask <netmask>

=== mem and swap ===

{{Cmd|vim /boot/extlinux.conf}}

{{Cmd|
APPEND initrd{{=}}initramfs-3.10.13-1-grsec root{{=}}UUID{{=}}7cd8789f-5659-40f8-9548-ae8f89c918ab modules{{=}}sd-mod,usb-storage,ext4 quiet cgroup_enable{{=}}memory swapaccount{{=}}1
}}

=== checkconfig ===
{{Cmd|lxc-checkconfig}}

{{Cmd|
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-3.10.13-1-grsec
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: missing
Network namespace: enabled
Multiple /dev/pts instances: enabled

--- Control groups ---
Cgroup: enabled
Cgroup clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: missing
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG{{=}}/path/to/config /usr/bin/lxc-checkconfig

}}

=== VirtualBox ===

In order for network to work on containers you need to set "Promiscuous Mode" to "Allow All" in VirtualBox settings for the network adapter.

[[File:VirtualBoxNetworkAdapter.jpg]]

[[Category:Virtualization]]

=== postgreSQL ===

Inside the container run: {{Cmd|chmod go+w /dev/null}} to fix {{Cmd|rc-service postgresql start}}

=== openVPN ===

see [[Setting_up_a_OpenVPN_server#openVPN_and_LXC]]

== LXC 1.0 Additional information ==

Some info regarding new features in LXC 1.0

https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/

== See also ==
* [[Howto-lxc-simple]]

Setting up disks manually

2018-01-27T12:25:21Z

Juef: fix a typo

{{Draft|Some information on this page may be incomplete or outdate.}}

You may have complex needs that aren't handled automatically by the [[Alpine Setup Scripts]]. In those cases, you'll need to prepare your disks manually.

It is possible to have one or more of RAID, encryption, and/or LVM on your {{Path|/}} (root) volume. However, the Alpine init script only knows how to handle them when they're layered in that order, and your initram and extlinux.conf file in the {{Path|/boot}} partition are configured properly.

Your {{Path|/boot}} cannot reside on an encrypted or LVM volume, at least not with Alpine's default bootloader (extlinux). (Grub2 can deal with {{Path|/boot}} being on an LVM volume.) The usual practice is to create a small partition for {{Path|/boot}}, and then devote the rest of your disk to a separate partition on which you layer one or more of RAID, encryption, and/or LVM.

Sometimes {{Path|/boot}} is also setup as a mirrored (RAID1) volume, however this is just for post-init access. That way, when you write a new kernel or bootloader config file to {{Path|/boot}}, it gets written to multiple physical partitions. During the pre-init, bootloader phase, only one of those partitions will be read from.

So, typical setups might look like this:

<pre>
One-disk system
---------------
+------------------------------------------------+
| small partition (32--100M), holding |
| only /boot, filesystem needn't be journaled |
+------------------------------------------------+
| rest of disk in second partition |
| +------------------------------------------+ |
| | cryptsetup volume | |
| | +-------------------------------------+ | |
| | | LVM PV, containing single VG, | | |
| | | containing multiple LVs, holding | | |
| | | /, /home, swap, etc | | |
| | +-------------------------------------+ | |
| +------------------------------------------+ |
+------------------------------------------------+

Two-disk system
---------------
+------------------------------------------------+ +------------------------------------------------+
| small partition (32--100M), holding | | small partition (32--100M), holding | These 2 partitions might
| only /boot, filesystem needn't be journaled | | only /boot, filesystem needn't be journaled | form a mirrored (RAID1)
+------------------------------------------------+ +------------------------------------------------+ volume
| rest of disk in second partition | | rest of disk in second partition |
| T================================================================================================T | These 2 partitions form
| T +--------------------------------------------------------------------------------------------+ T | a second mirrored
| T | cryptsetup volume | T | (RAID1) volume
| T | +---------------------------------------------------------------------------------------+ | T |
| T | | LVM PV, containing single VG, | | T |
| T | | containing multiple LVs, holding | | T |
| T | | /, /home, swap, etc | | T |
| T | +---------------------------------------------------------------------------------------+ | T |
| T +--------------------------------------------------------------------------------------------+ T |
| T================================================================================================T |
| | | |
+------------------------------------------------+ +------------------------------------------------+

</pre>

In a three-disk system, the {{Path|/boot}} would still be RAID1, but the larger partition might in that case be RAID5.

=== RAID ===
<code>setup-disk</code> will automatically build a RAID array if you supply the '''-r''' switch, or if you specify more than one device.

If you instead want to build your RAID array manually, see [[Setting up a software RAID array]]. Then you can add additional layers of encryption and/or LVM, or just assemble the RAID array, and supply the {{Path|/dev/md<i>i</i>}} device directly to [[setup-disk]]. When you're finished, be sure to disassemble the RAID array before rebooting.

If <code>setup-disk</code> sees that you're using RAID---either because you gave it the <code>-r</code> switch, or multiple devices, or a {{Path|/dev/md<i>i</i>}} device---then it will setup your initramfs and extlinux.conf file properly. However, in other cases, such as when you're also using encryption, or you invoke <code>setup-disk</code> with a mounted directory argument, these might not be properly setup for RAID. In that case, you may need to manually edit/rebuild them. The following assumes that <code>$MNT</code> holds the root directory you're installing into:

{{Cmd|1=echo "/sbin/mdadm" > $MNT/etc/mkinitfs/files.d/raid
echo "/etc/mdadm.conf" >> $MNT/etc/mkinitfs/files.d/raid
# edit $MNT/etc/mkinitfs/mkinitfs.conf to make sure features="..."
# includes raid (this field is space-separated and quoted)
mkinitfs -c $MNT/etc/mkinitfs/mkinitfs.conf -b $MNT
# edit $MNT/etc/update-extlinux.conf to make sure modules=... contains
# raid1 or raid456 (whichever your / is on; this field is comma-separated)
# also check the root= setting
extlinux --raid --install $MNT/boot --update
}}

{{Todo|Does adding the <code>--update</code> option to <code>extlinux ...</code> suffice to make {{Path|/boot/extlinux.conf}} be regenerated? Or do we need to manually tweak that file, or run <code>update-extlinux</code>, as well?}}

You might also need to manually tweak {{Path|$MNT/etc/fstab}}. And you might need to copy {{Path|/usr/share/syslinux/mbr.bin}} to your disk's MBR.

=== Encryption ===

See [[Setting up encrypted volumes with LUKS]]. Then you can add an additional layer of LVM, or just unlock the volume you've created (using <code>cryptsetup luksOpen ...</code>), and supply the {{Path|/dev/mapper/<i>something</i>}} device directly to [[setup-disk]]. When you're finished, be sure to relock the volume (using <code>cryptsetup luksClose ...</code>) before rebooting.

If you install your {{Path|/}} (root) on an encrypted volume, you'll need to manually edit/rebuild your initram and your extlinux.conf file. The following assumes that <code>$MNT</code> holds the root directory you're installing into, that you've created the cryptvolume on the device {{Path|/dev/md2}}, and that you want to unlock the encrypted volume into a virtual volume named "crypt":

{{Cmd|1=# edit $MNT/etc/mkinitfs/mkinitfs.conf to make sure features="..."
# includes cryptsetup (this field is space-separated and quoted)
mkinitfs -c $MNT/etc/mkinitfs/mkinitfs.conf -b $MNT
# edit $MNT/etc/update-extlinux.conf to make sure default_kernel_opts="..."
# contains cryptroot=/dev/md1 and cryptdm=crypt (this field is also space-separated and quoted)
# also check the root= setting
extlinux --install $MNT/boot --update
}}

{{Todo|Does adding the <code>--update</code> option to <code>extlinux ...</code> suffice to make {{Path|/boot/extlinux.conf}} be regenerated? Or do we need to manually tweak that file, or run <code>update-extlinux</code>, as well?}}

You might also need to manually tweak {{Path|$MNT/etc/fstab}}.

=== LVM ===
<code>setup-disk</code> will automatically build and use volumes in a LVM group if you supply the '''-L''' switch.

If you instead want to build your LVM system manually, see [[Setting up Logical Volumes with LVM]]. Then <code>vgchange -ay</code>, format and mount your volumes, and supply the root mountpoint to [[setup-disk]]. When you're finished, be sure to
{{Cmd|umount ...
vgchange -an}}
before rebooting.

If <code>setup-disk</code> sees that you're using LVM---perhaps because you gave it the <code>-L</code> switch---then it will setup your initram and extlinux.conf file properly. However, in other cases, these might not be properly setup. In that case, you may need to manually edit/rebuild them. The following assumes that <code>$MNT</code> holds the root directory you're installing into:

{{Cmd|1=# edit $MNT/etc/mkinitfs/mkinitfs.conf to make sure features="..."
# includes lvm (this field is space-separated and quoted)
mkinitfs -c $MNT/etc/mkinitfs/mkinitfs.conf -b $MNT
# edit $MNT/etc/update-extlinux.conf to make sure root= is set correctly
extlinux --install $MNT/boot --update
}}

{{Todo|Does adding the <code>--update</code> option to <code>extlinux ...</code> suffice to make {{Path|/boot/extlinux.conf}} be regenerated? Or do we need to manually tweak that file, or run <code>update-extlinux</code>, as well?}}

You might also need to manually tweak {{Path|$MNT/etc/fstab}}.

=== Custom partitioning ===
<code>setup-disk</code> will by default set up a root parition, a separate /boot partition and a swap. If you want a different layout you can manually create the parititions, filesystems and mount them up on {{Path|/mnt}} (or any other mount point) and then run:

{{Cmd|setup-disk /mnt}}

<code>setup-disk</code> will install your running system on the mounted root, detect your file system layout and generate a fstab. You are responsible for making the proper partition bootable and make sure the MBR is ok for extlinux.

See also [https://github.com/itoffshore/alpine-linux-scripts setup-partitions]

=== Dual-booting ===
See [[Installing Alpine on HDD dualbooting|Install to HDD with dual-boot]]

=== Other needs ===
* [[Installing Alpine Linux in a chroot]]
* [[Replacing non-Alpine Linux with Alpine remotely]]





== Setting up swap ==

# create partition with type "linux swap" (82) (If you're going to use an LVM logical volume for swap, skip this step and <code>lvcreate</code> that instead.)
# <code>mkswap /dev/sda2</code>
# <code>echo -e "/dev/sda2 none swap sw 0 0" >> /mnt/etc/fstab</code>
# <code>swapon /dev/sda2</code> (or <code>rc-service swap start</code>)

Then {{Cmd|free -m}} will show how much swap space is available (in MB).

If you prefer maximum speed, you don't need configure any raid devices for swap. Just add 2 swap partitions on different disks and linux will stripe them automatically. The downside is that at the moment one disk fails, the system will go down. For better reliability, put swap on RAID1.

{{Todo|Instructions for cryptswap?}}

[[Category:Installation]]
[[Category:Storage]]

Setting up LVM on GPT-labeled disks

2018-01-27T11:44:17Z

Juef: /* LVM Creation */ typo

[[Category:Storage]]
This document describes how to set up a system booting from a logical volume in Alpine using lvm2 and GPT-labeled disks.

Begin by booting from Alpine installation media in the usual way. Log in as `root`, run `setup-alpine`, and answer `none` when asked to choose a disk.

=== Partitioning ===
We need to install some tools:
{{Cmd|apk add parted lvm2}}

Now we can create the partition table:
{{Cmd|parted -a optimal /dev/sda}}

unit MiB
mkpart 1 1 256
name 1 boot
set 1 legacy_boot on
mkpart 2 256 100%
set 2 lvm on

Now, exit `parted` and reboot to force a reread of the partition table (for some reason `partprobe` doesn't work here).

=== LVM Creation ===
Once you've rebooted, run through `setup-alpine` again.

Install some more necessary bits:
{{Cmd|apk add lvm2 e2fsprogs syslinux}}

Create a PV, VG, and a LV for the root partition:
{{Cmd|pvcreate /dev/sda2}}
{{Cmd|vgcreate vg0 /dev/sda2}}
{{Cmd|lvcreate -n myhost.root -L 8G vg0}}
{{Cmd|rc-update add lvm}}
{{Cmd|vgchange -ay}}

Create file systems:
{{Cmd|mkfs.ext3 /dev/sda1}}
{{Cmd|mkfs.ext4 /dev/vg0/myhost.root}}

Mount the file systems in position:
{{Cmd|mount -t ext4 /dev/vg0/myhost.root /target}}
{{Cmd|mkdir /target/boot}}
{{Cmd|mount -t ext3 /dev/sda1 /target/boot}}

Now you can run `setup-disk` to install Alpine:
{{Cmd|setup-disk -m sys /target}}

Finally, install `syslinux` (note that we are installing to `/dev/sda`, *not* `/dev/sda1`):
{{Cmd|1=dd bs=440 conv=notrunc count=1 if=/usr/share/syslinux/gptmbr.bin of=/dev/sda}}

Reboot and enjoy your new Alpine installation!

Alpine Linux in a chroot

2018-01-27T10:48:50Z

Juef: fix a typo

This document explains how to set up an Alpine build environment in a chroot under a different Linux distro, such as Arch, Debian, Fedora, Gentoo, or Ubuntu. Once inside the chroot environment, you can build, debug, and run alpine packages. The guide can also be used to install Alpine Linux from a non-Alpine Linux livecd such as Ubuntu or System rescue CD.

This example installation of Alpine Linux in a chroot will work with the latest release. But it's also possible to make a chroot with '''[[Edge|edge]]''' or older releases of Alpine Linux to test backports.

You can also use script [https://github.com/alpinelinux/alpine-chroot-install/ alpine-chroot-install] that simplifies this process to just two commands. This script is useful especially on CI environment (e.g. Travis CI).

== Requirements ==
For the base Alpine Linux you will only need around 6MB of free space; though to build packages you'll need at least 500 MB.

== Prerequisites ==
The variables below:

*'''${chroot_dir}''' = Should point to the chroot directory where you
*'''${mirror}''' = Should be replaced with [http://nl.alpinelinux.org/alpine/MIRRORS.txt one of the available Alpine Linux mirrors].

== Set up APK ==

{{Tip|In the command below, replace x86_64 with x86 if running on a 32 bit installation}}

{{Warning|You will need Kernel version 2.6.22 or later to use apk-tools-static}}

Download the latest apk static package (replace <tt>${version}</tt> with actual version):

{{Cmd|wget ${mirror}/latest-stable/main/x86_64/apk-tools-static-${version}.apk}}

.apk packages are just gzipped tarballs, unpack using:
{{Cmd|tar -xzf apk-tools-static-*.apk}}

== Install the alpine base installation onto the chroot ==

{{Cmd|./sbin/apk.static -X ${mirror}/latest-stable/main -U --allow-untrusted --root ${chroot_dir} --initdb add alpine-base}}

== Set up the chroot ==

Set up some devices in the chroot
{{Tip|Manually creating devices is not needed if you choose to mount /dev of the hosts in the chroot described later.}}

{{Cmd|mknod -m 666 ${chroot_dir}/dev/full c 1 7
mknod -m 666 ${chroot_dir}/dev/ptmx c 5 2
mknod -m 644 ${chroot_dir}/dev/random c 1 8
mknod -m 644 ${chroot_dir}/dev/urandom c 1 9
mknod -m 666 ${chroot_dir}/dev/zero c 1 5
mknod -m 666 ${chroot_dir}/dev/tty c 5 0}}

If you need SCSI disc access:

{{Cmd|mknod -m 666 ${chroot_dir}/dev/sda b 8 0
mknod -m 666 ${chroot_dir}/dev/sda1 b 8 1
mknod -m 666 ${chroot_dir}/dev/sda2 b 8 2
mknod -m 666 ${chroot_dir}/dev/sda3 b 8 3
mknod -m 666 ${chroot_dir}/dev/sda4 b 8 4
mknod -m 666 ${chroot_dir}/dev/sda5 b 8 5
mknod -m 666 ${chroot_dir}/dev/sda6 b 8 6
mknod -m 666 ${chroot_dir}/dev/sdb b 8 16
mknod -m 666 ${chroot_dir}/dev/sdb1 b 8 17
mknod -m 666 ${chroot_dir}/dev/sdb2 b 8 18
mknod -m 666 ${chroot_dir}/dev/sdb3 b 8 19
mknod -m 666 ${chroot_dir}/dev/sdb4 b 8 20
mknod -m 666 ${chroot_dir}/dev/sdb5 b 8 21
mknod -m 666 ${chroot_dir}/dev/sdb6 b 8 22}}

A resolv.conf is needed for name resolution:

{{Cmd|cp /etc/resolv.conf ${chroot_dir}/etc/
mkdir -p ${chroot_dir}/root}}

If you don't want to copy the resolv.conf from the local machine, you can create a new one using OpenDNS servers (or any other):
{{Cmd|echo -e 'nameserver 208.67.222.222\nnameserver 2620:0:ccc::2' > ${chroot_dir}/etc/resolv.conf}}

Set up APK mirror (replace <tt>${branch}</tt> with the latest stable branch name, e.g. v3.3):

{{Cmd|mkdir -p ${chroot_dir}/etc/apk
echo "${mirror}/${branch}/main" > ${chroot_dir}/etc/apk/repositories}}

== Entering your chroot ==
At this point, Alpine has been succesfully installed onto the chroot directory. Before you chroot in you
will probably want to mount /proc and /sys in the chroot:

{{Cmd|mount -t proc none ${chroot_dir}/proc
mount -o bind /sys ${chroot_dir}/sys}}

If you don't want to create special device files yourself, mount the hosts device directory onto the chroot:
{{Cmd|mount -o bind /dev ${chroot_dir}/dev}}

You can now chroot:
{{Cmd|chroot ${chroot_dir} /bin/sh -l}}

To make the system actually bootable, we need to add some initscripts to appropriate runlevels:
{{Cmd|rc-update add devfs sysinit
rc-update add dmesg sysinit
rc-update add mdev sysinit

rc-update add hwclock boot
rc-update add modules boot
rc-update add sysctl boot
rc-update add hostname boot
rc-update add bootmisc boot
rc-update add syslog boot

rc-update add mount-ro shutdown
rc-update add killprocs shutdown
rc-update add savecache shutdown}}

Alpine Linux has a great meta-package for building Alpine packages from source available called alpine-sdk. To install, run:
{{Cmd|apk add alpine-sdk}}

If you are using Alpine as a Native build system you will have to make sure that chroot can run chmod. Add following to /etc/sysctl.conf

kernel.grsecurity.chroot_deny_chmod = 0

Then run the following command

{{Cmd|sysctl -p}}

== Alpine Linux in a chroot on Fedora ==

If you want to generate a chroot on a Fedora based system, you can use this [http://git.alpinelinux.org/cgit/user/fab/scripts/tree/alpine-chroot.sh script].

{{Note|Maybe you are able to use this script on other distribution but this is not tested.}}

= Troubleshooting =
== WARNING: Ignoring APKINDEX.xxxx.tar.gz ==
Make sure <tt>${chroot_dir}/etc/apk/repositories</tt> is valid and inside the chroot run:
{{Cmd|apk update}}

[[Category:Installation]]