This article is a continuation of Part 1. Raspberry PI As many people make trial and error toward becoming a diskless client, the content is about the software, PiServer, which is always a hit, and the construction of an alternative system. If you are facing the problem that your Raspberry Pi is not recognized by PiServer, please see Part 1.
Since the Raspberry Pi was originally made for educational purposes, students used a large number of discless Raspberry Pis in the classroom. It seems that the teacher was created assuming an environment where the same screen is viewed on a PC.
--The kernel is Debian on x86_64. --glibc is i386 (why ???) ――It's exactly the same desktop environment as Raspberry Pi --There is an item called "PiServer Settings" in the "Settings" menu. I guess this is PiServer.
When I checked the source published in GitHub piserver repository, I found the C ++ source of the management GUI and various bash scripts. The GUI part could be compiled and executed on the x86_64 version of ArchLinux, so it turned out that there was no need to use Raspberry PI Desktop. What's more, once you port the bash script published in the PiServer repository, all the remaining functions can be realized with just dnsmasq + OpenLDAP + qemu-user-static.
--I don't need a GUI that just rewrites the dnsmasq configuration file. --PiServer is shit (final decision) after all.
Just the other day, the official Raspberry announced that Raspberry PI OS will be 64-bit, and we will manage the 64-bit distribution. If you can't PiServer, you need to give up. So let's think about a method to build an alternative system.
Therefore, in order to realize the above procedure, it is necessary to prepare at least the following environment, and a server with these three functions is sometimes called a "PXE server".
Originally, diskless clients are usually used for applications where many users use the same environment, such as terminals for students in educational settings and terminals for data entry business.
However, since the final purpose of this article is to build a personal distributed processing environment, the contents related to the following three servers will not be described. By the way, DNS will be necessary if the number of clients exceeds 100, but if the number of clients is less than 10, name resolution by the / etc / hosts file is sufficient, and this file can be shared on the NFS server. You don't need it. By the way, in a distributed environment that only you use, you don't need an authentication server, and you don't need it because you can share the / etc / passwd file.
Building a DHCP, tftp, or DNS server with individual software such as dhcpd, atftpd, or bind is cumbersome and time consuming. That's where the software dnsmasq, which is also used by PiServer, comes into play. Originally, this software started development as a DNS cache server, but it is no exaggeration to say that it is a software specialized for building a PXE server because it has incorporated the functions of the tftp server and DHCP server before I knew it. Let's do it. Naturally, I will use this software. However, do not use DNS, which is the original purpose.
From now on, the x86_64 machine running dnsmasq will be referred to as the "PXE server".
In PiServer, all the functions were packed in order to sell "complete with one PC", but considering safety, it is better to separate the NFS server function into another machine. This is because if the PXE server doubles as an NFS server, the following can happen:
If you already have a file server that supports NFS, it will be a more robust system because it will be redundant with RAID, GlusterFS, etc. There is no problem if the boot related files distributed by tftp are also NFS mounted from the PXE server. However, I think it is better to use a machine with fast disk access.
Hereafter, a machine with NFS function will be referred to as an "NFS server".
[^ Reason]: If you have an existing file server, it will be redundant with RAID, GlusterFS, etc.
You can do this manually. However, it may be possible to automate it by modifying the bash script for OS import published on GitHub of PiServer.
Diskless clients mount the root file system read-only, so you cannot update the OS from the client side. You will need to update the OS on the PXE or NFS server side. However, the environment you are trying to build this time should be an ARM on the client side and an x86_64 machine on the server side. That's where you need an emulator.
This method is also implemented in PiServer, but using the emulator qemu (user mode static), binfmt support, and chroot, you can easily control the OS distributed to clients. You can read more about it here [http://blog.kmckk.com/archives/2342452.html).
For Debian, you just need to install the qemu-user-static package, and for ArchLinux, you need to compile it yourself with AUR.
If you have 10 or less Raspberry Pis, it's not a big deal to check them individually by the method described in My previous article.
Since it is a group of clients that only I use, I do not need to manage it, so I will omit it.
--User management of / etc / passwd + / etc / shadow with NFS share --Dnqmasq's DHCP function resolves + / etc / hosts, which allocates a fixed IP to each Raspberry Pi, with an NFS share
All will be solved by doing.
The author decides to build such an environment. The PXE server, NFS server, and controller may be combined into one unit, or the subnets may not be separated.
So that's it for this time. Next time I would like to actually install and configure dnsmasq on an x86_64 Linux machine.