Any "gotcha's" for D3/Linux 7.5.1 over RHEL5.2
Ross Ferris
and even though the testing we have done checks out AOK, just thought
I'd pose the question in case people are aware of any issues that have
climbed out of the woodwork (I'm a little cautious re the FLASH patch
that was released yesterday!)
In case it makes a difference, system is an IBM 3650 with 4Gb RAM, 2 x
3Ghz Quad core CPU's with 4 x 76Gb SAS drives in a RAID-10 array
hanging off a serveRAID-8k controller with 256Mb MB cache
TIA
Ross Ferris
Stamina Software
Visage > Better by Design!
cheseroo
issues. About the only gotcha when setting them up concerns
compressed pseudos. You need to create a logical link for the
compress verb to work properly. We did have some 7.5.1 releases
running on CentOS 5 that over time had funky flusher problems that
were cured by moving back to RHEL.
Mike Wooding
news:c390da39-8156-4141...@s9g2000prg.googlegroups.com
Any chance you could provide further details of these "funky flusher
problems". I'm in the early stages of testing a CentOS 5 box at the moment
and haven't noticed anything (yet!).
TIA
With Kindest Regards
Mike Wooding
cheseroo
> "cheseroo" <chese...@hotmail.com> wrote in message
Sorry for the delay as I see in another post that you are already up
and running. The issue we had was that the flusher wasn't and every
few weeks d3 would come to a halt. In order to get the flusher to
flush, we were having to reboot linux every so often. RD/TL more or
less ran away from the problem as soon as they discovered we were
running on an unsupported O/S (CentOS). Perhaps we could have pushed
the issue more but the reason why we run d3/linux is because we don't
have to think about those machines so we took the easy route and
switched the O/S to RHEL 5.1
Mike Wooding
> Sorry for the delay as I see in another post that you are already up
> and running.
Apology completely unnecessary, and I wouldn't go so far as to say "up and
running". D3 is installed on the CentOS box. Software and client data is
installed on D3, but the testing continues. Client users are currently
nowhere near the machine and that will remain the case until I am certain
all is well (or as certain as I can be).
(Latest niggle is a problem with "auto-xinet" which doesn't seem to be
creating the nailed telnet sessions correctly, despite thinking it has.)
> The issue we had was that the flusher wasn't and every
> few weeks d3 would come to a halt.
I'm running "buffers (l" on the CentOS box now and it is reporting 99.45%
availability, (but then as that's the only process curently running - that's
hardly surprising!)
I'll certainly keep an eye on it, so thanks for the heads-up.
> In order to get the flusher to flush, we were having
> to reboot linux every so often.
Might I enquire as to the exact value of "every so often"?
Also, did you try a periodic "flush" command from TCL? Did that make any
difference?
> RD/TL more or less ran away from the problem as soon as
> they discovered we were running on an unsupported O/S
> (CentOS). Perhaps we could have pushed the issue more
> but the reason why we run d3/linux is because we don't
> have to think about those machines so we took the easy
> route and switched the O/S to RHEL 5.1
The attitude from RD/TL is disappointing, but not entirely unexpected.
Final question: Might I ask how many users were on this system? (Understand
that you might not want / be able to answer that one.)
Thank you for your response.
cheseroo
> > In order to get the flusher to flush, we were having
> > to reboot linux every so often.
>
> Might I enquire as to the exact value of "every so often"?
It seemes to recall it being about 3-4 weeks in between failures. We
never really discovered why it was happening.
> Also, did you try a periodic "flush" command from TCL? Did that make any
> difference?
Yes, executed a z flushd which seemed to hold off the issue but we
still rebooted every couple weeks as a pre-emptive strike.
> > RD/TL more or less ran away from the problem as soon as
> > they discovered we were running on an unsupported O/S
> > (CentOS). Perhaps we could have pushed the issue more
> > but the reason why we run d3/linux is because we don't
> > have to think about those machines so we took the easy
> > route and switched the O/S to RHEL 5.1
>
> The attitude from RD/TL is disappointing, but not entirely unexpected.
Rick Davies was trying to convince them to certify CentOS and they
were considering it under the argument that it was based upon RedHat
but that effort kind of faded after this episode. RD/TL tried to run
gdb on the machine and discovered it wasn't installed as a part of
CentOS and that was the end of that.
> Final question: Might I ask how many users were on this system? (Understand
> that you might not want / be able to answer that one.)
It's a 30 user system.
Tony Gravagno
consideration for the facts - and even when the facts are presented in
a way that's favorable toward RD/TL they're still twisted into
something that sounds unfavorable.
Guys, I haven't been employed by that company for 8 years. It's
ancient history in my career. I don't sell their stuff. I don't have
any particular allegiance to them compared to any of the other MV DBMS
companies. They're just another company to me, and for the record (no
reflection on the people who implement policy decisions) I don't think
much of the company as a business entity either. So any claim of bias
on my part is simply targeting the messenger and not the message.
Like any other company I think they deserve fair commentary. So when
I'm commenting on the unfair commentary here, just remember I'd do the
same for you, whether I agree with you or not.
cheseroo wrote:
>> > RD/TL more or less ran away from the problem as soon as
>> > they discovered we were running on an unsupported O/S
>> > (CentOS).
Let's start with a technical perspective.
I'll preface all of this with the point that I always use CentOS when
possible and have not installed RHEL for my own use since they
implemented the mandatory fee-for-support model. So I fully support
CentOS and it would be in my best interest if TL supported it.
However, I use CentOS with full understanding of the ramifications,
which apparently other people still don't quite understand.
CentOS is not a supported platform for D3. What this means is that TL
is fully aware that it is based off of the same upline code as RHEL,
but TL has simply not gone through the testing cycle to certify this
platform as they would RHEL. Does this mean they think it's bad? No.
Will they refuse all support calls outright if you mention you're
running over CentOS? No. They can't claim support for a platform
that they simply haven't tested.
There is no reason at all why most code in the VME will run
differently on CentOS than RHEL, so if you have an issue inside the
environment then they will probably address it like any other with no
further questions.
As to the underlying OS, you need to understand that CentOS is a
completely separate distribution of Linux. It is assembled by
dilligent people, not being paid for their FLOSS efforts, who seek out
and modify the patches required to create their distro. Their goal is
to produce an equivalent package, but they don't always get it right.
Just look at the CentOS forum and you'll see that there are always
reports of some issue that was missed.
The VME makes frequent use of the OS for many features including
anything related to process handling for each PIB/Phantom, !executes,
tape operations, memory, disk access, and for compilation and
execution of FlashBASIC code. Because of this frequent cross-over
there will be many areas that turn out to be related to the D3 monitor
(the one that gets M patches) even if it doesn't look obvious that the
OS is involved at all. When D3 is being developed we can't expect
them to recompile and test over RHEL and CentOS. When a patch is
issued we can't expect that this very focused code will work over
CentOS.
Now to the commentary blaming this on TL:
>> Perhaps we could have pushed the issue more
>> > but the reason why we run d3/linux is because we don't
>> > have to think about those machines so we took the easy
>> > route and switched the O/S to RHEL 5.1
"We don't have to think about those machines"? What the hell does
that mean? Do you mean "we didn't want to pay the support fees for
those machines"?
Further, are you saying RHEL worked but CentOS did not? Doesn't that
clarify once and for all that CentOS is a derivative of RHEL and not a
copy, and that this and other derivatives like WhiteBox Linux are
subject to functioning differently?
As soon as the point is proven that some feature works in RHEL and not
CentOS, the position to not "support" CentOS is justified. If TL
claims support for the platform, they commit to testing, keeping up
with the latest product changes, and some amount of training for
internal people. All of that implies a budget for the effort. At
this point the question is not technical, it's a matter of who's money
is going to be spent - yours for RHEL Support or theirs to support
your free software.
And once again here is where people are severely confusing the line
between the concepts of Free beer and Free liberty. If you love Open
Source so much, and you're getting CentOS as Free (beer) software,
then hire someone to work with TL to support the software. That's the
price you pay for your free (liberty) software! If you can't afford
that, then pay RedHat their fee to produce their platform. But face
the facts that free (liberty) software is not always going to be
completely free (beer).
From Mike:
>> The attitude from RD/TL is disappointing, but not entirely unexpected.
My friend, I'm sorry, but that's another one of those "bandwagon"
statements that are completely unfounded but popularly accepted. If
the exact same statement were made about Martin Phillips for exactly
the same situation, there would be an uproar. Decisions need to be
made about which platforms will and will not be supported. These
decisions are based on the relative benefit vs expense of the effort
and need to be addressed at a business level - condemning Support
people for this is simply wrong. When a policy decision is made you
can't expect a Support technician or the Engineering department to
offer to go down the rabbit hole for you to thoroughly vet and resolve
any issue related to the "unsupported" platform.
The term "disappointing" is used when someone can do something and
they don't. In this case there are potentially hundreds of hours that
need to be spent to support a new platform. If you want the company
to support the platform, justify that time for them, but don't say a
technician's attitude is disappointing when they can't start to jump
into the middle of that process and try to change it.
The phrase "not entirely unexpected" would have a place elsewhere (and
I can think of many places where shortsighted thinking at TL is "not
entirely unexpected") but here it's simply inflamatory.
Cheseroo, your misrepresentation of the facts is heinous:
You said:
>> > RD/TL more or less ran away from the problem as soon as
>> > they discovered we were running on an unsupported O/S
>> > (CentOS).
Then you said:
>Rick Davies was trying to convince them to certify CentOS and they
>were considering it under the argument that it was based upon RedHat
>but that effort kind of faded after this episode.
So they didn't run away. It went to Engineering, they loaded up
CentOS, and tried to debug your issue. They were supporting an
unsupported platform - as they've done for many of us many times.
Once again quoting Mike: "The attitude from RD/TL is disappointing,
but not entirely unexpected." Doesn't it seem now like their attitude
was quite accommodating? Doesn't anyone get brownie points for the
effort? Why do you make it sound like there was no effort at all?
>RD/TL tried to run
>gdb on the machine and discovered it wasn't installed as a part of
>CentOS and that was the end of that.
Ibid. Obviously they did try to accommodate you.
Installing gdb is easy. Obviously there was more to it and that's
when the distinction between CentOS and RHEL made this an effort which
involved expense on one hand and ROI on the other. That's a business
decision. If you don't like it, take it up with management and
explain to them why your lack of desire to spend a few hundred dollars
is worth their tens of thousands of dollars in engineering.
Shifting gears a bit: Honestly I've tried to fight with that "prove to
me that it's worth it" attitude over there before, and again their
short-sightedness is amazing, but "not entirely unexpected". Then
again, while there are some areas where I know the long-term returns
to them would be better, I can only rarely cite a near-term positive
business case for them to make changes - so their short-sightedness
almost always wins. I'm not pleased with the results, but I'm happy
that I was given the opportunity to make a case. THAT's what's
important. If you have a case for them to support some platform, make
it. If you don't - other than it will save you some bucks - drop it.
Nuff outta me.
T
cheseroo
> "We don't have to think about those machines"? What the hell does
> that mean? Do you mean "we didn't want to pay the support fees for
> those machines"?
Irrespective of anything else of value you might have to say, you've
completely lost my interest when you get to this comment. Blow it out
your backside Mr Gravagno. Every single one of our combined 1000 or
so d3 users is on a full d3 support contract. Always has been that
way and always will. Every single RHEL installation is registered
with Red Hat. So go f yourself.
My comment about not having to think about these machines refers to
them running on d3/linux. If we have to be responsible for the
machines when/if they tip over, we insist on d3/linux. d3/NT isn't
worth considering when compared to d3/linux.
Talk about going off without any facts, geez.
cheseroo
> I'm really fed up with this BS. There is a complete lack of
> consideration for the facts - and even when the facts are presented in
>
> "Do you mean "we didn't want to pay the support fees for
> those machines"?
>
Regardless of anything of value you may/may not have to add, this last
statement upset me so much that my original response included language
that evidently did not pass muster. Mr Gravagno even though we both
live in the same region, let's not meet in person anytime soon. The
company I work for combined has roughly 1000 d3/nt users and every
single one is under a full RD/TL support contract. We've never
cheated this and never will. Every single one of the machines out
there running RH is running a paid, registered copy. So, blow it out
your backside.
> There is a complete lack of consideration for the facts
no kidding
Ross Ferris
probably go SUSE.
I haven't used the product, have no knowledege of it or experience
with it BUT it is supported by the major hardware manufacturers, and
is also the only SUPPORTED Linux distro under Hyper-V.
That said, when I compare the $349 it costs for RHEL5 as a download
with support to what I used to pay for SCO Unix, I figure it is worth
the money - and lets face it, if a client will not spring for $349 to
avoid the POTENTIAL of problems, ARE THEY WORTH IT ?!?!?
Anyway, thanks for the feedback from all, both on & off list (now
looks like I'll be installing 2 systems this week)
Andrew Kenna
far prefer Redhat. I've used a large variety of Linux variant's and SUSE
would have to be my most hated of all.
I am also a big believer in using what the supplier recomends to a certain
degree, as the last thing you want to do is sell a customer a server. Put
for arguements sake CentOS on there and have problems every couple of
weeks.. The less time a customer sees their server going down the more money
they make and the better the company looks that provided the server to them
because they can get on with what they are good at.
Whereas if the server was continually going down whether it be due to a D3
failure/problem or an operating system problem the customer is going to
start getting frustrated really quickly as they are spending more time on
the phone asking for help than they are running their business or selling
their products.
Andrew
"Ross Ferris" <ro...@stamina.com.au> wrote in message
news:707355c7-0e4a-4028...@w24g2000prd.googlegroups.com...