Bootstrapping a VSTS Linux build agent for Docker containers

1. Create an Ubuntu 17.04 VM in Azure
2. Install dotnetcore using the instructions here.
3. Install the Docker apt-get package using the instructions here.
4. Download and run the VSTS agent Docker image and run it as a Docker container itself using the instructions here, e.g. sudo docker run -e VSTS_ACCOUNT=myvstsaccountname -e VSTS_TOKEN=abcdtokenherefromportal -e VSTS_POOL="Docker Build Agents" -e VSTS_AGENT="myagentname" -it -v /var/run/docker.sock:/var/run/docker.sock microsoft/vsts-agent

"Network is unreachable" on an embedded box

We've been working extensively with embedded boxes lately trying to migrate our platform over. One of the programs we've been trying to migrate today was a simple announcer program that sends out a UDP broadcast. On our first go, the program wouldn't work, saying that the "Network is unreachable" when doing a 'perror' after the call to 'sendto'. After much experimentation with various network binding flags, etc, which took the whole day, I went into overtime trying to figure out the problem. Eventually, I got to the point where I inspected the routing tables of the embedded system and was shocked to find .... there was no routing table entry for the default gateway, i.e. 0.0.0.0 destination IP. I'm actually kind of ashamed of how long it took me to find this, but in my defense, I was dealing with a wild mixture of systems and had done a lot of network reconfiguration with the systems and some of the stuff was handled automatically for me by my Ubuntu box, which gave me some inconsistent results at times when experimenting.  For my own future reference, here's how I solved the problem:

• Run 'route -n'
• Ensure there's an entry that looks like the following :
• Destination: 0.0.0.0 Gateway: [the desired gateway, e.g. 192.168.10.1] Genmask: 0.0.0.0 Flags: UG, Metric: 0, Ref: 0, Use: 0, Iface: eth0 (or eth2, or whatever you may have)
• If the above entry doesn't exist, add it with the following command:
• sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.10.1 dev eth0

You should now have no problems with your UDP broadcasting. If you do, well, let me know how it goes, I'd love to hear your problem and your solution.

Cross-compiling libexpat (and other libraries)

So, lately I've been trying to cross-compile libexpat for a new board with a different architecture from what we typically use at work, and I've been having one heck of a time, until I finally got help online from my question at stackoverflow. Turns out, I just needed to be more specific about my host architecture in the configure command:

./configure --host=arm-none-linux --enable-shared CC=arm-none-linux-gnueabi-gcc CXX=arm-none-linux-gnueabi-g++ AR=arm-none-linux-gnueabi-ar RANLIB=arm-none-linux-gnueabi-ranlib STRIP=arm-none-linux-gnueabi-strip

I'm going to try similar recompilation with other libraries so that I can improve the functionality of our older systems as well.

Determining what ports Tomcat is running on

I've recently had problems connecting to a Tomcat server setup by another developer. In order to troubleshoot these problems, I wanted to use netstat to see what ports were being bound to, but apparently server sockets don't come up by default. If you really want to see what server sockets are in use on your machine, use the following :

netstat -lntp

The undocumented 't' option will cause netstat to show server sockets.