chapados.org

If anyone out there is actually checking this site for the latest info on readynas shell access, then know that this will probably be my last post about the topic. Infrant Netgear has finally released a beta version of RAIDiator v4. Highlights include:

• RAIDiator 4 is now based on Linux 2.6.
• Remote SSH for Support is disabled by default. If you wish to enable SSH access for Support, you’ll need to install the ToggleSSH add-on.
• Root SSH support. With the EnableRootSSH add-on, you can now remote login to the ReadyNAS RAIDiator shell as a root user. Initial password for root will be the same as the current FrontView admin password. Please keep in mind that NETGEAR may deny support if you’ve enabled root access.

However, the upgrade is a one-way deal. You can't go back to v3.x with the 2.4 kernel if something goes wrong. Also, keep this in mind:

"NETGEAR Support will in no way provide support for beta releases. All support will come from this beta forum. The Jedi council will try our best to support you here, but please understand that even if have encountered legitimate bugs, bug fixes may not occur in a timely manner, and in some cases if at all. "

Should I upgrade?

It depends... If you're worried about stability, then probably not. Ironically, in terms of stability, I'm pretty sure that the info published here is probably a safer bet than upgrading to raidiator 4 if all you care about is ssh access. They apparently redesigned frontview, but who cares if you do all your administration over ssh. In the end, who do you trust more, me or Netgear? ;-) The choice is yours (see below if you're having a hard time deciding).

I personally have not upgraded my ReadyNAS yet. To their credit, they are already on the 3rd release of the beta. I will probably wait until things are looking stable to apply the upgrade.

IMPORTANT: install the Toggle SSH add-on for 3.x/4.x

One thing you should definitely do is close this backdoor security hole[1] by installing the ToggleSSH add-on. Infrant also announced this vulnerability in their ssh-based backdoor. If you connect your readynas to any kind of network, you should either disable SSH access, or login and disable root ssh login.

[1]: I want to point out that while my name is listed first on the security advisory, practically all of the work was done by Felix. He did some very clever and elegant work to obtain that information, and I was thrilled to be along for the ride.

A few people have asked if I’ve been able to compile a working kernel and run it on my readynas. I haven’t attempted this, but the lazy web has come through for all of us. Head over to 360 and learn how to compile a working kernel and install it on the box.

When I wrote the original article on how to enable shell access to the readynas, I was motivated by the need to solve my backup problems. Given the unfulfilled promises from infrant regarding ssh availability, I was also frustrated, and wanted to share how easy it was to do it yourself. After solving solving the immediate problem, I did not try to develop a more elegant solution. Fortunately, the web is a big place, and I managed to inspire someone else to come up with a better solution that doesn't require removing any drives. This person, whom I will call "D", has asked to remain anonymous.

Protocol

Here is D's method for changing the root password:

This is a simple approach that exploits the ability to create symbolic links (symlinks) while using NFS, and the ability to traverse symlinks while using AFP (Apple File Protocol). It also exploits the fact that /etc/cron.d is writeable by the admin user, which permits arbitrary crontabs to be created. This will probably require a Macintosh, or another platform which can mount AFP shares.

1. Enable NFS and AFP services (Services -> Standard File Protocols).
2. Make a share NFS write-enabled and root privilege-enabled (Shares ->NFS)
3. Make the same share AFP write-enabled for the admin user (Shares -> AFP)
4. Mount the share using NFS
5. Create a symbolic link on the share to /etc (etc -> /etc).
6. Mount the share using AFP, as the admin user.
7. Create a new crontab file in etc/cron.d/

# example listing for /etc/cron.d/passwd

* * * * * root /usr/sbin/usermod -p '$1$RVWNkJR9$CaniKWqUxyXC3ETsWKrCE1' root

1. Reboot the device, to restart cron.

Notes

This would not work if the backend software on the readynas was configured properly. It turns out that frontview, which is written in perl, makes system calls directly and executes commands as the admin user. To make life easier on themselves, Infrant allows the admin user to modify key system files such as /etc/cron.d. In fact, the entire frontview interface is owned by admin, so you should be able to mount /frontview that same way that you mounted /etc and modify any of the files that control the web interface. Now that infrant has been acquired by netgear, maybe some of this will get cleaned up. I suspect that is why infrant was promising a 4.0 release of RAIDiator that will include ssh access, and will not be backwards compatible with the current versions of the OS (3.x). Sounds great, doesn't it? Given the amount of time that it takes Infrant to actually deliver on their promises lately, I think that if you want ssh access before 2008, you should probably use the method described above.

The first quarter of 2007 is almost over and Infrant has still not released any patches that enable ssh access to the readynas. I guess they were probably too busy putting out fires caused by Windows Vista. Those poor bastards.

Judging from the responses to my cross-compiler post (a few spam messages and 1 real response), I think most people would prefer to just download pre-compiled software, rather than go through the hassle of building and using a cross-compiler. In an ideal world, I would bundle up some of the packages I’ve compiled as .deb files that could be installed with dpkg. If there is enough interest, maybe I will make some time for doing that. Until then, I’m just going to redistribute the compiled packages along with the full source code. I’ve read through the license agreements and I’m pretty sure that I’m complying with all the conditions for each package. If I’m not, please tell me. It is not my intention to illegally redistribute this software.

I usually just build things when I need them for some reason. Since I’ve been primarily concerned about backups, I’ve tried rdiff-backup and rsync with extended attributes. I will add new software to this page if/when I end up building it for the readynas. Enjoy!

(Unless otherwise noted, you can install all of the prerequisite software from the debian-sparc repository)

rdiff-backup

rdiff-backup-1.1.9-readynas.tar.bz2 md5: c029e2ab6ad6a99f6b7aec2c7be871ab

This is a great backup program. However, due to the extreme strain it puts on the meager CPU of the readynas, it is not usable on the readynas.

prerequisites: python, pylibacl, pyxattr, librsync

installation

The tar file contains the complete source code, along with the build directory containing the compiled C extensions.

1. install prerequisites
2. unpack the tarball
3. run the setup.py program (as root): sudo python setup.py install

rsync-EA

rsync-2.6.3-readynas.tar.bz2 md5: 1735165cb7ab886a089f0fc42e20766b

This is a patched version of rsync-2.6.3 with all of the patches from apple and lartmaker.nl applied. In addition, I back-ported some very minor changes from rsync-2.6.4 so that I could cross-compile the code. This version has worked well for me so far, and is my primary backup tool. The tar file contains the full source code along with the cross-compiled executable.

installation

1. unpack the tarball
2. ‘sudo make install’ to install rsync in /usr/local/bin. Alternatively, you can just copy the executable to your favorite place.

Having shell access is cool, but the real fun doesn't begin until you can build and run the software that you want on the ReadyNAS. After an embarrassingly long delay, here is the second installment of my series on Infrant ReadyNAS hacks. In this article, I'll show you how to use crosstool to build a gcc compiler on a x86 linux box that you can use to compile software to run on your ReadyNAS.

As opposed to installing a development environment on the ReadyNAS itself, a cross compiler offers a few key advantages:

1. The ReadyNAS is slow and doesn't have much memory (256 MB by default). Compiling software on the box would take a long time.
2. It requires minimal modifications to the ReadyNAS. Let's face it, at the end of the day, you probably want to use the ReadyNAS for backups, which means you probably want a stable operating system that is compatible with upgrades released by Infrant. Manually installing the files necessary for a working development environment on the ReadyNAS is neither trivial nor elegant. I'm not sure if it would cause problems with future updates, but it is certainly an ugly solution.

Your first reaction to term "cross compiler" or "cross toolchain" might be that it sounds complicated, especially for an unknown system. I'm not an expert on gcc by any stretch of the imagination. Fortunately, the people who are experts have packaged up their knowledge into a set of shell scripts called crosstool, which mostly automates the process of building a cross compiler/toolchain. In short, Dan Kegel and the crosstool contributors are my heros. They deserve the lions share of credit for their work. I'm just a user reporting results.

Resouces

1. Access to an x86 linux box with a working build environment.

2. Crosstool. Go and download crosstool v0.43.

3. Patches for glibc-2.3.2 [released] by Infrant in accordance with the GPL.

4. Time. It will probably take a few to several hours to build the tool chain, depending on the speed of your system.

Background

If you haven't already, go read the crosstool howto, I'll wait.

Crosstool configuration for Infrant ReadyNAS

Crosstool knows how to build toolchains for various combinations of glibc/gcc to run on target systems. For the purposes of configuring crosstool, we can assume that the ReadyNAS is just running vanilla sparc-linux. We already know that the ReadyNAS uses glibc-2.3.2. According to the crosstool build matrix, there are only a few versions of gcc that are likely to work.

So, there actually aren't many Infrant-specific modifications that haven't already been provided by Infrant. However, to keep your crosstool directory nice and neat, you might want to set things up as follows:

In your crosstool directory, make yourself a customized copy of demo-sparc.sh

cp demo-sparc.sh infrant-sparc.sh

I was able to successfully build gcc-3.3.6 and glibc-2.3.2, so I recommend using that combination. For example, my infrant-sparc.sh file looks something like this:

#!/bin/sh
set -ex
TARBALLS_DIR=$HOME/downloads
RESULT_TOP=/opt/crosstool
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES

# Really, you should do the mkdir before running this,
# and chown /opt/crosstool to yourself so you don't need to run as root.
mkdir -p $RESULT_TOP

# Build the toolchain.  Takes a couple hours and a couple gigabytes.
eval `cat sparc.dat gcc-3.3.6-glibc-2.3.2.dat`         sh all.sh --notest

echo Done.

Get & Patch glibc-2.3.2

If you just started crosstool at this point, it would download all necessary programs, apply patches necessary for building a cross compiler and build. It really is that easy. In our case, the only thing we want to do differently is use the patched version of glibc-2.3.2 from Infrant. Download glibc-2.3.2 from your favority Debian mirror, and create the following shell script to apply the infrant patches:

apply-patches.sh:

#!/bin/bash

VERSION=2.3.2 # version of glibc

# Patch in the Debian patches:
DPATCHES="$( grep -v '^#' debian/patches/00list | grep infrant )"
for pf in ${DPATCHES}; do
    patchf=debian/patches/${pf}.dpatch
    if [ -s ${patchf} ]; then
      echo "$patchf"
      chmod 755 ${patchf}
      ${patchf} -patch glibc-${VERSION}
    fi
done

Now unpack the tar file, apply patches, and repackage the source:

cd $HOME/downloads
mkdir infrant
cd infrant
wget http://www.infrant.com/download/GPL/glibc-2.3.2.ds1.tar.bz2
tar xjvf glibc-2.3.2.ds1.tar.bz2
cd glibc-2.3.2.ds1
chmod +x prep.sh
./prep.sh
./apply-patches.sh
tar cvf ../../glibc-2.3.2.tar ./glibc-2.3.2
cd ..
bzip2 glibc-2.3.2.tar

These commands download the glibc-2.3.2 from Infrant, unpack the debian distribution, and apply all the patches (prep.sh). The end result is a glibc-2.3.2 directory ready to be built. We then pack up the patched source directory to create a glibc-2.3.2.tar.bz2 file in the download directory. Crosstool will find this file and use it instead of downloading the vanilla glibc-2.3.2.tar.bz2.

Are these patches really necessary?

I'm not sure if this step is necessary, because I never even tried to build the cross toolchain without using Infrant's glibc-2.3.2. I know, I know, I wasn't being very scientific, but I didn't have time to mess around forever with this stuff. Building gcc and friends takes time. If you try it without the patched glibc and it works, please let me know.

Build it

cd $HOME/crosstool
sudo mkdir -p /opt/crosstool
sudo chmod 777 /opt/crosstool
./infrant-sparc.sh | tee infrant-sparc-glibc-2.3.2-gcc-3.3.6.log

You don't need to use tee, but I like to keep a log of the build.

After some time, your build should have completely successfully, and you will have a cross toolchain in /opt/crosstool.

Test it

The right way to test your new toolchain is to use crosstest. Dan Kegel has written up some very nice documentation on exactly how to test gcc using dejavu. I am guilty of not doing this yet. Sorry. The worst part is that I was holding up this article for the test results. Sorry. It seems like there is enough interest in this information to just provide it "as is" for now, with a "works for me" clause. When I get the tests done, I will post another article about testing. Until, then I can only report that it works for the limited number of userland programs that I've tried.

Build stuff

If you're not planning to run the full test suite, you should at least try building a few "userland" programs. You can start with the classic hello world:

/* hello.c : prints "hello world" */
#include <stdio.h>
int main(void) {
    printf("hello world\n");
}

This will at least tell you that you can compile a basic running program. To compile it, save the text above into a file called hello.c, then:

/opt/crosstool/gcc-3.3.6-glibc-2.3.2/sparc-unknown-linux-gnu/bin/sparc-unknown-linux-gnu-gcc -o hello hello.c

Copy the "hello" executable to your ReadyNAS, run and make sure it prints "hello world" on the screen. This works, but it's annoying to deal with the long paths. I like to wrap all the commands necessary for using the cross toolchain into a shell script. Here's an example:

#!/bin/bash

TARGET="sparc-unknown-linux-gnu"
CROSSBIN="/opt/crosstool/gcc-3.3.6-glibc-2.3.2/sparc-unknown-linux-gnu/bin"

CROSS="${CROSSBIN}/${TARGET}-"

PATH="$PATH":$CROSSBIN
export PATH

# build commands below this line
# --------------------------
${CROSS}gcc -o hello hello.c

Unfortunately, according to the crosstool website, the builduserland option is broken for the time being. I've successfully compiled rsync, Python and the C components of rdiff-backup. I promise to post those instructions soon as an example of what is possible.

[UPDATED: 22-March-2007]

I realized that I forgot to include the step for actually applying the patches from infrant. This is now included as the apply-patches.sh shell script.

The Infrant ReadyNAS NV is a great backup server or media server. However, the one critical missing feature that will make any power-user break into a cold sweat is ssh shell/root access. My initial reaction was: Huh!? I’m buying this box to store my precious data and you won’t even tell me the root password or give me shell access? Dubious. I’m sure that this has driven away many potential customers. To be fair, Infrant has promised to add this feature in late 2006, but it’s almost December and it hasn’t happened yet.

As it turns out, gaining root ssh access is trivial, you just need:

1. Logs from your ReadyNAS
2. Computer with a free internal SATA port
3. Knowledge of linux

Don’t try this at home kids

This article is not a step-by-step, copy-and-paste walk-through guide. If you are not comfortable working at a root prompt and have no clue about how linux is configured, then this article will not help you. My intended audience is knowledgeable users who want shell access, but have live data on their ReadyNAS boxes and can’t afford to poke around and screw up their backups.

The system partition

The first thing I did after unpacking the ReadyNAS (no drives installed) was to plug it, connect it directly to my laptop and turn it on. My reasoning was that if the OS runs from a flash memory card, then the system should be accessible even without any disks. This is not the case. Instead, as I had hoped, the ReadyNAS creates a system partition on one of the drives. This means that the problem is essentially the same as that one time when your friend forgot the root password to her linux box and you had to help her “break in”.

Reconnaissance

If the ReadyNAS creates a system partition on a drive, where does that partition live? I’ll give you a hint: Download the logs through frontview and look at them. The file called “partition.log” is a good place to start.

If the ReadyNAS could be booted from a CD and had a monitor and a keyboard, you would just need a linux boot CD and and you’ve have access. It’s not quite that easy, but the drives are very easy to remove. You’ll just need to plug the drive with the system partition into another computer running linux. If you don’t have a linux installed on the system with a SATA controller, try one of the live CDs from Ubuntu or Gentoo. These will even nicely with a PowerMac G5.

Now that you’ve determined where the system partition lives, shutdown your ReadyNAS and remove the drive with the system partition. Plug it in to a computer with an internal SATA controller. Turn on the computer.

Break in (through the unlocked front door)

While you were looking at the log files, you probably noticed that the system partition type is ext3, which is not surprising, since the ReadyNAS runs GNU linux. Mount the partition as ext3. That’s it. You can now modify/create/delete files. However, the engineers at Infrant are clever. Enabling shell access is not as simple as modifying /etc/passwd and putting the drive back in your ReadyNAS.

Don’t steal the marked bills

.enc files

While you’re poking around in /etc, you’ll notice some files with “.enc” extensions. These are encrypted versions of the corresponding files without the extensions. The ReadyNAS updates the .enc files after you make changes to the system through frontview. The catch is that when you boot the ReadyNAS, it apparently compares each normal file with the encrypted version. If they are different, then the encrypted version is used to regenerate the normal file. This means that you won’t be able to modify files that are managed by this mechanism. Trust me, I already tried it. For those following along at home, this rules out:

• /etc/passwd
• /etc/exports
• /etc/sudoers
• /etc/inittab

I’m sure we can all dream up a few ways to get around this “security” system. I used the method outlined below.

/root

Anything you add to /root appears to get removed when you put the disk back in the ReadyNAS and reboot the system.

Set a trap

Since the usual targets get reset when you boot the ReadyNAS, one route of attack is to plant a trojan horse that will modify these files after the ReadyNAS boot up. Fortunately, /etc/crontab is not controlled by the security encryption, which makes setting the trap trivial.

Write a shell script to add a user with uid = 0 if the user doesn’t already exist. Add a line to /etc/crontab that executes this script as root every minute or so.

Spring the trap

Once you’re happy with your changes, unmount the partition, shutdown your computer, and transfer the drive back into the ReadyNAS. Turn it on and wait for it to boot up. Wait a few minutes for the cron job to execute, then login as your new root user. You’ll probably want to change the configuration settings so that you can login as a normal user and enable root access via sudo.

Cool… now what?

Well, now you can modify any file you want, install your favorite software, and configure everything exactly the way you want. Slow down. Before you get too excited, let’s think about this for a minute:

1. The Infrant processor runs @ ~250 MHz. You’re probably not going to want to run your database-backed app off of the ReadyNAS. It can barely handle ssh file transfers without maxing out the CPU.
2. The OS is a minimal version of Debian Linux. It does not have a working build environment.

Come back and look for the next article, which will cover building a sparc-linux cross-compiler with crosstool.

UPDATE

If you arrived at this page from a search engine and you’re looking for an easier way to enable ssh access that doesn’t require futzing with hardware, read this article.

The Infrant ReadyNAS NV is an extremely capable network attached storage (NAS) device that packs some serious power into a tiny box. If you’re in the market for a RAID storage device or perhaps even a home media server, give it a look. You’ll probably be impressed.

The ReadyNAS supports up to 4 drives in RAID 0,1,5 or Infrant’s proprietary X-RAID configuration. The X-RAID technology allows you to add drives as you go and the machine automagically configures the RAID to give you redundant storage.

The ReadyNAS uses a proprietary SPARC-based CPU/motherboard, optimized for RAID in a small package. The Raidiator OS is a slightly customized version of Debian GNU/Linux. So, when you buy a ReadyNAS NV, you are actually buying a tiny box optimized for life as a home RAID storage server.

Despite the impressive features, I had second thoughts, because the readynas doesn’t provide ssh shell/root access. It also doesn’t support rdiff-backup, rsnapshot, or even a version of rsync that plays nicely with Mac OS X (see this site). Shame on Infrant for thinking that power users will want to use their pre-packaged backup solution. In the end, my need for a small-footprint RAID solution for my music library and online backups won out. I bought a disk-less ReadyNAS from eAegis and one 500 GB Seagate Barracuda ES drive from newegg. I plan on adding a second drive soon, but in the meantime…

Since I was already storing data on a stack of external hard drives, there was no immediate rush to transfer all my data to the ReadyNAS immediately. Thus, I had some time to “play” with it before using it as my production backup system. The result is a series of hacks for the Infrant ReadyNAS that I’ve put together in my spare time over the past couple months.

Outline

In the next few articles, I hope to cover:

1. The first article covers gaining root ssh shell access. Go read it now.

2. Building a cross-compiler for the ReadyNAS using crosstool

   This process is straightforward using crosstool and building on x86 linux.

3. Compiling a modified version of rsync that properly stores meta-data from HFS+ filesystems.

4. Installing Python and the necessary requirements to run rdiff-backup

   The ReadyNAS runs Debian Linux, and dpkg is installed. You can download sparc packages and install them. To compile the [latest] rdiff-backup versions required for use with Mac OS X, you’ll need the cross-compiler. This all works really nicely, except that it’s really slow.

5. For those of you that were [asking], Perl is already installed, so [rsnapshot] shouldn’t be a problem, although I haven’t tried it yet.