A Drobo is a cool little storage unit where you just put disks in, and it takes care of figuring out how to protect you from data loss. You do not, like other raids, have to install matching disks. You do not, like other units, make arcane decisions about how the data is laid out. It pretends to be just a pile of storage, and does the smart thing you would have done if you had taken the time to put your mind to it.
So you bought a Drobo and you want to use it under linux. Great! Plug it in and Go! Really! It can be used just as a normal disk. Plug it in like any USB thumb drive. If you are an old Linux hand, then just use a partitioner, such as parted, and build an ext3 file system and set your mount point. see the Setup section for details on manually setting things up from the command line without any special software. For those with other tastes, there is also a GUI that can take care of it:
[ Screen Shots ] [ Download ][Links and Help][ Index] .. image:: droboview_prototype4.png
You can use Drobos without any special software. The blue capacity lights will fill up as the disks fill. When it gets too full, Drobo will ask for another drive with its drive lights. Just feed it drives when it asks, and you are good to go. So what is the dashboard good for?
- If you cannot see your Drobo, it can tell you what the lights would tell you.
- You can check if there is newer firmware available, and update it.
- You can see information about the hard drives in the Drobo without taking them out.
- You can change the drobo's settings from their defaults (like a 2 TiB LUN size)
- If you are using a DroboPro, then there are many settings (ip address?) you might need in order to configure it properly for use.
So that is where drobo-utils, the linux dashboard, comes in.
[Index]
Drobo-utils is a set of linux tools to query and manage Data Robotics Drobo storage systems. If you fire up drobom view, it should look familiar to those who have seen the dashboard on other operating systems. Drobom view is built on a little programmer interface which can be installed on the system and used by other applications as well. For experienced Linux hands, there rest of the command line interface is provided by other sub-commands of drobom, and offer the same functionality as the view graphical interface. There is also a python API.
On Ubuntu 9.10 [1] or later (or Debian unstable or other debian derived distributions), drobo-utils is included in the repositories, and installation from a shell prompt is simply:
% sudo apt-get install drobo-utils
to run at least the command line utility. Users on servers often want only command line functionality. On the other hand, to enable the graphical user interface, one more package must be installed:
% sudo apt-get install python-qt4
That is the easiest installation method, this method ensures that any packages required are automatically installed on the system as part of the above installation. On other distributions, or if the version in the repositories is too old, more complicated methods might be needed. For all other installation methods, one must ensure the packages that drobo-utils requires are installed. These packages are called Dependencies.
| [1] | Drobo-utils is developed for release on the stable version of Kubuntu at the time it is released. Development started on kubuntu 7.10 and continued to 9.10 at the end of 2009. Any similarly recent distribution ought to do. The package is accepted into Debian unstable, so all debian derived distributions (debian, *ubuntu, MEPIS, PCLinux-OS, etc...) should inherit the package in due course. |
Before one can install drobo-utils itself, the other packages needed are something like those below (these examples are ubuntu packages, names may vary on other distributions):
python -- interpreter for python language parted -- partitioner, usually included with the distro.
If using Redhat Enterprise Linux (RHEL, aka. CentOS, Scientific Linux etc...), which have python 2.4 [2], then the following are necessary:
python-ctypes -- module for C-interface
| [2] | I'm not sure that python-2.4 will work, for other reasons. the utility is built on python-2.5 and python-2.6 and it should work on them. python-2.4 is not tested. python-3 will definitely not work. |
On RPM-based distros (such as Redhat & SuSe), it would more likely be 'yum' instead of 'aptitude' and some of the package names will change. A typical difference is that packages for developers have the -devel suffix on Redhat derived distributions, instead of the -dev favoured by debian derived ones.
Here is an example from fedora 7 (courtesy of help4death on the google group):
% yum install python % yum install PyQt4 % yum install python-devel
NOTE: if X or QT is missing, it will only disable the GUI. Line mode will work without issues. The package should work fine on headless servers using only the command line.
Once dependencies are satisfied, one can install the latest stable package manually.
Point a browser at: http://sourceforge.net/project/showfiles.php?group_id=222830
where the most current packages are available. after downloading a .deb, it is simply a matter of:
# dpkg -i drobo-utils-<version>.deb
done!
Redhat/Fedora users. alien may be used to convert the package. I don't know if it works. Someone to take on RPM packaging would be very welcome! This is a pure python package, so the chances are good that it does work without issue.
Assuming the dependencies are installed/satisfied, the package will actually run fine without being installed in any systemish places. Source code can be directly downloaded run it explicitly from the directory.
Point a browser at: http://sourceforge.net/project/showfiles.php?group_id=222830
download the .tgz preferred, then unpack it:
# tar -xzvf drobo-utils-<version>.tgz # cd drobo-utils-<version> # ./drobom status
for all of the examples in the manual one just needs to prepend './' before drobom.
When a new model comes out, or the stable version is missing a feature, one may elect to follow along with the latest development version. installation of git, is necessary, then use it can be used to get a copy of the source tree:
# apt-get install git # git clone git://drobo-utils.git.sourceforge.net/gitroot/drobo-utils/drobo-utils # cd droo-utils # ./drobom status # git pull
This gives a read-only copy of the source code that can be updated with the latest changes with 'git pull'. One can also select any stable version of drobo-utils by use of 'git branch -r', and 'git checkout'. For details, consult git documentation.
So, one way or another, drobo-utils is installed. The next step is to try it out.
The first item to verify after installation is to invoke the command line interface (CLI.) and see if something sensible happens... on my system with a drobo[#sdz] the following happens:
% sudo drobom status /dev/sdz /drobo01 100% full ( ['Red alert', 'Bad disk', 'No redundancy'], 0 ) %
| [3] | in examples, drive always changed to sdz to avoid copy/paste errors. |
very scary, but my drobo is in bad shape right now... normal result is: [] as a status, which means there is nothing wrong. To get all kinds of information about the drobo, try 'drobom info.' You can then invoke it with no arguments at all which will cause it to print out a list of the commands available through the command line interface.
Once the command line functionality is verified, and assuming python-qt4 is installed:
# drobom view
as root starts a GUI for each drobo attached to a computer. There are various tabs to allow one to obtain information from the Drobo, and also change its configuration. For example, one can use the Format tab of the GUI to partition the device and create a single file system for a given LUN.
There are two choices to make when setting up a Drobo: file system type, and LUN size. For a discussion of these choices, please consult: LUNSIZE fits all and Filesystem Choice.
This section provides an illustrative example of the most common configuration. An ext3 file system is built on a Drobo with whatever LUNSIZE is already in place. The GUI and line modes produce exactly the same result, and simply execute standard linux partitioning using parted, and the appropriate file system builder for the type in question. Sample CLI run:
PleaseEraseMyData# drobom -d /dev/sdz format ext3 peter@pepino:~/drobo/drobo-utils$ sudo ./drobom format ext3 /dev/sdz - Drobo disk pack 00% full - ([], 0) preparing a format script for a ext3 file system as you requested OK, I built the script but nothing is erased yet... You can have a look at it with: cat /tmp/fmtscript If you are really sure, go ahead and do: sh /tmp/fmtscript WARNING: Ready to destroy all your data. Continue? (y/n) n Phew... You stopped just in time! peter@pepino:~/drobo/drobo-utils$ # cat /tmp/fmtscript #!/bin/sh parted /dev/sdz mklabel gpt parted /dev/sdz mkpart pri ext3 0 100% parted /dev/sdz print; sleep 5 mke2fs -j -i 262144 -L Drobo01 -m 0 -O sparse_super,^resize_inode /dev/sdz1
The above sets up the drobo as one big partition, with a label that says it ought to contain an ext3[#mke3fs] file system. For an NTFS file system, write ´ntfs´ in place of ext3. The next step is to add the file system into the partition. while parted's are instantaneous, the mke2fs takes a while, just have a little patience, it´ll be fine. The ´coffee is hot´ disclaimer is necessary at this point:
WARNING: THE FOLLOWING LINES WILL ERASE ALL DATA ON YOUR DROBO! WARNING: NO, IT WILL NOT ASK ANY QUESTIONS! WARNING: ASK YOURSELF, before you start: ARE YOU SURE? WARNING: AFTER THE SECOND LINE, YOU ARE TOAST. WARNING: BEST TO BACKUP YOUR DATA BEFOREHAND... sh -x /tmp/fmtscript
(For an ntfs file system, use mkntfs -f -L Drobo01 /dev/sdz1 ... For ext3, be prepared to wait[#mkext3time]_ )
| [4] | The proper command to build an ext3 file system is mke2fs -j. This confuses people who wonder why one doesn't use some sort of ext3 mkfs. There isn't one, an ext3 is an ext2 with a journal. |
| [5] | mke2fs takes a very long time to run, on the order of ten minutes per Terabyte. the display format button just turns red while the format is in progress. Have not determined a method to monitor progress yet from the GUI yet. other file systems are much more quickly created, so less of an issue. |
Sample run:
root@alu:~# parted -i /dev/sdz
GNU Parted 1.7.1
Using /dev/sdz
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted) mkpart pri ext2 0 100%
(parted) quit
root@alu:~# fdisk /dev/sdz
GNU Fdisk 1.0
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.
This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License for more details.
Using /dev/sdz
Command (m for help): p
Disk /dev/sdz: 2199 GB, 2199020382720 bytes
255 heads, 63 sectors/track, 267349 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdz1 1 267350 2147488843 83 Linux
Command (m for help): q
root@alu:~# mke2fs -j -i 262144 -L Drobo01 -m 0 -O sparse_super,^resize_inode /dev/sdz1
mke2fs 1.40.8 (13-Mar-2008)
Filesystem label=Drobo01
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
8388608 inodes, 536870886 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
16384 block groups
32768 blocks per group, 32768 fragments per group
512 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@alu:~#
root@alu:~# mount /dev/sdz1 /mnt
By default, Drobo creates a separate 'disk' visible to the computer for every 2 Terabytes (TiB) of parity-protected capacity on the unit. The natural usage that a drobo invites in users is to have a single, large device covering all the data on device. For example, on Mac OS/X, users often create 16 TB LUNS on HPFS. This allows all the storage to fit on one large pool. The downside of larger LUNS has to do with startup time, and the time to perform a file system check.
Under Linux unfortunately, If you have a first generation Drobo, you should limit the volume size to 2 TiB[#gen12TB]_. It is hoped, but not confirmed, that later products support LUNS larger than 2 TiB on Linux. Drobom view therefore limits lunsize to 2 TiB for the moment. The command line interface can be used to create larger LUNS, at your own risk...
- linux tools which aren't 2TB ready... to exceed 2 TB, you need to:
- -- use GPT partitions, which aren´t supported by older fdisk
- versions. Tools based on libparted work fine, mostly.
- -- gparted fails, and seems to have a 1 TB limit on devices.
- (bug #524948 reported to bugzilla.gnome.org) It's just the GUI, as libparted is fine, and other tools based on it still work.
-- Windows XP does not support LUNS > 2 TiB
| [6] | Many tests have been performed with first generation products and several different failure modes have been found when exceeding 2 TiB. Data Robotics has addressed several failure modes, via fixes to the kernel in 2.6.24, and for firewire in 2.6.31, and continues to address them in later generation products. |
Drobos work well under linux with ext3. You can, of course set up an NTFS or HPFS+ or FAT32 if you really want, but it seems actively counter-intuitive on Linux. Have not tested HPFS, but ntfs-3g works fine as well. Unless you are going to physically move the disk to between systems, the native (ext3) format has many advantages, most significant being speed.
Drobo-utils depends on the linux generic scsi layer. I suspect that there is just a basic ethernet connection now, and you a few additional driver layers set up before it will work. You need to configure the iscsi driver to recognize the device. (This information is based on a post by Lemonizer on the Google Group 2009/05/16)
First, connect the Pro via USB, and manually configure the ip of the dbpro:
# drobom info settings # drobom set IPAddress 192.168.2.80 # drobom set NetMask 255.255.255.0 # drobom set UseStaticIPAddress True
The next step is to disconnect USB, and connect by iSCSI:
2. Install open-iscsi (http://www.open-iscsi.org/): sudo apt-get install open-iscsi 3. Connect the dbpro to host machine via iscsi 4. Query dbpro's id: sudo iscsiadm --mode discovery --type sendtargets --portal 192.168.2.80 5. Copy the id string returned by iscsiadm, something like "iqn.2005-06.com.datarobotics:drobopro.tdb091840080.node0" 6. Connect to the dbpro: sudo iscsiadm --mode node --targetname iqn.2005-06.com.datarobotics:drobopro.tdb091840080.node0 --portal 192.168.2.80:3260 --login
If everything went well, your dbpro should show up under /dev. Also check /var/log/messages to confirm that the iscsi device connected successfully. After that, drobo-utils should be able to detect the Drobo and manage it over ethernet/iSCSI.
(source: http://groups.google.com/group/drobo-talk/browse_frm/thread/453e02e105e9b41?hl=en )
Some people reported data corruption. This link claims to fix one such issue: http://www.drobospace.com/forum/thread/13951/Dropped-iSCSI-connections/?page=2#24792
Upgrading firmware is pretty self-explanatory in the GUI. the first time you press the Update button, it checks to see if a new firmware is available. If it there is newer firmware, it offer to upgrade, with suitable prompts. Similarly, the line mode interface has two commands to deal with firmware, fwcheck will tell you if an upgrade is required. the fwupgrade will do the job. It takes a few minutes, and prints a status you you can see how it is progressing. Have patience:
root@pepino:/home/peter/drobo/drobo-utils/trunk# drobom fwupgrade validateFirmware start... Magic number validated. Good. 484 + 2937552 = 2938036 length validated. Good. CRC from header: 4260378881, calculated using python zlib crc32: 398201869 yeah, the header CRCs do not match. For now they never do ... ignoring it. CRC for body from header: 1852877921, calculated: 1852877921 32 bit Cyclic Redundancy Check correct. Good. validateFirmware successful... writeFirmware: i=484, start=484, last=2938036 fw length= 488 . wrote 32768 bytes... total: 33252 wrote 32768 bytes... total: 66020 . . . wrote 32768 bytes... total: 2720228 wrote 32768 bytes... total: 2752996 wrote 32768 bytes... total: 2785764 wrote 32768 bytes... total: 2818532 wrote 32768 bytes... total: 2851300 wrote 32768 bytes... total: 2884068 wrote 32768 bytes... total: 2916836 wrote 21200 bytes... total: 2938036 writeFirmware Done. i=2938036, len=2938036 root@pepino:/home/peter/drobo/drobo-utils/trunk#
when it's done, you can check if it worked using:
root@pepino# drobom status /dev/sdf - 00% full - (['New firmware installed'], 0)
If the status is like that, then do:
root@pepino:/home/peter/drobo/drobo-utils/trunk# drobom shutdown
lights will flash etc... wait until Drobo goes dark. Wait another five seconds, then un-plug the USB / connector.
Plug it back in, and wait 10 seconds. it should start up with the latest firmware available for your drobo.
The drobom commands, like DRI's dashboard, will normally get the latest and greatest firmware and upgrade. If you have the need, you can load arbitrary firmware from the CLI with fwload command.
Those worried about safety of using this software should know: it was developed with assistance from the vendor (Data Robotics Inc.), and in every case, based on vendor documentation, and with at least encouragement, if not outright support. For each release, a QA.txt file is built, demonstrating the functionality tests run. There are multiple checksum verifications built into the firmware upgrade process, so it is next to impossible to brick a drobo using the tools. Drobo-utils verifies firmware checksums before attempting to upload the image to the device, and the device checks the firmware against the checksums as well. New firmware is loaded into an alternate location from the currently active one, and if activation of the new firmware fails, the drobo will simply boot the old one.
On the other hand, common sense rules do apply. Setting the LUN size, or re-formatting a Drobo will erase all your data whether you do it on Linux or any other operating system. These are power tools, and they can do some damage to your data if used without proper care. For example, the reliability of any storage unit does not reduce the need for backups it only makes doing them easier. A Drobo is an excellent place to put backups, but not a substitute for them. Backups are the only way to address error 18 (the number of inches in front of the keyboard the source of the issue lies.) and no storage unit can protect against fire or flood.
Drobo has been tested with every old firmware version. Any Drobo should be upgradable to modern firmware using the dashboard.
for Drobo v1's (only models available to me used for QA)
- NOTE: really need at least 1.1.1 to use Linux & ext3.
- just use the tools to upgrade your firmware ASAP.
- 1.01 - very old... bad idea to install this, need to write
- a script to get out, because it isn't in the revision table. not much works except firmware upgrade. DO NOT USE. UPGRADE ASAP
- 1.0.2 - works ok in CLI And GUI to view, and upgrade firmware.
- DO NOT USE. UPGRADE ASAP
- 1.0.3 - GUI and CLI work OK, can upgrade firmware.
- Used ntfs3g for a few months under ubuntu 7.10 Linux. Used 2 TB LUN, with 1.5 TB of physical space available. DO NOT USE. UPGRADE ASAP
- 1.1.0 - dashboard works no issues.
- from this point, you don't seem to need to unplug the USB connector to complete the upgrade.
- firmware prior to here deals badly with ext3.
- 1.1.1 - 1.2.4 works without issues.
- ('name' not supported by firmware)
1.3.0 - works without issues. 1.3.5 - works without issues.
To find Drobo on a system, drobo-utils queries all the attached devices for indications it is made by Data Robotics. These strings change from product to product. If your (new model) of Drobo is not detected, then run the command line interface with the hardware detection debugging output turned out. like so:
# drobom -v 16 status examining: /dev/sda id: (0, 0, 0, 0, 'ATA ') rejected: vendor is ATA (not from DRI) examining: /dev/sdb id: (2, 0, 0, 0, 'ATA ') rejected: vendor is ATA (not from DRI) examining: /dev/sdc id: (8, 0, 0, 0, 'Drobo ') rejected: vendor is Drobo (not from DRI) returning list: [] No Drobos discovered
Here you see that the vendor string is 'Drobo' which was not a known vendor string at the time this example was run. so then try:
# drobom -s Drobo status
In other words, take the unknown vendor string and feed it as -s option to tweak detection of drobom. Your drobo will likely then be picked up.
LUN is an abbreviation of 'Logical UNit'. The origin of the term is SCSI[#SCSI]_ terminology. When RAID units became too large for support in the past, and were sub-divided to present smaller units the operating system. The default LUNSIZE on Drobos is 2 TiB (adjustable using the tools.) If more disk space (after allowing for parity/redundancy) than LUNSIZE is installed in a unit, Drobo will show a second (or even third) LUN. Each LUN shows up in Linux as a separate disk (examples if the first LUN shows up as /dev/sde, the next will be /dev/sdf, then /dev/sdg.)
If you think you should see multiple LUNS and you don't, you might have a look at some kernel settings: make sure that scsi_mod kernel module is loaded, make sure /sys/module/scsi_mod/parameters/max_luns is > 1.
Drobom view will start up one GUI per drobo, regardless of the number of LUNS. If asked to format, all LUNS for the device will be formatted.
| [7] | Small Computer System Interface. A ubiquitous standard for computers to communicate with storage hardware. SCSI includes hardware cabling specifications, which are mostly obsolete, but what remains is the "command set", the language used by the computer to make requests to the device. In that sense, All Drobos are SCSI devices. The SCSI commands are tunnelled within other protocols used to transport data between computer and device (Firewire, USB, eSATA, and, yes... ISCSI) |
drobom view isn't suited to run continuously for long periods, as it has a memory leak... total foot print starts out at 32M with a 15 MB resident set size, of which 10 MB are shared, so only about 4M of real memory consumed. but the RSS grows at about 2MB/hour.
29m 11m S 1 2.9 9:44.50 drobom view
best to restart it daily, or use it when necessary, but not leave it on for days.
After you resize luns, drobom view gets confused, you need to exit and restart.
We have a report that dumping diagnostics does not work over firewire. Work-around: connect via USB.
who did what:
Peter Silva: wrote most all of it. Chris Atlee: the proper debian packaging. Brad Guillory: some help with diagnostics and patches. Joe Krahn: lots of inspiration. Andy Grover: some elegance cleanups. Sebastian Sobolewski: DroboPro patches, and testing.
Testers (of DroboPRO): robj, Sebastian (aka Tom Green), ElliotA, Andrew Chalaturnyk
version 9999, somewhen
copyright:
Drobo Utils Copyright (C) 2008,2009 Peter Silva (Peter.A.Silva@gmail.com) Drobo Utils comes with ABSOLUTELY NO WARRANTY; For details type see the file named COPYING in the root of the source directory tree.
This software is copyright under GPL. See near end file for details...
This is a pile of random useful bits for developers. (aka notes to myself ;-)
Project Source code is managed using a git repository provided by sourceforge.net. Git ( http://git-scm.com/ ) provides a fully distributed development model, so one can exchange patches arbitrarily among developers. On the sf.net repository, the 'master' branch is the final integration target for future releases.
the following checks out the master branch of the source code tree and puts it in the drobo-utils subdirectory of the current tree.
git clone git://drobo-utils.git.sourceforge.net/gitroot/drobo-utils/drobo-utils (read-only)
git clone ssh://username@drobo-utils.git.sourceforge.net/gitroot/drobo-utils/drobo-utils drobo-utils (to be able to patch)
Before doing Any commits, ensure that the author fields are appropriately set. One can obtain patches applied to the branch with git pull, and commit patches for distribution with git push.
To build the package from source, there are a number of other packages needed:
boule% sudo aptitude install debhelper python2.5-dev boule% sudo aptitude install python-docutils boule%
The second line only required to build documentation. On the other hand, to get a complete list of packages you need, it is best to use a shell window to grep in the Debian package control file (which defines what the dependencies are for the build system):
peter@pepino% grep Depend debian/control
Build-Depends: debhelper (>= 5), python2.5-dev, python-docutils
Depends: ${shlibs:Depends}, ${misc:Depends}, parted
peter@pepino%
To ensure the correct author on patches created, make sure to set your author settings. Something like the following is appropriate if you use a single identity for all your code contributions:
boule% git config --global user.name "firstname lastname" boule% git config --global user.email "developer@sourceforge.net" boule%
Others may wish for the identity to be associated with each project.
Sometimes, when there are issues, the correction gets checked in, but there hasn't been time to do a full release process. If you really need the fix, then your only option is to get it from the developers' git repository. If you are told 'it is in git', that refers to the git source code management system, and the server for that is at sourceforge.net. How to get it:
# git clone ssh://developer@drobo-utils.git.sourceforge.net/gitroot/drobo-utils/drobo-utils mine # cd mine # go into the source directory you downloaded # ./drobom status # try it out... # python setup.py install # install it in system places... # drobom status # try it out... # git pull # get any changes made since the git clone was done. # python setup.py install # install the changes in system places.
Sample checkout of a stable version. To view available branches:
% git branch -r origin/HEAD -> origin/master origin/master origin/noC origin/peter origin/r0.2.1 origin/r0_3_3 origin/r0_4_0 origin/r0_5_0 origin/r0_6_0
Where a version is something like r0_4_0. then you can pick anyone to work with:
% git branch r0_4_0 -r origin/r0_4_0 Branch r0_4_0 set up to track remote branch r0_4_0 from origin. % git checkout r0_4_0 Switched to branch 'r0_4_0' %
When you use git to get a tree, it keeps copies of metadata to be able to track changes. If you want a copy that is contains no git cruft, rm -rf .git in the root of the source tree.
If you are mixing downloaded packages and source installs, check out the next section for gotchas.
The 'setup.py' script, mentioned in the previous section, is a convention from the distutils python packaging system. distutils installation is slightly different from installation from debian packages. There doesn't seem to be a distutils way to remove a package. touch all the files, do an installation, then manually remove the files it installed.
drobo-utils has been picked up for inclusion in debian. The "real" packaging for debian packages is kept in a separate tree, and maintained by debian developers.
The debian/ setup puts stuff in /usr/sbin while setup.py puts things in /usr/bin. Python install does not install man pages either, which the dpkg takes care of. The libs are placed differently too. haven't reviewed for other conflicts, least confusing to use one or the other method on a system.
(if you do distutils install, then remove the debian package via: dpkg --purge drobo-utils)
Procedure:
1 - make a branch # assuming you have a local repository... git branch <branch> # creates the branch, from the cwd (ought to be master) git checkout <branch> # switches current dir to the branch. 2 - Stamp the branch with version vi CHANGES.txt # complete change manifest for release vi debian/changelog # copy manifest from txt, add signature. vi setup.py # edit version vi Drobo.py # edit VERSION 3 - Build packages for testing & Install them. (see separate recipe.) 4 - Run QA. Record results of release tests in the branch (QA.txt) As new tests are created, modify QA.txt on trunk for to keep references for the next release. 5 - Commit & Push QA'd branch git commit -a git push origin origin:refs/heads/<branch>
QA.txt is a quality assurance log. The version on the trunk of the releases indicates the QA procedure to be applied to the next version during the release process. Since a branch is created for each release, the version of QA.txt acts as a quality log for that release. so one can do a git checkout, or git export to get the quality log for any release (QA.txt introduce in version 0.4.0)
Assumes you have installed the Build dependencies:
# obtain a fresh tree % git clone ssh://user@drobo-utils.git.sourceforge.net/gitroot/drobo-utils/<version> drobo-utils-<version> % cd drobo-utils-<version> % rm -rf .git # get rid of Git cruft, yielding a raw source tree. % chmod 755 debian/rules # I dunno why the permissions are wrong... # this debian/ config is just for non-distro packages. # builds for debian and Ubuntu. % dpkg-buildpackage -rfakeroot % cd .. # rename it for whatever distro is appropriate... % mv drobo_utils_0.3.3-1_i386 --> droboutils_0.3.3-1_i386_ubunutuIntrepid.deb # rebuild the source tar because it will have the 'debian' link in it. % cd drobo-utils-0.99.9 % rm debian % cd .. % tar -czvf drobo-utils-0.3.3-1.tgz drobo-utils-0.99.9
apply QA tests. as per QA.txt recording results there.
use the restructured text tools (from the python-docutils package.) to build things using:
% make doc
Have a look at Makefile for how that works. update the web site:
% scp README.html <user>,drobo-utils@web.sourceforge.net:htdocs
when running two fw uploads, the second one will not run easily. need to wait for transaction to timeout... perhaps randomize id? did randomization, did not change anything...
partition type should pre-select in Format dialog...
memory consumption on the GUI. still chews up 4 MB per hour...
STANDARD menu entries for droboview...
-- there should be some sort of service integrated with dbus-hal -- not sure that a GUI is needed at all. but if it is, it should be a DBUS client. -- how does authentication work in DBUS?
of interest: -- python bindings for parted... http://dcantrel.fedorapeople.org/pyparted/
Revision date: 2009/05/19
copyright:
Drobo Utils Copyright (C) 2008,2009 Peter Silva (Peter.A.Silva@gmail.com) Drobo Utils comes with ABSOLUTELY NO WARRANTY; For details type see the file named COPYING in the root of the source directory tree.
version 9999, somewhen
copyright:
Drobo Utils Copyright (C) 2008 Peter Silva (Peter.A.Silva@gmail.com) Drobo Utils comes with ABSOLUTELY NO WARRANTY; For details type see the file named COPYING in the root of the source directory tree.
[Index] Below are highlights included in each release.
add python version testing to test suite (2.4, 2.5, 2.6)
add LUN test procedure to DEVELOPERS.txt
looking at firmware based LUN creation/deletion & format.
alerts.
fix make_tarball to exclude .git and debian, like it is supposed to.
review getSubPageStatus, DMIP seems better now.
review unitstatus vs. diskpack status.
-- updated for relay out progress. -- alerting -- unified JSON interface for GUI & WUI. -- managed queueing for device (not five GUI's querying in parallel.) -- preserve option settings across reboot? (one report.) -- periodically synch. the drobo clock to the server.
versions will not recognize a drobo running 1.3.0 or later.
now allows command to be an option as well.
honored as a command-line argument (--verbose)
misc. improvements in documentation.
always.
drobom list returns a list that is easier to parse (suitable for use in backticks.)
droboview is now just a stub for drobom view. reduced overhead.
now reports VERSION id in usage. There is a -V option too.
0.3.2 release 2008/10/25
for v1, still don't understand index.txt file.
after testing, some more fixes, v2 downloads now work.
- fixes received from Brad Guillory for v2/tdz firmware downloading.
they don't do any harm afaict, don't have a v2 to test with.
added fwload directive to drobom.
added root user check to give a bigger hint.
0.3.1 release 2008/10/01
- OK I know checking for firmware updates doesn't work
right now, but I need to find out why. code seems correct. there is a bugfix for getting rid of the 'licensed' part.
- fixes for firmware validation:
- header CRC on 32bit was broken on 64bit.
- 32 vs. 64 bit kludge needed.
added ability to format Drobo
added ability to set lun sizes
added ability to set time on Drobo.
added simulation mode to Drobo.py, development aid.
some work done towards lunsize setting, but incomplete.
some work towards indicating relay out progress, not tested...
firmware uploads work with .tdz as well
works well enought upgrade old firmwares.
If more information is needed, then there are a number of resources available:
- Project -- development home page. source code there as a download too...
- README - Documentation for humans.
- Manual Pages - traditional unix style documentation (man pages)
- Group - The Google groups is the most active discussion forum
- Drobo - Who makes them
- Project - SourceForge Project
- DEVELOPERS Developer documentation
- DroboSpace - Vendor forum
- Email - The developers list, one of us will surely answer.
- Email Me - one can email me directly.
Contents
last revised: December 26th, 2009
copyright:
Drobo Utils Copyright (C) 2008,2009 Peter Silva (Peter.A.Silva@gmail.com) Drobo Utils comes with ABSOLUTELY NO WARRANTY; For details type see the file named COPYING in the root of the source directory tree.