Alpine Linux - User contributions [en]

Alpine local backup

2014-10-10T18:10:33Z

Andre: /* Create a apkovl elsewhere than on some specific media */

Alpine itself only loads a few required packages when you boot a clean Alpine Linux. 
But you probably want to do some personal adjustments (e.g [[Alpine_package_management|installing a package]] or doing some configuration). 
Because Alpine runs on RAM (normally), and everything in RAM will get lost next time the box is rebooted or shut down, you will need to permanently save your modifications and adjustments to Alpine. This is where 'lbu' comes in handy!

__TOC__

{{Note | If you installed Alpine on HDD you don't need to use 'lbu'. All your modifications would be permanently stored on your HDD.}}

First thing you need to know is this: '''As default 'lbu' only cares about modifications in ''/etc/'' and it's subfolders, with the exception of /etc/init.d/!''' 
Please have a look at '[[#Include_special_files.2Ffolders_to_the_apkovl|lbu include]]' to save files/folders located elsewhere than in ''/etc/''.

Alpine has the following tools for permanently storing your modifications:
* lbu
* lbu commit ''(Same as 'lbu ci')''
* lbu exclude ''(Same as 'lbu ex')''
* lbu include ''(Same as 'lbu inc')''
* lbu status ''(Same as 'lbu st')''
* lbu list-backup ''(Same as 'lbu lb')''
* lbu revert

In the below examples you will find some characters with special meaning
* '''|''' = '''or''' ''('lbu commit|ci' means that you can type ether 'lbu commit' or 'lbu ci')''
* '''[ ]''' = '''optional''' ''(In 'lbu commit|ci [-nv]' you can just skip the '-n', '-v' or '-nv' part if you don't want it)''

== Saving your changes ==
When you save your changes you will get a file that is named like 'myboxname.apkovl.tar.gz' ''('myboxname' will be the same as the hostname)''. 
This file (that contains your modifications) is called 'apkovl'. 
You will need to save your 'apkovl' on some suitable media (floppy, usb, cf, other).
<pre>
usage: lbu commit|ci [-nv] [<media>]

Options:
-d Remove old apk overlay files.
-e Protect configuration with a password.
-n Don't commit, just show what would have been committed.
-p <password> Give encryption password on the command-line
-v Verbose mode.

The following values for <media> is supported: floppy usb
If <media> is not specified, the environment variable LBU_MEDIA will be used.

Password protection will use aes-256-cbc encryption. Other ciphers can be
used by setting the DEFAULT_CIPHER or ENCRYPTION environment variables.
For possible ciphers, try: openssl -v

The password used to encrypt the file, can either be specified with the -p
option or using the PASSWORD environment variable.

The environment variables can also be set in /etc/lbu/lbu.conf
</pre>

== Include special files/folders to the apkovl ==
Assume that you have some files that you want to permanently save, but they are located somewhere else than in ''/etc/''. 
It could be ''/root/.ssh/authorized_keys'' (used by 'sshd' to authenticate ssh-users). 
Such files/folders can be added to the ''/etc/lbu/include'' list by manually editing the file or using the following command:
<pre>
usage: lbu include|inc|add [-rv] <file> ...
lbu include|inc|add [-v] -l

Options:
-l List contents of include list.
-r Remove specified file(s) from include list instead of adding.
-v Verbose mode.
</pre>
{{Note| This command only modifies some lbu-related config files. You will need to run 'lbu commit' to actually create/modify your apkovl.}}

== Exclude specific files/folders from the apkovl ==
Assume that you have some files located in ''/etc/'' or one of it's subfolders that you '''do not''' want to permanently save. 
It could be some log file or status file that for some reason is elsewhere than in ''/var/log''. 
Such files/folders can be added to the ''/etc/lbu/exclude'' list by manually editing the file or using the following command:
<pre>
usage: lbu exclude|ex|delete [-rv] <file> ...
lbu exclude|ex|delete [-v] -l

Options:
-l List contents of exclude list.
-r Remove specified file(s) from exclude list instead of adding.
-v Verbose mode.
</pre>
{{Note| This command only modifies some lbu-related config files. You will need to run 'lbu commit' to actually create/modify your apkovl.}}

== Execute a script as part of a backup ==

Sometimes it is necessary to run a script before or after a backup. Scripts in two optional directories allow for this:

/etc/lbu/pre-package.d
/etc/lbu/post-package.d

Files in those directories are run using run-script rules (meaning they must have the executable bit set, they are run in alphabetical order, and cannot contain an "extension" e.g. ''runme'' works, ''runme.sh'' does not.)

The scripts in pre-package.d are run before the apkovl is created; scripts inpost-package.d are run after the apkovl is created.

=== Example ===

Rather than adding the raw database directories to /etc/lbu/include, you can do a "database dump". For purposes of example, we use postgresql:

* Add the database dump file to the list of files to back up: lbu include root/pgdatabases.gz
* Create /etc/lbu/pre-package.d/sqldump with the following contents: <code>pg_dumpall -U postgres | gzip -c >/root/pgdatabases.gz</code>
* Mark the file executable: chmod +x /etc/lbu/pre-package.d/sqldump
* Create /etc/lbu/post-package.d/sqldumpdelete with the following contents: <code>rm -f /root/pgdatabases.gz</code>
* Mark the file executable: chmod +x /etc/lbu/post-package.d/sqldumpdelete

Now whenever you do a ''lbu commit'', the sql databases are dumped and gzipped to /root/pgdatabases.gz, and then the temporary file is deleted at the end of the lbu commit.

On a catastrophic restore, the databases are not automatically restored (that's not lbu's responsibility), but you will find a complete database dump in the /root directory, where it can be restored manually.

== Check what will be added to your apkovl ==
Sometimes it would be handy to know what files will be permanently saved next time you run 'lbu commit'. Here you have your help:
usage: lbu list|ls

== Create a apkovl elsewhere than on some specific media ==

<pre>
usage: lbu package|pkg -v [<dirname>|<filename>]

Options:
-v Verbose mode.

If <dirname> is a directory, a package named <hostname>.apkovl.tar.gz will
be created in the specified directory.

If <filename> is specified, and is not a directory, a package with the
specified name will be created.

If neither <dirname> nor <filename> is specified, a package named
<hostname>.apkovl.tar.gz will be created in current work directory.
</pre>

== Use SSH to create an apkovl on a different host ==

To create an apkovl of client on a centralized server, use "-" as the apkovl name:

On the server:
<pre>
ssh root@client "lbu package -" >client.apkovl.tar.gz
</pre>

== Check what files have been changed since last commit ==
<pre>
usage: lbu status|st [-av]

Options:
-a Compare all files, not just since last commit.
-v Also show include and exclude lists.
</pre>

== Multiple Backups ==
Lbu can now keep backups so you can revert to older, good known config.
Set BACKUP_LIMIT in /etc/lbu/lbu.conf to the number of backups you want
to keep.

You can list the current backups with:

{{Cmd|lbu list-backup [<media>]}}

and you can revert to an older with:

{{Cmd|lbu revert <filename> [<media>]}}

Note that when you revert, the current apkovl on media will be backed
up.

== See also ==
* [[Back Up a Flash Memory Installation]]
* [[Manually editing a existing apkovl]]

[[Category:Installation]]
[[Category:Storage]]
[[Category:Booting]]
[[Category:Package Manager]]

Alpine local backup

2014-10-10T18:05:57Z

Andre: /* Create a apkovl elsewhere than on some specific media */

Alpine itself only loads a few required packages when you boot a clean Alpine Linux. 
But you probably want to do some personal adjustments (e.g [[Alpine_package_management|installing a package]] or doing some configuration). 
Because Alpine runs on RAM (normally), and everything in RAM will get lost next time the box is rebooted or shut down, you will need to permanently save your modifications and adjustments to Alpine. This is where 'lbu' comes in handy!

__TOC__

{{Note | If you installed Alpine on HDD you don't need to use 'lbu'. All your modifications would be permanently stored on your HDD.}}

First thing you need to know is this: '''As default 'lbu' only cares about modifications in ''/etc/'' and it's subfolders, with the exception of /etc/init.d/!''' 
Please have a look at '[[#Include_special_files.2Ffolders_to_the_apkovl|lbu include]]' to save files/folders located elsewhere than in ''/etc/''.

Alpine has the following tools for permanently storing your modifications:
* lbu
* lbu commit ''(Same as 'lbu ci')''
* lbu exclude ''(Same as 'lbu ex')''
* lbu include ''(Same as 'lbu inc')''
* lbu status ''(Same as 'lbu st')''
* lbu list-backup ''(Same as 'lbu lb')''
* lbu revert

In the below examples you will find some characters with special meaning
* '''|''' = '''or''' ''('lbu commit|ci' means that you can type ether 'lbu commit' or 'lbu ci')''
* '''[ ]''' = '''optional''' ''(In 'lbu commit|ci [-nv]' you can just skip the '-n', '-v' or '-nv' part if you don't want it)''

== Saving your changes ==
When you save your changes you will get a file that is named like 'myboxname.apkovl.tar.gz' ''('myboxname' will be the same as the hostname)''. 
This file (that contains your modifications) is called 'apkovl'. 
You will need to save your 'apkovl' on some suitable media (floppy, usb, cf, other).
<pre>
usage: lbu commit|ci [-nv] [<media>]

Options:
-d Remove old apk overlay files.
-e Protect configuration with a password.
-n Don't commit, just show what would have been committed.
-p <password> Give encryption password on the command-line
-v Verbose mode.

The following values for <media> is supported: floppy usb
If <media> is not specified, the environment variable LBU_MEDIA will be used.

Password protection will use aes-256-cbc encryption. Other ciphers can be
used by setting the DEFAULT_CIPHER or ENCRYPTION environment variables.
For possible ciphers, try: openssl -v

The password used to encrypt the file, can either be specified with the -p
option or using the PASSWORD environment variable.

The environment variables can also be set in /etc/lbu/lbu.conf
</pre>

== Include special files/folders to the apkovl ==
Assume that you have some files that you want to permanently save, but they are located somewhere else than in ''/etc/''. 
It could be ''/root/.ssh/authorized_keys'' (used by 'sshd' to authenticate ssh-users). 
Such files/folders can be added to the ''/etc/lbu/include'' list by manually editing the file or using the following command:
<pre>
usage: lbu include|inc|add [-rv] <file> ...
lbu include|inc|add [-v] -l

Options:
-l List contents of include list.
-r Remove specified file(s) from include list instead of adding.
-v Verbose mode.
</pre>
{{Note| This command only modifies some lbu-related config files. You will need to run 'lbu commit' to actually create/modify your apkovl.}}

== Exclude specific files/folders from the apkovl ==
Assume that you have some files located in ''/etc/'' or one of it's subfolders that you '''do not''' want to permanently save. 
It could be some log file or status file that for some reason is elsewhere than in ''/var/log''. 
Such files/folders can be added to the ''/etc/lbu/exclude'' list by manually editing the file or using the following command:
<pre>
usage: lbu exclude|ex|delete [-rv] <file> ...
lbu exclude|ex|delete [-v] -l

Options:
-l List contents of exclude list.
-r Remove specified file(s) from exclude list instead of adding.
-v Verbose mode.
</pre>
{{Note| This command only modifies some lbu-related config files. You will need to run 'lbu commit' to actually create/modify your apkovl.}}

== Execute a script as part of a backup ==

Sometimes it is necessary to run a script before or after a backup. Scripts in two optional directories allow for this:

/etc/lbu/pre-package.d
/etc/lbu/post-package.d

Files in those directories are run using run-script rules (meaning they must have the executable bit set, they are run in alphabetical order, and cannot contain an "extension" e.g. ''runme'' works, ''runme.sh'' does not.)

The scripts in pre-package.d are run before the apkovl is created; scripts inpost-package.d are run after the apkovl is created.

=== Example ===

Rather than adding the raw database directories to /etc/lbu/include, you can do a "database dump". For purposes of example, we use postgresql:

* Add the database dump file to the list of files to back up: lbu include root/pgdatabases.gz
* Create /etc/lbu/pre-package.d/sqldump with the following contents: <code>pg_dumpall -U postgres | gzip -c >/root/pgdatabases.gz</code>
* Mark the file executable: chmod +x /etc/lbu/pre-package.d/sqldump
* Create /etc/lbu/post-package.d/sqldumpdelete with the following contents: <code>rm -f /root/pgdatabases.gz</code>
* Mark the file executable: chmod +x /etc/lbu/post-package.d/sqldumpdelete

Now whenever you do a ''lbu commit'', the sql databases are dumped and gzipped to /root/pgdatabases.gz, and then the temporary file is deleted at the end of the lbu commit.

On a catastrophic restore, the databases are not automatically restored (that's not lbu's responsibility), but you will find a complete database dump in the /root directory, where it can be restored manually.

== Check what will be added to your apkovl ==
Sometimes it would be handy to know what files will be permanently saved next time you run 'lbu commit'. Here you have your help:
usage: lbu list|ls

== Create a apkovl elsewhere than on some specific media ==

<pre>
usage: lbu package|pkg -v [<dirname>|<filename>]

Options:
-v Verbose mode.

If <dirname> is a directory, a package named <hostname>.apkovl.tar.gz will
be created in the specified directory.

If <filename> is specified, and is not a directory, a package with the
specified name will be created.

If <dirname> and <filename> are not specified, a package named
<hostname>.apkovl.tar.gz will be created in current work directory.
</pre>

== Use SSH to create an apkovl on a different host ==

To create an apkovl of client on a centralized server, use "-" as the apkovl name:

On the server:
<pre>
ssh root@client "lbu package -" >client.apkovl.tar.gz
</pre>

== Check what files have been changed since last commit ==
<pre>
usage: lbu status|st [-av]

Options:
-a Compare all files, not just since last commit.
-v Also show include and exclude lists.
</pre>

== Multiple Backups ==
Lbu can now keep backups so you can revert to older, good known config.
Set BACKUP_LIMIT in /etc/lbu/lbu.conf to the number of backups you want
to keep.

You can list the current backups with:

{{Cmd|lbu list-backup [<media>]}}

and you can revert to an older with:

{{Cmd|lbu revert <filename> [<media>]}}

Note that when you revert, the current apkovl on media will be backed
up.

== See also ==
* [[Back Up a Flash Memory Installation]]
* [[Manually editing a existing apkovl]]

[[Category:Installation]]
[[Category:Storage]]
[[Category:Booting]]
[[Category:Package Manager]]

Xen Dom0 on USB or SD

2014-10-10T13:24:42Z

Andre:

This guide will show you how to perform a Xen Dom0 install on a USB or SD card, so you can have your Dom0 running from tmpfs. This has some benefits, but you will need a place to store your guests (virtual machines) and a syslog server to redirect the logs to.

The first step is to set up a basic usb or SD install, to do this boot from the Alpine install CD (minimal is fine) and follow one of the following guides: [[Create a Bootable USB]] or [[Create a Bootable Compact Flash]]. Once you finished installing Alpine Linux on your device, boot from it and configure your newly installed system:

{{Note|you might have to edit /etc/apk/repositories and change the first line so it points to /media/usb/apks.}}

<pre>
# setup-alpine
[...]
# apk update
</pre>

Now that you have your system properly configured, it's time to install Xen:

<pre>
# Should this not be apk add xen xen-hypervisor ?
# apk add xen
</pre>

Now we have Xen installed, but we will need to modify the usb bootloader in order to load the Xen kernel. The first step is to remount /media/usb with write permissions:

{{Note|<nowiki>you might have to use /media/UUID=XXX-XXXX instead of /media/usb, see /proc/mounts to detected where is your usb/cf card mounted.</nowiki>}}

<pre>
# mount -o remount,rw /media/usb
</pre>

Then, copy the Xen kernel and mboot.c32 to the usb boot partition:

<pre>
# cp /boot/xen.gz /media/usb/boot/
# cp /boot/mboot.c32 /media/usb/boot/
</pre>

Now we have all the necessary files to boot Xen from the usb, it's time to change the bootloader and add a Xen entry, to do so open /media/usb/syslinux.cfg with your favorite editor and add one of the following entries:

Normal boot:
<pre>
LABEL xen
KERNEL /boot/mboot.c32
APPEND /boot/xen.gz --- /boot/grsec alpine_dev=UUID=XXXX-XXXX:vfat modules=loop,squashfs,sd-mod,usb-storage modloop=/boot/grsec.modloop.squashfs --- /boot/grsec.gz
</pre>

Serial console boot:
<pre>
LABEL xen
KERNEL /boot/mboot.c32
APPEND /boot/xen.gz com1=115200,8n1 console=com1 --- /boot/grsec alpine_dev=UUID=XXXX-XXXX:vfat modules=loop,squashfs,sd-mod,usb-storage modloop=/boot/grsec.modloop.squashfs --- /boot/grsec.gz
</pre>

Change the UUID to the correct one, and add the necessary modules for your system. It's also a good idea to check [http://wiki.xen.org/wiki/Xen_Hypervisor_Boot_Options Xen Boot options] and set dom0_mem, dom0_vcpus_pin and dom0_max_vcpus at least.

The next step is to load the necessary kernel modules for Xen, we will add them to /etc/modules, so they will be loaded automatically on boot:

<pre>
# echo "xen_netback" >> /etc/modules
# echo "xen_blkback" >> /etc/modules
# echo "tun" >> /etc/modules
</pre>

The last step is to configure startup services, we will need udev and xencommons at least to be started on boot:

<pre>
# rc-update add udev sysinit
# rc-update add udev-postmount
# rc-update add xenstored
# rc-update add xenconsoled
</pre>

If you need the xm toolstack, also add xend to startup services:

<pre>
# rc-update add xend
</pre>

Ok, now you have a fully functional Xen install, it's time to save your changes and boot into it.

<pre>
# lbu commit
# reboot
</pre>

Also remember to configure at least one network bridge following the [[Bridge]] guide.

== See also ==
* [[Xen Dom0]]

[[Category:Virtualization]]