K5Wiki - User contributions [en]

Kerberos for Windows (KfW) Build Environment

2026-04-22T21:30:17Z

Ghudson:

[[Category: Kerberos for Windows]]
Directions for producing an environment in which to build
Kerberos for Windows version 4.2

* Install 64-bit Windows 10.

* Install Visual Studio 2017 Community.
** Check "Desktop development with C++".
** Check "MFC and ATL support".
** After installing, locate the Visual Studio 2017 menu under the start menu, and pin the x64 and x86 Native Tools Command Prompt entries to the task bar for e

* Install the chocolatey package manager from https://chocolatey.org/install (by pasting the PowerShell command line into an administrative powershell). Install the following packages:

choco install wixtoolset -y
choco install strawberryperl -y
choco install git -y -params '"/GitAndUnixToolsOnPath"'
choco install emacs -y
choco install windbg -y

* Add wix to the path.
** search for "environment" and run "Edit the system environment variables".
** Click "environment variables" (button at bottom)
** click on wix, copy value.
** click on path, click edit, click new, paste value and add "\bin".

* Choose a released version of OpenSSL (called X.Y.Z below) and build it:

cd %homepath%
git clone https://github.com/openssl/openssl
cd openssl
git checkout openssl-X.Y.Z
perl Configure
nmake
nmake install
set OPENSSL_DIR=C:\Program Files\OpenSSL
set OPENSSL_VERSION=X

* Follow the instructions in src/windows/README to perform a build. NODEBUG can be set in the environment ("set NODEBUG=1") to avoid having to specify it on the nmake command line each time. For MIT-specific builds, also "set MIT_INTERNAL=1" or specify it on the nmake command line when building the installer.

* To sign an MSI file:
** Connect a cryptographic token with FIPS support containing a code-signing certificate. If using VMWare Workstation, use VM > Removable Devices to pass through the token, disconnecting it from the host.
** If it is a Yubikey token containing an ECC code-signing certificate, it may be necessary to install the YubiKey Smart Card Minidriver from https://www.yubico.com/support/download/smart-card-drivers-tools/ . Reconnect the Yubikey token after installing.
** Verify that the certificate is visible to Windows using "certutil -store -user my".
** Use the command:

signtool sign /v /d "MIT Kerberos for Windows installer" /a /fd sha256 /tr http://timestamp.comodoca.com /td sha256 kfw.msi

* To obtain a code-signing certificate (these steps are for a Debian-based Linux system):
** Obtain a cryptographic token with FIPS support. These notes assume a YubiKey 5 NFC FIPS token.
** Install the yubikey-manager package.
** Generate a certificate request and attestation file as follows:
ykman piv keys generate -a ECCP384 9a publickey
(return to use default key)
ykman piv keys attest 9a attest.crt
ykman piv certificates request -s "MIT Code Signing" 9a publickey csr
(enter default PIN 123456)
ykman piv certificates export f9 intermediate.crt
cat attest.crt intermediate.crt | base64 > attest.b64
** Send mail to mitcert@mit.edu . They will generate an invitation link to cert-manager.com. When filling out the form, leave the SAN email field blank. Paste the csr file and the attest.b64 file into the form.
** After issuance, choose the "Certificate (w/ issuer after), PEM" link from the resulting email message.
** Import the certificate with "ykman piv certificates import 9a cert.pem" (where "cert.pem" is the downloaded file).

See also https://www.sectigo.com/knowledge-base/detail/Key-Generation-and-Attestation-with-YubiKey .

More general KfW release engineering information at [[Kerberos for Windows Release Engineering]].

2021-12-09T07:15:40Z

Ghudson:

Kerberos Ticket Granting Service (TGS) requests are one of the most complicated areas of processing in MIT krb5, in both the client and the KDC. Here are some notes on the different kind of TGS requests and what considerations must be made when processing them.

==Protocol structure==

Like an AS request, a TGS request contains a KDC-REQ-BODY sequence and a sequence of PA-DATA. One of the pa-data elements will have type PA-TGS-REQ; its value will contain an AP-REQ, the same protocol structure a client would use to authenticate to an application server. The ticket in the AP-REQ is called the "header ticket" within the MIT KDC source code, because {{rfcref|4120}} uses the term "authentication header" to refer to the AP-REQ.

The authenticator in the AP-REQ contains a checksum over the encoding of the body. This checksum need not be keyed, as it is contained within an encrypted payload, but with modern encryption types it is usually a keyed checksum anyway. There is no intrinsic cryptographic binding between other padata elements and the PA-TGS-REQ or the body.

The authenticator in the AP-REQ may contain a subkey, in which case the TGS response should be encrypted in the subkey. Otherwise it should be encrypted in the session key of the header ticket. There are four historical interoperability bugs affecting the use of subkeys in TGS requests, as described here:

https://mailarchive.ietf.org/arch/msg/krb-wg/DD8CFMuWiHJhkkoHGbjx0Z1dpKo
https://mailarchive.ietf.org/arch/msg/krb-wg/4qhYxn7iovCnfsHL8wmim7-8Tq0
https://mailarchive.ietf.org/arch/msg/krb-wg/hl6PvUz94IQMFadSybnjGYeBCCE

TGS requests may use FAST implicit armor ({{rfcref|6113}} section 5.4). In this case one of the pa-data elements will have type PA-FX-FAST and its value will contain a second copy of the TGS request encrypted in a key derived from the subkey (which must be present) and the ticket session key.

==Normal TGS requests==

For the purposes of this article, a TGS request is considered "normal" if it:

* does not have any of the forwarded, proxy, renew, validate, enc-tkt-in-skey, or cname-in-addl-tkt options
* does not contain PA-FOR-USER or PA_S4U_X509_USER pa-data.

The header ticket for a normal TGS request server have an sname field of krbtgt/THIS.REALM, where THIS.REALM must match the realm field of the TGS request. If the header ticket is a cross-realm TGT (the ticket's srealm field is some OTHER.REALM different from THIS.REALM), the ticket's crealm must also be different from THIS.REALM; this is called the "lineage check", and ensures that foreign realms cannot issue tickets for local users. The KDC also (unless requested not to) checks the transited list in the ticket to ensure that OTHER.REALM has the authority to issue tickets for the realm of the header ticket client, and adds OTHER.REALM to the transited list of the issued ticket if it does not match the realm of the header ticket client.

If the requested server is a TGS principal for a different realm, the KDC may issue a ticket to an alternative TGS principal for an intermediate realm instead. If the requested server is not a TGS server but the request has the "canonicalize" KDC option set ({{rfcref|6803}} section 3), the KDC may issue a ticket to an outgoing TGS principal; this is called a "referral".

For local clients, some KDC implementations look up the client DB entry and apply the entry's policy in case it has changed (e.g. the account has been revoked). The MIT krb5 KDC does not currently do this.

It is possible for an otherwise normal TGS request to be part of a cross-realm Resource-Based Constrained Delegation (RBCD) operation transiting through this realm. In this case, the header ticket will be a cross-realm TGT, the request server will be a cross-realm TGS, the header ticket PAC will contain an S4U_DELEGATION_INFO buffer giving the ticket client as the last transited service, and the PAC_CLIENT_INFO buffer will contain a realm part in the name. These requests can be processed the same way as a normal TGS request, but when issuing a PAC for the resulting ticket the KDC must copy the PAC_CLIENT_INFO and S4U_DELEGATION_INFO buffers from the header ticket.

==Ticket modification requests==

A ticket modification request has the forwarded, proxy, renew, or validate option. The header ticket is not required to be a TGT, and must not be a TGT if the proxy option is requested. The request sname must match the ticket sname, and the KDC must not be issuing a referral. The header ticket must have a flag corresponding to the requested option (forwardable for forwarded, etc.) The issued ticket will be similar in most respects to the header ticket, except for the addresses, validity times, and invalid flag as indicated by the request option.

==User-to-user requests==

If the enc-tkt-in-skey option is requested, the request must contain a second ticket in the additional-tickets field. The second ticket must be a local-realm TGT for the server realm (krbtgt/THIS.REALM@THIS.REALM), and the second ticket cname and crealm must match the request sname and realm. The request is processed similarly to a normal request, but the resulting ticket will be encrypted in the session key of the second ticket, and will have a session key of the same type as the second ticket's. User-to-user requests cannot generate referrals.

==S4U2Self (protocol transition) requests==

If the request pa-data contains an element of type PA-FOR-USER or PA_S4U_X509_USER or both, it is a request to issue a ticket from a named user (known as the "subject") to the requesting service. The subject may be identified by principal or by X.509 certificate. S4U2Self requests do not require special privileges, although in some cases the forwardable flag will be cleared on the resulting ticket. S4U2Self requests must not contain any options for other kinds of special TGS requests (ticket modification, user-to-user, and S4U2Proxy).

For a local-realm S4U2Self requests, the request server must match the header ticket client, although they may use different aliases for the same principal. A PAC must be present in the header ticket, although it is not used as a basis for the PAC in the issued ticket. The subject is looked up in the database, checked for policy constraints, and a PAC is issued for it as it would be for an AS request. Authentication indicators are not copied from the header ticket, as there was no actual authentication of the subject.

For cross-realm S4U2Self scenarios, there are four different kinds of requests:

1. Zero or more AS requests to determine the subject realm, if it is not already known. These may be ordinary AS requests, but they may also contain PA_S4U_X509_USER if the user is identified by a certificate. The requesting service begins at the service realm and follows the chain of KDC_ERR_WRONG_REALM errors until a KDC_ERR_PREAUTH_REQUIRED error is received or a ticket is issued, indicating that the subject realm is known. The requesting server then obtains a cross-realm TGT to the subject realm using ordinary TGS requests.

2. A cross-realm S4U2Self request to the subject realm. Since the requesting service does not live in this realm, the request server will contain the representation of a requesting service as an enterprise principal. As for a local S4U2Self request, the subject realm KDC looks up the subject in the database, checks it for policy constraints, and constructs a PAC for the subject. Unlike a local request, the PAC_CLIENT_INFO name in the PAC will contain an "@REALM" suffix identifying the subject realm, and the KDC issues a referral TGT back towards the service realm. The reply includes PA_S4U_X509_USER naming the subject principal, in case a certificate was used to identify it.

3. Zero or more cross-realm S4U2Self requests to intermediate realms along the path back to the service realm, each resulting in a referral TGT. The S4U2Self padata in these requests must contain the subject principal name; the subject can no longer be identified by certificate at this step. As in step 2, the PAC in the issued referral TGTs must be for the subject and must contain an "@REALM" suffix in the PAC_CLIENT_INFO name.

4. A cross-realm S4U2Self request to the service realm. This type of request would ordinarily fail the lineage check (as the client is in the local realm and the TGT was issued by another realm), so S4U2Self requests are excepted from this check. The service realm KDC issues a ticket from the subject to the requesting service, using the PAC in the the referral ticket as a basis. However, the PAC_CLIENT_INFO name for the PAC does not contain the "@REALM" suffix.

S4U2Self requests override the no_authdata_required flag on the requesting service principal. Although the service may not require authorization data for tickets received from clients, its use of S4U2Self strongly suggests the need for a PAC--either the service plans to make an S4U2Proxy request, or it has a special need to inspect the PAC for a subject.

If the requesting service has any outgoing constrained delegation privileges, but does not have the ok_to_auth_as_delegate principal flag, then the forwardable ticket flag will be suppressed on tickets issued to it via S4U2Self. The intent is to prevent the use of S4U2Self-issued tickets as S4U2Proxy evidence tickets without this extra privilege when outgoing authorizations are used (but not when the delegation is allowed by an incoming authorization on the delegation target).

==S4U2Proxy (constrained delegation) requests==

If the cname-in-addl-tkt option is requested, the request is for a ticket from some client (known here as the "subject") to another service. The request must contain a second ticket (known as the "subject ticket" or "evidence ticket") in the additional-tickets field to identify the subject. The subject ticket must have the forwardable flag set. The request must not contain any options or padata for other kinds of special TGS requests (ticket modification, user-to-user, or S4U2Self). S4U2Proxy operations require special privileges, which may be modeled as outgoing delegation privileges on the requesting service or incoming delegation privileges on the delegation target. When incoming delegation privileges are used, the operation is known as resource-based constrained delegation (RBCD) and the delegation target may be in a different realm from the requesting service. Otherwise, the requesting service and delegation target must be in the same realm.

There are three parties to an S4U2Proxy operation:

1. The subject, which will be the cname and crealm of the resulting ticket. This party may also be known as the "client", although that term may be confused for the requesting service. For a local-realm S4U2Proxy or initial RBCD request, this is the client of the subject ticket. For a cross-realm RBCD request, the subject is identified by the PAC in the subject ticket.

2. The requesting service, as give by the client of the header ticket. This may also be known as the impersonator.

3. The delegation target, which will be the sname and realm of the resulting ticket. This party may also be known as the "resource", the "server" (because it is given by the sname and realm of the KDC request), the "proxy target", or (particularly in Microsoft documentation) just the "proxy". Experience has shown that the term "proxy" is easily confused with the impersonator, so the MIT implementation uses this term sparingly. The delegation target must not be a TGS name.

A PAC must be present in both the header ticket and subject ticket. For a cross-realm RBCD request, the PAC must contain an S4U_DELEGATION_INFO buffer with the requesting service as the last transited_service and the delegation target as the proxy_target, and an "@REALM" suffix in the PAC_CLIENT_INFO name. For a local S4U2Proxy request, the PAC must be for the second ticket client. The PAC in the header ticket must be for the requesting service.

For a local-realm or initial RBCD request, the KDC adds S4U_DELEGATION_INFO to the PAC in the issued service ticket or referral TGT. Any transited services specified in the subject PAC's delegation info (if it had one) are copied, and the requesting service is added to the end. The proxy_target field is set to the delegation target. Final RBCD requests verify and copy delegation info from the subject PAC without modifying it.

==References==

S4U2Self and S4U2Proxy are fully specified in [https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94 [MS-SFU]].

PACs are specified in [https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962 [MS-PAC]].

TGS Requests

2021-12-09T06:36:03Z

Ghudson:

Kerberos Ticket Granting Service (TGS) requests are one of the most complicated areas of processing in MIT krb5, in both the client and the KDC. Here are some notes on the different kind of TGS requests and what considerations must be made when processing them.

==Protocol structure==

Like an AS request, a TGS request contains a KDC-REQ-BODY sequence and a sequence of PA-DATA. One of the pa-data elements will have type PA-TGS-REQ; its value will contain an AP-REQ, the same protocol structure a client would use to authenticate to an application server. The ticket in the AP-REQ is called the "header ticket" within the MIT KDC source code, because {{rfcref|4120}} uses the term "authentication header" to refer to the AP-REQ.

The authenticator in the AP-REQ contains a checksum over the encoding of the body. This checksum need not be keyed, as it is contained within an encrypted payload, but with modern encryption types it is usually a keyed checksum anyway. There is no intrinsic cryptographic binding between other padata elements and the PA-TGS-REQ or the body.

The authenticator in the AP-REQ may contain a subkey, in which case the TGS response should be encrypted in the subkey. Otherwise it should be encrypted in the session key of the header ticket. There are four historical interoperability bugs affecting the use of subkeys in TGS requests, as described here:

https://mailarchive.ietf.org/arch/msg/krb-wg/DD8CFMuWiHJhkkoHGbjx0Z1dpKo
https://mailarchive.ietf.org/arch/msg/krb-wg/4qhYxn7iovCnfsHL8wmim7-8Tq0
https://mailarchive.ietf.org/arch/msg/krb-wg/hl6PvUz94IQMFadSybnjGYeBCCE

TGS requests may use FAST implicit armor ({{rfcref|6113}} section 5.4). In this case one of the pa-data elements will have type PA-FX-FAST and its value will contain a second copy of the TGS request encrypted in a key derived from the subkey (which must be present) and the ticket session key.

==Types of TGS requests==

* Normal

* Ticket modification

* User-to-user

* S4U2Self (aka "protocol transition")

* S4U2Proxy (aka "constrained delegation"): if the CNAME-IN-ADDL-TICKET option is requested, the request body must contain an additional ticket (called the "evidence ticket") from a user to the requesting service--or, for a cross-realm request, a cross-TGT containing a PAC or equivalent authorization data for a user. If delegation is allowed to the requested server, the KDC issues a ticket from the evidence ticket client (or the client named in the PAC) to the requested server. S4U2Proxy is specified in the same document as S4U2Self.

==Normal TGS requests==

For the purposes of this article, a TGS request is considered "normal" if it:

* does not have any of the forwarded, proxy, renew, validate, enc-tkt-in-skey, or cname-in-addl-tkt options
* does not contain PA-FOR-USER or PA_S4U_X509_USER pa-data.

The header ticket for a normal TGS request server have an sname field of krbtgt/THIS.REALM, where THIS.REALM must match the realm field of the TGS request. If the header ticket is a cross-realm TGT (the ticket's srealm field is some OTHER.REALM different from THIS.REALM), the ticket's crealm must also be different from THIS.REALM; this is called the "lineage check", and ensures that foreign realms cannot issue tickets for local users. The KDC also (unless requested not to) checks the transited list in the ticket to ensure that OTHER.REALM has the authority to issue tickets for the realm of the header ticket client, and adds OTHER.REALM to the transited list of the issued ticket if it does not match the realm of the header ticket client.

If the requested server is a TGS principal for a different realm, the KDC may issue a ticket to an alternative TGS principal for an intermediate realm instead. If the requested server is not a TGS server but the request has the "canonicalize" KDC option set ({{rfcref|6803}} section 3), the KDC may issue a ticket to an outgoing TGS principal; this is called a "referral".

For local clients, some KDC implementations look up the client DB entry and apply the entry's policy in case it has changed (e.g. the account has been revoked). The MIT krb5 KDC does not currently do this.

It is possible for an otherwise normal TGS request to be part of a cross-realm Resource-Based Constrained Delegation (RBCD) operation transiting through this realm. In this case, the header ticket will be a cross-realm TGT, the request server will be a cross-realm TGS, the header ticket PAC will contain an S4U_DELEGATION_INFO buffer giving the ticket client as the last transited service, and the PAC_CLIENT_INFO buffer will contain a realm part in the name. These requests can be processed the same way as a normal TGS request, but when issuing a PAC for the resulting ticket the KDC must copy the PAC_CLIENT_INFO buffer from the header ticket rather than creating one for the ticket client.

==Ticket modification requests==

A ticket modification request has the forwarded, proxy, renew, or validate option. The header ticket is not required to be a TGT, and must not be a TGT if the proxy option is requested. The request sname must match the ticket sname, and the KDC must not be issuing a referral. The header ticket must have a flag corresponding to the requested option (forwardable for forwarded, etc.) The issued ticket will be similar in most respects to the header ticket, except for the addresses, validity times, and invalid flag as indicated by the request option.

==User-to-user requests==

If the enc-tkt-in-skey option is requested, the request must contain a second ticket in the additional-tickets field. The second ticket must be a local-realm TGT for the server realm (krbtgt/THIS.REALM@THIS.REALM), and the second ticket cname and crealm must match the request sname and realm. The request is processed similarly to a normal request, but the resulting ticket will be encrypted in the session key of the second ticket, and will have a session key of the same type as the second ticket's. User-to-user requests cannot generate referrals.

==S4U2Self (protocol transition) requests==

If the request pa-data contains an element of type PA-FOR-USER or PA_S4U_X509_USER or both, it is a request to issue a ticket from a named user (known as the "subject") to the requesting service. The subject may be identified by principal or by X.509 certificate. S4U2Self requests do not require special privileges, although in some cases the forwardable flag will be cleared on the resulting ticket. S4U2Self requests must not contain any options for other kinds of special TGS requests (ticket modification, user-to-user, and S4U2Proxy).

For a local-realm S4U2Self requests, the request server must match the header ticket client, although they may use different aliases for the same principal. A PAC must be present in the header ticket, although it is not used as a basis for the PAC in the issued ticket. The subject is looked up in the database, checked for policy constraints, and a PAC is issued for it as it would be for an AS request. Authentication indicators are not copied from the header ticket, as there was no actual authentication of the subject.

For cross-realm S4U2Self scenarios, there are four different kinds of requests:

1. Zero or more AS requests to determine the subject realm, if it is not already known. These may be ordinary AS requests, but they may also contain PA_S4U_X509_USER if the user is identified by a certificate. The requesting service begins at the service realm and follows the chain of KDC_ERR_WRONG_REALM errors until a KDC_ERR_PREAUTH_REQUIRED error is received or a ticket is issued, indicating that the subject realm is known. The requesting server then obtains a cross-realm TGT to the subject realm using ordinary TGS requests.

2. A cross-realm S4U2Self request to the subject realm. Since the requesting service does not live in this realm, the request server will contain the representation of a requesting service as an enterprise principal. As for a local S4U2Self request, the subject realm KDC looks up the subject in the database, checks it for policy constraints, and constructs a PAC for the subject. Unlike a local request, the PAC_CLIENT_INFO name in the PAC will contain an "@REALM" suffix identifying the subject realm, and the KDC issues a referral TGT back towards the service realm. The reply includes PA_S4U_X509_USER naming the subject principal, in case a certificate was used to identify it.

3. Zero or more cross-realm S4U2Self requests to intermediate realms along the path back to the service realm, each resulting in a referral TGT. The S4U2Self padata in these requests must contain the subject principal name; the subject can no longer be identified by certificate at this step. As in step 2, the PAC in the issued referral TGTs must be for the subject and must contain an "@REALM" suffix in the PAC_CLIENT_INFO name.

4. A cross-realm S4U2Self request to the service realm. This type of request would ordinarily fail the lineage check (as the client is in the local realm and the TGT was issued by another realm), so S4U2Self requests are excepted from this check. The service realm KDC issues a ticket from the subject to the requesting service, using the PAC in the the referral ticket as a basis. However, the PAC_CLIENT_INFO name for the PAC does not contain the "@REALM" suffix.

S4U2Self requests override the no_authdata_required flag on the requesting service principal. Although the service may not require authorization data for tickets received from clients, its use of S4U2Self strongly suggests the need for a PAC--either the service plans to make an S4U2Proxy request, or it has a special need to inspect the PAC for a subject.

If the requesting service has any outgoing constrained delegation privileges, but does not have the ok_to_auth_as_delegate principal flag, then the forwardable ticket flag will be suppressed on tickets issued to it via S4U2Self. The intent is to prevent the use of S4U2Self-issued tickets as S4U2Proxy evidence tickets without this extra privilege when outgoing authorizations are used (but not when the delegation is allowed by an incoming authorization on the delegation target).

S4U2Self is fully specified in [http://msdn.microsoft.com/en-us/library/cc246071(PROT.13).aspx [MS-SFU]].

TGS Requests

2021-12-09T01:07:38Z

Ghudson:

TGS Requests

2021-12-09T00:45:49Z

Ghudson:

Kerberos.org server configuration

2021-08-06T16:40:35Z

Ghudson: /* BIND configuration */

This page documents the service configuration on kerberos.org (current canonical name kerborg-prod-app-2.mit.edu), which runs a web server, a wiki, and a DNS name server.

==Packages==

The apache2, bind9, certbot, mediawiki, and python3-certbot-apache packages are required.

==Web server configuration==

The static web page content is located in /var/www.

The Apache HTTP server configuration can be found in the krbdev-services repository under kerborg-apache. kerborg.cnf should be installed in /etc/ssl/private; the rest go in /etc/apache2/sites-available. Run the following commands to enable the correct configuration files:

a2ensite 000-default-kerberos-org.conf
a2ensite k5wiki.conf
a2dissite 000-default.conf
a2enmod rewrite
a2enmod ssl

The letsencrypt TLS certificate is generated using certbot:

certbot --apache -d 'kerberos.org,www.kerberos.org,k5wiki.kerberos.org,test.kerberos.org,www.test.kerberos.org,k5wiki.test.kerberos.org,kerberos.net,www.kerberos.net' certonly

letsencrypt certificates only last 90 days, but a systemd timer installed by the certbot package will automatically renew the certificate when it approaches expiration.

==Mediawiki configuration==

/etc/mediawiki/LocalSettings.php and /etc/mediawiki/Secrets.php contain the wiki configuration. Secrets.php must be readable by the web server; this is currently enabled by making it more 640 and owned by group www-data.

The wiki contents are stored in a MySQL database named "wikidb". This can be dumped with "mysqldump --databases wikidb > /somepath" and loaded with "mysql < /somepath".

A MySQL user named "wikiuser" must be created to access the database. To create it run the following commands inside mysql:

create user wikiuser@localhost identified by '<password>';
grant all privileges on `wikidb`.* to 'wikiuser'@'localhost';

Use the password from /etc/mediawiki/Secrets.php.

If migrating to a server with a new version of Mediawiki, the database must be upgraded. Navigate to /wm-config on the new server and follow instructions.

==Database backups==

Install /mit/ops/services/mysql/mysqlbackup_java.sh in /usr/local/sbin and make it mode 755. Modify the script to use /bin/bzip2 instead of /usr/bin/bzip2, and delete the three java invocations (which are for monitoring).

/usr/local/etc/mysqlbackup_java.conf contains the database password (PASS=xxxxx) and specifies COMPRESS=yes. Make it mode 600.

Create a MySQL user for backups by running the following within mysql:

create user 'dba-backup'@localhost identified by '<password>';
grant select, process, file, lock tables, show view on *.* to 'dba-backup'@'localhost;

Add the following root cron job:

00 23 * * * /usr/local/sbin/mysqlbackup_java.sh >/dev/null 2>&1

==BIND configuration==

The bind9 configuration files can be found in krbdev-services under bind. They should be installed under /etc/bind. "rndc reload" will restart the runing named with the changed configuration. If it is necessary to edit any of the zone files, be sure to update the serial number in the SOA record to the current date followed by "00" (or "01" etc. for successive edits in the same day).

If the IP address if kerberos.org needs to be changed, the glue record at hover.com must be updated. In the current Hover UI, glue records can be found under "advanced". The transfer lock on the domain must be temporarily disabled (via the Overview screen) to update glue records. Make sure to edit the records for kerberos.net as well as kerberos.org.

RT server configuration

2021-06-01T23:52:38Z

Ghudson: /* Testing */

This page contains notes on the setup of the MIT krb5 RT server. The current server is krbdev.mit.edu (canonical name kerborg-prod-app-1.mit.edu), which runs Ubuntu 20.04.

==Packages==

In Ubuntu 20.04, the request-tracker4 package contains a suitable version of RT. This package will ask some questions at installation time:

* RT site name: krbdev.mit.edu
* handle RT_SiteConfig.pm permissions: yes
* use dbconfig-common: no

The data in RT is stored in a PostgreSQL database. The postgresql Ubuntu package will install the recommended version of PostgreSQL for the current Ubuntu version.

The mail interface to RT is handled by Postfix, so the postfix package is required. The libsendmail-pmilter-perl package is required for the custom milter script.

The web front end to RT is an Apache2 web server, so the apache2 package is required. RT uses a FastCGI server, so the libapache2-mod-fcgid package is required.

The server host acts as an authoritative name server for the kerberos.org zone, so the bind9 package must be installed.

In sum, the following packages must be installed on the RT server:

apache2
bind9
libapache2-mod-fcgid
libsendmail-pmilter-perl
perl
perl-base
postfix
postgresql
request-tracker4

==User accounts==

The postgresql package will create a postgres user account.

The following user accounts and group entries must be created manually:

* group rt
* user rtcvs: primary group rt, homedir /var/rt2, shell /bin/sh
* user rt: primary group rt, homedir /var/rt2, shell /bin/false

These accounts could be created with:

groupadd -r rt
useradd -r -g rt -d /var/rt2 rtcvs
useradd -r -m -g rt -d /var/rt2 -s /bin/false rt

Some of the above accounts may be created by ops during provisioning. /var/rt2 and /var/rt2/.ssh must be owned by rtcvs or sshd will reject logins as rtcvs from drugstore.

Create /var/rt2/bin and copy in the following scripts from the krbdev-services repository:

rt-scripts/rt-reserve-ticket
rt-scripts/rtmilter.pl
rt-scripts/krb5-daily.sh
rt-cvs/rt-cvsgate

The scripts and directory should be mode 755 and owned by user rt and group rt.

/var/rt2 should contain an empty .k5login file, managed by ops. It should contain a .ssh/authorized_keys file, managed by ops, containing the krbsnap key from /git/krb5.git/hooks/krbsnap_rsa_key.pub on drugstore.mit.edu.

Create /var/psqlbackups (owned by root).

The rt user account is not actually needed for the current RT installation, and the homedir name /var/rt2 is outdated. The following references need to be taken into account when changing the user and group configuration:

* Both the rt and rtcvs accounts have the homedir /var/rt2.
* krb5-daily.sh references the krbsnap.keytab file and dumps directory in /var/rt2.
* A root cron job runs krb5-daily.sh from /var/rt2.
* A root cron job runs rtmilter on boot from /var/rt2.
* The empty /var/rt2/.k5login file is managed by ops.
* The /var/rt2/.ssh/authorized_keys file is managed by ops.
* On drugstore.mit.edu, the krb5 git repository rt-ssh-cmd config value references the rtcvs user and /var/rt2/bin/rt-cvsgate.
* On drugstore.mit.edu, the krb5 git repository hooks/krb5-rt-id script references the rtcvs user and /var/rt2/bin/rt-reserve-ticket. This script comes from the krbdev-services repository's githooks/krb5-rt-id.
* Some of the same references are present in the krbdev-services repository, but they aren't used.

==RT setup==

Install the RT_SiteConfig.pm file from the krbdev-services repository in /etc/request-tracker4.

In root's crontab file ("crontab -e" as root), add the following to perform daily maintenance:

MAILTO=krbcore-hw@mit.edu
0 3 * * * /usr/sbin/rt-clean-sessions
0 4 * * * /var/rt2/bin/krb5-daily.sh

==PostgreSQL configuration==

Many PostgreSQL files live in directories specific to the PostgreSQL major and minor version, such as /etc/postgresql/8.3 for PostgreSQL 8.3.

The Ubuntu postgresql package will create a "main" cluster with a configuration directory in /etc/postgresql/<version>/main.

In /etc/postgresql/<version>/main/pg_ident.conf, add:

local root root
local root postgres
local root rt_user
local rt rt_user
local rtcvs rt_user
local postfix rt_user
local nobody rt_user
local www-data rt_user

(The entry for "rt" should no longer be needed, but is currently still present.)

In /etc/postgresql/<version>/main/pg_hba.conf, find the line that reads "local all all peer" and add "map=local" to the end, so it reads "local all all peer map=local". Comment out the line that reads "local all postgres peer", despite the warning not to disable it. Run "service postgresql restart" to reread the affected files. Run "psql -Upostgres --list" to verify that the identity map works.

Run "createuser -Upostgres rt_user" to create the rt_user role.

Run "/usr/sbin/rt-setup-database --action create" to create the database, then restore it from a backup with "zcat /path/to/dump.gz | psql -d rt4 -Upostgres"

==Postfix configuration==

By default ops manages Postfix with Puppet. This must be disabled by ops, and the Debian defaults restored by copying /usr/share/postfix/main.cf.debian to /etc/postfix/main.cf and /usr/share/postfix/master.cf.dist to /etc/postfix/master.cf.

At the end of /etc/postfix/main.cf add:

myhostname = krbdev.mit.edu
mydestination = krbdev.mit.edu, kerborg-prod-app-1.mit.edu, localhost.mit.edu, localhost

# Suppress some headers to avoid leaking internal addresses to spammers.
prepend_delivered_header =
enable_original_recipient = no

# RT header milter
smtpd_milters = unix:private/milter

Copy /etc/aliases from the old server. To avoid aiding spammers, its contents are not reproduced here. In particular, /etc/aliases contains an internal address corresponding to the membership of the krb5-bugs-incoming mailman list; revealing this address could allow spammers to bypass moderation of incoming bug reports.

In root's crontab file ("crontab -e" as root):

@reboot /var/rt2/bin/rtmilter.pl /var/spool/postfix/private/milter

Run the command by hand (backgrounded) to start the milter process before the next reboot.

Run "newaliases" and "postfix reload" to pick up the changed configuration.

Make sure rt@kerborg-prod-app-1.mit.edu and rt-comment@kerborg-prod-app-1.mit.edu are authorized as non-member senders at https://mailman.mit.edu:444/mailman/admin/krb5-bugs/privacy/sender .

==Apache httpd configuration==

Create /etc/apache2/ssl.crt and /etc/apache2/ssl.key.

Copy /etc/apache2/ssl.key/server.key and /etc/apache2/ssl.crt/server.crt from the old server, or follow the instructions at http://kb.mit.edu/confluence/display/istcontrib/Obtaining+an+SSL+certificate+for+a+web+server to obtain a new one. server.key and server.crt may be symlinks using whatever scheme seems convenient for renewing certificates every few years.

Install /etc/apache2/ssl.crt/chain.crt from /mit/apache-ssl/certificates/InCommon-chain.crt.txt (requires tokens). Cutting and pasting is effective for transferring certificates as they are represented as short text files.

Install /etc/apache2/ssl.crt/clientCA.crt from /mit/apache-ssl/certificates/mitCAclient.pem (requires tokens).

Install the rt.conf file from the krbdev-services repository as /etc/apache2/sites-available/rt.conf .

Edit /etc/apache2/mods-available/proxy.conf and set:

ProxyVia On

ProxyPass /buildbot/ws ws://krbdev-buildbot.mit.edu:8010/ws
ProxyPassReverse /buildbos/ws ws://krbdev-buildbot.mit.edu:8010/ws
ProxyPass /buildbot/ http://krbdev-buildbot.mit.edu:8010/
ProxyPassReverse /buildbot/ http://krbdev-buildbot.mit.edu:8010/
<Proxy http://krbdev-buildbot.mit.edu:8010/*>
Allow from all
</Proxy>

Edit /etc/apache2/ports.conf and add "Listen 444" in the ssl_module section after "Listen 443".

Clean out /var/www and install index.html and robots.txt from the krbdev-www directory of the krbdev-services repository.

Run:

a2enmod ssl
a2enmod userdir
a2enmod rewrite
a2enmod proxy_http
a2enmod proxy_wstunnel
a2dissite 000-default
a2ensite rt
service apache2 restart

==Testing==

Get a certificate for the new VM's real hostname and temporarily point /etc/apache2/ssl.crt/server.crt at it.

In /etc/request-tracker4/RT_SiteConfig.pm, temporarily set @ReferrerWhitelist to use the real hostname instead of krbdev.mit.edu.

Temporarily set emergency moderation on the krb5-bugs mailing list (at https://mailman.mit.edu:444/mailman/admin/krb5-bugs/general ) to ensure that mail sent to that list as the result of testing is caught in the moderation queue.

Verify that RT displays at https://realhostname/rt and tickets can be accessed. Verify that https://realhostname:444/ works and that a new ticket can be created. Respond to the ticket via email and verify that the response is stored in the ticket.

As root, run /var/rt2/bin/krb5-daily.sh and verify that a dump file appears in /var/psqlbackups.

As rtcvs ("su -s /bin/bash - rtcvs"), run /var/rt2/bin/rt-reserve-ticket and verify that a ticket number is printed.

To test rt-cvsgate, create a test message in /tmp/testmsg like so:

ticket: new
id: NNNN (use the ticket number printed by rt-reserve-ticket above)
subject: rt-cvsgate test
tags: pullup

test commit message

As rtcvs, run "/var/rt2/bin/rt-cvsgate ''username'' < /tmp/testmsg", where ''username'' is an authorized user.

Undo the temporary changes and restore the database from a dump file.

==BIND configuration==

The bind9 configuration files can be found in krbdev-services under bind. They should be installed under /etc/bind. "rndc reload" will restart the runing named with the changed configuration. If it is necessary to edit any of the zone files, be sure to update the serial number in the SOA record to the current date followed by "00" (or "01" etc. for successive edits in the same day).

If the IP address if kerberos.org needs to be changed, the glue record at hover.com must be updated. In the current Hover UI, glue records can be found under "advanced". The transfer lock on the domain must be temporarily disabled (via the Overview screen) to update glue records.

RT server configuration

2021-06-01T23:44:06Z

Ghudson:

This page contains notes on the setup of the MIT krb5 RT server. The current server is krbdev.mit.edu (canonical name kerborg-prod-app-1.mit.edu), which runs Ubuntu 20.04.

==Packages==

In Ubuntu 20.04, the request-tracker4 package contains a suitable version of RT. This package will ask some questions at installation time:

* RT site name: krbdev.mit.edu
* handle RT_SiteConfig.pm permissions: yes
* use dbconfig-common: no

The data in RT is stored in a PostgreSQL database. The postgresql Ubuntu package will install the recommended version of PostgreSQL for the current Ubuntu version.

The mail interface to RT is handled by Postfix, so the postfix package is required. The libsendmail-pmilter-perl package is required for the custom milter script.

The web front end to RT is an Apache2 web server, so the apache2 package is required. RT uses a FastCGI server, so the libapache2-mod-fcgid package is required.

The server host acts as an authoritative name server for the kerberos.org zone, so the bind9 package must be installed.

In sum, the following packages must be installed on the RT server:

apache2
bind9
libapache2-mod-fcgid
libsendmail-pmilter-perl
perl
perl-base
postfix
postgresql
request-tracker4

==User accounts==

The postgresql package will create a postgres user account.

The following user accounts and group entries must be created manually:

* group rt
* user rtcvs: primary group rt, homedir /var/rt2, shell /bin/sh
* user rt: primary group rt, homedir /var/rt2, shell /bin/false

These accounts could be created with:

groupadd -r rt
useradd -r -g rt -d /var/rt2 rtcvs
useradd -r -m -g rt -d /var/rt2 -s /bin/false rt

Some of the above accounts may be created by ops during provisioning. /var/rt2 and /var/rt2/.ssh must be owned by rtcvs or sshd will reject logins as rtcvs from drugstore.

Create /var/rt2/bin and copy in the following scripts from the krbdev-services repository:

rt-scripts/rt-reserve-ticket
rt-scripts/rtmilter.pl
rt-scripts/krb5-daily.sh
rt-cvs/rt-cvsgate

The scripts and directory should be mode 755 and owned by user rt and group rt.

/var/rt2 should contain an empty .k5login file, managed by ops. It should contain a .ssh/authorized_keys file, managed by ops, containing the krbsnap key from /git/krb5.git/hooks/krbsnap_rsa_key.pub on drugstore.mit.edu.

Create /var/psqlbackups (owned by root).

The rt user account is not actually needed for the current RT installation, and the homedir name /var/rt2 is outdated. The following references need to be taken into account when changing the user and group configuration:

* Both the rt and rtcvs accounts have the homedir /var/rt2.
* krb5-daily.sh references the krbsnap.keytab file and dumps directory in /var/rt2.
* A root cron job runs krb5-daily.sh from /var/rt2.
* A root cron job runs rtmilter on boot from /var/rt2.
* The empty /var/rt2/.k5login file is managed by ops.
* The /var/rt2/.ssh/authorized_keys file is managed by ops.
* On drugstore.mit.edu, the krb5 git repository rt-ssh-cmd config value references the rtcvs user and /var/rt2/bin/rt-cvsgate.
* On drugstore.mit.edu, the krb5 git repository hooks/krb5-rt-id script references the rtcvs user and /var/rt2/bin/rt-reserve-ticket. This script comes from the krbdev-services repository's githooks/krb5-rt-id.
* Some of the same references are present in the krbdev-services repository, but they aren't used.

==RT setup==

Install the RT_SiteConfig.pm file from the krbdev-services repository in /etc/request-tracker4.

In root's crontab file ("crontab -e" as root), add the following to perform daily maintenance:

MAILTO=krbcore-hw@mit.edu
0 3 * * * /usr/sbin/rt-clean-sessions
0 4 * * * /var/rt2/bin/krb5-daily.sh

==PostgreSQL configuration==

Many PostgreSQL files live in directories specific to the PostgreSQL major and minor version, such as /etc/postgresql/8.3 for PostgreSQL 8.3.

The Ubuntu postgresql package will create a "main" cluster with a configuration directory in /etc/postgresql/<version>/main.

In /etc/postgresql/<version>/main/pg_ident.conf, add:

local root root
local root postgres
local root rt_user
local rt rt_user
local rtcvs rt_user
local postfix rt_user
local nobody rt_user
local www-data rt_user

(The entry for "rt" should no longer be needed, but is currently still present.)

In /etc/postgresql/<version>/main/pg_hba.conf, find the line that reads "local all all peer" and add "map=local" to the end, so it reads "local all all peer map=local". Comment out the line that reads "local all postgres peer", despite the warning not to disable it. Run "service postgresql restart" to reread the affected files. Run "psql -Upostgres --list" to verify that the identity map works.

Run "createuser -Upostgres rt_user" to create the rt_user role.

Run "/usr/sbin/rt-setup-database --action create" to create the database, then restore it from a backup with "zcat /path/to/dump.gz | psql -d rt4 -Upostgres"

==Postfix configuration==

By default ops manages Postfix with Puppet. This must be disabled by ops, and the Debian defaults restored by copying /usr/share/postfix/main.cf.debian to /etc/postfix/main.cf and /usr/share/postfix/master.cf.dist to /etc/postfix/master.cf.

At the end of /etc/postfix/main.cf add:

myhostname = krbdev.mit.edu
mydestination = krbdev.mit.edu, kerborg-prod-app-1.mit.edu, localhost.mit.edu, localhost

# Suppress some headers to avoid leaking internal addresses to spammers.
prepend_delivered_header =
enable_original_recipient = no

# RT header milter
smtpd_milters = unix:private/milter

Copy /etc/aliases from the old server. To avoid aiding spammers, its contents are not reproduced here. In particular, /etc/aliases contains an internal address corresponding to the membership of the krb5-bugs-incoming mailman list; revealing this address could allow spammers to bypass moderation of incoming bug reports.

In root's crontab file ("crontab -e" as root):

@reboot /var/rt2/bin/rtmilter.pl /var/spool/postfix/private/milter

Run the command by hand (backgrounded) to start the milter process before the next reboot.

Run "newaliases" and "postfix reload" to pick up the changed configuration.

Make sure rt@kerborg-prod-app-1.mit.edu and rt-comment@kerborg-prod-app-1.mit.edu are authorized as non-member senders at https://mailman.mit.edu:444/mailman/admin/krb5-bugs/privacy/sender .

==Apache httpd configuration==

Create /etc/apache2/ssl.crt and /etc/apache2/ssl.key.

Copy /etc/apache2/ssl.key/server.key and /etc/apache2/ssl.crt/server.crt from the old server, or follow the instructions at http://kb.mit.edu/confluence/display/istcontrib/Obtaining+an+SSL+certificate+for+a+web+server to obtain a new one. server.key and server.crt may be symlinks using whatever scheme seems convenient for renewing certificates every few years.

Install /etc/apache2/ssl.crt/chain.crt from /mit/apache-ssl/certificates/InCommon-chain.crt.txt (requires tokens). Cutting and pasting is effective for transferring certificates as they are represented as short text files.

Install /etc/apache2/ssl.crt/clientCA.crt from /mit/apache-ssl/certificates/mitCAclient.pem (requires tokens).

Install the rt.conf file from the krbdev-services repository as /etc/apache2/sites-available/rt.conf .

Edit /etc/apache2/mods-available/proxy.conf and set:

ProxyVia On

ProxyPass /buildbot/ws ws://krbdev-buildbot.mit.edu:8010/ws
ProxyPassReverse /buildbos/ws ws://krbdev-buildbot.mit.edu:8010/ws
ProxyPass /buildbot/ http://krbdev-buildbot.mit.edu:8010/
ProxyPassReverse /buildbot/ http://krbdev-buildbot.mit.edu:8010/
<Proxy http://krbdev-buildbot.mit.edu:8010/*>
Allow from all
</Proxy>

Edit /etc/apache2/ports.conf and add "Listen 444" in the ssl_module section after "Listen 443".

Clean out /var/www and install index.html and robots.txt from the krbdev-www directory of the krbdev-services repository.

Run:

a2enmod ssl
a2enmod userdir
a2enmod rewrite
a2enmod proxy_http
a2enmod proxy_wstunnel
a2dissite 000-default
a2ensite rt
service apache2 restart

==Testing==

Get a certificate for the new VM's real hostname and temporarily point /etc/apache2/ssl.crt/server.crt at it.

In /etc/request-tracker4/RT_SiteConfig.pm, temporarily set @ReferrerWhitelist to use the real hostname instead of krbdev.mit.edu.

Temporarily set emergency moderation on the krb5-bugs mailing list (at https://mailman.mit.edu:444/mailman/admin/krb5-bugs/general ) to ensure that mail sent to that list as the result of testing is caught in the moderation queue.

Verify that RT displays at https://realhostname/rt and tickets can be accessed. Verify that https://realhostname:444/ works and that a new ticket can be created. Respond to the ticket via email and verify that the response is stored in the ticket.

As root, run /var/rt2/bin/krb5-daily.sh and verify that a dump file appears in /var/psqlbackups.

As rtcvs ("su -s /bin/bash - rtcvs"), run /var/rt2/bin/rt-reserve-ticket and verify that a ticket number is printed.

To test rt-cvsgate, create a test message in /tmp/testmsg like so:

id: NNNN (use the ticket number printed by rt-reserve-ticket above)
ticket: new
subject: rt-cvsgate test
tags: pullup

test commit message

As rtcvs, run "/var/rt2/bin/rt-cvsgate ''username'' < /tmp/testmsg", where ''username'' is an authorized user.

Undo the temporary changes and restore the database from a dump file.

==BIND configuration==

The bind9 configuration files can be found in krbdev-services under bind. They should be installed under /etc/bind. "rndc reload" will restart the runing named with the changed configuration. If it is necessary to edit any of the zone files, be sure to update the serial number in the SOA record to the current date followed by "00" (or "01" etc. for successive edits in the same day).

If the IP address if kerberos.org needs to be changed, the glue record at hover.com must be updated. In the current Hover UI, glue records can be found under "advanced". The transfer lock on the domain must be temporarily disabled (via the Overview screen) to update glue records.

RT server configuration

2021-06-01T22:42:39Z

Ghudson:

This page contains notes on the setup of the MIT krb5 RT server. The current server is krbdev.mit.edu (canonical name kerborg-prod-app-1.mit.edu), which runs Ubuntu 20.04.

==Packages==

In Ubuntu 20.04, the request-tracker4 package contains a suitable version of RT. This package will ask some questions at installation time:

* RT site name: krbdev.mit.edu
* handle RT_SiteConfig.pm permissions: yes
* use dbconfig-common: no

The data in RT is stored in a PostgreSQL database. The postgresql Ubuntu package will install the recommended version of PostgreSQL for the current Ubuntu version.

The mail interface to RT is handled by Postfix, so the postfix package is required. The libsendmail-pmilter-perl package is required for the custom milter script.

The web front end to RT is an Apache2 web server, so the apache2 package is required. RT uses a FastCGI server, so the libapache2-mod-fcgid package is required.

The server host acts as an authoritative name server for the kerberos.org zone, so the bind9 package must be installed.

In sum, the following packages must be installed on the RT server:

apache2
bind9
libapache2-mod-fcgid
libsendmail-pmilter-perl
perl
perl-base
postfix
postgresql
request-tracker4

==User accounts==

The postgresql package will create a postgres user account.

The following user accounts and group entries must be created manually:

* group rt
* user rtcvs: primary group rt, homedir /var/rt2, shell /bin/sh
* user rt: primary group rt, homedir /var/rt2, shell /bin/false

These accounts could be created with:

groupadd -r rt
useradd -r -g rt -d /var/rt2 rtcvs
useradd -r -m -g rt -d /var/rt2 -s /bin/false rt

Some of the above accounts may be created by ops during provisioning. /var/rt2 and /var/rt2/.ssh must be owned by rtcvs or sshd will reject logins as rtcvs from drugstore.

Create /var/rt2/bin and copy in the following scripts from the krbdev-services repository:

rt-scripts/rt-reserve-ticket
rt-scripts/rtmilter.pl
rt-scripts/krb5-daily.sh
rt-cvs/rt-cvsgate

The scripts and directory should be mode 755 and owned by user rt and group rt.

/var/rt2 should contain an empty .k5login file, managed by ops. It should contain a .ssh/authorized_keys file, managed by ops, containing the krbsnap key from /git/krb5.git/hooks/krbsnap_rsa_key.pub on drugstore.mit.edu.

Create /var/psqlbackups (owned by root).

The rt user account is not actually needed for the current RT installation, and the homedir name /var/rt2 is outdated. The following references need to be taken into account when changing the user and group configuration:

* Both the rt and rtcvs accounts have the homedir /var/rt2.
* krb5-daily.sh references the krbsnap.keytab file and dumps directory in /var/rt2.
* A root cron job runs krb5-daily.sh from /var/rt2.
* A root cron job runs rtmilter on boot from /var/rt2.
* The empty /var/rt2/.k5login file is managed by ops.
* The /var/rt2/.ssh/authorized_keys file is managed by ops.
* On drugstore.mit.edu, the krb5 git repository rt-ssh-cmd config value references the rtcvs user and /var/rt2/bin/rt-cvsgate.
* On drugstore.mit.edu, the krb5 git repository hooks/krb5-rt-id script references the rtcvs user and /var/rt2/bin/rt-reserve-ticket. This script comes from the krbdev-services repository's githooks/krb5-rt-id.
* Some of the same references are present in the krbdev-services repository, but they aren't used.

==RT setup==

Install the RT_SiteConfig.pm file from the krbdev-services repository in /etc/request-tracker4.

In root's crontab file ("crontab -e" as root), add the following to perform daily maintenance:

MAILTO=krbcore-hw@mit.edu
0 3 * * * /usr/sbin/rt-clean-sessions
0 4 * * * /var/rt2/bin/krb5-daily.sh

==PostgreSQL configuration==

Many PostgreSQL files live in directories specific to the PostgreSQL major and minor version, such as /etc/postgresql/8.3 for PostgreSQL 8.3.

The Ubuntu postgresql package will create a "main" cluster with a configuration directory in /etc/postgresql/<version>/main.

In /etc/postgresql/<version>/main/pg_ident.conf, add:

local root root
local root postgres
local root rt_user
local rt rt_user
local rtcvs rt_user
local postfix rt_user
local nobody rt_user
local www-data rt_user

(The entry for "rt" should no longer be needed, but is currently still present.)

In /etc/postgresql/<version>/main/pg_hba.conf, find the line that reads "local all all peer" and add "map=local" to the end, so it reads "local all all peer map=local". Comment out the line that reads "local all postgres peer", despite the warning not to disable it. Run "service postgresql restart" to reread the affected files. Run "psql -Upostgres --list" to verify that the identity map works.

Run "createuser -Upostgres rt_user" to create the rt_user role.

Run "/usr/sbin/rt-setup-database --action create" to create the database, then restore it from a backup with "zcat /path/to/dump.gz | psql -d rt4 -Upostgres"

==Postfix configuration==

By default ops manages Postfix with Puppet. This must be disabled by ops, and the Debian defaults restored by copying /usr/share/postfix/main.cf.debian to /etc/postfix/main.cf and /usr/share/postfix/master.cf.dist to /etc/postfix/master.cf.

At the end of /etc/postfix/main.cf add:

myhostname = krbdev.mit.edu
mydestination = krbdev.mit.edu, kerborg-prod-app-1.mit.edu, localhost.mit.edu, localhost

# Suppress some headers to avoid leaking internal addresses to spammers.
prepend_delivered_header =
enable_original_recipient = no

# RT header milter
smtpd_milters = unix:private/milter

Copy /etc/aliases from the old server. To avoid aiding spammers, its contents are not reproduced here. In particular, /etc/aliases contains an internal address corresponding to the membership of the krb5-bugs-incoming mailman list; revealing this address could allow spammers to bypass moderation of incoming bug reports.

In root's crontab file ("crontab -e" as root):

@reboot /var/rt2/bin/rtmilter.pl /var/spool/postfix/private/milter

Run the command by hand (backgrounded) to start the milter process before the next reboot.

Run "newaliases" and "postfix reload" to pick up the changed configuration.

Make sure rt@kerborg-prod-app-1.mit.edu and rt-comment@kerborg-prod-app-1.mit.edu are authorized as non-member senders at https://mailman.mit.edu:444/mailman/admin/krb5-bugs/privacy/sender .

==Apache httpd configuration==

Create /etc/apache2/ssl.crt and /etc/apache2/ssl.key.

Copy /etc/apache2/ssl.key/server.key and /etc/apache2/ssl.crt/server.crt from the old server, or follow the instructions at http://kb.mit.edu/confluence/display/istcontrib/Obtaining+an+SSL+certificate+for+a+web+server to obtain a new one. server.key and server.crt may be symlinks using whatever scheme seems convenient for renewing certificates every few years.

Install /etc/apache2/ssl.crt/chain.crt from /mit/apache-ssl/certificates/InCommon-chain.crt.txt (requires tokens). Cutting and pasting is effective for transferring certificates as they are represented as short text files.

Install /etc/apache2/ssl.crt/clientCA.crt from /mit/apache-ssl/certificates/mitCAclient.pem (requires tokens).

Install the rt.conf file from the krbdev-services repository as /etc/apache2/sites-available/rt.conf .

Edit /etc/apache2/mods-available/proxy.conf and set:

ProxyVia On

ProxyPass /buildbot/ws ws://krbdev-buildbot.mit.edu:8010/ws
ProxyPassReverse /buildbos/ws ws://krbdev-buildbot.mit.edu:8010/ws
ProxyPass /buildbot/ http://krbdev-buildbot.mit.edu:8010/
ProxyPassReverse /buildbot/ http://krbdev-buildbot.mit.edu:8010/
<Proxy http://krbdev-buildbot.mit.edu:8010/*>
Allow from all
</Proxy>

Edit /etc/apache2/ports.conf and add "Listen 444" in the ssl_module section after "Listen 443".

Clean out /var/www and install index.html and robots.txt from the krbdev-www directory of the krbdev-services repository.

Run:

a2enmod ssl
a2enmod userdir
a2enmod rewrite
a2enmod proxy_http
a2enmod proxy_wstunnel
a2dissite 000-default
a2ensite rt
service apache2 restart

==Testing==

Get a certificate for the new VM's real hostname and temporarily point /etc/apache2/ssl.crt/server.crt at it.

In /etc/request-tracker4/RT_SiteConfig.pm, temporarily set @ReferrerWhitelist to use the real hostname instead of krbdev.mit.edu.

Temporarily set emergency moderation on the krb5-bugs mailing list (at https://mailman.mit.edu:444/mailman/admin/krb5-bugs/general ) to ensure that mail sent to that list as the result of testing is caught in the moderation queue.

Verify that RT displays at https://realhostname/rt and tickets can be accessed. Verify that https://realhostname:444/ works and that a new ticket can be created. Respond to the ticket via email and verify that the response is stored in the ticket.

As root, run /var/rt2/bin/krb5-daily.sh and verify that a dump file appears in /var/psqlbackups.

As rtcvs ("su -s /bin/bash - rtcvs"), run /var/rt2/bin/rt-reserve-ticket and verify that a ticket number is printed.

To test rt-cvsgate, create a test message in /tmp/testmsg like so:

id: NNNN (use the ticket number printed by rt-reserve-ticket above)
ticket: new
subject: rt-cvsgate test
tags: pullup

test commit message

As rt-cvsgate, run "/var/rt2/bin/rt-cvsgate ''username'' < /tmp/testmsg", where ''username'' is an authorized user.

Undo the temporary changes and restore the database from a dump file.

==BIND configuration==

The bind9 configuration files can be found in krbdev-services under bind. They should be installed under /etc/bind. "rndc reload" will restart the runing named with the changed configuration. If it is necessary to edit any of the zone files, be sure to update the serial number in the SOA record to the current date followed by "00" (or "01" etc. for successive edits in the same day).

If the IP address if kerberos.org needs to be changed, the glue record at hover.com must be updated. In the current Hover UI, glue records can be found under "advanced". The transfer lock on the domain must be temporarily disabled (via the Overview screen) to update glue records.

Developer chat

2021-06-01T22:36:22Z

Ghudson:

MIT Kerberos developers use several venues for instant message chat.

== IRC channels ==

The main IRC channel for MIT Kerberos development is <code>#krbdev</code> on Libera Chat. There is a separate channel, <code>#kerberos</code>, for general Kerberos discussion and support.

For more information about Libera Chat, see https://libera.chat/.

The <code>#krbdev</code> channel is logged at http://colabti.org/irclogger/irclogger_logs/krbdev using the colabti.org service, which generously offers IRC logging to Free / Open Source projects.

The <code>#krbdev</code> channel was previously logged by lopbot, courtesy of Brandon Allbery. These logs are no longer readily available online. Despite the possible existence of logging, please summarize important conversations to more permanent places, such as an appropriate mailing list or wiki page.