I use Xibo CMS behind reverse proxy to add more security. I used to have 1.7.9 on my own Apache server. With that, it was as easy as apt install libapache2-mod-rpaf
in /etc/apache2/mods-enabled/rpaf.conf change RPAFproxy_ips to my reverse proxy’s internal interface and simply service apache2 restart afterwards.
This allowed me to examine Apache logs containing proper information related to where connections come from (because otherwise the logs are populated with the IP address of the proxy).
How to do that with docker install? And will it survive an upgrade?
You would run your Docker install on a custom port. You then have a CMS listening on say 127.0.0.1:8080. You then setup your reverse proxy infront just as before on the host machine. No modification of the container is required.
There’s an example in the manual, or indeed in the guide I wrote here:
If you want to use a different method for configuring your reverse proxy then that’s fine, as long as traffic goes through with the original host header, and ideally X-Forwarded-For and X-Forwarded-Proto headers, then it should all work. Xibo will then see the correct IP addresses.
You misunderstand me.
The reverse proxy is on a different machine on the network, and is provided by pound (http://www.apsis.ch/pound/). It has nothing to do with the machine Xibo is running on. Logging in pound is a different story, and obviously is not part of this question.
What I need is to check the logs of the Apache server of Xibo, and analyse them for security reasons. Being a service accessible through a public IP address, that shouldn’t be too much to ask, right? And in the logs of it, the proper way to identify connections. Previously it was possible the way I described in the first post.
This also leads me to the next questions, how do I reverse proxy XMR? Is it also an http-like protokol?
Right. Had you given that information at the outset it would have greatly sped up the response. I can’t infer a completely custom setup without the appropriate information.
If you want to see the logs directly, you need to connect to the console of the container, and view them from inside.
docker exec -ti name bash
where “name” is the name of your web container. You can get the container names from docker ps.
Logs will then be in /var/log/apache
As the container is being proxied however, they will only contain the proxy’s IP address. The logs pound collects will be far more useful to you since they should contain the same information, as well as the real remote IP.
If that isn’t acceptable to you, you will need to build your own container, based upon the official one, but with the modifications you require. That’s a relatively straight forward job - to add the Apache modules you need and the configuration to enable them.
You could also make the exact same modification to the live container (ie do your apt-get install, and then configuration modification), however, be aware that that won’t survive an upgrade or rebuild of the container, so you’d need to do that manually each time.
Alternatively you can do a custom install as you had before, but then you’ll need to do all the setup that the container automates for you.
XMR cannot be proxied via an HTTP proxy. You can proxy it with a TCP proxy (like haproxy for example).
Fair enough. If you have a whole IT team and people who can invest time in configuring and maintaining all the required elements (XMR, XTR, the CMS itself, SQL, backups etc) then a custom install is completely feasible.
You have to appreciate here we’re catering for users like yourself, as well as people who want to install on a Windows desktop machine.
I really don’t understand this attitude Alex. You and your team’s work has been always appreciated. We never took things for free, we already purchased a dozen and a half of Android licenses and the on-premise licensing module for honest money.
We look forward in the near future (literally following weeks) for 2 expansion projects having about 30-40 Android clients each, and we also plan to get the player hardware from you (dsdevices) - with the honest intention to financially support the project.
I was always expecting that my observations are taken as constructive criticism, where you could take and see, or maybe even consider that there are multiple different scenarios where this great open source project is being used. Enforcing various things down the throat of people with no way to turn back doesn’t seem to be something too easy to accept for use cases where certain decisions have been already made knowing the features and functions of the software at that time. See some examples below:
One of the best things of Xibo up to 1.7.9 was that it was HTTP-only, we could break any walls with that. Employing XMR mandatory (because otherwise we lose basic functionality like screenshots) was a hit under the belt. It would have been much more correct if previous functionality was kept untouched and XMR would just add extra, if somebody is unable to XMR that due to various reasons, why not respect that?
Also the same with dockerization and stating immediately that non-dockered installs won’t be supported anymore. Again a hit under the belt, upgrade process is not as simple as the docs say (re-installing from scratch seems simpler than upgrading). I can understand that docker makes things simpler for you, but I am really sad to see that door has been suddenly shut (as officially stated) for custom installs (and it’s plain to see that documentation to have a custom install is next to non-existing - I don’t call searching various posts across the forums as proper documentation). Many installs use the same webserver where Xibo is located for many parallel things, like serving HLS video content to the same players, and other web-content which will be displayed by the same Xibo clients, but as embedded webpages (simply because Xibo’s own editor in the CMS can’t solve the customers special requests).
Things seem to change around Xibo with 1.8, and I’m not talking about features literally, but about the way things are approached. Up to 1.7(.9) features were more thoroughly tested (remember good old Launchpad times before 1.7), user interface elements were properly designed and written down, user feedback was better appreciated. Now I see tons of features appearing but all undocumented (not expecting a separate doc, but maybe just a sentence in the UI), literally just “thrown in” having the user run into confusion (remember my post about HLS media type not working in Android, I had to report it in the forums, and got the answer that HLS module was never intended to work under Android, that is a Windows-only feature - and I should simply try the Local video module - how on Earth was I supposed to know that from? The HLS module has nowhere a single word that it’s intended for Windows only, and Local video either doesn’t say a word that it supports HLS. All the documentation says is local video files and (maybe) certain RTP streams, (may I quickly note here that while HLS does work somehow in Local video media type, it’s far away from being something stable). Things like this making the product harder to use. And taking away your precious time too - as if they were properly done, the majority of the questions wouldn’t even appear on the forums and you wouldn’t have to instruct everybody one by one that “this has been already discussed many times” demoralizing the whole community etc. Such things didn’t happen in the past.
I’m really trying not to offend anyone here. But I am posting this in a hope that this is also taken as constructive criticism. We are really trying to use OpenSource software everywhere, not only taking it for free, but trying to give something back in exchange: our experience and feedback (to make the project better for others) and purchasing products to financially support those working in it. Of course could be easy to grab some windoze with an activator and use your WIndows-based client and hide away using it ‘as is’ - but we don’t do that. We’re trying to play open here, and take the professional approach - which we believe is better for everyone: the Xibo project, the end-users and us.
I’m sorry you’ve taken my reply as “attitude”. My reponse was written, and intended to mean “yes go for it - in your scenario that makes sense”, but, keep in mind that there’s some extra work on your part as a result. Nothing more.
I will mark this up for discussion again, but our experience is where we offer multiple ways for things to happen, it’s both a source of future issues, and of user confusion. They will expect to see an instant screenshot, and with therefore assume the system is broken.
This isn’t what we’ve said. We have provided Docker containers which have a sensible setup for running the CMS. If you choose to run outside of those, then we may not be able to offer you “free” support for that setup, since there are then so many variables. What you don’t see is the hundreds of maybe even thousands of hours we loose every year to issues where people tell us their install meets various requirements, and then actually it doesn’t. When we were back on Launchpad and there were a few hundred installs, it was completely feasible to manage that. Now there are tens of thousands, it just isn’t feasible to do that any longer. It comes down to a simple decision to either follow the industry trend for delivering a managed package with known, testable dependencies, or, stop providing the level of support we currently do. I’ve come across very few OS projects who offer the level of engagement and support that we do, and I don’t want that to change going forward.
Again, this is simply not the case. All I have said, is that we may not be able to offer you free support for a custom install. If you have an issue with your custom install, which reproduces in the container, then no problem - we will still look at it.[quote=“robreg, post:9, topic:9982”]
Many installs use the same webserver where Xibo is located for many parallel things, like serving HLS video content to the same players, and other web-content which will be displayed by the same Xibo clients, but as embedded webpages (simply because Xibo’s own editor in the CMS can’t solve the customers special requests).
There is provision to do that in the container. There’s a “userscrips” share for static content to be served from. If you require another server for your streaming etc, then a reverse proxy infront is the best solution, since it will allow Xibo to run in a subdomain or subfolder at your option, and other content can be served as you want.
I completely agree we’ve done a bad job of explaining why the official installation method is via Docker, however, if you look at the bugs that have been logged in the 1.8 series, there is a step change. The bugs are in the main less serious, cosmetic issues, and we have been able to reproduce and address them in a far more reliable fashion than before.
This is out of context. HLS does work on Android (with appropriate support. It certainly works on Android 6 - and supports resuming feeds if they drop etc as you requested), but it’s not the best way to achieve it. Yes the UI should note that, and we’ve logged a bug to address it. I’m sorry we missed it before release. Our view was it was more important to get that functionality available and it came right around the freeze for release.
I agree. I do try not to put “has been discussed many times”, but the simple fact is because we do answer posts in a timely fashion, there is a significant number of people who don’t even look in the FAQ before posting a question. We are human, and there is a limit to the number of posts we can address on the same question without referring people to other threads on the same issue.
It hasn’t offended, and I appreciate your feedback. We are really trying hard to improve the core product. 1.8 brings proper test-ability for the first time to the software, because of the changes we’ve made, which in part have driven the switch to Docker. That test suite catches many issues before code hits the main repositories. That your opinion that the thing is now thrown together without care is the most upsetting aspect of your post to me.
[quote=“alex, post:10, topic:9982”]
I’m sorry you’ve taken my reply as “attitude”.
[/quote]I meant “attitude” to the general tonality of your replies to all my posts lately. Not specifically this one.
[quote=“alex, post:10, topic:9982”]
That your opinion that the thing is now thrown together without care is the most upsetting aspect of your post to me.
[/quote]I understand and I’m sorry for this. But from corporate-IT perspective seen, this is how it looks like, although it may be not like:[quote=“alex, post:10, topic:9982”]
There’s a “userscrips” share for static content to be served from.
[/quote]Again, this is an example of what causes the whole project to be thrown together - this is not something obviously present in the documentation.
I repeat - I don’t statefully declare that it is thrown together - but it definitely looks like it would - at least from this perspective, where we manage many critical systems in corporate environments and Xibo is just one of them. We look forward to deploy hundreds of signage clients in the future, in such strict environments - and we really want to keep doing this with Xibo.
Thank you for your answers and the time to take to re-discuss some of the issues I described. I’m glad I was able to break the ice, although sorry that I had to make you upset. Sorry for that.
I wasn’t going to comment on this topic as I feel that Alex has done an excellent job of explaining our position and has tried to be as constructive and helpful as always. It is not an easy task to convey our “sentiment” using text, but I can assure you that none of our messages are ever intended to be negative - that goes for all 3 of us, not just Alex.
Ultimately this comment has pushed me towards posting a reply - as custodians of a popular open source project, we have thick skin, however it is upsetting to see a comment like this being posted. The irony is that as the project has aged we have applied more thought, development processes and testing to everything that we do. Of course this means that we are bit slower and that there are elements that can be improved, but overall the package is more robust in our opinion.
Documentation is the bane of all open source projects, usually neglected. This has been the case for our project in the past, but we are slowly improving. We are always open to documentation suggestions and contributions - the documentation has been converted to a format that is easily editable for specifically this purpose. The documentation around custom installations hasn’t gotten worse, but equally, as the product gets more complicated, explaining all possible installations on all possible environments just isn’t feasible. Again, we’re happy to accept contributions or guides to address specific platforms.
Finally - Docker - an entirely optional, but suggested way to install Xibo. Contrary to what you might think, we’ve expended considerable effort to get Xibo working well on Docker, and considerable effort to explain it. Xibo has always been easy to install, but hard to install correctly. In line with the rest of the industry, we wanted to provide a simple installation process, which came complete with best-practice configuration for security, maintenance and backup. That is what Docker brings and is what led our decision to adopt it. It definitely has helped our testing and development process, but that isn’t the main reason we use it. Containerisation (with Docker being a method to do that) should be more secure on restrictive environments, because you can surround the containers with whatever additional security methods you want without effecting the core operating methods of the container.
Xibo being used in corporate environments is something we are well aware of, and we certainly don’t want to alienate that user base.
I’d like to close by saying that we’d be delighted to have your feedback and contributions on any issues with the software - we are a large project and any help we get is gratefully received.
I see this school happening at every project growing over certain borders. There are many open source projects we’re part of, and we’re always pushing feedback, and requesting help, but also giving help once we have experience (this activity is also useful imho, since we’re helping the project by giving some support to newbies, freeing deveoper time).
There are projects more or less tolerant on this approach. For example notoriously microtik forums are rude and nerdy, it’s hard to integrate there. But it’s much easier with ubiquiti, pfsense and many others.
If I may contribute: I don’t see the need for Docker at all in a professional production environment, there are too many things and configurations you can no longer “touch” which is often needed to fine-tune the installation to your needs and once you ‘export’ everything, it’s no longer Docker (or you might as well roll your own Docker instance)
For very small instances, testing, development etc, Docker is definitely easy and I appreciate the effort done to make it work, it’s just not useful for my needs outside development/testing. For production, there are and have been many more ‘jail’ systems that are much more useful.
I found the reliance on XMR within the CMS confounding as well. I’ve worked around it but I think the CMS should figure out whether a system has XMR and respond appropriately. It’s a minor ‘bug’ imho.
After all, this is ‘free’ software, I am greatly appreciative of being able to use it and if something doesn’t work the way I want, I’m either going to fix it myself, submit a patch if necessary or pay someone to do it, I’m pretty sure if you fork over some money to the devs, they’ll work with you on your particular installation.
I absolutely see where you are coming from - many production environments will be highly customised to suit that specific need (or that specific network team) and Docker won’t always fit in that environment. We didn’t ever “target” this sort of environment when we thought about moving to Docker. For technical teams like this Docker can still be used as an example of how we would configure the application in a simple environment.
For us, Docker is about repeatable, identical deployments.
That is also interesting - we’ve purposely not made it reliant (apart from the screenshot issues mentioned). It is true that some things will not function without XMR, but only because it doesn’t make sense to do so in those specific cases. I’d be interested to hear where you think that should be decoupled further.
Time will tell whether Docker is adopted on a grand scale in production environments or not. I’m fairly certain that containerisation is the way forward and will become more popular over time, but we will see , I do know of some very large production installs that are using Docker and many more that aren’t.
I’d also be curious whether you’d have the same opinion if there was a benefit to using additional technologies - for example, perhaps a memcached container could be added to assist with loading on large installations? In Docker that would be fairly trivial… or perhaps Elastic Search could be added to store stats for large installations, etc.
I think there are many users of Xibo deployed in places where docker doesn’t fit in.
It’s just that maybe Xibo developers underestimated that, and thougt that majority of the users would be happy with it. Enterprise users just stay in silence, they are pro enough to deal things by themseves and don’t need support, like Guru_Evi just mentioned “if something doesn’t work the way I want, I’m either going to fix it myself, submit a patch if necessary”. Docker imposes many limitations on this kind of users.
Yesterday I was asked by another corporate environment, to replace a part of a Samsung MagicInfo system with Xibo. Again, a place where docker makes is harder (heres’s just a one of the restrictions they mentioned: in their network, all the internal web services requiring any kind of local authentication - like Xibo CMS - have to run on HTTPS and employ a certificate issued by their IT department; oh and another one - no internet access allowed on this specific network segment).
Maybe you are right, maybe we did underestimate the amount of trouble people would have with Docker. However, I still don’t think having Docker as our supported method of installation is wrong.
We can all think of problems to prevent the usage of Docker or any other system - no internet access (out of band) and HTTPS certificates are completely addressable and discussed already on here - but if you really don’t want to use Docker, you could take the approach of Guru_Evi and roll your own installation. There are resources in the manual to help you do that, and there are guides on here written by people that have done so.
Our position is that if you find an issue, and we can’t recreate it, we will ask that you recreate it in a Docker environment. This is a support process and makes perfect sense if you take the time to understand it. If you recreate your problem in Docker, we can assume we don’t understand exactly what you are doing, ask for your backups and recreate the exact same container here to see your problem. If you can’t recreate your problem in Docker, we can assume it is an issue with the environment and narrow down the issue accordingly. Remember we are talking about completely free support here!!
We can discuss this until the cows come home (English saying, means for a long time ), but in the end we will have to agree to disagree. IMO Docker can be applied to any environment if you are willing to make it so, in your opinion its restrictive and can’t be used in many environments. However it shouldn’t be a requirement to run Xibo, and it is not a requirement to run Xibo - so surely that is good!
Xibo is easy to install including all the prerequisites on any modern Ubuntu or other Linux instance (actually, a bit older since PHP7 is not yet supported). Again, I greatly appreciate the efforts so I can duplicate issues in a “stock, working Xibo” and for a support purpose, I think it’s definitely a good idea to require people to test things in Docker.
The problem I have with Docker is items like Memcached and MySQL (or MariaDB) or more exotic integrations, which at some point has to be tuned to your hardware/limits and Docker takes away a lot of that control, asks you to trust some random developer to have done it “right” and then forwards TCP packets between hosts which makes it very hard to get any ‘insight’ into the system.
Sure it works very easy on Amazon/Google-scale ‘clouds’ if you have the cash to run it on those services but not everything is Google-scale, most people simply got the job of “run this thing on the crappiest hardware we have”. I guess I’m “old-school”, I like my “private cloud” and optimizing to suit my clients’ need which in my opinion the industry will inevitably go back towards. On the other hand, if I were to launch a service that offers “Xibo in the Cloud”, I guess a customized Docker instance would be great.