jekillen at prodigy.net
Sat Nov 17 14:05:50 PST 2007
On Nov 17, 2007, at 12:13 PM, Matthew Seaman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> jekillen wrote:
>> I am planning on setting up Cyrus on a machine
>> and the documentation says that it is intended'
>> for use on 'sealed' servers (servers for which there
>> are no accounts that can log into the system)
> This is really just trying to say that you don't need
> a Unix login account in order to have an e-mail account
> via Cyrus IMAPd.
> Of course any server will require user accounts for its
> administrators to be able to log in.
>> If I use ssh to administer the system, I have to
>> set it up so I can ssh directly to root, right.
> Wrong. The best practice is to require users to log in
> as themselves (thus establishing some sort of audit trail)
> and then use some program like su or sudo to gain rootly
> powers. At work we use a second instance of sshd bound to
> a high-numbered port on the loopback so you can ssh to root
> only after you've logged in and only if you've using
> ssh-agent and your ssh public key is in root's
> ..ssh/authorized_keys file.
Thank you this answers these questions
>> Since there are references to use of MySQL
>> and the MySQL user is set up as a normal
>> user with a login/pwrd,
> No -- mysql runs as a non-privileged user which doesn't need
> to have any password set or any ability for anyone to get a
> login session as the mysql user. All that ID is for is to own
> some files and the various mysqld processes. This is a standard
> practice with most long-running daemons exposed to the network:
> it limits the damage that can be done by remote compromise of
> the software.
and this accept, I know that MySQL has a separate set of user/passwords
and various levels of access privilege, When I built and installed
MySQL I had
to create a mysql user as a normal user with password, unless I
Someone who knew this password would be able to log into the system as
user mysql (or the name that was given to mysqld to run as)
> The best way to configure MySQL in that situation is to
> * use 'skip-networking' in the configuration file. This
> forces all connections to mysql to be via the unix domain
> socket in /tmp/mysql.sock
> * Run 'mysql_secure_installation' to remove remote root access,
> set the root password, get rid of wildcarded logins etc.
> * Review all user IDs and GRANTS carefully -- if you aren't using
> networking, then all your MySQL users should be
> 'userid'@'localhost' Adopt a polict of *minimum privilege* --
> allow only the necessary access required for things to keep
> * In order to prevent the MySQL root password being used routinely
> (which makes it far more likely to be disclosed), create a
> file /root/.my.cnf with contents like:
> user = root
> password = yourpassword
> Make sure the file is mode 600: read-write only for the owner
> With this in place, then once you've become the Unix root user
> you can then just type 'mysql' and get a root MySQL session
> without having to type any passwords. ie. you rely on the
> security of your Unix root account to protect your MySQL
> root account.
>> Please forgive my lack of sophistication on this
>> issue, I am learning.
>> (I have also been looking at Dovecot)
>> I have assembled some documentation on this
>> but have not found a direct answer, thus the
>> query here.
>> system uses Postfix on FreeBSD 6.2
> Dovecot is good, and its configuration -- particularly where stuff
> like SASL
> is concerned -- is a lot easier for inexperienced users. It will run
> a mail
> server for tens of hundreds of users perfectly satisfactorily. On the
> hand, if you're looking at thousands of users then Cyrus IMAPd is what
>> One FYI that may be of interest:
>> I had my own dns servers listed in
>> resolv.conf before the isp's dns servers
>> and messages sent from this machine
>> (FreeBSD w/Postfix) were failing to deliver
>> to jekillen at prodigy.net due to dns lookup failures.
>> So I changed the order in resolv.conf (listing isp dns
>> servers first) and the messages were then delivered.
>> I thought that if one server could not respond with
>> enough info, the next server would be tried until one
>> was successful (making order insignificant).
> Sounds like your own recursive DNSes weren't actually working.
> Flaky DNS is the cause of most of the delays or failures that
> spoil your user experience:
That is probably the cause, but editing resolv.conf was the quick fix.
> until you've thoroughly mastered managing
> DNS servers, I'd recommend using your ISPs servers. Having
> reliable DNS will help you a great deal while you are debugging
> your mail server setup.
Actually they work fine for what I set them up for. It was the recursive
aspect that I had forgotten about, but as I remember, there was a
security issue with regard to recursive queries so I have them disabled.
I have the isp's servers set up to relay queries to in my primary
and that is probably what I have wrong, somehow. Because of this e-mail
setup issue, I had contacted the isp and they have delegated all my
static ip addresses to me and added my name servers to their database.
Thank you very much for your assistance.
More information about the freebsd-questions