From owner-freebsd-arm@freebsd.org Wed Sep 19 13:23:55 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 6C50C109B0F5 for ; Wed, 19 Sep 2018 13:23:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBD1B809DD for ; Wed, 19 Sep 2018 13:23:54 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: fe323303-bc0c-11e8-a70c-1d534e3451d5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id fe323303-bc0c-11e8-a70c-1d534e3451d5; Wed, 19 Sep 2018 13:07:44 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w8JD7gjR063247; Wed, 19 Sep 2018 07:07:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1537362462.90006.53.camel@freebsd.org> Subject: Re: Letting start sshd in an early stage on ARM devices From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org Date: Wed, 19 Sep 2018 07:07:42 -0600 In-Reply-To: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> References: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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 13:23:55 -0000 On Tue, 2018-09-18 at 21:48 -0300, 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. > > Best regards > > Rolf I suspect you'd get better answers to this on a more generic mailing list such as -hackers or -current, because it's not really arm specific. Here's what I can figure out just looking at the scripts involved... The sshd script requires FILESYSTEMS and LOGIN.  The FILESYSTEMS requirement seems pretty important... people can't log in until things like /usr and /home are available. Using mountcritlocal instead would leave out ZFS, and that won't work for a lot of people.  The LOGIN requirement is explained like this in the script:  # This is a dummy dependency to ensure user services such as xdm,  # inetd, cron and kerberos are started after everything else, in case  # the administrator has increased the system security level and  # wants to delay user logins until the system is (almost) fully  # operational. That is probably important to some people. Other things that come before sshd because of LOGINS also seem important... things like syslogd and ntpd (must have valid timestamps on files and in logs before allowing users to do things).  Just in general, if you run "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*" and look at everything that shows up between FILESYSTEMS and LOGIN, you can see that in a general- purpose-computer setup, you want most of those things to happen before users are allowed onto the system. init(8) allows logins as the last thing that happens in system startup, after all rc.d scripts are done. Sshd (and similar things such as inetd and xdm/slim) are also ways of allowing logins, and it makes sense to me that they are also almost the very last thing that happens in rc processing. So it seems unlikely that this will ever change on the freebsd side. Sometimes embedded systems have needs that are completely different than general-purpose-computer and it's appropriate to do things like start sshd very early, but that's always going to end up being a custom modification that has to be made by the creator of the embedded system. -- Ian