Tag Archives: Linux

Netgear ReadyNAS access recovery after SSH and WebGUI lockout

The following post is about a ReadyNAS Pro 4. I have no idea if it’ll work on other ReadyNAS devices.

I stupidly managed to lock myself out of SSH access (I blame /bin/false automagically appearing by my username in /etc/passwd instead of the usual /bin/bash).
Not thinking straight due to stress. I decided that I probably forgot my password, and proceeded to reset it by editing /etc/shadow from a ReadyNAS configuration backup and uploading it back to the device..

That was probably the dumbest move I’ve ever made. For several reasons:

1. Since I borked SSH access, Frontview (Web GUI) was my only option for control of the system at this time.

2. User access for Frontview is also read from /etc/shadow. Same as SSH.

3. Did I use an editor in Windows that was capable of editing files without inserting Windows specific weirdness? (i.e. whitespaces and linebreaks)? No I did not.

I didn’t figure this out until way later, but I wont describe just how dumb my thought process was during my evening. Just post a solution to the problem.

The problem being the following:
I was totally locked out of my system. No admin GUI, no console, nothing. My obvious options were paying Netgear to fix it, or losing all my data.
Neither is ok.

Here’s my solution. You probably shouldn’t do this unless you’re desperate. I won’t take responsibility for your bricked NAS or lost data if you decide to follow the steps i took. You can cause a lot of damage if you have clumsy fingers.

1. Power down the ReadyNAS.

2. Access the Boot Menu by pushing the reset button while powering up the device. Release reset when “Boot Menu” is shown in the display.

3. Select Tech Menu by pressing the backup button. Confirm by pushing the reset button again.

4. Log in with the following super secret Netgear Tech staff only account (Google is great some times): root / infr8ntdebug

5. Connect to the IP displayed on the ReadyNAS with Telnet (Port 23). At the # prompt (this is Busybox btw), you wont initially have access to the regular boot partition of the device. To mount that, enter the following commands:

echo DEVICE partitions > /etc/mdadm.conf
mdadm --examine --scan >> /etc/mdadm.conf
mdadm --assemble --scan
mount /dev/md0 /mnt

6. Navigate to /mnt/etc/

7. In my case, since I had broken shadow by inserting Windows whitespaces into them (^M in Vi), I had to get rid of those. Since %s/^V^M//g didn’t work for some reason, I did the following instead:

cat /etc/shadow | tr -d '\r' > shadow.temp
mv shadow.temp shadow

8. Reboot the device. I now had SSH access again. The Frontview account was still broken for some reason so that was fixed by issuing passwd admin and just resetting it.

My case may have been specific, but if you find yourself needing to access and modify the root partition of the ReadyNAS Pro without having SSH access, the Netgear tech support mode is a viable option. Just mind what you do when you’re there. You’re not supposed to be there and you’ll probably void your warranty just by considering it..

info: mpt raid status change on Debian 6/VMware

EDIT: I suggest you read the comment below by ndavis. Just get rid of the problem entirely 😉

I’m getting mails sent to root on a fresh install of Debian 6 with official VMware Tools, whining about RAID status changes, which is odd, since I have no visible RAID configs this Debian install should be worrying about.

Message contents:

This is a RAID status update from mpt-statusd. The mpt-status program reports that one of the RAIDs changed state: Report from /etc/init.d/mpt-statusd on <SERVER>

I don’t know what causes it, and the forums I’ve stumbled upon have offered fixes, but no actual explanation.

In order to disable the messages (and the daemon itself), do the following as root:

/etc/init.d/mpt-statusd stop
echo RUNDAEMON=no > /etc/default/mpt-statusd

Install open-vm-tools in Ubuntu Lucid Lynx (10.04 LTS)

I’ve previously had issues installing VMware Tools in various versions of Ubuntu server, which pointed me towards using open-vm-tools instead.

I’ve heard the latest version of VMware Tools is indeed compiled properly for Ubuntu but I’ve gotten used to using 3rd party alternatives so I’ve just kept going with open-vm-tools.

Here’s how you install it:

apt-get install --no-install-recommends linux-headers-virtual open-vm-dkms open-vm-tools

The reason for –no-install-recommends is that it’ll pull down the GUI tools for X as well if we just apt-get install open-vm-tools.

Installing PHP 5.2 on Ubuntu Lucid Lynx (10.04 LTS)

If you followed my previous post on downgrading your PHP installation, this may be of interest to you, since the Karmic security repositories are no longer available. There may be workarounds, but I couldn’t install PHP 5.2 following my previous instructions.

Here’s a different way to do it, that proved successful. Note that the install procedures outlined below, is for a fresh install of Ubuntu Server without the LAMP package selected during installation. If you want to adapt a system with 5.2 already installed, I’m sure you can figure it out using this post for inspiration.. 😛

First, you need to install add-apt-repository (root is assumed on all commands unless otherwise stated):

apt-get install add-apt-repository

Add the following into /etc/apt/preferences.d/php to pin PHP at version 5.2:

</pre>
Package: libapache2-mod-php5
Pin: version 5.2.10*
Pin-Priority: 991

Package: libapache2-<wbr>mod-php5filter
Pin: version 5.2.10*
Pin-Priority: 991</wbr>

Package: php-pear
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-cgi
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-cli
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-common
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-curl
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-dbg
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-dev
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-gd
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-gmp
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-ldap
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-mhash
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-mysql
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-odbc
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-pgsql
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-pspell
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-recode
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-snmp
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-sqlite
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-sybase
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-tidy
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-xmlrpc
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-xsl
Pin: version 5.2.10*
Pin-Priority: 991

Package: php5-mcrypt
Pin: version 5.2.6*
Pin-Priority: 991

Package: php5-imap
Pin: version 5.2.6*
Pin-Priority: 991

Now, we’ll be using PHP 5.2 compiled for Lucid Lynx (courtesy of Ralph Janke). Add Ralphs repository:

add-apt-repository ppa:txwikinger/php5.2

Update apt:

apt-get update

Install PHP 5.2:

apt-get install php5

Install MySQL if needed:

apt-get install mysql-server mysql-client

There. You should have a LAMP server up and running with PHP 5.2, without having to worry about Karmics repositories being gone, or an accidental upgrade to 5.3.

Using fail2ban for temporary lock outs

I’ve been using fail2ban for a while on a Linux system with a couple of ports open to the outside world. Naturally, this results in more than a few login attempts by unknowns during any given day. Fail2ban is a simple python based IP blocking application for POSIX systems. It works by continuously searching various system logs for failed login attempts, and blocking IP addresses temporarily with iptables.

Since we run a Debian-heavy enironment, this will only address installation on just that.

Start by installing fail2ban (as root):

apt-get install fail2ban

Modify /etc/fail2ban/jail.conf to suit your needs. The JAILS-section is used to defined the different parameters you’d like for your various open doors.

An example jail for SSH:

[ssh]

enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

And for mail systems using for example postfix and dovecot:


[postfix]

enabled  = true
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/mail.log


[dovecot-pop3imap]

enabled = true
port = pop3,pop3s,imap,imaps
filter = dovecot-pop3imap
logpath = /var/log/mail.log

As you can see, the configuration is fairly straight forward. Tell fail2ban where your logs are, what ports to monitor, max number of retries unless you want the default.

(Potentially) fix sharing violation errors in VMware Data Recovery

I’m back from the dead, kind of. I’ve been on paternity leave since mid November. I got back to work this Monday and I’m still trying to wrap my head around things.

We’ve deployed VMware Data Recovery in our live environment and have run into some issues with target devices being unavailable, generating sharing violation errors during backup.

There are no .lck files present and the target volume is exclusive to VDR.

A solution that seems to have done the trick, is tuning the Linux network stack (VDR is based on CentOS).

The default maximum TCP buffer size in Linux is too small for VDR to be happy. TCP memory is derived from the amount of system memory available. Usually the mem_max and wmem_max-values are set to 128Kb in most Linux distros, way too low a value for large chunks of data to be transferred efficiently.

SSH to your VDR appliance. Default username and password if unchanged is root and vmw@re.

We’ll start by setting wmem_max and rmem_max to 12Mb:

echo 'net.core.wmem_max=12582912' >> /etc/sysctl.conf
echo 'net.core.rmem_max=12582912' >> /etc/sysctl.conf

Proceed with minimum, initial and maximum size:

echo 'net.ipv4.tcp_rmem= 10240 87380 12582912' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_wmem= 10240 87380 12582912' >> /etc/sysctl.conf

Window scaling will enlarge the transfer window:

echo 'net.ipv4.tcp_window_scaling = 1' >> /etc/sysctl.conf

Enable RFC1323 timestamps:

echo 'net.ipv4.tcp_timestamps = 1' >> /etc/sysctl.conf

Enable select acknowledgements:

echo 'net.ipv4.tcp_sack = 1' >> /etc/sysctl.conf

Disable TCP metrics cache:

echo 'net.ipv4.tcp_no_metrics_save = 1' >> /etc/sysctl.conf

Set max number of packets to be queued on the INPUT chain, if the interface receives packets faster than the kernel can manage:

echo 'net.core.netdev_max_backlog = 5000' >> /etc/sysctl.conf

Reload:

sysctl -p

Disable IPv6 on Ubuntu Lucid Lynx (10.04.3 LTS)

I’m getting strange logging errors tracked down to IPv6 being enabled by default in Lucid.
The following commands will verify and disable IPv6.
The following command will check if IPv6 is enabled or disabled (0 = enabled, 1 = disabled… what.. not logical?):

cat /proc/sys/net/ipv6/conf/all/disable_ipv6

The removal of IPv6 involves startup scripts in /etc/sysctl.conf. You can edit this by running the following commands in the terminal (su is implied):

echo "#disable ipv6" | sudo tee -a /etc/sysctl.conf
echo "net.ipv6.conf.all.disable_ipv6 = 1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv6.conf.default.disable_ipv6 = 1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv6.conf.lo.disable_ipv6 = 1" | sudo tee -a /etc/sysctl.conf

Reboot and verify that the changes went through. with the first command in the post.