Plesk Installation

The first error I encountered was during the installation of Plesk. During the install I got this error:

Exception: Failed to solve dependencies:
psa-mail-driver-common-17.0.17-cos7.build1700161124.17.x86_64 requires libopendkim.so.10()(64bit)

ERROR: The Yum utility failed to install the required packages.
Attention! Your software might be inoperable.
Please contact product technical support.

Apparently CentOS 7 installs libopendkim-2.11 by default and Plesk requires version 2.10. To solve this I had to download and install libopendkim-2.10 which I found on the Plesk site:

http://parallels.bhs.mirrors.ovh.net/parallels/PSA_17.0.17/thirdparty-rpm-CentOS-7-x86_64/libopendkim-2.10.3-3.el7.x86_64.rpm

Download this file and install it with:

rpm -Uvh libopendkim-2.10.3-3.el7.x86_64.rpm

Then you can proceed with the Plesk Installation

Email Configuration

Enable port 587 for sending mail. This can be changed under Tools & Settings -> Mail Server Settings.

Make TLS optional on port 587.

1. Edit /etc/postfix/master.cf
2. Find the line that starts with “submission”
3. Change smtpd_tls_security_level to “may” instead of “encrypt”

Set queue lifetime to more sensible values by running these commands:

postconf -e “maximal_queue_lifetime=2h”
postconf -e “minimal_backoff_time=5m”
postconf -e “maximal_backoff_time=15m”
postconf -e “queue_run_delay=5m”

Upload your SSL certificate. This is really easy do to in Plesk 17. Just go to Tools & Settings -> SSL/TLS Certificates and follow the instructions there.

Email Migration

I used the Plesk Migration Manager to migrate all the domains and users and users mailboxes to the new server. However, the Migration Manager was lacking in a couple areas. First, it did not migrate any IMAP folders. It migrated the users’ inbox but if they had any IMAP folders, those did not get migrated. The solution I found was to use rsync. I wrote a little shell script to iterate through all the Maildir folders on the new server and copy the data from the old server using rsync. Create a file called syncmail.sh on the new server and paste in this code:

#!/bin/sh
DOMAIN=$1
SOURCE_SERVER=old.servername.com

find /var/qmail/mailnames/$DOMAIN -maxdepth 2 -name Maildir >/tmp/maildirs.txt

while read MAILDIR; do
echo “Syncing $MAILDIR”
rsync -av –delete $SOURCE_SERVER:$MAILDIR/ $MAILDIR/
done </tmp/maildirs.txt

This script syncs one domain at a time so you need to specify the domain name as the first argument when running the script. But you could change it to do all domains at once by leaving the domain name blank and changing maxdepth to 3. This not only copies the IMAP folders but it also syncs any changes made to the inbox on the old server such as new messages that have arrived or messages the user may have deleted. You can run this script as many times as you want and it will only copy the changes.

The second major flaw with the migration manager is that it doesn’t preserve the UID of each message. The UID is how Outlook and other mail clients determine which messages have already been downloaded. So if you don’t preserve the UID’s from the old server, Outlook will re-download all the messages again and you will have lots of users with lots of duplicate emails. I think the reason it didn’t preserve the UID’s is because the old server was using Courier-IMAP and the new server was using Dovecot. Luckily I found a utility online that can convert the UID’s from Courier to Dovecot. You can download it from http://wiki.dovecot.org/Migration/Courier. To use the script just do this on the new server after the mailbox has been copied over:

courier-dovecot-migrate.pl –to-dovecot –convert $MAILDIR

Where $MAILDIR is the location of the users Maildir folder. (/var/qmail/mailnames/domain.com/user@domain.com/Maildir). I even incorporated this step into the syncmail.sh script right after the rsync command like this:

#!/bin/sh
DOMAIN=$1
SOURCE_SERVER=old.servername.com

find /var/qmail/mailnames/$DOMAIN -maxdepth 2 -name Maildir >/tmp/maildirs.txt

while read MAILDIR; do
echo “Syncing $MAILDIR”
rsync -av –delete $SOURCE_SERVER:$MAILDIR/ $MAILDIR/
courier-dovecot-migrate.pl –to-dovecot –convert $MAILDIR
done </tmp/maildirs.txt

So now the script copies (syncs) all the email from all the Maildir folders on the old server to the new server and then converts the Courier-IMAP files into the format expected by Dovecot so all the UID’s are the same. Brilliant!

The overall process went something like this:

1. Use the Migration Manager to do the initial copy. That gets all the users setup on your new server with the same passwords as before.
2. Use the script to copy over the rest of the mailbox data for each domain.
3. Disable mail on the old server. I blocked all the mail-related ports (25,110,143,587,465,993 & 995) so that no new messages could come in and users could no longer connect to the old server
4. Run the script again to pickup any last minute changes
5. Change your hostname and MX records to point to the new server.

I didn’t want to go around and change the incoming and outgoing mail server settings in every mail client and smartphone, so I just pointed my old hostname to the new server’s IP address.

Website Migration

The Migration Manager did a good job of copying all the website files and databases from the old server to the new server

These steps are for Plesk Obsidian 18 but may work for other versions. First, you need to get the domain ID from MySQL:

# mysql -D psa

> select id from domains where name = 'example.com';

+----+
| id |
+----+
| 88 |
+----+
1 row in set (0.00 sec)

Then you need to find the WordPress instance ID using sqlite:

# sqlite3 /usr/local/psa/var/modules/wp-toolkit/wp-toolkit.sqlite3
sqlite> .mode columns
sqlite> .headers on
sqlite> select * from instances where domainId = 88;
id          domainId    path                  isIgnored   apsInstanceId  serverId
----------  ----------  --------------------  ----------  -------------  ----------
18          88          /httpdocs             0
19          88          /httpdocs.old/blog    0

Here you can see there are two instances for the same domain, however, one is old and needs to be removed.

Finally, you can detach the non-existent instance using the Plesk command line utility:

# plesk ext wp-toolkit --detach -instance-id 19

Download a repository from github

git clone <url>

Push changes back to github

git commit -a -m “Commit Message”
git push

This will only publish modified files. If you’ve added any new files you have to manually stage them with

git add <filename>

Or if you want to stage all new, modified & deleted files, use

git add -A

To see what files have been staged before doing a commit, use

git status

Saving Credentials

You will be asked for your github username and password every time you push. To prevent this you can use the credential helper. Enable the credential helper with

git config credential.helper store

The next time you do a push, your credentials will be stored for future use. Your credentials will be stored in this file

~/.git-credentials

Working with Branches

To see a list of all branches in the current repository type

git branch

To create a new local branch

git branch <branch-name>

If you want to switch to another branch you can use

git checkout <branch-name>

To create a new local branch and switch to it in one step

git checkout -b <branch-name>

To delete a branch, use

git branch -d <branch-name>

Push the new branch to the remote server

git push origin <branch-name>

Syncing a forked repository

So you’ve forked a repository and made some changes to it but the original repository has also been updated. You’d like to sync those changes from the original repo into your fork without losing the changes you’ve made.

Start by adding a remote called ‘upstream’ that points to the original repo

git add remote upstream  https://github.com/path/to/original/repo.git

Then fetch all the branches from the upstream remote

get fetch upstream

First make sure you are in the master branch, then merge the upstream master into our own master

git checkout master
get merge upstream/master

Then your local master should updated with the changes from the original repo. The final step is to push the merged copy back to the server by simply doing

get push

Source: http://stackoverflow.com/questions/7244321/how-do-i-update-a-github-forked-repository/7244456#7244456

If you have any branches, you need to rebase them to your master like this

git checkout <branch name>
git rebase master

Ignoring files

If your project depends on other projects and you’re using composer to autoload them, you might want to use a .gitignore file so your dependency files are not included in your project. Just create a .gitignore file in the root of your project and add these 2 lines

vendor
composer.lock

Location is not available. <mapped drive> is unavailable. If the location is on this PC, make sure the device is connected or the disc is inserted, and then try again. If the location is on a network, make sure you’re connect to the network or Internet, and the try again. If the location still can’t be found, it might have been moved or deleted.

I pulled my hair out for weeks trying to figure out what was causing it. I ruled out other causes such as the physical network, permission issues, and the antivirus software. Finally I discovered that I could reproduce the issue by opening one of the mapped network drives in Windows Explorer and then running “gpupdate /force” from a command prompt. So I knew it had to be a Group Policy that was causing it.

I discovered that the drives were being mapped using Group Policy Preferences and the Action was set to “Replace.” So every time the policy was applied, it would remove the drive mapping and recreate it, killing any open connections.

The odd thing is that it didn’t seem to affect any of the Windows 7 clients but both the Windows 8.1 clients were experiencing this issue. I changed the Action to “Update” and the problem went away.

1. Download the launch.ica file to a folder on your computer.

2. Right-click the launch.ica and click “open with…”

3. Browse to C:\Program files (x86)\Citrix\Receiver\Receiver.exe

The file will not open, but once ICA files are associated with the Citrix Receiver you should be able to launch applications from your web browser.

The file ‘autorun.dll’ could not be loaded or is corrupt. Setup cannot continue.

This will happen if you install the WinPE-Setup package without installing either the WinPE-Setup-Client package or the WinPE-Setup-Server package.

Mount a WIM file

dism /mount-wim /wimfile:”D:\path\to\wim\file” /index:1 /mountdir:D:\mount

Dismount a WIM file with commit

dism /unmount-win /mountdir:D:\mount /commit

Dismount a WIM file with discard

dism /unmount-win /mountdir:D:\mount /discard

Add a package to a WIM

dism /Image:D:\mount /Add-Package /PackagePath:”C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs\WINPE-MDAC.cab”

Display a list of the currently mounted WIM’s

dism /get-mountedwiminfo

Soultion 1: Check the time on all domain controllers.

This was a common suggestion from other posts online but it was not the issue in my case since both servers were in perfect sync.

I decided to run the EMTShooter script to see what it would say. Basically it gave me the same Access Denied error message. That was not very helpful except it did tell me everything was fine with the IIS PowerShell virtual directory.  So I figured it had to be an account authentication problem of some kind.

Solution 2: Reset the secure channel

Open the command prompt on the Exchange server and type:

netdom reset <server_name> /domain:<domain_name>

The <server_name> should be one of your domain controllers.

Solution 3: Reset the machine password

From the command prompt on the Exchange server, type:

netdom resetpw /s:<server_name> /ud:<user_name> /pd:*

<user_name> should be a domain user with administrative privileges in the format DOMAIN\username

At this point I was able to start all the Exchange services, but the Exchange Management Console was still giving me Kerberos errors. I thought about rebooting the server but I remember reading somewhere about deleting cached Kerberos tickets. The command to do that is:

klist purge

The klist command is built into Server 2008 R2. After purging the cached Kerberos tickets I was finally able to open the Exchange Management Console and everything was good.

1. Open Root Explorer
2. Navigate to /system/apps
3. Rename SDM.apk to SDM.apk.old
4. Rename SDM.odex to SDM.odex.old

This worked for me. However, if you have the paid version of Titanium Backup you can use Titanium Backup to freeze the SDM app.

To get things right you have to create a multipart/alternative message that is nested within a multipart/mixed message. Here is the code I used:

my $html = “<html><body>This is the HTML message</body></html>”;
my $text = “This is the text message”;
my $attachment = “<html><body>This is the HTML attachment</body></html>”;
my $email = “someone@example.com”;

my $msg = MIME::Lite->new(
From        =>  ‘me@example.com’,
To          =>  $email,
Subject     =>  ‘Test message’,
Type        =>  ‘multipart/mixed’
);

my $part = MIME::Lite->new(
Type => ‘multipart/alternative’,
);
$part->attach(
Type => ‘text/html; charset=utf-8’,
Data => $html,
);
$part->attach(
Type => ‘text/plain’,
Data => $text,
);
$msg->attach($part);

$msg->attach(
Type => ‘text/html’,
Data => $attachment,
Filename => ‘filename.htm’,
Disposition => ‘attachment’
);

$msg->send;
if ( $msg->last_send_successful() ) {
print ”  Message sent to $email\n”;
} else {
print ”  Error sending email to $email\n”;
}