CentOS uses the libjpeg-turbo fork of the original libjpeg project. So to install jpegtran do this:
1 |
yum install libjpeg-turbo-utils |
Linux and open-source solutions.
CentOS uses the libjpeg-turbo fork of the original libjpeg project. So to install jpegtran do this:
1 |
yum install libjpeg-turbo-utils |
Recently needed a good way to fetch the IP address of each interface within a script. Tried things like:
1 |
ifconfig | grep 'inet addr:'| grep -v '127.0.0.1' | cut -d: -f2 | awk '{ print $1}' |
and
1 |
/sbin/ifconfig | sed -n '2 p' | awk '{print $3}' |
But this is fairly ugly. So I tried:
1 |
hostname -I |
This gives a list of IP addresses but they are un-ordered so I can’t guarantee which address goes with which interface. Here’s one using “ip addr”:
1 |
ip=$(ip -f inet -o addr show eth0|cut -d\ -f 7 | cut -d/ -f 1) |
Still very messy. Finally, found the “ifdata” command which is part of the “moreutils” package. First make sure “moreutils” is installed with:
1 |
yum -y install moreutils |
Now you can query for a wide range of different information:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
Usage: ifdata [options] iface -e Reports interface existence via return code -p Print out the whole config of iface -pe Print out yes or no according to existence -pa Print out the address -pn Print netmask -pN Print network address -pb Print broadcast -pm Print mtu -ph Print out the hardware address -pf Print flags -si Print all statistics on input -sip Print # of in packets -sib Print # of in bytes -sie Print # of in errors -sid Print # of in drops -sif Print # of in fifo overruns -sic Print # of in compress -sim Print # of in multicast -so Print all statistics on output -sop Print # of out packets -sob Print # of out bytes -soe Print # of out errors -sod Print # of out drops -sof Print # of out fifo overruns -sox Print # of out collisions -soc Print # of out carrier loss -som Print # of out multicast -bips Print # of incoming bytes per second -bops Print # of outgoing bytes per second |
So here are some examples:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[root@host]# ifdata -pa eth0 10.210.160.53 [root@host]# ifdata -pa eth0 10.210.160.53 [root@host]# ifdata -pn eth0 255.255.224.0 [root@host]# ifdata -sip eth0 1622384587 [root@host]# ifdata -bops eth0 896 |
Overall this is much cleaner and more reliable then the earlier approaches.
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.
To find out if your server is affected, check your kernel version.
You’ll see output like this:
1 2 |
4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 UTC 2016 |
If your version is earlier than the following, you are affected:
Some versions of CentOS can use this script provided by RedHat for RHEL to test your server’s vulnerability. To try it, first download the script.
Then run it with bash
.
If you’re vulnerable, you’ll see output like this:
1 2 3 4 |
Your kernel is 3.10.0-327.36.1.el7.x86_64 which IS vulnerable. Red Hat recommends that you update your kernel. Alternatively, you can apply partial mitigation described at https://access.redhat.com/security/vulnerabilities/2706661 . |
Fortunately, applying the fix is straightforward: update your system and reboot your server.
On Ubuntu and Debian, upgrade your packages using apt-get
.
You can update all of your packages on CentOS 6 and 7 with sudo yum update
, but if you only want to update the kernel to address this bug, run:
Right now, we’re still waiting on a fix for CentOS 5. In the interim, you can use this workaround from the Red Hat bug tracker.
Finally, on all distributions, you’ll need to reboot your server to apply the changes.
Make sure to update your Linux servers to stay protected from this privilege escalation bug.
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 struggling with these weird symptoms.
Great article from the team at Sucuri about why websites get hacked:
https://blog.sucuri.net/2015/02/why-websites-get-hacked.html
Covering automation, targeted vs attacks of opportunity and the motivation behind hacking, this article is a great introduction for the non technical user.