aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGreg Hudson <ghudson@mit.edu>2018-09-17 09:59:47 -0400
committerGreg Hudson <ghudson@mit.edu>2018-10-03 12:11:24 -0400
commit4d56fab8385f1deb238bce37673af96df7f89073 (patch)
treecbc7d03e704c07ecd87ef3eb80506645f4b25065
parent3023a7d253c3052897b3d77d2f7ce992ff93e913 (diff)
downloadkrb5-4d56fab8385f1deb238bce37673af96df7f89073.zip
krb5-4d56fab8385f1deb238bce37673af96df7f89073.tar.gz
krb5-4d56fab8385f1deb238bce37673af96df7f89073.tar.bz2
Use the term "replica KDC" in source and docs
ticket: 8738 (new)
-rw-r--r--.gitignore6
-rw-r--r--NOTICE4
-rw-r--r--doc/admin/admin_commands/kadmind.rst30
-rw-r--r--doc/admin/admin_commands/kdb5_util.rst4
-rw-r--r--doc/admin/admin_commands/kprop.rst6
-rw-r--r--doc/admin/admin_commands/kpropd.rst25
-rw-r--r--doc/admin/admin_commands/kproplog.rst18
-rw-r--r--doc/admin/advanced/retiring-des.rst12
-rw-r--r--doc/admin/appl_servers.rst20
-rw-r--r--doc/admin/backup_host.rst22
-rw-r--r--doc/admin/conf_files/kdc_conf.rst12
-rw-r--r--doc/admin/conf_files/krb5_conf.rst4
-rw-r--r--doc/admin/database.rst91
-rw-r--r--doc/admin/install_appl_srv.rst2
-rw-r--r--doc/admin/install_kdc.rst115
-rw-r--r--doc/admin/lockout.rst8
-rw-r--r--doc/admin/realm_config.rst38
-rw-r--r--doc/admin/troubleshoot.rst24
-rw-r--r--doc/build/directory_org.rst2
-rw-r--r--doc/conf.py4
-rw-r--r--doc/iprop-notes.txt48
-rw-r--r--doc/mitK5defaults.rst4
-rw-r--r--doc/mitK5features.rst10
-rw-r--r--doc/notice.rst4
-rw-r--r--src/Makefile.in6
-rw-r--r--src/config-files/services.append2
-rw-r--r--src/configure.in4
-rw-r--r--src/include/iprop_hdr.h2
-rw-r--r--src/include/kdb.h8
-rw-r--r--src/include/osconf.hin2
-rw-r--r--src/kadmin/cli/kadmin.c2
-rw-r--r--src/kadmin/dbutil/dump.c4
-rw-r--r--src/kadmin/dbutil/kdb5_create.c4
-rw-r--r--src/kadmin/server/ipropd_svc.c10
-rw-r--r--src/kprop/Makefile.in (renamed from src/slave/Makefile.in)2
-rw-r--r--src/kprop/deps (renamed from src/slave/deps)0
-rw-r--r--src/kprop/kprop.c (renamed from src/slave/kprop.c)18
-rw-r--r--src/kprop/kprop.h (renamed from src/slave/kprop.h)2
-rw-r--r--src/kprop/kprop_util.c (renamed from src/slave/kprop_util.c)2
-rw-r--r--src/kprop/kpropd.c (renamed from src/slave/kpropd.c)14
-rw-r--r--src/kprop/kpropd_rpc.c (renamed from src/slave/kpropd_rpc.c)0
-rw-r--r--src/kprop/kproplog.c (renamed from src/slave/kproplog.c)2
-rw-r--r--src/kprop/replica_update (renamed from src/slave/kslave_update)14
-rw-r--r--src/lib/kdb/iprop.x4
-rw-r--r--src/lib/kdb/kdb_convert.c12
-rw-r--r--src/lib/kdb/kdb_log.c6
-rw-r--r--src/lib/krb5/krb/gic_keytab.c2
-rw-r--r--src/lib/krb5/krb/gic_pwd.c2
-rw-r--r--src/plugins/kdb/db2/kdb_db2.c10
-rw-r--r--src/tests/dejagnu/config/default.exp81
-rw-r--r--src/tests/dejagnu/krb-standalone/kprop.exp24
-rwxr-xr-xsrc/tests/t_iprop.py270
-rwxr-xr-xsrc/tests/t_kprop.py46
-rw-r--r--src/util/k5test.py16
-rw-r--r--src/util/testrealm.py2
-rw-r--r--src/windows/installer/wix/custom/custom.cpp6
-rw-r--r--src/windows/installer/wix/custom/custom.h2
-rw-r--r--src/windows/winlevel.h3
58 files changed, 551 insertions, 546 deletions
diff --git a/.gitignore b/.gitignore
index 5c80f0a..713d4a6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -415,9 +415,9 @@ local.properties
/src/po/*.mo
-/src/slave/kprop
-/src/slave/kpropd
-/src/slave/kproplog
+/src/kprop/kprop
+/src/kprop/kpropd
+/src/kprop/kproplog
/src/tests/adata
/src/tests/au.log
diff --git a/NOTICE b/NOTICE
index cb6ab46..dcaa5e4 100644
--- a/NOTICE
+++ b/NOTICE
@@ -311,8 +311,8 @@ the following new or changed files:
lib/kdb/kdb_log.c
lib/kdb/kdb_log.h
lib/krb5/error_tables/kdb5_err.et
- slave/kpropd_rpc.c
- slave/kproplog.c
+ kprop/kpropd_rpc.c
+ kprop/kproplog.c
are subject to the following license:
diff --git a/doc/admin/admin_commands/kadmind.rst b/doc/admin/admin_commands/kadmind.rst
index f5b7733..5c99541 100644
--- a/doc/admin/admin_commands/kadmind.rst
+++ b/doc/admin/admin_commands/kadmind.rst
@@ -49,14 +49,14 @@ After the server begins running, it puts itself in the background and
disassociates itself from its controlling terminal.
kadmind can be configured for incremental database propagation.
-Incremental propagation allows slave KDC servers to receive principal
-and policy updates incrementally instead of receiving full dumps of
-the database. This facility can be enabled in the :ref:`kdc.conf(5)`
-file with the **iprop_enable** option. Incremental propagation
-requires the principal ``kiprop/MASTER\@REALM`` (where MASTER is the
-master KDC's canonical host name, and REALM the realm name). In
-release 1.13, this principal is automatically created and registered
-into the datebase.
+Incremental propagation allows replica KDC servers to receive
+principal and policy updates incrementally instead of receiving full
+dumps of the database. This facility can be enabled in the
+:ref:`kdc.conf(5)` file with the **iprop_enable** option. Incremental
+propagation requires the principal ``kiprop/MASTER\@REALM`` (where
+MASTER is the master KDC's canonical host name, and REALM the realm
+name). In release 1.13, this principal is automatically created and
+registered into the datebase.
OPTIONS
@@ -78,10 +78,10 @@ OPTIONS
the server to place itself in the background.
**-proponly**
- causes the server to only listen and respond to Kerberos slave
+ causes the server to only listen and respond to Kerberos replica
incremental propagation polling requests. This option can be used
- to set up a hierarchical propagation topology where a slave KDC
- provides incremental updates to other Kerberos slaves.
+ to set up a hierarchical propagation topology where a replica KDC
+ provides incremental updates to other Kerberos replicas.
**-port** *port-number*
specifies the port on which the administration server listens for
@@ -100,12 +100,12 @@ OPTIONS
**-K** *kprop_path*
specifies the path to the kprop command to use to send full dumps
- to slaves in response to full resync requests.
+ to replicas in response to full resync requests.
**-k** *kprop_port*
- specifies the port by which the kprop process that is spawned by kadmind
- connects to the slave kpropd, in order to transfer the dump file during
- an iprop full resync request.
+ specifies the port by which the kprop process that is spawned by
+ kadmind connects to the replica kpropd, in order to transfer the
+ dump file during an iprop full resync request.
**-F** *dump_file*
specifies the file path to be used for dumping the KDB in response
diff --git a/doc/admin/admin_commands/kdb5_util.rst b/doc/admin/admin_commands/kdb5_util.rst
index 258498f..69086fc 100644
--- a/doc/admin/admin_commands/kdb5_util.rst
+++ b/doc/admin/admin_commands/kdb5_util.rst
@@ -272,9 +272,9 @@ specifies the encryption type of the new master key; see
values. The **-s** option stashes the new master key in the stash
file, which will be created if it doesn't already exist.
-After a new master key is added, it should be propagated to slave
+After a new master key is added, it should be propagated to replica
servers via a manual or periodic invocation of :ref:`kprop(8)`. Then,
-the stash files on the slave servers should be updated with the
+the stash files on the replica servers should be updated with the
kdb5_util **stash** command. Once those steps are complete, the key
is ready to be marked active with the kdb5_util **use_mkey** command.
diff --git a/doc/admin/admin_commands/kprop.rst b/doc/admin/admin_commands/kprop.rst
index 726c8cc..6365d85 100644
--- a/doc/admin/admin_commands/kprop.rst
+++ b/doc/admin/admin_commands/kprop.rst
@@ -12,15 +12,15 @@ SYNOPSIS
[**-d**]
[**-P** *port*]
[**-s** *keytab*]
-*slave_host*
+*replica_host*
DESCRIPTION
-----------
kprop is used to securely propagate a Kerberos V5 database dump file
-from the master Kerberos server to a slave Kerberos server, which is
-specified by *slave_host*. The dump file must be created by
+from the master Kerberos server to a replica Kerberos server, which is
+specified by *replica_host*. The dump file must be created by
:ref:`kdb5_util(8)`.
diff --git a/doc/admin/admin_commands/kpropd.rst b/doc/admin/admin_commands/kpropd.rst
index 5468b06..37162c9 100644
--- a/doc/admin/admin_commands/kpropd.rst
+++ b/doc/admin/admin_commands/kpropd.rst
@@ -10,7 +10,7 @@ SYNOPSIS
[**-r** *realm*]
[**-A** *admin_server*]
[**-a** *acl_file*]
-[**-f** *slave_dumpfile*]
+[**-f** *replica_dumpfile*]
[**-F** *principal_database*]
[**-p** *kdb5_util_prog*]
[**-P** *port*]
@@ -21,18 +21,19 @@ SYNOPSIS
DESCRIPTION
-----------
-The *kpropd* command runs on the slave KDC server. It listens for
+The *kpropd* command runs on the replica KDC server. It listens for
update requests made by the :ref:`kprop(8)` program. If incremental
propagation is enabled, it periodically requests incremental updates
from the master KDC.
-When the slave receives a kprop request from the master, kpropd
+When the replica receives a kprop request from the master, kpropd
accepts the dumped KDC database and places it in a file, and then runs
:ref:`kdb5_util(8)` to load the dumped database into the active
database which is used by :ref:`krb5kdc(8)`. This allows the master
Kerberos server to use :ref:`kprop(8)` to propagate its database to
-the slave servers. Upon a successful download of the KDC database
-file, the slave Kerberos server will have an up-to-date KDC database.
+the replica servers. Upon a successful download of the KDC database
+file, the replica Kerberos server will have an up-to-date KDC
+database.
Where incremental propagation is not used, kpropd is commonly invoked
out of inetd(8) as a nowait service. This is done by adding a line to
@@ -51,15 +52,15 @@ compatibility but does nothing.
Incremental propagation may be enabled with the **iprop_enable**
variable in :ref:`kdc.conf(5)`. If incremental propagation is
-enabled, the slave periodically polls the master KDC for updates, at
+enabled, the replica periodically polls the master KDC for updates, at
an interval determined by the **iprop_slave_poll** variable. If the
-slave receives updates, kpropd updates its log file with any updates
+replica receives updates, kpropd updates its log file with any updates
from the master. :ref:`kproplog(8)` can be used to view a summary of
-the update entry log on the slave KDC. If incremental propagation is
-enabled, the principal ``kiprop/slavehostname@REALM`` (where
-*slavehostname* is the name of the slave KDC host, and *REALM* is the
-name of the Kerberos realm) must be present in the slave's keytab
-file.
+the update entry log on the replica KDC. If incremental propagation
+is enabled, the principal ``kiprop/replicahostname@REALM`` (where
+*replicahostname* is the name of the replica KDC host, and *REALM* is
+the name of the Kerberos realm) must be present in the replica's
+keytab file.
:ref:`kproplog(8)` can be used to force full replication when iprop is
enabled.
diff --git a/doc/admin/admin_commands/kproplog.rst b/doc/admin/admin_commands/kproplog.rst
index ed90639..99ca8ff 100644
--- a/doc/admin/admin_commands/kproplog.rst
+++ b/doc/admin/admin_commands/kproplog.rst
@@ -17,18 +17,18 @@ The kproplog command displays the contents of the KDC database update
log to standard output. It can be used to keep track of incremental
updates to the principal database. The update log file contains the
update log maintained by the :ref:`kadmind(8)` process on the master
-KDC server and the :ref:`kpropd(8)` process on the slave KDC servers.
-When updates occur, they are logged to this file. Subsequently any
-KDC slave configured for incremental updates will request the current
-data from the master KDC and update their log file with any updates
-returned.
+KDC server and the :ref:`kpropd(8)` process on the replica KDC
+servers. When updates occur, they are logged to this file.
+Subsequently any KDC replica configured for incremental updates will
+request the current data from the master KDC and update their log file
+with any updates returned.
The kproplog command requires read access to the update log file. It
will display update entries only for the KDC it runs on.
If no options are specified, kproplog displays a summary of the update
log. If invoked on the master, kproplog also displays all of the
-update entries. If invoked on a slave KDC server, kproplog displays
+update entries. If invoked on a replica KDC server, kproplog displays
only a summary of the updates, which includes the serial number of the
last update received and the associated time stamp of the last update.
@@ -37,9 +37,9 @@ OPTIONS
-------
**-R**
- Reset the update log. This forces full resynchronization. If used
- on a slave then that slave will request a full resync. If used on
- the master then all slaves will request full resyncs.
+ Reset the update log. This forces full resynchronization. If
+ used on a replica then that replica will request a full resync.
+ If used on the master then all replicas will request full resyncs.
**-h**
Display a summary of the update log. This information includes
diff --git a/doc/admin/advanced/retiring-des.rst b/doc/admin/advanced/retiring-des.rst
index 8bcf83d..ebac95f 100644
--- a/doc/admin/advanced/retiring-des.rst
+++ b/doc/admin/advanced/retiring-des.rst
@@ -134,11 +134,11 @@ existing tickets will still function until their scheduled expiry
.. note::
- The new ``krbtgt@REALM`` key should be propagated to slave KDCs
+ The new ``krbtgt@REALM`` key should be propagated to replica KDCs
immediately so that TGTs issued by the master KDC can be used to
- issue service tickets on slave KDCs. Slave KDCs will refuse requests
- using the new TGT kvno until the new krbtgt entry has been propagated
- to them.
+ issue service tickets on replica KDCs. Replica KDCs will refuse
+ requests using the new TGT kvno until the new krbtgt entry has
+ been propagated to them.
It is necessary to explicitly specify the enctypes for the new database
entry, since **supported_enctypes** has not been changed. Leaving
@@ -321,8 +321,8 @@ The following KDC configuration will not generate DES keys by default:
As before, the KDC process must be restarted for this change to take
effect. It is best practice to update kdc.conf on all KDCs, not just the
- master, to avoid unpleasant surprises should the master fail and a slave
- need to be promoted.
+ master, to avoid unpleasant surprises should the master fail and a
+ replica need to be promoted.
It is now appropriate to remove the legacy single-DES key from the
``krbtgt/REALM`` entry:
diff --git a/doc/admin/appl_servers.rst b/doc/admin/appl_servers.rst
index f6474cd..fee49f0 100644
--- a/doc/admin/appl_servers.rst
+++ b/doc/admin/appl_servers.rst
@@ -121,16 +121,16 @@ Configuring your firewall to work with Kerberos V5
If you need off-site users to be able to get Kerberos tickets in your
realm, they must be able to get to your KDC. This requires either
-that you have a slave KDC outside your firewall, or that you configure
-your firewall to allow UDP requests into at least one of your KDCs, on
-whichever port the KDC is running. (The default is port 88; other
-ports may be specified in the KDC's :ref:`kdc.conf(5)` file.)
-Similarly, if you need off-site users to be able to change their
-passwords in your realm, they must be able to get to your Kerberos
-admin server on the kpasswd port (which defaults to 464). If you need
-off-site users to be able to administer your Kerberos realm, they must
-be able to get to your Kerberos admin server on the administrative
-port (which defaults to 749).
+that you have a replica KDC outside your firewall, or that you
+configure your firewall to allow UDP requests into at least one of
+your KDCs, on whichever port the KDC is running. (The default is port
+88; other ports may be specified in the KDC's :ref:`kdc.conf(5)`
+file.) Similarly, if you need off-site users to be able to change
+their passwords in your realm, they must be able to get to your
+Kerberos admin server on the kpasswd port (which defaults to 464). If
+you need off-site users to be able to administer your Kerberos realm,
+they must be able to get to your Kerberos admin server on the
+administrative port (which defaults to 749).
If your on-site users inside your firewall will need to get to KDCs in
other realms, you will also need to configure your firewall to allow
diff --git a/doc/admin/backup_host.rst b/doc/admin/backup_host.rst
index a0c2a28..982a2d1 100644
--- a/doc/admin/backup_host.rst
+++ b/doc/admin/backup_host.rst
@@ -18,17 +18,17 @@ Backing up the Kerberos database
--------------------------------
As with any file, it is possible that your Kerberos database could
-become corrupted. If this happens on one of the slave KDCs, you might
-never notice, since the next automatic propagation of the database
-would install a fresh copy. However, if it happens to the master KDC,
-the corrupted database would be propagated to all of the slaves during
-the next propagation. For this reason, MIT recommends that you back
-up your Kerberos database regularly. Because the master KDC is
-continuously dumping the database to a file in order to propagate it
-to the slave KDCs, it is a simple matter to have a cron job
-periodically copy the dump file to a secure machine elsewhere on your
-network. (Of course, it is important to make the host where these
-backups are stored as secure as your KDCs, and to encrypt its
+become corrupted. If this happens on one of the replica KDCs, you
+might never notice, since the next automatic propagation of the
+database would install a fresh copy. However, if it happens to the
+master KDC, the corrupted database would be propagated to all of the
+replicas during the next propagation. For this reason, MIT recommends
+that you back up your Kerberos database regularly. Because the master
+KDC is continuously dumping the database to a file in order to
+propagate it to the replica KDCs, it is a simple matter to have a cron
+job periodically copy the dump file to a secure machine elsewhere on
+your network. (Of course, it is important to make the host where
+these backups are stored as secure as your KDCs, and to encrypt its
transmission across your network.) Then if your database becomes
corrupted, you can load the most recent dump onto the master KDC.
(See :ref:`restore_from_dump`.)
diff --git a/doc/admin/conf_files/kdc_conf.rst b/doc/admin/conf_files/kdc_conf.rst
index 227c76d..ee17099 100644
--- a/doc/admin/conf_files/kdc_conf.rst
+++ b/doc/admin/conf_files/kdc_conf.rst
@@ -228,9 +228,9 @@ The following tags may be specified in a [realms] subsection:
Prior to release 1.11, the maximum value was 2500.
**iprop_slave_poll**
- (Delta time string.) Specifies how often the slave KDC polls for
- new updates from the master. The default value is ``2m`` (that
- is, two minutes).
+ (Delta time string.) Specifies how often the replica KDC polls
+ for new updates from the master. The default value is ``2m``
+ (that is, two minutes).
**iprop_listen**
(Whitespace- or comma-separated list.) Specifies the iprop RPC
@@ -247,8 +247,8 @@ The following tags may be specified in a [realms] subsection:
**iprop_port**
(Port number.) Specifies the port number to be used for
incremental propagation. When **iprop_enable** is true, this
- relation is required in the slave configuration file, and this
- relation or **iprop_listen** is required in the master
+ relation is required in the replica KDC configuration file, and
+ this relation or **iprop_listen** is required in the master
configuration file, as there is no default port number. Port
numbers specified in **iprop_listen** entries will override this
port number for the :ref:`kadmind(8)` daemon.
@@ -256,7 +256,7 @@ The following tags may be specified in a [realms] subsection:
**iprop_resync_timeout**
(Delta time string.) Specifies the amount of time to wait for a
full propagation to complete. This is optional in configuration
- files, and is used by slave KDCs only. The default value is 5
+ files, and is used by replica KDCs only. The default value is 5
minutes (``5m``). New in release 1.11.
**iprop_logfile**
diff --git a/doc/admin/conf_files/krb5_conf.rst b/doc/admin/conf_files/krb5_conf.rst
index 42c117a..d3a2e83 100644
--- a/doc/admin/conf_files/krb5_conf.rst
+++ b/doc/admin/conf_files/krb5_conf.rst
@@ -532,8 +532,8 @@ following tags may be specified in the realm's subsection:
one case: If an attempt to get credentials fails because of an
invalid password, the client software will attempt to contact the
master KDC, in case the user's password has just been changed, and
- the updated database has not been propagated to the slave servers
- yet.
+ the updated database has not been propagated to the replica
+ servers yet.
**v4_instance_convert**
This subsection allows the administrator to configure exceptions
diff --git a/doc/admin/database.rst b/doc/admin/database.rst
index b693042..960f304 100644
--- a/doc/admin/database.rst
+++ b/doc/admin/database.rst
@@ -510,13 +510,13 @@ availability. To roll over the master key, follow these steps:
master key, the new key will have version 2. The new master key
will not be used until you make it active.
-#. Propagate the database to all slave KDCs, either manually or by
+#. Propagate the database to all replica KDCs, either manually or by
waiting until the next scheduled propagation. If you do not have
- any slave KDCs, you can skip this and the next step.
+ any replica KDCs, you can skip this and the next step.
-#. On each slave KDC, run ``kdb5_util list_mkeys`` to verify that the
- new master key is present, and then ``kdb5_util stash`` to write
- the new master key to the slave KDC's stash file.
+#. On each replica KDC, run ``kdb5_util list_mkeys`` to verify that
+ the new master key is present, and then ``kdb5_util stash`` to
+ write the new master key to the replica KDC's stash file.
#. On the master KDC, run ``kdb5_util use_mkey 2`` to begin using the
new master key. Replace ``2`` with the version of the new master
@@ -529,11 +529,11 @@ availability. To roll over the master key, follow these steps:
command will iterate over the database and re-encrypt all keys in
the new master key. If the database is large and uses DB2, the
master KDC will become unavailable while this command runs, but
- clients should fail over to slave KDCs (if any are present) during
- this time period. In release 1.13 and later, you can instead run
- ``kdb5_util -x unlockiter update_princ_encryption`` to use unlocked
- iteration; this variant will take longer, but will keep the
- database available to the KDC and kadmind while it runs.
+ clients should fail over to replica KDCs (if any are present)
+ during this time period. In release 1.13 and later, you can
+ instead run ``kdb5_util -x unlockiter update_princ_encryption`` to
+ use unlocked iteration; this variant will take longer, but will
+ keep the database available to the KDC and kadmind while it runs.
#. On the master KDC, run ``kdb5_util purge_mkeys`` to clean up the
old master key.
@@ -794,22 +794,22 @@ Overview
At some very large sites, dumping and transmitting the database can
take more time than is desirable for changes to propagate from the
-master KDC to the slave KDCs. The incremental propagation support
+master KDC to the replica KDCs. The incremental propagation support
added in the 1.7 release is intended to address this.
With incremental propagation enabled, all programs on the master KDC
that change the database also write information about the changes to
an "update log" file, maintained as a circular buffer of a certain
-size. A process on each slave KDC connects to a service on the master
-KDC (currently implemented in the :ref:`kadmind(8)` server) and
+size. A process on each replica KDC connects to a service on the
+master KDC (currently implemented in the :ref:`kadmind(8)` server) and
periodically requests the changes that have been made since the last
check. By default, this check is done every two minutes. If the
database has just been modified in the previous several seconds
-(currently the threshold is hard-coded at 10 seconds), the slave will
-not retrieve updates, but instead will pause and try again soon after.
-This reduces the likelihood that incremental update queries will cause
-delays for an administrator trying to make a bunch of changes to the
-database at the same time.
+(currently the threshold is hard-coded at 10 seconds), the replica
+will not retrieve updates, but instead will pause and try again soon
+after. This reduces the likelihood that incremental update queries
+will cause delays for an administrator trying to make a bunch of
+changes to the database at the same time.
Incremental propagation uses the following entries in the per-realm
data in the KDC config file (See :ref:`kdc.conf(5)`):
@@ -817,53 +817,54 @@ data in the KDC config file (See :ref:`kdc.conf(5)`):
====================== =============== ===========================================
iprop_enable *boolean* If *true*, then incremental propagation is enabled, and (as noted below) normal kprop propagation is disabled. The default is *false*.
iprop_master_ulogsize *integer* Indicates the number of entries that should be retained in the update log. The default is 1000; the maximum number is 2500.
-iprop_slave_poll *time interval* Indicates how often the slave should poll the master KDC for changes to the database. The default is two minutes.
-iprop_port *integer* Specifies the port number to be used for incremental propagation. This is required in both master and slave configuration files.
-iprop_resync_timeout *integer* Specifies the number of seconds to wait for a full propagation to complete. This is optional on slave configurations. Defaults to 300 seconds (5 minutes).
+iprop_slave_poll *time interval* Indicates how often the replica should poll the master KDC for changes to the database. The default is two minutes.
+iprop_port *integer* Specifies the port number to be used for incremental propagation. This is required in both master and replica configuration files.
+iprop_resync_timeout *integer* Specifies the number of seconds to wait for a full propagation to complete. This is optional on replica configurations. Defaults to 300 seconds (5 minutes).
iprop_logfile *file name* Specifies where the update log file for the realm database is to be stored. The default is to use the *database_name* entry from the realms section of the config file :ref:`kdc.conf(5)`, with *.ulog* appended. (NOTE: If database_name isn't specified in the realms section, perhaps because the LDAP database back end is being used, or the file name is specified in the *dbmodules* section, then the hard-coded default for *database_name* is used. Determination of the *iprop_logfile* default value will not use values from the *dbmodules* section.)
====================== =============== ===========================================
-Both master and slave sides must have a principal named
+Both master and replica sides must have a principal named
``kiprop/hostname`` (where *hostname* is the lowercase,
fully-qualified, canonical name for the host) registered in the
Kerberos database, and have keys for that principal stored in the
default keytab file (|keytab|). In release 1.13, the
``kiprop/hostname`` principal is created automatically for the master
-KDC, but it must still be created for slave KDCs.
+KDC, but it must still be created for replica KDCs.
On the master KDC side, the ``kiprop/hostname`` principal must be
listed in the kadmind ACL file :ref:`kadm5.acl(5)`, and given the
**p** privilege (see :ref:`privileges`).
-On the slave KDC side, :ref:`kpropd(8)` should be run. When
+On the replica KDC side, :ref:`kpropd(8)` should be run. When
incremental propagation is enabled, it will connect to the kadmind on
the master KDC and start requesting updates.
The normal kprop mechanism is disabled by the incremental propagation
-support. However, if the slave has been unable to fetch changes from
-the master KDC for too long (network problems, perhaps), the log on
-the master may wrap around and overwrite some of the updates that the
-slave has not yet retrieved. In this case, the slave will instruct
-the master KDC to dump the current database out to a file and invoke a
-one-time kprop propagation, with special options to also convey the
-point in the update log at which the slave should resume fetching
-incremental updates. Thus, all the keytab and ACL setup previously
-described for kprop propagation is still needed.
-
-If an environment has a large number of slaves, it may be desirable to
-arrange them in a hierarchy instead of having the master serve updates
-to every slave. To do this, run ``kadmind -proponly`` on each
-intermediate slave, and ``kpropd -A upstreamhostname`` on downstream
-slaves to direct each one to the appropriate upstream slave.
+support. However, if the replica has been unable to fetch changes
+from the master KDC for too long (network problems, perhaps), the log
+on the master may wrap around and overwrite some of the updates that
+the replica has not yet retrieved. In this case, the replica will
+instruct the master KDC to dump the current database out to a file and
+invoke a one-time kprop propagation, with special options to also
+convey the point in the update log at which the replica should resume
+fetching incremental updates. Thus, all the keytab and ACL setup
+previously described for kprop propagation is still needed.
+
+If an environment has a large number of replicas, it may be desirable
+to arrange them in a hierarchy instead of having the master serve
+updates to every replica. To do this, run ``kadmind -proponly`` on
+each intermediate replica, and ``kpropd -A upstreamhostname`` on
+downstream replicas to direct each one to the appropriate upstream
+replica.
There are several known restrictions in the current implementation:
- The incremental update protocol does not transport changes to policy
objects. Any policy changes on the master will result in full
- resyncs to all slaves.
-- The slave's KDB module must support locking; it cannot be using the
+ resyncs to all replicas.
+- The replica's KDB module must support locking; it cannot be using the
LDAP KDB module.
-- The master and slave must be able to initiate TCP connections in
+- The master and replica must be able to initiate TCP connections in
both directions, without an intervening NAT.
@@ -885,10 +886,10 @@ rpcbind (also known as portmapper) and the client looks up the port
number to contact. In the MIT implementation, where interaction with
some modern versions of rpcbind doesn't always work well, the port
number must be specified in the config file on both the master and
-slave sides.
+replica sides.
The Sun implementation hard-codes pathnames in ``/var/krb5`` for the
-update log and the per-slave kprop dump files. In the MIT
+update log and the per-replica kprop dump files. In the MIT
implementation, the pathname for the update log is specified in the
-config file, and the per-slave dump files are stored in
+config file, and the per-replica dump files are stored in
|kdcdir|\ ``/slave_datatrans_hostname``.
diff --git a/doc/admin/install_appl_srv.rst b/doc/admin/install_appl_srv.rst
index 1490500..6bae724 100644
--- a/doc/admin/install_appl_srv.rst
+++ b/doc/admin/install_appl_srv.rst
@@ -34,7 +34,7 @@ the machine's root password.
In order to generate a keytab for a host, the host must have a
principal in the Kerberos database. The procedure for adding hosts to
the database is described fully in :ref:`add_mod_del_princs`. (See
-:ref:`slave_host_key` for a brief description.) The keytab is
+:ref:`replica_host_key` for a brief description.) The keytab is
generated by running :ref:`kadmin(1)` and issuing the :ref:`ktadd`
command.
diff --git a/doc/admin/install_kdc.rst b/doc/admin/install_kdc.rst
index 5c97fee..c7eec1e 100644
--- a/doc/admin/install_kdc.rst
+++ b/doc/admin/install_kdc.rst
@@ -2,23 +2,23 @@ Installing KDCs
===============
When setting up Kerberos in a production environment, it is best to
-have multiple slave KDCs alongside with a master KDC to ensure the
+have multiple replica KDCs alongside with a master KDC to ensure the
continued availability of the Kerberized services. Each KDC contains
a copy of the Kerberos database. The master KDC contains the writable
-copy of the realm database, which it replicates to the slave KDCs at
+copy of the realm database, which it replicates to the replica KDCs at
regular intervals. All database changes (such as password changes)
-are made on the master KDC. Slave KDCs provide Kerberos
+are made on the master KDC. Replica KDCs provide Kerberos
ticket-granting services, but not database administration, when the
master KDC is unavailable. MIT recommends that you install all of
your KDCs to be able to function as either the master or one of the
-slaves. This will enable you to easily switch your master KDC with
-one of the slaves if necessary (see :ref:`switch_master_slave`). This
-installation procedure is based on that recommendation.
+replicas. This will enable you to easily switch your master KDC with
+one of the replicas if necessary (see :ref:`switch_master_replica`).
+This installation procedure is based on that recommendation.
.. warning::
- The Kerberos system relies on the availability of correct time
- information. Ensure that the master and all slave KDCs have
+ information. Ensure that the master and all replica KDCs have
properly synchronized clocks.
- It is best to install and run KDCs on secured and dedicated
@@ -41,7 +41,7 @@ source (See :ref:`do_build`).
names::
kerberos.mit.edu - master KDC
- kerberos-1.mit.edu - slave KDC
+ kerberos-1.mit.edu - replica KDC
ATHENA.MIT.EDU - realm name
.k5.ATHENA.MIT.EDU - stash file
admin/admin - admin principal
@@ -286,23 +286,23 @@ against the principals that you have created on the previous step
shell% kinit admin/admin@ATHENA.MIT.EDU
-Install the slave KDCs
-----------------------
+Install the replica KDCs
+------------------------
-You are now ready to start configuring the slave KDCs.
+You are now ready to start configuring the replica KDCs.
.. note::
Assuming you are setting the KDCs up so that you can easily
- switch the master KDC with one of the slaves, you should
+ switch the master KDC with one of the replicas, you should
perform each of these steps on the master KDC as well as the
- slave KDCs, unless these instructions specify otherwise.
+ replica KDCs, unless these instructions specify otherwise.
-.. _slave_host_key:
+.. _replica_host_key:
-Create host keytabs for slave KDCs
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Create host keytabs for replica KDCs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Each KDC needs a ``host`` key in the Kerberos database. These keys
are used for mutual authentication when propagating the database dump
@@ -311,7 +311,8 @@ file from the master KDC to the secondary KDC servers.
On the master KDC, connect to administrative interface and create the
host principal for each of the KDCs' ``host`` services. For example,
if the master KDC were called ``kerberos.mit.edu``, and you had a
-slave KDC named ``kerberos-1.mit.edu``, you would type the following::
+replica KDC named ``kerberos-1.mit.edu``, you would type the
+following::
shell% kadmin
kadmin: addprinc -randkey host/kerberos.mit.edu
@@ -324,13 +325,13 @@ slave KDC named ``kerberos-1.mit.edu``, you would type the following::
It is not strictly necessary to have the master KDC server in the
Kerberos database, but it can be handy if you want to be able to swap
-the master KDC with one of the slaves.
+the master KDC with one of the replicas.
Next, extract ``host`` random keys for all participating KDCs and
store them in each host's default keytab file. Ideally, you should
extract each keytab locally on its own KDC. If this is not feasible,
you should use an encrypted session to send them across the network.
-To extract a keytab directly on a slave KDC called
+To extract a keytab directly on a replica KDC called
``kerberos-1.mit.edu``, you would execute the following command::
kadmin: ktadd host/kerberos-1.mit.edu
@@ -343,7 +344,7 @@ To extract a keytab directly on a slave KDC called
Entry for principal host/kerberos-1.mit.edu with kvno 2, encryption
type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.
-If you are instead extracting a keytab for the slave KDC called
+If you are instead extracting a keytab for the replica KDC called
``kerberos-1.mit.edu`` on the master KDC, you should use a dedicated
temporary keytab file for that machine's keytab::
@@ -357,12 +358,12 @@ The file ``/tmp/kerberos-1.keytab`` can then be installed as
``/etc/krb5.keytab`` on the host ``kerberos-1.mit.edu``.
-Configure slave KDCs
-~~~~~~~~~~~~~~~~~~~~
+Configure replica KDCs
+~~~~~~~~~~~~~~~~~~~~~~
Database propagation copies the contents of the master's database, but
does not propagate configuration files, stash files, or the kadm5 ACL
-file. The following files must be copied by hand to each slave (see
+file. The following files must be copied by hand to each replica (see
:ref:`mitK5defaults` for the default locations for these files):
* krb5.conf
@@ -371,27 +372,27 @@ file. The following files must be copied by hand to each slave (see
* master key stash file
Move the copied files into their appropriate directories, exactly as
-on the master KDC. kadm5.acl is only needed to allow a slave to swap
-with the master KDC.
+on the master KDC. kadm5.acl is only needed to allow a replica to
+swap with the master KDC.
-The database is propagated from the master KDC to the slave KDCs via
+The database is propagated from the master KDC to the replica KDCs via
the :ref:`kpropd(8)` daemon. You must explicitly specify the
principals which are allowed to provide Kerberos dump updates on the
-slave machine with a new database. Create a file named kpropd.acl in
-the KDC state directory containing the ``host`` principals for each of
-the KDCs::
+replica machine with a new database. Create a file named kpropd.acl
+in the KDC state directory containing the ``host`` principals for each
+of the KDCs::
host/kerberos.mit.edu@ATHENA.MIT.EDU
host/kerberos-1.mit.edu@ATHENA.MIT.EDU
.. note::
- If you expect that the master and slave KDCs will be
+ If you expect that the master and replica KDCs will be
switched at some point of time, list the host principals
from all participating KDC servers in kpropd.acl files on
all of the KDCs. Otherwise, you only need to list the
master KDC's host principal in the kpropd.acl files of the
- slave KDCs.
+ replica KDCs.
Then, add the following line to ``/etc/inetd.conf`` on each KDC
(adjust the path to kpropd)::
@@ -402,31 +403,31 @@ You also need to add the following line to ``/etc/services`` on each
KDC, if it is not already present (assuming that the default port is
used)::
- krb5_prop 754/tcp # Kerberos slave propagation
+ krb5_prop 754/tcp # Kerberos replica propagation
Restart inetd daemon.
Alternatively, start :ref:`kpropd(8)` as a stand-alone daemon. This is
required when incremental propagation is enabled.
-Now that the slave KDC is able to accept database propagation, you’ll
-need to propagate the database from the master server.
+Now that the replica KDC is able to accept database propagation,
+you’ll need to propagate the database from the master server.
-NOTE: Do not start the slave KDC yet; you still do not have a copy of
-the master's database.
+NOTE: Do not start the replica KDC yet; you still do not have a copy
+of the master's database.
-.. _kprop_to_slaves:
+.. _kprop_to_replicas:
-Propagate the database to each slave KDC
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Propagate the database to each replica KDC
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First, create a dump file of the database on the master KDC, as
follows::
shell% kdb5_util dump /usr/local/var/krb5kdc/slave_datatrans
-Then, manually propagate the database to each slave KDC, as in the
+Then, manually propagate the database to each replica KDC, as in the
following example::
shell% kprop -f /usr/local/var/krb5kdc/slave_datatrans kerberos-1.mit.edu
@@ -457,7 +458,7 @@ following is an example of a Bourne shell script that will do this.
You will need to set up a cron job to run this script at the intervals
you decided on earlier (see :ref:`db_prop`).
-Now that the slave KDC has a copy of the Kerberos database, you can
+Now that the replica KDC has a copy of the Kerberos database, you can
start the krb5kdc daemon::
shell% krb5kdc
@@ -487,24 +488,24 @@ Once your KDCs are set up and running, you are ready to use
services into the Kerberos database. This procedure is described
fully in :ref:`add_mod_del_princs`.
-You may occasionally want to use one of your slave KDCs as the master.
-This might happen if you are upgrading the master KDC, or if your
-master KDC has a disk crash. See the following section for the
+You may occasionally want to use one of your replica KDCs as the
+master. This might happen if you are upgrading the master KDC, or if
+your master KDC has a disk crash. See the following section for the
instructions.
-.. _switch_master_slave:
+.. _switch_master_replica:
-Switching master and slave KDCs
--------------------------------
+Switching master and replica KDCs
+---------------------------------
-You may occasionally want to use one of your slave KDCs as the master.
-This might happen if you are upgrading the master KDC, or if your
-master KDC has a disk crash.
+You may occasionally want to use one of your replica KDCs as the
+master. This might happen if you are upgrading the master KDC, or if
+your master KDC has a disk crash.
Assuming you have configured all of your KDCs to be able to function
-as either the master KDC or a slave KDC (as this document recommends),
-all you need to do to make the changeover is:
+as either the master KDC or a replica KDC (as this document
+recommends), all you need to do to make the changeover is:
If the master KDC is still running, do the following on the *old*
master KDC:
@@ -512,14 +513,14 @@ master KDC:
#. Kill the kadmind process.
#. Disable the cron job that propagates the database.
#. Run your database propagation script manually, to ensure that the
- slaves all have the latest copy of the database (see
- :ref:`kprop_to_slaves`).
+ replicas all have the latest copy of the database (see
+ :ref:`kprop_to_replicas`).
On the *new* master KDC:
#. Start the :ref:`kadmind(8)` daemon (see :ref:`start_kdc_daemons`).
#. Set up the cron job to propagate the database (see
- :ref:`kprop_to_slaves`).
+ :ref:`kprop_to_replicas`).
#. Switch the CNAMEs of the old and new master KDCs. If you can't do
this, you'll need to change the :ref:`krb5.conf(5)` file on every
client machine in your Kerberos realm.
@@ -529,5 +530,5 @@ Incremental database propagation
--------------------------------
If you expect your Kerberos database to become large, you may wish to
-set up incremental propagation to slave KDCs. See :ref:`incr_db_prop`
-for details.
+set up incremental propagation to replica KDCs. See
+:ref:`incr_db_prop` for details.
diff --git a/doc/admin/lockout.rst b/doc/admin/lockout.rst
index 446b91d..97d9b1e 100644
--- a/doc/admin/lockout.rst
+++ b/doc/admin/lockout.rst
@@ -102,13 +102,13 @@ traditional :ref:`kprop(8)` or incremental propagation. Because of
this, the number of attempts an attacker can make within a time period
is multiplied by the number of KDCs. For instance, if the
**maxfailure** parameter on a policy is 10 and there are four KDCs in
-the environment (a master and three slaves), an attacker could make as
-many as 40 attempts before the principal is locked out on all four
+the environment (a master and three replicas), an attacker could make
+as many as 40 attempts before the principal is locked out on all four
KDCs.
-An administrative unlock is propagated from the master to the slave
+An administrative unlock is propagated from the master to the replica
KDCs during the next propagation. Propagation of an administrative
-unlock will cause the counter of failed attempts on each slave to
+unlock will cause the counter of failed attempts on each replica to
reset to 1 on the next failure.
If a KDC environment uses a replication strategy other than kprop or
diff --git a/doc/admin/realm_config.rst b/doc/admin/realm_config.rst
index c7d9164..23245ca 100644
--- a/doc/admin/realm_config.rst
+++ b/doc/admin/realm_config.rst
@@ -9,10 +9,10 @@ following issues:
* How you will assign your hostnames to Kerberos realms.
* Which ports your KDC and and kadmind services will use, if they will
not be using the default ports.
-* How many slave KDCs you need and where they should be located.
-* The hostnames of your master and slave KDCs.
+* How many replica KDCs you need and where they should be located.
+* The hostnames of your master and replica KDCs.
* How frequently you will propagate the database from the master KDC
- to the slave KDCs.
+ to the replica KDCs.
Realm name
@@ -94,28 +94,28 @@ port numbers used by the Kerberos V5 programs, refer to the
:ref:`conf_firewall`.
-Slave KDCs
-----------
+Replica KDCs
+------------
-Slave KDCs provide an additional source of Kerberos ticket-granting
+Replica KDCs provide an additional source of Kerberos ticket-granting
services in the event of inaccessibility of the master KDC. The
-number of slave KDCs you need and the decision of where to place them,
+number of replica KDCs you need and the decision of where to place them,
both physically and logically, depends on the specifics of your
network.
Kerberos authentication requires that each client be able to contact a
KDC. Therefore, you need to anticipate any likely reason a KDC might
-be unavailable and have a slave KDC to take up the slack.
+be unavailable and have a replica KDC to take up the slack.
Some considerations include:
-* Have at least one slave KDC as a backup, for when the master KDC is
- down, is being upgraded, or is otherwise unavailable.
+* Have at least one replica KDC as a backup, for when the master KDC
+ is down, is being upgraded, or is otherwise unavailable.
* If your network is split such that a network outage is likely to
cause a network partition (some segment or segments of the network
- to become cut off or isolated from other segments), have a slave KDC
- accessible to each segment.
-* If possible, have at least one slave KDC in a different building
+ to become cut off or isolated from other segments), have a replica
+ KDC accessible to each segment.
+* If possible, have at least one replica KDC in a different building
from the master, in case of power outages, fires, or other localized
disasters.
@@ -127,8 +127,8 @@ Hostnames for KDCs
MIT recommends that your KDCs have a predefined set of CNAME records
(DNS hostname aliases), such as ``kerberos`` for the master KDC and
-``kerberos-1``, ``kerberos-2``, ... for the slave KDCs. This way, if
-you need to swap a machine, you only need to change a DNS entry,
+``kerberos-1``, ``kerberos-2``, ... for the replica KDCs. This way,
+if you need to swap a machine, you only need to change a DNS entry,
rather than having to change hostnames.
As of MIT krb5 1.4, clients can locate a realm's KDCs through DNS
@@ -248,7 +248,7 @@ Database propagation
--------------------
The Kerberos database resides on the master KDC, and must be
-propagated regularly (usually by a cron job) to the slave KDCs. In
+propagated regularly (usually by a cron job) to the replica KDCs. In
deciding how frequently the propagation should happen, you will need
to balance the amount of time the propagation takes against the
maximum reasonable amount of time a user should have to wait for a
@@ -256,10 +256,10 @@ password change to take effect.
If the propagation time is longer than this maximum reasonable time
(e.g., you have a particularly large database, you have a lot of
-slaves, or you experience frequent network delays), you may wish to
+replicas, or you experience frequent network delays), you may wish to
cut down on your propagation delay by performing the propagation in
parallel. To do this, have the master KDC propagate the database to
-one set of slaves, and then have each of these slaves propagate the
-database to additional slaves.
+one set of replicas, and then have each of these replicas propagate
+the database to additional replicas.
See also :ref:`incr_db_prop`
diff --git a/doc/admin/troubleshoot.rst b/doc/admin/troubleshoot.rst
index 0c61493..6a0c7f8 100644
--- a/doc/admin/troubleshoot.rst
+++ b/doc/admin/troubleshoot.rst
@@ -106,20 +106,20 @@ properly on the client if the principal entry has no long-term keys.
kprop: No route to host while connecting to server
..................................................
-Make sure that the hostname of the slave (as given to kprop) is
-correct, and that any firewalls between the master and the slave allow
-a connection on port 754.
+Make sure that the hostname of the replica KDC (as given to kprop) is
+correct, and that any firewalls between the master and the replica
+allow a connection on port 754.
.. _kprop_con_refused:
kprop: Connection refused while connecting to server
....................................................
-If the slave is intended to run kpropd out of inetd, make sure that
-inetd is configured to accept krb5_prop connections. inetd may need
-to be restarted or sent a SIGHUP to recognize the new configuration.
-If the slave is intended to run kpropd in standalone mode, make sure
-that it is running.
+If the replica KDC is intended to run kpropd out of inetd, make sure
+that inetd is configured to accept krb5_prop connections. inetd may
+need to be restarted or sent a SIGHUP to recognize the new
+configuration. If the replica is intended to run kpropd in standalone
+mode, make sure that it is running.
.. _kprop_sendauth_exchange:
@@ -128,8 +128,8 @@ kprop: Server rejected authentication (during sendauth exchange) while authentic
Make sure that:
-#. The time is synchronized between the master and slave KDCs.
+#. The time is synchronized between the master and replica KDCs.
#. The master stash file was copied from the master to the expected
- location on the slave.
-#. The slave has a keytab file in the default location containing a
- ``host`` principal for the slave's hostname.
+ location on the replica.
+#. The replica has a keytab file in the default location containing a
+ ``host`` principal for the replica's hostname.
diff --git a/doc/build/directory_org.rst b/doc/build/directory_org.rst
index f3aeeb5..db0c6c0 100644
--- a/doc/build/directory_org.rst
+++ b/doc/build/directory_org.rst
@@ -17,7 +17,7 @@ lib_ Libraries for use with/by Kerberos V5
plugins Kerberos plugins directory
po Localization infrastructure
prototype Templates files containing the MIT copyright message and a placeholder for the title and description of the file.
-slave Utilities for propagating the database to slave KDCs :ref:`kprop(8)` and :ref:`kpropd(8)`
+kprop Utilities for propagating the database to replica KDCs :ref:`kprop(8)` and :ref:`kpropd(8)`
tests Test suite
util_ Various utilities for building/configuring the code, sending bug reports, etc.
windows Source code for building Kerberos V5 on Windows (see windows/README)
diff --git a/doc/conf.py b/doc/conf.py
index 0555808..b0c5714 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -294,9 +294,9 @@ man_pages = [
('user/user_config/k5identity', 'k5identity', u'Kerberos V5 client principal selection rules', [u'MIT'], 5),
('admin/admin_commands/krb5kdc', 'krb5kdc', u'Kerberos V5 KDC', [u'MIT'], 8),
('admin/admin_commands/kadmin_local', 'kadmin', u'Kerberos V5 database administration program', [u'MIT'], 1),
- ('admin/admin_commands/kprop', 'kprop', u'propagate a Kerberos V5 principal database to a slave server', [u'MIT'], 8),
+ ('admin/admin_commands/kprop', 'kprop', u'propagate a Kerberos V5 principal database to a replica server', [u'MIT'], 8),
('admin/admin_commands/kproplog', 'kproplog', u'display the contents of the Kerberos principal update log', [u'MIT'], 8),
- ('admin/admin_commands/kpropd', 'kpropd', u'Kerberos V5 slave KDC update server', [u'MIT'], 8),
+ ('admin/admin_commands/kpropd', 'kpropd', u'Kerberos V5 replica KDC update server', [u'MIT'], 8),
('admin/admin_commands/kdb5_util', 'kdb5_util', u'Kerberos database maintenance utility', [u'MIT'], 8),
('admin/admin_commands/ktutil', 'ktutil', u'Kerberos keytab file maintenance utility', [u'MIT'], 1),
('admin/admin_commands/k5srvutil', 'k5srvutil', u'host key table (keytab) manipulation utility', [u'MIT'], 1),
diff --git a/doc/iprop-notes.txt b/doc/iprop-notes.txt
index 8efee36..722b039 100644
--- a/doc/iprop-notes.txt
+++ b/doc/iprop-notes.txt
@@ -5,15 +5,15 @@ Bugs or issues:
The "full resync" part of the protocol involves the master side firing
off a normal kprop (and going back to servicing requests), and the
-slave side stopping all the incremental propagation stuff and waiting
-for the kprop. If the connection from the master never comes in for
-some reason, the slave side just blocks forever, and never resumes
-incremental propagation.
+replica side stopping all the incremental propagation stuff and
+waiting for the kprop. If the connection from the master never comes
+in for some reason, the replica side just blocks forever, and never
+resumes incremental propagation.
The protocol does not currently pass policy database changes; this was
an intentional decision on Sun's part. The policy database is only
relevant to the master KDC, and is usually fairly static (aside from
-refcount updates), but not propagating it does mean that a slave
+refcount updates), but not propagating it does mean that a replica
maintained via iprop can't simply be promoted to a master in disaster
recovery or other cases without doing a full propagation or restoring
a database from backups.
@@ -29,17 +29,17 @@ the update log as well; etc. At least initially, we wouldn't treat it
as a differently-named database; the installation of the hooks would
be done by explicitly checking if iprop is enabled, etc.
-The "iprop role" is assumed to be either master or slave. The master
-writes a log, and the slave fetches it. But what about a cascade
-propagation model where A sends to B which sends to C, perhaps because
-A's bandwidth is highly limited, or B and C are co-located? In such a
-case, B would want to operate in both modes. Granted, with iprop the
-bandwidth issues should be less important, but there may still be
-reasons one may wish to run in such a configuration.
+The "iprop role" is assumed to be either master or replica. The
+master writes a log, and the replica fetches it. But what about a
+cascade propagation model where A sends to B which sends to C, perhaps
+because A's bandwidth is highly limited, or B and C are co-located?
+In such a case, B would want to operate in both modes. Granted, with
+iprop the bandwidth issues should be less important, but there may
+still be reasons one may wish to run in such a configuration.
The propagation of changes does not happen in real time. It's not a
-"push" protocol; the slaves poll periodically for changes. Perhaps a
-future revision of the protocol could address that.
+"push" protocol; the replicas poll periodically for changes. Perhaps
+a future revision of the protocol could address that.
kadmin/cli/kadmin.c call to kadm5_init_iprop - is this needed in
client-side program? Should it be done in libkadm5srv instead as part
@@ -67,18 +67,18 @@ db changes, which locking protocols should deal with anyways, (b)
existing acl code, (c) existing server process?
The incremental propagation protocol requires an ACL entry on the
-master, listing the slave. Since the full-resync part uses normal
-kprop, the slave also has to have an ACL entry for the master. If
+master, listing the replica. Since the full-resync part uses normal
+kprop, the replica also has to have an ACL entry for the master. If
this is missing, I suspect the behavior will be that every two
-minutes, the master side will (at the prompting of the slave) dump out
-the database and attempt a full propagation.
+minutes, the master side will (at the prompting of the replica) dump
+out the database and attempt a full propagation.
Possible optimizations: If an existing dump file has a recent enough
serial number, just send it, without dumping again? Use just one dump
-file instead of one per slave?
+file instead of one per replica?
-Requiring normal kprop means the slave still can't be behind a NAT or
-firewall without special configuration. The incremental parts can
+Requiring normal kprop means the replica still can't be behind a NAT
+or firewall without special configuration. The incremental parts can
work in such a configuration, so long as outgoing TCP connections are
allowed.
@@ -100,13 +100,13 @@ Would it be overkill to come up with a way to configure host+port for
kpropd on the master? Preferably in a way that'd support cascading
propagations.
-The kadmind process, when it needs to run kprop, extracts the slave
+The kadmind process, when it needs to run kprop, extracts the replica
host name from the client principal name. It assumes that the
principal name will be of the form foo/hostname@REALM, and looks
specifically for the "/" and "@" to chop up the string form of the
name. If looking up that name won't give a working IPv4 address for
-the slave, kprop will fail (and kpropd will keep waiting, incremental
-updates will stop, etc).
+the replica, kprop will fail (and kpropd will keep waiting,
+incremental updates will stop, etc).
Mapping between file offsets and structure addresses, we should be
careful about alignment. We're probably okay on current platforms,
diff --git a/doc/mitK5defaults.rst b/doc/mitK5defaults.rst
index 443bcc5..308fbbd 100644
--- a/doc/mitK5defaults.rst
+++ b/doc/mitK5defaults.rst
@@ -29,8 +29,8 @@ Password change port 464
========================================== ============================= ====================
-Slave KDC propagation defaults
-------------------------------
+Replica KDC propagation defaults
+--------------------------------
This table shows defaults used by the :ref:`kprop(8)` and
:ref:`kpropd(8)` programs.
diff --git a/doc/mitK5features.rst b/doc/mitK5features.rst
index aedf7e4..071b1aa 100644
--- a/doc/mitK5features.rst
+++ b/doc/mitK5features.rst
@@ -146,8 +146,8 @@ Release 1.13
protocol.
- Add support for `hierarchical incremental propagation
<https://k5wiki.kerberos.org/wiki/Projects/Hierarchical_iprop>`_,
- where slaves can act as intermediates between an upstream master
- and other downstream slaves.
+ where replicas can act as intermediates between an upstream master
+ and other downstream replicas.
- Add support for configuring GSS mechanisms using
``/etc/gss/mech.d/*.conf`` files in addition to
``/etc/gss/mech``.
@@ -255,9 +255,9 @@ Release 1.14
* Performance:
- - On slave KDCs, poll the master KDC immediately after processing a
- full resync, and do not require two full resyncs after the master
- KDC's log file is reset.
+ - On replica KDCs, poll the master KDC immediately after processing
+ a full resync, and do not require two full resyncs after the
+ master KDC's log file is reset.
Release 1.15
diff --git a/doc/notice.rst b/doc/notice.rst
index 69e6554..ff6e4b0 100644
--- a/doc/notice.rst
+++ b/doc/notice.rst
@@ -304,8 +304,8 @@ the following new or changed files:
lib/kdb/kdb_log.c
lib/kdb/kdb_log.h
lib/krb5/error_tables/kdb5_err.et
- slave/kpropd_rpc.c
- slave/kproplog.c
+ kprop/kpropd_rpc.c
+ kprop/kproplog.c
are subject to the following license:
diff --git a/src/Makefile.in b/src/Makefile.in
index f6dedf8..fd3dbea 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -29,7 +29,7 @@ SUBDIRS=util include lib \
plugins/preauth/spake \
plugins/preauth/test \
plugins/tls/k5tls \
- kdc kadmin slave clients appl tests \
+ kdc kadmin kprop clients appl tests \
config-files build-tools man doc @po@
WINSUBDIRS=include util lib ccapi windows clients appl plugins\preauth\spake
BUILDTOP=$(REL).
@@ -583,7 +583,7 @@ INDENTDIRS = \
lib/krb5 \
plugins \
prototype \
- slave \
+ kprop \
tests \
util
@@ -597,7 +597,7 @@ BSDFILES = \
lib/kadm5/kadm_rpc_xdr.c \
lib/kadm5/srv/adb_xdr.c \
lib/krb5/krb/strptime.c \
- slave/kpropd_rpc.c \
+ kprop/kpropd_rpc.c \
util/support/getopt.c \
util/support/getopt_long.c \
util/support/mkstemp.c \
diff --git a/src/config-files/services.append b/src/config-files/services.append
index a32fae6..34d1956 100644
--- a/src/config-files/services.append
+++ b/src/config-files/services.append
@@ -8,5 +8,5 @@ kpop 1109/tcp # Pop with Kerberos
kshell 544/tcp cmd # and remote shell
klogin 543/tcp # Kerberos authenticated rlogin
eklogin 2105/tcp # Kerberos encrypted rlogin
-krb5_prop 754/tcp # Kerberos slave propagation
+krb5_prop 754/tcp # Kerberos replica propagation
krb524 4444/tcp # Kerberos 5 to 4 ticket xlator
diff --git a/src/configure.in b/src/configure.in
index 086ad52..84529c1 100644
--- a/src/configure.in
+++ b/src/configure.in
@@ -108,7 +108,7 @@ AC_ARG_ENABLE([athena],
KRB5_BUILD_LIBOBJS
KRB5_BUILD_LIBRARY
KRB5_BUILD_PROGRAM
-# for slave
+# for kprop
AC_TYPE_MODE_T
AC_PROG_INSTALL
KRB5_AC_NEED_DAEMON
@@ -1457,7 +1457,7 @@ dnl lib/krb5/ccache/ccapi
dnl ccapi ccapi/lib ccapi/lib/unix ccapi/server ccapi/server/unix ccapi/test
- kdc slave config-files build-tools man doc include
+ kdc kprop config-files build-tools man doc include
plugins/certauth/test
plugins/hostrealm/test
diff --git a/src/include/iprop_hdr.h b/src/include/iprop_hdr.h
index 9027c76..435ed7e 100644
--- a/src/include/iprop_hdr.h
+++ b/src/include/iprop_hdr.h
@@ -32,7 +32,7 @@ extern "C" {
enum iprop_role {
IPROP_NULL = 0,
IPROP_MASTER = 1,
- IPROP_SLAVE = 2
+ IPROP_REPLICA = 2
};
typedef enum iprop_role iprop_role;
diff --git a/src/include/kdb.h b/src/include/kdb.h
index 7f11829..cecba31 100644
--- a/src/include/kdb.h
+++ b/src/include/kdb.h
@@ -933,10 +933,10 @@ typedef struct _kdb_vftabl {
*
* If db_args contains the value "temporary", the module should create an
* exclusively locked side copy of the database suitable for loading in a
- * propagation from master to slave. This side copy will later be promoted
- * with promote_db, allowing complete updates of the DB with no loss in
- * read availability. If the module cannot comply with this architecture,
- * it should return an error.
+ * propagation from master to replica. This side copy will later be
+ * promoted with promote_db, allowing complete updates of the DB with no
+ * loss in read availability. If the module cannot comply with this
+ * architecture, it should return an error.
*/
krb5_error_code (*create)(krb5_context kcontext, char *conf_section,
char **db_args);
diff --git a/src/include/osconf.hin b/src/include/osconf.hin
index 4b6f91b..391f48d 100644
--- a/src/include/osconf.hin
+++ b/src/include/osconf.hin
@@ -122,7 +122,7 @@
#define KRB5_ENV_CCNAME "KRB5CCNAME"
/*
- * krb5 slave support follows
+ * krb5 replica support follows
*/
#define KPROP_DEFAULT_FILE KDC_DIR "/slave_datatrans"
diff --git a/src/kadmin/cli/kadmin.c b/src/kadmin/cli/kadmin.c
index a0ba1a5..ed581ee 100644
--- a/src/kadmin/cli/kadmin.c
+++ b/src/kadmin/cli/kadmin.c
@@ -974,7 +974,7 @@ unlock_princ(kadm5_principal_ent_t princ, long *mask, const char *caller)
princ->fail_auth_count = 0;
*mask |= KADM5_FAIL_AUTH_COUNT;
- /* Record the timestamp of this unlock operation so that slave KDCs will
+ /* Record the timestamp of this unlock operation so that replica KDCs will
* see it, since fail_auth_count is unreplicated. */
retval = krb5_timeofday(context, &now);
if (retval) {
diff --git a/src/kadmin/dbutil/dump.c b/src/kadmin/dbutil/dump.c
index aca136f..2645088 100644
--- a/src/kadmin/dbutil/dump.c
+++ b/src/kadmin/dbutil/dump.c
@@ -1295,7 +1295,7 @@ dump_db(int argc, char **argv)
/*
* dump_sno is used to indicate if the serial number should be
* populated in the output file to be used later by iprop for
- * updating the slave's update log when loading.
+ * updating the replica's update log when loading.
*/
dump_sno = TRUE;
/* FLAG_OMIT_NRA is set to indicate that non-replicated
@@ -1649,7 +1649,7 @@ load_db(int argc, char **argv)
if (log_ctx != NULL && log_ctx->iproprole && !update) {
/* Don't record updates we are making to the temporary DB. We will
* reinitialize or update the ulog header after promoting it. */
- log_ctx->iproprole = IPROP_SLAVE;
+ log_ctx->iproprole = IPROP_REPLICA;
if (iprop_load) {
/* Parse the iprop header information. */
if (!parse_iprop_header(buf, &load, &last))
diff --git a/src/kadmin/dbutil/kdb5_create.c b/src/kadmin/dbutil/kdb5_create.c
index 92bb6f6..5cdee47 100644
--- a/src/kadmin/dbutil/kdb5_create.c
+++ b/src/kadmin/dbutil/kdb5_create.c
@@ -308,8 +308,8 @@ void kdb5_create(argc, argv)
/*
* Since we're creating a new db we shouldn't worry about
- * adding the initial principals since any slave might as well
- * do full resyncs from this newly created db.
+ * adding the initial principals since any replica might as
+ * well do full resyncs from this newly created db.
*/
log_ctx->iproprole = IPROP_NULL;
}
diff --git a/src/kadmin/server/ipropd_svc.c b/src/kadmin/server/ipropd_svc.c
index a3f8b05..dc9984c 100644
--- a/src/kadmin/server/ipropd_svc.c
+++ b/src/kadmin/server/ipropd_svc.c
@@ -338,8 +338,8 @@ ipropx_resync(uint32_t vers, struct svc_req *rqstp)
* dump already exists or that dump is not in ipropx format, or the
* sno and timestamp in the header of that dump are outside the
* ulog. This allows us to share a single global dump with all
- * slaves, since it's OK to share an older dump, as long as its sno
- * and timestamp are in the ulog (then the slaves can get the
+ * replicas, since it's OK to share an older dump, as long as its
+ * sno and timestamp are in the ulog (then the replicas can get the
* subsequent updates very iprop).
*/
if (asprintf(&ubuf, "%s -r %s dump -i%d -c %s", kdb5_util,
@@ -351,9 +351,9 @@ ipropx_resync(uint32_t vers, struct svc_req *rqstp)
}
/*
- * Fork to dump the db and xfer it to the slave.
+ * Fork to dump the db and xfer it to the replica.
* (the fork allows parent to return quickly and the child
- * acts like a callback to the slave).
+ * acts like a callback to the replica).
*/
fret = fork();
DPRINT("%s: fork=%d (%d)\n", whoami, fret, getpid());
@@ -418,7 +418,7 @@ ipropx_resync(uint32_t vers, struct svc_req *rqstp)
default: /* parent */
ret.ret = UPDATE_OK;
- /* not used by slave (sno is retrieved from kdb5_util dump) */
+ /* not used by replica (sno is retrieved from kdb5_util dump) */
ret.lastentry.last_sno = 0;
ret.lastentry.last_time.seconds = 0;
ret.lastentry.last_time.useconds = 0;
diff --git a/src/slave/Makefile.in b/src/kprop/Makefile.in
index f75a1f1..412d72a 100644
--- a/src/slave/Makefile.in
+++ b/src/kprop/Makefile.in
@@ -1,4 +1,4 @@
-mydir=slave
+mydir=kprop
BUILDTOP=$(REL)..
all: kprop kpropd kproplog
diff --git a/src/slave/deps b/src/kprop/deps
index c0f558e..c0f558e 100644
--- a/src/slave/deps
+++ b/src/kprop/deps
diff --git a/src/slave/kprop.c b/src/kprop/kprop.c
index 51799dc..b7fb637 100644
--- a/src/slave/kprop.c
+++ b/src/kprop/kprop.c
@@ -1,5 +1,5 @@
/* -*- mode: c; c-basic-offset: 4; indent-tabs-mode: nil -*- */
-/* slave/kprop.c */
+/* kprop/kprop.c */
/*
* Copyright 1990,1991,2008 by the Massachusetts Institute of Technology.
* All Rights Reserved.
@@ -50,7 +50,7 @@ static char *kprop_version = KPROP_PROT_VERSION;
static char *progname = NULL;
static int debug = 0;
static char *srvtab = NULL;
-static char *slave_host;
+static char *replica_host;
static char *realm = NULL;
static char *def_realm = NULL;
static char *file = KPROP_DEFAULT_FILE;
@@ -83,7 +83,7 @@ static void update_last_prop_file(char *hostname, char *file_name);
static void usage()
{
fprintf(stderr, _("\nUsage: %s [-r realm] [-f file] [-d] [-P port] "
- "[-s srvtab] slave_host\n\n"), progname);
+ "[-s srvtab] replica_host\n\n"), progname);
exit(1);
}
@@ -106,12 +106,12 @@ main(int argc, char **argv)
get_tickets(context);
database_fd = open_database(context, file, &database_size);
- open_connection(context, slave_host, &fd);
+ open_connection(context, replica_host, &fd);
kerberos_authenticate(context, &auth_context, fd, my_principal, &my_creds);
xmit_database(context, auth_context, my_creds, fd, database_fd,
database_size);
- update_last_prop_file(slave_host, file);
- printf(_("Database propagation to %s: SUCCEEDED\n"), slave_host);
+ update_last_prop_file(replica_host, file);
+ printf(_("Database propagation to %s: SUCCEEDED\n"), replica_host);
krb5_free_cred_contents(context, my_creds);
close_database(context, database_fd);
krb5_free_default_realm(context, def_realm);
@@ -148,7 +148,7 @@ parse_args(krb5_context context, int argc, char **argv)
}
if (argc - optind != 1)
usage();
- slave_host = argv[optind];
+ replica_host = argv[optind];
if (realm == NULL) {
ret = krb5_get_default_realm(context, &def_realm);
@@ -176,9 +176,9 @@ get_tickets(krb5_context context)
exit(1);
}
- /* Construct the principal name for the slave host. */
+ /* Construct the principal name for the replica host. */
memset(&creds, 0, sizeof(creds));
- retval = sn2princ_realm(context, slave_host, KPROP_SERVICE_NAME, realm,
+ retval = sn2princ_realm(context, replica_host, KPROP_SERVICE_NAME, realm,
&server_princ);
if (retval) {
com_err(progname, errno, _("while setting server principal name"));
diff --git a/src/slave/kprop.h b/src/kprop/kprop.h
index dbbda43..75331cc 100644
--- a/src/slave/kprop.h
+++ b/src/kprop/kprop.h
@@ -1,5 +1,5 @@
/* -*- mode: c; c-basic-offset: 4; indent-tabs-mode: nil -*- */
-/* slave/kprop.h */
+/* kprop/kprop.h */
/*
* Copyright 1990,1991 by the Massachusetts Institute of Technology.
* All Rights Reserved.
diff --git a/src/slave/kprop_util.c b/src/kprop/kprop_util.c
index 7e1ec22..c32d174 100644
--- a/src/slave/kprop_util.c
+++ b/src/kprop/kprop_util.c
@@ -1,5 +1,5 @@
/* -*- mode: c; c-basic-offset: 4; indent-tabs-mode: nil -*- */
-/* slave/kprop_util.c */
+/* kprop/kprop_util.c */
/*
* Copyright (C) 2010 by the Massachusetts Institute of Technology.
* All rights reserved.
diff --git a/src/slave/kpropd.c b/src/kprop/kpropd.c
index d621f10..68323dd 100644
--- a/src/slave/kpropd.c
+++ b/src/kprop/kpropd.c
@@ -1,5 +1,5 @@
/* -*- mode: c; c-basic-offset: 4; indent-tabs-mode: nil -*- */
-/* slave/kpropd.c */
+/* kprop/kpropd.c */
/*
* Copyright (C) 1998 by the FundsXpress, INC.
*
@@ -168,7 +168,7 @@ static void
usage()
{
fprintf(stderr,
- _("\nUsage: %s [-r realm] [-s srvtab] [-dS] [-f slave_file]\n"),
+ _("\nUsage: %s [-r realm] [-s srvtab] [-dS] [-f replica_file]\n"),
progname);
fprintf(stderr, _("\t[-F kerberos_db_file ] [-p kdb5_util_pathname]\n"));
fprintf(stderr, _("\t[-x db_args]* [-P port] [-a acl_file]\n"));
@@ -313,7 +313,7 @@ main(int argc, char **argv)
exit(0);
}
- if (log_ctx == NULL || log_ctx->iproprole != IPROP_SLAVE) {
+ if (log_ctx == NULL || log_ctx->iproprole != IPROP_REPLICA) {
do_standalone();
/* do_standalone() should never return */
assert(0);
@@ -883,7 +883,7 @@ reinit:
/*
* ulog_replay() will convert the ulog updates to db
* entries using the kdb conv api and will commit
- * the entries to the slave kdc database
+ * the entries to the replica kdc database
*/
if (debug) {
fprintf(stderr, _("Got incremental updates "
@@ -942,7 +942,7 @@ reinit:
case UPDATE_NIL:
/*
- * Master-slave are in sync
+ * Master-replica are in sync
*/
if (debug)
fprintf(stderr, _("KDC is synchronized with master.\n"));
@@ -1166,7 +1166,7 @@ parse_args(int argc, char **argv)
exit(1);
}
if (params.iprop_enabled == TRUE) {
- ulog_set_role(kpropd_context, IPROP_SLAVE);
+ ulog_set_role(kpropd_context, IPROP_REPLICA);
if (ulog_map(kpropd_context, params.iprop_logfile,
params.iprop_ulogsize)) {
@@ -1550,7 +1550,7 @@ load_database(krb5_context context, char *kdb_util, char *database_file_name)
edit_av[count++] = "-d";
edit_av[count++] = kerb_database;
}
- if (log_ctx && log_ctx->iproprole == IPROP_SLAVE)
+ if (log_ctx && log_ctx->iproprole == IPROP_REPLICA)
edit_av[count++] = "-i";
edit_av[count++] = database_file_name;
edit_av[count++] = NULL;
diff --git a/src/slave/kpropd_rpc.c b/src/kprop/kpropd_rpc.c
index 4877e37..4877e37 100644
--- a/src/slave/kpropd_rpc.c
+++ b/src/kprop/kpropd_rpc.c
diff --git a/src/slave/kproplog.c b/src/kprop/kproplog.c
index 232a16f..5ec97ae 100644
--- a/src/slave/kproplog.c
+++ b/src/kprop/kproplog.c
@@ -5,7 +5,7 @@
*/
/*
- * This module will parse the update logs on the master or slave servers.
+ * This module will parse the update logs on the master or replica servers.
*/
#include "k5-int.h"
diff --git a/src/slave/kslave_update b/src/kprop/replica_update
index 4497072..69e7bd4 100644
--- a/src/slave/kslave_update
+++ b/src/kprop/replica_update
@@ -2,7 +2,7 @@
#
# Propagate if database (principal.db) has been modified since last dump
# (dumpfile.dump_ok) or if database has been dumped since last successful
-# propagation (dumpfile.<slave machine>.last_prop)
+# propagation (dumpfile.<replica machine>.last_prop)
KDB_DIR=/usr/local/var/krb5kdc
@@ -11,20 +11,20 @@ DUMPFILE=$KDB_DIR/slave_datatrans
KDB5_UTIL=/usr/local/sbin/kdb5_util
KPROP=/usr/local/sbin/kprop
-SLAVE=$1
-if [ -z "${SLAVE}" ]
-then
- echo "Usage $0 slave_server"
+REPLICA=$1
+if [ -z "${REPLICA}" ]
+then
+ echo "Usage $0 replica_server"
fi
if [ "`ls -t $DUMPFILE.dump_ok $KDB_FILE | sed -n 1p`" = "$KDB_FILE" -o \
- "`ls -t $DUMPFILE.${SLAVE}.last_prop $DUMPFILE.dump_ok | \
+ "`ls -t $DUMPFILE.${REPLICA}.last_prop $DUMPFILE.dump_ok | \
sed -n 1p`" = "$DUMPFILE.dump_ok" ]
then
date
$KDB5_UTIL dump $DUMPFILE > /dev/null
- $KPROP -d -f $DUMPFILE ${SLAVE}
+ $KPROP -d -f $DUMPFILE ${REPLICA}
rm $DUMPFILE
fi
diff --git a/src/lib/kdb/iprop.x b/src/lib/kdb/iprop.x
index b04a453..8796589 100644
--- a/src/lib/kdb/iprop.x
+++ b/src/lib/kdb/iprop.x
@@ -12,7 +12,7 @@
* Generated files:
* lib/kdb/iprop_xdr.c
* include/iprop.h
- * slave/kpropd_rpc.c (clnt)
+ * kprop/kpropd_rpc.c (clnt)
*
* Derived files:
* kadmin/server/ipropd_svc.c
@@ -174,7 +174,7 @@ struct kdb_incr_update_t {
kdbe_t kdb_update; /* Attributes modified */
bool kdb_deleted; /* Is this update a DELETION ? */
bool kdb_commit; /* Is the entry committed or not ? */
- utf8str_t kdb_kdcs_seen_by<>; /* Names of slaves that have */
+ utf8str_t kdb_kdcs_seen_by<>; /* Names of replicass that have */
/* seen this update - for */
/* future use */
opaque kdb_futures<>; /* futures */
diff --git a/src/lib/kdb/kdb_convert.c b/src/lib/kdb/kdb_convert.c
index 691635e..7614073 100644
--- a/src/lib/kdb/kdb_convert.c
+++ b/src/lib/kdb/kdb_convert.c
@@ -579,7 +579,7 @@ ulog_conv_2dbentry(krb5_context context, krb5_db_entry **entry,
kdb_incr_update_t *update)
{
krb5_db_entry *ent;
- int slave;
+ int replica;
krb5_principal mod_princ = NULL;
int i, j, cnt = 0, mod_time = 0, nattrs;
krb5_principal dbprinc;
@@ -592,8 +592,8 @@ ulog_conv_2dbentry(krb5_context context, krb5_db_entry **entry,
*entry = NULL;
- slave = (context->kdblog_context != NULL) &&
- (context->kdblog_context->iproprole == IPROP_SLAVE);
+ replica = (context->kdblog_context != NULL) &&
+ (context->kdblog_context->iproprole == IPROP_REPLICA);
/*
* Store the no. of changed attributes in nattrs
@@ -655,17 +655,17 @@ ulog_conv_2dbentry(krb5_context context, krb5_db_entry **entry,
break;
case AT_LAST_SUCCESS:
- if (!slave)
+ if (!replica)
ent->last_success = (krb5_timestamp) u.av_last_success;
break;
case AT_LAST_FAILED:
- if (!slave)
+ if (!replica)
ent->last_failed = (krb5_timestamp) u.av_last_failed;
break;
case AT_FAIL_AUTH_COUNT:
- if (!slave)
+ if (!replica)
ent->fail_auth_count = (krb5_kvno) u.av_fail_auth_count;
break;
diff --git a/src/lib/kdb/kdb_log.c b/src/lib/kdb/kdb_log.c
index 2b0d633..2659a25 100644
--- a/src/lib/kdb/kdb_log.c
+++ b/src/lib/kdb/kdb_log.c
@@ -178,7 +178,7 @@ extend_file_to(int fd, unsigned int new_size)
/*
* Resize the array elements. We reinitialize the update log rather than
* unrolling the the log and copying it over to a temporary log for obvious
- * performance reasons. Slaves will subsequently do a full resync, but the
+ * performance reasons. Replicas will subsequently do a full resync, but the
* need for resizing should be very small.
*/
static krb5_error_code
@@ -353,7 +353,7 @@ ulog_add_update(krb5_context context, kdb_incr_update_t *upd)
return ret;
/* If we have reached the last possible serial number, reinitialize the
- * ulog and start over. Slaves will do a full resync. */
+ * ulog and start over. Replicas will do a full resync. */
if (ulog->kdb_last_sno == (kdb_sno_t)-1)
reset_ulog(log_ctx);
@@ -364,7 +364,7 @@ ulog_add_update(krb5_context context, kdb_incr_update_t *upd)
return ret;
}
-/* Used by the slave to update its hash db from the incr update log. */
+/* Used by the replica to update its hash db from the incr update log. */
krb5_error_code
ulog_replay(krb5_context context, kdb_incr_result_t *incr_ret, char **db_args)
{
diff --git a/src/lib/krb5/krb/gic_keytab.c b/src/lib/krb5/krb/gic_keytab.c
index f20af53..e82f425 100644
--- a/src/lib/krb5/krb/gic_keytab.c
+++ b/src/lib/krb5/krb/gic_keytab.c
@@ -306,7 +306,7 @@ krb5_get_init_creds_keytab(krb5_context context,
if (ret == 0)
goto cleanup;
- /* If the master is unreachable, return the error from the slave we
+ /* If the master is unreachable, return the error from the replica we
* were able to contact. */
if (ret == KRB5_KDC_UNREACH || ret == KRB5_REALM_CANT_RESOLVE ||
ret == KRB5_REALM_UNKNOWN)
diff --git a/src/lib/krb5/krb/gic_pwd.c b/src/lib/krb5/krb/gic_pwd.c
index 3565a7c..14ce23b 100644
--- a/src/lib/krb5/krb/gic_pwd.c
+++ b/src/lib/krb5/krb/gic_pwd.c
@@ -350,7 +350,7 @@ krb5_get_init_creds_password(krb5_context context,
if (ret == 0)
goto cleanup;
- /* If the master is unreachable, return the error from the slave we
+ /* If the master is unreachable, return the error from the replica we
* were able to contact and reset the use_master flag. */
if (ret == KRB5_KDC_UNREACH || ret == KRB5_REALM_CANT_RESOLVE ||
ret == KRB5_REALM_UNKNOWN) {
diff --git a/src/plugins/kdb/db2/kdb_db2.c b/src/plugins/kdb/db2/kdb_db2.c
index d23587a..5106a5c 100644
--- a/src/plugins/kdb/db2/kdb_db2.c
+++ b/src/plugins/kdb/db2/kdb_db2.c
@@ -110,11 +110,11 @@
* a bug, since the database may be inconsistant. Note that the
* absence of a semaphore file does not prevent another _update_ from
* taking place later. Database replacements take place automatically
- * only on slave servers; a crash in the middle of an update will be
- * fixed by the next slave propagation. A crash in the middle of an
- * update on the master would be somewhat more serious, but this would
- * likely be noticed by an administrator, who could fix the problem and
- * retry the operation.
+ * only on replica servers; a crash in the middle of an update will be
+ * fixed by the next propagation. A crash in the middle of an on the
+ * master would be somewhat more serious, but this would likely be
+ * noticed by an administrator, who could fix the problem and retry
+ * the operation.
*/
/* Evaluate to true if the krb5_context c contains an initialized db2
diff --git a/src/tests/dejagnu/config/default.exp b/src/tests/dejagnu/config/default.exp
index 19c836c..d7b2965 100644
--- a/src/tests/dejagnu/config/default.exp
+++ b/src/tests/dejagnu/config/default.exp
@@ -162,7 +162,7 @@ set passes {
{permitted_enctypes(client)=aes256-cts-hmac-sha1-96}
{permitted_enctypes(server)=aes256-cts-hmac-sha1-96}
{allow_weak_crypto(kdc)=false}
- {allow_weak_crypto(slave)=false}
+ {allow_weak_crypto(replica)=false}
{allow_weak_crypto(client)=false}
{allow_weak_crypto(server)=false}
{master_key_type=aes256-cts-hmac-sha1-96}
@@ -174,19 +174,19 @@ set passes {
des3_krbtgt=0
{supported_enctypes=aes256-sha2:normal}
{permitted_enctypes(kdc)=aes256-sha2}
- {permitted_enctypes(slave)=aes256-sha2}
+ {permitted_enctypes(replica)=aes256-sha2}
{permitted_enctypes(client)=aes256-sha2}
{permitted_enctypes(server)=aes256-sha2}
{default_tgs_enctypes(kdc)=aes256-sha2}
- {default_tgs_enctypes(slave)=aes256-sha2}
+ {default_tgs_enctypes(replica)=aes256-sha2}
{default_tgs_enctypes(client)=aes256-sha2}
{default_tgs_enctypes(server)=aes256-sha2}
{default_tkt_enctypes(kdc)=aes256-sha2}
- {default_tkt_enctypes(slave)=aes256-sha2}
+ {default_tkt_enctypes(replica)=aes256-sha2}
{default_tkt_enctypes(client)=aes256-sha2}
{default_tkt_enctypes(server)=aes256-sha2}
{allow_weak_crypto(kdc)=false}
- {allow_weak_crypto(slave)=false}
+ {allow_weak_crypto(replica)=false}
{allow_weak_crypto(client)=false}
{allow_weak_crypto(server)=false}
{master_key_type=aes256-sha2}
@@ -198,19 +198,19 @@ set passes {
des3_krbtgt=0
{supported_enctypes=camellia256-cts:normal}
{permitted_enctypes(kdc)=camellia256-cts}
- {permitted_enctypes(slave)=camellia256-cts}
+ {permitted_enctypes(replica)=camellia256-cts}
{permitted_enctypes(client)=camellia256-cts}
{permitted_enctypes(server)=camellia256-cts}
{default_tgs_enctypes(kdc)=camellia256-cts}
- {default_tgs_enctypes(slave)=camellia256-cts}
+ {default_tgs_enctypes(replica)=camellia256-cts}
{default_tgs_enctypes(client)=camellia256-cts}
{default_tgs_enctypes(server)=camellia256-cts}
{default_tkt_enctypes(kdc)=camellia256-cts}
- {default_tkt_enctypes(slave)=camellia256-cts}
+ {default_tkt_enctypes(replica)=camellia256-cts}
{default_tkt_enctypes(client)=camellia256-cts}
{default_tkt_enctypes(server)=camellia256-cts}
{allow_weak_crypto(kdc)=false}
- {allow_weak_crypto(slave)=false}
+ {allow_weak_crypto(replica)=false}
{allow_weak_crypto(client)=false}
{allow_weak_crypto(server)=false}
{master_key_type=camellia256-cts}
@@ -259,7 +259,7 @@ set passes {
mode=udp
des3_krbtgt=0
{allow_weak_crypto(kdc)=false}
- {allow_weak_crypto(slave)=false}
+ {allow_weak_crypto(replica)=false}
{allow_weak_crypto(client)=false}
{allow_weak_crypto(server)=false}
{dummy=[verbose -log "all default enctypes"]}
@@ -427,19 +427,19 @@ if ![info exists KEY] {
# Clear away any files left over from a previous run.
# We can't use them now because we don't know the right KEY.
# krb5.conf might change if running tests on another host
-file delete $tmppwd/krb5.conf $tmppwd/kdc.conf $tmppwd/slave.conf \
+file delete $tmppwd/krb5.conf $tmppwd/kdc.conf $tmppwd/replica.conf \
$tmppwd/krb5.client.conf $tmppwd/krb5.server.conf \
- $tmppwd/krb5.kdc.conf $tmppwd/krb5.slave.conf
+ $tmppwd/krb5.kdc.conf $tmppwd/krb5.replica.conf
proc delete_db {} {
global tmppwd
- # Master and slave db files
+ # Master and replica db files
file delete $tmppwd/kdc-db $tmppwd/kdc-db.ok $tmppwd/kdc-db.kadm5 \
$tmppwd/kdc-db.kadm5.lock $tmppwd/kdc-db.mdb $tmppwd/kdc-db.mdb-lock \
$tmppwd/kdc-db.lockout.mdb $tmppwd/kdc-db.lockout.mdb-lock \
$tmppwd/kdc-db.ulog \
- $tmppwd/slave-db $tmppwd/slave-db.ok $tmppwd/slave-db.kadm5 $tmppwd/slave-db.kadm5.lock \
- $tmppwd/slave-db~ $tmppwd/slave-db~.ok $tmppwd/slave-db~.kadm5 $tmppwd/slave-db~.kadm5.lock
+ $tmppwd/replica-db $tmppwd/replica-db.ok $tmppwd/replica-db.kadm5 $tmppwd/replica-db.kadm5.lock \
+ $tmppwd/replica-db~ $tmppwd/replica-db~.ok $tmppwd/replica-db~.kadm5 $tmppwd/replica-db~.kadm5.lock
# Creating a new database means we need a new srvtab.
file delete $tmppwd/srvtab $tmppwd/cpw_srvtab
}
@@ -486,10 +486,10 @@ foreach i {
{KDESTROY $objdir/../../clients/kdestroy/kdestroy}
{RESOLVE $objdir/../resolve/resolve}
{T_INETD $objdir/t_inetd}
- {KPROPLOG $objdir/../../slave/kproplog}
+ {KPROPLOG $objdir/../../kprop/kproplog}
{KPASSWD $objdir/../../clients/kpasswd/kpasswd}
- {KPROPD $objdir/../../slave/kpropd}
- {KPROP $objdir/../../slave/kprop}
+ {KPROPD $objdir/../../kprop/kpropd}
+ {KPROP $objdir/../../kprop/kprop}
} {
set varname [lindex $i 0]
if ![info exists $varname] {
@@ -780,7 +780,7 @@ proc setup_kerberos_files { } {
setup_krb5_conf client
setup_krb5_conf server
setup_krb5_conf kdc
- setup_krb5_conf slave
+ setup_krb5_conf replica
# Create a kdc.conf file.
if { ![file exists $tmppwd/kdc.conf] \
@@ -829,11 +829,11 @@ proc setup_kerberos_files { } {
close $conffile
}
- # Create a config file for the slave KDC (kpropd only, no normal
+ # Create a config file for the replica KDC (kpropd only, no normal
# KDC processes).
- if { ![file exists $tmppwd/slave.conf] \
+ if { ![file exists $tmppwd/replica.conf] \
|| $last_passname_conf != $multipass_name } {
- set conffile [open $tmppwd/slave.conf w]
+ set conffile [open $tmppwd/replica.conf w]
puts $conffile "\[kdcdefaults\]"
puts $conffile " kdc_listen = $portbase,[expr 1 + $portbase],[expr 2 + $portbase]"
puts $conffile " kdc_tcp_listen = $portbase,[expr 1 + $portbase],[expr 2 + $portbase]"
@@ -842,8 +842,8 @@ proc setup_kerberos_files { } {
puts $conffile " $REALMNAME = \{"
# Testing with a colon in the name exercises default handling
# for pathnames.
- puts $conffile " key_stash_file = $tmppwd/slave-stash"
- puts $conffile " acl_file = $tmppwd/slave-acl"
+ puts $conffile " key_stash_file = $tmppwd/replica-stash"
+ puts $conffile " acl_file = $tmppwd/replica-acl"
puts $conffile " kadmind_port = [expr 4 + $portbase]"
puts $conffile " kpasswd_port = [expr 5 + $portbase]"
puts $conffile " max_life = 1:00:00"
@@ -868,7 +868,7 @@ proc setup_kerberos_files { } {
if { $ulog != 0 } {
puts $conffile " iprop_enable = true"
puts $conffile " iprop_port = [expr 9 + $portbase]"
- puts $conffile " iprop_logfile = $tmppwd/slave-db.ulog"
+ puts $conffile " iprop_logfile = $tmppwd/replica-db.ulog"
} else {
puts $conffile "# no ulog"
}
@@ -896,8 +896,9 @@ proc setup_kerberos_files { } {
proc reset_kerberos_files { } {
global tmppwd
- file delete $tmppwd/kdc.conf $tmppwd/slave.conf $tmppwd/krb5.client.conf \
- $tmppwd/krb5.server.conf $tmppwd/krb5.kdc.conf
+ file delete $tmppwd/kdc.conf $tmppwd/replica.conf \
+ $tmppwd/krb5.client.conf $tmppwd/krb5.server.conf \
+ $tmppwd/krb5.kdc.conf
setup_kerberos_files
}
@@ -1055,7 +1056,7 @@ proc setup_kerberos_env { {type client} } {
client -
server { catch {unset env(KRB5_KDC_PROFILE)} }
kdc { set env(KRB5_KDC_PROFILE) $tmppwd/kdc.conf }
- slave { set env(KRB5_KDC_PROFILE) $tmppwd/slave.conf }
+ replica { set env(KRB5_KDC_PROFILE) $tmppwd/replica.conf }
default { error "unknown config file type $type" }
}
if [info exists env(KRB5_KDC_PROFILE)] {
@@ -1401,11 +1402,11 @@ proc setup_kerberos_db { standalone } {
return 1
}
-# setup_slave_db
-# Initialize the slave Kerberos database. Returns 1 on success, 0 on
+# setup_replica_db
+# Initialize the replica Kerberos database. Returns 1 on success, 0 on
# failure.
-proc setup_slave_db { } {
+proc setup_replica_db { } {
global REALMNAME
global KDB5_UTIL
global KADMIN_LOCAL
@@ -1416,7 +1417,7 @@ proc setup_slave_db { } {
set failall 0
envstack_push
- if { ![setup_kerberos_files] || ![setup_kerberos_env slave] } {
+ if { ![setup_kerberos_files] || ![setup_kerberos_env replica] } {
set failall 1
}
@@ -1432,7 +1433,7 @@ proc setup_slave_db { } {
}
}
- set test "slave kdb5_util create "
+ set test "replica kdb5_util create "
set body {
if $failall {
break
@@ -1444,11 +1445,11 @@ proc setup_slave_db { } {
expect "Enter KDC database master key:"
- set test "slave kdb5_util create (verify)"
+ set test "replica kdb5_util create (verify)"
send "masterkey$KEY\r"
expect "Re-enter KDC database master key to verify:"
- set test "slave kdb5_util create"
+ set test "replica kdb5_util create"
send "masterkey$KEY\r"
expect {
-re "\[Cc\]ouldn't" {
@@ -1471,7 +1472,7 @@ proc setup_slave_db { } {
}
# Stash the master key in a file.
- set test "slave kdb5_util stash"
+ set test "replica kdb5_util stash"
set body {
if $failall {
break
@@ -1497,7 +1498,7 @@ proc setup_slave_db { } {
if !$failall {
# create the admin database lock file
- catch "exec touch $tmppwd/slave-adb.lock"
+ catch "exec touch $tmppwd/replica-adb.lock"
}
return [expr !$failall]
@@ -1508,11 +1509,11 @@ proc start_kpropd {} {
global spawn_id
envstack_push
- setup_kerberos_env slave
- spawn $KPROPD -S -d -t -P [expr 10 + $portbase] -s $tmppwd/srvtab -f $tmppwd/incoming-slave-datatrans -p $KDB5_UTIL -a $tmppwd/kpropd-acl
+ setup_kerberos_env replica
+ spawn $KPROPD -S -d -t -P [expr 10 + $portbase] -s $tmppwd/srvtab -f $tmppwd/incoming-replica-datatrans -p $KDB5_UTIL -a $tmppwd/kpropd-acl
set kpropd_pid [exp_pid]
set kpropd_spawn_id $spawn_id
-# send_user [list $KPROPD -S -d -P [expr 10 + $portbase] -s $tmppwd/srvtab -f $tmppwd/incoming-slave-datatrans -p $KDB5_UTIL -a $tmppwd/kpropd-acl]\n
+# send_user [list $KPROPD -S -d -P [expr 10 + $portbase] -s $tmppwd/srvtab -f $tmppwd/incoming-replica-datatrans -p $KDB5_UTIL -a $tmppwd/kpropd-acl]\n
# spawn_shell
envstack_pop
}
diff --git a/src/tests/dejagnu/krb-standalone/kprop.exp b/src/tests/dejagnu/krb-standalone/kprop.exp
index f23ebe1..2221a65 100644
--- a/src/tests/dejagnu/krb-standalone/kprop.exp
+++ b/src/tests/dejagnu/krb-standalone/kprop.exp
@@ -5,24 +5,24 @@
# the rest of the tests inside a proc, so that we can easily kill the
# processes when the procedure ends.
-proc setup_slave {} {
+proc setup_replica {} {
global tmppwd hostname REALMNAME env
- file delete $tmppwd/slave-stash $tmppwd/slave-acl
- file copy -force $tmppwd/stash:foo $tmppwd/slave-stash
- file copy -force $tmppwd/acl $tmppwd/slave-acl
+ file delete $tmppwd/replica-stash $tmppwd/replica-acl
+ file copy -force $tmppwd/stash:foo $tmppwd/replica-stash
+ file copy -force $tmppwd/acl $tmppwd/replica-acl
if ![file exists $tmppwd/kpropdacl] {
set aclfile [open $tmppwd/kpropd-acl w]
puts $aclfile "host/$hostname@$REALMNAME"
close $aclfile
}
- file copy -force $tmppwd/adb.lock $tmppwd/slave-adb.lock
+ file copy -force $tmppwd/adb.lock $tmppwd/replica-adb.lock
if [info exists env(K5TEST_LMDB)] {
set suffixes { .mdb .mdb-lock .lockout.mdb .lockout.mdb-lock }
} else {
set suffixes { {} .kadm5 .kadm5.lock .ok }
}
foreach suffix $suffixes {
- file copy -force $tmppwd/kdc-db$suffix $tmppwd/slave-db$suffix
+ file copy -force $tmppwd/kdc-db$suffix $tmppwd/replica-db$suffix
}
}
@@ -64,7 +64,7 @@ proc doit { } {
if ![setup_kerberos_db 0] {
return
}
- setup_slave
+ setup_replica
if ![start_kerberos_daemons 0] {
return
}
@@ -79,7 +79,7 @@ proc doit { } {
# Get kprop server up and running.
envstack_push
- setup_kerberos_env slave
+ setup_kerberos_env replica
start_kpropd
envstack_pop
@@ -91,7 +91,7 @@ proc doit { } {
# Dump master database.
envstack_push
setup_kerberos_env kdc
- spawn $KDB5_UTIL dump $tmppwd/slave_datatrans
+ spawn $KDB5_UTIL dump $tmppwd/replica_datatrans
expect eof
if ![check_exit_status "kprop (kdb5_util dump)"] { return }
@@ -99,7 +99,7 @@ proc doit { } {
sleep 1
# Try a propagation.
- spawn $KPROP -f $tmppwd/slave_datatrans -P [expr 10 + $portbase] -s $tmppwd/srvtab $hostname
+ spawn $KPROP -f $tmppwd/replica_datatrans -P [expr 10 + $portbase] -s $tmppwd/srvtab $hostname
expect eof
set kprop_exit [check_exit_status "kprop (exit status)"]
# log output for debugging
@@ -107,14 +107,14 @@ proc doit { } {
if !$kprop_exit { return }
# Examine new database.
- setup_kerberos_env slave
+ setup_kerberos_env replica
spawn $KADMIN_LOCAL -r $REALMNAME -q listprincs
expect {
wakawaka@ {
expect eof
}
eof {
- fail "kprop (updated slave data)"
+ fail "kprop (updated replica data)"
return
}
timeout {
diff --git a/src/tests/t_iprop.py b/src/tests/t_iprop.py
index f4fae69..92e22b9 100755
--- a/src/tests/t_iprop.py
+++ b/src/tests/t_iprop.py
@@ -107,55 +107,55 @@ def check_ulog(num, first, last, entries, env=None):
if eprinc != None:
fail('Expected princ %s in update entry %d' % (eprinc, ser))
-# slave1 will receive updates from master, and slave2 will receive
-# updates from slave1. Because of the awkward way iprop and kprop
+# replica1 will receive updates from master, and replica2 will receive
+# updates from replica1. Because of the awkward way iprop and kprop
# port configuration currently works, we need separate config files
-# for the slave and master sides of slave1, but they use the same DB
-# and ulog file.
+# for the replica and master sides of replica1, but they use the same
+# DB and ulog file.
conf = {'realms': {'$realm': {'iprop_enable': 'true',
'iprop_logfile': '$testdir/db.ulog'}}}
-conf_slave1 = {'realms': {'$realm': {'iprop_slave_poll': '600',
- 'iprop_logfile': '$testdir/ulog.slave1'}},
- 'dbmodules': {'db': {'database_name': '$testdir/db.slave1'}}}
-conf_slave1m = {'realms': {'$realm': {'iprop_logfile': '$testdir/ulog.slave1',
- 'iprop_port': '$port8'}},
- 'dbmodules': {'db': {'database_name': '$testdir/db.slave1'}}}
-conf_slave2 = {'realms': {'$realm': {'iprop_slave_poll': '600',
- 'iprop_logfile': '$testdir/ulog.slave2',
- 'iprop_port': '$port8'}},
- 'dbmodules': {'db': {'database_name': '$testdir/db.slave2'}}}
+conf_rep1 = {'realms': {'$realm': {'iprop_slave_poll': '600',
+ 'iprop_logfile': '$testdir/ulog.replica1'}},
+ 'dbmodules': {'db': {'database_name': '$testdir/db.replica1'}}}
+conf_rep1m = {'realms': {'$realm': {'iprop_logfile': '$testdir/ulog.replica1',
+ 'iprop_port': '$port8'}},
+ 'dbmodules': {'db': {'database_name': '$testdir/db.replica1'}}}
+conf_rep2 = {'realms': {'$realm': {'iprop_slave_poll': '600',
+ 'iprop_logfile': '$testdir/ulog.replica2',
+ 'iprop_port': '$port8'}},
+ 'dbmodules': {'db': {'database_name': '$testdir/db.replica2'}}}
conf_foo = {'libdefaults': {'default_realm': 'FOO'},
'domain_realm': {hostname: 'FOO'}}
-conf_slave3 = {'realms': {'$realm': {'iprop_slave_poll': '600',
- 'iprop_logfile': '$testdir/ulog.slave3',
- 'iprop_port': '$port8'},
- 'FOO': {'iprop_logfile': '$testdir/ulog.slave3'}},
- 'dbmodules': {'db': {'database_name': '$testdir/db.slave3'}}}
-
-krb5_conf_slave4 = {'domain_realm': {hostname: 'FOO'}}
-conf_slave4 = {'realms': {'$realm': {'iprop_slave_poll': '600',
- 'iprop_logfile': '$testdir/ulog.slave4',
- 'iprop_port': '$port8'}},
- 'dbmodules': {'db': {'database_name': '$testdir/db.slave4'}}}
+conf_rep3 = {'realms': {'$realm': {'iprop_slave_poll': '600',
+ 'iprop_logfile': '$testdir/ulog.replica3',
+ 'iprop_port': '$port8'},
+ 'FOO': {'iprop_logfile': '$testdir/ulog.replica3'}},
+ 'dbmodules': {'db': {'database_name': '$testdir/db.replica3'}}}
+
+krb5_conf_rep4 = {'domain_realm': {hostname: 'FOO'}}
+conf_rep4 = {'realms': {'$realm': {'iprop_slave_poll': '600',
+ 'iprop_logfile': '$testdir/ulog.replica4',
+ 'iprop_port': '$port8'}},
+ 'dbmodules': {'db': {'database_name': '$testdir/db.replica4'}}}
for realm in multidb_realms(kdc_conf=conf, create_user=False,
start_kadmind=True):
- slave1 = realm.special_env('slave1', True, kdc_conf=conf_slave1)
- slave1m = realm.special_env('slave1m', True, krb5_conf=conf_foo,
- kdc_conf=conf_slave1m)
- slave2 = realm.special_env('slave2', True, kdc_conf=conf_slave2)
+ replica1 = realm.special_env('replica1', True, kdc_conf=conf_rep1)
+ replica1m = realm.special_env('replica1m', True, krb5_conf=conf_foo,
+ kdc_conf=conf_rep1m)
+ replica2 = realm.special_env('replica2', True, kdc_conf=conf_rep2)
# A default_realm and domain_realm that do not match the KDC's
# realm. The FOO realm iprop_logfile setting is needed to run
- # kproplog during a slave3 test, since kproplog has no realm
+ # kproplog during a replica3 test, since kproplog has no realm
# option.
- slave3 = realm.special_env('slave3', True, krb5_conf=conf_foo,
- kdc_conf=conf_slave3)
+ replica3 = realm.special_env('replica3', True, krb5_conf=conf_foo,
+ kdc_conf=conf_rep3)
# A default realm and a domain realm map that differ.
- slave4 = realm.special_env('slave4', True, krb5_conf=krb5_conf_slave4,
- kdc_conf=conf_slave4)
+ replica4 = realm.special_env('replica4', True, krb5_conf=krb5_conf_rep4,
+ kdc_conf=conf_rep4)
# Define some principal names. pr3 is long enough to cause internal
# reallocs, but not long enough to grow the basic ulog entry size.
@@ -180,13 +180,13 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
kiprop_princ = 'kiprop/' + hostname
realm.extract_keytab(kiprop_princ, realm.keytab)
- # Create the initial slave databases.
+ # Create the initial replica databases.
dumpfile = os.path.join(realm.testdir, 'dump')
realm.run([kdb5_util, 'dump', dumpfile])
- realm.run([kdb5_util, 'load', dumpfile], slave1)
- realm.run([kdb5_util, 'load', dumpfile], slave2)
- realm.run([kdb5_util, '-r', realm.realm, 'load', dumpfile], slave3)
- realm.run([kdb5_util, 'load', dumpfile], slave4)
+ realm.run([kdb5_util, 'load', dumpfile], replica1)
+ realm.run([kdb5_util, 'load', dumpfile], replica2)
+ realm.run([kdb5_util, '-r', realm.realm, 'load', dumpfile], replica3)
+ realm.run([kdb5_util, 'load', dumpfile], replica4)
# Reinitialize the master ulog so we know exactly what to expect in
# it.
@@ -201,14 +201,14 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
realm.run([kadminl, 'modprinc', '+allow_tix', pr2])
check_ulog(6, 1, 6, [None, pr1, pr3, pr2, pr2, pr2])
- # Start kpropd for slave1 and get a full dump from master.
+ # Start kpropd for replica1 and get a full dump from master.
mark('propagate M->1 full')
- kpropd1 = realm.start_kpropd(slave1, ['-d'])
+ kpropd1 = realm.start_kpropd(replica1, ['-d'])
wait_for_prop(kpropd1, True, 1, 6)
- out = realm.run([kadminl, 'listprincs'], env=slave1)
+ out = realm.run([kadminl, 'listprincs'], env=replica1)
if pr1 not in out or pr2 not in out or pr3 not in out:
- fail('slave1 does not have all principals from master')
- check_ulog(1, 6, 6, [None], slave1)
+ fail('replica1 does not have all principals from master')
+ check_ulog(1, 6, 6, [None], replica1)
# Make a change and check that it propagates incrementally.
mark('propagate M->1 incremental')
@@ -216,35 +216,35 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
check_ulog(7, 1, 7, [None, pr1, pr3, pr2, pr2, pr2, pr2])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, False, 6, 7)
- check_ulog(2, 6, 7, [None, pr2], slave1)
- realm.run([kadminl, 'getprinc', pr2], env=slave1,
+ check_ulog(2, 6, 7, [None, pr2], replica1)
+ realm.run([kadminl, 'getprinc', pr2], env=replica1,
expected_msg='Attributes: DISALLOW_ALL_TIX')
- # Start kadmind -proponly for slave1. (Use the slave1m environment
- # which defines iprop_port to $port8.)
- slave1_out_dump_path = os.path.join(realm.testdir, 'dump.slave1.out')
- slave2_in_dump_path = os.path.join(realm.testdir, 'dump.slave2.in')
- slave2_kprop_port = str(realm.portbase + 9)
+ # Start kadmind -proponly for replica1. (Use the replica1m
+ # environment which defines iprop_port to $port8.)
+ replica1_out_dump_path = os.path.join(realm.testdir, 'dump.replica1.out')
+ replica2_in_dump_path = os.path.join(realm.testdir, 'dump.replica2.in')
+ replica2_kprop_port = str(realm.portbase + 9)
kadmind_proponly = realm.start_server([kadmind, '-r', realm.realm,
'-nofork', '-proponly',
'-W', '-p', kdb5_util,
'-K', kprop, '-k',
- slave2_kprop_port,
- '-F', slave1_out_dump_path],
- 'starting...', slave1m)
+ replica2_kprop_port,
+ '-F', replica1_out_dump_path],
+ 'starting...', replica1m)
# Test similar default_realm and domain_realm map settings with -r realm.
mark('propagate 1->3 full')
- slave3_in_dump_path = os.path.join(realm.testdir, 'dump.slave3.in')
+ replica3_in_dump_path = os.path.join(realm.testdir, 'dump.replica3.in')
kpropd3 = realm.start_server([kpropd, '-d', '-D', '-r', realm.realm, '-P',
- slave2_kprop_port, '-f', slave3_in_dump_path,
- '-p', kdb5_util, '-a', acl_file,
- '-A', hostname], 'ready', slave3)
+ replica2_kprop_port, '-f',
+ replica3_in_dump_path, '-p', kdb5_util, '-a',
+ acl_file, '-A', hostname], 'ready', replica3)
wait_for_prop(kpropd3, True, 1, 7)
- out = realm.run([kadminl, '-r', realm.realm, 'listprincs'], env=slave3)
+ out = realm.run([kadminl, '-r', realm.realm, 'listprincs'], env=replica3)
if pr1 not in out or pr2 not in out or pr3 not in out:
- fail('slave3 does not have all principals from slave1')
- check_ulog(1, 7, 7, [None], env=slave3)
+ fail('replica3 does not have all principals from replica1')
+ check_ulog(1, 7, 7, [None], env=replica3)
# Test an incremental propagation for the kpropd -r case.
mark('propagate M->1->3 incremental')
@@ -252,89 +252,91 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
check_ulog(8, 1, 8, [None, pr1, pr3, pr2, pr2, pr2, pr2, pr1])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, False, 7, 8)
- check_ulog(3, 6, 8, [None, pr2, pr1], slave1)
- realm.run([kadminl, 'getprinc', pr1], env=slave1,
+ check_ulog(3, 6, 8, [None, pr2, pr1], replica1)
+ realm.run([kadminl, 'getprinc', pr1], env=replica1,
expected_msg='Maximum ticket life: 0 days 00:20:00')
kpropd3.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd3, False, 7, 8)
- check_ulog(2, 7, 8, [None, pr1], slave3)
- realm.run([kadminl, '-r', realm.realm, 'getprinc', pr1], env=slave3,
+ check_ulog(2, 7, 8, [None, pr1], replica3)
+ realm.run([kadminl, '-r', realm.realm, 'getprinc', pr1], env=replica3,
expected_msg='Maximum ticket life: 0 days 00:20:00')
stop_daemon(kpropd3)
# Test dissimilar default_realm and domain_realm map settings (no
# -r realm).
mark('propagate 1->4 full')
- slave4_in_dump_path = os.path.join(realm.testdir, 'dump.slave4.in')
- kpropd4 = realm.start_server([kpropd, '-d', '-D', '-P', slave2_kprop_port,
- '-f', slave4_in_dump_path, '-p', kdb5_util,
+ replica4_in_dump_path = os.path.join(realm.testdir, 'dump.replica4.in')
+ kpropd4 = realm.start_server([kpropd, '-d', '-D', '-P',
+ replica2_kprop_port, '-f',
+ replica4_in_dump_path, '-p', kdb5_util,
'-a', acl_file, '-A', hostname], 'ready',
- slave4)
+ replica4)
wait_for_prop(kpropd4, True, 1, 8)
- out = realm.run([kadminl, 'listprincs'], env=slave4)
+ out = realm.run([kadminl, 'listprincs'], env=replica4)
if pr1 not in out or pr2 not in out or pr3 not in out:
- fail('slave4 does not have all principals from slave1')
+ fail('replica4 does not have all principals from replica1')
stop_daemon(kpropd4)
- # Start kpropd for slave2. The -A option isn't needed since we're
- # talking to the same host as master (we specify it anyway to
- # exercise the code), but slave2 defines iprop_port to $port8 so
- # it will talk to slave1. Get a full dump from slave1.
+ # Start kpropd for replica2. The -A option isn't needed since
+ # we're talking to the same host as master (we specify it anyway
+ # to exercise the code), but replica2 defines iprop_port to $port8
+ # so it will talk to replica1. Get a full dump from replica1.
mark('propagate 1->2 full')
- kpropd2 = realm.start_server([kpropd, '-d', '-D', '-P', slave2_kprop_port,
- '-f', slave2_in_dump_path, '-p', kdb5_util,
+ kpropd2 = realm.start_server([kpropd, '-d', '-D', '-P',
+ replica2_kprop_port, '-f',
+ replica2_in_dump_path, '-p', kdb5_util,
'-a', acl_file, '-A', hostname], 'ready',
- slave2)
+ replica2)
wait_for_prop(kpropd2, True, 1, 8)
- check_ulog(2, 7, 8, [None, pr1], slave2)
- out = realm.run([kadminl, 'listprincs'], env=slave1)
+ check_ulog(2, 7, 8, [None, pr1], replica2)
+ out = realm.run([kadminl, 'listprincs'], env=replica1)
if pr1 not in out or pr2 not in out or pr3 not in out:
- fail('slave2 does not have all principals from slave1')
+ fail('replica2 does not have all principals from replica1')
# Make another change and check that it propagates incrementally
- # to both slaves.
+ # to both replicas.
mark('propagate M->1->2 incremental')
realm.run([kadminl, 'modprinc', '-maxrenewlife', '22 hours', pr1])
check_ulog(9, 1, 9, [None, pr1, pr3, pr2, pr2, pr2, pr2, pr1, pr1])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, False, 8, 9)
- check_ulog(4, 6, 9, [None, pr2, pr1, pr1], slave1)
- realm.run([kadminl, 'getprinc', pr1], env=slave1,
+ check_ulog(4, 6, 9, [None, pr2, pr1, pr1], replica1)
+ realm.run([kadminl, 'getprinc', pr1], env=replica1,
expected_msg='Maximum renewable life: 0 days 22:00:00\n')
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, False, 8, 9)
- check_ulog(3, 7, 9, [None, pr1, pr1], slave2)
- realm.run([kadminl, 'getprinc', pr1], env=slave2,
+ check_ulog(3, 7, 9, [None, pr1, pr1], replica2)
+ realm.run([kadminl, 'getprinc', pr1], env=replica2,
expected_msg='Maximum renewable life: 0 days 22:00:00\n')
- # Reset the ulog on slave1 to force a full resync from master.
+ # Reset the ulog on replica1 to force a full resync from master.
# The resync will use the old dump file and then propagate
- # changes. slave2 should still be in sync with slave1 after the
- # resync, so make sure it doesn't take a full resync.
+ # changes. replica2 should still be in sync with replica1 after
+ # the resync, so make sure it doesn't take a full resync.
mark('propagate M->1->2 full')
- realm.run([kproplog, '-R'], slave1)
- check_ulog(1, 1, 1, [None], slave1)
+ realm.run([kproplog, '-R'], replica1)
+ check_ulog(1, 1, 1, [None], replica1)
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, True, 1, 9)
- check_ulog(4, 6, 9, [None, pr2, pr1, pr1], slave1)
+ check_ulog(4, 6, 9, [None, pr2, pr1, pr1], replica1)
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, False, 9, 9)
- check_ulog(3, 7, 9, [None, pr1, pr1], slave2)
+ check_ulog(3, 7, 9, [None, pr1, pr1], replica2)
# Make another change and check that it propagates incrementally to
- # both slaves.
+ # both replicas.
mark('propagate M->1->2 incremental (after reset)')
realm.run([kadminl, 'modprinc', '+allow_tix', pr2])
check_ulog(10, 1, 10, [None, pr1, pr3, pr2, pr2, pr2, pr2, pr1, pr1, pr2])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, False, 9, 10)
- check_ulog(5, 6, 10, [None, pr2, pr1, pr1, pr2], slave1)
- realm.run([kadminl, 'getprinc', pr2], env=slave1,
+ check_ulog(5, 6, 10, [None, pr2, pr1, pr1, pr2], replica1)
+ realm.run([kadminl, 'getprinc', pr2], env=replica1,
expected_msg='Attributes:\n')
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, False, 9, 10)
- check_ulog(4, 7, 10, [None, pr1, pr1, pr2], slave2)
- realm.run([kadminl, 'getprinc', pr2], env=slave2,
+ check_ulog(4, 7, 10, [None, pr1, pr1, pr2], replica2)
+ realm.run([kadminl, 'getprinc', pr2], env=replica2,
expected_msg='Attributes:\n')
# Create a policy and check that it propagates via full resync.
@@ -343,13 +345,13 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
check_ulog(1, 1, 1, [None])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, True, 10, 1)
- check_ulog(1, 1, 1, [None], slave1)
- realm.run([kadminl, 'getpol', 'testpol'], env=slave1,
+ check_ulog(1, 1, 1, [None], replica1)
+ realm.run([kadminl, 'getpol', 'testpol'], env=replica1,
expected_msg='Minimum number of password character classes: 2')
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, True, 10, 1)
- check_ulog(1, 1, 1, [None], slave2)
- realm.run([kadminl, 'getpol', 'testpol'], env=slave2,
+ check_ulog(1, 1, 1, [None], replica2)
+ realm.run([kadminl, 'getpol', 'testpol'], env=replica2,
expected_msg='Minimum number of password character classes: 2')
# Modify the policy and test that it also propagates via full resync.
@@ -358,13 +360,13 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
check_ulog(1, 1, 1, [None])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, True, 1, 1)
- check_ulog(1, 1, 1, [None], slave1)
- realm.run([kadminl, 'getpol', 'testpol'], env=slave1,
+ check_ulog(1, 1, 1, [None], replica1)
+ realm.run([kadminl, 'getpol', 'testpol'], env=replica1,
expected_msg='Minimum password length: 17')
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, True, 1, 1)
- check_ulog(1, 1, 1, [None], slave2)
- realm.run([kadminl, 'getpol', 'testpol'], env=slave2,
+ check_ulog(1, 1, 1, [None], replica2)
+ realm.run([kadminl, 'getpol', 'testpol'], env=replica2,
expected_msg='Minimum password length: 17')
# Delete the policy and test that it propagates via full resync.
@@ -373,13 +375,13 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
check_ulog(1, 1, 1, [None])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, True, 1, 1)
- check_ulog(1, 1, 1, [None], slave1)
- realm.run([kadminl, 'getpol', 'testpol'], env=slave1, expected_code=1,
+ check_ulog(1, 1, 1, [None], replica1)
+ realm.run([kadminl, 'getpol', 'testpol'], env=replica1, expected_code=1,
expected_msg='Policy does not exist')
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, True, 1, 1)
- check_ulog(1, 1, 1, [None], slave2)
- realm.run([kadminl, 'getpol', 'testpol'], env=slave2, expected_code=1,
+ check_ulog(1, 1, 1, [None], replica2)
+ realm.run([kadminl, 'getpol', 'testpol'], env=replica2, expected_code=1,
expected_msg='Policy does not exist')
# Modify a principal on the master and test that it propagates
@@ -389,13 +391,13 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
check_ulog(2, 1, 2, [None, pr1])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, False, 1, 2)
- check_ulog(2, 1, 2, [None, pr1], slave1)
- realm.run([kadminl, 'getprinc', pr1], env=slave1,
+ check_ulog(2, 1, 2, [None, pr1], replica1)
+ realm.run([kadminl, 'getprinc', pr1], env=replica1,
expected_msg='Maximum ticket life: 0 days 00:10:00')
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, False, 1, 2)
- check_ulog(2, 1, 2, [None, pr1], slave2)
- realm.run([kadminl, 'getprinc', pr1], env=slave2,
+ check_ulog(2, 1, 2, [None, pr1], replica2)
+ realm.run([kadminl, 'getprinc', pr1], env=replica2,
expected_msg='Maximum ticket life: 0 days 00:10:00')
# Delete a principal and test that it propagates incrementally.
@@ -404,13 +406,13 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
check_ulog(3, 1, 3, [None, pr1, pr3])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, False, 2, 3)
- check_ulog(3, 1, 3, [None, pr1, pr3], slave1)
- realm.run([kadminl, 'getprinc', pr3], env=slave1, expected_code=1,
+ check_ulog(3, 1, 3, [None, pr1, pr3], replica1)
+ realm.run([kadminl, 'getprinc', pr3], env=replica1, expected_code=1,
expected_msg='Principal does not exist')
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, False, 2, 3)
- check_ulog(3, 1, 3, [None, pr1, pr3], slave2)
- realm.run([kadminl, 'getprinc', pr3], env=slave2, expected_code=1,
+ check_ulog(3, 1, 3, [None, pr1, pr3], replica2)
+ realm.run([kadminl, 'getprinc', pr3], env=replica2, expected_code=1,
expected_msg='Principal does not exist')
# Rename a principal and test that it propagates incrementally.
@@ -420,16 +422,16 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
check_ulog(6, 1, 6, [None, pr1, pr3, renpr, pr1, renpr])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, False, 3, 6)
- check_ulog(6, 1, 6, [None, pr1, pr3, renpr, pr1, renpr], slave1)
- realm.run([kadminl, 'getprinc', pr1], env=slave1, expected_code=1,
+ check_ulog(6, 1, 6, [None, pr1, pr3, renpr, pr1, renpr], replica1)
+ realm.run([kadminl, 'getprinc', pr1], env=replica1, expected_code=1,
expected_msg='Principal does not exist')
- realm.run([kadminl, 'getprinc', renpr], env=slave1)
+ realm.run([kadminl, 'getprinc', renpr], env=replica1)
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, False, 3, 6)
- check_ulog(6, 1, 6, [None, pr1, pr3, renpr, pr1, renpr], slave2)
- realm.run([kadminl, 'getprinc', pr1], env=slave2, expected_code=1,
+ check_ulog(6, 1, 6, [None, pr1, pr3, renpr, pr1, renpr], replica2)
+ realm.run([kadminl, 'getprinc', pr1], env=replica2, expected_code=1,
expected_msg='Principal does not exist')
- realm.run([kadminl, 'getprinc', renpr], env=slave2)
+ realm.run([kadminl, 'getprinc', renpr], env=replica2)
pr1 = renpr
@@ -439,10 +441,10 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
check_ulog(1, 1, 1, [None])
kpropd1.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd1, True, 6, 1)
- check_ulog(1, 1, 1, [None], slave1)
+ check_ulog(1, 1, 1, [None], replica1)
kpropd2.send_signal(signal.SIGUSR1)
wait_for_prop(kpropd2, True, 6, 1)
- check_ulog(1, 1, 1, [None], slave2)
+ check_ulog(1, 1, 1, [None], replica2)
# Stop the kprop daemons so we can test kpropd -t.
realm.stop_kpropd(kpropd1)
@@ -451,30 +453,30 @@ for realm in multidb_realms(kdc_conf=conf, create_user=False,
mark('kpropd -t')
# Test the case where no updates are needed.
- out = realm.run_kpropd_once(slave1, ['-d'])
+ out = realm.run_kpropd_once(replica1, ['-d'])
if 'KDC is synchronized' not in out:
fail('Expected synchronized from kpropd -t')
- check_ulog(1, 1, 1, [None], slave1)
+ check_ulog(1, 1, 1, [None], replica1)
# Make a change on the master and fetch it incrementally.
realm.run([kadminl, 'modprinc', '-maxlife', '5 minutes', pr1])
check_ulog(2, 1, 2, [None, pr1])
- out = realm.run_kpropd_once(slave1, ['-d'])
+ out = realm.run_kpropd_once(replica1, ['-d'])
if 'Got incremental updates (sno=2 ' not in out:
fail('Expected full dump and synchronized from kpropd -t')
- check_ulog(2, 1, 2, [None, pr1], slave1)
- realm.run([kadminl, 'getprinc', pr1], env=slave1,
+ check_ulog(2, 1, 2, [None, pr1], replica1)
+ realm.run([kadminl, 'getprinc', pr1], env=replica1,
expected_msg='Maximum ticket life: 0 days 00:05:00')
# Propagate a policy change via full resync.
realm.run([kadminl, 'addpol', '-minclasses', '3', 'testpol'])
check_ulog(1, 1, 1, [None])
- out = realm.run_kpropd_once(slave1, ['-d'])
+ out = realm.run_kpropd_once(replica1, ['-d'])
if ('Full propagation transfer finished' not in out or
'KDC is synchronized' not in out):
fail('Expected full dump and synchronized from kpropd -t')
- check_ulog(1, 1, 1, [None], slave1)
- realm.run([kadminl, 'getpol', 'testpol'], env=slave1,
+ check_ulog(1, 1, 1, [None], replica1)
+ realm.run([kadminl, 'getpol', 'testpol'], env=replica1,
expected_msg='Minimum number of password character classes: 3')
success('iprop tests')
diff --git a/src/tests/t_kprop.py b/src/tests/t_kprop.py
index f352ec8..c33e4fe 100755
--- a/src/tests/t_kprop.py
+++ b/src/tests/t_kprop.py
@@ -1,6 +1,6 @@
from k5test import *
-conf_slave = {'dbmodules': {'db': {'database_name': '$testdir/db.slave'}}}
+conf_replica = {'dbmodules': {'db': {'database_name': '$testdir/db.replica'}}}
def setup_acl(realm):
acl_file = os.path.join(realm.testdir, 'kpropd-acl')
@@ -21,71 +21,71 @@ def check_output(kpropd):
# kprop/kpropd are the only users of krb5_auth_con_initivector, so run
# this test over all enctypes to exercise mkpriv cipher state.
for realm in multipass_realms(create_user=False):
- slave = realm.special_env('slave', True, kdc_conf=conf_slave)
+ replica = realm.special_env('replica', True, kdc_conf=conf_replica)
# Set up the kpropd acl file.
setup_acl(realm)
- # Create the slave db.
+ # Create the replica db.
dumpfile = os.path.join(realm.testdir, 'dump')
realm.run([kdb5_util, 'dump', dumpfile])
- realm.run([kdb5_util, 'load', dumpfile], slave)
- realm.run([kdb5_util, 'stash', '-P', 'master'], slave)
+ realm.run([kdb5_util, 'load', dumpfile], replica)
+ realm.run([kdb5_util, 'stash', '-P', 'master'], replica)
# Make some changes to the master db.
realm.addprinc('wakawaka')
# Start kpropd.
- kpropd = realm.start_kpropd(slave, ['-d'])
+ kpropd = realm.start_kpropd(replica, ['-d'])
realm.run([kdb5_util, 'dump', dumpfile])
realm.run([kprop, '-f', dumpfile, '-P', str(realm.kprop_port()), hostname])
check_output(kpropd)
- realm.run([kadminl, 'listprincs'], slave, expected_msg='wakawaka')
+ realm.run([kadminl, 'listprincs'], replica, expected_msg='wakawaka')
# default_realm tests follow.
# default_realm and domain_realm different than realm.realm (test -r argument).
-conf_slave2 = {'dbmodules': {'db': {'database_name': '$testdir/db.slave2'}}}
-krb5_conf_slave2 = {'libdefaults': {'default_realm': 'FOO'},
- 'domain_realm': {hostname: 'FOO'}}
+conf_rep2 = {'dbmodules': {'db': {'database_name': '$testdir/db.replica2'}}}
+krb5_conf_rep2 = {'libdefaults': {'default_realm': 'FOO'},
+ 'domain_realm': {hostname: 'FOO'}}
# default_realm and domain_realm map differ.
-conf_slave3 = {'dbmodules': {'db': {'database_name': '$testdir/db.slave3'}}}
-krb5_conf_slave3 = {'domain_realm': {hostname: 'BAR'}}
+conf_rep3 = {'dbmodules': {'db': {'database_name': '$testdir/db.replica3'}}}
+krb5_conf_rep3 = {'domain_realm': {hostname: 'BAR'}}
realm = K5Realm(create_user=False)
-slave2 = realm.special_env('slave2', True, kdc_conf=conf_slave2,
- krb5_conf=krb5_conf_slave2)
-slave3 = realm.special_env('slave3', True, kdc_conf=conf_slave3,
- krb5_conf=krb5_conf_slave3)
+replica2 = realm.special_env('replica2', True, kdc_conf=conf_rep2,
+ krb5_conf=krb5_conf_rep2)
+replica3 = realm.special_env('replica3', True, kdc_conf=conf_rep3,
+ krb5_conf=krb5_conf_rep3)
setup_acl(realm)
-# Create the slave db.
+# Create the replica db.
dumpfile = os.path.join(realm.testdir, 'dump')
realm.run([kdb5_util, 'dump', dumpfile])
-realm.run([kdb5_util, '-r', realm.realm, 'load', dumpfile], slave2)
-realm.run([kdb5_util, 'load', dumpfile], slave3)
+realm.run([kdb5_util, '-r', realm.realm, 'load', dumpfile], replica2)
+realm.run([kdb5_util, 'load', dumpfile], replica3)
# Make some changes to the master db.
realm.addprinc('wakawaka')
# Test override of default_realm with -r realm argument.
-kpropd = realm.start_kpropd(slave2, ['-r', realm.realm, '-d'])
+kpropd = realm.start_kpropd(replica2, ['-r', realm.realm, '-d'])
realm.run([kdb5_util, 'dump', dumpfile])
realm.run([kprop, '-r', realm.realm, '-f', dumpfile, '-P',
str(realm.kprop_port()), hostname])
check_output(kpropd)
-realm.run([kadminl, '-r', realm.realm, 'listprincs'], slave2,
+realm.run([kadminl, '-r', realm.realm, 'listprincs'], replica2,
expected_msg='wakawaka')
stop_daemon(kpropd)
# Test default_realm and domain_realm mismatch.
-kpropd = realm.start_kpropd(slave3, ['-d'])
+kpropd = realm.start_kpropd(replica3, ['-d'])
realm.run([kdb5_util, 'dump', dumpfile])
realm.run([kprop, '-f', dumpfile, '-P', str(realm.kprop_port()), hostname])
check_output(kpropd)
-realm.run([kadminl, 'listprincs'], slave3, expected_msg='wakawaka')
+realm.run([kadminl, 'listprincs'], replica3, expected_msg='wakawaka')
success('kprop tests')
diff --git a/src/util/k5test.py b/src/util/k5test.py
index 6001246..3aec1ef 100644
--- a/src/util/k5test.py
+++ b/src/util/k5test.py
@@ -322,13 +322,13 @@ Scripts may use the following realm methods and attributes:
or similar methods.
* realm.start_kpropd(env, args=[]): Start a kpropd process. Pass an
- environment created with realm.special_env() for the slave. If args
- is given, it contains a list of additional kpropd arguments.
+ environment created with realm.special_env() for the replica. If
+ args is given, it contains a list of additional kpropd arguments.
Returns a handle to the kpropd process.
* realm.run_kpropd_once(env, args=[]): Run kpropd once, using the -t
flag. Pass an environment created with realm.special_env() for the
- slave. If args is given, it contains a list of additional kpropd
+ replica. If args is given, it contains a list of additional kpropd
arguments. Returns the kpropd output.
* realm.realm: The realm's name.
@@ -1019,10 +1019,10 @@ class K5Realm(object):
self._kadmind_proc = None
def _kpropd_args(self):
- slavedump_path = os.path.join(self.testdir, 'incoming-slave-datatrans')
+ datatrans_path = os.path.join(self.testdir, 'incoming-datatrans')
kpropdacl_path = os.path.join(self.testdir, 'kpropd-acl')
return [kpropd, '-D', '-P', str(self.kprop_port()),
- '-f', slavedump_path, '-p', kdb5_util, '-a', kpropdacl_path]
+ '-f', datatrans_path, '-p', kdb5_util, '-a', kpropdacl_path]
def start_kpropd(self, env, args=[]):
proc = _start_daemon(self._kpropd_args() + args, env, 'ready')
@@ -1362,6 +1362,6 @@ kvno = os.path.join(buildtop, 'clients', 'kvno', 'kvno')
kdestroy = os.path.join(buildtop, 'clients', 'kdestroy', 'kdestroy')
kpasswd = os.path.join(buildtop, 'clients', 'kpasswd', 'kpasswd')
t_inetd = os.path.join(buildtop, 'tests', 'dejagnu', 't_inetd')
-kproplog = os.path.join(buildtop, 'slave', 'kproplog')
-kpropd = os.path.join(buildtop, 'slave', 'kpropd')
-kprop = os.path.join(buildtop, 'slave', 'kprop')
+kproplog = os.path.join(buildtop, 'kprop', 'kproplog')
+kpropd = os.path.join(buildtop, 'kprop', 'kpropd')
+kprop = os.path.join(buildtop, 'kprop', 'kprop')
diff --git a/src/util/testrealm.py b/src/util/testrealm.py
index fba3ae0..ce32432 100644
--- a/src/util/testrealm.py
+++ b/src/util/testrealm.py
@@ -42,7 +42,7 @@ progpaths = [
os.path.join('clients', 'ksu'),
os.path.join('clients', 'kvno'),
os.path.join('clients', 'kswitch'),
- 'slave'
+ 'kprop'
]
# Add program directories to the beginning of PATH.
diff --git a/src/windows/installer/wix/custom/custom.cpp b/src/windows/installer/wix/custom/custom.cpp
index 3ef726d..3460def 100644
--- a/src/windows/installer/wix/custom/custom.cpp
+++ b/src/windows/installer/wix/custom/custom.cpp
@@ -328,7 +328,7 @@ struct _KillProc {
#define RV_BAIL if(rv != ERROR_SUCCESS) goto _cleanup
MSIDLLEXPORT KillRunningProcesses( MSIHANDLE hInstall ) {
- return KillRunningProcessesSlave( hInstall, TRUE );
+ return KillRunningProcessesWorker( hInstall, TRUE );
}
/* When listing running processes, we populate the ListBox table with
@@ -338,10 +338,10 @@ MSIDLLEXPORT KillRunningProcesses( MSIHANDLE hInstall ) {
*/
MSIDLLEXPORT ListRunningProcesses( MSIHANDLE hInstall ) {
- return KillRunningProcessesSlave( hInstall, FALSE );
+ return KillRunningProcessesWorker( hInstall, FALSE );
}
-UINT KillRunningProcessesSlave( MSIHANDLE hInstall, BOOL bKill )
+UINT KillRunningProcessesWorker( MSIHANDLE hInstall, BOOL bKill )
{
UINT rv = ERROR_SUCCESS;
_KillProc * kpList;
diff --git a/src/windows/installer/wix/custom/custom.h b/src/windows/installer/wix/custom/custom.h
index 3b28eec..53a250a 100644
--- a/src/windows/installer/wix/custom/custom.h
+++ b/src/windows/installer/wix/custom/custom.h
@@ -56,7 +56,7 @@ SOFTWARE.
void ShowMsiError(MSIHANDLE, DWORD, DWORD);
UINT SetAllowTgtSessionKey( MSIHANDLE hInstall, BOOL pInstall );
-UINT KillRunningProcessesSlave( MSIHANDLE hInstall, BOOL bKill );
+UINT KillRunningProcessesWorker( MSIHANDLE hInstall, BOOL bKill );
/* exported */
MSIDLLEXPORT AbortMsiImmediate( MSIHANDLE );
diff --git a/src/windows/winlevel.h b/src/windows/winlevel.h
index 13ad8fc..b7ae959 100644
--- a/src/windows/winlevel.h
+++ b/src/windows/winlevel.h
@@ -24,8 +24,7 @@
*/
/*
- * This is the slave file for Windows version stamping purposes.
-/* This value should be an ever increasing number that is
+ * This value should be an ever increasing number that is
* updated for each alpha, beta, final release. This will ensure
* that file identifiers are unique
*/