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 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/ 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/ 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 . -- Russ Allbery 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 " \ "/usr/lib/openafs/davolserver " \ /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 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 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 Tue, 19 Jun 2007 03:51:58 -0700