I found the problem.
I run named as a caching only server and had to change nsswitch.conf's
host line to look in dns instead of mdns4_minimal. I had changed this line:
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
to
hosts: files dns
After the upgrade I have a new nsswitch.conf file as well as a
nsswitch.conf.rpmnew, neither of which is my old file and both of which
have the first line above for the hosts definition. As a result
nslookup would work fine, because it directly connects to named and
doesn't use nsswitch and I could ping using IP addresses. But, I
couldn't resolve any in house domain names which I had forwarding
statements in named.conf. Once I redefined hosts in nsswitch.conf to be
like the second line and rebooted everything is fine.
So, it seems that the upgrade stomped on my locally modified
nsswitch.conf file because it is nowhere to be found.
If the upgrade was going to overwrite my nsswitch.conf file shouldn't it
have left a nsswitch.conf.rpmsave which would be a copy of my original
file ?
Also, in all the other cases where there was a .rpmnew file for a config
file created by the upgrade the original config file was left untouched
and it was left to me to merge my changes into .rpmnew and make that
merge the new config file. But in nsswitch.conf's case the upgrade left
me a nsswitch.conf.rpmnew as well as a new nsswitch.conf file that was
different than the nsswitch.conf.rpmnew and also different than the
nsswitch.conf.rpmnew or the original nsswitch.conf file.
It seems wrong to me to change the nsswitch.conf file but not leave a
nsswitch.conf.rpmsave copy of the original file.
At any rate my problem is solved and I just have to remember whenever I
do an upgrade I have to go edit the nsswitch.conf file. I did an upgrade
from F25 directly to F27 just to verify and indeed the same issue came
up. So, seems to be something that will need to be done going forward on
every upgrade. sigh... Hope I can remember this one.
Thanks
Chris Kottaridis
On 3/13/2018 8:27 AM, Mark C. Allman wrote:
On 03/13/2018 02:14 AM, Bill Shirley wrote:
You've posted very little code. Have you tried looking at the
headers? You
must turn on trace:
$soap_options = array(
'trace'=>true
// ,'soap_version'=>SOAP_1_2
// ,'exceptions'=>false
// ,'classmap'=>$classmap
);
$soap_client = new SoapClient($wsdl_url, $soap_options);
try {
$request_fault = false;
$soap_response = $soap_client->GetByProNumber($request_parms);
} catch (SoapFault $request_fault) {
echo "request_fault:\n" . print_r($request_fault,true) . "\n";
}
echo "<pre class='debug'><b>REQUEST HEADERS:</b><br>" .
htmlentities($soap_client->__getLastRequestHeaders()) . "</pre>\n";
echo "<pre class='debug'><b>Response Headers:</b><br>" .
htmlentities($soap_client->__getLastResponseHeaders()) . "</pre><br>\n";
HTH,
Bill
On 3/12/2018 11:54 AM, Chris Kottaridis wrote:
I finally got around to upgrading from Fedora25 to Fedora26.
The layout is I have two partitions of which at any time one of the
is the root partition, which contains everything but the /boot
partition, and the other is not used. I have a separate /boot
partition. When I upgrade I go into single user and duplicate the
currently used root partition to the unused one using:
# mkfs.xfs /dev/fedora/rootb
# mount /dev/fedora/rootb /mnt
# xfsdump -J - / | xfsrestore -J - /mnt
Then I modify /boot/grub2/grub.cfg and tell vmlinuz to use the new
partition and modify /mnt/etc/fstab to have the root partition be the
new partition. I then reboot and indeed I come up on the new
partition just fine, still running F25. On this new partition I do
the OS upgrade. The upgrade goes fine and it boots up just fine on
Fedora26.
I did a search for .rpmsave files to see if the upgrade changed any
configuration files I may have modified locally and that came up empty.
However, when I try and use the application that runs on that machine
which is PHP SOAP I get an error "can not connect to host". The
nslookup for that host is correct and I can ping the host. As far as
I know nothing has changed on that host. My code uses the following
to handle self-signed certs:
'stream_context'=> stream_context_create(array('ssl'=>
array('verify_peer'=>false,'verify_peer_name'=>false)))
But I know that the cert on the host I am contacting is not self-signed.
If I go back and edit /boot/grub2/grub.cfg to boot up off the old
Fedora25 root partition it comes up fine and I can use the
application just fine to connect to the host.
Is there any history of PHP or SOAP having a change from F25 to F26
that could explain the "can not connect to host" error I am seeing on
F26 that I don't see on F25 ?
Thanks
Chris Kottaridis
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
I'd check the firewall. I don't remember when firewalld was introduced.
I've also seen where upgrades to firewalld, iptables, sendmail, etc.,
have introduced changes like being enabled or not. If you weren't using
firewalld and the upgrade enabled it then the soap request (port 80?)
might now be blocked.
*Mark C. Allman, PMP, CSM*
Founder, See How You Ski, www.seehowyouski.com <http://www.seehowyouski.com>
Sr. Project Manager, Allman Professional Consulting, Inc.,
www.allmanpc.com <http://www.allmanpc.com>
617-947-4263, Twitter: @allmanpc
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx