Git SCM on Drobo B810n Issue with Mitigating Workaround (Corrected)

Git SCM on Drobo B810n Issue with Mitigating Workaround (Corrected)

*** Corrected posting from original posting dated 17–18 Apr 2020 ***

Summary: Partial install issue of Git SCM DroboApp on B810n with mitigating workaround.

Table of Contents:

  • Drobo Specs
  • Issue Walk Through
  • Mitigating Workaround

Drobo Specs:

  • Model: B810n
  • Firmware: 4.2.0-9.68.113472
  • Drobo Apps:
  • Dropbear (ssh)
  • Git SCM (issue with mitgating workaround)
  • Bash (but not required)
  • Python 3 (but not required)

Issue Walk Through:

I noticed an issue when installing the Git SCM 3rd party app via Drobo Apps. The install process works and no errors are reported in the Drobo Dashboard, as expected. But, once sshed onto the B810n the git binary is not found (see below)

$ which git

* Note: the $, you don’t need to elevate to root to complete the mitigation. The Git SCM app installs correctly in the normal location, /mnt/DroboFS/Shares/DroboApps/git. And a quick check indicates that Git itself is happy.

$ /mnt/DroboFS/Shares/DroboApps/git/bin/git --version
git version 2.6.3

Other command line apps are added to /bin/ and are therefore in the $PATH. A quick look in /bin/ shows that git is not there, but other command line 3rd party Drobo Apps are.

$ ls -l /bin # -l to illustrate the symbolic links

* Note: # is the line comment symbol in a shell command

As others have commented in other posts, the root directories of the file system are read-only, and are reflashed/rebuilt after a power cycle. The mounting process is part of the Drobo system boot sequence; i.e. part of the firmware. One of the firmware scripts does create symlinks for other Drobo Apps, so I suspect there is a configuration issue in the Git SCM installer.

Luckily, there is a straight forward mitigation that is persistent (survives power cycle), and is adaptable for similar situations.

Mitigating Workaround:

I prefer a cleaner $PATH over a longer chain of directories in my $PATH; and never put “.” in your $PATH. The approach discussed here also works with other shells, but you don’t need to install Bash or another shell for this mitigation technique to work. But if you do use other shells, by applying this mitigation technique you won’t have to change the $PATH in each of them every time you want to add something else to your $PATH.

Simple Steps Performed from Terminal (ssh) Session on Drobo:

  • Create a bin/ directory in the admin account’s (your) home (~) directory /mnt/DroboFS/
  • Create a symbolic link in the ~/bin/ directory for each binary you want to be in the $PATH
  • Add ~/bin/ to the end of the $PATH for the admin account in .profile

But, that sounds complicated. It’s not that bad, and you don’t need to know vi or another terminal editor.

First, ssh into your Drobo, there are other posts that discuss Dropbear, and too many SSH clients to cover specific instructions. But, from a client side shell it probably looks like this: $ ssh Drobo_Admin_Username@Drobo_IP_Address.

You should then be in a terminal on the Drobo, in the admin accounts home directory.

yourDrobo:~ $
yourDrobo:~ $ pwd # A quick Print Working Directory (pwd(1)) to see where we are in the file system
yourDrobo:~ $

Next step is to make a bin/ directory using mkdir(1); the (1) means that mkdir is in section 1 of the UNIX manual, e.g. $ man 1 mkdir. By default, there is not a bin/ directory in a user’s home directory on most UNIXes. Once made, we can verify using ls(1).

yourDrobo:~ $ mkdir bin
yourDrobo:~ $ ls -a # List all (show hidden) files
./ .ash_history/ home/ System/
../ bin/ Shares/ SystemLogs/
yourDrobo:~ $

Next we need to create a symbolic link (or symlink for short), similar to a shortcut in Windows, to Git in the ~/bin/ directory using ln(1).

yourDrobo:~ $ cd bin
yourDrobo:~/bin $ ln -s /mnt/DroboFS/Shares/DroboApps/git git
yourDrobo:~/bin $ ls -l
lrwxrwxrwx 1 ... Apr 20 2020 git -> /mnt/DroboFS/Shares/DroboApps/git*
yourDrobo:~/bin $

Now all we need to do is add ~/bin/ to our $PATH in .profile. But, wait that file doesn’t exist, and you said we didn’t need to use a text editor!?!?

Yep, note if you do have a .profile then you have likely already created and edited it in the past. In that case, it is better to use a terminal text editor to make a cleaner modification to the contents of .profile. If you don’t have a .profile then you’re just a few more commands away from complete.

The .profile file is processed as part of the shell session startup sequence; i.e. it is processed by the shell program as it is starting up. Any common UNIX shell will fallback to processing .profile if their own shell specific profile file is not found; e.g. Bash uses .bash_profile, but will read .profile if there is no .bash_profile.

We’ll use a series of echo(1) commands to create and write a .profile from scratch.

yourDrobo:~/bin $ cd # cd without any arguments changes to your home directory
yourDrobo:~/ $ echo "#!/usr/bin/env sh" > .profile # Note: You need to use double quotes, otherwise the shell will interpret the # as a comment
yourDrobo:~/ $ echo "# Append ~/bin to \$PATH" >> .profile # Note: Use of double >> before .profile to append contents to .profile; also, we're documenting the next line for future you
yourDrobo:~/ $ echo "PATH=\${PATH}:~/bin" >> .profile # Note: Use of \ (escape character) before $ to escape the normal meaning of $ to the shell
yourDrobo:~/ $ echo export PATH >> .profile

A quick check with ls and cat(1) shows that everything is as expected.

yourDrobo:~/ $ ls -a
./ .ash_history/
../ .profile ...
yourDrobo:~/ $ cat .profile
#!/usr/bin/env sh
export PATH
yourDrobo:~/ $

Cool, now to check to see if the entire workaround worked. We will need to exit our ssh session, then ssh back in, or run $ source .profile to have the current shell instance process .profile.

yourDrobo:~/ $ echo $PATH # Note: Lack of /mnt/DroboFS/bin
yourDrobo:~/ $ source .profile
yourDrobo:~/ $ echo $PATH
yourDrobo:~/ $ which git
yourDrobo:~/ $ git --version
git version 2.6.3

Go ahead and restart your Drobo as desired. When you ssh back into your Drobo Git will still work as intended; i.e. a persistent workaround as desired.

Congratulations! Your shell XP just increased by a few points. Now git going.

P.S. I’m working on a Drobo Shell Scripts repository that is hosted on GitHub to help automate some other tasks. The first set of scripts are related to setting up Git repositories on a Drobo. I will link to that once it is posted.