Month: February 2015

WP-Filebase plugin for WordPress – changing maximum upload file size limits in php

WP-Filebase
WP-Filebase

So my new favorite plugin for WordPress is WP-Filebase; a free, easy way to upload files into WordPress that makes those files easy for others to download. While the plugin seems a little daunting at first to manage, it pretty much follows the typical methods other plugins employ such as shortcode. While editing a page or post there is a WP-Filebase button next to the other editing buttons such as “insert link” or “Italic”. Once the basic concepts are mastered, it becomes a pleasure to create categories, upload, and post files for download. There are a ton of other features to categorize, post and track hits with WP-Filebase if you want.

One issue I encountered when using WP-Filebase is that by default the upload size for files in php and WordPress are pretty small, and that the upload size for my entire site had to be increased. When I tried to upload a file with WP-Filebase of any size larger than 2MB, the upload would quit and fail without much information or error messages. When you’re expecting to see “File added”, and instead the page just refreshes without an error, it can be a little frustrating. Here are the steps I took to increase the file upload size:

Login to an ssh session on the server running WordPress.

Before you edit php.ini, it’s always a good idea to make a copy of the original file with a command of something like:

cp /etc/php5/apache2/php.ini /home/jcoltrin/php.ini.original

edit /etc/php5/apache2/php.ini with the command:

sudo vi /etc/php5/apache2/php.ini

Below this paragraph are the php settings to find and change in the vi editor. To find the settings, it can be useful for vi to be in command mode (the vi editor starts in command mode by default). While in command mode, hit the forward slash key /, and then type the keyword, then hit [enter/return]. The vi editor will jump to the first instance of the keyword it finds. You can then simply hit the n key to cycle to the next instance of that keyword. Then hit the i key to go into insertion mode. Now you can hit the delete/backspace keys and use your arrow keys to edit the settings. When you’re done editing, hit the Escape key, then the : key, then type wq, then hit enter. There are ton of other shortcuts, tips and cheats for vi you can find here: http://www.lagmonster.org/docs/vi.html .

upload_max_filesize = 20M
post_max_size = 20M
max_execution_time = 500
max_input_time = 500

After making these changes, I wanted to be sure they stuck if apache restarts. I did this by restarting apache and then viewing the php settings coming from the web browser itself.

Restarted apache2 with:
sudo /etc/init.d/apache2 restart

Made sure these limits stuck by creating a new file in the root of my apache website files location:
sudo touch /var/www/phpinfo.php

Insert the following line into phpinfo.php (only):
<?php phpinfo(); ?>

Then visited the file by going to http://domainname.com/phpinfo.php

I found that the settings were active and applied successfully by looking at the phpinfo settings website.

I then tested uploads of 12.9MB files which were previously unable to upload and can now upload successfully.

Delete the phpinfo.php you created (you probably don’t want this file hanging around for the world to find.)

That’s it, enjoy using WP-Filebase, and uploading/downloading files of any size to your heart’s content.

Hyper-V failed to generate initial replica for server

turbolift_access_denied

I recently found that one of my virtual machines had failed it’s initial replication off to a server located at a different site. I looked at a few of the Hyper-V-VMMS Admin Event Logs and found some of the following errors:

Event ID: 32042 – Hyper-V failed to generate initial replica for ‘040REP001’: General access denied error (0x80070005). (Virtual machine ID GUID)

Event ID: 33680 – Replication operation for virtual machine ‘ServerName’ failed.

Event ID: 32086 – Hyper-V suspended replication for virtual machine ‘ServerName’ due to a non-recoverable failure. Resume replication after correcting the failure.

Also Event ID’s 33676, 18012, 16370

I googled around and found that most resolutions revolved around fixing the “Virtual Machine” group permissions of the parent Folder or Volume by using the icacls command that looks something like this:

icacls “C:ProgramDataMicrosoftWindowsHyper-VVirtual Machines5A6F2E44-7F95-4CF8-89E5-AE8A6648C93A.xml” /grant “NT VIRTUAL MACHINE5A6F2E44-7F95-4CF8-89E5-AE8A6648C93A”:(F) /L

or this:

icacls “C:UsersPublicDocumentsHyper-VVirtual Hard DisksMountPointHere” /grant “NT VIRTUAL MACHINEVirtual Machines”:F /T

The folder that the .vhd was contained in did not have “Virtual Machine” group permissions (c:\hyper-v\exports), so I decided I should move the VM and it’s virtual hard disk to a new location that does have the correct permissions. Since this was an old export, I found the original location of the .vhd in the config file in c:\hyper-v\exports\config.xml.

Since I didn’t like the current location of the virtual machine and .vhd anyway, I decided rather than trying to fix permissions, I’d move it to a better location in a folder that would inherit the correct permissions.

To resolve the replica problem I did the following:

1. Disabled alerting on the server, then shut down the VM.

2. Disabled replication on the vm – right-click on VM in HyperV Manager -> Replication -> Remove Replication

3. Moved all Virtual Machine folders associated with MyServerName out of a folder I had created “c:\Hyper-V\Exports”  including the .vhd within (folders that did not have the permissions) and cut/pasted into “C:\Users\Public\Documents\Hyper-V\Virtual hard disks\” folder that was already created. This folder inherited permissions from the parent folder including the “Virtual Machines” group.

4. On the shut-down VM, I then went into the VM’s settings and then IDE Controller 0 -> Hard Drive -> Changed Location of Virtual Hard Disk by hitting the “Browse…” button, browsed to the new .vhd location folder with the correct permissions -> OK

5. Started the Virtual Machine successfully, then re-enabled replication with the remote site Replica server and, – yes! – initial replica started normally and health is normal again. Sending initial Replica now at 3%.

6. Re-enabled alerting on the server.

Hope this helps someone else who’s replications are failing and they’re struggling with the “General Permissions Error” problems associated with snapshots and replication.