Alpine linux install git

Development using git

It should be renamed to Git. All git development articles should be consolidated (Discuss)

This document describes how to use git for Alpine Linux development and related projects. If you just want to browse the Alpine git repositories, please visit git.alpinelinux.org.

Contents

Basic Git usage

Configure your global git config

First you need to tell your name and email to git. This name and email will show up in all your commits.

git config —global user.name «Your Name Comes Here» git config —global user.email you@yourdomain.example.com

Using git config without --global let you configure other details for a specific git repository.

git config —global color.ui true git config —global core.pager more

Email configuration

To be able send your commits (patches) via email you need configure an SMTP server.

git config —global sendemail.smtpserver smtp.exmaple.com

For sending from a gmail address you can do:

git config —global sendemail.smtpserver smtp.gmail.com git config —global sendemail.smtpserverport 587 git config —global sendemail.smtpencryption tls git config —global sendemail.smtpuser your_email@gmail.com

Optionally, it is possible to skip the password prompt by adding it to the configuration with:

git config —global sendemail.smtppass your_password

To reset CC mail attribute

git config —global sendemail.suppresscc all

Cloning a repository via Git

There are two ways to work with the Alpine git repository.

• . without write access.
• . with write access.

git.alpinelinux.org shows all available Alpine git repositories.

Without write access

If you want to clone the Alpine aports repository, switch to the directory you want to have the aports/ directory in and launch git.

If you want only the last 3 revisions:

Use the command below to see the full log of the trunk.

With write access

If you have write access to the Alpine repository, the URL needs to be adjusted for cloning a repository

git clone git@git.alpinelinux.org:aports

Alternatively you can set the remote url of an exisiting git clone:

git remote set-url origin git@git.alpinelinux.org:aports

General GIT Workflow

1. Make your file edits in your local checkout of the local copy of repository.
2. Commit the changes in your local repository:

Bring the rest of your local repository up to date:

git pull —rebase

Check what you are going to push:

git log origin..master

Move your changes up to the master if you have write access

Источник

Как я домашний Git-сервер Gogs на Alpine linux устанавливал

“Опасное это дело, Фродо, выходить за порог: стоит ступить на дорогу и, если дашь волю ногам, неизвестно куда тебя занесет.”

(с) Властелин Колец: Братство Кольца

С чего всё началось

Мне захотелось завести себе домашний Git-сервер, чтобы практиковаться в разработке и развёртывании пет-проектов. Плюс спокойнее, когда твои наработки лежат не только на github.

В качестве операционной системы выбрал Alpine linux, так как меня заинтересовали её возможности. Был опыт размещения на ней небольшого сервиса. Понравилось, что в ней нет ничего лишнего, а ещё она очень лёгкая в плане системных ресурсов.

Исходные данные

В распоряжении был гипервизор на Proxmox 6.1-3, контейнер с системой Alpine просто взял из шаблонов (template) — Alpine Linux 3.12 Kernel 5.3.10-1-pve on an x86_64.

Реализацию Git-сервера выбирал из числа открытых и бесплатных проектов. Решил взять для начала, тот у которого меньше настроек и лишних плюшек. Мне нужен git-сервер, который не требователен к ресурсам и наличием базовых операций. Остановился на проекте Gogs.io.

Причины такого выбора:

знакомый интерфейс, т.к. использую на работе;

написан на Golang — значит довольно шустрый;

минимальный набор настроек и функционала;

Мой гипервизор пока обладает скромным железом. В распоряжении только:

ЦПУ — 4 x AMD Ryzen 3 1200 Quad-Core

Диски — два SSD в ZFS

Из них 1-2 Гб ОЗУ забирает ОС гипервизора. Значит на контейнеры и виртуалки остаётся не так много ресурсов. Решил, что для 1-2 пользователей git-сервера хватит одного ядра, 512 Мб ОЗУ и 8 Гб диска.

Запуск контейнера с ОС Alpine

Настройка и запуск Alpine на Proxmox очень просты и удобны. Описывать их не буду. Скажу только, что мне эта тема с шаблонами очень понравилась. Жаль, что самих шаблонов не так много на мой взгляд.

С другой стороны, никто не мешает развернуть любую ОС и поставить нужный сервис из её пакетов. Например в Alpine так:

Подготовка системы

Сменил имя хоста сервера:

Вначале я установил openssh и nano для его настройки, чтобы нормально подключаться по ssh:

Далее добавил демон в автозагрузку:

Поправил конфиг /etc/ssh/sshd_config и убрал комментарии строк:

Всё, запустил демон:

Установка сервиса Gogs

Попытка первая

В документации к Alpine рекомендуют для разработки использовать Gitea. Но это слишком просто неть, поэтому выбрал другое. Я решил внаглую установить git-сервер командой:

В результате, система помимо самого сервиса gogs установила ещё и дополнительные пакеты, например сам git. Пробую запустить сервер и получаю ошибку:

Как мы видим, ему не хватает конфига и структуры каталогов для работы. Проверил каталог /usr/bin, там оказался лишь одинокий исполняемый файл gogs.

Попытка вторая

После первой попытки я попробовал воссоздать необходимую структуру и конфиг вручную. Ничего хорошего из этого не вышло.

Тогда решил пойти другим путём — в документации Gogs описывается установка под популярные дистрибутивы Linux. Обнаружил там таблицу архивов под две версии Gogs, поэтому проверил, какой установился у меня на Alpine:

Решил попробовать вот этот. Скопировал его в директорию /opt на Alpine:

Мой замысел был в том, что либо он заработает после распаковки сразу, либо с него можно будет взять недостающей структуры и конфигов. Поменял права на директорию распакованного gogs:

Попробовал запустить и получил странную ошибку (спойлер: не удивительно, ведь С-компиляторы разные на Alpine это mysl, но об этом я узнаю позже):

Тогда то мне и пришла дикая идея подсунуть gogs из Alpine пакетов:

И бинго! Сервер стартанул и я даже смог его настроить из веб-интерфейса. Но это был не конец…

Попытка третья

Несмотря на охватившую меня эйфорию, радости и “я у мамки сисадмин!” весь следующий день я провёл в раздумьях. Мне не верилось, что в таком перспективном проекте как Alpine, есть место битому пакету. Чувство, что ошибка на моей стороне, не давала покоя.

Я нашел телеграм-чат по Alpine и (увы) на ломаном инглише объяснил свою проблему. Меня направили проверять конфиги в репозитории пакета gogs проекта Alpine.

Честно — у меня не получилось выяснить, в чём ошибка. Но добыл ценную инфу — сервер можно запускать с явным указанием пути к файлу конфига. Попробовал, и штатный gogs-сервер запустился:

Дальше настраивал по этому видео-уроку, начиная с момента про настройку из веб-интерфейса.

Конечно, это не полная настройка. При настройке из GUI, я выяснил, что нужно ещё ставить bash.

Кроме этого, нужно настроить автозапуск сервера. Вернее, он уже есть — /etc/init.d/gogs, но не работает:

Путём перебора вариантов пришёл к такому:

Грубо, но да — я просто вместо переменных прописал путь и пользователя (того, которого задавал при настройке из веб-интерфейса). Возможно на этот момент мне указывали в чатике Alpine?

Как на самом деле нужно было

После такого долгого пути экспериментов и щупанья головой стены на прочность, меня осенило! Сервер не нужно запускать вручную, он должен стартовать вместе с системой. Значит, его надо настроить по аналогии с openssh.

Снова решил проверить — клонировал контейнер с Alpine и уже настроенным ssh. А дальше всё оказалось очень просто:

Этого действительно достаточно, чтобы запустить свой Git-сервер (если вас устраивает БД SQLite). Теперь можно идти на веб-интерфейс, у меня это был http://192.168.50.205:3000, и делать базовые настройки.

Заключение

Этой статьёй я хочу обратить внимание на важность документации и навыков по ОС Linux. Скорее всего, опытные линуксоиды сразу поняли в чём дело и от души посмеялись над моим дилетанством. Что ж, теперь мне и самому забавно, каким извилистым был мой путь =).

Но правда также и в том, что простой справки по развороту именно пакета gogs на Alpine я не нашёл. Надеюсь, моя статья будет полезна тем, кто задумает нечто подобное.

Источник

Alpine Linux package management

Contents

Because Alpine Linux is designed to run from RAM, package management involves two phases:

• Installing / Upgrading / Deleting packages on a running system.
• Restoring a system to a previously configured state (e.g. after reboot), including all previously installed packages and locally modified configuration files. (RAM-Based Installs Only)

apk is the tool used to install, upgrade, or delete software on a running system.
lbu is the tool used to capture the data necessary to restore a system to a previously configured state.

This page documents the apk tool — See the Alpine Local Backup page for the lbu tool.

Overview

The apk tool supports the following operations:

add	Add new packages or upgrade packages to the running system
del	Delete packages from the running system
fix	Attempt to repair or upgrade an installed package
update	Update the index of available packages
info	Prints information about installed or available packages
search	Search for packages or descriptions with wildcard patterns
upgrade	Upgrade the currently installed packages
cache	Maintenance operations for locally cached package repository
version	Compare version differences between installed and available packages
index	create a repository index from a list of packages
fetch	download (but not install) packages
audit	List changes to the file system from pristine package install state
verify	Verify a package signature
dot	Create a graphviz graph description for a given package
policy	Display the repository that updates a given package, plus repositories that also offer the package
stats	Display statistics, including number of packages installed and available, number of directories and files, etc.
manifest	Display checksums for files contained in a given package

Packages and Repositories

Software packages for Alpine Linux are digitally signed tar.gz archives containing programs, configuration files, and dependency metadata. They have the extension .apk , and are often called «a-packs».

The packages are stored in one or more repositories. A repository is simply a directory with a collection of *.apk files. The directory must include a special index file, named APKINDEX.tar.gz to be considered a repository.

The apk utility can install packages from multiple repositories. The list of repositories to check is stored in /etc/apk/repositories , one repository per line. If you booted from a USB stick ( /media/sda1 ) or CD-ROM ( /media/cdrom ), your repository file probably looks something like this:

Contents of /etc/apk/repositories

In addition to local repositories, the apk utility uses busybox wget to fetch packages using http:, https: or ftp: protocols. The following is a valid repository file:

Contents of /etc/apk/repositories

Repository pinning

You can specify additional «tagged» repositories in /etc/apk/repositories :

Contents of /etc/apk/repositories

After which you can «pin» dependencies to these tags using:

apk add stableapp newapp@edge bleedingapp@testing

Apk will now by default only use the untagged repositories, but adding a tag to specific package:

1. will prefer the repository with that tag for the named package, even if a later version of the package is available in another repository

2. allows pulling in dependencies for the tagged package from the tagged repository (though it prefers to use untagged repositories to satisfy dependencies if possible)

Commandline repository options

By default, the apk utility will use the system repositories for all operations. This behavior can be overridden by the following options:

—repositories-file REPOFILE	Override the system repositories by specifying a repositories file.
-X|—repository REPO	Specify a supplemental repository that will be used in addition to the system repositories. This option can be provided multiple times.

Update the Package list

Remote repositories change as packages are added and upgraded. To get the latest list of available packages, use the update command. The command downloads the APKINDEX.tar.gz from each repository and stores it in the local cache, typically /var/cache/apk/ , /var/lib/apk/ or /etc/apk/cache/ .

Adding the —update-cache , or for short -U switch to another apk command, as in apk —update-cache upgrade or apk -U add . , the command has the same effect as first running apk update before the other apk command.

Add a Package

Use add to install packages from a repository. Any necessary dependencies are also installed. If you have multiple repositories, the add command installs the newest package.

apk add openssh apk add openssh openntp vim

If you only have the main repository enabled in your configuration, apk will not include packages from the other repositories. To install a package from the edge/testing repository without changing your repository configuration file, use the command below. This will tell apk to use that particular repository.

Add a local Package

To install a locally available apk package, for example if this device has no internet access but you can upload apk packages directly to it, use the —allow-untrusted flag:

apk add —allow-untrusted /path/to/file.apk

Note that multiple packages can be given. When installing a local package, all dependencies should also be specified. For example:

apk add —allow-untrusted /var/tig-2.2-r0.apk /var/git-2.11.1-20.apk

Remove a Package

Use del to remove a package (and dependencies that are no longer needed.)

apk del openssh apk del openssh openntp vim

Upgrade a Running System

Packages in general

To get the latest security upgrades and bugfixes available for the installed packages of a running system, first update the list of available packages and then upgrade the installed packages:

apk update apk upgrade

Or, combining the same into one single command:

Here is an example, showing the procedure on a system that has several additional repositories pinned:

To upgrade only specific packages, use the -u or —upgrade option of the add command:

apk update apk add —upgrade busybox

To enable unattended, automatic upgrades of packages, see the apk-autoupdate package.

To upgrade to a newer release, refer to the corresponding release notes and Upgrading_Alpine.

Upgrading «diskless» and «data» disk mode installs

If booting a «diskless» system from a read-only device, or iso image on writable media, it’s not possible to update the boot files (kernel, modules, firmware, . ) that reside on that device.

It becomes possible to update the boot files, though, if using a boot device that is writable and has been prepared with setup-bootable .

However, even then, the kernel, with its modules and firmware files, can still not be updated directly through regular packages updates. Instead, there is the update-kernel script that can generate initfs images and install them together with upgraded kernels.

Upgrading can be done as follows.

apk add mkinitfs

This package is required for the generation of the initial filesystem used during boot.

• Additional initfs features that are missing in the default configuration, like the «btrfs» filesystem support (at the time of writing, to allow loading .apkovl configs and package cache during boot), may be enabled in /etc/mkinitfs/mkinitfs.conf .
• Available initfs features may be listed with ls /etc/mkinitfs/features.d

ls /etc/mkinitfs/features.d apk add nano nano /etc/mkinitfs/mkinitfs.conf lbu commit

Finally update the kernel and its boot environment.

• An update-kernel run needs at least 8 GB free ram memory to avoid a broken modloop-image.
• See update-kernel —help for options to manually add additional module or firmware packages.

Search for Packages

The search command searches the repository Index files for installable packages.

The return format is Package—Version. Omit Version for apk add Package

To list all packages available, along with their descriptions:

To list all packages are part of the ACF system:

apk search -v ‘acf*’

To list all packages that list NTP as part of their description, use the -d or —description option:

apk search -v —description ‘NTP’

Information on Packages

apk info

The info command provides information on the contents of packages, their dependencies, and which files belong to a package.

For a given package, each element can be chosen (for example, -w to show just the webpage information), or all information displayed with the -a command.

apk info -a zlib

As shown in the example you can determine

• The description of the package (-d or —description)
• The webpage where the application is hosted (-w or —webpage)
• The size the package will require once installed (in bytes) (-s or —size)
• What packages are required to use this one (depends) (-R or —depends)
• What packages require this one to be installed (required by) (-r or —rdepends)
• The contents of the package, that is, which files it installs (-L or —contents)
• Any triggers this package sets. (-t or —triggers) Listed here are directories that are watched; if a change happens to the directory, then the trigger script is run at the end of the apk add/delete. For example, doing a depmod once after installing all packages that add kernel modules.

apk info —who-owns /sbin/lbu

Listing installed packages

To list all installed packages, use:

To list all installed packages in alphabetical order, with a description of each, do:

apk policy

To display the repository a package was installed from and will be updated from, plus any tagged or enabled repositories where it is also offered, if any, for this architecture — its policy:

Additional apk Commands

Local Cache

Overview

To have the packages available during boot, apk can keep a cache of installed packages on a local disk.

Added packages can then be automatically (re-)installed from local media into RAM when booting, without requiring, and even before there is a network connection.

The cache can be stored on any writable media, or at the same location as the .apkovl file from the local backup utility lbu .

Enabling Local Cache with current releases

Execute the script

and it will assist in enabling a local cache.

The script creates a symlink named /etc/apk/cache that points to the cache directory.

Cache maintenance

Removing older packages

When newer packages are added to the cache over time, the older versions of the packages default to remain in the cache directory.

The older versions of packages can be removed with the clean command.

apk cache clean

Or to see what is deleted include the verbose switch:

apk -v cache clean

Download missing packages

If you accidentally delete packages from the cache directory, you can make sure they are there with the download command,

apk cache download

Delete and download in one step

You can combine the two steps into one with the sync command — this cleans out old packages and downloads missing packages.

apk cache -v sync

Automatically Cleaning Cache on Reboot

To automatically attempt to validate your cache on reboot, you can add the above command to a /etc/local.d/*.stop file:

Contents of /etc/local.d/cache.stop

Special Caching Configurations

Enabling Local Cache on HDD installs

Note that HDD ‘sys’ installs don’t need an apk cache to maintain their state, it allows to serve packages over the network, though, e.g. to get installed by other local machines.

Manually create a cache dir and then symlink it to /etc/apk/cache:

mkdir -p /var/cache/apk ln -s /var/cache/apk /etc/apk/cache

Local Cache on tmpfs volumes

In some circumstances it might be useful to have the cache reside on tmpfs, for example if you only wish for it to last as long as the system is up.

NOTE: apk is coded to ignore tmpfs caches, and this is correct behaviour in most instances. Using tmpfs as a package cache can consume large amounts of system memory if you install a lot of packages, possibly resulting in a crashed system. You can limit this by restricting the size of your cache to a small number (128M in the example below).

To do it, you need to create an image inside which your cache can live. We do this by creating an image file, formatting it with ext2, and mounting it at /etc/apk/cache.

• apk add e2fsprogs
• dd if=/dev/zero of=/apkcache.img bs=1M count=128
• mkfs.ext2 -F /apkcache.img
• mkdir -p /etc/apk/cache
• mount -t ext2 /apkcache.img /etc/apk/cache
• apk update

As usual, if you want to download currently installed packages into the cache, use apk cache sync.

Manually Enabling Local Cache (required for releases prior to v2.3)

1. Create a cache directory on the storage device where you keep the lbu backups (typically, /dev/sda1 .)

mount -o remount,rw /media/sda1

and then don’t forget to run

mount -o remount,ro /media/sda1

when you are done with the following commands

1. Create a symlink to this directory from /etc/apk/cache .

ln -s /media/sda1/cache /etc/apk/cache

Run an lbu commit to save the change ( /etc/apk/cache is in /etc and is automatically backed up.)

mount -o remount,ro /media/sda1

now that you are done with saving the changes

Now whenever you run an apk command that pulls a new package from a remote repository, the package is stored on your local media. On startup, Alpine Linux will check the local cache for new packages, and will install them if available.

Advanced APK Usage

Holding a specific package back

In certain cases, you may want to upgrade a system, but keep a specific package at a back level. It is possible to add «sticky» or versioned dependencies. For instance, to hold the asterisk package to the 1.6.2 level or lower:

apk add asterisk=1.6.0.21-r0

apk add ‘asterisk 1.6.1’

will ensure that 1.6.1 is the minimum version used.

You can also use «fuzzy» version matching to pin the version to a major/minor release. For example:

apk add ‘asterisk=

will match any version of asterisk that starts with 1.6 (such as 1.6.0.21-r0 or 1.6.9.31-r9) Alpine source commit message

If you desire deterministic, repeatable package installation (such as with containerized environments) via package pinning, it is important to understand your package repo’s version retention rules. For example, most Alpine package repos contain an «edge» branch, which may drop package versions that are not deemed fit to make it into a stable branch. This means that pinning to a version on the edge branch may stop working after the package version is revoked from the repo. Always pin to a package version that is intended for your current Alpine Linux version.

Troubleshooting

«apk-tools is old»

apk update, apk upgrade or apk add may report the following:

This may happen if you are running Alpine Linux stable version with a certain edge/main, edge/community or testing package(s) also installed. One resolution is to consider upgrading apk-tools . If edge is already tagged in your repositories, then try:

Источник