--- Cleve Allison <[EMAIL PROTECTED]> wrote:
...
> One question .......during my installation of
> flowscan and the other
> software compenent that were needed......I logged in
> as root for most of
> the software install (except for flowscan itself
> which warns NOT to do
> the ./configure make make install thing as root but
> rather and the user
> that is created to run the package)
I sometime forget to not be root when I do the
.configure, make, make install thing, but I've yet
been bitten by it (that I know of...). This is
recommend to protect yourself since you are running
scripts that you probably haven't examined in great
detail.
The '.configure' command examines your system to make
sure all the requirements needed to compile the
software are in place, with the result being a
'Makefile' that is custom-built for your system. The
next command 'make' uses that Makefile to actually
compile the source code you have downloaded. You can
see how either of those commands could do all kinds of
damage if you are root, especially as both of those
commands splay a shotgun blast of characters on your
screen, making it easier to hide something nefarious
that a newbie might miss. Even if the author(s) didn't
put any malicious code in the configure script or
other build files, a simple command in the wrong place
('rm -rf *') in the wrong place could give you a
migraine. So, compiling sourcecode as a
non-priviledged user is for your own protection.
After you compile the software using 'make', you can
basically test the software out and use it by
executing the binary executibles, though you may even
have to temporarily add some files to your $PATH
environment variable. It may take a little work to
test it completely, but decent FOSS programmers will
even include a 'make test' option to test things out
for you, or will include details in the documentation
for running the software.
Ideally, you should test the software before
installing it, and only once you are ready to install
it should you become root ('su') and do the final
'make install'.
> but later I
> found that I have to do
> the chown -R thingy on several directories and on
> some files so that the
> flowscan app could create logs, locks, etc as it
> needed. I pretty much
> used trial and error and came up with something that
> worked however, if
> there is an easier, better way then I would prefer
> to do it that way.
> What originally happened was that I tried to install
> all components as
> the "flowscan" user that I created but found that
> this user did not have
> sufficient rights to install things were they wanted
> to go....so I would
> become root but then later the flowscan user needed
> to update create or
> append to already created files but did not have
> sufficient rights to
> update the files and directories so I had to give
> the flowscan user
> ownership of those files, etc.
Sounds to me like this software project is a little
rough around the edges, especially in the distribution
and installation end.
> This is an example of where "all the other
> documentation" is
> lacking....no mention is made of who should install
> what where.....ie.
> it is gear toward someone who knows what they are
> doing.
Like I mentioned earlier, the problem is not the
documentation, it is the build files. They are not
doing everything they could and should do. Of course,
the documentation _should_ say this.
> Is it more
> correct to provide a group with rights to certain
> files and directories
> and then to add my flowscan user to that group?
Depends on your system configuration and your needs.
In your case, you are perfectly okay to do what you
did. You want to use groups when you have a heck of a
lot of users and apps on a system. Creating a single
user and group for the flowscan app makes sense to me.
This isn't a bug, it is a feature of UNIX. ;)
Remember, you have all the control in your hands with
Linux, if you wish to use it. Everything else is just
what the community thinks of as the "common
convention" for configuring stuff in Linux. For a good
place to start to learn about those conventions, read:
http://www.pathname.com/fhs/. I don't know many other
good docs to learn about conventions. I am mostly a
Debian user, so I know about their excellent docs:
http://www.debian.org/doc/ and
http://www.debian.org/doc/devel-manuals#policy.
> I definitely have one way to make this thing
> work......but I don't want
> my document to be giving bad habits to the readers.
Don't worry so much about it. Just preface your
document with those thoughts and ask for feedback.
This is a communal effort, right? Your effort to write
docs up on this will be well-received by the authors
of flowscan. You should contact them early on when you
have something to show them.
> Especially, since
> one of the main points of this document is to
> provide a way for
> non-linux professionals with a way to get their feet
> wet and feel like
> they've accomplished something useful; rather than
> feeling discouraged
> and running back to the other environment.
You put your finger right on one of the most important
hotspots of FOSS: when is it ready for newbies?
Unfortunately, making all this computer/networking
simple is not so simple, especially for FOSS. ;) It
takes a lot of work. That's what the "alpha" and
"beta" version descriptions are for. :) However, don't
let this keep you from completing your chosen task;
write it down, share it with others, watch it grow.
Some of those non-Linux users will be able to stumble
along and get it. Most won't. But you are not alone.
By merely participating, you are helping the effort.
By your effort, more people may get inspired to offer
their support as well. That's all Linus did, and now
Steve Ballmer is losing his hair over Linux.
John Hebert
__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
