Date: Wed, 19 Sep 2018 10:58:48 -0300 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: Letting start sshd in an early stage on ARM devices Message-ID: <26263F22-B714-4992-B900-3BAC0A841A3C@obsigna.com> In-Reply-To: <1537362462.90006.53.camel@freebsd.org> References: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> <1537362462.90006.53.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 19.09.2018 um 10:07 schrieb Ian Lepore <ian@freebsd.org>: >=20 > 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=20= >> with a BeagleBone Black running FreeBSD 12.0-ALPHA5. >>=20 >> 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.=20 >>=20 >> 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. >>=20 >> For testing purposes, I changed the sshd rc script by replacing the >> line starting with # REQUIRE: ... by: >>=20 >> # REQUIRE: ipfw >> # BEFORE: mountcritremote >>=20 >> 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. >>=20 >> 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. >>=20 >> Best regards >>=20 >> Rolf >=20 > 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... >=20 > 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: >=20 > # 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. >=20 > 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. >=20 > 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. >=20 > 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, I appreciate your insights and your response. I completely agree = with your final comment, and actually that's the reason why I did not = raise a general PR, and I even don't want to ask for a general change in = the rc order. My embedded systems come with a number of other = customizations, and in the meantime I already put said changes to = /etc/rc.d/sshd into the list of sed commands to be applied when = setting-up a new system from the scratch.=20 That I did not care to much for a general case, you might see from that = I put ipfw as the requirement. The desktop folks seem to prefer pf = nowadays. So basically, I am fine with the need of customization. My = question was more about possible adverse implications in respect to the = given embedded use case - one filesystem, two users root/rolf, with home = directories on the root fs - in the given respect, opinions of FreeBSD = desktop users would withdraw the focus, and therefore I raised the issue = on this list.=20 You listed the general reasons on why sshd starts almost last. I will = not dispute that. However, I see that the ssh daemon which is launched = by the rc script is the mother daemon, i.e. the listener and initial = first responder on the ssh port, which spawns sshd childs on each login = request. My take on this is, that FILESYSTEM and LOGIN need not to be = for the mother but must be present for the spawned childs in order = somebody with home on late file systems could actually login. If the = mother sshd is up and running already but cannot spawn childs because = other pre-requisites are not yet ready, so what? The user can't login = unless NFS, ZFS, etc. is up and running, and in the current situation he = can't either. Anyway, once again, all this is more from the point of view of headless = systems (my FreeBSD servers, and the BBB - I don't have much experience = with FreeBSD desktop systems). I will keep my changes for the time being, if I experience some bad = effects, I will report back. Many thanks best regards Rolf=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26263F22-B714-4992-B900-3BAC0A841A3C>