VortexBox 5 levels behind

[toddrose]

I will not be installing VortexBox v2.5 as is. Version 2.5 is based on Fedora 25 while the current version is 30. this means all I get is a point upgrade but still unsupported OS. Fedora updates versions about every 6 months and provides updates for about 13 months after release. This means Fedora 25 lost updates in about December of 2017... that's close to two years ago so it's already unsupported. I won't be able to update any core OS vulnerabilities and there are new vulnerabilities all the time.

I MIGHT place this in a Virtual Machine running on a current OS, preferably one with Long Term Support. Ideally, I would like to have access to the SRPMS and use Centos for its LTS. With SRPMS, an automated build process could be maintained to provide updates to the VortexBox packages as Fedora advances through it iterations.

I run PLEX and use it as much more than a media server so I expect and require it to have up-to-date patches.

I appreciate the time and effort Andrew has spent and does spend on this project.

Thanks for a great music server

[dyohn]

If the platform is stable and does what we need it to do (i.e. be a music server) then what does it matter which version of Fedora underlies it as long as Andrew offers whatever it needs to run?

[chabelo]

1. Security. This should not need much motivation. Running a server 24/7 on your home internet-connected network without the latest available security patches is a very, very bad idea in the current environment. Fedora 25 contains an encyclopedia of known vulnerabilities that have long ago been patched in subsequent Fedora releases.

2. Compatibility and Extendability. Adding and updating certain packages becomes difficult or untenable when one is bound to old, unsupported platforms. Example - Dropbox stopped working about a year ago for all Fedora releases prior to 22. At any moment that could change to 28. Other packages require a more current verison of glibc (or other crucial library) than Fedora 25 offers. Plex has already been mentioned. Plex clients (e.g. IOS app, Roku app) roll constantly and often require relatively recent versions of the Plex server. If the latest Plex server decides to requires something beyond Fedora 25 you will be SOL.

IMHO the current VB platform strategy currently makes little sense. If Andrew wants slower upgrade cycles then one of the many LTS platforms make more sense. Fedora is meant to be the bleeding edge of the Red Hat family of OS's. It's not like VB takes advantage of bleeding-edge features. If it did so, it would roll with Fedora every six months.

I have gotten used to Fedora so I've taken to "rolling my own". I'm currently running (most of) the VB packages I use under Fedora 30. Those that I can't (or haven't figured out how I can) I've identified substitutes or work-arounds. It's nice to be able to run regular updates and roll with the platform and it hasn't diminished my user experience at all.

[Sully]

1. Security. This should not need much motivation. Running a server 24/7 on your home internet-connected network without the latest available security patches is a very, very bad idea in the current environment. Fedora 25 contains an encyclopedia of known vulnerabilities that have long ago been patched in subsequent Fedora releases.

2. Compatibility and Extendability. Adding and updating certain packages becomes difficult or untenable when one is bound to old, unsupported platforms. Example - Dropbox stopped working about a year ago for all Fedora releases prior to 22. At any moment that could change to 28. Other packages require a more current verison of glibc (or other crucial library) than Fedora 25 offers. Plex has already been mentioned. Plex clients (e.g. IOS app, Roku app) roll constantly and often require relatively recent versions of the Plex server. If the latest Plex server decides to requires something beyond Fedora 25 you will be SOL.

IMHO the current VB platform strategy currently makes little sense. If Andrew wants slower upgrade cycles then one of the many LTS platforms make more sense. Fedora is meant to be the bleeding edge of the Red Hat family of OS's. It's not like VB takes advantage of bleeding-edge features. If it did so, it would roll with Fedora every six months.

I have gotten used to Fedora so I've taken to "rolling my own". I'm currently running (most of) the VB packages I use under Fedora 30. Those that I can't (or haven't figured out how I can) I've identified substitutes or work-arounds. It's nice to be able to run regular updates and roll with the platform and it hasn't diminished my user experience at all.

chabelo, Did you start with the VB 2.5 image? Did you update directly to Fedora 30 or do it a level or 2 at a time?
I keep checking back to this site often, hoping to see the GA version of 2.5 released, but it seems to be stuck in beta for what, 7 months now?

Thanks
CS

[chabelo]

I start with a clean install of Fedora 30 server and add packages on top.

[Wirrunna]

Chabelo,
I am interested in how you did this and have a few questions-
1. did you use a 'minimal' install such as https://write.as/allgoodthings/minim...n-of-fedora-30
2. did you install the Vortexbox services to give you autoripping etc.
3. what packages did you install

I have made a couple of attempts to get Vortexbox to run on a nvme drive (https://www.vortexbox.org/forum/main...-2-5-on-an-nuc) and see starting from scratch as a way forward.

[chabelo]

Wirruna -

1. Did I do a minimal install of Fedora 30?

Not at all. In fact not only did I install Fedora Server, but I installed a good deal of Fedora Workstation on top of it. While I mostly run my box in a headless state I like to take advantage of certain GUI tools at times while configuring. Note – the evolution of Cockpit – the web-based Admin tool in recent versions of Fedora – is making this less and less necessary. Still it’s nice to be able to fall back on tools like Gparted, blivet-gui, Grip, and even Firefox when necessary.

2. I installed some but not all of the Vortexbox services.

Autoripping was one of the major things I did not get to work in the regular VB way. This is because I got caught in a tangle I never solved involving Perl version dependencies. I tried “perlbrew” and any other number of methods to attack it I never did solve it. However, I came close. I installed Grip which is a GUI-based program that calls CD Paranoia underneath. I used X forwarding to my laptop (running Linux, but X and X-terminal emulation are also available with packages in Mac OS and Windows). Once I fire up Grip with appropriate configuration I have autoripping proceeds more or less as it always has. There’s very little if any interaction I have to have with the GUI once the program is active. There may be a completely headless way to achieve the same but I haven’t bothered to figure it out as my collection is already ripped and I rarely rip CD’s at this point.

I have most of the basic VB menus working but again because of Cockpit and other tools I find I rarely if ever need them.

3. What packages did you install?

Lots of them. That’s a long, involved question. I built a “recipe” file as I went but it is in rough shape and not really in condition to share. I should clean it up. I used my recipe to convert other VB’s that I built and maintain for friends. There are about a half-dozen running so far and none of the other users are really aware of the difference other than the aforementioned autoripping not working as before. Most of them don’t have much ripping to do either anymore. In the rare event they do they tend to revert to ripping on their Mac’s or PC’s. I still do 100% of what little ripping I have on my quasi-VB via Grip.

Just rolled my laptop to Fedora 31 and hope to do so with my quasi-VB within the week.

[colinp]

Hi chabelo
I for one would be immensely grateful if you did get around to sharing your recipe file. I would much prefer to stick with VortexBox rather than move to something like daphile or snakeoil in order to use a 'current' version of OS. I don'y use VortexBox to rip CDs, so that wouldn't be a concern for me.

Cheers
Colin