Date: Wed, 19 Sep 2018 11:35:23 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Ian Lepore <ian@freebsd.org> Cc: "Dr. Rolf Jansen" <rj@obsigna.com>, freebsd-arm@freebsd.org Subject: Re: Letting start sshd in an early stage on ARM devices Message-ID: <8762DFEB-5DF1-4096-ABA8-43DE4E592934@gromit.dlib.vt.edu> 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
On Sep 19, 2018, at 9:07 AM, Ian Lepore <ian@freebsd.org> wrote: > 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. I agree with the above rationale. Unfortunately, the ordering produced = by rcorder wrt. things run after $early_late_divider (FILESYSTEMS) is = quite loose. Here is the output I get from "rcorder /etc/rc.d/* = /usr/local/etc/rc.d/*" on a regular 12-CURRENT system I have: /etc/rc.d/growfs /etc/rc.d/sysctl /etc/rc.d/hostid /etc/rc.d/zvol /etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/ccd /etc/rc.d/swap /etc/rc.d/fsck /etc/rc.d/root /etc/rc.d/mdconfig /etc/rc.d/hostid_save /etc/rc.d/mountcritlocal /etc/rc.d/zfsbe /etc/rc.d/zfs /etc/rc.d/var /etc/rc.d/cleanvar /etc/rc.d/FILESYSTEMS /etc/rc.d/ldconfig /etc/rc.d/kldxref /etc/rc.d/kld /etc/rc.d/addswap /etc/rc.d/adjkerntz /etc/rc.d/hostname /etc/rc.d/ip6addrctl /etc/rc.d/netoptions /etc/rc.d/opensm /etc/rc.d/random /etc/rc.d/sppp /etc/rc.d/ipfilter /etc/rc.d/ipnat /etc/rc.d/ipfs /etc/rc.d/serial /etc/rc.d/iovctl /etc/rc.d/netif /etc/rc.d/devd /etc/rc.d/ipsec /etc/rc.d/pfsync /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/stf /etc/rc.d/ppp /etc/rc.d/routing /etc/rc.d/ipfw /etc/rc.d/netwait /etc/rc.d/resolv /etc/rc.d/local_unbound /etc/rc.d/nsswitch /etc/rc.d/routed /etc/rc.d/rtsold /etc/rc.d/static_ndp /etc/rc.d/static_arp /etc/rc.d/bridge /etc/rc.d/route6d /etc/rc.d/defaultroute /etc/rc.d/NETWORKING /etc/rc.d/mountcritremote /etc/rc.d/dmesg /etc/rc.d/devfs /etc/rc.d/ipmon /etc/rc.d/kdc /etc/rc.d/mdconfig2 /etc/rc.d/newsyslog /etc/rc.d/syslogd /usr/local/etc/rc.d/microcode_update /etc/rc.d/watchdogd /etc/rc.d/savecore /etc/rc.d/archdep /etc/rc.d/abi /etc/rc.d/SERVERS /usr/local/etc/rc.d/vm /usr/local/etc/rc.d/uuidd /etc/rc.d/accounting /etc/rc.d/ntpdate /etc/rc.d/rpcbind /etc/rc.d/nfsclient /etc/rc.d/nisdomain /etc/rc.d/ypserv /etc/rc.d/ypbind /etc/rc.d/ypset /etc/rc.d/amd /etc/rc.d/auditd /etc/rc.d/auditdistd /etc/rc.d/automountd /etc/rc.d/automount /etc/rc.d/autounmountd /etc/rc.d/tmp /etc/rc.d/cleartmp /etc/rc.d/ctld /usr/local/etc/rc.d/tpmd /usr/local/etc/rc.d/tcsd /etc/rc.d/hastd /etc/rc.d/iscsid /etc/rc.d/iscsictl /etc/rc.d/keyserv /etc/rc.d/nfsuserd /etc/rc.d/gssd /etc/rc.d/quota /etc/rc.d/mountd /etc/rc.d/nfsd /etc/rc.d/statd /etc/rc.d/lockd /etc/rc.d/pppoed /etc/rc.d/pwcheck /etc/rc.d/virecover /etc/rc.d/ypldap /usr/local/etc/rc.d/apcupsd /etc/rc.d/DAEMON /usr/local/etc/rc.d/transmission /usr/local/etc/rc.d/tftpd /etc/rc.d/apm /etc/rc.d/bootparams /etc/rc.d/hcsecd /etc/rc.d/bthidd /etc/rc.d/local /etc/rc.d/lpd /etc/rc.d/motd /etc/rc.d/mountlate /etc/rc.d/nscd /etc/rc.d/ntpd /etc/rc.d/powerd /etc/rc.d/rarpd /etc/rc.d/rctl /etc/rc.d/sdpd /etc/rc.d/rfcomm_pppd_server /etc/rc.d/rtadvd /etc/rc.d/rwho /etc/rc.d/timed /etc/rc.d/ugidfw /etc/rc.d/utx /etc/rc.d/yppasswdd /usr/local/etc/rc.d/qbittorrent-nox /etc/rc.d/LOGIN <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D /usr/local/etc/rc.d/smartd /usr/local/etc/rc.d/salt_syndic /usr/local/etc/rc.d/salt_proxy /usr/local/etc/rc.d/salt_minion /usr/local/etc/rc.d/salt_master /usr/local/etc/rc.d/salt_api /usr/local/etc/rc.d/rsyncd /usr/local/etc/rc.d/poudriered /usr/local/etc/rc.d/dovecot /usr/local/etc/rc.d/postfix /usr/local/etc/rc.d/nginx /usr/local/etc/rc.d/miniupnpc /usr/local/etc/rc.d/ktrace.out /etc/rc.d/sshd <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D /usr/local/etc/rc.d/iocage /usr/local/etc/rc.d/inadyn-mt /usr/local/etc/rc.d/inadyn /usr/local/etc/rc.d/git_daemon /usr/local/etc/rc.d/couchpotato /usr/local/etc/rc.d/armv6hf /etc/rc.d/zfsd /etc/rc.d/ypxfrd /etc/rc.d/ypupdated /etc/rc.d/wpa_supplicant /etc/rc.d/ubthidhci /etc/rc.d/syscons /etc/rc.d/swaplate /etc/rc.d/sendmail /etc/rc.d/cron /etc/rc.d/jail /etc/rc.d/localpkg /etc/rc.d/securelevel /etc/rc.d/power_profile /etc/rc.d/othermta /etc/rc.d/nfscbd /etc/rc.d/natd /etc/rc.d/msgs /etc/rc.d/moused /etc/rc.d/mixer /etc/rc.d/kpasswdd /etc/rc.d/kfd /etc/rc.d/kadmind /etc/rc.d/ipropd_slave /etc/rc.d/ipropd_master /etc/rc.d/ipfw_netflow /etc/rc.d/inetd /etc/rc.d/hostapd /etc/rc.d/gptboot /etc/rc.d/geli2 /etc/rc.d/ftpd /etc/rc.d/ftp-proxy /etc/rc.d/dhclient /etc/rc.d/devmatch /etc/rc.d/cfumass /etc/rc.d/bsnmpd /etc/rc.d/bluetooth /etc/rc.d/blacklistd /etc/rc.d/bgfsck Although /etc/rc.d/sshd has "REQUIRE: LOGIN FILESYSTEMS", it ends up a = while past LOGIN in the execution, presumably because a lot of the other = services also just "REQUIRE: LOGIN FILESYSTEMS". I'm not saying what = rcorder is doing is wrong, as presumably the ordering criteria are all = being correctly fulfilled. But, the granularity is loose enough that it = results in a lot of services being given equal priority in the startup = ordering. (It's odd that it isn't refined to prioritise base OS = services above local services in the case of ties.) There are some other oddities I noticed. For example, /etc/rc.d/zfsd = ends up being run rather late in the day, despite only having "REQUIRE: = devd zfs". In the ordering, /etc/rc.d/zfs is listed shortly before = /etc/rc.d/FILESYSTEMS, and /etc/rc.d/devd comes before = /etc/rc.d/NETWORKING. That is before the other big milestones of = /etc/rc.d/SERVERS, /etc/rc.d/DAEMON, and /etc/rc.d/LOGIN, so it's = puzzling why /etc/rc.d/zfsd only ends up appearing after = /etc/rc.d/LOGIN, when it could be listed any time after /etc/rc.d/devd. = As I said, it is correct: it could be listed last and still fulfil its = requirements. I presume this is tied up in the way rcorder implements = its dependency sorting algorithm. Perhaps the lack of granularity is why /etc/rc.d/sshd doesn't start up = ASAP. (In the above case it has to wait until services such as Salt, = Dovecot, Postfix, and Nginx start up.) Maybe the previously-mentioned = OpenRC may not only address the granularity problem but also render it = moot by allowing parallel startup of dependency "ties". I agree with = the OP, though, that it would be nice to have SSHD start ASAP. Cheers, Paul.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8762DFEB-5DF1-4096-ABA8-43DE4E592934>