Wednesday, January 28, 2015

When Not to Use Generator Expressions

I found that post very helpful. I didn't know it's a better idea to use a list comprehension rather than a generator expression for "".join().

mod_wsgi + Flask

Here's my mod_wsgi configuration for a flask app that uses Flask-Admin.

Trailing slashes matter! If you set a trailing slash, it will only set the alias for that directory and not all of the directories below it.

Monday, January 26, 2015

Request.Args Empty During Tests - Flask

If you're using app.test_client().get, it's very important to use a relative url or your parameters will be removed.

# will not pass request.args
rv = self.client.get('')

# works just fine
rv = self.client.get('/view/?foo=bar')

Thursday, January 22, 2015

Self-Hosting Fonts

That's the most helpful guide I found for self-hosting your own fonts and preventing compatibility issues.

Wednesday, January 21, 2015

Dokku Change Nginx Timeout

None of the plug-ins for doing custom nginx configurations were working for me.

So, I changed the following two files:

I added the following under "location    / {":
proxy_connect_timeout 300s;
proxy_read_timeout 300s;

Tuesday, January 20, 2015

Supervisord Tips and Gotchas

If you make configuration changes, the changes will not take effect until you:
  • supervisorctl reread
  • supervisorctl update

"redirect_stderr=true" will cause both stderr and stdout to appear in the "stdout" log.

You get to select which user runs the command with the "user" parameter.
For example: user=root
Supervisord keeps its own set of environmental variables with the "environment" parameter. It won't pick up env variables from /etc/environment.
For example: environment=A="1",B="2"
For Gunicorn, use a configuration file rather than putting all your arguments into the "command" parameter.
For example, -t will be ignored here:
command=/path/to/gunicorn main:application -t 300
Instead use:
command=/path/to/gunicorn main:application -c /path/to/

Monday, January 19, 2015

Installing python-ldap on Dokku

Install this plugin:

Create an apt-packages file in the root directory of your repository with the following lines:

Now, commit your new apt-packages file and python-ldap should install successfully.

I also had trouble installing pymssql, and got an error saying "_mssql.c:314:22: fatal error: sqlfront.h: No such file or directory". Similar fix, just add "freetds-dev" to your apt-packages file.

Enabling SSL On Dokku

  1. It's important that you have the newest version of Dokku:
  2. Zip your certificate and key: sudo tar cvf archive_name.tar.gz server.crt server.key
  3. Import using dokku nginx:import-ssl appname < ~/archive_name.tar.gz


I was trying to add my certificate to Dokku using "dokku nginx:import-ssl" when I got the error message "Expecting: TRUSTED CERTIFICATE".

This ended up being an issue with line endings and the dos2unix utility fixed it:

Sunday, January 18, 2015

Thursday, January 15, 2015

Nmap Not Finding Hostnames

The secret ended up being running the command as sudo. It's odd how "socket.gethostbyaddr()" worked just fine without sudo, but was slower than nmap.

Wednesday, January 7, 2015

Slow Disk Performance On Dell r620


I installed openmanage with the instructions on this page and used it to check/update bios settings:

The fix ended up being BIOS power profile settings. It was set to Performance Per Watt (DAPC) and needed to be set to "Performance".
It's very interesting that the BIOS power profile settings didn't seem to affect Ubuntu 14.10's disk read speed.


I have three of the same server. All the servers are Dell r620's with a PERC H710 Mini RAID controller (21.2.0-0007_A04 firmware) and have the exact same hard drives (Seagate ST300MM0006) in RAID 1 configurations. I'm seeing about 50% worse disk read performance on some versions of Ubuntu.

They only differences I can find in the hardware:
  • The BIOS version on the poorly performing machines is 1.4.8, the machine that's performing well is on 1.6.0. The BIOS change log doesn't appear to have any changes between the two versions that would affect anything.
  • The chipset version on the RAID controller of the poorly performing machines is rev 01 (ChipRevision: B0). The machine that's performing well has the rev 05 chipset (ChipRevision: D1). The motherboard chipset revision is also different.
Here are the benchmark results for the different Ubuntu versions and RAID controller chipsets:

(mysql read speed test - using the same version of mysql across all 3 machines)
sysbench --test=oltp --oltp-table-size=1000000 --mysql-db=test --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run:
(13.04 - rev 05): read/write requests:                 4996362 (83271.11 per sec.)
(14.04 - rev 01): read/write requests:                 1906520 (31773.58 per sec.)
(14.10 - rev 01): read/write requests:                 5166798 (86111.50 per sec.)

dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output:
(13.04 - rev 05): 83886080 bytes (84 MB) copied, 0.0437543 s, 1.9 GB/s
(13.04 - rev 01) 83886080 bytes (84 MB) copied, 0.116811 s, 718 MB/s
(13.10 - rev 01): 83886080 bytes (84 MB) copied, 0.129371 s, 648 MB/s
(14.04 - rev 01): 83886080 bytes (84 MB) copied, 0.157808 s, 532 MB/s
(14.10 - rev 01): 83886080 bytes (84 MB) copied, 0.102355 s, 820 MB/s

hdparm -tT /dev/sda1:
(13.04 - rev 05): Timing cached reads:23154 MB in  2.00 seconds = 11589.16 MB/sec
(13.04 - rev 01): Timing cached reads:17934 MB in  2.00 seconds = 8973.68 MB/sec
(13.10 - rev 01): Timing cached reads:18102 MB in  2.00 seconds = 9058.08 MB/sec
(14.04 - rev 01): Timing cached reads:17846 MB in  1.99 seconds = 8956.28 MB/sec
(14.10 - rev 01): Timing cached reads:21538 MB in  2.00 seconds = 10777.93 MB/sec

At one point, 2 of the rev 01 servers were using Ubuntu 14.04 and were getting similar bad benchmark results. After the upgrading them to 14.10, I immediately saw the disk read speed increase.

The performance on rev 01 machine with 13.04 was bad, but somehow the rev 05 machine with the same OS version was performing well. This told me it's not a problem with the megaraid_sas driver, because the rev 01 and rev 05 machines with 13.04 had the same version.

Here's the closest I can find to a similar issue (it's different hardware though):

Update 3/1/2015:
Saw an interesting checklist on Hacker News today that also mentioned disabling BIOS power saving settings:

Tuesday, January 6, 2015

MegaCli64 / MegaCli Only showing "Exit Code: 0x00"

Problem: You see MegaCli64 or MegaCli only showing "Exit Code: 0x00" when you try to run commands.

Solution: Try running as sudo.

Thursday, January 1, 2015

Changing Putty Default Settings

If you need to change Putty's defaults, press "Load" on the saved session for "Default Settings", make your changes, and "Save".