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