Re: MegaCLI port is ports-only -- how would you deploy it?

Reply: Ed Maste : "Re: MegaCLI port is ports-only -- how would you deploy it?"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Doug Ambrisko <ambrisko_at_ambrisko.com>
Date: Tue, 16 Aug 2022 00:02:19 UTC
On Sat, Aug 13, 2022 at 10:41:33PM -0400, Dan Mahoney wrote:
| 
| 
| > On Aug 12, 2022, at 12:35, Doug Ambrisko <ambrisko@ambrisko.com> wrote:
| > 
| > On Fri, Aug 12, 2022 at 12:32:56PM -0400, Dan Mahoney wrote:
| > | 
| > | 
| > | > On Aug 12, 2022, at 12:31, Doug Ambrisko <ambrisko@ambrisko.com> wrote:
| > | > 
| > | > On Fri, Aug 12, 2022 at 12:21:36PM -0400, Dan Mahoney wrote:
| > | > | 
| > | > | > On Aug 8, 2022, at 16:45, Doug Ambrisko <ambrisko@ambrisko.com> wrote:
| > | > | > 
| > | > | > On Mon, Aug 08, 2022 at 04:10:10PM -0400, Dan Mahoney wrote:
| > | > | > | 
| > | > | > | 
| > | > | > | > On Aug 8, 2022, at 15:57, Doug Ambrisko <ambrisko@ambrisko.com> wrote:
| > | > | > | > 
| > | > | > | > On Thu, Aug 04, 2022 at 05:22:29PM +0300, Ruslan Makhmatkhanov wrote:
| > | > | > | > |    03.08.2022, 02:07, "Dan Mahoney" <freebsd@gushi.org>:
| > | > | > | > |      Hey there all,
| > | > | > | > |      At the dayjob we have a fleet of Dell Poweredge servers that can use
| > | > | > | > |      either mptsas or mrsas -- if you use mptsas, you use mptutil (in
| > | > | > | > |      base) to check the state of the card.
| > | > | > | > |      If you use mrsas, you need megacli, which is only in ports, and the
| > | > | > | > |      port hasn't translated to pkg probably because of license
| > | > | > | > |      restrictions. ( _LICENSE_RESTRICTED = delete-package
| > | > | > | > |      delete-distfiles), but the license listed is just "megacli".
| > | > | > | > |      * We want to deploy a cron job to periodically check the raid status
| > | > | > | > |      (we're writing a wrapper, also having it check mfiutil, zpool, etc).
| > | > | > | > |      * We do not want to install and manage a whole ports tree on every
| > | > | > | > |      machine in our fleet, just to install a raid utlity.
| > | > | > | > |      Option A:
| > | > | > | > |      Make a local package somehow.
| > | > | > | > |      The port just downloads a static binary, there's nothing to build
| > | > | > | > |      here, but we want to do this the "right" way. Is there some way to
| > | > | > | > |      have pkg deploy a single local package for this that will, for
| > | > | > | > |      example, report the right package ownership, without moving every
| > | > | > | > |      other package to our poudriere install (we're just using base
| > | > | > | > |      packages, we keep poudriere around for testing in case we need to
| > | > | > | > |      hot-patch something).
| > | > | > | > |      For what it's worth, we use puppet for config management, so pushing
| > | > | > | > |      out the static binary is not the worst answer, but it also feels
| > | > | > | > |      "dirty".
| > | > | > | > |      Option B:
| > | > | > | > |      Figure out how to fix the license. I have no idea what this would
| > | > | > | > |      involve.
| > | > | > | > |      Option C:
| > | > | > | > |      Also, apparently MegaCLI is no longer maintained (replaced by
| > | > | > | > |      StorCLI), but there's no port for StorCLI, and...there are multiple
| > | > | > | > |      raid-card specific versions? Jeez.
| > | > | > | > |      Feels even more dirty.
| > | > | > | > |      [1]https://support.siliconmechanics.com/portal/en/kb/articles/storcl
| > | > | > | > |      i-for-freebsd-and-other-operating-systems
| > | > | > | > |      Ideas welcome?
| > | > | > | > |      -Dan Mahoney
| > | > | > | > 
| > | > | > | > Although the path to get to StorCli goes through various cards the
| > | > | > | > latest greatest seem to work on all earlier cards.  It works on
| > | > | > | > HBAs and not just RAID cards.  At work I did a Linux/FreeBSD
| > | > | > | > POC for FW management and found the FreeBSD version could flash the HBA
| > | > | > | > and drive FW.  I've moved to StorCli from MegaCli.  I would suggest
| > | > | > | > we drop the MegaCli port and move to StorCli.
| > | > | > | > 
| > | > | > | > I have code to make mfiutil into mrsasutil and added the MFI ioctl
| > | > | > | > handler to mrsas.  I'm not sure how much value that has.  I don't
| > | > | > | > deal with supporting FreeBSD and RAID much anymore.  If interested
| > | > | > | > I could send patches.
| > | > | > | 
| > | > | > | This feels like it should be in base, regardless.  Just *something* to 
| > | > | > | query the raid status and health, even if it doesn't ring all the bells 
| > | > | > | of StorCLI.
| > | > | > | 
| > | > | > | Right now, you can do this with the older mfi, but not the newer mrsas, 
| > | > | > | which performs better in some cases, which leaves an admin with a 
| > | > | > | dilemma: better reliability, or better manageability.
| > | > | > | 
| > | > | > | I also feel like this could be added to a minor release (i.e. a 
| > | > | > | 12.3 --> 12.4 or a 13.0 --> 13.1), but obviously that decision is above me.
| > | > | > 
| > | > | > This is based of -current.  I haven't tested it recently:
| > | > | > 	https://people.freebsd.org/~ambrisko/git.mrsas_support_in_mfiutil.patch
| > | > | > 
| > | > | > Please give it a try.  You will need a new kernel built and booted to
| > | > | > provide the needed ioctl support.  It should be close to committable.
| > | > | 
| > | > | Doug,
| > | > | 
| > | > | I'm trying this out on 12.x and 13.x just for funsies, but given the 
| > | > | release schedule, it's unlikely that there'll be a 12.4 or a 13.2 that 
| > | > | this would make it into.  Regardless, I've opened a bug report to get 
| > | > | this added *somewhere* which may cause other people to try it out and test.
| > | > 
| > | > I'd have to put in -current first then look at MFC later on.  If looks
| > | > good for you then I'll put it up for review.  I just don't use this
| > | > stuff day to day anymore.
| > | 
| > | Yeah, most of our dayjob work is running critical DNS infrastructure, so 
| > | there's not a lot of -current there, but I can get permission to play 
| > | with it on a spare system.
| > 
| > It should apply to earlier releases, since there hasn't been a lot of
| > changes in this area.  So you can try that if that is easier.  I did
| > this code a long time ago probably in 10.X and have been moving it
| > forward.
| 
| I've confirmed that it shows drive status and array status on my R430 
| running FreeBSD 14.0-CURRENT #0 main-n257330-88951aaaee7-dirty in mrsas mode.
 
Along the way, I dropped:
diff --git a/usr.sbin/mfiutil/Makefile b/usr.sbin/mfiutil/Makefile
index dc6f3e48159..139e31d6c41 100644
--- a/usr.sbin/mfiutil/Makefile
+++ b/usr.sbin/mfiutil/Makefile
@@ -1,10 +1,12 @@
 # $FreeBSD$
 PROG=	mfiutil
+LINKS=	${BINDIR}/mfiutil ${BINDIR}/mrsasutil
 
 SRCS=	mfiutil.c mfi_bbu.c mfi_cmd.c mfi_config.c mfi_drive.c mfi_evt.c \
 	mfi_flash.c mfi_patrol.c mfi_show.c mfi_volume.c mfi_foreign.c \
 	mfi_properties.c
 MAN8=	mfiutil.8
+MLINKS=	mfiutil.8 mrsasutil.8
 
 CFLAGS.gcc+= -fno-builtin-strftime

That should make the links for mrsasutil.
 
| As currently built, the kernel makefiles do not install it as mrsasutil, 
| and this is a manual copy.  I think that would need to be fixed to make it 
| mergeable, but I think it should happen.
| 
| I've opened this PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265794
| 
| At this point, the ports- list is probably off-topic for this, but this 
| conversation should definitely continue.

Switched to -current.

Doug A.