Permanent banner when running XOA from the sources

[FoxieHazmat]

Context

• XO origin: the sources
• Versions:
  • xo-web: 5.34
  • xo-server: 5.34

Expected behavior

Current behavior

Just updated to 5.34. Can't disable the banner notification? Whats up with that? I am sure everyone who manually builds XOA understands the risks; there are warnings everywhere. I am all for that, but hurting the usability of the software because people won't/can't purchase support? Not FOSS, not cool.

Referring To - "[XO] Add banner for sources users to clarify support conditions #4165 (PR #4167)" In the changelog

[tuxpowered]

I know this is old... but I wanted to add my 2 cents here because I don't think anyone has suggested the following (not that I have seen) and because I think it addresses both sides of the issue.

The way I see it is that the CE users are generally annoyed that the "nag notice" consistently returns after acknowledging they are using a source install.

And @olivierlambert is annoyed that users are "But a lot of people are using Docker/3rd party scripts" without referring to the creators of those scripts for support.

It is 100% understandable that 3rd party scripts are not supported. (but not everyone reads esp people that are just 'testing' XO CE and barely know how to manage a server to start with. (I think seasoned admins do not have this issue and look at the documentation) So I think that mostly we are looking at 'new' adopters of the technology as a whole.

So to address the issue of "But a lot of people are using Docker/3rd party scripts" it seems logical that perhaps there is an official build script to build and install XO CE, or even a prebuilt xva for the CE edition alongside the XOA edition. This would kind of eliminate the need for any 3rd party scripts for installations. In the case of the XO CE as an .xva download, you could just have a nightly build script that builds and publishes a nightly build. If someone wanted to "upgrade" they would have to back up their config install a new VM and restore the config vs now where one might just run @Jarli01 xo-update.sh script instead (or as a cron job for the brave and bold) Still the point is the same. new users get a simple install but no updates or support

Would it really hurt if someone acknowledged that they were using the CE, and that a check bit was saved in the config to not show the notice again until they upgraded to the next version?

As to the Docker issue. I understand that supporting a docker version may not be on the roadmap. But again it would eliminate that issue. Personally, I do like docker images as they are easier to manage and update as a whole over other options. I do not think that there is anything anyone could do about this except provide an official version.

For the longest time, Zabbix refused to offer a docker image. As a result, several community versions popped up with monitoring artist being one of the most downloaded versions. With some of those being over 50+ million downloads!

This made Zabbix reconsider, and now Zabbix offers an official docker image, even though it is not recommended for production use. The end result? monitoringartist images have not been updated in years. Why... because most users started to just use the official Docker image. And when they moved to the official docker image, there was no need for the monitoringartists images any longer.

The point of this is that in the absence of a supported architecture or platform, with open-source software a community user will likely fill that nitch if there is a need. This is a good thing, but the end users likely are not technically adept enough to understand who the responsible parties are.

I would say one last thing about WHY you might want to consider an official Docker image. Many users lease cloud services. (Digital Ocean, Linode, etc). And most of these run KVM. They may already have a host running a few centralized docker images because it is outside of their own network. (Such as a Zabbix Monitoring server hosted in a cloud provider). Adding a management tool, like XO CE, or even native XO, as a docker allows the ability to have a supported image in a publicly assessable location that might be easier for visibility.

I for one do this very thing and run XO CE on a digital ocean VM connected using tailscale as the VPN to my home lab. I am able to see my lab from anywhere in the world without having to have direct access or opening ports on my firewall or having to have a dedicated VPN connection on a mobile device. And while I run this as a VM, I would much rather have had it as a supported Docker image.

Well that is my two cents. I hope it was useful.

-- P.S. I am also a paying XO subscriber for our production installation but use XO CE personally and as a demo to interested parties.

[olivierlambert]

Thanks for your input.

It's 2 different "problems" (bundling and "nag" screens), I don't see the connection between them.

1. About the bundling/docker-ing: it's mostly solved now, people understood where to report issues. We have a lot less problems due to that.
2. nag screen: there's still no way to know if it's used as a home lab or for a business (the latter shouldn't use it in prod). I don't see any solution in your feedback.

You are raising an interesting thing however: providing a "demo"/SaaS version of XO to test it very quickly. I have this in mind since a while, but it's not yet very high in the backlog :)

[tuxpowered]

A SaaS version (Hosted XO) I think could be a good option, if it was affordable. (I have to admit that XO is a little pricey esp for smaller companies. Esp, if you're trying to use the more advanced backup options. I still have clients that just install a copy of Windows as a VM and run Xen Center, because its far cheaper.

I do wish the CE could have 1 proxy though :)

[olivierlambert]

@tuxpowered we'll have bundles coming in the next months, with both XCP-ng and XO into a single offer. So this will solve the small company pricing issue.