Anyone try firmware 3.3.0 yet? The release notes are vague as usual.
I have it running.
There is a major overhaul of the DroboApps support. I’m really happy about it.
I notice that it’s numbered 3.3.0, not 3.2.4 as I was expecting. The release notes mention updated packages but not bug-fixes (though that would mean admitting to the presence of bugs in the first place!). I’ll be shutting mine down for a month as I’m going away. Perhaps 3.3.1 will be out by the time I get back.
My Drobo is running on 3.3.0, too… but I have not found any information about changes / features in “DroboApps 1.2”. Pretty useless to give this information in the release notes if there is nothing explained or to be found about this.
with fw3.3.0 for 5N, to the normal end-users … there is no much noticeable changes.
The “major” changes to fw3.3.0 for 5N is more towards DroboApps developers. As not with fw3.3.0, DroboApps developer framework is updated to so called “v2.1” format.
- with DroboApps v2.1 format, DroboApp developer can now “code” dependency modules that are needed and it will be downloaded as well.
For normal user, actually the noticeable changes as actually in the updated Dashboard v2.6.10 … which is released along with fw3.3.0 for 5N. With Dashboard v2.6.10, normal user will see there are NOW more DroboApps available and listed. All DroboApps has been updated.
- Noticeable DorboApps —>
ownCloud, pydio (Both are remote access packages for remote accessing 5N… very much creating your very own “Dropbox” with a Drobo 5N)
mysql, wordpress, etc…
I should have explained it better. To extend on what don said:
Crashplan should finally be easy to install. SDK 2.0 requested dependencies to be declared, but it did not do much with the information. Now it will download and install the dependencies automatically! Wordpress, for example, requires MySQL to be installed and a database to be created. All of this is handled automatically.
/usr/bin/DroboApps.sh has a lot of new functionality. Now it can download apps and install apps from the command line. You can list apps from the repository, do proper semantic version checks, and even ensure that a minimum app version is installed. Apps can now be properly uninstalled, and uninstall checks that no dependencies are broken.
Many apps have an “about” page, which explains a lot of the basics for each app, and how to proceed from there.
Full disclaimer: I have been working with the good folk at Drobo to get as many of my DroboApps in the official repository. This will be an ongoing partnership, so expect more apps to come.
Just want to highlight, there might be a potential issue with some of DroboApps. But again… i might be wrong.
- Say a user previously has Transmission, Plex DroboApps installed. This is done before fw3.3.0 and Dashboard 2.6.10.
- In this case, the Apache DroboApp installed along is v1.3.x
- Now user upgraded to fw3.3.0 and Dashboard 2.6.10.
- Existing Transmission and Plex still works fine as the existing Apache v1.3.x Include Config still has entires point to the WWW of each DroboApp.
- The new fw3.3.0 and Dashboard v2.6.10 includes many newer DroboApps such as ownCloud (for example).
- These newer DroboApps seems to install newer Apache2 DroboApp.
- Apache2 DroboApp is a full blown package with most mods and PHP support.
*In this case, when a user installed DroboApp such as ownCloud to existing 5N, it seems not to be working properly. Click on the “configure” button on the Dashboard shows a empty web page. By manually go to a browser and enter the web UI setup of ownCloud again leads to empty page.
I did some drill down… I noticed that newer DroboApps ownCloud will need Apache2 (PHP Support etc). For a new fresh setup, Apache2 DroboApp will be auto download and installed and config the Apache to ownClod www include. No issue here.
But if there is already older Apache 1.3.x DroboApp in the /mnt/DroboFS/Shares/DroboApps folder… the installer script thinking there is already Apache. But is a older version not Apache2.
The only way is to update the older Apache 1.3.x DroboApp to newer Apache2 DroboApp.
I’m not sure I understand. Are you saying that installing ownCould won’t force an upgrade of apache 1.3 to apache 2? If that is the case then that is a bug. The install script does a version check on apache, and updates as needed.
I had an issue when I attempted to install ProFTPd after upgrading the firmware and dashboard. The configure page was blank or not found (can’t remember). I noticed after SSHing into the Drobo5N that the original apache was still there. I deleted the apache folder in DroboApps and then reinstalled ProFTPd. It seemed to have gone ahead and redownloaded the new apache and then everything worked “fine”. I say fine because there was a bunch of other issues with installing the new apps (would get application install errors) or getting the apps themselves recognized in the dashboard as Drobo certified (got the generic triangle with exclamation for a while, still do but not often). It seems everything has settled now.
Yup… what i did was the same as isaacrdz. Force delete older Apache1.3.x and uninstall ownCloud and reinstall ownCloud. And this will properly install the correct Apache2.
Maybe the version check fail … i’m not sure yet as I have not yet look into the all the scripts
Thanks for the feedback. I think the solution is to force the apache update. The old apache is way overdue for an upgrade anyway.
Would it be possible to make the Apache package appear on the Drobo Dashboard as a Drobo certified app?
Since updating to the new firmware I cannot SSH in as root. I mean I try to login as root but neither my previous root password nor the default root password seem to work. I know traditionally FW updates reset the root password back to the default “root”, and I know this new FW I should be using sudo with the admin user but I want to make sure the root password is secure.
I’ll pass it along. I know that traditionally the apache app has been hidden to prevent people from stopping it, as this would break many other apps.[hr]
That is the beauty of it. By default the root accout is disabled and its password is blocked. It is impossible to login as root by default on 3.3.0. This is the root line on /etc/shadow (where the passwords are stored in 3.3.0):
The ‘!*’ means account locked, and no password authentication.
The other files of interest are /etc/sudoers:
root ALL=(ALL) ALL %wheel ALL=(ALL) NOPASSWD: ALL #includedir /mnt/DroboFS/System/sudoers.d
This means members of the ‘wheel’ group can sudo without password, and any sudoer config in ‘/mnt/DroboFS/System/sudoers.d’ is included as well.
Just to make sure that there is no funny business, here’s the default ‘/etc/group’:
root:x:0:root daemon:x:1:daemon wheel:x:10:root nobody:x:99:nobody nogroup:x:99: avahi:x:100:avahi
Group ‘wheel’ only contains root by default.
The content of ‘/mnt/DroboFS/System/sudoers.d’ is a single file named after the current admin user:
admin ALL=(ALL) ALL
The admin account can sudo, but a password is required. All the files in that folder are removed when a new admin account is defined.
Oh this is truly fantastic! No worries of root:root logins after a FW update if I forget to go in and change it.
So far I’m loving the new FW and apps and I have a feeling that’s in no small way thanks to Ricardo! Also respect and props to Drobo for continuing to rock on!
The best part for me is that now the security of the system is in my hands. If I ever get hacked is because I chose a bad password for the admin account. Well, there is still the problem that most DroboApps run as root, but we’ll get to that eventually.
You are very welcome, but I certainly can’t take all the credit. The Drobo engineering team is awesome.
I don’t suppose the new DroboApp framework (and updated Perl DroboApp) will allow for things like a self-hosted compile chain so I can finally load CPAN modules?
I’ve been working on a perl cross-compiler, so I guess it is the next best thing?
If there’s a relatively simple way to go about creating the modules, then thank heaven. I still run a bajillion scripts on a “real” computer simply because I can’t run them locally on the Drobo. LWP::UserAgent is a biggie for me, but there are always others. Meaning, you’ll never cover all the modules people might want by your lonesome.