TLDR: New .shar attached to fix a few port weirdnesses involving what looks like specifically a weird interaction between poudriere, the linux emulation layer and long symlinks. I think we’re ready to go, but people should read the following.
(If the list eats the .shar, let me know and I’ll upload it to the PR).
Long Version:
So, in my initial ask to help fix this port, I asked for someone who
understands the nuances of how Linux ports especially work.
I’m still hitting an issue with the binaries not actually working correctly.
The dell programs don’t ship a libssl.so — they try looking for it in a bunch
of places, but untimately they’re looking for a file called libssl.so (not
libssl.so.3 or libssl.so.3.2.2, just libssl.so).
These are not linked into the program, they’re dynamiclly loaded via dlopen()
when the code needs them. (This makes it way easier for dell to ship a binary
for lots of systems, especially without shipping crypto software and
dynamically linking it to one exact specific version).
If for some reason, when I try to use this, it can’t find that library, it
returns this error:
[dmahoney@poudriere-src ~]$ /compat/linux/opt/dell/srvadmin/bin/idracadm7 -r
mgmt.oak1f.f.root-servers.org -u root -p calvin getsysinfo
ERROR: RAC1170: Unable to find the SSL library in the default path.
If a SSL library is not installed, install one and retry the
operation. If a SSL library is installed, create a soft-link of the
installed SSL library to "libssl.so" using the linux "ln" command
and retry the operation.
My port line has a ${RLN} block to attempt to install this, but it tries to be
too clever, and creates a symlink to something with way too many ../../’s, so
much that it seems to confuse the linux compatibility layer (perhaps because it
traverses past the filesystem root?)
When I strace it, the linux libraries get “no such file or directory”.
Here are the broken symlinks that are created, and the fixed symlinks that are
created:
root@poudriere-src:/compat/linux/opt/dell/srvadmin/lib64 # ls -al
total 3
drwxr-xr-x 3 root wheel 5 Sep 2 06:48 .
drwxr-xr-x 6 root wheel 6 Sep 2 06:46 ..
lrwxr-xr-x 1 root wheel 37 Sep 2 06:48 libssl.so ->
../../../../usr/lib64/libssl.so.3.2.2 (four .. up is /compat/linux, six up is /)
lrwxr-xr-x 1 root wheel 77 Sep 2 06:44 libssl.so.old ->
../../../../../../../../../../../../../compat/linux/usr/lib64/libssl.so.3.2.2
drwxr-xr-x 3 root wheel 3 Sep 2 06:46 openmanage
root@poudriere-src:/compat/linux/opt/dell/srvadmin/lib64 # md5 libssl.so
MD5 (libssl.so) = 5fc94e90aff79602689b8453d7c0909c
root@poudriere-src:/compat/linux/opt/dell/srvadmin/lib64 # md5 libssl.so.old
MD5 (libssl.so.old) = 5fc94e90aff79602689b8453d7c0909c
These are links to the *SAME FILE*. One works, the other doesn’t, and I don’t
quite understand the mechanics that the ${rln} function uses and why it needs
to traverse 10 levels beyond the top of my filesystem. (I suspect it’s
something having to do with the staging directories as part of the build
system?)
I suspect that since the port works okay if you just cd
/usr/ports/sysutils/racadm, that this is being exacerbated by poudriere-bulk.
Poudriere creates a relative symlink that’s way too long, and the linuxulator
can’t follow it. I might poke bdrewery/bapt about this.
Ergo, I’ve changed the ${rln} in the Makefile to “ln -s”. The symlink is being
dropped into a directory only consumed by this tool, thus it only affects this
one binary, and it’s a fairly safe bet that your linux install will always be
located in /compat/linux. The porter’s handbook says “relative links are
strongly recommended” but not “required” and I think I’ve found an edge case
where you’d want to just use a real link. (I’ve confirmed that it’s properly
created, and removed when the port’s removed).
===
Also, because this feels important to do, I actually had it query a real-life
iDrac (on a personal machine):
[dmahoney@poudriere-src ~]$ /compat/linux/opt/dell/srvadmin/bin/idracadm7 -r
x.x.x -u root -p xxxxx getsysinfo
Security Alert: Certificate is invalid - EE certificate key too weak
Continuing execution. Use -S option for racadm to stop execution on
certificate-related errors.
RAC Information:
RAC Date/Time = Tue Sep 2 07:09:48 2025
[redacted]
Common settings:
Register DNS RAC Name = 0
DNS RAC Name = idrac-97GZQ22
Current DNS Domain =
Domain Name from DHCP = Disabled
[more redacted]
(For reference, this is an iDrac 7 on a dell R420 with an iDRAC enterprise
license).
Yay!
===
The new .shar file is attached with minor changes. (One other change — I don’t
want to use my work email for this, even if it’s well-known who I work for, if
god-forbid someone does something dumb with this, I’d rather not have it
implicate the dayjob).
-Dan
racadm.shar
Description: Binary data
> On Sep 1, 2025, at 22:38, Kurt Jaeger <[email protected]> wrote: > > Hi! > >> can you check if the port below works? >> >> I don't have any Dell machines around but it established an SSL >> connection to my port 443 successfully. > > Testbuild on 14.3 and 15.0 was fine. > > -- > [email protected] +49 171 3101372 Now what ?
