In an environment where you need to support multiple customers and there will be multiple CMS servers, can users and groups span multiple CMS servers.
In other words can multiple Displays for the same client on different CMS servers be managed with a single group and user account as the environment scales?
Thank you,
Kyle
simple answer for now is no. Each CMS has his own database where everything is registered in.
How many display per CMS do you have? (curiosity)
Hi Vishal, the real answer is only a couple at the moment, doing testing. I am working to build out my own specialized Cloud based environment. Using the backend technology to drive the displays and technology, wrapping that in a front end to manage the environment. I guess without knowing the Xibo Cloud architecture, I figured their doing something similar. Sure it might be possible to keep each client on the same CMS and just scale by adding more CMS’s. But as you know if one client has 20 displays and another has 400 displays I might want to scale the displays across multiple CMS’s to balance the load. I have a very specific use case for this setup where I need the front end management to wrap all the management functions required in a front-end management app. Some of the specific capabilities needed for this use case are not available in the on premise or Xibo cloud solution. Also, it will be to expensive to stand up a CMS for each client for use is a saas environment.
I am thinking I will create user-groups across each CMS, create user accounts in each CMS for a specific client, make sure the permissions are applied across each CMS per those user-group, make sure users are in the proper groups and use the front-end wrapper to make sure the user account password are keep in sync across the environment, as users will manage their profile and passwords in the front-end which will then update all instances on the CMS servers.
My initial plan is to abstract all of the activities from the Xibo CMS into the front-end so all the digital signage activities would be done from the Front-end not the CMS directly.
Thank you for you response.
Kyle,
So it means you are going to build a front-end which shows you multiple CMS instances. But at the backend it still uses the resources of where the displays are registered. Not sure if you can share the tasks that CMS #1 can run only for the selected displays for CMS #2. Not to mention your layouts that are also on different places.
If my understanding is correctly, I would just balance the displays between the 2 instances and keep the displays which are using the same layouts together. With your own custom front-end, your customers can still control displays at different CMS instances.
Hi Vishal, my use case is for a commercial solution supporting a large number of clients with smaller manageable environments ( probably 10 - 100 displays).
All CMS’s will probably be configured with the same layouts available, clients wont change those layouts, they will use the layouts. They will have the ability to choose from a few layout options, or make request for additional layouts. Our team and backend admins will have the ability to create new layouts and make those available to everyone, all CMS.
Initially we could be managing a couple CMS’s, but could grow to many. If the system works as planned, clients wont see which CMS, their displays are connected, the frontend will know and if they select a change or push content. The frontend will send to the displays that were selected by pushing the changes to one or all CMS’s involved managing the devices.
I am currently building out the frontend to manage two CMS’s, still deciding which options clients will have the ability to change, view and which options will only be avail to the backend admins.
For example, lets say client #1 looks in their front-end dashboard and they have 15 displays available, at 15 different locations. The plan is they should not care or even know what CMS these systems are talking with. Lets say they select 5 displays to push content to. The front-end applications and database know which CMS each display is connect to and the configuration on the CSM is configured to support the client, meaning the security groups exist, users exist and they are part of the proper group for permissions. Once the request is submitted from the front-end to push the content, the API will push that request to the proper CMS’s for the selected displays. (in theory).
As I said we are building out the proof-of-concept for the basic requirements, on-boarding displays, creating layouts, updating schedules, uploading and pushing content to displays as well as the managing users, groups and permissions. Which is why we have two CMS’s each with a couple displays installed.
Thank you for your input and feedback
It’s a nice project, but I don’t think it’s workable, or very complicated.
I think, xibo’s cloud operate on the basis of 1 customer = 1 docker instance.
By multiplying the backend, you’re in for a big surprise.
Especially when you want to upgrade a server.
The fontend makes a lot of SQL queries, to fetch media, displays, etc.
He’ll have to rewrite all the code (back and frontend).
One thing I’ve learned in development: don’t rewrite what already exists.
In your case, it’s best to create one docker instance per customer, like Xibo Cloud.
But don’t shout too loudly, the Xibo team doesn’t appreciate this method, which overshadows their business.
I understand, and I’ve decided not to offer a cloud solution myself. I prefer their partner program.
What specific features do you need?
Thanks for the feedback Proserv.
I might have to spin up a container per customer for sure. As you mentioned I do not want to recreate the signage software for my project, at least not now. My platform will be a SaaS similar to Xibo, but I need some very specific features geared toward managing a network of partners who have their own customers. I need my own dashboard for managing my partners (billing, subscriptions, etc.) and the partners need a dashboard for managing their customers which need a customer dashboard.
Partners actually have two types of customers, customers using their service, and affiliates that get paid, so they need the ability to manage both. Of course the partner needs their own dashboard, the customer using their platform needs a different dashboard and the affiliate needs even a different dashboard. There are many other future features that will eventually be part of the platform (coupons, QR codes, content delivered based on AI, content that can be delivered across all displays on the platform, etc.) One of my main issues is I really need the ability to stream Live-TV to the Windows player or a non-paid player, full screen, with the ability to support different sources per player (cable boxes, satellite, Internet streaming TV, etc. ) until the playlist has other digital sign content to display. At this point in the project I do not want to use paid media players, there may be a need in the future but right now I want to use the Windows or Linux player. And I am leaning to the Windows player because I have experience with .Net VB and C#.
As I build what I’m calling my MVP, I will have approximately 25 displays running in the initial environment, with a minimal set of features. I am currently working on the dashboards and basic features and interfaces to my CMS that will drive the displays. I am hoping I can map most features the client needs in the dashboard using the Xibo API.
Also, we do not own the displays, we will just provide the media players and the content that plays on the displays.
Thank you,
Kyle
I think this echoes what others have said; my advice would be to build your front end dashboard as a separate service which communicates with your CMSs’ via the CMS API.
Xibo is often used as a headless CMS in this way, so you’d be following a tried and tested approach. If you model them as a supportable environment it also gives some flexibility for if you want to move the hosting of those CMS instances at a later date, or need help.
Whether you model the CMS instances themselves as one big one or lots of little ones is up to you really; 10 to 100 displays will usually operate nicely in a single container, whereas larger single instances would require scaling.
Dan thank you for your feedback.
That’s exactly what I am doing, I figured I would need to build the SaaS front end and dashboards to integrate with the Xibo backend CMS.
Is there a document within Xibo, that details how to setup the feature permissions for groups to allow a group to be able to manage just their companies displays and media/content/schedules/layouts etc., I understand the user and group permissions were not specifically designed to support multiple companies, but looking at feature permissions its not clear how to lock down certain areas or if you can.
For example, can I lock a user group down to only being able to add displays for their company in their area? If so, how is this accomplished? Also, I see that you can create folders, do they have to be shared in order to set permissions by a group?
Like if I have folder structure:
Root Folder
Partner1
layouts
img
home
Partner 2
layouts
img
home
I don’t want anything stored at root, everything should be in folders under root. Is this possible?
Can permissions be setup to only allow content to be seen, created, deleted, etc., by members of specific groups with access to the folders under a specific Partner folder in the dashboard?
Thank you,
Kyle
I think that broadly speaking you can do the things you need with the features we have already in Xibo.
The only thing you won’t be able to do is have them add their own displays as currently they are added to the root folder with super admin only permissions.
Features and sharing are explained here: Features and Sharing | Xibo Digital Signage
If you’re building a front end, won’t you manage ACL there instead?
Hi Dan. thanks for the feedback. yes that’s a great point I am managing some of the ACL’s on the front end.
With that said, I have one question since you must be a super admin to add displays, does that mean when setting up the application in Xibo and the access code (API authentication info) does this authentication provide full permissions equal the to being a Super Admin or do you have to setup Sharing Scopes for full access?
Thank you,
Kyle
Unfortunately, rights on Xibo are still limited, especially when it comes to read-only access on folder (I’ve had a few problems with this), as well as the display part (displays, profiles, etc.).
If I’ve understood your needs, you can also turn to orchestrators like Kubernetes or others with an UI. This way, you give your partners an interface with controlled rights to this orchestrator, and they can create xibo container block for their customers.
Hi ProServ, no the partners nor their users will be able to actually stand up the infrastructure. Our team will do that. I want the partner to be able to manage their users and permissions so they can perform normal activities however I will be using a headless CMS model where everything will get done through the SaaS dashboards and not the Xibo dashboards.
The API will have full access to the Xibo based on the permission in the SaaS, and the permissions and roles in the SaaS will determine what users can do in the sign system.
I have decided for now to maintain a separate container per partner since keeping data separate per partner will just be to hard to manage in the same installation of Xibo.
I was just asking Dan how do I give the API full access, what does that setup look like. Does the Share access part of the API have to be used to allow full access.
Make since,
Kyle
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.