defaria.com/blogs/Status/archives/2008_02.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" id="sixapart-standard">
   4 <head>
   5    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6    <meta name="generator" content="Movable Type 5.2.3" />
   7
   8    <link rel="stylesheet" href="http://defaria.com/blogs/Status/styles-site.css" type="text/css" />
   9    <link rel="alternate" type="application/atom+xml" title="Atom" href="http://defaria.com/blogs/Status/atom.xml" />
  10    <link rel="alternate" type="application/rss+xml" title="RSS 2.0" href="http://defaria.com/blogs/Status/index.xml"$>" />
  11
  12    <title>Status for Andrew DeFaria: February 2008 Archives</title>
  13
  14    <link rel="start" href="http://defaria.com/blogs/Status/" title="Home" />
  15    <link rel="prev" href="http://defaria.com/blogs/Status/archives/2008_01.html" title="January 2008" />
  16    <link rel="next" href="http://defaria.com/blogs/Status/archives/2008_03.html" title="March 2008" />
  17 </head>
  18 <body class="layout-one-column">
  19    <div id="container">
  20       <div id="container-inner" class="pkg">
  21
  22          <div id="banner">
  23             <div id="banner-inner" class="pkg">
  24                <h1 id="banner-header"><a href="http://defaria.com/blogs/Status/" accesskey="1">Status for Andrew DeFaria</a></h1>
  25                <h2 id="banner-description">Searchable status reports and work log</h2>
  26             </div>
  27          </div>
  28
  29          <div id="pagebody">
  30             <div id="pagebody-inner" class="pkg">
  31                <div id="alpha">
  32                   <div id="alpha-inner" class="pkg">
  33
  34                      <p class="content-nav">
  35                         <a href="http://defaria.com/blogs/Status/archives/2008_01.html">&laquo; January 2008</a> |
  36                         <a href="http://defaria.com/blogs/Status/">Main</a>
  37                         | <a href="http://defaria.com/blogs/Status/archives/2008_03.html">March 2008 &raquo;</a>
  38                      </p>
  39
  40
  41                      <!--
  42 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  43          xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
  44          xmlns:dc="http://purl.org/dc/elements/1.1/">
  45 <rdf:Description
  46     rdf:about="http://defaria.com/blogs/Status/archives/2008_02.html#entry-000698"
  47     trackback:ping="http://defaria.com/mt/mt-tb.cgi/85"
  48     dc:title="New easter options"
  49     dc:identifier="http://defaria.com/blogs/Status/archives/2008_02.html#entry-000698"
  50     dc:subject="General Dynamics"
  51     dc:description=" Added source command to easter. This is the interactive equivalent of the -file option Changed history to log a -file &amp;lt;file&amp;gt; as a &quot;source &amp;lt;file&amp;gt;&quot; into the history file Changed prompt to &quot;easter&gt;&quot; Documented easter on the wiki Added..."
  52     dc:creator=""
  53     dc:date="2008-02-28T14:02:34-06:00" />
  54 </rdf:RDF>
  55 -->
  56
  57
  58                      <h2 class="date-header">February 28, 2008</h2>
  59                      <a id="a000698"></a>
  60                      <div class="entry" id="entry-698">
  61                         <h3 class="entry-header">New easter options</h3>
  62                         <div class="entry-content">
  63                            <div class="entry-body">
  64                               <ul>
  65   <li>Added source command to easter. This is the interactive equivalent of the -file option</li>
  66
  67   <li>Changed history to log a -file &lt;<em>file</em>&gt; as a "source &lt;<em>file</em>&gt;" into the history file</li>
  68
  69   <li>Changed prompt to <li>"easter>"</li>
  70
  71   <li>Documented easter on the wiki</li>
  72
  73   <li>Added rudimentary set/get commands to add things to the global $_optis hash. This allows the interactive user to set options like activecalls or displaylevel interactively for the during of the easter run. Note, there is no checking to insure the option if valid (i.e. set foo=bar is perfectly acceptable even though there is no "foo" option) nor is proper checking of balancing/mismatching of quotes (e.g. The results of set foo = "unbalanced or mismatched quotes' are undefined).</li>
  74 </ul>
  75
  76                               <p class="entry-footer">
  77                                  <span class="post-footers">Posted by  at  2:02 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000698.html">Permalink</a>
  78
  79                                  | <a href="http://defaria.com/blogs/Status/archives/000698.html#trackback">TrackBacks (0)</a>
  80                               </p>
  81                            </div>
  82                         </div>
  83                      </div>
  84
  85                      <!--
  86 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  87          xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
  88          xmlns:dc="http://purl.org/dc/elements/1.1/">
  89 <rdf:Description
  90     rdf:about="http://defaria.com/blogs/Status/archives/2008_02.html#entry-000697"
  91     trackback:ping="http://defaria.com/mt/mt-tb.cgi/84"
  92     dc:title="For immediate release"
  93     dc:identifier="http://defaria.com/blogs/Status/archives/2008_02.html#entry-000697"
  94     dc:subject="General Dynamics"
  95     dc:description="For immediate release... Recently Gantry mentioned the following problem: Error Prone Deliveries: Another problem is that Reinaldo&apos;s private files have to be merged manually. Ross, Andrew, and I are in a similar situation now where we have to take a..."
  96     dc:creator=""
  97     dc:date="2008-02-20T14:49:49-06:00" />
  98 </rdf:RDF>
  99 -->
 100
 101
 102                      <h2 class="date-header">February 20, 2008</h2>
 103                      <a id="a000697"></a>
 104                      <div class="entry" id="entry-697">
 105                         <h3 class="entry-header">For immediate release</h3>
 106                         <div class="entry-content">
 107                            <div class="entry-body">
 108                               <h2>For immediate release...</h2>
 109
 110 <p>Recently Gantry mentioned the following problem:</p>
 111
 112 <blockquote type=cite>
 113   <p>Error Prone Deliveries:</p>
 114
 115   <p>Another problem is that Reinaldo's private files have to be merged
 116 manually.</p>
 117
 118   <p>Ross, Andrew, and I are in a similar situation now where we have to
 119 take a snapshot of directories in a view over to seast1 in order to do
 120 development, then remember what we changed and copy them back in and
 121 deliver.</p>
 122
 123   <p>We have already made several mistakes. </p>
 124 </blockquote>
 125
 126 <p>The problem here is that we have two different Clearcase registry
 127 regions and subnets, code is developed in one region and run in the
 128 other. Gantry proposed a solution of writing more script to maintain
 129 that will essentially copy things between systems. I would like to
 130 propose an alternative...</p>
 131
 132 <h2>Release process</h2>
 133
 134 <p>What if we instead had a release process such that we deliver our
 135 development to the feature stream that is then automatically seen over
 136 on the cclinux region? Code is developed through the WOR process on the
 137 RAN and delivered to the feature stream. This stream has an official
 138 view which is exported to the cclinux region where it is mounted
 139 directly into place<a href="#note_1"><sup>1</sup></a>. Since all
 140 processes that utilize these scripts do so through this base they are
 141 all automatically and immediately updated when the view is updated.
 142 Additionally code is developed cognizant of this base such that an
 143 alternate base can easily be set allowing one to test the release
 144 before making it official.</p>
 145
 146 <h2>Solution proposed</h2>
 147
 148 <h3>Exporting a view</h3>
 149
 150 <p>Clearcase has the ability to export a view/vob path from a view
 151 server to any other machine. This allows you to "access Clearcase from
 152 a machine which does not have Clearcase" (see ct man export_mvfs). In
 153 order to do this a systems administrator adds a line to
 154 /etc/exports.mvfs on the view server where the view resides using the
 155 format of:</p>
 156
 157 <div class=code><pre>
 158 /view/&lt;<i>view_name</i>&gt;/vobs/&lt;<i>vobpath</i>&gt;&lt;<i>netgroup or machine</i>&gt;
 159 </pre></div>
 160
 161 <p>And executes the /opt/rational/clearcase/etc/export_mvfs -a
 162 command.  Additionally &lt;<i>view_name</i>&gt; should be started<a
 163 href="#note_2"><sup>2</sup></a>.</p>
 164
 165 <h3>Official view</h3>
 166
 167 <p>Additionally, as noted above, a view must be utilized. I suggest using
 168 what I like to call <i>official views</i> for this. An <i>official
 169 view</i> is merely a view not associated with any particular person
 170 (e.g. maybe ccadm) that serves in an official capacity. This view
 171 usually has a simple config spec such as the following:</p>
 172
 173 <div class=code><pre>
 174 element * REL_1.0 -nocheckout
 175 </pre></div>
 176
 177 <p>thereby limiting what was seen through the view as only that which is
 178 labeled with REL_1.0. The release process therefore consisted of
 179 applying the REL_1.0 label and poof! Automatically and immediately the
 180 new version was available. Updating to say a REL_1.1 release would
 181 involve then simply a ct setcs and a changing of REL_1.0 to REL_1.1.</p>
 182
 183 <p>For UCM based views, translate the above to applicable baselines...</p>
 184
 185 <h3>Importing the view</h3>
 186
 187 <p>On the client machine, importing the view is simply a mount
 188 command.  The suggestion here is to mount directly to our base,
 189 /usr/local/east:</p>
 190
 191 <div class=code><pre>
 192 $ mount view1:/views/&lt;<i>official view</i>&gt;/vobs/rantest /usr/local/east
 193 </pre></div>
 194
 195 <p>(Actually this should be added to /etc/fstab for automatic, at boot
 196 time, mounting).</p>
 197
 198 <h3>Security and visibility</h3>
 199
 200 <p>There is concern regarding exposing too much visibility of vob
 201 elements in the cclinux region. Since /etc/exports.mvfs allows us to
 202 specify an exacting path of what is exported we can insure that we are
 203 only exporting the .../vobs/rantest portion or even a subdirectory(s)
 204 under rantest. This should sufficiently limit the scope of what's
 205 exposed.</p>
 206
 207 <h2>Notes</h2>
 208
 209 <ol>
 210   <li><small><a name="note_1"></a>This assumes that we adopt a concept
 211 of a base variable from which everything emanates (e.g. /usr/local/east)</small></li>
 212   <li><small><a name="note_2"></a>At HP I devised a simply script
 213 solution to insure that views listed in /etc/views_to_start would be
 214 started at boot up on the view servers.</small></li>
 215 </ol>
 216
 217 <p>Comments? Concerns?</p>
 218
 219                               <p class="entry-footer">
 220                                  <span class="post-footers">Posted by  at  2:49 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000697.html">Permalink</a>
 221
 222                                  | <a href="http://defaria.com/blogs/Status/archives/000697.html#trackback">TrackBacks (0)</a>
 223                               </p>
 224                            </div>
 225                         </div>
 226                      </div>
 227
 228                      <!--
 229 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 230          xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
 231          xmlns:dc="http://purl.org/dc/elements/1.1/">
 232 <rdf:Description
 233     rdf:about="http://defaria.com/blogs/Status/archives/2008_02.html#entry-000696"
 234     trackback:ping="http://defaria.com/mt/mt-tb.cgi/83"
 235     dc:title="Rexec"
 236     dc:identifier="http://defaria.com/blogs/Status/archives/2008_02.html#entry-000696"
 237     dc:subject="General Dynamics"
 238     dc:description="Rexec Complications Rexec is a Perl module written by me. There are several things that Rexec provides but at it&apos;s core it essentially provides an object oriented interface to a remote command line. Rexec attempts to provide functionality by handling..."
 239     dc:creator=""
 240     dc:date="2008-02-12T14:24:24-06:00" />
 241 </rdf:RDF>
 242 -->
 243
 244
 245                      <h2 class="date-header">February 12, 2008</h2>
 246                      <a id="a000696"></a>
 247                      <div class="entry" id="entry-696">
 248                         <h3 class="entry-header">Rexec</h3>
 249                         <div class="entry-content">
 250                            <div class="entry-body">
 251                               <h2>Rexec Complications</h2>
 252
 253 <p>Rexec is a Perl module written by me. There are several things that Rexec provides but at it's core it essentially provides an object oriented interface to a remote command line. Rexec attempts to provide functionality by handling the details in nominal cases however it's basic paradigm is that it expects to be able to execute a command on the remote system, for that command to block and for the command to finish and to properly set the exit status. Rexec accomplishes this by using Expect. When instantiated, Rexec attempts to log into the remote machine using a cascading fallback of ssh, rsh and telnet (unless the caller has explicitly requested a particular protocol). User name and password can be supplied or passwordless login must be configured for Rexec to succeed to connect to the remote system.</p>
 254
 255 <p>Thereafter the caller calls the exec method to execute the remote command. Rexec wraps that command with two echo statements that mark the beginning and ending of the command's output as well as the status of the command. Rexec then gathers up the output lines and status, storing them in the object, and returning the output lines as an array (and the status obtainable using the status method). The caller can then proceed accordingly.</p>
 256
 257 <p>But the above does assume that commands are of the nature that they block while operating and that they set the exit code properly. No effort is made to do any output redirection, nor are any assumptions made about the command being executed.</p>
 258
 259 <p>The first problem arises when the caller has a need to "background" a task. Normally in Unix this means adding a "&" to the end of the line to indicate to put the command in the background. In such a case we run into two problems that the normal shell also has to deal with, that being how to handle asynchronous I/O and how to handle the exit status, which can come at any time. So far no functionality has been added to handle any asynchronous I/O - the answer here is <b>don't do that!!!</b>, at least, for now.</p>
 260
 261 <p>Exit status is also not gracefully handled in that it is not attempted to be captured at all.</p>
 262
 263 <p>What Rexec does normally is to add an <tt>echo &lt;<i>unique start string</i>&gt;</tt> to the front of the command and an <tt>echo &lt;<i>unique end string with status</i>&gt;</tt>. Then Rexec scans the output for the start and ending strings and knows that the strings inbetween must have resulted from the output from the command. Rexec also gathers the exit status from the later echo statement. Of course, this assume the command blocks and properly sets the exit status.</p>
 264
 265 <p>Now, if Rexec finds a "&" at the end of the command it will treat it as nonblocking. It does not add the start nor the ending echoes and makes no attempt at gathering neither output nor exit status from this command. Another potential problem are commands which do not indicate their desire to be backgrounded (by specifying the trailing "&" character) but background themselves nonetheless.</p>
 266
 267 <p>Another, odd problem was also discovered when the remote command ended up doing yet another ssh to another system. Such a command also does not return, or at least not right away. Worse yet, there is a good possibility that that 2nd remote ssh will result in a prompt that will be mistaken for the 1st session's prompt by Rexec! No easy way around this either!</p>
 268
 269 <p>Finally, other commands will likewise have a problem when executed remotely. For example: "vi /tmp/foo". But then again, even Expect has problems with this. So we can't be all things to all people but that doesn't mean we cannot be helpful nonetheless.</p>
 270
 271                               <p class="entry-footer">
 272                                  <span class="post-footers">Posted by  at  2:24 PM</span> <span class="separator">|</span> <a class="permalink" href="http://defaria.com/blogs/Status/archives/000696.html">Permalink</a>
 273
 274                                  | <a href="http://defaria.com/blogs/Status/archives/000696.html#trackback">TrackBacks (0)</a>
 275                               </p>
 276                            </div>
 277                         </div>
 278                      </div>
 279
 280                   </div>
 281                </div>
 282             </div>
 283          </div>
 284       </div>
 285    </div>
 286 </body>
 287 </html>