Links:
CloneDeploy is one of the more robust pieces of software I’ve used, but quite legacy in some areas.
There are some oddities and unexplained things, including:
- Where image definition data is exported TO, when you choose to export them… (I had to do some ’locate’ and ‘grep’ pipe magic to find out where it was exporting them to). If you access the website and click to export the data, it doesn’t send it through your browser as a download, it writes to a location on the server’s drive. Why?! Whatever…
- Images compress in gzip by default, and not pgzip. Compressing and decompression is SINGLE THREADED! YUCK! Use lz4. It encodes slower but decompression is multithreaded.
Nitpick Issues:
- Included PXE image loads the kernel and bootable via TFTP with UEFI PXE. I had to compile a custom version of PXE and copy those files to the root of the apache server. TFTP is extremely inefficient and slow. Via HTTP it downloads the image instantly. Why didn’t they include PXE binaries that include HTTP, and chain to the TFTP server so that the SysAdmin can dynamically modify the files in one place, instead of recompiling the PXE image? Probably for simplicity, but still…
- Built-In cluster system is not well-explained, and synchronizations are not automatic. If they are, I am suffering a skill issue. I made my own set of cron scripts using rsync to establish connections between the cluster primary and secondary, and synchronize the image files. However, image information and schema are not transferred, and must be done by hand for now. At that point I would rather have a monolithic CD server with 10Gbit networking at the top of the network topology.
Primary Issues:
- 6 years out of date. Definitely do not run this as an endpoint manager for a corporate office. Good as a simple internal deployment scheme.
- Binaries in the bootable image are out of date; they work on any machine imaginable, but the included SMART binary, for example, has difficulties reading the latest NVMe devices. The image is not documented in how it was crafted, to my knowledge.
Strengths:
- UI is excellent. The bar for FOSS deployment systems is extremely low. FOG which is much newer has an absolutely baffling UI, while CloneDeploy is far easier to comprehend. FOG devs should be ashamed.
- Computer management list. You can register computers via MAC address to CloneDeploy and assign them a name, an image to upload/download, etc.
- Built-In client scripting capability. You can modify the Bash scripts that the clients automatically download. Using that functionality, I created some basic drive testing systems via SMART and DD that assess system drive health and performance, and then sends those files to a logging server. Excellent.
- I hate the phrase “It just works,” (because things rarely just work the way people think they do), but CD is very stable and predictable. It might be lacking security features and is potentially riddled with exploits because very few eyes are upon it, but once you get it operating, it STAYS working.
The Successor to CloneDeploy:
- Officially, the developer released TheOpenEM. But:
- It is for Windows only. You need to use Windows Server or else it suffers from issues regarding skill and maximum TCP connections, according to their website. Instead of battling issues with configs and things that are sane and expected, I needed to keep asking myself “Is Windows the culprit here? What am I doing wrong? No, I’m not wrong, they are!” I eventually gave up because my time is valuable, and I already have a working product in my environment.
Final Verdict:
- Excellent tool for small, relatively simple deployment environments. Easy mode with enough flexibility to be useful in the long-run. Avoid use in environments that require security.