Git Repository via Apache II

I made a previous post about serving a git repository via Apache, and the method of delivery was WebDAV. Fast forward a couple of years and I find myself trying to use the same setup on our lab machine. In the end, it doesn’t work: in spite of everything, a git push will always fail due to some error locking a refs file. I ended up giving up on WebDAV and going with git-http-backend.

The setup is essentially identical to the first example here. A vanilla apache 2.4 install will have the modules (mod_cgi, mod_alias, mod_env) available, so it’s just a matter of uncommenting those in httpd.conf. I only had to change the ScriptAlias line to point git to the git-http-backend command in the local install of git. We already had a basic auth file that we use with the mod_dav_svn setup which we reused to protect access to the git repositories. Everything just worked and we didn’t need to rebuild apache.

I kind of regret spending so much time compiling Apache 2.4 thinking that the error had to do with running Apache 2.2, but then again it was a nice exercise in building a bunch of interlinked libraries on Centos. One thing I learned is that in the typical configure-make-make install cycle, ./configure --prefix=PREFIX is really useful to do. I always felt terrible about sending everything to /usr/local because (1) it gets pretty messy, and (2) you might not have permission to do it. But having picked up the CMake convention of always building projects with an out-of-source build, this makes a lot of sense to do a lot of the time, especially if you’re building stuff just to try out. I ended up not needing most of the stuff I built and now I don’t have to worry about cleaning up /usr/local.

Server build notes

The past week’s been pretty fun, configuring the web server for optimized request handling and more maintainable source code files. I’ll talk about the latter, how we made the server go to work to help us maintain our stuff. Two tools that we got compiled on the server are Sass and XHP.

Sass comes with the haml Rubygem, and it’s basically an extension to CSS, giving it things like variables, mixins – which are kinda like macros, and ability to generate nicely formatted CSS or compressed CSS for efficient use of bandwidth. Sass can then be set as a daemon to watch a project directory, compiling Sassy CSS files (as they call it) into standard CSS files whenever a change is made. Installation was as simple as gem install haml, assuming Ruby is set up on your server. It wasn’t on ours initially, but just clicking into Rubygems on the CPanel triggered the server to set it up automatically.

XHP took a little more work to get (and still doesn’t seem to work 100% – one post-build unit test failed… however, PHP was able to load the module and we’re making good use of it). First of all, the site specifies some prerequisite software – treat the versions as minimum requirements. re2c was one necessary package that wasn’t readily available in the required version (0.13.5 – we had 0.13.4 on the server but XHP accepts no less) as an RPM. So I had to hit up Sourceforge for the source RPM and compile it. This wasn’t too bad. The workflow is basically as follows:

1. rpm -ivv <name of source rpm>. This seems to stage the resources in an area for building and extracts a specfile, which is a Makefile of sorts. The -vv option will trigger verbose output, which should tell you where the specfile is.
2. rpmbuild -bb <name of the specfile>. Run this after you cd to the directory where the specfile is. This will start the build process, which hopefully runs without a hitch and produces an RPM at a secondary location.
3. rpm -i <name of compiled rpm>. The installed software should be available immediately.

Compiling was easy, but the post-build unit test refused to run because PHP had safe mode enabled. Apparently, it was compiled into the PHP on the server, so a rebuild was necessary. CPanel has a nice point-and-click configuration for this as well, though Apache needs to be rebuilt as a part of this as well. After that, do a make install and add extension=xhp.so on a new line in your php.ini. Your site should be good to go. Also, one useful configuration option to have is xhp.idx_expr=1, which enables you to index arrays returned from function evaluations right away.

This stuff all took a while to figure out, but in the end, we added two awesome tools to our disposal, which keeps the spirits high and the developers developing!

FreeDOS+Qemu+MASM Setup for Linux

I’m attending an Intro to Computer Systems class which is taught using the DOS debugger and M$ assembler MASM… *gag*. I should’ve checked before I put down the money on the textbook, which is also based on MASM. I don’t know much about assembly – it’s been like black magic to me for a long time – but I know that I could learn much more if we were using open source tools like NASM and GDB. Anyways, getting the fundamentals from this class will be good enough to allow me to jump towards other directions.

For now I’ll have to follow along in class. The assembler and linker are provided by the professor, but I have the problem of not having (and not willing to have) Windows/DOS installed. I struggled on my own for a while before a friendly guy who knows his stuff suggested a solution with FreeDOS and Qemu. The beauty is that you can install FreeDOS on a disk image that you can mount and access from Linux. Here’s what I did.

• Download a copy of FreeDOS. There is a barebones version and a live CD version, the latter which I used. But all that’s needed is the debugger, which should be in both. I went with the live CD version because it also includes vim, which will make it very convenient 🙂
• Install Qemu. Under Gentoo, I had to emerge gcc 3 because Qemu needs to be built with that. Also, I needed to add the sdl use flag so that graphical output is actually enabled (duh). Here’s what I did:

# install gcc 3 alongside gcc 4
emerge -av =sys-devel/gcc-3.4.6-r2

# flagedit's a nice app to set/unset use flags. just emerge flagedit
flagedit app-emulation/qemu-softmmu +sdl

# this should be automatic, but I had to manually switch to gcc 3 before emerging qemu
# this command just lists the available gcc's. you pick one from the list
gcc-config -l

# at last build qemu
emerge -av qemu

# don't forget to set gcc back to gcc 4 or weird things happen with the system
gcc-config -l

• Create a disk image to be the FreeDOS hard drive. This command does the trick:

# creates a 128MB image to hold our FreeDOS install
dd if=/dev/zero of=freedos.img bs=1024 count=128000

• Run Qemu to install FreeDOS onto our disk image. This command will boot from CD, where I set up the drive and installed FreeDOS.

qemu -cdrom /path/to/fdfullcd.iso -hda /path/to/freedos.img -boot d

• Once FreeDOS is set up, I mount the freshly baked disk image as a loopback device on my Linux filesystem so that I can transfer the assembly tools over. This command will take care of mounting the FreeDOS disk image:

# notice the offset option. Though it's FreeDOS, it isn't typical vfat so we need this magic number
mount -o loop,offset=32256,user,rw,umask=000 /path/to/freedos.img /path/to/mount

• At this point you can transfer things over, then unmount and boot up FreeDOS via Qemu again. Setting up the assembly tools is as simple as adding them to the path. Do it DOS style:

set PATH=%PATH%;C:\path\to\masm\dir

Then you’re good to go!

Capturing output might still be an issue. I will resort to piping in scripts and capturing output in files that I can collect later on. I don’t know if debug is like GDB where you can dump to files?

My benefactor also mentions concurrently mounting the disk image on Linux and using it with Qemu running. This sounds dangerous yet interesting. I tried it but got I/O errors trying to access from Linux a folder I was making changes in in FreeDOS.

At any rate, I’m going to have a lot of fun learning about assembly!