On Nov 17, 2007, at 12:13 PM, Matthew Seaman wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
jekillen wrote:
Hello;
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.
However:
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
and
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
misunderstood.
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
working.
* 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:
[client]
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
other
hand, if you're looking at thousands of users then Cyrus IMAPd is what
you
need.
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 [EMAIL PROTECTED] 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
named.conf
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.
Cheers,
Matthew
Thank you very much for your assistance.
Jeff K
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
