blog.plee.me About software, technology and random things

17Dec/160

Installing mod_cloudflare For Apache HTTPd 2.4 On Debian 8 (Jessie) Via Aptitude Repository

Hi!

If you are using the Cloudflare proxy functionality, you will find that your web server will end up only working with Cloudflare's IPs instead of the visitors'. After quite some time I thought that there has to be a better way to go about this, and I found mod_cloudflare, a solution officially developed by Cloudflare themselves.

When I was looking at the official Cloudflare documentation on how to install mod_cloudflare for Apache 2.4 on Debian 8 (Jessie) today, I was disappointed to find that they were only recommending manual ways: installing a .deb package or compiling the module yourself.

Luckily I found a guide on how to accomplish the installation with the standard apt-get / aptitude tool for Debian / Ubuntu.

This is how:

  1. Add the aptitude repository to a new sources list file, e.g. at /etc/apt/sources.list.d/cloudflare-main.list - with this content:
    deb http://pkg.cloudflare.com/ jessie main
  2. Download the Cloudflare repository key and add it to the aptitude known keys:
    # wget https://pkg.cloudflare.com/pubkey.gpg
    # apt-key add pubkey.gpg
    # rm pubkey.gpg
  3. Update the aptitude cache:
    # aptitude update
  4. Look at which packages are available in the new repository:
    # grep ^Package: /var/lib/apt/lists/pkg.cloudflare.com_dists_jessie_main_binary-amd64_Packages
  5. Install mod_cloudflare:
    # aptitude install libapache2-mod-cloudflare
  6. Restart the Apache HTTPd service:
    # service apache2 restart

Hopefully this way of installing will enable everyone to update / maintain it much more easily and with less one-time use packages installed.

Additionally, this could prove even more useful for people who want to install more Cloudflare packages.

I am confident that this method also works for Ubuntu and other versions of Debian - just replace the "jessie" part in the aptitude sources list file with your distribution major release codename (like "wheezy" for Debian 7 or "vivid" for Ubuntu 15.04).

Thanks for reading!

Original source: https://emtunc.org/blog/01/2016/installing-mod_cloudflare-ubuntu-14-04-apache-server/

7Jun/150

Memory Leaks / Problems with Long-Running Symfony / Doctrine Console Applications

Hi!

I recently built several console applications that have to keep running as daemons as part of a more complex website. As soon as I added Doctrine for its highly comfortable ORM functionality, I noticed a significant increase in the applications' memory usage, which made sense because it would load Doctrine's code in order to use it. The worst part of it, however, was that the processes kept eating up more and more memory the longer they ran and with each Doctrine query they executed. Finally the processes ended up being killed by Linux's OOM Killer due to the high amount of memory that they wanted allocated for them.

Clearing the Doctrine Entity Manager ($entityManager->clear()) and triggering PHP's garbage collection manually did not help at all. So I assumed it had something to do with the data that Doctrine accumulates in the background.

During my research I finally stumbled upon this Stack Overflow question: Memory leaks Symfony2 Doctrine2 / exceed memory limit

Apparently, Doctrine uses an SQL Logger to log each and every query it uses when running in debug mode.

Due to the nature of Symfony console applications starting up in the dev environment by default when launching them from the command line, it also kept enabling the debug mode. That in turn enabled the SQL Logger which gathered more and more data and kept it in memory.

I decided to launch the processes by simply manually disabling the debug flag. Using the dev environment is not a problem for me, so I just did the following:

$ php app/console custom:command --no-debug

You could also set the environment variable SYMFONY_DEBUG to 0 before launching the command without the --no-debug flag, as it also respects its value - refer to app/console's source code.

Alternatively, you could start it in a non-dev environment:

$ php app/console custom:command --env=prod

or

$ php app/console custom:command -e prod

or just set the environment variable SYMFONY_ENV before launching it.

This way, the SQL Logger is not enabled.

My processes have been running at stable memory usage size ever since.

Another way would be to deactivate the SQL Logger in the code by principle, but that would be defeating the purpose of the nice built-in features of enabling/disabling the debugging mode, so I rather chose the first path. It might come in handy sooner or later after all, and reverting those changes just to re-enable the SQL Logger would be an unnecessary pain.

I hope this was helpful to you. It certainly took me some time to get behind it.

1Jan/120

Using Different Color Schemes with Vim

Hey!

If you have been using the Linux console text editor vim (or: Vi IMproved), you have probably noticed already that at times - especially in files with a large amount of comments - the default color scheme on a black background is less than ideal. Dark blue on black is pretty hard to read and can strain the eyes a lot.

So today I went out to see if somebody had come up with a solution for this particular problem. I saw people who changed console colors by exporting and overwriting certain system variables, and others who edited the default color scheme.

The simplest solution I have found to this problem is just switching the color scheme. You can do that by typing the following in the already open vim session:

:colorscheme desert

where desert is just an example for the scheme of choice. Desert - for me - has just the right color for comments: aquamarine / light blue.

If you are satisfied with the scheme and would like it to be applied each time you launch vim, you can just edit /etc/vim/vimrc (or in my case with CentOS: /etc/vimrc) and add the following line:

colorscheme desert

with desert again, of course, being the chosen color scheme. This would apply this setting automatically for each vim instance that is launched system-wide. If you do not have access to the system-wide preferences or prefer just using it for your own user account, edit the ~/.vimrc instead.

The blog entry I got this tip from (Asher's space) has further instructions on how to edit existing color schemes and even a link to a blog post that explains how to edit the dark blue color for directories in ls listings with color, but I did not feel the need to go that far. If you are interested in that topic I can only encourage you to visit the original post.

Thanks for reading!

Update (2012-01-04):
Okay, looks like pingback isn't working, so here's a direct link to the original blog post:
vi code highlighting: change the default comments color from dark blue to light blue (https://asher2003.wordpress.com/)

2Jun/110

Detecting the Linux Distribution / Version

Hi!

Just a quick method to (roughly) detect your linux distribution and version:

$ cat /etc/issue
or
$ cat /etc/*release

Cheers 🙂

8Jun/090

Compiling PHP 5 with IMAP support on SuSE / openSUSE Linux

If you get the following configure error:

configure: error: utf8_mime2text() has old signature, but U8T_CANONICAL
is present. This should not happen. Check config.log for additional
information.

It's probably because you're missing either the libc-client-devel package or imap-lib and imap-devel. Fire up yast and install those. You should be good to go now 🙂

(I have openSUSE 11.0 and it doesn't have the libc-client-devel package, but I read about it on another page and thought I'd add it, just to be safe 🙂 )

   
%d bloggers like this: