Add to Google Reader or Homepage |
~ pjvenda / blog
$home . blog . photography

22 November 2006

bought myself a Wacom Graphire 4 tablet pen

Hi everyone,

I've just bought myself a new Wacom Graphire 4 tablet pen. For those that don't know what it is, a tablet pen is essentially a replacement for the mouse in the form of a ballpoint pen. It's a little more than that - it has a base pad (much like a mouse pad) eventually with some buttons and the pen itself also with some buttons.

The tablet pen isn't designed to *replace* the mouse in every situation, but for image editing and creative digital art it's close to mandatory. Anyone serious about the quality of their digital art work (even amateurs like me) must have or at least try a tablet pen.

Now for installation, I went straight The Linux Wacom Project for configuration guidelines. The howto there is one of the most verbose and complete guides I've ever seen (which is generally a good thing, but can discourage some people) and after a couple of minutes, I had everything set up. No external drivers were used, I didn't have to (or want to) touch the included driver and software CDs and every feature of the Graphire 4 was recognized and available for me to use.
Yep, Linux is sweet!
(I'll be posting a quick configuration guide with all the steps I took on my website)

Next step is the actual purpose of the tablet pen - the almighty GIMP. I'm using the development version 2.3.12 and I just had to enable the extra available input devices. That was it! The pen pointer worked as expected, the "rubber" too (once the correct tool is chosen) and overall the experience is a surprisingly natural and precise control of the imaging software - even for the interface itself! I recommend this hardware device for everyone doing image editing or drawing on the computer.

There are downsides, however... GIMP has a very nasty bug (still uncorrected) that crashes when any tool being controlled by the pen in the "touchdown" (equivalent to click & drag) position reaches a limit of the image window. It will surely ruin hours of hard work. The problem is more serious with the rubber due to the accessibility of the buttons near the pen pointer and the function of the bigger button (drag image position) - with the pen pointer it's possible to keep using the pen away from the window edges at all times. Let's hope the stack traces get the developers to fix this as soon as possible: bugzilla.gnome.org/bug#351246, bugzilla.gnome.org/bug#358442

That's it for today,
Cheers, PJ.

06 November 2006

blog look

I know and agree that this blog looks terrible.
It will take a while, bit I'm working on improving it though. Hopefully CSS will do and I won't have to hack too deep into blogspot widgets.

stand by...

Cheers, PJ.

Sysadmin research

Lately, I've been doing a lot of sysadmin research (and work). In just a few days, I've installed spam filtering engines in several forms, email antivirus, a mail filtering gateway and a multi domain MX server (all virtual accounts) managed by a web application.

warning: this is a big one!

Anti spam and Anti virus mail filtering


First of all, I've installed mail filtering systems on two servers, with antivirus and spam detection. There are many ways to skin a cat and the most widely used ways to skin this cat are, at the moment, clamav and spamassassin respectively for antivirus and spam detection. Another aparently good spam detection software is dspam, which has a different aproach than spamassassin but is said to be much faster and offers a different set of features.

One of my servers was, until recently, running a netqmail installation with qmail-scanner running messages through clamav. It was a recent setup that was running well, despite my lack of experience with qmail. qmail-scanner was hard to get working with clamav due to some permission problems originated by bad distribution packaging. This particular software package filters every message, eventually holding attachments for quarantine and changes the messages a bit (headers and/or body) before returning them to the MTA (this is important!). Essentially it works as a transparent filter integrated with the MTA and that's the way I want it to run.

Integration of spamassassin/clamav with MTAs


Due to the different integration aproaches of dspam and spamassassin, I've decided to use spamassassin, and having it integrated with qmail-scanner was really easy, mostly because qmail-scanner supports it explicitly and enabling spam scanning is only a matter of changing a couple of configuration switches. So for this server, things were going well, I had transparent spam detection and antivirus scanning of incoming mail.

On the other server the running MTA is a postfix 2.2.10, so qmail-scanner would not be adequate (although not impossible). To get things working quickly, I did a simple procmail rule to filter my email through spamassassin's spamc/spamd and it's working. I left system wide autolearn with sensible score values (0.0 < no autolearn < 12.0) and per user bayesian databases can be used. Not the ideal solution, but it works.

:0fw: spamassassin.lock
| /usr/bin/spamc

To get a nice scalable solution for postfix MTA with spamassassin and clamav antivirus, I googled a while and found amavisd-new. amavis is a mail filtering tool that accepts email like an MTA with no queues and runs a chain of programs on each message. It's by no standards a new tool but I've never stumbled upon it before.

Mail filtering gateways


This solution is very apealing for mail filtering gateways, where there's a host that acts as a domain MX, receives email, filters it through antivirus and antispam software and just redirects sane mail (or all mail, depending on the defined policy) to the internal mail servers. What's good about this solution is it's scalability: The MX MTA can be a cluster of servers, the antivirus can be another cluster and the antispam filters can be a third cluster. Such setup can scale to massive processing power and fault tolerance with cheap hardware.
Following this idea, I decided to build such a beast on a virtual server, based on CentOS 4.4. I'm not a fan of CentOS, but it's currently the chosen Linux distribution at where I work, so it seemed appropriate. This mail filtering gateway is built from the following components:
- mta: postfix
- mail filter: amavisd-new
- antispam: spamassassin
- antivirus: clamav
I'll give some feedback on the process one I find enough time to finish it.

Multi domain MX server with virtual accounts


At work, I am currently responsible for building a multi domain MX server with virtual accounts. It has to rely on an LDAP directory for accounting and authentication, supply POP access and provide easy management.

Setup


The Linux distribution is automatically chosen - CentOS 4.4 - and I chose Postfix for the MTA service, openldap for LDAP service, cyrus-sasl for authentication library (hell), dovecot for POP access and Jamm for management service.

It's been fun to build an elaborated MX server such as this, but not everything went well. As far as I was able to debug, cyrus-sasl isn't talking to openldap and there aren't many alternatives to do authenticated relay on postfix. Also, Jamm installation was incredibly complicated, time consuming and, at the end, impossible.

The bad


Starting with Jamm; It's a java web application that deploys on tomcat. Although I never did this before, it shouldn't be that hard, but for CentOS 4.4, it is. There are no official tomcat rpms, so I had to use a third party mirror and install something around 76 packages to get tomcat working. After that, I was unable to build the Jamm application (due to some unmet versioning requirements, I guess) and couldn't deploy it. Sad but true. Why doesn't CentOS include a tomcat/java tools distribution??
One way to solve this is to deploy Jamm on another server, perhaps on a Linux distribution better suited for tomcat. Another way is to use phamm - an alternative interface written in php with even more features than Jamm.
About cyrus-sasl... the story isn't pretty either. There are no alternatives (which don't imply recompilation of postfix and manual integration with another sasl library) and the ldap authentication plugin isn't talking to openldap. I'll have to get this working one way or the other.

The good


On the upside, LDAP is working well and makes management potentially so simple! Dovecot is a fresh, actively maintained IMAP/POP implementation and Postfix is very rich in features that make things such as aliasing, virtual domains, tls negotiations very easy to setup.

Migrating IMAP/POP service


As a sidenote, for migrations between IMAP implementations, Dovecot needs some tweaking for compatibility with courier-imap namespaces. courier-imap aparently uses an implicit INBOX namespace that needs to be defined in dovecot configuration, otherwise it won't find existing folders. As a reference this is, at least, for dovecot 1.0rc10.
The following namespace should be defined in addition to the default_env
# Courier-imap compatibility
namespace private {
separator = .
prefix = INBOX.
inbox = yes
}

Service monitoring tool


Time to wrap up with a service watchdog tool: monit. monit monitors and acts on configured processes and/or files. Processes can be restarted if they somehow die, if thei're using up more than a specified resource limit, files and directories can be monitored for changes, etc. Events are, of course, notified and the system can monitor remote services via authenticated SSL tunnels (for example). Finally, there's a cool web interface to access all this lovely information. I have to say, I was impressed by the website and the tool looks damn good!

That's it for now,
Cheers.