Stefan Helander

Magento and always_populate_raw_post_data readiness test fails

/0 Comments/in , /by

When running the Magento readiness test it failed with the message that always_populate_raw_post_data should be set to -1 since it is running under php 5.6. Even though I tried different methods of setting it to -1 and I could verify it by calling phpinfo(); Magento still complained.

The way I solved is a bit rough and it required that I had full system administrator access to the machine (which I had because it was a dedicated server). This is how I solved it:

echo "always_populate_raw_post_data=-1" > /etc/php5/mods-available/always_populate_raw_post_data.ini
php5enmod always_populate_raw_post_data
service php5-fpm restart
service apache2 restart

Stefan Helander

Magento “Cron readiness check failed” solved

/0 Comments/in , /by

First of all, check the Magento guide on this problem here.

In my case, at first I didn’t get any errors in the cron logs in <web-root>/var/log. When running the scripts by hand as the website user I got the not so informing “Cron readiness check failed” in the <web-root>/var/log/update.cron.log.

The reason the “Cron readiness failed” was actually due to some files in the file and directory structure in the web root that can not be written by the cron update script. In my case I used the AWstats package to create website statistics placed in a directory called /stats. This directory and it’s file was not writeable by the cron script, causing it to fail, even though the directory /stats and it’s files are not a part of Magento.

I discovered this by investigating the content of the file var/.update_cronjob_status. In this file you can find important information on why the cron update script is failing.

Stefan Helander

postgrey whitelisting outlook.com

/0 Comments/in /by

Greylisting is a way of reducing the amount of incoming spam and virus emails, in addition to other counter measures. Postgrey is a good choice if you are running postfix.

However, to be able to recieve emails from senders using outlook.com you need to whitelist it. This is because outlook.com is using a different host on each try to deliver the mail, causing delays up to hours, days or the mail not being delivered at all within time limits.

Create/edit the file /etc/postgrey/whitelist_clients.local and add:

# outlook.com
/^.*\.outbound\.protection\.outlook\.com$/
/^.*\.prod\.outlook\.com$/

Then execute:

service postgrey reload

Edit December 2021: The rule is changed from /^mail-.*\.outbound\.protection\.outlook\.com$/ to /^.*\.outbound\.protection\.outlook\.com$/ as Microsoft has changed their server naming standard.

Stefan Helander

How to export mailman mailinglist subscribers

/0 Comments/in /by

There is no built-in function to export the mailinglist subscriber in mailman. If you want to migrate to another software or move to another mailman installation you are in need to export the subscribers. I found this to be the easiest way:

  1. Log in to your mailman mailinglist administration panel, like http://hostname/cgi-bin/mailman/admin/mylist
  2. Replace “admin” with “roster” in the URL in the address bar and press enter, like http://hostname/cgi-bin/mailman/roster/mylist
  3. The subscribers are listed in a bulleted list with the @ sign replaced by ” at “. Mark the list in the browser, right click the selection and “Copy”
  4. Open a plain text editor, like notepad if you are running Windows (avoid Word, Wordpad, LibreOffice writer etc since you will also paste a lot of text attributes in those editors, use a plain text editor)
  5. Right click in the editor and select “Paste”
  6. Search and replace, normally by pressing CTRL-H. Search for ” at ” and replace it with “@” (without the “”) and click “Replace all”.
  7. Save the file

If you are moving the subscriber list into another mailman installation:

  1. In the text editor above, right click and “Select all” to select all text (the list of the subscribers) and then right click and “Copy”
  2. In the administration panel of the new mailman installation, click on “Membership management“
  3. Click on “Add new members to the list“
  4. In the top box where you can type email addresses one per line, right click and “Paste”
  5. Set “Send welcome message to new members” to “No” (unless you really want mailman to send an email welcoming all the subsrcibers you are adding)
  6. Click “Save” in the bottom of the page
Stefan Helander

Delete old PHP5 session files automatically

/0 Comments/in , /by

If not specified the PHP5 session files will be located in a directory like /var/lib/php5 and the builtin garbage collection will delete them, normally after 24 hours.

But often systems like CMS:es will put session files somewhere else and if the system doesn’t have it’s own garbage collection those session files will be kept forever. The reason can be to let a website visitor click “keep me logged in” or to remember a visitors preferences on the website. This normally doesn’t impose a problem as these session files are very small and the number of them counts in hundreds or possibly a couple of thousand files.

However, I encountered a site that created a very large number of session files and kept them forever. At some point the session files count was in the range of millions of files causing the system to run out of inodes. A solution could be to investigate how the system was handling session files but the internal workings of the site was outside of my responsibility. Another solution was to increase inodes but this will be a temporary solution.

The solution chosen was to create a garbage collection routine for the site in question, that deleted session files older than x days. The oldest session files was over 4 years old. The decision was to delete all session files older than a month (30 days), causing visitors who logged in, or had their preferences set, for more than a month ago had to re-login or set their preferences again on their next visit to the site. This was accomplished by the following command (which is run by cron every night):

find /var/www/somedomain.com/web/var/session/ -type f -mtime +30 -exec rm {} \;

Stefan Helander

PHP Parse error: syntax error, unexpected end of file in XXXXX.php

/0 Comments/in , , /by
  • Check that you have spaces around curly braces, i.e. for example don’t use <?php}?> but instead use <?php } ?>
  • If your script has been running without problems on earlier versions of PHP but you are now running PHP 5.4 or later, replace all occurrences of <? with <?php
Stefan Helander

Cron scripts in /etc/cron.daily not running

/0 Comments/in /by

If you put a script to be run by cron in cron.hourly, cron.daily, cron.weekly or cron.monthly but they won’t run, make sure that they:

  • Are chmod +x
  • Are owned by the correct user (like root:root)
  • Start with #!/bin/sh or the corresponding shell used to execute them
  • The filename doesn’t contain any dots, like a script name ending in .sh will not execute

You can also execute the command to verify that your script will be run:

run-parts –test /etc/cron.daily

Stefan Helander

FormMail.pl keeps reporting Bad referrer

/0 Comments/in , /by

I used FormMail.pl from Matt’s Script Archive on one of my web sites and called this script from several other web sites. This way I only need to maintain one copy of the script regarding updates.

The script began complaining about “Bad referrer” when called from my other sites, even though I could positively verify that the other site’s domain name was present in the referrers of FormMail.pl.

Not finding the problem in the script itself I began to think over what I had recently changed on the site hosting the FormMail.pl and one thing was that I recently added a http redirect any incoming calls that didn’t go to the site url using https and I also redirected www.sitename to just sitename. For example, a call to http://www.sitename was redirected to https://sitename using Apache’s http rewrite module.

On my other sites using the FormMail.pl script from the main site, I was calling the FormMail.pl using a url beginning with http://www, i.e. the call was redirected by http redirect rules. When changing the url to call the FormMail.pl script to https://sitename (i.e. using SSL and no www), the call would not be touched by http redirect rules and voila – everything was working again.