Concerto Player Software
Our goal is to create a common firmware image for the Concerto2 Player. This page is still at the draft stage. It is divided into two sections: information about the operation of the player, and information about the components of its software.
The following is a list of things that need to be configured on the screen:
- Instance URL
- Unique identifier
- Possibly, a security token or private key
- On/off hours
- Video settings
- Network and audio settings
At the first boot, the screen will need to be given an instance url by the user. This could happen in several ways:
- Locally, with keyboard and mouse (perhaps using a localhost webform)
- Locally, via serial cable
- Remotely, via webpage, ssh, etc. (IP would need to be shown on screen)
At the same time, any non-default network configuration, as well as security configuration, should be entered. Once complete, it may be desirable to disable certain modes of access. Potentially, a unique password could be generated to allow reconfiguration at a later point in time.
This entire step could be bypassed if you generate a custom firmware image containing connectivity information for your Concerto install. This might make sense in cases where a large number of screens were to be deployed.
The next steps in configuring the software could happen in a variety of ways. Here is one proposal; feel free to add your ideas.
- Player contacts server, sending some basic information about itself (including display info).
- Server stores this information as an incomplete "Player", returns a temporary ID code to be displayed on the screen.
- Administrator logs in, navigates to screen setup wizard, where the temporary ID code will be displayed in a list.
- Administrator answers questions that will aid in determining optimal display settings. Configuration files are generated. This may or may not include firmware updates.
- The Administrator is then prompted to link to set up a new Screen, and configure templates, subscriptions, etc.
- The player is polling for the files, downloads and verifies them, and updates itself accordingly. Once configured, it will redirect its web browser to the concerto player, which will begin operation as soon as the Screen is configured. see "Playing Concerto" below.
The end goal is to launch a full-screen web browser. After configuration, it should fetch the screen display webpage from the approrpriate instance, and javascript within the browser will manage the multimedia experience.
By visiting the administrator control panel, some data about the player should be available (incomplete list):
- Connectivity (last request)
- Uptime
It may also be desirable for the Player's local webserver to be accessible in a read-only mode which would provide information to assist in debugging connectivity.
There are various levels of security to consider:
- Server verification
- Client verification
- Disclosure prevention
The screen must be able to verify the identity of the server, so that unauthorized content and configuration data are not received. Further, important messages could be signed to make sure that the data hasn't been modified in transit.
It may be desirable that the server be able to verify the identity of the screen. This may not be required in all cases, but potential features like screen status reporting will benefit from this level of security.
One way to accomplish this may be adding a signature to requests. In an SSL environment, that key could be generated and via HTTPS during configuration. In an unencrypted environment, the user could type it in on one side or the other.
It may be desirable that all communications are encrypted end-to-end to prevent eavesdropping that might disclose private content or sensitive configuration information.
The most obvious solution is SSL. The downsides, of course, are dealing with certificates and the increased processing required.
As with Concerto V1, the computers will be loaded with a linux-based operating system. It will need to be capable of being updated remotely (though the actual mechanism might exist at the OS level or a higher level).
One of the key OS-level challenges will be video interface configuration.
The web browser must be launched in full-screen mode, and the cursor must be hidden. Important considerations for the browser will be performance and possible support for multimedia (flash or HTML video, audio).
This is a new idea since Concerto V1. The proposal is to use a lightweight local webserver to manage configuration. It would be the homepage for the browser, and once the system is configured, it would automatically redirect to the player on the appropriate domain when accessed from localhost.
This process would be responsible for launching and monitoring the web browser, as well as turning the screen on and off. It will also likely have responsibilities related to configuration and firmware updates; these functions may or may not be tied in with the configuration server.
We've created a Fedora kickstart file, based on the XFCE spin, that will generate a live CD starting Chrome in kiosk mode, pointing at a given URL. This needs to be extended to include the configuration server. The unclutter package is installed to hide the cursor. X11 settings are presently autodetected by the live CD's built-in facilities. The live CD can be installed to a flash drive using an included shell script provided by Fedora.
Boot process is provided by the Fedora live CD; existing code does not modify the default Fedora boot process. gdm is started in auto-login mode and starts xfce. A chrome-kiosk.desktop file in ~/.config/autostarts runs Chromium as chromium-browser --kiosk --app <url>.
When a user powers on the screen, the browser should be pointed at some 'magic' URL on the local configuration server. This will determine whether the screen has been configured or not. If it has been configured, the configuration server will redirect the user to the appropriate URL. If not, the user will be redirected to a configuration form.
The initial configuration display should prominently display the client's IP address. Fields should also be provided for inputting static IP configuration data.
Oddball use case: what if we're on a network without DHCP, and local entry isn't feasible? Is this a use case we want to consider? APIPA or IPv6 link-local addressing come to mind as possible solutions to this problem.
If the configuration file is JSON, the configuration server can be super simple. It just needs to be able to GET and PUT the configuration file (only for authenticated users of course), and serve up static HTML and JavaScript.
When the configuration file is saved, data in system configuration files (network settings, etc.) needs to be updated somehow.
NetworkManager may have to go, unless we can figure out how to generate a NetworkManager config from the configuration server. If this approach does work, wifi should be easy to support.
This will need to receive data from the server, either by HTTP polling or some other method, regarding whether the screen is supposed to be on or off.
The player needs to be able to pull down X configuration files before gdm starts up. This can maybe happen from /etc/rc.local.