Difference between revisions of "SuccessStories"

From NAS-Central Lacie Wiki
Jump to: navigation, search
(Under Construction)
(Under Construction)
Line 87: Line 87:
  
 
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.
 
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.
 +
---------------
 +
[[update Feb 10th, 2008]]
 +
 +
I realized now 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 '''

Revision as of 13:03, 10 February 2008

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.

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 .

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. You can now change the root password using

passwd root

After you have successfully logged in as root from telnet, remove the dangerous "newusertodeletelater". Well, from now on you have a new workstation...

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.


update Feb 10th, 2008

I realized now 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