Comments in the moderation queue: 1

Recently posted comments:

In 1.07, paths are unchanged from the old /var/qmail style.

FWIW, I’ve worked around this for the last 15 years by placing symlinks in /var/qmail, which qmail’s installer happily follows. So /var/qmail paths continue to work, but files are physically installed in sensible locations. For instance:

alias -> /etc/qmail/alias
bin -> /opt/pkg/bin
boot -> /opt/pkg/share/examples/qmail/boot
control -> /etc/qmail/control
doc -> /opt/pkg/share/doc/qmail
man -> /opt/pkg/man
queue -> /var/spool/qmail
users -> /etc/qmail/users

(The qmail package in pkgsrc has done this for 15 years too, because I’m the package maintainer.)

For notqmail 1.08, we intend to address FHS/hier(7) more directly.

Comment by Amitai Schleier Wed Aug 21 09:26:29 2019
This is just me hoping that notqmail hews to convention for where files go, rather than where djb elected to put them.
Comment by Nathan Myers Wed Aug 21 00:47:25 2019
I appreciate the suggestion, but we’re comfortable with the name. It makes clear that this is not DJB’s qmail, so don’t bother him or expect his security guarantee to apply. It’s a bit of wordplay on “netqmail”, the previous community effort. And I think the notqmail logo is funny. All positives :-)
Comment by Amitai Schleier Tue Aug 20 22:40:24 2019
Maybe it would be an idea to name it nqmail instead of notqmail, as to avoid any ‘negative’ connotation?
Comment by Torgeir Veimo Tue Aug 20 20:41:21 2019

Nice work! I have a question,

Isn’t it better to be the third runner up, than the winner, of a bad poetry contest?

Comment by james Tue May 7 07:44:00 2019

Strong work! /giphy chuck norris thumbs up

I like how you “set the table”, as it were, with the concepts of Play, Gratitude, and Community.

Comment by n8dgr8 Sun Nov 18 13:14:17 2018

This seems a reasonable “strangler pattern” for “doing a rewrite” of an old corporation.

Another version is taking a stake in a startup, then if said NewCo does well, buy it and operate it as an arms-length subsidiary with real autonomy. The risk is always tying them to BigCo too tightly.

Comment by @CuriousAgilist Wed Aug 22 01:01:22 2018

Thanks for the feedback! I wish I could offer hard-won advice about overcoming objections and trying a new thing. But as a consultant (or on a coding tour) I’m an outsider. That means I’m playing “influence people’s behavior” on easy mode. It was even easier than usual at BREDEX, because Alex had planted seeds of mob programming a while ago, a couple teams had even already tried it, and she had prepared everyone to understand what it would be like and when they’d be doing it. When people aren’t sure they want to try something, or are sure they don’t, I haven’t found it effective to try to talk them into it. Listening to them, if they’re willing to explain why not and explain it to me, can help — provided I promise not to try to persuade them, only to try to understand their point of view. I always want participation to be voluntary. If what some of us are doing looks fun and effective — and mob programming quite often does — some folks who were on the fence may decide to come watch. Maybe even try it. That’s the best overcoming-objections advice I can give, on any subject.

My best advice for introducing a team to the concept:

  • Remove any feeling of delivery pressure (for instance, by making clear there’s slack in the schedule)
  • Choose a real problem the business needs solved
  • Choose one that’s relatively complex, such that most folks on the team would not want it assigned to them alone
  • Have a whiteboard for writing down whatever you notice as you go (as mentioned above)
  • Two hours a day is a lot; leave plenty of time to decompress and continue working in other ways
  • Be ready for what might happen when team dynamics go under the spotlight
  • Be ready for what might happen when an impediment comes up, because it could block the entire team
  • Bring in an outsider who’s an experienced facilitator, if you can
  • Else become one as quickly as you can, leaning on The Mob Programming Guidebook (Pyhäjärvi and Falco) for what to pay attention to and patterns that have worked

I’m probably forgetting something. Get the book. It’ll fill in the gaps. Best of luck, and let us know how you get on!

Comment by Amitai Schleier Fri Aug 3 11:44:05 2018
Very much enjoying this series! Hearing about all the mob programming opportunities is making me very jealous. Thankfully I have my own plans in the works to train some newbies with mob programming. Would love to hear more about how the mob programming went, especially how you overcame objections and tactics for facilitating groups who are new to the concept.
Comment by Aaron Myatt Tue Jul 24 22:43:49 2018

After limping through a few manual Let’s Encrypt renewals — sometimes too late — I’ve scripted it with acme-tiny. Each user that wants SSL creates $HOME/.letsencrypt. For each site that wants SSL, they create letsencrypt/{cert,service} subdirectories. A shared lighttpd config fragment handles the Let’s Encrypt challenge URL. letsencrypt/service/run looks like so:


exec 2>&1
while true; do
sleep 1200000

Most sites provide only one argument to letsencrypt_create_or_renew. This service directory is then symlinked into $HOME/service. Since my system upgrade script runs svc -t /home/*/service/* (as threatened in the previous comment), these run scripts get restarted approximately once a week. If I skip a system rebuild, that’s fine for SSL purposes: letsencrypt_create_or_renew doesn’t bother talking to Let’s Encrypt servers anyway, unless the cert is more than 15 days old. Once a month, a system cronjob restarts all SSL-aware services, thereby reloading any certificates which may have been updated. Since Let’s Encrypt certs last 90 days, this is probably more than enough automation. I’ll check the logs (and cert expiration dates) in a month to make sure.

Comment by Amitai Schleier Sun Mar 11 14:06:38 2018