How to mount remote SSHFS via SSH Tunneling!

sshfs is very handy for mounting remote directories on your local filesystem. Recently I needed to mount the / directory off a remote server so I can remotely work from home without complicating everything by ssh’ng then vim my code – Painful exercise.

All that is needed is to copy the code below to a file and chmod +x it.

if [ -z "$*" ];
    USERNAME: Default to local username
    HOST: Hostname or IP of server to connect to.
    REMOTEHOST: Host to tunnel via
    REMOTEPORT: Host port to tunnel via (Default: 2222)
    MOUNTPOINT: Local mounting point"
    exit 1;

export PATH="${HOME}/bin:$PATH"

# Assumptions: ssh keys have been generated and successfully copied over to remotehost, vice versa
# if necessary, openssh-client, openssh-server and sshfs packages installed
# The first we need to pre-establish a forwarded port over SSH.
ssh -v -f -N -L 1233:"${HOST}":22 -p "${REMOTEPORT}" "${REMOTEHOST}"
sshfs -p 1233 "${USERNAME}"@localhost:/ "${MOUNTPOINT}" -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3


Automagically execute a bash function/cmd upon entering a directory.

After growing tired of sourcing Petalinux/Yocto-project settings, I decided to compile a script/code that resides under my ~/.bashrc , the only thing the code/script does it automagically source my settings upon entering the directory else it will just list the contents of that directory.

source $HOME/.opt/Xilinx/Vivado/2017.2/
export YOCTODIR=$HOME/Documents/Xilinx/EmbeddedLinux/Yocto/poky
export PETADIR=$HOME/Documents/Xilinx/EmbeddedLinux/Petalinux
function cd {
    # The 'builtin' keyword allows you to redefine a Bash builtin without
    # creating a recursion. Quoting the parameter makes it work in case there are spaces in
    # directory names.
    builtin cd "$@"
    if [ "$PWD" == "$YOCTODIR" ] ;
            bash $YOCTODIR/.source_yocto
    elif [ "$PWD" == "$PETADIR" ] ;
            bash $PETADIR/.source_petalinux
        ls -lhF;

The content of source_petalinux listed above.

$ cat $PETADIR/.source_petalinux
. ~/.opt/petalinux/

as well as .source_yocto

$ cat $YOCTODIR/.source_yocto

. $HOME/Documents/Xilinx/EmbeddedLinux/Yocto/poky/oe-init-build-env

Xilinx PetaLinux 2017.2 installation on Ubuntu 16.04.3

Firstly, we will to the Xilinx Downloads page to obtain the installer. Select version 2017.2 on the left sidebar. Choose “PetaLinux 2017.2 Installer”. It is a single-file executable that is 7.54GB large.

Note: you have to be a registered user to download it.


Firstly we need enable i386 architecture (if running Ubuntu x64):

sudo dpkg --add-architecture i386

Before you proceed, make sure all the prerequisites are satisfied:

sudo apt install chrpath socat texinfo gcc-multilib libsdl1.2-dev xinetd tofrodos iproute \
gawk gcc git-core make net-tools ncurses-dev libncurses5-dev zlib1g-dev flex bison lib32z1 \
lib32ncurses5 lib32stdc++6 libselinux1 xvfb autoconf libtool libbz2-1.0 xinetd tftpd tftp \
lib32stdc++6 libgtk2.0-0:i386 libfontconfig1:i386 libx11-6:i386 libxext6:i386 libxrender1:i386 libsm6:i386 libssl-dev \

for a successful installation, we need to configure tftp

sudo nano /etc/xinetd.d/tftp

service tftp
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no

Create a directory /tftpboot(this should match whatever you gave in server_args.)

sudo mkdir /tftpboot
sudo chmod -R 777 /tftpboot
sudo chown -R nobody /tftpboot

Restart tftp service

sudo /etc/init.d/xinetd stop
sudo /etc/init.d/xinetd start

/bin/sh to bash

sudo dpkg-reconfigure dash
# --> Select Yes

Now install PetaLinux into the directory/opt/petaLinux. The installer is a shell script that runs in the terminal.

chmod a+x
export PETADIR=$HOME/.opt/petalinux
sudo mkdir -p $PETADIR
sudo chown $USER:$USER -R $PETADIR

Press ‘ENTER' to see the licenses, q to quit reading the licenses, and y + ENTER to accept the licenses. The installation should last for about 15-30 mins.

Every time you want to use PetaLinux tools, remember to source the “settings” script to have the right environment variables:

source $HOME/.opt/petalinux/

Creating your first project [Board Support Package]

The following is a super simple walk-through of how to use PetaLinux tools.

  1. To create a PetaLinux project with a specific BSP, In my case Zedboard

Once you have the BSP of your choosing downloaded (and extracted if it was a zip file), go to your terminal and change directory to where you would like to create your new PetaLinux project directory and enter the following command.
In my case it would be:

$ cd $HOME/Documents/Xilinx/EmbeddedLinux/Petalinux/Projects
Then run the petalinux-create command on terminal:

$ petalinux-create -t project -s avnet-digilent-zedboard-v2017.2-final.bsp

Rebuilding the reference design system

In order to rebuild the system run petalinux-build

$ petalinux-build -v

This step usually takes 15-30min depending on the performance of your system, the step generated a device tree ‘DTB’ file, the FSBL(First Stage Bootloader), U-Boot, Linux Kernel and the root file-system images

After the build is complete you can test it in a simulated environment.

Pre-built Petalinux image test with QEMU

Petalinux provide QEMU support to enable testing the image-built in a simulated environment.

$ petalinux-boot --qemu --prebuilt 3
# The --qemu option test petalinux-boot to boot in QEMU instead of real hardware,
# and --prebuilt 3 boots the pre-built <span 				data-mce-type="bookmark" 				id="mce_SELREST_start" 				data-mce-style="overflow:hidden;line-height:0" 				style="overflow:hidden;line-height:0" 			></span>linux kernel

Diagnosing LAN Speeds

After having network issues/degradation while trying to access a work server, I had to diagnose the network the server is connected to. I had to set myself on a mission – and after realising that the seems to be very limited tools for such things, I stumbled upon ‘iperf‘.

Iperf is a command-line tool used in the diagnostics of network speed issues, it measures the maximum network throughput a server can handle. It is particularly useful when experiencing network speed issues, as you can use Iperf to determine which server is unable to reach maximum throughput.

Iperf installation

Iperf must be installed on both computers you are testing the connection between.

sudo apt-get install -y iperf

TCP Clients & Servers

Iperf requires two systems because one system must act as a server, while the other acts as a client. The client connects to the server you’re testing the speed of.

  1. On the node you wish to test, launch Iperf in server mode:
iperf -s

You should see output similar to:


2. On your second Linode, connect to the first. Replace dbelab04 with the first node’s IP address in my case i’m using the hostname

iperf -c dbelab04

You should see output similar to:

3. You will also see the connection and results on your Iperf server. This will look similar to:


4. To stop the Iperf server process, press CTRL + c.


You can do pretty much the same thing with plain old nc (netcat) if you’re that way inclined. On the server machine:

nc -vvlnp 12345 >/dev/null

You should see something similar to:


And the client can pipe a 10Gb of zeros through dd over the nc tunnel.

dd if=/dev/zero bs=10M count=1K status=progress | nc -vvn 12345

You should see something similar to:


The timing there is given by dd but it should be accurate enough as it can only output as fast the pipe will take it. If you’re unhappy with that you could wrap the whole thing up in a time call.

Remember that the result is in megabytes so multiply it by 8 to get a megabits-per-second speed. The demo above is running at 11.8mbps due to my laptops network limitation and number of hops…

Python’s Virtualenv working with Jenkins

If you use virtualenv to isolate your python project’s environment, and want your code tested automatically — read on, else ignore.

virtualenv isolates your project’s python environment

virtualenv makes sure you lock down your project’s main directory and all subdirectories of it. This ‘lockdown’ means that you never touches your global python binary, or any globally installed libraries (like “sudo pip install ipython” ).

Once locked down, you install all packages again, even those you have globally installed. This enables you to have one version of flask globally installed, but another version in your project. All dependencies can be listed in a separate file and validate a precise environment for you to work with. Tightly controlled dependencies is key to a deployment without surprises.

Jenkins checks the health of your project for each change

Jenkins is a CI server which means it does a lot of repeating stuff so you can focus on doing more important stuff. More specifically, it listens for changes to your project’s version control system (like git).

When changes are detected, the project is built and the test suite is executed. If any step fails, the CI server tells you that it did.

Setup Jenkins, and make it use virtualenv

Jenkins needs some massaging before it handles the hijacked environment of virtualenv. This is how I did it for my local git repository:

  • Download and install Jenkins
  • Start it, it should be up on http://localhost:8080
  • Install the Git Plugin
  • Setup a new project with these properties:
    • Source Code Management: add the URI to your local repository,
    • /Users/you/Sites/asdf in my case. Make sure the jenkins user can read this directory, otherwise the Jenkins GUI will tell you something random about invalid git repo, without a hint about a permissions error.
    • Build Triggers: Poll SCM (with an interval like 0 * * * *). This is needed because
      you’re too lazy to build manually; and
      you can not trigger builds with a git post-commit hook otherwise
    • Build > Execute shell. I’ve used two steps, one for setting up the environment and one for the actual tests:

# Setup a proper path, I call my virtualenv dir "venv" and
# I've got the virtualenv command installed in /usr/local/bin
if [ ! -d "venv" ]; then
        virtualenv venv
. venv/bin/activate
pip install -r requirements.txt --download-cache=/tmp/$JOB_NAME


. venv/bin/activate
which python

# reply should be

Setting up an MQTT server on Debian Jessie

Jolabs Tech Blog


Today we`re going to be setting up our own home automation server in a dedicated linux server. It’s gonna host our platform using the the Node.Js environment. The different devices around the house are going to be speaking MQTT to this server. I’ve chosen MQTT because of it’s robustness and lightweightness allowing for easy deployment on my favourite controllers: ESP8266. The esp-01, still the cheapest to this date,only sports 4mb of flash, has no trouble at all controlling a couple of relay’s for now. In the future the newer/bigger boards can be used to get more IO and function, but for now I’m going to be using the esp-01’s extensively around the house flexibly (it’s wireless…).


The idea is to have the server online 24/7, so consider a computer thats not to power-hungry; like a Raspberry Pi or a small embedded box computer. Alternatively you can boot up…

View original post 340 more words

Back to top