Re: Surprise null root password
On Tue, May 30, 2023 at 8:36 AM bob prohaska wrote:
>
> On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
> >
> > Quoting bob prohaska (from Fri, 26 May 2023 16:26:06
> > -0700):
> >
> > > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > > >
> > > > The question is how you update the configuration files,
> > > > mergemaster/etcupdate/something else?
> > > >
> > >
> > > Via etcupdate after installworld. In the event the system
> > > requests manual intervention I accept "theirs all". It seems
> > > odd if that can null a root password.
> > >
> > > Still, it does seem an outside possibility. I could see it adding
> > > system users, but messing with root's existing password seems a
> > > bit unexpected.
> >
> > As you are posting to -current@, I expect you to report this issue about
> > 14-current systems. As such: there was a "recent" change (2021-10-20) to the
> > root entry to change the shell.
> > https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
> >
> > By blindly accepting all changes, this has reset the PW to the default
> > setting (empty).
>
> So it's a line-by-line merge. That's the most sensible explanation available.
>
> >
> > I suggest to review changes ("df" instead of "tf" in etcupdate) to at least
> > those files which you know you have modified, including the password/group
> > stuff. After that you can decide if the diff which is shown with "df" can be
> > applied ("tf"), or if you want to keep the old version ("mf"), or if you
> > want to modify the current file ("e", with both versions present in the file
> > so that you can copy/paste between the different versions and keep what you
> > need).
> >
>
> The key sequences required to copy and paste between files in the edit screen
> were elusive. Probably it was thought self-evident, but not for me. I last
> tried
> it long ago, via mergemaster. Is there is a guide to commands for merging
> files
> using /etcupdate? Is it in the vi man page? I couldn't find it.
>
> Thanks for writing!
>
> bob prohaska
>
>
It's been a while for me so I forget if etcupdate resolve is automatic
or there is a prompt or message about it, but the guide at
https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-completing-merge-etcupdate
says:
If etcupdate(8) is not able to merge a file automatically, the merge
conflicts can be resolved with manual interaction by issuing:
# etcupdate resolve
But this info is far below the steps at
https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-quick-start
with section 25.6.6.1 also not being mentioned in the steps.
Info on merge commands, regardless, is under the Resolve Mode
description in the etcupdate man page
https://man.freebsd.org/cgi/man.cgi?etcupdate.
Re: GitHub Code Search [Re: Tooling Integration and Developer Experience]
On Tue, Jan 31, 2023, 9:47 AM David Chisnall wrote: > > On 30/01/2023 21:39, Yetoo wrote: > > > > If github is going to be considered for issue tracking I just want to > > say, after having extensively using it for issue tracking, it tends to > > be difficult to find an issue if the exact title isn't entered and many > > duplicate reports are made as a result. Code search sucks and doesnt > > show you the multiple places in a file where a match was made so a user > > may be left wondering if code exists or not, but this doesn't seem to be > > germane given this is about issue tracking. > > Which search are you using? The old GitHub search is not great, but > cs.github.com has replaced local search for me in the FreeBSD tree. > It's not *quite* as good as fxr, but it's close. > > For example, searching for sys_cap_enter: > > https://cs.github.com/?scopeName=All+repos==sys_cap_enter+repo%3Afreebsd%2Ffreebsd-src+ > > David Clicking that link greets me with a login screen and a requirement to join a waitlist. Yes, this is beta and may change in the future, but not thrilled that an account is required to use and opt into it.
Re: Tooling Integration and Developer Experience
My two cents... I think some of the integration issues can be resolved with some rule changes and showing those relevant rules that people will see every time they make a pull request, report, etc... as I think what will happen with each item is too uncertain even if there was automation. I think rules should enshrine a single place that will always get reports and places to review or pull request and/or discussion requires reports to be made there first. I think that single place should be bugzilla but I'm a bit biased toward bugzilla as I haven't created an account for freebsd phabricator. This would mean every review on phabricator or pull request on github would need an associated report on bugzilla as well as link to that report and link back on bugzilla in the url field (if only one allowed or easy per report, maybe make dedicated field for other trackers) or first comment or else bugzilla, github, and phabricator posts are closed. The problem of just having someone commenting a link where the pull requestin the middle of a long discussion is that it's hard to find. Perhaps this part can be automated first as it's draconian if rules/warnings can't be seen before and while editing. People can go to the mailing list to talk about issues or submit changes, but no change will be accepted until someone makes a bugzilla report for it and link back to mailing list and from mailing list to it. Then there can be more automation with phabricator and github notifying bugzilla that it exists/important events happened to the bug. I think if the rules viewed bugzilla centralized to all legs then the need for redundant notification and requests, such as git saying if there is an issue/review in phabricator and an issue report in bugzilla or a pull request automatically created in git when submitted to phabricator, would be avoided. If everything is moved into phabricator, including bugzilla, I think it's worth considering whether existing bugzilla reports, patches, tags, etc can be migrated without losing data. Bugzilla could be in a no new reports mode, but there would still be the problem of reports spread out across different systems. If github is going to be considered for issue tracking I just want to say, after having extensively using it for issue tracking, it tends to be difficult to find an issue if the exact title isn't entered and many duplicate reports are made as a result. Code search sucks and doesnt show you the multiple places in a file where a match was made so a user may be left wondering if code exists or not, but this doesn't seem to be germane given this is about issue tracking. >
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
On Fri, Dec 3, 2021 at 3:52 AM Yetoo Happy wrote: > > In https://docs.freebsd.org/en/books/handbook/cutting-edge/ I can see that at > 24.5.6.1 Merging Configuration Files are instructions to bootstrap etcupdate > if switching from mergemaster. This is really convenient and really useful, > EXCEPT for that fact that it is placed in a part of the handbook a little > ways after installation would complete. The critical issue here being that, > due to this information not being higher up, a user who is looking at the > handbook to update from source and are trusting the handbook because they > have faith that it won't play any dirty tricks on them, because all the > documentation and all the user groups speak so highly of the handbook being > complete and thorough and authoritative, are just going to 24.5.1. Quick > Start and follow the instructions and get to step 7 and may think that even > though etcupdate is different from mergemaster from the last time they used > the handbook they have faith that following the instructions won't brick > their system. This user will instead find that faith in general is just a > very complex facade for the pain and suffering of not following 24.5.6.1 > Merging Configuration Files because the user doesn't know that step exists or > relevant to the current step and ends up unknowingly having etcupdate append > "<<<< yours ... >>>>> new" to the top of the user's very important > configuration files that they didn't expect the program to actually modify > that way when they resolved differences nor could they predict easily because > the diff format is so unintuitive and different from mergemaster. Now unable > to login or boot into single user mode because redirections instead of the > actual configuration is parsed the user goes to the handbook to find out what > might have happened and scrolls down to find 24.5.6.1 Merging Configuration > Files is under 24.5.6. Completing the Update. What a mocking section? > Completing the update? How could I have completed the update if I was on Step > 7 of Quick Steps? The user now may feel cheated, jaded, or insulted and > wonder what the fuss is all about with this hyped documentation. > > Here's a solution: Make a red warning notice at the very top of 24.5.1. Quick > Start and refer to 24.5.6.1 Merging Configuration Files and make clear this > is for step 7. Another solution is, if possible, put that red warning notice > next to step 7 or step 7 in the grey section or red/pink section of the quick > start box area, I personally would prefer a warning with text right next to > step 7 in the red/pink part of the quick start box, but I'm not sure if > that's possible or respecting the documentation design paradigm. The next > best option is a warning at the top because it reduces the chance of a user > following instructions and missing that step because they haven't scrolled to > that point yet. > > I'm sorry if this comes across as an angry potentially combative message, but > I just wanted to make clear where and what the problem is and my frustration > with this problem. Around the time I made this post, I created a patch that I believe resolves the issue with the documentation. Here is the PR for posterity: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260253
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
If it was in a temporary directory, even if I manaually resolved the file and merge, I was expecting that file marked as resolve to stay in that temporary directory until I was done with all my files. Maybe I'm confusing mergemaster -Ui behavior with something else, but it seems like only merging after the user has reviewed all manual changes in a final verification sweep is common sense or at least explicitly display the tree directory that would be written to and say this is final change. I didn't know that each file etcupdate went over was going to be the final review. I think my system broke by the time I got to the rest of the postponed items due to this. On Wed, Dec 8, 2021, 9:05 AM John Baldwin wrote: > On 12/3/21 4:58 AM, Miroslav Lachman wrote: > > So beside the update of documentation I really would like to see some > > changes to etcupdate workflow where files are modified in temporary > > location and moved to destination only if they do not contain any syntax > > breaking changes like , , . > > This is what etcupdate does, so I'm a bit confused why you are getting > merge markers in /etc. When an automated 3-way merge doesn't work due > to conflicts, the file with the conflicts is saved in > /var/db/etcupdate/conflicts/. It is only copied to /etc when you > mark it as fully resolved when running 'etcupdate resolve'. Perhaps > you had multiple conflicts in a modified file and when editing the file > you only fixed the first one and then marked it as resolved at the > prompt? Even in that case etcupdate explicitly prompts you a second time > after you say "r" with "File still has conflicts, are you sure?", > so it will only install a file to /etc with those changes if you have > explicitly confirmed you want it. > > -- > John Baldwin >
Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
In https://docs.freebsd.org/en/books/handbook/cutting-edge/ I can see that at* 24.5.6.1 Merging Configuration Files* are instructions to bootstrap etcupdate if switching from mergemaster. This is really convenient and really useful, *EXCEPT* for that fact that it is placed in a part of the handbook a little ways after installation would complete. The critical issue here being that, due to this information not being higher up, a user who is looking at the handbook to update from source and are trusting the handbook because they have faith that it won't play any dirty tricks on them, because all the documentation and all the user groups speak so highly of the handbook being complete and thorough and authoritative, are just going to* 24.5.1. Quick Start* and follow the instructions and get to step 7 and may think that even though etcupdate is different from mergemaster from the last time they used the handbook they have faith that following the instructions won't brick their system. This user will instead find that faith in general is just a very complex facade for the pain and suffering of not following *24.5.6.1 Merging Configuration Files* because the user doesn't know that step exists or relevant to the current step and ends up unknowingly having etcupdate append " yours ... > new" to the top of the user's very important configuration files that they didn't expect the program to actually modify that way when they resolved differences nor could they predict easily because the diff format is so unintuitive and different from mergemaster. Now unable to login or boot into single user mode because redirections instead of the actual configuration is parsed the user goes to the handbook to find out what might have happened and scrolls down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. Completing the Update*. What a mocking section? Completing the update? How could I have completed the update if I was on Step 7 of Quick Steps? The user now may feel cheated, jaded, or insulted and wonder what the fuss is all about with this hyped documentation. Here's a solution: Make a red warning notice at the very top of *24.5.1. Quick Start* and refer to *24.5.6.1 Merging Configuration Files *and make clear this is for step 7. Another solution is, if possible, put that red warning notice next to step 7 or step 7 in the grey section or red/pink section of the quick start box area, I personally would prefer a warning with text right next to step 7 in the red/pink part of the quick start box, but I'm not sure if that's possible or respecting the documentation design paradigm. The next best option is a warning at the top because it reduces the chance of a user following instructions and missing that step because they haven't scrolled to that point yet. I'm sorry if this comes across as an angry potentially combative message, but I just wanted to make clear where and what the problem is and my frustration with this problem.
