Bug 201799 - [NEW PORT] sysutils/racadm9: Dell remote access controller admin utility
Summary: [NEW PORT] sysutils/racadm9: Dell remote access controller admin utility
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kurt Jaeger
URL:
Keywords: feature, needs-qa, patch
Depends on:
Blocks:
 
Reported: 2015-07-23 18:31 UTC by gekkey
Modified: 2023-04-05 10:35 UTC (History)
14 users (show)

See Also:


Attachments
this here's the stuff (126.98 KB, application/x-shar)
2015-07-23 18:31 UTC, gekkey
no flags Details
racadm.shar (127.14 KB, application/x-shar)
2015-08-18 22:07 UTC, gekkey
no flags Details
racadm.shar (89.99 KB, application/x-shar)
2015-08-19 01:20 UTC, gekkey
no flags Details
racadm.shar (115.80 KB, application/x-shar)
2015-08-21 20:23 UTC, gekkey
no flags Details
racadm.shar (115.89 KB, application/x-shar)
2015-09-03 18:52 UTC, gekkey
no flags Details
racadm.shar (120.97 KB, application/x-shar)
2017-07-21 11:05 UTC, Dan Mahoney
no flags Details
New racadm9 port to install 9.5 (3.38 KB, text/plain)
2021-03-03 20:49 UTC, Dan Mahoney
no flags Details
new non-truncated racadm9.shar (3.38 KB, text/plain)
2021-03-03 20:59 UTC, Dan Mahoney
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description gekkey 2015-07-23 18:31:31 UTC
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).
Comment 1 gekkey 2015-08-18 22:07:14 UTC
Created attachment 159992 [details]
racadm.shar
Comment 2 gekkey 2015-08-19 01:20:31 UTC
Created attachment 160000 [details]
racadm.shar
Comment 3 gekkey 2015-08-21 20:23:14 UTC
Created attachment 160190 [details]
racadm.shar
Comment 4 gekkey 2015-09-03 18:52:30 UTC
Created attachment 160689 [details]
racadm.shar
Comment 5 Matthew Seaman freebsd_committer freebsd_triage 2015-11-16 17:34:20 UTC
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.
Comment 6 Matthew Seaman freebsd_committer freebsd_triage 2016-01-10 09:46:05 UTC
No response from submitter in many weeks.
Comment 7 Adonis 2016-05-06 06:07:32 UTC
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.
Comment 8 Matthew Seaman freebsd_committer freebsd_triage 2016-05-06 06:15:17 UTC
Download the racadm.shar attached to this PR, then run:

# sh racadm.shar 

to extract the content.
Comment 9 RedBull 2016-06-29 06:08:34 UTC
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
Comment 10 Dan Mahoney 2017-07-21 11:05:20 UTC
Created attachment 184567 [details]
racadm.shar

New Version.
Comment 11 Dan Mahoney 2017-07-21 11:11:34 UTC
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.
Comment 12 Peter G. 2018-04-28 13:28:01 UTC
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.
Comment 13 Matthew Seaman freebsd_committer freebsd_triage 2018-04-28 14:55:21 UTC
Reopen given new submissions
Comment 14 Dan Mahoney 2018-04-29 06:54:29 UTC
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.
Comment 15 Jan Bramkamp 2018-04-30 15:10:05 UTC
Does ipmitool lack some important feature that prevents you from using ipmitool instead of racadm?
Comment 16 Dan Mahoney 2018-04-30 18:13:45 UTC
(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.
Comment 17 Peter G. 2018-05-01 01:20:18 UTC
(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.
Comment 18 Thomas 2020-08-31 21:53:27 UTC
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.
Comment 19 Juraj Lutter freebsd_committer freebsd_triage 2020-08-31 22:22:18 UTC
I'm working on an updated port.
Comment 20 Dan Mahoney 2020-09-01 07:23:33 UTC
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
Comment 21 Juraj Lutter freebsd_committer freebsd_triage 2020-09-01 08:37:46 UTC
(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.
Comment 22 Mateusz Piotrowski freebsd_committer freebsd_triage 2020-09-28 14:13:49 UTC
(In reply to Juraj Lutter from comment #21)

Would you like to submit a patch and take the maintainership of this port?
Comment 23 Juraj Lutter freebsd_committer freebsd_triage 2020-09-28 14:15:17 UTC
Yes, please.
Comment 24 Mateusz Piotrowski freebsd_committer freebsd_triage 2020-10-06 14:06:38 UTC
(In reply to Juraj Lutter from comment #23)

Great! Thank you!
Comment 25 Juraj Lutter freebsd_committer freebsd_triage 2020-10-06 20:02:59 UTC
As I am not a committer, can this PR be assigned to me?
Comment 26 Kurt Jaeger freebsd_committer freebsd_triage 2020-10-06 21:17:35 UTC
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 ?
Comment 27 Dan Mahoney 2021-03-02 05:40:47 UTC
Juraj,

Would you like to send me what you've got?  I've got a renewed interest in this.

-Dan
Comment 28 Dan Mahoney 2021-03-02 10:13:30 UTC
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
Comment 29 Juraj Lutter freebsd_committer freebsd_triage 2021-03-02 10:36:04 UTC
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.
Comment 30 Dan Mahoney 2021-03-03 07:04:16 UTC
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.
Comment 31 Dan Mahoney 2021-03-03 20:49:59 UTC
Created attachment 222951 [details]
New racadm9 port to install 9.5
Comment 32 Dan Mahoney 2021-03-03 20:56:28 UTC
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.
Comment 33 Dan Mahoney 2021-03-03 20:59:58 UTC
Created attachment 222953 [details]
new non-truncated racadm9.shar

New racadm9 shar for racadm7 version 9.5
Comment 34 Kurt Jaeger freebsd_committer freebsd_triage 2021-06-20 13:29:49 UTC
(In reply to Dan Mahoney from comment #33)
I've extracted the shar. It builds using make, but poudriere fails to build
it,
Comment 35 Kurt Jaeger freebsd_committer freebsd_triage 2021-06-20 13:32:31 UTC
(In reply to Dan Mahoney from comment #33)
One thing: is this racadm7 or racadm9 ?
Comment 36 Dan Mahoney 2021-07-23 23:21:05 UTC
(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.
Comment 37 Dan Mahoney 2021-12-22 07:57:41 UTC
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