Moving beyond four linux versions: Could use some help

1

Background:
I am a senior computer technologist with over 40 years in the business and, among many other things, Linux admin since Red Hat 1.1. And, I was asked by a popular radio show host, a friend, if I could help them get back to broadcasting after they got booted from the air for being not politically correct. SURE! I wanted to do this kind of thing anyway, mostly to broadcast for myself!

I looked at, and tried, a number of FOSS systems before coming to LibreTime and decided I like the basics. IF I can get it to work, I’ll contribute back where I can.

The Issue:
When I ran the setup and it kept giving me only a banner and then “error:” in red - with NOTHING MORE, I of course (being competent with bash) dove right in to see WTF.

I was SHOCKED to see that the current “package” only accepts FOUR linux distributions?! RATHER two versions of each of two linux distributions! WOW!

I run one of those distributions somewhere and know that if this can work on Debian, it can work on Fedora Server - I know FAR more about Fedora than Debian but I’ve never failed at getting software to work on both. And, as I intend to run this in production, there’s no chance I’m changing my server to a different distro - not at this point! I mean, nobody’s paying me for this!

So, rather than complain, I’d like to figure this out and HELP. I mean, if you want this software to get legs, it has to work on more than two versions of two distributions!

If the community can please help me get it working in short order, I am ready and willing to feed what I’ve done back into the extant code, etc. And, I’ll start here and now!

First of all, the function check_distribution() has to be changed. The way it is now, is, well… Nevermind. BETTER to say to folks: “This distribution is unsupported but maybe it can work out. and if you get it working on your distribution, please tell us how you did it.” And then back that up with a section in THIS forum - I mean discourse - just for people to talk about that until it can at some point become a supported platform!

Honestly, what worked for me to even BEGIN the installation was to add:

fedora-35) is_ubuntu=false && distro="UnNamed" ;;

to the case statement in that function. From there, I can see what’s not working and work on fixing them!

Ok, I hope that’s a good introduction to this. Anyone?

(I will reply to myself as necessary to share the issues, but I’m trying to work through them myself first!)

2

Sounds good. I don’t think anyone has worked on getting it to work with Fedora because there is a lot of dependency on apt in terms of the bash install script but I don’t see why you couldn’t get it to work with fedora with enough work. Feel free to document the process and we can possibly accept pull requests to add it, although I’m not that involved in the project coding at this point and I’m not sure what others opinion would be.

3

Thanks, robbt. A positive response is encouraging.

My weak point at this is going to be taking the time to learn how to patch this code and things like that. And besides, I don’t think there’ll be any real coding issues, just dealing with system organizational differences, which are mostly just scripts.

I’d rather just post what I’ve done and let the project’s commiter’s run diffs and such. Fair? … I just don’t have the time for all the rest.

Heck, I can well imagine this adaptation to Fedora might just be a matter of whole new files that can be chosen when the version is Fedora… THAT would be easy! However, the install script is definitely in need of “serious work,” though I’ll say I use EXACTLY the same type of structure in my own bash scripts (with a few notable differences) and this was perhaps the key reason I decided to dive in. … That, plus I have other Libre software on my systems and DO presume they’re “related!”

4

I realized early on that I COULD just read the install script and do what’s needed on my own box(es) but I decided that was lame because I know how to do more. So, I figured I’d just hack the install script so I can provide it back to the community. … After all, I have been hacking since the fall of 1977 and with sh / bash starting in the late '80s or early '90s.

I’m, a good programmer but I don’t claim to be any genius at BASH and I’ll confess, for example, I wasted far too much time trying to figure out why my calls to the Red Hat Package Manager (“rpm”) worked only when the package was already installed?! The cause? a set -e command right at the top of the script! DOAH! (It’s still there, I just reset it for Fedora since using rpm, yum and other packages with that “bad behavior” is required.)

Maybe not a genius at BASH but I’ve been in this industry long enough to know what system managers can and are willing to deal with happily and what makes them upset. I also know about deploying systems…

Therefore, I have begun the path to LibreTime moving to having more versions with a supportable installation script that provides support in the script for easy adaptation to more versions. And, it wasn’t all that hard to get LibreTime installed on Fedora. Now, it bifurcates based on distribution type first and then version, and package maintainers can easily tweak these for their distribution’s new versions as time moves on.

For Fedora MOST of the package names and such are just fine, but on Fedora, both Postgres package names were wrong, so, I fixed it; the non Fedora systems see no change but on Fedora, it converts the two names into the correct ones and installs them.

One issue, though, is that on Fedora, it’s critical that this script is run as root (su is fine, of course) but, of course pip throws a fit. And, I have ZERO idea just how seriously those warnings (that come across as threats) need to be taken when you DO install as root.

So, I added a redefinition of the PIP variable for the Fedora distribution, and the script is NOW supporting of at least THREE distributions AND is more tolerant of versioning! The new PIP definition goes to a function and from there it calls su -c. Problem solved.

Further, warnings are given for others if their distribution is unsupported but it LETS THE SCRIPT CONTINUE as it really can’t go too far wrong, and seeing the errors helps people decide if they want to contribute their time to tell us what’s needed.

Further, I removed the limits on versions - it now has a default so if the system’s version is not recognized, it’ll attempt to continue as the youngest version known to the script.

Anyway, it’s a start. … How do I join the community to contribute this and other changes? I want to talk with whoever is otherwise responsible for the install script so we can work together! I note that my web browser already encourages me to edit some of the documentation! … Email lists for developers, etc? …I’d rather devote what precious time I have for this go to coding and not reading up too much - I don’t plan on doing anything INSIDE the “engine” of LibreTime! So, a pointer or three would be nice!

Oh, without another way to share this back, I’ve put the new script, incomplete as it is, here. NOTE that I AM still editing it and will replace that one whenever I think of it. …It can use some testing from NON-Fedora installs!

5
6

The biggest hurdle to supporting additional distributions is time - LibreTime requires a host of system packages and some of those dependencies are very version specific (for example the major version of Liquidsoap). For every release, each supported distro needs testing. There are 2 people working on LibreTime at the moment. We welcome additional developers and if you wish to contribute, you are welcome. However, posting full, modified install scripts to your website is not a useful contribution to the development process. I’m sure it is helpful for other people trying to install LibreTime on Fedora 34, but it doesn’t work as a patch (See 2.4.8 of the C4). A pull request is a much better form of modification that we can work with.

Fixing distro-specific issues also requires knowledge and experience with that particular distro. A bug on Fedora is not necessarily the same as a bug on Ubuntu. @joola and myself understand and are experienced with Debian and Ubuntu-based systems, so we are comfortable maintaining support for those platforms. Additional platforms (e.g. Fedora) are welcome, but they need to be backed by someone who is willing to put in the work to help maintain them long-term. A drive-by contribution of a distribution is not going to work because we lack the workforce or experience to maintain other distros.

The current way distros are supported is deliberately built so that it can be extended - adding an additional distro requires some updates to the install script and the mapping of package name to distro release for each component of the LibreTime system.

If you would like to see Fedora 34 support, that is great! I look forward to engaging with a pull request. I am also happy to help chime in on any guidance you may need in Expanding LibreTime: Need help with packages.py - #3 by rtroy

3 Likes
7

Thanks much, paddatrapper.

Your post explains much, and is just the sort of straight-talk I was hoping for. It’s straight forward, and direct. Thanks for that.

My proposal at this point is: I just managed to get this bit of joy:

systemctl status libretime.target

â—Ź libretime.target - LibreTime Services
Loaded: loaded (/usr/lib/systemd/system/libretime.target; enabled; vendor >
Active: active since Sun 2022-10-23 15:30:06 PDT; 6s ago

Oct 23 15:30:06 server2 systemd[1]: Reached target LibreTime Services.
lines 1-5/5 (END)

(The leading line wasn’t bolded of course.)

I know Fedora pretty well, having first gotten into it with Red Hat v 1.1, WAY back in, oh, 1997? And I’ve mostly suck with it for systems I manage and develop on because of the need to know the platform pretty well.

What I don’t know that well that gives me pause is Python. And don’t have time to learn to full competency at this time. I also don’t know what all the other significant dependencies may be in stuff that’s not otherwise pedestrian. Different version of OpenSSL? No big deal. What ARE the big deals?

Note that for the most part Debian (can’t speak to Ubuntu) is extremely compatible with Fedora, it’s just got stuff in different places - that’s what “ln -s” is for!

If I had a private forum - like just plain email - to chat with, I’d be very pointed on my concerns about Python on-going, but I seem to have tamed the beast in this instance. … I invite you to contact me directly - you have my contact data. You can check me out in other forums if you want, such as Stack Exchange where I’m know as Richard T, or github, presuming I do a pull request…

As a very long-time programmer, system administrator, senior consultant to major businesses, my overall advice to folks is to find a working combination of versions and change them cautiously; this doesn’t mean you don’t innovate or keep up with the times, it’s about the dependencies. That’s why Centos, for example, has a slower pace of system upgrades.

So far as I’ve seen of Python so far, it’s a disaster for system managers - and therefore “porting” to other platforms - because there’s a false perception that there’s no need to worry about what packages someone installs. … I could cite a few times where I didn’t even know I was dependent upon Python packages and someone independently, unknowable to the system administrator, added or changed versions and the whole system had to be rebuilt because it screwed with other aspects of the system. “Disaster” is a mild word here. … For those who can dedicate a system to just one task, maybe that’s not a big deal…

Beyond Python, I expect I’m ignorant about some other aspects of LibreTime, but insofar as Python (and any other key dependencies) permits keeping to very specific versions of dependent packages, and so long as LibreTime is willing to make changes slowly and cautiously on those dependencies, this can really work, at least for Fedora. And that would really encourage me to do more.

What I’ve got now is a not polished install script that I intend to do some clean up on before “letting it out in the wild,” as I had to add some stuff to just figure out what was going on and it doesn’t really belong.

I strongly suggest that just whacking an existing installation of nginx is -ahem- unfriendly. But it appears that’s only a claim from the installation script as my original nginx installation appears to be running happily - good thing this is a backup system, though!

Since I just got it installed for the first time, I’ll be checking LibreTime out. And in the mean time if you’d get back to me about my comments, that would be good, thanks.

8

What I don’t know that well that gives me pause is Python. And don’t have time to learn to full competency at this time. I also don’t know what all the other significant dependencies may be in stuff that’s not otherwise pedestrian. Different version of OpenSSL? No big deal. What ARE the big deals?

The big ones are:

  • Python (>= 3.8)
  • PHP (==7.4, v8 is not supported because some of our dependencies are no longer supported and so we are stuck until we can drop them)
  • Liquidsoap (==1.4)

The Python dependencies are downloaded from pip precisely because the version skew across the various supported distros is unmaintainable. The supported version ranges are listed in each setup.py or requirements.txt file (they are kept in sync).

If I had a private forum - like just plain email - to chat with, I’d be very pointed on my concerns about Python on-going, but I seem to have tamed the beast in this instance. … I invite you to contact me directly - you have my contact data. You can check me out in other forums if you want, such as Stack Exchange where I’m know as Richard T, or github, presuming I do a pull request…

We are active here, on GitHub and https://chat.libretime.org, though we are not likely to move away from Python any time soon - in fact we are replacing the PHP parts with a reactive front-end and Python API.

As a very long-time programmer, system administrator, senior consultant to major businesses, my overall advice to folks is to find a working combination of versions and change them cautiously; this doesn’t mean you don’t innovate or keep up with the times, it’s about the dependencies. That’s why Centos, for example, has a slower pace of system upgrades.

I agree, which is why we maintain and test a very specific set of versions of dependencies. We try to maintain at least the versions required for the distros we support plus the newest version we can so that we are ready for newer distro releases.

So far as I’ve seen of Python so far, it’s a disaster for system managers - and therefore “porting” to other platforms - because there’s a false perception that there’s no need to worry about what packages someone installs. … I could cite a few times where I didn’t even know I was dependent upon Python packages and someone independently, unknowable to the system administrator, added or changed versions and the whole system had to be rebuilt because it screwed with other aspects of the system. “Disaster” is a mild word here. … For those who can dedicate a system to just one task, maybe that’s not a big deal…

LibreTime is designed to operate on a dedicated system, either bare-metal/VM or Docker. It will trample over dependencies and install things that it requires. There are a lot of dependencies and version requirements that don’t necessarily play well with other services on the system. If a sysadmin wants to install it on a running system, they should definitely not use the install script and should rather install things manually, understanding what each step involves. I seem to recall having something to this effect in the install docs, but can’t find it now. It probably needs to be made clearer.

1 Like
9

Thanks, paddatrapper.

I think that’s a fantastic reply. I didn’t reply right away because I felt I needed to bone up on Python and packaging issues, and, indeed, I’ve learned a lot in the interim. Unfortunately, I’ve been delayed in reply more significantly because of a collection of factors well outside my control, none of which have ever been an issue before. … Life throws us a curve-ball once in a while. And these issues are not yet resolved. But I’m trying to carve out time for things, like LibreTime.

That said, for about the same three-ish weeks it’s been since I posted last, I’ve got an installation that’s all “native” to Fedora and SEEMS to work but isn’t yet configured to my needs / environment. I have great optimism it’ll work just fine as all signs point that way.

Next week is Thanks Giving Week here and I expect I’ll be able to carve out some time to move things along and provide a competent reply to your erudite posting. And I really do regret the delay… Thanks again for commenting in this thread!

2 Likes