Monday, August 28, 2017

Solaris 10 - fiocompress (UFS file compression) settings

Bernd Schemmer has an interesting post about using fiocompress for file-system level compression of individual files on UFS file systems...

I did some experimentation and found a few more things:

  • Increasing the blocksize from the default of 8192 increases the compression ratio
  • The compression ratio seems to be somewhere between gzip and compress (on a text file)
  • Setting the blocksize to 65536 (64KiB) results in an unreadable and undeletable file (at least with normal tools on test system. This is fixed in the latest recommended patch bundle)
  • Using blocksizes below 8192 also results in unusable files. (I only tested multiples of 2)(This is fixed in the latest recommended patch bundle)
  • fiocompress uses an ioctl call to mark a file as compressed if -m is passed. No method to unmark a marked file exists, even in the filesystem driver. (It is possible to modify the OpenSolaris fiocompress to add an option to just mark (a previously compressed) file as compressed) (Look at ufs_vnops.c for the _FIO_COMPRESSED ioctl implementation)

Test compression code:
ls -lah testfile.txt; du testfile.txt; du -h testfile.txt; for b in 256 512 1024 2048 4096 8192 16384 32768 65536; do fiocompress -b $b -c -m testfile.txt testfile.txt$b; done

Results: (including other common formats)
$ls -lah testfile.txt*
testfile.txt1024: Operation not applicable
testfile.txt2048: Operation not applicable
testfile.txt256: Operation not applicable
testfile.txt4096: Operation not applicable
testfile.txt512: Operation not applicable
testfile.txt65536: Operation not applicable
-rw-r--r--   1 user   group      101M Mar 11 10:26 testfile.txt
-rw-------   1 user   group      4.4M Mar 11 10:29 testfile.txt.7z
-rw-r--r--   1 user   group      5.2M Mar 11 10:26 testfile.txt.bz2
-rw-r--r--   1 user   group      7.2M Mar 11 10:28 testfile.txt.gzip
-rw-r--r--   1 user   group      8.9M Mar 11 10:28 testfile.txt.gzip-1
-rw-r--r--   1 user   group      6.7M Mar 11 10:28 testfile.txt.gzip-9
-rw-r--r--   1 user   group       13M Mar 11 10:27 testfile.txt.Z
-rw-r--r--   1 user   group      7.2M Mar 11 10:32
-rw-r--r--   1 user   group      101M Mar 11 10:55 testfile.txt16384
-rw-r--r--   1 user   group      101M Mar 11 10:55 testfile.txt32768
-rw-r--r--   1 user   group      101M Mar 11 10:55 testfile.txt8192

$du testfile.txt*
206544  testfile.txt
9040    testfile.txt.7z
10624   testfile.txt.bz2
14848   testfile.txt.gzip
18240   testfile.txt.gzip-1
13840   testfile.txt.gzip-9
27632   testfile.txt.Z
18784   testfile.txt16384
16480   testfile.txt32768
22656   testfile.txt8192
$du -h testfile.txt*
 101M   testfile.txt
 4.4M   testfile.txt.7z
 5.2M   testfile.txt.bz2
 7.2M   testfile.txt.gzip
 8.9M   testfile.txt.gzip-1
 6.8M   testfile.txt.gzip-9
  13M   testfile.txt.Z
 9.2M   testfile.txt16384
 8.0M   testfile.txt32768
  11M   testfile.txt8192

eFiling and eHomeAffairs in Chrome

Google bundles Flash with Chorme (making it the only option for some things on GNU/Linux), however they have recently started phasing out Flash. As part of that, Chrome hides the presence of Flash to websites, but gives users an option to enable Flash on the site if the page attempts to use Flash. eHomeAffairs and SARS eFiling gives an error when Flash is not detected and doesn't attempt to load the content anyway, which means that the "Click to run" option does not work.

Recommeneded method: MyBroadband documented one method to get eFiling working.. For eHomeAffairs, the address to add to the list is "".

Alternative, works on many more sites: Another option is to configure Chrome not to hide Flash from websites. This can be done by visiting "chrome://flags" in the address bar and setting the "Prefer HTML5 over Flash" setting to "Disabled" ("chrome://flags/#prefer-html-over-flash" will take you directly to the setting). You need to restart Chrome for the setting to take effect. The content will then load. (Tested on Chrome 60). On some sites, the Flash content may still be click-to-run, however Chrome seems to currently run it automatically on both eHomeAffairs and SARS eFiling when this flag is set. (Chrome will attempt to detect important Flash content and enable that automatically)

Friday, February 24, 2017

OpenSSL cipher suite without forward secrecy

Firstly, you should not use this in normal use.

Sometimes, you might need to debug a problem that occurs behind TLS.

Wireshark can decode TLS traffic, given the session keys, or if forward secrecy ciphers was not used, the private key.

In the case of web traffic, SSLKEYLOGFILE can tell NSS, used by some browsers to log the keys. This is a better method than the one described here, but it is not an option if other clients are used, say in the case of SMTP.

An (OpenSSL) ciphersuite setting that excludes ciphers providing forward secrecy, while keeping strong ciphers is:

This should be avoided in production and should only be used for debugging.