• Blog
  • Research
  • Multi-Host Development Environments

    17 June, 2019 | General Hackery

    In my previous job I had a lot of sysprog work to do, so I basically forced myself to learn to use vi on the command line when writing code. I came to not rely on things like code completion or reliable syntax highlighting. Obviously this was also very handy when programming my Raspberry Pi cluster - I have a bunch of code running on each of my Pis, so I generally SSH to the appropriate host from my main Linux box, do my coding in a text editor, then git commit, all from a text window. It's great if you want to look like some kind of leet hacker, but frankly, there are better ways to program.

    There are many, many text editors, and just as many integrated development environments. Most commercial offerings are very good - I recall being virtually married to UltraEdit back in the early 2000s, and I currently use WebStorm at work. Both are awesome, and have more features that I will ever need. But I wanted something lightweight - my initial intention was to install something on all my Pis and run it over a remote X session. My only real requirements were git integration and syntax highlighting, so a full-on IDE was overkill. I also work exclusively in non-compiled languages such as PHP and Python, so I don't even need build tools. I found KDevelop. It's an IDE by the team responsible for KDE, but it runs under other desktops as well. It's lightweight and does everything I need, not to mention free. So now I'm kinda in love with that. Sorry, UltraEdit.

    The next step is, of course, using KDevelop to write code for all my Pis. I tend to develop on the Pis themselves. I'm impatient, have horrible coding standards, and only really use Git for version control, so I don't branch often, if at all. At home, I'm a hobby hacker, not a proper programmer. I did think of either installing KDevelop on every Pi I own and using a remote X session to code, or perhaps setting up a SMB share on every Pi and mounting them all within my main Linux PC's filesystem as an alternative. Both of these involved setting up extra things on the target Pis, which is inconvenient when you consider those nice premium IDEs both have the ability to open files over SFTP.

    But it turns out you can happily mount a filesystem over SFTP within Linux itself, using SSHFS.

    To install, it's a simple case of

    apt-get install sshfs

    Rather than run from /etc/fstab, you create mount points on the fly. I myself have a shell script that looks like this...

    #!/bin/bash
    sshfs pi@scavenger:/home/pi /home/ash/pi/scavenger -p 22 -o reconnect 2> /dev/null
    sshfs pi@mixmaster:/home/pi /home/ash/pi/mixmaster -p 22 -o reconnect 2> /dev/null
    sshfs pi@scrapper:/home/pi /home/ash/pi/scrapper -p 22 -o reconnect 2> /dev/null

    set to run every time my Linux box boots. Best of all, it's really good at reconnecting when it loses connection, and more than adequate for managing multiple projects across several local Linux hosts. I should point out, as an aside, that you'll need to configure SSH keys in order to be able to connect over SFTP without it asking for a password every 20 seconds. SSH keys are great, and you should use them anyway. It's a rare case of the more secure option being more convenient, as using keys is more secure than typing a password, so there really is no reason not to use SSH keys if you manage a lot of hosts over SSH.

    So now I simply have one directory under my home directory called 'pi', which in turn contains a subdirectory for each of my Pis, each of which is an FTP mount point to the home directory of the host in question. So I can simply have one copy of KDevelop, running on my main Linux box, which has multiple projects configured. It's quite cool to be able to have multiple files from multiple hosts open in the same IDE.

    KDevelop with various projects visible

    Of course one day I'm going to have to modify some code over SSH with no IDE installed, and I'm going to really struggle to remember how to use vi, but I'll worry about that when the time comes.