Oh, I'm not advocating the discarding of cgi-bin at all! It's just that compared to some of the modern, prettier ways of doing things, it certainly does *look* clunky.
Many poeple here have contributed to various Nagios plugins. Pretending that the plugins are separate from your sandwich is like pretending that the bread is not part of a hamburger, or like kernels without modules. A few people use them that way, but they're quite rare.
OK, I'm afraid this is typical of a lot of unfinished open-source tools.
* I see no PGP or GPG signatures on the Zenoss RPM's. This is always bad, especially for software doing core infrasture tasks like system monitoring.
* Install an RPM for MySQL that conflicts with the built-in version of every deployed OS known to Linuxkind. That's understandable, but it means you've left out a critical step: start with a clean box with no MySQL installed on it, because they can't be parallel installed and it *will* modify if not break your existing MySQL installation. And step away from ever being able to get security or bugfixes from the OS vendor by doiing so.
* Install a Zenoss-Plugins package with a messed up name (switching case in package names is always a bad sign!) that has no SRPM and apparently cannot be compiled from the tarball without considerable difficulty. That's a vrey secure software installation practice, don't you agree?
* You must also have to grab the various perl modules from a third-party repository: OK, DAG's repositories have most of them, but that dependency is not documented by the ZenOSS authors or you. I know how to set up those, but the ZenOSS SRPM doesn't list those dependencies, does it?
* Notice then that you spend a lot of time talking about ZenWin. I didn't ask about ZenWin, I asked about ZenOSS. This is an irrelevant feature and distracts from the usefulness of your answer.
Please excuse me for being so harsh about this. The list of the steps you used is appreciated, but this sort of thing is quite typical in the Nagios community and is one of the things that really detracts from the use of these tools.
The Nagios codebase is considerably older. It was written before mod_perl and PHP were in broad use, when binaries in a webpage meant using cgi-bin.
There are plenty more monitoring tools. Bigbrother and Bigsister come to mind, although Bigbrother was ruined when it went commercial. And despite the claims of the anonymous coward above, there are some workable GUI's, although I admit that they do need work to make commercial or production grade.
A good Nagios book would certainly be welcome on my bookshelf: it's used for the same reason sendmail is still used, it's stable and familiar and has stood up to the test of time.
Look again: according to my mainland Chines immigrant acquaintances, as much as 90% of the "official" game and movie DVD sales in mainland China are in fact pirated on a corporate scale. With so little threat of prosecution, and no robust identification of whare the discs were purchased from, there's just no way to control this.
This is why Microsoft wants Vista's enhanced DRM capabilities: to cooperate with video producers, and to protect its own software from cheap duplication.
And the reference implementaion is, let's see. jabberd 1.x and jabberd 2.x, both at www.jabber.org.
And frankly, the clients are irrelevant unless they actively *forbid* the use of the unencrypted protocol, and the clients have no way to prevent the server from using the plain-text password techniques used by default in the reference jabberd implementations. Given such deep security flaws as a matter of default practice, it's not worth pursuing the protocol.
Good. Go take a look at the source code for Jabber. Isn't it nice how the default is to store your passwords in clear-text and leave them legible to anyone on the Jabber server? And to send them unencrypted over an open channel? And you as a client will never know or be able to tell if they're doing this?
Are you really sure this is the standard you want to promote for remote communications?
I also suspect that you don't spend much time on the IRC warez or cracker channels: rootkits installing IRC servers are still a major problem for a lot of us to deal with, and I've never seen this for jabber.
That's no reason to do it on sourceforge. Running a private mailing list is a fairly trivial task. And for the authors of GAIM to require a secret mailing list hosted by someone else, in a site famed not for its secrecy but in fact for its openness, is silly indeed. Unless the contributors to the discussion were keeping their names secret and only communicating via Sourceforge aliases, it seems beyond silly and even downright foolish.
Apparently true. Of course, having secret legal negotiations on a forum designed to be so public as Sourceforge systems is like discussing your STD's in an elevator at work. Even if you're alone, the door's likely to open at a bad moment and your boss will hear about that embarassing weekend with his son and the consequences.
Would you care to correct the Wikipedia article on that point? I've not played enough with NetBSD to know whether they have a restricted access developer repository, and whether that's what Theo lost: many projects do. I admit it drives me nuts when the public code doesn't include the developer codelines.
How about SCO vs. IBM? Admittedly, the material I'm referring to was original BSD code that's turned up in the lawsuit and which SCO misidentified as from their AT&T UNIX licenses, but simply because the behavior is stupid or fraudulent doens't mean it's not real and shouldn't be avoided with cautious copyright policies.
Oh, no. Just strip out the copyright notices of an important part of OpenSSH (such as the RSA key handling) and include it in a GnuSSH project. Then watch for even more fun as Theo shrieks about stealing "his" code. Then slap him upside the head with the amount of OpenSSH code that is actually taken (admittedly legally!) from the last open-source version of the old ssh source code from ssh.com.
This is like the Emancipation Proclamation is designed to limit men's freedoms, because it forbids the ownership of slaves. Hello? It's curtailing some privileges of ownership to protect the rights of those who can't afford the fifty copyright verifications a typical small computer program might need, and preventing some of the demonstrated misuses of software secrecy that are demonstrated every year!
And it's not Theo's right to get so upset if it really was an accident. It's that of the author who stole/borrowed/accidentally dropped in the pot such large chunks of GPL'd code.
I wonder what else Theo or his developers got their wrists recently slapped for that has him so touchy?
Theo's continued ill behavior towards other development teams interfered with NetBSD work and BSD copyrights, because he's made it clear he can't be bothered to play nice or encourage his development partners to play nice.. It's now going to interfere with OpenBSD, which may cost us some technical features of OpenBSD but will encourage developers to stop playing with such a niche market and move over to the more commercially and developmentally effective world of Linux.
I mean, sheesh. have you ever tried to *install* OpenBSD?
I think we may have just found Theo's alias on Slashdot, exept it's not wordy and overblown enough. Like Richard Stallman, people often forgive Theo's personality flaws as the price of his genius: but Richard is far easier to deal with.
If you think I'm kidding, go take a look at the Wikipedia article on Theo, especially the first few lines.
In December 1994, NetBSD co-founder Theo de Raadt was asked to resign his position as a senior developer and member of the NetBSD core team, and his access to the source code repository was revoked. The reason for this is not wholly clear, although there are claims that it was due to personality clashes within the NetBSD project and on its mailing lists.[2] De Raadt has been criticized for having a sometimes abrasive personality: in his book, Free For All, Peter Wayner claims that de Raadt "began to rub some people the wrong way" before the split from NetBSD;[3] Linus Torvalds has described him as "difficult;"[4] and an interviewer admits to being "apprehensive" before meeting him.[5]
They obviously knew Theo. If he's going to throw a hissy, you may as well get it in print early so he can't even *pretend* he's remotely rational.
For example, his claim that "we are the people who wrote OpenSSH" is false from its start. OpenSSH had its foundations in the original SSH implementation, released under a very open source license but taken private at roughly version 1.2.22. Now, that wasn't stolen. But Theo and his peers taking credit for someone else's foundation work is hardly new. Most of the current OpenSSH maintainers are very careful to take credit only for *their* work, and credit the ssh.com authors with their original work.
Theo isn't so careful. Moreover, the OpenBSD insistence on pursuing useless but technically exciting features (such as their "chroot" functionality, which isn't actually a chroot cage for anything that uses SSH) have actually hindered its deployment. And their default insistence on not being able to detect passphrase-less keys continues to make SSH use a surprisingly dangerous tool: since the local keys are kept almost by default unprotected, any idiot who can read your backup tapes or access your home directory by other means can and will steal your private SSH keys and use them for anything they want.
The vulnerabilities have been known about for years. Pursing that unstable and unreliable chroot that only operates for millisends when starting up OpenSSH was considered far more important than these practical issues.
It's time for Theo to resign from his leadership position and let someone with more of a clue give him orders on his technically proficient code.
The new stuff is the extensive DRM, especially including the so-called "Trusted Computing" tools, and the remains of the attempts in insert WinFS, which turned out to be pretty unusable and wound up thrown out.
I do. When a known bug surfaces that affects a lot of people, it's basic security practice to check for other projects that use this chunk of code. In a well-built source control system, it's pretty obvious. With programmers who don't know or try to read how things work doing cut&paste programming, it's uncontrolled and unmanageable.
Guess what company famous for stealing software, lying about its security, famous for hiding "features" that deliberately break interoperability doesn't want to expose its code to review by outsiders or even by its own separate departments?
I've actually taken down a fully armored medieval enactment knight who had lost his temper. Bare-handed. Admittedly, I was wearing solid shoes, went under his overhead screaming swinging and got a good thrust kick in square on his chest, and his being lifted off his feet and landing flat on his back knocked the wind out of him. But that left me plenty of options, including stepping back as the referees and other fighters tore over there to deal with him.
Running is good: but sometimes there *is* an opening, especially when they're acting crazed and can't *believe* that you'd have the nerve to strike them.
Hey, it's hard for Cheney to reach that far up his backside and make his fingers do typing. It's especially hard when Rumsfield is sticking a hand up there and arm-wrestlinig him for control of the other hand.
It's a shame that groklaw.net seems off-line right now. Look for the records there on how Microsoft is helping keep SCO afloat by sponsoring "partnerships" with other Microsoft companies. It's also amusing how the money is just enough to keep SCO afloat: this weakens Linux with all the nonsense being spewed by SCO, but also keeps SCO from being able to do useful work with their own UNIX licenses.
It's certainly more desirable for Microsoft to interfere with both markets than to help either side win.
I'm not so suare: the child of a male donkey and a female horse is a mule. A female donkey and a male horse make a hinney.
What do you call the result of a llama that's been stuffed with RAM? Maybe we need a new word: for a woolly-thinking creature that has lots of memory that can't be accessed, we could call it a reagan?
Slashdot Mirror
Oh, I'm not advocating the discarding of cgi-bin at all! It's just that compared to some of the modern, prettier ways of doing things, it certainly does *look* clunky.
Many poeple here have contributed to various Nagios plugins. Pretending that the plugins are separate from your sandwich is like pretending that the bread is not part of a hamburger, or like kernels without modules. A few people use them that way, but they're quite rare.
OK, I'm afraid this is typical of a lot of unfinished open-source tools.
* I see no PGP or GPG signatures on the Zenoss RPM's. This is always bad, especially for software doing core infrasture tasks like system monitoring.
* Install an RPM for MySQL that conflicts with the built-in version of every deployed OS known to Linuxkind. That's understandable, but it means you've left out a critical step: start with a clean box with no MySQL installed on it, because they can't be parallel installed and it *will* modify if not break your existing MySQL installation. And step away from ever being able to get security or bugfixes from the OS vendor by doiing so.
* Install a Zenoss-Plugins package with a messed up name (switching case in package names is always a bad sign!) that has no SRPM and apparently cannot be compiled from the tarball without considerable difficulty. That's a vrey secure software installation practice, don't you agree?
* You must also have to grab the various perl modules from a third-party repository: OK, DAG's repositories have most of them, but that dependency is not documented by the ZenOSS authors or you. I know how to set up those, but the ZenOSS SRPM doesn't list those dependencies, does it?
* Notice then that you spend a lot of time talking about ZenWin. I didn't ask about ZenWin, I asked about ZenOSS. This is an irrelevant feature and distracts from the usefulness of your answer.
Please excuse me for being so harsh about this. The list of the steps you used is appreciated, but this sort of thing is quite typical in the Nagios community and is one of the things that really detracts from the use of these tools.
You got Zenoss working? Undre which OS distribution? And did you publish notes, or use an installation guide?
The Nagios codebase is considerably older. It was written before mod_perl and PHP were in broad use, when binaries in a webpage meant using cgi-bin.
There are plenty more monitoring tools. Bigbrother and Bigsister come to mind, although Bigbrother was ruined when it went commercial. And despite the claims of the anonymous coward above, there are some workable GUI's, although I admit that they do need work to make commercial or production grade.
A good Nagios book would certainly be welcome on my bookshelf: it's used for the same reason sendmail is still used, it's stable and familiar and has stood up to the test of time.
Look again: according to my mainland Chines immigrant acquaintances, as much as 90% of the "official" game and movie DVD sales in mainland China are in fact pirated on a corporate scale. With so little threat of prosecution, and no robust identification of whare the discs were purchased from, there's just no way to control this.
This is why Microsoft wants Vista's enhanced DRM capabilities: to cooperate with video producers, and to protect its own software from cheap duplication.
And the reference implementaion is, let's see. jabberd 1.x and jabberd 2.x, both at www.jabber.org.
And frankly, the clients are irrelevant unless they actively *forbid* the use of the unencrypted protocol, and the clients have no way to prevent the server from using the plain-text password techniques used by default in the reference jabberd implementations. Given such deep security flaws as a matter of default practice, it's not worth pursuing the protocol.
Good. Go take a look at the source code for Jabber. Isn't it nice how the default is to store your passwords in clear-text and leave them legible to anyone on the Jabber server? And to send them unencrypted over an open channel? And you as a client will never know or be able to tell if they're doing this?
Are you really sure this is the standard you want to promote for remote communications?
I also suspect that you don't spend much time on the IRC warez or cracker channels: rootkits installing IRC servers are still a major problem for a lot of us to deal with, and I've never seen this for jabber.
That's no reason to do it on sourceforge. Running a private mailing list is a fairly trivial task. And for the authors of GAIM to require a secret mailing list hosted by someone else, in a site famed not for its secrecy but in fact for its openness, is silly indeed. Unless the contributors to the discussion were keeping their names secret and only communicating via Sourceforge aliases, it seems beyond silly and even downright foolish.
Apparently true. Of course, having secret legal negotiations on a forum designed to be so public as Sourceforge systems is like discussing your STD's in an elevator at work. Even if you're alone, the door's likely to open at a bad moment and your boss will hear about that embarassing weekend with his son and the consequences.
Would you care to correct the Wikipedia article on that point? I've not played enough with NetBSD to know whether they have a restricted access developer repository, and whether that's what Theo lost: many projects do. I admit it drives me nuts when the public code doesn't include the developer codelines.
How about SCO vs. IBM? Admittedly, the material I'm referring to was original BSD code that's turned up in the lawsuit and which SCO misidentified as from their AT&T UNIX licenses, but simply because the behavior is stupid or fraudulent doens't mean it's not real and shouldn't be avoided with cautious copyright policies.
Oh, no. Just strip out the copyright notices of an important part of OpenSSH (such as the RSA key handling) and include it in a GnuSSH project. Then watch for even more fun as Theo shrieks about stealing "his" code. Then slap him upside the head with the amount of OpenSSH code that is actually taken (admittedly legally!) from the last open-source version of the old ssh source code from ssh.com.
Oh, please.
This is like the Emancipation Proclamation is designed to limit men's freedoms, because it forbids the ownership of slaves. Hello? It's curtailing some privileges of ownership to protect the rights of those who can't afford the fifty copyright verifications a typical small computer program might need, and preventing some of the demonstrated misuses of software secrecy that are demonstrated every year!
And it's not Theo's right to get so upset if it really was an accident. It's that of the author who stole/borrowed/accidentally dropped in the pot such large chunks of GPL'd code.
I wonder what else Theo or his developers got their wrists recently slapped for that has him so touchy?
Good.
Theo's continued ill behavior towards other development teams interfered with NetBSD work and BSD copyrights, because he's made it clear he can't be bothered to play nice or encourage his development partners to play nice.. It's now going to interfere with OpenBSD, which may cost us some technical features of OpenBSD but will encourage developers to stop playing with such a niche market and move over to the more commercially and developmentally effective world of Linux.
I mean, sheesh. have you ever tried to *install* OpenBSD?
I think we may have just found Theo's alias on Slashdot, exept it's not wordy and overblown enough. Like Richard Stallman, people often forgive Theo's personality flaws as the price of his genius: but Richard is far easier to deal with. If you think I'm kidding, go take a look at the Wikipedia article on Theo, especially the first few lines. In December 1994, NetBSD co-founder Theo de Raadt was asked to resign his position as a senior developer and member of the NetBSD core team, and his access to the source code repository was revoked. The reason for this is not wholly clear, although there are claims that it was due to personality clashes within the NetBSD project and on its mailing lists.[2] De Raadt has been criticized for having a sometimes abrasive personality: in his book, Free For All, Peter Wayner claims that de Raadt "began to rub some people the wrong way" before the split from NetBSD;[3] Linus Torvalds has described him as "difficult;"[4] and an interviewer admits to being "apprehensive" before meeting him.[5]
They obviously knew Theo. If he's going to throw a hissy, you may as well get it in print early so he can't even *pretend* he's remotely rational.
For example, his claim that "we are the people who wrote OpenSSH" is false from its start. OpenSSH had its foundations in the original SSH implementation, released under a very open source license but taken private at roughly version 1.2.22. Now, that wasn't stolen. But Theo and his peers taking credit for someone else's foundation work is hardly new. Most of the current OpenSSH maintainers are very careful to take credit only for *their* work, and credit the ssh.com authors with their original work.
Theo isn't so careful. Moreover, the OpenBSD insistence on pursuing useless but technically exciting features (such as their "chroot" functionality, which isn't actually a chroot cage for anything that uses SSH) have actually hindered its deployment. And their default insistence on not being able to detect passphrase-less keys continues to make SSH use a surprisingly dangerous tool: since the local keys are kept almost by default unprotected, any idiot who can read your backup tapes or access your home directory by other means can and will steal your private SSH keys and use them for anything they want.
The vulnerabilities have been known about for years. Pursing that unstable and unreliable chroot that only operates for millisends when starting up OpenSSH was considered far more important than these practical issues.
It's time for Theo to resign from his leadership position and let someone with more of a clue give him orders on his technically proficient code.
The new stuff is the extensive DRM, especially including the so-called "Trusted Computing" tools, and the remains of the attempts in insert WinFS, which turned out to be pretty unusable and wound up thrown out.
I do. When a known bug surfaces that affects a lot of people, it's basic security practice to check for other projects that use this chunk of code. In a well-built source control system, it's pretty obvious. With programmers who don't know or try to read how things work doing cut&paste programming, it's uncontrolled and unmanageable.
Guess what company famous for stealing software, lying about its security, famous for hiding "features" that deliberately break interoperability doesn't want to expose its code to review by outsiders or even by its own separate departments?
Make a bet?
I've actually taken down a fully armored medieval enactment knight who had lost his temper. Bare-handed. Admittedly, I was wearing solid shoes, went under his overhead screaming swinging and got a good thrust kick in square on his chest, and his being lifted off his feet and landing flat on his back knocked the wind out of him. But that left me plenty of options, including stepping back as the referees and other fighters tore over there to deal with him.
Running is good: but sometimes there *is* an opening, especially when they're acting crazed and can't *believe* that you'd have the nerve to strike them.
Hey, it's hard for Cheney to reach that far up his backside and make his fingers do typing. It's especially hard when Rumsfield is sticking a hand up there and arm-wrestlinig him for control of the other hand.
It's a shame that groklaw.net seems off-line right now. Look for the records there on how Microsoft is helping keep SCO afloat by sponsoring "partnerships" with other Microsoft companies. It's also amusing how the money is just enough to keep SCO afloat: this weakens Linux with all the nonsense being spewed by SCO, but also keeps SCO from being able to do useful work with their own UNIX licenses.
It's certainly more desirable for Microsoft to interfere with both markets than to help either side win.
I'm not so suare: the child of a male donkey and a female horse is a mule. A female donkey and a male horse make a hinney.
What do you call the result of a llama that's been stuffed with RAM? Maybe we need a new word: for a woolly-thinking creature that has lots of memory that can't be accessed, we could call it a reagan?
No, it's really not. It's quite bad for your wrists.