The best thing to do is take a rest on your hands, and get professional help. Voice recognition for coding sucks.. believe me. You're better off doing something else altogether if it comes to that.
Coding is very precise work, and voice recognition just isn't good at that. If you try coding with your voice, you'll soon find that your voice hurts, and you've been immensely frustrated at the whole experience.
Ah, and on the LDAP/NIS/NIS+ question, Ganymede can support anything you like with it. Historically it was designed with an NIS supporting schema, but we're also using it to synchronize accounts to Active Directory by way of LDAP, and synchronizing accounts to an OpenLDAP server is easily done as well.
The big problem with using LDAP for Unix authentication is that system vendors haven't implemented RFC 2307 in as consistent a fashion as they have their NIS implementations.. different operating systems have different limitations on how things like netgroups and automounter definitions are represented in LDAP, which makes it a bit difficult to have a very heterogeneous environment without requiring extensive client-side configuration.
Ganymede 2.0 uses SSL for all client-server communications, as well as digitally signing the applets. It also requires Java 1.4 or better, largely in order to support SSL.
Ganymede supports roles, so that you can give certain administrators arbitrarily reduced privileges. If you've got people who need to have limited privileges as you describe, it's possible to grant them in Ganymede, if the powers that be permit it.
We have been using our own software, Ganymede, to handle our DNS for the last 7 years. Ganymede is a programmable directory mastering application.. you give it a schema with objects for real-world items such as systems, interfaces, networks, etc., and Ganymede provides an object database and concurrent client/server GUI for making changes. Whenever an administrator hits 'commit' in their client, Ganymede turns around and updates the DNS (and in our case, our NIS, our Active Directory, our DHCP, and more) on a background thread.
The schema we use for managing DNS at ARL:UT is not the most flexible, in that we have only a single DNS domain that we are managing, and may well not fit your environment, however there is a consulting company in Germany, http://www.fg-networking.de/, which has built a complete DNS and DHCP management solution around Ganymede. They are using it to manage the DNS and DHCP for a University of 14,000 hosts, and they might be able to help you out with your environment.
If you do decide you might like to know more about Ganymede, let me know.. I've been working on it for the last couple of years for internal use and for clients, without posting any new releases on our website. The software has tons of improvements that have been made in the meantime.
You misunderstand his question. He's not looking to slave the clocks together on his network.. as you say, NTP does that just fine (and more than just fine) right now. He's looking to enforce a restriction on login capabilities according to the time of day, using LDAP and Kerberos.
It's easy to represent such constraints in LDAP, the question is whether any of his systems will know what he's talking about if he does.
You'll need to get some custom code written for your systems, in order to get them to honor the time constraints you put in your LDAP server. You could do this most simply by modifying pam_ldap, probably, though I don't know whether there are any pre-defined schema/OID values that you could leverage.. you might need to define your own attributes and encoding.
Doing it at the Keberos level would work, but that would require modifications to the ticket granting server, so that it knows what services are to be constrained for which users on whatever schedule.
I'm not sure it does what you need, but you might check out the XAD Identity Server from PADL.com down in Australia. Luke Howard of PADL wrote the RFC 2307 which guides the use of LDAP on Unix systems for NIS-like applications (as well as the nss_ldap and pam_ldap modules that most folks use), and is generally an incredibly expert fellow.
You could also use something like our own Ganymede software to provide management intelligence for your central directory services, but as it's not specifically linked to LDAP or Kerberos (though you can adapt it to manage both, as we have), something like XAD is more likely to provide an appropriate framework for you.
If you were to be especially ambitious about doing the right thing, you'd talk to Luke about getting scheduled access controls into some successor to RFC 2307, and integrating support for those extensions into nss_ldap/pam_ldap.
Yes, of course. If you read what I said, though, I didn't contradict that.
Just because Xen doesn't simulate a x86 processor doesn't mean that it doesn't simulate a processor. The processor that Xen simulates is a Xen-x86 processor, in which the only processor functions that have to be emulated are ones that are not virtualizable without Intel and AMD's upcoming virtualization ISA modifications, "Intel Virtualization Technology/Vanderpool", and "Pacifica".
But the kernel does boot and exceute on top of a processor environment provided by Xen, and that's the vital distinction I was meaning to draw in the comparison with OpenVZ and VServer.
You're right, it would seem that this would be the sort of thing that the software patenters would have been all over, but you can't patent something if there's prior art, and there was a lot of prior art in virtualization way before software patents were ever granted in this country.
If things like VServer and OpenVZ violate patents, I'd expect that the FreeBSD 5 Jail system would as well, and I've not heard of any patent action against the FreeBSD folks on this ground.
OpenVZ doesn't care about processor virtualization features. OpenVZ (like VServer) is all about implementing a system like FreeBSD jails. In this model, there's only one kernel running, but different sets of processes are isolated from each other through operating system features. The separation applies to things like the 'ps' command and the/proc interface in general, as well as things like sockets and networking.
With OpenVZ/VServer, you can set up security and network separation so that certain processes will think of themselves as on 'internal-web-server', while others will think of themselves as 'external-web-server', and the two sets of processes would not be able to interact with each other in ways other than through the same kind of networking connections that they would use if they were on separate pieces of physical hardware.
Something like Xen or VMWare achieves this virtualization by simulating separate processors, memory, and I/O space hardware. OpenVZ/VServer doesn't incur this overhead, but does require much more significant modifications to the Linux kernel, as lots of system calls have to be modified to enforce the process group separation rules.
The referenced article says he's with 'Cyber-Ark'. By sheerest coincidence, the Cyber-Ark company produces computer security products that deal with internal management of administrative passwords.
Most of the 'Perspectives' stuff on news.com is just like this, and the smaller cyber-zines like this one are probably filled with nothing but PR firm essays.
If you have, say, an SHA-256 or an SHA-512 hash and it turns out that a flaw is found in the algorythm that allows specially formulated additions to a message to generate a specific signature, then you will not be safe.
Yes, I understand that.
For example, imagine that I have found a way to take an arbitrary-length SHA hash and using data equal to the length of the signature, create a correction that will make the signature match whatever I want it to be. If you are using SHA to look for tampering then it is rendered useless. If on the other hand I am also using MD5, crypt, or some other hashing algorythm, then the collision of one hash would likely not match on the other. The attack against one would likely fail on the other, and one would have a much more complex problem of creating an a colision for arbitrary content has just become *far* more difficult.
I understand that, of course. That's why I proposed concatenating the hashes, above.
However, if you find a way to take an arbitrary-length SHA hash and find collisions at will, you have demonstrated that the SHA algorithm is deeply, fatally flawed.
It so happens that MD5 and SHA are in the same class of algorithms, and the weaknesses that have been revealed in MD5 affect SHA as well. It's just that SHA hashes can be long enough that the weakness does not make finding collisions feasible. If your opponent knows that you're using hash concatenation, he has two simpler problems to solve.. a shorter SHA and a short MD5. The way these algorithms work, the effort involved may in fact be two considerably simpler challenges added together, rather than multiplied.
Anyway, all I mean to say is that cryptographic algorithms are subtle, and while incorporating MD5 and SHA might get you a bit more strength, that doesn't make up for known algorithmic weaknesses in the hash algorithms.
Now, with my proposal, one would include independant hashs which would be checked independantly. If either one fails, one assumes that the data has been tampered with. The issue is that it would be difficult to defeat both simultaneously for this specific type of check. Being able to do so on demand while editing the file in a meaningful way might well prove impossible.
Yes, but only if you mean 'might well prove impossible' in the same way that it 'might well prove impossible' to break SHA-1 or MD5. There's nothing magical in the mathematics that makes a hash generated partially by SHA-1 and partially by MD5 harder to break than a hash generated by SHA-256 or the like, which generates a longer hash than SHA-1 or MD5 alone.
Remember, as long as the domain of source files to be hashed includes all possible data files longer than the generated hash, there will be collisions in the function's range. This is true even in the SHA1('data').MD5('data') case. And as long as there are collisions, it's just a question of how difficult it is to find them.
Yes, prefixing your MD5 hash with an SHA1 hash should make it much harder to find a collision in both algorithms simultaneously, but the very same difficulty could be achieved with a single hash algorithm which generates a longer hash. The magic is in the quality of the algorithm and the length of the output, not in the fact that two algorithms were put to use.
True, but you could use a hash function like SHA1('data').MD5('data'), where the . operator stands for string concatenation.
The reason that this isn't generally done is that should not provide more security than a proper cryptographic hash algorithm that produces hashes as long as the two different hash algorithms concatenated together.
If you want additional collision resistance, just generate a longer hash. I believe this is how people are advised to handle SHA-class algorithms right now.
VGA Planets. Quite the obscure title, but if you've got several friends up for an extended play by email campaign combining Diplomacy with Star Fleet Battles, you can have an amazingly good time.
Why should *any* thread have to bear a cost that it does not benefit from?
The threading mechanism should be efficient enough that the optional cost of creating a per-thread event queue or whatever can be set up as a second step, just as a database thread might need to set up thread local storage as a second step, or whatever. If you get the underlying mechanism efficient, everything on top benefits. Limiting the benefits of such efficiency to threads that do some particular limited task is not efficient.
Do you actually have any experience with this under Windows? What sort of optimizations are you alluding to, and how do you imagine they are done better than under Linux?
The problem (and the justification for your troll mod, I suppose) is that process and thread creation are (or should be) wholly orthogonal to GUI issues.
Why should the GUI have any impact whatsoever on low-level process and thread operations?
You'll be glad to know that people haven't answered Behe by saying, 'believe what we tell you to!'. Instead, people have answered Behe by saying, 'Not so, here's why!'
The thing is, Intelligent Design is like Holocaust Denial. It's based on something other than the evidence, and seeks to ignore, not to grapple with, the known evidence.
So far, Intelligent Design has presented no challenge to the biological sciences, if by that we mean that they have proposed answers that better fit the observed evidence than evolutionary biology. Intelligent Design has made no predictions, has come up with no test which a) would prove modern neo-darwinian evolutionary theory false if failed, and b) has been demonstrated to fail.
The sum total of peer-reviewed publications making an defensible Intelligent Design argument can be counted on the fingers of one hand, if that hand has had a run-in with a high powered shredding machine.
This, as opposed to tens of thousands of papers exploring and refining evolutionary biology.
Keep in mind that a theory is a framework of reasoning and thought that fits with all known evidence and which can make predictions as well as be falsified by possible discoveries.
Theory != Guess
Re:Full review and screen shots
on
Quake 4 Linux
·
· Score: 3, Funny
Yeah, yeah, optimization, performance, blah blah blah.
In Quake 4, your weapons come with _flashlights_ attached!
That's got to be the biggest improvement over Doom 3, right there.
Slashdot Mirror
The best thing to do is take a rest on your hands, and get professional help. Voice recognition for coding sucks.. believe me. You're better off doing something else altogether if it comes to that.
Coding is very precise work, and voice recognition just isn't good at that. If you try coding with your voice, you'll soon find that your voice hurts, and you've been immensely frustrated at the whole experience.
Have you had medical attention to your hands?
Mod: +1 railing against injust moderators
Yes. The individual who named the predecessor project (the Group Admin Shell) was not, however.
Ah, and on the LDAP/NIS/NIS+ question, Ganymede can support anything you like with it. Historically it was designed with an NIS supporting schema, but we're also using it to synchronize accounts to Active Directory by way of LDAP, and synchronizing accounts to an OpenLDAP server is easily done as well.
The big problem with using LDAP for Unix authentication is that system vendors haven't implemented RFC 2307 in as consistent a fashion as they have their NIS implementations.. different operating systems have different limitations on how things like netgroups and automounter definitions are represented in LDAP, which makes it a bit difficult to have a very heterogeneous environment without requiring extensive client-side configuration.
Ganymede 2.0 uses SSL for all client-server communications, as well as digitally signing the applets. It also requires Java 1.4 or better, largely in order to support SSL.
Ganymede supports roles, so that you can give certain administrators arbitrarily reduced privileges. If you've got people who need to have limited privileges as you describe, it's possible to grant them in Ganymede, if the powers that be permit it.
May I ask if you work at ARL:UT?
We have been using our own software, Ganymede, to handle our DNS for the last 7 years. Ganymede is a programmable directory mastering application.. you give it a schema with objects for real-world items such as systems, interfaces, networks, etc., and Ganymede provides an object database and concurrent client/server GUI for making changes. Whenever an administrator hits 'commit' in their client, Ganymede turns around and updates the DNS (and in our case, our NIS, our Active Directory, our DHCP, and more) on a background thread.
The schema we use for managing DNS at ARL:UT is not the most flexible, in that we have only a single DNS domain that we are managing, and may well not fit your environment, however there is a consulting company in Germany, http://www.fg-networking.de/, which has built a complete DNS and DHCP management solution around Ganymede. They are using it to manage the DNS and DHCP for a University of 14,000 hosts, and they might be able to help you out with your environment.
If you do decide you might like to know more about Ganymede, let me know.. I've been working on it for the last couple of years for internal use and for clients, without posting any new releases on our website. The software has tons of improvements that have been made in the meantime.
You are correct, sir!
Nicely done. ;-)
You misunderstand his question. He's not looking to slave the clocks together on his network.. as you say, NTP does that just fine (and more than just fine) right now. He's looking to enforce a restriction on login capabilities according to the time of day, using LDAP and Kerberos.
It's easy to represent such constraints in LDAP, the question is whether any of his systems will know what he's talking about if he does.
You'll need to get some custom code written for your systems, in order to get them to honor the time constraints you put in your LDAP server. You could do this most simply by modifying pam_ldap, probably, though I don't know whether there are any pre-defined schema/OID values that you could leverage.. you might need to define your own attributes and encoding.
Doing it at the Keberos level would work, but that would require modifications to the ticket granting server, so that it knows what services are to be constrained for which users on whatever schedule.
I'm not sure it does what you need, but you might check out the XAD Identity Server from PADL.com down in Australia. Luke Howard of PADL wrote the RFC 2307 which guides the use of LDAP on Unix systems for NIS-like applications (as well as the nss_ldap and pam_ldap modules that most folks use), and is generally an incredibly expert fellow.
You could also use something like our own Ganymede software to provide management intelligence for your central directory services, but as it's not specifically linked to LDAP or Kerberos (though you can adapt it to manage both, as we have), something like XAD is more likely to provide an appropriate framework for you.
If you were to be especially ambitious about doing the right thing, you'd talk to Luke about getting scheduled access controls into some successor to RFC 2307, and integrating support for those extensions into nss_ldap/pam_ldap.
Xen uses Bridge interfaces in the Dom0 operating system host.
Yes, of course. If you read what I said, though, I didn't contradict that.
Just because Xen doesn't simulate a x86 processor doesn't mean that it doesn't simulate a processor. The processor that Xen simulates is a Xen-x86 processor, in which the only processor functions that have to be emulated are ones that are not virtualizable without Intel and AMD's upcoming virtualization ISA modifications, "Intel Virtualization Technology/Vanderpool", and "Pacifica".
But the kernel does boot and exceute on top of a processor environment provided by Xen, and that's the vital distinction I was meaning to draw in the comparison with OpenVZ and VServer.
You're right, it would seem that this would be the sort of thing that the software patenters would have been all over, but you can't patent something if there's prior art, and there was a lot of prior art in virtualization way before software patents were ever granted in this country.
If things like VServer and OpenVZ violate patents, I'd expect that the FreeBSD 5 Jail system would as well, and I've not heard of any patent action against the FreeBSD folks on this ground.
OpenVZ doesn't care about processor virtualization features. OpenVZ (like VServer) is all about implementing a system like FreeBSD jails. In this model, there's only one kernel running, but different sets of processes are isolated from each other through operating system features. The separation applies to things like the 'ps' command and the /proc interface in general, as well as things like sockets and networking.
With OpenVZ/VServer, you can set up security and network separation so that certain processes will think of themselves as on 'internal-web-server', while others will think of themselves as 'external-web-server', and the two sets of processes would not be able to interact with each other in ways other than through the same kind of networking connections that they would use if they were on separate pieces of physical hardware.
Something like Xen or VMWare achieves this virtualization by simulating separate processors, memory, and I/O space hardware. OpenVZ/VServer doesn't incur this overhead, but does require much more significant modifications to the Linux kernel, as lots of system calls have to be modified to enforce the process group separation rules.
Right, good eye. Don't ever forget The Submarine.
The referenced article says he's with 'Cyber-Ark'. By sheerest coincidence, the Cyber-Ark company produces computer security products that deal with internal management of administrative passwords.
Most of the 'Perspectives' stuff on news.com is just like this, and the smaller cyber-zines like this one are probably filled with nothing but PR firm essays.
I don't think you understand what I am saying.
If you have, say, an SHA-256 or an SHA-512 hash and it turns out that a flaw is found in the algorythm that allows specially formulated additions to a message to generate a specific signature, then you will not be safe.
Yes, I understand that.
For example, imagine that I have found a way to take an arbitrary-length SHA hash and using data equal to the length of the signature, create a correction that will make the signature match whatever I want it to be. If you are using SHA to look for tampering then it is rendered useless. If on the other hand I am also using MD5, crypt, or some other hashing algorythm, then the collision of one hash would likely not match on the other. The attack against one would likely fail on the other, and one would have a much more complex problem of creating an a colision for arbitrary content has just become *far* more difficult.
I understand that, of course. That's why I proposed concatenating the hashes, above.
However, if you find a way to take an arbitrary-length SHA hash and find collisions at will, you have demonstrated that the SHA algorithm is deeply, fatally flawed.
It so happens that MD5 and SHA are in the same class of algorithms, and the weaknesses that have been revealed in MD5 affect SHA as well. It's just that SHA hashes can be long enough that the weakness does not make finding collisions feasible. If your opponent knows that you're using hash concatenation, he has two simpler problems to solve.. a shorter SHA and a short MD5. The way these algorithms work, the effort involved may in fact be two considerably simpler challenges added together, rather than multiplied.
Anyway, all I mean to say is that cryptographic algorithms are subtle, and while incorporating MD5 and SHA might get you a bit more strength, that doesn't make up for known algorithmic weaknesses in the hash algorithms.
Now, with my proposal, one would include independant hashs which would be checked independantly. If either one fails, one assumes that the data has been tampered with. The issue is that it would be difficult to defeat both simultaneously for this specific type of check. Being able to do so on demand while editing the file in a meaningful way might well prove impossible.
Yes, but only if you mean 'might well prove impossible' in the same way that it 'might well prove impossible' to break SHA-1 or MD5. There's nothing magical in the mathematics that makes a hash generated partially by SHA-1 and partially by MD5 harder to break than a hash generated by SHA-256 or the like, which generates a longer hash than SHA-1 or MD5 alone.
Remember, as long as the domain of source files to be hashed includes all possible data files longer than the generated hash, there will be collisions in the function's range. This is true even in the SHA1('data').MD5('data') case. And as long as there are collisions, it's just a question of how difficult it is to find them.
Yes, prefixing your MD5 hash with an SHA1 hash should make it much harder to find a collision in both algorithms simultaneously, but the very same difficulty could be achieved with a single hash algorithm which generates a longer hash. The magic is in the quality of the algorithm and the length of the output, not in the fact that two algorithms were put to use.
True, but you could use a hash function like SHA1('data').MD5('data'), where the . operator stands for string concatenation.
The reason that this isn't generally done is that should not provide more security than a proper cryptographic hash algorithm that produces hashes as long as the two different hash algorithms concatenated together.
If you want additional collision resistance, just generate a longer hash. I believe this is how people are advised to handle SHA-class algorithms right now.
VGA Planets. Quite the obscure title, but if you've got several friends up for an extended play by email campaign combining Diplomacy with Star Fleet Battles, you can have an amazingly good time.
Why should *any* thread have to bear a cost that it does not benefit from?
The threading mechanism should be efficient enough that the optional cost of creating a per-thread event queue or whatever can be set up as a second step, just as a database thread might need to set up thread local storage as a second step, or whatever. If you get the underlying mechanism efficient, everything on top benefits. Limiting the benefits of such efficiency to threads that do some particular limited task is not efficient.
Do you actually have any experience with this under Windows? What sort of optimizations are you alluding to, and how do you imagine they are done better than under Linux?
The problem (and the justification for your troll mod, I suppose) is that process and thread creation are (or should be) wholly orthogonal to GUI issues.
Why should the GUI have any impact whatsoever on low-level process and thread operations?
Seems like someone needs to read http://www.talkorigins.org/faqs/behe.html.
You'll be glad to know that people haven't answered Behe by saying, 'believe what we tell you to!'. Instead, people have answered Behe by saying, 'Not so, here's why!'
The thing is, Intelligent Design is like Holocaust Denial. It's based on something other than the evidence, and seeks to ignore, not to grapple with, the known evidence.
So far, Intelligent Design has presented no challenge to the biological sciences, if by that we mean that they have proposed answers that better fit the observed evidence than evolutionary biology. Intelligent Design has made no predictions, has come up with no test which a) would prove modern neo-darwinian evolutionary theory false if failed, and b) has been demonstrated to fail.
The sum total of peer-reviewed publications making an defensible Intelligent Design argument can be counted on the fingers of one hand, if that hand has had a run-in with a high powered shredding machine.
This, as opposed to tens of thousands of papers exploring and refining evolutionary biology.
Literally no contest.
What other theories?
Keep in mind that a theory is a framework of reasoning and thought that fits with all known evidence and which can make predictions as well as be falsified by possible discoveries.
Theory != Guess
Yeah, yeah, optimization, performance, blah blah blah. In Quake 4, your weapons come with _flashlights_ attached! That's got to be the biggest improvement over Doom 3, right there.
Except when they're not.