Save the file attached to the ticket 6718
save it as ghosttest.c in the target machine
gcc ghosttest.c -o ghosttest ./ghosttest
output should be “not vulnerable” If it says vulnable, then we have to
yum update glibc* and then again validate with ./ghosttest
If you run yum update glibc - we need to reboot the servers.
Apply the patches above and reboot should be done in this sequence - please change and validate order from Uday
(1) prdapp02 - (No down time is needed).
before restart -> use internal IP, validate site. -> check running services and verify that everything is normal -> verify whether bash update was done. if so verify whether it will impact restart -Opsource ticket 42400 -> update network functions if the above scenario is valid -> restart prdapp02 after restart -> Verify that the services are running - (apache/passenger, god & gluster drive is mounted. check if rails console opens up normally and no side effects.) -> check the site with internal IP -> check the site with external IP -> confirm normal functioning of site
(2) mysql slave - (Down time is needed (because of content files)).
before restart
-> check the status of slave with log and position replicated . check whether Yes is there for mysql slave replication process and thread
-> stop slave mysql
-> verify whether bash update was done. if so verify whether it will impact restart -Opsource ticket 42400
-> update network functions if the above scenario is valid
-> restart the box
after restart
-> check mysql services, solr and gluster server. Verify that gluster mounts are fine on prodapp01 and prodapp02.
-> start slave mysql
-> verify that the replication has started without errors- show slave status\G
(3) mysql master - (Down time is needed).
before restart -> check running services -> verify whether bash update was done. if so verify whether it will impact restart -Opsource ticket 42400 -> update network functions if the above scenario is valid -> restart master after restart -> check mysql services -> show master status
(4) prdapp01 - (Down time is needed).
before restart -> use internal IP, validate site. -> check running services and verify that everything is normal -> verify whether bash update was done. if so verify whether it will impact restart -Opsource ticket 42400 -> update network functions if the above scenario is valid -> restart prdapp01 after restart -> Verify that the services are running - (apache/passenger, god & gluster drive is mounted. check if rails console opens up normally and no side effects.) -> check the site with internal IP -> check the site with external IP -> confirm normal functioning of site
(5) prodcollab01 - (Down time is needed because of video recording feature.)
before restart -> check gluster services running -> check file / folder ownerships and document them for the gluster service -> raise a ticket for Opsource that you are going to restart the box -> be on call for them connected to the terminal of the box -> restart and then ask them to skip disk errors as it will take hours for the disk errors to be checked after restart -> check bbb / gluster services -> check gluster mounts from prdapp01 / prdapp02
(6) front end - (Down time is needed)
before restart after restart -> Verify Haproxy is up. Chat service is fine (both redis and node).
After the complete reboot -
Issue 1 - prodcollab01 - call Opsource and request them to skip disk check as we reboot Issue 2 - Network restart - https://bugzilla.redhat.com/show_bug.cgi?id=482826
Follow the solution in the bug above before doing the restart on each and every system.