Should hercules run on alpine linux?

[leenooks]

Should hercules run on alpine linux?

[leenooks]

@wrljet Thank you, indeed hercules helper does successfully build on alpine and hdt3270.so no longer has symbol issues. I tried both Aethra and SDL (havent yet learnt why there is two), but starting hercules I can connect with 3270. I'm going to investigate why your build works (because I'm curious, and I dont like a problem beating me).

Since my target platform is a docker container, I did notice a couple of things - not sure if you are interested. (And really the wrong issue # to cover this).

1. hercules wouldnt start, probably because it is doing some privileged operations that docker doesnt allow. (I didnt have this issue with my original build). So I need to investigate what privileged operations need to be added to starting a container, because you wouldnt want to give it the global privileged mode (and its strange that I havent stumbled across this). (Added privileged mode allowed it to start as a quick test.)

2. the builder doesnt let you build as "root". And while that is a good practice for normal "unix" applications, its less critical for docker containers (IMHO anyway). Certainly interacting with the build process via "sudo" is prone to failure, especially if builds are being automated via CI/CD. (I couldnt figure out how to disable --sudo, it still complained that it wasnt installed, and I disabled the "exit 1" for the build, since my build was running as root (inside the container).

   I do know some build environments (I think OpenShift), dont run as root (inside the container), and you may need to do some prep up front to make sure sudo doesnt wait for a password (I'm not in a position to explore this).

Now, if hercules on linux was consumed via a container image, available on docker hub, then nobody needs to build at all - have you thought about making it available that way?

Anyway, thanks for the fun, its nice to play with a mainframe at home.

[Fish-Git]

I successfully built hercules...

How? Did you build it manually yourself? Or did you use Bill's "Hercules Helper"?

If you built it manually yourself, were you careful to also build all of the Hercules "External Packages" too beforehand?

Error relocating /usr/lib/hercules/hdt3270.so: __vsnprintf_chk: symbol not found
Error relocating /usr/lib/hercules/hdt3270.so: __snprintf_chk: symbol not found
Error relocating /usr/lib/hercules/hdt3270.so: __fdelt_chk: symbol not found

I've tried lots of searching to see what libraries that might be missing that supplies these symbols (gcompat, etc), but no luck.

My Linux skills are very weak, but...

Is it possible you are trying to build a debug version of Hercules instead of a non-debug / production release version? Or maybe linking with a version of GLIBC that is too old?

• https://www.google.com/search?q=what+is+%22__vsnprintf_chk%22
• https://stackoverflow.com/questions/43334208/fmi-c-standard-library-version-differences-cause-linking-errors

What version of gcc and GLIBC do you have on your alpine Linux system compared with what you have on your rocky Linux system?

[leenooks]

How? Did you build it manually yourself? Or did you use Bill's "Hercules Helper"?

I dont know of the Hercules Helper, but yes, I did it myself:

Essentially, this is the part of my Dockerfile that builds hercules is:

RUN apk --no-cache add tmux bash gcompat libbz2 libpcap openssl
RUN apk --no-cache add git make gcc autoconf g++ libtool bzip2-dev linux-headers zlib-dev libpcap-dev ncurses-dev openssl-dev \
        && git clone https://github.com/sdl-hercules-390/hyperion /tmp/hyperion \
        && cd /tmp/hyperion \
        && ./configure --prefix=/usr --enable-cckd-bzip2 --enable-het-bzip2 \
        && make && make install \
        && cd /tmp && rm -rf /tmp/hyperion 

Is it possible you are trying to build a debug version of Hercules instead of a non-debug / production release version? Or maybe linking with a version of GLIBC that is too old?

My configure/make is above (so I dont think I'm building a debug version?

Alpine uses musl, instead of glibc - but even adding the gcompat (glibc capability layer), it still shows those errors.

https://wiki.alpinelinux.org/wiki/Running_glibc_programs

[wrljet]

Hercules-Helper will build SDL Hercules to run on Alpine.
It's not 100%, but close enough to run MVS.

[Fish-Git]

Essentially, this is the part of my Dockerfile that builds hercules is:

RUN apk --no-cache add tmux bash gcompat libbz2 libpcap openssl
RUN apk --no-cache add git make gcc autoconf g++ libtool bzip2-dev linux-headers zlib-dev libpcap-dev ncurses-dev openssl-dev \
        && git clone https://github.com/sdl-hercules-390/hyperion /tmp/hyperion \
        && cd /tmp/hyperion \
        && ./configure --prefix=/usr --enable-cckd-bzip2 --enable-het-bzip2 \
        && make && make install \
        && cd /tmp && rm -rf /tmp/hyperion 

Okay, it looks like you're not building the External Packages, which is likely where your problem lies. I highly recommend using Bill's Hercules Helper to build Hercules instead.

[leenooks]

Actually, according to helper-check-packages.sh line 255, in the Hercules Helper, it says Alpine Linux is not yet supported!.

I don't have any problem building hyperion, I have it running quite happily using a rocky(rhel) base image. I was hoping to build it using a base alpine image - the resulting image is 100MB vs 300MB for rocky. (There is no issue running the 300MB image, I am primarily exploring if it is possible with alpine, since that is what I use with other apps - maybe others will try on alpine as well one day.)

As I say, the alpine images appears to start fine, but without 3270's - it appears that the hdt3270.so file is the only one with symbol problems. (I havent tried running any OS under it yet, as I was hoping to see if 3270 could be supported (via addressing the missing symbols) - but I'm thinking no.

I've tried various ways of getting glibc on alpine, via gcompat and sgerrand/alpine-pkg-glibc without success.

I havent tried the "external packages" - so I'll look into that...

[wrljet]

helper-check-packages.sh is an under-construction helper that is currently only used for macOS.
It's not something you run by hand.

Simply follow the instructions in the README.md

[wrljet]

FWIW, after the most recent Alpine related changes, I only tested it with Hercules-Aethra.
Shouldn't matter. I think those changes made it into SDL.

I'm going to be away today, but can check that tomorrow.

[wrljet]

Deon,

@wrljet Thank you, indeed hercules helper does successfully build on alpine and hdt3270.so no longer has symbol issues. I tried both Aethra and SDL (havent yet learnt why there is two), but starting hercules I can connect with 3270. I'm going to investigate why your build works (because I'm curious, and I dont like a problem beating me).

Excellent! I'm glad it worked for you! (I'm sure Fish is pleased, too)
This is why Hercules-Helper (sorry, I know the project name is awful) exists. It captures all the institutional knowledge on how to build on basically everything.

Why Aethra exists? Well, that politics and I won't go into that.

Since my target platform is a docker container, I did notice a couple of things - not sure if you are interested. (And really the wrong issue # to cover this).

Of course I'm interested.

1. hercules wouldnt start, probably because it is doing some privileged operations that docker doesnt allow. (I didnt have this issue with my original build). So I need to investigate what privileged operations need to be added to starting a container, because you wouldnt want to give it the global privileged mode (and its strange that I havent stumbled across this). (Added privileged mode allowed it to start as a quick test.)

Near the end of the process, hercules-buildall.sh runs some setcap commands.
These allow Hercules to set up the networking, adjust priority of threads, etc. Perhaps it's related to that.

2. the builder doesnt let you build as "root". And while that is a good practice for normal "unix" applications, its less critical for docker containers (IMHO anyway). Certainly interacting with the build process via "sudo" is prone to failure, especially if builds are being automated via CI/CD. (I couldnt figure out how to disable --sudo, it still complained that it wasnt installed, and I disabled the "exit 1" for the build, since my build was running as root (inside the container).

I refuse to let it run as root because I don't want to feel guilty when somebody who doesn't really know what they are doing wrecks their system.

I do know some build environments (I think OpenShift), dont run as root (inside the container), and you may need to do some prep up front to make sure sudo doesnt wait for a password (I'm not in a position to explore this).

There is an option --askpass to use a sudo -A askpass helper and skip the interactive prompts.
That might solve your issue. I can explain it further if you're interested.

Now, if hercules on linux was consumed via a container image, available on docker hub, then nobody needs to build at all - have you thought about making it available that way?

Some people use Docker for Hercules. But no, I myself have never thought about that.

I do have GitHub Actions just about ready to release builds for the most common systems. These will be built for ever git push, and keep the most recent few around. This will be rolled out first (shortly) on Aethra, and then on SDL Hercules after I get Fish's approval. (I haven't even brought it up yet with Fish)

Anyway, thanks for the fun, its nice to play with a mainframe at home.

Enjoy your personal mainframe!

Bill