linux

It's not a coincidence that notebook docking stations are being sold only with high-end laptops. My Dell e7740 costs over 2000 €. When I bought it in January 2014, I couldn't imagine I'll have trouble making it work under Linux. After all, it was all-intel, already well-supported hardware. The trouble came from a usually dumb piece of hardware: the docking station. I run two 1920x1200 screens in portrait mode, but this freaking docking station"intelligently" merged the two screens into a virtual 3840x1200 screen and presented just that to the notebook.

The bug-o-feature responsible for this is called Displayport Multi-Stream Transport and it was intended to drive multiple displays via one cable using daisy-chaining. When first docking stations with MST support appeared by end 2013, none was prepared for it. It took well over a year before MST support landed in mainline 3.17 kernel. And it will take another year until all major distributions move to 3.17 and past it.

Red Hat itself found it out only when they run into the problem, and it took 6 months before David Airlie came up with a patch to fix this hardware bug. Check out this talk for a good overview of the story.

The cluster runs on apt-based systems. It is designed for high-availability: failure of one server is not critical. However, there is no automatic failover configuration. Instead, manual recovery is possible within minutes.

• Load balancers run varnish. Its configuration file takes into account the context_breakpoint cookie that's used to implement responsive delivery. The same server also has memcached.
• Application servers run nginx and a recent php5-fpm through unix sockets. There's also drush. The filesystem is shared through glusterfs.
• MariaDb is configured in master-slave mode on database servers. They also run Apache Solr.

All servers set up exim to work as smarthost, sending mails through gmail. In practice, gmail limits outgoing emails to a few thousands per day, so it is better to replace it by a dedicated solution such as Mailchimp. There's also newrelic for server monitoring on all servers.

The playbook assumes that all servers have public IPs on eth0 and sit in the private network on eth1.

For the rest, check the code in github.

Internet trolls are using Tor nowadays to avoid bans by IP. However, banning Tor exit nodes is just slightly more complex. The Tor Project provides a regularly updated list of exit nodes that can access your IP here. As there may be many hundreds or even thousands of nodes, adding them to iptables can hurt your server's network performance. Enter ipset, a user-space hash table for iptables:

# create a new set for individual IP addresses
ipset -N tor iphash
# get a list of Tor exit nodes that can access $YOUR_IP, skip the comments and read line by line
wget -q https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=$YOUR_IP -O -|sed '/^#/d' |while read IP
do 
  # add each IP address to the new set, silencing the warnings for IPs that have already been added
  ipset -q -A tor $IP
done
# filter our new set in iptables
iptables -A INPUT -m set --match-set tor src -j DROP

Assuming that the internal screen is LVDS and the external screen is DVI-0. inotifywait comes from the inotify-tools package.

# Wait for the changes detected by the kernel laptop mode.
while inotifywait -e modify /proc/sys/vm/laptop_mode
do
laptop_mode=`cat /proc/sys/vm/laptop_mode`
  # If on battery, switch on the internal screen.
  if [[ $laptop_mode -gt 0 ]]; then
    xrandr --output LVDS --mode 1280x800
    xrandr --output DVI-0 --off
  # Otherwise,
  elif [[ $laptop_mode = 0 ]]; then
     # if the external screen is connected, switch it on.
     if [[ `xrandr -q|grep DVI-0|cut -f2 -d\ ` = connected ]]; then
       xrandr --output DVI-0 --mode 1920x1200
       xrandr --output LVDS --off
     fi
  fi
done

A bad sysadmin changes the default SSH port.

A good sysadmin throttles the brute-force attackers by allowing one new connection in 20 seconds.

# requires xt_TARPIT
iptables -A INPUT -p tcp -m state --state NEW \
  --dport 22 -m recent --update --seconds 20 -j TARPIT
iptables -A INPUT -p tcp -m state --state NEW \
  --dport 22 -m recent --set -j ACCEPT

A brilliant sysadmin blocks intruders indefinitely

# requires hashlimit
iptables -A INPUT -p tcp -m tcp --dport 22 -m state \
  --state NEW -m hashlimit --hashlimit 1/hour \
  --hashlimit-burst 2 --hashlimit-mode srcip \
  --hashlimit-name SSH --hashlimit-htable-expire 60000 
  -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 22 \
  --tcp-flags SYN,RST,ACK SYN -j DROP 

iptables -A INPUT -p tcp -m state \
  --state NEW -m tcp --dport 22 -j ACCEPT

In the last example, the 1st rule allows up to two connections per hour. After the limit of two connections per hour is reached, the second rule becomes active and the hashlimit module starts to countdown from 1 minute (60 000 milliseconds). If you connect within 1 minute, the hashlimit counter is reset to 60 000. If you connect after 1 minute, you drop to the 3rd rule and are allowed access.

Cherry-picked from Habr