infra-openafs-deb/debian/openafs-fileserver.NEWS

openafs (1.8.0~pre4-1) unstable; urgency=low

  * Servers no longer use rxkad.keytab for long-term keys, which are
    now stored in KeyFileExt.  Administrators must use akeyconvert
    or similar tooling to populate the KeyFileExt.  In most cases,
    `akeyconvert` with no arguments will suffice, and krb5 keys
    can still be managed (and periodically updated) in the rxkad.keytab.
    `akeyconvert` is run automatically in the post-install script.
  * Server log handling has changed.  Logs are not truncated at
    startup by default, and are re-opened on SIGUSR1, to be compatible
    with external log rotation tools.

 -- Benjamin Kaduk <kaduk@mit.edu>  Tue, 13 Dec 2016 01:49:46 -0500

openafs (1.6.5-1) unstable; urgency=high

  The DES keys used by all previous versions of OpenAFS are not
  sufficiently strong to be secure.  As of this release, all OpenAFS
  servers support using stronger long-term keys than DES.  All sites are
  strongly encouraged to rekey their AFS cells after deploying the new
  version of the AFS server software on all AFS file server and AFS
  database server machines.

  To do so, generate a new set of keys for the afs/<cell> principal for
  your site and store those keys in /etc/openafs/server/rxkad.keytab on
  all file server and database server machines and then restart the server
  processes to upgrade the strength of server-to-server connections.
  After all existing AFS tokens have expired, you can then move the
  KeyFile aside, which will invalidate all old, existing DES tokens.

  If you are using Heimdal as your Kerberos KDC, you need to ensure that
  the afs/<cell> key includes a des-cbc-crc enctype (to allow for session
  keys), but you should remove all DES keys from the keytab before
  deploying it as rxkad.keytab.

  These are only abbreviated instructions and don't include some relevant
  details.  If possible, please study and follow the more comprehensive
  instructions available at:

      http://www.openafs.org/pages/security/install-rxkad-k5-1.6.txt
      http://www.openafs.org/pages/security/how-to-rekey.txt

  linked from <http://www.openafs.org/security/>.

 -- Russ Allbery <rra@debian.org>  Wed, 24 Jul 2013 12:08:46 -0700

openafs (1.5.77-1) experimental; urgency=low

  This version of the OpenAFS file server includes a version built with
  demand-attach, but as binaries with a different name.

  Demand-attach completely changes how the file server shuts down and
  starts up.  Instead of detaching all volumes on shutdown and reattaching
  them on startup, the file server saves state to disk and restores state
  when starting, enabling it to start far faster.  Volumes are only
  attached when used and are detached again if they go unused for an
  extended period.  Volumes can also be salvaged on demand.

  Demand-attach is recommended for new deployments and for evaluation in
  current production deployments, but requires a change to your bos
  configuration to use.  If you want to switch your file server to
  demand-attach, run:

      bos status localhost -instance fs -long

  and take note of the flags that you're using with the fileserver and
  volserver.  Then, run:

      bos stop localhost fs -localauth
      bos delete localhost fs -localauth
      bos create localhost dafs dafs \
          "/usr/lib/openafs/dafileserver <fileserver-flags>" \
          "/usr/lib/openafs/davolserver <volserver-flags>" \
          /usr/lib/openafs/salvageserver /usr/lib/openafs/dasalvager

  to create the correct new BosConfig entry for demand-attach AFS.

  If you were running an earlier version of the experimental
  openafs-filserver package, the way that demand-attach was handled has
  changed and you have to change your bos configuration to use the new
  demand-attach binary names.  Run:

      bos stop localhost dafs -localauth
      bos delete localhost dafs -localauth

  and then run the bos create command above.  This only applies to users
  of the previous experimental packages, not to upgrades from unstable.

 -- Russ Allbery <rra@debian.org>  Tue, 21 Sep 2010 14:08:04 -0700

openafs (1.5.73.3-1) experimental; urgency=low

  As of this release, the default permissions for /etc/openafs/server are
  now 0755, matching upstream.  The only file in that directory that needs
  to be kept secure is KeyFile, which is created with 0600 permissions.
  The directory permissions won't be changed on upgrade, so bosserver will
  complain now that it is no longer patched to permit restrictive
  permissions.  Once you're certain the per-file permissions of all files
  in that directory are safe, chmod 755 /etc/openafs/server to make
  bosserver happy.

 -- Russ Allbery <rra@debian.org>  Tue, 06 Apr 2010 14:51:52 -0700

openafs (1.4.4.dfsg1-4) unstable; urgency=low

  The files previously located in /etc/openafs/server-local have been
  moved to /var/lib/openafs/local.  The OpenAFS fileserver and bosserver
  write files to this directory on startup which are not configuration
  files and therefore, per the File Hierarchy Standard, should not be in
  /etc.  Any sysid, sysid.old, NetInfo, and NetRestrict files in
  /etc/openafs/server-local have been copied to /var/lib/openafs/local.

  upserver and upclient have moved to /usr/lib/openafs (from /usr/sbin) to
  match the other programs intended to be run by the bosserver and to
  match upstream's layout.  If you're running upserver or upclient from
  bosserver, BosConfig has been updated with the new path, but the
  services have not been restarted.

  At your convenience, you should restart your servers with:

      bos restart -all -bosserver

  so that the running servers will look at the new locations.  After doing
  so, you may remove /etc/openafs/server-local if you wish.

 -- Russ Allbery <rra@debian.org>  Tue, 19 Jun 2007 03:51:58 -0700