Plesk root password recovery

I was doing a password rotation on a server the other day and for some reason it failed whilst I was updating root. Maybe the password was too long, maybe Virtuozzo doesn’t do proper validity checking but either way I lost access to root.

Luckily if you’ve still got access to a Plesk admin user you can use this to your advantage and get root access back.

First of all you need a user with SSH access, in the Plesk admin panel make sure the account is set up with ‘/bin/bash’ as the root directory and not ‘/bin/bash (chrooted)’.

SSH into the server with that users’ credentials and create two scripts, the first one:

#!/bin/bash
cp /etc/shadow /tmp/shadow.tmp;
chmod 777 /tmp/shadow.tmp;
exit;

The second:

#!/bin/bash
cp /tmp/shadow.tmp /etc/shadow;
chmod 640 /etc/shadow;
exit;

Place them in /tmp or wherever you want to run them from and name them what you like, I’ll refer to them as 1.sh and 2.sh from here on.

Give the scripts execute permissions:

chmod +x /tmp/1.sh /tmp/2.sh

Now go back to your Plesk admin panel and go to Server > Tools & Resources > Scheduled Tasks.

Search for or select the user ‘root’ and add a new task.

Enter */1 in the Minute field and * in the rest of them, in the Command field enter the path to your first script, most probably /tmp/1.sh.

Hit the OK button.

This cron job will run the first script once a minute, on the minute so wait a minute and it will have made a copy of the /etc/shadow file called /tmp/shadow.tmp, check your /tmp folder for this.

Once the file has appeared, remove the task in the Plesk admin panel so it stops copying the file every minute.

In your SSH session open /tmp/shadow.tmp in your favourite editor.

Copy the whole line for a user that you know the password of, you might want to choose the line that matches the SSH user you’re currently using as you definitely know that password.

Replace the line (most probably at the top of the file) for the root user with the one you’ve just copied and then change the username at the beginning of the line from whatever user it is to ‘root’, save your file making sure it’s still called ‘shadow.tmp’.

Now go back to the Plesk admin panel and make a new scheduled task, exactly the same configuration as before but set the command to be ‘/tmp/2.sh’.

Hit the OK button on the task and wait 1 minute for the task to run, after a minute remove the task so it doesn’t carry on running the script. If you’ve done everything right you’ll have replaced the password hash for the root user with a known password and you’ll be able to log in as root using this known password.

Once you’ve logged back in change the root password and clear up the files in your /tmp folder.

Let me know how you get on, I know the scripts could be cleaned up and consolidated but I didn’t want to use a delay so that I wasn’t rushed in making sure I’d edited the files in time, it was easier just to run two cron jobs.

Speeding up RAID migration on a Synology DS414 NAS

I’ve had a Synology DS414 NAS for a few weeks now, this post is about how to change the default settings of mdadm, the tool used to manage software RAID, to speed up the process of migrating between RAID levels.

I started out with 2 x 4Tb WD Red drives, they were configured to be a Synology Hybrid RAID (SHR) volume which dynamically changes the RAID level depending on the number of drives you assign to it.

With 2 disks it’ll run in RAID 1, mirroring the data held on the drives, add another disk and it’ll convert the volume to RAID 5, striping the data across the drives for more available space whilst adding parity information to cope with the failure of any 1 of the drives.

Adding the 3rd disk was quick and easy, the DS414 supports hot plugging devices so I just went ahead and put the new drive in, added the drive to the volume and it went ahead and expanded it.

The next part is a bit of a waiting game and depending on the size of the volume it can take a while. Because the DS414 uses software RAID, where there’s no dedicated RAID hardware, it uses the CPU of the device which isn’t the fastest.

I left it overnight and late the next day it had only done about 30%, whilst expanding volumes data is essentially at risk as the array is not redundant. The longer the process takes the longer you’re not protected against disk failure.

There are a few things you can do to speed up the process, SSH to your NAS as admin and enter the following commands (change md3 to your device):

# echo 100000 > /proc/sys/dev/raid/speed_limit_min
# echo 32768 > /sys/block/md3/md/stripe_cache_size

The first command increases the minimum “goal” rebuild speeds for when there’s non-rebuild activity. On my DS414 I never saw this go above 90000KiB.

The second command increases the stripe cache size which increases sync performance by allowing a larger cache to synchronise the read and write operations on the array.  This is only available for RAID 5 volumes and it does decrease the amount of available system RAM but I never saw 100% utilisation on the DS414.

You can monitor the process with the following command:

# cat /proc/mdstat

Once I’d changed these settings the expand operation only took another 12 hours, a total of about 35. It should also work for speeding up volume consistency checks as they both read the same config. Remember the commands above will only set those options until the NAS is rebooted.