# Continuing with 10.3 without pkg support



## jimbobmcgee (Mar 16, 2021)

*tl;dr: *Does anyone have/can anyone point me at a primer for surviving with an existing 10.3 stack until such time I can afford to upgrade?

I've been using a 10.3 install---running a mix of 10.1 and 10.3 jails---on a home server which only serves within my private LAN.  Whilst I am comfortable enough _using_ this setup, I admit my workflow for changing or maintaining it rarely extends beyond an infrequent `zfs` cloning of a template jail volume that I put together a while ago, a few edits to config files where necessary, and then a few `pkg-static install pkgname` calls within that cloned jail.

It appears pkg.freebsd.org no longer contains packages for 10.x, and so `pkg-static` cannot download meta.tgz or packagesite.tgz.

Appreciating that the _right_ answer is to reinstall/upgrade, but accepting that my budget (fiscal or temporal) doesn't immediately extend to doing so, and acknowledging that I already do not have access to security updates, can someone advise what interim steps I now need to do to extend the life of this setup, until such time that I _am_ in a position to upgrade?

I can see that old versions of FreeBSD itself are still available from ftp-archive.freebsd.org, and I doubt I am the only person still running a 10.x server privately.  

As such, could I update /etc/pkg/FreeBSD.conf to point to an archive/mirror and limp along for a bit (if so, what reputable targets can I point `url:` and `fingerprints:` at)?

Or do I shift my workflow to installation via ports?  I can see ports/tags/RELEASE_10_3_0 does still exist, although not all of my jails currently have it.  Will these still install, given an older ports tree, or will I drown in missing dependencies?  Do I need much more than `make install`?

Appreciate any guidance...

J.


----------



## ShelLuser (Mar 16, 2021)

I fail to understand the problem with upgrading. Also considering the fact that 10.x is several years old. Which is basically the only answer here: upgrade to a supported version.


----------



## Beastie7 (Mar 16, 2021)

jimbobmcgee said:


> Appreciating that the _right_ answer is to reinstall/upgrade, but accepting that my budget (fiscal or temporal) doesn't immediately extend to doing so, and acknowledging that I already do not have access to security updates, can someone advise what interim steps I now need to do to extend the life of this setup, until such time that I _am_ in a position to upgrade?



This isn't Windows. Upgrading isn't going to significantly bog down your system. In fact, FreeBSD 13 will be significantly faster than 12.2 and earlier.

Stop being lazy and take care of your system correctly.


----------



## zirias@ (Mar 16, 2021)

The only way to get up-to-date packages would be compiling from ports. But then, be aware that ports aren't checked for being able to build on EOL releases any more, so expect quite some build errors you would have to resolve yourself, if at all possible.

In a nutshell, this will probably be a lot more work (with unpredictable chances for success) than just upgrading your base system.


----------



## olli@ (Mar 16, 2021)

I have to agree with the others: Updating your system to a supported release will take _less_ time than trying to install or build stuff on your old, unsupported OS.

Note that old jails continue to run fine on newer hosts. That means you can update your host to 12.2 or 13.0, while keeping the old 10.x jails, until you get around to update the jails, too. You don’t have to update all at once if you don’t have the time.


----------



## SirDice (Mar 16, 2021)

The longer you wait to apply your upgrades the bigger the issues are going to be. If you keep up you generally only have to take small steps in order to fix any issues that may arise. Thus upgrades are relatively quick and painless. The longer you wait the bigger those steps are going to get and the more potential problems you may have to overcome, making the upgrade process tedious and frustrating.


----------



## Snurg (Mar 16, 2021)

The need to stay with an EOL FreeBSD version might become more widespread as soon as the support of GPUs before Haswell gets dropped, which apparently seems to be planned somewhere in 13.x.

I am not yet sure what to do then with my laptop which I planned to install FreeBSD.
Upgrading to a more recent, non-EOLed FreeBSD version then would no longer be an option.

Maybe the only way to keep such a system usable would be to archive the base and ports source tree before they are taken offline?
But as said, I am not sure yet at all what to do then.


----------



## zirias@ (Mar 16, 2021)

The canonical answer is: buy new hardware (or use the existing one without accelerated rendering). It's perfectly normal that support for old hardware is dropped at some point in time. Desktop-Hardware like GPUs have a LOT of volatility and shorter lifecycles. By the time support for pre-haswell MIGHT be dropped, haswell will already be 8+ years old (probably more as I would expect it to stay supported at least for the whole lifetime of 13).


----------



## olli@ (Mar 16, 2021)

Snurg said:


> The need to stay with an EOL FreeBSD version might become more widespread as soon as the support of GPUs before Haswell gets dropped, which apparently seems to be planned somewhere in 13.x.
> 
> I am not yet sure what to do then with my laptop which I planned to install FreeBSD.
> Upgrading to a more recent, non-EOLed FreeBSD version then would no longer be an option.


Please stop spreading misinformation. It is _wrong_ that pre-Haswell graphics will stop working.

Historically, the KMS drivers were included in the FreeBSD base system. These were migrated to the drm-legacy-kmod port. That port was deprecated about half a year ago, and the improved drm-kmod port should be used instead. It supports Intel GPUs at least back to Sandy Bridge (which predates Haswell and Ivy Bridge); older GPUs might be supported, too, but there may be bugs because not many developers still have such old hardware. If you have graphics hardware that is even more ancient (like ~20 years old), then you can probably use one of the xf86-video-* drivers. Note that OpenGL acceleration for old GPUs was already dropped about 8 years ago.
 


> Maybe the only way to keep such a system usable would be to archive the base and ports source tree before they are taken offline?


That would be a very bad idea.


----------



## Deleted member 30996 (Mar 16, 2021)

olli@ said:


> Please stop spreading misinformation. It is _wrong_ that pre-Haswell graphics will stop working.


I would be headed to OpenBSD and taking seven Win7 Era Thinkpads currently running FreeBSD with me if that were the case.

I always keep any machine I'm going to use online updated to the current version and vulnerabilities patched. The ones that stay offline in service never get an Ethernet cord plugged into them, can run for years and never have a problem barring Hardware snafu.

I have one running i386 FreeBSD 11.2-RELEASE-p2 now that was built in June 2018 and hasn't been online since. But there it is, alive and well with XMMS, and so it shall stay.

I have a W520 running FreeBSD 12.1-RELEASE-p3 that is next on the list to be rebuilt since it's been replaced as my .mp3 player and going back into service online.


----------



## Snurg (Mar 16, 2021)

olli@ said:


> Please stop spreading misinformation. It is _wrong_ that pre-Haswell graphics will stop working.


Thank you for the clarification.
Please understand that I am not sure how to understand/interpret what I read.
It is not at all my intention to spread misinformation.
I am trying to understand what of the -often contradictory- pieces of information is true, wrong or just obsolete/overcome by time/events.

Atm I have no way to test on actual bare metal whether it is still possible to use the xf86-video-intel driver _without_ KMS, e.g. _without_ i915kms.ko and drm-kmod.
Other people have tested that (though probably not very intensive) *and reported that this does no longer works*.

So I hope you can understand that I feel concerned and want to find out what is true, what possibilities remain to use the old but perfectly working hardware.
For my part, and probably for most other users, it _only_ matters that they can use Xorg, and _it does not at all matter_ whether it's by the traditional user mode way or via KMS.
*So I would be very glad if it can be confirmed that it is/will be still possible to use the xf86-video-something drivers without KMS.*


----------



## jimbobmcgee (Mar 16, 2021)

With all due respect, does anyone have an answer to the question that was actually _asked_?

If this were an _production_ server, that I was charged with looking after in a professional capacity, I'd be in complete agreement with your opinions, but it _isn't_, and I'm not going to spunk money up the wall on a hobbyist box in the current climate.

So the question still stands.

To reiterate, now that pkg.freebsd.org no longer contains 10.x packages, is third-party software...
1. ...still available via a third-party package archive (e.g. some reconfig of /etc/pkg/freebsd.conf)
2. ...still available via the ports tree (whereupon I have to become more acquainted with `make install`, etc)
3. ...no longer available at all, under any circumstances?


----------



## Alexander88207 (Mar 16, 2021)

If I were in your situation i would get the ports tree from the FreeBSD 10 time and compile my own ports repo with ports-mgmt/poudriere, this does not bring anything up to date but better than nothing.

FreeBSD 10.3 died at April 30, 2018 so i would take this branch https://github.com/freebsd/freebsd-ports/tree/branches/2018Q1.

_Please be aware that there may be outdated software that can have dangerous consequences._


----------



## jimbobmcgee (Mar 16, 2021)

Alexander88207 said:


> If I were in your situation i would get the ports tree from the FreeBSD 10 time and compile my own ports repo with poudriere



Thanks, Alexander -- that indeed looks like something someone might do if they had, for instance, an indecent number of 10.x systems they _had_ to keep alive; rather than an occasional need to bang editors/nano into a jail that didn't currently have it  _(inb4 "just use vi": it was just an example)_.

Now, if _someone else_ had already done this, and was making it available on the internet somewhere, for the "benefit" of mankind, that might be closer to an answer (note that I'm not asking _for_ someone to do this, just _if_ someone had done this)...


----------



## Alexander88207 (Mar 16, 2021)

jimbobmcgee said:


> Now, if _someone else_ had already done this, and was making it available on the internet somewhere, for the "benefit" of mankind, that might be closer to an answer (note that I'm not asking _for_ someone to do this, just _if_ someone had done this)...


If there is no one, i am willing to host such a repo temporary.


----------



## tingo (Mar 17, 2021)

The only way your FreeBSD 10.3 machine is going to work reliably (for some value of "reliable") is if you consider it frozen in time. How so?
- you can update the base system via source and "make world", but there will be no support (other than yourself) if something breaks. And updates to the relevant branch for 10.3 have probably stopped already.
- you can update the ports tree, but you will soon enough find out the truth in "there is only ever one ports tree" (and it is for supported branches only); things will break, probably sooner than later.

Fixes, updates and new stuff? Forget it.


----------



## mark_j (Mar 17, 2021)

jimbobmcgee said:


> With all due respect, does anyone have an answer to the question that was actually _asked_?
> 
> If this were an _production_ server, that I was charged with looking after in a professional capacity, I'd be in complete agreement with your opinions, but it _isn't_, and I'm not going to spunk money up the wall on a hobbyist box in the current climate.
> 
> ...


The simple answer is this:
You can keep your old system at 10.3 but just like keeping the OS static, you'll have to keep the packages that way. Even ports will begin to fail to compile because of system and version changes. Guaranteed.

I retired an old 5.4 system over 18 months ago. It ran fine but nothing, I repeat nothing, was changed on it for years bar a few of my own programs running on it. Certainly no ports were even attempted to be used; they long disappeared (ie, the source codes).

So either take the time to upgrade or leave the system in your time machine bubble and don't touch it.


----------



## olli@ (Mar 17, 2021)

jimbobmcgee said:


> With all due respect, does anyone have an answer to the question that was actually _asked_?


With all due respect, _several_ people have responded to the actual question.


> To reiterate, now that pkg.freebsd.org no longer contains 10.x packages, is third-party software...
> 1. ...still available via a third-party package archive (e.g. some reconfig of /etc/pkg/freebsd.conf)


*No.* It would be a waste of resources to build packages for a release that is unsupported.


> 2. ...still available via the ports tree (whereupon I have to become more acquainted with `make install`, etc)


*No.* The current ports tree does not support releases that are unsupported. There is a switch to override the check, but 10.x is so old that the ports infrastructure won’t work anymore. You could try to work around that (which probably would take more time than updating the machine to a supported release), but even then, many ports won’t build because they require patches for your old system that don’t exist.
 
Of course you could keep the old ports tree as of 10.x, or check out the last ports tree from the repository that supports your FreeBSD version. But then you can only build _old_ versions of the ports, of course, many of which have bugs and known security issues (e.g. the old OpenSSL in 10.x has holes that are actively exploited!). Additionally, many ports won’t build because the distfiles are not available anymore.


> 3. ...no longer available at all, under any circumstances?


See above.
 
I have one request: If you still decide that you do not want to update your machine whatsoever, then _*please*_ do yourself and everyone else a favor – take the machine offline and do not connect it to the internet anymore. Given the age of the OS and software, it is likely that it will have unwanted “visitors” sooner or later, and start spreading spam, be used as a jump host by evil guys to cover their tracks, things like that. It is even possible that the police will turn up on your doorstep one day, because your machine is used as an intermediate hop for illegal activities. This is not far-fetched, I know someone who got into trouble exactly because of that.


----------



## jimbobmcgee (Mar 17, 2021)

(skip rant)



olli@ said:


> With all due respect, _several_ people have responded to the actual question.



Several people have responded to the _post_, not the _question_.   For a moment, let's just assess the responses...

#2. "I fail to understand the problem..."  -- good for you, but doesn't help me.
#3. "Stop being lazy..."  -- thanks for the ad hominem.
#4. "The only way to get up-to-date packages would be compiling from ports" -- the first real address to the question -- thanks Zirias, I'm sorry I missed this in my first read through.
#5. "Have to agree with the others" -- still doesn't get me anywhere
#5a. "Note that old jails continue to run fine on newer hosts" -- that's useful to know -- thanks for this, too (I imagine that there is at least going to be _some_ limitation to this, though, but that is a separate issue for later examination)
#6. "The longer you wait to apply your upgrades the bigger the issues are going to be." -- the first acknowledgement that, _actually_, it might not be as straightforward as everyone else is making out; presents useful advice for _later_, but not for _now_.
#7. Someone who may have a legitimate reason not to just blindly fire off the update command; bit of a hijack, but possibly relevant, so OK.
#8. A response specifically to #7, ultimately boiling down to "Just buy more stuff"
#9. Another response to #7 -- already tangental -- and certainly not an answer to #1
#9a. "That would be a very bad idea." -- vague warning is vague, some detail might be useful
#10. I _think_ this is a reply to #6; it doesn't seem wholly relevant to #1, though, but maybe I've missed a nuance
#11. Closure of #7, tail between legs.  Bet that person's glad they joined in, now, eh...?
#12. _...in which one fleetingly attempts to get back to the point..._
#13. Thanks for this possible workaround, although it may be chicken-and-egg, in that I first have to have _upgraded_ before I can _pkg install poudriere_.  Still again, a possible point of interest for future endeavours.
#14. ..._acknowledgement of #13..._
#15. A very kind offer, for which I am grateful, but I don't wish to burden someone solely on my behalf.  
#16. Useful, caveats understood and accepted -- thanks
#17. Again, useful -- thanks

In the first 10 replies, only one addresses my question directly (I missed it first time round, I'm sorry).  Some useful replies _after_ I asked everyone to stay on topic.

I'm glad all the people who are just telling me to upgrade are so absolutely confident in the upgrade process, and haven't ever been bitten by any issue during their lifetime.  I _haven't_ had that same experience. There's a myriad of things I need to check and be comfortable with in myself, before I pull the trigger on such a potentially-destructive process.

I want to draw a line under the above -- it isn't intended as an attack on anyone, and I am genuinely appreciative of the free time and wisdom people have put in to contribute to this conversation.



To address the remainder of your response (#18):



> It would be a waste of resources to build packages for a release that is unsupported.



I agree that there is no need to continually build the packages, but it _might not_ be a waste to keep a static copy of the _last _build after support has ended.  I don't necessarily sign up to the whole "storage is cheap" notion, but there is _some _argument for keeping these around.  It seems somewhat cynical (at least to me) to allow people to continue downloading older versions of the base ISO, if you are going to render it useless by deleting all the software that worked on it.

That's a matter of philosophy, though, and I'm not trying to change the world here.



> The current ports tree does not support releases that are unsupported



That's interesting to know but, again, we are not necessarily talking about the _current_ ports tree. If I haven't run `freebsd-update` for a while, then the likelihood of my having run `portsnap` is surely very low.



> Of course you could keep the old ports tree as of 10.x, or check out the last ports tree from the repository that supports your FreeBSD version.



_That _is what I am interested in exploring. As an _interim _measure. Until I am comfortable that I have all my ducks in a row, and am ready to update. 

My takeaway from the thread so far is that, _if _my last `portsnap` was the same time as my last `freebsd-update`, and _if_ the resources referenced by the various makefiles in those ports are still available, then `make install` _is_ still viable in the short-term.



> But then you can only build _old_ versions of the ports



I'm not sure how many different ways I need to explain that I understand that these will be old versions, and that old versions are very probably insecure.  I thought that my acknowledging that I wouldn't have the latest security updates back in in post #1 was enough, but everyone seems to have missed that.



> If you still decide that you do not want to update your machine whatsoever, then _*please*_ do yourself and everyone else a favor – take the machine offline and do not connect it to the internet anymore



Again, a private server on a private LAN, providing a backup fileshare for my main computers, and a couple of jails for things I once found interesting.  Not serving anyone else, not used day-to-day, etc.  With all the Win2003/2008 servers still around in the world---and us barely being able to buy a toaster that doesn't have a wi-fi client, these days---this box is the least of my concerns.

I do think that you are possibly putting too much stock in the term "supported", though.  I ultimately acknowledged that I wasn't _supported_ when I chose to install a free operating system, on some commodity hardware, in the corner of my living room, in my free time.  I haven't paid for a maintenance contract, so I have no illusion of _support_.  This thread was really intended to be a _discussion_ within a community of people with some subject-matter knowledge that exceeded my own, and not some expectation of _support_.


To think, this whole thing started because I wanted to quickly look inside a file without dragging it down to my main, and I couldn't get `pkg-static` to install archivers/unrar, because the regular mirrors don't have FreeBSD:10:amd64 any more.  

I'm OK with that---stuff moves on---but the answer to that very basic initial requirement surely isn't _burn down everything you have and rebuild it_. I can't believe that the FreeBSD team would engineer something that injects such a large dependency on _themselves_ to keep every user's server afloat.

So I wondered if there was an existing mirror that may have kept 10.x packages around, that I could somehow switch `pkg` to using, to meet that short-term need.

For what it is worth, I _did_ find a host still serving the FreeBSD:10:i386 and FreeBSD:10:amd64 directories alongside the current 11.x, 12.x, 13.x and 14.x ABIs, so I assume the providers of _that _have experienced similar issues. I won't link it here, but it's easy enough to find, and purports to be in the the Netherlands.

I acknowledge that, if I use that third-party mirror, I do so at my own risk, and that they may not choose to keep it around forever.

But, given the very limited use-case I've described (i.e. banging a quick utility app into an existing jail for a quick one-off use), is my simplest option to add a new /usr/local/etc/pkg/repos/FreeBSD.conf, with the below in it...


```
FreeBSD: {
  url: "pkg+hxxp://themirror.example.com/path-to/freebsd-pkg/${ABI}/latest"
}
```

...or is there more to it?

Thanks.


----------



## mark_j (Mar 17, 2021)

jimbobmcgee said:


> I'm glad all the people who are just telling me to upgrade are so absolutely confident in the upgrade process, and haven't ever been bitten by any issue during their lifetime.  I _haven't_ had that same experience. There's a myriad of things I need to check and be comfortable with in myself, before I pull the trigger on such a potentially-destructive process.



Upgrading is not easy, sometimes, but as your version slips back one revision every two years, the chances of a successful/smooth running upgrade also go backwards.





jimbobmcgee said:


> To address the remainder of your response (#18):
> 
> 
> 
> I agree that there is no need to continually build the packages, but it _might not_ be a waste to keep a static copy of the _last _build after support has ended.  I don't necessarily sign up to the whole "storage is cheap" notion, but there is _some _argument for keeping these around.  It seems somewhat cynical (at least to me) to allow people to continue downloading older versions of the base ISO, if you are going to render it useless by deleting all the software that worked on it.



They're there for posterity, not support. You need to understand that packages and/or ports are NOT part of the OS, they're an add-on. The FreeBSD OS is contained in the ISOs you mention. That is all FreeBSD core supports, not ports or packages.

And I take umbrage with it being "useless". Again, packages and ports are NOT part of the OS.
[On the weekend I installed 4.3 in a VM (because I wanted that specific compiler version to check something).]




jimbobmcgee said:


> I'm not sure how many different ways I need to explain that I understand that these will be old versions, and that old versions are very probably insecure.  I thought that my acknowledging that I wouldn't have the latest security updates back in in post #1 was enough, but everyone seems to have missed that.



But you also seem to have missed what others (and I) have said. To quote olli@ ". Additionally, many ports won’t build because the distfiles are not available anymore."

In short time, if not now, distfiles for ports will just disappear. Why? Well a lot of them are not stored by FreeBSD but pulled in from other sites. If those sites determine they don't want those versions and delete them, then bingo, that port for that version is dead.
Of course you could pull in a later version and possibly compile, applying patches to it and doing all the things a porter does, but that requires a significant level of knowledge of the system, compiling and the language(s) being used. The port might be written in C but use python, perl and meson to build aspects of it. 

This is how porters simplify yours (and mine) work.



jimbobmcgee said:


> I do think that you are possibly putting too much stock in the term "supported", though.  I ultimately acknowledged that I wasn't _supported_ when I chose to install a free operating system, on some commodity hardware, in the corner of my living room, in my free time.  I haven't paid for a maintenance contract, so I have no illusion of _support_.  This thread was really intended to be a _discussion_ within a community of people with some subject-matter knowledge that exceeded my own, and not some expectation of _support_.


But the forum policies specify your system version is not supported and the official line is: UPGRADE. So I guess you're lucky you've been able to discuss this in this level of detail without SirDice saying "move along, nothing to see here!" ? 



jimbobmcgee said:


> To think, this whole thing started because I wanted to quickly look inside a file without dragging it down to my main, and I couldn't get `pkg-static` to install archivers/unrar, because the regular mirrors don't have FreeBSD:10:amd64 any more.
> 
> I'm OK with that---stuff moves on---but the answer to that very basic initial requirement surely isn't _burn down everything you have and rebuild it_. I can't believe that the FreeBSD team would engineer something that injects such a large dependency on _themselves_ to keep every user's server afloat.


They don't. This is what you're missing. Ports and packages are not part of FreeBSD. FreeBSD, the OS, can exist perfectly without ports or packages. Now, granted, the impending demise of sendmail, for example, renders this situation moot and lends credence to your argument (in the future), but, essentially, the OS is the OS is the OS.

Now, sure, adding ports and packages is nice, but in the 'old days' [tm], we had to bring in software, compile it, fix it, patch it and install it all by ourselves. Yes, there were some ports but basically it was do-it-yourself. Porters made this job easier, but if all the porters disappeared tomorrow the OS would still run.

I'm trying to illustrate that ports and packages are not integral to the OS.



jimbobmcgee said:


> So I wondered if there was an existing mirror that may have kept 10.x packages around, that I could somehow switch `pkg` to using, to meet that short-term need.


You were told there is none, officially.

We have 2 old 10.x machines still awaiting upgrade (hopefully this month) but we maintain our own package repository. Perhaps you should consider this?



jimbobmcgee said:


> For what it is worth, I _did_ find a host still serving the FreeBSD:10:i386 and FreeBSD:10:amd64 directories alongside the current 11.x, 12.x, 13.x and 14.x ABIs, so I assume the providers of _that _have experienced similar issues. I won't link it here, but it's easy enough to find, and purports to be in the the Netherlands.



Ok, so you found one. So use them.

It would be nice to have all the packages for all the versions of the OS stored somewhere, but I believe the storage costs would be significant with very little return given the official line is, 2 old versions back is not supported.


----------



## Alexander88207 (Mar 17, 2021)

jimbobmcgee said:


> #15. A very kind offer, for which I am grateful, but I don't wish to burden someone solely on my behalf.


It is not a burden at all for me, because I have 2 servers that are just running currently empty anyway.


----------



## jimbobmcgee (Mar 18, 2021)

This is getting dangerously close to argumentative, and I didn't come here to argue.  I am firmly encouraged to upgrade, and will be upgrading, just not _quite _yet.

But some minor nitpicks, (with tongue firmly in cheek)...



> But you also seem to have missed what others (and I) have said. To quote olli@ ". Additionally, many ports won’t build because the distfiles are not available anymore."





> ...and _if_ the resources referenced by the various makefiles in those ports are still available...


I haven't missed this -- I just didn't use the word _distfiles_.



> You were told there is none, officially.


No, I _inferred _there was not one officially, by the fact that it is no longer available at pkg.freebsd.org. I'm not disputing this, nor complaining about it, nor asking for special favours in bringing about its return.



> Ports and packages are not part of FreeBSD. FreeBSD, the OS, can exist perfectly without ports or packages.


Fair enough, but you and I have different ideas of "useless".  If one of the principal means of getting software into that OS is dropped out from under you, you're not going to get a whole lot of use out of it.  [TORTURED-METAPHOR]_A canoe can exist without oars, but it isn't going very far up that creek_[/TORTURED-METAPHOR], after all.



> Now, granted, the impending demise of sendmail, for example, renders this situation moot and lends credence to your argument (in the future)


That sounds like a possible reason that someone might -- you know -- _not_ upgrade.  All that investment in sendmail just...lost...to time...like tears...in rain...



> On the weekend I installed 4.3 in a VM (because I wanted that specific compiler version to check something)


What could you possibly need to check something for?  No-one should be running 4.3, or anything compiled in it.  It's more than two versions out of date, and certainly isn't _supported_. 



> We have 2 old 10.x machines still awaiting upgrade (hopefully this month)...


...but...but...it's over two years old!!  I do hope you self-flagellate, daily, in penance.



> ...but we maintain our own package repository.  Perhaps you should consider this?


Yup, I'll just throw together a utility box, to support my hobby box.  Hang on, I've run out of plug sockets.  And boxes.  And it's warmer in my house, now.  And I can't hear the telly any more.  Now I've been relegated to the shed.


In all seriousness, though,...



> Ok, so you found one. So use them.



I'm certainly willing to _try_.  Is my approach correct (for the loose definition of _correct_), i.e....



> ...add a new /usr/local/etc/pkg/repos/FreeBSD.conf, with the below in it...
> 
> FreeBSD: {
> url: "pkg+hxxp://themirror.example.com/path-to/freebsd-pkg/${ABI}/latest"
> ...



For instance, do I have to consider _fingerprints_ (or some other verificiation signature), here?  Is there a canonical source of those, or does one have to trust the digests.tgz (?) from the mirror host?  _(Take "10.3" out of the equation here, if it is getting in the way of the answer.)_


----------



## mark_j (Mar 18, 2021)

jimbobmcgee said:


> No, I _inferred _there was not one officially, by the fact that it is no longer available at pkg.freebsd.org. I'm not disputing this, nor complaining about it, nor asking for special favours in bringing about its return.


I never said any of this so I am not sure why this is your reply. Anyway...



jimbobmcgee said:


> Fair enough, but you and I have different ideas of "useless".  If one of the principal means of getting software into that OS is dropped out from under you, you're not going to get a whole lot of use out of it.  [TORTURED-METAPHOR]_A canoe can exist without oars, but it isn't going very far up that creek_[/TORTURED-METAPHOR], after all.



You are free to do what I stated earlier, *install the source code and build it yourself*. _Nothing stops you from doing this now_. You can do this with 10.x FreeBSD until you die, it will still run and be productive. 

Ports and packages are a courtesy to help you (and I). Are they important to the adoption of FreeBSD? Yes, but there is an expectation you upgrade and with it, ports and packages are maintained to the standards applied by FreeBSD.

But back to your gripe: The cost of storage and network bandwidth storing ALL packages for ALL versions would be astonishing. I believe you do not understand the size of it. If you had to do this for the distfiles, that adds even more size. 
(However, I'm sure if you front up with the annual dollars for this and mirrors, the FreeBSD foundation could fund it... )




jimbobmcgee said:


> That sounds like a possible reason that someone might -- you know -- _not_ upgrade.  All that investment in sendmail just...lost...to time...like tears...in rain...
> 
> 
> What could you possibly need to check something for?  No-one should be running 4.3, or anything compiled in it.  It's more than two versions out of date, and certainly isn't _supported_.


But I did want to check the operation of the compiler (gcc) when optimising because I see an issue and we support all versions of this compiler back to that era. However, this is not the point. My point was that it can be installed on its own and it is a functioning OS. Ok, it doesn't have a database or a web site but who wants them in base?

You are free to take offense or deem this argumentative, even though I consider it neither of these. I've attempted to clarify what the OS is and that your expectations do not meet those of the FreeBSD org. That's why there's no packages for old systems FreeBSD officially no longer supports. 
They have to draw the line somewhere.

If I were in a business that was relying on a certain obsolete version of FreeBSD, I would have taken measures to make a copy of the entire package site or at the very least all the packages that I run on these systems. Unfortunately, for you, you've missed that boat.



jimbobmcgee said:


> For instance, do I have to consider _fingerprints_ (or some other verificiation signature), here?  Is there a canonical source of those, or does one have to trust the digests.tgz (?) from the mirror host?  _(Take "10.3" out of the equation here, if it is getting in the way of the answer.)_


I don't know about the source site so what verification are you talking about? The signature match in the packages should not change to that of the repository you're pointing to and the individual packages. If it does then nothing will built or be installed. You would also have to avoid updating pkg because it could break in future.
The canonical source WAS FreeBSD.

But, enough talking, just point the conf file to your new location and try it. It's after all, your only option. Just make a copy of your old one (for what it's worth and it's not much), just in case.

You have nothing to lose, it seems.


----------



## jimbobmcgee (Mar 18, 2021)

> This is getting dangerously close to argumentative, and I didn't come here to argue





> You are free to take offense or deem this argumentative...


No offense taken at all.  My statement regarding argument was due to my concern that I might be appearing to argue for the sake of argument itself, and to reassure that it wasn't my intent -- it was poorly-worded though.



> If I were in a business that was relying on a certain obsolete version of FreeBSD, I would have taken measures to make a copy of the entire package site or at the very least all the packages that I run on these systems.


That is, indeed, good advice (echoed elsewhere in the thread).  I'm not in a business supporting any version of FreeBSD (although I once seriously considered it).   It was not abundantly obvious to me when starting out that "not supported" meant the ecosystem (_specific to me_) was going to disappear out from under me. Hindsight is a wonderful thing.

For what it is worth, I don't expect anyone to maintain all the versions of all the packages, although I _did_ express an opinion that doing so might be useful (in a perfect world).



> what verification are you talking about?


My question regarding signatures was a follow-up, aimed at understanding if I had to do anything else besides set the URL, to verify that packages downloaded from a third-party mirror site of unknown origin, were indeed "genuine" packages.

In other words, if I point `pkg` at my chosen third-party and it downloads a package, are there mechanisms in place to confirm that the package is genuine?  I can see the mirror provides a digests.txz file but a misbehaving mirror could potentially serve a bad package and a deliberately-crafted digests.txz, and I would be none the wiser.

However, on reflection, I presume this is handled for me by `pkg` -- if the packages came from a true mirror of pkg.freebsd.org, `pkg` is going to install these without issue; and if they were built by an independent ports-mgmt/poudriere, I would have to explicitly configure trusting a different key.


----------



## ondra_knezour (Mar 18, 2021)

jimbobmcgee said:


> In other words, if I point `pkg` at my chosen third-party and it downloads a package, are there mechanisms in place to confirm that the package is genuine? I can see the mirror provides a digests.txz file but a misbehaving mirror could potentially serve a bad package and a deliberately-crafted digests.txz, and I would be none the wiser.


The digests.txz file may contain hashes signed by any key, which public part is also included in the file. See pkg-repo(8) man page for the 10.0-RELEASE. You may also look for more recent versions of this man page, which contains little more information which may or may not be valid for your version. Also here you may find some useful info about manual verification.

My theory is, that old mirror should contains digests signed by the FreeBSD key valid in given time (at least I don't see any reason why each/any mirror would like to rehash/resign all packages), so if you find corresponding public part (which is included in digests.txz, but you may want to verify it independently from another source), you should be able to verify that given packages was really built on the FreeBSD infrastructure.


----------



## mark_j (Mar 18, 2021)

jimbobmcgee said:


> In other words, if I point `pkg` at my chosen third-party and it downloads a package, are there mechanisms in place to confirm that the package is genuine?  I can see the mirror provides a digests.txz file but a misbehaving mirror could potentially serve a bad package and a deliberately-crafted digests.txz, and I would be none the wiser.
> 
> However, on reflection, I presume this is handled for me by `pkg` -- if the packages came from a true mirror of pkg.freebsd.org, `pkg` is going to install these without issue; and if they were built by an independent ports-mgmt/poudriere, I would have to explicitly configure trusting a different key.



Are these package repositories using signing? Do they provide the public key to the packages? It's not mandatory. We have public repositories of packages with no key signing , ie 'signature-type: none' and private server repository that's signed, ie 'signature-type: pubkey'.

There's also checksums on packages to help verify authenticity and integrity.

Nothing's guarantee, though.


----------



## Deleted member 30996 (Mar 18, 2021)

jimbobmcgee said:


> In the first 10 replies, only one addresses my question directly (I missed it first time round, I'm sorry).  Some useful replies _after_ I asked everyone to stay on topic.
> 
> I'm glad all the people who are just telling me to upgrade are so absolutely confident in the upgrade process, and haven't ever been bitten by any issue during their lifetime. * I haven't had that same experience. There's a myriad of things I need to check and be comfortable with in myself, before I pull the trigger on such a potentially-destructive process.*



Now that you've cut through what you considered to be all the answers that didn't address your issue, please allow me to do the same and address the real issue in your own words.

It wasn't till four days ago that I used pkg for the first time to build a desktop from scratch.

That was my experience and there's no reason it can't be just as easy for you. You've already stated it's not a Production server and that you're a "hobbyist". I'm a 10th Grade High School Dropout but I don't have a hobby. I have FreeBSD desktops.

You mentioned a fiscal and temporal budget. Maybe time is money for you because that's all it will cost.

It took me about 2 hours on that T43. Most of that time was used compiling the one port I had to fix. If you're running a server on a LAN you don't have to install all the programs I did or do the work setting up a desktop.


So what it boils down to, it would take you 2 hours at the most to build FreeBSD 12.2-RELEASE-p4 and be completely up to date but you haven't got the confidence in yourself to do it.

I'm here to help.

Just sustitute pkg for ports, like I basically outlined how to do in my previously linked post, take what you can use and leave the rest.









						Beginners Guide - How To Set Up A FreeBSD Desktop From Scratch
					

I'm going to guide you though the process of getting a fully functional FreeBSD 13.0-RELEASE desktop up and running, complete with system files and security settings, step-by-step as if you've never used UNIX or the command line. Now let's get started:  Insert your boot media and at the Welcome...




					forums.freebsd.org


----------

