The issue is that third-party packages depend on particular versions of Python, and you thus can't change the default version of Python between point releases.
That is, when 7.0 was released, Python 1.5.2 was the clear choice, given how little Python 2.x code existed at that point. So for the entire 7.x series, Red Hat needed to stick with Python 1.5.x as the default version. Now with the 8.x series, Python 2.2.x is the default version.
This is Red Hat's policy, and is quite sensible when you think about their userbase. They did a similar thing with Sendmail: 7.x used 8.11.x, even though 8.12 came out in the middle of the 7.x series, 7.2 and 7.3 both stuck with 8.11, because there were substantial changes with 8.12 (like no longer requiring that everything run as root...)
The goal is to make transitions within a major release as painless as possible, not only for us dumb sysadmins but also for third-party software developers: anything built against 7.0 should ideally run against 7.3 without so much as a recompile. Less ideally, you shouldn't have to port it but just rebuild it.
I'm pretty sure Debian does tons more testing with major releases than you do.
Er, no.
That is, not with in-house or third-party apps deployed on the server.
<VERYLITTLEWORDS>This may shock you, but sometimes people run software on computers. Sometimes even software that doesn't ship with the operating system.
If you upgrade from one Debian stable (Potato, say) to another (like Woody), many, many underyling software versions change.
These changes are necessary: after all, if the software versions didn't change, there wouldn't be a new release of the distribution, would there? But sometimes these changes break things. Changing from PHP 3 to PHP 4 sure breaks things. Upgrading from 4.0.6 to 4.1.x breaks things, too. Just ask the HORDE people.
Some people use many features of the operating system, and have a lot of custom code running on their servers. Often this is in addition to running a full compliment of basic services.
Testing the local code can take a long time, if there's a lot of it. Especially if it depends heavily on features (or even bugs!) of its development language. Perl tends not to break things, but even that happens sometimes.
The OS isn't the only piece that needs to be tested. Modern Linux works pretty much out-of-the-box in that regard. But that's hardly the only thing to test.</VERYLITTLEWORDS>
You've never worked in a large production environment, have you?
Seriously, if you can't handle the 1 year (6 + 6 months) upgrade cycle, then just use Debian stable. You really need to explain that unfounded pot shot at Debian, which is very stable, and doesn't force you to reinstall at all... just keep up to date with the security patches, and you shouldn't have to upgrade in your hardware's lifetime.
Remember when potato came out? Two weeks later (or was it three?) they gave four (or was it six) weeks notice that they were dropping support for the previous Debian stable.
Six weeks is enough for me to evaluate it for personal use, but not to upgrade and test stuff before real-world deployment.
That really pissed me off. I still have customers who use Debian, and I'm happy enough to support them, but I tend not to recommend it for new installations based on that experience.
Oh, and screw H-PU-X , Slowlaris or ACHES, your customers need to demand IRIX!
Gee, I thought you'd say PH-UX. And, actually, I've been on a team responsible for a number of large IRIX systems. The C compiler is really, really picky, but beside that the boxes were great. I hear that several OS revs further in the past there were stability problems, but by 1998 when I got to them, they were rock-solid.
And I understand SGI's supported release policy, too.;-)
Being a consultant, I run what the customers (already) run. Many of my customers do run Linux, and others run various BSD flavors and/or Solaris. I'll run HPUX or AIX when the customers demand it.:-)
But decisions like this do mean that I don't recommend OpenBSD to most customers. (Or Debian, for precisely the same reason.) Isn't it disappointing not to be able to run a technically superior product for reasons like this? I find it disappointing.
Give these guys a break. You had 6 months to test 3.1 and upgrade your boxes from 3.0. If you don't like their policy, use something else. As someone said over a deadly.org, if you want support for older releases, pay someone to provide patches for your system. Whatever you decide to do, stop complaining about something they give away for free.
So I've had six months? Great --- that's about how much time it takes to do testing for a substantial site. Now I'm done and can work on other tasks? Nope, gotta do it again for the new release.
You're right: the problem isn't the amount of notice they give. I was off on that point. However, the amount of time you get isn't enough for me to use OpenBSD at a customer's site. Eighteen months as the lifespan of a product isn't substantial enough, in my opinion.
They think that in two months I can take all of my production servers, build replacement boxes, test them, and put the new boxes into production? When the newest release of the OS isn't even available yet? (Why upgrade to the intermediate release when that'll be dropped as soon as the next one comes out...)
Do they assume I have only one box, or that I don't bother to test things, or that I don't lose any money if the upgrade is perfectly smooth? Do they assume that I won't switch to something with a better support policy (and more notice for dropping support) than what they do?
Do any of these people know anyone who manages systems for a living, or do they only talk to other developers?
The difference is, Scientists will eventually admit they were wrong and their "beliefs" will morph and change over time based on evidence.
This happens surprisingly infrequently with individual scientists. What tends to happen is that the scientists who don't believe the new, well-supported evidence (or its interpretation) retire or die.
Why do you want to work abroad?
on
Working Abroad?
·
· Score: 2
If you're after the cultural experience, you might have to work a lousy job, and not work in the tech industry. The tech recession is pretty much global.
If you think that the financial situation is better elsewhere, it isn't.
So, you need an initrd. No problem provided you can get lilo or grub or whateverelse to find and load it. All your initrd needs to do is to load up your USB modules, mount your root fs off of usb mass storage (/dev/sda1 or whatever weird devfs name you use) and then pivot_root over to it. This is mostly equivalent to an initrd setup for something like a network booting system that uses NFS root or fibre channel or something like that. Any initrd HOWTO will cover setting up an initrd that loads modules and performs configuration to mount the root device that the kernel cannot do on its own.
You missed a step: The initrd has to have about a one-second delay before you attempt to mount the drive from USB. This is because it takes a little while to detect it.
If you make this one change (a little static binary that does 'sleep 1', essentially) to a standard Red Hat 'mkinitrd' ramdisk, you can indeed do USB if your BIOS supports it.
I've done it. It was a @!#$% to debug the first time around: every time I dropped into sash everything worked, but if I didn't drop into sash it didn't.:-)
So, in this case, couldn't someone just as easily generate an md5 sum for the hacked file and put that in the sum file? I know on bsd you have ports which would prevent this, but what about Linux?
This is a solved problem. Red Hat, for example, GPG signs the MD5SUM file. So you can verify that the person who created the MD5SUM was authorized to do so.
am nearly insulted and definitely sick of the exclusion of the other major distros by companies/orgs that distribute tools like this
OK, assuming I've parsed this sentence fragment correctly, you're insulted that somebody has chosen to spend money to solve part of the problem.
(IMHO, RedHat based distros are NOT the standard for linux in general, nor is any single distro).
True enough. So you'd rather they not solve the problem at all if they can't solve it equally for everybody?
In observing this, if the entity does not take time or effort enough to consider other distros, can we consider their opinion to be learned enough to take seriously? (as most know, the differences between distros can be huge, and offering their tools for only two similar distros leaves a very large gap)
Because somebody doesn't solve the problem for everybody, they don't understand the problems other people face? That's a non-sequitur if ever I've seen one... If you understand how huge the differences between Linux distributions is, why do you think that a single tool should be able to be everything to everybody?
It seems to me that these people are spending money to try and solve other people's problems. Given this relatively altruistic gesture (though they have their reasons, I'm sure), why shouldn't they try to get the biggest bang for the buck? If covering those two distributions helps thirty or forty percent of Linux users, that's pretty darned good, if you ask me.
If no, is there an open-standards rating system that could be an equivalent to CIS's? Should there be?
Even if we can take them seriously, why can't there be an open standards rating system for security? I'm not sure there's a connection between these two ideas. But just because their tool to test doesn't work on all Linux distributions doesn't mean that the standard itself can't be applied to other distributions. Did you follow the link, or just decide to shoot your mouth off?
ObDisclaimer: Jay Beale, who wrote the Linux tool, is a good personal friend of mine.
ObFlame: That said, Mr. (or Ms.) Anonymous coward, your above writing demonstrates unclear thinking. Try keeping your sentences to one thought apiece, or at most two logically connected statements. Try to have clear relationships between those sentences so that other people can follow what you're saying.
Kernighan & Pike, "The Unix Programming Environment"
Absolutely a classic --- but somewhat outdated to use as a real intro to Unix. How many gurus do you know who use ed(1) as their primary editor? Also, based as it is upon stock System 7 Unix, there's nothing about networking, etc.
BlatantSelfPromotion: May I recommend Think Unix? It's an updated intro to modern Unix, designed to be read by smart people.
learys academic career was ruined because he and his team did not notice in time that their research had become a political issue.
But the research had become a political issue largely because Leary and Alpert and all their friends went around shouting about how important it was... that, too, was political. And it was obviously threatening to the institution. And they should have known better.
Not that potential research into the same subject isn't blocked today for political reasons. It is, obviously. But Leary's failure to realize that he was already being political sunk his research.
Since Dr. Wallace never offers a meaningful refutation of the Chinese room, let me offer one:
Sure, *you* don't understand Chinese. But the *whole system* understands Chinese. That includes the instruction cards, too. But it's difficult the query the whole system. Situating 'you' as part of the system makes it easy to forget that the human is just one component. (ie it's a red herring, designed to distract and confuse rather than enlighten).
I'm not entirely sure I believe it, as there's got to be a good refutation of this explanation somewhere. But I haven't seen it yet.
Well, I'm so totally unimpressed so far. One out of three, and we have a whole bunch of nonsense.
For starters, AI, neural nets, and brains. We have the assertion that the brain is a computer, and we should really be concerned with the software on the computer, not the state of the neurons.
Even accepting the good doctor's view that the brain is a computer, this is an absurd position. After all, the software is in the brain. It's not like it gets bootstrapped from outside sources. So either the software is built into the whole structure of the brain and we can only learn about it by studying the rules (a la neural nets) or we have to figure out which part of the brain bootstraps the rest of it. Which we'd have to study the wet squishy bits to figure out. Which can best be done with a combination of noninvasive study (MRI, for example) and simulation. Like neural nets.
(The third possibility is that the brain is a computer, but the program is stored on a shared network drive... that is, in a non-material 'soul.' Which would bring us back to Cartesian dualism, God, and a whole bunch of things you'd better reject if you want to work in AI. Not rejecting the notion of God per se, just in the degree of investment in the nonmaterial world in which a being needs to take part...)
Second, academic politics. Dr. Wallace seems to believe in a golden age (that occurred, not coincidentally, just before his professional career) where professors were promoted and supported on the basis of merit.
Right. Anyone who believes in any society at any time in the West that existed without politics is invited to check into the nearest mental institution. To accept the idea of a 'golden age' just tantalizingly out of his reach is pathetic. It's like imagining an era where writers received acclaim based on the quality of their work.
Newsflash: Emily Dickinson's writings were discovered after her death. Everything we read by Melville was written long after his popularity had waned. Any number of great artists were 'discovered' after their deaths. And the most popular writers and artists at any time have been the ones who played the political game successfully. (Personal politics, not governmental politics, of course.) Anyone who's read any medieval philosophy or theology knows that there hasn't been a meritocracy in Western academia for at least eight hundred years.
As far as LSD and politics, it was the professors involved in those experiments (ie Tim Leary) who engaged in politics. And they were bad at it. And they lost. And the substances ended up scheduled. And their academic careers were ruined.
On to part two, to see what he says there. Perhaps it gets better.
So I don't own, or use, Linux. But I've resolved to make Mandrake my distro when and if I decide to give it a try.
Translation: I don't have the slightest idea what I'm talking about. But I've made some decisions.
they're packed with features, lots of options, both GNOME and K desktops, and an easy installation
Translation: I can read the website, and this is what it says.
The fact is, any mainstream general-purpose Linux distribution has both GNOME and KDE, tons of features, and tons of options. While Mandrake's installer is nice, it's not worlds ahead of anybody else's anymore. (OK, it's ahead of Debian's in terms of user-friendliness, but what isn't?) Heck, even the Red Hat's installer is friendly these days.
Nice. I know that you can't do everything with Linux that you can with a current Mac or PC; everyone knows that.
Translation: I'm a troll. Don't take me seriously.
A short story about hyperintelligent mice. OK, they were bred --- we didn't have DNA manipulation in '54, and for that matter the discovery of DNA was only in the near-future.
The story's worth reading all the way through at least once.
I haven't looked at all of the new revision control systems, but they all seem to be evolutionary modifications rather than revolutionary changes to how things are done.
I don't think we'll see a truly successful next-generation revision control system until somebody tackles the problem from the ground up in an imaginative way.
Again, Limbo is a stopping off point for heaven, not hell
Nope. You're thinking of Purgatory, where ones' sins are purged before going to heaven.
Limbo is where virtuous non-Christians go. It's a later Christian idea --- in Dante's Inferno, virtuous Pagans go to the outermost (least harsh) circle of Hell. But people didn't like the idea that an unbaptized baby would go to Hell through no fault of their own, so 'Limbo' was postulated that gave a place for those people.
Not too long ago, the Catholic church decided that Limbo doesn't exist, however.
(I'm still waiting for them to say the same thing about Purgatory, Hell, and Heaven, but I might have a long wait...;-))
I tested this on 3 stock RH 7.3 boxes as well as a RH 7.2 box running 2.4.17 kernel. All still work.
Which is a good start. But did you check if any were actually running as user 'sshd'? I did, and none were --- it seems that privelege separation doesn't work on Red Hat boxes.
Of course, if I'm wrong, that's great --- but I hope somebody points me in the right direction.
Make sure you go into/etc/ssh/sshd_config to uncomment the "UsePrivilegeSeparation yes" line.
That's unnecessary: the commented lines show all of the options and their default values. If the comment says 'UsePrivilegeSeparation yes', then it's already turned on.
(And yes, I tried uncommenting this and restarting. It didn't enable priv. separation at that point.)
You should see two sshd processes, one with the UID of 0 (root), and the one you are logged in via which should have your UID and "[priv]" in its command name.
*Sigh* I've now tried both the official OpenSSH RPMs and rebuilt ones, and I can't get privelege separation working on any Red Hat 7.x box I have.
Presumably this is what Theo was referring to when saying that priv separation wouldn't work on some platforms.
Anyone manage to get priv sep working on a Red Hat 7.x box? If so, how?
My theory? There is no hole. He's disappointed about the reception of his god-given privilege separation code, and invented this to try and get vendors to adopt it. He's offered us no proof that his heaven-inspired architecture fixes the bug, much less that one exists. We have only his claim to work with.
Actually, Christopher Klaus of ISS said that they were working with another open source vendor on a major security hole while defending their actions with regard to the Apache hole. This case fits his description exactly.
I'm inclined to trust Theo on this one. But I'm not sure he should have said anything until they had a fix... reducing the root exploit to a remote-user exploit isn't good enough.
Slashdot Mirror
Ah, but that was never the issue.
The issue is that third-party packages depend on particular versions of Python, and you thus can't change the default version of Python between point releases.
That is, when 7.0 was released, Python 1.5.2 was the clear choice, given how little Python 2.x code existed at that point. So for the entire 7.x series, Red Hat needed to stick with Python 1.5.x as the default version. Now with the 8.x series, Python 2.2.x is the default version.
This is Red Hat's policy, and is quite sensible when you think about their userbase. They did a similar thing with Sendmail: 7.x used 8.11.x, even though 8.12 came out in the middle of the 7.x series, 7.2 and 7.3 both stuck with 8.11, because there were substantial changes with 8.12 (like no longer requiring that everything run as root...)
The goal is to make transitions within a major release as painless as possible, not only for us dumb sysadmins but also for third-party software developers: anything built against 7.0 should ideally run against 7.3 without so much as a recompile. Less ideally, you shouldn't have to port it but just rebuild it.
Er, yeah....
Er, no.
That is, not with in-house or third-party apps deployed on the server.
<VERYLITTLEWORDS>This may shock you, but sometimes people run software on computers. Sometimes even software that doesn't ship with the operating system.
If you upgrade from one Debian stable (Potato, say) to another (like Woody), many, many underyling software versions change.
These changes are necessary: after all, if the software versions didn't change, there wouldn't be a new release of the distribution, would there? But sometimes these changes break things. Changing from PHP 3 to PHP 4 sure breaks things. Upgrading from 4.0.6 to 4.1.x breaks things, too. Just ask the HORDE people.
Some people use many features of the operating system, and have a lot of custom code running on their servers. Often this is in addition to running a full compliment of basic services.
Testing the local code can take a long time, if there's a lot of it. Especially if it depends heavily on features (or even bugs!) of its development language. Perl tends not to break things, but even that happens sometimes.
The OS isn't the only piece that needs to be tested. Modern Linux works pretty much out-of-the-box in that regard. But that's hardly the only thing to test.</VERYLITTLEWORDS>
You've never worked in a large production environment, have you?
Remember when potato came out? Two weeks later (or was it three?) they gave four (or was it six) weeks notice that they were dropping support for the previous Debian stable.
Six weeks is enough for me to evaluate it for personal use, but not to upgrade and test stuff before real-world deployment.
That really pissed me off. I still have customers who use Debian, and I'm happy enough to support them, but I tend not to recommend it for new installations based on that experience.
Gee, I thought you'd say PH-UX. And, actually, I've been on a team responsible for a number of large IRIX systems. The C compiler is really, really picky, but beside that the boxes were great. I hear that several OS revs further in the past there were stability problems, but by 1998 when I got to them, they were rock-solid.
And I understand SGI's supported release policy, too. ;-)
Being a consultant, I run what the customers (already) run. Many of my customers do run Linux, and others run various BSD flavors and/or Solaris. I'll run HPUX or AIX when the customers demand it. :-)
But decisions like this do mean that I don't recommend OpenBSD to most customers. (Or Debian, for precisely the same reason.) Isn't it disappointing not to be able to run a technically superior product for reasons like this? I find it disappointing.
So I've had six months? Great --- that's about how much time it takes to do testing for a substantial site. Now I'm done and can work on other tasks? Nope, gotta do it again for the new release.
You're right: the problem isn't the amount of notice they give. I was off on that point. However, the amount of time you get isn't enough for me to use OpenBSD at a customer's site. Eighteen months as the lifespan of a product isn't substantial enough, in my opinion.
They think that in two months I can take all of my production servers, build replacement boxes, test them, and put the new boxes into production? When the newest release of the OS isn't even available yet? (Why upgrade to the intermediate release when that'll be dropped as soon as the next one comes out...)
Do they assume I have only one box, or that I don't bother to test things, or that I don't lose any money if the upgrade is perfectly smooth? Do they assume that I won't switch to something with a better support policy (and more notice for dropping support) than what they do?
Do any of these people know anyone who manages systems for a living, or do they only talk to other developers?
This happens surprisingly infrequently with individual scientists. What tends to happen is that the scientists who don't believe the new, well-supported evidence (or its interpretation) retire or die.
This is one of Kuhn's basic points.
Funny, that doesn't look like a DVI connector.
If you're after the cultural experience, you might have to work a lousy job, and not work in the tech industry. The tech recession is pretty much global.
If you think that the financial situation is better elsewhere, it isn't.
You missed a step:
The initrd has to have about a one-second delay before you attempt to mount the drive from USB. This is because it takes a little while to detect it.
If you make this one change (a little static binary that does 'sleep 1', essentially) to a standard Red Hat 'mkinitrd' ramdisk, you can indeed do USB if your BIOS supports it.
I've done it. It was a @!#$% to debug the first time around: every time I dropped into sash everything worked, but if I didn't drop into sash it didn't. :-)
This is a solved problem. Red Hat, for example, GPG signs the MD5SUM file. So you can verify that the person who created the MD5SUM was authorized to do so.
OK, assuming I've parsed this sentence fragment correctly, you're insulted that somebody has chosen to spend money to solve part of the problem.
True enough. So you'd rather they not solve the problem at all if they can't solve it equally for everybody?
Because somebody doesn't solve the problem for everybody, they don't understand the problems other people face? That's a non-sequitur if ever I've seen one... If you understand how huge the differences between Linux distributions is, why do you think that a single tool should be able to be everything to everybody?
It seems to me that these people are spending money to try and solve other people's problems. Given this relatively altruistic gesture (though they have their reasons, I'm sure), why shouldn't they try to get the biggest bang for the buck? If covering those two distributions helps thirty or forty percent of Linux users, that's pretty darned good, if you ask me.
Even if we can take them seriously, why can't there be an open standards rating system for security? I'm not sure there's a connection between these two ideas. But just because their tool to test doesn't work on all Linux distributions doesn't mean that the standard itself can't be applied to other distributions. Did you follow the link, or just decide to shoot your mouth off?
ObDisclaimer: Jay Beale, who wrote the Linux tool, is a good personal friend of mine.
ObFlame: That said, Mr. (or Ms.) Anonymous coward, your above writing demonstrates unclear thinking. Try keeping your sentences to one thought apiece, or at most two logically connected statements. Try to have clear relationships between those sentences so that other people can follow what you're saying.
Absolutely a classic --- but somewhat outdated to use as a real intro to Unix. How many gurus do you know who use ed(1) as their primary editor? Also, based as it is upon stock System 7 Unix, there's nothing about networking, etc.
BlatantSelfPromotion: May I recommend Think Unix? It's an updated intro to modern Unix, designed to be read by smart people.
But the research had become a political issue largely because Leary and Alpert and all their friends went around shouting about how important it was... that, too, was political. And it was obviously threatening to the institution. And they should have known better.
Not that potential research into the same subject isn't blocked today for political reasons. It is, obviously. But Leary's failure to realize that he was already being political sunk his research.
Since Dr. Wallace never offers a meaningful refutation of the Chinese room, let me offer one:
Sure, *you* don't understand Chinese. But the *whole system* understands Chinese. That includes the instruction cards, too. But it's difficult the query the whole system. Situating 'you' as part of the system makes it easy to forget that the human is just one component. (ie it's a red herring, designed to distract and confuse rather than enlighten).
I'm not entirely sure I believe it, as there's got to be a good refutation of this explanation somewhere. But I haven't seen it yet.
Well, I'm so totally unimpressed so far. One out of three, and we have a whole bunch of nonsense.
For starters, AI, neural nets, and brains. We have the assertion that the brain is a computer, and we should really be concerned with the software on the computer, not the state of the neurons.
Even accepting the good doctor's view that the brain is a computer, this is an absurd position. After all, the software is in the brain. It's not like it gets bootstrapped from outside sources. So either the software is built into the whole structure of the brain and we can only learn about it by studying the rules (a la neural nets) or we have to figure out which part of the brain bootstraps the rest of it. Which we'd have to study the wet squishy bits to figure out. Which can best be done with a combination of noninvasive study (MRI, for example) and simulation. Like neural nets.
(The third possibility is that the brain is a computer, but the program is stored on a shared network drive... that is, in a non-material 'soul.' Which would bring us back to Cartesian dualism, God, and a whole bunch of things you'd better reject if you want to work in AI. Not rejecting the notion of God per se, just in the degree of investment in the nonmaterial world in which a being needs to take part...)
Second, academic politics. Dr. Wallace seems to believe in a golden age (that occurred, not coincidentally, just before his professional career) where professors were promoted and supported on the basis of merit.
Right. Anyone who believes in any society at any time in the West that existed without politics is invited to check into the nearest mental institution. To accept the idea of a 'golden age' just tantalizingly out of his reach is pathetic. It's like imagining an era where writers received acclaim based on the quality of their work.
Newsflash: Emily Dickinson's writings were discovered after her death. Everything we read by Melville was written long after his popularity had waned. Any number of great artists were 'discovered' after their deaths. And the most popular writers and artists at any time have been the ones who played the political game successfully. (Personal politics, not governmental politics, of course.) Anyone who's read any medieval philosophy or theology knows that there hasn't been a meritocracy in Western academia for at least eight hundred years.
As far as LSD and politics, it was the professors involved in those experiments (ie Tim Leary) who engaged in politics. And they were bad at it. And they lost. And the substances ended up scheduled. And their academic careers were ruined.
On to part two, to see what he says there. Perhaps it gets better.
I'm not bothered by the fact that they based their older distributions on Red Hat. I am bothered that they are constantly begging for money.
The fact is, any mainstream general-purpose Linux distribution has both GNOME and KDE, tons of features, and tons of options. While Mandrake's installer is nice, it's not worlds ahead of anybody else's anymore. (OK, it's ahead of Debian's in terms of user-friendliness, but what isn't?) Heck, even the Red Hat's installer is friendly these days.
Translation: I'm a troll. Don't take me seriously.The Lysenko Maze - David Grinnell - F&SF Jul '54
A short story about hyperintelligent mice. OK, they were bred --- we didn't have DNA manipulation in '54, and for that matter the discovery of DNA was only in the near-future.
The story's worth reading all the way through at least once.
... that the problem needs to be reimagined.
I haven't looked at all of the new revision control systems, but they all seem to be evolutionary modifications rather than revolutionary changes to how things are done.
I don't think we'll see a truly successful next-generation revision control system until somebody tackles the problem from the ground up in an imaginative way.
Nope. You're thinking of Purgatory, where ones' sins are purged before going to heaven.
Limbo is where virtuous non-Christians go. It's a later Christian idea --- in Dante's Inferno, virtuous Pagans go to the outermost (least harsh) circle of Hell. But people didn't like the idea that an unbaptized baby would go to Hell through no fault of their own, so 'Limbo' was postulated that gave a place for those people.
Not too long ago, the Catholic church decided that Limbo doesn't exist, however.
(I'm still waiting for them to say the same thing about Purgatory, Hell, and Heaven, but I might have a long wait... ;-))
If it washes off when it rains, is it still vandalism?
Last I checked, vandalism was damaging or destroying property. Spraypaint or marker might be considered vandalism because it's permanant, but chalk?
Which is a good start. But did you check if any were actually running as user 'sshd'? I did, and none were --- it seems that privelege separation doesn't work on Red Hat boxes.
Of course, if I'm wrong, that's great --- but I hope somebody points me in the right direction.
That's unnecessary: the commented lines show all of the options and their default values. If the comment says 'UsePrivilegeSeparation yes', then it's already turned on.
(And yes, I tried uncommenting this and restarting. It didn't enable priv. separation at that point.)
*Sigh* I've now tried both the official OpenSSH RPMs and rebuilt ones, and I can't get privelege separation working on any Red Hat 7.x box I have.
Presumably this is what Theo was referring to when saying that priv separation wouldn't work on some platforms.
Anyone manage to get priv sep working on a Red Hat 7.x box? If so, how?
Actually, Christopher Klaus of ISS said that they were working with another open source vendor on a major security hole while defending their actions with regard to the Apache hole. This case fits his description exactly.
I'm inclined to trust Theo on this one. But I'm not sure he should have said anything until they had a fix... reducing the root exploit to a remote-user exploit isn't good enough.