Assembling the media center – part 3
Option 4.1: Synology? Crapology!
Synology’s operating system, called DiskStation Manager (DSM for short), can be tried out as an online demo or installed in a virtual machine. And since DSM is developed under the GPL, there is a fork of it called Xpenology. Thus, you can take old hardware, write a bootloader to a flash drive that will make DSM think that it is on valid equipment and get an excellent and functional NAS with constant firmware updates. Moreover, you can expand the number of screws as much as you like, limited only by the capacity of the case and the number of SATA connectors on the board based on a coolerless processor.
The problem with this approach is that transcoding will not work on the “left” hardware without the correct serial numbers. This is the first. People are looking for real serial numbers on photos of real NAS on Ebay and prescribing them in configs, but this is already completely unethical. Secondly, when upgrading DSM, it is easy to catch a situation when Synology managed to cut out some drivers from the firmware and your system stupidly does not start after the upgrade. Rolling back is already more difficult, because DSM is placed in a small partition on each disk and has time to update, making changes to the bootloader along the way. Then dances begin in the substitution of drivers on a flash drive and other gaiety.
In general, a real XPE newcomer has an unnecessary low-capacity hard drive in the household, which he uses as a test drive. When a new update is released, such a hardened user disables the main screws and leaves only the test one in the system. Along the way, makes a copy of the bootable flash drive. Then the update rolls and waits with bated breath for the download. If everything is OK, then the main screws are connected and the entire system is migrated. If not, the user tries to update the drivers with a pack on the bootloader. If it didn’t work out here either, he cuts off the test screw and connects the main screws by installing a copy of the old bootable flash drive (there is also not just a copy, but you need to prescribe the ID of a specific flash drive). The test screw is carried away to the main system, where it is mercilessly formatted.
As you understand, sooner or later you can get a situation where an update comes out with the closure of critical vulnerabilities, but it is impossible to roll the patch. Therefore, wealthy experimenters, in the end, just buy a new or used Synology and sleep peacefully.
Option 4.2: Have a question? opensource!
Since the main advantage of Synology is beauty and a lot of modules, which are especially unnecessary for many people, it is logical to put something from OpenSource on a freshly assembled NAS. Everything is fine here with updates, but when you buy hardware, you pay only for hardware. There are a lot of articles on Habré about setting up FreeNas, Nas4Free, OpenMediaVault and a few other lesser-known assemblies. All of them more or less support the ability to upload data via DLNA, and someone even allows you to put Flex on it.
An example of an OpenMediaVault window. Not as pretty as Synology or Qnap, but still functional
In any case, the choice of a specific assembly is determined rather by the requirements for the file system (for example, ZFS) and the requirements for backups and other matters. So the creation of a media server here is rather secondary.
By the way, since a modern NAS is the same server running Linux, it is logical to set up synchronization / backup with your server hosted on RuVDS. for example, through the same RSync. Such a link will never be superfluous.