Created attachment 159120 [details] this here's the stuff A port to download and extract Dell's linux binaries for interfacing with their remote access controllers (DRAC).
Created attachment 159992 [details] racadm.shar
Created attachment 160000 [details] racadm.shar
Created attachment 160190 [details] racadm.shar
Created attachment 160689 [details] racadm.shar
Hi, Thank you very much for submitting this port -- looks like it could be very useful to solve some iDrac related problems I've run into. I'm sorry it's been languishing in the uncommitted pile for so long, and I'll get it into the tree ASAP. Port passes 'poudriere testport' so we're mostly there. However there are a few points I noticed: * Can you add 'linux' as a secondary category please, and linux as PKGNAMEPREFIX? All linuxulator software should have this. * You've got scripts that use bash as their interpreter, but no dependency on bash. If the scripts are not too bash-centric, it would be good to tweak them into working with /bin/sh if that is possible. Otherwise, you'll need a RUN_DEPENDS on shells/bash. * Try 'USES=shebangfix' rather than manually changing the #! line for any scripts that do need to invoke /usr/local/bin/bash * You're installing some service startup scripts under ${LINUXBASE}/etc/rc.d/init.d -- are these necessary for racadm to work properly? If so, then you might consider crafting some FreeBSD rc scripts to go into /usr/local/etc/rc.d so that those services can be started up automatically at boot.
No response from submitter in many weeks.
How do I download the the work done on racadm? I am in need of this port and am willing to patch up the remaining changes to make it work - hopefully it wont be much.
Download the racadm.shar attached to this PR, then run: # sh racadm.shar to extract the content.
Adonis, if you manage to get this working, it will be tremendously appreciated. I am basically dying to have a working direct from shell racadm solution, as I work with several Dell servers. Many many thanks in advance. RBS
Created attachment 184567 [details] racadm.shar New Version.
I reworked this, and made it work under FreeBSD 11 AMD64. Note that it will probably not work under i386. The dell tools want to install a lot of things by default, and breaking those things out would seem to violate their license. The included service files are there as part of the RPM, but will not actually start anything (for example, they cannot modprobe nonexistent kernel modules). I found nothing good in the porter's handbook about how to handle that. Also of note, this port creates a symlink to deal with a Dell Library Braindeadness, but I couldn't find anything in the handbook about how to properly target a symlink either. As for the rest of the prior concerns (required descriptions, dependencies, etc), those are fixed here. It will probably only ever work on a "remote" idrac. Our kernel can't enumerate the ipmi to handle it locally. Perhaps a post-install message should be printed to this effect.
Dan, thanks for all the work. Can you please explain what is the problem with ipmi enumeration? Because remote racadm can be easily enough supplemented with drac ssh access and/or another method. The point is to have local racadm for easy and instantaneous self-monitoring, especially reading all the sensors. What would be needed to have local racadm? If this is available for other platforms, surely we can have it too. Many thanks.
Reopen given new submissions
Okay, I just broke this out after having it closed out for nine months. This port needs a little more love to be made to work correctly under a modern ports tree, but it's still totally viable. To answer your question: Remote racadm: pushes packets over the network and waits for a response. Local racadm: uses a linux centric kernel api and devices that don't seem to be compatible with freebsd's impi.ko Porting Local racadm: Making a port makefile that pulls down the dell OMSA package, and extracts a bunch of things from the included RPM files. Porting remote racadm: reimplementing the linux IPMI spec and device drivers, and not having the racadm source to work with. Patches welcome :) For my dayjob, a FreeBSD shop, where our jumphosts and management machines are FreeBSD, this means we can use remote racadm without having to spin up a linux machine. I suspect that was what the Norse guys wanted too when they initially created this port.
Does ipmitool lack some important feature that prevents you from using ipmitool instead of racadm?
(In reply to Jan Bramkamp from comment #15) Does /bin/sh lack some important feature that means we need a port of bash? Yes, ipmitool and racadm are completely different animals. There's *way* more that you can do on a dell with racadm. Think: manipulating every single bios setting. Resetting the serial console speed. Changing power management profiles. Heck, even configuring a raid card, via a well-documented series of "set" variables. Now, if you ssh into an iDrac, there's also an *embedded* racadm, but being able to have a local racadm on your management station so that you can use it as a sort of pseudo-puppet.
(In reply to Dan Mahoney from comment #14) Dan, many thanks for the explanation what's what. As also advised on freebsd-hackers@, I figured out local ipmi. But as you said, this is just like scratching the surface but at very least it lets me easily read all the sensors I need. Do you think it makes sense to finish this port without local management? That's still better than nothing I'd say. I am hoping somebody who is knowledgeable enough to understand in depth the ipmi problem with local racadm maybe could fix/finish this port, so we can have fully functional racadm on FreeBSD. It would be super useful. As I wrote on freebsd-hackers@, I offer a standing "bounty" of 50 EUR. No expiration date. I'll follow this ticket/submission. Maybe if more people chime in, somebody will figure out the issues.
Hi All Just wondering what the hold up/blocker is on this? Having racadm running on a freebsd jumpbox/bastion box is extremely useful, and there are commands/features that don't work on the local ssh version, such as (in my case the main reason for needing racadm on freebsd) ssl certificate/key uploads for idrac. local access for racadm IMO shouldn't be a blocker on this. You can always connect 'remotely' to the idrac unit. Thanks in advance.
I'm working on an updated port.
I detailed my reasons for not continuing in my other responses: Unclear options in porter's handbook to do things I needed to, sketchy license, limited usefulness. -Dan
(In reply to Dan Mahoney from comment #20) As stated before, I took over (as I need this port). So far, I've successfuly updated to 9.2.0, making it work under recent Linux emulation.
(In reply to Juraj Lutter from comment #21) Would you like to submit a patch and take the maintainership of this port?
Yes, please.
(In reply to Juraj Lutter from comment #23) Great! Thank you!
As I am not a committer, can this PR be assigned to me?
Juraj, I'll take that PR as a committer and you can provide your patch and I'll test it and get it committed. OK ?
Juraj, Would you like to send me what you've got? I've got a renewed interest in this. -Dan
So, I've done some hacking on this this evening, and it seems there's a few interesting ways forward. Previously, I extracted a LOT of things from the openmanage server application, which installed a lot of runtime services and the like. Dell has a (stable, monthly) linux repository we can pull down from. They even encourage rsync mirroring. Here's a recent one: http://linux.dell.com/repo/hardware/DSU_21.02.01/os_dependent/RHEL8_64/ And here's a list: http://linux.dell.com/repo/hardware/ We really just need two RPMs to extract: srvadmin-argtable2-9.5.0-4063.16816.el8.x86_64.rpm (gpl license covers this, but the RPM dell provides wants to put it in a funky place) srvadmin-idracadm7-9.5.0-4063.16816.el8.x86_64.rpm Which is, racadm. I threw it at one of our idrac 8 machines, and it talked to it. One more caveat -- this thing wants an SSL library, but it's not dynamically linked to one. It has code inside it to recognize which library its using and do whatever. It specifically asks you to symlink one in: 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. So we'd have to fix that somehow. -Dan
This is a good news. Unfortunately, my only Dell box available is in production now but as long as I do not disrupt its operation, I can test with iDrac9. If you share your recent work, we can synchronize.
Okay. Done. Port builds cleanly on my machine, passes port-lint. Because of the weird symlink it creates out of tree, poudriere testport *may* complain about that, but I'm currently hitting a different problem. Poudriere is currently crashing on me because of the linux procfs. I've emailed bdrewery, and he gave me something that helped somewhat, but poudriere testport currently bails. In the meantime, I can upload the .shar for testing if you want it here.
Created attachment 222951 [details] New racadm9 port to install 9.5
Here we go. New port which installs racadm7 version 9.5 from the dell RPMs. Passes portlint and while I can't poudriere testport it, I can do: poudriere bulk -j freebsd:12:x86:64 -Ct sysutils/racadm9 poudriere bulk -j freebsd:11:x86:64 -Ct sysutils/racadm9 And both of those worked fine. It's amd64-only. (That's all Dell distributes). Whoops, upload got truncated. Will try again.
Created attachment 222953 [details] new non-truncated racadm9.shar New racadm9 shar for racadm7 version 9.5
(In reply to Dan Mahoney from comment #33) I've extracted the shar. It builds using make, but poudriere fails to build it,
(In reply to Dan Mahoney from comment #33) One thing: is this racadm7 or racadm9 ?
(In reply to Kurt Jaeger from comment #34) This is due to a poudriere bug with /compat/linux. I've been in touch with bdrewery on this back in march. [00:00:05] Recording filesystem state for prepkg... done [00:00:06] Committing packages to repository: /usr/local/poudriere/data/packages/freebsd:12:x86:64-default/.real_1614671622 via .latest symlink [00:00:06] Removing old packages [00:00:06] Building with flags: PREFIX=/compat/linux [00:00:06] Removing existing /compat/linux (Bunch of warnings about not being able to remove /compat/linux stuff) rm: /usr/local/poudriere/data/.m/freebsd_12_x86_64-default/ref/compat/linux/proc/sys/vm/min_free_kbytes: Operation not supported (Many more warnings snipped) /usr/local/poudriere/data/.m/freebsd_12_x86_64-default/ref/compat/linux/proc/18359/maps: rm: /usr/local/poudriere/data/.m/freebsd_12_x86_64-default/ref/compat/linux: Directory not empty [00:00:06] Cleaning up [00:00:06] Unmounting file systems is what I got. I don't think we're ever going to bulk-build this, however, because of the licensing of the dell binaries. I am guessing you could call this sort of like MegaCli -- this is basically a binary package canopener port. The tool that gets installed is "racadm7" -- but the version of the package on the dell site is 9.5 which is why I called it racadm9. The idrac API differs based on versions of the server. An idrac 5 or 6 can't be talked to with racadm9. Additionally, because of the way Dell built this stuff, they don't supply a crypto lib, instead expecting you to drop one in place and dlopen()ing it.
Kurt, What's the solution when poudriere doesn't work, but the port actually does the right thing on the system I've tried it on? Commit it and mark it as restricted (which it might be anyway due to the dell license)? Short of fixing the bugs with poudriere and linux, is there a way to move this forward? -Dan
please could we change the importance on this one? Dell isn't a minor server vendor so we can assume it's affecting more people. I personally know at least one I see - daily! Plus racadm at the very least can help people shorten downtimes and similar things. Maybe then there can be more people help fix the poudriere issue. Arguably that should not be a blocker anyway if the port can be built manually.
(In reply to florian.heigl from comment #38) (especially since this already has just had an anniversary)
(In reply to florian.heigl from comment #39) Please follow the discussion on ports@. Dan and Marcin send shar files, I can only testbuild, but have no testbox to do run-tests.
I think this is ready to commit!!! Please have a look at https://users.isc.org/~dmahoney/racadm.tar.gz if you want to test it (untag in ports/sysutils). I have confirmed the symlink issue is fixed (using a normal link, the relative links feature is too broken), but passes poudriere Westport and the like. I can confirm it can talk to my dell R430. If we need a .shar for this, or a GitHub, or I need to do some other dance let me know. -Dan
Created attachment 264392 [details] git-format patch Git-format patch per Darius on Discord.
(In reply to Dan Mahoney from comment #42) testbuilds@work
(In reply to Kurt Jaeger from comment #43) testbuilds are fine on 15a5-amd64 and 14.3amd
(In reply to Kurt Jaeger from comment #44) portlint -AC FATAL: /pou/ports/default/sysutils/racadm/pkg-plist: [7]: Unpacked man file argtable.3 listed. Must be gzipped. FATAL: /pou/ports/default/sysutils/racadm/pkg-plist: [8]: Unpacked man file argtable2.3 listed. Must be gzipped.
Have anyone actually reviewed the license? https://www.dell.com/en-us/lp/legal/art-software-license-agreements Section 2, especially 2.1 E and 2.2 J (and possibly K) makes it non packable and is why you don't find it as such. J. Copy, republish, upload, post or transmit the Software in any way; K. Modify or create derivative works based upon the Software, or decompile, disassemble, reverse engineer, or otherwise attempt to derive source code from the Software, in whole or in part So it's a hard no, it's not going in.
(In reply to Daniel Engberg from comment #46) It is perfectly fine to have this in Ports with empty LICENSE_PERMS, no?
(In reply to Kurt Jaeger from comment #45) Kurt, would you mind if I reassign this PR to myself and push the final version of the port?
When I first started work on this, I had always assumed the license was restrictive enough that this would need to be a "the user must build this for themself at their org" sort of port, just like a port for any other closed source (or even commercial) piece of software, even if we require the user to manually drop the rpms into /usr/ports/distfiles, and this port is little more than a "can opener" for those RPMs. I don't think running this under the Linuxulator is a "derivative work" any more than running it under full Linux with bhyve would be. I maintain an FAQ about it that I'm willing to update. (My blog about using Dell Repository Manager is my most popular one ever, maybe this is a trend). If this port becomes a non-starter after ten years, I'll be sad, but it just means that the FAQ will say different things (and of course, I don't want to put myself, or the project at risk, Legally). But as noted by the history, people keep asking for it, and an open PR is not the answer to give them -- it just leads to more questions. There are some idrac-related functions that you simply cannot do without this tool (Applying a license to an iDrac and installing an SSL cert in any sort of automated way are the two big ones that come to mind).
Gleb, please finalize...
(In reply to Gleb Popov from comment #47) No, it needs to be no-dist-mirror no-dist-sell no-pkg-mirror no-pkg-sell no-auto-accept If we're going to pull this in Looking at the patch file.... +WRKSRC= ${WRKDIR}/${PORTNAME} +NO_WRKSUBDIR= yes Looks a bit strange? +do-install: + cd ${WRKSRC}; ${CP} -pR * ${STAGEDIR}${PREFIX} Should use the proper macros.... Should these be installed? +usr/lib/.build-id/ca/690910e69bfe67f0f4bd2e4b155adfcf8627d3 +usr/lib/.build-id/51/8f7b88f8e092b14c16c3454fa89b3e0541645f ...and ordering is a bit odd
My final version of the port: https://github.com/freebsd/freebsd-ports/commit/f49c27551c834432797fd6660b58388f3a92384e Everyone interested are invited to review. This unfortunately required a little adjustment in Mk/bsd.port.mk, which obviosly would need to be reviewed by portmgr@ and getting in before the port. (In reply to Daniel Engberg from comment #51) > No, it needs to be > no-dist-mirror no-dist-sell no-pkg-mirror no-pkg-sell no-auto-accept Why? The license framework defaults to prohibiting, so an empty LICENSE_PERMS means that nothing is allowed.
(In reply to Gleb Popov from comment #52) Because we know the license and relying on default undefined behaviour (there's nothing that doesn't say that the defaults will be changed tomorrow, unlikely however) is incorrect. Also empty is also incorrect, https://docs.freebsd.org/en/books/porters-handbook/book/#licenses-license_perms First line says: "Permissions. use none if empty." ..and above that, https://docs.freebsd.org/en/books/porters-handbook/book/#licenses "Each port must document the license under which it is available. If it is not an OSI approved license it must also document any restrictions on redistribution." I would also argue that you should exclude extracting libssl.so instead of using rm.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ad2f62b27547889d5e57b1bec20c27c06516c625 commit ad2f62b27547889d5e57b1bec20c27c06516c625 Author: Dan Mahoney <freebsd@gushi.org> AuthorDate: 2025-10-08 00:43:36 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2025-10-26 10:29:38 +0000 sysutils/linux-racadm: Add new port PR: 201799 Reviewed by: pi Co-authored-by: Gleb Popov <arrowd@FreeBSD.org> sysutils/Makefile | 1 + sysutils/racadm/Makefile (new) | 55 +++++++++++++++++++++++++++++++++++++++ sysutils/racadm/distinfo (new) | 5 ++++ sysutils/racadm/pkg-descr (new) | 1 + sysutils/racadm/pkg-message (new) | 11 ++++++++ sysutils/racadm/pkg-plist (new) | 12 +++++++++ 6 files changed, 85 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ac0684edaf1a7b9b4ca877af5ad06bc0bc89a778 commit ac0684edaf1a7b9b4ca877af5ad06bc0bc89a778 Author: Gleb Popov <arrowd@FreeBSD.org> AuthorDate: 2025-10-26 18:58:13 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2025-10-26 19:00:24 +0000 sysutils/racadm: Rename to linux-racadm as it was intended PR: 201799 Reported by: antoine Fixes: ad2f62b27547889d5e57b1bec20c27c06516c625 Pointy hat to: arrowd sysutils/{racadm => linux-racadm}/Makefile | 0 sysutils/{racadm => linux-racadm}/distinfo | 0 sysutils/{racadm => linux-racadm}/pkg-descr | 0 sysutils/{racadm => linux-racadm}/pkg-message | 0 sysutils/{racadm => linux-racadm}/pkg-plist | 0 5 files changed, 0 insertions(+), 0 deletions(-)