RE: Megaupload.com seized
> This is what disaster simulations are for, to suss out these problems > before a disaster and put in systems to avoid the mess. > > In the real world, while a city might keep the digital documents "in > the cloud" they would also (always) have paper copies, because in a big > emergency their computers (local mail/file servers or internet access > to the cloud) are likely to be unavailable, power or internet access is > likely to be disrupted. Nope, no paper copies. In fact, many of the documents such as maps and drawings are not even provided on paper anymore at any stage of the process. It's all electronic. The engineering drawings, maps, reports, plans, everything's electronic copy now. If you want a copy to take to the field, you print one off and dispose of it when done unless you keep it in your personal storage (desk file drawer). > In a true emergency such as Loma Prieta, they > are going to reach for the paper maps that were printed and saved for > just this eventuality Nope, the paper maps have been disposed of as they have become obsolete and replaced with electronic copy. It requires space to store all those documents. Space costs money. I'm being absolutely serious here. Not only are many of these municipalities no longer storing paper copies, they are storing them "in the cloud" that might become completely unreachable during an emergency. My jaw just about hit the floor when it was explained to me what one town in California was doing. Those people are going to be just about completely helpless in an emergency but they are doing it because they are running out of money. Pensions are eating that town alive. Their emergency drills do not include a loss of connectivity to the cloud. > CERT is a great program and will really help open your eyes > to many types of emergency planning you probably haven't thought about. > Plus, the more involved you are with CERT the more you are "known" to > your local disaster management teams, and the better access you will > have to them in the event of a major disaster. > I am talking here about the process internal to the government agency, not drills concerning the public. In case of an emergency where they are cut off from Google, that town government will have no email and no access to their documents. They have no other mechanism, they can't afford it. The days when a city could actually have contingency plans are just about over. Pensions are eating them up so badly, they are just barely able to function at all. I'm being dead serious. Larger cities such as San Jose have about 10 years left. The Mayor of SJC said that in about 12 years the city will not be able to provide any services whatsoever. Pensions will take 100% of city revenue. They have already started closing the libraries.
Re: Megaupload.com seized
On 01/21/2012 12:19 PM, George Bonser wrote: Sure, but balance that with podunk.usa's possibly incompetent IT staff? It costs a lot of money to run a state of the art shop, but only incrementally more as you add more and more instances of essentially identical shops. I guess I have more trust that Google is going to get the redundancy, etc right than your average IT operation. Now whether you should *trust* Google with all of that information from a security standpoint is another kettle of fish. Mike I agree, Mike. Problem is that the communications infrastructure that enables these sorts of options is generally so reliable people don't think about what will happen if something happens between them and their data that takes out their access to those services. Imagine a situation where several municipal governments in, say, Santa Cruz County, California are using such services and there is a repeat of the Loma Prieta quake. Their data survives in Santa Clara county, their city offices survive but there is considerable damage to infrastructure and structures in their jurisdiction. But the communications is cut off between them and their data and time to repair is unknown. The city is now without email service. Employees in one department can't communicate with other departments. Access to their files is gone. They can't get the maps that show where those gas lines are. The local file server that had all that information was retired after the documents were transferred to "the cloud" and the same happened to the local mail server. At this point they are "flying blind" or relying on people's memories or maybe a scattering of documents people had printed out or saved local copies of. It's going to be a mess. The point is that "the cloud" seems like a great option but it relies on being able to reach that "cloud". Your data may be safe and sound and your office may have survived without much wear, but if something happens in between, you might be sunk. And out in "Podunk", there aren't often multiple paths. You are stuck with what you get. Or your cloud provider might announce they are going out of that business next week. The problem is that the local infrastructure might just as easily get taken out too. Here in SF, I'm sure that the entirety of the data center capabilities aren't, say, housed in city hall itself, so we're just as vulnerable to partition whether they run their own infrastructure as we would be if we hosted in the "cloud" too. The larger issue here is diversity and resilience. The internet is guaranteed to fail us at the worst possible time, full stop. We need to make certain that we keep at least _some_ terribly inefficient and thoroughly antiquated means of doing the same thing viable for critical tasks. When I was at Cisco, there was a push to getting emergency responders to coordinate their communication infrastructure both for cross coordination as well as of course cost down. Makes perfect sense... so long as the unthinkable doesn't happen (ie the internet failing us). That's why our new IP monoculture sort of gives me the creeps. Mike
Re: Megaupload.com seized
Well I have a question which is off the top of megaupload.com But it's regarding governments around the world using cloud services. Do we have others Canadians on this list who can confirm, what branches of the Canada Government are actively using public cloud services like google cloud services. or are in the process are currently setting it up. -Original Message- From: Matthew Kaufman Sent: Sunday, January 22, 2012 12:49 AM To: George Bonser Cc: nanog@nanog.org Subject: Re: Megaupload.com seized On 1/21/2012 12:19 PM, George Bonser wrote: I agree, Mike. Problem is that the communications infrastructure that enables these sorts of options is generally so reliable people don't think about what will happen if something happens between them and their data that takes out their access to those services. Imagine a situation where several municipal governments in, say, Santa Cruz County, California are using such services and there is a repeat of the Loma Prieta quake. Their data survives in Santa Clara county, their city offices survive but there is considerable damage to infrastructure and structures in their jurisdiction. But the communications is cut off between them and their data and time to repair is unknown. The city is now without email service But fortunately the data is also replicated in another data center nowhere near the quake, so once they pull out the mobile emergency operations center and aim the VSAT dish, they're back online with everything as it was moments before the quake hit... far superior to what formerly happened when the power or phone lines were down at their own facility, never mind what would have happened if their own facility with its infrequent backups to unreliable tape were destroyed. Matthew Kaufman
Re: Megaupload.com seized
On 1/21/2012 12:19 PM, George Bonser wrote: I agree, Mike. Problem is that the communications infrastructure that enables these sorts of options is generally so reliable people don't think about what will happen if something happens between them and their data that takes out their access to those services. Imagine a situation where several municipal governments in, say, Santa Cruz County, California are using such services and there is a repeat of the Loma Prieta quake. Their data survives in Santa Clara county, their city offices survive but there is considerable damage to infrastructure and structures in their jurisdiction. But the communications is cut off between them and their data and time to repair is unknown. The city is now without email service But fortunately the data is also replicated in another data center nowhere near the quake, so once they pull out the mobile emergency operations center and aim the VSAT dish, they're back online with everything as it was moments before the quake hit... far superior to what formerly happened when the power or phone lines were down at their own facility, never mind what would have happened if their own facility with its infrequent backups to unreliable tape were destroyed. Matthew Kaufman
Re: Megaupload.com seized
On Jan 21, 2012, at 8:00 PM, Jay Ashworth wrote: > - Original Message - >> From: "Lyle Giese" > >> Not that I would not be a bit miffed if personal files disappeared, but >> that's one of the risks associated with using a cloud service for file >> storage. It could have been a fire, a virus erasing file, bankruptcy, >> malicious insider damage... Doesn't matter, you lost access to legit >> content in the crossfire. > > I'm not sure this is actually true. The Law generally recognizes 'accident' > as a means for relieving people of responsibility for criminal acts -- it > can't *be* a criminal act without scienter on the part of the doer. Actually, that's often not true in recent laws. There was an article in the Wall Street Journal a month or so ago that gave some glaring examples of not just laws but actual convictions. > > In this case, the doer was negligent, rather than purposefully malicious, > but we have solutions for that as well. I'm not sure what you mean by "doer" here. http://opinion.latimes.com/opinionla/2012/01/copyrights-feds-push-novel-theories-in-megaupload-case.html has an interesting analysis. It presents a number of factual statements that are capable of multiple interpretations. This in turn means that much of the case is likely to turn on scienter, which in turn means heavy reliance on the seized emails. This will be an interesting case to watch. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: Megaupload.com seized
On 21/01/12 12:19 PM, George Bonser wrote: Imagine a situation where several municipal governments in, say, Santa Cruz County, California are using such services and there is a repeat of the Loma Prieta quake. Their data survives in Santa Clara county, their city offices survive but there is considerable damage to infrastructure and structures in their jurisdiction. But the communications is cut off between them and their data and time to repair is unknown. The city is now without email service. Employees in one department can't communicate with other departments. Access to their files is gone. They can't get the maps that show where those gas lines are. The local file server that had all that information was retired after the documents were transferred to "the cloud" and the same happened to the local mail server. At this point they are "flying blind" or relying on people's memories or maybe a scattering of documents people had printed out or saved local copies of. It's going to be a mess. This is what disaster simulations are for, to suss out these problems before a disaster and put in systems to avoid the mess. In the real world, while a city might keep the digital documents "in the cloud" they would also (always) have paper copies, because in a big emergency their computers (local mail/file servers or internet access to the cloud) are likely to be unavailable, power or internet access is likely to be disrupted. In a true emergency such as Loma Prieta, they are going to reach for the paper maps that were printed and saved for just this eventuality, and part of the emergency preparedness is to have a regular process to print and save updated maps (every year or 6 months or month or whenever there's a major change - each department will undoubtedly have their own metrics depending on how critical their maps are). If you haven't participated in your city/county CERT training and disaster simulation exercises, I highly suggest you get involved. CERT is a great program and will really help open your eyes to many types of emergency planning you probably haven't thought about. Plus, the more involved you are with CERT the more you are "known" to your local disaster management teams, and the better access you will have to them in the event of a major disaster. jc
Re: Megaupload.com seized
- Original Message - > From: "Joly MacFie" > Technical nuances notwithsatnding, isn't the guts of the case that the > megaupload team wilfully engaged in harbouring infringing files as > evidenced by the email snooping, eg boasting to each other about > having feature movies available prior to release etc. That appears to be the case at this time, based on things which are hearsay to we the public, and should not have been released. But "has a substantially non-infringing use" is, if not a defense, a fact which should have made them *much* more careful in how they did the take down, a response which is all of a piece with our objections to SOPA. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Megaupload.com seized
- Original Message - > From: "Donald Eastlake" > I have always had a certain fondness for paper. Well, I was wondering where the Whacky Weekend thread was this week. "You can't grep dead trees." Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Megaupload.com seized
- Original Message - > From: "Lyle Giese" > Not that I would not be a bit miffed if personal files disappeared, but > that's one of the risks associated with using a cloud service for file > storage. It could have been a fire, a virus erasing file, bankruptcy, > malicious insider damage... Doesn't matter, you lost access to legit > content in the crossfire. I'm not sure this is actually true. The Law generally recognizes 'accident' as a means for relieving people of responsibility for criminal acts -- it can't *be* a criminal act without scienter on the part of the doer. In this case, the doer was negligent, rather than purposefully malicious, but we have solutions for that as well. I hope that we don't see a class-action lawsuit against the feds... I wanna see them have to defend each case individually. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Megaupload.com seized
On 01/21/2012 03:28 PM, Joel jaeggli wrote: On 1/21/12 11:38 , George Bonser wrote: Entire governments in the US are using "cloud storage" for their documentation these days. It is my understanding (which is hearsay) that Google has an entire service aimed at small governments (county and municipal mostly) in Google Docs for just this purpose and I know of at least one city on California that is using Google for their document repository and their city email. In case of an emergency where Google is unreachable, they are in a world of hurt and won't even be able to send email from one department to another in city hall because all their mail and documents are now "in the cloud" which would then be inaccessible to them rather than on a server in their local data center. So ... and Earthquake in Santa Clara county might take out city governments in Monterey or Santa Cruz counties which might otherwise be perfectly able to conduct their business. Point is, MANY people are using "the cloud" as their primary storage because it is marketed as being safe and secure (backed up and with better access security than they could manage themselves). It may also be the case that your cloud service may be uncoupled from the fate of your geography which may will allow it to survive a regional failure that might otherwise render you inoperable. All eggs in one basket is to my mind a bigger problem than who's basket they're in. If your network is wiped out it may not matter where the data is from an availability perspective unless alternatives are in place. I think that the larger issue here is resilience. If you're completely dependent on IP, then when IP fails you're hosed. We have a situation where that is becoming more and more true, however. When the last vestiges of TDM are rooted out of the telephony network, we will be less resilient than before. When paper record trails are replaced by the cloud, we are less resilient. It's sort of scarey in some ways how much of an information monoculture we're building: it's a huge strength and a glaring vulnerability. Mike
Re: Megaupload.com seized
On 1/21/12 11:38 , George Bonser wrote: >> Not that I would not be a bit miffed if personal files disappeared, >> but that's one of the risks associated with using a cloud service >> for file storage. It could have been a fire, a virus erasing file, >> bankruptcy, malicious insider damage... Doesn't matter, you lost >> access to legit content in the crossfire. >> >> There is always a risk of losing access to cloud resources. And >> for years, we always joked in my computer buddy circles, computers >> know when you don't have a backup. >> >> It's your fault(not theirs) if that was your only copy. >> >> Lyle Giese LCR Computer Services, Inc. > > Entire governments in the US are using "cloud storage" for their > documentation these days. It is my understanding (which is hearsay) > that Google has an entire service aimed at small governments (county > and municipal mostly) in Google Docs for just this purpose and I know > of at least one city on California that is using Google for their > document repository and their city email. In case of an emergency > where Google is unreachable, they are in a world of hurt and won't > even be able to send email from one department to another in city > hall because all their mail and documents are now "in the cloud" > which would then be inaccessible to them rather than on a server in > their local data center. So ... and Earthquake in Santa Clara county > might take out city governments in Monterey or Santa Cruz counties > which might otherwise be perfectly able to conduct their business. > > Point is, MANY people are using "the cloud" as their primary storage > because it is marketed as being safe and secure (backed up and with > better access security than they could manage themselves). It may also be the case that your cloud service may be uncoupled from the fate of your geography which may will allow it to survive a regional failure that might otherwise render you inoperable. All eggs in one basket is to my mind a bigger problem than who's basket they're in. If your network is wiped out it may not matter where the data is from an availability perspective unless alternatives are in place. > >
Re: How are you doing DHCPv6 ?
On Sat, Jan 21, 2012 at 1:05 PM, Randy Carpenter wrote: > Several people have mentioned clustering software. Does any one have any > examples of such a thing that supports v4 and v6? > > Linux-HA, RSF-1, Oracle Solaris Cluster, Veritas cluster, are a few examples of clustering software. ocf_heartbeat_anything + ocf_heartbeat_IPv6addr http://linux-ha.org/doc/man-pages/man-pages.html Obviously, building a DHCPD failover cluster involves some scripting and significant design considerations, but as far as clusters go, DNS and DHCPD failover clusters are very simple. And don't require special application support to achieve redundancy, unlike, say Firewalls, SQL, FTP, SMTP or HTTPD clusters, where a requirement may exist not to drop a single TCP connection, or fail a single query, in case of server failure. DHCPD doesn't even use TCP connections; and some amount of automatic retry by the client is a feature of the protocol. Database servers, HTTP, Firewalls, etc, are "stateful services", because there is an "in-flight" status which is not recorded in a database, and must be preserved by the application itself for graceful failover. If the Firewall connection table is not synchronized online, the failover between clustered firewalls would cause a disruption in the form of lost TCP connections, and online users will experience an immediate temporary issue at the moment of failover. The same for HTTP... a TCP connection dropping is a "permanent" error. The in-flight transactions would result in the user seeing an error page. Those are the types of applications that actually require special support or coordination from the application itself. Graceful DHCPD failover to deal with server issues can be achieved by using one of the open source or commercial clustering packages, plus a little bit of scripting. -- -JH
Re: Megaupload.com seized
I have always had a certain fondness for paper. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Sat, Jan 21, 2012 at 3:19 PM, George Bonser wrote: >> >> Sure, but balance that with podunk.usa's possibly incompetent IT staff? >> It costs a lot of money to run a state of the art shop, but only >> incrementally more as you add more and more instances of essentially >> identical shops. I guess I have more trust that Google is going to get >> the redundancy, etc right than your average IT operation. >> >> Now whether you should *trust* Google with all of that information from >> a security standpoint is another kettle of fish. >> >> Mike > > I agree, Mike. Problem is that the communications infrastructure that > enables these sorts of options is generally so reliable people don't think > about what will happen if something happens between them and their data that > takes out their access to those services. Imagine a situation where several > municipal governments in, say, Santa Cruz County, California are using such > services and there is a repeat of the Loma Prieta quake. Their data survives > in Santa Clara county, their city offices survive but there is considerable > damage to infrastructure and structures in their jurisdiction. But the > communications is cut off between them and their data and time to repair is > unknown. The city is now without email service. Employees in one department > can't communicate with other departments. Access to their files is gone. > They can't get the maps that show where those gas lines are. The local file > server that had all that information was retired after the documents were > transferred to "the cloud" and the same happened to the local mail server. > At this point they are "flying blind" or relying on people's memories or > maybe a scattering of documents people had printed out or saved local copies > of. It's going to be a mess. > > The point is that "the cloud" seems like a great option but it relies on > being able to reach that "cloud". Your data may be safe and sound and your > office may have survived without much wear, but if something happens in > between, you might be sunk. And out in "Podunk", there aren't often multiple > paths. You are stuck with what you get. > > Or your cloud provider might announce they are going out of that business > next week. > >
Re: Megaupload.com seized
On Jan 21, 2012, at 6:11 AM, Rich Kulawiec wrote: > On Fri, Jan 20, 2012 at 03:06:04PM -0500, Ricky Beam wrote: >> Upon receiving notice a file is infinging, they know that *file* >> is illegal, and must now remove all the links to it, not just the >> one that was reported. > > But what -- *exactly* -- is an "illegal file"? > > As Leo Bicknell astutely pointed out in this thread: > > "Also, when using a hashed file store, it's possible that > some uses are infringing and some are not." This is a personal anecdote, and I'm not really trying to take sides in this. But I think what Megaupload's problem was that when they were told that a specific file was not authorized to be distributed at all, they claimed they couldn't stop their users from reuploading it, could only prevent distribution of the file if you were somehow able to give them a list of all their URLs that held identical copies, etc. We had a client that had some data stolen - a laptop was physically stolen, and data from it uploaded to Megaupload. She jumped through the DMCA hoops to get them to take it down, they took more than 72 hours to finally remove it, and less than an hour later the same data was uploaded again. Another 72 hour wait to get them to remove it, rinse, repeat. We finally contacted someone there directly on our client's behalf, who insisted they had no ability to block specific files/hashes/etc -OR- locate additional identical copies on their system. If they didn't have this ability, it was because they were specifically trying not to, since they admitted elsewhere they hash everything that comes in to save space/time on their side, and writing something to block based on a hash they were already making would fall under pretty trivial work. Which may have been the MPAA/RIAA/etc's issue with them as opposed to Dropbox/etc. With Megaupload it was like playing whack-a-mole trying to get something removed, they kept trying to say with a straight face they couldn't stop it from happening, and actually paid uploaders of popular files to keep doing it. I'm not defending the practices of the copyright nazis, but Megaupload was frustratingly difficult to deal with in what should have been a very simple "The owner/creator of this file has not authorized it to be distributed anywhere, don't allow it on your service again" request.
RE: Megaupload.com seized
> > Sure, but balance that with podunk.usa's possibly incompetent IT staff? > It costs a lot of money to run a state of the art shop, but only > incrementally more as you add more and more instances of essentially > identical shops. I guess I have more trust that Google is going to get > the redundancy, etc right than your average IT operation. > > Now whether you should *trust* Google with all of that information from > a security standpoint is another kettle of fish. > > Mike I agree, Mike. Problem is that the communications infrastructure that enables these sorts of options is generally so reliable people don't think about what will happen if something happens between them and their data that takes out their access to those services. Imagine a situation where several municipal governments in, say, Santa Cruz County, California are using such services and there is a repeat of the Loma Prieta quake. Their data survives in Santa Clara county, their city offices survive but there is considerable damage to infrastructure and structures in their jurisdiction. But the communications is cut off between them and their data and time to repair is unknown. The city is now without email service. Employees in one department can't communicate with other departments. Access to their files is gone. They can't get the maps that show where those gas lines are. The local file server that had all that information was retired after the documents were transferred to "the cloud" and the same happened to the local mail server. At this point they are "flying blind" or relying on people's memories or maybe a scattering of documents people had printed out or saved local copies of. It's going to be a mess. The point is that "the cloud" seems like a great option but it relies on being able to reach that "cloud". Your data may be safe and sound and your office may have survived without much wear, but if something happens in between, you might be sunk. And out in "Podunk", there aren't often multiple paths. You are stuck with what you get. Or your cloud provider might announce they are going out of that business next week.
Re: Megaupload.com seized
On 01/21/2012 11:38 AM, George Bonser wrote: Entire governments in the US are using "cloud storage" for their documentation these days. It is my understanding (which is hearsay) that Google has an entire service aimed at small governments (county and municipal mostly) in Google Docs for just this purpose and I know of at least one city on California that is using Google for their document repository and their city email. In case of an emergency where Google is unreachable, they are in a world of hurt and won't even be able to send email from one department to another in city hall because all their mail and documents are now "in the cloud" which would then be inaccessible to them rather than on a server in their local data center. So ... and Earthquake in Santa Clara county might take out city governments in Monterey or Santa Cruz counties which might otherwise be perfectly able to conduct their business. Sure, but balance that with podunk.usa's possibly incompetent IT staff? It costs a lot of money to run a state of the art shop, but only incrementally more as you add more and more instances of essentially identical shops. I guess I have more trust that Google is going to get the redundancy, etc right than your average IT operation. Now whether you should *trust* Google with all of that information from a security standpoint is another kettle of fish. Mike
RE: Megaupload.com seized
> Not that I would not be a bit miffed if personal files disappeared, but > that's one of the risks associated with using a cloud service for file > storage. It could have been a fire, a virus erasing file, bankruptcy, > malicious insider damage... Doesn't matter, you lost access to legit > content in the crossfire. > > There is always a risk of losing access to cloud resources. And for > years, we always joked in my computer buddy circles, computers know > when you don't have a backup. > > It's your fault(not theirs) if that was your only copy. > > Lyle Giese > LCR Computer Services, Inc. Entire governments in the US are using "cloud storage" for their documentation these days. It is my understanding (which is hearsay) that Google has an entire service aimed at small governments (county and municipal mostly) in Google Docs for just this purpose and I know of at least one city on California that is using Google for their document repository and their city email. In case of an emergency where Google is unreachable, they are in a world of hurt and won't even be able to send email from one department to another in city hall because all their mail and documents are now "in the cloud" which would then be inaccessible to them rather than on a server in their local data center. So ... and Earthquake in Santa Clara county might take out city governments in Monterey or Santa Cruz counties which might otherwise be perfectly able to conduct their business. Point is, MANY people are using "the cloud" as their primary storage because it is marketed as being safe and secure (backed up and with better access security than they could manage themselves).
Re: Megaupload.com seized
On 01/21/12 12:38, George Bonser wrote: that was reported. But what -- *exactly* -- is an "illegal file"? As Leo Bicknell astutely pointed out in this thread: "Also, when using a hashed file store, it's possible that some uses are infringing and some are not." The problem is going to be the thousands of people who have now lost their legitimate files, research data, personal recordings, etc. that they were using Megaupload to share. http://torrentfreak.com/feds-please-return-my-personal-files-megaupload-120120/ Not that I would not be a bit miffed if personal files disappeared, but that's one of the risks associated with using a cloud service for file storage. It could have been a fire, a virus erasing file, bankruptcy, malicious insider damage... Doesn't matter, you lost access to legit content in the crossfire. There is always a risk of losing access to cloud resources. And for years, we always joked in my computer buddy circles, computers know when you don't have a backup. It's your fault(not theirs) if that was your only copy. Lyle Giese LCR Computer Services, Inc.
Re: How are you doing DHCPv6 ?
Several people have mentioned clustering software. Does any one have any examples of such a thing that supports v4 and v6? We have always used the built in failover in ISC dhcpd, and it works nicely. I don't understand why they felt it would not be needed in v6. -Randy On Jan 21, 2012, at 12:31, Jimmy Hess wrote: > On Sat, Jan 21, 2012 at 7:03 AM, Bjørn Mork wrote: > Randy Carpenter writes: > > Duplicate assignments are not a problem as long as you ensure that the > client is the same. > > Duplicate assignments to different clients also won't be established if your > standby server has access to an identical lease database at the moment > your clustering software determines that the primary server has failed, > kills the primary, and places the secondary in service. > > A sufficiently long lease duration should also be as good as a static lease, > in that case. > Because all the important details are in the database. > > You don't have to have any coordination in the DHCP software; you just in > some cases, need to exclude the DHCPD daemon from simultaneously being active > on multiple machines. > > > -- > -JH
RE: Megaupload.com seized
> > that was reported. > > But what -- *exactly* -- is an "illegal file"? > > As Leo Bicknell astutely pointed out in this thread: > > "Also, when using a hashed file store, it's possible that > some uses are infringing and some are not." The problem is going to be the thousands of people who have now lost their legitimate files, research data, personal recordings, etc. that they were using Megaupload to share. http://torrentfreak.com/feds-please-return-my-personal-files-megaupload-120120/
Re: How are you doing DHCPv6 ?
On Sat, Jan 21, 2012 at 7:03 AM, Bjørn Mork wrote: > Randy Carpenter writes: > > Duplicate assignments are not a problem as long as you ensure that the > client is the same. > Duplicate assignments to different clients also won't be established if your standby server has access to an identical lease database at the moment your clustering software determines that the primary server has failed, kills the primary, and places the secondary in service. A sufficiently long lease duration should also be as good as a static lease, in that case. Because all the important details are in the database. You don't have to have any coordination in the DHCP software; you just in some cases, need to exclude the DHCPD daemon from simultaneously being active on multiple machines. -- -JH
Re: Megaupload.com seized
In article <20120121121149.ga14...@gsp.org>, Rich Kulawiec writes But what -- *exactly* -- is an "illegal file"? Perhaps you mean "infringing"? -- Roland Perry
Fwd: [Argus] 190.144.248.64/27 is 'hijacked' by anomalous origin 'AS27817'
FYI, Argus detected a hijacking just now. It seems, I should send this email to South America NOG. -- Forwarded message -- From: argus-alarm Date: 2012/1/21 Subject: [Argus] 190.144.248.64/27 is 'hijacked' by anomalous origin 'AS27817' To: argus Prefix hijacking alarm: Start Time(UTC): Jan-21-2012 12:30:15 IP Prefix: 190.144.248.64/27 Origin AS change: AS14080 -> AS27817 Details: http://argus.csnet1.cs.tsinghua.edu.cn/fingerprints/90856/ ___ Argus mailing list ar...@csnet1.cs.tsinghua.edu.cn http://csnet1.cs.tsinghua.edu.cn/mailman/listinfo/argus -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Re: How are you doing DHCPv6 ?
Randy Carpenter writes: > DHCP is certainly not stateless, which is why there is a concept of > leases, which are stored in a file. You can't have 2 servers answering > for the same subnet without some sort of coordination, or you would > have a potential for duplicate addresses being assigned. Duplicate assignments are not a problem as long as you ensure that the client is the same. I.e. if the prefix delegating DHCPv6 server serves a statically assigned prefix to an end user based on information *uniquely identifying that user*, then you can replicate that setup to as many completely independent DHCPv6 servers as you like. Different end users will still not receive duplicate assignments. But if you want the DHCPv6 server to dynamically allocate a new prefix to each client, then you are up for problems of course. Don't see why you would want to do that though. Redundant DHCPv6 will be only one of many problems in such a setup. Bjørn
Re: Megaupload.com seized
On Fri, Jan 20, 2012 at 03:06:04PM -0500, Ricky Beam wrote: > Upon receiving notice a file is infinging, they know that *file* > is illegal, and must now remove all the links to it, not just the > one that was reported. But what -- *exactly* -- is an "illegal file"? As Leo Bicknell astutely pointed out in this thread: "Also, when using a hashed file store, it's possible that some uses are infringing and some are not." His example goes on to explain how this is so. (And I'll point out that his example applies, for example, to Amazon. There are coprighted files there -- e.g., books, music -- which may be used legally by those who have purchased them. Do they become infringing if someone finds a way to access them without authorization/payment because Amazon's programmers made an error and left a backdoor open that allow them to be retrieved via static links? No, they don't. Should Amazon delete them in this instance? No. Amazon should fix the backdoors, i.e., remove the spurious links.) Suppose that Joe and Jane are photographers. Joe has produced image X (to which he holds copyright) and Jane has produced image Y (similarly). Digital images X and Y are used as inputs to program P which produces output Z that is visually unrecognizable -- that is, anyone who looks at it sees what appears to be random noise. Does Z infringe on Joe or Jane's copyrights? How? Why? How does this change (or does it change) if program P' which can reverse the actions of P exists? Let me give another example, this time using content that is intrinsically illegal -- and to avoid triggering hot-button responses, I'm going to posit a hypothetical: marshmallow peep dioramas. Let's suppose that these are illegal in every country on the planet, that those responsible for them are universally reviled, that it's a crime to photograph them, possess photographs of them, etc. We thus conclude that a file consisting of a picture of one of these is always illegal: that is, it's illegal no matter where it's found. Now what happens if that picture is decomposed into individual files, each consisting of one row of pixels from the original? None of those files contain anything recognizable as a marshmallow peep diorama. The original cannot be reconstructed from any one of them. Is any one of them illegal? Further: reassembling these will require something: an index, an algorithm, some construct that allows the individual files to be recombined. (This construct contains no content of any kind, marshmallow peep or otherwise. It's merely a recipe for putting together files.) Is that construct illegal? If those individual files are spread across a multitude of hosts, are any of those hosts holding an illegal file? How would they know? (If you're going to argue that those individual rows of pixels are illegal because the original is illegal, then replace the above with "individual pixels". I trust nobody will argue that a single pixel is illegal. Ever.) One more scenario: a photo of a marshmalllow peep diorama is encrypted and uploaded onto server A. Does server A hold an illegal file? How would the operators of server A know? How would anyone (other than the uploader) know? Now suppose that the uploader, the only person on the planet with the decryption key for that file, dies; therefore, the file is reduced to -- for all practical purposes -- a random collection of bits. Is that file still illegal? Why? How? Who will be able to determine this? (Schrodinger's cat paradox in 1...2...) I posit these thought experiments (and I'll stop here, although many others suggest themselves) to highlight some serious problems with terminology, and with the law: it's an attempt to apply the principles of the physical world to the digital one, and it's a total failure. The putative sharp dividing line between "legal file" and "illegal file" doesn't really exist -- although many people would like it to exist, hope it exists, etc., because it serves their agendas or would make things easier for them. That doesn't make it so. Sometimes the world changes, and sometimes when it does, it's time to discard outdated philosophy that no longer applies to current reality -- because stubborn attempts to hang onto it at all costs, especially by warping it into something completely unrecognizable from the original framework, really DO cost, often dearly. (It's 2012, and there are still inferior people living on this planet who assign more credibility to astrology and ghosts than to evolution or anthropocentric global warming. This isn't funny or quaint any more. It's stupid and dangerous.) Schneier famously said "Trying to make bits uncopyable is like trying to make water not wet". What we are witnessing is precisely an attempt to do that, via a combination of anti-security technology (e.g., DRM) and purchased legislation, orchestrated by failing, legacy companies run by insatiably greedy people. These people simpl
Re: Argus: a hijacking alarm system
2012/1/21 Suresh Ramasubramanian > On Fri, Jan 20, 2012 at 10:45 PM, RijilV wrote: > >> A suggestion: pick a different name. There's already a network tool > >> named Argus (it's been around for years): http://www.qosient.com/argus/ > >> > >> I suggest using the name of a different Wishbone Ash album: "Bona > Fide". ;-) > > > Ha, there are already two with the name Argus: > > http://argus.tcp4me.com/ > > Argus being a many eyed dog from greek myth .. no surprise a lot of > tools that do this kind of thing have the very same name. > > Call it panopticon maybe? [nastier connotations - originally a prison > design by jeremy bentham where a warder sitting in the center could > see everything around him] > sounds cool :) panopticon > > --srs > > -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
Re: Argus: a hijacking alarm system
ah, bad news ~ too many Argus :) 2012/1/21 RijilV > On 20 January 2012 07:53, Rich Kulawiec wrote: > > On Fri, Jan 20, 2012 at 05:47:21PM +0800, Yang Xiang wrote: > >> I build a system ?Argus? to real-timely alert prefix hijackings. > > > > A suggestion: pick a different name. There's already a network tool > > named Argus (it's been around for years): http://www.qosient.com/argus/ > > > > I suggest using the name of a different Wishbone Ash album: "Bona Fide". > ;-) > > > > ---rsk > > > > Ha, there are already two with the name Argus: > > http://argus.tcp4me.com/ > > also been around for years... > > .r' > > -- _ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
