Re: Can I please get some help with my port of dell Racadm? (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201799)

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


> 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 ?