Category Archives: Uncategorized

Hello everyone

Today’s topic is a bit different than usual but to make sure that I remember this small fix I decided to write a small blog post about it. I run a number of WordPress installations for various people and recently I setup a new one on a web server behind a very nasty firewall. This firewall is blocking passive FTP connections so when trying to automatically update plugins and such requiring FTP in WordPress I was hitting a wall that after entering credentials the page would just hang at “loading”. I think a spent about an hour debugging what was going on. Nothing in web server logs, login was successful in FTP server logs. What was going on?

Then it struck me! The FTP server did not allow passive FTP connections to upload, they could connect but not upload. So was WordPress using passive FTP?

Turns out, yes it does. And it is hard-coded. Not very nice WordPress! Following this post: http://wordpress.org/support/topic/define-ftp-active-mode-in-wp-config I found the file:

includes/class-wp-filesystem-ftpext.php

and it indeed containged the line:

@ftp_pasv( $this->link, true );

which hard-codes the use of passive FTP. Now changing it to false solved my problem! It would be nice if this setting could be set via wp-config.php as other FTP options can.

In the process of migrating physical hosts between vCenter servers I encountered this odd:

Clearly I am switching from one Enterprise Plus license to another Enterprise Plus license but it still warns me that I will lose access to some features. Can’t explain why 😛

Hello again

Today I’m going to highlight some of the bugs/problems we have run into with vSphere Single Sign On (SSO), introduced in vSphere 5.1.

Using Active Directory groups from a Multi-Domain Forest with Parent-Child trust:

We are using a Active Directory (AD) forest that consists of a single root domain around 20 sub domains, a single level down. That is we have a root AD domain like example.com and below a single level we have all the domains, mostly on the form department.example.com. All users exist in one of the sub domains, none are placed in the root domain. It contains only service accounts, groups and servers.

The SSO as of version 5.1 U1b only supports External Two-way trusts (See: KB:2037410) so at first you think it won’t work. So you try adding a group from AD and you are able to do so. But trying to authenticate with a user of that group doesn’t work. Adding the user itself instead of the group works. VMware have stated to us that this is a problem with the transitivity of the trust in Parent-Child trusts which does not exist in the External Two-way trust. I suspect that this is also caused by another “bug” that we have noticed that I will explain below.

Workaround: use local SSO groups with AD users. This works just fine.

Users with same sAMAccountName in different domains in same forest cannot be used:

We discovered last week that we were unable to add users to permissions or SSO groups if the SSO already new a user with the same sAMAccountName but in a different domain. VMware confirmed this as a bug which will be fixed in an upcomming release. The bug only occurs in child domains in an AD forest.

Users are presented in the SSO with wrong domain when added:

This is small bug  but when adding a user (or group) the first time the user is added with username@example.com rather than the correct username@department.example.com which is shown when adding and despite selecting the correct domain in the “Add user” dialog. The result is that the first time the user logs in nothing is shown despite the user having permissions. Have the user log out and then remove and add the user solves the problem, as if the SSO figures out that the user is in the sub domain on first login. I suspect that this has something to do with the first problem as well.

Cannot remove user from SSO group:

Despite KB:2037102 stating that the bug was solved in vSphere 5.1 U1a we are experiencing it on this version aswell. We have not reported this yet but am doing so tomorrow morning. For some users no errors are shown but the user is not removed, for others an error is shown that the principal could not be removed. In the imsTrace log a Java exception shows that the principal cannot be removed because it does not exist on the group, even though the web client shows the user.

This post may be updated in the future:)