[AWS] building AWS error

[David Marceau]

Pascal Obry wrote:
> 
> David,
> 
>  > > Why do you think 1 and 2 are needed ?
>  > Actually, for just compiling examples in the gnat examples directory it
>  > is not necessary.
>  > However for any other project for example adagtk, adawebserver, xmlada,
>  > adasockets....
>  > I sincerely think this is a good preparatory measure for the
>  > includes/run-time-paths to come.
> 
> Well this is automatically done by GNAT...
> 
>  > >  > 3)set the PATH to point typically to c:/gnat/bin
>  > >  > 4)In the makefile.conf file declare the following variables:
>  > >  > AR=c:\gnat\bin\ar
>  > >  > CP=c:\msys\1.0\bin\cp -p
>  > >  > RM=c:\msys\1.0\bin\rm
>  > >  > MAKE=c:\gnat\bin\make
>  > >  > GREP=c:\msys\1.0\bin\grep
>  > >  > DIFF=c:\msys\1.0\bin\diff
>  > >  > SED=c:\msys\1.0\bin\sed
>  > >
>  > > I think it is better to set the PATH to point to the MSYS bin directory here.
>  > Tend to disagree here because there are many things in the makefile and
>  > the makefile.conf that seem to be passed off as understood.
> 
> Yes, but it is said in the documentation that to build AWS you need to install
> a set of UNIX tools (either Cygwin or MSYS) and of course this means that the
> tools are found in the PATH :)
> 
>  > If that was the case the compile would have built the first time
>  > correctly for Ada Web Server without any question.
> 
> Even by reading the doc :)
> 
>  > I am simply trying to clarify all the details in order for this
>  > situation to be prevented in the future and also to
>  > save the AWS team support time :)
> 
> That's fine.
> 
>  > >I think it is better to set the PATH to point to the MSYS bin
>  > >directory here.
>  >
>  > Also to support my argument I have seen the same kind of errors happen
>  > even with msys in the path.
>  > I am only suggesting the above stuff as a preventitive measure and also
>  > to liberate this stuff from the PATH environment variable
> 
> 


> There is anyway something definitly wrong with this is that everybody will
> have to change the the makefile to fit its environment.
All of the makefile(s)/makefile.conf(s) are in you version control
right?  Why would it be so painful to adapt it for this suggestion?
Maybe I'm not too clear about what I believe is important:
1)I don't believe putting everything in the path is the way to go.  I
believe in order to run something, there should be a start up script
that isolates the environment for just that executable.  In that manner
nothing else is in its path except for what it needs.  i.e just
gnat/bin. and no java/bin/, and no gtk bin if it is just ada web
server.  The same goes for the ada include and the ada object path.
2)The same goes for the makefile binaries necessary for the build.  I am
recommending to point out explicitly which tools and explicitly where
they are in a recommended explicit location.  With the present make, if
people just run it without looking into it, they didn't know it was
using cp, rm, grep, diff.  All they know is that they are recommended to
use cygwin tools but they would have no idea exactly which ones are
necessary.  This list is going to get bigger and bigger.
For example, in order to build the aws docs I remember somewhere it was
using tex and tex2pdf tools but there is no mention that tex needs to be
installed.
If there is an explicit environment variable in the makefile for this,
it is like a checklist for all the necessary tools needed to install
before commencing a build and pointing to their explicit path in the
makefile environment variables and not in the global path.

> That's not a good argument. With Cygwin you need to have the path set for the
> Cygwin runtime to be found (cygwin1.dll).
This is a bug not a feature.  It should be like gnat.  The basic exe
knows how to find the rest of that adaincludes/object paths.
How about setting the LD_LIBRARY_PATH in the aws startup script?  The
objective is to isolate and reduce the number of things in the basic
PATH to just what's necesary for aws and not to have everything else
under the sun in its path while it is running aws. i.e. apache, tomcat,
ethereal, pcap, main actor, staroffice, etc...
I envison running ada web server like this:
0)I boot up my machine
0.1)My machine has only the basic clean install paths for the respective
os. i.e. linux(/bin:/usr/bin), windows(/windows:/windows/system)
0.2)The other assumption is nothing else is installed in the linux
standard bin and in the windows standard windows.
1)open up a unix console or windows/dos prompt
2)go to the adawebserver derived application directory,
3)run the startup script.
3.1)The startup script sets up the necessary path in question.  Granted
you add an explicit path to location of the cygwin1.dll but in my
opinion I don't think it should be in the windows directory.  It should
be installed in another isolated directory like any other added extras.
3.2)the startup script sets up the ada include path.  It only points to
the gnat stuff and the ada web server stuff.  Nothing else.  It keeps
the environment controlled and isolated from everything else.
3.3)the startup script sets up the ada objects path
It should only point to the gnat stuff and to the ada web server
compiled stuff.  Nothing else.  Again there is no room for any other
versions of anything else to get in the way when it is done like this
since it is controlled and isolated from all the other applications
running because it is running in its own custom configured environment.
3.4)the startup script sets up the ld_library_path.  Ditto just the gnat
stuff and the ada web server libs, .o's, a's ...
3.5)the startup script sets up the path.  Here is how I assume it should
be done.  At firt point to gnat/bin, then for every necessary dll, add a
path to a directory that only contains that dll and nothing else.  The
assumption is there shouldn't be too many dll's floating around in
windows system.  Why?
There could be another dll with the same name floating around in your
path that gets used instead of the intended dll.  What happens is that
it makes for difficult debugging and it could be eventually a security
risk because somebody else could install another dll with extra
functionality implemented with the same basic api that you don't know
about.

I do hope the above scenario helps understand my thinking pattern as to
why the build configuration should be explicit and isolated in its own
environment as well as the run-time configuration should be explicit and
isolated in its own environment.

Also, the above is only intended to help the aws developers and users
save time in the long-term.  It may seem like a lot of effort doing the
above but in my opinion it is well worth the trouble if it helps you
from preventing hackers to get into your machine.  In my opinion a
developer box is even more important than a user box and every measure
should be done to keep it safe and well-controlled especially since it
is assume the developer boxes are always connected to the net at work
and intermittently at home.  Not keeping a close eye on your environment
and runtime variables could open a door to someone especially if he
knows too much about netbios and dcom.  This is a rumour but I have
heard of a software program that gets installed after an attack on
netbios.  This same program is extremely assymetric in that it
repartitions the hard drive and installs itself there and serves up
files and hells knows what else.  Recently someone tried opening up
ports on my machine on netbios and microsoft - and I would guess it
could be that software.  If you are on a windows box and you have a dll
with a com/dcom/.net interface, it could be possible for the remote
machine to talk to its own program on a regular basis without you
knowing about.  That is the case with this rumoured software.  Hence my
reasoning for the explicit and control environment in not only windows
but also the linux environment via the bonobo and other similar
rpc/com/corba components on linux.  And finally if you don't believe me
about these attacks, I suggest you put yourself directly on the net
without the firewall and have ethereal and pcap running on both windows
and linux and see what kind of log it generates for you.  These
attackers are very smart.  As soon as you appear on the dns, they are
onto you with their intrusion attempts.  Since we are building apps for
internet/extranet with ada web server I do believe these suggestions are
not irrelevant.

All this came about through a simple discussion on environment
configuration.  I do hope all my effort is not in vain.

Thanks for listening to my paranoid delusions :)

Sincerely,
David Marceau