HydroBot is a modular control system for automating hydroponic gardens. This system is designed with three objectives in mind. First, it will facilitate optimal growing techniques by using scheduling and feedback control loops to maintain state and adapt to changing conditions. Second, it will simplify controls interfaces, making setup and use easier for less tech-savvy gardeners. Finally, the components will be designed in a modular way to increase flexibility and support every imaginable garden configuration. HydroBot aims to bring sensors and actuators together through automation, which will allow hobby growers to focus on growing and not on constantly monitoring and adjusting the environment to keep their garden stable.

Why hydroponics?

NFT Hydroponic System

As the world population continues to grow and become increasingly connected, more attention is being focused on the disparity in living conditions across the globe. The further technology advances, the harder it is to believe that people in many parts of the world still struggle with attaining basic human necessities such as access to clean water and sustainable nutrition, and yet these issues remain unresolved. Addressing these problems will require collaboration from the global community, and I believe that hydroponics has the potential to be at least one part of the solution. Let’s look at the reasons why hydroponic gardening is superior to traditional agricultural methods.

• Hydroponics requires less space than traditional gardens when taking advantage of vertical space by stacking growing systems on top of each other.
• By tweaking the environment and nutrients given to the plants in real-time, hydroponics can speed up the process of growing plants by as much as 50% [1].
• Because the system is closed-loop, hydroponics can also use up to 90% less water than traditional farming methods [2].
• Plants can be grown year-round, increasing space utilization in the winter months.
• The absence of dirt means produce is cleaner, and the clean environment means less bugs to damage the crop and no weeds to worry about.
• With greater control over the nutrients being fed to the plants, they can be grown to contain more vitamins and minerals as well as improved taste.

The biggest downside to hydroponic gardening is the cost and complexity of the system required to support it – and that’s where HydroBot comes in.

The HydroBot Vision

HydroBot looks to solve the problem of controlling a complex hydroponic system through automation, simple interfaces, and flexible design. Automation will be accomplished through the use of an embedded computer that will handle all the feedback control loops and scheduled tasks. The embedded computer will communicate with a server to provide data logging and an easily accessible remote interface. The server will also host a webpage with data graphs and user controls, and have to ability to send out critical system alerts. To make the system flexible, a modular architecture will be used for all functions that interact with the physical world, such as sensors and actuators. Each function will have a corresponding module to carry out that specific task and report back to the embedded computer, which will act as a central hub for these modules. A multi-drop communication network will be used to connect the modules to each other and to the central hub. A block diagram of this system architecture can be found below.

HydroBot Block Diagram

Implementation Details

Although each module will be developed separately as the need arises, there are some high level system design decisions that will dictate the requirements for the modules. CAN has been chosen as the primary communication network for HydroBot, because it meets the multi-drop requirement, works well over relatively long distances, is very robust to environmental noise, handles errors gracefully, and has built-in arbitration and message priority. Support for additional communication protocols may be added in the future as needed – for instance, if an application requires wireless communication. To make the system as flexible as possible in a variety of applications, both 12V and 24V power will be supported. Modules will also be daisy-chain-able and allow up to 1A of pass-through current. To keep connectors consistent, JST ZH series has been chosen for module connections when possible. To keep a consistent code base and shared libraries across modules, STM32 microcontrollers will be used as the standard for module processing.

Several key modules have been identified to fulfill the basic functions required in most hydroponic systems:

• Environmental sensor to monitor air temperature, humidity, and pressure
• Water reservoir sensor to monitor water level and temperature
• Relay driver to control pumps, lights, heaters, etc.
• Dosing pump driver to control nutrient mixing
• Nutrient sensor to monitor salinity and pH
• Light sensor to monitor grow-light output

The possibilities for module development are endless, and additional modules will be developed as they are needed.

Summary

Deep Water Culture Hydroponic System

Hydroponics may be a good solution to many of the world’s food-related problems, but the barrier to entry is still very high for most people. HydroBot hopes to solve that by creating an automated control system that is easy to use and flexible enough for any garden setup.

Sources:

1. https://www.hydroponics.net/learn/hydroponic_gardening_for_beginners.php
2. http://swes.cals.arizona.edu/environmental_writing/stories/2011/merrill.html

Sample photobooth photostrips

Photobooths are popular at many types of social events, including weddings, birthday parties, and school dances. However, renting one can easily cost upwards of $1000, making them impractical for many events. So when a friend mentioned wanting one for her wedding, I jumped at the opportunity to build a low-cost DIY photobooth.

To make my photobooth cost-efficient, I decided to use a thermal receipt printer to print out black and white photo strips, which eliminates the need for an expensive photo printer and photo paper/ink. I also added Twitter integration so the photobooth can tweet out every photo strip it takes, and a QR code generator that prints a link to the corresponding Twitter post on each photo strip.

The BeagleBone Black single-board computer seemed like a perfect match to power this project, and I decided to script everything in Python to keep it simple. Gphoto2 provides the camera interface, CUPS handles the printing, and Python libraries take care of everything else.

Lets get into the details of how this thing works.

Electronics

BeagleBone Black

The BeagleBone Black will boot up into a usable state without any setup required. However, I found that some gPhoto2 functions did not work with the Debian install that came preloaded on my BBB. To solve this issue, I switched to Arch Linux ARM. Instructions on installing Arch on the BeagleBone can be found here.

The basic features I wanted the photobooth to have are user input to start a photo sequence, camera control to take pictures, Twitter communication to tweet photos, and support for printing the final product. Thankfully each of these features is relatively easy to implement with Python.

I used Python 3 to allow support for some newer Python libraries. Unfortunately, this eliminated the possibility of using Adafruit’s Python GPIO library, which is only compatible with Python 2. Instead, I used the manual approach of exporting the GPIO pins to files in the /sys/class/gpio/ directory and reading the pin status values from the files. In Python, it looks a little something like this:

import io

# export pin 7
f = open('/sys/class/gpio/export', 'w')
f.write('7')
f.close()

# define pin 7 direction as input
f = open('/sys/class/gpio/gpio7/direction', 'w')
f.write('in')
f.close()

# read pin 7 status
f = open('/sys/class/gpio/gpio7/value', 'r')
status = f.read()
if("1" in status):
    # do something
elif("0" in status):
    # do something else
f.close()

# unexport pin 7
f = open('/sys/class/gpio/unexport', 'w')
f.write('7')
f.close()

The GPIO pins can be used to capture button presses and trigger the photo sequence.

The primary function of a photobooth is to take pictures, so if nothing else we’re going to have a camera in the setup. The Gphoto2 library takes care of camera integration and simplifies it down to just a few commands. The library supports thousands of camera models, so chances are your camera will work. A list of supported cameras can be found here. Since I wanted to take 4 pictures in a row with even spacing and immediately download the pictures, I used the following command and arguments:

gphoto2 --capture-image-and-download --interval=3 --frames=4 --filename /tmp/portrait%n.jpg --force-overwrite

The arguments can be modified to fit various needs—for example, saving the photos on the camera’s internal memory after they have been downloaded.

I wanted to display live view from the camera on a monitor that would allow users to see themselves as they pose for pictures, but I wasn’t able to get this working. Gphoto2 seems to turn off live view on my camera after the first picture is taken, and it won’t come back on until the camera is power-cycled. I will be working to find a solution for this issue in the future, possibly by streaming the live view video to the BBB and displaying it from there, or by replacing the camera with a high-def web cam, but until then I will live without it.

To give the user feedback when each picture is taken (in the absence of live view), I decided to turn on the camera flash, even though using the built in flash is less than optimal. Without this feedback, it is difficult to tell when each picture is being taken and when the set is finished. To minimize the blinding effect a bright flash tends to have, I turned down the flash brightness to around a 16th of its usual strength.

Because a photobooth tends to be fairly dark, and since I wasn’t relying on the flash for full lighting, I added some extra lighting to the setup. I decided to use Protofusion’s Luma lighting system to give me flexible control over the lighting through the BeagleBone Black. This allowed me to easily set the lighting levels and give some additional feedback regarding program state or errors by flashing the lights different colors. Using the Luma LED Strip Driver and an LED strip, I was able to string lighting around the top of the booth and light it with a soft, distributed light. In the absence of such a high tech lighting system, any standard light source could be used. If the light source tends to be direct and harsh, I would recommend some type of diffuser to distribute and soften it out a bit.

DYMO 400 Printer

I picked the Dymo 400 Labelwriter to print the photo strips because I could find it on eBay for pretty cheap, and it seemed widely used and supported. To use it with the BBB, I installed the CUPS printing system and found the Dymo driver in the Arch User Repository (I recommend Packer for installing packages from the AUR). Here is a good tutorial on installing and configuring CUPS.

To make the Dymo 400 print the way I wanted, I had to make a few tweaks. When I chose the “Continuous Feed” paper option in CUPS, it would print a large margin at the top of strip, so I tried setting a custom paper size. No matter what custom paper size I set, the printer would always print out the strip, and then print out an equal amount of blank paper. There may be a solution to this, but I was unable to find it. So the work around I used was to manually change the default printing settings for the printer, by going through the printer configuration file and changing the printable area for the “Continuous Feed” paper option. The modified file can be found below.

To format the individual photos into one photo strip, along with some text and a QR code at the bottom, I chose the ImageMagick command line image editing tool. I used the convert -append command to assemble all the photos into one image. The one problem I found here was that the large photos taken by the camera were too large for the program to combine into one with the limited RAM on the BeagleBone. Instead, I resized each of the photos and then assembled the smaller images. Since the Dymo 400 printer has a printable width of 672 pixels, I converted all the images down to that size. Here is the sequence of commands I used to assemble a photo strip:

# resize each of the pictures and add a border to make them go together nicely
convert /tmp/portrait1.jpg -sample 26% -bordercolor '#FFFFFF' -border 2x20 /tmp/portrait1.jpg
convert /tmp/portrait2.jpg -sample 26% -bordercolor '#FFFFFF' -border 2x20 /tmp/portrait2.jpg
convert /tmp/portrait3.jpg -sample 26% -bordercolor '#FFFFFF' -border 2x20 /tmp/portrait3.jpg
convert /tmp/portrait4.jpg -sample 26% -bordercolor '#FFFFFF' -border 2x20 /tmp/portrait4.jpg
# put the pictures all together and add the protofusion logo
# this is the version I tweeted
convert -append /tmp/portrait1.jpg /tmp/portrait2.jpg /tmp/portrait3.jpg /tmp/portrait4.jpg /root/protofusion.jpg /tmp/twitter.jpg
# resize the QR code
convert /tmp/qrcode.jpg -sample x245 /tmp/qrcode.jpg
# add the QR code and some text together horizontally
convert +append /tmp/qrcode.jpg /root/photoboothtext.jpg /tmp/qrblock.jpg
# add the QR code and text to the photo strip
# this is the version I printed
convert -append /tmp/twitter.jpg /tmp/qrblock.jpg /tmp/print.jpg


In order to Tweet photos, the photobooth needs to be connected to the internet. I used a TP-LINK TL-WN722N wifi dongle I had laying around, but any of the adapters on this list as well as many others should work well. The Arch Wiki details the steps for connecting to a wifi network in Arch Linux.

Twitter integration adds a fun twist to the traditional photobooth. I used the twython Python Twitter API wrapper, which simplified many of the steps. The only tricky part is authenticating through Twitter’s three step authentication process.  I haven’t yet added authentication support to my script, so I just manually hard-coded in the generated keys needed. I hope to add Twitter authentication to the next iteration, and will write about that when I finish it.

To give users an easy way to find their tweeted photos, I used a Python QR code generator called qrcode that generates a QR code with a link to the posted image. The generator takes the link returned by the Twitter API and spits out a QR code which is saved and appended to the photo strip. I also added some custom text next to the QR code to explain what the QR code links to.

You can find my Python code here: photobooth.zip
You can find the cups printer config file I used here: printer_config.zip

Here is a list of the tasks (detailed above) that need to be completed to set up the full system:

• Install Arch Linux
• Install Packer
• Install Python
• Install Python libraries:
  • twython
  • oauthlib
  • qrcode
  • pyserial
• Install and configure Cups
• Install and configure printer drivers
• Setup wifi connection
• Install Gphoto2
• Install ImageMagick

Physical

The physical aspect of the photobooth was the easiest part to build, although my simple design has the potential to be greatly improved. To create the enclosure, I opted for a simple PVC pipe frame that could be quickly disassembled and easily transported. I made the enclosure 6 feet long, 4 feet wide, and 6.5 feet tall. These dimensions can be adjusted based on application, but I wanted plenty of space in mine for several people to stand and pose. So far, up to seven people at a time have successfully fit in it. The length really depends on the type of camera and focal length being used, but 6 feet seems like a good starting place. The height is also highly variable, especially if people will be sitting. But since I designed with standing in mind, I wanted to accommodate some of the taller potential users.

I chose ¾” PVC as a good compromise between cost and strength, and was able to find the elbow pieces I needed to assemble a cube. Here is the design I used for the frame:

Photobooth frame made with PVC pipe

Once the frame was built, I chose curtains to cover it. Curtains are a slightly more expensive choice than some of the other options (bedsheets, etc.), but they come pre-made in various lengths, with loops in the top that make them perfect for hanging on PVC. I chose black to create a more private feel in the booth, but in hindsight, something lighter may have allowed better contrast in the photographs and prints.

When I was looking to find some sort of button to use to trigger the photo sequence, I came across a round foot pedal from a tattoo machine. This worked especially well because the booth is designed to be used standing up. However, any type of input could be used to trigger the sequence.

Photobooth instructions

The photobooth setup also needs a tripod, or something to hold the camera. I used this tripod and was really happy with it. Lighting is also important in a photobooth, so some sort of fill lighting would be desirable. As mentioned above, I found a fancy solution to this, but any light source should work. I also found that some people tend to be confused no matter how straightforward the interface is. Although it may seem tacky, an instruction sheet can really clear up confusion, and when creatively designed, can blend in seamlessly with the look of the booth.

A photobooth can help create spontaneous and memorable moments at any party or get-together. I hope the details here will inspire someone to build their own, because sometimes it’s more fun to do it yourself!

Materials

Here’s a list of the materials I used to make the photobooth, along with an idea of what they all cost.

• Beaglebone Black x 1 = $65
• USB hub x 1 = $15
• Wifi adapter x 1 = $18
• Thermal printer x 1 = $30
• Receipt paper x 4 = $24
• Foot pedal x 1 = $12
• Tripod x 1 = $20
• PVC pipes x 10 = $25
• PVC connectors x 12 = $12
• Curtains x 6 = $60

Total = $281

Already had:

• Camera
• Lighting

Tools:

• Hack saw
• Screw drivers
• Wire cutters
• Computer

The BeagleBone Black is an ARM-based device and doesn’t have ACPI support like most x86 systems. ACPI generally handles triggering shutdown and other power management events on x86 systems, so this functionality is missing on the BeagleBone. We can easily work around this problem with acpid, which provides an event handling script that is triggered when the power button is pressed. This is a simple way to add power button triggered shutdown without actually having ACPI support in the hardware.

First, install acpid from your distribution’s package manager. For Arch Linux ARM:

sudo pacman -S acpid

Next, open /etc/acpi/handler.sh in a text editor. Look for the snippet containing “PowerButton pressed” near the beginning of the script. After this line, add a new line with “poweroff” on it. You may also add any other commands you wish to run when the power button is pressed.

        case "$2" in
            PBTN|PWRF)
                logger 'PowerButton pressed'
                poweroff
                ;;
            *)
                logger "ACPI action undefined: $2"
                ;;
        esac
        ;;

Now enable and start the acpid daemon. On systemd-based distros, use the method below.

systemctl enable acpid.service
systemctl start acpid.service

Now that acpid is running, power button events will be handled by the events script. Note that the acpid service will generate errors in its log because it is unable to communicate with the kernel, but the poweroff will execute as expected.

Finally, press the power button on your BeagleBone and it should begin shutting down. If you encounter any issues, check the logs of the acpid service to make sure it launched properly. Also double-check your syntax in the event handler script.

Arch Linux ARM currently includes an unpatched version of dtc (device tree compiler) which lacks the “@” option. If you want to enable additional UARTs, SPI, I2C, or just use GPIO without recompiling the bootloader, you need a patched version of dtc. You can download the source code and manually patch/compile, but to make this process easier I created a PKGBUILD which builds a patched version of dtc from git. Grab the raw PKGBUILD after the break, or just run packer to install from the AUR:

packer -S dtc-git-patched

Make sure you don’t have the vanilla version of dtc installed, pacman will throw “file exists on filesystem” errors if it’s already installed from the standard repository.

After installing dtc you can easily mux pins with the flattened device tree. For more information on muxing pins and enabling UARTs, check out the hipstercircuits guide.

# Maintainer: Ethan Zonca <ethanzonca@ethanzonca.com>

pkgname=dtc-git-patched
pkgver=20130410
pkgrel=1
pkgdesc="Device Tree Compiler with Dynamic Symbols and Fixup Support Patch"
url="http://jdl.com/software/"
arch=('i686' 'x86_64' 'armv7h')
license=('GPL2')
makedepends=('git')

_gitroot='http://jdl.com/software/dtc.git/'
_gitname='dtc.git'

build() {
    msg 'Downloading dynamic symbols fixup patch...'
    wget https://patchwork.kernel.org/patch/1934471/raw/ -O dynamic-symbols.patch
    msg 'Connecting to GIT server...'

    if [[ -d ${_gitname} ]]
    then
        cd ${_gitname}
        git reset --hard HEAD
        git pull -f
        git clean -f
    else
        git clone ${_gitroot} ${_gitname}
    fi

    msg 'GIT checkout done or server timeout'
}

package() {
   cd ${_gitname}

   # Revert to version that patch applies to
   git reset --hard f8cb5dd94903a5cfa1609695328b8f1d5557367f

   # Apply patch
   git apply ../dynamic-symbols.patch
   #    patch -Np1 -i ../dynamic-symbols.patch

    make || return 1
    make INSTALL=$(which install) DESTDIR=${pkgdir} PREFIX=/usr install || return 1
}

Image credit: Adafruit

I was introduced to the bash builtin /dev/tcp by warg the other day on x-tab#chat. He explained a basic use of this device by demonstrating how to download wget’s compressed tarball. The download process itself can be done with pure bash, but some post-processing of the downloaded file must be done to remove HTTP headers. I document warg’s application of /dev/tcp here because I found the idea fascinating and want this documentation for myself ;-).

Connecting and Downloading

To read about the /dev/tcp builtin for yourself, check out the following:

$ info '(bash) Redirections'

With the exec line we initiate the connection, allocating a file descriptor and storing the numeic file descriptor into the HTTP_FD variable. Then, with the echo line, we send an HTTP request through the descriptor to the server. After sending the request, we process the server’s response with the sed line which skips over the HTTP headers sent by the server and stows the results into wget-latest.tar.gz. Note that this last command will sit around for a while. It is with this command that the builk of the data transfer is performed. And, since you’re using shell redirections to download the file, you cannot see the download progress. Instead, wait for the command to complete. This also involves waiting for the server to time out your connection since it supports pipelining. After this process is completed, the wget-latest.tar.gz file is as your disposal.

$ WGET_HOSTNAME='ftp.gnu.org'
$ exec {HTTP_FD}<>/dev/tcp/${WGET_HOSTNAME}/80
$ echo -ne 'GET /gnu/wget/wget-latest.tar.gz HTTP/1.1\r\nHost: '\
    ${WGET_HOSTNAME}'\r\nUser-Agent: '\
    'bash/'${BASH_VERSION}'\r\n\r\n'  >&${HTTP_FD}
$ sed -e '1,/^.$/d' <&${HTTP_FD} >wget-latest.tar.gz

Now you have a wget source tarball on your machine. As long as you have tar and a compiler on the machine, you are well on your way to downloading stuff using a self-compiled wget. In the commands above, you may replace “gz” with “bz2” or “lzma” for smaller downloads if the machine you’re using has bzip2 or xz-utils installed. And, of course, it should not be too hard to repurpose the above code to download a particular version of wget or even a completely unrelated software package.

Please feel free to point out problems with this approach or give pointers on porting this to other environments :-).

There are numerous guides about setting up Google Voice and an incoming sip number for free outgoing calling. Sadly, all of the guides I found were written for FreePBX or some other Asterisk bundle, and also used a shell script to do much of the work (scary!). I have compiled the minimal amount that you need to put in your asterisk conf files to make things work, GUI-free and variant-independent.

Prerequisites

First off, you need a sip number. I recommend sipgate or ipkall (I use sipgate, it’s much more user-friendly). If you google around, you’ll find out how to set up your sipgate/ipkall number as an incoming number in asterisk, I won’t waste time covering it here.

Secondly, you need a google voice number. Once you get said number, turn off call presentation. Also, assign the account a password that you don’t mind having plaintext in a conf file. In addition, you must add your incoming sip number as a phone in google voice. I’d recommend connecting a softphone to your sip number to set this up with google’s verification call, or redirect all incoming calls in Asterisk to your extension.

Thirdly, you need pygooglevoice. Download and install it, or use python’s easy_install command.

The outgoing rule

Now for the actual configuration. First you need to set up an outgoing call rule, so all calls to the outside world (in this case, 10-digit numbers preceded with a “9”) are directed though google voice.

[CallingRule_LocalCalls]
exten = _9XXXXXXXXXX,1,Goto(custom-gv,${EXTEN:-10},1)

Explanation: Any outgoing 10-digit number prefixed with a 9 will match this rule and go to the custom-gv section which we will set up later. The number that was dialed is passed (the “-10” excludes the 9 prefix from this) at the first dialplan rule.

The GV dialer

Now we need to set up the custom-gv section:

[custom-gv]
exten => _X.,1,Verbose(0, Custom-GV Preparing to call and park call at number ${EXTEN})
exten => _X.,n,Wait(1)
exten => _X.,n,Playback(pls-wait-connect-call)
exten => _X.,n,System(gvoice -e me@me.com -p GVPassword call ${EXTEN} IncomingNum &)
exten => _X.,n,Set(PARKINGEXTEN=701)
exten => _X.,n,Park()

Explanation: After you dial an outgoing number, you’ll be dropped in here. The Verbose() function tosses some output in debug level 0 and up (see the console for this output). The System() command dials the number with google voice. Make sure you change the items in strikethrough to your own personal information. The call is then parked on extension 701 (70X extensions for parking are default. Switch to your parking extension range if you are using non-default options).

Routing GV callbacks

Now you need to set up an incoming call rule. Direct all incoming calls from your sip number at this rule.

[incoming-call-sifter]
exten = s,1,NoOp(CIDredirect)
exten = s,2,Verbose(0, Got incoming CID ${CALLERID(num)}, redirecting…)
exten = s,3,GotoIf($[“${CALLERID(num)}” == “GVNumber“]?custom-park,s,1)
exten = s,4,Goto(section-to-route-normal-incoming-calls,s,1)

Explanation: If your google voice number rings your PBX, you know that it’s connecting you to the call you just dialed, so we need to reconnect it to the extension you dialed from. We’ll handle linking of the incoming GV call and your outgoing call (which is now parked) in the next section (custom-park).

Bringing it all together

The custom-park section links a google voice incoming call (which is actually ringing the person you originally dialed) with your original outgoing call (which is parked).

[custom-park]
exten => s,1,Verbose(0, Got incoming GV Callback! Connecting to your original outgoing call…)
exten => s,2,ParkedCall(701)

Explanation: After you dialed your external number, your call was parked as google voice started dialing the other number. This section joins your outgoing call with google voice’s incoming call, so you are connected to the party you originally dialed.

You’re done!

[pullquote]Have comments, questions, or need clarification? Leave a comment![/pullquote]

Well that turned out to be a bit longer than I expected, but if you know what you’re doing, you can just ignore the italicized text.

Well, the school year is over, so I thought I’d post up some information about my (extremely cheap and junky-looking but functional) door opener.

The door handle is turned by one 24v globe motor (which have encoders that I’m sadly not using at the moment), and is pulled open by another identical motor. A very affordable ($30) SparkFun RFID reader is attached to the back the door so cards can be scanned from the outside. An arduino controls the process, and drives motors and a cooling fan with 3 darlington transistors.

Power supply case housing arduino and circuitry, along with door-pulling motor and ridiculously ugly tie-dye duct tape

The arduino was attached to an old Dell laptop, which ran the Apache webserver. A small password-protected php web interface was created to allow door opening from anywhere on campus. KDE4 widgets allowed door opening from computers inside the room, letting my roommate and I avoid walking less than 8 feet (or less) away to open the door for someone.

Touchscreen mounted to wall, password widget not shown. And no, I did not actually go to school in Munich, Germany

I also put a password-protected KDE4 widget on our touchscreen mounted on the wall outside of our room, so if one of us forgot our RFID card, we could type in a password on the touchscreen, and the door would open. Fun stuff.

Unfortunately I don’t have too many pictures, and the entire thing is disassembled now. Hopefully next year I’ll improve it (encoders and PID for motion control?) and post some more information.

As a Gentoo user, I value the ability to compile and install things from source. Yet I don’t want the messiness of a completely manual “distribution” such as LFS. Yet I feel like I’m missing out of a big chunk of the GNU/Linux experience when I have to tell people that I’ve only ever used Gentoo. Also, if one wants to make his package available from multiple distributions, he may find more success if he is able to facilitate creation of the binary packages for these other distributions.

Thus, I have committed sys-apps/pacman into Sunrise. I still have to get permission to commit a few fixes (hopefully by tomorrow). Also, archlinux’s take on mirrorselect, reflector, has been committed but awaits review. When these things get through, the following may actually be worth something:

I have attempted to write a guide to setting up an archlinux chroot on Gentoo. Don’t actually try the guide until about a week from now, when my stuff clears review, of course ;-). However, in the meantime, I would gladly accept:

• Technical criticisms
• (if you are tommy[d], please ignore the following) Alerts about the misuse of the apostrophe or general grammatical problems
• Documentation storage format suggestions — I suppose it would be a good exercise for me to learn docbook someday. Should I start now?

The problem: you have a computer sitting behind a firewall. You want to access it from a different location, but you don’t have the ability to forward any ports to it. The answer: SSH tunneling.

The Solution

Using an SSH tunnel, you can reverse-forward ports from one computer to another. To do this, you will need a computer running linux and sshd to reverse-forward the ports to. It is very convenient if this is the computer you will be using to access the remote machine. Otherwise, additional steps must be taken.

The Setup

The easiest way to set up and maintain a reverse port-forwarding tunnel is with ohnobinki’s insurgent script. The script allows you to specify a remote host and the ports you want to reverse-forward. To start off, create a new user on your system, such as insurgent. Log in or start a shell as this user. Assuming you have mercurial installed, run:

hg clone https://ohnopublishing.net/hg/insurgent

Now cd to the newly created insurgent/bin directory. Finally, place the contents of insurgent/share/contab.txt into your crontab (use crontab -e to edit your crontab).

Now you simply need to configure the script. To do so, open insurgent.sh in your favorite editor, and update the REMOTE_HOST and other variables. The format for ports is [remoteport]:hostname:[localport] (ssh(1) ). I recommend starting with reverse-fowarding SSH (port 22), a vnc session (590x where x is the VNC display number), and nfs.

If you have not done so already, you need to set up passwordless public key authentication for the new insurgent user.

You’re Done!

If you’ve gotten this far, you may be ready to go. You should be able to access any port on your insurgent box via the corresponding port on your local box. Have any problems? Drop some comments below or pop into irc.ohnopub.net#protofusion and speak to ohnobinki or normaldotcom.

Image credit: star6. Used under Creative Commons CC BY-SA 2.0

1. ssh-keygen -t rsa      (don’t enter a passphrase)
2. ssh-copy-id -i ~/.ssh/id_rsa user@remotehost
3. ssh user@remotehost

Wasn’t that easy?