1. 25
  1.  

  2. 7

    Heh I remember asking about this a while back on #prgmr, thanks for writing this up.

    1. 2

      There’s nothing there which isn’t covered by the official openbsd documentation.

      1. 12

        This blog post is the result of a customer reaching out to us due to installing OpenBSD with full disk encryption but being unable to get a password prompt on the serial console. They reached out after following the instructions provided in the OpenBSD FAQ but were unable to make them work.

        We went through a handful of other published articles but didn’t find anything that directly covered this scenario, and so wrote these instructions to pull them through installing OpenBSD on their VPS.

        If this scenario is in the official documentation they couldn’t find it or we didn’t understand it.

        1. -1

          boot(8) covers enabling serial on bootloader. It’s even one of the examples given below. Which is all you’d need, as passphrase input is done with the bootloader.

          Thus the tutorial is just a form of spoonfeeding, and IMHO does not belong here.

          1. 12

            boot(8) covers enabling serial on bootloader.

            And pray tell why would a new user know exactly where to go for serial on the boot loader?

            Thus the tutorial is just a form of spoonfeeding, and IMHO does not belong here.

            Elitism like that is what makes the BSD communities so unwelcoming and self-isolating. To contrast, DragonFly keeps tutorials for interesting tasks, like userspace drive mirroring in Hammer. I was able to get started because of tutorials like that - I had a goal to build a NAS and one of their tutorials helped me accomplish my goal. I also would give a shout out to the FreeBSD handbook which was more project/task oriented and quite helpful for new users to learn how all these parts fit together.

            1. 2

              And pray tell why would a new user know exactly where to go for serial on the boot loader?

              Why would they know about a random article online to help them? How do they know it’s up to date? If the system documentation is insufficient, that is a bug.

              1. 6

                Usually someone in that situation Google’s their exact situation and first tries the official docs followed by unofficial ones.

                Also, yeah, I agree the system documentation is insufficient. Unfortunately, when you have enough people with the attitude of “well I understand it, don’t spoonfeed it”, you get a dampening impulse to under document it.

                “Spoonfeeding” is dog whistling for “I don’t want those dirty common folk who are so stupid”. And that attitude is toxic. Everyone has to start from a position of ignorance. Being kind and open to such is an exercise in patience. Patience makes a community better for all of us. After all, life is short.

                1. 8

                  Good comment.

                  Everyone has to start from a position of ignorance.

                  One of the things I do is stand up and maintain services (infrastructure) for software teams. A significant portion of which is teaching people how to use the tools–integrating them with their own workflow and habits. After you work with enough people, it becomes pretty clear how different they are when they approach problems or try to understand something.

                  Almost everyone gets stuck (needs help, has a question) somewhere. Where a person gets stuck comes down to their subjective experience and tends to be particular to them. I get asked what I consider insightful questions–questions that demonstrate the asker understands and is testing their knowledge. I get asked what I consider basic (simple) questions–those that make me wonder how they managed to understand anything else. In all cases I answer the question in the straightforward manner of trying to inform. The way I understand something is not the way other people do, and my evaluation of the quality of a question has no bearing on whether the answer is helpful to the asker or the audience.

                  In the obverse I do the same–I’ll ask a series of questions where I 1) know the answer, for sure. 2) believe I know the answer but am not sure, 3) have no idea what the answer is. Asking simple (basic) questions helps me confirm that the answers to my other questions are correspondent.

                  Sometimes a question really is a test of the limits of your own competence, and almost always the asker wants to benefit from your understanding without the level of study (investment) you’ve made. They are working on their own problems, applying their own knowledge, working with many other specialists on a solution that none of you would accomplish alone.

                  It’s not “spoon feeding” to condense what you know in to a solution.

                  1. 2

                    “Spoonfeeding” is dog whistling for “I don’t want those dirty common folk who are so stupid”. And that attitude is toxic.

                    This was absolutely not the intent of my words. I do not appreciate my words being twisted this far to paint me as something I am not nor do I try to be.

                    That’s openly hostile, and I find it ironic if anything that you’re calling me toxic, despite.

                    1. 3

                      Agreed. Calling someone’s comments a dog whistle so you can attack what you claim they said rather than what they actually said is itself a form of toxicity.

                    2. 1

                      Also, yeah, I agree the system documentation is insufficient. Unfortunately, when you have enough people with the attitude of “well I understand it, don’t spoonfeed it”, you get a dampening impulse to under document it.

                      If you look at the commit list, you’ll see that a huge portion of the commits are purely documentation improvements. I’ve also seen features rejected because they made it harder to write documentation.

                      If there’s a dampening effect, it doesn’t seem to be very strong.

                  2. 2

                    Elitism like that is what makes the BSD communities so unwelcoming and self-isolating.

                    Good documentation makes them welcoming and not self-isolating at all. This is in contrast with Linux and its poor documentation (save perhaps Gentoo and Arch’s respective wiki sites, which is in no small part why I favor these distributions).

                    I was able to figure out how to configure the bootloader. Why would I not expect everybody else to be? The starting point was the same: Not having a clue about openbsd, just enough to decide to try it out. Everybody starts there.

                    why would a new user know exactly where to go for serial on the boot loader?

                    Assuming that checking boot(8) is not obvious for bootloader configuration, I would try a web search. I just tried this, on the most popular web search engine, for “openbsd bootloader”. The first result is boot(8).

                    Seriously, why do you think it is a good idea to spoonfeed that which is so easy to find?

                    Furthermore, If enough people get stuck there, isn’t the correct response to try and improve the documentation itself? It certainly is a much better approach than writing a tutorial.

                    Openbsd is an open source project. It takes patches, bug reports, suggestions. Documentation can be improved to cover this, so can code: The installer could be made to handle all of this.

                    1. 1

                      prgmr isn’t itself BSD project, and they have no particular obligation to try to improve the official documentation of any particular BSD project, rather than just writing their own blog post (although there’s certainly nothing wrong with trying to upstream a documentation patch - I’ve never done this myself and have no idea how easy or hard any given BSD makes this). In any case, I do think there’s value in users of software writing their own blog posts about their experiences with it, that need not be “documentation” in any official sense. (And I’ll say that I got the idea to use a FreeNAS virtual machine to manage those drives from user experience blog posts much like this one, rather than FreeNAS’s official documentation! I wouldn’t have even known that FreeNAS was a piece of software that might solve my problem without such blogs.)

                      I’ve only recently began using a BSD, in the guise of a FreeNAS virtual machine that I have managing some hard drives. I personally had no trouble installing it or using its web GUI to set up encrypted storage, and it’s been working perfectly fine for me so far. But I’m aware in the back of my mind that I’m not familiar with the command-line tools for managing BSD encryption, and I may need to know how to use them to debug this setup someday. So even though I’m not currently installing BSD on anything, this blog post is still potentially useful to me for gaining a better understanding of a system I already use.

                  3. 7

                    With an encrypted /etc, the bootloader can’t read from /etc/boot.conf to know to use the serial console. The novelty here is not booting from the serial console, but how to make an encrypted root and serial console work together.

                    As of a few years ago it was not supposed to be possible to have only the one file /etc/boot.conf be on an unencrypted partition: https://old.reddit.com/r/openbsd/comments/36hwhi/remote_rebooting_with_full_disk_encryption/ We didn’t find any documentation noting that had changed.

                    1. -2

                      This issue (and the workaround) is self-evident once you understand how it all works together, which is the result of reading the documentation.

                      I don’t see why anyone would need to be spoonfeed to this degree.

                      Every time I do install an openbsd I do not like that the installer doesn’t itself handle encryption. I do hope it will at some point. But all it takes is a short visit to the shell; This is much better than the netbsd situation.

                      Openbsd is an open source project. It takes patches, bug reports, suggestions. Documentation can be improved to cover this, so can code: The installer could be made to handle all of this.

                      This is a much better approach than writing a tutorial.

                      1. 5

                        Just because you understand it doesn’t mean that others understand it. Using Thought terminating cliches like “Spoon feeding” only serves to paint a user who doesn’t have your wonderful understanding as defective and wrong, which is unnecessary and cruel.

                        Also, “file a bug and do extra work in my exacting standards” is a pretty entitled attitude. You could very well just shrug and move on or go “hmm, I like OpenBSD and maybe, just maybe, there’s a disconnect in the documentation that will make it easier for all of us?”

                        If you want OpenBSD to remain on the sidelines and hostile to everyone but perfect people like you, keep it up - your attitude is perfect for that.

                        And yeah, I’ve encountered this before. The only reason why Linux is more successful is enough like-minded people of a professional demeanor have made multiple distros, websites, wikis, etc - all which have no issue with “spoon feeding” because attitudes like that get you fired.

                        1. -1

                          “hmm, I like OpenBSD and maybe, just maybe, there’s a disconnect in the documentation that will make it easier for all of us?”

                          I covered this case in my comment. File a bug and/or a patch; get the documentation fixed, or improve the installer so that documentation isn’t needed in the first place.

                          But maybe that isn’t as convenient as placing a howto on a personal website and hoping the documentation does never get fixed, so as to maximize the traffic?

                          1. 7

                            Here is the best I can do right now, based on the notes at the bottom of https://www.openbsd.org/faq/index.html:

                            https://marc.info/?l=openbsd-misc&m=158906005307187&w=2

                            We have a history of reporting bugs upstream even when we’ve found a local workaround. In this case, frankly it did not occur to me to make a change request for the FAQ, and I’m not sure why. So thank you for that suggestion.

                            Regardless of whether our information is incorporated into the FAQ, I think it’s valid to additionally do a blog post for the following reasons:

                            • Changes to FAQ items are generally not push notifications. I could be wrong but I don’t see any way to subscribe to updates to https://www.openbsd.org/faq/index.html .
                            • Let’s hypothesize that the maintainers of the FAQ either 1. are overworked (likely) so there’s a delay in publishing the information or 2. do not believe, like you, that this is novel information worthy of going in the FAQ. At least then we’ve done our best to share our work.
                            • The blog post has better formatting than plain text, and it would be unreasonable to expect someone to enable HTML when reading email.
                            1. 2

                              Well done re: sending email to openbsd-misc.

                              Let’s hope they take it seriously.

                    2. 6

                      This is the very attitude that made me drop OpenBSD after I encountered some problems, and the community was unwelcoming at helping me.

                      You are not nice guys, and while OpenBSD has many nice aspects, it is not that good that it outweighs this attitude. I don’t mean that the obsd community is mean, just too self-important.

                      Also the docs are pretty nice, but not completely flawless, complete, or up to date. At least not discoverable and interlinked enough to dismiss such writeups. (Much because of the old technologies used).

                      Also the filesystem layer, and the (not so) “full disk” encryption experience was underwhelming for me. The trunk network driver is what I really miss in other systems, that is the most simple and elegant stuff I admire the most in OpenBSD.

                      1. 2

                        the community was unwelcoming

                        I found the openbsd community to be extremely accommodating and have a lot of patience with useless people such as me.

                        (not so) “full disk” encryption experience

                        Now, I am curious. Can you elaborate on what if anything is missing from the disk encryption support? What are you comparing it with, if anything?

                        1. 3

                          My experience is rather different with the community.

                          I wanted two things from FDE:

                          1. encrypted mirror disk (or mirrored encrypted disk). The documentation clearly states this is unsupported.
                          2. encryption unlockable both with a key device (disk/file on partition/yubikey) and a password as a fallback. The documentation of bioctl and the docs don’t explicitly state if this is supported or not, but the command line examples suggest it is not. With 1. already making it a no-go I didn’t try this.

                          I have encountered other shortcoming of the system while evaluating it for its intended role (without encryption), and it proved unsuitable (and I didn’t have the resources to develop fixes, which may or may not be incorporated, while other systems are suitable out of the box). I abandoned the system as updates introduced regressions and made it unusable on the test machine.

                          1. 2

                            My experience is rather different with the community

                            I’ve found openbsd (and netbsd) communities to be quite friendly. Freebsd’s quite hostile. Of course, my experience is that of a single person, thus naturally limited.

                            FDE

                            You’re right in that it’s an odd mix between LUKS and dm-crypt, as it does handle the key for you (passphrase on bootloader), but doesn’t have the flexibility of LUKS nor the “I do it myself” kind of flexibility of using straight dm-crypt.

                            Dragonfly is the one BSD that does better in that regard… by simply implementing LUKS.

                            1. 2

                              FDE: the LUKS solution also has its not so elegant points (initrd regenereation when crypto setup is changed)

                              I have very good experience with the NetBSD community from a very log time ago. Super friendly guys! Some OpenBSD guys were friendly, but many more were not. I could not get help for my problems :S

                              I know a FreeBSD fan guy personally. Way unfriendly guy :) But I try not to generalize too much from a single element sample.

                              I have never tried Dragonfly, thus have no experience so far. That system also has some interesting aspects, but I’ve never had the resources to try it so far.

                              I could also point to #fedora on freenode, where I met a very unwelcoming environment with my questions, even more unwelcoming than that I encountered at obsd. Really mean guys there.

                              1. 2

                                I agree about netbsd being exceptionally friendly. I was honestly impressed myself. This has been true for at least 15 years.

                                I haven’t seen hostility from openbsd, but every time (across decades) I reached out to freebsd communities (irc, mostly) I’ve been met with open hostility.

                                Dragonfly team actually hang out in efnet, rather than freenode or oftc. They’re alright.

                2. 1

                  Cool post!