So, wordpress sites do not need chmod 777, as some customers do use. Traditionally, you will want to create permissions in accordance with this document:
https://codex.wordpress.org/Hardening_WordPress#File_Permissions
The most important pieces are chmod for folders and chmod for files using find to do this en-masse
D for directories
find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;
F for files
find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;
Rackspace Cloud Files CDN enabled containers and the Rackspace CDN product can occasionally have an issue, in such cases, you can troubleshoot this a lot easier by using the DEBUG headers. To do this add -D and the folowing -H headers for your output
curl -I http://rackspacecdnurlgoeshereprivatecensored.r17.cf3.rackcdn.com/common/test/generator.png -D - -H "Pragma: akamai-x-get-client-ip, akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no, akamai-x-feo-trace, akamai-x-get-request-id" -L
Naturally for this to work, you need to make sure you have a test URL. You can get one from Cloud Files in the Rackspace Control panel, or from whatever origin is configured with the CDN. Just login to the origin, and find a file path like httpdocs/somefolder/somefile.png and then get the raxcdn.com URL from the Rackspace CDN product page, or the Rackspace Cloud Files ‘show all links’ page on the cog icon next to the cloud files container. And add the path behind your documentroot.
So for the CDN URL rackspacecdnurlgoeshereprivatecensored.r17.cf3.rackcdn.com
For the files on the origin in the documentroot of the website configured with the CDN just add the ‘local’ document path within httpdocs or your www folder!
i.e. rackspacecdnurlgoeshereprivatecensored.r17.cf3.rackcdn.com becomes rackspacecdnurlgoeshereprivatecensored.r17.cf3.rackcdn.com/somefolder/somefile.png
So, I’ve been provisioning disks, and stuff recently.. this is how I did it on a Dell. Quite an easy thing to do!
omconfig storage controller action=createvdisk controller=0 raid=r1 size=max readpolicy=ara pdisk=0:0:2,0:0:3 Command successful!
In this case the two disks newly added were 0:0:2 and 0:0:3 on the SAS ‘bus’.
An additional primary partition was created and added for this device sdb1, and a filesystem of the same kind (ext3) as the system disk was created;
mkfs.ext3 /dev/sdb1 mke2fs 1.39 (29-May-2006) .... Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done
You will naturally need to mount the partition and create an fstab entry to make this permanent;
mount /dev/sdb1 /mnt/backup echo "/dev/sdb1 /mnt/backup ext3 defaults 1 1" >> /etc/fstab
You may wish to consider adding the above to fstab manually. It’s not a good idea using echo with it incase you make a mistake ;-D
Cheers &
Best wishes,
Adam
How to fix Dirty Cow vulnerability in CentOS, RedHat, Ubuntu, Debian, CloudLinux and OpenSuse Linux servers
Dirty COW vulnerability was first discovered a decade ago and has been present in Linux kernel versions from 2.6.22, which was released in 2007.
But the vulnerability gained attention only recently when hackers started exploiting it. This has led to the release of this bug as CVE-2016-5195 on October 19th, 2016.
What is Dirty Cow vulnerability (CVE-2016-5195)?
CVE-2016-5195 aka “Dirty COW vulnerability” involves a privilege escalation exploit which affects the way memory operations are handled.
Since the feature that is affected by this bug is the copy-on-write (COW) mechanism in Linux kernel for managing ‘dirty’ memory pages, this vulnerability is termed ‘Dirty COW’.
Misusing this flaw in kernel, an unprivileged local user can escalate his privileges in the system and thus gain write access on read-only memory updates.
Using this privilege escalation, local users can write to any file that they can read. Any malicious application or user can thus tamper with critical read-only root-owned files.
Is Dirty Cow vulnerability (CVE-2016-5195) critical?
Dirty COW vulnerability affects the Linux kernel. Most open-source operating systems such as RedHat, Ubuntu, Fedora, Debian, etc. are based over Linux kernel.
As a result, this vulnerability is a ‘High’ priority one as it can affect a huge percentage of servers running over Linux and Android kernels.
CVE-2016-5195 exploit can be misused by malicious users who are provided with shell access in Linux servers. They can gain root access and attack other users.
When combined with other attacks such as SQL injection, this privilege escalation attack can even mess up the entire data in these servers, which makes it a critical one.
Are you servers affected by Dirty Cow exploit?
If your server or VM or container is hosted with any of these OS versions, then they are vulnerable:
Red Hat Enterprise Linux 7.x, 6.x and 5.x
CentOS Linux 7.x, 6.x and 5.x
Debian Linux wheezy, jessie, stretch and sid
Ubuntu Linux precise (LTS 12.04), trusty, xenial (LTS 16.04), yakkety and vivid/ubuntu-core
SUSE Linux Enterprise 11 and 12
For more information about mitigating yourself against Dirty cow, please see:
Credit to Reeshma Mathews from bobcares.com for this
So, in the case you have a cloud-server, such as a Rackspace standard flavour instance, you might want to resize down.
The only problem is that when doing this it can result in the MBR being lost. Check out this great article from Jake Coe, explaining how it can be achieved.
https://community.rackspace.com/products/f/25/t/4716?_ga=1.244296325.1822315901.1458550977
Because of the sizes of larger vhds it will not let you downsizes these devices within the control panel. There may be a way to downsize them IF you are not using more then the required space on the server however there are some risks involved and once the downsize is completed there will be a manual fixed needed for the servers to get them to boot.
I would highly suggest that the following be attempted on a non production server as dataloss could happen.
Create an image of existing server you want to downsize.
Once the image is completed we can modify the min disk and ram to that of the smaller size needed.
On the new server once built to the larger size you will 1st need to write all zeros to empty space.
cat /dev/zero > /zero; rm -f /zero
Once this is done you will then downsize the server to the desired size.
Once the downsize is completed if this is a pvhvm instance the mbr will be gone and grub will need to be reinstalled
It is possible to use vhd-util scan -a -p to determine the size of a VHD in Xen server. It can be done as follows
vhd-util scan -a -p /var/run/sr-mount/96ca6e70-976e-32bd-837d-f1e7bade1262/e165978f-2ff7-4958-8642-7087be83d680.vhd