On Mon, 30 Apr 2012 13:23:40 -0400, Eitan Adler wrote:
> On 30 April 2012 07:36, Robert Bonomi <bonomi@mail...> wrote:
> > A competennt, "not stupid", sysadmin would know these things. And not
> > 'remove all doubt' (in the words of Abraham Lincoln), by raising such
> > nonsense questions.
> A competent sysadmin would ask questions when they don't know the
> answer bringing up possibilities they thought about.
> A stupid sysadmin would yell at someone asking a question claiming
> they should have known the answer.
I know I don't add anything substantial by the following
statement, but allow me to post it anyway in addition to
There is no problem in mentioning thoughts, possibilities
and options. It's also not a problem to admit a lack of
knowledge in certain fields (e. g. how UFS, journaling,
nullfs and fsck do "interact" with each other).
Things start to be problematic when conclusions are made
out of untrue assumptions or expectations. "It must be
a system error, as I don't see a human error here."
The problem is: "don't see" != "doesn't exist", and of
course != "can't be proven". Such kinds of conclusion
often lead into wrong directions.
Of course it's hard to narrow down possibilities. A "test
bed" with limited variables is neccessary to have. Also
the proper tools and procedures of testing are important.
That's the ONLY way to be sure - by eliminating one
possibility after the other. What's being found in the
end - and even if it's regarded unprobable from the
beginning - must be the reason.
Robert mentioned important things to consider. If you
(unintendedly) destroy evidence for a forensic analysis
of what happened (whatever it may be), you'll have a
hard time finding out _what_ happened - except you can
get it to happen again. In case of security breaches
this is something you _don't_ want to risk IN PUBLIC
just to be able to observe it.
At this point, one could argue politeness vs. importance
of arguments. From what I've seen on other lists, Robert's
statements are "still polite" and full of things you can
take as a start to what to additionally learn. You should
concentrate on that essence. If you take the time to "do
your homework", you'll be better prepared _if_ such thing
should ever happen again. Finding out _what_ has happened
is very hard (which I admit), and maybe it's even impossible.
You would have needed a more verbose auditing facility to
find out what program (user) caused a "mv-like syscall".
Command logs can be altered, logged syscalls... yes, it's
not impossible, but magnitudes _harder_ to remove trails.
By the way, I can understand the frustration when something
"impossible" happened and you never can _really_ say what
it was, hoping it would not happen again. I've experienced
such kinds of trouble myself. (That's why I'm on this list.)