Slashdot Mirror

← Back to Stories (view on slashdot.org)

Red Hat Suffers Massive Data Center Network Outage

Posted by msmash on from the outage-report dept.

An anonymous reader writes: According to multiple reports on Twitter, the Fedora Infrastructure Status page, and the #fedora-admin Freenode IRC channel, Red Hat is suffering a massive network outage at their primary data center. Details are sketchy at this point, but it looks to be impacting the Red Hat Customer Portal; as well as all their repositories (including Fedora, EPEL, Copr); their public build system, Koji; and a whole host of other popular services. There is no ETA for restoration of services at this point.

9 of 85 comments (clear)

  1. DeadHat !! by TechyImmigrant · · Score: 2

    'Nuff said.

    --
    I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    1. Re:DeadHat !! by Anonymous Coward · · Score: 5, Funny

      That's what you get from running systemd in production.

    2. Re:DeadHat !! by courteaudotbiz · · Score: 2, Insightful

      I don't understand all this systemd bashing. I've been working with it for a few months on CentOS 7, and all I can say is that it is easy to work with and until now, it has proven to be very stable. Never had a crash related to systemd.

    3. Re:DeadHat !! by StormReaver · · Score: 2

      I don't understand all this systemd bashing.

      A lot of people don't like change.

      There is one gripe, though, that I can sympathize with, and that's how systemd is expanding to encompass much more than is readily understandable. There may be perfectly good reasons for the expansion, but they're not readily apparent.

      That said, I've been using systemd ever since Kubuntu switched to it, and I haven't had any problems with it. But then, I haven't tried a recursive rm recently.

    4. Re:DeadHat !! by CanadianMacFan · · Score: 3, Insightful

      The problem is that systemd keeps on expanding and that goes against the philosophy of UNIX/Linux where each thing is kept small in scale and does it well. systemd keeps up integrating applications that have worked perfectly for a long time for the philosophy of one person who isn't really well respected in some areas of Linux development.

    5. Re:DeadHat !! by F.Ultra · · Score: 4, Insightful

      Not exactly true. The systemd that you talk about (encompassing applications) are the systemd the project and not systemd the pid 1 (init) application. Each new "application integration" is done via a separate application so the UNIX philosophy still stands. And these are not done in order to match the philosophy of one person (the whole systemd project have lots of developers this day) but are done in order to present a common plumbing layer mostly aimed at container developers at this moment, i.e to present a common set of tools that work and look the same.

  2. Can't they just run ... by fahrbot-bot · · Score: 4, Funny

    ... systemctl restart datacenter

    (Okay, maybe only if systemd ran as PID 2 ...)

    --
    It must have been something you assimilated. . . .
  3. Apps complexity by DrYak · · Score: 2

    But do these "separate application[s]" break if pid 1 is something other than systemd?

    Depends on the applications.

    Boot-loader ? NTP clients ? these aren't deeply interdependent.
    You could very much use these and then run openrc if you want.
    These are just handled by systemd in the sens that these are program who are now developed by people who are on the systemd *project* team.
    At most systemd might leverage boot-loader in the sense that it can more easily send parameters to it for the next boot.

    Though other daemon might be much more interlinked with systemd's (the daemon running at PID 1) job of starting/stopping things.
    (I'm thinking about daemon managing seats, sessions, and starting/stopping hardware).

    These are important as over time, the Linux kernel is starting to go way much more advanced than standard POSIX behaviour.
    Linux kernel, for example, offers cgroup isolation, namespaces, etc. (the facilities which are leveraged by containers such as LXC, Docker, Andbox...) which are definitely useful (separating session in different name-spaces, jailing some daemons in containers, automatically configuring the content of a container state-lessly)
    The older bash-script-based mess of code that used to predate systemd has absolutely zero ability to leverage them.
    SystemD is one rather successful way to deal with those things that wasn't provided by SysVinit.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
    1. Re:Apps complexity by drinkypoo · · Score: 2

      Linux kernel, for example, offers cgroup isolation, namespaces, etc. [...] The older bash-script-based mess of code that used to predate systemd has absolutely zero ability to leverage them.

      This is ignorant at best. Both cgroups and containers can be created and manipulated from the command line. Nobody bothered to do this as a PoC before going off on a tear and creating systemd.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"