all posts tagged make
Git submodules are actually a very beautiful thing. You might prefer the word powerful or elegant, but that’s not the point. The downside is that they are sometimes misused, so as always, use with care. I’ve used them in projects like puppet-gluster, oh-my-vagrant, and others. If you’re not familiar with them, do a bit of reading and come back later, I’ll wait.
I recently did some work packaging Oh-My-Vagrant as RPM’s. My primary goal was to make sure the entire process was automatic, as I have no patience for manually building RPM’s. Any good packager knows that the pre-requisite for building a SRPM is a source tarball, and I wanted to build those automatically too.
Simply running a
tar -cf on my source directory wouldn’t work, because I only want to include files that are stored in git. Thankfully, git comes with a tool called
git archive, which does exactly that! No scary tar commands required:
Nobody likes tar
Here’s how you might run it:
$ git archive --prefix=some-project/ -o output.tar.bz2 HEAD
--prefix argument prepends a string prefix onto every file in the archive. Therefore, if you’d like the root directory to be named
some-project, then you prepend that string with a trailing slash, and you’ll have everything nested inside a directory!
-o flag predictably picks the output file and format. Using
.tar.bz2 is quite common.
HEAD portion at the end specifies which git tree to pull the files from. I usually specify a git tag here, but you can specify a commit id if you prefer.
Obligatory, “make this article more interesting” meme image.
This is all well and good, but unfortunately, when I open my newly created archive, it is notably missing my git submodules! It would probably make sense for there to be an upstream option so that a
--recursive flag would do this magic for you, but unfortunately it doesn’t exist yet.
There are a few scripts floating around that can do this, but I wanted something small, and without any real dependencies, that I can embed in my project
Makefile, so that it’s all self-contained.
Here’s what that looks like:
@echo Running git archive...
# use HEAD if tag doesn't exist yet, so that development is easier...
git archive --prefix=oh-my-vagrant-$(VERSION)/ -o $(SOURCE) $(VERSION) 2> /dev/null || (echo 'Warning: $(VERSION) does not exist.' && git archive --prefix=oh-my-vagrant-$(VERSION)/ -o $(SOURCE) HEAD)
# TODO: if git archive had a --submodules flag this would easier!
@echo Running git archive submodules...
# i thought i would need --ignore-zeros, but it doesn't seem necessary!
p=`pwd` && (echo .; git submodule foreach) | while read entering path; do
[ "$$path" = "" ] && continue;
(cd $$path && git archive --prefix=oh-my-vagrant-$(VERSION)/$$path/ HEAD > $$p/rpmbuild/tmp.tar && tar --concatenate --file=$$p/$(SOURCE) $$p/rpmbuild/tmp.tar && rm $$p/rpmbuild/tmp.tar);
This is a bit tricky to read, so I’ll try to break it down. Remember, double dollar signs are used in
Make syntax for embedded bash code since a single dollar sign is a special
Make identifier. The
$(VERSION) variable corresponds to the version of the project I’m building, which matches a git tag that I’ve previously created.
$(SOURCE) corresponds to an output file name, ending in the
p=`pwd` && (echo .; git submodule foreach) | while read entering path; do
In this first line, we store the current working directory for use later, and then loop through the output of the
git submodule foreach command. That output normally looks something like this:
james@computer:~/code/oh-my-vagrant$ git submodule foreach
As you can see, this shows that the above
read command, eats up the Entering string, and pulls the quoted path into the second path variable. The next part of the code:
[ "$$path" = "" ] && continue;
uses bash idioms to remove the two single quotes that wrap our string, and then skip over any empty versions of the path variable in our loop. Lastly, for each submodule found, we first switch into that directory:
(cd $$path &&
Run a normal
git archive command and create a plain uncompressed tar archive in a temporary directory:
git archive --prefix=oh-my-vagrant-$(VERSION)/$$path/ HEAD > $$p/rpmbuild/tmp.tar &&
Then use the magic of tar to overlay this new tar file, on top of the source file that we’re now building up with each iteration of this loop, and then remove the temporary file.
tar --concatenate --file=$$p/$(SOURCE) $$p/rpmbuild/tmp.tar && rm $$p/rpmbuild/tmp.tar);
Finally, we end the loop:
Boom, magic! Short, concise, and without any dependencies but
Nobody should have to figure that out by themselves, and I wish it was built in to git, but until then, here’s how it’s done! Many thanks to
#git on IRC for pointing me in the right direction.
This is the commit where I landed this patch for oh-my-vagrant, if you’re curious to see this in the wild. Now that this is done, I can definitely say that it was worth the time:
Is it worth the time? In this case, it was.
With this feature merged, along with my automatic COPR builds, a simple ‘
make rpm‘, causes all of this automation to happen, and delivers a fresh build from git in a few minutes.
I hope you enjoyed this technique, and I hope you have some coding skills to get this feature upstream in git.
I needed a base image “box” for my Puppet-Gluster+Vagrant work. It would have been great if good boxes already existed, and even better if it were easy to build my own. As it turns out, I wasn’t able to satisfy either of these conditions, so I’ve had to build one myself! I’ve published all of my code, so that you can use these techniques and tools too!
Having an NIH problem is bad for your vision, and it’s best to benefit from existing tools before creating your own. I first tried using vagrant-cachier, and then veewee, and packer. Vagrant-cachier is a great tool, but it turned out not being very useful because there weren’t any base images available for download that met my needs. Veewee and packer can build those images, but they both failed in doing so for different reasons. Hopefully this situation will improve in the future.
Writing a script:
I started by hacking together a short shell script of commands for building base images. There wasn’t much programming involved as the process was fairly linear, but it was useful to figure out what needed getting done.
I decided to use the excellent
virt-builder command to put together the base image. This is exactly what it’s good at doing! To install it on Fedora 20, you can run:
$ sudo yum install libguestfs-tools
It wasn’t available in Fedora 19, but after a lot of pain, I managed to build (mostly correct?) packages. I have posted them online if you are brave (or crazy?) enough to want them.
Using the right tool:
After building a few images, I realized that a shell script was the wrong tool, and that it was time for an upgrade. What was the right tool? GNU Make! After working on this for more hours than I’m ready to admit, I present to you, a lovingly crafted virtual machine base image (“box”) builder:
Makefile itself is quite compact. It uses a few shell scripts to do some of the customization, and builds a clean image in about ten minutes. To use it, just run
At the moment, it builds x86_64, CentOS 6.5+ machines for vagrant-libvirt, but you can edit the
Makefile to build a custom image of your choosing. I’ve gone out of my way to add an
$(OUTPUT) variable to the
Makefile so that your generated files get saved in
/tmp/ or somewhere outside of your source tree.
Download the image:
If you’d like to download the image that I generated, it is being generously hosted by the Gluster community here. If you’re using the Vagrantfile from my Puppet-Gluster+Vagrant setup, then you don’t have to download it manually, this will happen automatically.
The biggest issue with the images is that SELinux gets disabled! You might be okay with this, but it’s actually quite unfortunate. It is disabled to avoid the SELinux relabelling that happens on first boot, as this overhead defeats the usefulness of a fast vagrant deployment. If you know of a way to fix this problem, please let me know!
If you’d like to see this in action, but don’t want to run it yourself, here’s an example run:
$ date && time make && date
Mon Jan 20 10:57:35 EST 2014
[ 1.0] Downloading: http://libguestfs.org/download/builder/centos-6.xz
[ 4.0] Planning how to build this image
[ 4.0] Uncompressing
[ 19.0] Resizing (using virt-resize) to expand the disk to 40.0G
[ 173.0] Opening the new disk
[ 181.0] Setting a random seed
[ 181.0] Setting root password
[ 181.0] Installing packages: screen vim-enhanced git wget file man tree nmap tcpdump htop lsof telnet mlocate bind-utils koan iftop yum-utils nc rsync nfs-utils sudo openssh-server openssh-clients
[ 212.0] Uploading: files/epel-release-6-8.noarch.rpm to /root/epel-release-6-8.noarch.rpm
[ 212.0] Uploading: files/puppetlabs-release-el-6.noarch.rpm to /root/puppetlabs-release-el-6.noarch.rpm
[ 212.0] Uploading: files/selinux to /etc/selinux/config
[ 212.0] Deleting: /.autorelabel
[ 212.0] Running: yum install -y /root/epel-release-6-8.noarch.rpm && rm -f /root/epel-release-6-8.noarch.rpm
[ 214.0] Running: yum install -y bash-completion moreutils
[ 235.0] Running: yum install -y /root/puppetlabs-release-el-6.noarch.rpm && rm -f /root/puppetlabs-release-el-6.noarch.rpm
[ 239.0] Running: yum install -y puppet
[ 254.0] Running: yum update -y
[ 375.0] Running: files/user.sh
[ 376.0] Running: files/ssh.sh
[ 376.0] Running: files/network.sh
[ 376.0] Running: files/cleanup.sh
[ 377.0] Finishing off
Output size: 40.0G
Output format: qcow2
Total usable space: 38.2G
Free space: 37.3G (97%)
Mon Jan 20 11:06:46 EST 2014
If you have any other questions, please let me know!
PS: Be careful when writing
Makefile‘s. They can be dangerous if used improperly, and in fact I once took out part of my
lib/ directory by running one. Woops!
Hope you installed and tried GlusterFS using the guide from gluster website. In this post we will cover the following topics:
- Get source from git.
- Make and install gluster from source.
Get source from git:
- Install git on your work machine using your favorite package manager. You may have to configure your git installation.
- Visit review.gluster.org and register yourself there. During the process you will have to provide ssh keys to authenticate your push and pull commands to the server. Just follow the instructions and you will be fine.
- Then we get the source!
- cd into your preferred working directory for your projects and type
git clone ssh://<UserName>@git.gluster.org/glusterfs.git glusterfs
- Congratulations! You now have the complete source code for your project.
Make and install gluster from source:
NOTE: Gluster has different default installation paths for installation from repo packages and source. If you had installed gluster previously from package manager , please uninstall before you proceed.
- Cd into the glusterfs directory where git has cloned the complete source from git server.
- Run autogen.sh present in the directory.
- Run “./configure –enable-debug” , you may get some output like this
GlusterFS configure summary
FUSE client : yes
Infiniband verbs : no
epoll IO multiplex : yes
argp-standalone : no
fusermount : no
readline : yes
georeplication : yes
Linux-AIO : yes
Enable Debug : no
systemtap : no
Block Device backend : no
We are good to go as long as you have yes against FUSE Client and readline for our current exploration. We will come back and look later at what other components do.
- Lets build! You can call make with CFLAG option O0 to get a debug build.
make CFLAG='-g -O0'
- If previous command completed successfully, that means you now have binaries under the same directory. Now lets install gluster in the right location.
make CFLAG=’-g -O0′ install
Now you have gluster installed on your machine. In the next post we will look at creating volumes in gluster and try to make guesses about architecture of gluster while we observe its behavior.
Assignment: Before we do that, I want you to make a list of all the files that were installed to different paths of the system when we installed gluster.