Downloading Package Binaries

T

Tridac

Still running 14.2 on one machine, and next major upgrade won't be until next spring. Seemed like a good idea to have a local copy of all port binaries, so using pkg fetch, as follows:

pkg fetch -a -s -o /export/nfs/sas4x3840/freebsd-ports/14

Still downloading, but question is, will that port collection be for 14, or something else ?.

Did try to find other repositories, which are there, but all seem to be virtual addresses, url not recognised, so unable to specify the download directory.

Thanks, Chris
 
Tridac said:
Still downloading, but question is, will that port collection be for 14, or something else ?.
Click to expand...
It's a package collection, not a port collection. And they'll be for 14.4 at this time. They're not going to work on 14.2.
 
Thanks, that was what was wanted, but have installed a few packages recently, and they do work, though do get a warning about possible incompatabilites. It's on my head alone, a compromise, until the next major upgrade next year. So, assume whatever uname is running, pkg fetch will download the correct packages.

Perfection and doing it right are always the ideal, but the real world of engineering is often a compromise:-).
 
Tridac said:
Thanks, that was what was wanted, but have installed a few packages recently, and they do work, though do get a warning about possible incompatabilites. It's on my head alone, a compromise, until the next major upgrade next year. So, assume whatever uname is running, pkg fetch will download the correct packages.

Perfection and doing it right are always the ideal, but the real world of engineering is often a compromise:-).
Click to expand...
When you do a normal upgrade, or install packages from a pkg repository that have a newer userland, you do get a warning about it (here is an example for 15.1 ):

Newer FreeBSD version for package zxfer:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1501000
- running userland: 1500068
Ignore the mismatch and continue? [y/N]:
Click to expand...
 
Correct, but at least there is the choice to take the risk. This just exposes the differences between os developers and end users. Modern os systems are so complex, and things move so fast, that a rigid discipline must maintained to avoid chaos. End user developers. on the other hand, just want to use the os to get real work done, with all the compromises and work arounds that that can entail. That is, gettng the job done, whatever that takes.

I'm just grateful that we have a first class os like FreeBSD for anyone to use. With features like ZFS, jails, and straightforward configuration, the closest I have ever seen to the boring, but very effective Solaris 10. No other open sourse os gets close, and I do try to test several new releases of many distros every year.
 
Usually, pkgs of non-kmod ports built against newer minor versions may work.
If you're lucky enough (not recommended, though), you can run non-kmod "binaries" built for FreeBSD 4.x on 16-CURRENT with GENERIC kernel by installing below.
  1. misc/compat4x
  2. misc/compat5x
  3. misc/compat6x
  4. misc/compat7x
  5. misc/compat8x
  6. misc/compat9x
  7. misc/compat10x
  8. misc/compat11x
  9. misc/compat12x
  10. misc/compat13x
  11. misc/compat14x
  12. misc/compat15x
Scripts for languages in ports/pkgs would be the different story as of the lack of backward compatibilities per specific language.
 
Don't remember ever using the compat libraries, but may have been included, perhaps in buiding an older port, with no current maintainer.

Had a progect some years ago (2016 ?), when I was still in Sun fanboy mode, where i wanted to get some frame buffer support for Ultra Sparc, for which FreeBSD (all os's ?) frame buffer support was bit sparse. Thinking, why not run it headless, with vnc across the network ?. Iirc, the FreeBSD version was 11.1, or close. Anyway, ended up building probably hundreds of ports, starting with xvnc, then the simplest frame buffer drivers, and ending with xvnc. All built with barely a warning, from memory, and still have that installed on a Sun V215. A vnc client does work, a bit glacial at load, but once a shell ot two are open, prerfectly usable. More proof of concept, rather than anything else, but was quite amazed as to how easily, all the ports built. That shows robustness. Don't know if anyone else would be interested in that, but have system dmp files, which should load straight back onto another machine. May have to adjust the network device id's, but a generic kernel, so should work on a variety of Sun machines..
 
Within minor versions like 14.2-14.4 older stuff is required to work on newer but newer is not required to run on older.

With that said, sometimes it works anyway like the php patches that were hullabalooed yesterday.

/grandpa
 
I've found it pretty flexible, and one can make tradeoffs as to the risk. The main gotcha being the inability to build older packages from source, as there ar no binaries. The answer here has been to install the older version os, then build from ports. Always install jails as thick jails as well, which provides isolation from the main os of any version, and allows exclusive ownership of a network interface, which can be on a different subnet, another essential aid to security. It's about ways to develop best practices for the sort of work being done.
 
Tridac said:
Always install jails as thick jails as well, which provides isolation from the main os of any version
Click to expand...
Thin jails do to. This isolation from the host OS is the whole point of a jail(8), regardless if it's a 'thick' or 'thin' jail. But the jail can never be newer than the host (14.4 jail on 14.2 host for example), the other way around is not a problem (14.2 jail on a 14.4 host). This is because a jail runs on the host's kernel, it does not have a kernel itself. The kernel is always backwards compatible, not forward.

Packages built for 14.4 may or may not run without problems on a 14.2 system, it's not guaranteed and definitely not a supported set up.

Anyway, I would upgrade the system to 14.5 (14.4 will be EoL soon) now, it's fine if you want to postpone the major version upgrade, the latest minor version of the 'legacy' 14 branch is still supported for a while (14.6 is tentatively scheduled for March 2027).
 
To clarify, i'm aware that a thin jail shares the main os kernal, but understood that a thick jail runs from its own kernel ?. Otherwise, what is the point of a thick jail ?. Afaics, for best security, it should extend right down to hardware level, as you have to assume that security measure in software alone, could be hijacked, given unlimited / determined resources. Would never even consider sharing a single network interface device across different subnets. Hardware is cheap enough to avoid that.
 
Tridac said:
but understood that a thick jail runs from its own kernel
Click to expand...
Nope. A jail(8) runs in a separate namespace on the host's kernel. This separated namespace is what provides the isolation. A virtual machine (bhyve(8) for example) would have more (hardware-level) isolation, but even that could be broken out of due to bugs or other issues.
 
Thanks, sorry to be persistent, but the doc suggests that a thick jail runs its own kernel, with with all the baggage associated. While it may 'run' under the host os kernel, and be allocated cpu time, in theory it only needs to view the jail kernel as another process to run. That distinction is critical to understanding. From simple tests, for any jailed network interface granted exclusive access, the main os kernel is not even aware that the network port exists.

Some really neat tunables in jails, eg: limiting memory usage, right down to defining which cpu core it will run on. On the install, hiding processes running in jails. Quite an achievement, considering that Sun Micro probably had hundreds of engineers to produce their original zones idea. Have spent years on real time embedded, unders Solaris and FreeBSD, but still a newby on the internals, another rabbit hole to dive into. IHave the v2 and earlier of the internals books, but is there a v3 yet ?.
 
Tridac said:
but the doc suggests that a thick jail runs its own kernel, with with all the baggage associated.
Click to expand...
Where does it say that?

Tridac said:
While it may 'run' under the host os kernel, and be allocated cpu time, in theory it only needs to view the jail kernel as another process to run. That distinction is critical to understanding.
Click to expand...
I think you are misunderstanding some fundamentals here. It does not, and will not do anything with a kernel that might be stored in your jail. Remove it and see for yourself, the jail will happily continue working. Also, just enter uname -a inside the jail, you will get the information of the host's kernel.

Tridac said:
Quite an achievement, considering that Sun Micro probably had hundreds of engineers to produce their original zones idea.
Click to expand...
FreeBSD's jail(8) predates Solaris' zones by a few years.
 
FreeBSd Handbook, Quote:

17.2.1. Thick Jails​

A thick jail is a traditional form of FreeBSD Jail.In a thick jail, a complete copy of the base system is replicated within the jail’s environment.This means that the jail has its own separate instance of the FreeBSD base system, including libraries, executables, and configuration files.The jail can be thought of as an almost complete standalone FreeBSD installation, but running within the confines of the host system.This isolation ensures that the processes within the jail are kept separate from those on the host and other jails.
 
Tridac said:
This means that the jail has its own separate instance of the FreeBSD base system, including libraries, executables, and configuration files.
Click to expand...
That's the userland part of the FreeBSD OS, i.e. everything except the kernel.

covacat said:
thick refers to the fact they have their own subtree of fs not some null mounts that share parts of the host or other jail file system
Click to expand...
Aye. There's some debate on what 'thin' means in this context, because you can have a single, statically linked, executable in a jail (so no libraries or other parts of the OS). Can't get any 'thinner' than that. Or 'thin' referring to a single base jail filesystem, that's nullfs mounted to several other, active, jails.
 
Still on thick jails here, never used the thin jail ability. At least some part of the file system must be shared normally, but that's just space on the disk for that function, which the main kernel must be aware of, to run the jail as a process. Looks well hidden though, as nothing jail related shows up in a ps -axl process list enquiry.

Case in question here, was to run an early version of mysql server, so installed the base system (including kernel) from 11.4 into that jail via bsdinstall, as per the handbook. Since that version of mysql would not run under 14.2, it must have been running the 11.4 version kernel as installed. Only needed the base system, nothng else installed (or needed) ?. Process list, including mysql server, 6 processes in total. That's lightweight, and does exactly what was needed.

Devil always in the detail, right ?.
 
kernels provide api compatiblity down to 4.x via COMPAT_FREEBSD#N kernel options (present in generic)
so if you have the shared libs of the prev version is possible to run 11.4 binaries on 14.x
 
covacat: Thanks not something I was aware of. Could be useful in the future, but installing an older base system seemed like the best way at the time

I guess the real enquiry here is to understand the edge limits of the thick jail system, and what dependencies there are in relation to the main kernel. The handbook seems to describe that well, but not in depth.
 
well these things worked before jails too. there were/are? some ports which needed compat libs of prev version like adaptec or hp raid manager or something, maybe others
as of simulating the original env probably you have
vm > jail > chroot > LD_LIBRARY_PATH hacks on the same fs
 
Agreed, but probably before my time with FreeBSD. The main interest in jails here, is what they were designed for, to provide the most secure isolation of applications on the same platform, database, web, and other critical applications. Seems to do that very well.
Wiil stop now, as don't want to look like a troll :-).
 
You must log in or register to reply here.
Back
Top