multiplatform /bin directory

multiplatform /bin directory

Post by Usman Muzaffa » Tue, 21 Dec 1999 04:00:00



Hi -

We have a couple dozen programs which were developed in-house.
Some are scripts (most Tcl/Tk, Perl, or sh), most are compiled
C or Fortran, and then there's a handful of oddballs (lisp
images, etc).

We also have a pretty heterogenous set of workstations:
Linux/x86, Solaris/SPARC, Solaris/x86, Tru64/Alpha, AIX/rs6000,
HPUX, Win9x, DOS, NeXT, and even a dying SunOS box or two.

The goal is simple: I'd like a single shared /bin directory
to be the home of all our in-house stuff (performance over
the lan has never been an issue). Right now, I have a /bin
directory that supports four architectures (tru64/alpha,
linux/x86, aix/rs6000, and solaris/sparc).

Scripts aren't really a probelm - I just use the shellbang
hack, which works great as long as the interpreter is in the
user's path (wherever that happens to be on the user's host):

#!/bin/sh
# restart \

...

and similarly for Perl, etc.

For compiled programs, each program foo is built as
foo.sparc, foo.alpha, foo.x86, foo.rs6000, and then 'foo'
is a symlink to .wrapper, which just calls the correct
binary with whatever arguments it was passed.

This system works well, but:

1. Now that I want to add different operating systems on
   the same arch (eg. both linux/x86 and solaris/x86),
   just 'foo.arch' is not enough. I could go 'foo.arch.os'
   but that is starting to seem clumsy - or is that just my
   own hangup?

2. In the case where a program has library/supporting files
   that are not arch dependent, they just go in a parallel /lib
   or /share directory - but if compiled libraries exist -
   should they go in their own arch/os directory hiearchy, or
   just all dumped in a flat /lib like the bin directory?
   Both choices seem to have advantages and disadvantages -
   comments appreciated.

3. Finally, the really tricky question: Samba can let us share
   this unix directory to DOS/Win systems; but of course all of
   the .wrapper and shellbang tricks above won't work now.
   Is there some neat solution (perhaps Samba pre/post processing)
   that will let me run a file /bin/foo.win32 as just 'foo' from Windows,
   without disturbing/cluttering anything else in the /bin directory?

Any comments or suggestions from anyone who has set up something
like this are greatly appreciated.

thanks,
usman

remove x from above to reply, if present

 
 
 

multiplatform /bin directory

Post by Dave Hi » Tue, 21 Dec 1999 04:00:00


I've got my development environment set up so all of the tools
I've compiled live in /devbin .

/devbin is a symbolic link to:
/usr/develop/`uname -sr|tr " " "_"`/bin

This way, when I get a new OS in house, I rebuild the
tools in the appropriate /usr/develop directory, and the
users find it at /devbin/whatever.  So, they can put
/devbin/perl in their scripts, or have /devbin in their
path, and it'll always have the right executable as long
as the link as been made on their client (and I've built
the tool for their OS).

Works quite well.  I'm happy with it, and my developers
always know where to find tools.  If it ain't in /devbin,
they ask nice & I build it.

Dave Hinz

: Hi -

: We have a couple dozen programs which were developed in-house.
: Some are scripts (most Tcl/Tk, Perl, or sh), most are compiled
: C or Fortran, and then there's a handful of oddballs (lisp
: images, etc).

: We also have a pretty heterogenous set of workstations:
: Linux/x86, Solaris/SPARC, Solaris/x86, Tru64/Alpha, AIX/rs6000,
: HPUX, Win9x, DOS, NeXT, and even a dying SunOS box or two.

: The goal is simple: I'd like a single shared /bin directory
: to be the home of all our in-house stuff (performance over
: the lan has never been an issue). Right now, I have a /bin
: directory that supports four architectures (tru64/alpha,
: linux/x86, aix/rs6000, and solaris/sparc).

: Scripts aren't really a probelm - I just use the shellbang
: hack, which works great as long as the interpreter is in the
: user's path (wherever that happens to be on the user's host):

: #!/bin/sh
: # restart \

: ...

: and similarly for Perl, etc.

: For compiled programs, each program foo is built as
: foo.sparc, foo.alpha, foo.x86, foo.rs6000, and then 'foo'
: is a symlink to .wrapper, which just calls the correct
: binary with whatever arguments it was passed.

: This system works well, but:

: 1. Now that I want to add different operating systems on
:    the same arch (eg. both linux/x86 and solaris/x86),
:    just 'foo.arch' is not enough. I could go 'foo.arch.os'
:    but that is starting to seem clumsy - or is that just my
:    own hangup?

: 2. In the case where a program has library/supporting files
:    that are not arch dependent, they just go in a parallel /lib
:    or /share directory - but if compiled libraries exist -
:    should they go in their own arch/os directory hiearchy, or
:    just all dumped in a flat /lib like the bin directory?
:    Both choices seem to have advantages and disadvantages -
:    comments appreciated.

: 3. Finally, the really tricky question: Samba can let us share
:    this unix directory to DOS/Win systems; but of course all of
:    the .wrapper and shellbang tricks above won't work now.
:    Is there some neat solution (perhaps Samba pre/post processing)
:    that will let me run a file /bin/foo.win32 as just 'foo' from Windows,
:    without disturbing/cluttering anything else in the /bin directory?

: Any comments or suggestions from anyone who has set up something
: like this are greatly appreciated.

: thanks,
: usman

: remove x from above to reply, if present

 
 
 

multiplatform /bin directory

Post by Rev. Don Koo » Wed, 22 Dec 1999 04:00:00



> Hi -

> We have a couple dozen programs which were developed in-house.
> Some are scripts (most Tcl/Tk, Perl, or sh), most are compiled
> C or Fortran, and then there's a handful of oddballs (lisp
> images, etc).

> We also have a pretty heterogenous set of workstations:
> Linux/x86, Solaris/SPARC, Solaris/x86, Tru64/Alpha, AIX/rs6000,
> HPUX, Win9x, DOS, NeXT, and even a dying SunOS box or two.

> The goal is simple: I'd like a single shared /bin directory
> to be the home of all our in-house stuff (performance over
> the lan has never been an issue). Right now, I have a /bin
> directory that supports four architectures (tru64/alpha,
> linux/x86, aix/rs6000, and solaris/sparc).

> Scripts aren't really a probelm - I just use the shellbang
> hack, which works great as long as the interpreter is in the
> user's path (wherever that happens to be on the user's host):

> #!/bin/sh
> # restart \

> ...

> and similarly for Perl, etc.

> For compiled programs, each program foo is built as
> foo.sparc, foo.alpha, foo.x86, foo.rs6000, and then 'foo'
> is a symlink to .wrapper, which just calls the correct
> binary with whatever arguments it was passed.

> This system works well, but:

> 1. Now that I want to add different operating systems on
>    the same arch (eg. both linux/x86 and solaris/x86),
>    just 'foo.arch' is not enough. I could go 'foo.arch.os'
>    but that is starting to seem clumsy - or is that just my
>    own hangup?

> 2. In the case where a program has library/supporting files
>    that are not arch dependent, they just go in a parallel /lib
>    or /share directory - but if compiled libraries exist -
>    should they go in their own arch/os directory hiearchy, or
>    just all dumped in a flat /lib like the bin directory?
>    Both choices seem to have advantages and disadvantages -
>    comments appreciated.

> 3. Finally, the really tricky question: Samba can let us share
>    this unix directory to DOS/Win systems; but of course all of
>    the .wrapper and shellbang tricks above won't work now.
>    Is there some neat solution (perhaps Samba pre/post processing)
>    that will let me run a file /bin/foo.win32 as just 'foo' from Windows,
>    without disturbing/cluttering anything else in the /bin directory?

> Any comments or suggestions from anyone who has set up something
> like this are greatly appreciated.

        I don't know how wedded you are to your current solution but
a simple way to support the different architectures is to take
advantage of the ARCH and OS variables in the automounter.  Under
"/bin" create a separate subdirectory named after that
architecture-os and then use "$ARCH" and "$OS" in the automount
maps.

        ex: /bin/sun4-sunos5/my_binary

        auto_apps:  my_binary   hostmachine:/bin/$ARCH-$OS/&

        Note:  I don't do it exactly like this so I'm not positive that
it's exactly right.  I just put it out there because it takes
advantage of the built in automount variables.  What I do is start
the automounter with a "-D KEY=sun4-sunos5" and then use "$KEY" in
the automount maps.

                        Hope this helps,
                              Don

--
**********************      You a bounty hunter?
* Rev. Don McDonald  *      Man's gotta earn a living.
* Baltimore, MD      *      Dying ain't much of a living, boy.
**********************             "Outlaw Josey Wales"
http://members.home.net/oldno7

 
 
 

multiplatform /bin directory

Post by Quang Pha » Thu, 23 Dec 1999 04:00:00


Similar to Rev. Don Kool idea, how about creating sub directories under
/bin, i.e. /bin/SOLARIS/bin
     /bin/SunOS/bin
     /bin/Linux/bin
     /bin/AIX/bin

in addition to this, you should write a public .cshrc file for everyone
to use.  Basically, the common .cshrc file will look for the platform
that the user's currently on and set $path enviroment to the appropriate
directory.

for example:

common .cshrc file
-------------------
#
setenv PLATFORM `uname -m`
set systype = `uname -s``uname -r | cut -c1`
setenv SYSTYPE $systype

switch ($systype)
    case SunOS4:
        setenv PATH /sbin:/bin/SunOS/bin
        .............
    brakesw;
    case SunOS5
        if ("/$PLATFORM" == "/i86pc") then
            setenv PATH /sbin:/bin/SolX86/bin
            ...........
        else
            setenv PATH /sbin:/bin/SOLARIS/bin      
            ...........
        endif
    brakesw;
    case AIX*:
        .........
        ...........
    breaksw;

# and continue on

=================================

user's .cshrc file
------------------
if (-f /bin/.chsrc) then
    source /bin/.cshrc
else
    echo "common .cshrc not found"
endif

...............

==============================================

don't know if this help.

regard,
Quang.

 
 
 

multiplatform /bin directory

Post by Dave Hi » Thu, 23 Dec 1999 04:00:00


I don't see the Rev's posts, due to a wonderful feature of my newsreader
configuration.  However,  the common .cshrc file (I call mine as .devrc),
is greatly simplified by getting rid of the "If it's Solaris 5.6, then..."
"If it's Irix 6.5, then...", "If it's Linux 2.0.36 then,", etc, by
making sure the path is consistant for each architecture, and then just setting
the path to include /usr/develop/$OSTYPE/bin, for instance.

I further simplify this, as I mentioned  here previously, by making a symbolic
link on each client making sure that /devbin points to the proper set
of executables.

I haven't found a problem using the uname -sr to determine OSTYPE.  Change the
space to an underscore, use the whole sttring as a directory name, and all the if/then's are
gone.

Dave Hinz

: Similar to Rev. Don Kool idea, how about creating sub directories under
: /bin, i.e. /bin/SOLARIS/bin
:      /bin/SunOS/bin
:      /bin/Linux/bin
:      /bin/AIX/bin

: in addition to this, you should write a public .cshrc file for everyone
: to use.  Basically, the common .cshrc file will look for the platform
: that the user's currently on and set $path enviroment to the appropriate
: directory.

: for example:

: common .cshrc file
: -------------------
: #
: setenv PLATFORM `uname -m`
: set systype = `uname -s``uname -r | cut -c1`
: setenv SYSTYPE $systype

: switch ($systype)
:     case SunOS4:
:         setenv PATH /sbin:/bin/SunOS/bin
:         .............
:     brakesw;
:     case SunOS5
:         if ("/$PLATFORM" == "/i86pc") then
:             setenv PATH /sbin:/bin/SolX86/bin
:             ...........
:         else
:             setenv PATH /sbin:/bin/SOLARIS/bin      
:             ...........
:         endif
:     brakesw;
:     case AIX*:
:         .........
:         ...........
:     breaksw;

: # and continue on

: =================================

: user's .cshrc file
: ------------------
: if (-f /bin/.chsrc) then
:     source /bin/.cshrc
: else
:     echo "common .cshrc not found"
: endif

: ...............

: ==============================================

: don't know if this help.

: regard,
: Quang.

 
 
 

multiplatform /bin directory

Post by Rev. Don Koo » Sat, 25 Dec 1999 04:00:00



> Similar to Rev. Don Kool idea, how about creating sub directories under
> /bin, i.e. /bin/SOLARIS/bin
>      /bin/SunOS/bin
>      /bin/Linux/bin
>      /bin/AIX/bin

> in addition to this, you should write a public .cshrc file for everyone
> to use.  Basically, the common .cshrc file will look for the platform
> that the user's currently on and set $path enviroment to the appropriate
> directory.

> for example:

        [...snip...]

        Quang, the only problem I have with your solution over mine is that
yours seems more complicated and more easily corrupted.  It depends
on the setting of the PATH environment variable which is something
under the users' control.  I would venture to guess that there are
very few of use who never saw a user modify their ".cshrc" file to
set path without including "$path" in their "set path" statement.
My suggestion to add a "KEY" variable to the automounter startup and
the automount maps has at least one advantage.  The user can't *
it up.

                        Hope this helps,
                              Don

--
**********************      You a bounty hunter?
* Rev. Don McDonald  *      Man's gotta earn a living.
* Baltimore, MD      *      Dying ain't much of a living, boy.
**********************             "Outlaw Josey Wales"
http://www.veryComputer.com/

 
 
 

multiplatform /bin directory

Post by Umberto Quai » Tue, 11 Jan 2000 04:00:00


About point number 3:

I don't know if you should configure Samba to launch a program
remotely. However, in MS-Windows extensions like .com or .exe
are tried before other possibilities when you specify a command
(the order should be first .com, then .exe, then .bat).

So what about making a symbolic link named foo.exe which points to
foo.win32 ? If you are lucky, that should solve your Windows problem:
no scripts are needed because Windows automatically chooses foo.exe.
On the other hand, UNIX doesn't operate that way and your foo script
still works as usual. Windows can't launch foo, because scripts must
have .bat extension.

Just try, with fingers crossed (as usual with MS & such)...         :-)

 
 
 

multiplatform /bin directory

Post by Umberto Quai » Tue, 11 Jan 2000 04:00:00


About point number 3:

I don't know if you should configure Samba to launch a program
remotely. However, in MS-Windows extensions like .com or .exe
are tried before other possibilities when you specify a command
(the order should be first .com, then .exe, then .bat).

So what about making a symbolic link named foo.exe which points to
foo.win32 ? If you are lucky, that should solve your Windows problem:
no scripts are needed because Windows automatically chooses foo.exe.
On the other hand, UNIX doesn't operate that way and your foo script
still works as usual. Windows can't launch foo, because scripts must
have .bat extension.

Just try, with fingers crossed (as usual with MS & such)...         :-)

 
 
 

1. Root directory 'bin bin'?

        (This discussion started in comp.unix.aix.  I've cross-posted
to comp.security.unix to get more input.  The original question was
why not change AIX's / ownership from 'bin bin' to 'root staff'?)


        The root account is often carefully maintained, while some
people are careless about what bin can access.  A number of cookbook
approaches involve getting access to the bin account, and then
promoting yourself to root.

        The fact that bin is expired (mentioned in another post) may
well be irrelevant.  Dan Farmer & Wietse Venema recently posted a
paper to the Firewalls mailing list in which they talked about
breaking in to systems by means other than password cracking/spoofing.

        Tangental note: AIX, as shipped, is as vulnerable to at least
one of these attacks, DNS spoofing, as any other OS.  To protect
yourself, remove *all* lines begining with # from /etc/hosts.equiv.
I've opened a call to ask IBM to remove this vulnerability from future
versions of AIX.

        No, hes not.  If bin owns /, bin can write to /.rhosts, /bin/*,
/sbin/*, /boot, or just about anything with an appropriate use of
chmod.  This leaves a path for just as long as it takes to get root
access this way and cover your tracks.

        Good advice.  Why does bin own /?  Why not default it to root
ownership?

--

Politics.  From the greek "poly," meaning many, and ticks, a small,
annoying bloodsucker.

2. Please help Linux newbie with Motif question

3. /usr/bin, /usr/local/bin, /sbin or /opt/bin, /var/opt/bin - I'm confused.

4. Zaptel Pseudo TDM Bus

5. Aliasing cgi-bin directory to CGI directory

6. Missing libXmu.so.6

7. /bin /usr/bin /usr/local/bin etc

8. inetd is missing. Help

9. Difference between /bin and /usr/local/bin and */bin?

10. /cgi-bin/phf /cgi-bin/test-cgi /cgi-bin/handler

11. Any specific reason of /bin and /sbin directories in Linux ( or unix variants.)

12. Creating user cgi-bin directories

13. Why should bin not own a directory