Bug 632238

(In reply to comment #0)
> Description of problem:
>  - Expand overview to relate "access levels" to "authorization" in overview
>  - Order subsections the same as concepts are introduced in overview, and how
> they are referenced, e.g. authentication before authorization because that is
> the order they are introduced and authorization refers to details of
> authentication

Good idea, but restructuring will have to happen later. Created BZ #633503.

> 
>  3.1. Access Levels
>   - Strike "Access Levels" header under the chapter header

Fixed.

>   - Config refers to condor_config.root, which does not exist anymore (I
> believe this is logged in another BZ as well)

<varlistentry>
	<term><parameter>CONFIG</parameter></term>
	<listitem>
		<para>
			Provides access to modify the configuration of services using <command>condor_config_val</command>. By default, this level of access can change any configuration parameters of a Condor pool. The <parameter>CONFIG</parameter> access level implies <parameter>READ</parameter> access.
		</para>

	</listitem>

</varlistentry>

When I find the other BZ, I'll mark it as a dupe.


> 
>  Table 3.1. Registered Commands
>   - I'm confused by "The command that initiates a new negotiation cycle" - I
> believe this is resolved by using my table though.

Your table is now in there.

>   - How do we map the information from the table onto actual configuration? 
> Suggest changing "Access level required" to Context as that's the correct

 <thead>
	<row>
		<entry>
			Activity
		</entry>
		<entry>
			Service
		</entry>
		<entry>
			Security Context
		</entry>

	</row>

</thead>

> security jargon here, and moving the table into an appendix that is referenced
> throughout the chapter.  These security contexts can be used in the more
> restrictive security context (authentication, integrity, etc) as well as the
> Host-Based security (which is the type we ship by default).  This table is
> really meant as a reference to ease the understanding of the type of security
> context needed for a certain task.  It is important we keep the jargon the
> same, as the format we tell users to use in 3.2 is SEC_CONTEXT_FEATURE, and the
> table is providing the type of CONTEXT for given activities.  There needs to be
> better wording to clarify what the table is representing in the overall
> security configuration.

I'll restructure this for 1.4. Added to BZ #633503.

> 
>   Also, the table needs to be updated to the one I provided earlier.

This was done in BZ #618389.

> 
>  3.2. Security negotiation
>   - Concept needs introduction in the overview
>   - "Negotiation is performed by the condor_negotiator service" - incorrect as
> negotiation happens between any client and service when a connection is made
>   - Need link between Access Levels and /CONTEXT/ or use common vernacular
> throughout.  I suggest using context.
>   - DEFAULT concept introduced but not explained.  From the condor manual "The
> DEFAULT value for <context> provides a way to set a policy for all access
> levels (READ, WRITE, etc.) that do not have a specific configuration variable
> defined"

Added to BZ #633503

> 
>  Table 3.2. Security negotiation resolution
>   - Left column appears to be first row, needs fixing
> 
>  Table 3.3. Security features negotiation resolution
>   - Left column appears to be first row, needs fixing

 It should be rendering OK now.

> 
>  3.3. Authentication
>   - Needs overview (see condor manual)

Added to BZ #633503

>   - "cmmunication"

Fixed.

>   - "acces"

Fixed.

>   - "The possible methods are" described in the next section. - awkward to list
> them twice so close together.

Deleted the first list.

> 
>  3.4. Authentication methods
>   - Need link between "Windows"" and NTSSAPI
>   - Generally need linkage between type here and from previous section, e.g.
> Filesystem = FS
>   SSL
>    - Needs to expand with an example (example for setting up a Certificate
> Authority for use with SSL provided in earlier BZ, but here it is again:
> http://pages.cs.wisc.edu/~zmiller/ca-howto/)

Added to BZ #633503

> 
>   Password
>    - "onyl"

Fixed.

>    - "servies"

Fixed.

>    - "CONFIG-LEVEL" ?  Think this should be <CONFIG>-level or some such.

<para>
	Storing a pool password requires <parameter><replaceable>CONFIG</replaceable>-LEVEL</parameter> access. The pool password can be set remotely, but this method is only recommended if it takes place using an encrypted channel.
</para>

> 
>   Filesystem
>    - "srvice"

Fixed. So many typos :(

> 
>   - No mention of FS_REMOTE (File System Remote)

There's some mention of FS_REMOTE in the sections that haven't been completed yet, which will happen after 1.3. Sorry.

LKB

(In reply to comment #1)
> >  3.2. Security negotiation
> >   - Concept needs introduction in the overview
> >   - "Negotiation is performed by the condor_negotiator service" - incorrect as
> > negotiation happens between any client and service when a connection is made

This clarification needs to be addressed in 1.3.

> >   - Need link between Access Levels and /CONTEXT/ or use common vernacular
> > throughout.  I suggest using context.
> >   - DEFAULT concept introduced but not explained.  From the condor manual "The
> > DEFAULT value for <context> provides a way to set a policy for all access
> > levels (READ, WRITE, etc.) that do not have a specific configuration variable
> > defined"

We need to at least give a small blurb about DEFAULT security since we do reference it.

> > 
> >  Table 3.2. Security negotiation resolution
> >   - Left column appears to be first row, needs fixing
> > 
> >  Table 3.3. Security features negotiation resolution
> >   - Left column appears to be first row, needs fixing
> 
>  It should be rendering OK now.

Both still look the same.  Possible staging isn't updated?

> > 
> >  3.4. Authentication methods
> >   - Need link between "Windows"" and NTSSAPI
> >   - Generally need linkage between type here and from previous section, e.g.
> > Filesystem = FS
> >   SSL
> >    - Needs to expand with an example (example for setting up a Certificate
> > Authority for use with SSL provided in earlier BZ, but here it is again:
> > http://pages.cs.wisc.edu/~zmiller/ca-howto/)
> 
> Added to BZ #633503

This really needs to be addressed for 1.3 as well.  We need to provide linkage between the previous section and what the authentication types are.

> >    - "CONFIG-LEVEL" ?  Think this should be <CONFIG>-level or some such.
> 
> <para>
>  Storing a pool password requires
> <parameter><replaceable>CONFIG</replaceable>-LEVEL</parameter> access. The pool
> password can be set remotely, but this method is only recommended if it takes
> place using an encrypted channel.
> </para>

This is still coming out as: CONFIG-LEVEL, only all in italics.  Staging not updated for some reason?

> > 
> >   - No mention of FS_REMOTE (File System Remote)
> 
> There's some mention of FS_REMOTE in the sections that haven't been completed
> yet, which will happen after 1.3. Sorry.
> 
> LKB

Revision 6.19 should be on the stage now.

LKB

Issues from Comment #2 still remain.

(In reply to comment #2)
> (In reply to comment #1)
> > >  3.2. Security negotiation
> > >   - Concept needs introduction in the overview
> > >   - "Negotiation is performed by the condor_negotiator service" - incorrect as
> > > negotiation happens between any client and service when a connection is made
> 
> This clarification needs to be addressed in 1.3.

<para>
	Security settings are determined through a security negotiation process. Security negotiation is used to determine what security features are required for each connection: authentication, encryption, integrity checking, or a combination. Negotiation also defines which protocol to use for each feature. 
</para>

> 
> > >   - Need link between Access Levels and /CONTEXT/ or use common vernacular
> > > throughout.  I suggest using context.

Changed instances of access level to context.

> > >   - DEFAULT concept introduced but not explained.  From the condor manual "The
> > > DEFAULT value for <context> provides a way to set a policy for all access
> > > levels (READ, WRITE, etc.) that do not have a specific configuration variable
> > > defined"
> 
> We need to at least give a small blurb about DEFAULT security since we do
> reference it.

<listitem>
	<para>
		<parameter>DEFAULT</parameter>
	</para>
	<para>
		The <parameter>DEFAULT</parameter> value provides a way to set a policy for all access levels that do not have a specific configuration variable defined.
	</para>
</listitem>


> 
> > > 
> > >  Table 3.2. Security negotiation resolution
> > >   - Left column appears to be first row, needs fixing
> > > 
> > >  Table 3.3. Security features negotiation resolution
> > >   - Left column appears to be first row, needs fixing
> > 
> >  It should be rendering OK now.
> 
> Both still look the same.  Possible staging isn't updated?

It looks OK to me. What specific errors are you seeing? I know it's not pretty, but everything is in the right place. We need to come up with a different way to present this information. I've requested a graphic that we can drop in to the book post 1.3:

https://engineering.redhat.com/rt3/Ticket/Display.html?id=73239

> 
> > > 
> > >  3.4. Authentication methods
> > >   - Need link between "Windows"" and NTSSAPI
> > >   - Generally need linkage between type here and from previous section, e.g.
> > > Filesystem = FS
> > >   SSL
> > >    - Needs to expand with an example (example for setting up a Certificate
> > > Authority for use with SSL provided in earlier BZ, but here it is again:
> > > http://pages.cs.wisc.edu/~zmiller/ca-howto/)
> > 
> > Added to BZ #633503
> 
> This really needs to be addressed for 1.3 as well.  We need to provide linkage
> between the previous section and what the authentication types are.

I understand this, but time is short. We'll get it in as soon after 1.3 as we can. Unless you have a quick one or two sentences I can drop in now?

> 
> > >    - "CONFIG-LEVEL" ?  Think this should be <CONFIG>-level or some such.
> > 
> > <para>
> >  Storing a pool password requires
> > <parameter><replaceable>CONFIG</replaceable>-LEVEL</parameter> access. The pool
> > password can be set remotely, but this method is only recommended if it takes
> > place using an encrypted channel.
> > </para>
> 
> This is still coming out as: CONFIG-LEVEL, only all in italics.  Staging not
> updated for some reason?

The original XML looks like this:
<parameter><replaceable>CONFIG</replaceable>-LEVEL</parameter>

Which, it seems, the CSS is rendering as all in italics.

I've changed this instance to:

<command><replaceable>CONFIG</replaceable>-LEVEL</command>

which should hopefully change the rendering.

LKB

Rob, are you going to give Lana "a quick one or two sentences I can drop in now?" from the previous comment or shall we verify this one as is?

The remaining comments have been addressed via irc yesterday (9/20).  The FS_REMOTE is now documented, as well as linkage between the auth methods and condor's configuration terms.  My review of those changes has produced the following changes:


Remote Filesystem - Remove " This authentication method is only appropriate for clients and services that are on the same physical computer."

"the CONFIGsecurity context" - Need space between CONFIG and security

(In reply to comment #7)
> The remaining comments have been addressed via irc yesterday (9/20).  The
> FS_REMOTE is now documented, as well as linkage between the auth methods and
> condor's configuration terms.  My review of those changes has produced the
> following changes:
> 
> 
> Remote Filesystem - Remove " This authentication method is only appropriate for
> clients and services that are on the same physical computer."

Gone.

> 
> "the CONFIGsecurity context" - Need space between CONFIG and security

<para>
	To store a pool password, the <parameter><replaceable>CONFIG</replaceable></parameter> security context is required. The pool password can be set remotely, but this method is only recommended if it takes place using an encrypted channel.
</para>

Look for version 6.22. Coming to a stage near you within the hour.

LKB