bsdinstall: Warn if hostname is empty

[ykla]

Warn if hostname is empty in bsdinstall.

See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286847

Signed-off-by: ykla [email protected]

[github-actions[bot]]

Thank you for taking the time to contribute to FreeBSD! There is an issue that needs to be fixed:

• Missing Signed-off-by lines^{c22e7dd34539cd704530b6fcaa2cc3f06ee21b46}

[concussious]

Hey ykla. I saw your forum post. I am super junior, so I am going to attempt to speak for the tribe, but please blame me alone if this is not correct, or written poorly.

I don't think anyone is ignoring you. Lots of people like to read the patches to see what's going on, but if it's not clear that what is being improved is needed, and it introduces regressions, the gut feeling is "no". People are trepidatious to say "no" repeatedly because they don't want to make a bad feeling or speak too soon.

I think we don't want this patch, the behavior has existed for a long time, and it's actually a big change for a very small corner case. It's not clear that this is a problem, and as Jessica said it would introduce a regression in some use cases in the last patch on this topic. Think about the security implications if there's a standard domain name for FreeBSD installations. There's a lot to make sure is going to be okay making a change like this, and there isn't agreement that this is a problem.

In FreeBSD we have a rule called Principle of Least Astonishment, which means there has to be a good reason to change the existing behavior. FreeBSD has a strong culture of maintaining existing behavior, that we really like a lot, and results in people thinking slowly about these kind of issues.

I think, and again, this is my feeling, please blame me alone if this is wrong; that nobody wants to tell you "we don't want this patch" right after closing the last one. People don't want to make a bad feeling, because everyone who works on this project does appreciate your interest. Myself included.

I just pushed this commit ^1 to the doc tree to try and clarify the handbook. Again, thank you for your contributions, I see you've been helping with the ports tree a lot.

[ykla]

Hey ykla. I saw your forum post. I am super junior, so I am going to attempt to speak for the tribe, but please blame me alone if this is not correct, or written poorly.

I don't think anyone is ignoring you. Lots of people like to read the patches to see what's going on, but if it's not clear that what is being improved is needed, and it introduces regressions, the gut feeling is "no". People are trepidatious to say "no" repeatedly because they don't want to make a bad feeling or speak too soon.

I think we don't want this patch, the behavior has existed for a long time, and it's actually a big change for a very small corner case. It's not clear that this is a problem, and as Jessica said it would introduce a regression in some use cases in the last patch on this topic. Think about the security implications if there's a standard domain name for FreeBSD installations. There's a lot to make sure is going to be okay making a change like this, and there isn't agreement that this is a problem.

In FreeBSD we have a rule called Principle of Least Astonishment, which means there has to be a good reason to change the existing behavior. FreeBSD has a strong culture of maintaining existing behavior, that we really like a lot, and results in people thinking slowly about these kind of issues.

I think, and again, this is my feeling, please blame me alone if this is wrong; that nobody wants to tell you "we don't want this patch" right after closing the last one. People don't want to make a bad feeling, because everyone who works on this project does appreciate your interest. Myself included.

I just pushed this commit ^1 to the doc tree to try and clarify the handbook. Again, thank you for your contributions, I see you've been helping with the ports tree a lot.

Hello, I’m not saying this because of any personal issue, nor am I complaining about a specific patch of mine not being accepted. If that were the case, everything would have ended three years ago. As I stated, the FreeBSD project currently needs change. Compared to patches that receive no replies for a year or even several years — and there are countless such reviews, most of which have already been thoroughly discussed and accepted but never committed — the situation is even worse when it comes to new port submissions.

I believe most people would prefer to simply receive a response, even just a “we can’t accept this, you need to do X” — any reply at all would be better. I believe it’s necessary to establish a working group dedicated to improving the experience for external contributors. This group should also work within a defined timeframe.

I understand that everyone is a volunteer, but if the FreeBSD project is to move forward, then someone must be willing to make greater sacrifices and put in more effort. I’ve noticed that most FreeBSD subprojects are being maintained by just a few individuals — such as Wi-Fi and the GNOME desktop — and this is a very unhealthy situation for the FreeBSD project as a whole.

We absolutely need young people to get involved. FreeBSD ultimately belongs to the younger generation. Without their participation, and without more external contributors becoming committers, nothing else can truly begin.

[bsdimp]

I agree.. we need more people landing pull requests so we can get the feedback to them faster.

I akso agree phab is the place non co mitters submit patches to die. It's quite difficult for people like me that want to find dropped balls, so they remain dropped.

We've recently made strides to make bugzilla feedback timely. Though the backlog is a mess and the diversity of views of how to address it .

[NatUni]

@ykla don't get discouraged...in general, i mean. Do be discouraged from this. This patch is utterly ill-conceived and misguided. I blame ivy@, not you. (i saw she encouraged this, well not this exactly, but how this began, from Bugzilla.) You're both absolutely great, though. I too encourage you; i'm only being a bit boorish.

You've identified a clear shortcoming, you're absolutely not wrong in that, so we will reach an improvement that is a prudent compromise (which nobody likes yet everyone can live with, LOL)

This is what it's about, the crucible. I see you keep showing up with the right enthusiasm; we'll make a 1337 kernel hacker out of you, yet.

@concussious hit the nail on the head; people struggle to give negative feedback, so they clam up, hope/expect someone else will. Meanwhile it sounds like you'd actually be thrilled for even just a little constructive criticism.

If you enforce the elimination of all Amnesiacs then countless and unknowable code paths the world over all go dark and gather dust, never to be tread or tested despite being there, getting slowly filled with dust and spiders while other unvisited unprepared code paths are suddenly ravaged like virgins by vikings.

Empty string is currently an allowed configuration. What your patch in fact does is not to "warn" the user but to wrangle/coerce them into submission inside an until true loop. Furthermore, you tell the user why to set a hostname, without telling the user why not to set a hostname or what can go wrong if they set one unwisely.

I promise you, for as many things out there that dont work quite right if hostname is unset, there are thrice as many which break in peculiar, frustrating and/or dangerous ways when a name is set, but poorly or with insufficient regard. Search bug reports, mailing lists and forums for "FQDN" and you'll find no shortage.

I might argue you should instead seek the opposite direction; find ways we elevate "allowed" closer to supported (searching issues and bug reports, write test cases, add checks and warnings/guidance to those consumers where they break, when they ought not break). All that hard work means the difference between a "fix" and a "solution"; now you see why this seemingly low hanging fruit is still dangling.

You're absolutely right that the current situation is not ideal because the breakage happens far away in space and time relative to the location of the problem and solution. You have the right intention; we can bring those closer together somehow. Let's see if we can replace this foot-cannon with one of our usual caliber foot-guns.

Since we do live in an increasingly connected world, and we've all known someone who has wasted a morning or afternoon pulling their hair out over the mysterious behavior that results from an empty hostname, i think the crusty whitebeards, and this crusty graybeard, will accept a patch which inserts an extra (dare i say two? probly not, but i could go for two) echo before and after the warning as it now exists, so that it stands out a little bit more among the wall of startup text (which as-is, may be viewed as utter gibberish by an increasing proportion of a widening user base).

One might even make the strong case for tossing a sleep 2 up in there (like a rolled-up newspaper on the end-user's nose) if one were prepared to withstand 3 to 18 months duking it out in a hot sweaty bikeshed over their passionate proposal.

Would you please be so kind to wire this up for us in there along with the aforementioned blank lines? checkyesno amnesiac_intentional || sleep ${amnesiac_delay}. Set the default no higher than 5 seconds, i'd personally say 3.

Please if you'd be so kind to also replace the comment in /defaults/ from "Set this!" to:

#hostname="a-genuine-official-hostname.our-fully-qualified.example.net"
#hostname="my-very-own-private-nickname-may-only-ever-end-with.invalid"
#hostname="that-or-i-may-choose-to-conduct-a-potentially-dangerous.test"
hostname=""			# End-user: you probably want to set this to a
				# sane value. There are also varying reasons
				# to leave it unset. Refer to rc.conf(5).

Please also extend the entry for hostname in our rc.conf(5) with:

An empty hostname can result in myriad mysterious behavior in third-party software which is then difficult to relate to this cause. The hostname(1) command reports by what name the system is currently referring to itself. If you are unsure what to set here then "not-sure.invalid" is a good fail-safe bet or "welcome-in.test" a reasonable fail-open choice. (See RFCs 2606 & 6761.) NOTE: This is not the appropriate place to set "anything.local"; for Rendezvous/Bonjour/Zeroconf a.k.a. mDNS, investigate solutions available in ports(7). Such configurations typically operate in conjunction with, not in lieu of, this setting: e.g. setting rick.example.net, rick.invalid or rick.test here would automatically expose "rick.local" if mDNS is configured properly. (Keep in mind, connecting to others.local is orthogonal to them connecting to you.local.)

[ykla]

@NatUni

Sorry I didn't understand your point. Just to clarify — the current dialog logic is not a loop that forces a non-empty hostname. The user is given a warning only once after leaving it empty, and may choose to proceed with the empty value by confirming. It behaves similarly to the "Are you sure you want to use this disk?" dialog during installation — a secondary confirmation, not enforcement.

I realize that in certain use cases, having an empty hostname setting is perfectly valid.

The warning dialog's design is similar to the secondary confirmation prompt when selecting a disk for installation. Based on my testing, the current code logic works as follows:

• If the user leaves the hostname field empty and presses Enter, a warning dialog appears.
  • If the user confirms keeping it empty (by selecting "No"), the installation proceeds.
  • If the user decides they should set a hostname (by selecting "Yes"), they are returned to the previous input screen.

This does not enforce a non-empty hostname—it merely ensures the user consciously accepts an empty value if they choose to proceed with it.

I’ve added a GIF to demonstrate the actual behavior of this PR. You can also test it on your local machine — just place the code under /usr/libexec/bsdinstall/hostname. I also tested both the empty and non-empty options to ensure the code does not interfere with the user's choice. I performed multiple actual installations.

[NatUni]

the current dialog logic is not a loop that forces a non-empty hostname

please accept my sincere apology; i did not give your code an adequate mental parse before i lambasted you. i completely overlooked how the logic controls the loop

are you saying you modeled your code according to the form of an existing construct from Devin Teske or Nathan Whitehorn? would you point me at the appropriate file for the "Are you sure you want to use this disk?" dialog? please forgive me; admittedly i have never once modified, read nor even used bsdinstall nor bsdconfig

thank you for the video. what tool did you use? can you make them 50% bigger in the future? (this one's fine)

[ykla]

the current dialog logic is not a loop that forces a non-empty hostname

please accept my sincere apology; i did not give your code an adequate mental parse before i lambasted you. i completely overlooked how the logic controls the loop

are you saying you modeled your code according to the form of an existing construct from Devin Teske or Nathan Whitehorn? would you point me at the appropriate file for the "Are you sure you want to use this disk?" dialog? please forgive me; admittedly i have never once modified, read nor even used bsdinstall nor bsdconfig

thank you for the video. what tool did you use? can you make them 50% bigger in the future? (this one's fine)

Please see also https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/bsdinstall/scripts/zfsboot#L422

Sorry, my image size might be too small. I recorded the video using QQ and then converted it to a GIF using the online tool at https://www.freeconvert.com/zh/convert/video-to-gif.

[NatUni]

@ykla thank you for directing me to learn more about the context surrounding this change

please forgive my ignorance; i am unfamiliar with bsdinstall and sysinstall is a distant memory to me.

i agree that your apparent change to the operation of the user interface is something of an improvement. i wish it had always been this way so things would be better today. However, i cannot say "LGTM" regarding your code change (not necessarily because i see anything wrong with it, but) because I am not intimately familiar with the architecture, engineering and construction of that subsection and to become even cursorily familiar would take me at least week of concentrated effort (so, nearly a year at my current level of occupation, distraction and diversion).

Yes i'm being a bit hyperbolic or overly dramatic if we consider the simplicity and trivial nature of this merge request but you've brought up greater philosophical points about the project and process.

As @concussious stated, for committers and long time users to warmly receive a patch of code requires that a significant proportion of participants have identified a clear and present problem or shortcoming that far exceeds, i think, the level of the issue this change is intended to resolve. Modifications to comments and documentation are much easier for everyone to look at and feel confident in imagining what the implications may be.

On the other hand, if you might walk me through more-or-less the entire architecture of bsdinstall and carefully educate me as a teacher might a young child, or if you can point at a dozen accepted patches youve authored (and each has gathered a dozen highly respected cosigners) to this or its immediately surrounding subsystems, either course would instill the confidence in you from myself and any observers...and I just so happen to be willing to take a crash course in bsdinstall/bsdconfig this week. In exchange i would become increasingly available to you for mentorship and direct collaboration so that you might enjoy greater effectiveness of FreeBSD in your life and so that more of the issues and problems you are diligently finding and reporting with FreeBSD and ports will become well formed solutions upon submission (or closer to it).

As I stated, the FreeBSD project currently needs change. ...

... This group should also work within a defined timeframe.

if the FreeBSD project is to move forward, then someone must be willing to make greater sacrifices and put in more effort.

... without more external contributors becoming committers, nothing else can truly begin.

Have you ever before heard the phrase, "Jia Tan Energy"? Please understand this comment has nothing to do with your nationality or culture and everything to do with the great responsibilities and liabilities i carry in order to use and apply FreeBSD at my work and in my home.

I’ve noticed that most FreeBSD subprojects are being maintained by just a few individuals — such as Wi-Fi and the GNOME desktop — and this is a very unhealthy situation for the FreeBSD project as a whole. ... We absolutely need young people to get involved.

Truer words have never been spoken. See xkcd/2347. However in each component or project a tightly knit few or handful of characters naturally gravitate together because it is the preferable situation versus a hodgepodge patchwork of inconsistent code style and behavior which leads to risks for our generation and confusion for the next. Of course some happy medium is the optimal, yet difficult to sustain, ideal.

This is precisely why fellows such as myself engage with diligent and enthusiastic participants even while you might be viewed by some as a nuisance that should not be encouraged. Personally, I would not seek to widen FreeBSDs intended audience, only to foster select individuals of promise and merit to become indoctrinated in the ways of the Old Guard. I must ask:

1. What is (or what are some of) your current use case / application for FreeBSD?
2. Where (or doing what) do you hope to see the FreeBSD project in 5 years?
3. How about 20? What will the world be like by then, if you have something to do with it?
4. Are you employed? How do you support yourself and maintain a livelihood? Do you have dependents?
5. Are you interested in a remote work job position? What are your requirements for compensation?

[concussious]

Please. More words matter less.

No one objected to the code, but the premise.

Before offering to mentor people, know how to search code by author.

Please keep the thread on topic.

[NatUni]

No one objected to the code, but the premise.

"trepidations" notwithstanding, i don't see a firm nor thoughtful objection to either; at least not against the shape of it here

if this PR becomes closed i will cheerfully accept any outcome & move on. @ykla i sincerely wish for you to remain engaged feeling valued & encouraged, most importantly

Before offering to mentor people, know how to search code by author.

i'm curious how i've given the impression that i must not & to which author/code you've referring

i am sorry if i've overstepped; i am not a committer nor do i claim a particularly distinguished position in our community. if "mentor" carries a formality in present context such that the word cannot be used in the general sense then i have spoken hastily or carelessly & will appreciate a corrective reprimand

i have merely been a minor contributor for quite some time who feels great joy & fulfillment from the experience, finding project participants to be gracious, appreciative, hard working & effective. imparting this sense is mainly what i'd seek to convey to anyone expressing their frustration. i am confident thru pair programming anyone can be shown how FreeBSD fosters self-sufficiency and empowers its users remarkably well

Is it your feeling that i should not engage nor encourage this person? (I'm not just being rhetorical by asking; this question is posed seriously to you & also to the broad community [or those few who mosey on by this PR] in regards both particularly to this individual as well as generally to our evolving group and culture.)

Please keep the thread on topic.

Acutely then: my present position is "NACK" although i think Ykla's issue has not been given the consideration she merits. i do believe a broadly useful & generally harmless improvement could be found which is not be a disproportionate expenditure of energy nor imposition of risk to our project/users. i only speak for me, so i volunteer to collaborate with a user who i see's been with us a pretty long time now, here practically begging for attention and engagement

I will continue these broader topics on freebsd-advocacy@ in the future (or at least i can be found there if any reader feels follow-up is warranted).

Please. More words matter less.

If i have come across as disrespectful of anyone's time or ungrateful of anyone's focus, i am ashamed. Only family is more fulfilling to me than to engage constructively with this community. I have FreeBSD to thank for every bit of the prosperity which grants me far more time than obligation in my retirement; so if i was unknowingly insensitive of others' busy or overburdened lifestyle, i hope they'll judge me redeemable and forgivable or at least share their judgments of me with me

If you wish, Alexander, that from here forward i shall keep your name out of my mouth then i will respect that wish

If you feel i should simply double my financial donations before withdrawing to my porch rocking chair to feed the ducks, I will...take your sentiments into consideration

[ykla]

Please. More words matter less.

No one objected to the code, but the premise.

Before offering to mentor people, know how to search code by author.

Please keep the thread on topic.

Excuse me, but it seems the FreeBSD CI might be running low on balance?

Also, could this GitHub PR conversation be locked, as it has gone off-topic?