Bug 201799 - [NEW PORT] sysutils/racadm: Dell remote access controller admin utility
Summary: [NEW PORT] sysutils/racadm: Dell remote access controller admin utility
Status: Open
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
Keywords: feature, needs-qa, patch
Depends on:
Reported: 2015-07-23 18:31 UTC by gekkey
Modified: 2020-10-06 21:17 UTC (History)
11 users (show)

See Also:

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

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]
Comment 2 gekkey 2015-08-19 01:20:31 UTC
Created attachment 160000 [details]
Comment 3 gekkey 2015-08-21 20:23:14 UTC
Created attachment 160190 [details]
Comment 4 gekkey 2015-09-03 18:52:30 UTC
Created attachment 160689 [details]
Comment 5 Matthew Seaman freebsd_committer 2015-11-16 17:34:20 UTC

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

Comment 10 Dan Mahoney 2017-07-21 11:05:20 UTC
Created attachment 184567 [details]

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

Comment 21 Juraj Lutter 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 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 2020-09-28 14:15:17 UTC
Yes, please.
Comment 24 Mateusz Piotrowski freebsd_committer 2020-10-06 14:06:38 UTC
(In reply to Juraj Lutter from comment #23)

Great! Thank you!
Comment 25 Juraj Lutter 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 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 ?