anchor.diff:  
   [source,shell]
   ------------------------------------------------------------------------
  -db@host:~$ sudo grr_config_updater upload_memory_driver --file=/path/to/my_special_pmem.kext.tgz --platform=windows  --arch amd64 --dest aff4:/config/drivers/osx/memory/pmem
  +db@host:~$ sudo grr_config_updater upload_memory_driver --file=/path/to/my_special_pmem.kext.tgz --platform=windows --arch amd64 --dest aff4:/config/drivers/osx/memory/pmem
   ------------------------------------------------------------------------
   
   If you need to customize some property of the driver you can easily inject configuration parameters into the above command line (this _must_ be done before the `upload_memory_driver` command). For example, if you recompiled the driver to present a different device name on the client:
  
positive.code: Authentication to the Admin UI.
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  The AdminUI uses basic authentication by default, based on
  the passwords within the user objects stored in the data store, but we _don't expect you to use this in production_. There is so much diversity and customization in enterprise authentication shemes that there isn't a good way to provide a solution that works for a majority of users. But you probably already have internal webapps that use authentication, this is just one more. Most people have found the easiest approach is to sit Apache (or similar) in front of the GRR Admin UI as a reverse proxy and use an existing SSO plugin that already works for that platform. Alternatively, with more work you can handle auth inside GRR by writing a Webauth Manager (AdminUI.webauth_manager config option) that uses an SSO or SAML based authentication mechanism.
  
  
  Security Considerations
  
negative.code: -------------------------
  
  Get a GRR server installed and running in a few minutes with the
  link:quickstart.adoc[quickstart install]. With more effort you can also
  link:installfromsource.adoc[install from source].
  
  Key Management
  