Comments for geekgeekgeek http://geekgeekgeek.antithetical.org geeky stuff Sat, 4 Feb 2012 23:59:54 +0000 http://wordpress.org/?v=2.0.3 Comment on fixing wordpress by geekierthanthou http://geekgeekgeek.antithetical.org/2006/06/fixing-wordpress/#comment-37 Sat, 25 Nov 2006 22:35:17 +0000 http://geekgeekgeek.antithetical.org/2006/06/fixing-wordpress/#comment-37 Trying to figure out how to change months in the archive list from long format 'November' to 'Nov.' Directly editing locale.php works, but I haven't found a hook that does what I want it to yet. Trying to figure out how to change months in the archive list from long format ‘November’ to ‘Nov.’ Directly editing locale.php works, but I haven’t found a hook that does what I want it to yet.

]]> Comment on upgrading sendmail 8.12.8 to 8.13.7 by geekgeekgeek http://geekgeekgeek.antithetical.org/2006/06/upgrading-sendmail-8128-to-8137/#comment-5 Fri, 23 Jun 2006 23:42:51 +0000 http://geekgeekgeek.antithetical.org/2006/06/upgrading-sendmail-8128-to-8137/#comment-5 Just for the record, I upgraded the sasl daemon, rebuilt sendmail with sasl support, and re-linked files in smrsh's execute directory on the dev box, too, so the boxes are once again in sync -- except for the mail filtering I'm testing on dev. Just for the record, I upgraded the sasl daemon, rebuilt sendmail with sasl support, and re-linked files in smrsh’s execute directory on the dev box, too, so the boxes are once again in sync — except for the mail filtering I’m testing on dev.

]]> Comment on upgrading sendmail 8.12.8 to 8.13.7 by geekgeekgeek http://geekgeekgeek.antithetical.org/2006/06/upgrading-sendmail-8128-to-8137/#comment-4 Fri, 23 Jun 2006 14:15:41 +0000 http://geekgeekgeek.antithetical.org/2006/06/upgrading-sendmail-8128-to-8137/#comment-4 Everything worked fine on the dev box (naturally) but the mailman installation on the production box complained: <code> smrsh: \"mailman\" not available for sendmail programs (stat failed) </code> Here\\\'s what happened: the default build for the new sendmail pointed smrsh at /usr/adm/sm.bin vs RedHat 9\\\'s default of /etc/smrsh. I could have recompiled smrsh: <code> -DSMRSH_CMDDIR=\\\\\\\"dir\\\\\\\" \\\\\\\"/usr/adm/sm.bin\\\\\\\" </code> But I took the easy way out and moved the former contents of /etc/smrsh. This was a little harder to figure out than it might have been for three reasons: <ol> <li>Red herring! I got hung up with lookng for setuid problems. Argh! </li> <li>Red herring! Found some documentation that said in /etc/mail/aliases I should change lines like <code>listname: \\\\\\\"&#124;/$pathtomailman/mailman post listname\\\\\\\"</code> to <code>listname: \\\\\\\"&#124;/$pathtosmrshexecutables post listname\\\\\\\"</code> This works (at least for \\\\\\\"post\\\\\\\") but it\\\\\\\'s not necessary and didn\\\\\\\'t fix my problem. </li> <li>This instruction was misleading: Figure out where smrsh expects symlinks for allowable mail programs. <strong>At the very beginning</strong> of the following output you will see a full path to some directory, e.g. /var/adm/sm.bin or similar: <code>% strings $path_to_smrsh &#124; less</code> In point of fact, the relevant output was not easy to parse. What I had to do was <code> strings $path_to_smrsh &#124; grep etc <br /> strings $path_to_smrsh &#124; grep usr </code> And so forth to see what was going on. </li> </ol> Everything worked fine on the dev box (naturally) but the mailman installation on the production box complained:

smrsh: \"mailman\" not available for sendmail programs (stat failed)

Here\\\’s what happened: the default build for the new sendmail pointed smrsh at /usr/adm/sm.bin vs RedHat 9\\\’s default of /etc/smrsh. I could have recompiled smrsh:

-DSMRSH_CMDDIR=\\\\\\\"dir\\\\\\\" \\\\\\\"/usr/adm/sm.bin\\\\\\\"

But I took the easy way out and moved the former contents of /etc/smrsh.

This was a little harder to figure out than it might have been for three reasons:

  1. Red herring! I got hung up with lookng for setuid problems. Argh!
  2. Red herring! Found some documentation that said in /etc/mail/aliases I should change lines like
    listname: \\\\\\\"|/$pathtomailman/mailman post listname\\\\\\\"
    to
    listname: \\\\\\\"|/$pathtosmrshexecutables post listname\\\\\\\"
    This works (at least for \\\\\\\”post\\\\\\\”) but it\\\\\\\’s not necessary and didn\\\\\\\’t fix my problem.
  3. This instruction was misleading:
    Figure out where smrsh expects symlinks for allowable mail programs. At the very beginning of the following output you will see a full path to some directory, e.g. /var/adm/sm.bin or similar:
    % strings $path_to_smrsh | less
    In point of fact, the relevant output was not easy to parse. What I had to do was

    strings $path_to_smrsh | grep etc

    strings $path_to_smrsh | grep usr

    And so forth to see what was going on.
]]> Comment on upgrading sendmail 8.12.8 to 8.13.7 by geekgeekgeek http://geekgeekgeek.antithetical.org/2006/06/upgrading-sendmail-8128-to-8137/#comment-3 Fri, 23 Jun 2006 13:03:30 +0000 http://geekgeekgeek.antithetical.org/2006/06/upgrading-sendmail-8128-to-8137/#comment-3 While trying to resolve smrsh problem, noticed this: <code> [root@vps mail]# newaliases <br /> Warning: Option: AuthMechanisms requires SASL support (-DSASL) <br /> Warning: Option: AuthOptions requires SASL support (-DSASL) </code> So it looks like I built sendmail without SASL. Figured out I\'m running SASL 2.1.10. and found instructions to add <code>APPENDDEF(`confENVDEF\\\', `-DSASL=2\\\') APPENDDEF(`conf_sendmail_LIBS\\\', `-lsasl2\\\')</code> to site.config.m4 (in $sendmailsourcepath/devtools/Site) compiled and re-installed sendmail (sh Build, sh Build install), no dice. Obtained, built and installed <a class="external" href=\"http://cyrusimap.web.cmu.edu/downloads.html\" rel="nofollow" rel="nofollow">SASL 2.1.22</a>. That was easy, but of no help. Of course, it\'s probably not a bad idea to be on the latest stable production release. Tore out hair for a couple of hours. Finally saw this in the devtools/Site/README: <code>Notice: if any of the above files is changed, the -c flag must be specified with the Build command, otherwise those changes will have no effect.</code> Oh, great, <em>now</em> you tell me. While trying to resolve smrsh problem, noticed this:

[root@vps mail]# newaliases

Warning: Option: AuthMechanisms requires SASL support (-DSASL)

Warning: Option: AuthOptions requires SASL support (-DSASL)

So it looks like I built sendmail without SASL. Figured out I\’m running SASL 2.1.10.
and found instructions to add
APPENDDEF(`confENVDEF\\\', `-DSASL=2\\\')
APPENDDEF(`conf_sendmail_LIBS\\\', `-lsasl2\\\')
to site.config.m4 (in $sendmailsourcepath/devtools/Site)
compiled and re-installed sendmail (sh Build, sh Build install), no dice.
Obtained, built and installed SASL 2.1.22.
That was easy, but of no help. Of course, it\’s probably not a bad idea to be on the latest stable production release.
Tore out hair for a couple of hours. Finally saw this in the devtools/Site/README:
Notice: if any of the above files is changed, the -c flag must be specified with the Build command, otherwise those changes will have no effect.
Oh, great, now you tell me.

]]> Comment on upgrading sendmail 8.12.8 to 8.13.7 by geekgeekgeek http://geekgeekgeek.antithetical.org/2006/06/upgrading-sendmail-8128-to-8137/#comment-2 Thu, 22 Jun 2006 20:59:53 +0000 http://geekgeekgeek.antithetical.org/2006/06/upgrading-sendmail-8128-to-8137/#comment-2 Did this first on dev, then the exact same process on prod Did this first on dev, then the exact same process on prod

]]>