Greetings.
I had a billing snafu with my ISP, straightened it out and now my postfix isn't working right. When I run
I get:
Code:
/usr/sbin/postconf: warning: data_directory: unknown parameter
/usr/sbin/postconf: warning: data_directory: unknown parameter
postfix/postfix-script: warning: not owned by postfix: /.
postfix/postfix-script: warning: not owned by postfix: /./mnt
postfix/postfix-script: warning: not owned by postfix: /./root
postfix/postfix-script: warning: not owned by postfix: /./root/.bash_history
postfix/postfix-script: warning: not owned by postfix: /./root/.rnd
postfix/postfix-script: warning: not owned by postfix: /./root/.ssh
postfix/postfix-script: warning: not owned by postfix: /./root/.ssh/known_hosts
postfix/postfix-script: warning: not owned by postfix: /./root/.lesshst
postfix/postfix-script: warning: not owned by postfix: /./root/req.pem
postfix/postfix-script: warning: not owned by postfix: /./root/key.pem
postfix/postfix-script: warning: not owned by postfix: /./root/pkgs
postfix/postfix-script: warning: not owned by postfix: /./root/.bashrc
The warnings continue
ad nauseam (I've not allowed it to go through the entire system yet!).
The obvious solution would be to fix the data_directory variable. I first just commented it out (it still is commented out), but the postconf seems to be picking it up. This makes me think data_directory *defaults* to the location in my main.cf:
Code:
data_directory = /var/lib/postfix
which didn't exist. I created it and chowned it postfix.postfix and that still didn't solve the problem.
Here's the output of postconf -n, which an observant person will notice does
not include data_directory:
Code:
# postconf -n
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
allow_percent_hack = no
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
hash_queue_names = deferred, defer active bounce flush incoming
html_directory = no
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
luser_relay = nimitz
mail_owner = postfix
mailbox_command = /usr/bin/procmail
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
mydestination = $myhostname, localhost.$mydomain $mydomain
mydomain = nimitz.net
myhostname = federalax.nimitz.net
mynetworks = 75.167.50.0/23
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/postfix
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_connect_timeout = 30s
smtpd_banner = $myhostname ESMTP Federalax Interstellar Courier Service v3.9319
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname, permit
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, reject_rbl_client list.dsbl.org, reject_rbl_client sbl-xbl.spamhaus.org, check_recipient_access hash:/etc/postfix/recipient_access,
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = smtpd
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain, permit
strict_rfc821_envelopes = no
unknown_local_recipient_reject_code = 550
virtual_alias_domains = galacticlore.com, galacticlore.net, sundering.com, annekaelber.com
virtual_alias_maps = hash:/etc/postfix/virtual
I'm not sure what has changed to cause this problem in what was a working set-up. Thus, the reason I mentioned the billing snafu. Perhaps someone out there knows an ISP trick-of-the-trade for dealing with delinquent accounts which I need to fix?
If this was simply a "problem waiting to happen", what is the problem and how do I fix it?
Sincerely confused,
Anne.