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?
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.
Harald Hannelius <harald.hannelius@gmail.com> wrote:
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.
It must be well buried somewhere as usual :-)
Andrzej Adam Filip wrote:
Harald Hannelius <harald.hannelius@gmail.com> wrote:
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.
That's simple: /etc/mail/[Mm]akefile is not part of the sendmail distribution, so obviously it is not documented by us.
It must be well buried somewhere as usual :-)
Maybe complain to whoever distributes a Makefile without
documentation?
Where is documented a proper safe way to compile (big) map files
according to sendmail.org?
Correcting the original post, it was virtual-domains that was the problematic db in our case.
On Tuesday, 25 May 2021 at 07:53:26 UTC+3, Claus Aßmann wrote:clip
Harald Hannelius wrote:
Version 8.15.2Correcting the original post, it was virtual-domains that was the problematic db in our case.Please post the output of
sendmail -bt -d0.15 </dev/null
Compiled with: DNSMAP IPV6_FULL LDAPMAP LDAP_REFERRALS LOG MAP_REGEX
about before me.It seems there is a locking problem on your systemSorry, I can't tell how long this has been happening but I remember that it has happened a couple of years back but back then I didn't trace it down this far. I concur that there's something going on that I really am sure that someone else has thought
and I would like to know which components cause that.
Andrzej Adam Filip wrote:
Where is documented a proper safe way to compile (big) map filesDo you really have to ask?
according to sendmail.org?
man makemap
How long does makemap for your "big map files" take on a recent
computer? If it's "too long" you can use the well-known workaround.
Harald Hannelius wrote:
Correcting the original post, it was virtual-domains that was the problematic db in our case.Please post the output of
sendmail -bt -d0.15 </dev/null
On which filesystem is /etc/mail/ ?
Which Berkeley DB version is used by sendmail?
It seems there is a locking problem on your system
and I would like to know which components cause that.
man makemap
I honestly checked there first, but there was no mention of risks involving running
makemap and having constant incoming e-mail.
Harald Hannelius wrote:
man makemap
I honestly checked there first, but there was no mention of risks involving runningBecause that was not a known problem - your bug report is the first
makemap and having constant incoming e-mail.
time I heard about this.
Thanks for the info provided elsewhere in this thread, I will try
to reproduce the problem (and then fix it).
Harald Hannelius wrote:
[[...]] it was virtual-domains that was the problematic db in our case.
Another question:
what's the definition of the map in the mc/cf file?
FEATURE(`virtusertable', ???)
It's not using -o (optional), right?
[[...]] it was virtual-domains that was the problematic db in our case.
25 + years with Sendmail and I would have found a bug? Incredible :)
I do think there's a reason why Debian does it the way they do. It
would be interesting to do some internet-archeology and find out why.
On 5/26/21 12:10 AM, Harald Hannelius wrote:
25 + years with Sendmail and I would have found a bug? Incredible :)
It happens.
I do think there's a reason why Debian does it the way they do. It
would be interesting to do some internet-archeology and find out
why.
I won't be surprised if it's because the time it took to build the map
on older systems for large numbers of entries took too long. Which
seems to be a non-starter for about the last decade or two for me.
Define/estimate your large (number of entries)
AFAIR Suresh (ancient times c.m.sendmaik poster) switched from sendmail
to postfix to avoid problems with exporting/map *HUGE* SQL database into sendmail maps (*LONG* build times).
On 5/26/21 12:10 AM, Harald Hannelius wrote:
25 + years with Sendmail and I would have found a bug? Incredible :)
It happens.
I do think there's a reason why Debian does it the way they do. It
would be interesting to do some internet-archeology and find out
why.
I won't be surprised if it's because the time it took to build the map
on older systems for large numbers of entries took too long. Which
seems to be a non-starter for about the last decade or two for me.
Another *very good* reason may be to keep old map version if the makemap fails e.g. due bad line format/missing value. Shit happens.
Update 2:
it seems the use of fcntl() for file locking does not work for
Berkeley DB 5.x (and later?).
8.17.0.1 (just released) fails to compile if such a setup is
detected. Alternatives are listed in the release notes etc.
^^^^^^^^^^^^^^^^8.17.0.1 (just released) fails to compile if such a setup is
detected. Alternatives are listed in the release notes etc.
conf.c:5952:6: error: invalid preprocessing directive #ERROR
# ERROR: "Berkeley DB file locking needs flock() for version 5.x (and greater?)"
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 209:53:04 |
Calls: | 6,619 |
Calls today: | 1 |
Files: | 12,168 |
Messages: | 5,317,184 |