1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • User unknown while 'makemap hash' [generating new access table]

    From Harald Hannelius@21:1/5 to Andrzej Adam Filip on Mon May 24 05:10:59 2021
    On Monday, 24 May 2021 at 14:59:07 UTC+3, Andrzej Adam Filip wrote:

    Have you considered using make (Makefile) in /etc/mail directory?
    It should allow you more atomic & fail-safe generation of new map version.

    I used it so much that I gleaned the solution from it. Slackware even has a Makefile, has it always been included?

    The rebuild includes a lot of other stuff in our environment, so I had to figure out how to do this right. Still funny that sendmail docs don't mention this.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrzej Adam Filip@21:1/5 to Harald Hannelius on Mon May 24 11:58:19 2021
    Harald Hannelius <harald.hannelius@gmail.com> wrote:
    Hello,

    it's been years since we had Usenet, I miss it so.

    I noticed that while running the command '/usr/sbin/makemap hash /etc/mail/access.db < /etc/mail/access' sendmail says "User unknown"
    for users for a few fractions of a second.

    Am I doing it wrong? Shouldn't there be a seamless gap between the old and new access db's?

    14:05:00.999160066 username@ourdomain.com... deliverable: mailer esmtp, host ourdomain.onmicrosoft.com., username@ourdomain.onmicrosoft.com.
    14:05:01.014579615 username@ourdomain.com... deliverable: mailer esmtp, host ourdomain.onmicrosoft.com., username@ourdomain.onmicrosoft.com.
    14:05:01.030263277 username@ourdomain.com... User unknown
    14:05:01.057106599 username@ourdomain.com... User unknown
    14:05:01.074483391 username@ourdomain.com... deliverable: mailer esmtp, host ourdomain.onmicrosoft.com., username@ourdomain.onmicrosoft.com.
    14:05:01.091811253 username@ourdomain.com... deliverable: mailer esmtp, host ourdomain.onmicrosoft.com., username@ourdomain.onmicrosoft.com.

    Have you considered using make (Makefile) in /etc/mail directory?
    It should allow you more atomic & fail-safe generation of new map version.

    AFAIK /etc/mail/Makefile provided by Debian-Linux uses 4 step procedure
    1. create new map version *in new/separate file* 2. fix ownership
    3. fix access permissions 4. do atomic replacement (file rename) of old
    version by new version

    /usr/sbin/makemap hash /etc/mail/access.new.db < /etc/mail/access
    chown smmta:smmsp /etc/mail/access.new.db
    chmod 0640 /etc/mail/access.new.db
    mv -f /etc/mail/access.new.db /etc/mail/access.db


    AFAIR Ancient horror stories here included *HUGE* map taking hours to
    generate as hash and 20 minutes to generate as btree from pre sorted
    input [It was ling before SSD]

    --
    [Andrew] Andrzej A. Filip

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Andrzej Adam Filip on Mon May 24 17:54:55 2021
    Andrzej Adam Filip wrote:

    AFAIK /etc/mail/Makefile provided by Debian-Linux uses 4 step procedure
    1. create new map version *in new/separate file* 2. fix ownership
    3. fix access permissions 4. do atomic replacement (file rename) of old version by new version

    This is useful if makemap takes "too long".

    However, any "long running" sendmail process will NOT notice the
    new map content -- sendmail checks whether the actual file it has
    open changed.

    Of course sendmail does this with the proper locking -- but if that
    locking is broken in some way on the OS (esp. if "lock on open"
    does NOT work!) then there can be problems.


    --
    Note: please read the netiquette before posting. I will almost never
    reply to top-postings which include a full copy of the previous
    article(s) at the end because it's annoying, shows that the poster
    is too lazy to trim his article, and it's wasting the time of all readers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)