sudo tar cvf archive_name.tar.gz server.crt server.keydokku nginx:import-ssl appname < ~/archive_name.tar.gz Dokku: Nginx proxy configurationI 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: http://serverfault.com/a/317038
http://docs.python-requests.org/en/latest/user/quickstart/#binary-response-content
From the example:
>>> from PIL import Image
>>> from StringIO import StringIO
>>> i = Image.open(StringIO(r.content))
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.
I’ve been doing a lot of work in Flask-Admin lately, and the thing that kept bugging me was editing a single field. I’d spot a typo in the list, click into the record’s edit form, change one field, save, and go back. That’s a lot of clicks for a one-character fix.
So I opened an issue proposing edits straight from the list view (#755) and then built it (#756, merged today).
It’s a new column_editable_list property on the ModelView:
class UserView(ModelView):
column_editable_list = ['name', 'email']
Those columns become click-to-edit in the list. Click a cell, type, hit enter, and it saves over AJAX with X-editable. Works across the SQLAlchemy, MongoEngine, and Peewee backends, and posts a CSRF token with each edit.
The messy part was the data handling. My first attempt rendered a form field for every row and tried to process the whole page as a WTForms FieldList. That got out of hand fast. What worked was wrapping each field on its own and reusing the existing update_model method to save, so validation and the record-not-found case were already handled. That fix came out of the code review on the PR.
Update: this one stuck around, and I ended up maintaining it for a while afterward: an XSS fix to HTML-escape the editable values (#1002), nullable enums and blank selects (#1009), and eventually a rewrite that builds a form per input (#1160, #1162). A bunch of smaller ones in between too. column_editable_list is still in Flask-Admin.
I installed openmanage with the instructions on this page and used it to check/update bios settings: Dell OpenManage (OMSA 7.1) apt repo
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:
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): Dell community forum: similar disk performance issue
Update 3/1/2015:
Saw an interesting checklist on Hacker News today that also mentioned disabling BIOS power saving settings: http://odetodata.com/2015/02/installation-and-configuration-checklist-for-microsoft-sql-server/
Problem: You see MegaCli64 or MegaCli only showing “Exit Code: 0x00” when you try to run commands.
Solution: Try running as sudo.
If you need to change Putty’s defaults, press “Load” on the saved session for “Default Settings”, make your changes, and “Save”.
This is my favorite boilerplate for new projects so far: https://github.com/kirpit/django-sample-app
Because:
If you’re not a fan of bootstrap, django-html5-boilerplate also looks good.
http://stackoverflow.com/a/27424739/1364191
It’s definitely a common mistake for people using WTForms. When you create a form and use something like datetime.date.today() as a default value, that value will always stay the same. The fix is to use “datetime.date.today” instead of datetime.date.today().