Alpine linux mirrors list

How to setup a Alpine Linux mirror

Contents

Introduction

This document describes how to set up an Alpine Linux mirror and make it available via http and rsync.

• create the dir where we have the mirror
• set up a cron job to sync with master mirror every hour
• set up lighttpd for http access
• set up rsync so other mirrors can rsync from you

Make sure that you have enough disk space.

Current (2021-06-10) disk usage in GB:

edge	v3.0	v3.1	v3.2	v3.3	v3.4	v3.5	v3.6	v3.7	v3.8	v3.9	v3.10	v3.11	v3.12	v3.13	v3.14	total
228.6	16.5	17.5	14.5	20.4	24.3	26.8	44.3	42.5	58.9	72.8	112.1	134.6	146.4	147.4	143.4	1251.3

Script used to calculate the size:

Setting up the cron job

Install rsync which will be used to sync from the master mirror.

Save the following file as /etc/periodic/hourly/alpine-mirror

Make it executable:

chmod +x /etc/periodic/hourly/alpine-mirror

Now it will sync every hour. (given cron runs)

Setting up HTTP access via lighttpd

Install the lighttpd server

apk add lighttpd

Enable dir listings by uncommenting the following line in /etc/lighttpd/lighttpd.conf:

Also set cache-control to force cache revalidate every 30 mins. Uncomment mod_setenv in /etc/lighttpd/lighttpd.conf:

Add also the following lines to /etc/lighttpd/lighttpd.conf:

Start lighttpd and make it start at boot:

rc-service lighttpd start rc-update add lighttpd

If so, simply install, start and auto-start the webserver:

apk add darkhttpd && rc-service darkhttpd start && rc-update add darkhttpd

Darkhttpd will, by default, offer directory listings and serve data from /var/www/localhost/htdocs/

See the main article on Darkhttpd for more configuration options

Setting up rsyncd

Add the following lines to /etc/rsyncd.conf:

Optionally set a bandwidth limit in /etc/conf.d/rsyncd. In this example we limit to 500Kbytes/s (approx 5Mbit/s)

Mirror statistics

Simple bandwidth statistics can be generated with vnstat.

edit /etc/vnstat.conf and replace the interface name with the appropriate one.

copy the following script to /etc/periodic/15min/stats and make sure your crond is running. please not that heredoc should be tab indented or the script will fail. A working copy can be found here: http://tpaste.us/RrMv

Update mirror from mqtt

If you want your mirror to be really uptodate compared to our master mirror you can subscribe to Alpine Linux message server «msg.alpinelinux.org» and check for upload messages. Add mqtt-exec to be able to execute processes when specific topics are being send.

apk add mqtt-exec

mqtt-exec supports running multiple time so we need to setup a specific config.

ln -s /etc/init.d/mqtt-exec /etc/init.d/mqtt-exec.sync-mirror

ln -s /etc/conf.d/mqtt-exec /etc/conf.d/mqtt-exec.sync-mirror

Copy the following file to /usr/local/bin/sync-mirror and make it executable (dont forget to update the variables).

And finally start mqtt-exec and let it listen on msg.alpinelinux.org

To make sure you are not missing any packages (in case something goes wrong with MQTT subscription) you can periodically sync all directories by adding the script to cron.

ln -s /usr/local/bin/sync-mirror /etc/periodic/hourly/sync-mirror

Now watch your syslog as it should tell you when it will update directories in your local mirror.

Источник

Enable Community Repository

Alpine software repositories have main packages and contributions made. Each Alpine release has two branches of repositories. The /community repository of each Alpine release contains community supported packages that were accepted from the /testing repository. Only /main repository of each version of Alpine release are supported for some Main Alpine Developers and Man Powers.

• Main packages are the Alpine package software that have direct support and updates from the Alpine core and main team, also have official documentation. Are always available for all releases and will have substitutions if some are not continued from upstream. Commonly those packages are selected due their responsibility and stability respecting upstream availability. Packages from testing that performs well or are mature goes to main branch.

• Community packages are those made by users in team with the official developers and well near integrated to the Alpine packages. Those have supported by those user contributions and could end if the user also ends respect with Alpine work, but may be removed in a future release due lack of support by upstream author. Packages from testing that are accept goes to community branch.

• Testing packages come into testing or edge repositories and are those made by any contributor on Alpine, the edge, this branch of repository has no release linked or related of Alpine. Those are in edge and when accepted goes to testing.

For further information check Alpine newbie APK section wiki page.

Contents

Using community repositories

The community repository was introduced with Alpine Linux version 3.3.

To enable the repository, edit the file /etc/apk/repositories and add (or uncomment) a line that points to the «community» directory.

https:// /alpine/ /community

After enabling the community repository, one needs to update the index of available packages with:

And then it’s possible to install packages from the community repository.

Using specific package versions

You can specify or pin «sticky» package versions like this:

• apk add packagename=1.2.3-suffix
• apk add ‘packagename

That will upgrade these packages only until the specified version.

It’s then safe to use apk upgrade to upgrade all packages, while packages with versions will remain on the specified version.

To set a minimum version just add … .

The official recommendation can be read here, citation below.

Using testing repositories

The testing repository was introduced with Alpine Linux edge development. To enable the repository, edit the file /etc/apk/repositories using an editor ( nano for instance) and add a line that points to the «testing» directory, formatted as in:

After enabling the testing repository, one needs to obtain the latest index of available packages with:

Inexperienced users should not enable this.

Using packages from testing (edge)

Never pin packages from the «edge» branch of the alpine package repo, as these are in test and may be revoked. (At pkgs.alpinelinux.org/packages, click «edge» and change it to the alpine image version you use, and click «search» again.)

Inexperienced users should not enable this.

Источник

Replacing non-Alpine Linux with Alpine remotely

Contents

With VNC access

Download an alpine iso that boots from ram, e.g. alpine-virt

Flash the image to the drive of your server, e.g. /dev/sda

Reboot, and login again from vnc with root. Alpine is now running from ram, and should have mounted /dev/sda on /media/sda, paste it into ram.

Copy also the kernel modules which are located in /.modloop

Unmount modloop and the media folder

Move back the files in place

Finally you can format the disk to install alpine

Or just run the the whole setup

Without VNC access

• SSH access to the remote box (needs to have SSH server running)
• Alpine Linux supported hardware
• Adventurous mind
• Nerves of steel

These instructions are based on a debian (physical) server, and all steps are performed while logged into the machine. So you should start with a machine that has ssh running.

Create apk overlay suitable for hard disk based tmpfs boot

The first step is to create Alpine configuration file with basic configuration of the host. We need the new box to start networking and ssh in the beginning so we can reconnect to it after reboot.

Create basic layout for the overlay:

You can also use default Alpine configuration files. In this case you should use ssh key to authorize yourself (as root password is empty, and ssh has empty passwords disabled).

If you want to keep the existing host identity (e.g. SSH key), you can copy them over:

Copy over your ssh authorized_keys and make sure its included in future:

Find out which shell is used for root:

If its /bin/ash, you are good. If not, edit etc/passwd and change it to /bin/ash.

Create etc/network/interfaces with network configuration (unless it was previously copied over). It should look something like:

Since Alpine 3.13 must be:

Make sure there is no whitespace at end of lines in interfaces file. Busybox ifup is very picky.

Make sure your etc/resolv.conf exists; if not create etc/resolv.conf with the nameserver configuration like:

Create the apk world (etc/apk/world) with essential packages:

Double check the IP configuration and ssh keys.

Finally, make the essential services start up automatically and create the overlay file:

Verify the overlay with «tar tzf» to see that it contains everything in proper places, and ensure it is in the / directory

Install Alpine cd-rom image on hard disk

We need to copy over two sets of information: the boot kernel (kernel, initramdisk and boot configuration) and operating system boot data (overlay, apk packages and kernel modules). These can reside on same partition if they fit. However, /boot is usually small, so you might want to put the apks on separate partition. This guide assumes they are on sda1 (/boot) and sda2 (/) with both having ext3 filesystems. If you don’t have ext3 on / or /boot, then you might be able to disable swap and reformat the swap partition as ext3 and use that.

Download an alpine iso and mount it; for example

Copy the apkovl and the contents of cd-rom image to root of current installation:

Next we make the Alpine Linux kernel bootable (requires syslinux) and use fdisk to mark the /boot partition as bootable (if not done already):

Make sure that /boot dir has a symlink pointing to itself. This is to handle the case when /boot is on separate partition.

Create /boot/extlinux.conf with contents like (check the filesystem type for alpine_dev; kernel and initrd are relative to partition root):

From Alpine Linux 2.1 you can use the UUID of the partition that holds the apkovl and the apks directory, the current root. Use blkid to get the proper UUID. By using UUID we solve the problem when there are multiple disks and we don’t knowing how kernel enumerates them after boot. Example extlinux.conf:

[Comment added by IceCodeNew]

I tried this instruction on Ubuntu 20.04, and I’m installing Alpine-virt 3.13.2.

I found there is no such file named `*/syslinux/mbr.bin`, but even if I skip the step which issuing `dd if=/usr/share/syslinux/mbr.bin of=/dev/sda`, the machine was able to boot alpine without problem.

Here is the extlinux.conf I use (since there are lots of files that had been renamed):

Finally make the /boot partition bootable by extlinux.

(Tested on 2.1.2 and higher) Make sure:

• grsec.cmg is on /
• [something].apkovl.tar.gz is on /
• grsec.gz is on /boot
• The apline_dev UUID value points to whatever is currently /
• the partition for /boot is flagged as bootable
• the output of extlinux was for the partition currently mounted at /boot

Install Alpine on hard-disk

Reboot the box. And wait for it to come alive again. If it doesn’t, tough luck. So dry practice with local box, with as identical hardware as possible.

Once back in the box, we are running in Alpine Linux from tmpfs. So just do a regular installation of Alpine from network via ssh connection.

Edit /etc/apk/repositories to contain your favorite Alpine mirror or just:

After hard disk setup is complete, copy ssh_authorized_keys to hard disk.

Reboot once more, and you have the server with native Alpine hard disk installation.

Источник

Alpine Linux in a chroot

Contents

Inside the chroot environment, you can build, debug, and run Alpine packages or develop things. It’s the most known way to do so without replacing your system or using a Virtual Machine. This document explains how to set up an Alpine build environment in a chroot under a host Linux distro, that can also be used to install Alpine Linux from a non-Alpine Linux system or live environment.

Requirements

• Working Linux instalation where to perform all the process
• Linux kernel 2.6.22, with curl and chroot binary installed
• target media with at least 100M, 900MB for more complete solution as minimum
• internet connection

Prerequisites

The variables below:

• $ = Should point to the new root directory
• $ = Should be replaced with one of the available Alpine Linux mirrors.
• $ = Should be the cpu architecture like x86 (i386) or amd64(x86_64)..

Set up APK

Download the latest apk static package (replace $ with actual version):

curl -LO $/latest-stable/main/$/apk-tools-static-$.apk

.apk packages are just gzipped tarballs, you can unpack them using:

tar -xzf apk-tools-static-*.apk

Install the alpine base installation onto the chroot

./sbin/apk.static -X $/latest-stable/main -U --allow-untrusted -p $ --initdb add alpine-base

Seting up the chroot

Before you change root to the new directory, you need to create the required devices

Method 1.a Simple way: Using the host's /dev

mount -o bind /dev $/dev

Method 1.b Manual way: Creating needed nodes

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

If you need SCSI disc access you can create the device nodes like this:

mknod -m 666 $/dev/sda b 8 0 mknod -m 666 $/dev/sda1 b 8 1 mknod -m 666 $/dev/sda2 b 8 2 mknod -m 666 $/dev/sda3 b 8 3 mknod -m 666 $/dev/sdb b 8 16 mknod -m 666 $/dev/sdb1 b 8 17

Make the process fs and /sys fs available

mount -t proc none $/proc mount -o bind /sys $/sys

Set up name resolution

A resolv.conf is needed for name resolution:

You can either copy your host's resolv.conf:

or instead you can create a new one (this example uses OpenDNS):

echo -e 'nameserver 8.8.8.8\nnameserver 2620:0:ccc::2' > $/etc/resolv.conf

Prepare the APK repositories

Set up APK main repository (replace $ with the latest stable branch name, e.g. v3.3):

Entering your chroot

You then can enter your chroot by running this command as the root user (UID 0).

Preparing init services

If you plan to use your chroot with a init system or setup a new system on another device you should add these services:

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

Troubleshooting

Hardened kernels or alpine as chroot host

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

Then reload the sysctl configuration

chroot: cannot run command ' . Exec format error

This usually indicates that you booted with one architecture (e.g. armf) and are trying to chroot into another (e.g. x86_64). The binaries must be built for the architecture that the host runs!

Note that with one exception you can run 32 bit x86 chroot in x86_64, but not viceversa!

WARNING: Ignoring APKINDEX.xxxx.tar.gz

Make sure $/etc/apk/repositories is valid and run:

Источник