- HomePage
- Create-bootable-images
- Create-what-is-only-needed-repo
- Create-alpine-rescue-disk
- Boot-dance-everything-in-usr-folder
- True-diskless-boot
- Diskless-install-on-devices-with-2gb-ram
- Diskless-install-on-devices-with-1gb-ram
- About-diskless-boot
- How-to-share-you-apks-repo
- How-to-manage-shared-apks-repo
- How-to-manage-shared-apks-repo-2
Create what is needed repo in Alpine Linux installs (Part 3) - repository sharing
Work scenarios
- You need multiple similar stable Alpine Linux installations, like in, institutions/schools.
- Net connection is flaky or restricted for users.
- Your setup does not need permanent /sys installs.
Why local shared repository is needed?
- Edge(rolling release) is in constant flux, not recommended for production uses.
- Latest stable - frequent updates(version) - will out-date your packages with next pointy release.
- Old stable versions - they are stable to use for production, but watch out for each end of support.
/cachefiles downloads are controlled byapkand should not be manually updated/changed.- Your setup does not depend/need on frequent updates, once required applications are downloaded/working.
- Method described below is presently meant for ram-based installs. It may not be effective on other methods of installs.
- Method assumes you have a basic internet ready ram-based install/setup up and running.
Shared repository - explained
- Its a snapshot of packages (resistant to frequent need for upgrades).
- Its a partial mirror of official repository with required packages/applications for current setup.
- Install/download once, and run everywhere.
Directory structure
(1)
/media/sdb1/
|-- apks2 <- custom curated apk pkgs folder
| `-- v3.22
| |-- fetch-apk.sh <- helper script to download apks
| |-- main
| | `-- x86_64
| | |-- APKINDEX.tar.gz
| | `-- ... .apk
| `-- community
| `-- x86_64
| |-- APKINDEX.tar.gz
| `-- ... .apk
|-- cache
| `-- installed
|-- ...
|-- ...
`-- lost+found
- apks2 downloads as in (1) above can reside on local lan(method 1) and/or on booted disk(method 2).
Method 1 - local lan
- Fast access via local lan.
- For easy start use a a diskless booted disk to build apks2 server.
Server setup to access lan repository
Step 1 - server setup
This server can be on any running device in your LAN.
Make sure they are accessible via local internet.
Alt 1: Using busybox-extras(quick/manual).
apk add busybox-extras
cd /media/sdb1/
busybox-extras httpd -f -p8080
- Busybox-extra's httpd applet(advanced)
#TODO
Alt 2: Using nginx.
apk add nginx nginx-mod-http-fancyindex
-
- How to install Nginx
- link to nginx documents
Step 2 - add url to /etc/apk/repositories
Edit your diskless installations /etc/apk/repositories, or run setup-apkrepos.
File: /etc/apk/repositories
/media/usb/apks # Lets say, device/server on which you have apks2(above) has IP - 192.168.1.100 http://192.168.1.100:8080/apks2/v3.22/main http://192.168.1.100:8080/apks2/v3.22/community
Method 2 - boot disk
- On boot disk apks2 folder, with some use case,
- Create-what-is-only-needed-repo - a how to
- Create-alpine-rescue-disk - an useful use-case
So far we have seen 2 Methods on how to share your apks repositories, i.e,
- Server method 1
- On boot disk method 2
Below are links on on how to create diskless boot, so as to make use of above methods.
Ways to do diskless boot
Q&A
Is this process/method environment friendly?
This method surely does save lots of bandwidth, but if its environment friendly, is currently difficult to say.
Do I still need /cache in these setup?
Yes/No, author of this article suggests to run a setup without /cache enabled and later with /cache enabled and see if its still needed in your current setups using shared repository.
Is this method officially supported?
Currently No. Having a partial repository also means it may contain packages/versions that are no longer provided by official repositories. Seeking help on such packages may not be possible.
Author experience
- I only have diskless installs, and they mostly install from a local pre-downloaded repository. The install process is faster and is less prone to errors arising from flaky internet.
Author
V.Krishn