03-15-2021, 07:19 PM
(This post was last modified: 03-15-2021, 07:27 PM by TheOldPresbyope.
Edit Reason: typo
)
@UpsiUps
<tl;dr>
No.
<the rest of the story>
The network-boot part is well described in the RPi online documentation. I didn't consider it needing testing.
After reading the PiServer documentation I decided their classroom scenario (what we used to call a "thin client" scenario) isn't my scenario. What they want is to have multiple RPis boot into a read-only rootfs stored on a central server. Data written by a program running on any given RPi would be stored on the central server. Nothing is stored locally.
What I wanted is automation that allows me to connect multiple RPis to a central server, to download a fresh copy of moOde to each of the RPis *and to install* it to local storage, and then to configure each of the moOde players separately (because of different DACs and services) based on information retrieved from the central server. After that, each moOde player would run as it does now, without needing access to the central server, because everything is stored locally. When a new release of moOde comes along, put it on the central server, rinse and repeat.
This process is often referred to as provisioning and configuring a system. I decided 18 months ago that implementing it would "take a bit of fuss and bother that I wasn't willing to invest."
I believe that the new moOde utility developed by bitlab (the moodecfg.ini file and its parser) would make the final task much easier than it was before. We're close to a point where one could implement what I described above and have little else to do. When a new release of moOde shows up, each currently running moOde player could export its configuration to the central server. After the player is re-provisioned, its configuration could then be re-imported. As new features become available in moOde, each player would need to be configured for them but the new bits would then carry forward in this export/import process.
The tech savvy reader will note there is a similarity between my scenario and the kinds of problems folks tackle with Docker and all the software-engineering infrastructure that's built up around it. If only it were as easy to implement a full-blown Docker-based solution as it is to create the PowerPoint presentation pitching the approach.
Regards,
Kent
<tl;dr>
No.
<the rest of the story>
The network-boot part is well described in the RPi online documentation. I didn't consider it needing testing.
After reading the PiServer documentation I decided their classroom scenario (what we used to call a "thin client" scenario) isn't my scenario. What they want is to have multiple RPis boot into a read-only rootfs stored on a central server. Data written by a program running on any given RPi would be stored on the central server. Nothing is stored locally.
What I wanted is automation that allows me to connect multiple RPis to a central server, to download a fresh copy of moOde to each of the RPis *and to install* it to local storage, and then to configure each of the moOde players separately (because of different DACs and services) based on information retrieved from the central server. After that, each moOde player would run as it does now, without needing access to the central server, because everything is stored locally. When a new release of moOde comes along, put it on the central server, rinse and repeat.
This process is often referred to as provisioning and configuring a system. I decided 18 months ago that implementing it would "take a bit of fuss and bother that I wasn't willing to invest."
I believe that the new moOde utility developed by bitlab (the moodecfg.ini file and its parser) would make the final task much easier than it was before. We're close to a point where one could implement what I described above and have little else to do. When a new release of moOde shows up, each currently running moOde player could export its configuration to the central server. After the player is re-provisioned, its configuration could then be re-imported. As new features become available in moOde, each player would need to be configured for them but the new bits would then carry forward in this export/import process.
The tech savvy reader will note there is a similarity between my scenario and the kinds of problems folks tackle with Docker and all the software-engineering infrastructure that's built up around it. If only it were as easy to implement a full-blown Docker-based solution as it is to create the PowerPoint presentation pitching the approach.
Regards,
Kent
