https://k5wiki.kerberos.org/w/api.php?action=feedcontributions&user=TomYu&feedformat=atomK5Wiki - User contributions [en]2024-03-19T03:26:08ZUser contributionsMediaWiki 1.27.4https://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5778Ops feedback teleconference2017-03-06T21:31:28Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2017-03-07 ===<br />
<br />
* Patch releases (krb5-1.15.1, krb5-1.14.5)<br />
* SHA-1 collision attack response<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Continuous_integration&diff=5745Continuous integration2017-02-23T22:44:19Z<p>TomYu: </p>
<hr />
<div>[[Category:Infrastructure]]<br />
<br />
Our continuous integration infrastructure includes Buildbot, Travis CI, AppVeyor, and a nightly cron job.<br />
<br />
==Buildbot==<br />
<br />
http://krbdev.mit.edu/buildbot/<br />
<br />
Automatically builds and tests master and active release branches on every push (with a 5-minute stability timer). Doesn't currently build pull requests. Periodically does a Coverity Scan build.<br />
<br />
==Travis CI==<br />
<br />
https://travis-ci.org/krb5/krb5<br />
<br />
Builds and tests all active branches and pull requests. Use <code>[ci skip]</code> in a commit message to request that Travis skip that commit.<br />
<br />
==AppVeyor==<br />
<br />
https://ci.appveyor.com/project/krb5/krb5<br />
<br />
Build and tests all active branches and pull requests under Windows.<br />
<br />
==Nightly builds==<br />
<br />
http://web.mit.edu/krbdev/testing/README.txt<br />
<br />
We run a nightly cron job on two machines (one Linux, one Solaris) which builds a snapshot and reports success or failure. We now have a Solaris buildbot worker, so we can probably decommission the nightly build infrastructure.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5744Ops feedback teleconference2017-02-06T21:59:37Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2017-02-07 ===<br />
<br />
* What needs to happen before we can disable service principal DNS canonicalization by default?<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5743Ops feedback teleconference2017-02-06T21:58:01Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2017-02-14 ===<br />
<br />
* What needs to happen before we can disable service principal DNS canonicalization by default?<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Solaris_Build_Environment&diff=5740Solaris Build Environment2017-01-24T22:08:33Z<p>TomYu: </p>
<hr />
<div>This page contains notes on the setup of a Solaris buildbot worker for MIT krb5.<br />
<br />
Our current Solaris build hardware is a Sun Fire V240 running Solaris 10 U10.<br />
<br />
Solaris 10 includes a variety of free software tools in /usr/sfw, but not the full set of dependencies needed to checkout, build, and test the krb5 tree. We have chosen to use [https://opencsw.org/ OpenCSW] to add most of the dependencies, and local builds in /usr/local for the remaining few.<br />
<br />
==Set up a useful shell==<br />
<br />
A root login by default uses a very minimal shell (/bin/sh) with a very minimal path (/usr/sbin:/usr/bin). For any operations performed as root, we begin by starting a functional shell as follows:<br />
<br />
bash<br />
export PATH=/opt/csw/bin:/usr/sbin:/usr/bin:/usr/sfw/bin:/usr/ccs/bin<br />
export MANPATH=/opt/csw/share/man:/usr/share/man:/usr/sfw/share/man<br />
<br />
For now, we are not modifying /etc/passwd or root's dotfiles to make this happen automatically.<br />
<br />
==Set up OpenCSW==<br />
<br />
Installing the pkgutil command (it will be placed in /opt/csw/bin) and update its catalog as follows:<br />
<br />
pkgadd -d http://get.opencsw.org/now<br />
pkgutil -U<br />
<br />
"pkgutil -l" lists installed packages. "pkgutil -a string" looks up string in the catalog. "pkgutil -i packagename" installs a package; the -y flag can be used to skip prompts. "pkgutil -U" followed by "pkgutil -yu" updates all installed packages.<br />
<br />
==Install required OpenCSW packages==<br />
<br />
pkgutil -y -i git<br />
pkgutil -y -i libssl_dev<br />
mkdir /opt/csw/sbin/sparcv9 # to work around an apparent bug in openldap package<br />
pkgutil -y -i openldap<br />
pkgutil -y -i openldap_back_bdb<br />
pkgutil -y -i openldap_client<br />
pkgutil -y -i openldap_dev<br />
pkgutil -y -i autoconf<br />
pkgutil -y -i tcl<br />
pkgutil -y -i tcl_dev<br />
pkgutil -y -i expect<br />
pkgutil -y -i bind_utils<br />
pkgutil -y -i bison<br />
pkgutil -y -i python27<br />
pkgutil -y -i buildbot_slave<br />
pkgutil -y -i emacs<br />
pkgutil -y -i gdb<br />
edit /etc/passwd and change the home directory of "games" to /<br />
<br />
We have decided not to support the Solaris 10 native LDAP library and tools (Solaris 11 ships with OpenLDAP and Solaris 12 will make it the default), so we install OpenLDAP from OpenCSW. OpenSSL 0.9 is present in /usr/sfw/lib, but we need 1.0 or later for PKINIT so we install the OpenCSW version. The bison in /usr/sfw/bin is also too old for our x-deltat.y file. buildbot_slave requires Python 2.7 but does not list it as a formal dependency. emacs and gdb are not needed to build krb5, but are handy to have around for manual testing and debugging work.<br />
<br />
buildbot 0.9 changes its terminology to refer to "workers" rather than "slaves". At the time of this writing, OpenCSW only includes buildbot 0.8.4; when it switches to buildbot 0.9, the package we need will likely change to buildbot_worker.<br />
<br />
One of the above packages appears to create a "games" account with the home directory set to /opt/csw. This would ordinarily allow ssh access by the Kerberos principal games@ATHENA.MIT.EDU. We change the home directory of this account to / so that /.k5login governs access.<br />
<br />
==Local builds of remaining dependencies==<br />
<br />
dejagnu is not present in OpenCSW, so we need to build it ourselves:<br />
<br />
mkdir /usr/local /usr/local/src<br />
From https://ftp.gnu.org/gnu/dejagnu/ fetch the latest dejagnu; untar it in /usr/local/src<br />
chown -R root:root /usr/local/src/dejagnu-''version''<br />
cd /usr/local/src/dejagnu-''version''<br />
./configure && gmake install<br />
<br />
==Set up buildbot==<br />
<br />
Create and switch to the buildbot account:<br />
<br />
useradd -d /var/lib/buildbot -u 101 -s /bin/bash -m buildbot<br />
su - buildbot<br />
touch .k5login<br />
edit .profile and add:<br />
PATH=/usr/local/bin:/opt/csw/bin:/usr/bin:/usr/sfw/bin:/usr/ccs/bin<br />
MANPATH=/usr/local/share/man:/opt/csw/share/man:/usr/share/man:/usr/sfw/share/man<br />
USER=buildbot<br />
export PATH MANPATH USER<br />
<br />
Principals may be added to .k5login, but make sure it exists so that the Kerberos principal "buildbot" does not have access to the account.<br />
<br />
Set up ssh for the ssh tunnel to krbdev.mit.edu:<br />
<br />
mkdir .ssh<br />
ssh-keygen -q -N <nowiki>''</nowiki> -f .ssh/id_rsa -t rsa<br />
cat .ssh/id_rsa.pub<br />
In a separate shell, log into krbdev.mit.edu, "su -s /bin/bash - buildbot" and add the contents of id_rsa.pub to .ssh/authorized_keys<br />
Edit .ssh/known_hosts (new file) and add:<br />
krbdev.mit.edu,18.9.62.43 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAmV2SWbD5nZah7F0nhzEpBtmdiNa38TTDx58i/HhENlT3yV4xpwyHcqBSObUR+wQlW+LfBRgyGeXEZAoiEMG4kQk93P+JKEsK5G/X9QF2LICsoMSZKW31S1K4axqtlhesFnnlXzZZkWQhYhG3He8DXBBw+2AMWR6jfTnM634fGpl5Vo76r7QuxL09RpnSEZyihR/6n8IG8EaAyX4Rbj23pkLlj6DjfWoYd1CmjN+JKiZ9q/yXHQMW+/yMo+JhmAPwgBVjQkc/pDfVFffavWzRPJ39ZUbRRNBSHU0lweXLcCIq6K4P+Mvt/WKwsFNxASNOOmkbWVDfNflT8L1maFCr7w==<br />
<br />
Create the slave directory:<br />
<br />
mkdir slaves<br />
buildslave create-slave /var/lib/buildbot/slaves/s01 127.0.0.1:9989 s01 ''password''<br />
<br />
where ''password'' should match the entry for s01 in slaves.py on krbdev.mit.edu.<br />
<br />
As root, create /etc/init.d/buildslave with the contents:<br />
<br />
#!/sbin/sh<br />
case "$1" in<br />
start)<br />
su buildbot -c 'ssh -l buildbot -N -L9989:127.0.0.1:9989 krbdev.mit.edu &'<br />
su - buildbot -c 'buildslave start --quiet /var/lib/buildbot/slaves/s01'<br />
;;<br />
stop)<br />
su buildbot -c '/opt/csw/bin/buildslave stop --quiet /var/lib/buildbot/slaves/s01'<br />
;;<br />
esac<br />
exit 0<br />
<br />
Make it executable with "chmod u+x /etc/init.d/buildslave". Create the following links:<br />
<br />
ln -s /etc/init.d/buildslave /etc/rc2.d/S99buildslave<br />
ln -s /etc/init.d/buildslave /etc/rc2.d/K00buildslave<br />
<br />
We do not currently stop the ssh tunnel automatically, because it isn't easy to do. The ssh tunnel must be manually restarted if it breaks; on other workers, we use a cron job which runs "ssh -oExitOnForwardFailure=yes ...", but the Solaris 10 ssh does not support that option. The start rule will display an unwanted copy of /etc/motd; an alternative would be to explicitly set the path when running buildbot, instead of relying on buildbot's .profile.<br />
<br />
==Create user accounts==<br />
<br />
By default, /home on Solaris is controlled by the automounter. To avoid needing to change the automounter configuration, we create user accounts with home directories in /export/home. For example:<br />
<br />
useradd -u 3622 -d /export/home/ghudson -s /bin/bash -m ghudson<br />
<br />
Creating an account allows the Kerberos principal of the same name in the ATHENA.MIT.EDU realm to log in on that account. Matching the local UID to the Moira UID may be unnecessary as long as we do not make use of remote filesystems on this machine.<br />
<br />
To set a reasonable path for development work, the user can edit .profile to add:<br />
<br />
PATH=/usr/local/bin:/opt/csw/bin:/usr/bin:/usr/sfw/bin:/usr/ccs/bin<br />
MANPATH=/usr/local/share/man:/opt/csw/share/man:/usr/share/man:/usr/sfw/share/man<br />
export PATH MANPATH<br />
<br />
The following shell function, or a variant of it, may be useful for configuring a build with the correct paths. This variant is designed to work in a separate build directory placed next to the src directory within a checkout.<br />
<br />
k5configure() { ../src/configure --enable-maintainer-mode --prefix=$HOME/inst --with-ldap CFLAGS=-g CPPFLAGS="-I/opt/csw/include" LDFLAGS="-L/opt/csw/lib -R/opt/csw/lib" "$@"; }<br />
<br />
==To do==<br />
<br />
* We should install the SunPro compiler and do automated builds with that compiler as well as gcc.<br />
<br />
==Hardware notes==<br />
<br />
The 8-pin modular serial connector for console/ALOM takes a shielded UTP cable. (The shielding probably isn't too important except for EMI reasons.) The modular to female DE-9 adapter is wired as a RS-232 DCE so it will plug directly into most USB to DE-9 RS-232 adapters. (The modular to male DB-25 adapter seems to be wired as a DTE and might need a null modem.)</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Roadmap&diff=5734Roadmap2017-01-03T22:06:45Z<p>TomYu: /* Current roadmap items */ Trello is more up to date than JIRA</p>
<hr />
<div>This is the outline of the '''development roadmap''' for MIT Kerberos. A more comprehensive [[Projects | list of projects]] is also available; some individual projects have links below.<br />
<br />
== Timeline ==<br />
<br />
Target 12 month cycle. (plus/minus 2 months)<br />
<br />
Releases will have a 2-year maintenance lifetime, subject to changes based on community input.<br />
<br />
; [[Release_1.8|krb5-1.8]]<br />
: Branch Jan. 2009<br />
: Release early Mar. 2010<br />
<br />
; [[Release_1.9|krb5-1.9]]<br />
: Branch Oct. 2010<br />
: Release Dec. 2010<br />
<br />
; [[Release_1.10|krb5-1.10]]<br />
: Branch Oct. 2011<br />
: Release Dec. 2011<br />
<br />
; [[Release_1.11|krb5-1.11]]<br />
: Branch Oct. 2012<br />
: Release Dec. 2012<br />
<br />
; [[Release_1.12|krb5-1.12]]<br />
: Branch Oct. 2013<br />
: Release Dec. 2013<br />
<br />
; [[Release_1.13|krb5-1.13]]<br />
: Branch Aug. 2014<br />
: Release Oct. 2014<br />
<br />
; [[Release_1.14|krb5-1.14]]<br />
: Branch Sep. 2015<br />
: Release Nov. 2015<br />
<br />
; [[Release_1.15|krb5-1.15]]<br />
: Branch Aug. 2016<br />
: Release Oct. 2016<br />
<br />
== Guiding principles ==<br />
<br />
* Code quality<br />
* Developer experience (including modularity)<br />
* End-user experience<br />
* Administrator experience<br />
* Performance<br />
* Protocol evolution<br />
<br />
== Current roadmap items ==<br />
<br />
This list will probably eventually be superseded by the [https://trello.com/b/maBtyclL/krbdev Trello board] (still migrating issues from the [https://ist-jira.atlassian.net/issues/?filter=16402 KRB JIRA backlog]). <br />
Target releases for roadmap items are subject to change.<br />
<br />
=== krb5-1.15 ===<br />
<br />
* [[Projects/SPAKE_Preauthentication]]<br />
* [[Projects/Reporting-friendly KDB dump format improvements]]<br />
* [[Projects/NAPTR|URI discovery for KDC HTTP proxy]]<br />
* Query to efficiently report when a principal is locked out due to password failures<br />
<br />
=== krb5-1.16 ===<br />
<br />
* Forward secrecy for AP-REQ/AP-REP exchange<br />
* [[Projects/Graceful_recovery_after_destructive_service_rekey]]<br />
<br />
== Long-term roadmap items ==<br />
<br />
=== Code quality ===<br />
<br />
* Move toward test-driven development<br />
* Increase conformance to coding style<br />
** Selective refactoring<br />
** Continue formatting cleanup<br />
* Use cyclomatic complexity metrics to identify cleanup targets<br />
<br />
=== Developer experience ===<br />
<br />
* Crypto modularity -- make sure PKCS#11 etc. work well<br />
* API documentation<br />
* Support readily building subsets<br />
** "Lite" client<br />
** "Lite" server<br />
* KDC Database modularity (long-term)<br />
** SQLite back end<br />
** Does the existing DAL make sense?<br />
** Make data model less "blobby"<br />
** Track IETF data model work<br />
* [[Projects/Plugin support improvements | Plugin support improvements]]<br />
** GSS-API mechanism glue<br />
** DNS / host-to-realm mapping<br />
* Secure co-processor ("would be nice")<br />
* GSS proxy<br />
* interposition capability for GSS mechs (useful for GSS proxy) -- external for 1.11<br />
* Use default keytab for gss_init_sec_context<br />
* gss_export_cred (useful for async GSS proxy)<br />
* Improve ASN.1 support code (better support for plugins that need to encode/decode their own ASN.1 types)<br />
<br />
=== End-user experience ===<br />
<br />
* Improve credential management<br />
<br />
=== Administrator Experience ===<br />
<br />
* Plugin for kadmin authorizations<br />
* Move more realm-global configuration into KDB<br />
* Add interface to purge old keys (1.8 patch?)<br />
* Add interface to delete keys of specific enctypes (1.8 patch?)<br />
* Disable enctypes at compile time (1.8 patch?)<br />
* Improve IPv6 support<br />
* Improve key rollover<br />
** Application service keys<br />
* Decrease DNS-related fragility<br />
* Plugins for login failure lockout<br />
* Plugins for audit support<br />
* Plugins for ticket issuance access control<br />
* Plugins for domain-realm mapping<br />
* Friendlier smart card support<br />
* FAST OTP client in libkrb5 (maybe excluding second-level plugins hardware OTP tokens)<br />
* Multiple logging levels for trace logging<br />
<br />
=== Performance ===<br />
<br />
* Decrease DNS traffic<br />
* Client resolution of KDC (etc.) addresses can be very slow. Decouple address resolution from initiation of KDC communications. (requires some redesign of internal interfaces)<br />
* Replay cache ("rcache")<br />
** Improve implementation<br />
** Support disabling by service type name<br />
* Enhancements to improve concurrency<br />
** Explicit state<br />
** Reduce mutex contention<br />
** Support asynchronous APIs and frameworks such as Apple's Grand Central Dispatch; begin refactoring code to make this easier<br />
<br />
=== Protocol evolution ===<br />
<br />
* International strings in protocol (need IETF feedback)<br />
** Principal names<br />
** Error strings, etc. (need language tag negotiation)<br />
* Timestamp-independence<br />
* Replay-proofing protocols<br />
* Encryption algorithm updates (SHA-2, SHA-3, CCM, GCM)<br />
* PKU2U<br />
* One time password support<br />
* Multiply-authenticated authorization data container<br />
* POSIX IDs in authorization data<br />
* Level of Assurance in authorization data<br />
* Site-defined string-keyed claims in authorization data<br />
* X.509 attributes in authorization data<br />
* FAST preauth sets (e.g. OTP + long-term password)<br />
<br />
== Completed roadmap items ==<br />
<br />
See [[Roadmap (completed items)]].</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Main_Page&diff=5733Main Page2017-01-03T22:02:24Z<p>TomYu: bump current release</p>
<hr />
<div>__NOTOC__<br />
'''K5Wiki''' is a wiki supporting the development of [[MIT Kerberos]], a reference implementation of [[wp:Kerberos (protocol)|the Kerberos network authentication protocol]].<br />
<br />
This wiki serves both as a place for coordination of development efforts on MIT Kerberos and as a means for potential contributors and other interested people to become more involved with MIT Kerberos development. This wiki does not focus on the needs for the average end user, but it may nevertheless contain information that is useful to advanced users, such as system administrators who wish to make customizations.<br />
<br />
What can this wiki do for you?<br />
* I have a [[Asking questions|question]]<br />
* I want to [[Writing applications|write Kerberos application software]]<br />
* I want to [[Reporting bugs|report bugs]]<br />
* I want to [[Fixing bugs|fix bugs]]<br />
* I want to [[Learning about the code|learn more about the code]]<br />
* I have [[Suggesting enhancements|ideas for enhancements]]<br />
* I want to [[Contributing code|contribute code]]<br />
* I want to [[K5Wiki:Todo|help to improve this wiki]]<br />
<br />
== Releases ==<br />
<br />
The current release is [http://web.mit.edu/kerberos/krb5-latest/ krb5-1.15].<br />
<br />
* [[Release 1.15 | Release 1.15 goals]]<br />
<br />
Additional information on future releases:<br />
<br />
* Development [[roadmap]]<br />
<br />
== Users ==<br />
<br />
We recommend that end users use MIT Kerberos software packages built by their operating system vendor if possible, and use support resources provided by their site or by their vendor. For those users (typically system administrators) who have a need to build MIT Kerberos from source code, we have some resources available on this wiki.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[user resources]]<br />
<br />
== System administrators ==<br />
<br />
We also recommend that most system administrators use MIT Kerberos software packages from their operating system vendor if possible.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* [[IPv6]] support status<br />
* Monthly [[ops feedback teleconference]]<br />
* More [[sysadmin resources]]<br />
<br />
== Developers ==<br />
<br />
Developers can include end users who have a need to customize the MIT Kerberos source code, or who would like to contribute patches for new features or for bug fixes.<br />
<br />
* [[Developer resources]]<br />
* [[Getting source code]]<br />
* [[Committer resources]] -- only really useful for people with commit access.<br />
<br />
=== Contributing ===<br />
<br />
* [[How to contribute]] to the MIT Kerberos software<br />
* [[Fixing bugs]]<br />
* [[Suggesting enhancements]]<br />
* [[Contributing code]]<br />
<br />
=== Background information ===<br />
<br />
* [[:Category:Policies|Policies for development]]<br />
* [[:Category:Lore|Lore]]<br />
<br />
=== Code quality ===<br />
<br />
* [[Coding style]]<br />
* [[Test-driven development]]<br />
* [[Manual_Testing|Manual testing procedures]]<br />
* [[Cleanups|Code cleanup opportunities]]<br />
<br />
=== Planning ===<br />
<br />
* Development [[roadmap]]<br />
* [[Projects]]<br />
<br />
=== Communication ===<br />
<br />
* [[Release_Meeting_Minutes|Release Meeting Minutes]]<br />
* [[Developer chat]]<br />
* [http://blog.kerberos.org/ Blog]<br />
<br />
== Additional information ==<br />
<br />
* [[K5Wiki:Todo|A todo list for work needing doing on this wiki]]<br />
* [[Application_Maintenance|Notes on maintenance of the krb5 telnet/rlogin/gssftp applications]]<br />
<br />
We look forward to your contributions to K5Wiki and MIT Kerberos.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5732Ops feedback teleconference2017-01-02T22:08:21Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2017-01-03 ===<br />
<br />
* Search path for default realm<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5725Ops feedback teleconference2016-12-05T23:22:18Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2016-12-06 ===<br />
<br />
* Feedback on strategic directions<br />
* [[Release 1.15|krb5-1.15]] Q&A<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5724Ops feedback teleconference2016-12-05T21:24:59Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2016-12-06 ===<br />
<br />
* Strategic directions<br />
* [[Release 1.15|krb5-1.15]] Q&A<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_engineering_notes&diff=5716Release engineering notes2016-12-02T21:57:33Z<p>TomYu: </p>
<hr />
<div>==Required manual steps==<br />
<br />
===Pre-mkrel===<br />
<br />
* check copyright years in project-wide stuff<br />
* update <code>config.guess</code> and <code>config.sub</code> from <code>git://git.savannah.gnu.org/config.git</code><br />
* make sure you're in a build tree that's not the source tree and configured using <code>--enable-maintainer-mode</code><br />
* <code>make depend</code> and commit if changed<br />
* regenerate manpages: <code>(cd man && make man)</code> and commit if changed<br />
* regenerate localization template <code>(cd po && make update-po)</code> and commit if changed<br />
* manually edit patchlevel.h to reflect the new release<br />
* manually update README<br />
** release dates (in major changes heading, ISO 8601 date format with hyphens)<br />
** changes<br />
*** note whether bugfix release, maintenance vs current release<br />
*** bullet list of major changes<br />
*** minor changes = list of RT tickets fixed -- always grab a fresh list from RT when editing these!<br />
** contributors (RT is a good source for these)<br />
* make additional manpage and update-po commits with updated patchlevel.h<br />
* squash preceding commits so all versioning-related commits are a single commit (non-versioning changes to maintainer-mode stuff should remain separate commits)<br />
* <code>git tag krb5-x.y.z-final</code><br />
<br />
===Running mkrel===<br />
<br />
* <code>path_to_mkrel/mkrel --repository $YOUR_SOURCE_TREE krb5-x.y.z-final krb5-x.y.z</code><br />
* manually inspect output for versioning and correctness<br />
** HTML docs<br />
** PDF docs<br />
** patchlevel.h as modified by mkrel<br />
* push to authoritative repository<br />
* rerun mkrel against the authoritative repository: <code>path_to_mkrel/mkrel krb5-x.y.z-final krb5-x.y.z</code><br />
<br />
===Post-mkrel===<br />
<br />
* PGP sign<br />
* generate branded HTML docs<br />
** <code>HTML_LOGO=.... make html</code><br />
** we don't ship the branded (with logo) docs because the logo is an MIT trademark<br />
* edit web pages<br />
* send announcement to kerberos-announce</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5668Ops feedback teleconference2016-10-31T15:35:32Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2016-11-01 ===<br />
<br />
* Future features feedback<br />
** Suggest 3 features or changes (in priority order) you'd like to see in a future release<br />
* [[Release 1.15|krb5-1.15]] Q&A<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_1.15&diff=5666Release 1.152016-10-07T21:15:17Z<p>TomYu: </p>
<hr />
<div>== Timeline ==<br />
<br />
This is only an approximate timeline. Dates are subject to change.<br />
<br />
* Jul. 2016 -- cutoff for submitting contributions for review<br />
* Aug. 2016 -- make release branch: feature integration freeze<br />
* Oct. 2016 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Clean up numerous compilation warnings<br />
<br />
== Developer experience ==<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* Allow extraction of current keys without change (requires a special kadmin permission), with the exception of highly protected keys<br />
* Restore recursive dump capability for DB2 back end<br />
* [[Projects/KDC Discovery]] DNS auto-discovery of HTTP proxy<br />
* Implement password history for LDAP back end<br />
* Implement principal renaming in LDAP back end<br />
<br />
== Performance ==<br />
<br />
== Protocol evolution ==<br />
<br />
* AES-SHA2 enctypes (Suite B crypto)</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5665Ops feedback teleconference2016-10-03T19:31:31Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2016-10-04 ===<br />
<br />
* [[Release 1.15|krb5-1.15]] Q&A<br />
* PKINIT with smart cards<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_1.15&diff=5664Release 1.152016-10-03T19:23:37Z<p>TomYu: </p>
<hr />
<div>== Timeline ==<br />
<br />
This is only an approximate timeline. Dates are subject to change.<br />
<br />
* Jul. 2016 -- cutoff for submitting contributions for review<br />
* Aug. 2016 -- make release branch: feature integration freeze<br />
* Oct. 2016 -- final release<br />
<br />
== Code quality ==<br />
<br />
* Clean up numerous compilation warnings<br />
<br />
== Developer experience ==<br />
<br />
== End-user experience ==<br />
<br />
== Administrator experience ==<br />
<br />
* Restore recursive dump capability for DB2 back end<br />
* [[Projects/KDC Discovery]] DNS auto-discovery of HTTP proxy<br />
* Implement password history for LDAP back end<br />
* Implement principal renaming in LDAP back end<br />
<br />
== Performance ==<br />
<br />
== Protocol evolution ==<br />
<br />
* AES-SHA2 enctypes (Suite B crypto)</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Category:Release_1.15_projects&diff=5663Category:Release 1.15 projects2016-10-03T19:13:52Z<p>TomYu: Created page with "Category:Completed projects"</p>
<hr />
<div>[[Category:Completed projects]]</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Projects/KDC_Discovery&diff=5662Projects/KDC Discovery2016-10-03T19:13:07Z<p>TomYu: </p>
<hr />
<div>{{project-rel|1.15}}<br />
<br />
This project will implement Kerberos service discovery by DNS as specified by {{idref|draft-mccallum-kitten-krb-service-discovery-02}}. The draft currently specifies a new URI DNS record type.<br />
<br />
The current method of KDC discovery using DNS SRV records has the following drawbacks:<br />
<br />
* Only UDP and TCP protocols can be specified<br />
* Multiple queries are needed to discover both protocol records<br />
* The DNS administrator has no influence on client protocol use<br />
<br />
==Design==<br />
<br />
The client performs a DNS lookup for one or more of the following URI records:<br />
* _kerberos-adm.REALM (Admin service)<br />
* _krb5kdc.REALM (KDC)<br />
* _kpasswd.REALM (Password service)<br />
<br />
The URI record includes a priority and weight, and contains a URI string of the krb5srv scheme name, flags, transport, and target (containing optional port and path) fields, separated by colons. <br />
<br />
* krb5srv:[flags]:transport:host[:port][/path]<br />
<br />
The priority and weight are as defined in RFC 2782. Weight may or may not be implemented, and priority must be implemented. On the initial KDC contact, all KDCs will be tried according to priority regardless of master status. On the fallback contact, master KDCs will be tried according to priority, excluding non-masters.<br />
<br />
The flags field contains zero or more flag characters. Currently the only valid character is M, indicating that the record is for a master server. On the initial contact, if a non-master KDC has answered and returns an error such as PREAUTH_FAILED, entries that are marked as master will be contacted.<br />
<br />
The transport field indicates the transport type for the given host address. It can be either "tcp", "udp", or "kkdcp" for MS-KKDCP.<br />
<br />
The host field in the udp and tcp transport cases can be a hostname, IPv4 address, or bracket-enclosed IPv6 address, and can be followed by a port extension. A host for the MS-KKDCP transport type uses a https:// URL, and can include a port and/or path extension. <br />
<br />
Discovery using this new method should be attempted before searching SRV records.<br />
<br />
==Examples==<br />
<br />
* _krb5kdc IN URI 10 1 <nowiki>"krb5srv:M:kkdcp:https://kdc.example.com/path"</nowiki><br />
* _krb5kdc IN URI 20 1 <nowiki>"krb5srv::kkdcp:https://kdc2.example.com"</nowiki><br />
* _kerberos-adm IN URI 10 1 "krb5srv::tcp:192.168.1.20:1333"<br />
<br />
==Implementation==<br />
<br />
src/lib/krb5/os/dnsglue.c: k5_try_realm_txt_rr() has existing TXT lookup code, but only retrieves a realm name from the record. Make a generalized TXT lookup function to pass the result to a new parsing function for the URI format. <br />
<br />
==Resources==<br />
<br />
* https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-02<br />
* http://mailman.mit.edu/pipermail/krbdev/2016-May/012588.html</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Downstream_statuses&diff=5661Downstream statuses2016-09-22T21:56:40Z<p>TomYu: Created page with "This page contains links to useful resources for checking on the status of downstream bugs, etc. for our software. ==Debian== * https://packages.qa.debian.org/k/krb5.html * ..."</p>
<hr />
<div>This page contains links to useful resources for checking on the status of downstream bugs, etc. for our software.<br />
<br />
==Debian==<br />
<br />
* https://packages.qa.debian.org/k/krb5.html<br />
* https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=krb5<br />
<br />
==Ubuntu==<br />
<br />
* https://launchpad.net/ubuntu/+source/krb5<br />
* https://bugs.launchpad.net/ubuntu/+source/krb5</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5660Ops feedback teleconference2016-09-05T20:17:52Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, as a Consortium activity, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2016-09-06 ===<br />
<br />
* There are no specific topics for this session, but feel free to suggest topics either before or during the call.<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_engineering_notes&diff=5659Release engineering notes2016-08-31T21:54:48Z<p>TomYu: </p>
<hr />
<div>==Required manual steps==<br />
<br />
===Pre-mkrel===<br />
<br />
* check copyright years in project-wide stuff<br />
* update <code>config.guess</code> and <code>config.sub</code> from <code>git://git.savannah.gnu.org/config.git</code><br />
* make sure you're in a build tree that's not the source tree and configured using <code>--enable-maintainer-mode</code><br />
* <code>make depend</code> and commit if changed<br />
* regenerate manpages: <code>(cd man && make man)</code> and commit if changed<br />
* regenerate localization template <code>(cd po && make update-po)</code> and commit if changed<br />
* manually edit patchlevel.h to reflect the new release<br />
* manually update README<br />
** release dates (in major changes heading, ISO 8601 date format with hyphens)<br />
** changes<br />
*** note whether bugfix release, maintenance vs current release<br />
*** bullet list of major changes<br />
*** minor changes = list of RT tickets fixed -- always grab a fresh list from RT when editing these!<br />
** contributors (RT is a good source for these)<br />
* make additional manpage and update-po commits with updated patchlevel.h<br />
* squash preceding commits so all versioning-related commits are a single commit (non-versioning changes to maintainer-mode stuff should remain separate commits)<br />
* <code>git tag krb5-x.y.z-final</code><br />
<br />
===Running mkrel===<br />
<br />
* <code>path_to_mkrel/mkrel --repository $YOUR_SOURCE_TREE krb5-x.y.z-final krb5-x.y.z</code><br />
* manually inspect output for versioning and correctness<br />
** HTML docs<br />
** PDF docs<br />
** patchlevel.h as modified by mkrel<br />
* push to authoritative repository<br />
* rerun mkrel against the authoritative repository: <code>path_to_mkrel/mkrel krb5-x.y.z-final krb5-x.y.z</code><br />
<br />
===Post-mkrel===<br />
<br />
* PGP sign<br />
* generate branded HTML docs<br />
* edit web pages<br />
* send announcement to kerberos-announce</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Berkeley_DB_notes&diff=5658Berkeley DB notes2016-08-26T14:40:08Z<p>TomYu: /* Bugs */</p>
<hr />
<div>==Internals==<br />
<br />
These notes mostly describe the btree back end for our special db-1.85/1.86 variant, as used for the "db2" KDB module. Some of this material should go into the official documentation to help operators understand possible database corruption characteristics.<br />
<br />
Berkeley DB files are made up of fixed-size pages. Each back end (hash, btree) has its own way of organizing data into pages. Page zero of a database file is a metadata page that includes persistent parameters of the whole database.<br />
<br />
===mpool===<br />
<br />
Berkley DB has a user-space page cache called mpool. Pages in the cache can be in-use/pinned (<code>MPOOL_PINNED</code>) and/or dirty (<code>MPOOL_DIRTY</code>). There is a hash table for pages in the cache, and an LRU queue to help release memory used by unreferenced pages.<br />
<br />
<code>mpool_open</code> opens a memory pool from an already-open file descriptor. It takes a <code>pagesize</code> and a <code>maxcache</code> parameter. <code>pagesize</code> is typically a persistent parameter of an upper layer (e.g., stored in the btree metadata page), while <code>maxcache</code> can be tuned for performance without changing persistent database parameters.<br />
<br />
<code>mpool_get</code> gets an existing page. It checks to see if the requested page is not pinned, and retrieves it from the cache if it's already in the cache. (If built with <code>-DDEBUG</code>, it will abort if the page is already pinned, unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag). If the page is not in cache, <code>mpool_get</code> reads in the page from disk. Regardless of how it obtained the page, <code>mpool_get</code> sets <code>MPOOL_PINNED</code> unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag. If the current cache size is at least <code>maxcache</code>, <code>mpool_get</code> tries to reuse unreferenced cache entries when reading in a previously uncached page (through static helper <code>mpool_bkt</code>). It does this by getting the first unpinned page from the LRU queue (which might be dirty, in which case it will flush it to disk). If this fails to free up a cache entry, <code>mpool_bkt</code> will allocate a new entry anyway, growing the cache beyond the <code>maxcache</code>.<br />
<br />
<code>mpool_put</code> releases a pinned page, clearing <code>MPOOL_PINNED</code>. The caller can pass the <code>MPOOL_DIRTY</code> flag to indicate that it modified the page and the page therefore needs to be written back to disk. Notably, <code>mpool_put</code> does not change the order of the LRU queue; only <code>mpool_get</code> does that, which means that the ordering of <code>mpool_put</code> calls doesn't determine the order in which mpool flushes dirty pages to disk. If a subsequent <code>mpool_get</code> fetches a dirty page before it is flushed to disk, the page moves to the tail of the LRU queue, possibly further delaying its being written to disk.<br />
<br />
<code>mpool_sync</code> writes dirty pages out to disk and calls <code>fsync</code>. The only part of the btree back end that calls it is <code>__bt_sync</code> (usually by way of <code>__bt_close</code>).<br />
<br />
===btree===<br />
<br />
The btree back end is actually a [https://en.wikipedia.org/wiki/B%2B_tree B+tree]. Pages in the tree are either internal pages or leaf pages. There is also a free list (with its head pointer in the metadata page). Leaf pages contain key-value pairs in key-sorted order; internal pages contain keys (also sorted) paired with pointers to child pages. Pages have sibling links to pages to their left and right on the same level of the tree. (The free list also uses sibling links.) These sibling links help speed up some tree update operations and sequential traversal. Updates that split a page can touch a potentially multiple pages, especially if parent pages must split (possibly up to the root), leading to opportunities for corruption if some of the writes fail (due to crashes or power failures). Often, corruption will result in some items being inaccessible to sequential access, random access, or both. Observed instances of corruption appear to be inconsistencies between parent-child links and sibling links. Rarely, loops will form in a sibling chain, causing infinite loops (at least until disk space exhaustion) during dumps. Sibling link corruption can lead to worse corruption if a page with a corrupted sibling link splits or is deleted.<br />
<br />
Page splits of non-root pages always preserve the page being split as the left-hand page. Splitting the root creates two new pages and converts the root to an internal page if it started out as a leaf page.<br />
<br />
Even though every page in a tree should have at least two children or items, some pages can end up with only one due to deletions. Only when a deletion would completely empty a page is that page deleted.<br />
<br />
==Compatibility==<br />
<br />
Our bundled "db2" is actually probably db-1.86 with patches. db-1.85 was the version included by most BSD derivatives. db-1.86 made backward-incompatible changes in the hash back end (but not probably not the btree back end, though we haven't confirmed that).<br />
<br />
There's some issue that prevents krb5_db2_promote_db (and thus kdb5_util load) from working properly with db-5.3, and possibly earlier releases.<br />
<br />
==Bugs==<br />
<br />
Byteswapping in <code>bt_conv.c</code> might not work correctly for leaf records with small keys but big (overflow) data. This probably can't be caught by the current test suite, which can only check that the byteswapping code is internally consistent. (A proper test for this would need a database file created on an opposite-endian platform.)<br />
<br />
Overflow page pointers for big keys (and sometimes big data) are unaligned; this can cause problems with byte swapping on platforms that enforce strict alignment.<br />
<br />
==BSD "upstreams"==<br />
<br />
The major open-source BSD derivatives NetBSD, FreeBSD, and OpenBSD have db-1.85/1.86 in their libc. They have shared various patches back and forth, but there are still some divergences among them. These can become relevant when trying to minimize diffs.<br />
<br />
NetBSD seems to have converted from BSD fixed-width types (e.g., <code>u_int32_t</code>) to C99/POSIX fixed-width type (e.g., <code>uint32_t</code>), but FreeBSD and OpenBSD have not. FreeBSD and NetBSD seem to have converted function declarations to prototypes, but OpenBSD has not. NetBSD and OpenBSD have eliminated BSD type names such as <code>u_long</code>, but FreeBSD has not.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Berkeley_DB_notes&diff=5657Berkeley DB notes2016-08-26T12:18:47Z<p>TomYu: </p>
<hr />
<div>==Internals==<br />
<br />
These notes mostly describe the btree back end for our special db-1.85/1.86 variant, as used for the "db2" KDB module. Some of this material should go into the official documentation to help operators understand possible database corruption characteristics.<br />
<br />
Berkeley DB files are made up of fixed-size pages. Each back end (hash, btree) has its own way of organizing data into pages. Page zero of a database file is a metadata page that includes persistent parameters of the whole database.<br />
<br />
===mpool===<br />
<br />
Berkley DB has a user-space page cache called mpool. Pages in the cache can be in-use/pinned (<code>MPOOL_PINNED</code>) and/or dirty (<code>MPOOL_DIRTY</code>). There is a hash table for pages in the cache, and an LRU queue to help release memory used by unreferenced pages.<br />
<br />
<code>mpool_open</code> opens a memory pool from an already-open file descriptor. It takes a <code>pagesize</code> and a <code>maxcache</code> parameter. <code>pagesize</code> is typically a persistent parameter of an upper layer (e.g., stored in the btree metadata page), while <code>maxcache</code> can be tuned for performance without changing persistent database parameters.<br />
<br />
<code>mpool_get</code> gets an existing page. It checks to see if the requested page is not pinned, and retrieves it from the cache if it's already in the cache. (If built with <code>-DDEBUG</code>, it will abort if the page is already pinned, unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag). If the page is not in cache, <code>mpool_get</code> reads in the page from disk. Regardless of how it obtained the page, <code>mpool_get</code> sets <code>MPOOL_PINNED</code> unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag. If the current cache size is at least <code>maxcache</code>, <code>mpool_get</code> tries to reuse unreferenced cache entries when reading in a previously uncached page (through static helper <code>mpool_bkt</code>). It does this by getting the first unpinned page from the LRU queue (which might be dirty, in which case it will flush it to disk). If this fails to free up a cache entry, <code>mpool_bkt</code> will allocate a new entry anyway, growing the cache beyond the <code>maxcache</code>.<br />
<br />
<code>mpool_put</code> releases a pinned page, clearing <code>MPOOL_PINNED</code>. The caller can pass the <code>MPOOL_DIRTY</code> flag to indicate that it modified the page and the page therefore needs to be written back to disk. Notably, <code>mpool_put</code> does not change the order of the LRU queue; only <code>mpool_get</code> does that, which means that the ordering of <code>mpool_put</code> calls doesn't determine the order in which mpool flushes dirty pages to disk. If a subsequent <code>mpool_get</code> fetches a dirty page before it is flushed to disk, the page moves to the tail of the LRU queue, possibly further delaying its being written to disk.<br />
<br />
<code>mpool_sync</code> writes dirty pages out to disk and calls <code>fsync</code>. The only part of the btree back end that calls it is <code>__bt_sync</code> (usually by way of <code>__bt_close</code>).<br />
<br />
===btree===<br />
<br />
The btree back end is actually a [https://en.wikipedia.org/wiki/B%2B_tree B+tree]. Pages in the tree are either internal pages or leaf pages. There is also a free list (with its head pointer in the metadata page). Leaf pages contain key-value pairs in key-sorted order; internal pages contain keys (also sorted) paired with pointers to child pages. Pages have sibling links to pages to their left and right on the same level of the tree. (The free list also uses sibling links.) These sibling links help speed up some tree update operations and sequential traversal. Updates that split a page can touch a potentially multiple pages, especially if parent pages must split (possibly up to the root), leading to opportunities for corruption if some of the writes fail (due to crashes or power failures). Often, corruption will result in some items being inaccessible to sequential access, random access, or both. Observed instances of corruption appear to be inconsistencies between parent-child links and sibling links. Rarely, loops will form in a sibling chain, causing infinite loops (at least until disk space exhaustion) during dumps. Sibling link corruption can lead to worse corruption if a page with a corrupted sibling link splits or is deleted.<br />
<br />
Page splits of non-root pages always preserve the page being split as the left-hand page. Splitting the root creates two new pages and converts the root to an internal page if it started out as a leaf page.<br />
<br />
Even though every page in a tree should have at least two children or items, some pages can end up with only one due to deletions. Only when a deletion would completely empty a page is that page deleted.<br />
<br />
==Compatibility==<br />
<br />
Our bundled "db2" is actually probably db-1.86 with patches. db-1.85 was the version included by most BSD derivatives. db-1.86 made backward-incompatible changes in the hash back end (but not probably not the btree back end, though we haven't confirmed that).<br />
<br />
There's some issue that prevents krb5_db2_promote_db (and thus kdb5_util load) from working properly with db-5.3, and possibly earlier releases.<br />
<br />
==Bugs==<br />
<br />
Byteswapping in <code>bt_conv.c</code> might not work correctly for leaf records with small keys but big (overflow) data. This probably can't be caught by the current test suite, which can only check that the byteswapping code is internally consistent. (A proper test for this would need a database file created on an opposite-endian platform.)<br />
<br />
==BSD "upstreams"==<br />
<br />
The major open-source BSD derivatives NetBSD, FreeBSD, and OpenBSD have db-1.85/1.86 in their libc. They have shared various patches back and forth, but there are still some divergences among them. These can become relevant when trying to minimize diffs.<br />
<br />
NetBSD seems to have converted from BSD fixed-width types (e.g., <code>u_int32_t</code>) to C99/POSIX fixed-width type (e.g., <code>uint32_t</code>), but FreeBSD and OpenBSD have not. FreeBSD and NetBSD seem to have converted function declarations to prototypes, but OpenBSD has not. NetBSD and OpenBSD have eliminated BSD type names such as <code>u_long</code>, but FreeBSD has not.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Berkeley_DB_notes&diff=5656Berkeley DB notes2016-08-25T19:56:26Z<p>TomYu: </p>
<hr />
<div>==Internals==<br />
<br />
These notes mostly describe the btree back end for our special db-1.85/1.86 variant, as used for the "db2" KDB module. Some of this material should go into the official documentation to help operators understand possible database corruption characteristics.<br />
<br />
Berkeley DB files are made up of fixed-size pages. Each back end (hash, btree) has its own way of organizing data into pages. Page zero of a database file is a metadata page that includes persistent parameters of the whole database.<br />
<br />
===mpool===<br />
<br />
Berkley DB has a user-space page cache called mpool. Pages in the cache can be in-use/pinned (<code>MPOOL_PINNED</code>) and/or dirty (<code>MPOOL_DIRTY</code>). There is a hash table for pages in the cache, and an LRU queue to help release memory used by unreferenced pages.<br />
<br />
<code>mpool_open</code> opens a memory pool from an already-open file descriptor. It takes a <code>pagesize</code> and a <code>maxcache</code> parameter. <code>pagesize</code> is typically a persistent parameter of an upper layer (e.g., stored in the btree metadata page), while <code>maxcache</code> can be tuned for performance without changing persistent database parameters.<br />
<br />
<code>mpool_get</code> gets an existing page. It checks to see if the requested page is not pinned, and retrieves it from the cache if it's already in the cache. (If built with <code>-DDEBUG</code>, it will abort if the page is already pinned, unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag). If the page is not in cache, <code>mpool_get</code> reads in the page from disk. Regardless of how it obtained the page, <code>mpool_get</code> sets <code>MPOOL_PINNED</code> unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag. If the current cache size is at least <code>maxcache</code>, <code>mpool_get</code> tries to reuse unreferenced cache entries when reading in a previously uncached page (through static helper <code>mpool_bkt</code>). It does this by getting the first unpinned page from the LRU queue (which might be dirty, in which case it will flush it to disk). If this fails to free up a cache entry, <code>mpool_bkt</code> will allocate a new entry anyway, growing the cache beyond the <code>maxcache</code>.<br />
<br />
<code>mpool_put</code> releases a pinned page, clearing <code>MPOOL_PINNED</code>. The caller can pass the <code>MPOOL_DIRTY</code> flag to indicate that it modified the page and the page therefore needs to be written back to disk. Notably, <code>mpool_put</code> does not change the order of the LRU queue; only <code>mpool_get</code> does that, which means that the ordering of <code>mpool_put</code> calls doesn't determine the order in which mpool flushes dirty pages to disk. If a subsequent <code>mpool_get</code> fetches a dirty page before it is flushed to disk, the page moves to the tail of the LRU queue, possibly further delaying its being written to disk.<br />
<br />
<code>mpool_sync</code> writes dirty pages out to disk and calls <code>fsync</code>. The only part of the btree back end that calls it is <code>__bt_sync</code> (usually by way of <code>__bt_close</code>).<br />
<br />
===btree===<br />
<br />
The btree back end is actually a [https://en.wikipedia.org/wiki/B%2B_tree B+tree]. Pages in the tree are either internal pages or leaf pages. There is also a free list (with its head pointer in the metadata page). Leaf pages contain key-value pairs in key-sorted order; internal pages contain keys (also sorted) paired with pointers to child pages. Pages have sibling links to pages to their left and right on the same level of the tree. (The free list also uses sibling links.) These sibling links help speed up some tree update operations and sequential traversal. Updates that split a page can touch a potentially multiple pages, especially if parent pages must split (possibly up to the root), leading to opportunities for corruption if some of the writes fail (due to crashes or power failures). Often, corruption will result in some items being inaccessible to sequential access, random access, or both. Observed instances of corruption appear to be inconsistencies between parent-child links and sibling links. Rarely, loops will form in a sibling chain, causing infinite loops (at least until disk space exhaustion) during dumps. Sibling link corruption can lead to worse corruption if a page with a corrupted sibling link splits or is deleted.<br />
<br />
Page splits of non-root pages always preserve the page being split as the left-hand page. Splitting the root creates two new pages and converts the root to an internal page if it started out as a leaf page.<br />
<br />
Even though every page in a tree should have at least two children or items, some pages can end up with only one due to deletions. Only when a deletion would completely empty a page is that page deleted.<br />
<br />
==Compatibility==<br />
<br />
Our bundled "db2" is actually probably db-1.86 with patches. db-1.85 was the version included by most BSD derivatives. db-1.86 made backward-incompatible changes in the hash back end (but not probably not the btree back end, though we haven't confirmed that).<br />
<br />
There's some issue that prevents krb5_db2_promote_db (and thus kdb5_util load) from working properly with db-5.3, and possibly earlier releases.<br />
<br />
==BSD "upstreams"==<br />
<br />
The major open-source BSD derivatives NetBSD, FreeBSD, and OpenBSD have db-1.85/1.86 in their libc. They have shared various patches back and forth, but there are still some divergences among them. These can become relevant when trying to minimize diffs.<br />
<br />
NetBSD seems to have converted from BSD fixed-width types (e.g., <code>u_int32_t</code>) to C99/POSIX fixed-width type (e.g., <code>uint32_t</code>), but FreeBSD and OpenBSD have not. FreeBSD and NetBSD seem to have converted function declarations to prototypes, but OpenBSD has not. NetBSD and OpenBSD have eliminated BSD type names such as <code>u_long</code>, but FreeBSD has not.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Berkeley_DB_notes&diff=5654Berkeley DB notes2016-08-15T16:14:43Z<p>TomYu: </p>
<hr />
<div>==Internals==<br />
<br />
These notes mostly describe the btree back end for our special db-1.85/1.86 variant, as used for the "db2" KDB module. Some of this material should go into the official documentation to help operators understand possible database corruption characteristics.<br />
<br />
Berkeley DB files are made up of fixed-size pages. Each back end (hash, btree) has its own way of organizing data into pages. Page zero of a database file is a metadata page that includes persistent parameters of the whole database.<br />
<br />
===mpool===<br />
<br />
Berkley DB has a user-space page cache called mpool. Pages in the cache can be in-use/pinned (<code>MPOOL_PINNED</code>) and/or dirty (<code>MPOOL_DIRTY</code>). There is a hash table for pages in the cache, and an LRU queue to help release memory used by unreferenced pages.<br />
<br />
<code>mpool_open</code> opens a memory pool from an already-open file descriptor. It takes a <code>pagesize</code> and a <code>maxcache</code> parameter. <code>pagesize</code> is typically a persistent parameter of an upper layer (e.g., stored in the btree metadata page), while <code>maxcache</code> can be tuned for performance without changing persistent database parameters.<br />
<br />
<code>mpool_get</code> gets an existing page. It checks to see if the requested page is not pinned, and retrieves it from the cache if it's already in the cache. (If built with <code>-DDEBUG</code>, it will abort if the page is already pinned, unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag). If the page is not in cache, <code>mpool_get</code> reads in the page from disk. Regardless of how it obtained the page, <code>mpool_get</code> sets <code>MPOOL_PINNED</code> unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag. If the current cache size is at least <code>maxcache</code>, <code>mpool_get</code> tries to reuse unreferenced cache entries when reading in a previously uncached page (through static helper <code>mpool_bkt</code>). It does this by getting the first unpinned page from the LRU queue (which might be dirty, in which case it will flush it to disk). If this fails to free up a cache entry, <code>mpool_bkt</code> will allocate a new entry anyway, growing the cache beyond the <code>maxcache</code>.<br />
<br />
<code>mpool_put</code> releases a pinned page, clearing <code>MPOOL_PINNED</code>. The caller can pass the <code>MPOOL_DIRTY</code> flag to indicate that it modified the page and the page therefore needs to be written back to disk. Notably, <code>mpool_put</code> does not change the order of the LRU queue; only <code>mpool_get</code> does that, which means that the ordering of <code>mpool_put</code> calls doesn't determine the order in which mpool flushes dirty pages to disk. If a subsequent <code>mpool_get</code> fetches a dirty page before it is flushed to disk, the page moves to the tail of the LRU queue, possibly further delaying its being written to disk.<br />
<br />
<code>mpool_sync</code> writes dirty pages out to disk and calls <code>fsync</code>. The only part of the btree back end that calls it is <code>__bt_sync</code> (usually by way of <code>__bt_close</code>).<br />
<br />
===btree===<br />
<br />
The btree back end is actually a [https://en.wikipedia.org/wiki/B%2B_tree B+tree]. Pages in the tree are either internal pages or leaf pages. There is also a free list (with its head pointer in the metadata page). Leaf pages contain key-value pairs in key-sorted order; internal pages contain keys (also sorted) paired with pointers to child pages. Pages have sibling links to pages to their left and right on the same level of the tree. (The free list also uses sibling links.) These sibling links help speed up some tree update operations and sequential traversal. Updates that split a page can touch a potentially multiple pages, especially if parent pages must split (possibly up to the root), leading to opportunities for corruption if some of the writes fail (due to crashes or power failures). Often, corruption will result in some items being inaccessible to sequential access, random access, or both. Observed instances of corruption appear to be inconsistencies between parent-child links and sibling links. Rarely, loops will form in a sibling chain, causing infinite loops (at least until disk space exhaustion) during dumps. Sibling link corruption can lead to worse corruption if a page with a corrupted sibling link splits or is deleted.<br />
<br />
Page splits of non-root pages always preserve the page being split as the left-hand page. Splitting the root creates two new pages and converts the root to an internal page if it started out as a leaf page.<br />
<br />
Even though every page in a tree should have at least two children or items, some pages can end up with only one due to deletions. Only when a deletion would completely empty a page is that page deleted.<br />
<br />
==Compatibility==<br />
<br />
Our bundled "db2" is actually probably db-1.86 with patches. db-1.85 was the version included by most BSD derivatives. db-1.86 made backward-incompatible changes in the hash back end (but not probably not the btree back end, though we haven't confirmed that).<br />
<br />
There's some issue that prevents krb5_db2_promote_db (and thus kdb5_util load) from working properly with db-5.3, and possibly earlier releases.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Berkeley_DB_notes&diff=5653Berkeley DB notes2016-08-13T15:51:07Z<p>TomYu: </p>
<hr />
<div>==Internals==<br />
<br />
These notes mostly describe the btree back end for our special db-1.85/1.86 variant, as used for the "db2" KDB module. Some of this material should go into the official documentation to help operators understand possible database corruption characteristics.<br />
<br />
Berkeley DB files are made up of fixed-size pages. Each back end (hash, btree) has its own way of organizing data into pages. Page zero of a database file is a metadata page that includes persistent parameters of the whole database.<br />
<br />
===mpool===<br />
<br />
Berkley DB has a user-space page cache called mpool. Pages in the cache can be in-use/pinned (<code>MPOOL_PINNED</code>) and/or dirty (<code>MPOOL_DIRTY</code>). There is a hash table for pages in the cache, and an LRU queue to help release memory used by unreferenced pages.<br />
<br />
<code>mpool_open</code> opens a memory pool from an already-open file descriptor. It takes a <code>pagesize</code> and a <code>maxcache</code> parameter. <code>pagesize</code> is typically a persistent parameter of an upper layer (e.g., stored in the btree metadata page), while <code>maxcache</code> can be tuned for performance without changing persistent database parameters.<br />
<br />
<code>mpool_get</code> gets an existing page. It checks to see if the requested page is not pinned, and retrieves it from the cache if it's already in the cache. (If built with <code>-DDEBUG</code>, it will abort if the page is already pinned, unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag). If the page is not in cache, <code>mpool_get</code> reads in the page from disk. Regardless of how it obtained the page, <code>mpool_get</code> sets <code>MPOOL_PINNED</code> unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag. If the current cache size is at least <code>maxcache</code>, <code>mpool_get</code> tries to reuse unreferenced cache entries when reading in a previously uncached page (through static helper <code>mpool_bkt</code>). It does this by getting the first unpinned page from the LRU queue (which might be dirty, in which case it will flush it to disk). If this fails to free up a cache entry, <code>mpool_bkt</code> will allocate a new entry anyway, growing the cache beyond the <code>maxcache</code>.<br />
<br />
<code>mpool_put</code> releases a pinned page, clearing <code>MPOOL_PINNED</code>. The caller can pass the <code>MPOOL_DIRTY</code> flag to indicate that it modified the page and the page therefore needs to be written back to disk. Notably, <code>mpool_put</code> does not change the order of the LRU queue; only <code>mpool_get</code> does that, which means that the ordering of <code>mpool_put</code> calls doesn't determine the order in which mpool flushes dirty pages to disk. If a subsequent <code>mpool_get</code> fetches a dirty page before it is flushed to disk, the page moves to the tail of the LRU queue, possibly further delaying its being written to disk.<br />
<br />
<code>mpool_sync</code> writes dirty pages out to disk and calls <code>fsync</code>. The only part of the btree back end that calls it is <code>__bt_sync</code> (usually by way of <code>__bt_close</code>).<br />
<br />
===btree===<br />
<br />
The btree back end is actually a [https://en.wikipedia.org/wiki/B%2B_tree B+tree]. Pages in the tree are either internal pages or leaf pages. There is also a free list (with its head pointer in the metadata page). Leaf pages contain key-value pairs in key-sorted order; internal pages contain keys (also sorted) paired with pointers to child pages. Pages have sibling links to pages to their left and right on the same level of the tree. (The free list also uses sibling links.) These sibling links help speed up some tree update operations and sequential traversal. Updates that split a page can touch a potentially multiple pages, especially if parent pages must split (possibly up to the root), leading to opportunities for corruption if some of the writes fail (due to crashes or power failures). Often, corruption will result in some items being inaccessible to sequential access, random access, or both. Observed instances of corruption appear to be inconsistencies between parent-child links and sibling links. Rarely, loops will form in a sibling chain, causing infinite loops (at least until disk space exhaustion) during dumps.<br />
<br />
==Compatibility==<br />
<br />
Our bundled "db2" is actually probably db-1.86 with patches. db-1.85 was the version included by most BSD derivatives. db-1.86 made backward-incompatible changes in the hash back end (but not probably not the btree back end, though we haven't confirmed that).<br />
<br />
There's some issue that prevents krb5_db2_promote_db (and thus kdb5_util load) from working properly with db-5.3, and possibly earlier releases.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Berkeley_DB_notes&diff=5652Berkeley DB notes2016-08-12T22:37:20Z<p>TomYu: Created page with "==Internals== These notes mostly describe the btree back end for our special db-1.85/1.86 variant. Some of this material should go into the official documentation to help ope..."</p>
<hr />
<div>==Internals==<br />
<br />
These notes mostly describe the btree back end for our special db-1.85/1.86 variant. Some of this material should go into the official documentation to help operators understand possible database corruption characteristics.<br />
<br />
Berkeley DB files are made up of fixed-size pages. Each back end (hash, btree) has its own way of organizing data into pages. Page zero of a database file is a metadata page that includes persistent parameters of the whole database.<br />
<br />
===mpool===<br />
<br />
Berkley DB has a user-space page cache called mpool. Pages in the cache can be in-use/pinned (<code>MPOOL_PINNED</code>) and/or dirty (<code>MPOOL_DIRTY</code>). There is a hash table for pages in the cache, and an LRU queue to help release memory used by unreferenced pages.<br />
<br />
<code>mpool_get</code> gets an existing page. It checks to see if the requested page is already in memory in a cache and not pinned. (It will abort if the page is already pinned, unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag). It reads in the page from disk if necessary, and sets <code>MPOOL_PINNED</code> unless the caller passes the <code>MPOOL_IGNOREPIN</code> flag. If the cache size is larger than a configured maximum, <code>mpool_get</code> tries to reuse unreferenced cache entries when reading in a previously uncached page. It does this by walking the LRU queue for unpinned pages (which might be dirty, in which case it will flush them to disk). If this fails to free up a cache entry, <code>mpool_get</code> will allocate a new entry anyway, growing the cache beyond the nominal maximum size.<br />
<br />
<code>mpool_put</code> releases a pinned page, clearing <code>MPOOL_PINNED</code>. The caller can pass the <code>MPOOL_DIRTY</code> flag to indicate that it modified the page and the page therefore needs to be written back to disk. Notably, <code>mpool_put</code> does not change the order of the LRU queue; only <code>mpool_get</code> does that, which means that the ordering of <code>mpool_put</code> calls doesn't determine the order in which mpool flushes dirty pages to disk. If a subsequent <code>mpool_get</code> fetches a dirty page before it is flushed to disk, the page moves to the tail of the LRU queue, possibly further delaying its being written to disk.<br />
<br />
===btree===<br />
<br />
The btree back end is actually a [https://en.wikipedia.org/wiki/B%2B_tree B+tree]. Pages in the tree are either internal pages or leaf pages. There is also a free list. Leaf pages contain key-value pairs in key-sorted order; internal pages contain keys (also sorted) with pointers to lower level pages. Pages have sibling links to pages to their left and right on the same level of the tree. (The free list also uses sibling links.) These sibling links help speed up some tree update operations and sequential traversal. Updates that split a page can touch a potentially multiple pages, especially if parent pages must split (possibly up to the root), leading to opportunities for corruption if some of the writes fail. Often, corruption will result in some items being inaccessible to sequential access, random access, or both. Rarely, loops will form in a sibling chain, causing infinite loops (at least until disk space exhaustion) during dumps.<br />
<br />
==Compatibility==<br />
<br />
Our bundled "db2" is actually probably db-1.86 with patches. db-1.85 was the version included by most BSD derivatives. db-1.86 made backward-incompatible changes in the hash back end (but not probably not the btree back end, though we haven't confirmed that).<br />
<br />
There's some issue that prevents krb5_db2_promote_db (and thus kdb5_util load) from working properly with db-5.3, and possibly earlier releases.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5649Ops feedback teleconference2016-08-01T18:55:24Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, as a Consortium activity, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2016-08-02 ===<br />
<br />
* reverse DNS for host principal canonicalization -- usability tradeoffs<br />
* how to consolidate per-principal settings of ticket policy to a policy object, e.g., ticket lifetimes<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_engineering_notes&diff=5648Release engineering notes2016-07-24T15:59:49Z<p>TomYu: </p>
<hr />
<div>==Required manual steps==<br />
<br />
===Pre-mkrel===<br />
<br />
* check copyright years in project-wide stuff<br />
* make sure you're in a build tree that's not the source tree and configured using <code>--enable-maintainer-mode</code><br />
* <code>make depend</code> and commit if changed<br />
* regenerate manpages: <code>(cd man && make man)</code> and commit if changed<br />
* regenerate localization template <code>(cd po && make update-po)</code> and commit if changed<br />
* manually edit patchlevel.h to reflect the new release<br />
* manually update README<br />
** release dates (in major changes heading, ISO 8601 date format with hyphens)<br />
** changes<br />
*** note whether bugfix release, maintenance vs current release<br />
*** bullet list of major changes<br />
*** minor changes = list of RT tickets fixed -- always grab a fresh list from RT when editing these!<br />
** contributors (RT is a good source for these)<br />
* make additional manpage and update-po commits with updated patchlevel.h<br />
* squash preceding commits so all versioning-related commits are a single commit (non-versioning changes to maintainer-mode stuff should remain separate commits)<br />
* <code>git tag krb5-x.y.z-final</code><br />
<br />
===Running mkrel===<br />
<br />
* <code>path_to_mkrel/mkrel --repository $YOUR_SOURCE_TREE krb5-x.y.z-final krb5-x.y.z</code><br />
* manually inspect output for versioning and correctness<br />
** HTML docs<br />
** PDF docs<br />
** patchlevel.h as modified by mkrel<br />
* push to authoritative repository<br />
* rerun mkrel against the authoritative repository: <code>path_to_mkrel/mkrel krb5-x.y.z-final krb5-x.y.z</code><br />
<br />
===Post-mkrel===<br />
<br />
* PGP sign<br />
* generate branded HTML docs<br />
* edit web pages<br />
* send announcement to kerberos-announce</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Kerberos_for_Windows_(KfW)_Build_Environment&diff=5647Kerberos for Windows (KfW) Build Environment2016-07-22T19:45:05Z<p>TomYu: Update for InCommon cert/timestamping</p>
<hr />
<div>[[Category: Kerberos for Windows]]<br />
Directions for producing an environment in which to build<br />
Kerberos for Windows version 4<br />
<br />
Start with a clean Windows 7 installation (64-bit necessary?)<br />
<br />
(0) get a browser that you like/trust to validate SSL certs/etc.<br />
<br />
(1) Install MS Visual Studio 2010 Professional<br />
grab the Visual C++ 10.0 runtime for x86 and x64<br />
also the 64-bit prerequisites<br />
Documentation files not necessary<br />
Choose 'Visual C++ Development Settings' (probably doesn't matter)<br />
You should now have an 'HTML Help Workshop' entry within<br />
Program Files (x86). This will get added to the path, later.<br />
(2) Install the Windows SDK version 7.1<br />
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=8279<br />
The download is over a non-https url by default, though the installer<br />
is signed by a Microsoft certificate.<br />
[Select all components (add application verifier, debugging tools,<br />
windows performance toolkit)]<br />
Finishing the installation brings up the Help Library Manager (installer?)<br />
but nothing should be necessary from that utility.<br />
If you have an error mentioning "Please refer to Samples\Setup\HTML\ConfigDetails.htm"<br />
then uninstall any existing Visual Studio 2010 Redistributable packages installed on<br />
your system and try again.<br />
(3) Install the Utilities and SDK for UNIX-based Applications (amd64 if on a 64-bit system)<br />
First, enable the Windows feature "Subsystem for UNIX-based Applications"<br />
from the Control Panel. (Programs [and Features] menu, "Turn on or off<br />
Windows features", or similar.)<br />
Then visit (also available from the All Programs menu)<br />
http://www.microsoft.com/en-us/download/details.aspx?id=23754<br />
Again, this is a http-default page, and attempting to use SSL causes<br />
an error due to Akamai configuration.<br />
I have Version 10.0.6030.0 of the SUA, which claims to be for<br />
Windows Vista RTM/Windows Vista SP1/Windows Server 2008 RTM<br />
but appears to work fine on Windows 7.<br />
[The standard installation gives us awk, which may be all we need?]<br />
(4) Install the Windows Installer XML Toolkit<br />
Tested with version 3.5; there is a 3.6 beta available as well.<br />
wix.sourceforge.net --> wix.codeplex.com/releases/view/60102<br />
These default to non-SSL urls; try to get<br />
https://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=wix&DownloadId=204417&FileTime=129409234222130000&Build=19194<br />
Install all components (the default setting).<br />
(5) Update the system path to include some necessary utilities.<br />
This is something like<br />
Control Panel->System->Advanced System Settings->Environment<br />
awk is in C:\Windows\SUA\bin<br />
But, you will need to make a *copy* (not link) of it named awk.exe in<br />
order for things to work properly. Check the permissions so that everyone<br />
can read and execute it.<br />
Add the directory containing hhc.exe to the path:<br />
C:\Program Files (x86)\HTML Help Workshop<br />
Add C:\Program Files (x86)\Windows Installer XML v3.5\bin to the path<br />
to get candle.exe.<br />
(6) Install a real Perl that can handle both forward-slash and backward-slash as path separators, e.g., ActivePerl or Strawberry Perl.<br />
I used Strawberry Perl, since its installer was downloadable over SSL and<br />
was digitally signed.<br />
I have strawberry_perl-5.14.2.1-64bit.msi<br />
Note that you may not have spaces in the path to the installation, so<br />
it installs to c:\strawberry by default.<br />
<br />
That should be enough for the build environment.<br />
<br />
To actually build an installer, first get the source. If you are using git<br />
to get the source, don't set it to convert the line endings to native. The<br />
SUA version of awk expects the files to have unix line endings.<br />
<br />
Next, fire up the Windows SDK 7.1 command prompt.<br />
<br />
(0) cmd /v to get delayed expansion of variables<br />
<br />
(1) Environment set-up<br />
set KRB_INSTALL_DIR=/path/to/an/obj/dir<br />
[set MIT_INTERNAL=1]<br />
[set NODEBUG=1]<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x86 [/release]<br />
set CPU=i386<br />
(2) Build the 32-bit binaries<br />
cd /path/to/krb5-tree/src<br />
[nmake clean]<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
(3) Build 32-bit installer<br />
cd windows/installer/wix<br />
[nmake clean]<br />
nmake<br />
rename kfw.msi kfw32.msi<br />
(4) 64-bit build -- NOTE: don't delete the install directory from the 32-bit build; the 32-bit DLLs are needed by the 64-bit installer<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x64 [/release]<br />
set CPU=AMD64<br />
cd /path/to/krb5-tree/src<br />
nmake clean<br />
nmake -f Makefile.in prep-windows [?]<br />
nmake<br />
nmake install<br />
(5) Build 64-bit installer<br />
cd windows/installer/wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw64.msi<br />
<br />
Code signing<br />
<br />
signtool sign /a /t http://timestamp.comodoca.com foo.msi<br />
<br />
Code signing with SHA256 file digest and timestamp (not required until 2017-01-01?)<br />
<br />
signtool sign /v /a /fd sha256 /td sha256 /tr http://timestamp.comodoca.com foo.msi<br />
<br />
See also https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/68/7/<br />
<br />
More general KfW release engineering information at [[Kerberos for Windows Release Engineering]].</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_engineering_notes&diff=5646Release engineering notes2016-07-20T01:35:27Z<p>TomYu: </p>
<hr />
<div>==Required manual steps==<br />
<br />
===Pre-mkrel===<br />
<br />
* check copyright years in project-wide stuff<br />
* make sure you're in a build tree that's not the source tree and configured using <code>--enable-maintainer-mode</code><br />
* <code>make depend</code> and commit if changed<br />
* regenerate manpages: <code>(cd man && make man)</code> and commit if changed<br />
* regenerate localization template <code>(cd po && make update-po)</code> and commit if changed<br />
* manually edit patchlevel.h to reflect the new release<br />
* manually update README<br />
** dates<br />
** changes -- always grab a fresh list from RT when editing these!<br />
** contributors (RT is a good source for these)<br />
* make additional manpage and update-po commits with updated patchlevel.h<br />
* squash preceding commits so all versioning-related commits are a single commit (non-versioning changes to maintainer-mode stuff should remain separate commits)<br />
* <code>git tag krb5-x.y.z-final</code><br />
<br />
===Running mkrel===<br />
<br />
* <code>path_to_mkrel/mkrel --repository $YOUR_SOURCE_TREE krb5-x.y.z-final krb5-x.y.z</code><br />
* manually inspect output for versioning and correctness<br />
** HTML docs<br />
** PDF docs<br />
** patchlevel.h as modified by mkrel<br />
* push to authoritative repository<br />
* rerun mkrel against the authoritative repository: <code>path_to_mkrel/mkrel krb5-x.y.z-final krb5-x.y.z</code><br />
<br />
===Post-mkrel===<br />
<br />
* PGP sign<br />
* generate branded HTML docs<br />
* edit web pages<br />
* send announcement to kerberos-announce</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_engineering_notes&diff=5645Release engineering notes2016-07-12T18:52:42Z<p>TomYu: </p>
<hr />
<div>==Required manual steps==<br />
<br />
===Pre-mkrel===<br />
<br />
* check copyright years in project-wide stuff<br />
* make sure you're in a build tree that's not the source tree and configured using <code>--enable-maintainer-mode</code><br />
* <code>make depend</code> and commit if changed<br />
* regenerate manpages: <code>(cd man && make man)</code> and commit if changed<br />
* regenerate localization template <code>(cd po && make update-po)</code> and commit if changed<br />
* manually edit patchlevel.h to reflect the new release<br />
* manually update README<br />
** dates<br />
** changes<br />
** contributors<br />
* make additional manpage and update-po commits with updated patchlevel.h<br />
* squash preceding commits so all versioning-related commits are a single commit (non-versioning changes should remain separate commits)<br />
* <code>git tag krb5-x.y.z-final</code><br />
<br />
===Running mkrel===<br />
<br />
* <code>path_to_mkrel/mkrel --repository $YOUR_SOURCE_TREE krb5-x.y.z-final krb5-x.y.z</code><br />
* manually inspect output for versioning and correctness<br />
** HTML docs<br />
** PDF docs<br />
** patchlevel.h as modified by mkrel<br />
* push to authoritative repository<br />
* rerun mkrel against the authoritative repository: <code>path_to_mkrel/mkrel krb5-x.y.z-final krb5-x.y.z</code><br />
<br />
===Post-mkrel===<br />
<br />
* PGP sign<br />
* generate branded HTML docs<br />
* edit web pages<br />
* send announcement</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_engineering_notes&diff=5644Release engineering notes2016-07-12T18:34:55Z<p>TomYu: </p>
<hr />
<div>==Required manual steps==<br />
<br />
===Pre-mkrel===<br />
<br />
* check copyright years in project-wide stuff<br />
* make sure you're in a build tree that's not the source tree and configured using <code>--enable-maintainer-mode</code><br />
* <code>make depend</code> and commit if changed<br />
* regenerate manpages: <code>(cd man && make man)</code> and commit if changed<br />
* regenerate localization template <code>(cd po && make update-po)</code> and commit if changed<br />
* manually edit patchlevel.h to reflect the new release<br />
* manually update README<br />
** dates<br />
** changes<br />
** contributors<br />
* make additional manpage and update-po commits with updated patchlevel.h<br />
* squash preceding commits so all versioning-related commits are a single commit (non-versioning changes should remain separate commits)<br />
<br />
===Post-mkrel===<br />
<br />
* PGP sign<br />
* generate branded HTML docs<br />
* edit web pages<br />
* send announcement</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Kerberos_for_Windows_Release_Engineering&diff=5641Kerberos for Windows Release Engineering2016-06-27T22:32:06Z<p>TomYu: </p>
<hr />
<div>[[Category: Kerberos for Windows]]<br />
Release Engineering notes for the Kerberos for Windows 4.0.0 release<br />
<br />
Software to test against new builds:<br />
* SapGUI<br />
* OpenAFS<br />
* SecureCRT (and SecureFX?)<br />
* SPNEGO (in multiple browsers?)<br />
* Adobe Keyserver a.k.a the Sassafras key client<br />
* SMTP/IMAP via Thunderbird (must disable SSPI though?)<br />
* LDAP in some form?<br />
* XMPP via, e.g., Pidgin<br />
<br />
Upgrades scenarios to test:<br />
* 32-bit to 32-bit, from 3.2<br />
* 64-bit to 64-bit, from 3.2<br />
* 32-bit to 64-bit, from 3.2<br />
* 32-bit and 64-bit to 64-bit, from 3.2<br />
* 32-bit to 64-bit, from 4.0<br />
* 64-bit to 32-bit, from 4.0<br />
When starting from 3.2, it probably suffices to test the Secure Endpoints versions once only, and assume that there will not be future changes to 4.0 which cause the upgrade process to fail for the SE version but not the MIT-distributed version.<br />
The NSIS upgrade path is a separate codepath and should be tested separately.<br />
<br />
Current known issues:<br />
* The version number implanted in various dlls no longer reflects the underlying krb5 version (instead using the KfW version); this may not actually be a bug.<br />
* windows/README is outdated<br />
* (Version) upgrades that go from 64-bit to 32-bit leave 64-bit binaries around but otherwise succeed.<br />
<br />
Issues that we believe to be resolved:<br />
* The uninstaller prompts to kill running processes but does not do succeed in doing so. There may be cases in which it just kills processes without prompting, which may still be a bug.<br />
* The upgrade procedure attempts to kill running processes but does not succeed in doing so (these two may be sharing most of the code). The wix-users archives suggest that Util:CloseApplication may be useful to do this in pure WiX instead of a custom element<br />
* There is a report of crashes on a multiprocessor machine unless CPU-pinning is used<br />
* Uninitialized (NULL) TLS pointers that were most prominent on multi-processor machines, causing internal ccache errors that were reported as "unknown error" due to another minor bug.<br />
* Thunderbird cannot do GSSAPI auth unless you disable SSPI<br />
* Our DllMain attach/detach handler spews to the terminal when running command-line utilities. Possibly other debug print statements, too.<br />
<br />
Versioning stuff:<br />
<br />
* src/patchlevel.h<br />
* src/windows/installer/wix/site-local.wxi<br />
* src/windows/version.rc (copyright year)<br />
* src/windows/winlevel.h<br />
* src/windows/kerberos.ver<br />
<br />
Procedure for building release binaries (MIT and non-MIT, i386 and amd64):<br />
<br />
On the VM host:<br />
<br />
rm -rf /path/to/share/kfw-4.1-beta2 && git archive --prefix=kfw-4.1-beta2/ [committish] | (cd /path/to/share/; tar x)<br />
rm -rf /path/to/share/kfw-4.1-beta2-mit && git archive --prefix=kfw-4.1-beta2-mit/ [committish] | (cd /path/to/share/; tar x)<br />
git archive --prefix=kfw-4.1-beta2/ --format=zip -o ../kfw-4.1-beta2-src.zip refs/tags/kfw-4.1-beta2<br />
<br />
<br />
mkdir C:\destdir<br />
mkdir C:\debug-symbols<br />
mkdir C:\debug-symbols\kfw-NNN-i386-mit<br />
mkdir C:\debug-symbols\kfw-NNN-amd64-mit<br />
mkdir C:\debug-symbols\kfw-NNN-i386<br />
mkdir C:\debug-symbols\kfw-NNN-amd64<br />
setenv /x86 /release<br />
set CPU=i386<br />
set KRB_INSTALL_DIR=C:\destdir<br />
set NODEBUG=1<br />
set DEBUG_SYMBOL=1<br />
set MIT_INTERNAL=1<br />
# do the MIT i386 build<br />
cd C:\kfw-NNN-mit\src<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-i386-mit<br />
cd windows\installer\wix<br />
nmake<br />
rename kfw.msi kfw-NNN-i386-mit.msi<br />
# time for the MIT amd64 build<br />
cd ..\..\..<br />
setenv /x64 /release<br />
set CPU=AMD64<br />
set DEBUG_SYMBOL=1<br />
nmake clean<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-amd64-mit<br />
cd windows\installer\wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw-NNN-amd64-mit.msi<br />
rm -r C:\destdir\bin<br />
rm -r C:\destdir\lib<br />
rm -r C:\destdir\include<br />
# fresh env for the non-MIT i386 build<br />
setenv /x86 /release<br />
set CPU=i386<br />
set DEBUG_SYMBOL=1<br />
set MIT_INTERNAL= # unset it<br />
cd C:\kfw-NNN\src<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-i386<br />
cd windows\installer\wix<br />
nmake<br />
rename kfw.msi kfw-NNN-i386.msi<br />
cd ..\..\..<br />
# the non-MIT amd64 build<br />
setenv /x64 /release<br />
set CPU=AMD64<br />
set DEBUG_SYMBOL=1<br />
nmake clean<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-amd64<br />
cd windows\installer\wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw-NNN-amd64.msi<br />
[copy C:\kfw-NNN{,-mit}\src\windows\installer\wix\*.msi to the shared drive]<br />
[recursively copy C:\debug-symbols\kfw-NNN* to the shared drive]<br />
<br />
On the VM host, extract the build output for signing.<br />
<br />
Use the arCHMage package to extract HTML from the CHM file for the web. The tool outputs some bogus absolute URLs for links and inline images, so use<br />
<br />
perl -pi -e 's,((?:href|src)=")/,\1../,g' */*<br />
<br />
to postprocess.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5639Ops feedback teleconference2016-06-06T19:06:50Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, as a Consortium activity, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2016-06-07 ===<br />
<br />
* functionality of MIT ktutil vs Heimdal; possibility of adding adding Heimdal UI compatibility to MIT ktutil<br />
* keytab manipulation in general; what else could be improved?<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Category:Target_1.15_projects&diff=5638Category:Target 1.15 projects2016-06-06T18:37:45Z<p>TomYu: Created page with "Category:Projects"</p>
<hr />
<div>[[Category:Projects]]</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=MediaWiki:Sitenotice&diff=5630MediaWiki:Sitenotice2016-05-25T19:13:12Z<p>TomYu: </p>
<hr />
<div><div style="padding-top: 1em">[http://www.kerberos.org https://k5wiki.kerberos.org/logo_kerberos.gif]</div></div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5629Ops feedback teleconference2016-05-02T19:18:57Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, as a Consortium activity, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2016-05-03 ===<br />
<br />
* Build-time disabling of crypto algorithms for regulatory and risk management reasons<br />
* Ease of building from source<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Committer_resources&diff=5628Committer resources2016-05-01T15:28:54Z<p>TomYu: /* RT headers */</p>
<hr />
<div>This is information for developers who are [[Committers|committers]] to our repository.<br />
<br />
== Enrollment ==<br />
<br />
* Athena account: MITKC staff will sponsor as appropriate. See http://web.mit.edu/accounts/www/getaccount.html for some overview information about Athena accounts.<br />
* X.509 client certificate: Needed for RT access, among others. Information on how to obtain one is at http://web.mit.edu/ist/topics/certificates/index.html<br />
* RT account<br />
* Git access<br />
* Posting authorization to cvs-krb5 if you are going to commit stuff.<br />
* Coverity scan access<br />
<br />
== Where stuff is at ==<br />
<br />
* Git URL: git.mit.edu:/git/krb5.git -- you may need to put "username@" in front if your local username is not the same as your Athena account name. Clone this instead of git@github.com:krb5/krb5.git when setting up your local repository in order to be able to push changes.<br />
* SSH to athena.dialup.mit.edu if you want easy access to AFS, a UNIX shell, etc.<br />
** You'll need to set GSSAPIDelegateCredentials=yes in order to do passwordless login, because user home directories are in AFS, and the administrators didn't want to confuse users who logged in with Kerberos but couldn't access their files.<br />
* RT https://krbdev.mit.edu/rt/ (or https://krbdev.mit.edu:444/rt/ if your browser doesn't deal with "optional" SSL client certificate verification)<br />
<br />
== Accessing git.mit.edu ==<br />
<br />
The preferred way to access git.mit.edu is with GSSAPI krb5 authentication. It is not necessary to delegate credentials.<br />
<br />
It is also possible to use publickey authentication. Because Athena account home directories are stored in AFS, there are some extra setup steps required to make sure that the sshd on git.mit.edu can read your public key:<br />
<br />
* Your home directory and .ssh directory must allow list (but not read) access to unauthenticated users. This is generally the case by default.<br />
* Your .ssh/authorized_keys file must be a link to a directory which allows read access to unauthenticated users. To set this up, you can ssh to athena.dialup.mit.edu and run:<br />
<br />
# mkdir $HOME/.ssh if it doesn't already exist.<br />
cd $HOME/.ssh<br />
mkdir pub<br />
fs sa pub system:anyuser rl<br />
# Move aside authorized_keys if it already exists.<br />
ln -s pub/authorized_keys authorized_keys<br />
<br />
The contents of your key pair's .pub file should be placed into $HOME/.ssh/pub/authorized_keys.<br />
<br />
Finally, you can authenticate to git.mit.edu using password authentication with your Athena password.<br />
<br />
== RT headers ==<br />
<br />
If a commit makes a user-visible change, such as adding a new feature or fixing a user-visible bug in a previous release, it should be associated with an RT ticket. Do this by adding RT pseudo-headers at the end of the commit message, after a blank line. The most important header is "ticket:", which associates the commit with a ticket number. Add "tags: pullup" and "target_version: X.Y-next" if the commit should be pulled up to a release branch. Here is an example:<br />
<br />
Use correct profile var in krb5_get_tgs_ktypes<br />
<br />
In r21879, when we converted to using KRB5_CONF macros for profile<br />
variable names, we made a typo in krb5_get_tgs_ktypes and erroneously<br />
started using default_tkt_enctypes instead of default_tgs_enctypes for<br />
TGS requests. Fix the typo and return to the documented behavior.<br />
<br />
ticket: 7155<br />
target_version: 1.10-next<br />
tags: pullup<br />
<br />
A ticket can multiple target_version values. If a fix needs to go into multiple releases, use a separate target_version header for each one.<br />
<br />
=== New tickets ===<br />
<br />
If you are creating a new ticket, run "ssh git.mit.edu krb5-rt-id" to reserve a ticket number, and put "ticket: NNNN (new)" in the commit message, substituting the ticket number for NNNN. The summary line of the commit will be used as the subject of the new ticket; if this is not what you want, you can use a "subject:" RT header to set the ticket subject, or you can change the subject afterwards in RT.<br />
<br />
You can automate this process using a [https://raw.github.com/krb5/krbdev-services/master/githooks-client/commit-msg commit-msg hook]. Drop the contents of the hook into .git/hooks/commit-msg and make it executable. Then you can put just "ticket: new" at the end of a commit message, and the hook will automatically reserve a ticket number and rewrite the header to "ticket: NNNN (new)". You should have some form of passwordless login to git.mit.edu set up for this to work transparently.<br />
<br />
=== More about RT keywords ===<br />
<br />
These are somewhat inconsistent and will need more editing:<br />
* Additional detail about [[RT keywords]]<br />
* [[Manipulating RT tickets using commits]]<br />
<br />
== Pushing changes from contributors ==<br />
<br />
When integrating code changes created by contributors, take note of the following:<br />
<br />
* If the change is presented to you as one or more git commits, fetch the commit into your local git repository and then use git cherry-pick to make a copy of the relevant commits onto your master branch (or a topic branch). Do not use git merge.<br />
<br />
* If the change is presented to you as a patch, make a commit from the patch and use the --author flag to git commit to set the commit author field to the author's name and email address.<br />
<br />
* Review the changes as well as possible, and make sure they are organized into logical commits as required by our [[Coding_style/Version_control_practices|version control practices]]. Run the C style checker to identify possible style issues.<br />
<br />
* Make sure the changes build and pass "make check".<br />
<br />
* Add appropriate RT headers to the commit messages if appropriate.<br />
<br />
* If you need to make significant changes to the commit or commit message, you can add a note to the end (before any RT headers) like:<br />
<br />
[ghudson@mit.edu: Stylistic changes, commit message]</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Main_Page&diff=5627Main Page2016-04-21T18:45:20Z<p>TomYu: bump current release number</p>
<hr />
<div>__NOTOC__<br />
'''K5Wiki''' is a wiki supporting the development of [[MIT Kerberos]], a reference implementation of [[wp:Kerberos (protocol)|the Kerberos network authentication protocol]].<br />
<br />
This wiki serves both as a place for coordination of development efforts on MIT Kerberos and as a means for potential contributors and other interested people to become more involved with MIT Kerberos development. This wiki does not focus on the needs for the average end user, but it may nevertheless contain information that is useful to advanced users, such as system administrators who wish to make customizations.<br />
<br />
What can this wiki do for you?<br />
* I have a [[Asking questions|question]]<br />
* I want to [[Writing applications|write Kerberos application software]]<br />
* I want to [[Reporting bugs|report bugs]]<br />
* I want to [[Fixing bugs|fix bugs]]<br />
* I want to [[Learning about the code|learn more about the code]]<br />
* I have [[Suggesting enhancements|ideas for enhancements]]<br />
* I want to [[Contributing code|contribute code]]<br />
* I want to [[K5Wiki:Todo|help to improve this wiki]]<br />
<br />
== Releases ==<br />
<br />
The current release is [http://web.mit.edu/kerberos/krb5-latest/ krb5-1.14].<br />
<br />
* [[Release 1.14 | Release 1.14 goals]]<br />
<br />
Additional information on future releases:<br />
<br />
* Development [[roadmap]]<br />
* [[Release 1.15 | Release 1.15 goals]]<br />
<br />
== Users ==<br />
<br />
We recommend that end users use MIT Kerberos software packages built by their operating system vendor if possible, and use support resources provided by their site or by their vendor. For those users (typically system administrators) who have a need to build MIT Kerberos from source code, we have some resources available on this wiki.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* More [[user resources]]<br />
<br />
== System administrators ==<br />
<br />
We also recommend that most system administrators use MIT Kerberos software packages from their operating system vendor if possible.<br />
<br />
* [[Building]] the MIT Kerberos software<br />
* [[Reporting bugs]]<br />
* [[Suggesting enhancements]]<br />
* [[IPv6]] support status<br />
* Monthly [[ops feedback teleconference]]<br />
* More [[sysadmin resources]]<br />
<br />
== Developers ==<br />
<br />
Developers can include end users who have a need to customize the MIT Kerberos source code, or who would like to contribute patches for new features or for bug fixes.<br />
<br />
* [[Developer resources]]<br />
* [[Getting source code]]<br />
* [[Committer resources]] -- only really useful for people with commit access.<br />
<br />
=== Contributing ===<br />
<br />
* [[How to contribute]] to the MIT Kerberos software<br />
* [[Fixing bugs]]<br />
* [[Suggesting enhancements]]<br />
* [[Contributing code]]<br />
<br />
=== Background information ===<br />
<br />
* [[:Category:Policies|Policies for development]]<br />
* [[:Category:Lore|Lore]]<br />
<br />
=== Code quality ===<br />
<br />
* [[Coding style]]<br />
* [[Test-driven development]]<br />
* [[Manual_Testing|Manual testing procedures]]<br />
* [[Cleanups|Code cleanup opportunities]]<br />
<br />
=== Planning ===<br />
<br />
* Development [[roadmap]]<br />
* [[Projects]]<br />
<br />
=== Communication ===<br />
<br />
* [[Release_Meeting_Minutes|Release Meeting Minutes]]<br />
* [[Developer chat]]<br />
* [http://blog.kerberos.org/ Blog]<br />
<br />
== Additional information ==<br />
<br />
* [[K5Wiki:Todo|A todo list for work needing doing on this wiki]]<br />
* [[Application_Maintenance|Notes on maintenance of the krb5 telnet/rlogin/gssftp applications]]<br />
<br />
We look forward to your contributions to K5Wiki and MIT Kerberos.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Kerberos_for_Windows_(KfW)_Build_Environment&diff=5625Kerberos for Windows (KfW) Build Environment2016-04-11T18:46:23Z<p>TomYu: </p>
<hr />
<div>[[Category: Kerberos for Windows]]<br />
Directions for producing an environment in which to build<br />
Kerberos for Windows version 4<br />
<br />
Start with a clean Windows 7 installation (64-bit necessary?)<br />
<br />
(0) get a browser that you like/trust to validate SSL certs/etc.<br />
<br />
(1) Install MS Visual Studio 2010 Professional<br />
grab the Visual C++ 10.0 runtime for x86 and x64<br />
also the 64-bit prerequisites<br />
Documentation files not necessary<br />
Choose 'Visual C++ Development Settings' (probably doesn't matter)<br />
You should now have an 'HTML Help Workshop' entry within<br />
Program Files (x86). This will get added to the path, later.<br />
(2) Install the Windows SDK version 7.1<br />
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=8279<br />
The download is over a non-https url by default, though the installer<br />
is signed by a Microsoft certificate.<br />
[Select all components (add application verifier, debugging tools,<br />
windows performance toolkit)]<br />
Finishing the installation brings up the Help Library Manager (installer?)<br />
but nothing should be necessary from that utility.<br />
If you have an error mentioning "Please refer to Samples\Setup\HTML\ConfigDetails.htm"<br />
then uninstall any existing Visual Studio 2010 Redistributable packages installed on<br />
your system and try again.<br />
(3) Install the Utilities and SDK for UNIX-based Applications (amd64 if on a 64-bit system)<br />
First, enable the Windows feature "Subsystem for UNIX-based Applications"<br />
from the Control Panel. (Programs [and Features] menu, "Turn on or off<br />
Windows features", or similar.)<br />
Then visit (also available from the All Programs menu)<br />
http://www.microsoft.com/en-us/download/details.aspx?id=23754<br />
Again, this is a http-default page, and attempting to use SSL causes<br />
an error due to Akamai configuration.<br />
I have Version 10.0.6030.0 of the SUA, which claims to be for<br />
Windows Vista RTM/Windows Vista SP1/Windows Server 2008 RTM<br />
but appears to work fine on Windows 7.<br />
[The standard installation gives us awk, which may be all we need?]<br />
(4) Install the Windows Installer XML Toolkit<br />
Tested with version 3.5; there is a 3.6 beta available as well.<br />
wix.sourceforge.net --> wix.codeplex.com/releases/view/60102<br />
These default to non-SSL urls; try to get<br />
https://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=wix&DownloadId=204417&FileTime=129409234222130000&Build=19194<br />
Install all components (the default setting).<br />
(5) Update the system path to include some necessary utilities.<br />
This is something like<br />
Control Panel->System->Advanced System Settings->Environment<br />
awk is in C:\Windows\SUA\bin<br />
But, you will need to make a *copy* (not link) of it named awk.exe in<br />
order for things to work properly. Check the permissions so that everyone<br />
can read and execute it.<br />
Add the directory containing hhc.exe to the path:<br />
C:\Program Files (x86)\HTML Help Workshop<br />
Add C:\Program Files (x86)\Windows Installer XML v3.5\bin to the path<br />
to get candle.exe.<br />
(6) Install a real Perl that can handle both forward-slash and backward-slash as path separators, e.g., ActivePerl or Strawberry Perl.<br />
I used Strawberry Perl, since its installer was downloadable over SSL and<br />
was digitally signed.<br />
I have strawberry_perl-5.14.2.1-64bit.msi<br />
Note that you may not have spaces in the path to the installation, so<br />
it installs to c:\strawberry by default.<br />
<br />
That should be enough for the build environment.<br />
<br />
To actually build an installer, first get the source. If you are using git<br />
to get the source, don't set it to convert the line endings to native. The<br />
SUA version of awk expects the files to have unix line endings.<br />
<br />
Next, fire up the Windows SDK 7.1 command prompt.<br />
<br />
(0) cmd /v to get delayed expansion of variables<br />
<br />
(1) Environment set-up<br />
set KRB_INSTALL_DIR=/path/to/an/obj/dir<br />
[set MIT_INTERNAL=1]<br />
[set NODEBUG=1]<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x86 [/release]<br />
set CPU=i386<br />
(2) Build the 32-bit binaries<br />
cd /path/to/krb5-tree/src<br />
[nmake clean]<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
(3) Build 32-bit installer<br />
cd windows/installer/wix<br />
[nmake clean]<br />
nmake<br />
rename kfw.msi kfw32.msi<br />
(4) 64-bit build -- NOTE: don't delete the install directory from the 32-bit build; the 32-bit DLLs are needed by the 64-bit installer<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x64 [/release]<br />
set CPU=AMD64<br />
cd /path/to/krb5-tree/src<br />
nmake clean<br />
nmake -f Makefile.in prep-windows [?]<br />
nmake<br />
nmake install<br />
(5) Build 64-bit installer<br />
cd windows/installer/wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw64.msi<br />
<br />
Code signing<br />
<br />
signtool sign /a /t http://timestamp.verisign.com/scripts/timstamp.dll foo.msi<br />
<br />
Code signing with SHA256 file digest and timestamp (not required until 2017-01-01?)<br />
<br />
signtool sign /v /a /fd sha256 /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp foo.msi<br />
<br />
See also https://knowledge.symantec.com/support/code-signing-support/index?page=content&id=SO15544<br />
<br />
More general KfW release engineering information at [[Kerberos for Windows Release Engineering]].</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Kerberos_for_Windows_(KfW)_Build_Environment&diff=5624Kerberos for Windows (KfW) Build Environment2016-04-11T18:45:09Z<p>TomYu: </p>
<hr />
<div>[[Category: Kerberos for Windows]]<br />
Directions for producing an environment in which to build<br />
Kerberos for Windows version 4<br />
<br />
Start with a clean Windows 7 installation (64-bit necessary?)<br />
<br />
(0) get a browser that you like/trust to validate SSL certs/etc.<br />
<br />
(1) Install MS Visual Studio 2010 Professional<br />
grab the Visual C++ 10.0 runtime for x86 and x64<br />
also the 64-bit prerequisites<br />
Documentation files not necessary<br />
Choose 'Visual C++ Development Settings' (probably doesn't matter)<br />
You should now have an 'HTML Help Workshop' entry within<br />
Program Files (x86). This will get added to the path, later.<br />
(2) Install the Windows SDK version 7.1<br />
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=8279<br />
The download is over a non-https url by default, though the installer<br />
is signed by a Microsoft certificate.<br />
[Select all components (add application verifier, debugging tools,<br />
windows performance toolkit)]<br />
Finishing the installation brings up the Help Library Manager (installer?)<br />
but nothing should be necessary from that utility.<br />
If you have an error mentioning "Please refer to Samples\Setup\HTML\ConfigDetails.htm"<br />
then uninstall any existing Visual Studio 2010 Redistributable packages installed on<br />
your system and try again.<br />
(3) Install the Utilities and SDK for UNIX-based Applications (amd64 if on a 64-bit system)<br />
First, enable the Windows feature "Subsystem for UNIX-based Applications"<br />
from the Control Panel. (Programs [and Features] menu, "Turn on or off<br />
Windows features", or similar.)<br />
Then visit (also available from the All Programs menu)<br />
http://www.microsoft.com/en-us/download/details.aspx?id=23754<br />
Again, this is a http-default page, and attempting to use SSL causes<br />
an error due to Akamai configuration.<br />
I have Version 10.0.6030.0 of the SUA, which claims to be for<br />
Windows Vista RTM/Windows Vista SP1/Windows Server 2008 RTM<br />
but appears to work fine on Windows 7.<br />
[The standard installation gives us awk, which may be all we need?]<br />
(4) Install the Windows Installer XML Toolkit<br />
Tested with version 3.5; there is a 3.6 beta available as well.<br />
wix.sourceforge.net --> wix.codeplex.com/releases/view/60102<br />
These default to non-SSL urls; try to get<br />
https://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=wix&DownloadId=204417&FileTime=129409234222130000&Build=19194<br />
Install all components (the default setting).<br />
(5) Update the system path to include some necessary utilities.<br />
This is something like<br />
Control Panel->System->Advanced System Settings->Environment<br />
awk is in C:\Windows\SUA\bin<br />
But, you will need to make a *copy* (not link) of it named awk.exe in<br />
order for things to work properly. Check the permissions so that everyone<br />
can read and execute it.<br />
Add the directory containing hhc.exe to the path:<br />
C:\Program Files (x86)\HTML Help Workshop<br />
Add C:\Program Files (x86)\Windows Installer XML v3.5\bin to the path<br />
to get candle.exe.<br />
(6) Install a real Perl that can handle both forward-slash and backward-slash as path separators, e.g., ActivePerl or Strawberry Perl.<br />
I used Strawberry Perl, since its installer was downloadable over SSL and<br />
was digitally signed.<br />
I have strawberry_perl-5.14.2.1-64bit.msi<br />
Note that you may not have spaces in the path to the installation, so<br />
it installs to c:\strawberry by default.<br />
<br />
That should be enough for the build environment.<br />
<br />
To actually build an installer, first get the source. If you are using git<br />
to get the source, don't set it to convert the line endings to native. The<br />
SUA version of awk expects the files to have unix line endings.<br />
<br />
Next, fire up the Windows SDK 7.1 command prompt.<br />
<br />
(0) cmd /v to get delayed expansion of variables<br />
<br />
(1) Environment set-up<br />
set KRB_INSTALL_DIR=/path/to/an/obj/dir<br />
[set MIT_INTERNAL=1]<br />
[set NODEBUG=1]<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x86 [/release]<br />
set CPU=i386<br />
(2) Build the 32-bit binaries<br />
cd /path/to/krb5-tree/src<br />
[nmake clean]<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
(3) Build 32-bit installer<br />
cd windows/installer/wix<br />
[nmake clean]<br />
nmake<br />
rename kfw.msi kfw32.msi<br />
(4) 64-bit build -- NOTE: don't delete the install directory from the 32-bit build; the 32-bit DLLs are needed by the 64-bit installer<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x64 [/release]<br />
set CPU=AMD64<br />
cd /path/to/krb5-tree/src<br />
nmake clean<br />
nmake -f Makefile.in prep-windows [?]<br />
nmake<br />
nmake install<br />
(5) Build 64-bit installer<br />
cd windows/installer/wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw64.msi<br />
<br />
Code signing<br />
<br />
signtool sign /a /t http://timestamp.verisign.com/scripts/timstamp.dll foo.msi<br />
<br />
Code signing with SHA256 file digest and timestamp (not required until 2017-01-01?)<br />
<br />
signtool sign /v /a /fd sha256 /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp foo.msi<br />
<br />
See also https://knowledge.symantec.com/support/code-signing-support/index?page=content&id=SO15544</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Kerberos_for_Windows_Release_Engineering&diff=5623Kerberos for Windows Release Engineering2016-04-11T18:44:54Z<p>TomYu: </p>
<hr />
<div>[[Category: Kerberos for Windows]]<br />
Release Engineering notes for the Kerberos for Windows 4.0.0 release<br />
<br />
Software to test against new builds:<br />
* SapGUI<br />
* OpenAFS<br />
* SecureCRT (and SecureFX?)<br />
* SPNEGO (in multiple browsers?)<br />
* Adobe Keyserver a.k.a the Sassafras key client<br />
* SMTP/IMAP via Thunderbird (must disable SSPI though?)<br />
* LDAP in some form?<br />
* XMPP via, e.g., Pidgin<br />
<br />
Upgrades scenarios to test:<br />
* 32-bit to 32-bit, from 3.2<br />
* 64-bit to 64-bit, from 3.2<br />
* 32-bit to 64-bit, from 3.2<br />
* 32-bit and 64-bit to 64-bit, from 3.2<br />
* 32-bit to 64-bit, from 4.0<br />
* 64-bit to 32-bit, from 4.0<br />
When starting from 3.2, it probably suffices to test the Secure Endpoints versions once only, and assume that there will not be future changes to 4.0 which cause the upgrade process to fail for the SE version but not the MIT-distributed version.<br />
The NSIS upgrade path is a separate codepath and should be tested separately.<br />
<br />
Current known issues:<br />
* The version number implanted in various dlls no longer reflects the underlying krb5 version (instead using the KfW version); this may not actually be a bug.<br />
* windows/README is outdated<br />
* (Version) upgrades that go from 64-bit to 32-bit leave 64-bit binaries around but otherwise succeed.<br />
<br />
Issues that we believe to be resolved:<br />
* The uninstaller prompts to kill running processes but does not do succeed in doing so. There may be cases in which it just kills processes without prompting, which may still be a bug.<br />
* The upgrade procedure attempts to kill running processes but does not succeed in doing so (these two may be sharing most of the code). The wix-users archives suggest that Util:CloseApplication may be useful to do this in pure WiX instead of a custom element<br />
* There is a report of crashes on a multiprocessor machine unless CPU-pinning is used<br />
* Uninitialized (NULL) TLS pointers that were most prominent on multi-processor machines, causing internal ccache errors that were reported as "unknown error" due to another minor bug.<br />
* Thunderbird cannot do GSSAPI auth unless you disable SSPI<br />
* Our DllMain attach/detach handler spews to the terminal when running command-line utilities. Possibly other debug print statements, too.<br />
<br />
Versioning stuff:<br />
<br />
* src/patchlevel.h<br />
* src/windows/installer/wix/site-local.wxi<br />
* src/windows/version.rc (copyright year)<br />
* src/windows/winlevel.h<br />
* src/windows/kerberos.ver<br />
<br />
Procedure for building release binaries (MIT and non-MIT, i386 and amd64):<br />
<br />
On the VM host:<br />
<br />
rm -rf /path/to/share/kfw-4.1-beta2 && git archive --prefix=kfw-4.1-beta2/ [committish] | (cd /path/to/share/; tar x)<br />
rm -rf /path/to/share/kfw-4.1-beta2-mit && git archive --prefix=kfw-4.1-beta2-mit/ [committish] | (cd /path/to/share/; tar x)<br />
git archive --prefix=kfw-4.1-beta2/ --format=zip -o ../kfw-4.1-beta2-src.zip refs/tags/kfw-4.1-beta2<br />
<br />
<br />
mkdir C:\destdir<br />
mkdir C:\debug-symbols<br />
mkdir C:\debug-symbols\kfw-NNN-i386-mit<br />
mkdir C:\debug-symbols\kfw-NNN-amd64-mit<br />
mkdir C:\debug-symbols\kfw-NNN-i386<br />
mkdir C:\debug-symbols\kfw-NNN-amd64<br />
setenv /x86 /release<br />
set CPU=i386<br />
set KRB_INSTALL_DIR=C:\destdir<br />
set NODEBUG=1<br />
set DEBUG_SYMBOL=1<br />
set MIT_INTERNAL=1<br />
# do the MIT i386 build<br />
cd C:\kfw-NNN-mit\src<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-i386-mit<br />
cd windows\installer\wix<br />
nmake<br />
rename kfw.msi kfw-NNN-i386-mit.msi<br />
# time for the MIT amd64 build<br />
cd ..\..\..<br />
setenv /x64 /release<br />
set CPU=AMD64<br />
set DEBUG_SYMBOL=1<br />
nmake clean<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-amd64-mit<br />
cd windows\installer\wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw-NNN-amd64-mit.msi<br />
rm -r C:\destdir\bin<br />
rm -r C:\destdir\lib<br />
rm -r C:\destdir\include<br />
# fresh env for the non-MIT i386 build<br />
setenv /x86 /release<br />
set CPU=i386<br />
set DEBUG_SYMBOL=1<br />
set MIT_INTERNAL= # unset it<br />
cd C:\kfw-NNN\src<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-i386<br />
cd windows\installer\wix<br />
nmake<br />
rename kfw.msi kfw-NNN-i386.msi<br />
cd ..\..\..<br />
# the non-MIT amd64 build<br />
setenv /x64 /release<br />
set CPU=AMD64<br />
set DEBUG_SYMBOL=1<br />
nmake clean<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-amd64<br />
cd windows\installer\wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw-NNN-amd64.msi<br />
[copy C:\kfw-NNN{,-mit}\src\windows\installer\wix\*.msi to the shared drive]<br />
[recursively copy C:\debug-symbols\kfw-NNN* to the shared drive]<br />
<br />
On the VM host, extract the build output for signing.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Kerberos_for_Windows_Release_Engineering&diff=5622Kerberos for Windows Release Engineering2016-04-08T22:21:08Z<p>TomYu: </p>
<hr />
<div>Release Engineering notes for the Kerberos for Windows 4.0.0 release<br />
<br />
Software to test against new builds:<br />
* SapGUI<br />
* OpenAFS<br />
* SecureCRT (and SecureFX?)<br />
* SPNEGO (in multiple browsers?)<br />
* Adobe Keyserver a.k.a the Sassafras key client<br />
* SMTP/IMAP via Thunderbird (must disable SSPI though?)<br />
* LDAP in some form?<br />
* XMPP via, e.g., Pidgin<br />
<br />
Upgrades scenarios to test:<br />
* 32-bit to 32-bit, from 3.2<br />
* 64-bit to 64-bit, from 3.2<br />
* 32-bit to 64-bit, from 3.2<br />
* 32-bit and 64-bit to 64-bit, from 3.2<br />
* 32-bit to 64-bit, from 4.0<br />
* 64-bit to 32-bit, from 4.0<br />
When starting from 3.2, it probably suffices to test the Secure Endpoints versions once only, and assume that there will not be future changes to 4.0 which cause the upgrade process to fail for the SE version but not the MIT-distributed version.<br />
The NSIS upgrade path is a separate codepath and should be tested separately.<br />
<br />
Current known issues:<br />
* The version number implanted in various dlls no longer reflects the underlying krb5 version (instead using the KfW version); this may not actually be a bug.<br />
* windows/README is outdated<br />
* (Version) upgrades that go from 64-bit to 32-bit leave 64-bit binaries around but otherwise succeed.<br />
<br />
Issues that we believe to be resolved:<br />
* The uninstaller prompts to kill running processes but does not do succeed in doing so. There may be cases in which it just kills processes without prompting, which may still be a bug.<br />
* The upgrade procedure attempts to kill running processes but does not succeed in doing so (these two may be sharing most of the code). The wix-users archives suggest that Util:CloseApplication may be useful to do this in pure WiX instead of a custom element<br />
* There is a report of crashes on a multiprocessor machine unless CPU-pinning is used<br />
* Uninitialized (NULL) TLS pointers that were most prominent on multi-processor machines, causing internal ccache errors that were reported as "unknown error" due to another minor bug.<br />
* Thunderbird cannot do GSSAPI auth unless you disable SSPI<br />
* Our DllMain attach/detach handler spews to the terminal when running command-line utilities. Possibly other debug print statements, too.<br />
<br />
Versioning stuff:<br />
<br />
* src/patchlevel.h<br />
* src/windows/installer/wix/site-local.wxi<br />
* src/windows/version.rc (copyright year)<br />
* src/windows/winlevel.h<br />
* src/windows/kerberos.ver<br />
<br />
Procedure for building release binaries (MIT and non-MIT, i386 and amd64):<br />
<br />
On the VM host:<br />
<br />
rm -rf /path/to/share/kfw-4.1-beta2 && git archive --prefix=kfw-4.1-beta2/ [committish] | (cd /path/to/share/; tar x)<br />
rm -rf /path/to/share/kfw-4.1-beta2-mit && git archive --prefix=kfw-4.1-beta2-mit/ [committish] | (cd /path/to/share/; tar x)<br />
git archive --prefix=kfw-4.1-beta2/ --format=zip -o ../kfw-4.1-beta2-src.zip refs/tags/kfw-4.1-beta2<br />
<br />
<br />
mkdir C:\destdir<br />
mkdir C:\debug-symbols<br />
mkdir C:\debug-symbols\kfw-NNN-i386-mit<br />
mkdir C:\debug-symbols\kfw-NNN-amd64-mit<br />
mkdir C:\debug-symbols\kfw-NNN-i386<br />
mkdir C:\debug-symbols\kfw-NNN-amd64<br />
setenv /x86 /release<br />
set CPU=i386<br />
set KRB_INSTALL_DIR=C:\destdir<br />
set NODEBUG=1<br />
set DEBUG_SYMBOL=1<br />
set MIT_INTERNAL=1<br />
# do the MIT i386 build<br />
cd C:\kfw-NNN-mit\src<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-i386-mit<br />
cd windows\installer\wix<br />
nmake<br />
rename kfw.msi kfw-NNN-i386-mit.msi<br />
# time for the MIT amd64 build<br />
cd ..\..\..<br />
setenv /x64 /release<br />
set CPU=AMD64<br />
set DEBUG_SYMBOL=1<br />
nmake clean<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-amd64-mit<br />
cd windows\installer\wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw-NNN-amd64-mit.msi<br />
rm -r C:\destdir\bin<br />
rm -r C:\destdir\lib<br />
rm -r C:\destdir\include<br />
# fresh env for the non-MIT i386 build<br />
setenv /x86 /release<br />
set CPU=i386<br />
set DEBUG_SYMBOL=1<br />
set MIT_INTERNAL= # unset it<br />
cd C:\kfw-NNN\src<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-i386<br />
cd windows\installer\wix<br />
nmake<br />
rename kfw.msi kfw-NNN-i386.msi<br />
cd ..\..\..<br />
# the non-MIT amd64 build<br />
setenv /x64 /release<br />
set CPU=AMD64<br />
set DEBUG_SYMBOL=1<br />
nmake clean<br />
nmake<br />
nmake install<br />
set DEBUG_SYMBOL= # unset it<br />
mv C:\destdir\bin\*.pdb C:\debug-symbols\kfw-NNN-amd64<br />
cd windows\installer\wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw-NNN-amd64.msi<br />
[copy C:\kfw-NNN{,-mit}\src\windows\installer\wix\*.msi to the shared drive]<br />
[recursively copy C:\debug-symbols\kfw-NNN* to the shared drive]<br />
<br />
On the VM host, extract the build output for signing.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Continuous_integration&diff=5621Continuous integration2016-04-06T16:37:42Z<p>TomYu: AppVeyor URL works now</p>
<hr />
<div>[[Category:Infrastructure]]<br />
<br />
Our continuous integration infrastructure includes Buildbot, Travis CI, AppVeyor, and a nightly cron job.<br />
<br />
==Buildbot==<br />
<br />
http://krbdev.mit.edu/buildbot/<br />
<br />
Automatically builds and tests master and active release branches on every push (with a 5-minute stability timer). Doesn't currently build pull requests. Periodically does a Coverity Scan build.<br />
<br />
==Travis CI==<br />
<br />
https://travis-ci.org/krb5/krb5<br />
<br />
Builds and tests all active branches and pull requests. Use <code>[ci skip]</code> in a commit message to request that Travis skip that commit.<br />
<br />
==AppVeyor==<br />
<br />
https://ci.appveyor.com/project/krb5/krb5<br />
<br />
Build and tests all active branches and pull requests under Windows.<br />
<br />
==Nightly builds==<br />
<br />
http://web.mit.edu/krbdev/testing/README.txt<br />
<br />
We run a nightly cron job on two machines (one Linux, one Solaris) which builds a snapshot and reports success or failure. This is currently our only regular build for Solaris; if we set up a Solaris buildbot slave, then we can decommission the nightly build infrastructure.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Kerberos_for_Windows_(KfW)_Build_Environment&diff=5616Kerberos for Windows (KfW) Build Environment2016-04-01T21:11:21Z<p>TomYu: </p>
<hr />
<div>Directions for producing an environment in which to build<br />
Kerberos for Windows version 4<br />
<br />
Start with a clean Windows 7 installation (64-bit necessary?)<br />
<br />
(0) get a browser that you like/trust to validate SSL certs/etc.<br />
<br />
(1) Install MS Visual Studio 2010 Professional<br />
grab the Visual C++ 10.0 runtime for x86 and x64<br />
also the 64-bit prerequisites<br />
Documentation files not necessary<br />
Choose 'Visual C++ Development Settings' (probably doesn't matter)<br />
You should now have an 'HTML Help Workshop' entry within<br />
Program Files (x86). This will get added to the path, later.<br />
(2) Install the Windows SDK version 7.1<br />
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=8279<br />
The download is over a non-https url by default, though the installer<br />
is signed by a Microsoft certificate.<br />
[Select all components (add application verifier, debugging tools,<br />
windows performance toolkit)]<br />
Finishing the installation brings up the Help Library Manager (installer?)<br />
but nothing should be necessary from that utility.<br />
If you have an error mentioning "Please refer to Samples\Setup\HTML\ConfigDetails.htm"<br />
then uninstall any existing Visual Studio 2010 Redistributable packages installed on<br />
your system and try again.<br />
(3) Install the Utilities and SDK for UNIX-based Applications (amd64 if on a 64-bit system)<br />
First, enable the Windows feature "Subsystem for UNIX-based Applications"<br />
from the Control Panel. (Programs [and Features] menu, "Turn on or off<br />
Windows features", or similar.)<br />
Then visit (also available from the All Programs menu)<br />
http://www.microsoft.com/en-us/download/details.aspx?id=23754<br />
Again, this is a http-default page, and attempting to use SSL causes<br />
an error due to Akamai configuration.<br />
I have Version 10.0.6030.0 of the SUA, which claims to be for<br />
Windows Vista RTM/Windows Vista SP1/Windows Server 2008 RTM<br />
but appears to work fine on Windows 7.<br />
[The standard installation gives us awk, which may be all we need?]<br />
(4) Install the Windows Installer XML Toolkit<br />
Tested with version 3.5; there is a 3.6 beta available as well.<br />
wix.sourceforge.net --> wix.codeplex.com/releases/view/60102<br />
These default to non-SSL urls; try to get<br />
https://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=wix&DownloadId=204417&FileTime=129409234222130000&Build=19194<br />
Install all components (the default setting).<br />
(5) Update the system path to include some necessary utilities.<br />
This is something like<br />
Control Panel->System->Advanced System Settings->Environment<br />
awk is in C:\Windows\SUA\bin<br />
But, you will need to make a *copy* (not link) of it named awk.exe in<br />
order for things to work properly. Check the permissions so that everyone<br />
can read and execute it.<br />
Add the directory containing hhc.exe to the path:<br />
C:\Program Files (x86)\HTML Help Workshop<br />
Add C:\Program Files (x86)\Windows Installer XML v3.5\bin to the path<br />
to get candle.exe.<br />
(6) Install a real Perl that can handle both forward-slash and backward-slash as path separators, e.g., ActivePerl or Strawberry Perl.<br />
I used Strawberry Perl, since its installer was downloadable over SSL and<br />
was digitally signed.<br />
I have strawberry_perl-5.14.2.1-64bit.msi<br />
Note that you may not have spaces in the path to the installation, so<br />
it installs to c:\strawberry by default.<br />
<br />
That should be enough for the build environment.<br />
<br />
To actually build an installer, first get the source. If you are using git<br />
to get the source, don't set it to convert the line endings to native. The<br />
SUA version of awk expects the files to have unix line endings.<br />
<br />
Next, fire up the Windows SDK 7.1 command prompt.<br />
<br />
(0) cmd /v to get delayed expansion of variables<br />
<br />
(1) Environment set-up<br />
set KRB_INSTALL_DIR=/path/to/an/obj/dir<br />
[set MIT_INTERNAL=1]<br />
[set NODEBUG=1]<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x86 [/release]<br />
set CPU=i386<br />
(2) Build the 32-bit binaries<br />
cd /path/to/krb5-tree/src<br />
[nmake clean]<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
(3) Build 32-bit installer<br />
cd windows/installer/wix<br />
[nmake clean]<br />
nmake<br />
rename kfw.msi kfw32.msi<br />
(4) 64-bit build -- NOTE: don't delete the install directory from the 32-bit build; the 32-bit DLLs are needed by the 64-bit installer<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x64 [/release]<br />
set CPU=AMD64<br />
cd /path/to/krb5-tree/src<br />
nmake clean<br />
nmake -f Makefile.in prep-windows [?]<br />
nmake<br />
nmake install<br />
(5) Build 64-bit installer<br />
cd windows/installer/wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw64.msi<br />
<br />
Code signing<br />
<br />
signtool sign /a /t http://timestamp.verisign.com/scripts/timstamp.dll foo.msi<br />
<br />
Code signing with SHA256 file digest and timestamp (not required until 2017-01-01?)<br />
<br />
signtool sign /v /a /fd sha256 /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp foo.msi<br />
<br />
See also https://knowledge.symantec.com/support/code-signing-support/index?page=content&id=SO15544</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Kerberos_for_Windows_(KfW)_Build_Environment&diff=5615Kerberos for Windows (KfW) Build Environment2016-03-28T19:44:17Z<p>TomYu: </p>
<hr />
<div>Directions for producing an environment in which to build<br />
Kerberos for Windows version 4<br />
<br />
Start with a clean Windows 7 installation (64-bit necessary?)<br />
<br />
(0) get a browser that you like/trust to validate SSL certs/etc.<br />
<br />
(1) Install MS Visual Studio 2010 Professional<br />
grab the Visual C++ 10.0 runtime for x86 and x64<br />
also the 64-bit prerequisites<br />
Documentation files not necessary<br />
Choose 'Visual C++ Development Settings' (probably doesn't matter)<br />
You should now have an 'HTML Help Workshop' entry within<br />
Program Files (x86). This will get added to the path, later.<br />
(2) Install the Windows SDK version 7.1<br />
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=8279<br />
The download is over a non-https url by default, though the installer<br />
is signed by a Microsoft certificate.<br />
[Select all components (add application verifier, debugging tools,<br />
windows performance toolkit)]<br />
Finishing the installation brings up the Help Library Manager (installer?)<br />
but nothing should be necessary from that utility.<br />
If you have an error mentioning "Please refer to Samples\Setup\HTML\ConfigDetails.htm"<br />
then uninstall any existing Visual Studio 2010 Redistributable packages installed on<br />
your system and try again.<br />
(3) Install the Utilities and SDK for UNIX-based Applications (amd64 if on a 64-bit system)<br />
First, enable the Windows feature "Subsystem for UNIX-based Applications"<br />
from the Control Panel. (Programs [and Features] menu, "Turn on or off<br />
Windows features", or similar.)<br />
Then visit (also available from the All Programs menu)<br />
http://www.microsoft.com/en-us/download/details.aspx?id=23754<br />
Again, this is a http-default page, and attempting to use SSL causes<br />
an error due to Akamai configuration.<br />
I have Version 10.0.6030.0 of the SUA, which claims to be for<br />
Windows Vista RTM/Windows Vista SP1/Windows Server 2008 RTM<br />
but appears to work fine on Windows 7.<br />
[The standard installation gives us awk, which may be all we need?]<br />
(4) Install the Windows Installer XML Toolkit<br />
Tested with version 3.5; there is a 3.6 beta available as well.<br />
wix.sourceforge.net --> wix.codeplex.com/releases/view/60102<br />
These default to non-SSL urls; try to get<br />
https://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=wix&DownloadId=204417&FileTime=129409234222130000&Build=19194<br />
Install all components (the default setting).<br />
(5) Update the system path to include some necessary utilities.<br />
This is something like<br />
Control Panel->System->Advanced System Settings->Environment<br />
awk is in C:\Windows\SUA\bin<br />
But, you will need to make a *copy* (not link) of it named awk.exe in<br />
order for things to work properly. Check the permissions so that everyone<br />
can read and execute it.<br />
Add the directory containing hhc.exe to the path:<br />
C:\Program Files (x86)\HTML Help Workshop<br />
Add C:\Program Files (x86)\Windows Installer XML v3.5\bin to the path<br />
to get candle.exe.<br />
(6) Install a real Perl that can handle both forward-slash and backward-slash as path separators, e.g., ActivePerl or Strawberry Perl.<br />
I used Strawberry Perl, since its installer was downloadable over SSL and<br />
was digitally signed.<br />
I have strawberry_perl-5.14.2.1-64bit.msi<br />
Note that you may not have spaces in the path to the installation, so<br />
it installs to c:\strawberry by default.<br />
<br />
That should be enough for the build environment.<br />
<br />
To actually build an installer, first get the source. If you are using git<br />
to get the source, don't set it to convert the line endings to native. The<br />
SUA version of awk expects the files to have unix line endings.<br />
<br />
Next, fire up the Windows SDK 7.1 command prompt.<br />
<br />
(0) cmd /v to get delayed expansion of variables<br />
<br />
(1) Environment set-up<br />
set KRB_INSTALL_DIR=/path/to/an/obj/dir<br />
[set MIT_INTERNAL=1]<br />
[set NODEBUG=1]<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x86 [/release]<br />
set CPU=i386<br />
(2) Build the 32-bit binaries<br />
cd /path/to/krb5-tree/src<br />
[nmake clean]<br />
nmake -f Makefile.in prep-windows<br />
nmake<br />
nmake install<br />
(3) Build 32-bit installer<br />
cd windows/installer/wix<br />
[nmake clean]<br />
nmake<br />
rename kfw.msi kfw32.msi<br />
(4) 64-bit build -- NOTE: don't delete the install directory from the 32-bit build; the 32-bit DLLs are needed by the 64-bit installer<br />
\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd /x64 [/release]<br />
set CPU=AMD64<br />
cd /path/to/krb5-tree/src<br />
nmake clean<br />
nmake -f Makefile.in prep-windows [?]<br />
nmake<br />
nmake install<br />
(5) Build 64-bit installer<br />
cd windows/installer/wix<br />
nmake clean<br />
nmake<br />
rename kfw.msi kfw64.msi<br />
<br />
Code signing<br />
<br />
signtool sign /a /t http://timestamp.verisign.com/scripts/timstamp.dll foo.msi<br />
<br />
You might need to add <code>/i Verisign</code> or something to select the right signing cert.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Ops_feedback_teleconference&diff=5605Ops feedback teleconference2016-02-29T21:52:41Z<p>TomYu: </p>
<hr />
<div>A monthly public Kerberos operations/administration teleconference call takes place the first Tuesday of each month at 13:00 (1:00pm) US Eastern Time. This is an opportunity for operators or administrators of Kerberos deployments to share their Kerberos operational experiences with Kerberos developers and each other. Although the primary developers in attendance are developers of MIT Kerberos, as a Consortium activity, we welcome discussion of experiences that operators or administrators have with other implementations.<br />
<br />
== Topics ==<br />
<br />
=== Proposed recurring topics ===<br />
<br />
* What do you wish you knew when you started working with Kerberos but had trouble discovering?<br />
* What Kerberos-related tasks do you find difficult or impossible that you wish were easier?<br />
<br />
=== Proposed topics for 2016-03-01 ===<br />
<br />
* [[Roadmap]] feedback and feature requests (see also https://ist-jira.atlassian.net/issues/?filter=16402)<br />
<br />
=== Future proposed topics ===<br />
<br />
To suggest additional topics, please send email to tlyu@mit.edu.<br />
<br />
== Notes ==<br />
<br />
<categorytree hideroot=on depth=3 mode=pages>Ops_feedback_notes</categorytree><br />
<br />
== Conference info ==<br />
<br />
Audio conference:<br />
: US Toll Number: +1-617-324-0000<br />
: Access code:640 256 582<br />
<br />
For the password to access the online meeting, e.g., if you want to use your computer for audio, please check the kerberos@mit.edu mailing list on the day of the meeting.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=KfW_UAC_interactions&diff=5604KfW UAC interactions2016-02-26T21:05:28Z<p>TomYu: /* Troubleshooting */</p>
<hr />
<div>This page attempts to characterize what we know about KfW interactions with UAC.<br />
<br />
==TGT-less API ccache==<br />
<br />
"Matching credential not found" from gss_init_sec_context<br />
<br />
Conditions:<br />
<br />
* WIN.MIT.EDU domain joined Windows workstation<br />
* domain user with local Administrator rights logs in<br />
* UAC is active<br />
* ms2mit.exe runs from the login scripts<br />
* user hasn't set a default ccache location for KfW in the registry HKCU\Software\MIT\Kerberos5\ccname? maybe also HKLM<br />
<br />
The result is an API: ccache with no TGTs that contains only the service tickets that existed in the LSA ccache at the time ms2mit.exe ran. This leads to cryptic errors when running SAPgui, etc. and no prompting by Leash for a password to get fresh tickets. (If the API: ccache is empty, Leash should prompt.) We believe this is because the LSA doesn't allow direct access to TGTs when an admin user is logged in with UAC active.<br />
<br />
The Windows LSA apparently creates two sets of access tokens (Kerberos credentials? how equivalent are they?) when a domain user with local Administrator rights logs in. One set has full Administrator rights on the local machine, and the other has those rights filtered (presumably by filtering the PAC? See https://support.microsoft.com/en-us/kb/937624 but it's not very clear due to vague terminology). Allowing access to the TGT session key in a non-elevated user session might allow a user to get a ticket with an unfiltered PAC and thereby gain access to unrestricted local Administrator rights while bypassing UAC.<br />
<br />
Leash has some code to copy the LSA creds to the API: ccache during startup, but it seems to notice when the TGT session key is unavailable and refuses to copy anything. ms2mit.exe apparently uses different logic and copies all the existing service tickets but not the (inaccessible) TGT. In theory this means that not running ms2mit.exe will cause something mostly reasonable to happen: domain users without local Administrator rights get a usable API: ccache, and users with local Administrator rights get an empty API: ccache and a password prompt. Unfortunately, when Richard disabled running ms2mit.exe in the logon script, some users reported problems. Were these running an older KfW release that had different Leash startup logic for copying LSA creds?<br />
<br />
TODO:<br />
<br />
Investigate how the LSA cache behaves in a machine not joined to the WIN domain. Such a machine might not know how to contact ATHENA realm KDCs or how to do cross-realm to WIN correctly (this is highly speculative).<br />
<br />
==Popup kinit failure==<br />
<br />
* Popup from Leash displays, prompting for Kerberos password<br />
* Type password<br />
* Get "Couldn't inquire DEFAULT INITIATING credentials" from gss_inquire_cred<br />
<br />
This seems to happen when<br />
<br />
* the registry key HKCU\Software\MIT\Kerberos5\ccname isn't set (nor its HKLM version)<br />
* the API: ccache is empty (or expired?)<br />
* user is in the local admin group<br />
* UAC is active<br />
<br />
==Troubleshooting==<br />
<br />
Check whether the user is in the local Administrators group:<br />
<br />
net localgroup Administrators<br />
<br />
or<br />
<br />
whoami /groups<br />
<br />
when logged in as the user.<br />
<br />
Look for WIN\username or WIN\groupname (where username is the user's account name, and groupname is the name of a group the user belongs to).<br />
<br />
Check the default ccache name:<br />
<br />
reg query HKCU\Software\MIT\Kerberos5 /v ccname<br />
reg query HKLM\Software\MIT\Kerberos5 /v ccname<br />
<br />
Also running<br />
<br />
"C:\Program Files\MIT\Kerberos\bin\klist.exe" -A<br />
<br />
and looking at whether the MSLSA: ccache is lacking krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU is useful. On some machines, it's necessary to give the full path to the KfW klist because there's a Windows native klist program that behaves differently.</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=Release_engineering_notes&diff=5603Release engineering notes2016-02-25T23:29:32Z<p>TomYu: </p>
<hr />
<div>==Required manual steps==<br />
<br />
===Pre-mkrel===<br />
<br />
* check copyright years in project-wide stuff<br />
* make depend<br />
* update patchlevel.h<br />
* regenerate manpages<br />
* regenerate localization template<br />
* update README<br />
** dates<br />
** changes<br />
** contributors<br />
<br />
===Post-mkrel===<br />
<br />
* PGP sign<br />
* generate branded HTML docs<br />
* edit web pages<br />
* send announcement</div>TomYuhttps://k5wiki.kerberos.org/wiki?title=KfW_UAC_interactions&diff=5600KfW UAC interactions2016-02-24T19:42:35Z<p>TomYu: </p>
<hr />
<div>This page attempts to characterize what we know about KfW interactions with UAC.<br />
<br />
==TGT-less API ccache==<br />
<br />
"Matching credential not found" from gss_init_sec_context<br />
<br />
Conditions:<br />
<br />
* WIN.MIT.EDU domain joined Windows workstation<br />
* domain user with local Administrator rights logs in<br />
* UAC is active<br />
* ms2mit.exe runs from the login scripts<br />
* user hasn't set a default ccache location for KfW in the registry HKCU\Software\MIT\Kerberos5\ccname? maybe also HKLM<br />
<br />
The result is an API: ccache with no TGTs that contains only the service tickets that existed in the LSA ccache at the time ms2mit.exe ran. This leads to cryptic errors when running SAPgui, etc. and no prompting by Leash for a password to get fresh tickets. (If the API: ccache is empty, Leash should prompt.) We believe this is because the LSA doesn't allow direct access to TGTs when an admin user is logged in with UAC active.<br />
<br />
The Windows LSA apparently creates two sets of access tokens (Kerberos credentials? how equivalent are they?) when a domain user with local Administrator rights logs in. One set has full Administrator rights on the local machine, and the other has those rights filtered (presumably by filtering the PAC? See https://support.microsoft.com/en-us/kb/937624 but it's not very clear due to vague terminology). Allowing access to the TGT session key in a non-elevated user session might allow a user to get a ticket with an unfiltered PAC and thereby gain access to unrestricted local Administrator rights while bypassing UAC.<br />
<br />
Leash has some code to copy the LSA creds to the API: ccache during startup, but it seems to notice when the TGT session key is unavailable and refuses to copy anything. ms2mit.exe apparently uses different logic and copies all the existing service tickets but not the (inaccessible) TGT. In theory this means that not running ms2mit.exe will cause something mostly reasonable to happen: domain users without local Administrator rights get a usable API: ccache, and users with local Administrator rights get an empty API: ccache and a password prompt. Unfortunately, when Richard disabled running ms2mit.exe in the logon script, some users reported problems. Were these running an older KfW release that had different Leash startup logic for copying LSA creds?<br />
<br />
TODO:<br />
<br />
Investigate how the LSA cache behaves in a machine not joined to the WIN domain. Such a machine might not know how to contact ATHENA realm KDCs or how to do cross-realm to WIN correctly (this is highly speculative).<br />
<br />
==Popup kinit failure==<br />
<br />
* Popup from Leash displays, prompting for Kerberos password<br />
* Type password<br />
* Get "Couldn't inquire DEFAULT INITIATING credentials" from gss_inquire_cred<br />
<br />
This seems to happen when<br />
<br />
* the registry key HKCU\Software\MIT\Kerberos5\ccname isn't set (nor its HKLM version)<br />
* the API: ccache is empty (or expired?)<br />
* user is in the local admin group<br />
* UAC is active<br />
<br />
==Troubleshooting==<br />
<br />
Check whether the user is in the local Administrators group:<br />
<br />
net localgroup Administrators<br />
<br />
Look for WIN\username or WIN\groupname (where username is the user's account name, and groupname is the name of a group the user belongs to).<br />
<br />
Check the default ccache name:<br />
<br />
reg query HKCU\Software\MIT\Kerberos5 /v ccname<br />
reg query HKLM\Software\MIT\Kerberos5 /v ccname<br />
<br />
Also running<br />
<br />
"C:\Program Files\MIT\Kerberos\bin\klist.exe" -A<br />
<br />
and looking at whether the MSLSA: ccache is lacking krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU is useful. On some machines, it's necessary to give the full path to the KfW klist because there's a Windows native klist program that behaves differently.</div>TomYu