Video: New laptop lets you easily view Raspberry Pi inside, and upgrade
When the Raspberry Pi Foundation announced Raspbian (Debian) Stretch for x86 and Macs, there was a very brief mention of something called PiServer to manage multiple Pi clients on a network, with a promise to cover it in more detail later.
Well, ‘later’ has now arrived, in the form of a new Raspberry Pi Blog post titled The Raspberry Pi PiServer Tool. In simple terms, the PiServer package allows you to manage multiple Raspberry Pi clients from a single PC or Mac server. Here are the key points:
- Only Raspberry Pi 3 clients are supported. Sorry.
- Clients boot via network (PXE) from the PiServer, not from their own microSD cards.
- User accounts and passwords are defined on the PiServer, not on the client.
- The client root filesystem is mounted from the PiServer, not locally.
- All clients share the same user/password data and root and /home filesystem.
With this kind of configuration and those restrictions, it seems to me that this will be most interesting for educational or industrial installations, where there are multiple clients which must be identically configured.
I find this kind of thing absolutely fascinating, so of course I had to set it up for myself and give it a try.
For the server, I just used one of my laptops, an ASUS X540S. Installing Raspbian Stretch on it was no problem, as it uses a slightly modified version of the Debian installer. After the base installation is complete, make sure that you install all the latest updates. The PiServer software is included in the base distribution, so you don’t have to do anything special to prepare that.
For the clients, the only preparation necessary is to enable network boot. This means, as mentioned above, only Raspberry Pi 3clients are supported, as they are the only ones which are capable of network boot.
See also: Enterprise IoT calculator: TCO and ROI
To enable network boot, the client must first be running Raspbian. Then simply add this line to the end of /boot/config.txt:
Reboot the Pi3, and check that the command worked:
$ vcgencmd otp_dump | grep 17:
Once you have confirmed the value shown here, you can remove the line that you added to the end of config.txt above.
What this configuration actually does is add USB and PXE (network) boot to the Pi 3 boot sequence. They are added after the normal local disk (SD card) boot, so as long as you have a bootable microSD card installed, you won’t see any difference. So now you need to shut down the client, and remove the microSD card.
With the server and clients prepared. The PiServer and client(s) must be connected to the same (wired) local network — wireless networking is not supported. In practical terms, this usually means they are all connected to the same Ethernet hub or switch.
You will find PiServer in the PIXEL desktop menus, under Preferences. You do not have to be root to run it (which I find a bit surprising).
The first time you run PiServer, it starts with the Introduction screen shown here. The server must have internet access, because it is going to download the client software that it will need. What that means in practical terms is that I had the wired network connection of the laptop connected to an Ethernet hub, and the wi-fi connected to my home network.
The screen reminds you of the basic requirements that I mentioned above, plus one more: the clients should have the same keyboard layout as the server. That’s not really a requirement, because the client will boot and run anyway, but it might be better for your sanity if it has the same keyboard layout.
The next PiServer screen lets you add clients, based on a list that it builds of the MAC addresses of clients which are asking for PXE boot on the local network. If you haven’t powered up any clients yet, the list will be empty, and you can’t go any further until there is at least one client in the list.
If you have any doubts about whether a particular Pi 3 is in the list or not, simply power-cycle it and watch what happens to the list. It’s kind of fun to watch them appear and disappear dynamically.
If for some reason you have any systems on your network which are asking for PXE boot, but which you don’t want to manage with the PiServer, simply un-check the box beside them.
When all the clients you want to configure are visible and selected, continue to the next PiServer screen. Here you can enter the usernames and passwords. Remember, this is a shared list — every client will use this list, and any user in this list will be able to login on any client which is managed by this PiServer.
It is important to note here that the traditional ‘pi’ login name is not automatically included in the PiServer clients, so if you want it, you have to add it here. If you choose to do that, then please, please, please don’t add it with the traditional default password. Please?
It is also important to know that the root login is automatically defined for the clients, so you don’t need to add that here.
After entering at least one login name and password, continue to the next screen where you can choose what operating system the PiServer will provide to the clients. You will see that both Raspbian (with PIXEL) and Raspbian Lite are listed, but in this ‘first-run’ screen you can only choose one of the two, and it will be provided to all the clients. Don’t worry, you can change this later so that different clients get different operating systems if you want.
The operating systems to be provided by PiServer have to be prepared and packaged in a special way. Even though the lower part of this window gives you the possibility to specify a local file or a URL, you can not just use a previously downloaded Raspbian (or NOOBS) image, and you can not just enter a URL which points to one of the standard images.
When you continue to the next screen PiServer will first perform the local network utility configuration (LDAP, NFS, DHCP, and such), then it will download whichever Raspbian version you selected for installation.
Depending on which version you chose, and how fast your internet connection is, the download can take anywhere from five minutes to a pretty long time, so be patient. The good news is that this is a one-time download (for each different Raspbian version), so you won’t have to sit through it every time you start PiServer.
When the download is complete, the Finished screen will be displayed. Click on Close and the first-run window will go away, and a normal PiServer window will open.
What the first-run process fails to mention at this point is that by this time your Pi 3 clients, which you powered on a while ago so that they would be added to the Client list, have timed out and are no longer trying to PXE boot. So even though it says installation was successful, you need to power-cycle your clients one more time to get them to actually boot from the PiServer.
If you have a nice Ethernet hub with pretty blinking LEDs that show network activity, you will be able to see what happens as they boot (or try to boot…). About five seconds after you power on the client, the Ethernet link should come up. Another five seconds or so after that, you should see the LED blink when the client tries to PXE boot. If it then continues to blink, the client is coming up and if you have a display connected you should see the client boot sequence. But if the network LED blinks once or twice and then just stops, and the client still doesn’t boot, there is one more configuration change that you need to make. Read on.
Someone on the local network has to be responsible for assigning IP addresses to the clients when they boot. By default the PiServer is configured to act as a proxy DHCP server, which means that some other system on the local network is responsible for assigning IP addresses on demand. This would be typical if your PiServer and clients were just one part of a larger lab or educational network, for example.
If that fits your case, then when you power-cycle the clients they will boot, and the world is a wonderful place! But if you are using a local hub, like I am, and the PiServer and its clients are the only things connected, then the PiServer has to be configured to assign IP addresses to the clients when they boot. Go to the Settings screen of the PiServer, and select Act as a standalone DHCP server, and then click Save.
Once the DHCP configuration is correct, the clients should boot from the PiServer. Hooray! But what if you don’t want all of the clients to run the same Raspbian image?
If you would like to have both versions of Raspbian (PIXEL and Lite) available, you can go to the PiServer Software screen and add the one which you did not choose in the first-run. It will then be downloaded and added to the available list. The PiServer blog post mentions that while Raspbian is the only operating system available right now, they are hopeful that others will be added in the future.
After adding the other Raspbian distribution, you can go to the PiServer Clients window and modify whatever client(s) you want to use it. There is one other very nice touch here, you can add a description for each client. That certainly beats having to try to remember which one is which by MAC addresses!
Finally, I would like to add just a couple of technical notes and comments about things I have noticed while getting PiServer installed and running. The implementation of PiServer functionality is actually just a very clever use of some existing capabilities, and understanding that can help you get the most out of your PiServer setup.
The client’s root filesystem is an NFS mount of /var/lib/piserver/os/[name] from the PiServer. This means that every client will get the same root filesystem, and thus the same configuration. This is the reason why the blog post says that the clients must have the same keyboard layout as the server — but in fact that is not really true. If you edit the keyboard configuration file in the PiServer hierarchy (/var/lib/piserver/os/[name]/etc/default/keyboard) you can set it to a different layout — but of course all clients booting from that image would then get the new layout.
The users’ home directory on any client is an NFS mount of /home/[user] from the PiServer. This means that a user can log in on any client and will still get the same home directory, and that the content of the home directory will be preserved across reboots of the client.
Because the client filesystems are NFS mounts of portions of the PiServer filesystem, the amount of disk space available to the clients is in fact the amount available on the PiServer. So when you install the PiServer system, make sure you give it plenty of disk space. At the very least you will need enough space for the operating system images (about 4GB for Raspbian with PIXEL, and about 1GB for Raspbian Lite), but that only gets you to the point where you can boot the clients. You then need to make sure that the PiServer /home has enough space for all the clients’ users and their files.
User accounts created through the PiServer utility are not members of the sudo group, so they do not have root access. Whew.
Dynamic configuration of peripherals is not preserved across client reboots. The specific case where this got me was my Bluetooth keyboard and mouse, but it is also going to be true of things like network printers.
Additional hardware which requires special configuration and support from the operating system will not work on the client systems. I ran into this problem with the Element14 Pi Desktop Case, which includes a Power/Clock module. Support for this module requires additional software to be installed in the operating system, and that is not included in the client boot image.
I doubt that this would be much of a problem in an educational environment, where the clients are likely to be pretty basic. But I can imagine that in an industrial installation, where the clients might have things like scanners, badge readers or other peripherals connected, it could be an issue.
So, that’s it for now. My PiServer is up and running, and I have two Pi 3 clients booting from it. One boots Raspbian PIXEL and the other boots Raspbian Lite. Very cool.
The Pi-Desktop Kit add-on board includes a connection for an mSATA SSD drive. I am going to look at adding one, and using it for simple disk storage expansion and for booting the Raspberry Pi.
The latest release of this excellent security, forensic, and penetration testing Linux distribution is everything I have come to expect from the software and more, with both PC (32 and 64 bit) and Raspberry Pi images.
Los Alamos National Lab finds its answer to ‘exascale’ software development in the tiny Raspberry Pi.
The pi-top laptop has a sliding keyboard and runs off Raspberry Pi.
The new Asus Tinker Board S is broadly similar in spec to the original board, but adds 16GB of eMMC storage, which Asus promises will boost performance.