README.md | 6 years ago | ||
brewenvs | 6 years ago | ||
makefile | 6 years ago |
This is automation support for the linuxbrew-based tools procedure documented at:
https://www.tundraware.com/TechnicalNotes/Divorce-Your-Linux-Admin
This makefile
handles both the bootstrapping and then the full release of a custom linuxbrew based toolset, installed at any location you wish (so long as you have write permission there).
Before doing anything, edit the variables as the top of the makefile
to reflect where you want the built tarballs to be exported, where you intend to install the tools, and what set of tools you want installed.
Both the bootstrap and full build process create tarballs and rename the tools directory with a version stamp in the form, YYYMMDD
. The idea is to allow multiple verisons of your toolsets to exist under ${INSTALLDIR}
. You simply create a symlink in that directory named ${TOOLS}
to point to the version you want. This makes certain automation use cases with tsshbatch
or ansible
somewhat simpler.
Log into your build machine, VM, ordocker
image.
Make sure you have write permission to the installation directory.
Make sure the native OS compiler tools are installed.
Get the linuxbrew image:
make getbrew
Build the bootstrap image:
make bootstrap-build
Build a release tarball and export it:
make bootstrap-release
Cleanup:
make clean
Log into your build machine, VM, ordocker
image. Make sure this machine does not have native OS compilers and development tools installed and/or in ${PATH}
! We want to use only the compiler and tools created in the previous step. Docker
containers are handy here: One for the bootstrap build, another for the self compiling full tools build.
However, there are a few things that are required in the OS load, because of boneheaded assumptions made by some open source packages about where things live. So:
`sudo yum -y install autoconf automake perl' # Or whatever package management system you use
Un-tar the bootstrap tarball created above into the proper location. Recall that this was saved with a date revision stamp. So, before proceeding, we have to:
cd ${INSTALLDIR} && mv -v ${TOOLS}-YYYYMMDD ${TOOLS}
Setup the required environment variables:
. brewenv
Make sure ${MYTOOLS}
has all the packages you want listed.
Build the full tool set using the bootstrapped compiler we just built:
make full-build
Export it for installation elsewhere:
make full-release
Cleanup:
make clean
We've just created a tarball that has all the tools we want precompiled and ready for distribution. We just untar the full tools tarball onto any other machine. The only restrictions are:
We must un-tar so that the tools directory ends up in the same location in the filesystem as where it was built. The binaries created above make assumptions about where to find their libraries and other dependencies. So, if we built the tools under:
/opt/mydir/tools
Every installation on other machines must also install them there (and be added to $(PATH}
as described in brewenv
).
Recall that this procedure actually creates the tools directory as:
/opt/mydir/tools-YYYYMMDD
.
In this example, you could either symlink tools
to that directory or just rename the directory accordingly.
The build- and target machines must have reasonably close kernel versions. That's because the bootstrap phase makes use of native OS header files that are kernel-dependent. If, say, you try to build this on a CentOS 7 instance, but then attempt to deploy to CentOS 5, expect problems. Always build your deploy image on an OS that is substantially the same as your targets. Again, docker
is your friend here.
brewenv
FileThe brewenv
file documents the environment variables that need to be set in order to access your installed binaries and support files. You may find this useful when doing the builds. You certainly will want these variables set when running a final installation of your tools.
Just be sure to edit it and change TOOLSDIR="/opt/TundraWare/tools"
to wherever your tools installation actually lives.