Description of problem: General question: Throughout the appendix, we refer to the application as "condor", but in the manual we use MRG Grid. Do we want/should we have a uniform means for referring to what we ship (either condor or MRG Grid)? General Comment: I'd suggest moving away from $() when denoting a parameter in text. $() is used in condor's configuration when referencing another param, so it should be kept in the examples, but it doesn't really look right in the text (and isn't internally consistent with other areas of the docs). I believe I've caught most, if not all, places where this is done but be on the look out for places I missed. From list of SUBSYSTEM - Remove SUBMIT, TOOL, QUILL Also, SUBSYSTEMs are not pre-defined configuration variables as implied by the section header. They are solely defined within the configuration file, and by how daemons register with the collector. Suggest either moving this list to another section (A.8 SUBSYSTEM?). LOCAL_XACT_BACKUP_FILTER - Change all 'xact's to 'transaction's in the description X_CONSOLE_DISPLAY - "display that condor should ..." -> display that the condor kbdd daemon should ..." Suggest removing the subsystem list in "Logging configuration variables". It's the same as earlier and is duplicated information. $(STARTD_LOG) -> STARTD_LOG $(SUBSYSTEM_LOG) -> SUBSYSTEM_LOG LOGS_USE_TIMESTAMP - Format is: [Month]/[Day]/[Year] [Hour]:[Minute]:[Second] D_ALL - "There is no need to list any other debug levels in addition to D_ALL" Sadly, this isn't true. It provides more verbose logging than D_FULLDEBUG, but it doesn't provide ALL levels of logging. Some items, like D_SECURITY, must still be added to the debug level to get that level of logging. Suggest removing the sentence as the real description is likely too convoluted for the manual. $(SUBSYSTEM_DEBUG) -> SUBSYSTEM_DEBUG $(SUBSYSTEM_LOG) -> SUBSYSTEM_LOG $(SUBSYSTEM_[LEVEL]_LOG) -> SUBSYSTEM_[LEVEL]_LOG HOSTALLOW... -> ALLOW... HOSTDENY -> DENY SETTABLE_ATTRS... - Need a reference to the new security chapter that will be discussing settable params (source: http://www.cs.wisc.edu/condor/manual/v7.5/3_6Security.html#SECTION004611000000000000000) ...and is required for Quill. - Remove. We don't ship/support Quill. SUBSYSTEM_EXPRS - Remove all mention of SUBSYSTEM_EXPRS. SUBSYSTEM_ATTRS is the new syntax and there's no reason to complicate the documentation by mentioning the old param name. DAEMON_SHUTDOWN - Remove mention of glide-in. "file descriptors the Condor daemon is allowed to use ..." -> file descriptors the Condor daemons are allowed to use ... UPDATE_COLLECTOR_WITH_TCP - Remove mention of flocking (...not any sites that a condor_schedd might flock to) MASTER_WAITS_FOR_GCB_BROKER - Remove mention of condor_glidein UID_DOMAIN - Suggest using examples with redhat.com instead of cs.wisc.edu $(UID_DOMAIN) -> UID_DOMAIN "Running standard universe jobs as user nobody enhances security and should cause no problems, because the jobs use remote I/O to access all of their files." - Remove. We do not support standard universe "On Windows SLOTx_USER will only work if the credential of the specified user is stored on the execute machine using condor_store_cred" - Remove. We don't support running as users on windows. EXECUTE_LOGIN_IS_DEDICATED - Remove. No point in mentioning a deprecated param. $(FILESYSTEM_DOMAIN) -> FILESYSTEM_DOMAIN RESERVE_AFS_CACHE - Remove USE_NFS - Remove. We don't support standard universe USE_AFS - Remove "This configuration variable cannot be changed by using condor_reconfig or by sending a SIGHUP. To change this configuration variable, restart the condor_master daemon by using condor_restart. Only then will the change take effect. " - Remove. This is no longer true. "On your central manager, your $(DAEMON_LIST) will be different from your regular pool, since it will include entries for the condor_collector and condor_negotiator. " - Not sure this note is helpful. It's likely the DAEMON_LIST will be different on more than just the CM, unless there is only 1 schedd in the pool and it is on the CM. Recommend removing it. "As of Condor version 7.2.1,+ - remove Suggest moving the list of SUBSYSTEMS to A.8 SUBSYSTEM. This seems a good place to explain what subsystems are defined by default. PREEN - Description has some spacing issues. Additionally "]condor_preen" should be fixed (remove the ]?) $(DAEMON_LIST) -> DAEMON_LIST $(SUBSYSTEM_ARGS) -> SUBSYSTEM_ARGS PREEN_ARGS - The "-m means ..." doesn't look properly spaced, but does appear to be so. Any way to enhanced that appearance? $(CONDOR_ADMIN) -> CONDOR_ADMIN $(START_MASTER) -> START_MASTER MASTER_SHUTDOWN_Name - Remove. We don't ship condor_set_shutdown "... larger after each crashe" - Should be crash? (unless the e is an old english spelling of the word?) t = c + kn - This is wrong, as it's k to the power n (k^n) not k times n (k * n). The examples have it correct, but the formula is wrong. "Previous to Condor 7.1.1, when the string included an @ sign, Condor replaced whatever followed the @ sign with the fully qualified host name of the local machine." - Remove. We never shipped that version of condor "(for example, when using condor_glidein)" - Remove. We don't support glidein "(this is done automatically in the case of condor_glidein)" - Remove SECONDARY_COLLECTOR_LIST - Remove $(UPDATE_INTERVAL) -> UPDATE_INTERVAL $(UPDATE_OFFSET) -> UPDATE_OFFSET "Unfortunately, there are no such devices on Digital UNIX (the kernel does not update the access times on these devices, despite the /dev/keyboard0 entry) so this macro is of no use. Instead you must get this information by using the condor_kbdd to connect to the X server." - Remove. We don't care about Digital UNIX. :) STARTD_ATTRS, STARTD_DEBUG, STARTD_ADDRESS_FILE - Why have these here at all? We've covered them for the general case in the daemoncore section. $(LOG) - LOG condor_restart -startd -> condor_restart -subsystem startd STARTD_NOCLAIM_SHUTDOWN - Remove, as it's primarily for glidein, which we don't support. ENABLE_BACKFILL, BACKFILL_SYSTEM, START_BACKFILL, EVICT_BACKFILL - Remove. We don't support backfill. "This setting was formerly know as STARTD_VM_ATTRS or STARTD_VM_EXPRS (before version 6.9.3)" - Remove. We don't care about history $(MAX_SLOT_TYPES) -> MAX_SLOT_TYPES "dynamic provisioning" -> "dynamic slots" $(STARTD_CRON_NAME) -> <italic>STARTD_CRON_NAME</italic> "In Hawkeye, this is usually named HAWKEYE_JOBS. " - Remove. $(SPOOL) -> SPOOL Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(In reply to comment #0) > Description of problem: > General question: Throughout the appendix, we refer to the application as > "condor", but in the manual we use MRG Grid. Do we want/should we have a > uniform means for referring to what we ship (either condor or MRG Grid)? I'd prefer to use MRG Grid when referring to the system itself (as in "MRG Grid will use the parameters to ..."), and Condor only when referring to daemons and the like ("The condor_startd will shut down ..."). Thoughts? > > General Comment: I'd suggest moving away from $() when denoting a parameter in > text. $() is used in condor's configuration when referencing another param, so > it should be kept in the examples, but it doesn't really look right in the text > (and isn't internally consistent with other areas of the docs). I believe I've > caught most, if not all, places where this is done but be on the look out for > places I missed. Absolutely agree. A lot of this text was fairly hastily edited from the original UW manual, so it's a lot rougher than the rest of the book, unfortunately. > > From list of SUBSYSTEM - Remove SUBMIT, TOOL, QUILL Done. > > Also, SUBSYSTEMs are not pre-defined configuration variables as implied by the > section header. They are solely defined within the configuration file, and by > how daemons register with the collector. Suggest either moving this list to > another section (A.8 SUBSYSTEM?). Moved into a separate list for now. Let me know if you think it needs a separate section. > > LOCAL_XACT_BACKUP_FILTER - Change all 'xact's to 'transaction's in the > description <varlistentry> <term><command>LOCAL_XACT_BACKUP_FILTER</command></term> <listitem> <para> Defines whether or not to back up transactions based on whether or not the commit was successful. When set to <parameter>ALL</parameter> local transaction backups will always be kept. When set to <parameter>NONE</parameter> local transaction backups will never be kept. When set to <parameter>FAILED</parameter> local transaction backups will be kept for transactions that have failed to commit. </para> <para> To retain backups, <command>LOCAL_QUEUE_BACKUP_DIR</command> must be set to a valid directory and <command>LOCAL_XACT_BACKUP_FILTER</command> must be set to something other than <parameter>NONE</parameter>. </para> </listitem> </varlistentry> > > X_CONSOLE_DISPLAY - "display that condor should ..." -> display that the condor > kbdd daemon should ..." <varlistentry> <term><command>X_CONSOLE_DISPLAY</command></term> <listitem> <para> The name of the display that the condor kbdd daemon should monitor. Defaults to <parameter>:0.0</parameter>. </para> </listitem> </varlistentry> > > Suggest removing the subsystem list in "Logging configuration variables". It's > the same as earlier and is duplicated information. Gone. > > $(STARTD_LOG) -> STARTD_LOG <para> The name of the log file for a given subsystem. For example, <command>STARTD_LOG</command> gives the location of the log file for the <command>condor_startd</command> daemon. </para> > > $(SUBSYSTEM_LOG) -> SUBSYSTEM_LOG <para> Specifies the lock file used to synchronize additions to the log file. It must be a separate file from the <command><replaceable>SUBSYSTEM</replaceable>_LOG</command> file, since that file can be rotated and synchronization should occur across log file rotations. A lock file is only required for log files which are accessed by more than one process. Currently, this includes only the SHADOW subsystem. This macro is defined relative to the <command>LOCK</command> macro. </para> > > LOGS_USE_TIMESTAMP - Format is: [Month]/[Day]/[Year] [Hour]:[Minute]:[Second] <programlisting> [Month]/[Day]/[Year] [Hour]:[Minute]:[Second] </programlisting> > > D_ALL - "There is no need to list any other debug levels in addition to D_ALL" > Sadly, this isn't true. It provides more verbose logging than D_FULLDEBUG, but > it doesn't provide ALL levels of logging. Some items, like D_SECURITY, must > still be added to the debug level to get that level of logging. Suggest > removing the sentence as the real description is likely too convoluted for the > manual. <listitem> <para> <command>D_ALL</command> </para> <para> The most verbose logging option. This setting generates an extremely large amount of output. </para> </listitem> > > $(SUBSYSTEM_DEBUG) -> SUBSYSTEM_DEBUG > > $(SUBSYSTEM_LOG) -> SUBSYSTEM_LOG > > $(SUBSYSTEM_[LEVEL]_LOG) -> SUBSYSTEM_[LEVEL]_LOG <varlistentry> <term><command><replaceable>SUBSYSTEM</replaceable>_<replaceable>[LEVEL]</replaceable>_LOG</command></term> <listitem> <para> This is the name of a log file for messages at a specific debug level for a specific subsystem. If the debug level is included in <command><replaceable>SUBSYSTEM</replaceable>_DEBUG</command>, then all messages of this debug level will be written both to the <command><replaceable>SUBSYSTEM</replaceable>_LOG</command> file and the <command><replaceable>SUBSYSTEM</replaceable>_<replaceable>[LEVEL]</replaceable>_LOG</command> file. </para> </listitem> </varlistentry> > > HOSTALLOW... -> ALLOW... > > HOSTDENY -> DENY <varlistentry> <term><command>ALLOW...</command></term> <listitem> <para> All macros that begin with either <command>ALLOW</command> or <command>DENY</command> are settings for Condor's host-based security. </para> </listitem> </varlistentry> > > SETTABLE_ATTRS... - Need a reference to the new security chapter that will be > discussing settable params (source: > http://www.cs.wisc.edu/condor/manual/v7.5/3_6Security.html#SECTION004611000000000000000) <varlistentry> <term><command>SETTABLE_ATTRS...</command></term> <listitem> <para> All macros that begin with <command>SETTABLE_ATTRS</command> or <command><replaceable>SUBSYSTEM</replaceable>_SETTABLE_ATTRS</command> are settings used to restrict the configuration values that can be changed using the <command>condor_config_val</command> command. </para> <para> For more information on this parameter, see <xref linkend="chap-Grid_User_Guide-Security" /> </para> </listitem> </varlistentry> > > ...and is required for Quill. - Remove. We don't ship/support Quill. <varlistentry> <term><command><replaceable>SUBSYSTEM</replaceable>_DAEMON_AD_FILE</command></term> <listitem> <para> A complete path to a file that is to contain the ClassAd for a daemon. When the daemon sends a ClassAd describing itself to the condor_collector, it will also place a copy of the ClassAd in this file. Currently, this setting only works for the <command>condor_schedd</command> (that is <command>SCHEDD_DAEMON_AD_FILE</command>). </para> </listitem> </varlistentry> > > SUBSYSTEM_EXPRS - Remove all mention of SUBSYSTEM_EXPRS. SUBSYSTEM_ATTRS is > the new syntax and there's no reason to complicate the documentation by > mentioning the old param name. Gone. > > DAEMON_SHUTDOWN - Remove mention of glide-in. <para> Normally, these expressions would not be necessary. If they are not defined, they default to <parameter>FALSE</parameter>. </para> > > "file descriptors the Condor daemon is allowed to use ..." -> file descriptors > the Condor daemons are allowed to use ... <para> This specifies the maximum number of file descriptors the Condor daemons are allowed to use. File descriptors are a system resource used for open files and for network connections. Condor daemons that make many simultaneous network connections may require an increased number of file descriptors. </para> > > UPDATE_COLLECTOR_WITH_TCP - Remove mention of flocking (...not any sites that a > condor_schedd might flock to) <varlistentry> <term> <command>UPDATE_COLLECTOR_WITH_TCP</command></term> <listitem> <para> This setting defaults to <command>False</command>. If your site needs to use TCP connections to send ClassAd updates to your collector set to this to <parameter>True</parameter>. At this time, this setting only affects the main <command>condor_collector</command> for the site. If enabled, also define <command>COLLECTOR_SOCKET_CACHE_SIZE</command> at the central manager, so that the collector will accept TCP connections for updates, and will keep them open for reuse. For large pools, it is also necessary to ensure that the collector has a high enough file descriptor limit (e.g. using <command>MAX_FILE_DESCRIPTORS</command>). </para> </listitem> </varlistentry> > > MASTER_WAITS_FOR_GCB_BROKER - Remove mention of condor_glidein Removed last para. > > UID_DOMAIN - Suggest using examples with redhat.com instead of cs.wisc.edu > > > $(UID_DOMAIN) -> UID_DOMAIN > Removed first para and fixed some issues in the second. The second para was an edited duplicate of the first. > "Running standard universe jobs as user nobody enhances security and should > cause no problems, because the jobs use remote I/O to access all of their > files." - Remove. We do not support standard universe <para> An administrator can also leave <command>UID_DOMAIN</command> undefined. This will force Condor to always run jobs as user <parameter>nobody</parameter>. However, if vanilla jobs are run as user <parameter>nobody</parameter>, then files that need to be accessed by the job will need to be marked as world readable/writable so the user <parameter>nobody</parameter> can access them. </para> > > "On Windows SLOTx_USER will only work if the credential of the specified user > is stored on the execute machine using condor_store_cred" - Remove. We don't > support running as users on windows. Gone. > > EXECUTE_LOGIN_IS_DEDICATED - Remove. No point in mentioning a deprecated > param. Gone. > > $(FILESYSTEM_DOMAIN) -> FILESYSTEM_DOMAIN <para> Note that if you do not set <command>FILESYSTEM_DOMAIN</command>, Condor defaults to setting the macro's value to be the fully qualified host name of the local machine. Since each machine will have a different <command>FILESYSTEM_DOMAIN</command>, they will not be considered to have shared file systems. </para> > > RESERVE_AFS_CACHE - Remove Gone. > > USE_NFS - Remove. We don't support standard universe Gone. > > USE_AFS - Remove Gone. > > "This configuration variable cannot be changed by using condor_reconfig or by > sending a SIGHUP. To change this configuration variable, restart the > condor_master daemon by using condor_restart. Only then will the change take > effect. " - Remove. This is no longer true. > > "On your central manager, your $(DAEMON_LIST) will be different from your > regular pool, since it will include entries for the condor_collector and > condor_negotiator. " - Not sure this note is helpful. It's likely the > DAEMON_LIST will be different on more than just the CM, unless there is only 1 > schedd in the pool and it is on the CM. Recommend removing it. Removed the entire "Notes:" list. > > "As of Condor version 7.2.1,+ - remove <para> A daemon may be appended to the default <command>DC_DAEMON_LIST</command> value by placing the plus character (+) before the first entry in the <command>DC_DAEMON_LIST</command> definition. For example: </para> > > Suggest moving the list of SUBSYSTEMS to A.8 SUBSYSTEM. This seems a good > place to explain what subsystems are defined by default. Except the subsystems are referred to throughout this chapter. They need to be closer to the beginning. Leaving them where they are for now. > > PREEN - Description has some spacing issues. Additionally "]condor_preen" > should be fixed (remove the ]?) Fixed (hopefully. Will need to check the output on the stage). > > $(DAEMON_LIST) -> DAEMON_LIST <command>DAEMON_LIST</command> > > $(SUBSYSTEM_ARGS) -> SUBSYSTEM_ARGS <command><replaceable>SUBSYSTEM</replaceable>_ARGS</command> > > PREEN_ARGS - The "-m means ..." doesn't look properly spaced, but does appear > to be so. Any way to enhanced that appearance? I wrapped some text around it, it's not good practise to have called-out text begin a sentence anyway. Have another look now. > > $(CONDOR_ADMIN) -> CONDOR_ADMIN <command>CONDOR_ADMIN</command> > > $(START_MASTER) -> START_MASTER <varlistentry> <term> <command>START_DAEMONS</command></term> <listitem> <para> This macro is similar to the <command>START_MASTER</command> macro described above. This macro, however, does not force the <command>condor_master</command> to exit; instead preventing it from starting any of the daemons listed in the <command>DAEMON_LIST</command>. The daemons may be started later with a <command>condor_on</command> command. </para> </listitem> </varlistentry> > > MASTER_SHUTDOWN_Name - Remove. We don't ship condor_set_shutdown Gone. > > "... larger after each crashe" - Should be crash? (unless the e is an old > english spelling of the word?) Maybe back in Shakespeare's day ;) It's fixed now. > > t = c + kn - This is wrong, as it's k to the power n (k^n) not k times n (k * > n). The examples have it correct, but the formula is wrong. <programlisting> t = c + k<superscript>n</superscript> </programlisting> And removed the $(*) from the text, too. > > "Previous to Condor 7.1.1, when the string included an @ sign, Condor replaced > whatever followed the @ sign with the fully qualified host name of the local > machine." - Remove. We never shipped that version of condor <para> A defined <command>MASTER_NAME</command> is presumed to be of the form <replaceable>identifying-string.name</replaceable>. If the string does not include an @ sign, Condor appends one, followed by the fully qualified host name of the local machine. The identifying-string portion may contain any alphanumeric ASCII characters or punctuation marks, except the @ sign. We recommend that the string does not contain the : (colon) character, since that might cause problems with certain tools. Condor does not modify any portion of the string, if it contains an @ sign. This is useful for remote job submissions under the high availability of the job queue. </para> > > "(for example, when using condor_glidein)" - Remove. We don't support glidein > > "(this is done automatically in the case of condor_glidein)" - Remove <para> If the <command>MASTER_NAME</command> setting is used, and the condor_master is configured to spawn a <command>condor_schedd</command>, the name defined with <command>MASTER_NAME</command> takes precedence over the <command>SCHEDD_NAME</command> setting. Since Condor makes the assumption that there is only one instance of the <command>condor_startd</command> running on a machine, the <command>MASTER_NAME</command> is not automatically propagated to the <command>condor_startd</command>. However, in situations where multiple <command>condor_startd</command> daemons are running on the same host, the <command>STARTD_NAME</command> should be set to uniquely identify the <command>condor_startd</command> daemons. </para> > > SECONDARY_COLLECTOR_LIST - Remove Gone. > > $(UPDATE_INTERVAL) -> UPDATE_INTERVAL > > $(UPDATE_OFFSET) -> UPDATE_OFFSET <para> An integer value representing the number of seconds that the <command>condor_startd</command> should wait before sending its initial update, and the first update after a <command>condor_reconfig</command> command is sent to the <command>condor_collector</command>. The time of all other updates sent after this initial update is determined by <command>UPDATE_INTERVAL</command>. Thus, the first update will be sent after <command>UPDATE_OFFSET</command> seconds, and the second update will be sent after <command>UPDATE_OFFSET</command> + <command>UPDATE_INTERVAL</command>. This is useful when used in conjunction with the <command>RANDOM_INTEGER</command> macro for large pools, to spread out the updates sent by a large number of <command>condor_startd</command> daemons. Defaults to <parameter>0</parameter>. </para> > > "Unfortunately, there are no such devices on Digital UNIX (the kernel does not > update the access times on these devices, despite the /dev/keyboard0 entry) so > this macro is of no use. Instead you must get this information by using the > condor_kbdd to connect to the X server." - Remove. We don't care about Digital > UNIX. :) *shock* :P It's gone. > > STARTD_ATTRS, STARTD_DEBUG, STARTD_ADDRESS_FILE - Why have these here at all? > We've covered them for the general case in the daemoncore section. I've no idea. They're gone. > > $(LOG) - LOG <command>LOG</command> > > condor_restart -startd -> condor_restart -subsystem startd <programlisting> condor_restart -subsystem -startd </programlisting> > > STARTD_NOCLAIM_SHUTDOWN - Remove, as it's primarily for glidein, which we don't > support. > Gone. > ENABLE_BACKFILL, BACKFILL_SYSTEM, START_BACKFILL, EVICT_BACKFILL - Remove. We > don't support backfill. Gone. > > "This setting was formerly know as STARTD_VM_ATTRS or STARTD_VM_EXPRS (before > version 6.9.3)" - Remove. We don't care about history tut-tut. Gone. > > $(MAX_SLOT_TYPES) -> MAX_SLOT_TYPES <command>MAX_SLOT_TYPES</command> > > "dynamic provisioning" -> "dynamic slots" Fixed in another bug. > > $(STARTD_CRON_NAME) -> <italic>STARTD_CRON_NAME</italic> > > "In Hawkeye, this is usually named HAWKEYE_JOBS. " - Remove. Can't find that string in the current document. > > $(SPOOL) -> SPOOL > <para> To avoid condor_preen removing this log, place it in a directory other than the directory defined by <command>SPOOL</command>. Alternatively, if this log file is to go in the directory defined by <command>SPOOL</command>, add the file to the list given by <command>VALID_SPOOL_FILES</command>. </para> This will be available on the stage for review shortly. LKB
(In reply to comment #1) > (In reply to comment #0) > > Description of problem: > > General question: Throughout the appendix, we refer to the application as > > "condor", but in the manual we use MRG Grid. Do we want/should we have a > > uniform means for referring to what we ship (either condor or MRG Grid)? > > I'd prefer to use MRG Grid when referring to the system itself (as in "MRG Grid > will use the parameters to ..."), and Condor only when referring to daemons and > the like ("The condor_startd will shut down ..."). Thoughts? That's fine with me and makes sense, but in the appendix there are numerous places where we mention "condor" in a system sense. For example: LIBEXEC The directory where support commands for Condor are placed. Do not add this directory to a user or system-wide path. > > > > General Comment: I'd suggest moving away from $() when denoting a parameter in > > text. $() is used in condor's configuration when referencing another param, so > > it should be kept in the examples, but it doesn't really look right in the text > > (and isn't internally consistent with other areas of the docs). I believe I've > > caught most, if not all, places where this is done but be on the look out for > > places I missed. > > Absolutely agree. A lot of this text was fairly hastily edited from the > original UW manual, so it's a lot rougher than the rest of the book, > unfortunately. > > > > > Also, SUBSYSTEMs are not pre-defined configuration variables as implied by the > > section header. They are solely defined within the configuration file, and by > > how daemons register with the collector. Suggest either moving this list to > > another section (A.8 SUBSYSTEM?). > > Moved into a separate list for now. Let me know if you think it needs a > separate section. The text still implies there are "set" subsystem/daemon names. Sadly, this isn't true. Suggest a minor tweaking: "The possible subsystem names are" -> Example subsystem names are > > > > SETTABLE_ATTRS... - Need a reference to the new security chapter that will be > > discussing settable params (source: > > http://www.cs.wisc.edu/condor/manual/v7.5/3_6Security.html#SECTION004611000000000000000) > > <varlistentry> > <term><command>SETTABLE_ATTRS...</command></term> > <listitem> > <para> > All macros that begin with <command>SETTABLE_ATTRS</command> or > <command><replaceable>SUBSYSTEM</replaceable>_SETTABLE_ATTRS</command> are > settings used to restrict the configuration values that can be changed using > the <command>condor_config_val</command> command. > </para> > <para> > For more information on this parameter, see <xref > linkend="chap-Grid_User_Guide-Security" /> > </para> > > </listitem> > </varlistentry> For this reference to be valid, we need to include the 3.6.11 section from the condor manual at UW. I originally didn't mark this as critically important to get into 1.3, but I leave up to you to determine if you can get it in. If not, suggest removing SETTABLE_ATTRS completely from the Appendix until we can get the aforementioned security section into our manual. DAEMON_SHUTDOWN - Remove mention of Condor version 6.9. We've never shipped it. :) user@$(UID_DOMAIN) -> user@UID_DOMAIN condor_preenfrom running -> condor_preen from running > > > > condor_restart -startd -> condor_restart -subsystem startd > > <programlisting> > condor_restart -subsystem -startd > </programlisting> condor_restart -subsystem -startd -> Remove the - before startd. startd is the target os the subsystem option.
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > Description of problem: > > > General question: Throughout the appendix, we refer to the application as > > > "condor", but in the manual we use MRG Grid. Do we want/should we have a > > > uniform means for referring to what we ship (either condor or MRG Grid)? > > > > I'd prefer to use MRG Grid when referring to the system itself (as in "MRG Grid > > will use the parameters to ..."), and Condor only when referring to daemons and > > the like ("The condor_startd will shut down ..."). Thoughts? > > That's fine with me and makes sense, but in the appendix there are numerous > places where we mention "condor" in a system sense. For example: > > LIBEXEC > The directory where support commands for Condor are placed. Do not add this > directory to a user or system-wide path. > > I've done a quick search through and fixed a lot of the obvious ones. The rest we can catch over time. > > The text still implies there are "set" subsystem/daemon names. Sadly, this > isn't true. Suggest a minor tweaking: > > "The possible subsystem names are" -> Example subsystem names are > Changed to: "Some possible subsystem names are:" > > > > > > SETTABLE_ATTRS... - Need a reference to the new security chapter that will be > > > discussing settable params (source: > > > http://www.cs.wisc.edu/condor/manual/v7.5/3_6Security.html#SECTION004611000000000000000) > > > > <varlistentry> > > <term><command>SETTABLE_ATTRS...</command></term> > > <listitem> > > <para> > > All macros that begin with <command>SETTABLE_ATTRS</command> or > > <command><replaceable>SUBSYSTEM</replaceable>_SETTABLE_ATTRS</command> are > > settings used to restrict the configuration values that can be changed using > > the <command>condor_config_val</command> command. > > </para> > > <para> > > For more information on this parameter, see <xref > > linkend="chap-Grid_User_Guide-Security" /> > > </para> > > > > </listitem> > > </varlistentry> > > For this reference to be valid, we need to include the 3.6.11 section from the > condor manual at UW. I originally didn't mark this as critically important to > get into 1.3, but I leave up to you to determine if you can get it in. If not, > suggest removing SETTABLE_ATTRS completely from the Appendix until we can get > the aforementioned security section into our manual. I'e commented out the "For more information ..." bit for now. I'm working on the Security chapter this week, so we'll see how far I get with it. > > DAEMON_SHUTDOWN - Remove mention of Condor version 6.9. We've never shipped > it. :) Gone. > > user@$(UID_DOMAIN) -> user@UID_DOMAIN > > condor_preenfrom running -> condor_preen from running Fixed. > > > > > > > condor_restart -startd -> condor_restart -subsystem startd > > > > <programlisting> > > condor_restart -subsystem -startd > > </programlisting> > > condor_restart -subsystem -startd -> Remove the - before startd. startd is the > target os the subsystem option. <programlisting> condor_restart -subsystem startd </programlisting> LKB