alpine issueshttps://gitlab.alpinelinux.org/groups/alpine/-/issues2021-05-03T15:37:11Zhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12647Run Alpine on Raspberry PI 4B with PXE boot from FreeNAS NFS & TFTP2021-05-03T15:37:11ZEdvard FilistovičRun Alpine on Raspberry PI 4B with PXE boot from FreeNAS NFS & TFTPHello,
I want to run Alpine on Raspberry PI 4B with PXE boot from FreeNAS NFS & TFTP
I have my DHCP Service on my core router. TrueNAS with tftp & nfs on it. I want to run alpine linux on this configuration, and build in a future k8s o...Hello,
I want to run Alpine on Raspberry PI 4B with PXE boot from FreeNAS NFS & TFTP
I have my DHCP Service on my core router. TrueNAS with tftp & nfs on it. I want to run alpine linux on this configuration, and build in a future k8s or k3s cluster. my PI are powered from PoE, and I have 12 devices in my PI rack.
I browse a lot of google, but still can't find a solution. I assume also to have persistence storage on NFS, and some shared storage for kubernetes on NFS.
Edhttps://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10474[Installation-Wiki FIXME-2 (data disk mode)] allow selecting new data disk f...2021-05-20T10:32:08ZSPO[Installation-Wiki FIXME-2 (data disk mode)] allow selecting new data disk for configs[ Alpine's "Installation" page covers the Alpinelinux disk modes. (https://wiki.alpinelinux.org/wiki/Installation)
However, it still has to refer to two manual `setup-alpine` "FIXME" workarounds, to cover the basic installation options....[ Alpine's "Installation" page covers the Alpinelinux disk modes. (https://wiki.alpinelinux.org/wiki/Installation)
However, it still has to refer to two manual `setup-alpine` "FIXME" workarounds, to cover the basic installation options. ]
=> In `setup-alpine`, after chhosing the "data disk mode", please allow selecting the just configured data disk, to also store configs.
----
From the wiki:
[FIXME-2: Setup-alpine can not yet configure to store lbu configs to the "data disk" after selecting to use one.
It's still necessary to
* first select to save configs to "none" in setup-alpine (the new data partition is not listed), and
* to manually edit /etc/lbu/lbu.conf to set e.g. LBU_MEDIA=sdXY,
* execute a corresponding echo "/dev/sdXY /media/sdXY vfat rw 0 0" >> /etc/fstab afterwards, and
* save the config with lbu commit to have the partition (here, dubbed as sdXY) mounted when booting.
]https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10473[Installation-Wiki FIXME-1 (diskless mode)] config/package cache on *internal...2021-05-20T10:42:44ZSPO[Installation-Wiki FIXME-1 (diskless mode)] config/package cache on *internal* disk[ Alpine's "Installation" page covers the Alpinelinux disk modes. (https://wiki.alpinelinux.org/wiki/Installation) However, it still has to refer to two manual `setup-alpine` "FIXME" workarounds, to cover the basic installation options. ...[ Alpine's "Installation" page covers the Alpinelinux disk modes. (https://wiki.alpinelinux.org/wiki/Installation) However, it still has to refer to two manual `setup-alpine` "FIXME" workarounds, to cover the basic installation options. ]
=> In `setup-alpine`, please also show internal partitions in the selection for local configs and package cache in the "diskless" operation mode.
---
From the wiki:
[FIXME-1: Storing local configs and the package cache on an internal disk still requires some manual steps to have the partition listed, i.e. making a /etc/fstab entry, mountpoint, and mount *before* running setup-alpine. And requires to manually commit this configuration to disk afterwards.]
The manual workaround steps are maintained at:
https://wiki.alpinelinux.org/wiki/Alpine_local_backup#Saving_and_loading_ISO_image_customizationshttps://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/issues/11Formalize what level should be logged from services2021-05-01T04:50:54ZLeoFormalize what level should be logged from servicesMy idea is:
## Error
Things that should be investigated and rectified.
Examples:
1. GitLab API call fails
## Warn
when something prevents expected operation but it should be fixed at the source
or there is no way to reasonably fix....My idea is:
## Error
Things that should be investigated and rectified.
Examples:
1. GitLab API call fails
## Warn
when something prevents expected operation but it should be fixed at the source
or there is no way to reasonably fix.
Examples:
1. In AutoMaintainer() the API call to get the APKBUILD works but the APKBUILD
itself has no maintainer to be extracted.
2. In AutoMaintainer() if we get more than 1 maintainer we cannot assign as
Alpine Linux does not have GitLab gold so we just abort
## Info
something happened during normal operation but it is important that the admin
knows.
Example:
1. A service started
2. A service did its job (like AutoMaintainer assigning someone as maintainer)
3. A service finishedhttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12642community/pass-contrib: passmenu not usable without pinentry with gui2021-04-28T20:09:12ZJuliancommunity/pass-contrib: passmenu not usable without pinentry with guiWhen running `passmenu` without `pinentry-gtk` or `pinentry-qt`, no dialog opens to enter the password to unlock the key. `pinentry`, which is a dependency of `gnupg`, does not come with a gui.When running `passmenu` without `pinentry-gtk` or `pinentry-qt`, no dialog opens to enter the password to unlock the key. `pinentry`, which is a dependency of `gnupg`, does not come with a gui.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12628Raspi 4B: PXE: Cannot enable cgroups2021-04-22T17:55:47ZopvielRaspi 4B: PXE: Cannot enable cgroupsI hope this is the right place.
The Raspi runs a nonstandard bootloader, which takes its kernel boot arguments via the textfile `/boot/cmdline.txt`
When booting via PXE, the `cgroups` settings in that file get ignored.
The following c...I hope this is the right place.
The Raspi runs a nonstandard bootloader, which takes its kernel boot arguments via the textfile `/boot/cmdline.txt`
When booting via PXE, the `cgroups` settings in that file get ignored.
The following cmdline.txt works fine for a PXE boot:
`modules=loop,squashfs console=ttyS0,115200 ip=dhcp alpine_repo=http://10.0.2.10/alpine/v3.13/main apkovl=http://10.0.2.10/overlay.tar.gz`
Adding the three following options however has no effect:
`cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory`
Setting those arguments in a local sys-mode install works fine.
A workaround would be greatly appreciated, and I am happy to be available for testing.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12623pidfile not readable by any user for chronyd and syslog2022-01-21T18:35:12ZTom Lebreuxpidfile not readable by any user for chronyd and syslog# Details
The pidfile for both chronyd and syslog are not readable by all users.
For chronyd, the file is in the `/run/chronyd/` directory which is 0640.
```sh
soju:~/aports/testing/openrc-exporter$ sudo ls -ld /run/chrony/
drwxr-x---...# Details
The pidfile for both chronyd and syslog are not readable by all users.
For chronyd, the file is in the `/run/chronyd/` directory which is 0640.
```sh
soju:~/aports/testing/openrc-exporter$ sudo ls -ld /run/chrony/
drwxr-x--- 2 chrony chrony 80 Apr 20 08:09 /run/chrony/
soju:~/aports/testing/openrc-exporter$ sudo ls -ld /run/chrony/chronyd.pid
-rw-r--r-- 1 root root 5 Apr 20 08:09 /run/chrony/chronyd.pid
```
For syslog, the file `/run/syslogd.pid` is 0640.
```sh
soju:~/aports/testing/openrc-exporter$ sudo ls -ld /run/syslogd.pid
-rw-r----- 1 root wheel 5 Aug 17 2020 /run/syslogd.pid
```
# Reasoning
I am working on a Prometheus exporter for OpenRC ([openrc-exporter]). I would like the exporter
to run as non-root. This is possible as long as the pidfiles are readable by everyone. Otherwise,
the function [rc_service_daemons_crashed] returns true for pids that cannot be read. So right now,
my exporter mistakenly reports that the daemons have crashed for chronyd and syslog.
[openrc-exporter]: https://sr.ht/~tomleb/openrc-exporter/
[rc_service_daemons_crashed]: https://github.com/OpenRC/openrc/blob/2355f1a3f2a4fd62cac6d9af0e94c8731acd4c0f/src/librc/rc.h.in#L316
# Version information
I am currently running alpine 3.12 and haven't tested in 3.13/edge but the APKBUILD/initd files seems the same.
Can this be considered as a bug that should be fixed?
Thankshttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12622BIND 9.16.11 and edge version are crashing when when running from a container...2021-04-20T19:37:02ZRicardo Rodriguez ValdezBIND 9.16.11 and edge version are crashing when when running from a container and using ACL to permit hostsWhen running from VM or runnung from alpine BIND 9.16.6 (Stable Release) <id:25846cf> it works.
If I use the BIND 9.16.11 (Stable Release) <id:9ff601b> or 9.16.11-r2 it does not work from the container, but it works if I remove the perm...When running from VM or runnung from alpine BIND 9.16.6 (Stable Release) <id:25846cf> it works.
If I use the BIND 9.16.11 (Stable Release) <id:9ff601b> or 9.16.11-r2 it does not work from the container, but it works if I remove the permit-update-host; ACL, or insert the ip directly without use ACL it works. but in previus versions was working.
`podman run --cap-add CAP_NET_RAW -it --rm d --name test-bind-dns bind-dns bash`
`named -u named -f -g -c /etc/bind/named.conf`
```
named.conf
include "/etc/bind/rndc.key";
include "/var/bind/dynamic/update.key";
acl "trusted" {
${_custom_trusted_nets}
};
acl "permit-update-hosts" {
192.168.1.10;
};
acl "permit-transfer-hosts" {
};
zone "dom.local" IN {
type master;
file "/var/bind/master/dom.local.zone";
allow-update { key rndc-key; key ddns; key update; permit-update-hosts; };
};
```
Here the error output when running from a container using podman:
```
20-Apr-2021 19:21:51.613 BIND 9 is maintained by Internet Systems Consortium,
20-Apr-2021 19:21:51.613 Inc. (ISC), a non-profit 501(c)(3) public-benefit
20-Apr-2021 19:21:51.613 corporation. Support and training for BIND 9 are
20-Apr-2021 19:21:51.613 available at https://www.isc.org/support
20-Apr-2021 19:21:51.613 ----------------------------------------------------
20-Apr-2021 19:21:51.613 found 16 CPUs, using 16 worker threads
20-Apr-2021 19:21:51.613 using 16 UDP listeners per interface
20-Apr-2021 19:21:51.631 using up to 21000 sockets
20-Apr-2021 19:21:51.634 loading configuration from '/etc/bind/named.conf'
20-Apr-2021 19:21:51.636 reading built-in trust anchors from file '/etc/bind/bind.keys'
20-Apr-2021 19:21:51.637 statistics channel listening on ::1#8053
20-Apr-2021 19:21:51.637 statistics channel listening on 127.0.0.1#8053
20-Apr-2021 19:21:51.637 using default UDP/IPv4 port range: [32768, 60999]
20-Apr-2021 19:21:51.637 using default UDP/IPv6 port range: [32768, 60999]
20-Apr-2021 19:21:51.639 listening on IPv4 interface lo, 127.0.0.1#53
20-Apr-2021 19:21:51.647 listening on IPv4 interface tap0, 10.0.2.100#53
20-Apr-2021 19:21:51.654 listening on IPv6 interface lo, ::1#53
20-Apr-2021 19:21:51.661 listening on IPv6 interface tap0, fe80::9009:e1ff:fe5f:2739%2#53
20-Apr-2021 19:21:51.689 generating session key for dynamic DNS
20-Apr-2021 19:21:51.690 sizing zone task pool based on 7 zones
Segmentation fault (core dumped)
```
Here the output when running from a container using podman with the host ACL:
```
20-Apr-2021 19:32:59.102 ----------------------------------------------------
20-Apr-2021 19:32:59.102 BIND 9 is maintained by Internet Systems Consortium,
20-Apr-2021 19:32:59.102 Inc. (ISC), a non-profit 501(c)(3) public-benefit
20-Apr-2021 19:32:59.102 corporation. Support and training for BIND 9 are
20-Apr-2021 19:32:59.102 available at https://www.isc.org/support
20-Apr-2021 19:32:59.102 ----------------------------------------------------
20-Apr-2021 19:32:59.102 found 16 CPUs, using 16 worker threads
20-Apr-2021 19:32:59.102 using 16 UDP listeners per interface
20-Apr-2021 19:32:59.119 using up to 21000 sockets
20-Apr-2021 19:32:59.124 loading configuration from '/etc/bind/named.conf'
20-Apr-2021 19:32:59.126 reading built-in trust anchors from file '/etc/bind/bind.keys'
20-Apr-2021 19:32:59.134 statistics channel listening on ::1#8053
20-Apr-2021 19:32:59.134 statistics channel listening on 127.0.0.1#8053
20-Apr-2021 19:32:59.134 using default UDP/IPv4 port range: [32768, 60999]
20-Apr-2021 19:32:59.134 using default UDP/IPv6 port range: [32768, 60999]
20-Apr-2021 19:32:59.136 listening on IPv4 interface lo, 127.0.0.1#53
20-Apr-2021 19:32:59.143 listening on IPv4 interface tap0, 10.0.2.100#53
20-Apr-2021 19:32:59.150 listening on IPv6 interface lo, ::1#53
20-Apr-2021 19:32:59.160 listening on IPv6 interface tap0, fe80::9009:e1ff:fe5f:2739%2#53
20-Apr-2021 19:32:59.182 generating session key for dynamic DNS
20-Apr-2021 19:32:59.182 sizing zone task pool based on 7 zones
20-Apr-2021 19:32:59.184 zone 'dom.local' allows unsigned updates from remote hosts, which is insecure
20-Apr-2021 19:32:59.184 none:99: 'max-cache-size 90%' - setting to 35638MB (out of 39598MB)
20-Apr-2021 19:32:59.287 set up managed keys zone for view _default, file '/var/bind/dynamic/managed-keys.bind'
20-Apr-2021 19:32:59.287 automatic empty zone: 10.IN-ADDR.ARPA
```https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10744Cryptographic module abstraction2022-12-21T19:37:21ZAriadne Conillariadne@ariadne.spaceCryptographic module abstractionAt present, apk-tools makes direct use of libcrypto to do signature verification, signing, etc.
It would be nice to factor this out so that we can eventually drop the libcrypto dependency with something better.
Similarly, it would be n...At present, apk-tools makes direct use of libcrypto to do signature verification, signing, etc.
It would be nice to factor this out so that we can eventually drop the libcrypto dependency with something better.
Similarly, it would be nice to replace our use of libssl with libtls in our libfetch fork, for the same reason: multiple libtls implementations exist, and we can just use whatever one we want (for now, libtls-standalone, but later perhaps libtls-bearssl instead.)v3.1https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10743lbu commit fails storing correct permissions on lbu include directories2022-08-02T19:17:39Zmacmpilbu commit fails storing correct permissions on lbu include directoriesI'm running Alpine 3.13 on disk-less setup and installed mpd.\
I need to save/restore some music files within `/var/lib/mpd/music`\
`/var/lib/mpd/music` is created at mpd install with mpd:audio\
If I add a file root:root as `/var/lib/mpd...I'm running Alpine 3.13 on disk-less setup and installed mpd.\
I need to save/restore some music files within `/var/lib/mpd/music`\
`/var/lib/mpd/music` is created at mpd install with mpd:audio\
If I add a file root:root as `/var/lib/mpd/music/test` and then `lbu include /var/lib/mpd/music/test` and `lbu commit -d`, then at reboot `/var/lib/mpd` and `/var/lib/mpd/music` become root:root and original permissions are altered.
Any suggested workaround?
Note: this looks similar to older issue https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/1241https://gitlab.alpinelinux.org/alpine/aports/-/issues/12607libguestfs: virt-sparsify missing?2021-09-24T09:37:39ZJosep Maria Viñolas Auquerlibguestfs: virt-sparsify missing?Hi, while building libguestfs the packages created are missing some utilities found in libguestfs src as sparsify (virt-sparsify).
Am I missing something or they can't be built on alpine? It seems that some perl modules are missing to bu...Hi, while building libguestfs the packages created are missing some utilities found in libguestfs src as sparsify (virt-sparsify).
Am I missing something or they can't be built on alpine? It seems that some perl modules are missing to build some virt-* tools.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12605gdm: fails to wake up after locking2023-01-29T15:58:55ZDylan Van Asschegdm: fails to wake up after locking# Description
I upgraded to edge to have GNOME 40 and when my desktop is now locked (manually or automatically after X minutes), I cannot wake it up anymore. The screen stays blank. If I switch to another tty using CTRL + F-key, the scr...# Description
I upgraded to edge to have GNOME 40 and when my desktop is now locked (manually or automatically after X minutes), I cannot wake it up anymore. The screen stays blank. If I switch to another tty using CTRL + F-key, the screen turns on and shows me a prompt. If I switch back to the original tty, the GDM greeter is shown.
# What's happening
Pressing a key or moving the mouse doesn't do anything when the desktop is locked.
# What's supposed to happen
Pressing a key or moving the mouse wakes up the desktop and shows the GDM greeter.
# Steps to reproduce
1. Lock the screen
2. Wait until the screen enter low power mode
3. Try to wake it up by moving the mouse or pressing a key on the keyboard.
# Environment
- Alpine Linux edge
- Intel integrated GPU (Mesa Intel® UHD Graphics 630 (CML GT2))
- GNOME 40.0 on Wayland
- GDM 40.0
# Logs
[greeter.log](/uploads/1b0a415a8a2978b4011bb906bed51295/greeter.log)Rasmus Thomsenoss@cogitri.devRasmus Thomsenoss@cogitri.devhttps://gitlab.alpinelinux.org/alpine/abuild/-/issues/10029Let python programs, which install files to /usr/lib/python3.X/, automaticall...2021-05-15T20:46:04ZOliver SmithLet python programs, which install files to /usr/lib/python3.X/, automatically depend on that python versionThis makes it easier to automatically find packages that need to be rebuilt after python was upgraded.This makes it easier to automatically find packages that need to be rebuilt after python was upgraded.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12587Fail2ban: ERROR unexpected EOF while parsing (<string>, line 1)2021-04-08T08:42:58ZEuro DomeniiFail2ban: ERROR unexpected EOF while parsing (<string>, line 1)Full error description:
```
alpin:~# cat /etc/alpine-release
3.13.4
alpin:~# apk version fail2ban
Installed: Available:
fail2ban-0.11.1-r4 = 0.11.1-r4
alpin:~# fail2ban-client -i
Fa...Full error description:
```
alpin:~# cat /etc/alpine-release
3.13.4
alpin:~# apk version fail2ban
Installed: Available:
fail2ban-0.11.1-r4 = 0.11.1-r4
alpin:~# fail2ban-client -i
Fail2Ban v0.11.1 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.
fail2ban> status sshd
2021-04-07 23:00:07,800 fail2ban [454]: ERROR unexpected EOF while parsing (<string>, line 1)
```
Also, encountered in 3.10. Latest working version was 3.7 ( maybe due to the fact that was using python2).
UPDATE:
I've used to test on 3.10 and fail2ban wasn't banning and I've wrongly assumed that 3.13 fails also, if _I've got fail2ban-client -i [474]: ERROR unexpected EOF while parsing (<string>, line 1)_
In fact, 3.13 works
```
# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 2
| `- File list: /var/log/messages
`- Actions
|- Currently banned: 1
|- Total banned: 2
`- Banned IP list: XX.YY.ZZ.WW
```
But there's an interface error.
```
~ # fail2ban-client -i
Fail2Ban v0.11.1 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.
fail2ban> stauts sshd
2021-04-08 08:35:55,028 fail2ban [474]: ERROR unexpected EOF while parsing (<string>, line 1)
```
So, there's a bug, but with low priority and without any impact on blocking functionality.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12582targetcli:adding missing modules for Raspberry PI2021-04-12T16:43:08ZFrancesco Colistatargetcli:adding missing modules for Raspberry PICan we the needed targetcli modules ``target_core_mod`` and ``iscsi_target_mod`` for Raspberry PI be built?`
```
~# apk add targetcli
fetch http://uk.alpinelinux.org/alpine/v3.13/main/aarch64/APKINDEX.tar.gz
fetch http://uk.alpinelinux....Can we the needed targetcli modules ``target_core_mod`` and ``iscsi_target_mod`` for Raspberry PI be built?`
```
~# apk add targetcli
fetch http://uk.alpinelinux.org/alpine/v3.13/main/aarch64/APKINDEX.tar.gz
fetch http://uk.alpinelinux.org/alpine/v3.13/community/aarch64/APKINDEX.tar.gz
(1/43) Installing libffi (3.3-r2)
(2/43) Installing gdbm (1.19-r0)
(3/43) Installing sqlite-libs (3.34.1-r0)
(4/43) Installing python3 (3.8.8-r0)
(5/43) Installing py3-six (1.15.0-r0)
(6/43) Installing py3-configobj (5.0.6-r7)
(7/43) Installing py3-urwid (2.1.2-r0)
(8/43) Installing py3-parsing (2.4.7-r1)
(9/43) Installing py3-configshell (1.1.26-r1)
(10/43) Installing py3-ethtool (0.14-r4)
(11/43) Installing py3-ipaddr (2.2.0-r5)
(12/43) Installing udev-init-scripts (34-r0)
Executing udev-init-scripts-34-r0.post-install
(13/43) Installing udev-init-scripts-openrc (34-r0)
(14/43) Installing eudev-libs (3.2.9-r3)
(15/43) Installing zstd-libs (1.4.5-r3)
(16/43) Installing kmod-libs (28-r0)
(17/43) Installing eudev (3.2.9-r3)
(18/43) Installing eudev-openrc (3.2.9-r3)
(19/43) Installing py3-udev (0.22-r0)
(20/43) Installing py3-rtslib (2.1_p72-r0)
(21/43) Installing py3-simpleparse (2.2.2-r0)
(22/43) Installing libintl (0.20.2-r2)
(23/43) Installing libmount (2.36.1-r1)
(24/43) Installing glib (2.66.7-r1)
(25/43) Installing py3-dbus (1.2.16-r2)
(26/43) Installing libxau (1.0.9-r0)
(27/43) Installing libbsd (0.10.0-r0)
(28/43) Installing libxdmcp (1.1.3-r0)
(29/43) Installing libxcb (1.14-r1)
(30/43) Installing libx11 (1.7.0-r0)
(31/43) Installing libxext (1.3.4-r0)
(32/43) Installing libxrender (0.9.10-r3)
(33/43) Installing brotli-libs (1.0.9-r3)
(34/43) Installing libpng (1.6.37-r1)
(35/43) Installing freetype (2.10.4-r1)
(36/43) Installing fontconfig (2.13.1-r3)
(37/43) Installing pixman (0.40.0-r2)
(38/43) Installing cairo (1.16.0-r2)
(39/43) Installing cairo-gobject (1.16.0-r2)
(40/43) Installing gobject-introspection (1.66.1-r0)
(41/43) Installing py3-gobject3 (3.38.0-r0)
(42/43) Installing targetcli (2.1.53-r0)
(43/43) Installing targetcli-openrc (2.1.53-r0)
Executing busybox-1.32.1-r5.trigger
Executing eudev-3.2.9-r3.trigger
OK: 117 MiB in 156 packages
~# rc-service targetcli start
* Caching service dependencies ... [ ok ]
* Starting targetcli ...
modprobe: module configfs not found in modules.dep
modprobe: module target_core_mod not found in modules.dep
modprobe: module iscsi_target_mod not found in modules.dep
mount: mounting none on /sys/kernel/config failed: Resource busy
b'modprobe: module target_core_mod not found in modules.dep\n' [ !! ]
* ERROR: targetcli failed to start
```
I dont' know if this has already been considered and not worthy to be added.
Thanks.
.: Francescohttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12557Handling per-network interface specific services dependancies2021-03-30T22:11:18ZDermot BradleyHandling per-network interface specific services dependanciesCurrently there is no standard way to handle init.d services that depend on specific network interfaces.
However if the Openssh server is configured (in /etc/ssh/sshd_config) to bind to one or more specific IP addresses (via ListenAddre...Currently there is no standard way to handle init.d services that depend on specific network interfaces.
However if the Openssh server is configured (in /etc/ssh/sshd_config) to bind to one or more specific IP addresses (via ListenAddress) the /etc/init.d/sshd script detects this and indicates:
```
You are binding an interface in ListenAddress statement in your sshd_config!
You must add rc_need="net.FOO" to your /etc/conf.d/sshd
where FOO is the interface(s) providing the following address(es):
```
For now, as I am using static IP addressing, I have created multiple scripts in /etc/init.d, one per interface, derived from /etc/init.d/net-online that check that the interface is up, and have added a entry to /etc/conf.d/sshd:
```
rc_need="net-interface-<INTERFACENAME>"
```
which the relevant script then provides. I have also locally added such rc_need entries in the conf.d files for other network daemons that I'm binding to specific network interfaces and it now all works as expected.
This approach obviously works in the situation of knowing which interfaces will exist ahead of time and setting up the init.d scripts for them, and so it doesn't cater for "unknown" dynamic interfaces (i.e. different machines with different numbers or names of interfaces).
In the longer term @kaniini's and @skarnet's vision of s6 and ifupdown-ng would likely give the flexibility to provide per interface services dependancies (indeed per-SSID in the case of WiFi).
In the short to medium term I'm wondering how this issue can be addressed. The fact that the Openssh server package detects the need for a per-interface dependancy implies someone else previously thought of this issue.https://gitlab.alpinelinux.org/alpine/aports/-/issues/12556Could JRuby depend on Jansi 2.x?2021-03-30T09:35:00Zomniomni+alpine@hack.orgCould JRuby depend on Jansi 2.x?Hi, I noticed that our `java-jansi-native` is very old, from 2013, and there exist a few more recent releases, the last from 2018.
However, upstream readme says "The Jansi Native library is deprecated and is now embedded inside Jansi 2....Hi, I noticed that our `java-jansi-native` is very old, from 2013, and there exist a few more recent releases, the last from 2018.
However, upstream readme says "The Jansi Native library is deprecated and is now embedded inside Jansi 2.x".
Should Jansi 2.x (currently 2.3.2) be packaged and `jruby` depend on that instead? I guess that's why `java-jansi-native` is there and would then be removed.Jakub JirutkaJakub Jirutkahttps://gitlab.alpinelinux.org/alpine/aports/-/issues/12554discover-backend-apk: does not find all system updates2021-03-28T12:48:44ZAriadne Conillariadne@ariadne.spacediscover-backend-apk: does not find all system updatesWhen updating the system with Discover, some updates are missed.
For example, Discover says my system is up to date, but `apk list -u` shows 3 pending updates:
```
$ apk list -u
alsa-lib-dev-1.2.4-r2 x86_64 {alsa-lib} (LGPL-2.1-or-late...When updating the system with Discover, some updates are missed.
For example, Discover says my system is up to date, but `apk list -u` shows 3 pending updates:
```
$ apk list -u
alsa-lib-dev-1.2.4-r2 x86_64 {alsa-lib} (LGPL-2.1-or-later) [upgradable from: alsa-lib-dev-1.2.3.2-r1]
kde-cli-tools-5.21.3-r0 x86_64 {kde-cli-tools} ((GPL-2.0-only OR GPL-3.0-only) AND GPL-2.0-or-later AND GPL-2.0-only AND LGPL-2.1-only) [upgradable from: kde-cli-tools-5.20.5-r1]
alsa-lib-1.2.4-r2 x86_64 {alsa-lib} (LGPL-2.1-or-later) [upgradable from: alsa-lib-1.2.3.2-r1]
```https://gitlab.alpinelinux.org/alpine/aports/-/issues/12553Enabling IPv6 in Docker via daemon.json breaks IPv6 connectivity on the host2022-10-16T11:55:37ZMax GashkovEnabling IPv6 in Docker via daemon.json breaks IPv6 connectivity on the host// This is my first time reporting bug to Alpine and I'm terribly sorry if I'm missing something.
Enabling IPv6 in Docker engine via daemon.json breaks IPv6 connectivity. To be exact, Docker removes default IPv6 route upon start.
Envir...// This is my first time reporting bug to Alpine and I'm terribly sorry if I'm missing something.
Enabling IPv6 in Docker engine via daemon.json breaks IPv6 connectivity. To be exact, Docker removes default IPv6 route upon start.
Environment:
```
# cat /etc/alpine-release
3.13.3
# docker info |fgrep 'Server Version'
Server Version: 20.10.3
# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
hostname tpl-alpine-docker
iface eth0 inet6 manual
# cat /etc/docker/daemon.json
{
"ipv6": true,
"fixed-cidr-v6": "fd00::/80"
}
```
IPv6 route table before docker restart with the config above:
```
# ip -6 route show
2400:4153:xxxx:xxxx::/64 dev eth0 metric 256 expires 0sec
fe80::/64 dev eth0 metric 256
default via fe80::ae44:f2ff:fe66:c7d4 dev eth0 metric 1024 expires 0sec
multicast ff00::/8 dev eth0 metric 256
```
Table after docker restart:
```
# ip -6 route show
2400:4153:xxxx:xxxx::/64 dev eth0 metric 256 expires 0sec
fd00::/80 dev docker0 metric 256
fd00::/80 dev docker0 metric 1024
fe80::/64 dev eth0 metric 256
fe80::/64 dev docker0 metric 256
anycast 2400:4153:xxxx:xxxx:: dev eth0 metric 0
anycast fe80:: dev eth0 metric 0
multicast ff00::/8 dev eth0 metric 256
# ping6 google.com
PING google.com (2404:6800:400a:807::200e): 56 data bytes
ping6: sendto: Network unreachable
```
Network seems to be fixed after placing default route back, but to be perfectly frank I don't know IPv6 well enough to be sure that this is correct fix:
```
# ip -6 route replace default via fe80::ae44:f2ff:fe66:c7d4 dev eth0
# ping6 google.com
PING google.com (2404:6800:400a:808::200e): 56 data bytes
64 bytes from 2404:6800:400a:808::200e: seq=0 ttl=116 time=6.018 ms
```https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10472Not able to install in a AMD CPU based VPS (Alpine version: 3.13.2)2022-11-11T17:36:41ZFengying ZhaoNot able to install in a AMD CPU based VPS (Alpine version: 3.13.2)I tried to install alpine Linux in my VPS by following this [tutorial](https://wiki.alpinelinux.org/wiki/Replacing_non-Alpine_Linux_with_Alpine_remotely).
CPU info:
```
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64...I tried to install alpine Linux in my VPS by following this [tutorial](https://wiki.alpinelinux.org/wiki/Replacing_non-Alpine_Linux_with_Alpine_remotely).
CPU info:
```
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 23
Model: 49
Model name: AMD EPYC 7K62 48-Core Processor
Stepping: 0
CPU MHz: 2595.124
BogoMIPS: 5190.24
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
L3 cache: 16384K
NUMA node0 CPU(s): 0
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 arat
```
After using `dd` command and reboot, Alpine Linux can not work properly.
When I use a 64-bit os image (alpine-virt-3.13.2-x86_64.iso), the kernel panic immediately after rebooting:
![CleanShot_2021-03-23_at_18.21.38_2x](/uploads/f4b6141cbd4951a9f83f4a0b2a035c9b/CleanShot_2021-03-23_at_18.21.38_2x.png)
When I use a 32-bit os image (alpine-virt-3.13.2-x86.iso), I can log into the system, but all the build-in apps (apk, setup-alpine...) does not work properly:
![CleanShot_2021-03-23_at_18.31.21_2x](/uploads/f94bb5087ccf68d839c869c6b7e0b0b8/CleanShot_2021-03-23_at_18.31.21_2x.png)
![CleanShot_2021-03-23_at_18.33.59_2x](/uploads/69b790dd941c9893f087c617c3025013/CleanShot_2021-03-23_at_18.33.59_2x.png)
By the way I have another instance on the same VPS hosting provider with intel CPU, and I can install Alpine Linux to that VPS properly, so I guess the issue is caused by AMD CPU (or virtualization on AMD CPU?).