Archive for the ‘Linux’ Category

Google Chrome and Kerberos on Linux

November 24, 2012

So we all know you can enable Kerberos by adding the “–auth-server-whitelist” to the command line:

google-chrome --auth-server-whitelist="*.example.org"

But you can also make it permanent. Simply create a directory (in Linux) called /etc/opt/chrome/policies/managed/ and within it drop a json file such as example-corp.json with the following contents:

{ "AuthServerWhitelist": "*.example.org",
"AuthNegotiateDelegateWhitelist": "*.example.org" }

And voila, no need to fiddle the command line options every time you start Chrome. Plus as an administrator you can simply deploy that file automatically across all your workstations and not have to bother the users, things will just work.

Fedora 16 with SELinux running WordPress with WP Super Cache

January 4, 2012

Updated (Jan 5, 2012): chcon changes the SELinux security on a file, but a restorecon would wipe that out, you need to actually run semanage to change the policy, then run restorecon to make it “permanent”.  Thanks to [email protected] for pointing this out to me.

So I recently started upgrading all the CloudSecurityAlliance web servers from F14 (with SELinux enabled) to F16 (with SELinux enabled). But I ran into a nasty little problem, WP Super Cache was broken. The error message that came up was:

Error: Your cache directory (/var/www/html/wp-content/cache/)
or /var/www/html/wp-content need to be writable for this
plugin to work. Double-check it.

Cannot continue... fix previous problems and retry.

Well shoot. The file permissions were correct, apache had write permissions and so on to the directory. But it was unable to write… Ah.. must be SELinux. The quickest way to test this is to simply disable SELinux for a second:

setenforce Permissive

and reload the WP Super Cache control page. Ah it works. So we know it’s an SELinux problem. The good news is that this is easy to fix, simply set the label on the directories and files you want the httpd process to be able to write to (and don’t forget to re-enable SELinux after you disabled it in the previous step):

You can use chcon to change the content on the directories:

chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/cache/
chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/plugins/
chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/themes
chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/uploads/
chcon -t httpd_sys_rw_content_t /var/www/html/wp-content/wp-cache-config.php

For a more permanent change however use semanage to change the targeted policy:

semanage -S targeted -i - << _EOF
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/cache(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/uploads(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/plugins(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/themes(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/wp-cache-config.php
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/themes(/.*)?
fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/blogs.dir(/.*)?
_EOF
restorecon -R -v /var/www/html

Also you may want to add “/var/www/html/wp-content/blogs.dir(/.*)?” so that WordPress multi-site uploads work properly.

Be mindful of selinux policy updates, they shouldn’t overwrite the changes you made but you may want to in order to get the latest greatest policies. Also you probably won’t have semanage installed:

yum install policycoreutils-python

Ok that was easy. But how do we find out what label needs to be applied? Well the ls command can give us a hint:

ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html

So we’re dealing with httpd (obviously, but for other servers and services it may not be as simple so I’m doing this step by step). We can check for httpd related contexts using grep:

grep httpd /etc/selinux/targeted/contexts/files/file_contexts

Which will return a huge list of stuff. If you examine the output however you will notice lines like:

/var/lib/drupal.*       system_u:object_r:httpd_sys_rw_content_t:s0
/var/cache/mediawiki(/.*)?      system_u:object_r:httpd_cache_t:s0

So it would appear we have two main choices: httpd_sys_rw_content_t and httpd_cache_t. There are a number of other related labels as well: httpd_mediawiki_rw_content_t, httpd_git_rw_content_t, httpd_bugzilla_rw_content_t, httpd_mojomojo_rw_content_t and httpd_dspam_content_rw_t to name a few. Any of these will work, but I chose httpd_sys_rw_content_t as it;s rpetty obvious as to what it is for at first glance.

For more details on Red Hat Enterprise Linux (this also applies to Fedora) with SELinux and confined services check the Red Hat documentation:

Managing_Confined_Services/sect-Managing_Confined_Services-The_Apache_HTTP_Server-Types.html

Getting Amazon AWS EC2 API Tools working properly

December 8, 2010

a) First remove all hints of Java from your system (libgcj, openjdk, etc.). Use “whereis java” and “locate java” and “rpm -qf /some/random/thing/java” to expunge your system.

b) Install JDK from Sun/Oracle (http://www.java.com/en/download/installed.jsp?detect=jre&try=1)

c) install ruby (“yum install ruby”)

d) download EC2 API tools (http://aws.amazon.com/developertools/351?_encoding=UTF8&jiveRedirect=1) , unpack, copy the bin and libs directories into /opt/ec2/ or wherever you want

e) create and download a certificate pair from the AWS management interface

f) export stuff:

export JAVA_HOME=/usr/

export EC2_CERT=/root/cert.pem

export EC2_PRIVATE_KEY=/root/pk.pem

export EC2_HOME=/opt/ec2/

Linux iSCSI server (target)

May 24, 2010

So basically all the articles I could find on setting up Linux as an iSCSI server (aka iSCSI target) were out of date and useless. Here’s the current info:

You have two current choices:

Linux SCSI target framework (also current as of April 2010) – http://stgt.sourceforge.net/

iSCSI Enterprise Target (currently maintained as of late April 2010) – http://iscsitarget.sourceforge.net/

The first one, Linux SCSI target framework (tgt) is shipped by Red Hat (5 and 6 beta, Fedora), Debian, SuSE and several other vendors which is good, but most of the vendors ship older versions (like 0.4, 0.6, 0.9) rather than the current 1.0 which is not so great (but upgrading is easy). Judging by the widespread vendor support I’m going to pick tgt over the iSCSI Enterprise Target for the simple and pragmatic reason that more people are using it and thus bugs and support are probably easier to deal with.

The Fedora Project Wiki has a quick start guide for setting up tgt at https://fedoraproject.org/wiki/Scsi-target-utils_Quickstart_Guide that covers creating target devices/etc.

The good news is that iSCSI initiators (aka clients) are reasonably mature and included in the installation support for most modern Linux systems.VMware also supports iSCSI out of the box with pretty much no hassle.

Now to find an affordable 16 port SATA RAID controller and case.

Obsolete iSCSI target software for Linux:

http://www.open-iscsi.org/ – Not maintained since May 2009

http://linux-iscsi.sourceforge.net/– Not maintained since 2005