I recently had to diagnose a couple of servers running Postfix which emailed results of rsync cronjobs when they returned a non-OK value. While Postfix was emailing the recipients on rsync failure, I noticed that the cronjob STDOUT was not being locally relayed correctly to the root mail.
I documented my fix on ServerFault, hopefully it's useful for someone else.
Having fixed local root cron reports, I then noticed on the CentOS7 box that the AIDE service was running, had been scanning for integrity checks against the original postfix install (subsequently upgraded to Postfix 3) and as such was throwing errors every night for no real reason, quite annoying.
To fix this I tried running
aide --update but it didn't work (probably my fault from doing an
--init first). I had to rm the
/var/lib/aide/aide.db.new.gz files, then
run aide --init and rename the newly-made
aide.db.gz. After that, it was happy.
I've been working with Oracle Session Border Controllers and Enterprise Communications Brokers a lot recently, A couple of weeks ago I encountered what I think is a new - and quite serious - bug (it's with Oracle for investigation) regarding how the devices *mis*handle special characters. If you admin ECBs or SBCs and are planning to change their credentials to include non-alphanumeric characters, read this first.
I've been working with Oracle Session Border Controllers and Enterprise Communications Brokers a lot recently, and I encountered what I think is a new bug (it's with Oracle for investigation).
After deploying some new ECB instances, I changed the login and enable passwords, per the Oracle ACLI guide ("secret login" and "secret enable" at the SSH prompt). I used randomly generated strong passwords which included limited special characters -- "#", "%", "?" and "!".
The ECB appliances use two passwords per username - one to log on to the unit, and one to 'enable' (admin mode for configuring them, similar to Cisco's enable mode).
On one appliance, the new password I generated for it was accepted without complaint when typed and retyped at the confirmation prompt. However, attempting to then authenticate a new session using this password resulted in immediate refusal by the appliance. It effectively denied access, with no recovery method. I had to flatten and redeploy the appliance! Continue reading "Tiplet: DO NOT USE the # symbol in Oracle Enterprise Communication Broker passwords!"