From nobody@FreeBSD.org  Sat Dec 31 04:14:15 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A53331065676
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 31 Dec 2011 04:14:15 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 936EF8FC25
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 31 Dec 2011 04:14:15 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pBV4EFkY098180
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 31 Dec 2011 04:14:15 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id pBV4EFdb098152;
	Sat, 31 Dec 2011 04:14:15 GMT
	(envelope-from nobody)
Message-Id: <201112310414.pBV4EFdb098152@red.freebsd.org>
Date: Sat, 31 Dec 2011 04:14:15 GMT
From: Devin Teske <dteske@vicor.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: The mountlate rc.d boot script cannot be disabled
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         163727
>Category:       conf
>Synopsis:       [rc.d] [patch] The mountlate rc.d boot script cannot be disabled
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    dougb
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Dec 31 04:20:10 UTC 2011
>Closed-Date:    Sat Dec 31 07:58:41 UTC 2011
>Last-Modified:  Sat Dec 31 15:50:12 UTC 2011
>Originator:     Devin Teske
>Release:        FreeBSD 8.1-RELEASE-p6 i386
>Organization:
FIS Global, Inc.
>Environment:
FreeBSD kxt2a.jbsd.vicor.com 8.1-RELEASE-p6 FreeBSD 8.1-RELEASE-p6 #15: Wed Dec 7 11:08:51 PST 2011
dteske@ipm0.vbsd.vicor.com:/usr/src/sys/i386/compile/FIS i386
>Description:
For those headless systems that are administered remotely, sometimes thousands-of-miles away, we find ourselves needing to disable the mountlate rc.d boot script. Otherwise, there exists no-less than half-a-dozen scenarios that can cause the system to boot into single-user mode -- many of which are out-of-control of the system itself and may even be part of a Denial-of-Service (DoS) attack. For example, if the host has NFS mounts and the DNS server is "taken out," the next time it reboots, the host will hang forever at the single-user mode prompt.

Attached is a patch to HEAD that we similarly apply internally to all systems, allowing us to disable the mountlate feature. We lose the ability to mount any filesystem in the fstab(5) configuration, but that's something we're glad to relinquish in-favor of the ability to build systems that eventually get into multi-user mode. In testing, all edge-cases produce a multi-user system after some eventual length of timeouts reached when network filesystems (NFS/SMB/etc.) are configured in fstab(5).
>How-To-Repeat:
Configure any number of network filesystems in fstab(5). Use both IP addresses and DNS names.

1. Test-case #1: Move /etc/resolv.conf aside and reboot. The system boots into single-user mode because DNS names will fail to resolve.

2. Test-case #2: Disconnect one of the machines that provides any of the network filesystems configured. Reboot. The system boots into single-user mode because the mounts fail.

3. Test-case #3: Disconnect the DNS server. Reboot. Like #1, the system will [eventually] boot into single--user mode.

Other scenarios exist but range from being very hardware specific to being sporadic in nature.

After applying the attached patch, adding mountlate_enable="NO" to rc.conf(5) and rebooting, all test-cases [eventually] produce a multi-user system and you can ssh(1) into the remote system.

Without this patch, it may require physical access (if a remote serial console is not configured/attached) to resume multi-user mode when the mountlate boot script stops the boot process for failed network mounts (late or otherwise).

The attached patch simply allows the system administrator the choice to disable this boot script, sacrificing "late" filesystems but gaining the ability to prevent network filesystem failure from dropping the system into single-user mode.
>Fix:
--- etc/defaults/rc.conf.orig   Fri Dec  2 11:21:08 2011
+++ etc/defaults/rc.conf        Fri Dec  2 11:22:31 2011
@@ -93,6 +93,7 @@
netfs_types="nfs:NFS oldnfs:OLDNFS smbfs:SMB portalfs:PORTAL nwfs:NWFS" # Net
filesystems.
extra_netfs_types="NO" # List of network extra filesystem types for delayed
                       # mount at startup (or NO).
+mountlate_enable="YES" # Mount critical late/remaining filesystems in fstab(5)

##############################################################
###  Network configuration sub-section  ######################
--- etc/rc.d/mountlate.orig     Fri Dec  2 11:19:51 2011
+++ etc/rc.d/mountlate  Fri Dec  2 11:20:28 2011
@@ -11,6 +11,7 @@
. /etc/rc.subr

name="mountlate"
+rcvar="`set_rcvar`"
start_cmd="mountlate_start"
stop_cmd=":"


>Release-Note:
>Audit-Trail:

State-Changed-From-To: open->closed 
State-Changed-By: dougb 
State-Changed-When: Sat Dec 31 07:54:00 UTC 2011 
State-Changed-Why:  

1. What you're talking about is an extreme edge case. If you can't figure 
out how to properly configure these systems, then simply removing the script 
from /etc/rc.d is enough. 

2. Don't attempt to mount critical remote file systems using DNS names. This 
has been true for as long as I can remember.  

3. If you have critical remote systems that you can't afford to have hang 
in single user mode, put a serial console on them. 

Meta-notes: 

1. I obeyed your disclaimer text and removed the second patch that you sent. 

2. It hasn't been "rcng" for a long time now. The preferred term is rc.d. 


Responsible-Changed-From-To: freebsd-rc->dougb 
Responsible-Changed-By: dougb 
Responsible-Changed-When: Sat Dec 31 07:54:00 UTC 2011 
Responsible-Changed-Why:  

I'm closing this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=163727 

From: Jilles Tjoelker <jilles@stack.nl>
To: bug-followup@FreeBSD.org, dteske@vicor.com
Cc:  
Subject: Re: conf/163727: [rc.d] [patch] The mountlate rc.d boot script
 cannot be disabled
Date: Sat, 31 Dec 2011 15:55:05 +0100

 > [mountlate may fail boot -> single user mode]
 
 Aren't the failok and bg mount options designed for this?
 
 -- 
 Jilles Tjoelker

From: Devin Teske <devin.teske@fisglobal.com>
To: Jilles Tjoelker <jilles@stack.nl>
Cc: <bug-followup@FreeBSD.org>, <dteske@vicor.com>
Subject: Re: conf/163727: [rc.d] [patch] The mountlate rc.d boot script cannot be disabled
Date: Sat, 31 Dec 2011 07:43:05 -0800

 --Apple-Mail-4--853365532
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain; charset="us-ascii"
 
 
 On Dec 31, 2011, at 6:55 AM, Jilles Tjoelker wrote:
 
 >> [mountlate may fail boot -> single user mode]
 >=20
 > Aren't the failok
 
 Never heard of "failok".
 
 It doesn't seem to be documented anywhere.
 
 I can't even find any uses of it -- not on 8.1 or 9.0-CURRENT (snapshot 05-=
 2011) at least.
 
 
 > and bg mount options designed for this?
 
 As discussed here:
 http://lists.freebsd.org/pipermail/freebsd-rc/2011-December/002527.html
 
 and here:
 http://lists.freebsd.org/pipermail/freebsd-rc/2011-December/002531.html
 
 the "bg" option does not do what is intended when the hostid cannot be reso=
 lved.
 
 The "bg" option only works if (a) the hostid is resolvable at boot time and=
  (b) the mount fails due to a timeout.
 
 If instead the hostid cannot be resolved, single-user mode you go.
 --=20
 Devin
 
 _____________
 The information contained in this message is proprietary and/or confidentia=
 l. If you are not the intended recipient, please: (i) delete the message an=
 d all copies; (ii) do not disclose, distribute or use the message in any ma=
 nner; and (iii) notify the sender immediately. In addition, please be aware=
  that any message addressed to our domain is subject to archiving and revie=
 w by persons other than the intended recipient. Thank you.
 
 --Apple-Mail-4--853365532
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/html; charset="us-ascii"
 
 <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:=
  space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 31, 2=
 011, at 6:55 AM, Jilles Tjoelker wrote:</div><br class=3D"Apple-interchange=
 -newline"><blockquote type=3D"cite"><div><blockquote type=3D"cite">[mountla=
 te may fail boot -&gt; single user mode]<br></blockquote><br>Aren't the fai=
 lok</div></blockquote><div><br></div><div>Never heard of "failok".</div><di=
 v><br></div><div>It doesn't seem to be documented anywhere.</div><div><br><=
 /div><div>I can't even find any uses of it -- not on 8.1 or 9.0-CURRENT (sn=
 apshot 05-2011) at least.</div><div><br></div><br><blockquote type=3D"cite"=
 ><div> and bg mount options designed for this?<br></div></blockquote><div><=
 br></div><div>As discussed here:</div><div><div><a href=3D"http://lists.fre=
 ebsd.org/pipermail/freebsd-rc/2011-December/002527.html">http://lists.freeb=
 sd.org/pipermail/freebsd-rc/2011-December/002527.html</a></div><div><br></d=
 iv></div><div>and here:</div><div><a href=3D"http://lists.freebsd.org/piper=
 mail/freebsd-rc/2011-December/002531.html">http://lists.freebsd.org/piperma=
 il/freebsd-rc/2011-December/002531.html</a></div><div><br></div><div>the "b=
 g" option does not do what is intended when the hostid cannot be resolved.<=
 /div><div><br></div><div>The "bg" option only works if (a) the hostid is re=
 solvable at boot time and (b) the mount fails due to a timeout.</div><div><=
 br></div><div>If instead the hostid cannot be resolved, single-user mode yo=
 u go.</div><div>--&nbsp;</div><div>Devin</div></div>
 <DIV>
 _____________<BR>
 The information contained in this message is proprietary and/or confidentia=
 l. If you are not the intended recipient, please: (i) delete the message an=
 d all copies; (ii) do not disclose, distribute or use the message in any ma=
 nner; and (iii) notify the sender immediately. In addition, please be aware=
  that any message addressed to our domain is subject to archiving and revie=
 w by persons other than the intended recipient. Thank you.<BR>
 </DIV></body></html>
 
 --Apple-Mail-4--853365532--
>Unformatted:
