Hi, This has been a major issuse for sometime. After any release updates, such as last one I have done recently, after issueing : freebsd-update -r 13.2-RELEASE upgrade (from 13.1) .. At the step The following file could not be merged automatically: /etc/passwd Press Enter to edit this file in /usr/bin/vi and resolve the conflicts manually... I get the following post (my default editor is vi) .. <<<<<<< current version # $FreeBSD$ # root:*:0:0:Charlie &:/root:/usr/local/bin/bash ======= root:*:0:0:Charlie &:/root:/bin/csh toor:*:0:0:Bourne-again Superuser:/root: >>>>>>> 13.2-RELEASE .. Major inconsistencies and critical defects: It is an upgrade, should not change passwd file in any way, unless standart / delimiter / format changed. If user don't pay attention and save it the way it is then passwd file becomes corrupted. I understand the intent is somewhat adding patch phrase, however, a) it is not the job of upgrade script to change my passwd file. b) It is not the job of upgrade script adding already removed user(s) like 'toor', back. SUPER CRITICAL: Upgrade script patches sshd server system-wide configuration file. It is too crowded already and hard to see/catch patches on screen. If I don't pay enough attention and save it the way it is, it continues with invalid characters inserted into sshd_config. Auto inserted lines similar to the followings are absolute SSHD/PAM killer. @@ -56,10 +55,11 @@ @@ -77,11 +77,11 @@ <<<<<<< current version >>>>>>> ... This once made sshd_config file invalid and, after reboot, SSHD did not start and I was not able to access server remotely. Almost cost me my job. Please stop this type of standarts in upgrades. Simply dangerous. More harm than good. Instead, create a large files of: 1) what's done/applied, call it UPGRADE-timestamp.upgrade 2) what needs to be confirmed by user, call it PENDING-timestamp.upgrade Let user review and apply further changes. Thanks,.
If a person has the expertise to intentionally remove a user that's normally a part of FreeBSD, I should expect the person to be prepared for reintroduction of the user as part of a normal freebsd-update routine. <https://man.freebsd.org/cgi/man.cgi?query=freebsd-update&sektion=8&manpath=freebsd-release> Re: remnants following use of freebsd-update, I'm surprised that the FreeBSD Handbook does not describe what to do – during an update – when the user is presented with things such as this: <<<<<<< current version
... If a person has the expertise to intentionally remove a user that's normally a part of FreeBSD, I should expect the person to be prepared for reintroduction of the user as part of a normal freebsd-update routine. ... I beg to differ. It is not about user's skills. We are all human beings, in many circumstances even most skillfull ones will certainly act differently. The points are: - If I am the admin, it is my decision to have removed users back or not. Not the update script's. I am the one responsible for the system, after all, not update script. Certain things could be automated but this one is not one of those. - If the system has been running perfectly without those users for years, it clearly proves that the suggested practice not really necessary. In short, we need to trust (admin) users and offer some freedom rather than the approach of "we designers know everything, hence, just follow the directions". PS: Totally agree with documenting these instances in the handbook. Thanks,.
It’s not reasonable to “not pay attention” and expect the process to do everything. Upgrades will, from time to time, need to add users. However, if anyone wants to work on those functions they are welcome.
Folks, if anything I can do to help, let me know.
(In reply to Kenan Bektas from comment #0 and comment #2) Please consider things such as: * the IgnorePaths option of freebsd-update.conf(5) <https://man.freebsd.org/cgi/man.cgi?query=freebsd-update.conf&sektion=5&manpath=freebsd-release> * etcupdate(8) <https://man.freebsd.org/cgi/man.cgi?query=etcupdate&sektion=8&manpath=freebsd-release>. If you find appealing the controllability/configurability of etcupdate, then you may prefer to build and install from source; to not rely upon freebsd-update. From the introductory paragraph at <https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld>: >> … complete customization to produce a tailored version of FreeBSD.
Note that freebsd-update will (currently) refuse to proceed and prompt the user to re-edit the file, if conflict markers like <<<<<<<<, =========, or >>>>>>>> are found in the file.