I looked through the qt-backup and qt-restore scripts on github.
They seem intended for backup and restore to the same model toaster
where EVERYTHING is essentially identical. That seems less applicable
when upgrading by two centos versions which is accompanied by newer
versions of the adjunct sof
I would like to check that out too since I need to move some accounts from a 5x
box. I just moved one domain and the steps I had to do is add the domain /
users on the new server and then I did an rsync
I wish I did not have to create an account but then it means I have to copy
the db over. I
I went through the qt-backup and rsync'd the necessary directories and
dumped the vpopmail database and restored it on the new machine. Let me
take a look at my replicate script and I'll get it to you.
On 8/14/2018 7:17 PM, Andrew Swartz wrote:
Do I just rsync the /home/vpopmail directories?
Do I just rsync the /home/vpopmail directories? Or is there
data/settings elsewhere also?
-Andy
On 8/14/2018 4:40 PM, Eric Broch wrote:
> Maria and MySQL have the same commands you should be okay with a restore.
>
> Other things are different like spamassassin /etc/mail/spamassassin vs
> /etc
Maria and MySQL have the same commands you should be okay with a restore.
Other things are different like spamassassin /etc/mail/spamassassin vs
/etc/spamassassin.
If I had the servers side by side I wouldn't use backup and restore, I'd
use rsync.
On 8/14/2018 11:09 AM, Andrew Swartz wrote
Does anyone know if these will do a backup of a centos-5 toaster and
restore to a centos-7 toaster?
vpopmail seems unchanged, but mysql has changed to mariadb and courier
has changed to dovecot.
I have very little database knowledge. I'm fearful of the restore
causing disaster on the new toaster
My understanding is that RFC compliance is highly variable in email
client-server relationships. This is because servers tend to have
preexisting relationships with clients such that servers can dictate
configurations. Therefore RFC compliance isn't important for
interoperability.
Using STARTTLS
Qtp-menu not supported with centos 7?
From: Eric Broch
Sent: Tuesday, August 14, 2018 8:55 AM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] qtp utils
ftp://ftp.whitehorsetc.com/pub/qmail/CentOS5/qmt/plus/qmailtoaster-plus/bin/
On 8/14/2018 6:24 AM, rtar...@host2ma
ftp://ftp.whitehorsetc.com/pub/qmail/CentOS5/qmt/plus/qmailtoaster-plus/bin/
On 8/14/2018 6:24 AM, rtar...@host2max.com wrote:
Was there an answer to this? I cannot find these either and
qtp.qmailtoaster.com is down.
Thanks
*From:*Gary Bowling
*Sent:* Friday, June 23, 2017 8:41 AM
*To:*
Gary,
Eric put these tools up on his Whitehorse ftp site, but they are also
available for install through yum.
"yum install qmt-plus"
Includes qmHandle, qmlog, etc.
Hope this helps.
Best, Sean
On 8/14/2018 8:24 AM, rtar...@host2max.com wrote:
Was there an answer to this? I cannot find t
Was there an answer to this? I cannot find these either and
qtp.qmailtoaster.com is down.
Thanks
From: Gary Bowling
Sent: Friday, June 23, 2017 8:41 AM
To: qmailtoaster-list@qmailtoaster.com
Subject: [qmailtoaster] qtp utils
There used to be a bunch of utilities installed with th
Only because others are talking security and LetEncrypt… I put together a
script that I run AFTER certbot renew checks are run. Figured I would include
it here for the Qmail community to use:
[root@mail7 ~]# more copy_letsencrypt_files.sh
#!/bin/bash
#
# Script to copy lets encrypt files t
Thanks Andy. Just to be sure on this: I had the impression that
STARTTLS could be used also with port 143? At least reading
https://wiki.dovecot.org/SSL indicates so:
"Clients using STARTTLS work by connecting to the regular unencrypted
port and immediately issue a STARTTLS command, after which th
Peter,
If you are using ports 110/143, which are clear-text, then you should
switch to 993/995 (if possible, of course).
Ports 993/995 are never intentionally clear-text; they are either TLS or
STARTTLS. Many servers/clients can be configured for either, but they
cannot be configured for both bec
Thanks for the suggestions!
So if I have only plain and login auth mechanisms enabled, what does
that mean in practice security wise?
Any ideas why the error is happening sometimes but not always and why
aut_cache settings would fix the problem? Is it related to caching
credentials for different
Yea I just run the script looks like it did gen the bigger key. 2048 now
> On Aug 13, 2018, at 23:53, Andrew Swartz wrote:
>
> This is copied out of qmail/bin/dh_key:
>
> openssl dhparam -2 -out /var/qmail/control/dh1024.new 2048 2>&1 > /dev/null
> chmod 644 /var/qmail/control/dh1024.new 2>&1
16 matches
Mail list logo
