Headless installation (w/o monitor and keyboard, over ssh)

[cracauer@]

While I prepare the preliminary patch(1) file version 0.1 (MILESTONE 1: Usable with basic UNIX knowledge AND a UNIX machine to prepare the image (apply the patch)), anyone interested in this topic can
1. dive into the rc(8) scripts of the install image and figure out how to NOT start bsdinstall(8) on the console:
/usr/libexec/bsdinstall/runconsoles /usr/libexec/bsdinstall/startb...
is running. Instead we want that to run on our ssh(1) login, preferably dont start it before we login. And then
2. since we already have the network interface configured via DHCP, how to disable this step in bsdinstall(8)
Thx in advance!
P.S. I forgot: I'm using an install image of FreeBSD-15.0-STABLE (March, 12th IIRC). Usually there are no major differences in bsdinstall(8) to the preceding major version, but this time there are!

Thats's why I told you to use a proper install, configured with your user account, to boot the blind server. There is no need to use an installer image. sysinstall can be started from any installed system.

 

[Mjölnir]

Thats's why I told you to use a proper install, configured with your user account, to boot the blind server. There is no need to use an installer image. sysinstall can be started from any installed system.

You mean bsdinstall(8)? Hm yes, a minimal basic install where
sshd(8) runs as the only service after boot. Then we don't have to worry about breaking the install procedure, because it does not apply. IIUC that's exactly what mfsBSD does. So
1. I take mfsBSD,
2. it should be pretty easy to adopt for 14.4-REL or 15.0-STABLE,
3. create a user fbsdinstall
4. Enable DHCP,
5. Enable sshd(8)
that's it, it will be able to do what I want. I can remotely login as fbsdinst and start bsdinstall(8). Sorry I needed so long to catch it ...

 

[SirDice]

Look at how a vagrant image is set up.

 

[Mjölnir]

I “voted” no. How often do you need to (re‑)install FreeBSD per (headless) machine? This isn’t VVindoh’s, you know. For once in your life you can hook up the box to a keyboard and display.​

That's not the point. The point is that some innocent newbie might want to install FBSD on his/her headless box. My intention was to provide an install medium that they can download to do that. I can create it, you can create it, but most non-UNIX folk can't do it. They might be interested to give FBSD a try on their NAS box or such, but they can't install it because there is no headless install image they can download.

 

[JohnK]

"What may I do?" at length I cried,
Tired of the painful task.
The fairy quietly replied,
And said, "You must not ask."
~ Lewis Carroll

I say go for it. I'm growing tired of the "nay"'s and "no"'s. What is it to them?

 

[Mjölnir]

I say go for it. I'm growing tired of the "nay"'s and "no"'s. What is it to them?

That's a really nice short poem! I still have hope that FBSD becomes even more welcoming to interested newbies. At least AFAICT there has been a lot of improvement concerning this in the last decade.
Now I'm going to ask some Q how to set up my new box in another thread.

 

[sko]

Either use mfsBSD or mount a FreeBSD installer image (rw!), chroot into it and manually start sshd once (to generate the host ssh keys). Add your own public ssh key to /root/.ssh/known_hosts, edit /etc/ssh/sshd_config at will and then add sshd_enabled to rc.conf and a basic network configuration that suits your needs and the target host. Save, exit, dd to a usb disk and boot it. For a one-off installation this is still the quickest and easiest way IMHO.
After logging in via ssh you just start bsdinstall and proceed as with any other installation.

I haven't used either method for a while, since pretty much every system I've set up over the last years either was a real server with a BMC supporting console redirection (e.g. via web interface), some embedded platform with a serial console (for that you need to setup comconsole in loader.conf and maybe switch from vt to sc, since vt often tries to do fancy stuff that may lock up the serial console...) or a VM (bhyve) with direct console access.
I regularly used mfsBSD with some 'cloud-init'-like scripts to set up throwaway cloud instances for a while - if you have to do this more than once, this might also be an option as it is easily customizable and makes it pretty simple to produce up-to-date installer images without doing eveything from scratch over and over again.

RE the poll:
The installer images already have a headless mode: on systems without any graphics adapter it defaults to serial console. The problem with that is that most emulation layers for this in EFI firmwares are broken some way or another and need some tweaking.
Mounting the image and putting 1-2 lines in /boot/loader.conf isn't that hard - if one can't do that, they also won't be able to install, let alone set up and run a server anyways. (and sholdn't be allowed to - especially if its hooked up to the interwebs...)
So i voted "no" - it's already there and only needs to be adjusted for the actual use case. I don't think its worth wasting valuable developer time trying to make something that automagically catches each and every weird, ancient hardware reliably (how should it know which network interface you want it to use anyways? most servers have more than one...)

 

[cracauer@]

That's not the point. The point is that some innocent newbie might want to install FBSD on his/her headless box. My intention was to provide an install medium that they can download to do that. I can create it, you can create it, but most non-UNIX folk can't do it. They might be interested to give FBSD a try on their NAS box or such, but they can't install it because there is no headless install image they can download.

An innocent newbie would not even attempt this, they would drag a monitor and keyboard to the closet. Or get an IPMI capable mainboard.

How is a newbie going to figure out which IP address the thing lands on after USB boot?

 

[Mjölnir]

[...] I regularly used mfsBSD with some 'cloud-init'-like scripts to set up throwaway cloud instances for a while - if you have to do this more than once, this might also be an option as it is easily customizable and makes it pretty simple to produce up-to-date installer images without doing eveything from scratch over and over again. [...]

I'm with you 99%

[...] if one can't do that, they also won't be able to install, let alone set up and run a server anyways. (and sholdn't be allowed to - especially if its hooked up to the interwebs...) [...]

...except with this. These folks repairs our roofs, drill our teeths, etc. pp. They have every right on earth to have access to good IT stuff. I really think it's a matter of attitude. Why is Linux so omnipresent in consumer hardware? Because some guys understood how to make it accessible for non-IT-nerds. It would benefit FreeBSD if it's easier to access. Then the young kid that learns FBSD now could become a skilled kernel developer in 15-20 years.

How is a newbie going to figure out which IP address the thing lands on after USB boot?

All the DHCP servers I've seen on consumer hw let the client choose it's hostname. So then they could easily use the name (freebsd) instead of the IP#.