Posts tagged CentOS
If you get a “Refusing to undefine while domain managed save image exists” message whilst trying to undefine an image using virsh, try passing the –managed-save flag like so:
$ -> virsh undefine service-a-3 --managed-save
Flag was added as part of this bug.
I recently ran into a situation where I needed to grant access to certain /home dirs in order to get puppetmaster started with SELinux enforcing. And I had to do it in such a way that I could keep the resulting “type enforcement” (.te) file in version control, this would allow me to track human readable changes.
$ -> cd ~ $ -> echo > /var/log/audit/audit.log # this ensures a clean log for analysis $ -> /etc/init.d/puppetmaster start # should fail $ -> audit2allow -i /var/log/audit/audit.log -m puppetmaster # this will output the perms necessary for puppetmaster to access needed resources, copy and paste this into the file you are using in version control $ -> checkmodule -M -m -o puppetmaster.mod /path/to/your/version/controlled/puppetmaster.te # this will create a .mod file $ -> semodule_package -m puppetmaster.mod -o puppetmaster.pp # this will create a compiled semodule $ -> semodule -i puppetmaster.pp # this will install the module
At this point, you have added a custom puppetmaster selinux module which will allow you to get through the first issue discovered when trying to start the service. From here there are one of two course of action, depending on whether the service starts or not. If the service starts, you are done. If the service does not start, you will need to repeat the above steps to determine which new permissions are required to allow the service to start, rinse and repeat until your service starts.
After moving melikedev.com to a vps, I was able to improve performance by configuring nginx to serve static assets while apache serves the content. In order to test if the NGinx config was correctly configured I used the ‘curl’ command to test response headers of known static assets. After testing and implementing the changes the site has never performed better.
When testing response headers I passed a few flags to the curl command; the ‘-I’ flag tells curl to only output the response headers, and the ‘-L’ flag tells curl which link you want the response headers for.
mpurcell@service1 -> curl -I -L http://melikedev.com/wp-content/plugins/sociable/js/sociable.js?ver=3.4.2 HTTP/1.1 200 OK Server: nginx/1.0.15 Date: Thu, 24 Jan 2013 21:20:44 GMT Content-Type: text/css Content-Length: 63287 Last-Modified: Sat, 29 Dec 2012 08:50:42 GMT Connection: keep-alive Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000 Pragma: public Cache-Control: public Accept-Ranges: bytes
Notice in the response headers the response code is 200, which is good. But notice the expires date, this far out date allows the browser to cache the static asset for a long time, which means when a return user refreshes the page, the static assets should be loaded from browser cache.
There was one more performance step I took to speed up the render time of the melikedev.com pages, and that was to compress static assets such as xml, html, css etc. In order to test whether the compression was I working I had to add an extra flag to the curl command line, the ‘-H’ flag. This flag allows you to pass custom headers to the request header, which can dictate the data contained within response headers.
mpurcell@service1 -> curl -I -H "Accept-Encoding: gzip, deflate" -L http://melikedev.com/wp-content/plugins/sociable/css/sociable.css?ver=3.4.2 HTTP/1.1 200 OK Server: nginx/1.0.15 Date: Thu, 24 Jan 2013 21:24:30 GMT Content-Type: text/css Last-Modified: Sat, 29 Dec 2012 08:50:41 GMT Connection: keep-alive Expires: Thu, 31 Dec 2037 23:55:55 GMT Cache-Control: max-age=315360000 Pragma: public Cache-Control: public Content-Encoding: gzip
Notice in this set of response headers the return code was 200 and the expires date was still the far out date, but notice the ‘Content-Encoding’ field, it responded with gzip. This means that because we told the server we are accepting gzip and deflate as encodings, the server compressed the static asset.
Taking steps to increase performance makes end users happy and increases hardware life cycles.
If you are writing manifests which include using templates and you receive a wrong header line format error message, it means there is a syntax error in one of your template files. The message is pretty much worthless due to it’s cryptic nature, and there appears to be an open defect to improve the messaging, but not sure that it will be fixed as the current status is “accepted”.
So check your templates, the issue that generated this warning for me was:
# Notice the <% = # Should be <%= alias /<%= tpl_src_code_path %>/<% = static_asset_dir %>/;
Currently I am working on a project to centralize all syslog entries into one server and have been running into issues due to the fact that I run SELinux and store the rsyslog.conf file in version control. By default you can tail the /var/log/audit/audit.log to see what’s going on, but the message is fairly encrypted and not easily understood. After some research there is an executable sealert which will parse the audit log and convert the messages into human readable format. sealert does not get installed by default on CentOS systems, so you have to do:
yum install setroubleshoot-server
After the install is completed, you can then analyze the audit log by issuing the following command:
sealert -a /var/log/audit/audit.log > /var/log/audit/audit_human_readable.log
It took a few seconds to analyze, but upon completion I was able to open the human readable version, and see entries like:
-------------------------------------------------------------------------------- SELinux is preventing /sbin/rsyslogd from search access on the directory /home. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that rsyslogd should be allowed search access on the home directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep rsyslogd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
So I was able to create the audit policy to allow rsyslogd the access it needed to the config file in order to run properly.
Recently I started retro-fitting the MeLikeDrinks.com drink website to cache frequently used data to improve performance, as such I wrote a light, custom cache API which sits on top of PHP’s Memcached API. Because I follow TDD principles, I wrote out the tests first, which helped me write out the API calls needed to support the application, but when it came time to actually get the memcached service on my CentOS box, I ran into all sorts of confusion, which motivated me to write this article. It is my hope that this article will help alleviate any confusion others may face when they decide to dive into the cache pool.
First, I need to clarify one of the more confusing issues regarding PHP and Memcache, which is, there are two different PHP Apis. Depending on which PHP Memcache API you select, will determine the steps necessary for PHP to gain access to the underlying memcached server. The differences between PHP Memcache and PHP Memcached are outlined here. Regardless of the differences between the two PHP APIs we have to choose from, they both access the same underlying Memcached Service. The only REAL difference, as far as configuration and installation steps are concerned, is that PHP Memcached requires an external library known as libmemcached. In short, the stacks look like this:
PHP (PECL) Memcache
- libevent (dependency)
- memcached (service)
- zlib (PHP dependency)
- PHP (PECL) Memcache
PHP (PECL) Memcached
- libevent (dependency)
- memcached (service)
- zlib (PHP dependency)
- PHP (PECL) Memcached
As you can see, the stacks are nearly identical, except for the fact that PHP Memcached requires an extra layer; libmemcached. If you opt to use PHP Memcache, and because this article assumes you are using CentOS, you can simply have YUM install the entire stack for your via `yum install php-memcache`. If your environment requires you to compile PHP, then you can issue a `yum install memcached` command, and YUM will install libevent and memcached, then you can compile PHP (and PHP Memcache module).
If you are still reading, then you want to install and use PHP Memcached, which unfortunately will require a little more work on your end. I will not go over how to install PHP Memcached using PECL, as I do not believe in these types of automated processes. In the past I have had bad experiences with PECL and rather not introduce another layer of complexity, so the following steps will allow you to compile and install the PHP Memcached stack without PECL.
- libevent (dependency)
- yum install libevent libevent-devel
- memcached (service)
- yum install memcached
- First check which version of PHP Memcached you wish to use, which will determine which version of libmemcached you need. For example; according to PHP PECL Memcached changelog, the latest version of libmemcached you can use is 1.0.4, otherwise if you try to use a newer version of PHP PECL Memcached you may run into unforeseen issues, in other words, you should ALWAYS assume that PHP PECL Memcached is a few versions behind libmemcached.
- Based on which version of libmemcached you need from the previous step, you can download from libmemcached download page.
- Extract file and CD into dir
- $ -> ./configure –with-libevent-prefix=/usr
- $ -> make
- $ -> make install
- PHP PECL Memcached
- Download the correct version based on which version of libmemcached you compiled and installed via changelog (which links to download) page.
- Extract file and CD into dir
- $ -> phpize
- $ -> ./configure –with-libmemcached-dir=/path/to/where/memcached.h/is/located
- make install
- PHP ini config
- vi /path/to/php.ini
- Add: extension=memcached.so
- Test module installation
- $ -> php -m
- You should memcached listed among other modules
- $ -> php -i | fgrep -irs cache
- You should see various memcached config settings
- Finishing touches
- Restart apache
- Start memcached
- Write a test script to test the setting and getting of a value from your cache server via PHP Memcached API.
And there you have it, a memcached stack without using PECL. All things considered it should not have been too painful an installation, however I must make one disclaimer; I customized my memcached stack a bit more than I eluded to in this article, so if you run into an issue, just post a comment and I will try to help you resolve the issue.
Now that you have a memcached service, and an API to use, you should start focusing on the code points of your application with the most overhead, this will give you the most bang for your buck when you start caching data. Good luck, and happy caching.
I run Percona MySQL on all my CentOS servers by way of the Percona MySQL RPM. So every time I run `yum update` Percona MySQL also gets updated. Unfortunately, when yum reports back with the packages that will be updated, and Percona MySQL is among the list, all I see is a version number. Rather than blindly accepting the package upgrade, I would also like to see the change log, so I had to do some searching but found the 5.1, and 5.5 release notes. Posting links so others can easily access the release notes every time a new release makes it way through a yum update.
I have been working with Magento and came across another hurdle. Magento requires the mycrypt PHP module to be compiled, otherwise you will not be able to complete the install process. So naturally I opened up a terminal and typed `yum install mcrypt` only to find that no such libraries existed. Apparently, the default repos don’t provide the mcrypt libraries any more, so I had to use the EPEL repo, which does provide access to the required mcrypt libraries.
The following steps outline how I successfully installed mcrypt libraries on my CentOS (6.x) system:
Localize EPEL Repo
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
To verify that it was installed correctly, you can type `$ -> yum repolist`
Disable EPEL Repo
I don’t like not knowing what is installed on my system, as such I didn’t want to keep the EPEL repo enabled by default. Rather, I preferred to tell YUM to use EPEL only when I directed it to do so. In order to accomplish this, you need to make the following changes:
# /etc/yum.repos.d/epel.repo enabled=1 # to enabled=0
Now, the EPEL repo will not automatically be considered when you go to install a new package. Convenient for ensuring your system stays as “vanilla” as possible.
$ -> yum install libmcrypt libmcrypt-devel mcrypt --enablerepo=epel
The libmcrypt-devel libraries are only necessary if you are going to install the PHP mcrypt module.
The above command will install the mcrypt libraries as provided by the EPEL repo.
Now that we have mcrypt installed on our system, we can compile the PHP mcrypt module, first lets find out where mcrypt was installed:
$ -> which mcrypt /usr/bin/mcrypt
Now that we know where mcrypt is installed we can add the following flag to our PHP configure for compilation: –with-mcrypt=/usr/bin
After configure be sure to run make, and make install, after they are complete you should be able to `php -m` and see mcrypt as a compiled module.
Be careful when upgrading CentOS 5.x servers to 6.x with respect to GIT. On CentOS 5.x GIT was not available via default repo, so I compiled it manually and it was on version 1.7.6, but when I installed CentOS 6 and did a yum install for GIT, it was at version 1.7.1.
Glad that CentOS finally provided GIT via the default repo, I let yum handle the install, but when I went to start pushing code to my production box (with git 1.7.6) I kept getting GIT failures. Only after I upgraded my production box to CentOS6 and yum installed GIT, did my code push script work again.
Linux – CentOS6 – httpd – mod_file_cache – mod_mem_cache – mod_imagemap – Cannot Load into Server – Cannot Open Shared Object0
If you are upgrading from CentOS5 to CentOS6 and attempt to start httpd, you may come across a message similar to: “Starting httpd: httpd: Syntax error on line 196 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_file_cache.so into server: /etc/httpd/modules/mod_file_cache.so: cannot open shared object file: No such file or directory”. Apparently the removal of some apache mods was an upstream decision which CentOS passed through to us. You can find more information here.
The quick fix is to remove these references from your httpd.conf file, however if you depend on these modules being available, you will have to download and compile manually.