Re: The oh so stable Linux - Linux

This is a discussion on Re: The oh so stable Linux - Linux ; On Mon, 20 Oct 2008 10:42:53 -0500, Sinister Midget wrote: > Which is exactly why I asked what it was he was doing. Even in a > workaround situation (such as the script, or a modified one that sets > ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: Re: The oh so stable Linux

  1. Re: The oh so stable Linux

    On Mon, 20 Oct 2008 10:42:53 -0500, Sinister Midget wrote:

    > Which is exactly why I asked what it was he was doing. Even in a
    > workaround situation (such as the script, or a modified one that sets
    > up a lot of rules) it should happen so fast as to be undetectable, more
    > like a quick network glitch. Certainly not a long laborious process the
    > way he makes it sound.


    The server is a combination Firewall/PBX. It has two WAN connections
    because both are only semi-reliable. When one fails, it fowards traffic to
    the other, and when the first is restored it puts traffic back on the
    primary interface. In addition, the PBX listens on both external
    interfaces, connecting to two different VOIP servers. If one network goes
    down, then the VOIP provider automatically routes the calls to the second
    IP.

    This is the sort of thing that Watchguards and SonicWalls do all the time.
    DUAL-WAN with failover (not load balancing).

    Now, what happens, is after a period of time, something in IPTables gets
    confused. It starts to randomly drop packets that there are rules for (and
    you can see them still when you list rules). It stops forwarding traffic
    randomly (sometimes to one subnet, sometimes to others). It stops logging
    failures, so the logfile is useless.

    So I delete the rules, unload mod_conntrack, etc.. then reload them, and
    everything works fine again until it starts whacking out again.

    >
    > Hell, if it happens with frequency just cronjob the thing and it can
    > take care of itself. If they're using Windwoes (my guess) they're
    > already accustomed to long timeouts. They wouldn't even notice a
    > split-second glitch every hour and a half that reset the rules. More
    > than likely the desktops would all be in the middle of one of their
    > frequent 10-second confused states anyway.
    >
    > But I never got any answers from Erik because he was already in a
    > corner and had no place left to go. And he knew it.


  2. Re: The oh so stable Linux

    Erik Funkenbusch writes:

    > On Mon, 20 Oct 2008 10:42:53 -0500, Sinister Midget wrote:
    >
    >> Which is exactly why I asked what it was he was doing. Even in a
    >> workaround situation (such as the script, or a modified one that sets
    >> up a lot of rules) it should happen so fast as to be undetectable, more
    >> like a quick network glitch. Certainly not a long laborious process the
    >> way he makes it sound.

    >
    > The server is a combination Firewall/PBX. It has two WAN connections
    > because both are only semi-reliable. When one fails, it fowards traffic to
    > the other, and when the first is restored it puts traffic back on the
    > primary interface. In addition, the PBX listens on both external
    > interfaces, connecting to two different VOIP servers. If one network goes
    > down, then the VOIP provider automatically routes the calls to the second
    > IP.
    >
    > This is the sort of thing that Watchguards and SonicWalls do all the time.
    > DUAL-WAN with failover (not load balancing).
    >
    > Now, what happens, is after a period of time, something in IPTables gets
    > confused.


    So, if Watchguard can do it reliably, it *can't* be iptables that gets
    confused.

    Watchguard *is* iptables.

    So, obviously it is *you* who can't get it to work. Not a biggie, not
    everyone can be good at doing iptables. What I don't understand is why
    you try to set it up despite your lack of knowledge anyway, and then
    blame iptables for not working. You would have been better off by
    selling a firewall appliance to your customer.

    Mart

    --
    "We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

  3. Re: The oh so stable Linux

    On Mon, 20 Oct 2008 20:48:15 +0200, Mart van de Wege wrote:

    > So, if Watchguard can do it reliably, it *can't* be iptables that gets
    > confused.
    >
    > Watchguard *is* iptables.


    No, it's not. Watchguard uses their own version of iptables. I know this
    because I asked them.

  4. Re: The oh so stable Linux

    On 2008-10-20, Mart van de Wege wrote:
    >
    > And that it takes a special kind of idiot to write iptables scripts by
    > hand when they're not a dedicated firewall specialist, instead of
    > handing that task over to a frontend, either in the form of a
    > graphical designer like fwbuilder, or a dedicated appliance like a
    > Watchguard.


    Oy!

    I take offence at that. I'm no iptables "dedicated firewall specialist",
    yet I've built my own firewall rules for my openwrt WRT54GL router. It's
    not that hard if you study how other products (such as shorewall) do the
    job. All it takes is research and testing.

    I'd accept your comments if you are talking about a mission critical
    system with thousands of clients, but.....

    --
    Regards,

    Gregory.
    Gentoo Linux - Penguin Power

  5. Re: The oh so stable Linux

    Gregory Shearman writes:

    > On 2008-10-20, Mart van de Wege wrote:
    >>
    >> And that it takes a special kind of idiot to write iptables scripts by
    >> hand when they're not a dedicated firewall specialist, instead of
    >> handing that task over to a frontend, either in the form of a
    >> graphical designer like fwbuilder, or a dedicated appliance like a
    >> Watchguard.

    >
    > Oy!
    >
    > I take offence at that. I'm no iptables "dedicated firewall specialist",
    > yet I've built my own firewall rules for my openwrt WRT54GL router. It's
    > not that hard if you study how other products (such as shorewall) do the
    > job. All it takes is research and testing.
    >
    > I'd accept your comments if you are talking about a mission critical
    > system with thousands of clients, but.....


    Yes, well, there is a difference between writing iptables rules by
    hand on *your* WRT54GL, and doing it on a customer's firewall.

    The first counts as development. The second is stupid.

    Mart

    --
    "We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

  6. Re: The oh so stable Linux

    On 2008-10-21, Erik Funkenbusch claimed:
    > On Tue, 21 Oct 2008 10:06:17 +0200, Mart van de Wege wrote:
    >
    >>> Nobody has yet been able to provide a viable reason why a solution that
    >>> works for anywhere from 1 day to 2 weeks then randomly starts failing could
    >>> be anything other than a bug in the kernel.
    >>>
    >>> Are you going to provide a plausible explanation?

    >>
    >> Yes.
    >>
    >> You're incompetent.

    >
    > In other words, you can't even come up with a plausible theory.


    Plausible theory? I thought "you're incompetent" settled that one.

    > Didn't think so.


    How can somebody provide a "plausible explanation" for something that
    they don't believe happened? Am I supposed to explain alien vistations
    when I think they fall completely outside the realm of reality? Am I
    supposed to explain why people believe kook theories, like GWB getting
    ready to declare martial law and take over the country, when I know
    them to be kook theories?*

    Maybe you can provide a "plausible explanation" for why you had trouble
    with the setup you created, using tools that others use every day,
    24/7, without running into the problems you claim to have had. But I
    certainly can't when I believe it's either not true, or it's explained
    perfectly with "you're incompetent".

    * The same types of kooks said the same types of things about Bubba
    Clinton, and pointed to the year 2000 and the Y2K "bug" as proof. I
    work with a retard that actually stored rations and water (and
    probably weapons) in his basement because he was convinced Clinton
    was going to declare martial law on 12/31/99.

    --
    A crash reduces
    Your crap Windows computer
    To a simple stone

  7. Re: The oh so stable Linux

    On Tue, 21 Oct 2008 10:06:17 +0200, Mart van de Wege wrote:

    >> Nobody has yet been able to provide a viable reason why a solution that
    >> works for anywhere from 1 day to 2 weeks then randomly starts failing could
    >> be anything other than a bug in the kernel.
    >>
    >> Are you going to provide a plausible explanation?

    >
    > Yes.
    >
    > You're incompetent.


    In other words, you can't even come up with a plausible theory.

    Didn't think so.

  8. Re: The oh so stable Linux

    Erik Funkenbusch wrote:

    > On Tue, 21 Oct 2008 10:06:17 +0200, Mart van de Wege wrote:
    >
    >>> Nobody has yet been able to provide a viable reason why a solution that
    >>> works for anywhere from 1 day to 2 weeks then randomly starts failing
    >>> could be anything other than a bug in the kernel.
    >>>
    >>> Are you going to provide a plausible explanation?

    >>
    >> Yes.
    >>
    >> You're incompetent.

    >
    > In other words, you can't even come up with a plausible theory.


    Looks very plausible to me.
    After all, you have proven over and over again that you know next to nothing
    about linux

    > Didn't think so.


    Difficult with such a tiny brain
    --
    99% of lawyers give the rest a bad name.


  9. Re: The oh so stable Linux

    On Oct 21, 11:38 am, Erik Funkenbusch
    wrote:
    > On Tue, 21 Oct 2008 10:06:17 +0200, Mart van de Wege wrote:
    >
    > >> Nobody has yet been able to provide a viable reason why a solution that
    > >> works for anywhere from 1 day to 2 weeks then randomly starts failing could
    > >> be anything other than a bug in the kernel.

    >
    > >> Are you going to provide a plausible explanation?

    >
    > > Yes.

    >
    > > You're incompetent.

    >
    > In other words, you can't even come up with a plausible theory.
    >
    > Didn't think so.


    I for one can think of a fair number. Pick the one(s) most relevant,
    as you like.

    [1] The hardware is marginal or outright suspect, or is plugged
    into marginal or suspect power. A simple voltmeter should be of
    assistance here, to ensure proper power supply operation. An
    oscilloscope might be even better, though is probably overkill.

    [2] Congratulations, you've found a kernel bug that has eluded
    the best and the brightest. Things happen, and even thousands
    of pairs of eyes might miss what's right in front of their respective
    noses (though the probability is low). Remember the
    four-card Mindcraft/spinlock bug, for example, that was fixed in the
    2.4
    release cycle.

    [3] Kernel changes can introduce bugs, especially if tools
    such as iptables aren't upgraded with.

    [4] Ditto for config changes. Hey, things happen.

    [5] If a kernel is rebuilt but a module not rebuilt, the
    module may not load properly and/or function properly
    after reboot. This is the closest thing to "incompetence"
    that I for one can find, and is easily rectified by starting
    from scratch with "make mrproper". (Be sure to save
    the configuration file /usr/src/linux/.config first, if necessary,
    and have a LiveDisc handy. One might have to clear out
    /lib/modules/ as well.)

    [6] If a kernel is rebuilt with a module *deleted* (since the
    builder thinks it's no longer necessary) but doesn't update
    /lib/modules/ properly, I strongly suspect strange
    things can happen if that module is loaded.

    [7] One might be running on different hardware than that
    tested -- for example, ARM versus intel.

    [8] The solution may be incompatible with Microsoft solutions.

    Accusations of incompetence need to be far more specific,
    if they're going to stick.

  10. Re: The oh so stable Linux

    On Tue, 21 Oct 2008 12:08:33 -0700 (PDT), The Ghost In The Machine wrote:

    >> In other words, you can't even come up with a plausible theory.
    >>
    >> Didn't think so.

    >
    > I for one can think of a fair number. Pick the one(s) most relevant,
    > as you like.


    Ok...

    > [1] The hardware is marginal or outright suspect, or is plugged
    > into marginal or suspect power. A simple voltmeter should be of
    > assistance here, to ensure proper power supply operation. An
    > oscilloscope might be even better, though is probably overkill.


    It's a brand new Dell 2950III with dual Broadcom Gigabit NIC's and a
    seperate PCI-e Quad port e1000. I've trid both the onboard and Intel
    ports. Same issue.

    The power runs through a Liebert nFinitiy UPS that does power conditioning,
    and it's got dual power supplies.

    > [2] Congratulations, you've found a kernel bug that has eluded
    > the best and the brightest. Things happen, and even thousands
    > of pairs of eyes might miss what's right in front of their respective
    > noses (though the probability is low). Remember the
    > four-card Mindcraft/spinlock bug, for example, that was fixed in the
    > 2.4 release cycle.


    First, this is Centos 5.2, using a relatively old kernel that is supposed
    to be rock solid. 2.6.18-92.1.13.el5. I don't know whether the problem is
    related to a Red Hat patch or the kernel itself.

    > [3] Kernel changes can introduce bugs, especially if tools
    > such as iptables aren't upgraded with.


    I've done full yum updates. The problem has pesisted through many kernel
    revisions.

    > [5] If a kernel is rebuilt but a module not rebuilt, the
    > module may not load properly and/or function properly
    > after reboot. This is the closest thing to "incompetence"
    > that I for one can find, and is easily rectified by starting
    > from scratch with "make mrproper". (Be sure to save
    > the configuration file /usr/src/linux/.config first, if necessary,
    > and have a LiveDisc handy. One might have to clear out
    > /lib/modules/ as well.)


    i didn't build the kernel, i'm using stock kernels and multiple versions.
    I doubt Centos would be that clumbsy.

    > [6] If a kernel is rebuilt with a module *deleted* (since the
    > builder thinks it's no longer necessary) but doesn't update
    > /lib/modules/ properly, I strongly suspect strange
    > things can happen if that module is loaded.


    unlikely, i'm using standard functionality.

    > [7] One might be running on different hardware than that
    > tested -- for example, ARM versus intel.


    It's Intel.

    > [8] The solution may be incompatible with Microsoft solutions.


    Uhh.. what? How would that stop the PBX itself, running on the firewall
    box, from connecting to the outside world?

    > Accusations of incompetence need to be far more specific,
    > if they're going to stick.


    All they're doing is burying their head in the sand. It's impossible for
    it to be Linux's fault, so I must be incompetant or lying in their eyes.
    Nevermind the fact that various newsgroups are filled to the brim with
    people encountering problems with Linux.

  11. Re: The oh so stable Linux

    Erik Funkenbusch writes:

    > On Tue, 21 Oct 2008 10:06:17 +0200, Mart van de Wege wrote:
    >
    >>> Nobody has yet been able to provide a viable reason why a solution that
    >>> works for anywhere from 1 day to 2 weeks then randomly starts failing could
    >>> be anything other than a bug in the kernel.
    >>>
    >>> Are you going to provide a plausible explanation?

    >>
    >> Yes.
    >>
    >> You're incompetent.

    >
    > In other words, you can't even come up with a plausible theory.
    >
    > Didn't think so.


    Oh, I can think of plenty of plausible theories. But unless you give
    more details on your configuration, none of them are worth a damn.

    Except the theory that you're incompetent. *That* you have proven many
    times before.

    Occam's Razor, and all that.

    Mart

    --
    "We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

  12. Re: The oh so stable Linux

    After takin' a swig o' grog, The Ghost In The Machine belched out
    this bit o' wisdom:

    > On Oct 21, 11:38 am, Erik Funkenbusch
    > Accusations of incompetence need to be far more specific,
    > if they're going to stick.


    How about claims of competence?

    --
    You can't fall off the floor.

  13. Re: The oh so stable Linux

    After takin' a swig o' grog, Erik Funkenbusch belched out
    this bit o' wisdom:

    > On Tue, 21 Oct 2008 12:08:33 -0700 (PDT), The Ghost In The Machine wrote:
    >
    >> Accusations of incompetence need to be far more specific,
    >> if they're going to stick.

    >
    > All they're doing is burying their head in the sand. It's impossible for
    > it to be Linux's fault, so I must be incompetant or lying in their eyes.
    > Nevermind the fact that various newsgroups are filled to the brim with
    > people encountering problems with Linux.


    How many petabytes is "filled to the brim"?

    --
    Schlattwhapper, n.:
    The window shade that allows itself to be pulled down,
    hesitates for a second, then snaps up in your face.
    -- Rich Hall, "Sniglets"

  14. Re: The oh so stable Linux

    After takin' a swig o' grog, Sinister Midget belched out
    this bit o' wisdom:

    > How can somebody provide a "plausible explanation" for something that
    > they don't believe happened? Am I supposed to explain alien vistations
    > when I think they fall completely outside the realm of reality? Am I
    > supposed to explain why people believe kook theories, like GWB getting
    > ready to declare martial law and take over the country, when I know
    > them to be kook theories?*


    Been to a U.S. airport lately?

    --
    File cabinet:
    A four drawer, manually activated trash compactor.

  15. Re: The oh so stable Linux

    On Oct 21, 12:34 pm, Erik Funkenbusch
    wrote:
    > On Tue, 21 Oct 2008 12:08:33 -0700 (PDT), The Ghost In The Machine wrote:
    >
    > >> In other words, you can't even come up with a plausible theory.

    >
    > >> Didn't think so.

    >
    > > I for one can think of a fair number. Pick the one(s) most relevant,
    > > as you like.

    >
    > Ok...
    >
    > > [1] The hardware is marginal or outright suspect, or is plugged
    > > into marginal or suspect power. A simple voltmeter should be of
    > > assistance here, to ensure proper power supply operation. An
    > > oscilloscope might be even better, though is probably overkill.

    >
    > It's a brand new Dell 2950III with dual Broadcom Gigabit NIC's and a
    > seperate PCI-e Quad port e1000. I've trid both the onboard and Intel
    > ports. Same issue.


    The specs suggest dual onboard Boardcom NetXtreme 5708s.
    I am not familiar enough with this hardware to criticize, though
    I do wonder why one needs additional networking cards (unless
    you were trying to work around the dropout problem, which is
    admittedly quite plausible).

    >
    > The power runs through a Liebert nFinitiy UPS that does power conditioning,
    > and it's got dual power supplies.


    Won't do much good if that Liebert doesn't supply sufficient juice.
    While that's unlikely, I'd still check pro forma both the input to
    the Blade and the internal +5, -5, +12, and -12 busses, or whatever
    voltages they're supposed to be (I swear the microprocessers switch
    voltages every year :-) ). Check both DC and AC (for ripple);
    granted I'm nowhere near expert but somebody can probably find
    a good spec for maximum tolerable RMS voltages on the internal bus.

    >
    > > [2] Congratulations, you've found a kernel bug that has eluded
    > > the best and the brightest. Things happen, and even thousands
    > > of pairs of eyes might miss what's right in front of their respective
    > > noses (though the probability is low). Remember the
    > > four-card Mindcraft/spinlock bug, for example, that was fixed in the
    > > 2.4 release cycle.

    >
    > First, this is Centos 5.2, using a relatively old kernel that is supposed
    > to be rock solid. 2.6.18-92.1.13.el5. I don't know whether the problem is
    > related to a Red Hat patch or the kernel itself.


    I'd switch to 2.6.19 on general principles but would have to dig for
    the
    specifics on that version. The "el5" looks like some sort of Centos
    patch,
    and the 2.6.19 changelogs do mention an RHEL5 bug, which is apparently
    elicited when a large number of fragmented packets are fed into the
    kernel.
    The fix for that problem may have caused yours.

    http://www.kernel.org/pub/linux/kern...angeLog-2.6.19

    >
    > > [3] Kernel changes can introduce bugs, especially if tools
    > > such as iptables aren't upgraded with.

    >
    > I've done full yum updates. The problem has pesisted through many kernel
    > revisions.


    Then either *all kernels* have this dropout bug, or you're going to
    have to look elsewhere for the bug (which is admittedly possible,
    depending on how your PBX solution is structured -- I for one would
    have to dig and frankly don't know what apps run on an openbox
    PBX anyway).

    >
    > > [5] If a kernel is rebuilt but a module not rebuilt, the
    > > module may not load properly and/or function properly
    > > after reboot. This is the closest thing to "incompetence"
    > > that I for one can find, and is easily rectified by starting
    > > from scratch with "make mrproper". (Be sure to save
    > > the configuration file /usr/src/linux/.config first, if necessary,
    > > and have a LiveDisc handy. One might have to clear out
    > > /lib/modules/ as well.)

    >
    > i didn't build the kernel, i'm using stock kernels and multiple versions.
    > I doubt Centos would be that clumbsy.


    Hard for me to say; I don't use Centos myself.

    >
    > > [6] If a kernel is rebuilt with a module *deleted* (since the
    > > builder thinks it's no longer necessary) but doesn't update
    > > /lib/modules/ properly, I strongly suspect strange
    > > things can happen if that module is loaded.

    >
    > unlikely, i'm using standard functionality.


    True; since you're not building kernels this doesn't apply to you.

    >
    > > [7] One might be running on different hardware than that
    > > tested -- for example, ARM versus intel.

    >
    > It's Intel.


    OK.

    >
    > > [8] The solution may be incompatible with Microsoft solutions.

    >
    > Uhh.. what? How would that stop the PBX itself, running on the firewall
    > box, from connecting to the outside world?


    The outside world uses Microsoft Windows, in case you've not
    noticed. ;-)
    Whether that's relevant to your app is unclear, of course -- PSTN
    should
    in theory work on anything from old black candlestick phones to next
    generation
    Bluetooth-aware smart units. However, I don't know how a Blade/PBX
    gets phonecall audio.

    >
    > > Accusations of incompetence need to be far more specific,
    > > if they're going to stick.

    >
    > All they're doing is burying their head in the sand. It's impossible for
    > it to be Linux's fault, so I must be incompetant or lying in their eyes.
    > Nevermind the fact that various newsgroups are filled to the brim with
    > people encountering problems with Linux.


    Impossible? Hardly. My Kayak drops off the net all the time,
    which is one reason I rarely use it (of course, it only has an 833 MHz
    processor anyway, which is another reason I rarely use it :-) ).
    Haven't gotten around to fiddling with the driver (I don't remember
    what card it uses anyway), but clearly there's both a hardware and a
    Linux problem involved -- hardware because it keeps dropping out
    (and fortunately it does elicit a rather cryptic but nevertheless
    reasonably
    visible message, presumably because the driver is seeing something it
    doesn't like from the NIC, when it fails), and Linux because it can't
    recover
    by resetting the hardware after some sort of watchdog timeout, or
    otherwise dealing with the issue; I have to manually ifconfig down
    then ifconfig up the interface, as I recall.

    Were I all that concerned I could put in a daemon that checks for
    a functioning network and bounces ifconfig if it finds any problems,
    but clearly that's a workaround, not a fix.

  16. Re: The oh so stable Linux

    On Tue, 21 Oct 2008 14:38:12 -0400, Erik Funkenbusch wrote:

    > On Tue, 21 Oct 2008 10:06:17 +0200, Mart van de Wege wrote:
    >
    >>> Nobody has yet been able to provide a viable reason why a solution
    >>> that works for anywhere from 1 day to 2 weeks then randomly starts
    >>> failing could be anything other than a bug in the kernel.
    >>>
    >>> Are you going to provide a plausible explanation?

    >>
    >> Yes.
    >>
    >> You're incompetent.

    >
    > In other words, you can't even come up with a plausible theory.


    Mart already has a plausible theory, I believe him, and all the Linux
    advocates here will believe him as well because Marts argument was well
    reasoned and well written..

    Mart said you're a lying, and incompetent Linux admin, and it's true.

    Your forte is as a barely plausible Linux user who NEVER has any luck
    with Linux.

    But don't despair Erik, even tho all the Linux advocates laugh at you,
    and your fantasy scenarios, you're in the top 10% as far as Wintroll fake
    Linux users go.

    I'm sure many of your posts have caused Windows users on Cola, who know
    *nothing* about Linux to wonder why anyone would use Linux, until they
    read the following rebuttals.

    And you can take that to your boss!

    >
    > Didn't think so.


    Yeah, yeah.



    --
    Linux full time, on the desktop, since August 1997

  17. Re: The oh so stable Linux

    On Tue, 21 Oct 2008 15:34:11 -0400, Erik Funkenbusch wrote:


    > All they're doing is burying their head in the sand. It's impossible for
    > it to be Linux's fault, so I must be incompetant or lying in their eyes.
    > Nevermind the fact that various newsgroups are filled to the brim with
    > people encountering problems with Linux.


    That idiot HPT is attempting the very same tactic in my printer thread.
    Despite web pages posted as proof he is still scrambling around to
    save the mother ship Linux.

    It's truly sick.

    --
    Moshe Goldfarb
    Collector of soaps from around the globe.
    Please visit The Hall of Linux Idiots:
    http://linuxidiots.blogspot.com/
    Please Visit www.linsux.org

+ Reply to Thread