The FreeBSD Handbook, Chapter 12. Linux Binary Compatibility: https://docs.freebsd.org/en/books/handbook/linuxemu/ Its first suggestion for linux userland is in section: 12.3.1. CentOS Base System from FreeBSD Packages But the package it recommends, linux_base-c7, is deprecated. Seems therefore that the handbook should not recommend this at all!
https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/ https://www.centos.org/download/ Looks like CentOS is still alive (version 9).. for some reason I thought the project is dead.. was it resurrected? I switched to Debootstrap and now with APT I have zero problems with Linux packages management on FreeBSD :-)
The status of CentOS itself isn't really relevant... The Handbook recommends the "linux_base-c7" package, and that package is deprecated: https://www.freshports.org/emulators/linux_base-c7/
What I meant the whole CentOS seems 0xDEADBEEF (deprecated) but that does not solve the problem of documentation ;-) https://www.redhat.com/en/blog/centos-linux-going-end-life-what-does-mean-me
I guess the update is linux_base-c7 -> linux_base-rl9 (Rocky Linux 9)
^Triage: Upstream deprecation is a separate issue from Linuxulator's progress. c7 will be deprecated when is rl9 is supporting all use cases supported by c7, and then the doc will be updated. The doc is still WAI by recomending the currently supported path.
How can it be 'working as intended' to recommend using a deprecated port? Deprecation literally means something is discouraged from being used: https://en.wikipedia.org/wiki/Deprecation But being listed in the document is encouraging it to be used, exactly the opposite. At the very least, shouldn't the document have a warning note to say that the port is deprecated and to be prepared for a migration in the future?
Sorry I wasn't clear, upstream has deprecated it, but we have not deprecated it because the replacement is under development and not yet at feature parity.
Who is "we"? The "linux_base-c7" port is deprecated, see here: https://www.freshports.org/emulators/linux_base-c7/ Maybe the "we" that marked it deprecated is a different "we" than you're talking about? When doing a `pkg update/upgrade` on my server that uses it, I got a big warning about the port being deprecated. So I went to the Handbook for guidance, but found none. So I came here to lobby for Handbook improvements so that others that get warnings from `pkg` will have some idea what to do.
(In reply to Sean McBride from comment #8) Maybe I missed it, but where is DEPRECATED exactly? I don't see it in the Makefile: https://cgit.freebsd.org/ports/tree/emulators/linux_base-c7/Makefile
Hopefully, "we" represents the consensus of the the FreeBSD Project, I don't want to misuse the term. Interesting discrepancy, that is much more helpful than the wikipedia article and would have been helpful in the initial post. I too checked the makefile, then asked the SMEs I knew who were using Linuxulator. I am going to consider this issue as escalated to a comitter and bow out, but I'm interested in the conclusion!
(In reply to Fernando Apesteguía from comment #9) https://cgit.freebsd.org/ports/commit/Mk/Uses/linux.mk?id=45d64d8e70ae4848b855f6eb81bb4ad13162a8c9
Fernando, I don't know where or how or who marked it deprecated. 1) it shows as deprecated on freshports: https://www.freshports.org/emulators/linux_base-c7/ 2) running `pkg update/upgrade` the other day I got the following output: ``` Message from linux_base-c7-7.9.2009_3: -- ===> NOTICE: This port is deprecated; you may wish to reconsider installing it: CentOS Linux 7 reached end of life (EOL) on June 30, 2024. ===== Message from linux-c7-devtools-7.9.2009_3: -- ===> NOTICE: This port is deprecated; you may wish to reconsider installing it: ``` 3) running `pkg audit` just now and I get things like: ``` libsndfile -- out-of-bounds read memory access CVE: CVE-2017-6892 WWW: https://vuxml.FreeBSD.org/freebsd/004debf9-1d16-11e8-b6aa-4ccc6adda413.html libsndfile -- multiple vulnerabilities CVE: CVE-2017-14634 CVE: CVE-2017-12562 CVE: CVE-2017-8365 CVE: CVE-2017-8363 CVE: CVE-2017-8362 CVE: CVE-2017-8361 WWW: https://vuxml.FreeBSD.org/freebsd/2b386075-1d9c-11e8-b6aa-4ccc6adda413.html libsndfile -- out-of-bounds reads CVE: CVE-2017-17457 CVE: CVE-2017-17456 CVE: CVE-2017-14246 CVE: CVE-2017-14245 WWW: https://vuxml.FreeBSD.org/freebsd/30704aba-1da4-11e8-b6aa-4ccc6adda413.html libsndfile -- multiple vulnerabilities CVE: CVE-2017-7742 CVE: CVE-2017-7741 CVE: CVE-2017-7586 CVE: CVE-2017-7585 WWW: https://vuxml.FreeBSD.org/freebsd/5a97805e-93ef-4dcb-8d5e-dbcac263bfc2.html linux-c7-nettle-2.7.1_1 is vulnerable: nettle 3.7.2 -- fix serious ECDSA signature verify bug WWW: https://vuxml.FreeBSD.org/freebsd/80f9dbd3-8eec-11eb-b9e8-3525f51429a0.html linux-c7-sqlite-3.7.17_2 is vulnerable: sqlite -- use-after-free bug in jsonparseaddnodearray CVE: CVE-2024-0232 WWW: https://vuxml.FreeBSD.org/freebsd/42ec2207-7e85-11ef-89a4-b42e991fc52e.html ``` If freshports can be trusted, these ports are not getting updates, not even security updates. So again: it seems to me the Handbook should really not be suggesting their use.
tijl@ marked the port as deprecated, yes. I think in that case I will change the documentation. I'll wait for tijl@ to chime in just in case. Please Sean (and others). Feel free to ping me in a couple of days if you don't hear from me.
I'm surprised all of this is done without an issue dedicated to tracking the linux_base-c7 removal. For example, I can't move games/linux-steam-utils to linux_base-rl9 without i386 libs and that requirement is essentially invisible to other people. There might be a few minor issues here and there with other ports as well.
The upstream EoL means there won't be any security fixes so I marked the ports DEPRECATED to make users aware of that. There are no plans to remove the c7 ports because the rl9 ports don't support 32 bit programs and they require x86-64-v2 (CPU from 2010). I've been thinking of replacing c7 with debian 12, but I don't have time for that right now.
Then, since the packages are not planned for removal, I think we can close this one. I might add a note in the documentation if it helps noting that the c7 ports are deprecated upstream and that rl9 should be used instead unless 32 bit compatibility is required. Would that work for you guys?
Whether they are planned for removal or not, I strongly feel they should be discouraged and warned against because they won't be getting security updates. Fernando, your suggestion sgtm.
https://reviews.freebsd.org/D47017
Beautiful! Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/doc/commit/?id=1536574a26a531edf09d5f1d6d144329797cdd4c commit 1536574a26a531edf09d5f1d6d144329797cdd4c Author: Fernando Apesteguía <fernape@FreeBSD.org> AuthorDate: 2024-05-15 17:53:01 +0000 Commit: Fernando Apesteguía <fernape@FreeBSD.org> CommitDate: 2024-10-11 16:29:36 +0000 [handbook][linuxemu]: Mention Rocky Linux 9 userland And add note about c7 deprecation PR: 281837 Reviewed by: 0mp@ Differential Revision: https://reviews.freebsd.org/D47017 .../content/en/books/handbook/linuxemu/_index.adoc | 50 +++++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-)
Review committed, Thanks!
% pkg search rl9 | grep -i meta linux-rl9-9.4 Meta-port for all things Rocky Linux 9.4 % emulators/linux_rl9 does not exist. Linked from <https://docs.freebsd.org/en/books/handbook/linuxemu/#linuxemu-rockylinux>: <https://cgit.freebsd.org/ports/tree/emulators/linux_rl9/>
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/doc/commit/?id=d4f2d0af3b7636a35722db902b05fd897488569d commit d4f2d0af3b7636a35722db902b05fd897488569d Author: Fernando Apesteguía <fernape@FreeBSD.org> AuthorDate: 2024-10-13 20:51:38 +0000 Commit: Fernando Apesteguía <fernape@FreeBSD.org> CommitDate: 2024-10-13 20:52:35 +0000 [hb][linuxemu]: Fix typo in package name PR: 281837 Reported by: grahamperrin@gmail.com documentation/content/en/books/handbook/linuxemu/_index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks!
FYI, now I have to explain all of this to random people and I don't appreciate that at all: https://github.com/shkhln/linuxulator-steam-utils/issues/143. Especially since this is quite an abuse of semantic definition of "deprecation".
>Especially since this is quite an abuse of semantic definition of "deprecation". What is an abuse of the definition of "deprecation"? deprecation = "the discouragement of use" It seems entirely appropriate here. `pkg audit` lists unfixed security bugs, and the port maintainer has said they won't be fixed. Thus those ports should be discouraged from being used.
(In reply to Sean McBride from comment #26) https://www.merriam-webster.com/dictionary/deprecate: > to withdraw official support for or discourage the use of (something, such as a software product) _in favor of a newer or better alternative_ (emphasis mine) Also, it's pretty clear from the linux_base-c7 _remaining the default setting_ in the ports, it's not quite discouraged yet, never mind alternatives not being ready.
I guess "better" is subjective. For me, anything that still gets security updates is better than anything that doesn't get security updates. But I guess that depends if you are using FreeBSD on a publicly facing server, or using it to play games on an ancient i386 CPU.
That's enough.
(In reply to Alex S from comment #27) I agree this situation is far from ideal, but leaving the c7 packages as if nothing happened would have been detrimental for users. I think it is better that they are aware those packages are deprecated upstream and they will not get any security updates. The documentation only recommends c7 if 32 bit support is necessary. In that case it is at users' discretion to do so. I'm open to clarify the docs if necessary. Replacing/adding another Linux emulation package set is very costly and won't happen anytime soon.
This needs a better warning because a giant use case of where Linuxulator works today is 32 bit software. Maintainer said his users were astonished because something is printing a giant warning not to use a piece of software which has no replacement. Now his users and Sean are talking down to him without putting any effort into understanding the situation. Can we please find a better wording for the deprecation notice to reflect the fact that c7 is the currently recomended path for 32-bit software?
(In reply to Alexander Ziaee from comment #31) Do you being more explicit here? https://docs.freebsd.org/en/books/handbook/linuxemu/#linuxemu-centos
(In reply to Fernando Apesteguía from comment #32) How's: ``` "FreeBSD provides the legacy CentOS 7 userland for running 32-bit Linux applications. To install the CentOS 7 userland execute the following command:" ```
Or: ``` "FreeBSD provides the deprecated CentOS 7 userland for running 32-bit Linux applications. To install the CentOS 7 userland execute the following command:" ```
(In reply to Alexander Ziaee from comment #34) The inconvenient I see with this message is that it is not explicit with the fact that the packages will not receive security updates. I think we need to be transparent about that in the message. Also I think we should recommend rl9 packages if they work for the user purposes... And this should be no doubt a warning, not a normal text.
Opening up with warning boxes makes everyone complain loudly, that is the cause of this in the first place, not any actual security breaches. By being more explicit about CentOS 7, and even using the word deprecated, the user should understand that is ancient and obviously not recieving updates. Similar to how we provide ftp support. It is for compat, and people know it is for compat, and it is an amazing feature that helps people for that. ``` "FreeBSD provides the deprecated CentOS 7 userland for running 32-bit Linux applications. To install the CentOS 7 userland execute the following command:" ``` Look at what we did with sysexits for example. The functionality is described first: https://man.freebsd.org/cgi/man.cgi?query=sysexits&apropos=0&sektion=0&manpath=FreeBSD+15.0-CURRENT&arch=default&format=html
>Now his users and Sean are talking down to him... For the record, I'm not talking down to anyone. I've explained my view forthrightly. "better" really is subjective. There's nothing wrong with the use case of, for example, games on i386, but what's better there is genuinely not what's better in other scenarios. i386 is currently Tier 2, and projected to be unsupported in FreeBSD 15.x, so IMHO the docs should concentrate on the more mainstream use case. Certainly they could and should point out the limited cases where using this deprecated stuff still makes sense.
Sorry for the misunderstanding then! This has nothing to do with i386 hardware or server. This issue is about 32-bit application support on current hardware, which yes in 2024, there are plenty of for the desktop use case, which is extremely important to the "not driving away next generation" use case. Maintainer maintains a current, 32-bit desktop application for FreeBSD called "Steam" which is generally working on FreeBSD and is (cross platform total) used by ~62 million people each day. These warnings make users yell inappropriately, because this is *the currently working method* of running *current* 32-bit linux applications on current hardware, on current freebsd. These commits are, I think unintentionally, deprecating working *32-bit linux application support*.
Being able to use an operating system for day to day desktop tasks is an important use case for younger talent deciding if they want to learn freebsd, which is required for maintaining a healthy freebsd software ecosystem on server.
FWIW, linux_base packages only exist to serve as dependencies of other packages. They are _not supposed_ be directly installed in the way the docs currently suggest. It doesn't really make sense to discuss their usage out of ports tree. All of our packaged Linux apps are either desktop apps or... game servers. (In reply to Sean McBride from comment #37) > i386 is currently Tier 2, and projected to be unsupported in FreeBSD 15.x You aren't willing to pay even a minimal amount of attention: Steam is structured in way that requires 32-bit compat to run 64-bit apps on an amd64 machine. No 32-bit compat = no Steam. Think what you will about it, but it's an upstream requirement and they aren't budging.
(In reply to Alexander Ziaee from comment #36) Yes, but sysexits are unlikely to show security issues in the future unlike a port. See the approach we do for "unamaintained" ports: "The ${dp_PKGBASE} port currently does not have a maintainer. As a result, it is more likely to have unresolved issues, not be up-to-date, or even be removed in the future..." This is pretty explicit about the state of the port and its implications. I don't think it is a good idea to conceal that from the users. I understand some (many?) linux programs need 32-bit compatibility. I just want users to *understand the risks* of installing c7 ports. Some people install linux emulation to run things that can be run in 64 bits mode. Those people should also be pointed to rl9 ports since they are way more modern and they are still updated. Also, the warning at the beginning of the Centos section was explicitly place there as a consequence of some feedback in the review. How about this? It is less alarming (IMO), but clear enough: ``` The emulators/linux_base-c7 port is no longer maintained upstream and will not receive further security updates. Users who require 32-bit compatibility may continue to use emulators/linux_base-c7, though caution is advised due to potential security vulnerabilities. For users working in a 64-bit environment, it is recommended to migrate to the Rocky Linux Base System (emulators/linux_base-rl9), which is actively maintained and supported. ```
>Being able to use an operating system for day to day desktop tasks is an important use case for younger talent deciding if they want to learn freebsd, which is required for maintaining a healthy freebsd software ecosystem on server. I agree completely. >... this is *the currently working method* of running *current* 32-bit linux applications on current hardware, on current freebsd. I see. Indeed I had misunderstood it being about 32 bit hardware, sorry about that. >These warnings make users yell inappropriately... Not sure it's so inappropriate honestly, after all, what you're saying is that the current best method is based on a dead upstream (CentOS 7). That's far from ideal. But understandably not easy to fix. But this ticket is about the docs, and I for one have no objection to them being clarified further to point out those deprecated packages are the only way for this use case. Fernando Apesteguía your new text lgtm. >Some people install linux emulation to run things that can be run in 64 bits mode That was the case for me. I used linux_base-c7 because it was the first thing listed in the handbook. It was only thanks to pkg giving the deprecation warning that I knew to look for something newer.
The purpose of a chapter should be the first sentance of the introductory paragraph. That reassures the reader that something they can understand is going on here. Opening up with a warning box before the reader knows what's going on is too emotionally jarring. That is why they complain so agressively and by the time they get to wherever they're going to complain, they aren't ready to get any information about what is going on. Can we convey the information of 1. What is going on in this chapter and 2. The security risk involve; without terrorizing the user? The proposed text is better than before, but opening a chapter with a warning box causes users to stop reading there, and then go complain about our operating system. Similar to how our wayland chapter opened with an arguement instead of a synopsis until this year, and most people just assumed it didn't work and complained, often not to us, which hurts our reputation. Can we use a combination of both? Clear warning in normal text in opening, immediately after explaining purpose: ``` FreeBSD provides the CentOS 7 userland for users who require 32-bit Linux application compatibility. Note that it is no longer maintained upstream and will not receive further security updates. To install the CentOS 7 userland execute the following command: # pkg install linux_base-c7 emulators/linux_base-c7 will place the base system derived from CentOS 7 into /compat/linux. ``` No one who is capable of successfully configuring and using freebsd could miss that, I hope. However it doesn't read like someone is screaming at you. FreeBSD desktop is for nerds, and they get very alarmed when someone is screaming at them. That is why I wrote the synopsis of the wayland chapter having never before or since used wayland. Previously it opened directly into arguing and which is emotionally jarring and creates a massive social problem. Then if a warning box is truly improving the security environment it can go at the end like usual boxes?
So basically, now the handbook have a big warning for centos7, while giving advice to use ubuntu bionic which don't get security update unless you are paying for extended support.
(In reply to Alexander Ziaee from comment #43) > Can we convey the information of 1. What is going on in this chapter and 2. The > security risk involve; without terrorizing the user? "terrorizing"? Really? Quite an hyperbole I think. > Can we use a combination of both? Clear warning in normal text in opening, Clear warning in normal text is a contradiction in itself. *Many* people don't read the text paragraph. Installing the linux base packages is a oneliner. People see the oneliner, execute it and go on with their lives :-) > FreeBSD desktop is for nerds, and they get very alarmed when someone is screaming at them. That was very uncalled for. Don't use that adjective and/or assume people have some kind of specific mental trait. > Then if a warning box is truly improving the security environment it can go at the end like usual boxes? This was discussed in the review, and nobody objected. Only after the commit which is unfortunate and kind of unfair if you ask me. See https://reviews.freebsd.org/D47017#inline-281657 Note that I don't say this commit is perfect (or even good) because it had a backing review. What I say is that this discussion should have happened there. Now, the *objective truth*, the *fact* is that c7 packages are *deprecated upstream*. And we know what that means: no bugfixing, no security updates. What I see here: https://github.com/shkhln/linuxulator-steam-utils/issues/143 is people saying the package is going away, which is false. The package does not have an EXPIRATION_DATE. The same way, an unmaintained port does not go away, but it means it is more likely to have unresolved issues. The other thing I see in that link is someone saying "I kind of expected the same people that contributed the newer linux base to do the necessary preparation work". Well, patches are always welcome. The fact that we have a new linux base system has nothing to do with the fact that c7 packages are deprecated upstream. I don't think hiding the implications of using c7 packages under the rug is a good policy.
(In reply to Thibault Payet from comment #44) The handbook explains how to install a debian/ubuntu system with debootstrap but does not encourages users to do it in detriment of other options. The only advice to install one linux base system instead of another is for the c7 - rl9 *64bit* scenario.
Sorry for the misunderstanding, I was very suprised to hear that nerds is an offensive term, I have never heard of that before, and I meant absolutely no offense whatsoever. Yes sir, a big red warning as the opening of a chapter, before the reader knows what the chapter is for or about, is always terrorizing the reader. The first sentance of any technical introductory paragraph should *always* explain the purpose of the chapter.
(In reply to Fernando Apesteguía from comment #45) > The other thing I see in that link is someone saying "I kind of expected the same people that contributed the newer linux base to do the necessary preparation work". That someone is me and the task was on their todo list (afaik). > Well, patches are always welcome. I actually have a history of submitting unwanted patches (for the last one see bug 247327) and that is why I want to see the tracking issue first. > I don't think hiding the implications of using c7 packages under the rug is a good policy. This is not something that can be fixed on the doc level. Users receive whatever base that is specified their app [package] dependencies. For example, if they type `pkg install linux-chrome` that would be r9, if they type `pkg install linux-sublime3` c7 would be fetched. (And if they want both apps, they are screwed.) There is no realistic scenario where users select the linux base directly and happily continue using it with their app, pkg doesn't allow it. Your warnings are essentially unactionable. The only way to get rid of security issues is updating ports/packages (or removing them entirely), anything else doesn't have any meaningful impact.
>There is no realistic scenario where users select the linux base directly Sure there is. I did. I have a pre-built linux executable from a supplier, and I needed to run it. So I went to the handbook and chose the first thing there.
Manually installing Linux userspace from packages absolutely IS a normal, supported and documented scenario.
I think the way we word the introductory paragraph to a chapter of a doc or manual has a colossal impact on peoples understanding of the topic at hand and even the project as a whole. Please don't write docs saying "well nobody reads them anyway". The quality, length, and semantic density of the introduction is where the reader decides if it's worth reading. If information is disorganized or repetative, then they don't read it.