Mathieu Gueydan

Hello,

This small note just to remind me, what just happened as I upgrade a debian with an installed postfix using courier as SASL authentifiaction (for smtp)

1. First, the smtp daemon had no access to the courier socket.

Symptom :

tail /var/log/mail.info
SASL authentication failure: cannot connect to Courier authdaemond: Connection refused

Explanation :

For some reason, the smtp daemon is chrooted again. There maybe is a solution to allow him to access to courier socket even if it is chrooted, but I didn't find any (played some time with symbolic links but unsuccessfully. Tried to ask courier to put its socket in postfix chroot jail, but didn't work either)

So I choosed to unchroot it :

sudo emacs /etc/postfix/master.cf
smtp inet n - n - - smtpd

And then restart postfix of course.

2. Then, the smtp daemon had no right anymore to read the courier socket.

Symptom :

tail /var/log/mail.info
SASL authentication failure: cannot connect to Courier authdaemond: Permission denied

Explanation :
The rights on the socket folder went wrong. Be carefull, the rights on the socket itself where good.

ls -l /var/run/courier/authdaemon/socket
ls: cannot access /var/run/courier/authdaemon/socket: Permission denied

sudo ls -l /var/run/courier/authdaemon/socket
srwxrwxrwx 1 root root 0 Jul 14 21:31 /var/run/courier/authdaemon/socket

sudo ls -l /var/run/courier/
drwxr-x--- 2 daemon daemon 100 Jul 14 21:31 authdaemon

I choosed to add postfix in the daemon group :

sudo usermod -a -G daemon postfix

You may find multiple topics on various internet forums describing the very same symptom:

On Ubuntu with old Nvidia cards, at some point, generally after an apt-get update or new video driver installation : compiz disappear.

There are a lot of "fixes" answered on those forums. None of them concerns the case I encountered multiple times on my laptop.

I put the description of my problem here. Hope it will be useful. At least it will be a reminder for myself :

Here is the log describing the error :
> sudo grep "(EE)" /var/log/Xorg.0.log
[ 693.341] (EE) Failed to load /usr/lib/x86_64-linux-gnu/xorg/extra-modules/x86_64-linux-gnu_xorg_extra_modules/x86_64-linux-gnu_xorg_extra_modules/...
[ 693.341] (EE) Failed to load module "glx" (loader failed, 7)

Here are some strange resulted commands :
> ls -l /etc/alternatives/x86_64-linux-gnu_xorg_extra_modules
/etc/alternatives/x86_64-linux-gnu_xorg_extra_modules -> /usr/lib/x86_64-linux-gnu/xorg/extra-modules
> ls -l /usr/lib/x86_64-linux-gnu/xorg/extra-modules
/usr/lib/x86_64-linux-gnu/xorg/extra-modules -> /etc/alternatives/x86_64-linux-gnu_xorg_extra_modules

Here is how I "solved" it :
> sudo rm /usr/lib/x86_64-linux-gnu/xorg/extra-modules

Here are 6 mottoes I believe in :
- First : Make it work. Then : Refactor - Anonymous
- To lead people, walk behind them - 老子
- Inherit, not to reuse, but to be reused - Sutter / Alexandrescu
- Quality is not an act, it is a habit - Aristotle
- Why programm by hand in five days what you can spend five years of your life automating - Terence Parr
- Cease dependence on mass inspection to achieve quality - W.E. Deming

Collecting them has been proven to be very useful. It allows me to display clear messages to my bosses, customers, co-workers... I use to write them on walls or whiteboards in my workspace and even printed them on my business cards

I'm not sure I'm smart enough to say something new and useful on Sutter's and Alexandrescu's work or on Lǎo zǐ's thinking, but what I will try to do in this post is to explain what's hidden behind the very first one :

First : make it work. Then : refactor

Basically, this is a procedure on how to build something new, especially software.

Let's look what one may want to do, when before build something new (a new feature, a new product...):

1. spend a lot of time thinking about what should be done and then writing specifications. These thinkings and specifications of course include technical details like configuration files, protocols used etc.

2. spend a lot of time building everything that will be used by the application. Among them: environment, unitary-tests, nice object model, tools and components like loggers, rpc ...

Of course you want all of theses. Going on without any unitary test or without a good logger is a waste of time. Everybody knows it. I know it.

What this motto means, is that before all of this, you want to do a PoC. A fast-coded prototype that will demonstrate the main feature of your software, and only the main feature. And you want your customer to have this in hands very early.

There are at least 3 reasons why you want this are :

1. Because you're not sure of the feasibility of what you want to do. Most of the time, even after a very careful thinking and a nice specification, coding it make new issues appear you was not able to anticipate.

2. Because you want to provide something concrete to your user/customer. Your user/customer will have something to focus on very early. Every discussion that takes places after that may be done with concrete demonstrations. It drastically reduce the customer/coder misunderstandings.

3. Because it make you shine. When your competitors need 2 weeks to provide something, you will come back to your client in 2 days. Of course, in the end you may not be faster. But what will stay in mind is that you came back with something in 2 days.


I don't spend too much words on the second part : "Then refactor", it's pretty obvious. You wrote some bad-code in order to provide a PoC. You don't want this code to stay in your final application. You need refactoring.