Drobo 5N supports DroboApps for migrated FS disk packs

diamondsw · January 19, 2013, 8:56pm

Contrary to all published information (and even Drobo’s own firmware release notes for the 5N), I can confirm that out of box, the 5N supports classic DroboApps! I SSH’ed into the Drobo on a lark and was stunned when my OpenSSH install responded.

(I’m mystified as to why they didn’t reassure us that existing app support still existed while they refine the Drobo-supported apps - the only thing I can come up with is the infrastructure that supports DroboApps is in flux and may break without warning. Personally, I can deal with an environment in flux a lot better than no environment at all.)

EDIT: After discussing the matter with Drobo Inc, DroboApps support will continue to work on an FS disk pack such as mine - it’s not accidental, and won’t be pulled back. However, there is no method to enable the functionality on a new disk pack, so new 5N users will have to wait for official support to roll out at a later date.

[code]$ cat /usr/bin/DroboApps.sh
DROBOAPPS_DIR="/mnt/DroboFS/Shares/DroboApps"

check_new()
{
# unpack any .tgz files - DroboApps that haven’t been installed yet
for tgz in find "$DROBOAPPS_DIR" -type f -maxdepth 1 -name \*.tgz; do
APPDIR=echo $tgz | sed s/\.tgz$//

	# if the directory already exists, this is an upgrade and 
	# untar on top of the existing install. 
	if [ -d $APPDIR ]; then
		echo "Upgrading $tgz."
	else
		echo "Installing $tgz."
		mkdir $APPDIR
	fi

	tar -zxf $tgz -C $APPDIR && rm "$tgz"

	# if there is an install.sh file, run it.
	if [ -e "$APPDIR/install.sh" ]; then
		echo Running post-install script.
		( cd $APPDIR && 
		sh $APPDIR/install.sh &&
		rm $APPDIR/install.sh )
	fi

	if [ "$STARTNEW" -eq "1" ]; then
		if [ -e "$APPDIR/service.sh" ]; then
			echo Starting `basename "$APPDIR"`.
	                # Added the cd because some apps had difficulties if not started
                            # in same directory.
                            (cd $APPDIR && sh $APPDIR/service.sh start)
		fi
	fi

done

}

start_apps()
{
# get a list of all installed DroboApps
for i in find $DROBOAPPS_DIR -type d -maxdepth 1; do
DROBOAPPS="$DROBOAPPS $i"
done

# run the service script for each DroboApp
for APP_NAME in $DROBOAPPS; do 
	if [ -e "$APP_NAME/service.sh" ]; then
		echo Starting `basename "$APP_NAME"`.
		# Added the cd because some apps had difficulties if not started
		# in same directory.
		(cd $APP_NAME && sh $APP_NAME/service.sh start)
	fi
done

}

stop_apps()
{
# get a list of all installed DroboApps
cd “$DROBOAPPS_DIR”
for i in find . -type d -maxdepth 1; do
DROBOAPPS="$DROBOAPPS $i"
done

# run the service script for each DroboApp
for APP_NAME in $DROBOAPPS; do
	if [ -e "$APP_NAME/service.sh" ]; then
		echo Stopping `basename "$APP_NAME"`.
		sh $APP_NAME/service.sh stop
	fi
done

}

if [ -z “$1” ]; then
echo “Syntax: DroboApps.sh [start|stop|install]”
exit 1
fi

verify the directory exists, create if necessary

if [ ! -d “$DROBOAPPS_DIR” ]; then
mkdir “$DROBOAPPS_DIR”
fi

if [ “$1” == “start” ]; then
check_new
start_apps
elif [ “$1” == “stop” ]; then
stop_apps
elif [ “$1” == “install” ]; then
STARTNEW=1
check_new
else
echo “Syntax: DroboApps.sh [start|stop|install]”
exit 1
fi
[/code]

So, initial experience is that apps fired up fine. At least cursory usage indicates all of the following are peachy:
[list][]crashplan
[]droboadmin
[]java7
[]lighttpd
[]nano
[]openssh
[]p7zip
[]perl
[]screen
[]stgt
[]sudo
[]unfsd
[]unrar[/list]
The following are confirmed not working:
[list][]bash: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory
[]nfs-kernel - doesn’t work, likely because the underlying kernel has changed so much
[]locale - Perl complains about locale problems on startup, so something appears mildly off with this package. Crashplan isn’t able to use it to fix issues with foreign character sets.[/list]

Here’s the perl locale error:

$ perl perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = "en_US.UTF-8", LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C").

Here are errors I get when trying to troubleshoot locale (freshly installed package):

[code]$ locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
C
en_US.utf8
POSIX

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE=“en_US.UTF-8”
LC_NUMERIC=“en_US.UTF-8”
LC_TIME=“en_US.UTF-8”
LC_COLLATE=“en_US.UTF-8”
LC_MONETARY=“en_US.UTF-8”
LC_MESSAGES=“en_US.UTF-8”
LC_PAPER=“en_US.UTF-8”
LC_NAME=“en_US.UTF-8”
LC_ADDRESS=“en_US.UTF-8”
LC_TELEPHONE=“en_US.UTF-8”
LC_MEASUREMENT=“en_US.UTF-8”
LC_IDENTIFICATION=“en_US.UTF-8”
LC_ALL=en_US.UTF-8

$ /mnt/DroboFS/Shares/DroboApps/locale/bin/localedef -c -v -f UTF-8 -i en_US en_US.UTF-8
/usr/share/i18n/locales/en_US:7: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:8: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:9: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:11: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:14: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:15: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:16: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:17: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:19: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:20: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:21: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:22: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:23: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:24: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:25: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:26: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:27: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:28: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:29: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:34: non-symbolic character value should not be used
/usr/share/i18n/locales/en_GB:50: non-symbolic character value should not be used
/usr/share/i18n/locales/i18n:1107: non-symbolic character value should not be used
/usr/share/i18n/locales/i18n:1313: non-symbolic character value should not be used
/usr/share/i18n/locales/i18n:1345: non-symbolic character value should not be used
/usr/share/i18n/locales/i18n:1373: non-symbolic character value should not be used
/usr/share/i18n/locales/en_GB:53: non-symbolic character value should not be used
/usr/share/i18n/locales/en_GB:59: non-symbolic character value should not be used
/usr/share/i18n/locales/en_GB:149: non-symbolic character value should not be used
/usr/share/i18n/locales/en_US:40: non-symbolic character value should not be used
/usr/share/i18n/locales/translit_neutral:10: non-symbolic character value should not be used
/usr/share/i18n/locales/translit_neutral:11: non-symbolic character value should not be used
/usr/share/i18n/locales/translit_neutral:12: non-symbolic character value should not be used
/usr/share/i18n/locales/translit_neutral:13: non-symbolic character value should not be used
/usr/share/i18n/locales/translit_neutral:14: non-symbolic character value should not be used
/usr/share/i18n/locales/translit_neutral:15: non-symbolic character value should not be used
/usr/share/i18n/locales/translit_neutral:16: non-symbolic character value should not be used
/usr/share/i18n/locales/translit_neutral:17: non-symbolic character value should not be used
LC_NAME: field name_gen' not defined LC_IDENTIFICATION: fieldaudience’ not defined
LC_IDENTIFICATION: field application' not defined LC_IDENTIFICATION: fieldabbreviation’ not defined
LC_IDENTIFICATION: no identification for category `LC_MEASUREMENT’
LC_CTYPE: table for class “upper”: 2475922323 bytes
LC_CTYPE: table for class “lower”: 2475922323 bytes
LC_CTYPE: table for class “alpha”: 2475922323 bytes
LC_CTYPE: table for class “digit”: 2475922323 bytes
LC_CTYPE: table for class “xdigit”: 2475922323 bytes
LC_CTYPE: table for class “space”: 2475922323 bytes
LC_CTYPE: table for class “print”: 2475922323 bytes
LC_CTYPE: table for class “graph”: 2475922323 bytes
LC_CTYPE: table for class “blank”: 2475922323 bytes
LC_CTYPE: table for class “cntrl”: 2475922323 bytes
LC_CTYPE: table for class “punct”: 2475922323 bytes
LC_CTYPE: table for class “alnum”: 2475922323 bytes
LC_CTYPE: table for class “combining”: 2475922323 bytes
LC_CTYPE: table for class “combining_level3”: 2475922323 bytes
LC_CTYPE: table for map “toupper”: 2475922323 bytes
LC_CTYPE: table for map “tolower”: 2475922323 bytes
LC_CTYPE: table for map “totitle”: 2475922323 bytes
LC_CTYPE: table for width: 0 bytes
[/code]

ricardo · January 22, 2013, 2:55pm

Your assessment is basically right. Both nfs-kernel and locale depend on the kernel source code, so this means that the 5N uses a different (hopefully newer) kernel.

What is interesting though is that whatever the new CPU is, it is fully compatible with the previous generation. Since most of my apps are statically compiled, this means that most should run just fine on the 5N. Awesome.

By the way: the fact that the old disk pack mounts as /mnt/DroboFS instead of /mnt/Drobo5N is probably on purpose for migration reasons. A stock FS has two folders inside /mnt: DroboFS and DroboNAS. As far as I can tell DroboNAS is inherited from DroboShares.

tkjazzer · January 25, 2013, 4:16am

Probably because regular techy savy but not code / app savy users struggle to barely install apps and then after installing them we have no idea how they actually make our life better or how to use them.

If you could post detailed step-by-step videos on how to install and use each and every drobo FS app you have and then post it on YouTube that would be great.

Thanks!

EDIT: here is an old How to install FS apps video but I don’t know how to use them
http://www.youtube.com/watch?v=Jlyb8J23ewk&list=UUSD-6QC1rxrZTQvYBSCUj8g&index=20

diamondsw · January 25, 2013, 5:11am

Oh, no question the DroboApps system needs an overhaul to be more useful. My issue was that they were removing support while they figure out what to do next. For those of us that have gotten it working and depend on it, having it taken away was a bitter pill. I’m extremely glad I still have support, but I can’t say I like the way this was handled.

Once they finish their new system this will all fade away and be moot, and I’ll be quite happy of that.

yoyoma · January 26, 2013, 3:34am

diamondsw, I’ve been thinking about this and while I don’t have a Drobo 5N nor an FS (I have DroboS), I have been wondering how to handle it if I did get a 5N. Because I wasn’t interested in the FS, but now with your review and others of the 5N, I wouldn’t mind learning more.
And it seems that I would want the DroboApps capability, if I did invest in the 5N. And how to offer this solution to others.

So, I am thinking about starting a company, using a DroboFS. You send me a HD, preferably 1TB or bigger, and I will install it in my DroboFS and format it with DroboApps capability. I send the hard disk back to you and you install into your Drobo 5N. Then, you start out with an “FS diskpack” of one disk. Add in all of your other disk and you are now have DroboApps support/capability.

Thank you for this idea.

diamondsw · January 26, 2013, 5:37am

Cool idea, but I think you need two disks for a valid disk pack. Although I can’t say I’ve ever tried. It would also be a time-limited company as official support will roll out eventually. Finally, you’re also tying yourself to Ext3, rather than Ext4 on a 5N disk pack.

But yes, the same thoughts had crossed my mind.

yoyoma · January 27, 2013, 3:35am

Time-limited is a nebulous word in DRI vocabulary. How long did they string me along saying the Drobov2 would support >2TB drives?

3 days short of a year From October 2010 through September 2011. If anyone remembers that thread.

bhiga · January 27, 2013, 6:36am

At least it did eventually show up. Far too many other times I was promised something and the company went away, got bought, or just gave up.

IIRC, someone smarter than me (Docchris?) had mentioned Drobo will operate with one drive. The Drobo Capacity Calculator agrees, showing that it’ll reserve half the drive for protection, and of course this doesn’t provide fault-tolerance for drive failure.

NeilR · January 27, 2013, 10:38pm

Can you imagine Synology or Netgear or QNAP introducing their 2013 line of NAS boxes and saying… “no app support for… awhile”. Strange. What are they thinking?

yoyoma · January 28, 2013, 1:28am

Surely the app supports will arrive in the next 11 months for the 5N. There’s time.

diamondsw · January 30, 2013, 8:08pm

FYI, I updated my list above - both CrashPlan and stgt (userland iSCSI target) work fine, although CrashPlan doesn’t handle non-ASCII characters well as locale support is borked at the moment.

diamondsw · February 19, 2013, 12:32am

Okay, now that ricardo’s outfitted with a shiny new 5N, I can commence asking for updated bash and locale DroboPorts.

ricardo · February 19, 2013, 8:11am

Hehehe… normal apps will be no problem. Although DRI has not released any information about the SDK, I managed to figure out what I needed from the device itself. Not much different than before, really.

As for kernel-dependent apps (such as nfs-kernel and locale), that is a bit more complicated. To compile those I need two things:

The kernel source code, and;
The configuration used to compile the kernel.

The good thing is that the kernel config is available from the device itself. Just type “zcat /proc/config.gz” and you can get your own copy. Now we just need a copy of the kernel source code.

Technically speaking DRI must provide the source for anyone who asks for it, since it is GPL software. Anyone care to give it a try?