From owner-freebsd-questions@freebsd.org Fri Jul 21 00:14:19 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C051CFF610 for ; Fri, 21 Jul 2017 00:14:19 +0000 (UTC) (envelope-from frank2@fjl.co.uk) Received: from bs1.fjl.org.uk (bs1.fjl.org.uk [84.45.41.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bs1.fjl.org.uk", Issuer "bs1.fjl.org.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C27A981E95 for ; Fri, 21 Jul 2017 00:14:18 +0000 (UTC) (envelope-from frank2@fjl.co.uk) Received: from [192.168.1.35] (host86-191-18-76.range86-191.btcentralplus.com [86.191.18.76]) (authenticated bits=0) by bs1.fjl.org.uk (8.14.4/8.14.4) with ESMTP id v6L0EG9M073391 for ; Fri, 21 Jul 2017 01:14:16 +0100 (BST) (envelope-from frank2@fjl.co.uk) Subject: Re: Stop ZFS/opensolaris from autoloading? To: freebsd-questions@freebsd.org References: From: Frank Leonhardt Message-ID: Date: Fri, 21 Jul 2017 01:14:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 00:14:19 -0000 On 19/07/2017 03:31, Dan Mahoney, System Admin wrote: > On Tue, 18 Jul 2017, Frank Leonhardt wrote: > >> On 01/05/2017 00:17, Dan Mahoney wrote: >> Short of renaming the modules (which breaks upgrades and is >> unpredictable) is there any easy way to stop a system from >> auto-loading the ZFS >> modules? >> >> We've got some memory-constrained systems and the concept of >> "modules that load themselves" somewhat bugs me. >> >> I'd rather "zpool status" (which is often called by things like >> Facter) simply return an error than load a kernel module that will >> never be >> used. >> >> >> I've not had that problem myself, but my inclination would be to make >> sure it's not loaded or compiled in the kernel (obvious) and then simply >> rename/replace all the zxxxx executables with scripts that do what I >> want. Less intrusive fiddling that way. > > That also breaks freebsd-update. You're on to something, however. I > wonder if chmod'ing the appropriate files 000 will stop it, or > chmod'ing the kernel module 000. There are stronger ways of making files immutable but I don't think it's the way. Just run a script after the update: echo exit 1 >/sbin/zfs echo exit 1 >/sbin/zpool ... chmod a+x /sbin/z* You could even put it in rc.local and have it re-patched every time you boot. I do something similar for modifications; it helps to keep a record of everything that's changed in a system in one place for all sorts of reasons. For example, I put a wrapper around "shutdown" on remote servers so I don't accidentally "shutdown -p now" anything in a data centre. thinking I'm turning off my local box. Regards, Frank.