Sadly, Kerberos can't be used for everything. Especially logins to systems you don't control such as support and vendor ordering logins that should be available to people.
This is what we do for a much smaller group of admins and systems: Create a simple text file with the systems, usernames and passwords. GPG/PGP encrypt this file to a list of recipients. Now you have a single encrypted file that can be decrypted by any of the recipients. You could break this out into multiple levels by having multiple files, one for each group of "only these users have these passwords" and each file is encrypted to different sets of users. No logging, nothing fancy, but it just plain works and doesn't require lots of money or time to set up. One bit of advice: include your web passwords for vendor support or ordering in here as well, not just your internal systems.
If I recall correctly from reading and a bit of training we were given at my company, this is supposed to be the guideline for validity of a patent application. I would think that if you asked just about any computer geek in 1995 to come up with a way to navigate a large music library, a hierarchy would have been the result. This is also how I used to arrange my mp3s before there were nice frontends, as a directory of Artists with subdirectories for Albums for each artist.
In my opinion I doubt that the development effort to bring Office to Linux desktops is worth it for Microsoft. Costs: Programmer effort including learning/using libraries that I doubt MS programmers have lots of experience with. Potentially making Linux a more viable-looking desktop OS alternative to Windows Potential added complexity to the codebase Benefits: Miniscule amount of sales to a small market Improve their image of working with non-MS technologies
It just doesn't seem like they have a lot to gain from doing this...
Agreed on your multipath statements, except that in this case, due to the topology, losing a switch means losing all drives connected via that switch. In most SANs (sometimes even iSCSI) you have multiple routes from the raid card, through different networks, to the servers.
As far as SAN's management capability being its downfall, I disagree. I find it isn't terribly complicated (much simpler/faster than the Linux LVM tools I've used) and it can even be done in a standard way by creating your own iSCSI target and using those very same LVM tools. Someone even commented on this story that they had done this. The point is that all the raid and volume administration is done in one place, and individual servers do not have to worry about that complexity.
I read some of the responses. First off, I still don't see how you can have multipath if the actual trays only have one port (which looks to be the case). Their EtherDrive units where a RAID card and drives sit in one unit and then the already-raided volumes are exported over AoE is a bit different, but at that point you could just make your own iSCSI target and be more compatible with existing mature iSCSI implementations (such as the software initiator in windows). All this talk of how raid/can/ be done on a linux server is missing my main point, which is: raid and volume management should not/have/ to be handled on the server in a SAN environment, it is one of the main selling points of SANs. A single place to manage your storage configuration, all servers just see a chunk of storage and don't have to worry about the details. I am not saying AoE is not useful in some settings or a neat technology, my main point is that it is not an iSCSI killer because it does not fill all the functions iSCSI does.
1) Complexity for RAID and volume management is not centralized and is pushed to individual hosts. One of the main benefits of SAN technology is that you can just carve out storage from a single interface and assign it to a server and the server simply sees it as a block device. With AoE each drive is addressed separately by the server, which means it is up to the server (and server admin) to figure out how to handle distributing over multiple drives, handle drive failures, and expanding volumes. This is huge. 2) It is not a standard and is only really supported by one vendor. This may change in the future but it is significant right now. It is registered with the IEEE but that hardly makes it a peer-reviewed standard with input/improvements from many experts. 3) No boot from SAN. Until someone makes some sort of mini bootstrap system on a CD or a hardware card implementation of AoE that can be addressed as a block device admins will be unable to host the root filesystem and/or C: drive on an AoE SAN 4) No multipath (that I can see). Perhaps I misunderstand this, but it seems like there is no way to do multipath IO with this system. That is, all the drives are single-connected to a network. If that network switch goes down, all drives on that network are inaccessible. So AoE looks like a neat technology for pushing drives out of the box and potentially sharing them among hosts, but there is no intelligence there. It is just dumb block addressable storage with no added availability or management, and therefore is far from being an iSCSI or FC killer.
I think what you should be looking at is a SAN that has the capability of a NAS frontend. For your transactional/database loads you will want block-level I/O which usually means either fibre channel or iSCSI connections from the servers. For the file sharing you can either connect a regular server to the SAN and have it handle exporting the storage or get NAS functionality from your SAN vendor. Most NAS functionality from SAN vendors only does SMB or NFS but is nicely integratable and manageable. We were in a similar situation and evaluated about seven vendors and narrowed it down to EMC, NetApp, and Pillar Data for solutions in our price range that would be able to handle different types of workloads all from one pool of disk. We decided on pillar for a few reasons. One of the biggest things pillar had that nobody else did at the time was the ability to get different levels of performance from a single type of disk by using a neat QoS I/O scheduler and putting the high priority data on the outer tracks of the disk. They also have fully redundant paths to SATA drives where each drive is dual-ported and can be addressed by two raid cards. Supposedly they can get similar performance of 10k RPM FC drives from the SATA drives they use with their system. They are also adding the ability to add trays of FC disks as well. I'm really pleased with the system, it is very flexible (can scale by I/O as well by adding just controllers, not replacing) and one of the only solutions that allow you to start at around 2TB but still have several levels of great performance all on one pool of disk. EMC is adding more similar QoS stuff to their new systems. Another thing that I found out is that it is really hard to get full redunancy from controllers down for under $75k on most other systems (with netapp you need to buy two separate frontends and can't go beyond two without another level of software/management).
This would be a real shame as SGI has talent for engineering great systems. The Altix is a really nice architecture, the idea being you start with a 4 CPU node and can scale to a very large system with a single system image, high availability, easy scalability of memory, cpu, storage and interconnect, and has nice management tools for partitioning, etc. Unfortunately the price of entry is a bit high, and I think that perhaps going with IA64 rather than the budding Opteron was a misstep at the time. I also feel they lost a lot of momentum by dabbling in various unpopular markets like high end NT workstations, expensive specialty graphics workstations (given this was a core market for them earlier, but high power graphics became commoditized) and didn't really strongly launch into the linux server market and make a big presence in time. If they had pushed a cheaper starting system for a scalable single system box they may have done better, but who knows.
By the time Ambegris is ready to be used in perfume, it has been floating around in the ocean for ~10 years. By this time, the odor would certainly not make one vomit and may even be considered pleasant. Also, I wanted to mention that some ingredients used in perfumery are not present to provide olfactory enjoyment. For example, civit and castor oils are used as a fixitive in the base of the perfume to preserve the natural floral essences. Ambergris also serves this purpose, but happens to add to the olfactory experience as well. Only the oldest fragrance houses still use these methods. Most companies have replaced the use of animal ingredients with synthetics.
Two things, first, it is probably more proper to match the X-Spam: YES header than the number of asterisks in the X-Spam-Level header. Then you configure you can tweak your cutoff level for X-Spam: Yes in the SA config. Also, rather than running SA from procmail or other means, it is much more efficient and clean to run it from a seperate daemon like amavisd-new and then configure postfix to use amavisd-new as a content_filter. There are several advantages of this approach, the greatest one being that you do not have process startup penalties for incoming mails to be scanned since amavisd-new is written in perl, references the SA engine through the perl module rather than the commandline, and has a similar scalable child process architecture to apache and many other network server daemons. Other nice things about amavisd-new is that you can integrate many different virus scanners with it as well as SA and it will handle all the subject rewriting, mail deleting, etc for you.
Yes. There are security concerns with reverse DNS. Some time ago there was at lease one exploit that had you put bogus data in your reverse DNS, vulnerable software trusted the data it got from a reverse DNS lookup and this led to a possible exploit. Many people started trying to own DNS servers just for this purpose. It us understandable to be surly sometimes.
Natalie Portman: an actress many slashdot trolls seem to be obsessed about. Her most well known role is as Queen Amidala in the latest Star Wars movie.
grits: ground up corn as far as I can tell/know. Most popular in southeastern US. A popular side dish like mashed potatoes.
All your base are belong to us: net humor/fad. Based on a poor english translation of a japanese video game called "Zerowing". It is mentioned on the lycos 50. It us understandable to be surly sometimes.
"Deep Impact" was mentioned in one of mst3k's summer blockbuster preview shows. Crow gave it a treatment something like: "Now for a movie about an important piece of legislation that changes the sex-for-money industry forever, "Dee Pimp Act""
I found it very amusing. It us understandable to be surly sometimes.
Akira is a good one and is available at most rental places. It really helped kickstart the anime-in-America scene. Battle Angel Alita is one of my personal favorites as it has an excellent sci-fi plot. Both Akira and Alita are sci-fi-ish. There are other genres of anime as well (drama, horror, comedy, adult, etc). Vampire Hunter D is a cool horror-esque series. Ranma is a popular comedy series. There are many others of course. It us understandable to be surly sometimes.
Slashdot Mirror
Sadly, Kerberos can't be used for everything. Especially logins to systems you don't control such as support and vendor ordering logins that should be available to people.
This is what we do for a much smaller group of admins and systems:
Create a simple text file with the systems, usernames and passwords. GPG/PGP encrypt this file to a list of recipients. Now you have a single encrypted file that can be decrypted by any of the recipients. You could break this out into multiple levels by having multiple files, one for each group of "only these users have these passwords" and each file is encrypted to different sets of users.
No logging, nothing fancy, but it just plain works and doesn't require lots of money or time to set up.
One bit of advice: include your web passwords for vendor support or ordering in here as well, not just your internal systems.
If I recall correctly from reading and a bit of training we were given at my company, this is supposed to be the guideline for validity of a patent application. I would think that if you asked just about any computer geek in 1995 to come up with a way to navigate a large music library, a hierarchy would have been the result. This is also how I used to arrange my mp3s before there were nice frontends, as a directory of Artists with subdirectories for Albums for each artist.
In my opinion I doubt that the development effort to bring Office to Linux desktops is worth it for Microsoft.
Costs:
Programmer effort including learning/using libraries that I doubt MS programmers have lots of experience with.
Potentially making Linux a more viable-looking desktop OS alternative to Windows
Potential added complexity to the codebase
Benefits:
Miniscule amount of sales to a small market
Improve their image of working with non-MS technologies
It just doesn't seem like they have a lot to gain from doing this...
But what about WebKit, or other projects like it, such as WebKit?
Agreed on your multipath statements, except that in this case, due to the topology, losing a switch means losing all drives connected via that switch. In most SANs (sometimes even iSCSI) you have multiple routes from the raid card, through different networks, to the servers.
As far as SAN's management capability being its downfall, I disagree. I find it isn't terribly complicated (much simpler/faster than the Linux LVM tools I've used) and it can even be done in a standard way by creating your own iSCSI target and using those very same LVM tools. Someone even commented on this story that they had done this. The point is that all the raid and volume administration is done in one place, and individual servers do not have to worry about that complexity.
I read some of the responses. First off, I still don't see how you can have multipath if the actual trays only have one port (which looks to be the case). Their EtherDrive units where a RAID card and drives sit in one unit and then the already-raided volumes are exported over AoE is a bit different, but at that point you could just make your own iSCSI target and be more compatible with existing mature iSCSI implementations (such as the software initiator in windows). /can/ be done on a linux server is missing my main point, which is: raid and volume management should not /have/ to be handled on the server in a SAN environment, it is one of the main selling points of SANs. A single place to manage your storage configuration, all servers just see a chunk of storage and don't have to worry about the details.
All this talk of how raid
I am not saying AoE is not useful in some settings or a neat technology, my main point is that it is not an iSCSI killer because it does not fill all the functions iSCSI does.
1) Complexity for RAID and volume management is not centralized and is pushed to individual hosts. One of the main benefits of SAN technology is that you can just carve out storage from a single interface and assign it to a server and the server simply sees it as a block device. With AoE each drive is addressed separately by the server, which means it is up to the server (and server admin) to figure out how to handle distributing over multiple drives, handle drive failures, and expanding volumes. This is huge.
2) It is not a standard and is only really supported by one vendor. This may change in the future but it is significant right now. It is registered with the IEEE but that hardly makes it a peer-reviewed standard with input/improvements from many experts.
3) No boot from SAN. Until someone makes some sort of mini bootstrap system on a CD or a hardware card implementation of AoE that can be addressed as a block device admins will be unable to host the root filesystem and/or C: drive on an AoE SAN
4) No multipath (that I can see). Perhaps I misunderstand this, but it seems like there is no way to do multipath IO with this system. That is, all the drives are single-connected to a network. If that network switch goes down, all drives on that network are inaccessible.
So AoE looks like a neat technology for pushing drives out of the box and potentially sharing them among hosts, but there is no intelligence there. It is just dumb block addressable storage with no added availability or management, and therefore is far from being an iSCSI or FC killer.
I think what you should be looking at is a SAN that has the capability of a NAS frontend. For your transactional/database loads you will want block-level I/O which usually means either fibre channel or iSCSI connections from the servers. For the file sharing you can either connect a regular server to the SAN and have it handle exporting the storage or get NAS functionality from your SAN vendor. Most NAS functionality from SAN vendors only does SMB or NFS but is nicely integratable and manageable.
We were in a similar situation and evaluated about seven vendors and narrowed it down to EMC, NetApp, and Pillar Data for solutions in our price range that would be able to handle different types of workloads all from one pool of disk. We decided on pillar for a few reasons. One of the biggest things pillar had that nobody else did at the time was the ability to get different levels of performance from a single type of disk by using a neat QoS I/O scheduler and putting the high priority data on the outer tracks of the disk. They also have fully redundant paths to SATA drives where each drive is dual-ported and can be addressed by two raid cards. Supposedly they can get similar performance of 10k RPM FC drives from the SATA drives they use with their system. They are also adding the ability to add trays of FC disks as well. I'm really pleased with the system, it is very flexible (can scale by I/O as well by adding just controllers, not replacing) and one of the only solutions that allow you to start at around 2TB but still have several levels of great performance all on one pool of disk. EMC is adding more similar QoS stuff to their new systems. Another thing that I found out is that it is really hard to get full redunancy from controllers down for under $75k on most other systems (with netapp you need to buy two separate frontends and can't go beyond two without another level of software/management).
Here's a correction:
That should be "You're way out.", unless you are talking about a "way out" belonging to the poster. You're == You are.
This would be a real shame as SGI has talent for engineering great systems. The Altix is a really nice architecture, the idea being you start with a 4 CPU node and can scale to a very large system with a single system image, high availability, easy scalability of memory, cpu, storage and interconnect, and has nice management tools for partitioning, etc. Unfortunately the price of entry is a bit high, and I think that perhaps going with IA64 rather than the budding Opteron was a misstep at the time.
I also feel they lost a lot of momentum by dabbling in various unpopular markets like high end NT workstations, expensive specialty graphics workstations (given this was a core market for them earlier, but high power graphics became commoditized) and didn't really strongly launch into the linux server market and make a big presence in time. If they had pushed a cheaper starting system for a scalable single system box they may have done better, but who knows.
The Scion-branded Toyotas are actually built in Japan. I bought an xB that I'm quite pleased with after almost 20k miles.
How about "I'm sorry, our website's on another server!"
By the time Ambegris is ready to be used in perfume, it has been floating around in the ocean for ~10 years. By this time, the odor would certainly not make one vomit and may even be considered pleasant.
Also, I wanted to mention that some ingredients used in perfumery are not present to provide olfactory enjoyment. For example, civit and castor oils are used as a fixitive in the base of the perfume to preserve the natural floral essences. Ambergris also serves this purpose, but happens to add to the olfactory experience as well.
Only the oldest fragrance houses still use these methods. Most companies have replaced the use of animal ingredients with synthetics.
Two things, first, it is probably more proper to match the X-Spam: YES header than the number of asterisks in the X-Spam-Level header. Then you configure you can tweak your cutoff level for X-Spam: Yes in the SA config.
Also, rather than running SA from procmail or other means, it is much more efficient and clean to run it from a seperate daemon like amavisd-new and then configure postfix to use amavisd-new as a content_filter. There are several advantages of this approach, the greatest one being that you do not have process startup penalties for incoming mails to be scanned since amavisd-new is written in perl, references the SA engine through the perl module rather than the commandline, and has a similar scalable child process architecture to apache and many other network server daemons. Other nice things about amavisd-new is that you can integrate many different virus scanners with it as well as SA and it will handle all the subject rewriting, mail deleting, etc for you.
Yes. There are security concerns with reverse DNS. Some time ago there was at lease one exploit that had you put bogus data in your reverse DNS, vulnerable software trusted the data it got from a reverse DNS lookup and this led to a possible exploit. Many people started trying to own DNS servers just for this purpose.
It us understandable to be surly sometimes.
Nice sig, commodore?
It us understandable to be surly sometimes.
Um, they both tend to increase over time?
It us understandable to be surly sometimes.
Natalie Portman: an actress many slashdot trolls seem to be obsessed about. Her most well known role is as Queen Amidala in the latest Star Wars movie.
grits: ground up corn as far as I can tell/know. Most popular in southeastern US. A popular side dish like mashed potatoes.
All your base are belong to us: net humor/fad. Based on a poor english translation of a japanese video game called "Zerowing". It is mentioned on the lycos 50.
It us understandable to be surly sometimes.
I would use systemimager to install a full linux image on the machines. I use it for our cluster and it works great.
www.systemimager.org
It us understandable to be surly sometimes.
"yes I got the joke, I was mocking the 75% of /. to literal-minded to get it."
That should be "too literal-minded."
It us understandable to be surly sometimes.
pirhana was not installed by default, and thus affected very few people.
It us understandable to be surly sometimes.
"Deep Impact" was mentioned in one of mst3k's summer blockbuster preview shows. Crow gave it a treatment something like: "Now for a movie about an important piece of legislation that changes the sex-for-money industry forever, "Dee Pimp Act""
I found it very amusing.
It us understandable to be surly sometimes.
"Nobody has voted on whether he or she wants to live in a world with only healthy, cheerful, smart and attractive inhabitants."
:)
I vote "Yes."
It us understandable to be surly sometimes.
Akira is a good one and is available at most rental places. It really helped kickstart the anime-in-America scene.
Battle Angel Alita is one of my personal favorites as it has an excellent sci-fi plot. Both Akira and Alita are sci-fi-ish. There are other genres of anime as well (drama, horror, comedy, adult, etc). Vampire Hunter D is a cool horror-esque series. Ranma is a popular comedy series. There are many others of course.
It us understandable to be surly sometimes.