Removal of cmtool.sh about debian

[annawake]

Sure. We've come up with a simpler way for users to inject custom functionality in these templates as boxes are built - the custom-script.sh. This is a seam where you can do things like install CM tools, if that's what you want to do.

Boxcutter never published boxes with CM tools baked in, we never ran builds with cmtools.sh, so whatever was in cmtools.sh was always poorly vetted, and oftentimes did not work.

Further, most CM tools these days are designed with a system to dynamically inject/bootstrap the CM tool into an environment, so you always have the latest version, which is a much better approach than trying to bake a version of the tool into an image. The philosophy behind the images has always been that they are JEOS images "Just Enough OS" for a configuration management tool. It's just that in the past "just enough" usually also meant the CM tool itself as many CM systems didn't have great ways to bootstrap themselves. Now it seems like CM installers have evolved and matured that's not needed so much.

That being said, you can still do what you used to do via custom-script.sh, should you want to bake in a CM tool.

[mafrosis]

Thanks for the explanation. I'm probably one of the few people who uses the saltstack part of cmtool.sh, and I've been running my own patched version from my fork for a while. I'll move that into custom-script.sh and update to master.

Thanks for your work on this project!