From owner-freebsd-arm@freebsd.org Wed Sep 19 09:43:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8853D1095552 for ; Wed, 19 Sep 2018 09:43:51 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A87479EEE for ; Wed, 19 Sep 2018 09:43:51 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: brd/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 162A2129D6 for ; Wed, 19 Sep 2018 09:43:51 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 9547221B35 for ; Wed, 19 Sep 2018 05:43:50 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Wed, 19 Sep 2018 05:43:50 -0400 X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 269844204; Wed, 19 Sep 2018 05:43:50 -0400 (EDT) Message-Id: <1537350230.279314.1513235480.66B5E703@webmail.messagingengine.com> From: Brad Davis To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e556cd15 Subject: Re: Letting start sshd in an early stage on ARM devices Date: Wed, 19 Sep 2018 03:43:50 -0600 References: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> In-Reply-To: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 09:43:51 -0000 On Tue, Sep 18, 2018, at 6:48 PM, Dr. Rolf Jansen wrote: > Last week I had the first official presentation of my ADC/DAC-project > with a BeagleBone Black running FreeBSD 12.0-ALPHA5. > > I experienced a problem with the NFS client, which was sort of home made > problem, because in the hurry I forgot to deactivate the mount-directive > of a nfs share in fstab, and when I started the BBB before the > presentation, it was not connected to it's home-network and it hang at > that point. I built it into a very tight box and there was no place > anymore for the FTDI serial connector, and since sshd is usually loaded > as one of the last services, I was effectively locked out of the BBB. > Fortunately, I overcame the problem by simulating the nfs share with my > notebook and after restart, I was able to fix the fstab right before the > actual presentation began, so nobody saw that I had a problem - anyway, > I would prefer to never become that nervous again. > > My question is now, why is sshd set to start so very late in the booting > process? If we want to put autonomous ARM devices somewhere into the > field, then any hick-up in the startup sequence would leave us out- > locked. > > For testing purposes, I changed the sshd rc script by replacing the line > starting with # REQUIRE: ... by: > > # REQUIRE: ipfw > # BEFORE: mountcritremote > > Now, sshd starts right after ipfw has been set up, and in case the BBB > hangs, e.g. in the course of mounting a nfs share, I am still able to > login via ssh and fix most of the issues. > > I would like to leave it like this (at least on the headless ARM > devices). Are there any risks or hidden problems which I might > experience, when having sshd running very early in the boot sequence? Of > course after any FreeBSD update, I would need to check the sshd rc > script. I have had this pain before as well. My case was apache starting before sshd with a passphrase on the cert hanging the rc script. It seems like this will be solved by the import of OpenRC as that will allow for parallel start up. Regards, Brad Davis