Scan and create multipage .pdf files from .jpeg

Recently I needed to scan and mail multi-page documents. I have a rather simple scanner that can produce descent .jpeg files, but when combining into a document it sucks. Therefore I prefer to scan in 100% quality and then produce documents depending on my needs.

E.g. hereby some commands to put two scanned pages into a single .pdf document with 75% quality (reducing ~2.3MB images into ~800KB):


convert -quality 75 page_1.jpeg page_1_75.jpeg
convert -quality 75 page_2.jpeg page_2_75.jpeg
convert -page A4 -compress jpeg page_1_75.jpeg page_2_75.jpeg document.pdf

One-liner to rename files in bash

To rename many files from one pattern to another use e.g.

for i in *.jpeg; do mv $i ${i//exampel/example}; done

Some useful patterns:

${parameter//substring/replacement}
${parameter##remove_matching_prefix}
${parameter%%remove_matching_suffix}
${parameter:offset}
${parameter:offset:length}
${parameter:offset:length}

To check whether the parameter is null:

${parameter:+use this if param is NOT null}
${parameter:-use this if param is null}
${parameter:=use this and assign to param if param is null}
${parameter:?show this error if param is null}

Joomla! upgrade

Unbelievable that such a simple thing as an upgrade to a newer version of CMS may cause any headache these times. Recently I have received a warning message from my host (lunarpages.com) that I still use an old version (1.7.2) of Joomla! for my company site, while a newer version is available. I have tried to follow official upgrade procedures for about an hour without success, resulting in wrong layouts and half-working admin functionality, and finally ended up just downloading the complete package for Joomla_3.1.5-Stable-Full_Package.zip and simply unzipping it to the current installation folder. That did the trick (well, almost) leaving me with the similarly popular warning message

Joomla upgrade warning Error
Your host needs to disable magic_quotes_gpc to run this version of Joomla!

After some googling around the following solution worked. I have created two files as shown below in the folder with Joomla! installation (so not affecting other websites) and that did the trick.


[php.ini]
magic_quotes_gpc = Off
session.save_path = "/home/<user>/tmp"


[.htaccess]
/home/<user>/www/<site>/php.ini

Enjoy!

Configuring Django under wsgi

A small reminder for settings up Django under wsgi. Apparently the following snippet helps getting the path correct avoiding the dreadful


self.load_middleware()
File "/usr/local/lib/python2.7/dist-packages/Django-1.4.3-py2.7.egg/django/core/handlers/base.py", line 39, in load_middleware
for middleware_path in settings.MIDDLEWARE_CLASSES:
File "/usr/local/lib/python2.7/dist-packages/Django-1.4.3-py2.7.egg/django/utils/functional.py", line 184, in inner
self._setup()
File "/usr/local/lib/python2.7/dist-packages/Django-1.4.3-py2.7.egg/django/conf/__init__.py", line 42, in _setup
self._wrapped = Settings(settings_module)
File "/usr/local/lib/python2.7/dist-packages/Django-1.4.3-py2.7.egg/django/conf/__init__.py", line 95, in __init__
raise ImportError("Could not import settings '%s' (Is it on sys.path?): %s" % (self.SETTINGS_MODULE, e))
ImportError: Could not import settings 'xxx.settings' (Is it on sys.path?): No module named xxx.settings

messages from Apache (well, instead of ‘xxx’ your project name will be mentioned of course).

The fix
import sys

# Correct path.
app_path = os.path.abspath(os.path.join(os.path.dirname( __file__ ), '..'))
if app_path not in sys.path:
sys.path.append(app_path)

For completeness, the sites-enables/xxx looks like

WSGIPythonPath /var/www/path/to/project

<VirtualHost *:80>
DocumentRoot /var/www/path/to/project
ServerAdmin admin@example.com
ServerName my.example.com

Alias /static/ /var/www/path/to/project/

Order deny,allow
Allow from all

WSGIDaemonProcess project_name
WSGIScriptAlias / /var/www/path/to/project/wsgi.py

</VirtualHost>

Happy Djangoing!

UPDATE: when multiple Django applications are configured under Apache apparently a request could be routed to the Apache instance hosting wrong application. The server will not load application and Apache log files would show:


Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/Django-1.4.3-py2.7.egg/django/core/handlers/wsgi.py", line 219, in __call__
self.load_middleware()
File "/usr/local/lib/python2.7/dist-packages/Django-1.4.3-py2.7.egg/django/core/handlers/base.py", line 39, in load_middleware
for middleware_path in settings.MIDDLEWARE_CLASSES:
File "/usr/local/lib/python2.7/dist-packages/Django-1.4.3-py2.7.egg/django/utils/functional.py", line 184, in inner
self._setup()
File "/usr/local/lib/python2.7/dist-packages/Django-1.4.3-py2.7.egg/django/conf/__init__.py", line 42, in _setup
self._wrapped = Settings(settings_module)
File "/usr/local/lib/python2.7/dist-packages/Django-1.4.3-py2.7.egg/django/conf/__init__.py", line 95, in __init__
raise ImportError("Could not import settings '%s' (Is it on sys.path?): %s" % (self.SETTINGS_MODULE, e))
ImportError: Could not import settings 'xxx.settings' (Is it on sys.path?): No module named xxx.settings

basically failing to load settings from the wrong application. More on this topic in this blog post, but the fix seem to be specifying WSGIDaemonProcess per application.

Setting up Dango i18n, i10n

Anything related to i18n/i10n subject seem to be somehow quirkier than it looks at first glance. Python (2.x) itself and handling of unicode is a story apart.

This time I was looking into building a small website that has to provide UI in different languages. As this is one of the things you want to have right away I’ve started experimenting with adding i18n and i10n support.

First step is easy, the settings.py already had proper settings. Then for .py files it is rather straightforward to add e.g. (for forms):


from django.utils.translation import ugettext_lazy as _
...
city_name = forms.CharField( required = False, label = _('City:'))

For the .html files something like


{% load i18n %}

{% trans "Hello there!" %}

Then create under project folder folder ‘conf/locale’ (if you don’t do this it will complain), and then run

django-admin.py makemessages -l ru

Edit the resulting django.po file, add translations to your messages.

Warning: don’t forget to edit the following field, which comes EMPTY first, even while you have given it a parameter! Otherwise this file will be not used properly.

"Language: ru\n"

Then compile your nice and shiny translations:

django-admin.py compilemessages

Now we get all messages available. At least they should. But there is another trick missed in the Django documentation/tutorials: you HAVE TO specify the location of the message files explicitly in your settings.py otherwise your texts will continue coming up in default (en) language no matter how hard you try. E.g.:

LOCALE_PATHS = (
os.path.join(os.path.dirname(__file__), 'conf', 'locale').replace('\\','/'),
)

Well, after all this it seems to work. But it costs quite some searching and poking around to come to this. I can imagine after several rounds this becomes obvious, but you don’t get any errors, warnings, whatsoever, it just does not what you want it to do. Well, I hope it will do it for you now :).

Happy Djangoing!

(Re-)configuring Apache SSL on Ubuntu server

Since my old server died there were many things waiting to happen. First of all the main ‘carrier’ for my project information was located on a webserver obviously hosted on the dead server. For security reasons it only serves HTTPS, so, guess what, I needed to setup it up again.
The very first thing I found that my SSL certificates were no longer valid as the key used to generate them was happily buried on (both) dead hard disks. Arrrgghhh. OK, luckily it takes only few mouse clicks on GoDaddy site to re-generate the certificates. You perform

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

on the server where the domain is to be hosted (in my case my smallish-greenish server) and copy/paste the content of the .csr file to the GoDaddy’s interface. Viola! You can download your certificates now and put them under e.g. the corresponding VirtualHost:


SSLEngine on
SSLCertificateFile /etc/apache2/certificates/watchitforme/watchitfor.me.crt
SSLCertificateKeyFile /etc/apache2/certificates/watchitforme/watchitfor.me.key
SSLCertificateChainFile /etc/apache2/certificates/watchitforme/gd_bundle.crt
ServerSignature Off

Good. Restart Apache using e.g.

sudo /etc/init.d/apache2 restart

…browse to your https://domain.tld and WTF-WTF-WTF…

Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

Watta… well, this is something new apparently, but you are also required to edit the Apache ports.conf file, and add

Listen 443
NameVirtualHost *:443

and then in your virtual host setup you need to say instead of

<VirtualHost domain.tld:443>

put

<VirtualHost *:443>

Restart Apache again and you get your pages nicely served through HTTPS. C’mon, why so much trouble each time?..

p.s. There are a lot of posts about Chrome, IE, etc settings, but check the root cause first!

FreeBSD vs Ubuntu server

Some frustration from installing FreeBSD on a Foxconn A3550 with a Realtek 8168B/8111 card and Ubuntu saving my day (again).

After a pretty sad death of both harddisks in RAID1 setup on my old server that was sucking a lot of electricity and making pretty annoying level of noise for several years (don’t ask when the last backup was performed) I was obviously up to another setup. This time I decided to go for a ‘greenish’ setup without unnecessary redundancy and splitting the concerns of large storage and running all kinds of things like Apache, MySQL, etc for private projects data.

After some small research I settled down on Foxconn nT-A3550 E-350. Dropped some 4Gb of memory and 64 Gb SDD gave me a tiny silent box that can be used to exercise all kinds of things. There was only one small thing left… Installing an OS.
Somehow I had a FreeBSD as the first candidate when thinking of a server. Previous server had a rather old Ubuntu server version, but this time I was up to something new. Except… well, one by one.

My first idea was getting recent version of FreeBSD, which is at the time of writing was 9.0. Few minutes of download, dd’ing a spare USB stick and we’re done. Installation went smooth, although I’ve only realized later that it was due to the fact that 9.0 recognized the Intel wireless card in the little Foxconn and downloaded everything using wireless connection. The problem started when I’ve tried to setup wired connection (preferred for stability, as wireless may drop once in a while). Well, there was no luck for two sleepless nights and a lot of digesting of forums. I’ve tried many things and narrowed the problem down to the driver of the Realtek 8168B/8111 under FreeBSD. While it was recognized there was no luck in getting either DHCP acknowledgement or getting connection using static IP configuration. Symptoms: card fires up, link is detected, DCHP client tries to get IP, but does not “see” the DHCP offer from the router. Checking the logs of the router show that the offer is sent, but apparently never received/understood by the client. Apparently Realtek did release a driver version for FreeBSD 8.0 and some people claim that there was better support after 9.0 release this didn’t really help. I’ve tried the Realtek version, but it didn’t compile under 9.0 due to cleanup of the internal software interface. The version in 9.0 looked like a more advanced version apparently it didn’t work with my card. Bad luck…

Next trying FreeBSD 8.3 The idea was that the drivers are further developed since the 9.0 release. Well, I haven’t even got to the drivers. The Intel wireless card was not recognized and the wired Realtek still didn’t work with the same symptoms. That was it for FreeBSD.

And then Ubuntu (12.01 LTS server to be specific). Creating a bootable USB stick involved just another conversion step (from .iso to .img) as nicely described on the Ubuntu site and off we go. Guess what, the installation went smooth and all hardware detected at once. About 30 minutes later I had a fully functioning system with the software installed. So after all I am back to Ubuntu again.

Second though on FreeBSD. I may give it a chance later on when 9.1 comes out. Having manually built driver that relies on a (apparently deprecated) interface just asks for a trouble with the next update (which may be needed due to e.g. security reasons).