I would suggest to try MariaDB 10, instead of 5.x and see if that’s still the case.
Remo > On Oct 2, 2018, at 17:02, Eric Broch <ebr...@whitehorsetc.com> wrote: > > This might be worthy of a note to the MariaDB folks. > > > On 10/2/2018 5:59 PM, Andrew Swartz wrote: >> I felt a new subject appropriate. >> >> Current setup is QMT on Centos7 (set up last month). I did a >> backup/restore (of accounts only) from a Centos5 QMT. >> >> NEW INFORMATION: >> I just dug through a few automated accounts which still have the long >> passwords which I've not updated since the backup/restore. I tried >> logging in via Squirelmail. >> >> - I cannot authenticate with the long password. >> - I CAN authenticate with the first 16 characters of the password. >> - The hashes in the old (Centos5) and new (Centos7) vpopmail databases >> are identical. Therefore it Eric seems correct that the restore did not >> regenerate the hashes. >> >> HOWEVER: >> I just tried the same account/password on the old Centos5 QMT, and >> successfully logged in with the long password (via squirrelmail). >> >> NEXT: >> I just took a test account with a short password on the Centos7 QMT, and >> I reset it to a long. >> - I cannot authenticate with the long password. >> - I CAN authenticate with the first 16 characters of the password. >> >> >> The only thing I can say conclusively is that this is different behavior >> than on my Centos5 QMT where I was authenticating with long passwords >> and never had any such problems. >> >> It seems that the different before/after behavior is not due to the >> backup/restore scripts, but rather to some sort of different >> functionality of the Centos7 setup. It may take a lot of digging and >> expert knowledge to sort this out. >> >> Curious to hear if others can replicate this behavior. >> >> >> -Andy >> >> >> >> >> >> >> On 10/2/2018 3:19 PM, Andrew Swartz wrote: >>> I had the issue. >>> >>> I merely fixed it rather than fully investigating it. >>> >>> I had some accounts where, after the backup/restore, the passwords >>> worked fine. Yet other where the passwords failed. When I looked at >>> the database, the ones where the passwords failed had a long cleartext >>> password which was chopped off at 16 characters. All the accounts with >>> short passwords worked fine. I looked at the database schema, and saw >>> that the cleartext password field is 16 characters. So I tried >>> authenticating with the shortened version of the password, and I >>> ~believe~ that it worked. However, I figured that there was now a >>> discrepancy between the cleartext and the hash, so I reset the passwords >>> for all the affected accounts. >>> >>> In retrospect, I wish I had investigated further; however, I was in the >>> mode of fixing the problem as rapidly as possible. I apologize for not >>> digging further so that I could pass the info along to others. >>> >>> I do not remember if I visually compared the hashes. I probably did, >>> and they were probably the same. That is probably why I got worried >>> about a cleartext versus hash discrepancy. >>> >>> This much I can say with 100% confidence: >>> The accounts with passwords >16 characters would not authenticate after >>> the backup/restore procedure. Resetting those passwords fixed the problem. >>> >>> >>> -Andy >>> >>> >>> >>> On 10/2/2018 2:49 PM, Tony White wrote: >>>> Hi Eric, >>>> Sorry, I made it sound like you had the issue. I know it was not you. >>>> >>>> best wishes >>>> Tony White >>>> >>>> On 03/10/18 07:50, Eric Broch wrote: >>>> >>>>> Okay, >>>>> >>>>> It seems odd, to me at least, that using the mysql/mariadb commands >>>>> 'mysqldump' to backup the vpopmail database and to restore it again >>>>> with 'mysql -u xxx -pyyy vpopmail < db' yields a corrupt database. How >>>>> is this possible? Certainly a backup/restore doesn't rehash passwords >>>>> using the clear text field. It should simply restore exactly what's >>>>> backed up. Is this thinking erroneous??? >>>>> >>>>> Eric >>>>> >>>>> >>>>> On 10/2/2018 12:09 PM, Dan McAllister - QMT DNS wrote: >>>>>> I hear ya Andrew! I have a very large QMT that hosts hundreds of >>>>>> domains. One of those tenants knows that this is a QMT install, and >>>>>> wanted to have access to the vqadmin program -- which WOULD have >>>>>> given them visibility to other domains' passwords -- but I deny >>>>>> access to that tool to anyone (I don't even use it)... they CAN use >>>>>> the admin role with the standard qmailadmin interface, because that >>>>>> is limited to one domain at a time. >>>>>> >>>>>> I have a list of "superadmins" for that system that have access to >>>>>> the user passwords through the shell "vuserinfo" command -- and you >>>>>> have to be elevated (root) to run that, so anyone breaking in >>>>>> (hacking) the website (apache user), or qmail (qmail, qmaill, or >>>>>> qmailq users) or even vpopmail (vpopmail user) will NOT be able to >>>>>> run that command. >>>>>> >>>>>> I also CHANGE the default passwords for the MySQL database... so if >>>>>> you CAN break in, you CANNOT just query the database (because the >>>>>> vpopmail password is well known). >>>>>> >>>>>> So that's been my way to deal with it... your mileage may vary 😊 >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Andrew Swartz <awswa...@acsalaska.net> >>>>>> Sent: Tuesday, October 2, 2018 11:24 AM >>>>>> To: qmailtoaster-list@qmailtoaster.com >>>>>> Subject: Re: Fwd: Re: [qmailtoaster] centos 6 >>>>>> >>>>>> Dan, >>>>>> >>>>>> Excellent explanation. Thank you. >>>>>> >>>>>> It explains something which I did not report in my email: I solved this >>>>>> by trying only the first 16 characters of the long passwords, and sure >>>>>> enough they validated. I did not put enough thought into it to realize >>>>>> that the hashes had been regenerated from the shortened passwords. >>>>>> >>>>>> This explanation implies that the problem is that the restore script >>>>>> generates new hashes from the [stored] cleartext passwords. Seems like >>>>>> an easy fix would be to just backup/restore the hashes instead of >>>>>> generating new hashes. >>>>>> >>>>>> QUESTIONS: >>>>>> 1. What is the format of the stored hash? Looks like concatenation of >>>>>> two [atypical] base64 fields. >>>>>> >>>>>> 2. How difficult would it be to remove the cleartext passwords from >>>>>> vpopmail? I see the logic of storing the "hint". But it means that for >>>>>> systems with multiple admins, all of the admins can view (and therefore >>>>>> use) most users' passwords. That is problematic even without >>>>>> considering the foreign intruder risk. >>>>>> >>>>>> My security concern for QMT has always been that I've never trusted the >>>>>> qmail accessories as much as qmail itself. I remain fairly confident >>>>>> that an intruder will not enter via port 25 (i.e. through qmail). But >>>>>> running the web server (for webmail) markedly increases the risk. >>>>>> >>>>>> QUESTION: could a webserver SQL-injection retrieve the cleartext >>>>>> passwords? >>>>>> >>>>>> -Andy >>>>>> >>>>>> >>>>>> >>>>>> On 10/2/2018 5:02 AM, Dan McAllister - QMT DNS wrote: >>>>>>> I know I'm "Johnny-come-lately" on this topic, but I can explain the >>>>>>> results you're seeing and have seen the same myself: >>>>>>> >>>>>>> The QMT vpopmail default setup saves the hashed password, as well as >>>>>>> the first 16-characters of the clear-text password, in the MySQL >>>>>>> database. That has already been established. What you probably don't >>>>>>> know (or didn't think of) is how those fields are used! >>>>>>> >>>>>>> Consider the following: >>>>>>> - First, the length of the hashing algorithm is a fixed length. >>>>>>> Different hashes, different lengths (for example: MD5 hashes are >>>>>>> always 32 characters, SHA1 hashes have 40 characters, sha512 hashes >>>>>>> 128, and so on...) >>>>>>> - Second, ONLY the hashed password is used for validation. There >>>>>>> is no NEED for the cleartext password in the database, it's there >>>>>>> simply because the MySQL database was considered somewhat secure, >>>>>>> and the original developers of the QMT realized that about 40% of >>>>>>> user problems are caused by NOT KNOWING THEIR PASSWORDS, and being >>>>>>> able to GIVE them their existing password was generally easier than >>>>>>> resetting it (and hearing complaints that, although you "fixed" >>>>>>> their desktop mail, now their phone's weren't getting email!) >>>>>>> - Finally, the original designers of QMT assumed people would use >>>>>>> long passwords -- it was suggested in the original documentation. >>>>>>> Thus, saving only the first 16 characters of the password in >>>>>>> cleartext meant you were only REALLY saving a "password hint" vs. >>>>>>> the entire password. >>>>>>> >>>>>>> So - when you enter a 75 character password (only slightly absurd >>>>>>> these days), and if we assume a sha1 password hash, then the "set >>>>>>> password" function hashes your 75 characters into a 40-character >>>>>>> SHA1 hash and saves it into the database field that stores up to >>>>>>> (magically) 40 characters. (FWIW: when you enter your 2-character >>>>>>> password of "ok", the sha1 algorithm ALSO generates a 40 character >>>>>>> output!). After is stores the hashed password, it ALSO stores the >>>>>>> first 16 characters of the cleartext password -- because that's the >>>>>>> length of the field in the database. >>>>>>> >>>>>>> When you try to authenticate, the password you provided is re-hashed >>>>>>> (regardless of its length -- although usually those fields have 64, >>>>>>> 72, or 128 character field limits - depending on the web-page >>>>>>> designer/programmer), and those 40 characters (the output of the >>>>>>> sha1 hash) are compared to your stored hash... there is no query of >>>>>>> the cleartext password. >>>>>>> >>>>>>> Unfortunately, when you attempt to restore your passwords using just >>>>>>> the stored cleartext passwords, you will find (not surprisingly) >>>>>>> that passwords that were longer than the 16 chars generate a totally >>>>>>> different hash result! (Interesting side-note: you could have told >>>>>>> your users that their passwords were unchanged, but that they had to >>>>>>> stop after the 16th character -- and it would have worked!) >>>>>>> >>>>>>> I hope this explains a few things!! >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> IT4SOHO, LLC >>>>>>> 33 4th St N; STE 211 >>>>>>> St. Petersburg, FL 33701 >>>>>>> +1-877-IT4SOHO >>>>>>> +1-877-484-7646 >>>>>>> For service requests, direct your email to serv...@it4soho.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Eric Broch <ebr...@whitehorsetc.com> >>>>>>> Sent: Friday, September 28, 2018 1:35 AM >>>>>>> To: qmailtoaster-list@qmailtoaster.com >>>>>>> Subject: Re: Fwd: Re: [qmailtoaster] centos 6 >>>>>>> >>>>>>> Thanks, Andy. Plain text password have been a part of qt for as long >>>>>>> as I've been using it. I understand you're concern. I'm not sure >>>>>>> about the password length issue, I don't remember ever changing >>>>>>> (patching) vpopmail like that, but I'll look into it. >>>>>>> >>>>>>> >>>>>>> On 9/27/2018 11:28 PM, Andrew Swartz wrote: >>>>>>>> I recently did the backup/restore and I have one hiccup to report. >>>>>>>> >>>>>>>> A few of the account passwords did not work after backup from centos5 >>>>>>>> and restore to centos7. >>>>>>>> >>>>>>>> Took some time to troubleshoot, but I poked around in the vpopmail >>>>>>>> database and figured it out. It was due to the vpopmail database >>>>>>>> schema, which stores a 16 character password AND its hash. It allowed >>>>>>>> [and worked with] passwords longer than 16 characters (I'm unsure >>>>>>>> how). >>>>>>>> But after the backup/restore, all passwords longer than 16 characters >>>>>>>> failed. Problem was fixed by resetting all of these passwords to new >>>>>>>> ones with the proper length. Luckily there were not many like this. >>>>>>>> But for a large system, this could be a major pain. >>>>>>>> >>>>>>>> This seems like a bug. If the max password length is 16 characters, >>>>>>>> then the set-password webpage should reject passwords that are too >>>>>>>> long. >>>>>>>> >>>>>>>> Also, I'm not sure why it stores a plaintext password in addition to >>>>>>>> its hash. The modern standard is to store only the hash. This is >>>>>>>> potentially a major security problem. >>>>>>>> >>>>>>>> -Andy >>>>>>>> >>>>>>>> >>>>>>>> On 9/27/2018 8:57 PM, Tony White wrote: >>>>>>>>> Eric, >>>>>>>>> I now have a working v6 COS qmt, thank you for you help an >>>>>>>>> patience. >>>>>>>>> Now the backup and restore... >>>>>>>>> >>>>>>>>> best wishes >>>>>>>>> Tony White >>>>>>>>> >>>>>>>>> On 28/09/18 14:43, Eric Broch wrote: >>>>>>>>> >>>>>>>>>> changed now >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/27/2018 10:41 PM, Tony White wrote: >>>>>>>>>>> Eric, >>>>>>>>>>> Yes I did run that command. >>>>>>>>>>> >>>>>>>>>>> At stage 3 after manually starting qmail at the end of >>>>>>>>>>> qt-install. >>>>>>>>>>> >>>>>>>>>>> Stage 3 >>>>>>>>>>> >>>>>>>>>>> rpm -Uvh >>>>>>>>>>> ftp://ftp.qmailtoaster.com/pub/repo/qmt/CentOS/6/current/x86_64/qmt >>>>>>>>>>> -release-1-5.qt.el6.noarch.rpm >>>>>>>>>>> needs to be >>>>>>>>>>> >>>>>>>>>>> rpm -Uvh >>>>>>>>>>> ftp://ftp.qmailtoaster.com/pub/repo/qmt/CentOS/6/current/x86_64/qmt >>>>>>>>>>> -release-1-6.qt.el6.noarch.rpm >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> best wishes >>>>>>>>>>> Tony White >>>>>>>>>>> >>>>>>>>>>> .----------------. .----------------. .----------------. >>>>>>>>>>> | .--------------. || .--------------. || .--------------. | >>>>>>>>>>> | | ____ ____ | || | ______ | || | _______ | | >>>>>>>>>>> | | |_ _||_ _| | || | .' ___ | | || | / ___ | | | >>>>>>>>>>> | | \ \ / / | || | / .' \_| | || | | (__ \_| | | >>>>>>>>>>> | | \ \/ / | || | | | | || | '.___`-. | | >>>>>>>>>>> | | _| |_ | || | \ `.___.'\ | || | |`\____) | | | >>>>>>>>>>> | | |______| | || | `._____.' | || | |_______.' | | >>>>>>>>>>> | | | || | | || | | | >>>>>>>>>>> | '--------------' || '--------------' || '--------------' | >>>>>>>>>>> '----------------' '----------------' '----------------' >>>>>>>>>>> >>>>>>>>>>> http://www.ycs.com.au >>>>>>>>>>> 4 The Crescent >>>>>>>>>>> Yea >>>>>>>>>>> Victoria >>>>>>>>>>> Australia 3717 >>>>>>>>>>> >>>>>>>>>>> Telephone No's >>>>>>>>>>> VIC : 0418 515 717 >>>>>>>>>>> >>>>>>>>>>> Please note: YCS records all calls to better serve you. >>>>>>>>>>> >>>>>>>>>>> IMPORTANT NOTICE >>>>>>>>>>> >>>>>>>>>>> This communication including any file attachments is intended >>>>>>>>>>> solely for the use of the individual or entity to whom it is >>>>>>>>>>> addressed. If you are not the intended recipient, or the person >>>>>>>>>>> responsible for delivering this communication to the intended >>>>>>>>>>> recipient, please immediately notify the sender by email and delete >>>>>>>>>>> the original transmission and its contents. Any unauthorised use, >>>>>>>>>>> dissemination, forwarding, printing or copying of this >>>>>>>>>>> communication including file attachments is prohibited. >>>>>>>>>>> It is your responsibility to scan this communication including any >>>>>>>>>>> file attachments for viruses and other defects. To the extent >>>>>>>>>>> permitted by law, Yea Computing Services and its associates will >>>>>>>>>>> not be liable for any loss or damage arising in any way from this >>>>>>>>>>> communication including any file attachments. >>>>>>>>>>> You may not disclose this information to a third party without >>>>>>>>>>> written permission from the Author. >>>>>>>>>>> On 28/09/18 14:14, Eric Broch wrote: >>>>>>>>>>>> Excellent!!! Glad to hear it. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 9/27/2018 10:03 PM, Tony White wrote: >>>>>>>>>>>>> Eric, >>>>>>>>>>>>> Sorry I did not intend to email offlist. >>>>>>>>>>>>> I did a reply to sender not the list. >>>>>>>>>>>>> Apologies. >>>>>>>>>>>>> >>>>>>>>>>>>> I have reset the VM to give me a blank minimal install again. >>>>>>>>>>>>> It has just finished qt-bootstrp-2 without error. >>>>>>>>>>>>> So far so good. >>>>>>>>>>>>> >>>>>>>>>>>>> cheers. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 28/09/18 13:53, Eric Broch wrote: >>>>>>>>>>>>>> Tony, If you communicate off list you must whitelist my address >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tony, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think (not sure why) you're still using the wrong bootstrap >>>>>>>>>>>>>> scripts, my bootstrap's (below in red and green) do not use >>>>>>>>>>>>>> 'mirrors.qmailtoaster.com' but 'mirror2.qmailtoaster.com' >>>>>>>>>>>>>> >>>>>>>>>>>>>> Irritatingly, this is because all the mirror maintainers dropped >>>>>>>>>>>>>> the ball and didn't bother to let anyone know that they weren't >>>>>>>>>>>>>> supporting QMT anymore. If this is a pre-existing machine >>>>>>>>>>>>>> disable the qmailtoaster-current repo: >>>>>>>>>>>>>> >>>>>>>>>>>>>> # yum install yum-utils && yum-config-manager --disable >>>>>>>>>>>>>> qmailtoaster-current qmailtoaster-current-nodist >>>>>>>>>>>>>> >>>>>>>>>>>>>> <qt-bootstrap-1> >>>>>>>>>>>>>> >>>>>>>>>>>>>> #!/bin/bash >>>>>>>>>>>>>> >>>>>>>>>>>>>> # Copyright (C) Eric Shubert <e...@datamatters.us> # # script to >>>>>>>>>>>>>> do initial bootstrap processing (disable selinux, update >>>>>>>>>>>>>> everything) >>>>>>>>>>>>>> ################################################################ >>>>>>>>>>>>>> ###### >>>>>>>>>>>>>> # Change Log >>>>>>>>>>>>>> # 12/26/13 written by Eric 'shubes' <e...@shubes.net> >>>>>>>>>>>>>> ################################################################ >>>>>>>>>>>>>> ###### >>>>>>>>>>>>>> >>>>>>>>>>>>>> ################################################################ >>>>>>>>>>>>>> ###### >>>>>>>>>>>>>> # disable SELINUX >>>>>>>>>>>>>> # >>>>>>>>>>>>>> a2_disable_selinux(){ >>>>>>>>>>>>>> >>>>>>>>>>>>>> selinux_config=/etc/selinux/config >>>>>>>>>>>>>> >>>>>>>>>>>>>> if [ ! -f "$selinux_config" ]; then >>>>>>>>>>>>>> echo "$me - $seclinux_config not found" >>>>>>>>>>>>>> exit 1 >>>>>>>>>>>>>> fi >>>>>>>>>>>>>> >>>>>>>>>>>>>> echo "$me - disabling SELINUX ..." >>>>>>>>>>>>>> sed -i$(date +%Y%m%d) -e "s|^SELINUX=.*$|SELINUX=disabled|" >>>>>>>>>>>>>> $selinux_config >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> ################################################################ >>>>>>>>>>>>>> ###### >>>>>>>>>>>>>> # main routine begins here >>>>>>>>>>>>>> # >>>>>>>>>>>>>> me=${0##*/} >>>>>>>>>>>>>> myver=v1.0 >>>>>>>>>>>>>> echo "$me - $myversion" >>>>>>>>>>>>>> >>>>>>>>>>>>>> a2_disable_selinux >>>>>>>>>>>>>> >>>>>>>>>>>>>> echo "$me - updating all packages (yum update) ..." >>>>>>>>>>>>>> yum clean all >>>>>>>>>>>>>> yum -y --nogpgcheck update >>>>>>>>>>>>>> >>>>>>>>>>>>>> echo "$me - rebooting now..." >>>>>>>>>>>>>> shutdown -r now >>>>>>>>>>>>>> >>>>>>>>>>>>>> echo "$me - completed" >>>>>>>>>>>>>> exit 0 >>>>>>>>>>>>>> </qt-bootstrap-1> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> <qt-bootstrap-2> >>>>>>>>>>>>>> >>>>>>>>>>>>>> #!/bin/bash >>>>>>>>>>>>>> # Copyright (C) Eric Shubert <e...@datamatters.us> # # script to >>>>>>>>>>>>>> do secondary bootstrap processing (install yum priorities, QMT >>>>>>>>>>>>>> repo) >>>>>>>>>>>>>> ################################################################ >>>>>>>>>>>>>> ###### >>>>>>>>>>>>>> # Change Log >>>>>>>>>>>>>> # 12/26/13 written by Eric 'shubes' <e...@shubes.net> >>>>>>>>>>>>>> ################################################################ >>>>>>>>>>>>>> ###### >>>>>>>>>>>>>> >>>>>>>>>>>>>> ################################################################ >>>>>>>>>>>>>> ###### >>>>>>>>>>>>>> # main routine begins here >>>>>>>>>>>>>> # >>>>>>>>>>>>>> me=${0##*/} >>>>>>>>>>>>>> myver=v1.0 >>>>>>>>>>>>>> echo "$me - $myversion" >>>>>>>>>>>>>> >>>>>>>>>>>>>> # install yum-priorities >>>>>>>>>>>>>> echo "$me - installing yum-priorities (plugin) ..." >>>>>>>>>>>>>> yum -y install yum-priorities >>>>>>>>>>>>>> >>>>>>>>>>>>>> # install qmailtoaster-release >>>>>>>>>>>>>> qmt_release_pkg=qmailtoaster-release-2.0-2.qt.nodist.noarch.rpm >>>>>>>>>>>>>> echo "$me - installing $qmt_release_pkg (repo) ..." >>>>>>>>>>>>>> rpm -ivh >>>>>>>>>>>>>> http://mirror2.qmailtoaster.com/current/nodist/$qmt_release_pkg >>>>>>>>>>>>>> >>>>>>>>>>>>>> # install qmailtoaster-util (scripts) echo "$me - installing >>>>>>>>>>>>>> qmailtoaster-util (scripts) ..." >>>>>>>>>>>>>> yum -y install --nogpgcheck qmailtoaster-util >>>>>>>>>>>>>> >>>>>>>>>>>>>> echo "$me - completed" >>>>>>>>>>>>>> exit 0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> </qt-bootstrap-2> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/27/2018 8:50 PM, Tony White wrote: >>>>>>>>>>>>>>> Eric, >>>>>>>>>>>>>>> Step one failed on .org... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [root@cos6-10-base ~]# curl >>>>>>>>>>>>>>> https://www.qmailtoaster.org/qt-bootstrap-1 >qt-bootstrap-1 && >>>>>>>>>>>>>>> curl https://www.qmailtoaster.org/qt-bootstrap-2 >>>>>>>>>>>>>>>> qt-bootstrap-2 >>>>>>>>>>>>>>> % Total % Received % Xferd Average Speed Time Time >>>>>>>>>>>>>>> Time Current >>>>>>>>>>>>>>> Dload Upload Total >>>>>>>>>>>>>>> Spent >>>>>>>>>>>>>>> Left Speed >>>>>>>>>>>>>>> 105 1050 105 1050 0 0 931 0 0:00:01 0:00:01 >>>>>>>>>>>>>>> --:--:-- 4133 >>>>>>>>>>>>>>> % Total % Received % Xferd Average Speed Time Time >>>>>>>>>>>>>>> Time Current >>>>>>>>>>>>>>> Dload Upload Total >>>>>>>>>>>>>>> Spent >>>>>>>>>>>>>>> Left Speed >>>>>>>>>>>>>>> 100 1004 100 1004 0 0 890 0 0:00:01 0:00:01 >>>>>>>>>>>>>>> --:--:-- 3968 >>>>>>>>>>>>>>> [root@cos6-10-base ~]# chmod 755 qt-bootstrap-* >>>>>>>>>>>>>>> [root@cos6-10-base ~]# ./qt-bootstrap-1 >>>>>>>>>>>>>>> qt-bootstrap-1 - >>>>>>>>>>>>>>> qt-bootstrap-1 - disabling SELINUX ... >>>>>>>>>>>>>>> qt-bootstrap-1 - updating all packages (yum update) ... >>>>>>>>>>>>>>> Loaded plugins: fastestmirror, priorities Cleaning repos: base >>>>>>>>>>>>>>> extras qmailtoaster-current qmailtoaster-current-nodist updates >>>>>>>>>>>>>>> Cleaning up Everything Cleaning up list of fastest mirrors >>>>>>>>>>>>>>> Loaded plugins: fastestmirror, priorities Setting up Update >>>>>>>>>>>>>>> Process Determining fastest mirrors Could not retrieve >>>>>>>>>>>>>>> mirrorlist >>>>>>>>>>>>>>> http://mirrors.qmailtoaster.com/current/CentOS/mirror.list >>>>>>>>>>>>>>> error was >>>>>>>>>>>>>>> 14: PYCURL ERROR 51 - "SSL: certificate subject name >>>>>>>>>>>>>>> 'whitehorsetc.com' does not match target host name >>>>>>>>>>>>>>> 'mirrors.qmailtoaster.com'" >>>>>>>>>>>>>>> Error: Cannot find a valid baseurl for repo: >>>>>>>>>>>>>>> qmailtoaster-current >>>>>>>>>>>>>>> qt-bootstrap-1 - rebooting now... >>>>>>>>>>>>>>> qt-bootstrap-1 - completed >>>>>>>>>>>>>>> [root@cos6-10-base ~]# >>>>>>>>>>>>>>> Broadcast message from root@cos6-10-base >>>>>>>>>>>>>>> (/dev/pts/0) at 12:49 ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The system is going down for reboot NOW! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> best wishes >>>>>>>>>>>>>>> Tony White >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 28/09/18 12:37, Eric Broch wrote: >>>>>>>>>>>>>>>> Tony, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It is working, but... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I can tell by the download of >>>>>>>>>>>>>>>> 'qmailtoaster-release-2.0-1.qt.nodist.noarch.rpm' and the use >>>>>>>>>>>>>>>> of 'mirrors.qmailtoaster.com' in the scripts that you're not >>>>>>>>>>>>>>>> following the correct instructions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm not sure whether the qmailtoaster.com website (mirrored) >>>>>>>>>>>>>>>> has completely propagated or not. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Go to qmailtoaster.org and follow the instructions there. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Eric >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/27/2018 7:56 PM, Tony White wrote: >>>>>>>>>>>>>>>>> Hi Eric, >>>>>>>>>>>>>>>>> Sadly it is still not working... >>>>>>>>>>>>>>>>> The download of the >>>>>>>>>>>>>>>>> http://mirrors.qmailtoaster.com/current/nodist/qmailtoaster-r >>>>>>>>>>>>>>>>> elease-2.0-1.qt.nodist.noarch.rpm file will always fail due >>>>>>>>>>>>>>>>> to it kicking the connection up to https and not leaving it >>>>>>>>>>>>>>>>> as http. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Screen Dump... >>>>>>>>>>>>>>>>> -------------------------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [root@cos6-10-base ~]# sh qt-bootstrap-2 >>>>>>>>>>>>>>>>> qt-bootstrap-2 - >>>>>>>>>>>>>>>>> qt-bootstrap-2 - installing yum-priorities (plugin) ... >>>>>>>>>>>>>>>>> Loaded plugins: fastestmirror Setting up Install Process >>>>>>>>>>>>>>>>> Loading mirror speeds from cached hostfile >>>>>>>>>>>>>>>>> * base: centos.mirror.digitalpacific.com.au >>>>>>>>>>>>>>>>> * extras: centos.mirror.digitalpacific.com.au >>>>>>>>>>>>>>>>> * updates: mirror.as24220.net Resolving Dependencies >>>>>>>>>>>>>>>>> --> Running transaction check >>>>>>>>>>>>>>>>> ---> Package yum-plugin-priorities.noarch 0:1.1.30-42.el6_10 >>>>>>>>>>>>>>>>> will be installed >>>>>>>>>>>>>>>>> --> Finished Dependency Resolution >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Dependencies Resolved >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ============================================================= >>>>>>>>>>>>>>>>> ================================================== >>>>>>>>>>>>>>>>> Package Arch Version >>>>>>>>>>>>>>>>> Repository Size >>>>>>>>>>>>>>>>> ============================================================= >>>>>>>>>>>>>>>>> ================================================== >>>>>>>>>>>>>>>>> Installing: >>>>>>>>>>>>>>>>> yum-plugin-priorities noarch >>>>>>>>>>>>>>>>> 1.1.30-42.el6_10 updates 28 k >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Transaction Summary >>>>>>>>>>>>>>>>> ============================================================= >>>>>>>>>>>>>>>>> ================================================== >>>>>>>>>>>>>>>>> Install 1 Package(s) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Total download size: 28 k >>>>>>>>>>>>>>>>> Installed size: 28 k >>>>>>>>>>>>>>>>> Downloading Packages: >>>>>>>>>>>>>>>>> yum-plugin-priorities-1.1.30-42.el6_10.noarch.rpm >>>>>>>>>>>>>>>>> | 28 kB 00:00 >>>>>>>>>>>>>>>>> Running rpm_check_debug >>>>>>>>>>>>>>>>> Running Transaction Test >>>>>>>>>>>>>>>>> Transaction Test Succeeded >>>>>>>>>>>>>>>>> Running Transaction >>>>>>>>>>>>>>>>> Installing : >>>>>>>>>>>>>>>>> yum-plugin-priorities-1.1.30-42.el6_10.noarch >>>>>>>>>>>>>>>>> 1/1 >>>>>>>>>>>>>>>>> Verifying : >>>>>>>>>>>>>>>>> yum-plugin-priorities-1.1.30-42.el6_10.noarch >>>>>>>>>>>>>>>>> 1/1 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Installed: >>>>>>>>>>>>>>>>> yum-plugin-priorities.noarch >>>>>>>>>>>>>>>>> 0:1.1.30-42.el6_10 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Complete! >>>>>>>>>>>>>>>>> qt-bootstrap-2 - installing >>>>>>>>>>>>>>>>> qmailtoaster-release-2.0-1.qt.nodist.noarch.rpm (repo) ... >>>>>>>>>>>>>>>>> Retrieving >>>>>>>>>>>>>>>>> http://mirrors.qmailtoaster.com/current/nodist/qmailtoaster-r >>>>>>>>>>>>>>>>> elease-2.0-1.qt.nodist.noarch.rpm >>>>>>>>>>>>>>>>> curl: (51) SSL: certificate subject name >>>>>>>>>>>>>>>>> 'monk13.stakehouse.io' >>>>>>>>>>>>>>>>> does not match target host name 'mirrors.qmailtoaster.com' >>>>>>>>>>>>>>>>> error: skipping >>>>>>>>>>>>>>>>> http://mirrors.qmailtoaster.com/current/nodist/qmailtoaster-r >>>>>>>>>>>>>>>>> elease-2.0-1.qt.nodist.noarch.rpm >>>>>>>>>>>>>>>>> - transfer failed >>>>>>>>>>>>>>>>> qt-bootstrap-2 - installing qmailtoaster-util (scripts) ... >>>>>>>>>>>>>>>>> Loaded plugins: fastestmirror, priorities Setting up Install >>>>>>>>>>>>>>>>> Process Loading mirror speeds from cached hostfile >>>>>>>>>>>>>>>>> * base: centos.mirror.digitalpacific.com.au >>>>>>>>>>>>>>>>> * extras: centos.mirror.digitalpacific.com.au >>>>>>>>>>>>>>>>> * updates: mirror.as24220.net No package qmailtoaster-util >>>>>>>>>>>>>>>>> available. >>>>>>>>>>>>>>>>> Error: Nothing to do >>>>>>>>>>>>>>>>> qt-bootstrap-2 - completed >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> best wishes >>>>>>>>>>>>>>>>> Tony White >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 27/09/18 10:24, Eric Broch wrote: >>>>>>>>>>>>>>>>>> List, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> There were problems with the installation of QMT on CentOS 6 >>>>>>>>>>>>>>>>>> as you'all well know since I tested last November (2017). >>>>>>>>>>>>>>>>>> The problems existed primarily due to mirrors not being >>>>>>>>>>>>>>>>>> maintained. I've fixed these problems...hopefully. If anyone >>>>>>>>>>>>>>>>>> has issue please let me know so that they can be fixed. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Eric Broch >>>>>>>>>>>>>>>> White Horse Technical Consulting (WHTC) >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Eric Broch >>>>>>>>>>>>>> White Horse Technical Consulting (WHTC) >>>>>>>>>>>> -- >>>>>>>>>>>> Eric Broch >>>>>>>>>>>> White Horse Technical Consulting (WHTC) >>>>>>>>>> -- >>>>>>>>>> Eric Broch >>>>>>>>>> White Horse Technical Consulting (WHTC) >>>>>>> -- >>>>>>> Eric Broch >>>>>>> White Horse Technical Consulting (WHTC) >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>>>>>> For additional commands, e-mail: >>>>>>> qmailtoaster-list-h...@qmailtoaster.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> --- >>>>>>> This email has been checked for viruses by Avast antivirus software. >>>>>>> https://www.avast.com/antivirus >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>>>>>> For additional commands, e-mail: >>>>>>> qmailtoaster-list-h...@qmailtoaster.com >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>>>>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>>>>> > > -- > Eric Broch > White Horse Technical Consulting (WHTC) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > --------------------------------------------------------------------- To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
