4/29/20

Postfix fails with (error: postdrop: warning: mail_queue_enter: create file maildrop/randomfilename.xxxxx: Permission denied)

Problem: Postfix delivery fails with error

(postdrop: warning: mail_queue_enter: create file maildrop/randomfilename.xxxxx: Permission denied)


** see note below

Cause:

/usr/sbin/postdrop has incorrect permissions. 
Correct the permissions for /usr/sbin/postdrop are as follows:
# ll /usr/sbin/postdrop

-rwxr-sr-x. 1 root postdrop 180808 Aug 23  2018 /usr/sbin/postdrop

Solution:

Fix permissions with the following:


rpm --setperms postfix
rpm --setugids postfix

In order to prepare for this next part, you need to make sure that you have the yum-plugin-verify.noarch installed from your standard CentOS or RedHat YUM repository.

You can figure out the default permissions for whatever file that maybe having a permissions issue on your Linux system.

To prepare for this task, you need to make sure that you have the yum plugin
by doing the following:
  • figure out which package provides the file you are troubleshooting.
    • On my CentOS 6 system, this can be accomplished by running the command 
    • rpm -q --whatprovides /usr/sbin/postdrop which will produce the following output indicating the package name that provided our postdrop file when it was installed:
      • postfix-2.6.6-8.el6.x86_64
    • Next step is to run the yum verify-all command against the package name to see the default ownership & permissions for its files as follows:
    • yum verify-all postfix-2.6.6-8.el6.x86_64 
    • The command above will produce something similar to the following output:

  • Just please not that this screenshot is not indicative of the problem at hand because the permissions issues were fixed. This screenshot part is only complaining about checksums & mtime values since this postfix install was updated and modified multiple times.

4/27/20

resolv.conf reverts to old DNS entries

/etc/resolv.conf keeps reverting back to its old entries after updating your DNS server list whether manually or via the setup front-end tool for setting up your Network, authentication, services etc on RHEL or CentOS version 5,6,7.

The solution comes from Redhat's KB article entitled "How to make persistent changes to the /etc/resolv.conf?"https://access.redhat.com/solutions/7412


The issue is that DNS servers in /etc/resolv.conf changed after a reboot or network service restart.

If a single ifcfg-file both specifies a nameserver using DNS1 and also gets a nameserver via DHCP, both nameservers will be placed in resolv.conf.


Root Cause:

- From the script /etc/sysconfig/network-scripts/ifdown-post if the "RESOLV_MODS=no" or "PEERDNS=no" is not present in the relevant /etc/sysconfig/network-scripts/ifcfg-* files, the contents of /etc/resolv.conf could get overwritten with /etc/resolv.conf.save.
- /etc/sysconfig/network-scripts/ifup-post script, checks for the presence of "RESOLV_MODS=no" or "PEERDNS=no"


Resolution:

The change in my situation was due to the ifcfg-eth0 file directives DNS1 and DNS2 which lead to modification of resolv.conf

In my particular situation, the solution was to mark the /etc/resolv.conf as immutable with this command:

chattr +i /etc/resolv.conf
to prevent any tool or configuration from modifying it.

For diagnosing the issue, look for entries similar to the following in your /var/log/messages:

Oct 14 12:40:52 hostname NET[22961]: /etc/sysconfig/network-scripts/ifdown-post : updated /etc/resolv.conf
Oct 14 12:40:57 hostname NET[23256]: /etc/sysconfig/network-scripts/ifup-post : updated /etc/resolv.conf

Quick HTTP to HTTPS - Apache2

There are several methods for redirecting your Apache-based website visitors who might type your servers URL using the plain (non-secure) HT...