17 Dec 2014∞
Let’s say you have a Synology NAS for storing all your important data (i.e. Linux ISOs). Let’s say you’re a fairly paranoid person and use Synology Hybrid RAID (SHR) which can tolerate the loss of two drives simultaneously. Just in case. Let’s say you experience some kind of catostrophic failure that causes the system to think it has lost 5 of 12 drives at once.
This is what has happened to me.
To make matters worse, I had installed the bash ipkg to make using the command line more palatable. Did I follow best practices and exec bash from my ash .profile script? No. Do I regret this? Very much.
Since all of my volumes have failed, including /opt where bash is stored, I can no longer SSH into the Synology! And, more importantly: neither can support. If you haven’t created a separate user to SSH in from, this is really bad. The default configuration does not let you exec commands via ssh user@host <command> so you’re pretty much dead in the water.
If you still have an available volume, you can install a third party package that emulates a Terminal in the browser to repair /etc/passwd, but all my volumes have failed.
Just about thinking I was out of luck entirely, I stumbled on the Scheduled Tasks page in the Control Panel. A-ha! A little command-fu and I was able to send the output of commands to my webserver to fix the problems.
On server:
$ tcpdump -s 0 -A -nni eth0 host <home IP> and port 80
In Scheduled Task:
<command> | curl -d @- http://<server>/
Now I can execute commands and see the results in my tcpdump output. A little bit of sed and I was all patched up:
sed -i -e 's@/opt/bin/bash@/bin/ash@g' /etc/passwd 2>&1 | curl -d @- http://<server>/
Since the command executed successfully, there was no output and I was free to SSH back into my NAS. And, again, more importantly: so could support! Now, hopefully, they can repair my volumes.