Should hercules run on alpine linux?

[leenooks]

Hi,

I'm a docker fan, and pretty much run all my apps in docker. I generally try and (re)build them using alpine as the base, as the alpine images are normally 1/3 to 1/2 the size of debian/rhel based containers.

I successfully built hercules (f7d2360 using alpine as a base, but when I start it I get an error similar to #431.

Doing some investigation, I see that the hdt3270.so library as missing symbols (and possibly the reason that herc doesnt know what a 3270 is?)

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.

(Rebuilding using rockylinux as the base - see's the 3270s without any issues.)

Any tips? Or is using alpine a lost cause?

[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.

[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.

[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

[Fish-Git]

@leenooks, @wrljet:  Is this issue resolved now? Should it be closed?

[wrljet]

I know people who are running on Alpine and it's working for them. At this point I don't know what the "issue" is here.

[Fish-Git]

At this point I don't know what the "issue" is here.

Well, it looks like the original reported issue was that Hercules wasn't running right, most likely because the OP wasn't building Hercules correctly.

Since it has since been reported that Hercules now builds and runs correctly on Alpine when Hercules-Helper is used to build it with, in my opinion this issue has been resolved and should be closed as PEBKAC.

I will do so now.

[wrljet]

A few members trolled me on this Alpine thing on Moshix's Discord until it worked. I don't believe it is 100% though, but it will run MVS JCL.

[Fish-Git]

A few members trolled me on this Alpine thing on Moshix's Discord until it worked. I don't believe it is 100% though, but it will run MVS JCL.

I'm not quite sure what that means, so I'll just leave things up to you, Bill -- Keep it open. Close it. Change to "OnGoing" status. Whatever you decide is fine with me.

[wrljet]

Let's go ahead and close it. It's not that popular for Hercules (IMH), and those who do use it are vocal, so they will let us know.