As we dive into the final quarter of 2019 the Linux community typically begins to reflect on the year behind, and plans for the coming holiday season quickly take priority. Don’t be too hasty though, as we still have much to look forward to with soon-to-be-released updates to the healthy Linux ecosystem.
Most recently, we saw the highly anticipated release of CentOS 8. If you’re interested in enterprise Linux we recommend you check it out. I write from a personal perspective when I say I’m no fan of CentOS. But I accept that it is a much respected distribution and many servers run CentOS. So hey, if I’m alone in my personal despise of CentOS, then that’s fine with me. When the conversation moves to Ubuntu 19.10 and IBM/Fedora 31 – both due for public release in the coming weeks – then you have my attention. Looking forward to the first half of 2020 should see the release of OpenSUSE Leap 15.2. I’m excited for all of these upcoming releases and you should be too.
Right at this minute, I’m still coming down from the high experienced over the last few weeks after working on a new experimental network platform which is being developed as part of a joint collaboration project between several different technology players. While we are unable to disclose the complete specifications of the prototype platform on OSRadar, we can disclose that we have been provided access to a working prototype of the network platform. We can also disclose that the most recent stage of its development has been specifically designed to accommodate the inclusion of the upcoming IBM/Fedora 31 (F31) Linux operating system into its overall framework.
The prototype platform is referred to as LinkNet, but it remains unclear whether this name will be retained or whether this is simply a code name for the platform during its development. LinkNet accommodates F31 in the unique form of what is being called a “snap-in module”. We understand it isn’t crucial that F31 is the operating system required for snap-in modules to function. In fact, LinkNet will accommodate all GNU/Linux and BSD-based systems as snap-in modules, which effectively connect into the LinkNet framework to perform various functions as required. Providing the snap-in module is fit for purpose and meets the strict configuration requirements to remain compatible with the LinkNet framework, there’s nothing that constrains the snap-in modules to any specific operating system, really. Instead, LinkNet is attempting to develop a network connected environment with a specific specifications protocol which can be expanded or reduced on a needed basis, while technically having no performance hit to the overall network performance or the services LinkNet provides.
There is redundancy measures implemented into the network platform’s design which attempts to reduce any possibility of downtime occurring, even if a server goes down. Currently, the redundancy model is very flaky and actually flawed. It’s ineffective and really doesn’t take much effort to pull a service off LinkNet and have the redundancy protocols fail. Still, we must respect this is a prototype platform and in its infancy. As development progresses and LinkNet becomes more mature, redundancy protocols will be improved. It is the ultimate aim to not just reduce the possibility of downtime, but to eradicate any possibility of it occurring. But realistically, with networked computing there is always the possibility of downtime and any effort to achieve 100% uptime is pretty ambitious. Recent testing which has included live patching of running systems resulted in feedback which has been extremely positive. Controlled testing proved that systems can be updated and serviced on-the-fly without interruption to the service the snap-in module provides to LinkNet, even with current premature implementation of the redundancy protocols.
As LinkNet is being developed, updates to all the connected snap-in modules are constantly being manually applied. The demonstration snap-in module was running the latest F31 Beta build and utilizes the XFCE desktop environment. It connects using dual ethernet adapters which were specifically pre-configured prior to demonstration for the specific network access specifications required to connect to LinkNet. It must be understood that LinkNet is a prototype network platform by way of function and connectivity, and not a new type of technology or hardware. Everything that makes up LinkNet makes use of existing technology. It could described as kind of like a mini-internet, isolated from the main internet. You might be thinking, ‘well isn’t that just what you call an intranet?’. Well that’s a fair question, and the answer is yes and no. Intranets have a specific purpose and are limited by design. LinkNet is limited, yes, but only limited by the way it is isolated from the internet at present. There is actually a decent selection of content available on the network which is provided by parties associated with LinkNet development and testing. But as it is isolated from the internet, accessibility is limited and operates as kind of an underground network for a privileged few. It functions different to a regular internet too, as all content appears to be delivered by one server on one page, with additional servers handling the connectivity and access to the LinkNet core. To briefly explain, Nginx is used as a reverse proxy pulling from an Apache server which shares content with the core server – a mainframe I guess you could call it. However, the LinkNet core is delivered by a different method and not traditional server software like Nginx or Apache. Instead, it relies on a custom in-house developed DNS software package and custom web server technology. Also, the LinkNet core operates from a multi-directory, multi-tier filesystem structure on a dedicated array. In its current form, there are ten filesystem tiers and three arrays present on the LinkNet core server. Two of the three arrays were marked as inactive, with only one array delivering LinkNet at present. Extra arrays can be activated when required and will eventually play a crucial role in the design of the redundancy protocols planned to ensure LinkNet never crashes. If LinkNet ever comes to fruition in its intended form, then the potential of purpose appears limitless, yet limited by its connectivity cushion.
The F31 snap-in module was configured for the sole purpose of a network file server to be accessed by all other systems on LinkNet. Think NAS! Sort of like a community accessible file server available for use by anyone. Sounds like a security nightmare, really. But security protocols are also in development. The flexibility of having a network-wide file server, or chain of file servers in the form of additional snap-in modules, accessible to the entire network is really interesting to think about. But how this could be possibly be secured properly, protect data privacy and data loss prevention are all challenges that will have to be dealt with by LinkNet. At the moment, we cannot provide any specific security details and are not familiar with the precise security settings adopted on the F31 snap-in module. Final security protocols and related elements for any future LinkNet platform have not yet been finalized and may change as development progresses and the network is expanded.
We had very open access to the F31 system and had a poke around at some of the system’s configuration files and other obvious stuff. We discovered that the snap-in module is running three active hard disks. The first hard disk is a SSD while the two remaining drives were mechanical in nature and configured in a RAID0 array. We suspect this is to draw maximum performance for its intended role of a file server. The first disk was the main system drive mounted as / with the two-striped disks mounted as /home, which is where the file server network access is linked to. While we feel that RAID0 is good for fast disk performance it does not cater for data backup, which is a challenge LinkNet will be forced to deal with eventually. Or, perhaps LinkNet leaves the user to pick up the responsibility of backing up their data, placing it onto a personal hard disk or system not connected to LinkNet. That’s all just a presumption at this stage though.
The twin-ethernet setup is a good option, but we still have mixed feelings on the configuration of separate IP address allocation to each adapter. We believe it would have been better configured in a twin-ethernet bonded configuration with a single shared IP address to maximize network throughput of large file transfers across the network to the RAID0 array. Still, we didn’t experience any network lag during our file transfers to the snap-in module despite it being limited to the use of only one ethernet adapter, so we shouldn’t be complaining. Perhaps there’s a valid reason for the chosen configuration. That’s very likely. Also, some server-grade network chipsets would be a nice addition instead of the consumer desktop-grade chipsets it utilizes.
The F31 Beta build that was installed on the snap-in module is built on top of a Linux 5.3.0 kernel and Bash 5.0.7. As mentioned before, it comes with the XFCE desktop environment and includes the latest version of the popular minimalist graphical environment, 4.14. The latest update to XFCE has been highly anticipated for some time by many XFCE loyalists, including us. However, there really isn’t much to brag about. At least not with the aesthetics anyway. To the naked eye, it simply looks identical to its predecessor and most of the changes and improvements are under the hood and just not visible. The F31 build installed on the snap-in module appeared to be a pretty standard instance and performed well when we did have to dig into the graphical environment. But to be fair, that was not often as this system was issued a specific responsibility of performing as a snap-in module file server. So the graphical desktop environment didn’t play a major part in our usage. Still, it was a good opportunity to get a good look at how F31 performs prior to its official release.
The snap-in module was tweaked with a pre-configured application menu, background and icons. The changes are very IBM-esque and really seem to embrace the reemergence of IBM as a significant contributor to the Linux ecosystem, largely thanks to its acquisition of Red Hat, which in-turn funds the development of the Fedora Project. IBM nor Red Hat have anything to do with the LinkNet project, but we like the IBM look and feel of this particular module.
Despite having access to the LinkNet project, we’re going to refrain from making any early verdict on IBM/Fedora 31 considering it’s still in Beta and not recommended for production use yet. Still, from what we have been able to experience with how LinkNet is being developed with F31 being considered as a supported platform for its snap-in module specification, early indications tell us it’s an impressive release.
Information on proposed development features for LinkNet is limited and the project has a kind of organic feel to it. Its development is slow, but also flows kind of naturally rather than be forced by deadlines and milestones. We understand a custom terminal console will eventually be rolled out onto LinkNet connected systems, which will create a kind of unity between all systems irrespective of the underlying operating system. We still have no time-frame for any final platform or any confirmation that this project will ever become a reality outside of the labs. Still, we feel extremely lucky to be able to take an early look at the potential of F31 in a working environment. If anything, that’s what we’ve enjoyed most.