Question about postscreen_cache.db
Hello, I have an admittedly basic question, but I have been trying to troubleshoot this for a while with no success. I have enabled postscreen(8) on Postfix 3.1 and receive a warning in mail.log: “close database /var/spool/postfix/var/lib/postscreen_cache.db: No such file or directory (possible Berkeley DB bug)” A quick Google of this returns that this is caused on Debian systems that run Postfix in a jail (which matches my system). The most recent post regarding this appears to be here: https://tech.feedyourhead.at/content/postscreen_cache_db_no_such_file As per the blog posting, I stopped Postfix and created a directory in the jail for the postscreen_cache.db: $ sudo systemctl stop postfix.service $ sudo mkdir -p /var/spool/postfix/var/lib/postfix I moved the postscreen_cache.db file to this location: $ sudo mv /var/lib/postfix/postscreen_cache.db /var/spool/postfix/var/lib/postfix I set the permission and ownership on this file: $ sudo chown postfix:postfix /var/spool/postfix/var/lib/postfix/postscreen_cache.db $ sudo chmod 0660 /var/spool/postfix/var/lib/postfix/postscreen_cache.db I checked that the postfix user can access this file: $ sudo -u postfix namei -m /var/spool/postfix/var/lib/postfix/postscreen_cache.db I *DIFFER* from the blog in that I do not create a symbolic link - I use the Postfix main.cf configuration parameter below: postscreen_cache_map = btree:/var/spool/postfix/var/lib/postfix/postscreen_cache I then start Postfix: $ sudo systemctl start postfix.service When I check: /var/spool/postfix/var/lib/postfix I can see that postscreen_cache.db is updated as time progress, but I still get the warning about not being able to close the postscreen_cache.db database. What am I missing ? Thanks, - J
Re: Question about postscreen_cache.db
Hi, > On Nov 11, 2017, at 3:06 AM, J Doe wrote: > > Hello, > > I have an admittedly basic question, but I have been trying to troubleshoot > this for a while with no success. > > I have enabled postscreen(8) on Postfix 3.1 and receive a warning in > mail.log: > > “close database /var/spool/postfix/var/lib/postscreen_cache.db: No such file > or directory (possible Berkeley DB bug)” > > A quick Google of this returns that this is caused on Debian systems that run > Postfix in a jail (which matches my system). The most recent post regarding > this appears to be here: > https://tech.feedyourhead.at/content/postscreen_cache_db_no_such_file > > As per the blog posting, I stopped Postfix and created a directory in the > jail for the postscreen_cache.db: > > $ sudo systemctl stop postfix.service > $ sudo mkdir -p /var/spool/postfix/var/lib/postfix > > I moved the postscreen_cache.db file to this location: > > $ sudo mv /var/lib/postfix/postscreen_cache.db > /var/spool/postfix/var/lib/postfix > > I set the permission and ownership on this file: > > $ sudo chown postfix:postfix > /var/spool/postfix/var/lib/postfix/postscreen_cache.db > $ sudo chmod 0660 /var/spool/postfix/var/lib/postfix/postscreen_cache.db > > I checked that the postfix user can access this file: > > $ sudo -u postfix namei -m > /var/spool/postfix/var/lib/postfix/postscreen_cache.db > > I *DIFFER* from the blog in that I do not create a symbolic link - I use the > Postfix main.cf configuration parameter below: > > postscreen_cache_map = > btree:/var/spool/postfix/var/lib/postfix/postscreen_cache > > I then start Postfix: > > $ sudo systemctl start postfix.service > > When I check: /var/spool/postfix/var/lib/postfix I can see that > postscreen_cache.db is updated as time progress, but I still get the warning > about not being able to close the postscreen_cache.db database. An update on this initial e-mail ... Checking mail.log, Postfix outputted a helpful warning about me attempting the following in main.cf: postscreen_cache_map = btree:/var/spool/postfix/var/lib/postfix/postscreen_cache Postfix notes that the path I created in the jail does not point to the expected Postfix data directory. It then displayed that the data directory was: /var/lib/postfix My initial response was to update the data_directory in main.cf to point to the jail path: data_directory = /var/spool/postfix/var/lib/postfix ...however this caused other parameters to display warnings because the jail path I specified was not expected. I checked the default setting: $ postconf | grep -i data_directory ...which revealed that it was: /var/lib/postfix I then tried setting the postscreen_cache_map to this in main.cf: postscreen_cache_map = btree:/var/lib/postfix/postscreen_cache ...but received the original warning message when postscreen(8) attempted to close the postscreen cache map. I went back and moved the postscreen_cache.db to the jail location and created a symbolic link (as per the instructions in the blog I referenced in the original e-mail): $ sudo mv /var/lib/postfix/postscreen_cache.db /var/spool/postfix/var/lib/postfix $ sudo ln -s /var/spool/postfix/var/lib/postfix/postscreen_cache.db /var/lib/postfix/postscreen_cache.db ...and restarted Postfix . . . and the warnings from postscreen stop (success) ! Is this really the only way to fix this, though ? This feels a bit like a workaround as opposed to the “correct” solution (assuming that there is a “more correct” solution). Thanks, - J
Re: Virtual mailbox domains vs relay domains
Viktor Dukhovni: > > perhaps more importantly, what is the recommended way of sending > > emails from Postfix to Dovecot? The advantage of Peer's method is that > > you can place the Postfix server in a DMZ and it does not need access > > to your MySQL/... database for username information. > > Losing recipient validation is NOT an advantage. Either way, > you need to have a table of valid recipients to avoid backscatter. An alternative to a static table is dynamic recipient verification. This uses a cache with proactive refresh. http://www.postfix.org/ADDRESS_VERIFICATION_README.html Wietse
Re: Question about postscreen_cache.db
J Doe: > Is this really the only way to fix this, though ? This feels a bit like a > workaround as opposed to the ?correct? solution (assuming that there is a > ?more correct? solution). Why bother with all this? The database is synced without error. It is in a consistent state. Only the close operation complains because of some DB bug. This does not affect correctness. Wietse
Re: Question about postscreen_cache.db
Hi Wietse, > On Nov 11, 2017, at 8:37 AM, Wietse Venema wrote: > > J Doe: >> Is this really the only way to fix this, though ? This feels a bit like a >> workaround as opposed to the ?correct? solution (assuming that there is a >> ?more correct? solution). > > Why bother with all this? The database is synced without error. > It is in a consistent state. Only the close operation complains > because of some DB bug. This does not affect correctness. Thanks for your reply. When Googling for this problem, a number of the posts I found referenced this situation happening in jailed deployments and that’s what I’m running. Most of these posts are from some time ago, so I assumed that with me running Postfix 3.1 on a modern distro, the bug(s) in the Berkeley DB libraries that cause this issue would be fixed by the Berkeley DB developers. The other reason is that the volume of these warnings seemed quite large. I can, of course, filter that out, but I wondered if there was a workaround for this to suppress the warnings. The workaround that I found works, I just wasn’t sure if it was the best solution. - J
Re: Question about postscreen_cache.db
J Doe: > Hi Wietse, > > > On Nov 11, 2017, at 8:37 AM, Wietse Venema wrote: > > > > J Doe: > >> Is this really the only way to fix this, though ? This feels a bit like a > >> workaround as opposed to the ?correct? solution (assuming that there is a > >> ?more correct? solution). > > > > Why bother with all this? The database is synced without error. > > It is in a consistent state. Only the close operation complains > > because of some DB bug. This does not affect correctness. > > Thanks for your reply. > > When Googling for this problem, ... Why bother. All data is safe. Let the computer ignore the message if it bothers you. Wietse
Re: Question about postscreen_cache.db
Wietse Venema: > J Doe: > > Hi Wietse, > > > > > On Nov 11, 2017, at 8:37 AM, Wietse Venema wrote: > > > > > > J Doe: > > >> Is this really the only way to fix this, though ? This feels a bit like > > >> a workaround as opposed to the ?correct? solution (assuming that there > > >> is a ?more correct? solution). > > > > > > Why bother with all this? The database is synced without error. > > > It is in a consistent state. Only the close operation complains > > > because of some DB bug. This does not affect correctness. > > > > Thanks for your reply. > > > > When Googling for this problem, ... > > Why bother. All data is safe. Let the computer ignore the message > if it bothers you. Or you can use 'lmdb:' instead 'btree:'. LMDB support was added in Postfix 2.11. It's a totally different implementation. Wietse
Re: Question about postscreen_cache.db
Hi, > On Nov 11, 2017, at 7:24 PM, Wietse Venema wrote: > > Or you can use 'lmdb:' instead 'btree:'. LMDB support was added in Postfix > 2.11. > It's a totally different implementation. That’s a great idea - that will side-step any Berkeley DB specific bugs. Thanks, - J
