| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
All of rst_source/ is now just in doc/.
The krb_ prefix is stripped from the document sub-directories.
rst_tools are now just tools.
The section headers of kadmind, krb5kdc, and sserver match as conflict markers.
bigredbutton: whitespace
ticket: 7409
|
| |
|
|
|
|
|
| |
Mention the options on the synopsis line, and do not imply that
the principal argument(s) for ktadd are optional.
reST line blocks are needed to keep the two forms of ktadd on
separate lines.
|
| |
|
|
|
|
| |
We should include the stashsrvpw content in that section, not
the list content. Likewise, the list_policy content instead
of the destroy_policy content.
|
| |
|
|
|
|
| |
This text has not caught up with changes to the utility itself.
As a side effect, our output text box is narrower and does not have
to scroll on as many browser windows.
|
| |
|
|
|
|
|
| |
The keyfile worth overriding is the one in kdc.conf. Though using
stash -f would override kdb5_util's -sf argument, there is no reason to
pass both flags to the same invocation.
In any case, the "at startup" language is not really correct.
|
| |
|
|
| |
The policy must be unused, not the delete_policy command.
|
| |
|
|
|
|
|
|
| |
It's really not appropriate for the "examples" subsection of
"Adding, modifying and deleting principals".
While here, update the enctype recommendation for cross-realm principals
to something that does not include weak crypto.
|
| |
|
|
|
| |
Start with a capital letter and end with a full stop, making
the description a sentence (or at least close to one).
|
| |
|
|
|
|
| |
The target principal and restrictions arguments are not orthogonal;
a target principal argument must be given in order for a restriction
list to be supplied.
|
| |
|
|
|
|
|
|
|
| |
It is an eggregious security violation to give all admin principals
admin rights and then give all null instances permission to change
the password of the associated admin instance.
While here, don't assume that admin and root are the only non-null
instances, and correct the formatting of an entry with restrictions.
|
| |
|
|
| |
Make it a special note in the documentation to help it stand out.
|
| |
|
|
| |
Grammar fixup and avoid jargon.
|
| |
|
|
|
| |
Tweak the wording a bit to be more clear and avoid using multiple
words deriving from the stem "use" in close succession.
|
| |
|
|
|
|
|
|
|
| |
Even though they are subject to vulnerabilities via DNS spoofing
and we accordingly don't recommend their use, we do have the code
to use them. Just as we document dns_lookup_realm in krb5.conf(5),
document them here.
ticket: 7407
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There are, unfortunately, still some single-DES deployments out
there. Try to help them along by documenting a procedure for
migrating to stronger crypto.
The texinfo install guide had a section on "upgrading", but it was
not really suitable for direct import into a RST document. For one,
it gave a high profile to the on-disk incompatibilities in upgrades
to 1.1 and 1.2. It also was driven at upgrading *to* triple-des (or RC4),
which are something of a dead-end. This new text attempts to be more
general and applicable to today's environment.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It's a slightly less-contrived use case of the utility than the
other example, which reads more like a usage statement.
Give a motivating sentence before each example, and note that this
new example is not needed in the general upgrade case.
The need to dump/load for upgrades prior to 1.2 was documented in
the texinfo install guide, but not in any RST sources until now.
ticket: 7407
|
| |
|
|
| |
ticket: 7375
|
| |
|
|
| |
ticket: 7376
|
| |
|
|
| |
ticket: 7379
|
| |
|
|
|
|
|
|
|
|
|
|
| |
New options:
-p path-to-kdb5_util
-K path-to-kprop
-F dump-file
These are needed for testing without first having to install.
ticket: 7372
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make kpropd in iprop mode fork a child to listen for kprops from the
master. The child writes progress and outcome reports to the parent
for each kprop. This fixes a race between asking for a full resync
and setting up a listener socket for it.
- Add runonce (-t) for kpropd do_standalone() too.
- Add a new iprop parameter: iprop_resync_timeout. kpropd will keep
asking for incremental updates while waiting for a full resync to
finish, and will re-request a full resync if kadmind continues to
indicate that one is needed after this timeout passes since the
previous full resync was requested.
- Allow polling intervals less than 10 seconds.
[ghudson@mit.edu: split out debug output changes; note polling interval
change in commit message]
ticket: 7373
|
| | |
|
| |
|
|
|
|
|
|
| |
This page gets rendered for the web with Sphinx but is also turned
into the krb5_conf.5 manual page. We need to use three-hyphen
em dashes for the Sphynx config, but those are a bit long for
monospace terminal output. Since the dash here can easily be
changed to a comma, do so, and avoid the conflict of formatting.
|
| |
|
|
|
|
|
|
|
| |
Our sphinx configuration uses SmartyPants, which produces smart
quotes and dashes in HTML output, using '--' for en dash and
'---' for em dash. (This is also the LaTeX convention.)
These points in the text are meant to be em dashes, so format them
as such. Also standardize on no spaces around the dash per
Chicago Manual of Style (and others).
|
| |
|
|
|
| |
Also, move [logging] section documentation after [dbmodules]
documentation.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Do not leave anyone thinking that they might have to specify it
in the config file to get the standard behavior.
|
| |
|
|
|
|
|
|
| |
For Unix-like platforms, add %{username} to the path expansion
facility, expanding to the result of getpwuid on the euid.
Also, for manual testing convenience, make t_expand_path print the
result if no second argument is given.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simply adds KADM5_API_VERSION_4 and various fields to the
policy structures:
- attributes (policy-ish principal attributes)
- max_life (max ticket life)
- max_renewable_life (max ticket renewable life)
- allowed_keysalts (allowed key/salt types)
- TL data (future policy extensions)
Of these only allowed_keysalts is currently implemented.
Some refactoring of TL data handling is also done.
ticket: 7223 (new)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add DEFCCNAME, DEFKTNAME, and DEFCKTNAME configure variables to
change the built-in ccache and keytab names.
* Add krb5-config options to display the built-in ccache and keytab
names.
* In the default build, use krb5-config to discover the system's
built-in ccache and keytab names and use them (if not overridden).
This can be controlled with the --with-krb5-config=PATH or
--without-krb5-config configure options.
* Make the built-in ccache name subject to parameter expansion.
ticket: 7221 (new)
|
| |
|
|
|
|
|
| |
Like default_keytab_name and default_client_keytab_name,
default_ccache_name is subject to parameter expansion.
ticket: 7220 (new)
|
| |
|
|
|
|
|
| |
Make the default_keytab_name and default_client_keytab_name variables
subject to parameter expansion.
ticket: 7219 (new)
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
It seems to be "more correct".
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default client keytab is intended to be used to automatically
acquire initial credentials for client applications. The current
hardcoded default is a placeholder, and will likely change before
1.11.
Add test framework settings to ensure that a system default client
keytab doesn't interfere with tests, and to allow tests to be written
to deliberately use the default client keytab.
Add documentation about keytabs to the concepts section of the RST
docs, and describe the default client keytab there.
ticket: 7188 (new)
|
| |
|
|
|
| |
Explicitly state that a module name will usually be the same as the
shared object name, but doesn't have to be.
|
| | |
|