Comment Gartner... (Score 2) 207
Gartner gives the numbers the group contracting the study want.
Toshiba: large hole in the bottom where the air gets sucked in and then blown against a heat sink on with tiny fins. dust gets sucked in and blown against the heat sink where it gets stuck and when that dust layer gets thick enough, the only way to clean it is to rip the whole laptop apart. It's almost as if they designed the laptop to wear out after a year or two passes.
Right, you would put Telefonica's pubic key into the authorized_keys on each device file but never the local device public key. The simple fact is that unless they are far more stupid than the article suggests this cannot be used to break into the routers.
Isn't TFS supposed to explain what it's talking about?
1. Why does a router have public-facing SSH? The reason to use SSH on your router is to configure it, over a wired connection from your PC, innit?
2. Why does a router come with SSH keys already installed? Don't you generate your own SSH keys?
Given that they were deployed by one particular provider (Telefónica de España in this case) they probably requested a special firmware from the vendor for their CPE to allow remote management. And then did a bad job of keeping the master key safe (by putting a copy of it on 250,000+ devices). And then the vendor used it elsewhere, too.
Honestly, after the Carna botnet, does anyone think the internet isn't a raging sea of completely compromised devices?
I don't think so. The pubic and private keys are only good for outgoing connections and not incoming.
They could do that, but then Telefonica wouldn't be able to buy the routers from China for $15 each (non wholesale price for the exact model Telefonica had in my house when I lived in Spain).
I strongly suggest avoiding Lenovo completely. They already fail to boot if there is an unrecognized wifi card ( I had to hack the BIOS) and for their latest move towards evilness refuse to charge both third party and batteries the system detects as too old.
Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies.
Speaking of outright lies... where is your proof that only a minority of people are unhappy about SystemD?
You do realize RedHat (the distro running systemd for the longest) has reported their subscriptions going up for the last several quarters? Meanwhile we have people who are making a lot of noise about leaving but never actually do. (Distrowatch is showing interest in *BSD as dropping) We have a Debian fork claiming to be a bunch of "veteran admins" without naming any of them and a mailing list of people who like to argue more than they like actually doing anything. So where are all of these upset people going?
Let's examine our current environment: Slashdot.
Here there are more people who are deeply against SystemD than there are for SystemD. If you look at the arguments against, there are numerous well-reasoned arguments that nobody from the SystemD has even begun to address.
Well reasoned like the post I was replying to? It managed a "Score 5: Informative" despite not having any arguments that were actually true.
The Slashdot echo chamber is what annoys me the most about all of this. I see posts like "SystemD is Monolithic" (it isn't) "SystemD includes an NTP and DHCP server in PID 1(They are optional and don't run as PID 1). Or my all time favorite: "SystemD" is designed for desktops and makes server administration harder" When the reality is that SystemD was designed with some of the more complicated server setups in mind and the speed improvement on the desktop was mostly an accidental byproduct. The only actual valid complaint I have seen so far is about the binary logs but they are easy to bypass and even with journald doing mostly nothing, the whole thing uses less RAM and disk space than the init system it is replacing.
If you look at the arguments for, they do not seem terribly convincing, such as "this is a better way" or "startup is faster in the best case".
Naturally, this is plumbing and boring by nature. "Works best for this case" is actually a good reason for doing it In the meantime, the old system was a bug ridden mess. I mean really, I had until recently some servers that need a partial filesystem mount followed the network followed by GlusterFS followed by Apache. Care to guess how well that works in a default Debian stable install?
I mean really, even if the damned thing did what it claims to do, the specific implementation is clearly lacking. So I have to ask, why exactly are you so gung-ho for SystemD? Surely you should be gung-ho for a solution, not a specific method. No?
I am not so much pro SystemD as much as I am anti FUD. I am annoyed that I let the slashdot crowd actually made me worry about my future as a Linux admin until I researched for myself what the facts were
Debian switched because they were losing market share on larger systems that the current init system only handles under extreme protest.
What are you talking about? losing market share? larger systems? Which systems? How was market share measured? Show me where the Debian project claims this. You sound like an MBA.
It's right in their "Why SystemD" document. " But the real problems arise on big server setups, where Debian is losing ground because of its antiquated init system. On these systems, you need fine service management, process monitoring, reliable dependencies, complex device setups and proper event handling."
For me, there is only a single mandatory piece that I have a problem with and that is the binary logging but that is easy to bypass even if I can't turn it off. For the rest of the crap such as his DHCP server or his NTP server, I have no plans to install them.
This will not be the end of Linux, it is slightly different and hasn't caused me any headaches server side and a single problem with pulseaudio (permissions problem) on my desktop running Debian testing (my laptop works fine however). It has however saved me once on the server when I accidentally typed "/etc/init.d/networking restart" instead of "nohup
When they spread misinformation? Yes. When they bring up every possible opportunity to tell the whole world how much they hate SystemD? Yes.
What pisses me off is that based on the posts I was seeing here, I started to really worry about my future as a Linux admin but then I looked for myself and discovered just how much misinformation was being passed around here.
Who modded this up?
SystemD has put in jeopardy the entire presence of Linux in the server room:
1: AFIAK, as there have been zero mention of this, SystemD appears to have had -zero- formal code testing, auditing, or other assurance that it is stable. It was foisted on people in RHEL 7 and downstreams with no ability to transition to it.
Formal code testing is pretty much what Redhat brings to the table.
2: It breaks applications that use the init.d mechanism to start with. This is very bad, since some legacy applications can not be upgraded. Contrast that to AIX where in some cases, programs written back in 1991 will run without issue on AIX 7.1. Similar with Solaris.
At worst it breaks their startup scripts, and since they are shell scripts they are easy to fix.
3: SystemD is one large code blob with zero internal separation... and it listens on the network with root permissions. It does not even drop perms which virtually every other utility does. Combine this with the fact that this has seen no testing... and this puts every production system on the Internet at risk of a remote root hole. It will be -decades- before SystemD becomes a solid program. Even programs like sendmail went through many bug fixes where security was a big problem... and sendmail has multiple daemons to separate privs, unlike SystemD.
Do you really understand the architecture of either SystemD or sendmail? Sendmail was a single binary written in a time before anyone cared about security. I don't recall sendmail being a bundle programs but then it's been a decade since I stopped using it precisely because of it's poor security track record. Contrary to your FUD, Systemd runs things as separate daemons with each component using the least amount of privileges needed to do it's job and on top of that many of the network services (ntp, dhcpd) that people complain about are completely optional addons and quite frankly, since they seem designed around the single purpose of Linux containers, I have not installed them. This is a basic FAQ entry on the systemd web site so I really don't get how you didn't know this.
4: SystemD cannot be worked around. The bash hole, I used busybox to fix. If SystemD breaks, since it encompasses everything including the bootloader, it can't be replaced. At best, the system would need major butchery to work. In the enterprise, this isn't going to happen, and the Linux box will be "upgraded" to a Windows or Solaris box.
Unlikely, it is a minority of malcontents who are upset about SystemD who have created an echo chamber of half truths and outright lies. Anyone who needs to get work done will not even notice the transition.
5: SystemD replaces many utilities that have stood 20+ years of testing, and takes a step back in security by the monolithic userland and untested code. Even AIX with its ODM has at least seen certification under FIPS, Common Criteria, and other items.
Again you use the word "monolitic without having a shred of knowledge about how SystemD works.The previous init system despite all of it's testing was a huge mess. There is a reason there were multiple projects that came before SystemD that tried to clean up the horrific mess that was the previous init.
6: SystemD has no real purpose, other than ego. The collective response justifying its existence is, "because we say so. Fuck you and use it." Well, this is no way to treat enterprise customers. Enterprise customers can easily move to Solaris if push comes to shove, and Solaris has a very good record of security, without major code added without actual testing being done, and a way to be compatible. I can turn Solaris 11's root role into a user, for example.
Solaris has already transitioned to it's own equivalent daemon that does roughly what SystemD does.
As for SystemD: It allows booting on more complicated hardware. Debian switched because they were losing market share on larger systems that the current init system only handles under extreme protest. As a side affect of the primary problem it was meant to solve, it happens to be faster which is great for desktops and uses a lot less memory which is good for embedded systems.
So, all and all, SystemD is the worst thing that has happened with Linux, its reputation, and potentially, its future in 10 years, since the ACTA treaty was put to rest. SystemD is not production ready, and potentially can put every single box in jeopardy of a remote root hole.
Riight.. Meanwhile in the real world, none of my desktops or servers have any SystemD related network services running so no root hole here.
You knew the job was dangerous when you took it, Fred. -- Superchicken
