On CentOS 7, getting 404 error from yum when trying to update.
|
1 |
http://mirror.centos.org/centos/7/virt/x86_64/xen-46/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found |
The error is related to Xen-46 which has been removed. The fix is to remove the repo and add the new Xen-48 repo:
|
1 2 |
yum remove centos-release-xen yum install centos-release-xen-48 |
Here’s a good set of instructions for upgrading MySQL from 5.1 to 5.5 on older CentOS 6.9 servers: How to Upgrade MySQL 5.1 to MySQL 5.5 on CentOS 6.7
CentOS uses the libjpeg-turbo fork of the original libjpeg project. So to install jpegtran do this:
|
1 2 |
yum install libjpeg-turbo-utils |
On October 19, 2016, a privilege escalation vulnerability in the Linux kernel was disclosed. The bug is nicknamed Dirty COW because the underlying issue was a race condition in the way kernel handles copy-on-write (COW). Dirty COW has existed for a long time — at least since 2007, with kernel version 2.6.22 — so the vast majority of servers are at risk. Exploiting this bug means that a regular, unprivileged user on your server can gain write access to any file they can read, and can therefore increase their privileges on the system. More information can be found on CVE-2016-5195 from Canonical, Red Hat, and Debian. Fortunately, most major distributions have already released a fix. You can follow this tutorial to see if your server is vulnerable and to apply updates as needed. Check Vulnerability Ubuntu/Debian To find out if your server is affected, check your kernel version. uname -rv
Ran into a strange problem recently … web server behind a firewall was able to resolve names with “dig” sucessfully but attempts to fetch web pages with “wget” or “curl” was very slow … seemed to hang on name resolution. So this would work fine:
|
1 |
dig yahoo.com |
but this would hang for several seconds:
|
1 |
wget yahoo.com |
This problem extended to curl requests from with in PHP … in this case a Magento website … various plugins in the site were “calling home” when loading admin pages which resulted in making the admin painfully slow. After much debugging we concluded that the problem was due to the fact that certain versions of glibc run IPv4 and IPv6 requests in parallel which breaks some firewalls and/or DNS servers. The work around was to add this option in /etc/resolv.conf:
|
1 |
options single-request |
This forces the requests to be made sequentially instead of in parallel. Hope this helps other
Reliable Penguin provides managed web hosting, systems administration, website and server migrations, and expert consulting.
Submit the form—or for immediate service call 866-649-7984.