-- Regarding Brent's reference, the Japanese page describes how to implement NFS as a user-level driver (as opposed to kernel-level).

-- Regarding Brent's reference, the Japanese page describes how to implement NFS as a user-level driver (as opposed to kernel-level).

It is, however, incomplete in its description of what to do (you have modify the init.d scripts, etc.).

It is, however, incomplete in its description of what to do (you have modify the init.d scripts, etc.).

−

Still, using it as a springboard, I have gotten the user-level driver working on my TS, and I've been stress-testing it days without a hiccup. However, I've been only getting 2.2MBytes/sec writes using it (where I can get 4.2Mbytes/sec writes using the rsync daemon, but the rsync daemon shipped has problems with extra-long file names that NFS driver does not).

+

Still, using it as a springboard, I have gotten the user-level driver working on my TS, and I've been stress-testing it days without a hiccup. However, I've been only getting 2.2MBytes/sec writes using it (where I can get 4.2Mbytes/sec writes using the rsync daemon, but the rsync daemon shipped has problems with extra-long file names that the NFS driver does not).

While collecting the components to try and start build a cross compile toolchain I found an set of nfs kernel modules and the nfs kernel daemon here (http://downloads.linkstationwiki.net/terastation/kernel_modules/). These seem to load fine on my TS (with a change to the /etc/init.d/nfs-kernel-server to allow rpc.mountd to start). Will try and run some tests on >2GB files when I have some on there to work with.

Software for the TeraStation

I will add small software packages as .tgz here for you to install onto the TeraStation.

As a rule, you should be able to use most Debian PowerPC packages built for woody. Use ftp to access ftp.de.debian.org (or another mirror), go to pub/debian/pool/main/ and to the directory named with the first letter of what you are looking for, there you should find a directory for the package; download a suitable version (should have "woody" and "powerpc" in the name), unpack it on a Debian box using "dpkg-deb -x package.deb name-of-temporary-dir", remove any clutter (man pages) from your temporary directory, create a tar file and copy it over to the TeraStation.

(NB I wanted to upload a .tgz but the Wiki didn't let me, saying that .tgz was not an accepted image format. --Fred 12:05, 12 Dec 2005 (CET))

Can i setup publick key authentication on dropbear. If so can someone give me an example. I was able to upgrade the firmware succesffully on the Terastation Pro. I am planning to do a Public Key Authentication on my mac and use rsync for backup using ssh protocol. Any ideas?
Thanks a gazillion,
Naven

Yes you can: Create a key on your Linux/Unix workstation with:
ssh-keygen -t rsa
The public and private key will be automatically saved to the directory .ssh in your homedir.

Next: copy the text from id_rsa.pub and connect to your Terastation as root.

On your Terastation:
- mkdir /root/.ssh
- vi /root/.ssh/authorized_keys
- paste the text you copied in the step before
- save the file

Now you can connect to your Terastation by using public key authentication

Encryption, NTFS Support, and Windows Share Management

Samba

It is possible to modify the TeraStation's Samba install to properly map the System, Archive, Hidden, and Read-Only attributes for files (not directories). This modification will require you have Telnet access to your TeraStation as per the modifications previously mentioned.

The general approach is this. The /etc/samba/smb.conf file contains Samba's configuration settings. To map the attributes, we need to add the following to the global section or to the individual shares:

We also need to remove the "force create mode" and "force directory mode" entries. Unfortunately, just modifying the file is not enough because every boot, a script calls /sbin/teractrl -k which overwrites the configuration file. I noticed that most of the scripts also called /usr/local/bin/mkrsconf.pl afterwards to setup the rsync config for backup purposes, so I piggy back on that script to rewrite the Samba configuration.

Make a backup of your existing mkrsconf.pl file, and then replace the original with the new file content I have below. If you're working in Windows, you can copy the file to one of the shares under /mnt/array1, just be sure to use a UNIX compatible text editor if you don't want your newlines to get messed up. Then you can copy from there to the /usr/local/bin folder via Telnet to overwrite the original file.

The other thing you'll need to do when you're done is update all of the attributes on your existing shares since previously everything was probably created with 777 permisions, which will result in all of your files now showing up as hidden, system files. You can change the permissions from Telnet using chmod, or you can do it from a Windows Command Prompt using the attrib command.

Also of note, TeraStation generated files are created by "root", so with group permissions adjusted now you may not be able to modify attributes of files like backup logs. It's probably not necessary though as you can still read/write the content, but if you need to, you can either take care of those from Telnet by doing a chown to change the owner, or you can modify the script to also add:

One word of caution, for most configurations I think I'm picking up all of the required entries from the system configuration files. But, it's entirely possible you may have a configuration parameter that isn't currently read by the script. If so, please note the discrepency, let me know so I can update it, and make sure you update your copy to pick up the extra parameter if you need to use it in the mean time.

Once you've replaced the file, just type "reboot" from the Telnet prompt and when your TeraStation comes back up, you should have the ability to change file attributes. This will allow you to use real backup programs that make use of the Archive attribute for incremental backups.

Warning

Problems with NFS may arise, please see the discussion page for details.

Having just spent several days trying to get NFS working I can give a few tips. If you can write to the NFS share, but have problems reading from it (transfers stall or terastation randomly reboots) try disabling jumbo packets. If the jumbo packet size on all your machines doesn't match than UDP transfers such as NFS wreak havoc with the terastation. I now have the 2.03 firmware and user mode NFS (from debian PPC) working smoothly. An alternative solution would be to use TCP rather than UDP for NFS, but not all NFS implementations support this.

Alternative to NFS

After following in the foot steps of other NFS experimenters, I tried compiling my own NFSD module with TCP support. I was using the 2.4.20 kernel which comes with the OpenTera 2.12 firmware hack.

After finally getting the toolchains and code compiled, and after a battle with symbol names (the TS uses the "versioned" symbols suffixes), the NFSD w/ TCP had horrible performance and would stall out quickly. I had to reboot it once which threw the TS into it's nightmarish 12 hour raid consistency check.

My motivation for adding NFS support was so that I could perform rdiffbackup's to back up a "live" linux machine. I didn't want to loose file attributes and permissions through SMB/CIFS shortcomings.

Another alternative, while not the highest performance, but /will/ achieve the same results is to create an EXT2/3 or XFS binary image on the TS. Mount the location containing this image via smb, then use loopback to mount the FS image file itself.

I did the following: Set up a new folder for sharing called "foo", then telnet to the TS

I ran into one small problem, however. Performing dd as 'myroot' on the TS left me with incorrect owner and permission bits. Come to find out the default coreutils don't support large files. I had to install midnight commander to do the 'chmod' and 'chown'
--AxMstrLP 06:55, 11 February 2007 (CET)

Notes

Missing rpcinfo? After installing nfsd_terastation.tgz "tar -C / -xzf nfsd_terastation.tgz" the initialization script "/etc/init.d/nfsd-kernel-server" references "rpcinfo" and fails to start rpc.mountd because rpcinfo is missing and the parameters for rpc.mountd are wrong.

Edit the nfsd-kernel-server file and set the option on line 22 to:

RPCMOUNTDOPTS="--no-nfs-version"
or
RPCMOUNTDOPTS="--nfs-version"

Note line 39-40. It uses RPCMOUNTDOPTS to build an options line for rpc.mountd. Simply put on line 22 RPCMOUNTDOPTS="--nfs-version" and when you start the server, it will run "rpc.mountd --nfs-version 3".

If you get a "Permission Denied" when trying to mount an export, check to see that the reverse DNS entry resolves correctly for the server trying to mount. On the terastation, update your /etc/hosts file (optional) and create a script to reset this file every time the server boots. /etc/rc.d/init.d/networking overwrites this file.

I put in "--nfs-version 3" as I only want v3 support. I am still testing this. -- Kimbotha 10:45, 26 October 2006 (CEST)

--status: Please note that I have personally had a HUGE problem with the NFS CLIENTS when using this server. There seems to be a large degree of "retransmissions" and I/O problems as a result of communicating with the nfs server. (Run "nfsstat" on the client). If there has been any updates to the server, I'd wish they would be published! Perhaps I'll just fall back to using "smbmount" Also, this server appears to have only UDP support. NFS Clients complain with "nfs over UDP causes data corruption" (ick).
-- 12:00, November 24 2006 (SGT)

The above linked file "all-nfsd.tar.gz" seems to be for linkstation, not terastation. I believe the correct stuff is here: [2]
--Neilfred 04:46, 14 January 2007 (CET)

-- Regarding Brent's reference, the Japanese page describes how to implement NFS as a user-level driver (as opposed to kernel-level).
It is, however, incomplete in its description of what to do (you have modify the init.d scripts, etc.).
Still, using it as a springboard, I have gotten the user-level driver working on my TS, and I've been stress-testing it days without a hiccup. However, I've been only getting 2.2MBytes/sec writes using it (where I can get 4.2Mbytes/sec writes using the rsync daemon, but the rsync daemon shipped has problems with extra-long file names that the NFS driver does not).

Kudo's to Brent for pointing out the link.

I have submitted my package to OpenTera firmware guy. Bunshichi 10 March 2007

A couple of things to note here. The Terastation stock gcc/glibc is 3.3.1/2.3.2. The gcc crossbuild #:of 3.3.1 requires a couple of extra patches to compile and 3.3.6 compiles cleanly. It's unlikely #:that something would specifically require 3.3.1 so I used 3.3.6.

Also, note that the java language is not built. It does not compile without error in the crossbuild. #:It's probably trivial to get it to compile, I just quit trying because I don't currently have a use #:for it. If you get it to compile, please post the patch here.

Start the Build

First create the /opt/crosstools directory and make sure your compiling user (hopefully not root) has #:access to write files there, then:

./powerpc-603e.sh

(Go have a beer, or six. This will take awhile. On my 1.4 GHz machine, it takes roughly 4 hours #:(hey, just be happy you're not building it on your wimpy TS). It will use about 2 GB of disk space #:as well.)

Building code on the Terastation using Gentoo

This is a quick and dirty way to get a working gcc build environment on the Terastation itself.

Due to the size of the Gentoo base layout, we don't want to do this on the root filesystem, or we'll fill it up. The easiest thing to do is create a new shared folder called (for example) gentoo under /mnt/array1.

Download the 2004.1 stage3 ppc tarball from one of the Gentoo Mirrors. You will need to look in the releases/historical/ppc/2004.1/stages/ppc/ directory for stage3-ppc-2004.1.tar.bz2. Put this in the gentoo folder.

At this point, you should have access to gcc, nano, ssh, and a host of other useful tools - certainly enough to download tarballs and build applications. I've succeeded in building unfs3, openssh, and a bunch of other apps this way. Note that anything you build must either be run from inside the chroot'd environment, OR you must resolve any additional library dependencies by copying new required libs into /lib on the real root filesystem.

I did try unsuccessfully to get the whole Gentoo portage system working - which would be pretty sweet, but I kept running into problems which I think are due to the 2004.1 release being so old. Unfortunately later versions of the stage3 tarball don't work because its libs are designed to work with a 2.6 kernel.

If you've done all the steps correctly then OpenSSH should be running and also start each time you reboot the TeraStation.
The version of OpenSSH that was compiled for the Kuro Box actually has a security flaw which was corrected in newer versions of OpenSSH.
And now you can Access from Windows too your Tera with Winscp and make Tunnel with Putty. You can trick some Firewall with Putty and Tunnel :-)