Slashdot Mirror
Linux Kernel 3.18 Reaches End of Life (softpedia.com)
prisoninmate quotes a report from Softpedia: Linux kernel 3.18.48 LTS is here and it's the last in the series, which was marked for a January 2017 extinction since mid-April last year. According to the appended shortlog, the new patch changes a total of 50 files, with 159 insertions and 351 deletions. It brings an updated networking stack with Bluetooth, Bridge, IPv4, IPv6, CAIF, and Netfilter improvements, a couple of x86 fixes, and a bunch of updated USB, SCSI, ATA, media, GPU, ATM, HID, MTD, SPI, and networking (Ethernet and Wireless) drivers. Of course, this being the last maintenance update in the series, you are urged to move to a newer LTS branch, such as Linux kernel 4.9 or 4.4, which are far more secure and efficient than Linux 3.18 was. But Linux 3.18 appears to be used by Google and other vendors on a bunch of Android-powered devices, and even some Chromebooks use Linux kernel 3.18 on Chrome OS, so here's what the kernel developer suggests you do if you can't upgrade. "If you are _stuck_ on 3.18 (/me eyes his new phone), well, I might have a plan for you, that first involves you yelling very loudly at your hardware vendor and refusing to buy from them again unless they cut this crap out. After you properly vent to them, drop me an email and let's see what we can come up with, you aren't in this sinking ship alone, and it's obvious your vendor isn't going to help out," said Greg Kroah-Hartman in the mailing list announcement.
First we lose Richard Hatch; now it's Linux kernel 3.18. Man...
#DeleteChrome
Last I checked the Linux kernel had 4672 bugs. Something is clearly wrong with the release process. Imagine if it took an airline 1-2 years to return your lost luggage?
I like articles that use real words (ones in the dictionary). Acronyms for technical terms is one thing, and brand names as well, but this is neither.
My phone is stuck on 3.4.42. Thanks Google (and Lenovo now I guess)
I suppose it's still supported though, until April 2017
Linux is open source. Support doesn't have to come from kernel.org. Linaro are supporting 3.18 until December 2018. There may be other vendors committing to maintaining the kernel with at least security fixes for longer.
This is what I come to slashdot for. The intelligent and well articulated discussions about news for Nerds and Stuff that Matters.
That's not a fair comparison. Releases are done very differently now. Also version schemes of old kernels don't match version schemes since 3.0, so that might mislead younger people.
Also the 2.4 kernel was the one that just wouldn't die. It was maintained until 2011. I guess 2.6 was just too drastic of a change for some folks.
They are still supporting ATM? I am really curious because I actually wrote ATM code. Fifteen years ago. Both device drivers and stack code. Great stuff, but that is ancient history. Can anyone tell what ATM has done in the last decade? Thanks!
A dingo ate my sig...
Most distros will support their long-term kernels well after kernell.org moves on. For example, Red Hat Enterprise, released in 2007, with kernel 2.6.18, has some support from Red hat until November 30, 2020.
RHEL 6,RHEL 7, and their debranded CentOS twins provide important security updates for ten years. I use CentOS 6, kernel 2.6.32, supported from 2010 to 2020. I'll probably switch to CentOS 7 (or 8) in 2018 or so.
The second sentence is missing the version number. That should say:
For example, Red Hat Enterprise 5, released in 2007 with kernel 2.6.18, has some support from Red Hat until November 30, 2020.
For Red Hat 6 (kernel 2..32), they'll soon stop adding support for new hardware and it'll be security fixes and important bugs only. That may work for me until 8 is released. I prefer not to replace the OS more than once every ten years or so, so I'de prefer to skip version 7.
The Linux Colonel
This is what I come to slashdot for. The intelligent and well articulated discussions about news for Nerds and Stuff that Matters.
I prefer the calm, objective, well-reasoned debate in which all valid viewpoints are welcome and represented, and there is no prevailing group-think, ad hominems, or fanboyism. That's why *I* come to Slashdot.
The best is simply the best.
"yelling very loudly at your hardware vendor and refusing to buy from them again unless they cut this crap out"
3.18 was released slightly over 2 years ago (7 Dec 2014). It went LTS 3 months later (2015/3/11). At the time, "it will be supported with patches for at least two more years from today." Now it's gone, less than 2 years later. And, 2 years isn't "long term" by any reasonable definition to begin with. Don't yell loudly at anyone who used it, yell loudly at Greg Kroah-Hartman and the other kernel maintainers for over-promising and under-delivering, who think 2 years is a long time and won't even keep that commitment. 3.16 (LTS) is projected to go to 2020, when it's 5 1/2 years old (kudos to Ben Hutchings, who's a bit more realistic about what "long term" means).
(and of course, anyone the size of Google should be able to put their own resource on maintaining a kernel they chose to use for longer if need be, not that they've figured out how to keep Android devices up-to-date anyway)
"National Security is the chief cause of national insecurity." - Celine's First Law
Linux xxx.yyy.com 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I'm operating at the bottom of the ocean and everything still works. :-)
What's the process for determining what version of Linux Slashdot runs on?
> so I don't have to think about security patches. ...
> cPanel/WHM
If you care *at all* about security and are running Cpanel or even worse Plesk, you probably want to make to turn off SuExec. Both php suexec and cgi suexec. Basically what suexec does is give all visitors to your site *permission* to change all of your files. In all likelihood one of your PHP scripts gives them the *mechanism* to do so.
Suexec was designed for servers with a thousand hosting customers who have $20/year hosting accounts all on the same server. It has some marginal utility in such a case, protecting customers from each other, though the documentation opens with a warning from the suexec developers "you shouldn't even consider enabling suexec unless you thoroughly understand the security risks". It can't possibly do any good whatsoever on a dedicated server running one site (unless you're planning to attack yourself).
Unfortunately, Cpanel made it easy to enable, after a developer there failed to read even the first few sentences of the suexec documentation.
If it's enabled, your file permissions amd owmership are a little screwed up. Files written by the web server are owned by your login and chmod 644. (That appears to make them unwriteable by visitors, but remember suexec basically bypasses permissions). After disabling suexec, files which *should* be writable by scripts need to be chmod 666, marking those files (and *only* those files) as writeable.
https://www.bing.com/images/se...
I prefer my dictionaries to be descriptive not prescriptive.
I can tell by your Nick that your an intelligent, smooth-spoken and reasonable individual.
It seems my post was unclear. It *may* also be that you are so comfortable with your current knowledge that you are somewhat resistant to unfamiliar ideas. If that's so, that's fine. I've made a LOT of money over the last 20 years cleaning up rooted servers run by people who thought they understood this issue.
> ITK. ... This allows each account to have permissions of 0600
Whether you do suexec using mod_suexec, php_suexec, mod_ruid2, or mpm_ik doesn't really matter, either way the *effective* permissions are 666. How is it that a script (a visitor) can write to a file chmod 600, or even read it? It's because with mpm_itk, all visitors can read and write ALL files. Let that sink in for a minute - there's no difference in permissions between visitor_log.txt (which should be writeable) and .htaccess or .htpasswd (which shouldn't be). They all have the *same* permissions. visitor_log.txt is writeable, even with 600 permissions, because ALL files are writeable, regardless of permissions.
The alternative, what the documentation suggests that you do if you're not a security expert, is to have only the files that *need* to be writeable as 666, and all others 644, so they are not writeable. You do that by running Apache in its default configuration, by simply not adding mod_suexec or mpm_itk to make your chmod 600 files writeable.
Don't let 'em get to you. After all, by responding to it you let it know that it got your attention. It doesn't deserve the cheap thrill.
Who cares about Android updating beyond 3.18 if they aren't even updating the patches within 3.18?
Assume the OS you get when you buy your Android device is going to be the last update for it ever.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I mean, once you get to 2.99.99 then what? /p>
Then you get 2.100. Quite simple really.
Who cares about EOL, when the firmware of your device includes a fixed kernel image which won't be updated, ever?
I mean, my current Android phone (using Marshmallow) employs a kernel 3.4.42, released on April 2013. The current version of the 3.4 branch is 3.4.113 (source), released on October 2016. I don't know if there are any critical (security, performance) improvements from 3.4.42 to 3.4.113, but I simply don't care becase I know the manufacturer won't publish an updated version of the firmware with a recent kernel. If a serious kernel security bug appears and it is solved in a new kernel version, it won't be solved in my device. The situation is way better when you consider Linux desktop distributions, but still...
What I mean is that for at least 99% of the people, the kernel is an atomic part of the firmware of their device (phone) and they won't bother about updating it. With this in mind, there should be no recommendations to the final users ("yelling very loudly" because your Android phone employs a given kernel version, haha), EOL is only significant for upgradeable systems. Not even phone designers need to worry about using LTS: they know they will never update their kernel.
So basically you remember the present?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Yes, Enterprise Linux 6 (Red Hat, CentOS, Scientific Linux, Oracle, others) is still supported, and run 2.6.32
The rapid change in kernels with incompatibilities between versions has become a big problem, especially in business settings. Software like VMware is unlikely to work after upgrades, and not just because kernel modules have to be recompiled, but because they won't recompile.
Then the business choice becomes "don't upgrade the kernel", and choosing distros that won't upgrade them and only backport critical patches.
Something happened with the transition from 2.4 to 2.6. When distros started shipping with 2.6, linux stopped being the answer to using old hardware. It fell as slow and sluggish as any other OS would (except maybe DOS). My fathers Celeron 300A was a great illustration of such, as well as the Compaq laptop my nephew once owned.
I think the bigger kicker was 2.6 wasn't drop in compatible to 2.4. A lot of things changed (like linuxthreads->NPTL) and with it, so did the libraries that shipped with it. Old applications (Kylix) were dead in the water
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
It's your server, you can of course do what you want. I'm just giving you information about how 90% of malware infections occur on web sites. For twenty years I've been remediating compromised servers, and this is how it normally happens.
> From there it will fork off a process and setuid/setgid's the process to the VirtualHost's defined uid/gid .. which has full permission to change any and all the files on the site.
> It's important to note that all SSH, and FTP daemons work in a very similar way.
Do you run your FTP server open with no password required?
Probably not, that would be stupid. FTP can be used to change all your files, so you require a login.
Do you run your SSH server open with no password required?
Probably not, that would be stupid. SSH can be used to change all of your files, so you require a log in.
Do you run your web server wide open with no password required?
Yes! No login required, yet you set it up to have permission to change all of your files. That would be stu...