Hello,

It’s been a while since my last blog post. Work has been amazing and I could hardly find some spare time writing something.

This last days, I’ve been working on upgrading my remaining Squeeze servers to Debian Wheezy… And it implies upgrading from PHP 5.3 to 5.4.

Sounds pretty harmless, right ? Well, look at PHP 5.4 release notes:

• The register_globals and register_long_arrays php.ini directives have been removed.
• Call-time pass by reference has been removed.

That shouldn’t be a big deal unless you’re running some very old code you are not intending to fix. And I did.

After trying to fix the code by adding the required _POST and _GET everywhere, I ended up with half pages still not working. Despites fixing post and get, there were also variables from _SERVER and _COOKIE used everywhere and it’s a lot harder to spot them.

My co-worker said: “Better rewrite everything, it would be faster” and I think he was right.

So, I asked Google about this… And Internet helped me:

Here is the trick:

1. Create a PHP file looping against POST, GET, SERVER and COOKIE arrays and defining all variables (aka register_globals)
2. Use PHP “auto_prepend_file” directive to include this new code in all your pages
3. Do this inside the Apache virtual host config to avoid messing up all other sites by changing php.ini

Create a “dirty_hack_restore_register_globals.php” file in your website wwwroot and fill it with the following code:

Edit your Apache configuration file to add a php_value directive for your wwwroot.

I also added “display_errors” because I had some functions called using references (triggers a PHP Fatal error now).

It’s easier to display them inside the generated HTLM page and users will be able to report them.

Running the command below inside your wwwroot should help you to find all pass-by-references issues:

Beware to only remove the “&” from function call, not function definition!

Keeping “display_errors” enabled can help spotting other issues not covered by this article.

 

Hope that could help ! See you soon.

 

Hi,

This is my first post about fixing things in real life so I’d appologise for all english mistakes I’m going to make. I don’t feel really confortable with DIY words in my non-native language 😉

Anyway, my sister texted me “my macbook won’t power up anymore”.  It’s an old Macbook 13″ she bought a couple of years ago so I said her “that’s probably the motherboard or some electronic stuff broken, bring it if you want but I won’t be able to do anything than saving your data by removing the internal hard drive…

But I’ve been able to do something, here is how.

Symptoms

The Mac won’t power up. When the power cord is plugged the LED is lit but it’s very low. You can hardly guess it’s up. The battery is discharged (one LED blinking when pushing the battery state button).

Sometime, when pressing the power connector, the LED comes up for one sec.

Cause

This “MagSafe” power adapter uses a specific connector with a magnet inside. The plug pins can go back inside the connector to adjust their own size (using a spring?).

After several years of plug in and plug out, the plug pins won’t go out enough anymore, and thus can’t touch their receiver on the Mac.

Fix it!

There’s nothing we can do for the pins to go out more, it’s probably springs which are tired… But we can use an engineering file to reduce the size of the rest of the connector, so it could go deeper inside the mac.

Well that’s pretty hard to explain, but with a picture, you should get it:

Beware to use the file on the edge only! If you do it on the complete connector, you’ll reduce the pins size as well and it’ll be useless!

You’ll probably need a vice, or a lots of patience. I suggest putting the connector wrapped in something to protect it in the vice.

It’s back to life !

 

Hi!

According to several report from my users, it seems we were getting more and more spams written in some foreign languages.
Despite my good amavis/spamassassin filtering system, all kind of bayesian filters are no-op and this spam usually comes from valid yahoo/gmail/others accounts aren’t reported to pyzor or dcc.
Real pain…

The good news is nobody speaks hebrew around, so I can safely tag these mails as junk. Here a quick howto to enable this on Debian:

Edit /etc/spamassassin/v310.pre and uncomment the following line:

Configure this new plugin from /etc/spamassassin/local.cf:

“ok_languages” contains only the lang I actually understand (french and english). You can add yours (see the commented URL for “language codes”).
The second line enable all supported language. TextCat disable by default a couple of rare languages to save servers ressources, but honestly, who cares about CPU usage on servers nowadays…
Then, I increase the score to 5 (default is 2.8) and the last line add a X-Spam-Languages headers so I can check my spam/ham to see which langs have been detected.

However, amavis will rewrite all headers by his own and drop X-Spam-Languages.
So, edit “/etc/amavis/conf.d/50-user” and add the following lines before “1;”:

This will ask amavis to keep this header from spamassasin. Please note, it won’t work unless you’re running amavis >= 2.7 !

You may want to check than spamassasin can load the module fine:

Don’t worry about the “language possibly: en” line, it doesn’t mean anything (when using –lint spamassassin behaves like if it was processing a real mail).

Restart amavis and enjoy !

Here is what you should find in headers of a mail from your Junk mailbox soon:

Hey,

Like me, you may have experiencied slow-down on your PHP/MySQL website, especially when using a crappy CMS (who said Joomla ? ;-)) and have been told “hey, the linux guy, please fix this”.
To be honest, I won’t fix anything as I’m neither a DBA or a developer, however, in this article we will set up an automatic e-mail reporting of slow queries processed by your MySQL server.

First, you’ll have to remove your old syslog server and replace it with something powerful (I mean: syslog-ng):

The default Debian configuration doesn’t log mail system messages into syslog (unlike default rsyslogd), I suggest fixing this first:
In /etc/syslog-ng/syslog-ng.conf, find the line

And add this one:

We need to ask MySQL to log slow queries (queries for which processing took more than NN seconds).
Edit /etc/mysql/my.cnf and uncomment the following lines:

We started investigating with long_query_time set to 5 seconds, but 1 is a decent value. I haven’t tried yet to use something lower than 1 sec but I guess that should work.

Restart mysql server.

Open /etc/syslog-ng/syslog-ng.conf again and add the following piece of configuration:

A little explanation:
First we define a new source of log file. MySQL has its own way of logging and doesn’t rely on syslog, so we need to track its own log file and ask our syslog to merge this logs.
Then we create a new destination similar to the default d_syslog (aka /var/log/syslog file) but with text refactoring (just to make it look like a real syslog entry).
After that, another destination: pipe into an homemade script that will send the lines by email (and text refactoring again).
Finally, associate the sources with the two destinations.

So, yes, we need to create that “mailing” script. Create a new file named /etc/syslog-ng/mail-alert-mysql-slow-query and fill it with:

I stole this script somewhere on syslog-ng’s mailing list and tweaked it a bit.
This script is a lot better because it handles a timeout before sending the email (see 0.1 in last line).
A full “slow query log” is written on several line. Thanks to this genius piece of Python script, only one email containing all of them will be send!

Set this file +x (chmod 755) and restart syslog-ng. Run tail -f /var/log/syslog and start a slow mysql query.
You should see something like this:

Enjoy!

*UPDATE* 2012-10-22

After using this setup for a while, we discovered that most of alert sent during the night were irrelevant.
So here a quick patch to disable it from midnight to 8am:

*UPDATE* 2015-11-19

I made a slightly better version for another issue at work:

Also, in this case I decided to filter out messages within syslog-ng, which would probably be a lot more efficient than using re module in Python script.

Here is my configuration file:

Hi there,

1. Introduction

My first blog post will be about getting hardware accelerated aes-128-cbc cipher on my ALIX board, running a Geode LX. This processor can only handle aes-128-cbc so it’s basically useless, unless you plan to configure every service to only use this specific cipher. Anyway, I’ll do it nevertheless !

Unlike VIA chips (padlock), the Geode doesn’t come with any native acceleration on Linux. It’s however possible using OCF (Open Crypto Framework) which has been ported from BSD to Linux. It’ll provide in-kernel hardware acceleration exported to userland using /dev/crypto device node.

2. Rebuilding Debian’s kernel with OCF-Linux patch

Sadly, OCF requiere little changes into the kernel and cannot (for now) be built as a module.

/!\ If you plan to build a 32 bits kernel from a 64 bits environment, use a 32 bits chroot !

Install a bunch of dependencies: 

Download and extract current Debian’s latest kernel: 

(If there’s a GPG sign error or something, run dpkg-source -x *.dsc)

Download latest OCF-Linux package:

Generate OCF kernel patch:

Let’s get started…

Bump Debian’s package ABI by editing debian/config/defines:

Copy OCF Linux kernel patch:

Create a quilt patch “series” file:
/!\ 3+alix.1 must be be the version according to debian/changelog.
In my example, package version is 3.0.0-3, mine will be 3.0.0-3+alix.1.

Install build dependencies (with some pbuilder’s magic!):

Clean and prepare the source package:

It will probably fails because the patch contains some “fuzz”. If so, go to debian/build/source, duplicate this directory, apply the patch, diff again and replace ocf-linux-26.patch). Run both commands again.

Create a new changelog entry:

Set target to UNRELEASED instead on unstable (first line).
Fill the changelog, here’s mine:

Setup the right kernel flavor (refer to official documentation on Debian’s wiki for more information):

Configure it!

Change CPU type to Geode LX/GX (will enable a few optimization, dunno if it really matters).
Enable OCF in kernel configuration but disable the following hardware chip drivers (they fail to build): Micronas 7108, cryptocteon, XP4xx, Kirkwood, Talitos and Hifn. AMD Geode doesn’t require any driver: upstream provide geode_aes kernel module which only need a way to be accessed from userland, so you may disable everything except cryptosoft (software fallback for unsupported ciphers) and crytodev (userland link).

BUILD!

Once you see linux-headers and linux-image deb package, you can stop the build by hitting Ctrl+c (generating documentation packages takes ages).

We need linux-headers-common as well:

That’s it for the kernel part…

Stay tuned !