Re: [HEADSUP] making /bin/sh the default shell for root
In message <20210922083645.4vnoajyvwq6wf...@aniel.nours.eu>, Baptiste Daroussin writes: > Hello, > > TL;DR: this is not a proposal to deorbit csh from base!!! > > For years now, csh is the default root shell for FreeBSD, csh can be confusin > g > as a default shell for many as all other unix like settled on a bourne shell > compatible interactive shell: zsh, bash, or variant of ksh. > > Recently our sh(1) has receive update to make it more user friendly in > interactive mode: > * command completion (thanks pstef@) > * improvement in the emacs mode, to make it behave by default like other shel > ls > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > * support for history as described by POSIX. > > This makes it a usable shell by default, which is why I would like to propose > to > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > If no strong arguments has been raised until October 15th, I will make this > proposal happen. > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! Having used /bin/sh as my root shell on all my FreeBSD machines, here and at $JOB, except for only one, I feel this is perfectly reasonable. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few.
Re: [HEADSUP] making /bin/sh the default shell for root
It looks like every time I correct an error, someone tries to hack my account… odd. > On Sep 29, 2021, at 3:40 AM, grarpamp wrote: > The system shell really only need to support the > language of the shipped scripts of the base tooling > such as rc subsystem. No. The system shell is supposed to make the system usable by the users. Actually, the real problem is that the easiest way to shoot one's own foot is by changing the language (say, the shell) spoken by default by FreeBSD. > zoor zsh > toor tcsh > coor csh > qoor sql > poor python > boor bash > goor go > plus the entire rest of world of shellish thingies just > to satisfy. Which is obviously untenable and absurd and > causes futher legacies, maintenance, dependencies. > Where does it stop, what is the limiting definition. > Moving to just one, some type of an "sh", seems best > to resolve the question. This is non-sense. Every unix user should know that it's possible to changing the used shell by using chsh and this includes root. BTW, toor default to sh, not tcsh. -- rollingbits — rollingb...@icloud.com rollingb...@gmail.com rollingb...@yahoo.com
Re: FreeBSD base pkg (packaging) and critical ports build alongside
On 2021-09-29 01:28, FreeBSD User wrote: Hello, I use FreeBSD-base packages built on self hosted systems to update 13-STABLE and CURRENT hosts. I run into the problem, that the packages of the FreeBSD base, built via the FreeBSD framework and from most recent 13-STABLE sources, are often oit of synchronisation with our poudriere packaging builders, that is especially true for critical ports with kernel modules, like i915 drm, virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources and probably the API changes more rapidly than those of the appropriate builder hosts for poudriere and since it takes a bunch of days to build a whole poudriere packages repository, there is often a gap between the revision of the kernel and the port containing kernel modules. So, the question is: how can I add ports to the building process of the FreeBSD sources tree in the way they get build every time I build the FreeBSD-base packages alongside the OS? The simple answer is; by keeping/getting both trees where you want them before you initiate a build. This is what I do; Pick some point in time, or in git(1) parlance; hash/revision. I then git co/clone git hash/revision for both trees. I then fire off a build for both. Creating $BASE install(s)/images && packages. Since I'm subscribed to the freebsd-security-notifications ML. I get announcements whenever FreeBSD pushes security patches. I then check the git log for when the patch(s) was/were pushed/committed. Then update the affected tree to that hash/revision, and update the ports tree to the same place in time. Then build both trees and update the affected boxes (servers/hosts). You probably will also want to monitor the commit list (WARNING it's a high volume list) for CVE notices. So as to keep your ports tree safe. Simply do the same -- update the ports tree that contains the CVE commit && build up/deploy your packages from it. Customization (adding ports drivers to your $BASE (src) build: Simply add PORTS_MODULES= to your make.conf(5). For instance; your i915 driver. That pretty much covers it I think. :-) See also; man make(1) man make.conf(5) && man ports(7) HTH --Chris Thanks in advance, oh 0xBDE49540.asc Description: application/pgp-keys
Re: FreeBSD base pkg (packaging) and critical ports build alongside
On Wed, 29 Sep 2021 09:42:46 +0100 David Chisnall wrote: > Hi, > > I think your best option would be to do the opposite of what you > suggest. Poudriere can build pkgbase sets from a source tree and > populate a jail from them. No it doesn't populate the jail from the pkgbase sets, the jail will still be populated using make installworld and friends. I still need to add the possibility to create a jail (and update it) just from a pkgbase but haven't got time yet for this. > The flow that I'd suggest is: > > - Poudriere jail to build a jail from an existing source tree. > - If there are kernel changes, install the packages on the package > builder and reboot. > - Poudriere bulk in the new jail to build the new package set. > > Note: You can *normally* skip the second step (drm ports, for example, > will be built against the new kernel sources in the jail, though they > might not be loadable on the host) but there's no guarantee that you can > run a newer userland on an older kernel so things may break. > > If you enable reproduceable builds in the src.conf that you use for > building the jail then you should be able to just diff the kernel binary > to see if anything has changed. > > If you have bhyve or are running on a cloud platform then you can > replace the second step with a poudriere image invocation to build a VM > image containing poudriere and your newly-built base system and deploy > this to build the packages. I'm planning on working on some tooling to > do this in Azure with GitHub Actions. > > Note that poudriere uses packages installed on the host system to build > a jail. If you have, for example, installed llvm12 then you can put a > line in your src-env.conf for the jail to tell it to use that as an > external toolchain and skip the toolchain-bootstrap phase of the build. > This means that the base-build is fairly fast even on quite modest > hardware (it still builds clang, but at least it does it only once). > > David > > > On 29/09/2021 09:28, FreeBSD User wrote: > > Hello, > > > > I use FreeBSD-base packages built on self hosted systems to update 13-STABLE > > and CURRENT hosts. I run into the problem, that the packages of the FreeBSD > > base, built via the FreeBSD framework and from most recent 13-STABLE > > sources, > > are often oit of synchronisation with our poudriere packaging builders, > > that is > > especially true for critical ports with kernel modules, like i915 drm, > > virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE > > sources > > and probably the API changes more rapidly than those of the appropriate > > builder > > hosts for poudriere and since it takes a bunch of days to build a whole > > poudriere packages repository, there is often a gap between the revision of > > the > > kernel and the port containing kernel modules. > > > > So, the question is: how can I add ports to the building process of the > > FreeBSD > > sources tree in the way they get build every time I build the FreeBSD-base > > packages alongside the OS? > > > > Thanks in advance, > > > > oh > > > -- Emmanuel Vadot
Re: FreeBSD base pkg (packaging) and critical ports build alongside
Hi, I think your best option would be to do the opposite of what you suggest. Poudriere can build pkgbase sets from a source tree and populate a jail from them. The flow that I'd suggest is: - Poudriere jail to build a jail from an existing source tree. - If there are kernel changes, install the packages on the package builder and reboot. - Poudriere bulk in the new jail to build the new package set. Note: You can *normally* skip the second step (drm ports, for example, will be built against the new kernel sources in the jail, though they might not be loadable on the host) but there's no guarantee that you can run a newer userland on an older kernel so things may break. If you enable reproduceable builds in the src.conf that you use for building the jail then you should be able to just diff the kernel binary to see if anything has changed. If you have bhyve or are running on a cloud platform then you can replace the second step with a poudriere image invocation to build a VM image containing poudriere and your newly-built base system and deploy this to build the packages. I'm planning on working on some tooling to do this in Azure with GitHub Actions. Note that poudriere uses packages installed on the host system to build a jail. If you have, for example, installed llvm12 then you can put a line in your src-env.conf for the jail to tell it to use that as an external toolchain and skip the toolchain-bootstrap phase of the build. This means that the base-build is fairly fast even on quite modest hardware (it still builds clang, but at least it does it only once). David On 29/09/2021 09:28, FreeBSD User wrote: Hello, I use FreeBSD-base packages built on self hosted systems to update 13-STABLE and CURRENT hosts. I run into the problem, that the packages of the FreeBSD base, built via the FreeBSD framework and from most recent 13-STABLE sources, are often oit of synchronisation with our poudriere packaging builders, that is especially true for critical ports with kernel modules, like i915 drm, virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources and probably the API changes more rapidly than those of the appropriate builder hosts for poudriere and since it takes a bunch of days to build a whole poudriere packages repository, there is often a gap between the revision of the kernel and the port containing kernel modules. So, the question is: how can I add ports to the building process of the FreeBSD sources tree in the way they get build every time I build the FreeBSD-base packages alongside the OS? Thanks in advance, oh
Re: FreeBSD base pkg (packaging) and critical ports build alongside
Hello, On Wed, 29 Sep 2021 10:28:05 +0200 FreeBSD User wrote: > Hello, > > I use FreeBSD-base packages built on self hosted systems to update 13-STABLE > and CURRENT hosts. I run into the problem, that the packages of the FreeBSD > base, built via the FreeBSD framework and from most recent 13-STABLE sources, > are often oit of synchronisation with our poudriere packaging builders, that > is > especially true for critical ports with kernel modules, like i915 drm, > virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources > and probably the API changes more rapidly than those of the appropriate > builder > hosts for poudriere and since it takes a bunch of days to build a whole > poudriere packages repository, there is often a gap between the revision of > the > kernel and the port containing kernel modules. > > So, the question is: how can I add ports to the building process of the > FreeBSD > sources tree in the way they get build every time I build the FreeBSD-base > packages alongside the OS? > > Thanks in advance, > > oh > What I do to have packages (from ports) and pkgbase in sync is that I use poudriere to also build pkgbase. It's available in poudriere-devel using -B when creating the jail. Then I simply cpdup the packages and pkgbase at the same time at the end of the package build. poudriere knows how to do make update-package for pkgbase so your machine will just update the modified packages (provided that you are on a RELEASE/STABLE branch or have WITH_REPRODUCIBLE_BUILD=yes in your jail src.conf for CURRENT). There is still one problem with that approch for kernel modules, they will be recompiled but as the version isn't bumped it will not be upgraded, so I just pkg install -f drm-devel-kmod from time to time. Cheers, -- Emmanuel Vadot
FreeBSD base pkg (packaging) and critical ports build alongside
Hello, I use FreeBSD-base packages built on self hosted systems to update 13-STABLE and CURRENT hosts. I run into the problem, that the packages of the FreeBSD base, built via the FreeBSD framework and from most recent 13-STABLE sources, are often oit of synchronisation with our poudriere packaging builders, that is especially true for critical ports with kernel modules, like i915 drm, virtualbox and so on. The problem is, obviously, barehanded: 13-STABLE sources and probably the API changes more rapidly than those of the appropriate builder hosts for poudriere and since it takes a bunch of days to build a whole poudriere packages repository, there is often a gap between the revision of the kernel and the port containing kernel modules. So, the question is: how can I add ports to the building process of the FreeBSD sources tree in the way they get build every time I build the FreeBSD-base packages alongside the OS? Thanks in advance, oh
Re: [HEADSUP] making /bin/sh the default shell for root
The system shell really only need to support the language of the shipped scripts of the base tooling such as rc subsystem. If those were someday written in Greek, then the shell serves alone, the most common expectation of any "unix" to have there seems to be an "sh", from which users can further customize the box in whatever ways. Base's simplicity, perhaps that is in part why 14 would go with sh, and no longer litter the password file with any other shells, else base must really add and carry them all... zoor zsh toor tcsh coor csh qoor sql poor python boor bash goor go plus the entire rest of world of shellish thingies just to satisfy. Which is obviously untenable and absurd and causes futher legacies, maintenance, dependencies. Where does it stop, what is the limiting definition. Moving to just one, some type of an "sh", seems best to resolve the question. > The little help you get on the command line to search and repeat commands is > very useful compared to plain "sh". That is in part why the sh UI appears to be getting some nice improvements as noted in the HEADSUP / thread. BSD users could contribute more to that effort, or run on the systems whichever shells are preferred. > change "Charlie &" in the gecos field to something more > sensible, e.g. just "Superuser" Seconded. It seems somewhat against good idea to have expandos in and downstream with a passwd file. This update can also help users minimize parsing and gotcha bugs by removing some possible escaping/AND/backgrounding interpretation problems, and reducing complexity and surface. There's actually been a good bit of stepwise cleaning and organization of the passwd/group file, and UID/GID to filesystem/daemons, etc over the years. It's good to view this as part of that effort as well. Another problem and lost opportunity cost and burnt cycles this update finally fixes is the decades worth of N times a year debate on this issue. It's a cumulative friction and waste of time. By selecting just one and sh, that goes away, and can move forward there now too :) > More bashism and linuxism in BSD world, > you are waking the devil. It was meant to say 'sh-like', bash is GPL so it shouldn't be in BSD base, the two shells just have some common than with *csh. Let the beastie daemon... and its more free copyright and unique approach to the "unix", its ongoing "pros" "innovatives" and much more that make bsd good... boil the waterparks of linux into vaporware ;) > Like https://github.com/shellspec/shellbench ? Interesting tool and data :)
