# Is there a process which decides what software goes in "base/world" ?



## Alain De Vos (Oct 21, 2022)

FreeBSD does not has a Linus Thorvalds who makes end decisions.
So who & how is decided what goes in base ?
I have my personal preferences but I am just "a small fly".
I like to have in base the software I use  so will everybody else ...


----------



## VladiBG (Oct 21, 2022)

A project model for the FreeBSD Project
					

A formal study of the organization of the FreeBSD project




					docs.freebsd.org


----------



## Alain De Vos (Oct 21, 2022)

I would like to have opensmtpd & dovecot & any browser in base... , because i use freebsd as desktop PC.


----------



## Brian546 (Oct 21, 2022)

I hope this type of request is smacked down every time. So far it has, thankfully. Browsers have no business being in base, ever. What kind of server needs a browser? Whether you like it or not, whether the foundation says so or not, this is a server OS. Furthermore I think they should completely abolish www and x11-wm from the ports.


----------



## kpedersen (Oct 21, 2022)

Xorg is not in base, so there will be pretty much no GUI installer and no browser which are both common requests from new users coming to FreeBSD.



Alain De Vos said:


> FreeBSD does not has a Linus Thorvalds who makes end decisions.


The problem is Linux Torvalds doesn't make these kinds of decisions; he only cares about the kernel so what happens with individual Linux distros is chaos and mess. Some have browsers, some don't, some have GUI installers, some don't, some are undocumented, some are deprecated, etc, etc.


----------



## mer (Oct 21, 2022)

Alain De Vos said:


> FreeBSD does not has a Linus Thorvalds who makes end decisions.


To the best of my knowledge he is the final arbiter only for the kernel.  Everything else, it's whomever packages the distribution.  
Sorry same thing that kpedersen says.


----------



## Alain De Vos (Oct 21, 2022)

While installing FreeBSD i had in a shell running,

```
elinks https://docs.freebsd.org/en/books/handbook/
```
Stating browsers are important to find information.


----------



## VladiBG (Oct 21, 2022)

Think about other users which use FreeBSD as server. They don't need web browser or pretty GUI as they don't have a monitor attached. All management is done via SSH or SOL.
Even if you install the local doc (handbook) you still will need a pdf reader as ghostview (gv) to open the PDF from `/usr/local/share/doc/en/books` and the ghostview still need 59 other dependencies + Xorg so it will end up with ton of other software installed and every single installed software is potential security risk of having some unknown bug into it.
So i personally prefer to have a minimum possible program base and only if i need to install any additional software so to keep the overall installed apps to minimum and use only those that i really need to provide some service.


----------



## kpedersen (Oct 21, 2022)

VladiBG said:


> Think about other users which use FreeBSD as server.


Indeed. And one might argue that there should be a "user-friendly" FreeBSD. And that is fine; however that is not this project. This project is the one that these are built ontop of. You don't start with a messy user-friendly OS and strip things out to make a clean OS. It doesn't go well that way.


----------



## hunter0one (Oct 21, 2022)

Brian546 said:


> Whether you like it or not, whether the foundation says so or not, this is a server OS.


From the freebsd.org homepage:


> FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.


Not that I disagree browsers and X.Org itself has no place in base, but its clear that FreeBSD is a general purpose OS.


----------



## jmos (Oct 21, 2022)

Brian546 said:


> this is a server OS


Has to be repeated much more often to be true  Have you read the first sentence from the main web page? "FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms." Nope, it isn't just a server OS.

Edit: OK, I should read to the end before writing … others wrote that already, too…


----------



## tingo (Oct 21, 2022)

OP: think of other ways to solve your needs.
For me I can summarize it like so: I need a working computer (desktop or laptop, with working net and at least a web browser) in order to install a new computer.


----------



## smithi (Oct 22, 2022)

Alain De Vos said:


> While installing FreeBSD i had in a shell running,
> 
> ```
> elinks https://docs.freebsd.org/en/books/handbook/
> ...



Sure Alain, but how hard is `pkg install elinks`?



VladiBG said:


> Think about other users which use FreeBSD as server. They don't need web browser or pretty GUI as they don't have a monitor attached. All management is done via SSH or SOL.



I've been one of those, but now I'm mostly one if these 



VladiBG said:


> Even if you install the local doc (handbook) you still will need a pdf reader as ghostview (gv) to open the PDF from `/usr/local/share/doc/en/books` and the ghostview still need 59 other dependencies + Xorg so it will end up with ton of other software installed and every single installed software is potential security risk of having some unknown bug into it.



Not necessarily so; here they're at /usr/local/share/doc/freebsd/en/{books,articles}/ and for every .pdf (44 total) there's a matching .html. links works fine and is 4.5MB.

Above the freebsd directory there are 22 more .pdfs but 3850 .htm* files, so no need for X and such to read them.



VladiBG said:


> So i personally prefer to have a minimum possible program base and only if i need to install any additional software so to keep the overall installed apps to minimum and use only those that i really need to provide some service.



Agreed.  Others can install src, ports and packages to taste and requirements.


----------



## VladiBG (Oct 22, 2022)

smithi last time when i check the pdf=on was default format of the docs and the default pkg provide only the pdf version. Unless you fetch the ports and build it from there without pdf=on in the port config.


----------



## cy@ (Oct 22, 2022)

IMO there should be less in base. No server software except for sshd. Remove the MTAs, remove NTP, remove the KDC. Rely fully on ports for this. The user should be able to select packages or groups of packages (meta packages or meta ports) to build whatever they need.

For the reset pkgbase. Not everyone needs everything.

Regarding the kernel, everything should be modules. An install loader.conf that includes everything. When installed only enough to boot the system. Let every other driver load as needed.


----------



## Alain De Vos (Oct 22, 2022)

I can subscribe to this minimalism idea. I compile the kernel with,

```
nooption    COMPAT_FREEBSD4     # Compatible with FreeBSD4
nooption    COMPAT_FREEBSD5     # Compatible with FreeBSD5
nooption    COMPAT_FREEBSD6     # Compatible with FreeBSD6
nooption    COMPAT_FREEBSD7     # Compatible with FreeBSD7
nooption    COMPAT_FREEBSD9     # Compatible with FreeBSD9
nooption    COMPAT_FREEBSD10    # Compatible with FreeBSD10
nooption    COMPAT_FREEBSD32    # Compatible with i386 binaries
```
And everything works fine.
And,

```
nodevice fdc 
nodevice      ahc         # AHA2940 and onboard AIC7xxx devices
nodevice      ahd         # AHA39320/29320 and onboard AIC79xx devices
nodevice      esp         # AMD Am53C974 (Tekram DC-390(T))
nodevice      hptiop          # Highpoint RocketRaid 3xxx series
nodevice      isp         # Qlogic family
nodevice     ispfw           # Firmware for QLogic HBAs- normally a module
nodevice      mpt         # LSI-Logic MPT-Fusion
nodevice      mps         # LSI-Logic MPT-Fusion 2
nodevice      mpr         # LSI-Logic MPT-Fusion 3
nodevice      sym         # NCR/Symbios Logic
nodevice      isci            # Intel C600 SAS controller
nodevice      ocs_fc          # Emulex FC adapters
nodevice      pvscsi          # VMware PVSCSI
nodevice      amr         # AMI MegaRAID
nodevice      arcmsr          # Areca SATA II RAID
nodevice      ciss            # Compaq Smart RAID 5*
nodevice      iir         # Intel Integrated RAID
nodevice      ips         # IBM (Adaptec) ServeRAID
nodevice      mly         # Mylex AcceleRAID/eXtremeRAID
nodevice      twa         # 3ware 9000 series PATA/SATA RAID
nodevice      smartpqi        # Microsemi smartpqi driver
nodevice      tws         # LSI 3ware 9750 SATA+SAS 6Gb/s RAID controller
nodevice      aac         # Adaptec FSA RAID
nodevice      aacp            # SCSI passthrough for aac (requires CAM)
nodevice      aacraid         # Adaptec by PMC RAID
nodevice      ida         # Compaq Smart RAID
nodevice      mfi         # LSI MegaRAID SAS
nodevice      mlx         # Mylex DAC960 family
nodevice      mrsas           # LSI/Avago MegaRAID SAS/SATA, 6Gb/s and 12Gb/s
nodevice      pmspcv          # PMC-Sierra SAS/SATA Controller driver
nodevice     pst         # Promise Supertrak SX6000
nodevice      twe         # 3ware ATA RAID
nodevice      nvme            # base NVMe driver
nodevice      nvd         # expose NVMe namespaces as disks, depends on nvme
nodevice      vmd         # base VMD device
nodevice      vmd_bus         # bus for VMD children
nodevice      ppc
nodevice      ppbus           # Parallel port bus (required)
nodevice      lpt         # Printer
nodevice      ppi         # Parallel port interface device
nodevice     vpo         # Requires scbus and da
nodevice      puc         # Multi I/O cards and multi-channel UARTs
nodevice      iflib
nodevice      em          # Intel PRO/1000 Gigabit Ethernet Family
nodevice      ix          # Intel PRO/10GbE PCIE PF Ethernet
nodevice      ixv         # Intel PRO/10GbE PCIE VF Ethernet
nodevice      ixl         # Intel 700 Series Physical Function
nodevice      iavf            # Intel Adaptive Virtual Function
nodevice      ice         # Intel 800 Series Physical Function
nodevice      vmx         # VMware VMXNET3 Ethernet
nodevice      axp         # AMD EPYC integrated NIC
nodevice      bxe         # Broadcom NetXtreme II BCM5771X/BCM578XX 10GbE
nodevice      le          # AMD Am7900 LANCE and Am79C9xx PCnet
nodevice      ti          # Alteon Networks Tigon I/II gigabit Ethernet
nodevice      mlx5            # Base driver
nodevice      mlxfw           # Firmware update
nodevice      mlx5en          # Ethernet driver
nodevice      ae          # Attansic/Atheros L2 FastEthernet
nodevice      age         # Attansic/Atheros L1 Gigabit Ethernet
nodevice      alc         # Atheros AR8131/AR8132 Ethernet
nodevice      ale         # Atheros AR8121/AR8113/AR8114 Ethernet
nodevice      bce         # Broadcom BCM5706/BCM5708 Gigabit Ethernet
nodevice      bfe         # Broadcom BCM440x 10/100 Ethernet
nodevice      bge         # Broadcom BCM570xx Gigabit Ethernet
nodevice      cas         # Sun Cassini/Cassini+ and NS DP83065 Saturn
nodevice      dc          # DEC/Intel 21143 and various workalikes
nodevice      et          # Agere ET1310 10/100/Gigabit Ethernet
nodevice      fxp         # Intel EtherExpress PRO/100B (82557, 82558)
nodevice      gem         # Sun GEM/Sun ERI/Apple GMAC
nodevice      jme         # JMicron JMC250 Gigabit/JMC260 Fast Ethernet
nodevice      lge         # Level 1 LXT1001 gigabit Ethernet
nodevice      msk         # Marvell/SysKonnect Yukon II Gigabit Ethernet
nodevice      nfe         # nVidia nForce MCP on-board Ethernet
nodevice      nge         # NatSemi DP83820 gigabit Ethernet
nodevice      sge         # Silicon Integrated Systems SiS190/191
nodevice      sis         # Silicon Integrated Systems SiS 900/SiS 7016
nodevice      sk          # SysKonnect SK-984x & SK-982x gigabit Ethernet
nodevice      ste         # Sundance ST201 (D-Link DFE-550TX)
nodevice      stge            # Sundance/Tamarack TC9021 gigabit Ethernet
nodevice      vge         # VIA VT612x gigabit Ethernet
nodevice      vr          # VIA Rhine, Rhine II
nodevice      xl          # 3Com 3c90x (``Boomerang'', ``Cyclone'')
nodevice      snd_cmi         # CMedia CMI8338/CMI8738
nodevice      snd_csa         # Crystal Semiconductor CS461x/428x
nodevice      snd_emu10kx     # Creative SoundBlaster Live! and Audigy
nodevice      snd_es137x      # Ensoniq AudioPCI ES137x
nodevice      snd_via8233     # VIA VT8233x Audio
nodevice      hyperv          # HyperV drivers 
nodevice      xenpci          # Xen HVM Hypervisor services driver
nodevice      iwifw
nodevice      iwnfw
nodevice      snd_driver
nodevice      snd_ad1816
nodevice      snd_als4000
nodevice      snd_atiixp
nodevice      snd_cmi
nodevice      snd_cs4281
nodevice      snd_csa
nodevice      snd_ds1
nodevice      snd_emu10kx
nodevice      snd_envy24
nodevice      snd_spicds
nodevice      snd_envy24ht
nodevice      snd_es137x
nodevice      snd_ess
nodevice      snd_sbc
nodevice      snd_fm801
nodevice      snd_mss
nodevice      snd_maestro
nodevice      snd_maestro3
nodevice      snd_neomagic
nodevice      snd_sb16
nodevice      snd_sb8
nodevice      snd_solo
nodevice      snd_t4dwave
nodevice      snd_via8233
nodevice      snd_via82c686
nodevice      snd_vibes
```
Probably i've forgotten some devices i don't use.


----------



## smithi (Oct 22, 2022)

VladiBG said:


> smithi last time when i check the pdf=on was default format of the docs and the default pkg provide only the pdf version. Unless you fetch the ports and build it from there without pdf=on in the port config.



I'm on 12.3-RELEASE and installed docs from the .pkg with that.

If 13.x has really ditched the much smaller .html files then that's an absurd regression that would indeed mandate installing Xorg just to read local docs, when a 4.5MB binary will do the job.


----------



## jmos (Oct 23, 2022)

Alain De Vos said:


> Stating browsers are important to find information.


Discussing what the base system should include (and what not) will never get a satisfying result for more than one person. I agree to you that one should be able to get docs/informations by just having a basic installation, but that should be possible without being forced to have the network up & running - so a webbrowser won't make sense. I think there are things that could be moved to the ports tree (f.e. sendmail - makes more sense as a port (and exists as a port, too); pax - never saw anyone using this; banner - why ever a OS needs that etc.), but overall: FreeBSD did a great job so far.


----------



## zirias@ (Oct 23, 2022)

I'm more or less with cy@ here. Maybe a bit less "radical". IMHO, base should keep its character of being a working, integrated OS. And, again, IMHO, this includes a (simple) MTA, cause stuff like e.g. cron needs it. But apart from these details, yes, keep base as small and lean as possible! I personally don't see any valid reason to have a full-featured MTA like sendmal, just for example.

As we've seen it here _yet again_: *No*, FreeBSD ist not a "server OS". It is a general purpose OS. But this of course doesn't mean you need any "desktop" stuff in base. Base is self-contained and a working ("minimal") OS. Nothing would ever depend on e.g. a web browser.

What I personally want to keep in base (other than what's strictly necessary for it to be self-contained) is "admin tools". Just as one example: cu(1). This tool allows you to access a serial console of a headless server, without owning one of these hardware serial terminals


----------



## zirias@ (Oct 23, 2022)

Oh, I forgot to answer the original question. Although, the link in the first response already explains a lot .

But when specifically asking about the decision what's part of base and what isn't, well it's just applying this structure in practice. If someone thinks something should be added or removed, well, the typical way to go would be to open up a discussion on a mailing list, likely also adding a review on phabricator about the intended change. Most of the times, this will be a public mailing list, so contributors and users can add their 2 cents as well. In some specific cases, the discussion might be started on (or, later moved to) an internal mailing list... These discussions will typically reveal a tendency. Only if things can't be resolved in discussion, e.g. the "core" team (which is, of course, elected!) will finally decide stuff.

Personal opinion: FreeBSD is both more organized and more democratic than e.g. Linux, which I like very much


----------



## kpedersen (Oct 23, 2022)

zirias@ said:


> As we've seen it here _yet again_: *No*, FreeBSD ist not a "server OS". It is a general purpose OS. But this of course doesn't mean you need any "desktop" stuff in base.


Agreed. Regardless of the "mechanism", this will tend to mean that base should be even more spartan to cater to the lowest common denominator between server and client.

A server would come with more stuff than in a general purpose base.


----------



## Alain De Vos (Oct 23, 2022)

I vote for "oksh" in base. Note oksh is a program without external dependencies or dynamic libraries.
In fact i copied "oksh" into /bin in order for eventual "recovery".
Do you want "sendmail" or "opensmtpd" in base is an interesting question ? Or ntpd ? Or cron ? Or syslog ?
I did not include "sendmail" in base.
I don't use base ntpd but ports ntpd.
I don't use base cron but ports fcron.
I don't use base syslog but ports syslog-ng.


----------



## zirias@ (Oct 23, 2022)

Alain De Vos said:


> I vote for "oksh" in base.


Won't happen. Sure, you could try to discuss this on the mailing lists, but I can predict the outcome  ... one bourne shell in base is all it takes. It's OTOH questionable to also include a C shell (tcsh), it seems this is done mostly for "historic reasons".


Alain De Vos said:


> Do you want "sendmail" or "opensmtpd" in base is an interesting question ? Or ntpd ? Or cron ?


Currently, there's both sendmail and dma in base for the role of an MTA. IMHO, one of them would be enough, of course prefer the minimal one (dma). I think cron is a "must have" for a self-contained working base system. Ntpd could probably be up to discussion ....


----------



## Alain De Vos (Oct 23, 2022)

"openssh" in base seems logical.


----------



## ralphbsz (Oct 23, 2022)

cy@ said:


> IMO there should be less in base. No server software except for sshd.


I mostly agree. Base should contain all the software that is required to make a minimal but functioning computer. The question here is how to define "functioning". Today, a computer that can't be networked is mostly considered useless, so we need the basic TCP/IP stack, we need setup utilities (like DHCP client and configuring the hostname and resolver).

A computer that can not be accessed is pointless and might as well not exist. In the old days, that meant that you have to be able to connect a terminal to the computer, often by serial line. Starting with the IBM PC era, that was replaced by connecting a video monitor and a keyboard. Today, a large fraction of all computers no longer have physical console connections (they are in data centers, or virtualized). So sshd is absolutely needed, as it is often the only sensible way of getting into the computer. Technically, sshd is a server (in the networking sense), but in the practical sense, it does not provide a service to other machines.



> Remove the MTAs, remove NTP, remove the KDC.


Here I disagree. Within a modern Unix system, minimal functioning email is required, even within a single computer. The one example already mentioned is storing results from cron job. I think base needs to contain at the minimum a simple and preconfigured MTA and MUA. Whether that has to be sendmail or not is something worth discussing, although I come down on the side of wanting sendmail present (even tough I personally don't use it on any machine).

Similarly, in a modern networked world a computer whose clock is off is just a nuisance. A minimal but functioning NTP client needs to be present in base. That does not mean that base needs to contain a full-feature NTP; for example the capability to connect to hardware clocks (such as GPS receivers) or being an NTP server is not required for basic operation.

Cron and syslog are more examples: A basic version of both is needed for a simple system to function sensibly.



Alain De Vos said:


> I vote for "oksh" in base.


Why? We already have a good functioning korn shell in base. It has been there for many years. In the case of shells, removing them from base is very dangerous, because there is a huge installed corpus of scripts that rely on the features of the base shell.


----------



## Alain De Vos (Oct 23, 2022)

I was told it dangerous to change the root shell.
I use zsh as root shell, and every script works fine, even /etc/rc.subr .
But yes, the number of shells in base should be limited.
Because otherwise you end up in a shell-scripting-flavor-hell.


----------



## zirias@ (Oct 23, 2022)

There's only one shell scripting standard, and that's bourne (POSIX). So IMHO, any different shell (C shells!) doesn't need to be in base.



Alain De Vos said:


> I was told it dangerous to change the root shell.


This is "dangerous" because your shell _might_ be damaged by port upgrades (or might be unavailable if /usr/local resides on a different device, although that's unusual nowadays). Without a "base system" (looking at Linux), you wouldn't even have a chance to avoid that danger. You can easily avoid it by giving at least one of `root` or `toor` a shell that's in base.


----------



## ralphbsz (Oct 23, 2022)

Now you're mixing two different concepts. Perhaps three.

First question: FreeBSD has to ship with at least one shell in base. One of the reasons is that users have to be able to start a login session, and have at least a minimally functioning shell. It is also needed for those parts of the base system that are implemented as shell scripts, for example the rc system. The current implementation needs a Korn-style or Posix-style shell. What exact shell implementation is used here is somewhat secondary, but there really is no benefit and grave danger in changing it.

That basic scripting shell, which is absolutely required, does not have to be any users login shell, the one they are faced with with doing interactive CLI use. For historic reasons, BSD has always shipped a csh variant for that, and this is the default login shell of the root user. But note that the login shell of any user (including root) does not have to be the same as the scripting shell that's used for mandatory parts of the system.



Alain De Vos said:


> I was told it dangerous to change the root shell.


Yes, and no. Yes: If a clueless system administrator changes the root shell to something that breaks, then they can't easily dig themselves out of the grave they dug. That particularly includes the historically common case of a shell that is in /usr/local (not mounted if disks fail or file systems break or we are in single-user mode), or depends on shared libraries that can easily be broken. If this happens, they either need to reinstall the system, or get a functioning OS in another way (boot from USB stick or CD) and repair what they did, and that is a big hassle (and in the old days, it wasn't even possible).

No: A knowledgeable admin can change the login shell of the root user, and if they're careful, it will work fine. Classic example is to statically link that new shell, and store it in the root file system (or at least in the same file system that contains bin). With today's systems typically not having multiple physical disks, and modern file systems being very reliable, it is even possible to use a dynamically linked shell that's in /usr/local. For example, on my machine, root uses bash. If you look at /etc/rc, it clearly uses /bin/sh.



> I use zsh as root shell, and every script works fine, even /etc/rc.subr .


Did you install the zsh package, and then changed the login shell for root to be zsh? In that case, scripts such as /etc/rc* do not use zsh. The way they run is: the executor looks at their first line (which is /bin/sh), and runs that program.

On the other hand, if you actually overwrote /bin/sh with a copy of zsh (perhaps a link to it), then you are indeed using it. It would be mildly surprised if the system still worked, but pleasantly surprised: It would mean that the folks who write and maintain the /etc/rc system have done an excellent job of being independent of features of specific shells, and use only the common subset.

For this reason, one of the good practices of people writing shell scripts is to test their scripts with a minimal shell. The best one for this purpose is actually the ancient V7 Bourne shell. Note: I mean the implementation written by Steve Bourne at Bell Labs, not what we today call bash. I think pdksh (can be put into a V7-compatible mode (perhaps it's a build option) that is good for developing scripts.



> But yes, the number of shells in base should be limited.
> Because otherwise you end up in a shell-scripting-flavor-hell.


Matter-of-fact, the correct number of shells in base should be 1, that being minimal. And since the traditional /bin/sh needs to exist, that should be the only one. In practice, this is not a good idea, since many users have come to rely on tcsh being present, and many existing installations have scripts (including login files and aliases) that rely on that.

I don't see any need to change anything here. If someone wants another shell, they're super easy to install, but they should not be in base. Personally, I always configure all my accounts to use bash, for consistency: It is a reasonably good shell (with a few annoying gnu-isms, but I can grit my teeth), and it is easily available on all machines I use.


----------



## jmos (Oct 23, 2022)

Alain De Vos said:


> In fact i copied "oksh" into /bin in order for eventual "recovery".


oksh uses libraries from the base system (actually /lib/libncursesw.so.9  and /lib/libc.so.7); So f.e. after an upgrade of FreeBSDs base system your recovery shell may require a library that isn't available anymore. None shell from the ports tree is a good idea for roots tasks.


----------



## Alain De Vos (Oct 23, 2022)

So if i'm correct i must look for staticly linked shells without any dynamic dependency as recovery shell ?
But,
ldd /bin/sh            

```
/bin/sh:
    libedit.so.8 => /lib/libedit.so.8 (0x1090d1ee000)
    libc.so.7 => /lib/libc.so.7 (0x1090eb8d000)
    libncursesw.so.9 => /lib/libncursesw.so.9 (0x1090dde4000)
```


----------



## kpedersen (Oct 23, 2022)

jmos said:


> None shell from the ports tree is a good idea for roots tasks.


There is bash-static which should be fine in theory but curiously, it drags in more dependencies than standard bash. I think the port might be broken.

If I recall, running a `ldd` on it reveals that it isn't statically linked either.


----------



## Alain De Vos (Oct 23, 2022)

/usr/ports/shells/bash-static #make patch
===>  bash-static-5.2_3 is marked as broken: ld: error: undefined symbol:
rl_trim_arg_from_keyseq.
*** Error code 1


----------



## Alain De Vos (Oct 23, 2022)

Dynamic linking with libraries is not a problem as long as they don't get broken by upgrades.
Who checks if an upgrade don't break a dynamic linking ? Rethorical question.


----------



## _martin (Oct 23, 2022)

kpedersen said:


> If I recall, running a `ldd` on it reveals that it isn't statically linked either.


Nope, it is a fancy blob of static ELF. It's not broken, works just fine. I use it on all my FreeBSD servers, even as root. And yes, I walked the walk of shame before when I had to boot the rescue CD to fix the login after unsuccessful upgrade.

While on HP-UX I've got very much used to ksh on daily basis. But I must admit I like bash as interactive shell (`/me ducks down`). And yeah, it's a big blob. I don't care for interactive shell. For scripts I stick to the classics - sh.



Alain De Vos said:


> Dynamic linking with libraries is not a problem as long as they don't get broken by upgrades.


Problem is not that it depends on a library but rather it depends on a library from ports. And those can break easier. It's assumed that your base doesn't get screwed up that easily.  You can always create an emergency rescue user that has shell in /rescue/sh in case of an emergency. But if you can't use csh from base because of dynlib usually you have bigger problems.


----------



## Alain De Vos (Oct 23, 2022)

You walked  the wall of shame, we all did.
Once I wanted to clean my system
So I did a rm -vfR /usr/local.
But my root shell zsh dynamic library was there.

Now comes the interesting part,
ldd
usr/local/bin/oksh:
    libncursesw.so.9 => /lib/libncursesw.so.9 (0x822073000)
    libc.so.7 => /lib/libc.so.7 (0x822702000)
You see nothing in /usr/local ... except oksh itself wich i had put in /bin
oksh has only dependencies in "base/world". Which have the tendency to be "more stable".


----------



## jmos (Oct 24, 2022)

Alain De Vos said:


> oksh has only dependencies in "base/world". Which have the tendency to be "more stable".


Yes, but: That dependencies may differ from what your system actually provides. An actual example can be found in a german BSD forum: Someone set Bash as the default shell. By upgrading from FreeBSD 12.x to FreeBSD 13.1 after a reboot (without having run the package upgrade yet) even a login required libncursesw.so.8, but that wasn't available anymore. So there was much more trouble to upgrade the packages after upgrading world.
OK, I'm sure you would be able to solve this by yourself, but: A shell that is not compiled with the whole environment it is running on is not a good idea to rely on.


----------



## ralphbsz (Oct 24, 2022)

As long as the system can boot and come up to the multiuser level (logins are possible), a lot of these issues can be solved by having a second root account (typically called toor), which uses a boring standard shell as its login shell. Traditionally, it uses (t)csh.


----------



## kpedersen (Oct 24, 2022)

_martin said:


> Nope, it is a fancy blob of static ELF. It's not broken, works just fine. I use it on all my FreeBSD servers, even as root.


Interesting. I use bash as my interactive shell on most my machines. Mainly because I am quite used to it but also so I can sidestep *bashisms* with my colleagues scripts 

It is just strange that the bash-static package drags in *any* additional dependencies. Perhaps for installation I will just extract it manually from the package file.


----------



## SirDice (Oct 24, 2022)

Alain De Vos said:


> So if i'm correct i must look for staticly linked shells without any dynamic dependency as recovery shell ?
> But,
> ldd /bin/sh


/bin/sh is part of the base OS and is updated at the same time as /lib/libc.so. So there's never a risk of having the shell linked to a non-existing version of libc (they are both built and installed in unison). A shell that's installed with a port/package would still be linked to the 'old' libc version from the previous major version.


----------



## _martin (Oct 24, 2022)

kpedersen said:


> It is just strange that the bash-static package drags in *any* additional dependencies.


Yeah, that's true. Even pkg says so. While readelf doesn't show any dependencies I can't do this:
	
	



```
# cp /usr/local/bin/bash /a
# chroot /a /bash
Segmentation fault (core dumped)
#
```
So something's up with it. Not in a mood to debug it why now though. Always handy to have that rescue/2nd root account with a shell from base, that's for sure.

Just for demo if one needs a rescue user this does work:
	
	



```
# cp /rescue/sh /a/
# chroot /a /sh
Cannot read termcap database;
using dumb terminal settings.
#
```
But as I've mentioned if one has problem with libc login in general is least of the problem.


----------



## SirDice (Oct 24, 2022)

_martin said:


> So something's up with it.


You're missing a couple of important /dev/ entries in your chroot(8).


----------



## Alain De Vos (Oct 24, 2022)

_martin said:


> Yeah, that's true. Even pkg says so. While readelf doesn't show any dependencies I can't do this:
> 
> 
> 
> ...


chroot / /a works fine


----------



## _martin (Oct 24, 2022)

Alain De Vos said:


> chroot / /a works fine


Not sure what you're trying to achieve; I wanted to chroot to /a and let the /bash within chroot be the shell being executed. Static binary without further dependency (or configuration requirement) would survive that. 



SirDice said:


> You're missing a couple of important /dev/ entries in your chroot(8).


It should not crash because of that though. Curiosity did get best of me, I checked it. As I wanted to have debug symbols I compiled the bash from ports with static flag. This actually works:
	
	



```
# mkdir /a && cp /usr/ports/shells/bash/work/bash-5.2/bash /a
# chroot /a /bash
# echo /*
/bash
#
```
So bash-static from binary package is built differently. It's a pity FreeBSD doesn't ship debug symbols to go along the binary packages. It crashed because it killed itself. I'd assume it has some lib dependency that it fails on. Stacktrace was a bit weird though.


----------



## SirDice (Oct 24, 2022)

_martin said:


> It's a pity FreeBSD doesn't ship debug symbols to go along the binary packages.


You need to build the port with DEBUG set. It's one of those 'hidden' options that's nearly always available but doesn't need to be in OPTIONS in the port's Makefile.


----------



## _martin (Oct 24, 2022)

SirDice said:


> You need to build the port with DEBUG set. It's one of those 'hidden' options


I was talking about the binary packages not ports. FreeBSD doesn't provide these, one has to build the port with appropriate make.conf in place or toggle OPTIONS.


----------



## SirDice (Oct 24, 2022)

_martin said:


> FreeBSD doesn't provide these, one has to build the port with appropriate make.conf in place or toggle OPTIONS.


Doesn't need to be in OPTIONS or make.conf. You can just add it, `make -DWITH_DEBUG install` in the port's directory.


----------



## _martin (Oct 24, 2022)

We don't understand each other. I'm talking about debug symbols to the binary packages, packages that are installed by pkg. If I do `pkg install bash-static` I'll get the binary package without debug symbols. It would be nice if debug symbols would be available for that binary package, something like `bash-static-dbgsym`. This is not available so whenever one wants to have debug symbols for a given package it has to be built from ports (issue here is not how to build a port with debug symbols).

But since I did this bash test now for the sake of chroot it seems bash-static is built differently when it's shipped with binary package as my chroot test shows. Which is interesting.


----------



## kpedersen (Oct 24, 2022)

_martin said:


> it seems bash-static is built differently when it's shipped with binary package as my chroot test shows. Which is interesting.


Indeed. There is something not quite right with it. I assumed that the port was rotting a little because the static flavour probably isn't used by many users so is lacking some testing.


----------



## _martin (Oct 24, 2022)

kpedersen said:


> the static flavour probably isn't used by many users so is lacking some testing.


Yeah, could be. All my physical boxes use ports so I never had any issue with it.
I might poke around a bit around that crashdump as that did catch my attention and spur some curiosity.


----------



## _martin (Oct 24, 2022)

I poked around in gdb and figured that out it's crashing on internal strcmp (arg0 being NULL). Don't want to go into too much detail; I found a way to make it work: 
	
	



```
# mkdir /a
# cp -p /usr/local/bin/bash /a
# chroot /a /bash
Segmentation fault (core dumped)
#
# LC_ALL=C chroot /a /bash
# echo /*
/bash /bash.core
#
```
Interestingly enough bash 5.1 doesn't have this problem. Not that this helps anybody.


----------



## hardworkingnewbie (Oct 24, 2022)

Wouldn't the POSIX standard be the minimum document of what goes into base?


----------

