Profile

unixronin: Galen the technomage, from Babylon 5: Crusade (Default)
Unixronin

December 2012

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

Most Popular Tags

Expand Cut Tags

No cut tags
Sunday, December 31st, 2006 03:13 pm

I had to reboot babylon5 last night because the framebuffer wedged.  Today, I became suspicious that no new mail had come in since yesterday.

Thus I discovered that if you're running Postfix with qmqpd enabled, on a system which also runs NIS, then it is necessary either to start Postfix BEFORE starting NIS, or force a port for ypbind using the -p switch.  Otherwise, the possibility exists -- rare¹, but a possibility nevertheless -- that ypbind can steal qmqpd's port, 628, thus preventing Postfix from starting.  Whose idea was it for ypbind to pick a random port upon startup?

[1]  When I say "rare", I mean it's the first time it's happened to me in ten years of running Postfix.  But there's evidently a first time for everything.

Tags:
Sunday, December 31st, 2006 09:14 pm (UTC)
Why is ypbind picking a random port to begin with?! Especially one under 1024?!?!
Sunday, December 31st, 2006 09:45 pm (UTC)
It's one of those wonderful RPC quirks.
Monday, January 1st, 2007 01:52 pm (UTC)
Postfix should have shrieked loudly, bad Postfix, no cookie.
Monday, January 1st, 2007 05:19 pm (UTC)
What are the advantages of qmqpd with Postfix?
Monday, January 1st, 2007 07:16 pm (UTC)
It enables much more efficient mail exchange between multiple machines running Postfix within a domain, because QMQP (http://cr.yp.to/proto/qmqp.html) enables mail to be sent in batches rather than sending single messages via SMTP and so all the per-message handshaking overhead is skipped.
Wednesday, January 3rd, 2007 08:52 am (UTC)
There is a reason why those of us who remember its original name used to render it as "yellow plague".

The three-headed dog that guards the gates of hell waits for you to call him...
Wednesday, January 3rd, 2007 12:37 pm (UTC)
Yeah, I've thought at various times about implementing Kerberos instead. But I don't really know enough about it.

Which is, I suppose, a good reason to learn more.