ark-dev — Arusha Project development and discussion list

ARK APIs

[Brian L. <bl...@sg...>]

Hi,

I have a couple of questions --

1.  What API(s) does ARK have for other software to interface with it?
2. Can it manage a chroot environment, LXC container, or any other method of setting up an image that will eventually be applied as the OS for a Linux host

Re: Arusha (ARK) on Wikipedia

[Jim R. <jm...@qu...>]

Will Partain wrote:

>(Sorry to be slow in replying.)
>
>Daniel Clark writes:
>
>  
>
>>BTW, what's happening with Arusha these days? Is it still in use at
>>any sites?
>>    
>>
>
>I continue to use it daily.  Either no-one else is using it, or
>they are _very_ contented (and have nothing to say :-).  I have a
>few scraps to check in, but haven't scared up the cycles to mess
>with it.
>
>Will
>  
>

We have what was originally a pilot effort still using it.   Within the 
scope that is was deployed it is clearly a production subsystem.   It 
hasn't grown into a full-scale deployment primarily for the same reason 
Will cites -- I haven't been able to scare up the cycles!

Jim

RE: Arusha (ARK) on Wikipedia

[Donald D. <Don...@sl...>]

I'm still using the framework but I tend to manually configure it rather
than let it do it's automated stuff these days.

Donald Deasy
Systems Manager
Institute for System Level Integration
Tel: +44 1506 469311 (Direct)
=20
ISLI provides postgraduate education, professional training and research
in system level integration incorporating cross over technologies such
as hardware, embedded software, MNT/MEMS.  Details of our activities can
be found at: www.sli-institute.ac.uk


-----Original Message-----
From: ark...@li...
[mailto:ark...@li...] On Behalf Of Will Partain
Sent: 05 March 2007 12:48
To: ar...@li...
Subject: Re: Arusha (ARK) on Wikipedia

(Sorry to be slow in replying.)

Daniel Clark writes:

> There is some movement towards getting a good comparison of=20
> Configuration Management software up on Wikipedia; ...

Excellent; what you've put up so far is accurate.

> BTW, what's happening with Arusha these days? Is it still in use at=20
> any sites?

I continue to use it daily.  Either no-one else is using it, or they are
_very_ contented (and have nothing to say :-).  I have a few scraps to
check in, but haven't scared up the cycles to mess with it.

Will

------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
ark-dev mailing list
ar...@li...
https://lists.sourceforge.net/lists/listinfo/ark-dev

Re: Arusha (ARK) on Wikipedia

[Will P. <pa...@dc...>]

(Sorry to be slow in replying.)

Daniel Clark writes:

> There is some movement towards getting a good comparison of
> Configuration Management software up on Wikipedia; ...

Excellent; what you've put up so far is accurate.

> BTW, what's happening with Arusha these days? Is it still in use at
> any sites?

I continue to use it daily.  Either no-one else is using it, or
they are _very_ contented (and have nothing to say :-).  I have a
few scraps to check in, but haven't scared up the cycles to mess
with it.

Will

Arusha (ARK) on Wikipedia

[Daniel C. <dc...@po...>]

There is some movement towards getting a good comparison of
Configuration Management software up on Wikipedia; so someone with
more intimate knowledge of ark/arusha than I may want to take a stab
at adding more to these articles:

http://en.wikipedia.org/wiki/Arusha_Project
http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software

BTW, what's happening with Arusha these days? Is it still in use at
any sites? I've been working on Bcfg2 lately, but I think Arusha has a
lot of great ideas (my main problem with it when I tried setting it up
years ago was that the bring-up was sort of complex, and I was much
more shy back then than I am now :-)

Cheers,
-- 
Daniel Clark # http://dclark.us # http://opensysadmin.com

Re: squishing install and deploy dirs together

[Will P. <pa...@dc...>]

Hi, Jim et al. -- Taking your questions/comment out of order:

> 3.) Am I out of my mind?

No :-)

> 1.) In this context, are there reasons to keep install and deploy 
> distinct?  If so, what?

Probably not (i.e. your analysis is sound).

The install/deploy/reveal thing is *not* supposed to be an all-knowing
everyone-should-do-it-this-way thing.  It's just one way.  The more
common "just stick it in /usr/local" -- make install prefix=/usr/local
-- should also be possible.  Or what you want to do.

For the install/deploy/reveal thing, the steps (and what they get you)
go like this:

* You tell the software at build time that it is in the deploy place; i.e.
  make install prefix=$deploy_dir [whatever that is]

  Because the deploy_dir is traditionally version-specific, you can have
  many versions live at once.

* The business of copying over what you've built to the install area
  (again version-specifically) is so that you have a single golden copy
  per type of machine with which you can do clever things.

* We now deploy the golden cop{y,ies} onto individual machines.  If an
  individual machine has a big disk (they all do now, but they didn't
  when ARK started...), you can deploy by taking a copy.  Or you can
  deploy by symlinking.  Or whatever you like, machine by machine.

  Another thing you can customize is what set of versions of the
  software each machine sees.  So, for example, the Team A machines
  might have an old version; but the Team B machines would have all
  versions.

* Finally, revealing: This is creating a symlink or something in the
  users' PATH so that they can run whatever it is.  My experience is
  that asking users to meddle with their individual PATHs constantly is
  just a recipe for disaster.  So, for example, we just say "put
  /our/bin near the front of your PATH" and declare victory.  Revealing
  puts the right links to the right versions in /our/bin.  Again, it can
  be varied machine by machine (if you're crazy enough to do that).

If you don't want any of that stuff, don't do it that way.

> 2.) Do you have guidance for me in terms of the general approach to 
> making them be the same?  (i.e, Where do I hack?)  Is this going to be a 
> big job or a small one?  Has anyone done something similar that would be 
> useful as a starting point?

I am not aware of someone doing something similar.  I hope it would be a
pretty small job.

Assuming you're sucking on the Sidai methods (i.e. in
$ARK/sidai/package/{GNU,ALL}.xml), I'd proceed by...

* cutting out unnecessary methods -- so, for instance, if you want
'reveal-bits' to depend on 'install' rather than 'deploy', just change
the dependency in the 'reveal-bits' method.

* simply change the method shell scripts to do what you want

I'd do them in place (for simplicity).  Afterwards, you can move your
changed files out of the way, re-'cvs co' the sidai stuff, then use the
diffs (which I would expect to be modest) to fashion some .xml for your
own team that would then override the sidai stuff and do what you want.

Hope this helps,

Will

squishing install and deploy dirs together

[Jim R. <jm...@qu...>]

Hi,

I'm considering a model where the install, deploy and reveal dirs are 
all in AFS.  As I understand it, most of the arguments for having 
distinct install and deploy dirs disappear in this context.  (I can't 
think of any good reasons to have separate dirs, except that you have to 
avoid trampling on existing deployed code that is being used.)  Thus, 
I'm thinking that the ideal configuration is one where you install into 
the deploy dir and just leave it there -- instead of copying it back to 
install, etc.

I haven't gotten as far as looking into exactly how one might achieve 
this.  Before I do, I have have some questions:

1.) In this context, are there reasons to keep install and deploy 
distinct?  If so, what?

2.) Do you have guidance for me in terms of the general approach to 
making them be the same?  (i.e, Where do I hack?)  Is this going to be a 
big job or a small one?  Has anyone done something similar that would be 
useful as a starting point?

3.) Am I out of my mind?

Jim

Re: Questions from the start..

[Will P. <pa...@dc...>]

> I'm just starting to play with Ark in order to see if it addresses
> some problems I've got.

Hi, Michael; happy to see what we can do...

> When following the "try-ark" doc, I came up with these questions:
> 1) Does the test-dir area have to not be /tmp?

You should be able to put it anywhere.  /tmp is sometimes slightly
magical (esp across reboots :-).

> 2) Does the ark-src-dir have to be a hard path and not an
>     environmental variable (as in ark_profile)?

A path, yes. I'd recommend an absolute path.

> 3) Is "solo-host" the "controller"

I'm not sure what you mean by "the controller".  The idea of the try-ark
experiment is that you use ARK on a single machine to build a few
packages in a non-special directory (e.g. under your home directory).

Once the experiment is over, you can throw it away.  Then you will write
an ARK description that fits your site and what you are trying to do.
ARK isn't a product that you download and it magically does fixed tasks
for you; rather, it is a "language" with which you can describe the
sysadmin tasks/situations at your site that you care about.  (Happily,
you can build upon what others have described -- the "sidai" team is
nothing but a big pile of descriptions that you can build upon.  That's
what the try-ark experiment does.)

> It seems like the activity in this product has dwindled.

Which may be a good or bad thing, depending on your point of view :-)

The core ARK engine (which processes the "language" mentioned above)
hasn't changed much in five years or so.  I personally consider this a
Very Good Thing.

I use the ARK stuff every day and plan to keep doing so; I don't know
about anyone else.  I usually release a full set of my bits about once a
year and, yes, I'm running a little behind schedule this year :-(

> Does anyone have an alternative to this one?

Depending on what you are trying to do, the answer is likely to be 'yes'.

Will

Questions from the start..

[Michael T. <mti...@us...>]

I'm just starting to play with Ark in order to see if it addresses
some problems I've got.

When following the "try-ark" doc, I came up with these questions:
1) Does the test-dir area have to not be /tmp?
2) Does the ark-src-dir have to be a hard path and not an
    environmental variable (as in ark_profile)?
3) Is "solo-host" the "controller"

It seems like the activity in this product has dwindled.
Does anyone have an alternative to this one?
--
    << MCT >>   Michael C Tiernan.
    Is God a performance artist?
    EGO hack vivo quod ago accido.

Re: gcc, specs, and rethinking the sidai -R thing

[Daniel H. <ha...@li...>]

 > [Recap: "my" [vague] proposal was: lose the -R stuff, have some extra
 > ARK gunk to "manage" the ld.config game (where to find .so files).]

    Not paying attention to any of the sidai stuff (where the
constraints are very different), developers that do *not* understand
the use of RPATH and expect that I either use LD_LIBRARY_PATH or
change the system library path Just Don't Get It and are up there on
the "#!@% me off" list.


    The point of -R is for when you're building objects into non
standard locations, which if I remember correctly, sounds like what
you do.  Your specific case is mitigated somewhat in that you're
building the whole system, but only somewhat.

    The system library path is the system library path for exactly
that;  certain unpleasant corners cases are generally vetted by way of
"we promise we won't do this to you" (LD_LIBRARY_PATH has the same
problems where you're taking the promise on yourself).

    What happens when my application has a libfoobar.so that includes
a definition of printf?  We haven't even started on the fun corner
cases the appear when we introduce dlopen into the picture.

    printf is obviously an extreme example, but the point is that I've
actually lived through doing linking the wrong way.  ELF brought us
RPATH and taught us to use it for a reason.  The previous methods
don't work, and in some cases, people notice.

Re: gcc, specs, and rethinking the sidai -R thing

[Jim R. <jm...@qu...>]

Will Partain wrote:

>Jim, I agree with your misgivings.  After all, something must've
>pushed me into this -R thing in the first place :-)
>
>I wonder if some sort of hybrid scheme would make sense?  I observe
>that not all .so files are created equal...
>  
>
In some cases it will make sense - yes.

>* things like libgcc_s.so -- every program needs it; carefully managed
>  by the GCC lads... Why not just put this in your ld.config...
>
>    /our/.-ark-deploy/gcc--4.0.2/lib
>    /our/.-ark-deploy/gcc--3.4.3/lib
>    /our/.-ark-deploy/gcc--2.95.3/lib
>
>  ... and declare victory?  If your program picks up the version from
>  a different version than what you might've expected, it will almost
>  certainly be OK.
>  
>

You're probably right about the resilience to version mismatches 
aspect.  And in the context of within a managed "cluster", doing 
something like this isn't particularly hard or evil.  Reasonable choice 
if it saves some headaches.

>* things like libz.so -- very stable interfaces; likely only upgraded
>  for security reasons; ubiquitous use; versioning done responsibly.
>  Again, having these picked up from a well-controlled ld.config will
>  probably be OK.
>
>* things like the Berkeley DB libraries -- you do _not_, on pain of
>  death, want a program picking up a version other than the one you
>  explicitly intended! -- a horrible horrible death will certainly
>  follow.  -R all the way.
>  
>

I think these three "classes" are probably reasonably representative of 
all the use cases, and it is clear that there is some variation in "how 
much it matters".

>Of course, judgement calls are being made in all of that.  So (if you
>decided to try to distinguish between those cases), it would a
>delicate bit of ARK scripting to keep it all together.
>
>Meanwhile, I wildly support that you should be able to do the kinds of
>things you're trying to do ("you don't need anything but a raw box").
>  
>

This one flies right in the face of the libgcc approach above.  In order 
to get to this level of sophistication/portability, you have to solve 
whatever issues there are completely and "correctly", since you can't 
manipulate ld.config.  Somewhat unfortunate, but a fact of life.  The 
ways to solve it that I see are:

1.) -R at build time, specifying all of the libs, and paths to 
version-specific deploy dirs -- the way it is done now.

2.) A wrapper that sets LD_LIBRARY_PATH on a per-app basis, with the 
info that would have been in "-R" above.

3.) Install apps into some shared dir, abandoning the current 
version-specific deploy dirs as the $prefix.  Implies giving up full 
control of  the ability to robustly deploy multiple versions of an app 
or lib.  If that "shared dir" isn't already on ld.config's path, still 
requires some amount of solution ala 1 or 2 above, but the level of 
effort will be seriously lowered -- since there's only one path to 
push.   If that dir is /usr/local; it's likely already solved.


>(Let me know if I've forgotten something, e.g. from earlier in the
>thread.)
>  
>

I've been puzzling on this for some time, and I think that the current 
approach, while it's a pain in the !@#, is the best one. 

I've nailed down my current biggest headache; it's that my current 
version of libstdc++ that I have built doesn't have a -R path to libgcc 
built in.  Now I just have to figure out how to fix it.


Jim

Re: gcc, specs, and rethinking the sidai -R thing

[Will P. <pa...@dc...>]

Responding to Jim Rowan... sorry to be so slow.

> I'd love to see the -R stuff go away as well.  It is a major detractor.
> 
> However, your proposal causes the behavior of ark installed programs
> to be dependant on the configuration of the machine (OS) itself --

[Recap: "my" [vague] proposal was: lose the -R stuff, have some extra
ARK gunk to "manage" the ld.config game (where to find .so files).]

Jim, I agree with your misgivings.  After all, something must've
pushed me into this -R thing in the first place :-)

I wonder if some sort of hybrid scheme would make sense?  I observe
that not all .so files are created equal...

* things like libgcc_s.so -- every program needs it; carefully managed
  by the GCC lads... Why not just put this in your ld.config...

    /our/.-ark-deploy/gcc--4.0.2/lib
    /our/.-ark-deploy/gcc--3.4.3/lib
    /our/.-ark-deploy/gcc--2.95.3/lib

  ... and declare victory?  If your program picks up the version from
  a different version than what you might've expected, it will almost
  certainly be OK.

* things like libz.so -- very stable interfaces; likely only upgraded
  for security reasons; ubiquitous use; versioning done responsibly.
  Again, having these picked up from a well-controlled ld.config will
  probably be OK.

* things like the Berkeley DB libraries -- you do _not_, on pain of
  death, want a program picking up a version other than the one you
  explicitly intended! -- a horrible horrible death will certainly
  follow.  -R all the way.

Of course, judgement calls are being made in all of that.  So (if you
decided to try to distinguish between those cases), it would a
delicate bit of ARK scripting to keep it all together.

Meanwhile, I wildly support that you should be able to do the kinds of
things you're trying to do ("you don't need anything but a raw box").

(Let me know if I've forgotten something, e.g. from earlier in the
thread.)

Will

Re: gcc, specs, and rethinking the sidai -R thing

[Jim R. <jm...@qu...>]

This one slipped under my radar somehow -- just noticed it.

Will Partain wrote:

>Following on from some of Jim Rowan's recent experience (and mine),
>I'm rethinking some of the Sidai way of dealing with shared
>libraries...
>
>...
>  
>

> <>Now, there's another mechanism for this kind of thing, namely setting
> up ld.config (or equivalent). You tell the runtime linker "here are
> some places to look for shared libraries", and then it does the rest.
> So, for example, I did [on a Sun]...
>
> sudo crle -l /usr/lib:/our/.-ark-deploy/gcc--4.0.2/lib
> ... and my libgcc_s problems went away forever :-)
>
> Now, it's quite easy to play this ld.config game so that it's just as
> ill-disciplined as the "throw it all in /usr/local/include" game. But
> surely there is a way to gain most of the discipline of the "I'll tell
> you _exactly_ what I want" -R'ing scheme. Something like... each
> package providing libraries has a field...
>
> <ld-config-spec>
> <param name="prefix">!sidai_prefix</param>
> <string>$prefix/lib</string>
> </ld-config-spec>
>
> ... and some small program comes through and collects these, and sets
> ld.config appropriately.
>
> I haven't done all this yet, but am seriously considering it. Love to
> see all that -R stuff go up in smoke. Thoughts?


I'd love to see the -R stuff go away as well.  It is a major detractor.

However, your proposal causes the behavior of ark installed programs to 
be dependant on the configuration of the machine (OS) itself -- 
something that I don't believe was previously a requirement (beyond 
having the right stuff mounted/accessible).  This has at least two side 
effects:

1.) It means that these apps have no chance of running on a machine that 
isn't specially configured (unless they're run by a user that has 
LD_LIBRARY_PATH set appropriately).  I'm toying with the possibility of 
building "islands" of ark-ness in AFS, so that people at other places 
can see how cool it is with respect to building/managing apps.      I'd 
really like to build a set of apps that can be run from any box that has 
the appropriate OS, and by a user that does nothing more than adjust 
their PATH.

2.) It seems to preclude more than one run-time environment per 
machine.  A user that wants to run version abcde.alpha of something 
won't be able to (reliably) because the loader finds the wrong shared 
library. 

I don't think this sounds like our ideal solution.  :(

Jim

gcc, specs, and rethinking the sidai -R thing

[Will P. <pa...@dc...>]

Following on from some of Jim Rowan's recent experience (and mine),
I'm rethinking some of the Sidai way of dealing with shared
libraries...

Context ... The old traditional way was: build a library, throw it
into /usr/local/lib, put /usr/local/lib in your LD_LIBRARY_PATH, and
off you go.  Good: easy; bad: /usr/local/lib becomes a mess and (if
you're not careful) a bit of a no-go area ("Don't delete anything, you
have no idea what program relies on that.")

Reaction, the Sidai way: Libraries get built, put into (something
like) /our/.-ark-deploy/<package>--<version>/lib, and everything that
needs those libraries gets linked with "-R
/our/.-ark-deploy/<package>--<version>/lib".  Good: you're being
Really Explicit about what you want; bad: it's a bit of a pain, and
it's hard to replace a library with a simple improvement (e.g. one
security fix).

You've also got to get GCC to cooperate... it links a shared library
libgcc_s.so into lots of things.  So, in building GCC, we 'sed' the
so-called 'specs' file to produce one that inserts a "-R
/our/.-ark-deploy/gcc--4.0.2/lib" (for example) into every link
invocation.

Ugly, but it used to work :-( Recently, Jim reported that it didn't
for him; when I just built gcc 4.0.2, it doesn't even *have* a
deployed specs file!  (I think the specs must get wired into the 'gcc'
binary, or something.)

Now, there's another mechanism for this kind of thing, namely setting
up ld.config (or equivalent).  You tell the runtime linker "here are
some places to look for shared libraries", and then it does the rest.
So, for example, I did [on a Sun]...

  sudo crle -l /usr/lib:/our/.-ark-deploy/gcc--4.0.2/lib

... and my libgcc_s problems went away forever :-)

Now, it's quite easy to play this ld.config game so that it's just as
ill-disciplined as the "throw it all in /usr/local/include" game.  But
surely there is a way to gain most of the discipline of the "I'll tell
you _exactly_ what I want" -R'ing scheme.  Something like... each
package providing libraries has a field...

    <ld-config-spec>
      <param name="prefix">!sidai_prefix</param>
    <string>$prefix/lib</string>
    </ld-config-spec>

... and some small program comes through and collects these, and sets
ld.config appropriately.

I haven't done all this yet, but am seriously considering it.  Love to
see all that -R stuff go up in smoke.  Thoughts?

Will

python; configure; ark...

[Jim R. <jm...@qu...>]

Still fighting against this python configure. :(  Following is long and 
complicated, but I would appreciate whatever ideas anyone has!


My earlier discovery that unsetting CONFIG_SHELL allowed me to run 
configure to completion.  However, I have now run into something else 
and I am baffled by the results of my debugging efforts.

The "problem" is that when I ask ark to configure the package, I get an 
error from configure:

...
+ ./configure --prefix=/our/.-ark-deploy/python--2.4.2 --disable-nls
LDFLAGS= -L/our/.-ark-deploy/python--2.4.2/lib 
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib CXXFLAGS=-O2 
-I/our/.-ark-deploy/python--2.4.2/include CFLAGS=-O2 -fstrict-aliasing 
-I/our/.-ark-deploy/python--2.4.2/include CPPFLAGS= 
-I/our/.-ark-deploy/python--2.4.2/include CXX=/our/bin/g++ 
CC=/our/bin/gcc CONFIG_SHELL=
checking MACHDEP... sunos5
checking EXTRAPLATDIR...
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for c++... /our/bin/g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... configure: error: cannot run 
C++ compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.


config.log tells us a bit more:

...
configure:1833: result: a.out
configure:1838: checking whether the C++ compiler works
configure:1844: ./a.out
ld.so.1: ./a.out: fatal: libgcc_s.so.1: version `GCC_3.3' not found 
(required by file /our/.-ark-deploy/gcc--3.4.4/lib/libstdc++.so.6)
configure:1847: $? = 137
configure:1854: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
...

And this would point fairly clearly to a runtime load library path kind 
of problem...  except that I have very conflicting/confusing other info:

I've tried to recreate this failure by running it in various ways by 
hand, and I cannot recreate it.

0.) If I run configure by hand, (with no args) it works just fine.

1.) I hacked the configure script to save a copy of the a.out that it 
built when run under ark.  I can run a.out just fine.  I don't have 
LD_LIBRARY_PATH set in my environment.

2.) I tracked down the python code in arkbase/ark/think.py that runs the 
shell code that is built up, and uncommented the debug statements near 
line 1800:
        elif lang == 'sh':
            #print 'pre=',`self.preambleSh()`
            #print 'exp=',`self.expandParams(lang)`
            #print 'cod=',`string.strip(code)`
Ran the ark package configure again; saved the resulting statements to a 
file, messed with it to remove/adjust the quoting, and ended up with a 
file (foo) that I can run with the command "sh foo".  This does 
everything that I think ark is doing (certainly the output looks very 
similar).  *It* also runs to completion, and doesn't have trouble with 
the C++ compiler/loader issue.  foo is attached.


This latter one is the most perplexing.  I don't understand how the 
"environment" when run via "ark package configure" might be different 
from what "foo" does -- but it clearly is different enough that it has 
this problem....

Got any ideas?

(I may or may not have a problem with the compiler and libstdc++, but 
even if I do, why does this stuff succeed when run by hand and fail when 
run by ark.?)

(I think I really need to understand this unable-to-recreate-failure, so 
that I can successfully debug any compiler problem I have.)

Re: patch: sidai/package/GNU.xml

[Jim R. <jm...@qu...>]

Will Partain wrote:

> Well figured-out.  This would suggest that the Sidai-ish way to encode
> your knowledge is not to set <CONFIG-SHELL> for a host (because it's
> not a platform-ish thing); rather, in $ARK/sidai/package/python.xml
> [assuming you're using that as one of your prototypes], record...
>
> <configure>
>  <!-- setting config_shell breaks things as at version 2.x.y -->
>  <param name="CONFIG_SHELL"></param>
> </configure>
>
> I guess I'll add that in, unless someone yells.
>
>  
>
Yes, I agree it should go in there.  At this point, I've only confirmed 
that it needs this on Solaris.  (But I don't see how this is likely to 
hurt elsewhere; it's probably also broken anywhere that actually needs 
to set CONFIG_SHELL.  And if it you don't need to set it, unsetting it 
won't hurt!)

+1

Jim

Re: patch: sidai/package/GNU.xml

[Will P. <pa...@dc...>]

Jim Rowan writes:

> I think you're missing the point; ...

No, just floundering helplessly as usual :-)

> And finally, I figured out I should check this outside of ark.
> export CONFIG_SHELL=/bin/bash
> ./configure
> 
> FAILS!  This is an autoconf/python configure issue... it doesn't work
> like it should. :(

Well figured-out.  This would suggest that the Sidai-ish way to encode
your knowledge is not to set <CONFIG-SHELL> for a host (because it's
not a platform-ish thing); rather, in $ARK/sidai/package/python.xml
[assuming you're using that as one of your prototypes], record...

<configure>
  <!-- setting config_shell breaks things as at version 2.x.y -->
  <param name="CONFIG_SHELL"></param>
</configure>

I guess I'll add that in, unless someone yells.

Will

Re: patch: sidai/package/GNU.xml

[Jim R. <jm...@qu...>]

Will Partain wrote:

>
>
>Hmmm... Well, at least we know it got set.  Doing a little test on
>this sol10 box:
>
>  partain@slimy% ksh
>  $ test -e ~/foo
>  $ type test
>  test is a shell builtin
>  $ test -e
>  ksh: test: argument expected
>  $ test -e /dev/ptmx
>  $ echo $?
>  0
>  $ 
>  
>
I think you're missing the point; I get the same thing with ksh, when 
testing in this manner.  It's sh that doesn't work.  And configure, when 
run from the command line, even compensates for it (by switching to 
bash).  It just doesn't compensate when ark invokes it.  THAT's the 
wierdest part.

>In summary: it makes no sense at all :-(  Unless you have some other
>program called 'test' in your PATH and it misbehaves in just the right
>way... I doubt it.
>  
>
Nope.  In any case, test is built in to sh as well.

>What if you change your <CONFIG-SHELL> setting for solaris to /bin/bash?
>I mean, if you've *got* a /bin/bash, I would expect GNU stuff to be
>very bash-friendly.
>
>An unsatisfactory answer... I hate things like this :-)
>  
>
I'll try it -- but it won't work.  ....   nope.  Exactly the same, 
except that the debug output said 'CONFIG_SHELL=/bin/bash'.

The patch/whack that I had posted (changing CONFIG_SHELL) *did* work -- 
but I can't fully explain why (ultimately, in not setting CONFIG_SHELL).


Here's another thing that did work:
<CONFIG-SHELL></CONFIG-SHELL>
this results in the --verbose output showing:
CONFIG_SHELL=

(as one would expect...) and lets configure choose to use bash, sucessfully.

And finally, I figured out I should check this outside of ark.
export CONFIG_SHELL=/bin/bash
./configure

FAILS!  This is an autoconf/python configure issue... it doesn't work 
like it should. :(

Re: patch: sidai/package/GNU.xml

[Will P. <pa...@dc...>]

Jim Rowan wrote:

> + ./configure --prefix=/our/.-ark-deploy/python--2.4.2 --disable-nls
> LDFLAGS= -L/our/.-ark-deploy/python--2.4.2/lib
> -Wl,-R/our/.-ark-deploy/python--2.4.2/lib CXXFLAGS=-O2
> -I/our/.-ark-deploy/python--2.4.2/include CFLAGS=-O2 -fstrict-aliasing
> -I/our/.-ark-deploy/python--2.4.2/include CPPFLAGS=
> -I/our/.-ark-deploy/python--2.4.2/include
> CXX=/pkg/gnu_compilers/gcc-3.2.3/bin/c++ CC=/our/bin/gcc
> CONFIG_SHELL=/bin/ksh

Hmmm... Well, at least we know it got set.  Doing a little test on
this sol10 box:

  partain@slimy% ksh
  $ test -e ~/foo
  $ type test
  test is a shell builtin
  $ test -e
  ksh: test: argument expected
  $ test -e /dev/ptmx
  $ echo $?
  0
  $ 

In summary: it makes no sense at all :-(  Unless you have some other
program called 'test' in your PATH and it misbehaves in just the right
way... I doubt it.

What if you change your <CONFIG-SHELL> setting for solaris to /bin/bash?
I mean, if you've *got* a /bin/bash, I would expect GNU stuff to be
very bash-friendly.

An unsatisfactory answer... I hate things like this :-)

Will

Re: patch: sidai/package/GNU.xml

[Jim R. <jm...@qu...>]

Will Partain wrote:

>Jim Rowan writes:
>
>  
>
>>RCS file: /cvsroot/ark/sidai/package/GNU.xml,v
>>retrieving revision 1.36
>>diff -u -r1.36 GNU.xml
>>--- GNU.xml     11 Apr 2005 11:29:09 -0000      1.36
>>+++ GNU.xml     9 Nov 2005 23:39:59 -0000
>>@@ -121,7 +121,7 @@
>>     eval "$pre_config_eval"
>> fi
>> -CONFIG_SHELL="$CONFIG_SHELL" \
>>+CONFIGURE="$CONFIG_SHELL" \
>> CC="$cc"               \
>> CXX="$cxx"             \
>> CPPFLAGS="$cppflags"   \
>>    
>>
>
>Hmm... I don't buy this.  It simply says "Don't set CONFIG_SHELL"
>(which is probably not right for all GNU-built programs, which is what
>that prototype is for), and instead sets the CONFIGURE environment
>variable... which is never used in a configure script.  (I checked the
>Python one and one or two others.)
>
>You will note that the <host> prototypes
>sidai/host/{linux,solaris}.xml have settings for <CONFIG-SHELL>, to
>either /bin/bash or /bin/ksh, respectively.
>
>Did you try setting <CONFIG-SHELL> for your relevant host (the one
>doing the building), either with the sidai prototype, or one of your
>own (or just directly in your <host>.xml)?
>
>If setting CONFIG-SHELL correctly doesn't work, then we have a problem
>:-)
>  
>
I know *I* have a problem. :)

Yes, I set CONFIG_SHELL.  No, it didn't work.  (I just went back and 
don't see where it was set -- so I reran the whole test again.  It is 
current set in arik/sparc_solaris.xml, a template for cactus-aus where 
tthe build is happening.)

Here is some relevant output:

cactus-aus$ ark package configure --hosts=. --verbose python--2.4.2

 > configure on python--2.4.2 ( not done before )
  [FROM: param PKG_PROTO_HOST       - sidai:package/python [M 1.25 + 
2005.11.09 15:11.07],
         param dep_iflags           - sidai:package/python [M 1.25 + 
2005.11.09 15:11.07],
         param dep_lflags           - sidai:package/python [M 1.25 + 
2005.11.09 15:11.07],
         param pre_config_eval      - sidai:package/python [M 1.25 + 
2005.11.09 15:11.07],
         param extra_configure_args - arik:package/GNU [? + 2005.11.02 
11:34.15],
         code - sidai:package/GNU [M 1.36 + 2005.11.11 11:22.40] ]
 >> host: cactus-aus [for hosts: sparc-solaris9]
PKG_PROTO_HOST=sparc-solaris9
dep_iflags=-I/our/.-ark-deploy/python--2.4.2/include
dep_lflags=-L/our/.-ark-deploy/python--2.4.2/lib 
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
pre_config_eval=/bin/rm -f Iflags Lflags; echo "$dep_iflags" > Iflags; 
echo "$dep_lflags" > Lflags
extra_configure_args=--disable-nls
FIND=/usr/bin/find
XARGS=/usr/bin/xargs
cc=/our/bin/gcc
cxx=/pkg/gnu_compilers/gcc-3.2.3/bin/c++
ccboot=/pkg/gnu_compilers/gcc-3.2.3/bin/gcc
cxxboot=/pkg/gnu_compilers/gcc-3.2.3/bin/c++
cppflags= -I/our/.-ark-deploy/python--2.4.2/include
cflags=-O2 -fstrict-aliasing -I/our/.-ark-deploy/python--2.4.2/include
cxxflags=-O2 -I/our/.-ark-deploy/python--2.4.2/include
ldflags= -L/our/.-ark-deploy/python--2.4.2/lib 
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
cppflagsboot= -I/our/.-ark-deploy/python--2.4.2/include
cflagsboot=-O2 -fstrict-aliasing -I/our/.-ark-deploy/python--2.4.2/include
cxxflagsboot=-O2 -I/our/.-ark-deploy/python--2.4.2/include
ldflagsboot= -L/our/.-ark-deploy/python--2.4.2/lib 
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
in_dir=.
CONFIG_SHELL=/bin/ksh
CONFIGURE=./configure
configure_args=
prefix=/our/.-ark-deploy/python--2.4.2
+ cd 
/prj/qct/sysadmin/aus-it/arik/ark-builds/python--2.4.2/sparc-solaris9/.
+ /usr/bin/xargs+ /usr/bin/find . ( -name config*.cache -o -name 
autom4te.cache -o -name config.log -o -name config.status -o -name 
conftest.c ) -print
 /bin/rm -rf
+ [ x != x ]
+ sidaiPickProgram /our/bin/gcc /pkg/gnu_compilers/gcc-3.2.3/bin/gcc
+ echo /our/bin/gcc
+ sed -e s/ .*//
p_w1=/our/bin/gcc
+ [ -x /our/bin/gcc ]
+ echo /our/bin/gcc
+ return
cc=/our/bin/gcc
+ [ x/our/bin/gcc = x/pkg/gnu_compilers/gcc-3.2.3/bin/gcc ]
+ sidaiPickProgram /pkg/gnu_compilers/gcc-3.2.3/bin/c++ 
/pkg/gnu_compilers/gcc-3.2.3/bin/c++
+ + sedecho /pkg/gnu_compilers/gcc-3.2.3/bin/c++
 -e s/ .*//
p_w1=/pkg/gnu_compilers/gcc-3.2.3/bin/c++
+ [ -x /pkg/gnu_compilers/gcc-3.2.3/bin/c++ ]
+ echo /pkg/gnu_compilers/gcc-3.2.3/bin/c++
+ return
cxx=/pkg/gnu_compilers/gcc-3.2.3/bin/c++
+ [ x/pkg/gnu_compilers/gcc-3.2.3/bin/c++ = 
x/pkg/gnu_compilers/gcc-3.2.3/bin/c++ ]
cppflags= -I/our/.-ark-deploy/python--2.4.2/include
cxxflags=-O2 -I/our/.-ark-deploy/python--2.4.2/include
ldflags= -L/our/.-ark-deploy/python--2.4.2/lib 
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
+ [ x/bin/rm -f Iflags Lflags; echo "$dep_iflags" > Iflags; echo 
"$dep_lflags" > Lflags != x ]
+ eval /bin/rm -f Iflags Lflags; echo "$dep_iflags" > Iflags; echo 
"$dep_lflags" > Lflags
+ /bin/rm -f Iflags Lflags
+ echo -I/our/.-ark-deploy/python--2.4.2/include
+ echo -L/our/.-ark-deploy/python--2.4.2/lib 
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib
+ ./configure --prefix=/our/.-ark-deploy/python--2.4.2 --disable-nls
LDFLAGS= -L/our/.-ark-deploy/python--2.4.2/lib 
-Wl,-R/our/.-ark-deploy/python--2.4.2/lib CXXFLAGS=-O2 
-I/our/.-ark-deploy/python--2.4.2/include CFLAGS=-O2 -fstrict-aliasing 
-I/our/.-ark-deploy/python--2.4.2/include CPPFLAGS= 
-I/our/.-ark-deploy/python--2.4.2/include 
CXX=/pkg/gnu_compilers/gcc-3.2.3/bin/c++ CC=/our/bin/gcc 
CONFIG_SHELL=/bin/ksh
checking MACHDEP... sunos5
checking EXTRAPLATDIR...
checking for --without-gcc... no
checking for --with-cxx=<compiler>... no
checking for c++... /pkg/gnu_compilers/gcc-3.2.3/bin/c++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for gcc... /our/bin/gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /our/bin/gcc accepts -g... yes
checking for /our/bin/gcc option to accept ANSI C... none needed

....

checking for broken nice()... no
checking for broken poll()... no
checking for struct tm.tm_zone... (cached) no
checking for tzname... (cached) yes
checking for working tzset()... yes
checking for tv_nsec in struct stat... yes
checking whether mvwdelch is an expression... yes
checking whether WINDOW has _flags... yes
checking for /dev/ptmx... ./configure: test: argument expected
cactus-aus$


The test for /dev/ptmx involves "test -e".  QED.

I can tell that CONFIG_SHELL ended up being set in the environment in 
which configure was run; the config.log created shows
SHELL='/bin/ksh'

Unfortunately, it doesn't get far enough to create config.status or 
config.log, which would be nicer to see what is really going on.  I am 
not enough of a configure/autoconf wizard to understand in detail how it 
works ... but my understanding is that if SHELL gets set then it will 
have exec'd SHELL to run itself.  I don't see why it fails.

Somehow this failure is being *introduced* by the way ark is invoking 
configure -- I don't get it -- but:

I run this:

/bin/sh (my normal shell is zsh)
SHELL=/bin/sh
export SHELL

<check that no CONFIG_SHELL variable is set in my env...>

./configure

And it succeeds.  The resulting config.status  tells me that  it chose 
to run it under /bin/bash.

cactus-aus$ head config.status
#! /bin/bash
# Generated by configure.
# Run this file to recreate the current configuration.
# Compiler output produced by configure, useful for debugging
# configure, is in config.log if it exists.

debug=false
ac_cs_recheck=false
ac_cs_silent=false
SHELL=${CONFIG_SHELL-/bin/bash}

Re: patch: sidai/package/GNU.xml

[Will P. <pa...@dc...>]

Jim Rowan writes:

> RCS file: /cvsroot/ark/sidai/package/GNU.xml,v
> retrieving revision 1.36
> diff -u -r1.36 GNU.xml
> --- GNU.xml     11 Apr 2005 11:29:09 -0000      1.36
> +++ GNU.xml     9 Nov 2005 23:39:59 -0000
> @@ -121,7 +121,7 @@
>      eval "$pre_config_eval"
>  fi
>  -CONFIG_SHELL="$CONFIG_SHELL" \
> +CONFIGURE="$CONFIG_SHELL" \
>  CC="$cc"               \
>  CXX="$cxx"             \
>  CPPFLAGS="$cppflags"   \

Hmm... I don't buy this.  It simply says "Don't set CONFIG_SHELL"
(which is probably not right for all GNU-built programs, which is what
that prototype is for), and instead sets the CONFIGURE environment
variable... which is never used in a configure script.  (I checked the
Python one and one or two others.)

You will note that the <host> prototypes
sidai/host/{linux,solaris}.xml have settings for <CONFIG-SHELL>, to
either /bin/bash or /bin/ksh, respectively.

Did you try setting <CONFIG-SHELL> for your relevant host (the one
doing the building), either with the sidai prototype, or one of your
own (or just directly in your <host>.xml)?

If setting CONFIG-SHELL correctly doesn't work, then we have a problem
:-)

Will

recent gcc build?

[Jim R. <jm...@qu...>]

I'm building gcc 3.4.4 on solaris, using the sidai/gcc.xml template.

I haven't looked at this enough to be really sure -- but it looks to me 
like the whack to put the -R flag into the specs file isn't actually 
accomplishing the intent.  (The specs file that is deployed does have 
the appropriate -R string in it, but gcc -dumpspecs doesn't -- and the 
behaviour is that something it builds it can't find libgcc.so.)

Does this ring any bells with anyone?  (If not, don't spend a bunch of 
time on it; certainly possible that I have done something dumb...!)

I'll report back tomorrow with more detail when I have it.

patch: sidai/package/GNU.xml

[Jim R. <jm...@qu...>]

It isn't currently using CONFIG_SHELL.  The Python 2.4.2 build breaks on 
solaris as a result, because /bin/sh doesn't do test -e.  This fixes it, 
although it isn't readily apparent from what gets printed as a result of 
--verbose.



cactus-aus$ cvs diff -u GNU.xml
Index: GNU.xml
===================================================================
RCS file: /cvsroot/ark/sidai/package/GNU.xml,v
retrieving revision 1.36
diff -u -r1.36 GNU.xml
--- GNU.xml     11 Apr 2005 11:29:09 -0000      1.36
+++ GNU.xml     9 Nov 2005 23:39:59 -0000
@@ -121,7 +121,7 @@
     eval "$pre_config_eval"
 fi
 
-CONFIG_SHELL="$CONFIG_SHELL" \
+CONFIGURE="$CONFIG_SHELL" \
 CC="$cc"               \
 CXX="$cxx"             \
 CPPFLAGS="$cppflags"   \

Re: welcome to Arusha!

[Will P. <pa...@dc...>]

Hi, Jim (and others) -- Arusha land is pretty quiet, but still
here...  On your various remarks:

> 1.) A sidai suggestion: sidai/package/rsync.xml has a phrase in the
> <patch> section that names a bunch of rsync versions.  I think the
> sense of the test should be reversed, so it tests *for* [
> "$PKG_VERSION" = "2.5.5" ] and defaults to : ok # no worries, mate.
> (The "doesn't need a patch" list is already out of date, 2.6.6 is out
> and the build fails because of this...)

*Yes*.  There are many instances of equally egregious code.  Reason:
the shortest path to success is to add '-o <new-version>' and move on.
But, this being "collaborative sysadmin", I guess I'll need to do
better :-)

> 2.) Mostly a statement: the 'how do I migrate from the "try-ark" mode
> to a real site' instructions are .... lacking.  I got a bit frustrated
> trying to discover in which dark corner the magic config file that was
> causing certain behavior lived... turned out I had a mixture of old
> and new happening, and didn't know that, because of the level of magic
> involved.  At that early phase of maturity, this needs to be smoother.
> (I know -- send patches...  :)

Urgh.  I _do_ tend to test that stuff before releases (which are now
about a year apart -- CVS updates happen, of course...), but of course
I never see it with newbie eyes.  All advice welcome...

> 3.) Newbie Q: what happens if a machine is down when a deploy/reveal
> command is issued?  Is there anything akin to "self-healing state
> management" in here?

Er, not really.  There may be some command-line gunk (--down-hosts=?)
to advise the tool to steer clear; I'd have to look it up.  You can
also change a host <status> to "pending", which means it will get put
into tables and things (i.e. its a "player") but won't get ssh'd to.
I often do this if I know a machine's going to be down for a few days.

The _right_ solution is something like a client cron job that does
'ark package reveal ALL' every 15 mins.  This would need some slight
extra mechanism (which I've never needed) for someone to say "this one
is good to go", after which the cron job would get it.  The machinery
exists... 

   ark package good-to-go synopsys-vcs--2005.06

... which does little more than 'touch' some sentinel; then change
the deploy method a bit to look for the sentinel.

> 4.) Anyone done any windows integration?    Thoughts in that direction?

Um... sorry.

> 5.) Are there any utilities/commands to report on the ark-state info?

No; there should be.  Got an idea for one? -- maybe we could write it.

> 6.) A sidai question: I built a version of gcc to go into /our; used
> the sidai template with just a couple of tiny tweaks.  It got
> installed/deployed in a somewhat unexpected manner -- in the deploy
> tree I have a whole tree of subdirectories, and (most of) the leaves
> are symlinks into the install tree.  A couple of things are directly
> stored in the deploy tree.  All the other apps I've done so far have
> the top of the deploy tree just symlinked to the top of the respective
> install tree. Is this expected, and if so -- what is the logic behind
> doing it this way; and what directive triggered the different install?

The idea was: for a few bits of a GCC build (libgcc.so for example),
you really don't want to be making NFS trips to get it.  So each
(per-client) deployment has a copy of that.  On the other hand,
for swathes of a GCC distribution, one shared copy is fine.  So
symlinks to those bits.  The guilty party is ($ARK/sidai/package/gcc.xml):

<deployment-spec><table><entry name="*">
@TYPE@=manifest
^lib/lib.*\.so copy * * 755
.              link
</entry></table></deployment-spec>

If you just wanted to copy blindly, you'd change (override) that with

<deployment-spec><table><entry name="*">
@TYPE@=copy
</entry></table></deployment-spec>

for example.

Will

welcome to Arusha!

[Jim R. <jm...@qu...>]

So, after a *very* long lurking period, I finally got around to 
installing and using Arusha for real.  Y'all have done a great job -- I 
like it a lot so far.  (1 week)

Our team (humbly named "arik":) has at the moment  2 systems in  it; 
prototypes for SLES9 amd64 and Solaris 9.  Just now beginning to 
integrate it for real into our real world.  In the near future we'll 
have 50ish systems hooked in.  Initially we're just doing (open source 
tools) packages; but I anticipate growing from there.

I've got some questions/comments.. 

1.) A sidai suggestion: sidai/package/rsync.xml has a phrase in the 
<patch> section that names a bunch of rsync versions.  I think the sense 
of the test should be reversed, so it tests *for* [ "$PKG_VERSION" = 
"2.5.5" ] and defaults to : ok # no worries, mate.
(The "doesn't need a patch" list is already out of date, 2.6.6 is out 
and the build fails because of this...)

2.) Mostly a statement: the 'how do I migrate from the "try-ark" mode to 
a real site' instructions are .... lacking.  I got a bit frustrated 
trying to discover in which dark corner the magic config file that was 
causing certain behavior lived... turned out I had a mixture of old and 
new happening, and didn't know that, because of the level of magic 
involved.  At that early phase of maturity, this needs to be smoother.  
(I know -- send patches...  :)

3.) Newbie Q: what happens if a machine is down when a deploy/reveal 
command is issued?  Is there anything akin to "self-healing state 
management" in here?

4.) Anyone done any windows integration?    Thoughts in that direction?

5.) Are there any utilities/commands to report on the ark-state info?

6.) A sidai question: I built a version of gcc to go into /our; used the 
sidai template with just a couple of tiny tweaks.  It got 
installed/deployed in a somewhat unexpected manner -- in the deploy tree 
I have a whole tree of subdirectories, and (most of) the leaves are 
symlinks into the install tree.  A couple of things are directly stored 
in the deploy tree.  All the other apps I've done so far have the top of 
the deploy tree just symlinked to the top of the respective install tree. 
Is this expected, and if so -- what is the logic behind doing it this 
way; and what directive triggered the different install?

Thanks,
Jim