SuccessStories
From NAS-Central Lacie Wiki
Contents[hide] |
edmini V2 as a Home Server
Under Construction
This is about the edmini V2, bought in 2007, single disk model with 320 / 500 / 750 GB SATA disk and ARM CPU. These instructions have also been confirmed to work with the LaCie NetworkSpace 500 GB / 1 TB.
The nicest way of adding a web browser and telnet backdoor to the edmini would of course be the built in web update function, available through the web interface. It works based on gpg signed tar files that are verified, unpacked and that can then replace particular components in the root file system. Snapshots of the previous configuration are kept in separate paritions. I have not yet tested whether these updates would interfere with custom modifications such as added binaries and shell scripts.
Here I'll describe the warranty voiding way of modifying the edmini. Remember you are doing this at your own risk and don't expect help, especially from the manufacturer, if things go wrong. Unfortunately, you need a real linux box with the possibility to connect a SATA hard drive. Yet, you can make images (e.g. with dd) of all partitions used by the system so that you are able to restore to factory defaults if you want. It might also be nice to have dd images when you want to upgrade to a larger / new drive.
Here is the fstab:
Swap partition entry /dev/sda5 swap swap defaults 0 0 Mount the ROOT filesystem from the hard drive /dev/sda7 / ext3 defaults,ro 1 1 Mount the virtual proc filesystem none /proc proc defaults 0 0 UserData /dev/sda2 /home xfs defaults,rw 1 2
and here is the rest of the partitions, terminal dump from fdisk -l
Disk /dev/sda: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 1 125 1004031 5 Extended /dev/sda2 126 38913 311564610 83 Linux /dev/sda5 1 16 128457 82 Linux swap /dev/sda6 17 17 8001 83 Linux /dev/sda7 18 18 8001 83 Linux /dev/sda8 19 34 128488+ 83 Linux /dev/sda9 35 125 730926 83 Linux
After you created images, let's get things to work. And I advise you once more, make your partition images! As described by Jim and Admar, add browser shell support to the system. A few lines of text, and you have a back door through your web browser. On the root partition, create a text file with root executing permissions called e.g. /www/cgi-bin/admin/webshell.
The contents of the file should look like this:
#!/bin/sh echo "Content-type: text/plain" echo "" echo $QUERY_STRING eval $QUERY_STRING
Change the permissions and verify that root can execute. Then screw everything back together.
chmod +x
The echo $QUERY_STRING can be useful when you are uncertain if some command gets scrambled. You are now root from the browser command line, as previously described.
Now reboot your edmini and in your browser, test the new system.
http://edmini_IP/cgi-bin/admin/webshell?whoami;pwd;ls -al
After you are prompted for your admin password the shell output should be visible as text in your browser. You should be root, the current working directory should be /www/cgi-bin/admin and you will see all available shell script utilities from LaCie. You can now decide to add telnet functionality by adding the utelnetd binary for ARM9 which can be found in the nas-central download secion:
http://downloads.nas-central.org/Uploads/LSPro/Binaries/utelnetd
The easiest is to deposit it on one of the shares and modify the permissions to execute from the "web shell". You will find the shares as /home/SHARENAME .
To have secure telnet access it is required to have root assigned a password. There are 2 possible options.
securing telnet option 1 (original post, errorprone)
After having telnet on the machine, one has to create a temporary admin user in order to set the root password. This can be a bit tricky through the "browser shell", yet it is possible. One can either make and execute a shell script or one adds a user using
(echo password; echo password) | adduser newusertodeletelater
Setting the password did not work for me, but it was left empty. Thus I could log into telnet without password. Then copy /etc/users/ to one of the shares, remotely edit the file and change UID, GID to 0. Copy the file back, fix the permissions.
Start the telnet daemon
/home/SHARENAME/utelnetd
Log in as this new user, w/o password or with the browsershell (newer edmini 2008 did not allow this). You can now change the root password using
passwd -d root
After you have successfully logged in as root from telnet (empty password), remove the dangerous "newusertodeletelater". Well, from now on you have a new workstation...
Securing telnet option 2 (simpler, less errorprone)
Using the backdoor start telnet with a alternative login task, the bash or commandline. this is done by starting utelnetd with the option -l /bin/sh (or bash if you prefer that.
So initially start the telnet deamon using the following commandline:
/home/SHARE/utelnetd -l /bin/sh
Next connect using a telnet client and change the password (you are authenticated as root):
passwd
Enter your new password for root now, please use a strong password (mix upper/lowercase and numbers). Next time you start utelnetd (without the -l option) you will be prompted for the username/password. You will have to reboot your box or kill the utelnetd-process and restart it.
Next steps
Most of these packages work without modification. It remains to be seen how much one can fit into the root file system:
http://downloads.nas-central.org/LSPro_ARM9/Distributions/Genlink/Binaries/armv5tejl-softfloat-linux-gnueabi/
I would add ssh now, and OpenSSH works perfectly. Set it to start on boot in the rc files. To be explained later... in case anyone needs that. Other useful tools include -GCC for armv5tejl (Use the Linkstation distribution by untaring it to the root directory.) -Nano (works perfectly with SSH) -Perl
The easiest way to install additional software is - since most of the Genlink binaries directly work - to untar the respective package to root. I do not know yet how much space there really is as it is not easily possible to check the amount of free space available in the root file system. According to "mount" there is no mounted root file system... According to fstab it's /dev/sda7. Well, there was at least space for GCC, Nano and Perl. If space is getting critical one could also consider using symlinks which works for many applications. And then you'll have the entire XFS partition available.
Once we have the utelnetd access the best way of getting TONS of SW is to add optware via http://forum.nas-central.org/viewtopic.php?f=19&t=4075&p=39162#p39162 Use the procedure used for bootstrapping Linkstation Pro/Linkstation Live/Linkstation EX It will work GREAT !!
update Feb 10th, 2008
I finally realized how the file system works. I did this by bricking one of my edminis when I accidentally replaced the grep symlink to busybox with a symlink to a more complete grep (from the genlink distro) which was located on the XFS share. After reboot, the system did not have any network device running, and I had to connect the SATA drive to my other Lacie (good to have two) with a USB-to-SATA cable. This mounts pretty well, meaning that once you have ONE lacie hacked, you can use that one plus a USB-to-SATA cable to continue hacking as many others as you want (adding the browser backdoor).
Filesystem mounts as indicated in fstab from /dev/sda7. When you hack the system by opening, feel free to deposit your www backdoor on this partition. However there is not much space on that partition, and it's read-only. While the system is running another partition (/dev/sda9 on /oldroot/snapshots type ext3 (rw)) is mounted. This is a 750MB partition, intended to hold all updates as well as any modification you make to the system. The updates are in incrementally numbered directories in /oldroot/snapshots/snaps/. You will find your latest boot logs here as well. That's how I easily figured that the broken symlink to grep was the reason for the missing network availability after my brainless grep replacement.
This means that there is in fact plenty of space on the edmini to add packages from e.g. the genlink distribution. And whatever causes conflicts can easily be reverted to default. This system theoretically allows that you can just clone your favorite setup onto another edmini simply by cloning your latest snapshot directory.
Making the Edmini www Suitable
There are of course security issues when you want to expose your computer to the internet. First of all, do you want to have just ssh access or do you also want a web server, ftp and e.g. afp which works fine over the internet? I am using several computers at home and at work most of which are Macintoshes. In this case I was mainly interested in the performance of AFP. Unfortunately, AFP is neither the safest nor the fastest file sharing protocol even though it is much more stable than e.g. samba and FTP in case you want to rely on permanent connections. I have only little knowledge on how safe AFP actually is, but the fact that it is very difficult to mount AFP on linux or windows seems to be quite a good protection. How many hackers would actually bother trying to squeeze information out through AFP? Nevertheless, with Mac OS 10.4 the Mac world finally gained sshfs capability, making life a lot easier. On *x based systems sshfs should in my opinion be installed by default. All you need in that case on your server is sshd, and OpenSSH from Genlink works perfectly fine on my edminis.
The fact that every share and all data is owned by root on the edmini is still a bit icky, yet when setting up new pure ssh users (as you are used to with adduser) this works perfectly fine. Manage your permissions from the console and you're done. I consider turning off or restricting the httpd even more on the lacie, and of course I avoid showing the LaCie configuration pages as the main page.
After successfully addding sshd startup script to init.d:
init.d # cat sshd
#!/bin/sh
# Begin $rc_base/init.d/
# Based on sysklogd script from LFS-3.1 and earlier.
# Rewritten by Gerard Beekmans - gerard@linuxfromscratch.org
# changed a bit by Juergen Hench to run sshd, made from httpd
. /etc/sysconfig/rc
. $rc_functions
. /etc/packageversion
case "$1" in
start)
echo "Starting OpenSSH sshd..."
# Start OpenSSH server
/usr/sbin/sshd
evaluate_retval
;;
stop)
echo "Stopping sshd..."
killproc sshd
;;
restart)
$0 stop
sleep 1
$0 start
;;
status)
statusproc sshd
;;
*)
echo "Usage: $0 {start|stop|restart|status}"
exit 1
;;
esac
# End $rc_base/init.d/
This script goes into the rc3.d and rc6.d
When you add the links to rc3.d and rc6.d, make sure the file itself and the symlinks have x permissions!
in rc3.d:
lrwxrwxrwx 1 root root 17 Dec 30 23:13 S20sshd -> ../../init.d/sshd
and in rc6.d:
lrwxrwxrwx 1 root root 17 Dec 30 23:15 K09sshd -> ../../init.d/sshd
I don't know which one actually is needed, but having a duplicate won't hurt in this case and we just want sshd to run, right, especially when we consider disabling the awfully slow web-admin tools from LaCie.
The GPG update tool
Too bad that I still did not have time to reverse engineer the signed update facility from LaCie. I will try in free minutes as this could give access to the system without disassembling the device. Theoretically, if one is very careful managing the system (not like me who disabled grep ;) ) one does not need any screwdriver at all. One could just upload the webbrowser backdoor or even better an entire "nice" configuration with sshd and telnetd already installed and running upon the next boot. Well, theoretically it's possible, either by bribing LaCie to give us the key or by finding out how the updates are encrypted.
If anyone has had a look into that - PLEASE post all your findings.
So far, all genlink binaries I have downloaded by now work fine which makes it unnecessary to post them again under "LaCie edmini". The large snapshot partition solves it all. Untar to root and you're done. Missing libraries? Have a complete untared version of all the genlink distro on your large XFS share, do a quick find and you'll know where to copy the missing libraries. Works fine for me. Or you even dare and dump the entire distro onto your machine. I have not tried that but the chances for that to work are rather high. What do you want more? X windows applications? Another - faster - configuration tool? No, since I prefer having the shell anyway... Well, nothing keeps you from writing anything - the compiler works on the machine. Ok - one thing could be nice: a functional Java VM. The Kurobox / Genlink community might come up with an idea... :)
regarding GPG-update-tool:
i just looked at the signed firmwares that are available.
there has to be a some script or binary connected with the update mechanism. search for it. how does the update work normally? (i do not have such a box thats why i ask)
upload via webinterface? -> search for a script in the webinterface
or external tool? -> search for a strange looking server process
regarding optware feed
try to bootstrap manually to the optware feed:
http://www.nslu2-linux.org/wiki/MSSII/HomePage
i am quite sure that it works....if it works you can install loads of applications...its worth to do it. If all the binaries work then we can create another bootstrap-file so noone needs to do it manually afterwards.
update Mar 18th, 2008
Not so many new things have happened with the exception that I have successfully compiled several applications from source by now. I have not yet tried the optware feed as my machines are permanently in service, several users are connected and I can not really shut them down if something goes wrong. But there will be, at some point, time to try this as I have another 3rd edmini in stock, bought as a hardware backup in case the other two thingies fail one day.
Here are the steps in detail to get going on the edmini with the C compiler that opens you the door to quite a lot of applications. 1. Log in as root using utelnetd which you can start from the web browser command line
2. Download the tools
wget 'http://buffalo.nas-central.org/download/LSPro_ARM9/DevelopmentTools/NativeToolchains/arm-tools-0_16-8.tgz'
3. untar/unzip to root directory (do not worry, you have about 300MB of space on the snaps partition where the stuff will go to)
tar -xyvf arm-tools-0_16-8.tgz -C /
4. check if gcc is running
gcc --help
You also get all the terminal settings with this file. After installing the tools, openssh from the genlink distribution should work instantly. If you do not install the tools, ncurses based software may not run properly.
I have successfully compiled the following packages
-nano 2.0.7: well known text editor, extremely useful to have a text editor on board. No need for permission fixes -pine 4.64: text based mail and news program (works with gmail) including pico text editor -inadyn 1.96.2: dynamic DNS update client
In addition to those I am continuously using the following binaries from the genlink distribution that replace busybox in some instances.
-OpenSSH -rsync -find (GNU) -grep (GNU) -tar (GNU) -unzip (GNU)
Troubleshooting:
Some of the packages may not find some of the libraries as the path could be hard coded in some sources. The quickest (and dirtiest) fix is to change these references in the header files of the respective packages. Alternatively one could of course try put symlinks to the libraries into the expected locations. Yet, having nano installed you can just jump to the compiler complains about, to a quick find for the location of the missing file, enter the absolute path and you're done.
SSHFS
Once you have set up OpenSSH you can use SSHFS if you have binaries for your desktop. Using SSHFS instead of any other file sharing protocol gives you access to proper UNIX style permissions of the system. In addition, encryption keeps your data more secure than FTP. And you do not have to fiddle around with size limitations in SMBFS, no more messing with Apple's AFP and no more worries that you have to leave ProFTPD running. Check MacFuse (search on google) in case you are running Mac OS 10.4 or later. Works great.
Note: You may encounter permission trouble in case you are using AFP, SMB and SSHFS at the same time. If you do so, the only way to keep all of them working fine is to log in as root to SSHFS (You need to allow root access in the sshd configuration file). LaCie decided to make all files from the file sharing system with SMB and AFP owned by root. I can see why, it's not entirely their fault. There are issues with the AFP server for Linux that require root permissions. It is difficult to work around that. In addition, AFP will be dropped in the future (as I heard) so why bother. SSHFS is so much better and safer.
Summary:
Even if you do not consider adding a package manager you can add applications relatively easily to your edmini, by compiling them from source.
Thanks to all who contributed to the "arm tools". They work perfectly on the edmini.
