ALERT Buh-bye CentOS.

[wardmundy]

@Eliad: diff file1 file2

 

[progs_00]

I looked at both Debian logs, the successful and the failed one, I cant figure out the error except on the failed one, userman module is reported as failed toward very end of the log.
Now, next step is to look at the difference between Debian older install script (early Jan 2021) versus the most current install script. I think I should look at those because the older installer works fine. This is way above my current level of knowledge, hopefully i will learn something.

Hi Eliad
As for the repositories above, I'm talking about the Proxmox ones. You remove/disable the subscription based one and insert the "community ones" that will get you the latest Proxmox.
After that proceed with Debian net install 10.7 iso. Please select a primary mirror (something like ftp.country_code.)
The installation should finish without any issue. Don't update to 10.8. Begin installing IncrediblePBX2021 Debian first

Keep in mind that I had issues during some installations with a couple of files that had to be downloaded from the incrediblepbx.com server. The one that causes me issues most often is "ffmpeg-release-amd64-static.tar.xz" that takes ages to download but in the end it gets there

If the installation finished ok then you are good to go. If it doesn't, could you please run
./upgrade-asterisk18
It's a nice trick that helps me identify the part that causes the issues faster

Try all this and keep us posted
Good luck

 

[Eliad]

Hi Eliad
As for the repositories above, I'm talking about the Proxmox ones. You remove/disable the subscription based one and insert the "community ones" that will get you the latest Proxmox.
After that proceed with Debian net install 10.7 iso. Please select a primary mirror (something like ftp.country_code.)
The installation should finish without any issue. Don't update to 10.8. Begin installing IncrediblePBX2021 Debian first

Keep in mind that I had issues during some installations with a couple of files that had to be downloaded from the incrediblepbx.com server. The one that causes me issues most often is "ffmpeg-release-amd64-static.tar.xz" that takes ages to download but in the end it gets there

If the installation finished ok then you are good to go. If it doesn't, could you please run
./upgrade-asterisk18
It's a nice trick that helps me identify the part that causes the issues faster

Try all this and keep us posted
Good luck

you mean to add more sources? what is the name for the "community ones"

this is my Proxmox /etc/apt/sources.list
deb http://ftp.us.debian.org/debian buster main contrib
deb http://ftp.us.debian.org/debian buster-updates main contrib
# PVE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve buster pve-no-subscription
# security updates
deb http://security.debian.org buster/updates main contrib

 

[progs_00]

you mean to add more sources? what is the name for the "community ones"

this is my Proxmox /etc/apt/sources.list
deb http://ftp.us.debian.org/debian buster main contrib
deb http://ftp.us.debian.org/debian buster-updates main contrib
# PVE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve buster pve-no-subscription
# security updates
deb http://security.debian.org buster/updates main contrib

What you have is correct. I called them community repos just to separate them from the enterprise one. Did you go ahead with the Debian 10.7 installation?

 

[Eliad]

What you have is correct. I called them community repos just to separate them from the enterprise one. Did you go ahead with the Debian 10.7 installation?

I tried just recently and did not work with the latest incredible install script. It did work with the prior version (Jan 2) version. It could be some random failure of downloading something,. I am still investigating. @wardmundy gave me the clue on how to compare the successful install log versus the failed one.
At this time I am actually good since I got one good install done and I transformed into a template prior to any customizations,
I am trying to figure out why the install failed (several attempts of install actually ) to be able to help other fellows who get into this problem.

 

[progs_00]

I tried just recently and did not work with the latest incredible install script. It did work with the prior version (Jan 2) version. It could be some random failure of downloading something,. I am still investigating. @wardmundy gave me the clue on how to compare the successful install log versus the failed one.
At this time I am actually good since I got one good install done and I transformed into a template prior to any customizations,
I am trying to figure out why the install failed (several attempts of install actually ) to be able to help other fellows who get into this problem.

Yeah I followed the discussion above but I thought you still didn't have a good install to work with. I'm glad that's not the case. Hope you get to the issue soon
Stay well my friend

 

[Eliad]

Yeah I followed the discussion above but I thought you still didn't have a good install to work with. I'm glad that's not the case. Hope you get to the issue soon
Stay well my friend

I appreciate it. Maybe I will figure out what is not working correctly in my case with the latest install and at the same time improve my knowledge on how things work.
I do like Proxmox, besides PBX I have other VM Installed, I set it up with HA (3 proxmox servers) and I just added Proxmox Backup server. I think is a nice setup I dont want to change to another Hypervisor system just because the PBX install is stubborn.

 

[wardmundy]

In an effort to improve install and download performance and reliability, we are introducing a new download site with an experimental Debian installer for Incredible PBX 2021. With the exception of WebMin, NeoRouter, and some Debian repo modules, all remaining components now are hosted on this new platform. You can try it out here:

cd /root
wget http://downloads.incrediblepbx.net/IncrediblePBX2021-D.sh
chmod +x IncrediblePBX2021-D.sh
./IncrediblePBX2021-D.sh

New downloads.incrediblepbx.net server performance:

Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Nitel (Dallas, TX) [3.78 km]: 2.699 ms
Testing download speed................................................................................
Download: 1378.54 Mbit/s
Testing upload speed................................................................................................
Upload: 765.20 Mbit/s

 

[KNERD]

I do wonder if Red Hat/IBM can now be found in violation of Open Source licensing?

Since CentOS was just their RHEL with all the branding, and proprietary code removed, they no longer have that.
Now CentOS Stream is a test bed for RHEL, they will technically no longer be providing the RHEL source as required by the various open source licenses.

 

[jerrm]

RHEL, they will technically no longer be providing the RHEL source as required by the various open source licenses.

Why do you think that? RHEL source will remain available. What do you think the new CentOS replacements are using?

They would be in violation of GPL if the only source available was the CentOS version. They have to provide what they compile and distribute as RHEL.

 

[KNERD]

Why do you think that? RHEL source will remain available. What do you think the new CentOS replacements are using?

They would be in violation of GPL if the only source available was the CentOS version. They have to provide what they compile and distribute as RHEL.

The source is only "available" if you pay a subscription. I think that violates some of the FOSS licenses.

Also, as mentioned the CentOS replacement is not RHEL, but newer unbranded test versions of unstable RHEL. Not the actual RHEL code.

 

[jerrm]

The source is only "available" if you pay a subscription.

You need a subscription (for easy access), you don't have to pay.

I'll bet there is some technical violation, but it will be buried so deep in FUD and conflicting GPL/TOS/EUA legalese no one will pursue it. The source doesn't have to be available in the easiest possible format. It's even OK to charge for the source in some scenarios. Anything approaching reasonable access to the source and no one will bother to pursue it.

 

[KNERD]

You need a subscription (for easy access), you don't have to pay.

I'll bet there is some technical violation, but it will be buried so deep in FUD and conflicting GPL/TOS/EUA legalese no one will pursue it. The source doesn't have to be available in the easiest possible format. It's even OK to charge for the source in some scenarios. Anything approaching reasonable access to the source and no one will bother to pursue it.

If you don't have to pay, I sure would like to see how so. I recall seeing a few bug reports at https://bugzilla.redhat.com/ and their reply would always be NOTABUG and point to CentOS URLs.

For charging, yes I have seen that before such in the case of providing the distro on a CD , or DVD. I had also seen some years ago where people were selling CD and DVDs on eBay, but their listings getting removed for copyright reasons.

 

[Halea]

I do wonder if Red Hat/IBM can now be found in violation of Open Source licensing?

Since CentOS was just their RHEL with all the branding, and proprietary code removed, they no longer have that.
Now CentOS Stream is a test bed for RHEL, they will technically no longer be providing the RHEL source as required by the various open source licenses.

The "RHEL product" is actually a mix of xGPL, MIT, Apache, public domain, and commercial/proprietary license software bits (there are probably other license types in the mix on top of the ones that I listed).

With respect to any xGPL bits the licensing terms are actually very clear. The source code needs to be made available "alongside" the binaries for a full compliance with the licensing terms. Keeping them in a separate area of your distribution server is also ok as long as the user can access and retrieve "without undue hurdle". In such cases the binary distribution material often "offers to help with the retrieval of the source code if requested (through support or sales department)". You'll see such postings for instance on Linux Mint's website for situations where you're having difficulties to fetch some source code.

In the 1990s some jurisprudence shaped the legal framework in this respect. There was a time, developers were compelled to deliver the source code (truly) "alongside" the binaries, which the legalese calls for. If you're backed in a corner you can sue and set the "alongside" concept as the ground level. Then the horse-trading between the parties (and/or the judge) will decide what's reasonable, what's not!

But, I can predict (having the court experience at both sides of the issue in 2002 and 2003) that "registration" for the purpose of just accessing the source code of GPLed software won't be acceptable, neither will be asking for a fee even for ancillaries.

In a case that my company won (we were trying to get a specific version of a source code) the judge ordered us to remit to the software developer "sufficient number of blank DVDs or CDs", so that the developer can put "any and all source code, all documentation related to the source code, and all matching compiled binaries including but not limited to object modules, dynamic and static libraries and executables", and "further document the used assemblers, pre-compilers, compilers and linkers used in the production of the outcome". The order was entered to be executed within 30 days, the developer was barred from asking any fees for the execution of the order, and it was warned that it would be slapped with a US $300,000 fine if it was found in contempt of the court order.

 

[jerrm]

The source code needs to be made available "alongside" the binaries for a full compliance with the licensing terms.

In the RHEL case, downloading even a free trial requires account creation and login. So source under the same construct is arguably alongside.

Vast chasms of gray area here, not saying RH is 100% in the right, but the attorneys will push the line as much as they can get away with. Also think any remotely reasonable request would be settled vs risk a precedent.

 

[KNERD]

The thing is, why are not the IP holders taking action?

There is a pro bono legal organization for open source folks.

Software Freedom Law Center

The Software Freedom Law Center provides legal representation and other law related services to protect and advance Free and Open Source Software.

softwarefreedom.org

 

[Halea]

The thing is, why are not the IP holders taking action?

There is a pro bono legal organization for open source folks.

Software Freedom Law Center

The Software Freedom Law Center provides legal representation and other law related services to protect and advance Free and Open Source Software.

softwarefreedom.org

They actually do. I know of a couple of cases where businesses were litigated by municipalities or state utilities because in their business dealings with various government entities they delivered open source software as part of their development. Most such contracts require that you put all the source code of your proiduct (including open source) in escrow. In those cases the developers couldn't fully comply because in turn they didn't have access to some of the source codes upstream.
So, the SFLC helped them litigate upstream in order to get what they needed.
The thing with most pro bono legal representation is that they wouldn't take pro-active action. You gotta have a case with potential for material loss so that they can help you.

The case that I described earlier (my company's) was also one of those, where you get sued by a local government because you can't deliver something that you don't have access to. So, you are tacitly forced to litigate upstream. Otherwise nobody in his right mind would go to court for open source license violation litigation. In our case we were "lucky" because we had/have on staff more than a dozen attorneys in three US states and half a dozen overseas countries. So, the cost was only incremental. But it still cost us a pretty penny by the time everything was said and done.

 

[KNERD]

They actually do. I know of a couple of cases where businesses were litigated by municipalities or state utilities because in their business dealings with various government entities they delivered open source software as part of their development. Most such contracts require that you put all the source code of your proiduct (including open source) in escrow. In those cases the developers couldn't fully comply because in turn they didn't have access to some of the source codes upstream.
So, the SFLC helped them litigate upstream in order to get what they needed.
The thing with most pro bono legal representation is that they wouldn't take pro-active action. You gotta have a case with potential for material loss so that they can help you.

The case that I described earlier (my company's) was also one of those, where you get sued by a local government because you can't deliver something that you don't have access to. So, you are tacitly forced to litigate upstream. Otherwise nobody in his right mind would go to court for open source license violation litigation. In our case we were "lucky" because we had/have on staff more than a dozen attorneys in three US states and half a dozen overseas countries. So, the cost was only incremental. But it still cost us a pretty penny by the time everything was said and done.

Well, if was referring to the issue with Red Hat and having paying to get to the source code they are using.

 

[kenn10]

You guys might as well be arguing why the sky is blue. CentOS is dead to me at this point and not worth the discussion anymore.

 

[Halea]

Well, if was referring to the issue with Red Hat and having paying to get to the source code they are using.

This will be pure speculation on my part, but if an attorney simply wrote a letter to RHEL/IBM's legal department complaining about the "requirement to register" being inconsistent with the obtainment/dissemination of the GPL licensed code, I suspect that the reply will be very accommodating and probably along the lines "please contact such and such by email and identify all the software modules and versions for which you are requesting the corresponding source code".
I've dealt with IBM Research for many years and I saw their legal team in action. They have a no-nonsense legal culture and it's probably starting to be enshrined in RH's. It won't change their standard practice with one such action, but if that keeps happening they will eventually drop such requirements as it would be the path of least resistance.