Alpine Linux - User contributions [en]

User:Przemoc/Todo/Users and groups for AL 3.4

2021-07-02T11:58:10Z

Przemoc: Fix mailing list links (sourcehut-based).

What I wanted to do and did before AL 3.4 release and some fixing done afterwards.

__TOC__

== Pre-install/upgrade scripts ==

=== Improvements ===

==== Make all packages create only ''system'' users and groups ====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [https://git.alpinelinux.org/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. [2016-04-25]

It was part of patch set:
* [https://lists.alpinelinux.org/~alpine/aports/patches/2713 Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches) [2016-04-23]

=== Corrections ===

==== Fix problems introduced by adding -S to adduser ====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [https://git.alpinelinux.org/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. [2016-06-03]
* [https://git.alpinelinux.org/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. [2016-06-07]

They are (apart from the first one) part of patch set:
* [https://lists.alpinelinux.org/~alpine/aports/patches/928 Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches) [2016-06-06]

Patches for main and community are already cherry-picked in 3.4-stable branch as of 2016-06-20.

Following packages were overlooked before:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

My commit fixing them is:
* [https://git.alpinelinux.org/aports/commit/?id=94e0b0631f37 94e0b0631f37] testing/[various]: Add group and use it as primary in .pre-* scripts. [2016-06-20]

It is part of patch set:
* [https://lists.alpinelinux.org/~alpine/aports/patches/994 Forgotten pre-install addgroup/adduser fixes and fixes.] (5 patches) [2016-06-17]

==== Fix problems for those who already installed above mentioned packages in Alpine Linux 3.4.0 ====

Fixes in previous sections work only for people that haven't installed above mentioned packages within Alpine Linux 3.4.0.
Even package removal and reinstallation is not enough, because old entries in <code>/etc/passwd</code> and <code>/etc/group</code> remain.
You can remove these old entries before reinstallation using <code>deluser</code>, but before that you have to find all the files owned by that user (<code>find / -user NAME</code>) to fix ownership after package reinstallation, as group id will change and user id may change.

We cannot and shouldn't do such invasive changes in automatic way during upgrade.

I wanted to at least add missing groups and add users to them via upgrades in AL 3.4. (Mind that such users's primary group will not be changed either, i.e. from <code>nogroup</code>, because user could have changed it on her/his own.) But there wasn't much interest, even though I provided some patches, like for below examples (so called AL 3.4 band-aids for ccc056dbf9d3 in .pre-* script).

Examples of known problems for people upgrading from Alpine Linux 3.4.0:

* main/apache2: No <code>apache</code> group. (Default config uses <code>apache:apache</code>, so daemon won't start.)
* main/lighttpd: No <code>lighttpd</code> group.

I consider this topic in the context of AL 3.4 closed.

User:Przemoc/Todo/Users and groups for AL 3.4

2021-07-02T10:06:41Z

Przemoc: Provide dates next to commits in square brackets.

What I wanted to do and did before AL 3.4 release and some fixing done afterwards.

__TOC__

== Pre-install/upgrade scripts ==

=== Improvements ===

==== Make all packages create only ''system'' users and groups ====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [https://git.alpinelinux.org/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. [2016-04-25]

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

=== Corrections ===

==== Fix problems introduced by adding -S to adduser ====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [https://git.alpinelinux.org/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. [2016-06-03]
* [https://git.alpinelinux.org/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. [2016-06-07]
* [https://git.alpinelinux.org/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. [2016-06-07]

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Patches for main and community are already cherry-picked in 3.4-stable branch as of 2016-06-20.

Following packages were overlooked before:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

My commit fixing them is:
* [https://git.alpinelinux.org/aports/commit/?id=94e0b0631f37 94e0b0631f37] testing/[various]: Add group and use it as primary in .pre-* scripts. [2016-06-20]

It is part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3109.html Forgotten pre-install addgroup/adduser fixes and fixes.] (5 patches)

==== Fix problems for those who already installed above mentioned packages in Alpine Linux 3.4.0 ====

Fixes in previous sections work only for people that haven't installed above mentioned packages within Alpine Linux 3.4.0.
Even package removal and reinstallation is not enough, because old entries in <code>/etc/passwd</code> and <code>/etc/group</code> remain.
You can remove these old entries before reinstallation using <code>deluser</code>, but before that you have to find all the files owned by that user (<code>find / -user NAME</code>) to fix ownership after package reinstallation, as group id will change and user id may change.

We cannot and shouldn't do such invasive changes in automatic way during upgrade.

I wanted to at least add missing groups and add users to them via upgrades in AL 3.4. (Mind that such users's primary group will not be changed either, i.e. from <code>nogroup</code>, because user could have changed it on her/his own.) But there wasn't much interest, even though I provided some patches, like for below examples (so called AL 3.4 band-aids for ccc056dbf9d3 in .pre-* script).

Examples of known problems for people upgrading from Alpine Linux 3.4.0:

* main/apache2: No <code>apache</code> group. (Default config uses <code>apache:apache</code>, so daemon won't start.)
* main/lighttpd: No <code>lighttpd</code> group.

I consider this topic in the context of AL 3.4 closed.

User:Przemoc/Todo/Users and groups for AL 3.4

2021-07-02T10:03:22Z

Przemoc: Fix commit links (/cgit/ is no longer in path).

What I wanted to do and did before AL 3.4 release and some fixing done afterwards.

__TOC__

== Pre-install/upgrade scripts ==

=== Improvements ===

==== Make all packages create only ''system'' users and groups ====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [https://git.alpinelinux.org/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

=== Corrections ===

==== Fix problems introduced by adding -S to adduser ====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [https://git.alpinelinux.org/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [https://git.alpinelinux.org/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [https://git.alpinelinux.org/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [https://git.alpinelinux.org/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [https://git.alpinelinux.org/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [https://git.alpinelinux.org/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [https://git.alpinelinux.org/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Patches for main and community are already cherry-picked in 3.4-stable branch as of 2016-06-20.

Following packages were overlooked before:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

My commit fixing them is:
* [https://git.alpinelinux.org/aports/commit/?id=94e0b0631f37 94e0b0631f37] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-20)

It is part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3109.html Forgotten pre-install addgroup/adduser fixes and fixes.] (5 patches)

==== Fix problems for those who already installed above mentioned packages in Alpine Linux 3.4.0 ====

Fixes in previous sections work only for people that haven't installed above mentioned packages within Alpine Linux 3.4.0.
Even package removal and reinstallation is not enough, because old entries in <code>/etc/passwd</code> and <code>/etc/group</code> remain.
You can remove these old entries before reinstallation using <code>deluser</code>, but before that you have to find all the files owned by that user (<code>find / -user NAME</code>) to fix ownership after package reinstallation, as group id will change and user id may change.

We cannot and shouldn't do such invasive changes in automatic way during upgrade.

I wanted to at least add missing groups and add users to them via upgrades in AL 3.4. (Mind that such users's primary group will not be changed either, i.e. from <code>nogroup</code>, because user could have changed it on her/his own.) But there wasn't much interest, even though I provided some patches, like for below examples (so called AL 3.4 band-aids for ccc056dbf9d3 in .pre-* script).

Examples of known problems for people upgrading from Alpine Linux 3.4.0:

* main/apache2: No <code>apache</code> group. (Default config uses <code>apache:apache</code>, so daemon won't start.)
* main/lighttpd: No <code>lighttpd</code> group.

I consider this topic in the context of AL 3.4 closed.

How to make a custom ISO image

2017-05-30T15:31:00Z

Przemoc: Add info about sibling page using mkimage.

{{Obsolete|alpine-iso is deprecated since Alpine 3.5 in favor of mkimage scripts found in root of aports directory. Check also: [[How to make a custom ISO image with mkimage]].}}

This document explains how to build a custom ISO image using the alpine-iso scripts.

== Prerequisite ==

First make sure we have the needed tools
{{Cmd|apk add alpine-sdk xorriso syslinux}}

Then create signing keys (-i installs them in /etc/apk/keys which is required for later)
{{Cmd|abuild-keygen -i -a}}

Clone (or update) the [http://git.alpinelinux.org/cgit/alpine-iso.git/ alpine-iso git repository].
{{Cmd|git clone git://git.alpinelinux.org/alpine-iso}}

== Core Configuration ==

The alpine-iso scripts is a simple makefile which you need to feed with a ''<name>.conf.mk'' file and a ''<name>.packages''.

In the ''<name>.conf.mk'' we specify

;ALPINE_NAME
:name of iso image

;ALPINE_VERSION
:(optional) version string. Will default to todays date.

;KERNEL_FLAVOR
:(optional) either ''grsec'', ''vserver'' or ''pae''. Will default to grsec.

;MODLOOP_EXTRA
:(optional) Extra kernel module packages for the modloop image. For example: ''dahdi-linux-vserver''

;APK_REPOS
:(optional) Path to addidtional apk repository.

The ''<name>.packages'' is just a plaintext list of packages that should be included in the ISO image. You should always add ''alpine-base'' in there or the CD might not be able to boot. The dependencies for the packages will automatically be pulled in.

== A rescue CD example ==
As an example, let us make a rescue ISO image with packages needed for rescue operations. We call it ''alpine-rescue''

We create the ''alpine-rescue.conf.mk'' as follows:
ALPINE_NAME := alpine-rescue
KERNEL_FLAVOR := grsec
MODLOOP_EXTRA :=

If you are going to use a custom kernel, don't forget to specify KERNEL_FLAVOR_DEFAULT which will set the default kernel to boot.

And then the ''alpine-rescue.packages'' as:
alpine-base
bkeymaps
openssh
e2fsprogs
mdadm
lvm2
parted
debootstrap
ntfs-3g

{{Tip| Make sure your public keys are placed in /etc/apk/keys/ (example: root-xxxxxxxx.rsa.pub):
{{Cmd|ls /etc/apk/keys/}}

Learn apk-tools to find your home-built apk's:
{{Cmd|echo "~/.cache/abuild/" >> /etc/apk/repositories}}
}}

Make sure the apk index is up to date (so apk finds the packages):
{{Cmd|apk update}}

We create the ISO image by telling the makefile the profile name. The makefile target is ''iso''.
{{Cmd|<nowiki>make PROFILE=alpine-rescue iso</nowiki>}}

{{Tip| If you are building inside an LXC guest, use fakeroot:
{{Cmd|<nowiki>fakeroot make PROFILE=alpine-rescue iso</nowiki>}}
}}

To generate the sha256 sum we use the ''sha256'' make target.
{{Cmd|<nowiki>make PROFILE=alpine-rescue sha256</nowiki>}}

== Package lists ==

Beside the plaintext package lists in the git repository, there are more documented package lists contributed by Alpine users. Those lists can be transformed into a plain text description by <code>apk search --exact -v $(cat alpine.packages)</code>.

So far the lists below are available (check [[:Category:ISO|here]] for more.)

* [[Alpine_mini|Alpine Mini]]
* [[Alpine_rescue|Alpine Rescue]]
* [[Alpine_security|Alpine Security]]
* [[Alpine SCST]]

== Live Disk Setup with APKOVL ==

Once you have customized your custom ISO, you can now setup the live environment to operate outside of the standard installer as follows:

* Generate an APKOVL file with [[Alpine_local_backup|lbu]], <code>lbu ci</code>
* Alpine ISO requires the OVL Volume to be hosted on a web server. Put the APKOVL file on a webserver and identify the url.
* Uncomment the <code>APKOVL</code> line in the alpine flavor of your choice and set it to the address of your ovl volume.

Notes:

* Any packages you add to /etc/apk/world of your lbu will automatically be installed onto the live system image.
* If you don't have a web server you can run busybox's httpd temporarily - <code>busybox httpd -p 127.0.0.1:80</code>
* In general, <code>lbu</code> will only handle files in <code>/etc</code>, to customize this further, you need to add additional files.
* If you want to make a customized installer, you need to create <code>.default_boot_services</code> which will cause <code>mkinitfs</code> to create the defaults for the live image.

== Testing your ISO image ==

[[Qemu#Live_mode| Qemu]] is useful for a quick test of your created ISO image.

[[Category:Package Manager]]
[[Category:ISO]]

User:Przemoc/Todo

2017-05-30T13:19:27Z

Przemoc:

Todo:
* ...

Done:
* [[User:Przemoc/Todo/Users and groups for AL 3.4]]

User:Przemoc/Todo/Users and groups for AL 3.4

2017-05-30T13:16:51Z

Przemoc: Update

What I wanted to do and did before AL 3.4 release and some fixing done afterwards.

__TOC__

== Pre-install/upgrade scripts ==

=== Improvements ===

==== Make all packages create only ''system'' users and groups ====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

=== Corrections ===

==== Fix problems introduced by adding -S to adduser ====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Patches for main and community are already cherry-picked in 3.4-stable branch as of 2016-06-20.

Following packages were overlooked before:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

My commit fixing them is:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=94e0b0631f37 94e0b0631f37] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-20)

It is part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3109.html Forgotten pre-install addgroup/adduser fixes and fixes.] (5 patches)

==== Fix problems for those who already installed above mentioned packages in Alpine Linux 3.4.0 ====

Fixes in previous sections work only for people that haven't installed above mentioned packages within Alpine Linux 3.4.0.
Even package removal and reinstallation is not enough, because old entries in <code>/etc/passwd</code> and <code>/etc/group</code> remain.
You can remove these old entries before reinstallation using <code>deluser</code>, but before that you have to find all the files owned by that user (<code>find / -user NAME</code>) to fix ownership after package reinstallation, as group id will change and user id may change.

We cannot and shouldn't do such invasive changes in automatic way during upgrade.

I wanted to at least add missing groups and add users to them via upgrades in AL 3.4. (Mind that such users's primary group will not be changed either, i.e. from <code>nogroup</code>, because user could have changed it on her/his own.) But there wasn't much interest, even though I provided some patches, like for below examples (so called AL 3.4 band-aids for ccc056dbf9d3 in .pre-* script).

Examples of known problems for people upgrading from Alpine Linux 3.4.0:

* main/apache2: No <code>apache</code> group. (Default config uses <code>apache:apache</code>, so daemon won't start.)
* main/lighttpd: No <code>lighttpd</code> group.

I consider this topic in the context of AL 3.4 closed.

User:Przemoc/Todo

2017-05-30T12:49:08Z

Przemoc: Przemoc moved page User:Przemoc/Todo to User:Przemoc/Todo/Users and groups for AL 3.4: It became one topic page, so let it truly be.

#REDIRECT [[User:Przemoc/Todo/Users and groups for AL 3.4]]

User:Przemoc/Todo/Users and groups for AL 3.4

2017-05-30T12:49:07Z

Przemoc: Przemoc moved page User:Przemoc/Todo to User:Przemoc/Todo/Users and groups for AL 3.4: It became one topic page, so let it truly be.

What I want to do for AL.

__TOC__

== Users and groups ==

=== Pre-install/upgrade scripts ===

==== Improvements ====

===== Make all packages create only ''system'' users and groups =====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

==== Corrections ====

===== Fix problems introduced by adding -S to adduser =====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Patches for main and community are already cherry-picked in 3.4-stable branch as of 2016-06-20.

Following packages were overlooked before:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

My commit fixing them is:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=94e0b0631f37 94e0b0631f37] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-20)

It is part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3109.html Forgotten pre-install addgroup/adduser fixes and fixes.] (5 patches)

===== Fix problems for those who already installed above mentioned packages in Alpine Linux 3.4.0 =====

Fixes in previous sections work only for people that haven't installed above mentioned packages within Alpine Linux 3.4.0.
Even package removal and reinstallation is not enough, because old entries in <code>/etc/passwd</code> and <code>/etc/group</code> remain.
You can remove these old entries before reinstallation using <code>deluser</code>, but before that you have to find all the files owned by that user (<code>find / -user NAME</code>) to fix ownership after package reinstallation, as group id will change and user id may change.

We cannot and shouldn't do such invasive changes in automatic way during upgrade, but we can at least add missing groups and add users to them. Mind that such users's primary group will not be changed either (from <code>nogroup</code>), because user could have changed it on her/his own.

Below I'll try to document all known problems:

* main/apache2: No <code>apache</code> group. (Default config uses <code>apache:apache</code>, so daemon won't start.) (sent to ML already, but it's postponed as it will be a part of bigger pull request(s) - it was discussed with ncopa on IRC)

{{todo|Go through all packages, starting from main.}}

User:Przemoc/Todo/Users and groups for AL 3.4

2016-06-20T16:52:24Z

Przemoc: Update

User:Przemoc/Todo/Users and groups for AL 3.4

2016-06-20T16:48:54Z

Przemoc: Update

What I want to do for AL.

__TOC__

== Users and groups ==

=== Pre-install/upgrade scripts ===

==== Improvements ====

===== Make all packages create only ''system'' users and groups =====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

==== Corrections ====

===== Fix problems introduced by adding -S to adduser =====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Following packages were overlooked before:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

My commit fixing them is:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=94e0b0631f37 94e0b0631f37] testing/[various]: Add group and use it as primary in .pre-* scripts.

It is part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3109.html Forgotten pre-install addgroup/adduser fixes and fixes.] (5 patches)

===== Fix problems for those who already installed above mentioned packages in Alpine Linux 3.4.0 =====

Fixes in previous sections work only for people that haven't installed above mentioned packages within Alpine Linux 3.4.0.
Even package removal and reinstallation is not enough, because old entries in <code>/etc/passwd</code> and <code>/etc/group</code> remain.
You can remove these old entries before reinstallation using <code>deluser</code>, but before that you have to find all the files owned by that user (<code>find / -user NAME</code>) to fix ownership after package reinstallation, as group id will change and user id may change.

We cannot and shouldn't do such invasive changes in automatic way during upgrade, but we can at least add missing groups and add users to them. Mind that such users's primary group will not be changed either (from <code>nogroup</code>), because user could have changed it on her/his own.

Below I'll try to document all known problems:

* main/apache2: No <code>apache</code> group. (Default config uses <code>apache:apache</code>, so daemon won't start.) (sent to ML already, but it's postponed as it will be a part of bigger pull request(s) - it was discussed with ncopa on IRC)

{{todo|Go through all packages, starting from main.}}

User:Przemoc/Todo/Users and groups for AL 3.4

2016-06-20T10:23:30Z

Przemoc: Update.

What I want to do for AL.

__TOC__

== Users and groups ==

=== Pre-install/upgrade scripts ===

==== Improvements ====

===== Make all packages create only ''system'' users and groups =====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

==== Corrections ====

===== Fix problems introduced by adding -S to adduser =====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Following packages still need patches:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

These patches have been already sent to ML in patch set:
* Forgotten pre-install addgroup/adduser fixes and fixes. (5 patches)

===== Fix problems for those who already installed above mentioned packages in Alpine Linux 3.4.0 =====

Fixes in previous sections work only for people that haven't installed above mentioned packages within Alpine Linux 3.4.0.
Even package removal and reinstallation is not enough, because old entries in <code>/etc/passwd</code> and <code>/etc/group</code> remain.
You can remove these old entries before reinstallation using <code>deluser</code>, but before that you have to find all the files owned by that user (<code>find / -user NAME</code>) to fix ownership after package reinstallation, as group id will change and user id may change.

We cannot and shouldn't do such invasive changes in automatic way during upgrade, but we can at least add missing groups and add users to them. Mind that such users's primary group will not be changed either (from <code>nogroup</code>), because user could have changed it on her/his own.

Below I'll try to document all known problems:

* main/apache2: No <code>apache</code> group. (Default config uses <code>apache:apache</code>, so daemon won't start.) (sent to ML already)

{{todo|Go through all packages, starting from main.}}

User:Przemoc/Todo/Users and groups for AL 3.4

2016-06-17T15:28:06Z

Przemoc: Better formatting.

What I want to do for AL.

__TOC__

== Users and groups ==

=== Pre-install/upgrade scripts ===

==== Improvements ====

===== Make all packages create only ''system'' users and groups =====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

==== Corrections ====

===== Fix problems introduced by adding -S to adduser =====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Following packages still need patches:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

These patches have been already sent to ML in patch set:
* Forgotten pre-install addgroup/adduser fixes and fixes. (5 patches)

===== Fix problems for those who already installed above mentioned packages in Alpine Linux 3.4.0 =====

Fixes in previous sections work only for people that haven't installed above mentioned packages within Alpine Linux 3.4.0.
Even package removal and reinstallation is not enough, because old entries in <code>/etc/passwd</code> and <code>/etc/group</code> remain.
You can remove these old entries before reinstallation using <code>deluser</code>, but before that you have to find all the files owned by that user (<code>find / -user NAME</code>) to fix ownership after package reinstallation, as group id will change and user id may change.

We cannot and shouldn't do such invasive changes in automatic way during upgrade, but we can at least add missing groups and add users to them. Mind that such users's primary group will not be changed either (from <code>nogroup</code>), because user could have changed it on her/his own.

Below I'll try to document all known problems:

* main/apache2: No <code>apache</code> group. (Default config uses <code>apache:apache</code>, so daemon won't start.)

{{todo|Go through all packages, starting from main.}}

User:Przemoc/Todo/Users and groups for AL 3.4

2016-06-17T15:11:56Z

Przemoc: Update

What I want to do for AL.

__TOC__

== Users and groups ==

=== Pre-install/upgrade scripts ===

==== Improvements ====

===== Make all packages create only ''system'' users and groups =====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

==== Corrections ====

===== Fix problems introduced by adding -S to adduser =====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Following packages still need patches:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

These patches have been already sent to ML in patch set:
* Forgotten pre-install addgroup/adduser fixes and fixes. (5 patches)

===== Fix problems for those who already installed above mentioned packages in Alpine Linux 3.4.0 =====

Fixes in previous sections work only for people that haven't installed above mentioned packages within Alpine Linux 3.4.0.
Even package removal and reinstallation is not enough, because old entries in <code>/etc/passwd</code> and <code>/etc/group</code> remain.
You can remove these old entries before reinstallation using <code>deluser</code>, but before that you have to find all the files owned by that user (<code>find / -user NAME</code>) to fix ownership after package reinstallation, as group id will change and user id may change.

We cannot and shouldn't do such invasive changes in automatic way during upgrade, but we can at least add missing groups and add users to them. Mind that such users's primary group will not be changed either (from nogroup), because user could have changed it on her/his own.

Below I'll try to document all known problems

* main/apache2: No <code>apache</code> group. (Default config uses <code>apache:apache</code>, so daemon won't start.)

{{todo|Go through all packages, starting from main.}}

User:Przemoc/Todo/Users and groups for AL 3.4

2016-06-17T01:58:47Z

Przemoc: Update regarding needed patches.

What I want to do for AL.

__TOC__

== Users and groups ==

=== Pre-install/upgrade scripts ===

==== Improvements ====

===== Make all packages create only ''system'' users and groups =====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

==== Corrections ====

===== Fix problems introduced by adding -S to adduser =====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Following packages still need patches:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

These patches have been already sent to ML in patch set:
* Forgotten pre-install addgroup/adduser fixes and fixes. (5 patches)

User:Przemoc/Todo/Users and groups for AL 3.4

2016-06-15T10:33:42Z

Przemoc: Fix omission

What I want to do for AL.

__TOC__

== Users and groups ==

=== Pre-install/upgrade scripts ===

==== Improvements ====

===== Make all packages create only ''system'' users and groups =====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

==== Corrections ====

===== Fix problems introduced by adding -S to adduser =====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from the first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.] (15 patches)

Following packages still need patches:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

User:Przemoc/Todo/Users and groups for AL 3.4

2016-06-15T10:31:34Z

Przemoc: Fix formatting

What I want to do for AL.

__TOC__

== Users and groups ==

=== Pre-install/upgrade scripts ===

==== Improvements ====

===== Make all packages create only ''system'' users and groups =====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

==== Corrections ====

===== Fix problems introduced by adding -S to adduser =====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts. (2016-06-07)

They are (apart from first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.]

Following packages still need patches:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

User:Przemoc/Todo/Users and groups for AL 3.4

2016-06-15T08:25:05Z

Przemoc: Created page with "What I want to do for AL. __TOC__ == Users and groups == === Pre-install/upgrade scripts === ==== Improvements ==== ===== Make all packages create only ''system'' users a..."

What I want to do for AL.

__TOC__

== Users and groups ==

=== Pre-install/upgrade scripts ===

==== Improvements ====

===== Make all packages create only ''system'' users and groups =====

'''(MOSTLY DONE)'''
Call <code>adduser</code> and <code>addgroup</code> with <code>-S</code> option in pre-install/upgrade scripts.
It's mostly done already and only mostly, because 1) some new packages might have been added that aren't using <code>-S</code> yet and 2) it introduced problems, which aren't fully fixed yet.

{{note|
System user creation doesn't add same named group and uses nogroup as primary group unless explicitly specified via <code>-G</code>.

It means that system user creation (<code>adduser</code> with <code>-S</code> option present)
differs from normal user creation (<code>adduser</code> without <code>-S</code> option) in more
ways than the range of used UIDs and the default GECOS field.

Normal user, when created via <code>adduser</code>, gets its own automatically
created group, and this group becomes primary group of that user.
Group creation can be avoided if <code>-G</code> option is used, but then already
existing group has to be provided there.

System user, when created via <code>adduser</code>, never gets its own automatically
created group and by default primary group of that user becomes group
called <code>nogroup</code>, unless <code>-G</code> option is used to provide other already
existing group.
}}

My commit:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=ccc056dbf9d3 ccc056dbf9d3] Add lacking -S option (system) to adduser/addgroup in scripts. (2016-04-25)

It was part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/2909.html Pre-upgrade/pre-install addgroup/adduser cleanings] (7 patches)

==== Corrections ====

===== Fix problems introduced by adding -S to adduser =====

'''(MOSTLY DONE)'''
I somehow overlooked different adduser behavior explained in above note
and thus my sole adding of <code>-S</code> to <code>adduser</code> calls
in commit ccc056dbf9d3
(i.e. without proper <code>-G</code> option and preceding <code>addgroup</code> call when needed)
proved to be drastic in effects, i.e. status quo has not been preserved,
because primary groups of those users in new Alpine Linux installations has been changed.
Alpine Linux 3.4.0 is affected by this.

Lesson relearned. Beware of such small and allegedly "cosmetic" changes!

Pre-install/upgrade scripts are already mostly fixed in master branch of aports repository.

Packages creating users that were badly touched by commit ccc056dbf9d3 and should have been already fixed:
* community/caddy
* community/domoticz
* community/oscam
* community/syncthing
* main/apache2
* main/aports-build
* main/atheme-iris
* main/clamav
* main/clamsmtp
* main/coova-chilli
* main/dhcp
* main/djbdns
* main/dovecot
* main/ez-ipupdate
* main/fetchmail
* main/freeswitch
* main/gitolite
* main/gnats
* main/gross
* main/icecast
* main/lighttpd
* main/memcached
* main/ngircd
* main/nrpe
* main/openntpd
* main/postgrey
* main/snort
* main/squid
* main/transmission
* main/znc
* testing/at
* testing/dbmail
* testing/dspam
* testing/opensips
* testing/pdns
* testing/qpage
* testing/rrdbot
* testing/wt

My commits fixing them are:
* [http://git.alpinelinux.org/cgit/aports/commit/?id=1de4b02204f7 1de4b02204f7] main/lighttpd: Fix lighttpd user's primary group. (2016-06-03)
* [http://git.alpinelinux.org/cgit/aports/commit/?id=f27dface22b3 f27dface22b3] testing/at: Properly set primary group in .pre-install.
* [http://git.alpinelinux.org/cgit/aports/commit/?id=40521bdafd3c 40521bdafd3c] main/dovecot: Properly set primary group in .pre-install.
* [http://git.alpinelinux.org/cgit/aports/commit/?id=3c1fa46624bd 3c1fa46624bd] main/{npre, postgrey}: Properly set primary group in .pre-install.
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a7d67c695ca2 a7d67c695ca2] main/[various]: Add group and use it as primary in .pre-* scripts.
* [http://git.alpinelinux.org/cgit/aports/commit/?id=5708404c50a7 5708404c50a7] community/[various]: Add group and use it as primary in .pre-* scripts.
* [http://git.alpinelinux.org/cgit/aports/commit/?id=a835b6916533 a835b6916533] testing/[various]: Add group and use it as primary in .pre-* scripts.

They are (apart from first one) part of patch set:
* [http://lists.alpinelinux.org/alpine-aports/3059.html Pre-upgrade/pre-install addgroup/adduser fixes.]

Following packages still need patches:
* testing/buildbot
* testing/buildbot-slave
* testing/clapf

User:Przemoc

2016-06-15T07:18:26Z

Przemoc:

[[User:Przemoc/Notes]]

[[User:Przemoc/Todo]]

User:Przemoc

2016-06-15T07:17:28Z

Przemoc: Link my todo list

[[User:Przemoc/Notes]]
[[User:Przemoc/Todo]]

User:Przemoc/Notes

2016-06-14T23:13:38Z

Przemoc: AL 3.3.3: Applications/Irssi

I finally installed AL and I'm poking it a bit. Here you can find some notes regarding this experience. They should be helpful, but please use them with caution. I may add some additional commentary sometimes. If you think there is a better way to perform some of mentioned here tasks, then don't hesitate to notify me about it. Top-level headings denotes AL version that was used. Backward and forward compatibility is possible, but not tested.

__TOC__

== Alpine Linux 3.3.3 ==

=== Shell ===

Even though I always try to write POSIX sh-compliant scripts, I like to have <code>bash</code> as my default shell, because it's quite handy. Being able to write for instance quick <code>diff -u <(COMMAND1) <(COMMAND2)</code> (to compare output of two commands) or <code>mv FILE{,SUFFIX}</code> (to rename file by adding suffix) is very convenient.

==== Bash as default shell ====

AL doesn't have <code>vipw</code>, so root has to perform <code>vi /etc/passwd</code> himself to change the last field of root record (should be the first line in the file). You have to install ''util-linux'' package to get <code>chsh</code> utility.

==== Activate color prompt ====

Initial prompt: <code style="background-color:black;color:gray;">baytrail:~# </code>

{{cmd|mv /etc/profile.d/color_prompt{,.sh}
}}

Prompt after above change and relogin: <code style="background-color:black;color:gray;">baytrail [~]# </code>

In case of normal users it's: <code style="background-color:black;color:gray;">baytrail [~]$ </code>

==== Long history ====

I like to have long history, so I created following file:

{{Cat|/etc/profile.d/long_history.sh|export HISTSIZE{{=}}9999999
export HISTFILESIZE{{=}}$HISTSIZE
}}

=== Console ===

If you have physical access to screen connected to your machine with AL, it's nice to have properly configured console.

==== UTF-8 encoding ====

To have UTF-8 from OpenRC point of view, you have to set in <code>/etc/rc.conf</code>:
<pre>unicode="YES"</pre>
and add <code>/etc/init.d/termencoding</code> to autostart:
{{cmd|rc-update add termencoding}}
In fact it's mostly irrelevant (prove me wrong).

==== Font with polish letters ====

To be able to see polish letters, you have to install ''kbd-misc'' package, set in <code>/etc/conf.d/consolefont</code>:
<pre>consolefont="lat2-sun16.psfu.gz"
consoletranslation="8859-2_to_uni.trans"</pre>
and add <code>/etc/init.d/consolefont</code> to autostart:
{{cmd|rc-update add consolefont}}

If you don't like default <code>default8x16.psf.gz</code> font, then use <code>lat2-16.psfu.gz</code> instead. If you're comfortable with lower letter height, then I suggest using <code>lat2-14.psfu.gz</code>, which is still readable, yet on my 1920x1200 display increases LINES number from 75 to 85.

==== Keymap with only right Alt used for inputting polish letters ====

Default polish keymap <code>pl</code> uses both Alt keys for polish letters. If you prefer left Alt to be usable for other stuff (like switching to active window in irssi via Alt+A), then you have to switch to <code>pl1</code> variant. ''bkeymaps'' package is needed for setting, but can be removed later.
{{cmd|setup-keymap pl pl1}}

==== UTF-8 in tmux ====

tmux checks upon start-up whether environment variable <code>LC_ALL</code>, or if it's empty then <code>LC_CTYPE</code>, or if it's empty then <code>LANG</code>, contain string <code>UTF-8</code> or <code>UTF8</code> to activate its UTF-8 mode. It can be also triggered by <code>-u</code> option. Important part is that globally turning on <code>utf8</code> window option in tmux configuration doesn't enforce UTF-8 mode.

musl has locale system since v1.1.4, it was incomplete and experimental, but I'm not sure how it is now. The thing is it's not leveraged by AL and by default you have no <code>LC_*</code> variables set. In musl built-in default is <code>C.UTF-8</code>, so we can simply create one file to set <code>LC_CTYPE</code> to such default value and it will satisfy tmux check:

{{Cat|/etc/profile.d/locale.sh|export LC_CTYPE{{=}}C.UTF-8
}}

Possible alternative is to alias <code>tmux</code> to <code>tmux -u</code>, but it seems clunky.

==== Serial console ====

To get tty on serial port you have to uncomment line in <code>/etc/inittab</code>:
<pre>
ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100
</pre>
If you want to be able to log as root using serial console, you have to add the serial port (here: <code>ttyS0</code>) to <code>/etc/securetty</code>.

Finally you can reload <code>init</code> process configuration:
{{cmd|kill -HUP 1
}}
Now you'll see login stuff on the serial port.

=== Disk ===

==== Set up RAID1 on two devices ====

<pre>
# install package
apk add mdadm

# load "raid1" module during boot (not really needed if you perform further steps)
echo raid1 >>/etc/modules

# create RAID1 array on two whole disks with 1MB data offset
mdadm --create --level=1 --raid-devices=2 --data-offset=1M /dev/md0 /dev/sda /dev/sdb

# preserve original example mdadm.conf
mv /etc/mdadm.conf{,.orig}

# save current setup into configuration file
# (usually people do not use -v, but it's more readable)
mdadm --detail -v --scan >/etc/mdadm.conf

# add raid devices starting to autostart
rc-update add mdadm-raid

# add raid devices monitoring to autostart
rc-update add mdadm

# start raid devices monitoring now
/etc/init.d/mdadm start

# following steps are needed if you want to support RAID early during boot

# add "raid" to features (space-separated values)
vi /etc/mkinitfs/mkinitfs.conf

# rebuild /boot/initramfs-grsec
mkinitfs

# add "raid1" to modules (comma-separated values)
vi /etc/update-extlinux.conf

# update extlinux
update-extlinux
</pre>

==== Install smartctl and smartd ====

<pre>
# install package
apk add smartmontools

# comment DEVICESCAN and uncomment DEVICESCAN -R 194 -R 231 -I 9
# to get meaningful and useful raw temperature in syslog
vi /etc/smartd.conf

# add smartd service to autostart
rc-update add smartd

# start the service now
/etc/init.d/smartd start
</pre>

=== Sensors ===

==== lm_sensors ====

<pre>
# install package
apk add lm_sensors

# install package for detecting sensors (if needed) - installs perl too
apk add lm_sensors-detect

# load module required for detecting sensors
modprobe i2c-dev

# detect sensors (skip scanning Super I/O, IPMI, ISA if you're on grsec)
sensors-detect

# after detecting sensors you can remove perl (if you don't need it)
apk del perl
</pre>

===== Problems =====

<ol>
<li><code>sensors-detect</code> command created <code>/etc/modules-load.d/lm_sensors.conf</code> file, but its first line is a comment, which leads to following message during boot
<pre>
modprobe: ERROR: missing parameters. See -h.
</pre>
It can be fixed by improving sed command in <code>/etc/init.d/modules</code> from <code>'s/\#.*//g'</code> to <code><nowiki>'s/\#.*//g;/^[[:space:]]*$/d'</nowiki></code> (deleting blank lines).
{{note|Patch has been sent to alpine-devel ML. http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3432. It was applied in commit [http://git.alpinelinux.org/cgit/aports/commit/?id{{=}}fc95677dd60833bca07ad5c2a037058e94471ff7 fc95677dd608] (2016-04-21)}}

<li>It seems that nowadays you don't have to add <code>lm_sensors</code> to autostart, because in AL ''lm_sensors'' package is patched to create file <code>/etc/modules-load.d/lm_sensors.conf</code> (files in this directory are inspected by <code>/etc/init.d/modules</code>). <code>/etc/init.d/lm_sensors</code> seems in fact superfluous and it also doesn't work
<pre>
* /etc/conf.d/lm_sensors does not exist, try running sensors-detect
* ERROR: lm_sensors failed to start
</pre>
because it expects old file (<code>/etc/conf.d/lm_sensors</code>), which is no longer provided.
{{note|Problem has been reported to alpine-devel ML: http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3433. File has been removed in commit [http://git.alpinelinux.org/cgit/aports/commit/?id{{=}}05ca027f69eb029ba8ddc97700639dbe5cb3ad91 05ca027f69eb] (2016-04-20).
}}

</ol>

=== Mail ===

I don't need my own real mail server (as it's kind of PITA to set it up properly nowadays). Simple MTA is good enough. In the old days I used ssmtp, but it stopped being maintained (apparently debian devs maintain it now), so I switched to msmtp.

==== msmtp ====

After installing ''msmtp'' package, you need to create configuration file in your home directory. You can find example for Zoho Mail account.

{{Cat|~/.msmtprc|defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
auth on
port 587

account yourname@zoho.com
from yourname@zoho.com
user yourname@zoho.com
host smtp.zoho.com

account default : yourname@zoho.com
}}

You'll be asked for password every time mail is sent.

===== Problems =====

If you use gmail, then it's no longer that simple. After changing each zoho to gmail in above exemplary configuration, you still won't be able to send any mail. You'll get:

<pre>msmtp: server message: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=...> Please log in via your web browser and then try again.
msmtp: server message: 534-5.7.14 Learn more at
msmtp: server message: 534-5.7.14 https://support.google.com/mail/answer/78754 ...
</pre>

and you'll receive e-mail titled "Sign-in attempt prevented".

You have to [https://www.google.com/settings/security/lesssecureapps turn on less secure apps] if you want to deal with it. If you're using 2-step verification, then you'll have to [https://security.google.com/settings/security/apppasswords add app password for msmtp].

=== Applications ===

Some tips for some applications.

==== Irssi ====

Irssi is my IRC client of choice.

===== /script support =====

You have to add following line in <code>~/.irssi/startup</code>:
<pre>/LOAD perl</pre>

Creating an Alpine package

2016-06-06T00:16:59Z

Przemoc: /* install */ Fix $pkgname.pre-install example

== Requirements ==

To build a package for Alpine Linux you need an Alpine Linux installation. Check the [[Installation]] page to see all available installation options.

== Setup your system and account ==
{{:Include:Setup_your_system_and_account_for_building_packages}}

== Getting some help ==

It might be wise to start by checking what the [[Abuild|abuild]] program can/cannot do.

{{Cmd|abuild -h}}

== Creating an APKBUILD file ==

=== Use a template APKBUILD ===

To create the actual APKBUILD file {{Pkg|newapkbuild}} can serve you a template to start with. It will create a directory with the given package name, place an example/template APKBUILD file to the given directory, and fill some variables if those are provided. Please check the [[Package_policies| package policies]] page about naming details.

If you doubt to which repository your package belongs to you can safely use '''testing'''. Building package in your aports/testing directory is not mandatory but this way the package is already at the right place.

{{:Include:Newapkbuild}}

{{Note|On older Alpine systems, abuild -c -n ''packagename'' was the way to create APKBUILD files. The 'packagename' was a parameter to the -n option so order of -c and -n matters. }}

[[Abuild_and_Helpers#apkbuild-cpan|apkbuild-cpan]] simplifies the creation of perl packages from CPAN and [[Abuild_and_Helpers#apkbuild-pypi|apkbuild-pypi]] ease the generation of APKBUILD files for python packages from PyPi.

If you are create a daemon package which needs initd scripts you can add the -c making it:

{{Cmd|newapkbuild -c ''packagename''}}

This will copy the sample initd and confd files to the build directory. 
A third file sample.install file will be copied as well (we will discuss this later on).

=== Modify your APKBUILD ===
Edit APKBUILD and fill in the needed info (especially pkgname, pkgver, pkgdesc, url, license, depends and source).

If you are going to use any of the variables for directories like $pkgdir, always make sure they are double quoted like:

"$pkgdir"/somedir

This will prevent issues with spaces/special characters in the future.

{{Note|If you like syntax highlighting we suggest you to install vim. We have setup vim to recognize the APKBUILD file as a bash scripts so its easier to read them.}}

=== APKBUILD variables/functions ===

==== source ====

The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[Creating an Alpine package#install|install variable]]), patches, and all other necessary files.

Here are few things to note:

* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
: {{cmd|abuild checksum}}
: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre>
: (or similar depending on the package).

* When the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
: You must prepend '${pkgname}-${pkgver}.tar.gz::' to the protocol, like so:
: <pre>source="${pkgname}-${pkgver}.tar.gz::http://oss.example.org/?get=software&ver=1.0"</pre>
: This causes the file to be saved as ''software-1.0.tar.gz'' where abuild can use it, instead of ''?get=software&ver=1.0'', where abuild cannot use it.

* Some projects didn't provide a release tarball. If you point source to an tarball provided by a git web interface (gitweg, cgit, github), such as:
: <pre>http://repo.or.cz/w/gitstats.git/snapshot/ad7efbb9399e60cee6cb217c6b47e604174a8093.tar.gz</pre>
: You will run into issues because the checksum changes when downloading on the build system.

* abuild currently supports the following protocols for remote file retrieval:
** http
** https
** ftp



* abuild currently supports the following archive types/archive file extensions:
** .tar.gz / .tgz
** .tar.bz2
** .tar.lzma
** .tar.xz
** .zip

==== depends & makedepends ====

Depends are the actual running dependencies that a package would need when it is running. Makedepends are only needed when you are building a package. If you set a package, in depends you do not need to add it to makedepends as well. The best way to find out what the depends and makedepends of a package are is to [http://en.wikipedia.org/wiki/Rtfm RTFM].

No kidding, lots of important information can be found it the package INSTALL and README file (or the likes). Another good way is the run <code>./configure --help</code> from the source directory to see which options are needed for configure to finish without errors. If you do not yet have a source directory you can create one with the command:

{{Cmd|abuild unpack}}

Running <code>configure</code> will also show you how you can disable a specific option for this package. A good example is for instance "--disable-nls" which will disable native language support and thus does not depend on gettext (libiconv, glib, ...).

Alpine likes to keep things small, so we try to disable as much as possible without losing too many features. The exact disable/enable options are decided the package builder but please try to follow Alpine's design concept as much as possible.

An easy way of quickly finding out the build info for a package is to check Arch Linux (Alpine package management and build scripts are similar) or Gentoo Linux ebuilds (previous versions of Alpine were based on Gentoo).

* [http://www.gentoo-portage.com Search ebuilds]
* [http://sources.gentoo.org/viewcvs.py/gentoo-x86/ Gentoo CVS]
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

After the package is successfully compiled and created we should make sure it didn't link to any package that is not present in the <code>$depends</code> variable. We do this by using <code>scanelf</code>. If scanelf is not yet installed on your system you can do that by installing {{Pkg|pax-utils}}.

{{Cmd|scanelf -nR pkg}}

An example output of {{Pkg|libcurl}} would be:

ET_DYN libssl.so.0.9.8,libcrypto.so.0.9.8,libz.so.1,libc.so.0,ld-uClibc.so.0 pkg/usr/lib/libcurl.so.4.1.1

You can see the needed files and should be able to find out which file belongs to which package.

==== license ====

The '''license''' tag must reflect the license of the source code. Please check the source tarball for COPYING, LICENSE, or other files with names that indicates that it contains licensing information. Beside the license file most developer include headers in the source code files with licensing details. Please use the short name and the release number in the license tag, e.g

{| cellpadding="5" border="1" class="wikitable"
|-
! Short name
! Full name
|-
| GPL2
| GNU General Public License Version 2.0
|-
| LGPL2+
| GNU Lesser General Public License Version 2.1
|-
| ASL 2.0
| Apache License Version 2.0
|-
| BSD
| BSD License
|-
| MIT
| MIT license
|-
| MPL 2.0
| Mozilla Public License v2.0
|-
| ZPL 2.0
| Zope Public License v 2.0
|-
| PHP
| PHP License v3.0
|-
| zlib
| zlib/libpng License
|-
|}

For the GNU General Public License the '+' means ''or (at your option) any later version.'' which covers future releases of that license. We skip the ''v'' because it's obvious that the number shows the version. If you are unsure about the short name of a license, please check the resources below for additional information.

* [https://wiki.archlinux.org/index.php/Licenses ArchLinux and Licensing]
* [https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses Fedora and Licensing]

If a package has a special/custom license we need to provide it with the release. Because we want to save space and don't like to have licenses all over our system we have decided to include the license in the doc subpackage. Please follow the following guidelines to add a proper license. Locate the license file inside the source package. Add the doc subpackage to the $subpackages variable as follows:

subpackages="$pkgname-doc"

Add a similar line to the following to your package() function, depending on the license description file:

install -Dm644 COPYING "$pkgdir"/usr/share/licenses/$pkgname/COPYING

If you follow these steps then abuild will automatically add the license to the package-doc apk for you.

==== arch ====

The package architecture(s) to build for. This can be one of: ''x86, x86_64, all,'' or ''noarch'', where ''all'' means all architectures, and ''noarch'' means it's architecture-independent (ie, a pure-python package).
{{Tip|To determine if your APKBUILD can use ''noarch'', build the package for your architecture and then run "scanelf -R pkg" from the directory that the APKBUILD resides in, in order to scan for ELF files in the ''./pkg'' directory. If you do NOT get output from this, then ''noarch'' can be used.}}

==== url ====

Website address for the program. This is usefully later on when either finding documentation or other information about the package.

==== pkgdesc ====

A brief, one line, description of what the package does. Useful for the package management system.

Here is an example from apk_info for the OpenSSH client package

pkgdesc="Port of OpenBSD's free SSH release - client"

==== pkgver ====

Provide the release number of the package you are building.

==== pkgrel ====

The $pkgrel versioning is made so if you change something to your APKBUILD file without changing the actual $pkgver you can higer pkgrel so apk tools will detect it as an update. For instance if you forget to add a dependency you can add it afterward and you can +1 pkgver so apk finds this update and add the missing dependency. When there's an upstream version changes, we reset the pkgrel to 0.

==== pkgname ====

The base name of the package you are creating. For Freeswitch 1.0.6, you would use "freeswitch"

==== install ====

There are 6 different kinds of install scripts. Each script is called with the $pkgname.''<action>'' where ''<action>'' is one of the following:

<dl>
<dt>$pkgname.pre-install
<dd>This script is executed before package is installed. Typical use is when package needs a group and a user to be created. For example:
<pre>
#!/bin/sh

addgroup -S clamav 2>/dev/null
adduser -S -D -H -s /bin/false -G clamav -g clamav clamav 2>/dev/null

exit 0
</pre>
Note the ''exit 0'' at the end. If the script exits with failure (if the user already exist), the package will not be installed and <code>apk add</code> will exit with failure.

<dt>$pkgname.post-install
<dd>This script is executed after package is installed. Can be used to generate font cache and similar.

<dt>$pkgname.pre-upgrade
<dd>Same as pre-install but is executed before upgrading an already installed package.

<dt>$pkgname.post-upgrade
<dd>Same as post-install but is executed after upgrading an already installed package.

<dt>$pkgname.pre-deinstall
<dd>This script is executed before uninstalling a package. If script exits with failure apk will not uninstall the package.

<dt>$pkgname.post-deinstall
<dd>This script is executed after a package have been uninstalled. Can be used to update font caches and restore busybox links. For example:
<pre>
#!/bin/sh
busybox --install -s
</pre>

</dl>

If the package have an pre-install and post-install script the APKBUILD should have the ''install'' variable defined and the scripts should also be added to the source variable:
<pre>
...
install="$pkgname.pre-install $pkgname.post-install"
source="http://....
$install"
...
</pre>

==== subpackages ====

$subpackages are made to split up the normal "make install" into separate packages. The most common subpackages we use are doc and dev. Because we like to keep our target system small we move documentation and development files (only needed when building packages) into separate packages. To use the specific program a user only need to install the base apk without package-doc or package-dev, but if he wants to read the manual he will need to install package-doc.

The easiest way to find out if you need to use -dev and -doc is to first build the package without these options set and wait until the build finishes. When its finished you should have a pkg directory which is the fake root directory. Inside this directory you will see the structure as how it would be installed in / on the target system.

To see if you need the -dev package you can run the following cmd:

{{Cmd|find pkg/usr/ -name '*.[acho]' -o -name '*.la'}}

If this returns any files you need to include the -dev package.

 To see if you need the -doc package you can run the following cmd:

{{Cmd|find pkg/usr/share -name doc -o -name man -o -name info -o -name html -o -name sgml -o -name licenses}}

If this returns any directories you need to include the -doc package.

===== Custom subpackages =====

Some software additionally has non-essential files that do not qualify as either documentation or development content. These files should be placed in their own, specialized subpackage(s). Some packages include large test suites which are only needed in specific circumstances or binaries which have depends which we prefer not to install. To handle those we create our own package/function. In the APKBUILD below the build() function we create another function:

test() {
mkdir -p "$subpkgdir"/usr
mv "$pkgdir"/usr/package-test "$subpkgdir"/usr/
}

We also need to add the package info to $subpackages variable:

subpackages="$pkgname-doc $pkgname-dev $pkgname-test"

After we finish building the package you should see another apk called packagename-test.apk which includes the files which we moved to the $subpkgdir dir.

The above mentioned variables can also be used in our custom function. If we want for instance to build the test() function with perl support we would add:

depends="perl"
makedepends="perl-dev"

If we would install the base package it would not install perl, but if we install the package-test package it would.

==== Patches ====

Please make sure you always submit human readable patches. Way's to create them are:

directory compare:

{{Cmd|diff -urp original_directory new_directory > filename.patch}}

file compare:

{{Cmd|diff -up original.file new.file > filename.patch}}

If you are going to use multiple patches for a single package, the preferred way to handle those is a loop and numbering the patches.

for i in "$srcdir"/*.patch; do
msg "Applying ${i}"
patch -p0 -i $i || return 1
done

Because multiple patches can patch the same file, we could create offset for the next patch. To make sure we always patch in a specified way we should number the patches as followed:

10-patch1.patch 20-patch2.patch 30-patch3.patch

This way we are always sure patch 1 is first and if we want to add additional patches between them we can use 11,12,21,22...

==== Configure options ====

Alpine has some default configure options we set by default. We use /usr for prefix to make sure everything is installed with /usr in front of it. If you notice that anything is installed in the wrong directory please run {{Cmd|./configure --help}} and see if you can set the correct location.

We are not covering the depend switches here we have discussed this already in the depend section.

{{Tip|Common steps for building package contain ''./configure'', ''make'' and ''make install''. Everyone of them should be enclosed by ''|| return 1'' to check exit status. Otherwise even if previous step fails e.g. ''./configure'', next will be launched e.g. ''make''. This complicates identifying the point where the build breaks. The same applies to installing additional files.}}

==== Make options ====

If you notice weird problems when compiling or installing the package with make/make install you could try to disable [http://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be:

make || return 1

To disable parallel we use:

make -j1 || return 1

We can use the same for make install.

Because we do not want to install the package in our build environment but we want to install it in a fake root directory we need to tell 'make install' to use another destination directory instead of '/'. We do this by setting a variable when we execute make install as followed:

make DESTDIR="$pkgdir" install

Please note that some Makefiles do not support this variable and will always install software in '/'. To make sure you do not mess up your build system NEVER run your build system as root but always use a custom user and sudo when needed. If by accident the Makefile does not support DESTDIR variable it will fail to install in our build system system directories.

==== _builddir ====
If you used <tt>newapkbuild</tt> to create your APKBUILD file, you must specify the path to your unpacked sources. Inside the sections during the prepare/build/install process ''_builddir'' is used. Most of the time a combination of ''$srcdir'' and ''$pkgname-$pkgver'' will work. When not, check the /src directory or the source tarball for the right string. Especially when you are working with automatically generated tarballs (like from github and gitorious), this needs to be adjusted.

_builddir="$srcdir"/$pkgname-$pkgver

==== Additional files ====

If you want/need to install additional files not mentioned above you can use the following cmd (this is an example of a conf file):

install -Dm644 doc/$pkgname.conf "$pkgdir"/etc/$pkgname.conf

== Build the package ==

If you did not already create the checksums as mentioned above you can do so now:

{{Cmd|cd $pkgname
abuild checksum}}

It's about time we build our package. Because a build system should never have all the package installed to prevent linking to packages we don't want it to link we use a abuild recursively with the '''-r''' switch. It will install all dependency's from your repository and builds it, afterwards it will uninstall all those depending packages again. You could also use the '''-R''' switch which would build your package including the dependency packages.

{{Cmd|abuild -r}}

== Commit your work ==

After you successfully build your package you can submit your APKBUILD to alpine git repository.

Update your git repo, before adding new files:

{{Cmd|cd $aportsdir
git pull}}

This should pull all the changes made by others into you local git repo.

When you think you are ready you can add your files to git:

{{Cmd|cd $aportsdir
git add testing/$pkgdir (include any other files needed for the build; $pkgname.install...)
git commit}}

In the commit message, add the following (remove the comments in the last four lines):

{{Cmd| # Please enter the commit message for your changes
#[snip]
#
testing/$pkgname: new aport # this will be the subject line
# a blank line
$pkgurl # homepage of project
$pkgdesc # a one line description}}

Now your changes are only available locally in your repository.

Because you do not have push rights to the Alpine aports repository you need to create diff (patch) of the changes you made and send this patch to the
[http://lists.alpinelinux.org/alpine-aports/ alpine-aports mailinglist].

To create a diff patch

{{Cmd|git format-patch HEAD^}}

or if you have sprunge, you can create a link to your patch for convenience

{{Cmd|git format-patch HEAD^ --stdout <nowiki>|</nowiki> sprunge}}

== Send a patch ==

[[Creating_patches#Only_the_last_commit_with_.27git_send-email.27|git send-email]] will do that for you.

== See Also ==
* [[APKBUILD Reference]]
* [[APKBUILD examples]]
* [[Development using git]]

[[Category:Development]]

APKBUILD Reference

2016-06-06T00:16:52Z

Przemoc: /* $pkgname.pre-install */ Fix $pkgname.pre-install example

APKBUILDs are the scripts that are created in order to build Alpine packages using the [[abuild]] tool.

This page is intended to serve as a reference for creating APKBUILDs; if this is your first time creating a package for Alpine Linux, please see [[Creating an Alpine package]].

= Legend =
The following notes will assist you in understanding this document.

In description text:
* If a variable is not prefixed with a ''$'', it will be represented by italics (i.e., ''srcdir'' ).
* Functions will also be represented by italics, but will also end with a pair of parentheses (i.e., ''build()'' ).
* Shell commands will be represented <code>like this</code>.

= Variables =
{{Note|Variables that contain a path (e.g. ''$srcdir'' and ''$pkgdir'') should always be quoted using double quotes (i.e., ''"$srcdir"''). This is done to prevent things from breaking, should the user have the APKBUILD in a directory path that contains spaces.}}
{{Note|All arbitrary variable and function names should be prefixed with an underscore character ( _ ) to avoid name clashes with the internals of abuild (for example, ''_builddir'').}}

== abuild-defined variables ==
The following variables are defined by abuild:

==== startdir ====
: The directory where the APKBUILD script is.
==== srcdir ====
: The directory where sources, from the ''source'' variable, are downloaded to and unpacked to.
==== pkgdir ====
: This directory should receive the files for the main package. For example, a normal [http://en.wikipedia.org/wiki/GNU_build_system autotools] package would have <code>make DESTDIR="$pkgdir" install</code> in the ''package()'' function.
==== subpkgdir ====
: This directory should receive the files for a subpackage. This variable should only be used from subpackage functions.

{{Tip|''_builddir'' is not defined by abuild; instead this should be defined by hand when it's needed. You might define it as:

_builddir{{=}}"$srcdir/$pkgname-$pkgver"
}}

== User-defined variables ==
The following variables should be defined by the user:
==== arch ====
: Package architecture(s) to build for. Can be one of: '''x86, x86_64, all''', or '''noarch''', where '''all''' means all architectures, and '''noarch''' means it's architecture-independent (e.g., a pure-python package).
: {{Tip|To determine if your APKBUILD can use '''noarch''': First specify '''all''' and then build the package by executing <code>abuild -r</code>. Watch the output towards the end for warnings saying that '''noarch''' can be used. If the main package and all subpackages, if you have any subpackages, give a warning saying that '''noarch''' can be used, then you can use '''noarch'''.}}
==== depends ====
: Run-time dependency package(s) that are not shared-object dependencies. Shared objects dependencies are auto-detected and should not be specified here.
==== depends_dev ====
: Run-time dependency package(s) for the '''$pkgname-dev''' subpackage.

: {{Note|From ncopa on IRC: To find out if you need to add a package to depends_dev have a look at *requires* in usr/lib/pkgconfig/*.pc. With libtool it gets more complicated, but we should delete the .la files. Also check if there are any /usr/bin/*-configure #!/bin/bash #!/usr/bin/perl or Python. Sometimes scripts or similar are generated at build time (i.e autoconf automake) then you normally don't need add those to depends_dev. You can also just add all -dev makedepends to depends_dev but it will slow the build process a little bit (more build dependencies).}}

==== install ====
: There are 6 different types of install scripts. Install scripts are named '''$pkgname.action''', where '''action''' can be: '''pre-install, post-install, pre-upgrade, post-upgrade, pre-deinstall''', or '''post-deinstall'''. For example, if ''pkgname'' is set to '''mypackage''' and ''install'' is set to '''$pkgname.post-install''', then a script named '''mypackage.post-install''' must exist along-side the APKBUILD.

: First, a few notes regarding install scripts:
<blockquote>{{Note|When using install scripts, ''$install'' should be included in ''source'' so that checksums can be generated and used for the install scripts specified in ''install''. For example:
<pre>
install="$pkgname.pre-install $pkgname.post-install"
source="http://....
$install"
</pre>}}
{{Note|Always use <code>/bin/sh</code> for the command-line interpreter on the [http://en.wikipedia.org/wiki/Shebang_%28Unix%29 shebang line] of your install scripts.}}</blockquote>

The following are the different types of install scripts in detail:

===== $pkgname.pre-install =====
: This script is executed ''before installing'' the package. Typical use is when the package needs a group and a user to be created. For example:
<blockquote><pre>
#!/bin/sh

addgroup -S clamav 2>/dev/null
adduser -S -D -H -s /bin/false -G clamav -g clamav clamav 2>/dev/null

exit 0
</pre>
{{Note|If the script exits with a failure (e.g., if the user already exists), the package will not be installed and <code>apk</code> will exit with failure, hence the <code>exit 0</code> at the end.}}</blockquote>

===== $pkgname.post-install =====
: This script is executed ''after installing'' the package.

===== $pkgname.pre-upgrade =====
: This script is executed ''before upgrading'' the package.

===== $pkgname.post-upgrade =====
: This script is executed ''after upgrading'' the package.

===== $pkgname.pre-deinstall =====
: This script is executed ''before uninstalling'' the package.
: {{Note|If the script exits with failure, <code>apk</code> will not uninstall the package.}}

===== $pkgname.post-deinstall =====
: This script is executed ''after uninstalling'' the package.

==== license ====
: License(s) for the package.
==== makedepends ====
: Build-time dependency package(s).
==== md5sums ====
: Checksums for the files/URLs listed in ''source''. The checksums are normally generated and updated by executing <code>abuild checksum</code> and should be the last item in the APKBUILD.
==== options ====
: Build-time options for the package. Can be: '''!strip''' - to avoid stripping symbols from binaries.
==== pkgdesc ====
: A brief, one-line description of what the package does.

: Here's an example from the OpenSSH client package:
: <pre>pkgdesc="Port of OpenBSD's free SSH release - client"</pre>
==== pkggroups ====
: System group(s) to be created during build-time. System group(s) should also be created in the '''[[APKBUILD Reference#.24pkgname.pre-install|$pkgname.pre-install]]''' script, so that the system group(s) are also created prior to package installation for run-time use.
==== pkgname ====
: The name of the package. All letters should be lowercase.
: {{Note|When creating an APKBUILD of a module or library for another package, we use some common package prefixes, such as: ''lua-'', ''perl-'', ''php-'', and ''py-''. Search aports for other common prefixes.}}

==== pkgrel ====
: Alpine package release number. Starts at 0 (zero). Always increment ''pkgrel'' when making updates to an aport; reset ''pkgrel'' to 0 (zero) when incrementing ''pkgver''.
==== pkgusers ====
: System user(s) to be created during build-time. System user(s) should also be created in the '''[[APKBUILD Reference#.24pkgname.pre-install|$pkgname.pre-install]]''' script, so that the system user(s) are also created prior to package installation for run-time use.
==== pkgver ====
: The version of the software being packaged.
==== provides ====
: Add documentation.
==== replaces ====
: Package(s) that this package replaces. This package will "take over" files owned by packages listed in the ''replaces'' variable. This is useful when files move from one package to another, or when a package gets renamed.
==== replaces_priority ====
: The priority of the replaces. If multiple packages replace each other, then will the package with highest ''replaces_priority'' win.
==== source ====
: The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[APKBUILD Reference#install|install variable]]), patches, and all other necessary files.

: Here are few things to note:

:* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
:: {{Cmd|abuild checksum}}
:: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

:* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
:: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre>
:: (or similar depending on the package).

:* You can set target filename (eg 'save as...') by prefixing the URI with ''filename::''. This is useful when the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
:: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
:: or when the filename is braindead, like githubs' download tags:
:: <pre>https://github.com/software/software/archive/v$pkgver.tar.gz</pre>
:: The above two examples needs a target filename prefix:
:: <pre>$pkgname-$pkgver.tar.gz::http://oss.example.org/?get=software&ver=$pkgver</pre>
:: and:
:: <pre>$pkgname-$pkgver.tar.gz::https://github.com/software/software/archive/v$pkgver.tar.gz</pre>

:* abuild currently supports the following protocols for remote file retrieval:
:** http
:** https
:** ftp

:* abuild currently supports the following archive types/archive file extensions:
:** .tar.gz / .tgz
:** .tar.bz2
:** .tar.lzma
:** .tar.xz
:** .zip

:: {{Note|Legacy APKBUILD scripts define ''source'' variable as "saveas-[brain-dead-url]/[target-filename]" format instead of the modern [target-filename]::[brain-dead-url]. ''BAD'': source="saveas-http://releases.ddvtech.com/download.php?pack=libmist_dist&ver=RC/$pkgname-$pkgver.tar.gz" ''GOOD'': source=$pkgname-$pkgver.tar.gz::http://releases.ddvtech.com/download.php?pack=libmist_dist&ver=RC"}}

==== subpackages ====
: Subpackages built from this APKBUILD. abuild will parse this variable and try to find a subpackage split function. The split function must ''move'' files that do not belong in the main package, from ''$pkgdir'' to ''$subpkgdir''. Files and directories can also be ''copied'' from ''$startdir'' and ''$srcdir'' to ''$subpkgdir''.

: The split function can be specified in 1 of 3 different methods:
:# subpkgname:'''splitfunc'''
:# $pkgname-'''splitfunc'''
:# '''splitfunc'''

: {{Note|Split function names '''cannot''' use hyphens; use the first method above if the subpackage name contains a hyphen (-) character, like this: ''subpkg-name:subpkg_name'', where <code>subpkg-name</code> is the name of the '''subpackage''' and <code>subpkg_name</code> is the name of the '''subpackage's split function'''.}}

: {{Tip|For more information, see the [[APKBUILD_examples:Subpackages|Subpackages example]].}}

==== triggers ====
: Apk-tools can "monitor" directories and execute a trigger if any package installed/uninstalled any file in the monitored dir. The triggers are always execute after the apk action (install, uninstall, upgrade).

: The triggers are specified in the format: ''scriptname''=''pathlist'' where ''scriptname'' is the (sub)package name + .trigger suffix and pathlist is : separated list of the dirs to monitor.

: The '''triggers''' variable must include the triggers for subpackages too if they have any.

: It is possible to use wildcards (*) in the dir list.

==== url ====
: The homepage for the package. This is to help users find upstream documentation and other information regarding the package.

==== install_if ====
:install_if can be used when a package needs to be installed when some packages are already installed or are in the dependency tree. As example we could take open-vm-tools. Currently it contains the userspace tools and separate packages for the kernel modules (grsec and vserver). When we install the userspace tools, apk should automatically install the correct kernel modules and will need to figure out for which kernel. This is where install_if jumps in. For any of the kernel modules package we would use:

:<pre>install_if="linux-${_flavor}=${_kernelver} open-vm-tools"</pre>

:This will automatically install the package when the specified packages are installed or are in dependency tree.

= Functions =
{{Note|All functions should consider the current working directory as undefined, and should therefore use the [[APKBUILD Reference#abuild-defined_variables|abuild-defined directory variables]] to their advantage.}}

== abuild-defined functions ==
The following functions are provided by abuild and can be overridden:

==== fetch() ====
: Downloads remote sources listed in ''source'' to ''SRCDEST'' (''SRCDEST'' is configured in ''/etc/abuild.conf'') and creates symlinks in ''$srcdir''.
==== unpack() ====
: Unpacks .tgz, .tar.gz, .tar.bz2, .tar.lzma, .tar.xz, and .zip archives in ''$srcdir'' to ''$srcdir''.
==== dev() ====
: Subpackage function for the '''$pkgname-dev''' package. Without specifying a custom ''dev()'' function, abuild will call it's internal ''dev()'' function, which in turn calls ''default_dev()'', which will move ''"$pkgdir"/usr/include'', ''*.a'', ''*.la'' and similar files to ''$subpkgdir''.
==== doc() ====
: Subpackage function for the '''$pkgname-doc''' package. Without specifying a custom ''doc()'' function, abuild will call it's internal ''doc()'' function, which in turn calls ''default_doc()'', which will move ''"$pkgdir"/usr/share/doc'', ''"$pkgdir"/usr/share/man'' and similar to ''$subpkgdir''.

== User-defined functions ==
The following functions should be defined by the user:

==== prepare() ====
: '''''Optional''.''' Used for build preparation: patches, etc, should be applied here. This function is available for your convenience.
==== build() ====
: '''Required.''' This is the compilation stage. This function will be called as the current user (unless the ''package()'' function is missing - for compatibility reasons). If no compilation is needed, this function can contain a single line: <code>return 0</code>
==== package() ====
: '''Required.''' This is the packaging stage. Here, the built application and support files should be installed into '''$pkgdir'''. If this is a metapackage, this function can contain a single line: <code>mkdir -p "$pkgdir" && return 0</code>

{{Note|Building in fakeroot will reduce performance for parallel builds dramatically. It is for this reason that we split the build and package process into two separate functions.}}

= Examples =
The [[APKBUILD examples]] page will assist you in understanding how to create an APKBUILD.

[[Category:Development]]

User:Przemoc/Notes

2016-05-08T22:57:57Z

Przemoc: AL 3.3.3: Console/Serial

Creating an Alpine package

2016-04-28T19:09:56Z

Przemoc: /* install */ Improve $pkgname.pre-install example to follow currently used style and arguments order. (aports commits ccc056dbf9d3, a593d306c92f, a60b9f07dee0, da4e96aacef5)

== Requirements ==

To build a package for Alpine Linux you need an Alpine Linux installation. Check the [[Installation]] page to see all available installation options.

== Setup your system and account ==
{{:Include:Setup_your_system_and_account_for_building_packages}}

== Getting some help ==

It might be wise to start by checking what the [[Abuild|abuild]] program can/cannot do.

{{Cmd|abuild -h}}

== Creating an APKBUILD file ==

=== Use a template APKBUILD ===

To create the actual APKBUILD file {{Pkg|newapkbuild}} can serve you a template to start with. It will create a directory with the given package name, place an example/template APKBUILD file to the given directory, and fill some variables if those are provided. Please check the [[Package_policies| package policies]] page about naming details.

If you doubt to which repository your package belongs to you can safely use '''testing'''. Building package in your aports/testing directory is not mandatory but this way the package is already at the right place.

{{:Include:Newapkbuild}}

{{Note|On older Alpine systems, abuild -c -n ''packagename'' was the way to create APKBUILD files. The 'packagename' was a parameter to the -n option so order of -c and -n matters. }}

[[Abuild_and_Helpers#apkbuild-cpan|apkbuild-cpan]] simplifies the creation of perl packages from CPAN and [[Abuild_and_Helpers#apkbuild-pypi|apkbuild-pypi]] ease the generation of APKBUILD files for python packages from PyPi.

If you are create a daemon package which needs initd scripts you can add the -c making it:

{{Cmd|newapkbuild -c ''packagename''}}

This will copy the sample initd and confd files to the build directory. 
A third file sample.install file will be copied as well (we will discuss this later on).

=== Modify your APKBUILD ===
Edit APKBUILD and fill in the needed info (especially pkgname, pkgver, pkgdesc, url, license, depends and source).

If you are going to use any of the variables for directories like $pkgdir, always make sure they are double quoted like:

"$pkgdir"/somedir

This will prevent issues with spaces/special characters in the future.

{{Note|If you like syntax highlighting we suggest you to install vim. We have setup vim to recognize the APKBUILD file as a bash scripts so its easier to read them.}}

=== APKBUILD variables/functions ===

==== source ====

The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[Creating an Alpine package#install|install variable]]), patches, and all other necessary files.

Here are few things to note:

* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
: {{cmd|abuild checksum}}
: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre>
: (or similar depending on the package).

* When the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
: You must prepend '${pkgname}-${pkgver}.tar.gz::' to the protocol, like so:
: <pre>source="${pkgname}-${pkgver}.tar.gz::http://oss.example.org/?get=software&ver=1.0"</pre>
: This causes the file to be saved as ''software-1.0.tar.gz'' where abuild can use it, instead of ''?get=software&ver=1.0'', where abuild cannot use it.

* Some projects didn't provide a release tarball. If you point source to an tarball provided by a git web interface (gitweg, cgit, github), such as:
: <pre>http://repo.or.cz/w/gitstats.git/snapshot/ad7efbb9399e60cee6cb217c6b47e604174a8093.tar.gz</pre>
: You will run into issues because the checksum changes when downloading on the build system.

* abuild currently supports the following protocols for remote file retrieval:
** http
** https
** ftp



* abuild currently supports the following archive types/archive file extensions:
** .tar.gz / .tgz
** .tar.bz2
** .tar.lzma
** .tar.xz
** .zip

==== depends & makedepends ====

Depends are the actual running dependencies that a package would need when it is running. Makedepends are only needed when you are building a package. If you set a package, in depends you do not need to add it to makedepends as well. The best way to find out what the depends and makedepends of a package are is to [http://en.wikipedia.org/wiki/Rtfm RTFM].

No kidding, lots of important information can be found it the package INSTALL and README file (or the likes). Another good way is the run <code>./configure --help</code> from the source directory to see which options are needed for configure to finish without errors. If you do not yet have a source directory you can create one with the command:

{{Cmd|abuild unpack}}

Running <code>configure</code> will also show you how you can disable a specific option for this package. A good example is for instance "--disable-nls" which will disable native language support and thus does not depend on gettext (libiconv, glib, ...).

Alpine likes to keep things small, so we try to disable as much as possible without losing too many features. The exact disable/enable options are decided the package builder but please try to follow Alpine's design concept as much as possible.

An easy way of quickly finding out the build info for a package is to check Arch Linux (Alpine package management and build scripts are similar) or Gentoo Linux ebuilds (previous versions of Alpine were based on Gentoo).

* [http://www.gentoo-portage.com Search ebuilds]
* [http://sources.gentoo.org/viewcvs.py/gentoo-x86/ Gentoo CVS]
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]

After the package is successfully compiled and created we should make sure it didn't link to any package that is not present in the <code>$depends</code> variable. We do this by using <code>scanelf</code>. If scanelf is not yet installed on your system you can do that by installing {{Pkg|pax-utils}}.

{{Cmd|scanelf -nR pkg}}

An example output of {{Pkg|libcurl}} would be:

ET_DYN libssl.so.0.9.8,libcrypto.so.0.9.8,libz.so.1,libc.so.0,ld-uClibc.so.0 pkg/usr/lib/libcurl.so.4.1.1

You can see the needed files and should be able to find out which file belongs to which package.

==== license ====

The '''license''' tag must reflect the license of the source code. Please check the source tarball for COPYING, LICENSE, or other files with names that indicates that it contains licensing information. Beside the license file most developer include headers in the source code files with licensing details. Please use the short name and the release number in the license tag, e.g

{| cellpadding="5" border="1" class="wikitable"
|-
! Short name
! Full name
|-
| GPL2
| GNU General Public License Version 2.0
|-
| LGPL2+
| GNU Lesser General Public License Version 2.1
|-
| ASL 2.0
| Apache License Version 2.0
|-
| BSD
| BSD License
|-
| MIT
| MIT license
|-
| MPL 2.0
| Mozilla Public License v2.0
|-
| ZPL 2.0
| Zope Public License v 2.0
|-
| PHP
| PHP License v3.0
|-
| zlib
| zlib/libpng License
|-
|}

For the GNU General Public License the '+' means ''or (at your option) any later version.'' which covers future releases of that license. We skip the ''v'' because it's obvious that the number shows the version. If you are unsure about the short name of a license, please check the resources below for additional information.

* [https://wiki.archlinux.org/index.php/Licenses ArchLinux and Licensing]
* [https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses Fedora and Licensing]

If a package has a special/custom license we need to provide it with the release. Because we want to save space and don't like to have licenses all over our system we have decided to include the license in the doc subpackage. Please follow the following guidelines to add a proper license. Locate the license file inside the source package. Add the doc subpackage to the $subpackages variable as follows:

subpackages="$pkgname-doc"

Add a similar line to the following to your package() function, depending on the license description file:

install -Dm644 COPYING "$pkgdir"/usr/share/licenses/$pkgname/COPYING

If you follow these steps then abuild will automatically add the license to the package-doc apk for you.

==== arch ====

The package architecture(s) to build for. This can be one of: ''x86, x86_64, all,'' or ''noarch'', where ''all'' means all architectures, and ''noarch'' means it's architecture-independent (ie, a pure-python package).
{{Tip|To determine if your APKBUILD can use ''noarch'', build the package for your architecture and then run "scanelf -R pkg" from the directory that the APKBUILD resides in, in order to scan for ELF files in the ''./pkg'' directory. If you do NOT get output from this, then ''noarch'' can be used.}}

==== url ====

Website address for the program. This is usefully later on when either finding documentation or other information about the package.

==== pkgdesc ====

A brief, one line, description of what the package does. Useful for the package management system.

Here is an example from apk_info for the OpenSSH client package

pkgdesc="Port of OpenBSD's free SSH release - client"

==== pkgver ====

Provide the release number of the package you are building.

==== pkgrel ====

The $pkgrel versioning is made so if you change something to your APKBUILD file without changing the actual $pkgver you can higer pkgrel so apk tools will detect it as an update. For instance if you forget to add a dependency you can add it afterward and you can +1 pkgver so apk finds this update and add the missing dependency. When there's an upstream version changes, we reset the pkgrel to 0.

==== pkgname ====

The base name of the package you are creating. For Freeswitch 1.0.6, you would use "freeswitch"

==== install ====

There are 6 different kinds of install scripts. Each script is called with the $pkgname.''<action>'' where ''<action>'' is one of the following:

<dl>
<dt>$pkgname.pre-install
<dd>This script is executed before package is installed. Typical use is when package needs a user/group to be created. For example:
<pre>
#!/bin/sh

adduser -S -D -H -s /bin/false -g clamav clamav 2>/dev/null

exit 0
</pre>
Note the ''exit 0'' at the end. If the script exits with failure (if the user already exist), the package will not be installed and <code>apk add</code> will exit with failure.

<dt>$pkgname.post-install
<dd>This script is executed after package is installed. Can be used to generate font cache and similar.

<dt>$pkgname.pre-upgrade
<dd>Same as pre-install but is executed before upgrading an already installed package.

<dt>$pkgname.post-upgrade
<dd>Same as post-install but is executed after upgrading an already installed package.

<dt>$pkgname.pre-deinstall
<dd>This script is executed before uninstalling a package. If script exits with failure apk will not uninstall the package.

<dt>$pkgname.post-deinstall
<dd>This script is executed after a package have been uninstalled. Can be used to update font caches and restore busybox links. For example:
<pre>
#!/bin/sh
busybox --install -s
</pre>

</dl>

If the package have an pre-install and post-install script the APKBUILD should have the ''install'' variable defined and the scripts should also be added to the source variable:
<pre>
...
install="$pkgname.pre-install $pkgname.post-install"
source="http://....
$install"
...
</pre>

==== subpackages ====

$subpackages are made to split up the normal "make install" into separate packages. The most common subpackages we use are doc and dev. Because we like to keep our target system small we move documentation and development files (only needed when building packages) into separate packages. To use the specific program a user only need to install the base apk without package-doc or package-dev, but if he wants to read the manual he will need to install package-doc.

The easiest way to find out if you need to use -dev and -doc is to first build the package without these options set and wait until the build finishes. When its finished you should have a pkg directory which is the fake root directory. Inside this directory you will see the structure as how it would be installed in / on the target system.

To see if you need the -dev package you can run the following cmd:

{{Cmd|find pkg/usr/ -name '*.[acho]' -o -name '*.la'}}

If this returns any files you need to include the -dev package.

 To see if you need the -doc package you can run the following cmd:

{{Cmd|find pkg/usr/share -name doc -o -name man -o -name info -o -name html -o -name sgml -o -name licenses}}

If this returns any directories you need to include the -doc package.

===== Custom subpackages =====

Some software additionally has non-essential files that do not qualify as either documentation or development content. These files should be placed in their own, specialized subpackage(s). Some packages include large test suites which are only needed in specific circumstances or binaries which have depends which we prefer not to install. To handle those we create our own package/function. In the APKBUILD below the build() function we create another function:

test() {
mkdir -p "$subpkgdir"/usr
mv "$pkgdir"/usr/package-test "$subpkgdir"/usr/
}

We also need to add the package info to $subpackages variable:

subpackages="$pkgname-doc $pkgname-dev $pkgname-test"

After we finish building the package you should see another apk called packagename-test.apk which includes the files which we moved to the $subpkgdir dir.

The above mentioned variables can also be used in our custom function. If we want for instance to build the test() function with perl support we would add:

depends="perl"
makedepends="perl-dev"

If we would install the base package it would not install perl, but if we install the package-test package it would.

==== Patches ====

Please make sure you always submit human readable patches. Way's to create them are:

directory compare:

{{Cmd|diff -urp original_directory new_directory > filename.patch}}

file compare:

{{Cmd|diff -up original.file new.file > filename.patch}}

If you are going to use multiple patches for a single package, the preferred way to handle those is a loop and numbering the patches.

for i in "$srcdir"/*.patch; do
msg "Applying ${i}"
patch -p0 -i $i || return 1
done

Because multiple patches can patch the same file, we could create offset for the next patch. To make sure we always patch in a specified way we should number the patches as followed:

10-patch1.patch 20-patch2.patch 30-patch3.patch

This way we are always sure patch 1 is first and if we want to add additional patches between them we can use 11,12,21,22...

==== Configure options ====

Alpine has some default configure options we set by default. We use /usr for prefix to make sure everything is installed with /usr in front of it. If you notice that anything is installed in the wrong directory please run {{Cmd|./configure --help}} and see if you can set the correct location.

We are not covering the depend switches here we have discussed this already in the depend section.

{{Tip|Common steps for building package contain ''./configure'', ''make'' and ''make install''. Everyone of them should be enclosed by ''|| return 1'' to check exit status. Otherwise even if previous step fails e.g. ''./configure'', next will be launched e.g. ''make''. This complicates identifying the point where the build breaks. The same applies to installing additional files.}}

==== Make options ====

If you notice weird problems when compiling or installing the package with make/make install you could try to disable [http://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be:

make || return 1

To disable parallel we use:

make -j1 || return 1

We can use the same for make install.

Because we do not want to install the package in our build environment but we want to install it in a fake root directory we need to tell 'make install' to use another destination directory instead of '/'. We do this by setting a variable when we execute make install as followed:

make DESTDIR="$pkgdir" install

Please note that some Makefiles do not support this variable and will always install software in '/'. To make sure you do not mess up your build system NEVER run your build system as root but always use a custom user and sudo when needed. If by accident the Makefile does not support DESTDIR variable it will fail to install in our build system system directories.

==== _builddir ====
If you used <tt>newapkbuild</tt> to create your APKBUILD file, you must specify the path to your unpacked sources. Inside the sections during the prepare/build/install process ''_builddir'' is used. Most of the time a combination of ''$srcdir'' and ''$pkgname-$pkgver'' will work. When not, check the /src directory or the source tarball for the right string. Especially when you are working with automatically generated tarballs (like from github and gitorious), this needs to be adjusted.

_builddir="$srcdir"/$pkgname-$pkgver

==== Additional files ====

If you want/need to install additional files not mentioned above you can use the following cmd (this is an example of a conf file):

install -Dm644 doc/$pkgname.conf "$pkgdir"/etc/$pkgname.conf

== Build the package ==

If you did not already create the checksums as mentioned above you can do so now:

{{Cmd|cd $pkgname
abuild checksum}}

It's about time we build our package. Because a build system should never have all the package installed to prevent linking to packages we don't want it to link we use a abuild recursively with the '''-r''' switch. It will install all dependency's from your repository and builds it, afterwards it will uninstall all those depending packages again. You could also use the '''-R''' switch which would build your package including the dependency packages.

{{Cmd|abuild -r}}

== Commit your work ==

After you successfully build your package you can submit your APKBUILD to alpine git repository.

Update your git repo, before adding new files:

{{Cmd|cd $aportsdir
git pull}}

This should pull all the changes made by others into you local git repo.

When you think you are ready you can add your files to git:

{{Cmd|cd $aportsdir
git add testing/$pkgdir (include any other files needed for the build; $pkgname.install...)
git commit}}

In the commit message, add the following (remove the comments in the last four lines):

{{Cmd| # Please enter the commit message for your changes
#[snip]
#
testing/$pkgname: new aport # this will be the subject line
# a blank line
$pkgurl # homepage of project
$pkgdesc # a one line description}}

Now your changes are only available locally in your repository.

Because you do not have push rights to the Alpine aports repository you need to create diff (patch) of the changes you made and send this patch to the
[http://lists.alpinelinux.org/alpine-devel/ alpine-devel mailinglist].

To create a diff patch

{{Cmd|git format-patch HEAD^}}

or if you have sprunge, you can create a link to your patch for convenience

{{Cmd|git format-patch HEAD^ --stdout <nowiki>|</nowiki> sprunge}}

== Send a patch ==

[[Creating_patches#Only_the_last_commit_with_.27git_send-email.27|git send-email]] will do that for you.

== See Also ==
* [[APKBUILD Reference]]
* [[APKBUILD examples]]
* [[Development using git]]

[[Category:Development]]

APKBUILD Reference

2016-04-28T19:09:16Z

Przemoc: /* $pkgname.pre-install */ Improve $pkgname.pre-install example to follow currently used style and arguments order. (aports commits ccc056dbf9d3, a593d306c92f, a60b9f07dee0, da4e96aacef5)

APKBUILDs are the scripts that are created in order to build Alpine packages using the [[abuild]] tool.

This page is intended to serve as a reference for creating APKBUILDs; if this is your first time creating a package for Alpine Linux, please see [[Creating an Alpine package]].

= Legend =
The following notes will assist you in understanding this document.

In description text:
* If a variable is not prefixed with a ''$'', it will be represented by italics (i.e., ''srcdir'' ).
* Functions will also be represented by italics, but will also end with a pair of parentheses (i.e., ''build()'' ).
* Shell commands will be represented <code>like this</code>.

= Variables =
{{Note|Variables that contain a path (e.g. ''$srcdir'' and ''$pkgdir'') should always be quoted using double quotes (i.e., ''"$srcdir"''). This is done to prevent things from breaking, should the user have the APKBUILD in a directory path that contains spaces.}}
{{Note|All arbitrary variable and function names should be prefixed with an underscore character ( _ ) to avoid name clashes with the internals of abuild (for example, ''_builddir'').}}

== abuild-defined variables ==
The following variables are defined by abuild:

==== startdir ====
: The directory where the APKBUILD script is.
==== srcdir ====
: The directory where sources, from the ''source'' variable, are downloaded to and unpacked to.
==== pkgdir ====
: This directory should receive the files for the main package. For example, a normal [http://en.wikipedia.org/wiki/GNU_build_system autotools] package would have <code>make DESTDIR="$pkgdir" install</code> in the ''package()'' function.
==== subpkgdir ====
: This directory should receive the files for a subpackage. This variable should only be used from subpackage functions.

{{Tip|''_builddir'' is not defined by abuild; instead this should be defined by hand when it's needed. You might define it as:

_builddir{{=}}"$srcdir/$pkgname-$pkgver"
}}

== User-defined variables ==
The following variables should be defined by the user:
==== arch ====
: Package architecture(s) to build for. Can be one of: '''x86, x86_64, all''', or '''noarch''', where '''all''' means all architectures, and '''noarch''' means it's architecture-independent (e.g., a pure-python package).
: {{Tip|To determine if your APKBUILD can use '''noarch''': First specify '''all''' and then build the package by executing <code>abuild -r</code>. Watch the output towards the end for warnings saying that '''noarch''' can be used. If the main package and all subpackages, if you have any subpackages, give a warning saying that '''noarch''' can be used, then you can use '''noarch'''.}}
==== depends ====
: Run-time dependency package(s) that are not shared-object dependencies. Shared objects dependencies are auto-detected and should not be specified here.
==== depends_dev ====
: Run-time dependency package(s) for the '''$pkgname-dev''' subpackage.

: {{Note|From ncopa on IRC: To find out if you need to add a package to depends_dev have a look at *requires* in usr/lib/pkgconfig/*.pc. With libtool it gets more complicated, but we should delete the .la files. Also check if there are any /usr/bin/*-configure #!/bin/bash #!/usr/bin/perl or Python. Sometimes scripts or similar are generated at build time (i.e autoconf automake) then you normally don't need add those to depends_dev. You can also just add all -dev makedepends to depends_dev but it will slow the build process a little bit (more build dependencies).}}

==== install ====
: There are 6 different types of install scripts. Install scripts are named '''$pkgname.action''', where '''action''' can be: '''pre-install, post-install, pre-upgrade, post-upgrade, pre-deinstall''', or '''post-deinstall'''. For example, if ''pkgname'' is set to '''mypackage''' and ''install'' is set to '''$pkgname.post-install''', then a script named '''mypackage.post-install''' must exist along-side the APKBUILD.

: First, a few notes regarding install scripts:
<blockquote>{{Note|When using install scripts, ''$install'' should be included in ''source'' so that checksums can be generated and used for the install scripts specified in ''install''. For example:
<pre>
install="$pkgname.pre-install $pkgname.post-install"
source="http://....
$install"
</pre>}}
{{Note|Always use <code>/bin/sh</code> for the command-line interpreter on the [http://en.wikipedia.org/wiki/Shebang_%28Unix%29 shebang line] of your install scripts.}}</blockquote>

The following are the different types of install scripts in detail:

===== $pkgname.pre-install =====
: This script is executed ''before installing'' the package. Typical use is when the package needs a user/group to be created. For example:
<blockquote><pre>
#!/bin/sh

adduser -S -D -H -s /bin/false -g clamav clamav 2>/dev/null

exit 0
</pre>
{{Note|If the script exits with a failure (e.g., if the user already exists), the package will not be installed and <code>apk</code> will exit with failure, hence the <code>exit 0</code> at the end.}}</blockquote>

===== $pkgname.post-install =====
: This script is executed ''after installing'' the package.

===== $pkgname.pre-upgrade =====
: This script is executed ''before upgrading'' the package.

===== $pkgname.post-upgrade =====
: This script is executed ''after upgrading'' the package.

===== $pkgname.pre-deinstall =====
: This script is executed ''before uninstalling'' the package.
: {{Note|If the script exits with failure, <code>apk</code> will not uninstall the package.}}

===== $pkgname.post-deinstall =====
: This script is executed ''after uninstalling'' the package.

==== license ====
: License(s) for the package.
==== makedepends ====
: Build-time dependency package(s).
==== md5sums ====
: Checksums for the files/URLs listed in ''source''. The checksums are normally generated and updated by executing <code>abuild checksum</code> and should be the last item in the APKBUILD.
==== options ====
: Build-time options for the package. Can be: '''!strip''' - to avoid stripping symbols from binaries.
==== pkgdesc ====
: A brief, one-line description of what the package does.

: Here's an example from the OpenSSH client package:
: <pre>pkgdesc="Port of OpenBSD's free SSH release - client"</pre>
==== pkggroups ====
: System group(s) to be created during build-time. System group(s) should also be created in the '''[[APKBUILD Reference#.24pkgname.pre-install|$pkgname.pre-install]]''' script, so that the system group(s) are also created prior to package installation for run-time use.
==== pkgname ====
: The name of the package. All letters should be lowercase.
: {{Note|When creating an APKBUILD of a module or library for another package, we use some common package prefixes, such as: ''lua-'', ''perl-'', ''php-'', and ''py-''. Search aports for other common prefixes.}}

==== pkgrel ====
: Alpine package release number. Starts at 0 (zero). Always increment ''pkgrel'' when making updates to an aport; reset ''pkgrel'' to 0 (zero) when incrementing ''pkgver''.
==== pkgusers ====
: System user(s) to be created during build-time. System user(s) should also be created in the '''[[APKBUILD Reference#.24pkgname.pre-install|$pkgname.pre-install]]''' script, so that the system user(s) are also created prior to package installation for run-time use.
==== pkgver ====
: The version of the software being packaged.
==== provides ====
: Add documentation.
==== replaces ====
: Package(s) that this package replaces. This package will "take over" files owned by packages listed in the ''replaces'' variable. This is useful when files move from one package to another, or when a package gets renamed.
==== replaces_priority ====
: The priority of the replaces. If multiple packages replace each other, then will the package with highest ''replaces_priority'' win.
==== source ====
: The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[APKBUILD Reference#install|install variable]]), patches, and all other necessary files.

: Here are few things to note:

:* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
:: {{Cmd|abuild checksum}}
:: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

:* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
:: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre>
:: (or similar depending on the package).

:* You can set target filename (eg 'save as...') by prefixing the URI with ''filename::''. This is useful when the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
:: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
:: or when the filename is braindead, like githubs' download tags:
:: <pre>https://github.com/software/software/archive/v$pkgver.tar.gz</pre>
:: The above two examples needs a target filename prefix:
:: <pre>$pkgname-$pkgver.tar.gz::http://oss.example.org/?get=software&ver=$pkgver</pre>
:: and:
:: <pre>$pkgname-$pkgver.tar.gz::https://github.com/software/software/archive/v$pkgver.tar.gz</pre>

:* abuild currently supports the following protocols for remote file retrieval:
:** http
:** https
:** ftp

:* abuild currently supports the following archive types/archive file extensions:
:** .tar.gz / .tgz
:** .tar.bz2
:** .tar.lzma
:** .tar.xz
:** .zip

:: {{Note|Legacy APKBUILD scripts define ''source'' variable as "saveas-[brain-dead-url]/[target-filename]" format instead of the modern [target-filename]::[brain-dead-url]. ''BAD'': source="saveas-http://releases.ddvtech.com/download.php?pack=libmist_dist&ver=RC/$pkgname-$pkgver.tar.gz" ''GOOD'': source=$pkgname-$pkgver.tar.gz::http://releases.ddvtech.com/download.php?pack=libmist_dist&ver=RC"}}

==== subpackages ====
: Subpackages built from this APKBUILD. abuild will parse this variable and try to find a subpackage split function. The split function must ''move'' files that do not belong in the main package, from ''$pkgdir'' to ''$subpkgdir''. Files and directories can also be ''copied'' from ''$startdir'' and ''$srcdir'' to ''$subpkgdir''.

: The split function can be specified in 1 of 3 different methods:
:# subpkgname:'''splitfunc'''
:# $pkgname-'''splitfunc'''
:# '''splitfunc'''

: {{Note|Split function names '''cannot''' use hyphens; use the first method above if the subpackage name contains a hyphen (-) character, like this: ''subpkg-name:subpkg_name'', where <code>subpkg-name</code> is the name of the '''subpackage''' and <code>subpkg_name</code> is the name of the '''subpackage's split function'''.}}

: {{Tip|For more information, see the [[APKBUILD_examples:Subpackages|Subpackages example]].}}

==== triggers ====
: Apk-tools can "monitor" directories and execute a trigger if any package installed/uninstalled any file in the monitored dir. The triggers are always execute after the apk action (install, uninstall, upgrade).

: The triggers are specified in the format: ''scriptname''=''pathlist'' where ''scriptname'' is the (sub)package name + .trigger suffix and pathlist is : separated list of the dirs to monitor.

: The '''triggers''' variable must include the triggers for subpackages too if they have any.

: It is possible to use wildcards (*) in the dir list.

==== url ====
: The homepage for the package. This is to help users find upstream documentation and other information regarding the package.

==== install_if ====
:install_if can be used when a package needs to be installed when some packages are already installed or are in the dependency tree. As example we could take open-vm-tools. Currently it contains the userspace tools and separate packages for the kernel modules (grsec and vserver). When we install the userspace tools, apk should automatically install the correct kernel modules and will need to figure out for which kernel. This is where install_if jumps in. For any of the kernel modules package we would use:

:<pre>install_if="linux-${_flavor}=${_kernelver} open-vm-tools"</pre>

:This will automatically install the package when the specified packages are installed or are in dependency tree.

= Functions =
{{Note|All functions should consider the current working directory as undefined, and should therefore use the [[APKBUILD Reference#abuild-defined_variables|abuild-defined directory variables]] to their advantage.}}

== abuild-defined functions ==
The following functions are provided by abuild and can be overridden:

==== fetch() ====
: Downloads remote sources listed in ''source'' to ''SRCDEST'' (''SRCDEST'' is configured in ''/etc/abuild.conf'') and creates symlinks in ''$srcdir''.
==== unpack() ====
: Unpacks .tgz, .tar.gz, .tar.bz2, .tar.lzma, .tar.xz, and .zip archives in ''$srcdir'' to ''$srcdir''.
==== dev() ====
: Subpackage function for the '''$pkgname-dev''' package. Without specifying a custom ''dev()'' function, abuild will call it's internal ''dev()'' function, which in turn calls ''default_dev()'', which will move ''"$pkgdir"/usr/include'', ''*.a'', ''*.la'' and similar files to ''$subpkgdir''.
==== doc() ====
: Subpackage function for the '''$pkgname-doc''' package. Without specifying a custom ''doc()'' function, abuild will call it's internal ''doc()'' function, which in turn calls ''default_doc()'', which will move ''"$pkgdir"/usr/share/doc'', ''"$pkgdir"/usr/share/man'' and similar to ''$subpkgdir''.

== User-defined functions ==
The following functions should be defined by the user:

==== prepare() ====
: '''''Optional''.''' Used for build preparation: patches, etc, should be applied here. This function is available for your convenience.
==== build() ====
: '''Required.''' This is the compilation stage. This function will be called as the current user (unless the ''package()'' function is missing - for compatibility reasons). If no compilation is needed, this function can contain a single line: <code>return 0</code>
==== package() ====
: '''Required.''' This is the packaging stage. Here, the built application and support files should be installed into '''$pkgdir'''. If this is a metapackage, this function can contain a single line: <code>mkdir -p "$pkgdir" && return 0</code>

{{Note|Building in fakeroot will reduce performance for parallel builds dramatically. It is for this reason that we split the build and package process into two separate functions.}}

= Examples =
The [[APKBUILD examples]] page will assist you in understanding how to create an APKBUILD.

[[Category:Development]]

User:Przemoc/Notes

2016-04-25T19:17:42Z

Przemoc: AL 3.3.3: Shell/Color prompt - update

I finally installed AL and I'm poking it a bit. Here you can find some notes regarding this experience. They should be helpful, but please use them with caution. I may add some additional commentary sometimes. If you think there is a better way to perform some of mentioned here tasks, then don't hesitate to notify me about it. Top-level headings denotes AL version that was used. Backward and forward compatibility is possible, but not tested.

__TOC__

== Alpine Linux 3.3.3 ==

=== Shell ===

Even though I always try to write POSIX sh-compliant scripts, I like to have <code>bash</code> as my default shell, because it's quite handy. Being able to write for instance quick <code>diff -u <(COMMAND1) <(COMMAND2)</code> (to compare output of two commands) or <code>mv FILE{,SUFFIX}</code> (to rename file by adding suffix) is very convenient.

==== Bash as default shell ====

AL doesn't have <code>vipw</code>, so root has to perform <code>vi /etc/passwd</code> himself to change the last field of root record (should be the first line in the file). You have to install ''util-linux'' package to get <code>chsh</code> utility.

==== Activate color prompt ====

Initial prompt: <code style="background-color:black;color:gray;">baytrail:~# </code>

{{cmd|mv /etc/profile.d/color_prompt{,.sh}
}}

Prompt after above change and relogin: <code style="background-color:black;color:gray;">baytrail [~]# </code>

In case of normal users it's: <code style="background-color:black;color:gray;">baytrail [~]$ </code>

==== Long history ====

I like to have long history, so I created following file:

{{Cat|/etc/profile.d/long_history.sh|export HISTSIZE{{=}}9999999
export HISTFILESIZE{{=}}$HISTSIZE
}}

=== Console ===

If you have physical access to screen connected to your machine with AL, it's nice to have properly configured console.

==== UTF-8 encoding ====

To have UTF-8 from OpenRC point of view, you have to set in <code>/etc/rc.conf</code>:
<pre>unicode="YES"</pre>
and add <code>/etc/init.d/termencoding</code> to autostart:
{{cmd|rc-update add termencoding}}
In fact it's mostly irrelevant (prove me wrong).

==== Font with polish letters ====

To be able to see polish letters, you have to install ''kbd-misc'' package, set in <code>/etc/conf.d/consolefont</code>:
<pre>consolefont="lat2-sun16.psfu.gz"
consoletranslation="8859-2_to_uni.trans"</pre>
and add <code>/etc/init.d/consolefont</code> to autostart:
{{cmd|rc-update add consolefont}}

If you don't like default <code>default8x16.psf.gz</code> font, then use <code>lat2-16.psfu.gz</code> instead. If you're comfortable with lower letter height, then I suggest using <code>lat2-14.psfu.gz</code>, which is still readable, yet on my 1920x1200 display increases LINES number from 75 to 85.

==== Keymap with only right Alt used for inputting polish letters ====

Default polish keymap <code>pl</code> uses both Alt keys for polish letters. If you prefer left Alt to be usable for other stuff (like switching to active window in irssi via Alt+A), then you have to switch to <code>pl1</code> variant. ''bkeymaps'' package is needed for setting, but can be removed later.
{{cmd|setup-keymap pl pl1}}

==== UTF-8 in tmux ====

tmux checks upon start-up whether environment variable <code>LC_ALL</code>, or if it's empty then <code>LC_CTYPE</code>, or if it's empty then <code>LANG</code>, contain string <code>UTF-8</code> or <code>UTF8</code> to activate its UTF-8 mode. It can be also triggered by <code>-u</code> option. Important part is that globally turning on <code>utf8</code> window option in tmux configuration doesn't enforce UTF-8 mode.

musl has locale system since v1.1.4, it was incomplete and experimental, but I'm not sure how it is now. The thing is it's not leveraged by AL and by default you have no <code>LC_*</code> variables set. In musl built-in default is <code>C.UTF-8</code>, so we can simply create one file to set <code>LC_CTYPE</code> to such default value and it will satisfy tmux check:

{{Cat|/etc/profile.d/locale.sh|export LC_CTYPE{{=}}C.UTF-8
}}

Possible alternative is to alias <code>tmux</code> to <code>tmux -u</code>, but it seems clunky.

=== Disk ===

==== Set up RAID1 on two devices ====

<pre>
# install package
apk add mdadm

# load "raid1" module during boot (not really needed if you perform further steps)
echo raid1 >>/etc/modules

# create RAID1 array on two whole disks with 1MB data offset
mdadm --create --level=1 --raid-devices=2 --data-offset=1M /dev/md0 /dev/sda /dev/sdb

# preserve original example mdadm.conf
mv /etc/mdadm.conf{,.orig}

# save current setup into configuration file
# (usually people do not use -v, but it's more readable)
mdadm --detail -v --scan >/etc/mdadm.conf

# add raid devices starting to autostart
rc-update add mdadm-raid

# add raid devices monitoring to autostart
rc-update add mdadm

# start raid devices monitoring now
/etc/init.d/mdadm start

# following steps are needed if you want to support RAID early during boot

# add "raid" to features (space-separated values)
vi /etc/mkinitfs/mkinitfs.conf

# rebuild /boot/initramfs-grsec
mkinitfs

# add "raid1" to modules (comma-separated values)
vi /etc/update-extlinux.conf

# update extlinux
update-extlinux
</pre>

==== Install smartctl and smartd ====

<pre>
# install package
apk add smartmontools

# comment DEVICESCAN and uncomment DEVICESCAN -R 194 -R 231 -I 9
# to get meaningful and useful raw temperature in syslog
vi /etc/smartd.conf

# add smartd service to autostart
rc-update add smartd

# start the service now
/etc/init.d/smartd start
</pre>

=== Sensors ===

==== lm_sensors ====

<pre>
# install package
apk add lm_sensors

# install package for detecting sensors (if needed) - installs perl too
apk add lm_sensors-detect

# load module required for detecting sensors
modprobe i2c-dev

# detect sensors (skip scanning Super I/O, IPMI, ISA if you're on grsec)
sensors-detect

# after detecting sensors you can remove perl (if you don't need it)
apk del perl
</pre>

===== Problems =====

<ol>
<li><code>sensors-detect</code> command created <code>/etc/modules-load.d/lm_sensors.conf</code> file, but its first line is a comment, which leads to following message during boot
<pre>
modprobe: ERROR: missing parameters. See -h.
</pre>
It can be fixed by improving sed command in <code>/etc/init.d/modules</code> from <code>'s/\#.*//g'</code> to <code><nowiki>'s/\#.*//g;/^[[:space:]]*$/d'</nowiki></code> (deleting blank lines).
{{note|Patch has been sent to alpine-devel ML. http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3432. It was applied in commit [http://git.alpinelinux.org/cgit/aports/commit/?id{{=}}fc95677dd60833bca07ad5c2a037058e94471ff7 fc95677dd608] (2016-04-21)}}

<li>It seems that nowadays you don't have to add <code>lm_sensors</code> to autostart, because in AL ''lm_sensors'' package is patched to create file <code>/etc/modules-load.d/lm_sensors.conf</code> (files in this directory are inspected by <code>/etc/init.d/modules</code>). <code>/etc/init.d/lm_sensors</code> seems in fact superfluous and it also doesn't work
<pre>
* /etc/conf.d/lm_sensors does not exist, try running sensors-detect
* ERROR: lm_sensors failed to start
</pre>
because it expects old file (<code>/etc/conf.d/lm_sensors</code>), which is no longer provided.
{{note|Problem has been reported to alpine-devel ML: http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3433. File has been removed in commit [http://git.alpinelinux.org/cgit/aports/commit/?id{{=}}05ca027f69eb029ba8ddc97700639dbe5cb3ad91 05ca027f69eb] (2016-04-20).
}}

</ol>

=== Mail ===

I don't need my own real mail server (as it's kind of PITA to set it up properly nowadays). Simple MTA is good enough. In the old days I used ssmtp, but it stopped being maintained (apparently debian devs maintain it now), so I switched to msmtp.

==== msmtp ====

After installing ''msmtp'' package, you need to create configuration file in your home directory. You can find example for Zoho Mail account.

{{Cat|~/.msmtprc|defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
auth on
port 587

account yourname@zoho.com
from yourname@zoho.com
user yourname@zoho.com
host smtp.zoho.com

account default : yourname@zoho.com
}}

You'll be asked for password every time mail is sent.

===== Problems =====

If you use gmail, then it's no longer that simple. After changing each zoho to gmail in above exemplary configuration, you still won't be able to send any mail. You'll get:

<pre>msmtp: server message: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=...> Please log in via your web browser and then try again.
msmtp: server message: 534-5.7.14 Learn more at
msmtp: server message: 534-5.7.14 https://support.google.com/mail/answer/78754 ...
</pre>

and you'll receive e-mail titled "Sign-in attempt prevented".

You have to [https://www.google.com/settings/security/lesssecureapps turn on less secure apps] if you want to deal with it. If you're using 2-step verification, then you'll have to [https://security.google.com/settings/security/apppasswords add app password for msmtp].

User:Przemoc/Notes

2016-04-24T00:55:13Z

Przemoc: AL 3.3.3: Console/Keymap

I finally installed AL and I'm poking it a bit. Here you can find some notes regarding this experience. They should be helpful, but please use them with caution. I may add some additional commentary sometimes. If you think there is a better way to perform some of mentioned here tasks, then don't hesitate to notify me about it. Top-level headings denotes AL version that was used. Backward and forward compatibility is possible, but not tested.

__TOC__

== Alpine Linux 3.3.3 ==

=== Shell ===

Even though I always try to write POSIX sh-compliant scripts, I like to have <code>bash</code> as my default shell, because it's quite handy. Being able to write for instance quick <code>diff -u <(COMMAND1) <(COMMAND2)</code> (to compare output of two commands) or <code>mv FILE{,SUFFIX}</code> (to rename file by adding suffix) is very convenient.

==== Bash as default shell ====

AL doesn't have <code>vipw</code>, so root has to perform <code>vi /etc/passwd</code> himself to change the last field of root record (should be the first line in the file). You have to install ''util-linux'' package to get <code>chsh</code> utility.

==== Activate color prompt ====

Initial prompt: <code style="background-color:black;color:gray;">baytrail:~# </code>

{{cmd|mv /etc/profile.d/color_prompt{,.sh}
}}

Prompt after above change and relogin: <code style="background-color:black;color:gray;">baytrail [~]# </code>

==== Long history ====

I like to have long history, so I created following file:

{{Cat|/etc/profile.d/long_history.sh|export HISTSIZE{{=}}9999999
export HISTFILESIZE{{=}}$HISTSIZE
}}

=== Console ===

If you have physical access to screen connected to your machine with AL, it's nice to have properly configured console.

==== UTF-8 encoding ====

To have UTF-8 from OpenRC point of view, you have to set in <code>/etc/rc.conf</code>:
<pre>unicode="YES"</pre>
and add <code>/etc/init.d/termencoding</code> to autostart:
{{cmd|rc-update add termencoding}}
In fact it's mostly irrelevant (prove me wrong).

==== Font with polish letters ====

To be able to see polish letters, you have to install ''kbd-misc'' package, set in <code>/etc/conf.d/consolefont</code>:
<pre>consolefont="lat2-sun16.psfu.gz"
consoletranslation="8859-2_to_uni.trans"</pre>
and add <code>/etc/init.d/consolefont</code> to autostart:
{{cmd|rc-update add consolefont}}

If you don't like default <code>default8x16.psf.gz</code> font, then use <code>lat2-16.psfu.gz</code> instead. If you're comfortable with lower letter height, then I suggest using <code>lat2-14.psfu.gz</code>, which is still readable, yet on my 1920x1200 display increases LINES number from 75 to 85.

==== Keymap with only right Alt used for inputting polish letters ====

Default polish keymap <code>pl</code> uses both Alt keys for polish letters. If you prefer left Alt to be usable for other stuff (like switching to active window in irssi via Alt+A), then you have to switch to <code>pl1</code> variant. ''bkeymaps'' package is needed for setting, but can be removed later.
{{cmd|setup-keymap pl pl1}}

==== UTF-8 in tmux ====

tmux checks upon start-up whether environment variable <code>LC_ALL</code>, or if it's empty then <code>LC_CTYPE</code>, or if it's empty then <code>LANG</code>, contain string <code>UTF-8</code> or <code>UTF8</code> to activate its UTF-8 mode. It can be also triggered by <code>-u</code> option. Important part is that globally turning on <code>utf8</code> window option in tmux configuration doesn't enforce UTF-8 mode.

musl has locale system since v1.1.4, it was incomplete and experimental, but I'm not sure how it is now. The thing is it's not leveraged by AL and by default you have no <code>LC_*</code> variables set. In musl built-in default is <code>C.UTF-8</code>, so we can simply create one file to set <code>LC_CTYPE</code> to such default value and it will satisfy tmux check:

{{Cat|/etc/profile.d/locale.sh|export LC_CTYPE{{=}}C.UTF-8
}}

Possible alternative is to alias <code>tmux</code> to <code>tmux -u</code>, but it seems clunky.

=== Disk ===

==== Set up RAID1 on two devices ====

<pre>
# install package
apk add mdadm

# load "raid1" module during boot (not really needed if you perform further steps)
echo raid1 >>/etc/modules

# create RAID1 array on two whole disks with 1MB data offset
mdadm --create --level=1 --raid-devices=2 --data-offset=1M /dev/md0 /dev/sda /dev/sdb

# preserve original example mdadm.conf
mv /etc/mdadm.conf{,.orig}

# save current setup into configuration file
# (usually people do not use -v, but it's more readable)
mdadm --detail -v --scan >/etc/mdadm.conf

# add raid devices starting to autostart
rc-update add mdadm-raid

# add raid devices monitoring to autostart
rc-update add mdadm

# start raid devices monitoring now
/etc/init.d/mdadm start

# following steps are needed if you want to support RAID early during boot

# add "raid" to features (space-separated values)
vi /etc/mkinitfs/mkinitfs.conf

# rebuild /boot/initramfs-grsec
mkinitfs

# add "raid1" to modules (comma-separated values)
vi /etc/update-extlinux.conf

# update extlinux
update-extlinux
</pre>

==== Install smartctl and smartd ====

<pre>
# install package
apk add smartmontools

# comment DEVICESCAN and uncomment DEVICESCAN -R 194 -R 231 -I 9
# to get meaningful and useful raw temperature in syslog
vi /etc/smartd.conf

# add smartd service to autostart
rc-update add smartd

# start the service now
/etc/init.d/smartd start
</pre>

=== Sensors ===

==== lm_sensors ====

<pre>
# install package
apk add lm_sensors

# install package for detecting sensors (if needed) - installs perl too
apk add lm_sensors-detect

# load module required for detecting sensors
modprobe i2c-dev

# detect sensors (skip scanning Super I/O, IPMI, ISA if you're on grsec)
sensors-detect

# after detecting sensors you can remove perl (if you don't need it)
apk del perl
</pre>

===== Problems =====

<ol>
<li><code>sensors-detect</code> command created <code>/etc/modules-load.d/lm_sensors.conf</code> file, but its first line is a comment, which leads to following message during boot
<pre>
modprobe: ERROR: missing parameters. See -h.
</pre>
It can be fixed by improving sed command in <code>/etc/init.d/modules</code> from <code>'s/\#.*//g'</code> to <code><nowiki>'s/\#.*//g;/^[[:space:]]*$/d'</nowiki></code> (deleting blank lines).
{{note|Patch has been sent to alpine-devel ML. http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3432. It was applied in commit [http://git.alpinelinux.org/cgit/aports/commit/?id{{=}}fc95677dd60833bca07ad5c2a037058e94471ff7 fc95677dd608] (2016-04-21)}}

<li>It seems that nowadays you don't have to add <code>lm_sensors</code> to autostart, because in AL ''lm_sensors'' package is patched to create file <code>/etc/modules-load.d/lm_sensors.conf</code> (files in this directory are inspected by <code>/etc/init.d/modules</code>). <code>/etc/init.d/lm_sensors</code> seems in fact superfluous and it also doesn't work
<pre>
* /etc/conf.d/lm_sensors does not exist, try running sensors-detect
* ERROR: lm_sensors failed to start
</pre>
because it expects old file (<code>/etc/conf.d/lm_sensors</code>), which is no longer provided.
{{note|Problem has been reported to alpine-devel ML: http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3433. File has been removed in commit [http://git.alpinelinux.org/cgit/aports/commit/?id{{=}}05ca027f69eb029ba8ddc97700639dbe5cb3ad91 05ca027f69eb] (2016-04-20).
}}

</ol>

=== Mail ===

I don't need my own real mail server (as it's kind of PITA to set it up properly nowadays). Simple MTA is good enough. In the old days I used ssmtp, but it stopped being maintained (apparently debian devs maintain it now), so I switched to msmtp.

==== msmtp ====

After installing ''msmtp'' package, you need to create configuration file in your home directory. You can find example for Zoho Mail account.

{{Cat|~/.msmtprc|defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
auth on
port 587

account yourname@zoho.com
from yourname@zoho.com
user yourname@zoho.com
host smtp.zoho.com

account default : yourname@zoho.com
}}

You'll be asked for password every time mail is sent.

===== Problems =====

If you use gmail, then it's no longer that simple. After changing each zoho to gmail in above exemplary configuration, you still won't be able to send any mail. You'll get:

<pre>msmtp: server message: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=...> Please log in via your web browser and then try again.
msmtp: server message: 534-5.7.14 Learn more at
msmtp: server message: 534-5.7.14 https://support.google.com/mail/answer/78754 ...
</pre>

and you'll receive e-mail titled "Sign-in attempt prevented".

You have to [https://www.google.com/settings/security/lesssecureapps turn on less secure apps] if you want to deal with it. If you're using 2-step verification, then you'll have to [https://security.google.com/settings/security/apppasswords add app password for msmtp].

User:Przemoc/Notes

2016-04-23T12:12:01Z

Przemoc: AL 3.3.3: Sensors/lm_sensors/Problems - update

I finally installed AL and I'm poking it a bit. Here you can find some notes regarding this experience. They should be helpful, but please use them with caution. I may add some additional commentary sometimes. If you think there is a better way to perform some of mentioned here tasks, then don't hesitate to notify me about it. Top-level headings denotes AL version that was used. Backward and forward compatibility is possible, but not tested.

__TOC__

== Alpine Linux 3.3.3 ==

=== Shell ===

Even though I always try to write POSIX sh-compliant scripts, I like to have <code>bash</code> as my default shell, because it's quite handy. Being able to write for instance quick <code>diff -u <(COMMAND1) <(COMMAND2)</code> (to compare output of two commands) or <code>mv FILE{,SUFFIX}</code> (to rename file by adding suffix) is very convenient.

==== Bash as default shell ====

AL doesn't have <code>vipw</code>, so root has to perform <code>vi /etc/passwd</code> himself to change the last field of root record (should be the first line in the file). You have to install ''util-linux'' package to get <code>chsh</code> utility.

==== Activate color prompt ====

Initial prompt: <code style="background-color:black;color:gray;">baytrail:~# </code>

{{cmd|mv /etc/profile.d/color_prompt{,.sh}
}}

Prompt after above change and relogin: <code style="background-color:black;color:gray;">baytrail [~]# </code>

==== Long history ====

I like to have long history, so I created following file:

{{Cat|/etc/profile.d/long_history.sh|export HISTSIZE{{=}}9999999
export HISTFILESIZE{{=}}$HISTSIZE
}}

=== Console ===

If you have physical access to screen connected to your machine with AL, it's nice to have properly configured console.

==== UTF-8 encoding ====

To have UTF-8 from OpenRC point of view, you have to set in <code>/etc/rc.conf</code>:
<pre>unicode="YES"</pre>
and add <code>/etc/init.d/termencoding</code> to autostart:
{{cmd|rc-update add termencoding}}
In fact it's mostly irrelevant (prove me wrong).

==== Font with polish letters ====

To be able to see polish letters, you have to install ''kbd-misc'' package, set in <code>/etc/conf.d/consolefont</code>:
<pre>consolefont="lat2-sun16.psfu.gz"
consoletranslation="8859-2_to_uni.trans"</pre>
and add <code>/etc/init.d/consolefont</code> to autostart:
{{cmd|rc-update add consolefont}}

If you don't like default <code>default8x16.psf.gz</code> font, then use <code>lat2-16.psfu.gz</code> instead. If you're comfortable with lower letter height, then I suggest using <code>lat2-14.psfu.gz</code>, which is still readable, yet on my 1920x1200 display increases LINES number from 75 to 85.

==== UTF-8 in tmux ====

tmux checks upon start-up whether environment variable <code>LC_ALL</code>, or if it's empty then <code>LC_CTYPE</code>, or if it's empty then <code>LANG</code>, contain string <code>UTF-8</code> or <code>UTF8</code> to activate its UTF-8 mode. It can be also triggered by <code>-u</code> option. Important part is that globally turning on <code>utf8</code> window option in tmux configuration doesn't enforce UTF-8 mode.

musl has locale system since v1.1.4, it was incomplete and experimental, but I'm not sure how it is now. The thing is it's not leveraged by AL and by default you have no <code>LC_*</code> variables set. In musl built-in default is <code>C.UTF-8</code>, so we can simply create one file to set <code>LC_CTYPE</code> to such default value and it will satisfy tmux check:

{{Cat|/etc/profile.d/locale.sh|export LC_CTYPE{{=}}C.UTF-8
}}

Possible alternative is to alias <code>tmux</code> to <code>tmux -u</code>, but it seems clunky.

=== Disk ===

==== Set up RAID1 on two devices ====

<pre>
# install package
apk add mdadm

# load "raid1" module during boot (not really needed if you perform further steps)
echo raid1 >>/etc/modules

# create RAID1 array on two whole disks with 1MB data offset
mdadm --create --level=1 --raid-devices=2 --data-offset=1M /dev/md0 /dev/sda /dev/sdb

# preserve original example mdadm.conf
mv /etc/mdadm.conf{,.orig}

# save current setup into configuration file
# (usually people do not use -v, but it's more readable)
mdadm --detail -v --scan >/etc/mdadm.conf

# add raid devices starting to autostart
rc-update add mdadm-raid

# add raid devices monitoring to autostart
rc-update add mdadm

# start raid devices monitoring now
/etc/init.d/mdadm start

# following steps are needed if you want to support RAID early during boot

# add "raid" to features (space-separated values)
vi /etc/mkinitfs/mkinitfs.conf

# rebuild /boot/initramfs-grsec
mkinitfs

# add "raid1" to modules (comma-separated values)
vi /etc/update-extlinux.conf

# update extlinux
update-extlinux
</pre>

==== Install smartctl and smartd ====

<pre>
# install package
apk add smartmontools

# comment DEVICESCAN and uncomment DEVICESCAN -R 194 -R 231 -I 9
# to get meaningful and useful raw temperature in syslog
vi /etc/smartd.conf

# add smartd service to autostart
rc-update add smartd

# start the service now
/etc/init.d/smartd start
</pre>

=== Sensors ===

==== lm_sensors ====

<pre>
# install package
apk add lm_sensors

# install package for detecting sensors (if needed) - installs perl too
apk add lm_sensors-detect

# load module required for detecting sensors
modprobe i2c-dev

# detect sensors (skip scanning Super I/O, IPMI, ISA if you're on grsec)
sensors-detect

# after detecting sensors you can remove perl (if you don't need it)
apk del perl
</pre>

===== Problems =====

<ol>
<li><code>sensors-detect</code> command created <code>/etc/modules-load.d/lm_sensors.conf</code> file, but its first line is a comment, which leads to following message during boot
<pre>
modprobe: ERROR: missing parameters. See -h.
</pre>
It can be fixed by improving sed command in <code>/etc/init.d/modules</code> from <code>'s/\#.*//g'</code> to <code><nowiki>'s/\#.*//g;/^[[:space:]]*$/d'</nowiki></code> (deleting blank lines).
{{note|Patch has been sent to alpine-devel ML. http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3432. It was applied in commit [http://git.alpinelinux.org/cgit/aports/commit/?id{{=}}fc95677dd60833bca07ad5c2a037058e94471ff7 fc95677dd608] (2016-04-21)}}

<li>It seems that nowadays you don't have to add <code>lm_sensors</code> to autostart, because in AL ''lm_sensors'' package is patched to create file <code>/etc/modules-load.d/lm_sensors.conf</code> (files in this directory are inspected by <code>/etc/init.d/modules</code>). <code>/etc/init.d/lm_sensors</code> seems in fact superfluous and it also doesn't work
<pre>
* /etc/conf.d/lm_sensors does not exist, try running sensors-detect
* ERROR: lm_sensors failed to start
</pre>
because it expects old file (<code>/etc/conf.d/lm_sensors</code>), which is no longer provided.
{{note|Problem has been reported to alpine-devel ML: http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3433. File has been removed in commit [http://git.alpinelinux.org/cgit/aports/commit/?id{{=}}05ca027f69eb029ba8ddc97700639dbe5cb3ad91 05ca027f69eb] (2016-04-20).
}}

</ol>

=== Mail ===

I don't need my own real mail server (as it's kind of PITA to set it up properly nowadays). Simple MTA is good enough. In the old days I used ssmtp, but it stopped being maintained (apparently debian devs maintain it now), so I switched to msmtp.

==== msmtp ====

After installing ''msmtp'' package, you need to create configuration file in your home directory. You can find example for Zoho Mail account.

{{Cat|~/.msmtprc|defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
auth on
port 587

account yourname@zoho.com
from yourname@zoho.com
user yourname@zoho.com
host smtp.zoho.com

account default : yourname@zoho.com
}}

You'll be asked for password every time mail is sent.

===== Problems =====

If you use gmail, then it's no longer that simple. After changing each zoho to gmail in above exemplary configuration, you still won't be able to send any mail. You'll get:

<pre>msmtp: server message: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=...> Please log in via your web browser and then try again.
msmtp: server message: 534-5.7.14 Learn more at
msmtp: server message: 534-5.7.14 https://support.google.com/mail/answer/78754 ...
</pre>

and you'll receive e-mail titled "Sign-in attempt prevented".

You have to [https://www.google.com/settings/security/lesssecureapps turn on less secure apps] if you want to deal with it. If you're using 2-step verification, then you'll have to [https://security.google.com/settings/security/apppasswords add app password for msmtp].

User:Przemoc/Notes

2016-04-20T16:47:34Z

Przemoc: AL 3.3.3: Sensors/lm_sensors/Problems - update

I finally installed AL and I'm poking it a bit. Here you can find some notes regarding this experience. They should be helpful, but please use them with caution. I may add some additional commentary sometimes. If you think there is a better way to perform some of mentioned here tasks, then don't hesitate to notify me about it. Top-level headings denotes AL version that was used. Backward and forward compatibility is possible, but not tested.

__TOC__

== Alpine Linux 3.3.3 ==

=== Shell ===

Even though I always try to write POSIX sh-compliant scripts, I like to have <code>bash</code> as my default shell, because it's quite handy. Being able to write for instance quick <code>diff -u <(COMMAND1) <(COMMAND2)</code> (to compare output of two commands) or <code>mv FILE{,SUFFIX}</code> (to rename file by adding suffix) is very convenient.

==== Bash as default shell ====

AL doesn't have <code>vipw</code>, so root has to perform <code>vi /etc/passwd</code> himself to change the last field of root record (should be the first line in the file). You have to install ''util-linux'' package to get <code>chsh</code> utility.

==== Activate color prompt ====

Initial prompt: <code style="background-color:black;color:gray;">baytrail:~# </code>

{{cmd|mv /etc/profile.d/color_prompt{,.sh}
}}

Prompt after above change and relogin: <code style="background-color:black;color:gray;">baytrail [~]# </code>

==== Long history ====

I like to have long history, so I created following file:

{{Cat|/etc/profile.d/long_history.sh|export HISTSIZE{{=}}9999999
export HISTFILESIZE{{=}}$HISTSIZE
}}

=== Console ===

If you have physical access to screen connected to your machine with AL, it's nice to have properly configured console.

==== UTF-8 encoding ====

To have UTF-8 from OpenRC point of view, you have to set in <code>/etc/rc.conf</code>:
<pre>unicode="YES"</pre>
and add <code>/etc/init.d/termencoding</code> to autostart:
{{cmd|rc-update add termencoding}}
In fact it's mostly irrelevant (prove me wrong).

==== Font with polish letters ====

To be able to see polish letters, you have to install ''kbd-misc'' package, set in <code>/etc/conf.d/consolefont</code>:
<pre>consolefont="lat2-sun16.psfu.gz"
consoletranslation="8859-2_to_uni.trans"</pre>
and add <code>/etc/init.d/consolefont</code> to autostart:
{{cmd|rc-update add consolefont}}

If you don't like default <code>default8x16.psf.gz</code> font, then use <code>lat2-16.psfu.gz</code> instead. If you're comfortable with lower letter height, then I suggest using <code>lat2-14.psfu.gz</code>, which is still readable, yet on my 1920x1200 display increases LINES number from 75 to 85.

==== UTF-8 in tmux ====

tmux checks upon start-up whether environment variable <code>LC_ALL</code>, or if it's empty then <code>LC_CTYPE</code>, or if it's empty then <code>LANG</code>, contain string <code>UTF-8</code> or <code>UTF8</code> to activate its UTF-8 mode. It can be also triggered by <code>-u</code> option. Important part is that globally turning on <code>utf8</code> window option in tmux configuration doesn't enforce UTF-8 mode.

musl has locale system since v1.1.4, it was incomplete and experimental, but I'm not sure how it is now. The thing is it's not leveraged by AL and by default you have no <code>LC_*</code> variables set. In musl built-in default is <code>C.UTF-8</code>, so we can simply create one file to set <code>LC_CTYPE</code> to such default value and it will satisfy tmux check:

{{Cat|/etc/profile.d/locale.sh|export LC_CTYPE{{=}}C.UTF-8
}}

Possible alternative is to alias <code>tmux</code> to <code>tmux -u</code>, but it seems clunky.

=== Disk ===

==== Set up RAID1 on two devices ====

<pre>
# install package
apk add mdadm

# load "raid1" module during boot (not really needed if you perform further steps)
echo raid1 >>/etc/modules

# create RAID1 array on two whole disks with 1MB data offset
mdadm --create --level=1 --raid-devices=2 --data-offset=1M /dev/md0 /dev/sda /dev/sdb

# preserve original example mdadm.conf
mv /etc/mdadm.conf{,.orig}

# save current setup into configuration file
# (usually people do not use -v, but it's more readable)
mdadm --detail -v --scan >/etc/mdadm.conf

# add raid devices starting to autostart
rc-update add mdadm-raid

# add raid devices monitoring to autostart
rc-update add mdadm

# start raid devices monitoring now
/etc/init.d/mdadm start

# following steps are needed if you want to support RAID early during boot

# add "raid" to features (space-separated values)
vi /etc/mkinitfs/mkinitfs.conf

# rebuild /boot/initramfs-grsec
mkinitfs

# add "raid1" to modules (comma-separated values)
vi /etc/update-extlinux.conf

# update extlinux
update-extlinux
</pre>

==== Install smartctl and smartd ====

<pre>
# install package
apk add smartmontools

# comment DEVICESCAN and uncomment DEVICESCAN -R 194 -R 231 -I 9
# to get meaningful and useful raw temperature in syslog
vi /etc/smartd.conf

# add smartd service to autostart
rc-update add smartd

# start the service now
/etc/init.d/smartd start
</pre>

=== Sensors ===

==== lm_sensors ====

<pre>
# install package
apk add lm_sensors

# install package for detecting sensors (if needed) - installs perl too
apk add lm_sensors-detect

# load module required for detecting sensors
modprobe i2c-dev

# detect sensors (skip scanning Super I/O, IPMI, ISA if you're on grsec)
sensors-detect

# after detecting sensors you can remove perl (if you don't need it)
apk del perl
</pre>

===== Problems =====

<ol>
<li><code>sensors-detect</code> command created <code>/etc/modules-load.d/lm_sensors.conf</code> file, but its first line is a comment, which leads to following message during boot
<pre>
modprobe: ERROR: missing parameters. See -h.
</pre>
It can be fixed by improving sed command in <code>/etc/init.d/modules</code> from <code>'s/\#.*//g'</code> to <code>'s/\#.*//g;/^[[:space:]]*$/d'</code> (deleting blank lines).
{{note|Patch has been sent to alpine-devel ML. http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3432}}

<li>It seems that nowadays you don't have to add <code>lm_sensors</code> to autostart, because in AL ''lm_sensors'' package is patched to create file <code>/etc/modules-load.d/lm_sensors.conf</code> (files in this directory are inspected by <code>/etc/init.d/modules</code>). <code>/etc/init.d/lm_sensors</code> seems in fact superfluous and it also doesn't work
<pre>
* /etc/conf.d/lm_sensors does not exist, try running sensors-detect
* ERROR: lm_sensors failed to start
</pre>
because it expects old file (<code>/etc/conf.d/lm_sensors</code>), which is no longer provided.
{{note|Problem has been reported to alpine-devel ML: http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3433. File has been removed in commit [http://git.alpinelinux.org/cgit/aports/commit/?id{{=}}05ca027f69eb029ba8ddc97700639dbe5cb3ad91 05ca027f69eb].
}}

</ol>

=== Mail ===

I don't need my own real mail server (as it's kind of PITA to set it up properly nowadays). Simple MTA is good enough. In the old days I used ssmtp, but it stopped being maintained (apparently debian devs maintain it now), so I switched to msmtp.

==== msmtp ====

After installing ''msmtp'' package, you need to create configuration file in your home directory. You can find example for Zoho Mail account.

{{Cat|~/.msmtprc|defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
auth on
port 587

account yourname@zoho.com
from yourname@zoho.com
user yourname@zoho.com
host smtp.zoho.com

account default : yourname@zoho.com
}}

You'll be asked for password every time mail is sent.

===== Problems =====

If you use gmail, then it's no longer that simple. After changing each zoho to gmail in above exemplary configuration, you still won't be able to send any mail. You'll get:

<pre>msmtp: server message: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=...> Please log in via your web browser and then try again.
msmtp: server message: 534-5.7.14 Learn more at
msmtp: server message: 534-5.7.14 https://support.google.com/mail/answer/78754 ...
</pre>

and you'll receive e-mail titled "Sign-in attempt prevented".

You have to [https://www.google.com/settings/security/lesssecureapps turn on less secure apps] if you want to deal with it. If you're using 2-step verification, then you'll have to [https://security.google.com/settings/security/apppasswords add app password for msmtp].

User:Przemoc/Notes

2016-04-19T22:08:45Z

Przemoc: AL 3.3.3: Sensors/lm_sensors/Problems - update

I finally installed AL and I'm poking it a bit. Here you can find some notes regarding this experience. They should be helpful, but please use them with caution. I may add some additional commentary sometimes. If you think there is a better way to perform some of mentioned here tasks, then don't hesitate to notify me about it. Top-level headings denotes AL version that was used. Backward and forward compatibility is possible, but not tested.

__TOC__

== Alpine Linux 3.3.3 ==

=== Shell ===

Even though I always try to write POSIX sh-compliant scripts, I like to have <code>bash</code> as my default shell, because it's quite handy. Being able to write for instance quick <code>diff -u <(COMMAND1) <(COMMAND2)</code> (to compare output of two commands) or <code>mv FILE{,SUFFIX}</code> (to rename file by adding suffix) is very convenient.

==== Bash as default shell ====

AL doesn't have <code>vipw</code>, so root has to perform <code>vi /etc/passwd</code> himself to change the last field of root record (should be the first line in the file). You have to install ''util-linux'' package to get <code>chsh</code> utility.

==== Activate color prompt ====

Initial prompt: <code style="background-color:black;color:gray;">baytrail:~# </code>

{{cmd|mv /etc/profile.d/color_prompt{,.sh}
}}

Prompt after above change and relogin: <code style="background-color:black;color:gray;">baytrail [~]# </code>

==== Long history ====

I like to have long history, so I created following file:

{{Cat|/etc/profile.d/long_history.sh|export HISTSIZE{{=}}9999999
export HISTFILESIZE{{=}}$HISTSIZE
}}

=== Console ===

If you have physical access to screen connected to your machine with AL, it's nice to have properly configured console.

==== UTF-8 encoding ====

To have UTF-8 from OpenRC point of view, you have to set in <code>/etc/rc.conf</code>:
<pre>unicode="YES"</pre>
and add <code>/etc/init.d/termencoding</code> to autostart:
{{cmd|rc-update add termencoding}}
In fact it's mostly irrelevant (prove me wrong).

==== Font with polish letters ====

To be able to see polish letters, you have to install ''kbd-misc'' package, set in <code>/etc/conf.d/consolefont</code>:
<pre>consolefont="lat2-sun16.psfu.gz"
consoletranslation="8859-2_to_uni.trans"</pre>
and add <code>/etc/init.d/consolefont</code> to autostart:
{{cmd|rc-update add consolefont}}

If you don't like default <code>default8x16.psf.gz</code> font, then use <code>lat2-16.psfu.gz</code> instead. If you're comfortable with lower letter height, then I suggest using <code>lat2-14.psfu.gz</code>, which is still readable, yet on my 1920x1200 display increases LINES number from 75 to 85.

==== UTF-8 in tmux ====

tmux checks upon start-up whether environment variable <code>LC_ALL</code>, or if it's empty then <code>LC_CTYPE</code>, or if it's empty then <code>LANG</code>, contain string <code>UTF-8</code> or <code>UTF8</code> to activate its UTF-8 mode. It can be also triggered by <code>-u</code> option. Important part is that globally turning on <code>utf8</code> window option in tmux configuration doesn't enforce UTF-8 mode.

musl has locale system since v1.1.4, it was incomplete and experimental, but I'm not sure how it is now. The thing is it's not leveraged by AL and by default you have no <code>LC_*</code> variables set. In musl built-in default is <code>C.UTF-8</code>, so we can simply create one file to set <code>LC_CTYPE</code> to such default value and it will satisfy tmux check:

{{Cat|/etc/profile.d/locale.sh|export LC_CTYPE{{=}}C.UTF-8
}}

Possible alternative is to alias <code>tmux</code> to <code>tmux -u</code>, but it seems clunky.

=== Disk ===

==== Set up RAID1 on two devices ====

<pre>
# install package
apk add mdadm

# load "raid1" module during boot (not really needed if you perform further steps)
echo raid1 >>/etc/modules

# create RAID1 array on two whole disks with 1MB data offset
mdadm --create --level=1 --raid-devices=2 --data-offset=1M /dev/md0 /dev/sda /dev/sdb

# preserve original example mdadm.conf
mv /etc/mdadm.conf{,.orig}

# save current setup into configuration file
# (usually people do not use -v, but it's more readable)
mdadm --detail -v --scan >/etc/mdadm.conf

# add raid devices starting to autostart
rc-update add mdadm-raid

# add raid devices monitoring to autostart
rc-update add mdadm

# start raid devices monitoring now
/etc/init.d/mdadm start

# following steps are needed if you want to support RAID early during boot

# add "raid" to features (space-separated values)
vi /etc/mkinitfs/mkinitfs.conf

# rebuild /boot/initramfs-grsec
mkinitfs

# add "raid1" to modules (comma-separated values)
vi /etc/update-extlinux.conf

# update extlinux
update-extlinux
</pre>

==== Install smartctl and smartd ====

<pre>
# install package
apk add smartmontools

# comment DEVICESCAN and uncomment DEVICESCAN -R 194 -R 231 -I 9
# to get meaningful and useful raw temperature in syslog
vi /etc/smartd.conf

# add smartd service to autostart
rc-update add smartd

# start the service now
/etc/init.d/smartd start
</pre>

=== Sensors ===

==== lm_sensors ====

<pre>
# install package
apk add lm_sensors

# install package for detecting sensors (if needed) - installs perl too
apk add lm_sensors-detect

# load module required for detecting sensors
modprobe i2c-dev

# detect sensors (skip scanning Super I/O, IPMI, ISA if you're on grsec)
sensors-detect

# after detecting sensors you can remove perl (if you don't need it)
apk del perl
</pre>

===== Problems =====

<ol>
<li><code>sensors-detect</code> command created <code>/etc/modules-load.d/lm_sensors.conf</code> file, but its first line is a comment, which leads to following message during boot
<pre>
modprobe: ERROR: missing parameters. See -h.
</pre>
It can be fixed by improving sed command in <code>/etc/init.d/modules</code> from <code>'s/\#.*//g'</code> to <code>'s/\#.*//g;/^[[:space:]]*$/d'</code> (deleting blank lines).
{{note|Patch has been sent to alpine-devel ML. http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3432}}

<li>It seems that nowadays you don't have to add <code>lm_sensors</code> to autostart, because in AL ''lm_sensors'' package is patched to create file <code>/etc/modules-load.d/lm_sensors.conf</code> (files in this directory are inspected by <code>/etc/init.d/modules</code>). <code>/etc/init.d/lm_sensors</code> seems in fact superfluous and it also doesn't work
<pre>
* /etc/conf.d/lm_sensors does not exist, try running sensors-detect
* ERROR: lm_sensors failed to start
</pre>
because it expects old file (<code>/etc/conf.d/lm_sensors</code>), which is no longer provided.
{{note|Problem has been reported to alpine-devel ML. http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3433}}

</ol>

=== Mail ===

I don't need my own real mail server (as it's kind of PITA to set it up properly nowadays). Simple MTA is good enough. In the old days I used ssmtp, but it stopped being maintained (apparently debian devs maintain it now), so I switched to msmtp.

==== msmtp ====

After installing ''msmtp'' package, you need to create configuration file in your home directory. You can find example for Zoho Mail account.

{{Cat|~/.msmtprc|defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
auth on
port 587

account yourname@zoho.com
from yourname@zoho.com
user yourname@zoho.com
host smtp.zoho.com

account default : yourname@zoho.com
}}

You'll be asked for password every time mail is sent.

===== Problems =====

If you use gmail, then it's no longer that simple. After changing each zoho to gmail in above exemplary configuration, you still won't be able to send any mail. You'll get:

<pre>msmtp: server message: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=...> Please log in via your web browser and then try again.
msmtp: server message: 534-5.7.14 Learn more at
msmtp: server message: 534-5.7.14 https://support.google.com/mail/answer/78754 ...
</pre>

and you'll receive e-mail titled "Sign-in attempt prevented".

You have to [https://www.google.com/settings/security/lesssecureapps turn on less secure apps] if you want to deal with it. If you're using 2-step verification, then you'll have to [https://security.google.com/settings/security/apppasswords add app password for msmtp].

User:Przemoc/Notes

2016-04-19T21:43:51Z

Przemoc: AL 3.3.3: Sensors/lm_sensors/Problems - update

I finally installed AL and I'm poking it a bit. Here you can find some notes regarding this experience. They should be helpful, but please use them with caution. I may add some additional commentary sometimes. If you think there is a better way to perform some of mentioned here tasks, then don't hesitate to notify me about it. Top-level headings denotes AL version that was used. Backward and forward compatibility is possible, but not tested.

__TOC__

== Alpine Linux 3.3.3 ==

=== Shell ===

Even though I always try to write POSIX sh-compliant scripts, I like to have <code>bash</code> as my default shell, because it's quite handy. Being able to write for instance quick <code>diff -u <(COMMAND1) <(COMMAND2)</code> (to compare output of two commands) or <code>mv FILE{,SUFFIX}</code> (to rename file by adding suffix) is very convenient.

==== Bash as default shell ====

AL doesn't have <code>vipw</code>, so root has to perform <code>vi /etc/passwd</code> himself to change the last field of root record (should be the first line in the file). You have to install ''util-linux'' package to get <code>chsh</code> utility.

==== Activate color prompt ====

Initial prompt: <code style="background-color:black;color:gray;">baytrail:~# </code>

{{cmd|mv /etc/profile.d/color_prompt{,.sh}
}}

Prompt after above change and relogin: <code style="background-color:black;color:gray;">baytrail [~]# </code>

==== Long history ====

I like to have long history, so I created following file:

{{Cat|/etc/profile.d/long_history.sh|export HISTSIZE{{=}}9999999
export HISTFILESIZE{{=}}$HISTSIZE
}}

=== Console ===

If you have physical access to screen connected to your machine with AL, it's nice to have properly configured console.

==== UTF-8 encoding ====

To have UTF-8 from OpenRC point of view, you have to set in <code>/etc/rc.conf</code>:
<pre>unicode="YES"</pre>
and add <code>/etc/init.d/termencoding</code> to autostart:
{{cmd|rc-update add termencoding}}
In fact it's mostly irrelevant (prove me wrong).

==== Font with polish letters ====

To be able to see polish letters, you have to install ''kbd-misc'' package, set in <code>/etc/conf.d/consolefont</code>:
<pre>consolefont="lat2-sun16.psfu.gz"
consoletranslation="8859-2_to_uni.trans"</pre>
and add <code>/etc/init.d/consolefont</code> to autostart:
{{cmd|rc-update add consolefont}}

If you don't like default <code>default8x16.psf.gz</code> font, then use <code>lat2-16.psfu.gz</code> instead. If you're comfortable with lower letter height, then I suggest using <code>lat2-14.psfu.gz</code>, which is still readable, yet on my 1920x1200 display increases LINES number from 75 to 85.

==== UTF-8 in tmux ====

tmux checks upon start-up whether environment variable <code>LC_ALL</code>, or if it's empty then <code>LC_CTYPE</code>, or if it's empty then <code>LANG</code>, contain string <code>UTF-8</code> or <code>UTF8</code> to activate its UTF-8 mode. It can be also triggered by <code>-u</code> option. Important part is that globally turning on <code>utf8</code> window option in tmux configuration doesn't enforce UTF-8 mode.

musl has locale system since v1.1.4, it was incomplete and experimental, but I'm not sure how it is now. The thing is it's not leveraged by AL and by default you have no <code>LC_*</code> variables set. In musl built-in default is <code>C.UTF-8</code>, so we can simply create one file to set <code>LC_CTYPE</code> to such default value and it will satisfy tmux check:

{{Cat|/etc/profile.d/locale.sh|export LC_CTYPE{{=}}C.UTF-8
}}

Possible alternative is to alias <code>tmux</code> to <code>tmux -u</code>, but it seems clunky.

=== Disk ===

==== Set up RAID1 on two devices ====

<pre>
# install package
apk add mdadm

# load "raid1" module during boot (not really needed if you perform further steps)
echo raid1 >>/etc/modules

# create RAID1 array on two whole disks with 1MB data offset
mdadm --create --level=1 --raid-devices=2 --data-offset=1M /dev/md0 /dev/sda /dev/sdb

# preserve original example mdadm.conf
mv /etc/mdadm.conf{,.orig}

# save current setup into configuration file
# (usually people do not use -v, but it's more readable)
mdadm --detail -v --scan >/etc/mdadm.conf

# add raid devices starting to autostart
rc-update add mdadm-raid

# add raid devices monitoring to autostart
rc-update add mdadm

# start raid devices monitoring now
/etc/init.d/mdadm start

# following steps are needed if you want to support RAID early during boot

# add "raid" to features (space-separated values)
vi /etc/mkinitfs/mkinitfs.conf

# rebuild /boot/initramfs-grsec
mkinitfs

# add "raid1" to modules (comma-separated values)
vi /etc/update-extlinux.conf

# update extlinux
update-extlinux
</pre>

==== Install smartctl and smartd ====

<pre>
# install package
apk add smartmontools

# comment DEVICESCAN and uncomment DEVICESCAN -R 194 -R 231 -I 9
# to get meaningful and useful raw temperature in syslog
vi /etc/smartd.conf

# add smartd service to autostart
rc-update add smartd

# start the service now
/etc/init.d/smartd start
</pre>

=== Sensors ===

==== lm_sensors ====

<pre>
# install package
apk add lm_sensors

# install package for detecting sensors (if needed) - installs perl too
apk add lm_sensors-detect

# load module required for detecting sensors
modprobe i2c-dev

# detect sensors (skip scanning Super I/O, IPMI, ISA if you're on grsec)
sensors-detect

# after detecting sensors you can remove perl (if you don't need it)
apk del perl
</pre>

===== Problems =====

<ol>
<li><code>sensors-detect</code> command created <code>/etc/modules-load.d/lm_sensors.conf</code> file, but its first line is a comment, which leads to following message during boot
<pre>
modprobe: ERROR: missing parameters. See -h.
</pre>
It can be fixed by improving sed command in <code>/etc/init.d/modules</code> from <code>'s/\#.*//g'</code> to <code>'s/\#.*//g;/^[[:space:]]*$/d'</code> (deleting blank lines).
{{note|Patch has been sent. http://thread.gmane.org/gmane.linux.distributions.alpine.devel/3432}}

<li>It seems that nowadays you don't have to add <code>lm_sensors</code> to autostart, because in AL ''lm_sensors'' package is patched to create file <code>/etc/modules-load.d/lm_sensors.conf</code> (files in this directory are inspected by <code>/etc/init.d/modules</code>). <code>/etc/init.d/lm_sensors</code> seems in fact superfluous and it also doesn't work
<pre>
* /etc/conf.d/lm_sensors does not exist, try running sensors-detect
* ERROR: lm_sensors failed to start
</pre>
because it expects old file (<code>/etc/conf.d/lm_sensors</code>), which is no longer provided.
{{todo|Report this issue on alpine-devel ML.}}

</ol>

=== Mail ===

I don't need my own real mail server (as it's kind of PITA to set it up properly nowadays). Simple MTA is good enough. In the old days I used ssmtp, but it stopped being maintained (apparently debian devs maintain it now), so I switched to msmtp.

==== msmtp ====

After installing ''msmtp'' package, you need to create configuration file in your home directory. You can find example for Zoho Mail account.

{{Cat|~/.msmtprc|defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
auth on
port 587

account yourname@zoho.com
from yourname@zoho.com
user yourname@zoho.com
host smtp.zoho.com

account default : yourname@zoho.com
}}

You'll be asked for password every time mail is sent.

===== Problems =====

If you use gmail, then it's no longer that simple. After changing each zoho to gmail in above exemplary configuration, you still won't be able to send any mail. You'll get:

<pre>msmtp: server message: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=...> Please log in via your web browser and then try again.
msmtp: server message: 534-5.7.14 Learn more at
msmtp: server message: 534-5.7.14 https://support.google.com/mail/answer/78754 ...
</pre>

and you'll receive e-mail titled "Sign-in attempt prevented".

You have to [https://www.google.com/settings/security/lesssecureapps turn on less secure apps] if you want to deal with it. If you're using 2-step verification, then you'll have to [https://security.google.com/settings/security/apppasswords add app password for msmtp].

User:Przemoc/Notes

2016-04-19T18:43:54Z

Przemoc: AL 3.3.3: Console/tmux

I finally installed AL and I'm poking it a bit. Here you can find some notes regarding this experience. They should be helpful, but please use them with caution. I may add some additional commentary sometimes. If you think there is a better way to perform some of mentioned here tasks, then don't hesitate to notify me about it. Top-level headings denotes AL version that was used. Backward and forward compatibility is possible, but not tested.

__TOC__

== Alpine Linux 3.3.3 ==

=== Shell ===

Even though I always try to write POSIX sh-compliant scripts, I like to have <code>bash</code> as my default shell, because it's quite handy. Being able to write for instance quick <code>diff -u <(COMMAND1) <(COMMAND2)</code> (to compare output of two commands) or <code>mv FILE{,SUFFIX}</code> (to rename file by adding suffix) is very convenient.

==== Bash as default shell ====

AL doesn't have <code>vipw</code>, so root has to perform <code>vi /etc/passwd</code> himself to change the last field of root record (should be the first line in the file). You have to install ''util-linux'' package to get <code>chsh</code> utility.

==== Activate color prompt ====

Initial prompt: <code style="background-color:black;color:gray;">baytrail:~# </code>

{{cmd|mv /etc/profile.d/color_prompt{,.sh}
}}

Prompt after above change and relogin: <code style="background-color:black;color:gray;">baytrail [~]# </code>

==== Long history ====

I like to have long history, so I created following file:

{{Cat|/etc/profile.d/long_history.sh|export HISTSIZE{{=}}9999999
export HISTFILESIZE{{=}}$HISTSIZE
}}

=== Console ===

If you have physical access to screen connected to your machine with AL, it's nice to have properly configured console.

==== UTF-8 encoding ====

To have UTF-8 from OpenRC point of view, you have to set in <code>/etc/rc.conf</code>:
<pre>unicode="YES"</pre>
and add <code>/etc/init.d/termencoding</code> to autostart:
{{cmd|rc-update add termencoding}}
In fact it's mostly irrelevant (prove me wrong).

==== Font with polish letters ====

To be able to see polish letters, you have to install ''kbd-misc'' package, set in <code>/etc/conf.d/consolefont</code>:
<pre>consolefont="lat2-sun16.psfu.gz"
consoletranslation="8859-2_to_uni.trans"</pre>
and add <code>/etc/init.d/consolefont</code> to autostart:
{{cmd|rc-update add consolefont}}

If you don't like default <code>default8x16.psf.gz</code> font, then use <code>lat2-16.psfu.gz</code> instead. If you're comfortable with lower letter height, then I suggest using <code>lat2-14.psfu.gz</code>, which is still readable, yet on my 1920x1200 display increases LINES number from 75 to 85.

==== UTF-8 in tmux ====

tmux checks upon start-up whether environment variable <code>LC_ALL</code>, or if it's empty then <code>LC_CTYPE</code>, or if it's empty then <code>LANG</code>, contain string <code>UTF-8</code> or <code>UTF8</code> to activate its UTF-8 mode. It can be also triggered by <code>-u</code> option. Important part is that globally turning on <code>utf8</code> window option in tmux configuration doesn't enforce UTF-8 mode.

musl has locale system since v1.1.4, it was incomplete and experimental, but I'm not sure how it is now. The thing is it's not leveraged by AL and by default you have no <code>LC_*</code> variables set. In musl built-in default is <code>C.UTF-8</code>, so we can simply create one file to set <code>LC_CTYPE</code> to such default value and it will satisfy tmux check:

{{Cat|/etc/profile.d/locale.sh|export LC_CTYPE{{=}}C.UTF-8
}}

Possible alternative is to alias <code>tmux</code> to <code>tmux -u</code>, but it seems clunky.

=== Disk ===

==== Set up RAID1 on two devices ====

<pre>
# install package
apk add mdadm

# load "raid1" module during boot (not really needed if you perform further steps)
echo raid1 >>/etc/modules

# create RAID1 array on two whole disks with 1MB data offset
mdadm --create --level=1 --raid-devices=2 --data-offset=1M /dev/md0 /dev/sda /dev/sdb

# preserve original example mdadm.conf
mv /etc/mdadm.conf{,.orig}

# save current setup into configuration file
# (usually people do not use -v, but it's more readable)
mdadm --detail -v --scan >/etc/mdadm.conf

# add raid devices starting to autostart
rc-update add mdadm-raid

# add raid devices monitoring to autostart
rc-update add mdadm

# start raid devices monitoring now
/etc/init.d/mdadm start

# following steps are needed if you want to support RAID early during boot

# add "raid" to features (space-separated values)
vi /etc/mkinitfs/mkinitfs.conf

# rebuild /boot/initramfs-grsec
mkinitfs

# add "raid1" to modules (comma-separated values)
vi /etc/update-extlinux.conf

# update extlinux
update-extlinux
</pre>

==== Install smartctl and smartd ====

<pre>
# install package
apk add smartmontools

# comment DEVICESCAN and uncomment DEVICESCAN -R 194 -R 231 -I 9
# to get meaningful and useful raw temperature in syslog
vi /etc/smartd.conf

# add smartd service to autostart
rc-update add smartd

# start the service now
/etc/init.d/smartd start
</pre>

=== Sensors ===

==== lm_sensors ====

<pre>
# install package
apk add lm_sensors

# install package for detecting sensors (if needed) - installs perl too
apk add lm_sensors-detect

# load module required for detecting sensors
modprobe i2c-dev

# detect sensors (skip scanning Super I/O, IPMI, ISA if you're on grsec)
sensors-detect

# after detecting sensors you can remove perl (if you don't need it)
apk del perl
</pre>

===== Problems =====

<ol>
<li><code>sensors-detect</code> command created <code>/etc/modules-load.d/lm_sensors.conf</code> file, but its first line is a comment, which leads to following message during boot
<pre>
modprobe: ERROR: missing parameters. See -h.
</pre>
It can be fixed by improving sed command in <code>/etc/init.d/modules</code> from <code>'s/\#.*//g'</code> to <code>'s/\#.*//g;/^[ \t]*$/d'</code> (deleting empty lines).

<li>It seems that nowadays you don't have to add <code>lm_sensors</code> to autostart, because in AL ''lm_sensors'' package is patched to create file <code>/etc/modules-load.d/lm_sensors.conf</code> (files in this directory are inspected by <code>/etc/init.d/modules</code>). <code>/etc/init.d/lm_sensors</code> seems in fact superfluous and it also doesn't work
<pre>
* /etc/conf.d/lm_sensors does not exist, try running sensors-detect
* ERROR: lm_sensors failed to start
</pre>
because it expects old file (<code>/etc/conf.d/lm_sensors</code>), which is no longer provided.
</ol>

{{todo|Report both issues on alpine-devel ML.}}

=== Mail ===

I don't need my own real mail server (as it's kind of PITA to set it up properly nowadays). Simple MTA is good enough. In the old days I used ssmtp, but it stopped being maintained (apparently debian devs maintain it now), so I switched to msmtp.

==== msmtp ====

After installing ''msmtp'' package, you need to create configuration file in your home directory. You can find example for Zoho Mail account.

{{Cat|~/.msmtprc|defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
auth on
port 587

account yourname@zoho.com
from yourname@zoho.com
user yourname@zoho.com
host smtp.zoho.com

account default : yourname@zoho.com
}}

You'll be asked for password every time mail is sent.

===== Problems =====

If you use gmail, then it's no longer that simple. After changing each zoho to gmail in above exemplary configuration, you still won't be able to send any mail. You'll get:

<pre>msmtp: server message: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=...> Please log in via your web browser and then try again.
msmtp: server message: 534-5.7.14 Learn more at
msmtp: server message: 534-5.7.14 https://support.google.com/mail/answer/78754 ...
</pre>

and you'll receive e-mail titled "Sign-in attempt prevented".

You have to [https://www.google.com/settings/security/lesssecureapps turn on less secure apps] if you want to deal with it. If you're using 2-step verification, then you'll have to [https://security.google.com/settings/security/apppasswords add app password for msmtp].

User:Przemoc/Notes

2016-04-18T22:05:00Z

Przemoc: AL 3.3.3: Console

I finally installed AL and I'm poking it a bit. Here you can find some notes regarding this experience. They should be helpful, but please use them with caution. I may add some additional commentary sometimes. If you think there is a better way to perform some of mentioned here tasks, then don't hesitate to notify me about it. Top-level headings denotes AL version that was used. Backward and forward compatibility is possible, but not tested.

__TOC__

== Alpine Linux 3.3.3 ==

=== Shell ===

Even though I always try to write POSIX sh-compliant scripts, I like to have <code>bash</code> as my default shell, because it's quite handy. Being able to write for instance quick <code>diff -u <(COMMAND1) <(COMMAND2)</code> (to compare output of two commands) or <code>mv FILE{,SUFFIX}</code> (to rename file by adding suffix) is very convenient.

==== Bash as default shell ====

AL doesn't have <code>vipw</code>, so root has to perform <code>vi /etc/passwd</code> himself to change the last field of root record (should be the first line in the file). You have to install ''util-linux'' package to get <code>chsh</code> utility.

==== Activate color prompt ====

Initial prompt: <code style="background-color:black;color:gray;">baytrail:~# </code>

{{cmd|mv /etc/profile.d/color_prompt{,.sh}
}}

Prompt after above change and relogin: <code style="background-color:black;color:gray;">baytrail [~]# </code>

==== Long history ====

I like to have long history, so I created following file:

{{Cat|/etc/profile.d/long_history.sh|export HISTSIZE{{=}}9999999
export HISTFILESIZE{{=}}$HISTSIZE
}}

=== Console ===

If you have physical access to screen connected to your machine with AL, it's nice to have properly configured console.

==== UTF-8 encoding ====

To have UTF-8 from OpenRC point of view, you have to set in <code>/etc/rc.conf</code>:
<pre>unicode="YES"</pre>
and add <code>/etc/init.d/termencoding</code> to autostart:
{{cmd|rc-update add termencoding}}
In fact it's mostly irrelevant (prove me wrong).

==== Font with polish letters ====

To be able to see polish letters, you have to install ''kbd-misc'' package, set in <code>/etc/conf.d/consolefont</code>:
<pre>consolefont="lat2-sun16.psfu.gz"
consoletranslation="8859-2_to_uni.trans"</pre>
and add <code>/etc/init.d/consolefont</code> to autostart:
{{cmd|rc-update add consolefont}}

If you don't like default <code>default8x16.psf.gz</code> font, then use <code>lat2-16.psfu.gz</code> instead. If you're comfortable with lower letter height, then I suggest using <code>lat2-14.psfu.gz</code>, which is still readable, yet on my 1920x1200 display increases LINES number from 75 to 85.

=== Disk ===

==== Set up RAID1 on two devices ====

<pre>
# install package
apk add mdadm

# load "raid1" module during boot (not really needed if you perform further steps)
echo raid1 >>/etc/modules

# create RAID1 array on two whole disks with 1MB data offset
mdadm --create --level=1 --raid-devices=2 --data-offset=1M /dev/md0 /dev/sda /dev/sdb

# preserve original example mdadm.conf
mv /etc/mdadm.conf{,.orig}

# save current setup into configuration file
# (usually people do not use -v, but it's more readable)
mdadm --detail -v --scan >/etc/mdadm.conf

# add raid devices starting to autostart
rc-update add mdadm-raid

# add raid devices monitoring to autostart
rc-update add mdadm

# start raid devices monitoring now
/etc/init.d/mdadm start

# following steps are needed if you want to support RAID early during boot

# add "raid" to features (space-separated values)
vi /etc/mkinitfs/mkinitfs.conf

# rebuild /boot/initramfs-grsec
mkinitfs

# add "raid1" to modules (comma-separated values)
vi /etc/update-extlinux.conf

# update extlinux
update-extlinux
</pre>

==== Install smartctl and smartd ====

<pre>
# install package
apk add smartmontools

# comment DEVICESCAN and uncomment DEVICESCAN -R 194 -R 231 -I 9
# to get meaningful and useful raw temperature in syslog
vi /etc/smartd.conf

# add smartd service to autostart
rc-update add smartd

# start the service now
/etc/init.d/smartd start
</pre>

=== Sensors ===

==== lm_sensors ====

<pre>
# install package
apk add lm_sensors

# install package for detecting sensors (if needed) - installs perl too
apk add lm_sensors-detect

# load module required for detecting sensors
modprobe i2c-dev

# detect sensors (skip scanning Super I/O, IPMI, ISA if you're on grsec)
sensors-detect

# after detecting sensors you can remove perl (if you don't need it)
apk del perl
</pre>

===== Problems =====

<ol>
<li><code>sensors-detect</code> command created <code>/etc/modules-load.d/lm_sensors.conf</code> file, but its first line is a comment, which leads to following message during boot
<pre>
modprobe: ERROR: missing parameters. See -h.
</pre>
It can be fixed by improving sed command in <code>/etc/init.d/modules</code> from <code>'s/\#.*//g'</code> to <code>'s/\#.*//g;/^[ \t]*$/d'</code> (deleting empty lines).

<li>It seems that nowadays you don't have to add <code>lm_sensors</code> to autostart, because in AL ''lm_sensors'' package is patched to create file <code>/etc/modules-load.d/lm_sensors.conf</code> (files in this directory are inspected by <code>/etc/init.d/modules</code>). <code>/etc/init.d/lm_sensors</code> seems in fact superfluous and it also doesn't work
<pre>
* /etc/conf.d/lm_sensors does not exist, try running sensors-detect
* ERROR: lm_sensors failed to start
</pre>
because it expects old file (<code>/etc/conf.d/lm_sensors</code>), which is no longer provided.
</ol>

{{todo|Report both issues on alpine-devel ML.}}

=== Mail ===

I don't need my own real mail server (as it's kind of PITA to set it up properly nowadays). Simple MTA is good enough. In the old days I used ssmtp, but it stopped being maintained (apparently debian devs maintain it now), so I switched to msmtp.

==== msmtp ====

After installing ''msmtp'' package, you need to create configuration file in your home directory. You can find example for Zoho Mail account.

{{Cat|~/.msmtprc|defaults
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile ~/.msmtp.log
auth on
port 587

account yourname@zoho.com
from yourname@zoho.com
user yourname@zoho.com
host smtp.zoho.com

account default : yourname@zoho.com
}}

You'll be asked for password every time mail is sent.

===== Problems =====

If you use gmail, then it's no longer that simple. After changing each zoho to gmail in above exemplary configuration, you still won't be able to send any mail. You'll get:

<pre>msmtp: server message: 534-5.7.14 <https://accounts.google.com/signin/continue?sarp=1&scc=1&plt=...> Please log in via your web browser and then try again.
msmtp: server message: 534-5.7.14 Learn more at
msmtp: server message: 534-5.7.14 https://support.google.com/mail/answer/78754 ...
</pre>

and you'll receive e-mail titled "Sign-in attempt prevented".

You have to [https://www.google.com/settings/security/lesssecureapps turn on less secure apps] if you want to deal with it. If you're using 2-step verification, then you'll have to [https://security.google.com/settings/security/apppasswords add app password for msmtp].

User:Przemoc/Notes

2016-04-18T19:50:08Z

Przemoc: AL 3.3.3: Mail

User:Przemoc/Notes

2016-04-17T18:10:14Z

Przemoc: Use Cat and cmd templates (but not everywhere, because cmd requires too much escaping to be convenient).

User:Przemoc/Notes

2016-04-15T22:56:44Z

Przemoc: AL 3.3.3: Sensors

User:Przemoc/Notes

2016-04-15T21:16:07Z

Przemoc: AL 3.3.3: Disk/RAID1

User:Przemoc/Notes

2016-04-15T20:37:45Z

Przemoc: AL 3.3.3: Disk/smartd

User:Przemoc

2016-04-15T20:20:55Z

Przemoc: Link my notes

[[User:Przemoc/Notes]]

User:Przemoc/Notes

2016-04-15T20:19:05Z

Przemoc: AL 3.3.3: Shell