Archive

Archive for September, 2012

Varnish: check your config before you restart!

September 27, 2012 Leave a comment

If you’re using Varnish cache, you will be familiar with the “service varnish restart” then the “oh, there’s a config error and now all my sites are down!”.

Fear no more: there’s a command to check your Varnish syntax before you restart. Just run:

$ varnishd -Cf /etc/varnish/default.vcl

And it will tell you what’s wrong (or at least where the error is). If it prints out all your default.vcl, you’re good!

Advertisements
Categories: English, Varnish Tags: ,

Migrating from Redmine 1 to Redmine 2.1.0 on Debian Squeeze

September 26, 2012 Leave a comment

This is a draft (but unlikely to be improved quickly, so published just in case it might help someone out there).

First: see previous post to install Redmine 2.1.0 (just don’t execute the second half of data filling and stuff: https://beeznest.wordpress.com/2012/09/20/installing-redmine-2-1-on-debian-squeeze-with-apache-modpassenger/

Second: get inspiration from the upgrade guide here: http://www.redmine.org/projects/redmine/wiki/RedmineUpgrade

Third: *before* you call db:migrate, rename the changeset_parents table and possibly the queries_roles table to something else. For example:


rename table changeset_parents to changeset_parentsbak;
rename table queries_roles to queries_rolesbak;

Don’t forget to clean the cache and restart Apache…

Categories: English, Techie Tags:

User’s mail: My Chamilo LMS is slow

September 24, 2012 2 comments

Sir,
I am a user of Chamilo 1.8 as my Website is : http://www.team**.in and i am having about 1300 users registered on that portal
but i always face big problem with chamilo 1.8 that when i take test of all users on same day then it stops working.
chamilo 1.8 is not able to handle online users more than 40, so i am facing big problem right now.

Sir, i want to ask u that should i upgrade or use chamilo 2.1 so that i can handle up to 2000 users online at same time for better output.
or please give me the solution for my problem .

Waiting for your response!

Regards
M.K.

Our answer:

Hello Mandeep,

You can try Chamilo LCMS Connect 2.1 if you want, but:
– there is no working upgrade mechanism from Chamilo LMS (1.8, 1.9) to
Chamilo LCMS Connect (2.1, 3.1) at the moment
– Chamilo LCMS Connect 3.1 should be out in a few days now
– Chamilo LMS 1.8 is *much* lighter than Chamilo LCMS 2.1 as far as we
know, so upgrading would definitely not fix the weight problem.

Apart from that, you might be interested to know that:
– Chamilo LMS 1.9.2 will be released this week (but it is a bit heavier
than Chamilo 1.8)
– Chamilo LMS and Chamilo LCMS Connect have no real common point (apart
of the fact that they are managed by the same association and are LMS
platforms)
– there is an optimization guide in the documentation/ folder of Chamilo LMS. Please
read it and make sure you apply a few hints from there to your portal.
You might get great improvements in speed if you know a little bit of
optimization principles (for example showing the number of connected
users adds a massive load time to each page if you do not use any shared
memory variable caching)
– 1300 registered users shouldn’t be a problem. However, the number of
*simultaneous* users is really where the stress might come from. The
hardware you use for this site will be the issue if you use a virtual
machine with low resources, for example. Do not think of an LMS as a
blog or website: in an LMS, all the content has to be personalized,
which is much more difficult to optimize than a website, where the
content is the same for all users.

I’ve had a look at the reports for the homepage (can’t go further
without login) of http://www.team***.in/elms/ and it seems
alright (C-Rank without optimizations is rather good).

Taking a test for 1300 users simultaneously will
*obviously* put a lot of load on the database. You could reduce the load
by trying different settings, like having all questions on one page
instead of one question per page (because people will finish the exam at
different times and will only send one big SQL request at the end of the
test, which will hopefully be treated faster than one request every time
one single person answers one single question), or adding in-cache
indexes to your MySQL database but, most of all, you will need to have
a solid database behind your site (having it on a separate server to split
the load between php and MySQL might be a good idea).

Best regards,

Y.W.

Cache management in Drupal 6 & 7

September 24, 2012 Leave a comment

There’s a nice article from Makina-Corpus on the topic here: http://www.makina-corpus.org/blog/separate-cache-backends-drupal6-and-drupal7

Notably, the cache_backport module in Drupal 6 backports the cache handlers from Drupal 7 (replaces cacherouter, in a way).

Categories: Drupal, English Tags: , , ,

Installing SoulFu on Ubuntu 12.04 64bit

September 23, 2012 Leave a comment

If you ever want to install the amazing multiplayer SoulFu medieval-fantasy game from Aaron Bishop (up to 4 players with joysticks & keyboard on a single computer) on your Ubuntu 12.04 (Precise) 64bit, follow the howto below. The most problematic point is that it depends on libjpeg62 compiled in a 32bit version. To install this one (although you’re running on 64bit) you need to issue a specific “apt-get install libjpeg62:i386” command (instead of the same version without :i386).

Follow the guide here: http://www.playdeb.net/updates/Ubuntu/12.04#how_to_install. Namely, issue the following commands:

wget -q -O- http://archive.getdeb.net/getdeb-archive.key | sudo apt-key add -
sudo echo "deb http://archive.getdeb.net/ubuntu precise-getdeb games" >> /etc/apt/sources.list.d/playdeb.list
apt-get update
apt-get install soulfu libjpeg62:i38

Then launch SoulFu to start playing:

soulfu

Installing Redmine 2.1 on Debian Squeeze with Apache modPassenger

September 20, 2012 10 comments

This article is co-authored by Jérôme Warnier, from work mostly done by him with my occasional support. Kudos go to him.

We couldn’t find any valuable manual to install Redmine 2.1 on Debian Squeeze, and we sure met a lot of resistance along the way, so we came up with the following step-by-step guide…

Sources of inspiration

We used the following resources as a starting point. Thanks to their respective authors.

Assumptions

We take as given that:

  • We are using a Debian Squeeze installation
  • We have root access to this machine
  • There is public access to the machine itself (public IP)
  • We are able to define a public domain (or subdomain) name for this Redmine installation
  • We have access to define a database (we chose MySQL) user for Redmine (this is important to avoid security risks in sharing accounts with another web system). We also assume that we already have a MySQL server installation
  • We will be using Apache 2’s modPassenger (and Apache 2 is already installed on the server)
  • We will be using redmine.example.com; so every time you see this below, replace it by your own domain

Warming up

We will first need to install basic packages:

apt-get install ruby rubygems libruby libapache2-mod-passenger

Download the latest version of Redmine (2.1.0 in our case) and untar it, then move it to /usr/local/share

ln /usr/local/share/redmine-2.1.0 /usr/local/share/redmine
chown -R root:root /usr/local/share/redmine-2.1.0

Install development libraries for MySQL:
apt-get install libmysqlclient-dev

Install development libs for Imagick:
apt-get install libmagickcore-dev libmagickwand-dev (install shitload of packages)

Running the Gem stuff

Install Bundler (removing useless module, which would otherwise create dependencies):
gem install bundler
cd /usr/local/share/redmine/
/var/lib/gems/1.8/bin/bundle install --without development test postgresql sqlite

Configuration

Copy config/database.yml.example to config/database.yml and edit this file in order to configure your database settings for “production” environment.
Example for a MySQL database using ruby1.8 or jruby:
production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: my_password

Generate a session store secret:
/var/lib/gems/1.8/bin/rake generate_secret_token

Generate the database structure:
RAILS_ENV=production /var/lib/gems/1.8/bin/rake db:migrate

Generate default configuration data:
RAILS_ENV=production /var/lib/gems/1.8/bin/rake redmine:load_default_data
(using “es” for Spanish language in terminal prompt)

Setup config file in config/configuration.yml

Change database_ciphr_key: *******
/var/lib/gems/1.8/bin/rake db:encrypt RAILS_ENV=production

Apache

Setup Apache’s VirtualHost config

# 8080 in this case is because we use a reverse proxy before Apache. Otherwise use :80

<VirtualHost *:8080>
 ServerName redmine.example.com
 DocumentRoot /usr/local/share/redmine/public
 <Directory /usr/local/share/redmine/public>
   AllowOverride all
   Options -MultiViews
 </Directory>
</VirtualHost>

There’s technically nothing special with the Apache config, given we use modPassenger, which makes Apache automatically detect Ruby files and interpret them with the right module… Just pointing to the right directory is enough.

Once you enable this virtual host (a2ensite redmine.example.com) and reload Apache (/etc/init.d/apache2/reload), you should see your site running on http://redmine.example.com.

The default login/password is admin/admin (don’t forget to change this).

Drupal 7 + HTTPS + Nginx + Varnish + Apache + Boost + APC + Securepages + Drupal

September 20, 2012 Leave a comment

If you happen to develop large sites in Drupal, you might fall upon a case like this one, where different servers (namely at least one reverse proxy and one web server) interact, causing a series of chain reactions every time you change something.

It might be frustrating, at times, to try and boost a coordinated system like this, and end up getting your users frustrated because part of it doen’t work, when the rest (the part that *does* work) is super-fast. Come on, you deserve some praise!

Let’s explain a little bit about what requirements might lead to this system…

First of all, you want a website. You don’t want to play with php-fpm yet, so you decide to use Apache + mod-PHP. Great.

Then you want to boost the page interpretation time a little bit, so you decide to use APC. Nothing wrong there.
You now have Apache + PHP + APC + Drupal in line.

Then you want to make sure anonymous users get pre-generated pages to go even faster. You add the Boost module to the loop.
You now have Apache + Boost + PHP + APC + Drupal.

Then you want to speed up loading small static resources, like icons and stuff. You decide to add Varnish in front of the queue.
You now have Vanish + Apache + Boost + PHP + APC + Drupal.

And then comes the late requirement for HTTPS… Damn… Varnish doesn’t support HTTPS!? Man, and now what? Well… you can use Nginx to decipher HTTPS and handle things over to Varnish to follow in the normal queue.
You now have HTTPS + Nginx + Varnish + Apache + Boost + PHP + APC + Drupal.

And finally, your customer tells you that, because of the extra load (between 20% and 400%) generated by the ciphering to HTTPS, he only wants specific pages to be HTTPS. Apart from the mess in redirecting pages to HTTP when they shouldn’t be HTTPS (which can be done in Nginx’s config), you will also need to define rules to send HTTP pages to HTTPS when they should be secure. You can do that with Drupal’s Securepages module.
You finally have your (rather) complete schema of HTTPS + Nginx + Varnish + Apache + Boost + PHP + APC + Securepages + Drupal.

Here is a list of things to think about when doing this:

  1. the Boost module had a bug in early 2012, which didn’t define the DRUPAL_UID cookie very consistently (see previous article on this blog). Because of that, users might loose their session “from time to time” (which is more than frustrating for both you and your customer)
  2. in the specific case of requesting pages to be HTTPS without being logged in (which has the effect of not generating  Drupal connection cookie), the user will first get to Varnish, which will pass on to Apache, which will pass on to Drupal (I’m skipping a few steps here), which will send a HTTP Redirect to Varnish and Varnish will (cache it and) pass it to the user. The user (the user’s browser, in practice) then calls the same URL as HTTPS. Now Nginx takes over for deciphering HTTPS into HTTP before passing it on to Varnish. When Varnish rceives the call, whether it is cached or not, the return value it sends is a 301 Redirect, to the same URL as HTTPS. And so you now are in a loop.
Categories: Drupal, English, php, Techie Tags: , ,
%d bloggers like this: