drupal5, images and private file systems – a match made in ….

Ok,  It wasn’t a lot of pain, but it was a tad annoying nonetheless.

The story begins with using Drupal 5 for a private website (Note: I actually think these later releases of Drupal are pretty good – it’s pretty easy to create themes and the feature set is pretty rich).  Since the data that was being uploaded needed access controls I set Adminster/File System/Download Method to private.   Sounds Good so far.

Since I wanted to have some nodes containing uploaded image data, which I wanted to have ACLs protecting I installed the ACL/Content_Access modules and the Image module.  I set the ACLs on the nodes as appropriate for me – nothing for Anonymous and view for Authenticated users.

Bugger – didn’t work.  According to the logs I was getting 403’s via the module performing the private downloads.  This wasn’t good.  So after a great deal of Ineffective Googling (now known as IG) I decided to read the code.

After scratching my head for a little while I started to make sense of the code.  The problem was that in addition to the ACL settings on the Image nodes I also needed to have view_original_file and view_uploaded_files permissions set for my Authenticated Role.  Once I set that everything started working as I expected and sanity was restored.

Hopefully this little blog entry will end some drupal induced suffering for someone else.


openssh crypto cipher performance

It was mentioned to me that when transferring files on an internal network that by selecting a different cryptographic cipher you could improve the file transfer performance.  So, since I had a few spare minutes and elected not to scratch my bum I whipped up the following little script to test the theory.

I elected to scp a random ~700Mb file I affectionately called disc1.iso  (it was actually just random data, but you get the idea) to my localhost.  That is, I transferred the file from system A to system A.   I’m not interested in getting the highest possible speed with this test, i’m more interested in the relative performance of the ciphers.   Doing this creates a ‘relatively’ stable environment to conduct the comparisons.

I added my ssh key to allow myself to talk to myself – sort of like this blog really with the number of readers I have 🙂  Then I did the following (a man ssh shows the valid ciphers for protocol 2)

for c in 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr \
         arcfour128 arcfour256 arcfour blowfish-cbc cast128-cbc ; \
         do for j in `seq 1 1`  ; \
          do /usr/bin/time -a -o results.txt -f "$c,$j,%E,%U,%S" scp -c $c disc1.iso localhost:tmp/ ;\
          done  ; \
         done &

This creates a results file which in my case looks like this :


Now, according to the man page aes128-cbc is the default cipher for Protocol version 2 so if I use this as the baseline then the relative performance becomes  :

Cipher Relative Performance
3des-cbc 0.77
aes128-cbc 1.00
aes192-cbc 1.03
aes256-cbc 1.01
aes128-ctr 0.94
aes192-ctr 0.87
aes256-ctr 0.92
arcfour128 0.97
arcfour256 0.72
arcfour 0.95
blowfish-cbc 0.92
cast128-cbc 0.65

Based on those numbers I really wouldn’t bother trying to select a different cipher for the file transfer.

Note 1: This was performed on a run of the mill core 2 duo system running Ubuntu Hardy, you will possibly find that certain architectures have better results with certain ciphers possibly due to the instruction set being a better fit for a certain algorithm or in the case of higher end servers the availability and use of cryptographic hardware.

Note 2:  The seq 1 1 allows you to run the test multiple times, just change it to seq 1 10 to run each test 10 times.  I just did it once for the purposes of putting it in the blog.