Thanks Paul: Those were my observations of an 'out-of-the-box' test install using './configure --with-mysql'. Like it or not, that was the outcome.
Peter described his DbMailAdministrator error message as, "Failed. Could not connect to database (check log)" which isn't a permission-denied message. Your comments about using dbmail-adduser are noted. While building DbMailAdministrator for my own use, I thought to share the results of my effort with DbMail users. It seemed a more ubiquitous approach to use the indigenous tools of DbMail. Whereas we all seem to want to collaboratively govern network and information security, it is the responsibility of the admin tool user, no matter what the tool, to use and protect their administration privileges properly. Any tool given to a Sys Admin for system-level access needs security commensurate with circumstance and environment. I rely on the three information security elements of tool design: confidentiality, integrity and availability. Enterprise management must be performed. Whatever environment you choose to do that within, using your user and permission sets, would be a good place to try DbMailAdministrator: http://library.mobrien.com/dbmailadministrator/ USAGE EXAMPLES: I have one test implementation of DbMailAdministrator on a non-routable LAN host having DbMail plus database clients installed. The 'conf' file points to a backend MySQL cluster and dbmail-adduser speaks via LAN-side TCP to the database. In another dev install, DbMailAdmistrator is accessible across a VPN, NAT'd across the DMZ to its unique port running on its own, owned instance of Apache mod_ssl. It calls upon its own copy of dbmail-adduser in its root also owned by xxx:xxx. I have this VPN to run Netcool, Topaz and Tivoli plus other enterprise mgmt tools all in the same VPN environments for a long time, without problems, touch wood. Concomitantly, the secure environment you use for your enterprise management, with your authenticated permission sets --and that might be localhost wherever you console access dbmail-adduser -- would be a good place to try DbMailAdministrator and see if it is of use to you. Thanks for your comments, Paul. best... Mike Just some input here: If Peter is running the debian packages or uses a similar permission setup that would also explain his troubles. In debian the dbmail.conf is installed 0600 and owned by root. M. J. [Mike] O'Brien wrote: > Hey Peter: > dbmail-adduser runs as guest fresh out of gmake. It relies on MySQL username > and pass in dbmail.conf. > I just slapped DbMail onto a file server that has only a mysql40-client and > the dbmail.conf pointing to an external cluster. Logged out and in as > guest:guest and 'dbmail-adduser s' accessed the remote MySQL servers. I then > used 'dbmail-adduser a' to add a user and alias and it did. Which is a seriously hazardous situation. This means anyone with shell access on your machine can wreck havoc in your dbmail userdb, thereby possibly deleting all your mail. Unless noone has any kind of access to your webserver or shellserver you should avoid this setup. Almost as bad as running apache as root :-) Imagine mr. blackhat installing a php script or cgi that has system/exec permissions, thereby gaining access to dbmail-adduser... IMO you should either clamp down on dbmail.conf's mode, and/or restrict access to dbmail-adduser. Somekind of suexec setup is the only safe path here.
