FreeRADIUS / freeradius-server

FreeRADIUS - A multi-protocol policy server.
http://freeradius.org
GNU General Public License v2.0
2.13k stars 1.08k forks source link

Docker images are not multi-architecture #2780

Open DomAmato opened 5 years ago

DomAmato commented 5 years ago

Issue type


Defect/Feature description

How to reproduce issue

Trying to use the docker image for freeradius on a raspberry pi leads to errors during build time:

exec user process caused "exec format error"

building the image locally fixed this issue.

There are multiple ways of creating multi-arch images and I am not sure how the current build gets deployed to docker hub. I have had success using dockers buildx cli extension

mcnewton commented 5 years ago

Thanks for the info. This is pretty low priority; it's easy enough to build the docker images on any system yourself. Current images are built on an x86 system with commands in the Makefile - see make docker. Patches welcome... though I'll try and look at it at some point if I have time.

shivamb commented 4 years ago

I would love to see this fix.

flisboac commented 3 years ago

@mcnewton an official image would still add a ton of value. Most ARM users (which is now rather common) won't customize the image in any way, so not having a build at ready would be an unnecessary barrier to adoption. I don't think this is "pretty low" in priority. Perhaps medium; or low, at most. But again, I lack the vision of the bigger picture in the project.

How would you estimate the effort to add support for ARM builds? Would it be possible to add CI infrastructure to build ARM images (perhaps with QEMU/etc, or buildx?)

mcnewton commented 3 years ago

Sure if you've got some magic to take all the high and medium items off our to-do lists, then this will jump up from being low priority. Otherwise, it stays where it is. I'm not disputing whether it's useful or not.

I have no estimate on the effort involved, as I've not looked at it.

As always, pull requests welcome.

arr2036 commented 3 years ago

Agreed. This would be a relatively easy one for an external contributor to tackle. I'd be great to have a CI task that built a version of the server for ARM under qemu and tested it... Even better if we could cross-compile and then test under an emulator.

flisboac commented 3 years ago

First of all, I'm sorry for my initial message.

I took a very quick look into this yesterday. The build system is quite complex, but I think I have a vague idea on how to make it work by using buildx. I cloned the project and made some changes, but I didn't have the time to test the build again. I also don't know yet if the changes I made would break any automated CI pipelines the project may have. In fact, I don't know anything about this project's CI pipelines at all.

My idea was to change the crossbuild rule dependencies around, in scripts/docker/crossbuild/crossbuild.mk, to add a single dependency to a new target crossbuild.${1}.push, which would depend on crossbuild.${1} and then push the native (tested) image along with additional ARM builds (by using docker buildx build --push). Problem is that this approach doesn't test the ARM images themselves, I guess.

Unfortunately, I had to stop before I could test these changes in a proper x64 Linux host. I don't have too much time now, but perhaps this weekend I can see into this issue. If it's okay, I can commit what I have changed and open a PR, just for the sake of getting early feedback.

mcnewton commented 3 years ago

@flisboac thanks for taking a look! Don't worry about crossbuild, that's more for developers to check different platforms, it's not used for the official Docker builds.

Docker builds are done by scripts/docker/docker.mk, and the Dockerfiles used by the "official" docker images are in scripts/docker/ubuntu18/ and scripts/docker/alpine. There are Dockerfiles there for other platforms as well, but they're not built and uploaded to Dockerhub, but they should be kept in sync if any of the others are changed (which I think is unlikely anyway).

I don't know how the alternative arch builds work at all (I've never looked at buildx) but if it's a simple command to run then I would imagine that it's quite easy to add into docker.mk. There's only a handful of targets there.

kmluoh commented 2 years ago

I've made some changes to build/publish multi-platform images. docker images can be found at https://hub.docker.com/repository/docker/kmluoh/freeradius-server change set can be found at https://github.com/kmluoh/freeradius-server/compare/release_3_0_25..e6190beeeeb92e155894738f17e68971a35b3e6a @mcnewton Let me know if you want a PR. happy to help on that.

slyglif commented 2 years ago

@mcnewton Any chance you've had any correspondence w/ @kmluoh about integrating this?

alandrees commented 1 year ago

Just wanted to chime in:

Attempting to build on an arm64 raspberry pi: Linux util3 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux

the docker build process fails because there is a node dependency that is not compatible with arm64:

Step 10/22 : RUN npm i -g @antora/cli@2.1 @antora/site-generator-default@2.1
 ---> Running in 78934e6d6c9b
+ npm i -g @antora/cli@2.1 @antora/site-generator-default@2.1
npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for deep-freeze-node@1.1.3: wanted {"os":"darwin,linux,win32","arch":"x64,ia32,arm,mips"} (current: {"os":"linux","arch":"arm64"})
npm ERR! notsup Valid OS:    darwin,linux,win32
npm ERR! notsup Valid Arch:  x64,ia32,arm,mips
npm ERR! notsup Actual OS:   linux
npm ERR! notsup Actual Arch: arm64

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2023-02-04T14_49_46_101Z-debug.log
ConsoleTVs commented 10 months ago

Raspberry, M1, M2 and M3 users (most mac users) can't use the image due this.

Any updates?

dronenb commented 8 months ago

It seems as though the current versions of @antora/site-generator-default and @antora/cli (latest for both is 3.1.7 at the time of writing) can both install on ARM64 architectures, whereas version 2.1 cannot due to dependency on deep-freeze-node, which seems to no longer be maintained. Maintainers, would there be apprehension to upgrading these packages to their latest versions? I would perhaps be interested in assisting with this so this issue can be closed out... The more people who can run FreeRADIUS, the better, including those who wish to run it at their house on a Raspberry Pi in a container! :)

alandekok commented 8 months ago

@dronenb We're happy to take patches. There's no reason to keep antora on an older version.

mcnewton commented 8 months ago

Not sure why there are comments about Antora on this issue - if you have problems with that then you are trying to build the wrong images. The main docker images don't use Antora at all. As I already explained in a comment above, don't use the crossbuild target. That is just for developers to debug different OSes, not for actually running FreeRADIUS.

I just tested on a Raspberry Pi and the Docker images build and run just fine - seescripts/docker/docker.mk:

$ make DOCKER_VERSION=3.2.3 docker-ubuntu
$ docker run --rm -it freeradius/freeradius-server:3.2.3 -X

(The main issue still stands, but it doesn't stop you building Docker images for ARM yourself if you really want the extra layer of complexity. As well as that, the main documentation is all built from the master branch, which I updated to use Antora v3 last year.)

dronenb commented 8 months ago

@mcnewton apologies for the confusion, I must be missing something, as I do not see a docker.mk anywhere in this repository, nor do I see the scripts/docker/ubuntu18/ and scripts/docker/alpine directories that you said the official Dockerfiles live in. I think where people (myself included) are going wrong is the fact that we are wrongly trying to use the dockerbuild script, and when doing so, are running into that issue with Antora. The following files exist in the master branch in scripts/docker:

$ ls -al
total 24
drwxr-xr-x  12 dronenb  staff   384 Mar 17 09:21 .
drwxr-xr-x  39 dronenb  staff  1248 Mar 17 09:03 ..
-rw-r--r--   1 dronenb  staff  4745 Mar 17 09:00 README.md
drwxr-xr-x   4 dronenb  staff   128 Mar 17 09:00 build-centos7
drwxr-xr-x   4 dronenb  staff   128 Mar 17 09:00 build-debian10
drwxr-xr-x   4 dronenb  staff   128 Mar 17 09:00 build-debian11
drwxr-xr-x   5 dronenb  staff   160 Mar 17 09:00 build-debian9
drwxr-xr-x   4 dronenb  staff   128 Mar 17 09:00 build-debiansid
drwxr-xr-x   4 dronenb  staff   128 Mar 17 09:00 build-ubuntu18
drwxr-xr-x   4 dronenb  staff   128 Mar 17 09:00 build-ubuntu20
drwxr-xr-x   4 dronenb  staff   128 Mar 17 09:00 crossbuild
-rwxr-xr-x   1 dronenb  staff  2017 Mar 17 09:00 dockerbuild

What exactly am I missing?

mcnewton commented 8 months ago

Don't use the development master branch. Checkout v3.2.x and build Docker images from that, which is what this issue was originally about. The dockerfiles in master are in need of some serious rework and may not work at all.

mcnewton commented 5 months ago

As a starting point, development build images are now multi-arch with ARM support: see the freeradius/freeradius-dev repository, e.g.

$ docker run --rm -it freeradius/freeradius-dev:v3.2.x -X

or

$ docker run --rm -it freeradius/freeradius-dev:v3.2.x-alpine -X

Works for me on Raspberry Pi 5 (bookworm) but please report back other successes/failures.