SysAdmin

For plain bytes/second bandwidth testing - ie without taking things like encryption overhead and compression improvements into account - the netcat command-line utility is pretty handy. Once installed on both servers (let’s call them serverA and serverB): start netcat to listen on one server and pipe the output through wc -c to both count the bytes (for confirmation) but also so that the bytes are not written to a filesystem or the terminal (which would cause a bottleneck and likely reduce the apparent bandwidth). By default nc will quit when the first network connection it accepts is closed: <span id="line-58" class="anchor"></span>serverA$ nc -l -p 12345 | wc -c start netcat to send data from the other server - using dd to send as quickly as possible (using /dev/zero is fast). Using -q 0 will cause netcat to quit as soon as it sees an end of file (EOF): <span id="line-61" class="anchor"></span>serverB$ dd if=/dev/zero bs=$((2**20)) count=$((2**10)) | nc -q 0 serverA 12345 On the sending server (serverB) the output will show the number of bytes transmitted and the time it took to do that: <span id="line-66" class="anchor"></span>1048576+0 records in <span id="line-67" class="anchor"></span>1048576+0 records out <span id="line-68" class="anchor"></span>1073741824 bytes (1.1 GB) copied, 9.68678 s, 111 MB/s And on the other server (serverA) the number of bytes will be printed (confirming the transmission was complete): 1073741824 Run this in both directions a few times to get a good feeling for the bandwidth between the servers.

The Scenario A couple of terminals open, connected to a mix of your own workstation, local development servers and remote servers running on a different network and frequently behind a variety of security barriers. You want to copy a smallish chunk of code from a file across the network, or the output of a diff to apply a patch - but characters like whitespace and newlines which should not change will frequently be modified through the copy. You end up with whitespace changes where you don’t want them (perhaps later causing source code control merges to fail, and patches will fail straight away). ...

Setting up WordPress server there were a couple of minor wrinkles to sort out. I’ve run a blog before before and that fell by the wayside when I started using a personal wiki instead. But this seems like a good opportunity to see how one of the very popular blogging platforms works and what’s involved in keeping that running under the hood. I work primarily with Debian systems, so that was a natural place to start. The wordpress package makes it very easy to get the base dependencies going with a known supported version, so if you’re running a recent release of Debian that seems like a reasonable place to start as well. That said, this of course means that the package is reconfigured along Debian guidelines and I found that I needed to spend a little time working out how this was done before it made sense. ...

The Problem: A Default Setting By default user registration is enabled. It’s important to realise that even though links to the user registration page may not have been included in the design of a Joomla site the components are still present and they will be regularly targetted by automatic spiders searching for vulnerable sites. Check access logs for requests to paths like: /index.php/shop-login /index.php/shop-login?view=registration&layout=complete /index.php/component/users/?view=registration /index.php/component/user/?task=register /index.php?option=com_user&view=register With user registration enabled scripts can use a Joomla site as an open mail relay by registering users with target email addresses and inserting spam/attack payload into the user details. The Joomla site will send a confirmation email to the target email address, and any email tracing of the source of the email will lead directly to the weakened Joomla server. ...