Other folks are giving good answers on the encryption side of things. I'll address this one:
I would also like to locally cache the data I receive from the LDAP directory. Are there any solutions for doing that? Or should I just cache the data in a SQL database running locally on the WebApp server?"
Caching locally in an SQL database is not going to be very efficient - as a general rule, LDAP reads are going to be faster than SQL reads. Caches are for speed, not reliability. If time on wire is your concern, run a local LDAP slave. For raw speed, use MLDBM or similar for your cache - you really can't get much faster without writing an application specific cache that sits in memory.
I like Bruce a lot. He's a very smart man. I have talked to him before, but I doubt he remembers it.
That book is a nice read. One should know going into reading it that it is an ad for his company. I don't think Bruce saw it happening that way, but it did. I do think he's telling the truth as he sees it.
Sorry I can't give a black-and-white comment here. It is still a great book.
So, getting publicity is not needed to be a hero(tm). Putting yourself at risk in the service of your fellow man is.
So, when I was nearly killed working in a tomato field, I'm a hero? Cool. Because I was Working For My Fellow Man, being hit by a tractor makes me a hero.
Reality check follows.
Heros are those who get lots of attention, who happened to do something cool, or foolhardy, or lucky. People like to look at them and think they'd do something similar. Nation states like to memorialize them to encourage certain behaviour.
I'm not disupting that heroes exist. I have several, personally. I do agree that the shuttle crew were not heroes.
Me: Are you asserting that because people who don't medically need pot will use it, it should be denied to people who medically need it? You seem to be.
rewster: I have yet to see a reasonable argument why anyone "needs" it.
Pot has been shown numerous times to be beneficial for a number of maladies not addressed by other medication. I'm not going to cite links becuase I'm sure you're aware of them. If not, Google is your pal.
Me: By the way, can you explain in clear, concise terms why pot _should_ be illegal?
rewster: Explain to me first why it should. Studies have shown the kind of damage it does to the human brain - so tell me how that's beneficial to anyone? And why people with certain diseases should be allowed to use it, then?
Ok, here is why is should be legal. I'm holding you to your side of the bargain - you have to explain in clear, concise terms why pot should be illegal.
It should be legal because we live in a country based on the concept that the individual knows best what is good for them. Roughly, one should be able to go to hell in thier own way, so long as they don't take others with them. We allow people do drive motorcycles, have dangerous sex, climb rocks, drink too much, and drop out of school. Even if pot were so harmful that it was worse that alcohol or cigarettes, it should still be legal. That the drug trade is dangerous to others is a self-referential argument - if it were legal, there wouldn't be crime surrounding the trade.
So, now it is your turn - please explain in clear, concise turms why pot should be illegal. I accepted your turn around, and answered you. Please pay me the same respect.
Are you asserting that because people who don't medically need pot will use it, it should be denied to people who medically need it? You seem to be.
Seriously, everybody assumes that since someone is - coincidentally - furthering the interests of people who are in pain, they're doing the world a big favor, when they're probably in it for themselves.
I'm running a business hoping to make money. Does that mean that when I open source things, I'm not doing something good? Think before answering.
By the way, can you explain in clear, concise terms why pot _should_ be illegal?
After bitching to the seller, I posted negative feedback on eBay.
The seller freaked out and demanded that I retract my statement. (Not sure that's possible, honestly).
I responded via email saying I am just stating facts, that my check was deposited, and that I had no goods to show for it, and then...
I AM NOT RESPONSIBLE FOR THE MAIL IF YOU DONT TAKE DOWN MY NEGATIVE RATIN I WILL SSUE YOU INTO THE GROUND.
I am not making this up.
I asked the person to sue me. I also mentioned that I've been in touch with barristers that might have an interest, and hinted that if my cash came back, I may not attack.
I got a premium on my cash. The lawyers asked me if I'd work on another project. I said no.
(Don't do this if you don't, actually. have a lawyer, it can go horribly wrong. Take the advice they give you if you do have one. Get one if you don't. IANAL, etc.)
I was essentially placing bets on behaviour of marketing droids. They have to be able to predict, and to control, in order to do the jobs they do.
My comments were about the intersection of marketing and math.
Unfortunately, I'm far from my reference material right now. I'd love to verify that RSA and MD5 have nothing to do with each other, but I can't be bothered to go through the source I have on hand before I go to bed. I'll note, though, you're mounting a theoretical attack, rather than one that takes into account the timing imperetives of the problems a Brittny campaign might have.
Moor(e)'s law is great, and fine, but it does not speak to advances in math. (It doesn't speak very well to the advances in circuit design, but that's a different discusion.)
My point is just this - I want to mimick a cryptographically sound sum, in order to dupe a downloader into wasting time, and/or hearing my sales pitch.
If I have a distributed clearing house of sums, that cannot happen, if you use an approved(tm) sum, such as MD5 or SHA.
A clearing house (which can be like DNS, and shoudl be) can provide multiple answers. The user can pick and choose.
I've been working on this problem from a different angle, nothing to do with file transfer, but it isn't that hard (and no, the code isn't open source, yet. We have to make money first). But there's no reason typing at one another is different than transfering files. It is all in how you match people up.
Directed graphs are cool. So are reputations.
Think about it hard. I'm up for the game. I think I'll find out I'm right.
Another interesting note for things like this is that estimates of cost-per-attack calculations is that they apply over an average - you might collide on the first trial or you might have to cover the entire keyspace for a given run.
That fact does not co-exist well with carefully timed media blitzes. If Brittney's new album is proving to be difficult to poison (the collisions for some of the rips are statistically landing on the wrong end of the curve), an attacker may be forced to throw additional resources at those problems, thus doing fewer other songs, in order to make sure the marketing timeline from Jay Leno to concerts to ads with Pepsi goes well.
I don't think poisoning P2P is vital enough for those considerations to be terribly important right now. Still is a simple cost analysis, but marketing would probably be pissed.
In general, I fully agree with what you're saying.
But one nit is that (and I'm not verifying your math, this is Slashdot, but it does feel right) it isn't 1000 songs/month that could be targeted, but 1000 files/month. If you assume you're only targeting, say, the 5 most popular rippers at the 3 most popular bitrates, that's 1000/15= 67 songs/month.
This sort of thing would work better for things that don't survive lossy compression, like software.
Yes, a birthday attack on MD5 is fairly 'easy', but only when compared to the problem you're not solving: finding a string of bits that MD5s to a specific checksum. In a birthday attack, you don't care what the checksum is. When finding a file to match an MD5 checksum, you do.
Another reason why MD5 is useful here is that it is extremely likely that even if you generated a collision for a specific hash, it would likely look nothing like an MP3. Therefore, P2P software could trivially check that there was a valid MP3 header as the file was being transfered, and abort if it didn't.
There have been some interesting attacks on MD5 that don't look good for the long-term viability of MD5, but at this point they are soley theoretical.
Cryptography is cool. ** The MD5 of this post, above the "**", is 0b82e0e6df9eec5502de3c094b994e39. If you can post something that matches that, you've got an awfully cool paper to write.
Most material is second hand, but as you read, you get a good feel of things.
There's also a huge amount of garbage there.
I've been a subscriber, most of the time, since 1994, although it usually isn't a good idea to post unless you have a lot of time to fight with a bunch of nuts.That said, it is a very good source of opinions, and once in a great while something very interesting happens (RC4 was disclosed anonymously a log time ago, for instance).
We were doing some slightly bizarre things, in the way that only sites that are long lived and creative can become. One of my personal cliches is "backwords compatibitity with your company's code is your worst nightmare". Among other things, we were interoperating with a pile of code written by a departed contractor written in ADL. I am not making this up.
My normal pattern was to hack the.cf until it did what I wanted, and turn that into something reasonably reasonable as a define statement, so that we could upgrade without losing hair or teeth.
Don't get me started on when we had to hack the source to get something that would check a remote site for the existance of a given username... _that_ was bad.
In any case, yes, sendmail has a long history of being inclusive, reasonable, and solid. I think people who badmouth it do so because they don't understand it.
That's Apache::Mason curling up and (croke|die)ing.
Looks like the coder is trying to be a good citizen, and either the database can't handle the load, or Apache is running out of swap. Or, there's a dumb captialization problem in the use statements or somesuch.
Sorry, I've just been doing too much of this lately. "Stop me before I debug again"...
In a former life, I had to build a mailing list manager that handled content generation, sub/unsub, bounce management, etc. for a large number of mailing lists that had to do about 1.3 million messages in 4 hours.
Without going through the whole set up, there were slave boxes that just delivered mail. They used pieces of postfix, which did a good job (I like postfix, BTW, my current company's primary mail server uses it).
The primary machine used sendmail. Once you get over the horror of writing a.cf file, the flexibility, and tweakability of sendmail is astounding. Not everyone needs it, but when you do, sendmail rocks.
A lot of people who don't really know what they're talking about rag on sendmail, echoing some very valid complaints that are mostly only of historical interest now. The most valid complaint these days is that it is arcane to configure. My take is, sure, it is, as it should be. Handling large volumes of email is second only to nntp for placing a heavy load on all sections of a network. If you don't know what you're doing, you shouldn't be doing it.
I use postfix because it is easy now, we're only handling a few thousand messages a day.Should that change, I'm back with my old pal sendmail.
There's so much confusion going on that I'm not even going to try to sort it out. A couple of hints -
Trademark does indeed need to be defended in order to be help as such. That has nothing to do with IP or trade secrets (two different things).
Trade secrets are only enforced contractually. They have no special protection. A leak is a leak - if you leak a trade secret to me, you can be held in violation of any contract in place, but I can do whatever I want with the information. (If you don't believe me, google on "+RC4 +cypherpunks +RSA +anonymous")
IP means a large number of different things, with patents being a large centerpiece. This case has nothing to do with IP.
In short, defending contractual agreements has nothing to do with one's brand from a legal standpoint. Try not to get confused in the future.
Full feedback loops that control a real world robot is interesting. Maybe not earthshaking, maybe not the Evil Robot Army we all want to have, but it is a big deal.
Sure, you can grow a cell-culture somewhere, and it may even have some of the same attributes as the real thing grown from the same cells. But it lacks it's overall organization
I think that's the point, and for a wider audience than the ones who want replacement eyeballs and Evil Robot Armies.
Learning how cognitive cells self-organize and interact with the real world is both a dazzling chance for more study and really, really fucking creepy.
2. Turn it into ns1 (import records,etc), turn off ns1 at old location
3. Update host records for ns1 with Tucows and Internic
I'm REALLY nervous about running on one name server for the few hours between moving. I also have an irrational fear that when I transition ns1 to its temporary home, it will cause a rift in the time-space continuum making all of my site inaccessable.
Is it advisable to bring ns0 up with the rest of the equipment and skip the redirect?
If I'm following you, I wouldn't be too concerned with running on one name server for a short time. The odds of something going wrong on it in that period is lower than the odds of something else going wrong.If it makes you really nervous, have the redirect server also do DNS for that period, although that slows you down - you'll have to wait for Tucows or whoever to make an additional change.
As for fears of transitioning ns1, what I'd do is not turn off the old ns1 until after you're sure that the new one is being used - wait until the host record update goes through and you see zero traffic on the old one to turn it off.
Another hint I thought of:
- if you can get away with it, institute a configuration freeze several days before the move, and reboot everything you can at the old place. I wish I had done thing - several machines had very long uptimes, and people had made changes that caused problems when we brought them back up at the new location. If you can test them one at a time, you might save yourself some grief.
Every site is different, with different services, operator skill sets, requirements, demands, and cash.
Lay out your priorities. You say "everything has to stay up" - maybe that's true, but I moved a rather large commercial site stuck in one colo elsewhere, in pieces, when we had a *lot* of money, and when cost analysis started being done, it turned out we could afford downtime.
Look at your traffic records, worry about what has to be up and what doesn't. Think *hard* about dependencies.
Perhaps you can afford two trips (which is what we did), in which case, you move a skeleton crew to the new site (pre configured and tested, of course) , switched DNS (you did think about your TTL, yes?), waited for it to be picked up from a site I knew had not cached the DNS, and completed the move.
Perhaps you can buy/borrow from the office/use spares (but be careful about occupying your spares!) for the move.
Perhaps you can offload the bulk of your traffic elsewhere (Akamai or something to move the demand on machines off the machines while you're doing it.)
I can't speak to your situation, but there's always a way to make it work - like I said, it is pure operations. Analyse, plan, plan again, execute.
More hints -
- Before you're slouching in the colo breaking down the network, copy all data where it needs to be from the comfort of your office. Doublecheck you got it right.
- when disassembling equipment, label all interconnects, in order, unless every box is flat on a local net, with nothing hanging off of them. Don't forget routers, and don't assume it's stupid to label something obvious. Assume you're going to be brain dead when you put it back together - if something unexpected happens (someone flips the truck?), you will be brain dead. And even if you're not, it does help, esp. with messy SCSI configs, etc.
- Write out a timeline, and give yourself more time than you need. Make sure other people concerned know what it is.
- Oh, _back up your machines_. I know, it is obvious, but I know of one company that screwed this up royally.
- Bring one more person than you need. They might be helpful, and if not, they can at least fetch coffee and donuts when you need them.
- Bring snacks, lots of them.
- Convince your accountant insurance is worth it, if they don't belive it already. We were moving ~2M worth of gear, and I would have been even more freaked out than I was if we hadn't insured it while it was being transported.
- Have a wad of company cash/credit card on hand. You never know what comes up.
- Ditto for spares, whatever you can - is that disk that's been spinning for 4 years going to come back up? Cat 5?
- If you have heavy gear, think about whether or not you're going to move it yourself.
- Overplan it. You'll be glad. Think contigencies and fall back positions.
- Make sure your staff is well rested before you do it, and that they have whatever they need before you start.
Slashdot Mirror
When you can dance as well as Britney Speers, you can make fun of her. Until then shut up.
I would also like to locally cache the data I receive from the LDAP directory. Are there any solutions for doing that? Or should I just cache the data in a SQL database running locally on the WebApp server?"
Caching locally in an SQL database is not going to be very efficient - as a general rule, LDAP reads are going to be faster than SQL reads. Caches are for speed, not reliability. If time on wire is your concern, run a local LDAP slave. For raw speed, use MLDBM or similar for your cache - you really can't get much faster without writing an application specific cache that sits in memory.
Funny you should be posting to an article on selfish routing....
Break it apart.
The claim is that something vital for humanity is happening. Like, say, making food, or doing cool things in space.
The claim further assumes that someone doing accepts risks and does so for whatever fame and glory they can get.
Contrast this with my statement, which I intended to be an amusing sideline, with a little bit of actual pointy bits here and there, towards the end.
Let me know when you get the point. Maybe, then we can actually talk about what it takes to be a hero.
I like Bruce a lot. He's a very smart man. I have talked to him before, but I doubt he remembers it.
That book is a nice read. One should know going into reading it that it is an ad for his company. I don't think Bruce saw it happening that way, but it did. I do think he's telling the truth as he sees it.
Sorry I can't give a black-and-white comment here.
It is still a great book.
Please come back when you supported your career on the worth of your published papers.
Thank you, drive through.
I'm not saying that's right or proper, but it is a fact.
So, getting publicity is not needed to be a hero(tm). Putting yourself at risk in the service of your fellow man is.
So, when I was nearly killed working in a tomato field, I'm a hero? Cool. Because I was Working For My Fellow Man, being hit by a tractor makes me a hero.
Reality check follows.
Heros are those who get lots of attention, who happened to do something cool, or foolhardy, or lucky. People like to look at them and think they'd do something similar. Nation states like to memorialize them to encourage certain behaviour.
I'm not disupting that heroes exist. I have several, personally. I do agree that the shuttle crew were not heroes.
My first thought was the "read/write" MRIs featured in Vinge's _A Deepness In The Sky_.
rewster: I have yet to see a reasonable argument why anyone "needs" it.
Pot has been shown numerous times to be beneficial for a number of maladies not addressed by other medication. I'm not going to cite links becuase I'm sure you're aware of them. If not, Google is your pal.
Me: By the way, can you explain in clear, concise terms why pot _should_ be illegal?
rewster: Explain to me first why it should. Studies have shown the kind of damage it does to the human brain - so tell me how that's beneficial to anyone? And why people with certain diseases should be allowed to use it, then?
Ok, here is why is should be legal. I'm holding you to your side of the bargain - you have to explain in clear, concise terms why pot should be illegal.
It should be legal because we live in a country based on the concept that the individual knows best what is good for them. Roughly, one should be able to go to hell in thier own way, so long as they don't take others with them. We allow people do drive motorcycles, have dangerous sex, climb rocks, drink too much, and drop out of school. Even if pot were so harmful that it was worse that alcohol or cigarettes, it should still be legal. That the drug trade is dangerous to others is a self-referential argument - if it were legal, there wouldn't be crime surrounding the trade.
So, now it is your turn - please explain in clear, concise turms why pot should be illegal. I accepted your turn around, and answered you. Please pay me the same respect.
-j
Is there a client for Linux? Doesn't look like it.
Seriously, everybody assumes that since someone is - coincidentally - furthering the interests of people who are in pain, they're doing the world a big favor, when they're probably in it for themselves.
I'm running a business hoping to make money. Does that mean that when I open source things, I'm not doing something good? Think before answering.
By the way, can you explain in clear, concise terms why pot _should_ be illegal?
I was the winning bidder on an item.
The seller and I exchanged info.
I sent a check.
I did not get product.
After bitching to the seller, I posted negative feedback on eBay.
The seller freaked out and demanded that I retract my statement. (Not sure that's possible, honestly).
I responded via email saying I am just stating facts, that my check was deposited, and that I had no goods to show for it, and then...
I AM NOT RESPONSIBLE FOR THE MAIL IF YOU DONT TAKE DOWN MY NEGATIVE RATIN I WILL SSUE YOU INTO THE GROUND.
I am not making this up.
I asked the person to sue me. I also mentioned that I've been in touch with barristers that might have an interest, and hinted that if my cash came back, I may not attack.
I got a premium on my cash. The lawyers asked me if I'd work on another project. I said no.
(Don't do this if you don't, actually. have a lawyer, it can go horribly wrong. Take the advice they give you if you do have one. Get one if you don't. IANAL, etc.)
I was essentially placing bets on behaviour of marketing droids. They have to be able to predict, and to control, in order to do the jobs they do.
My comments were about the intersection of marketing and math.
Unfortunately, I'm far from my reference material right now. I'd love to verify that RSA and MD5 have nothing to do with each other, but I can't be bothered to go through the source I have on hand before I go to bed. I'll note, though, you're mounting a theoretical attack, rather than one that takes into account the timing imperetives of the problems a Brittny campaign might have.
Moor(e)'s law is great, and fine, but it does not speak to advances in math. (It doesn't speak very well to the advances in circuit design, but that's a different discusion.)
My point is just this - I want to mimick a cryptographically sound sum, in order to dupe a downloader into wasting time, and/or hearing my sales pitch.
If I have a distributed clearing house of sums, that cannot happen, if you use an approved(tm) sum, such as MD5 or SHA.
A clearing house (which can be like DNS, and shoudl be) can provide multiple answers. The user can pick and choose.
I've been working on this problem from a different angle, nothing to do with file transfer, but it isn't that hard (and no, the code isn't open source, yet. We have to make money first). But there's no reason typing at one another is different than transfering files. It is all in how you match people up.
Directed graphs are cool. So are reputations.
Think about it hard. I'm up for the game. I think I'll find out I'm right.
Insert doing-too-many-things-at-once-witticism here.
Another interesting note for things like this is that estimates of cost-per-attack calculations is that they apply over an average - you might collide on the first trial or you might have to cover the entire keyspace for a given run.
That fact does not co-exist well with carefully timed media blitzes. If Brittney's new album is proving to be difficult to poison (the collisions for some of the rips are statistically landing on the wrong end of the curve), an attacker may be forced to throw additional resources at those problems, thus doing fewer other songs, in order to make sure the marketing timeline from Jay Leno to concerts to ads with Pepsi goes well.
I don't think poisoning P2P is vital enough for those considerations to be terribly important right now. Still is a simple cost analysis, but marketing would probably be pissed.
-j
In general, I fully agree with what you're saying.
But one nit is that (and I'm not verifying your math, this is Slashdot, but it does feel right) it isn't 1000 songs/month that could be targeted, but 1000 files/month. If you assume you're only targeting, say, the 5 most popular rippers at the 3 most popular bitrates, that's 1000/15= 67 songs/month.
This sort of thing would work better for things that don't survive lossy compression, like software.
-j
Yes, a birthday attack on MD5 is fairly 'easy', but only when compared to the problem you're not solving: finding a string of bits that MD5s to a specific checksum. In a birthday attack, you don't care what the checksum is. When finding a file to match an MD5 checksum, you do.
Another reason why MD5 is useful here is that it is extremely likely that even if you generated a collision for a specific hash, it would likely look nothing like an MP3. Therefore, P2P software could trivially check that there was a valid MP3 header as the file was being transfered, and abort if it didn't.
There have been some interesting attacks on MD5 that don't look good for the long-term viability of MD5, but at this point they are soley theoretical.
Cryptography is cool.
**
The MD5 of this post, above the "**", is 0b82e0e6df9eec5502de3c094b994e39. If you can post something that matches that, you've got an awfully cool paper to write.
For starters, check out
http://cypherpunks.venona.com/
Most material is second hand, but as you read, you get a good feel of things.
There's also a huge amount of garbage there.
I've been a subscriber, most of the time, since 1994, although it usually isn't a good idea to post unless you have a lot of time to fight with a bunch of nuts.That said, it is a very good source of opinions, and once in a great while something very interesting happens (RC4 was disclosed anonymously a log time ago, for instance).
We were doing some slightly bizarre things, in the way that only sites that are long lived and creative can become. One of my personal cliches is "backwords compatibitity with your company's code is your worst nightmare". Among other things, we were interoperating with a pile of code written by a departed contractor written in ADL. I am not making this up.
.cf until it did what I wanted, and turn that into something reasonably reasonable as a define statement, so that we could upgrade without losing hair or teeth.
My normal pattern was to hack the
Don't get me started on when we had to hack the source to get something that would check a remote site for the existance of a given username... _that_ was bad.
In any case, yes, sendmail has a long history of being inclusive, reasonable, and solid. I think people who badmouth it do so because they don't understand it.
That's Apache::Mason curling up and (croke|die)ing.
Looks like the coder is trying to be a good citizen, and either the database can't handle the load, or Apache is running out of swap. Or, there's a dumb captialization problem in the use statements or somesuch.
Sorry, I've just been doing too much of this lately. "Stop me before I debug again"...
I have to disagree.
.cf file, the flexibility, and tweakability of sendmail is astounding. Not everyone needs it, but when you do, sendmail rocks.
Sendmail kicks ass.
In a former life, I had to build a mailing list manager that handled content generation, sub/unsub, bounce management, etc. for a large number of mailing lists that had to do about 1.3 million messages in 4 hours.
Without going through the whole set up, there were slave boxes that just delivered mail. They used pieces of postfix, which did a good job (I like postfix, BTW, my current company's primary mail server uses it).
The primary machine used sendmail. Once you get over the horror of writing a
A lot of people who don't really know what they're talking about rag on sendmail, echoing some very valid complaints that are mostly only of historical interest now. The most valid complaint these days is that it is arcane to configure. My take is, sure, it is, as it should be. Handling large volumes of email is second only to nntp for placing a heavy load on all sections of a network. If you don't know what you're doing, you shouldn't be doing it.
I use postfix because it is easy now, we're only handling a few thousand messages a day.Should that change, I'm back with my old pal sendmail.
There's so much confusion going on that I'm not even going to try to sort it out. A couple of hints -
Trademark does indeed need to be defended in order to be help as such. That has nothing to do with IP or trade secrets (two different things).
Trade secrets are only enforced contractually. They have no special protection. A leak is a leak - if you leak a trade secret to me, you can be held in violation of any contract in place, but I can do whatever I want with the information. (If you don't believe me, google on "+RC4 +cypherpunks +RSA +anonymous")
IP means a large number of different things, with patents being a large centerpiece. This case has nothing to do with IP.
In short, defending contractual agreements has nothing to do with one's brand from a legal standpoint. Try not to get confused in the future.
-j, not a lawyer, etc.
Full feedback loops that control a real world robot is interesting. Maybe not earthshaking, maybe not the Evil Robot Army we all want to have, but it is a big deal.
Sure, you can grow a cell-culture somewhere, and it may even have some of the same attributes as the real thing grown from the same cells. But it lacks it's overall organization
I think that's the point, and for a wider audience than the ones who want replacement eyeballs and Evil Robot Armies.
Learning how cognitive cells self-organize and interact with the real world is both a dazzling chance for more study and really, really fucking creepy.
-j
2. Turn it into ns1 (import records,etc), turn off ns1 at old location
3. Update host records for ns1 with Tucows and Internic
I'm REALLY nervous about running on one name server for the few hours between moving. I also have an irrational fear that when I transition ns1 to its temporary home, it will cause a rift in the time-space continuum making all of my site inaccessable.
Is it advisable to bring ns0 up with the rest of the equipment and skip the redirect?
If I'm following you, I wouldn't be too concerned with running on one name server for a short time. The odds of something going wrong on it in that period is lower than the odds of something else going wrong.If it makes you really nervous, have the redirect server also do DNS for that period, although that slows you down - you'll have to wait for Tucows or whoever to make an additional change.
As for fears of transitioning ns1, what I'd do is not turn off the old ns1 until after you're sure that the new one is being used - wait until the host record update goes through and you see zero traffic on the old one to turn it off.
Another hint I thought of:
- if you can get away with it, institute a configuration freeze several days before the move, and reboot everything you can at the old place. I wish I had done thing - several machines had very long uptimes, and people had made changes that caused problems when we brought them back up at the new location. If you can test them one at a time, you might save yourself some grief.
Good luck
-j
Every site is different, with different services, operator skill sets, requirements, demands, and cash.
Lay out your priorities. You say "everything has to stay up" - maybe that's true, but I moved a rather large commercial site stuck in one colo elsewhere, in pieces, when we had a *lot* of money, and when cost analysis started being done, it turned out we could afford downtime.
Look at your traffic records, worry about what has to be up and what doesn't. Think *hard* about dependencies.
Perhaps you can afford two trips (which is what we did), in which case, you move a skeleton crew to the new site (pre configured and tested, of course) , switched DNS (you did think about your TTL, yes?), waited for it to be picked up from a site I knew had not cached the DNS, and completed the move.
Perhaps you can buy/borrow from the office/use spares (but be careful about occupying your spares!) for the move.
Perhaps you can offload the bulk of your traffic elsewhere (Akamai or something to move the demand on machines off the machines while you're doing it.)
I can't speak to your situation, but there's always a way to make it work - like I said, it is pure operations. Analyse, plan, plan again, execute.
More hints -
- Before you're slouching in the colo breaking down the network, copy all data where it needs to be from the comfort of your office. Doublecheck you got it right.
- when disassembling equipment, label all interconnects, in order, unless every box is flat on a local net, with nothing hanging off of them. Don't forget routers, and don't assume it's stupid to label something obvious. Assume you're going to be brain dead when you put it back together - if something unexpected happens (someone flips the truck?), you will be brain dead. And even if you're not, it does help, esp. with messy SCSI configs, etc.
- Write out a timeline, and give yourself more time than you need. Make sure other people concerned know what it is.
- Oh, _back up your machines_. I know, it is obvious, but I know of one company that screwed this up royally.
- Bring one more person than you need. They might be helpful, and if not, they can at least fetch coffee and donuts when you need them.
- Bring snacks, lots of them.
- Convince your accountant insurance is worth it, if they don't belive it already. We were moving ~2M worth of gear, and I would have been even more freaked out than I was if we hadn't insured it while it was being transported.
- Have a wad of company cash/credit card on hand. You never know what comes up.
- Ditto for spares, whatever you can - is that disk that's been spinning for 4 years going to come back up? Cat 5?
- If you have heavy gear, think about whether or not you're going to move it yourself.
- Overplan it. You'll be glad. Think contigencies and fall back positions.
- Make sure your staff is well rested before you do it, and that they have whatever they need before you start.
Hope this helps.
-j
But then I'd have to compete with you.