This is different. Cable companies are not blocking port 25 because they are trying to sell something competing. You could argue that blocking port 80 is because they are competing, but even then making the "you are doing this so you get the business instead" argument is hard to make stick.
With VOIP it is different. If an ISP is selling a VOIP offering and blocking the competitors, then they are using their blocking "to compete unfairly". With outbound mail thru SMTP, and to a lesser extent with the prohibition of web servers, the ISP is not trying to make another of their products more appealing.
Just imagine the uproar if Vonage paid ISPs to block UDP port 5060 destined to any network but theirs.
VOIP calls run exclusively over UDP packets. There is not a TCP packet to be found. SIP, or Session Initiation Protocol is a UDP handshake that is used to setup a connection. With consumer VOIP circuits, the client will send a SIP registration request to the SIP proxy server (Vonage in this case). The proxy server will reply with an OK. The actual payload of the UDP packets looks just like an HTTP transaction (complete with a GET and headers) and ditto for the reply. It is just not in a TCP stream. If a packet gets lost, then it is lost and the transaction does not happen.
The SIP client will nearly continually repeat this UDP registration followed by shorter "keep alive" exchanges. The idea is to keep any NAT router happy so that the channel now is end-to-end connected.
If the server needs to ring your phone, it now has an IP address and UDP port number that it can send a packet to. This then causes the SIP client to setup an RTP "connection". Again, these are UDP packets and TCP is nowhere to be found. The RTP connection is basically a set of UDP packets sent out very quickly. For a non-compressing codec (like G711.u [aka ulaw]), this means 50 UDP packets/second of about 220 bytes each. The packets go both ways at full speed (which is why VOIP does not work over dialup). There is no error detection. If a packet is lost, 20ms of voice is dropped.
So is a SIP client a server. I don't think so. I think it is wrong to describe a server as something that listens on a port. In the case of residential internet access, it is not the listening that the ISP does not like. It is the bandwidth and usage patterns. A better metric would be "is this a one to one communication". A web server is one to many. Ditto for streaming video. SIP is one to one. If you want to call SIP a server, then you should probably call an IM client a server as well.
What the ISPs are really doing is trying to figure out how to charge some people "more" when they can get away with it. It is not just "usage", but also an arbitrary categorization of what is residential access. From a purely network and traffic point of view, bittorrent should be the first thing outlawed. A local webserver on port 80 is nothing compared to a good torrent.
The other issue is "should an ISP be allowed to block competitors traffic". A lot of people argue against regulation of any kind. If you are one of these then you are a fool. If you leave a company completely without regulation, they will steal from you. There have to be limits to their behaviour. I have seen VOIP companies that claim, in the contracts, that they don't honor local number portability requests. They are saying that if you get a phone number from then that they will not give it up. Perhaps the regulations have not caught up to VOIP providers, but this policy is wrong, probably illegal, and the government should work to stop it. Similarily, if an ISP has a policy to hurt a competitors traffic so that their service works better, then that ISP is wrong. If this is not against the law, then the law should be enlarged to stop the practice. At the very least, this policy should be openly disclosed by the ISP to all of their customers up front.
It is about time for businesses to provide service to their customers instead of feeling like their customers are their property to leverage.
This type of discussion really worries me for "single owner" systems.
You have setup a system that will keep people away from the data unless you and only you try to access this. What happens if something happens to you. Your family might need your account numbers if you die, have a stroke, etc.
If you are protecting your child porn stash, then maybe this is the best solution. For things like credit card numbers, on-line banking, etc. you should "escrow" your passwords somewhere so that others can get to them if needed. This could be as simple as a printout of your passwords/accounts in your safe deposit box to having information kept by your lawyer.
Remember that bad things can happen beyond just hackers trying to get data.
And I am not just trolling for karma. My wife just had a friend die suddenly and one of the first questions from the family was "how do we get his laptops password". My anser was, "it depends, if he really secured it well, you are pretty much out of luck".
Frys are good and evil at the same time. They are good because they are very large stores with lots of decent computer hardware, including lots of components. You can buy processors, memory, resistors, MBs, you name it. Not quite an electronics distributor (they are more retail than that) but they have a lot of stuff.
The stores themselver are huge (the size of most large grocery chain stores [~80,000 sf - a guess]). They are typically split into three parts. Computer hardware and accessories occupy about 40% of the store. Software and things like DVS are about 20%. The rest is home and car electronics (everything from portable phones to big screen TVs). They have >40 checkout registers. When they open a new store, I have seen >1hr lines to check out that line the perimiter of the store.
The problem with Frys is both their size and the people they hire. They use commissioned salepeople that arguably dont have a clue. If you want a taste of this, do a good search on "frys electronics employment application". There are at least three versions floating around.
On the whole, I am glad that we have a local Frys. There prices are not the best, you absolutely dont want to use them for "advise", but they are local and they usually do have what you need.
I don't know where you are located, but around here, I would go to a high-end electronics dealer that dealt in in-car entertainment systems, the kind where the kids can watch TV in the back seat. You should be able to find a video-in LCD display from 5 to 10". Most will probably run off 12V power, but this is not that hard to get out of a PC PS.
Around here (Orange County, California) this would be Frys, Best Buy, or one of the independent auto shops. And if you mod me down because I said Frys, then I agree with your judgement.
If you look at the page on a mirror and examine is closely, it looks like the source HTML came straight from a "real" CNN page and the new story was cut and pasted in. Even the ads are real.
So, technically, the parody site does violate the copyright of CNN for the HTML "code" on the page. This is more than just layout as it includes javascript and even content management comments. Even the links were copied intact so that they are now broken. Basically, a lazy parody site that would not take the time to create an "original" parody and just cut and pasted instead.
Now, I still think that CNN is being incredibly "stupid" in pursueing this. I also think that the DMCA is dumb (on a lot of grounds in addition to) not requiring that the nature of an infringement be specified in a complaint.
So I think thenationaldebate just needs to be a little less sloppy and not just use "save as" with other peoples web sites. Make it look like who you are parodying, but write it yourself.
Your ground-source heat pump is not all that unusual. I used to live in central Florida (Cocoa Beach), and almost everyone ran water-cycle heat pumps from artesian wells. 70 degree water all year. The savings there was on air conditioning efficiency. Plus you could water your lawn with it.
We used to use Nagios here to monitor a large number of services on a large number of servers. We eventually agandoned it and replaced our "is the server up" monitoring with simple scripts that call fping. The problem with nagios is that the process model starts to fall apart at several hundred monitored servers/services and we really did not want to dedicate a farm to monitoring.
You can push the data using rsync. Load the Windows / cygwin version of rsync/ssh on the windows box. Then sync the whole box up to a debian directory over ssh. If you get fancy you can build rotation sets, etc. rsync is very efficient at moving only what changes, handling include/exclude lists, etc. Great for backing up lots of data.
Do a google search on "rsync windows backup".
The only downside is that rync will "kill" your upstream internet connection (it is that efficient). Fortunately, there is a --bwlimit option so you can back off a little.
If you are looking for a commercial hoster with all of the scripts pre-built we are happy to help (sorry for the AD), but it is pretty easy to roll this yourself.
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
Section 3 says that "you may copy and distribute the program".
But the subscription license says that if you copy or distribute the program, then you incur a penalty. Thus you are not "free" to copy or distribute the program. "Free" means gratis and "free" it means liberty. If you are blacklisted from a site, then you are not free.
What you are arguing is that Sveasoft is saying, "go ahead and distribute the program, and we will then cancel your contract." Regardless of how you parse this, Sveasoft is trying to hinder you from distributing the program, thus Sveasoft is trying to restrict your "excersise of the rights granted herein".
Perhaps in this case the call is close, but consider what would happen if someone larger is involved.
A hypothetical company has 50 servers running RedHat Enterprise Linux. They pay redhat $40,000/year and think that it is worth it. A departmental programmer is donating time to a small parish library who wants to use RHEL, but cannot afford it. This programmer gives the library the RHEL GPL packages (and leaves out any RedHat copyright packages). By your logic it would be acceptable for RedHat to cancel the 50 server RHEL contract.
The policy at Sveasoft is meant as a restriction. It is not 100% effective because Sveasoft does not own the packages. It is still a restriction to distribution rights regardless.
In order to get the software, you have to have a subscription. The subscription is a contract between Sveasoft and you. Because you cannot get the GPL software without this contract, the contracts terms impact your use of, and rights to the GPL software. Thus the two contracts are linked.
In this case, their are terms of the Sveasoft contract that do restrict your use of the software. They say that if you redistribute pre-releases of the software then you lose rights that you would note lose if you did not redistribute. The wording of the GPL is very clear:
You may not impose any further restrictions on the recipients' excercise of the rights granted herein.
In this case the meaning of the subscription and what it includes does not really matter. In order to get the subscription you need to agree to the subscription license and that license restricts what you can do with the GPL software. While it does not say that I cannot redistribute the software entirely, it definately impacts my "excersise of the rights granted herein".
Imagine for a second how this could abuse the GPL. By allowing two licenses to be tied together, I can sell 100% proprietary software that is GPL just by having a second license that creates a very onerous penalty if your redistribute, or load onto multiple systems, or make modifications, or log on too many times. RedHat (or Suse, or whoever) could threaten to cancel Enterprise Linux contracts for users that redistribute 100% GPL packages that are part of their updates (bye bye White Box Linux). If you argue that this is mearly an unrelated license, then you have allowed anyone to create 100% proprietary and closed GPL packages by just wrapping them in another license.
The GPL says that if you receive the code, you are free to redistribute it under the GPL. This policy does not allow you to "freely" distribute the code.
Consider a hypothetical license:
If you agree not to redistribute the package under the GPL the software
costs $50.
If you violate this agreement, the package costs $50,000.
The real problem here is that Sveasoft is not distributing the code under the GPL but instead under the GPL and under their license. This "combined" license is a modification to the GPL, which they cannot do.
The part of the GPL that is violated is:... You may not impose any further restrictions on the recipients' exercise of the rights granted herein....
While you can argue that terminating a "subscription" is not a restriction on rights. This is just wrong. If you get the code, you are free to do anything with it you want under the GPL. Except in this case, if you actually re-distribute the code, you are penalized for availing yourself of your rights.
If the FSF stated that their subscription policy was *not* a violation, they are wrong. Penalties for re-distribution is clearly a license restriction.
Hopefully, some group with actual copyrights (like the iptables people) will declare this policy in violation of the GPL and demand that Sveasoft stop.
Most shell accounts are disappearing because they are very unsafe for the hoster. Also, the prevelence of UML (User Mode Linux) lets hosters run virtual servers in security sandboxes so that the child application is more isolated from the host system.
UML virtuals behave like complete Linux servers with smaller RAM and disk sizes. You can load full distros and get a direct, public, IP address. Some hosters let you run IRC servers and some don't (many upstream providers hard-filter IRCD). In terms of software and services, you can run just about anything you want. Mail, FTP, ssh, IRC, Apache, Perl, PHP, MySql, etc. Plus you have full editors (vi, emacs) and compilers (gcc, java, etc.).
You can typically get these starting at about $12/mo. We sell them starting at $15/mo. They are more than shell accounts because the load you can place on a physical server is much smaller. In general, we only put 15-20 on a box to keep the underlying LoadAvg < 1.
I have walked thru it many times. It is basically a hallway with opposing doors that cannot both open simultaniously. Guards watch the interior making it difficult to wheel out lots of gear without being noticed. Now, if there were machine guns, they were well hidden;)
Many banks do run in Co-los. We have neighbors in the co-los we are in that are banks, insurance companies, medical, etc. And I would feel very comfortable with my bank locating in some of the co-los that we are in.
Case in point are co-los with "real" security. Savvis (formerly Exodus) in Los Angeles (actually El Segundo for those that care) has armed guards, card key access, hand scanners, more security cameras than you can count, and man traps. If you need more, you can get private cages, rooms, and even bomb-proof vaults. And if you know of a "regulation" that states that your internet-connected servers cannot be located in a secured facility with bonded armed guards, I would like to read that reg. Personally, I think your statement is just a continuation of the "myth" that co-los are somehow less secure. While no place is 100% perfect, co-los are much "more secure" than the back room at your office.
Remember, that when I say co-lo, I don't mean "cheap-ass-servers.com" (someone quick, go register this as it appears to be available). There are many high-quality co-los from companies like Savvis, Switch and Data, and others that are run extremely professionally. If you are lucky enough to be in a good co-lo, you will get better up-time than you could possibly hope for in-house.
Only for those few souls that are still running green-screen. And I really was not trying to advertise (at least not too much) but was trying to get people to think about what is possible.
If anything, my "real" motive is to keep people from putting servers in-house. If your office has the same "pipe", "power", and "security" as a good co-lo, then you spent too much money building it.
After all, there are millions of square feet of unused co-lo at rock-bottom prices just begging for more space-heaters (er, servers) to keep the resident space-heaters (er, servers) company.
My personal opinion is that trying to reach this level of redundancy for a lot of companies is just not practical and that there are much better approaches.
The idea here is to think of your internet connectivity as two different classes of services. You should place your internet reachable servers in a good co-lo. Get BGP lines from two different sources and multi-home the boxes. Don't run your own AS (use the upstreams space) but instead place your servers "close" to your provider's edge routers. In the end, you are BPGing the loop and it is hard for 100ft of cat-5 to fail. In the end, you have to ask yourself "Am I more qualified to keep my BPG up than is Level-3 (or Savvis... or AT&T... or MCI... or Sprint... or Cogent)".
In terms of your office, stick to client-only type services. Get two "diverse" connections. This might be a T-1 and a DSL, or a DSL and a cable modem. By using completely different architechures, you can get incredible diversity without spending a bunch of money. You can then IPSEC your local net over the client-only connection back to your addresses in the co-lo and with the help of a little client-side monitoring, auto-switch when a line goes down.
We offer something similar as a part of our hosting offering for users with green-screen (telnet, serial terminal) applications. A client gateway application manages logical "connections" back to our multi-homed central servers walking around BPG router "flaps" and other transient outages that BGP does not even address.
You are correct if you are going to route "big chunks" of address space. On the other hand, most of us (at least those with some colo machines at our disposal) don't have spare/24s laying around [and if you do you should give them back to ARIN]. Also, it is arguably better to watch 256 "random" addresses than 256 in a row, so watching a bunch of small blocks is actually better than grabbing a big contiguous block.
A couple of other points here. ARP does not actually create any extra traffic on the interface that is being watched. In this example, the ARP goes from eth0 to the upstream router. You are packet sniffing tap0. Thus tap0 will show absolutely zero outbound traffic (it cannot because there is no "client" application talking to it). Regardless, we are talking about IP here. If you have traffic reaching your interface that it not IP (and ARP is not IP), just why did the router forward it to you anyway.
If you have a lot of nets that need to be routed this way, you can still do it. There is nothing wrong with static routes that go thru 5 systems on the way to the tap device. These can cross local LAN segments and provided there are no firewall rules that disallow it, the effect is the same.
If your purpose is to dedicate resources to this project, then the dedicated network solutions is best. Otherwise, the virtual network solutions that use 'arp' and 'tap' devices gets you 100% of the same traffic to analyze.
My "best" choice if you want to watch a "lot" of addresses would be to run something like LaBrea that responds to "un ARPed" packets. This could be mangled to automatically setup the interface to forward unused addresses within the current block to a tap device. I have not tried this, but it would be fun and not too hard to implement.
The idea here is to catch traffic to otherwise unused network addresses. This does not require any of the stuff that seems to be implied here.
For example, say you have a Linux system in a colo somewhere (or on the end of a T-1 or some other >1 IP address static network). You have some IP addresses assigned to you that are otherwise not assigned. Here is how you can get all of the darknet functionality with your standard server.
Some example numbers (none of which are real)
Unused address to watch: 10.11.12.13
Interface on which you receive traffic: eth0
A fake interface to route to: tap0
At this point the traffic should all route to the fake device tap0. You can run tcpdump on this, setup IP filter chains, run MRTG on it directly, etc. All without any extra hardware.
For those that work with UML (User Mode Linux), you already recognize this is exactly how you setup virtual UML networks.
This is also somewhat related to "tar pits" that just answer connect requests to addresses that have un-completed ARP requests.
Machine prices do work this way, you just aren't in a position to realize it (or you are in a position where the difference between $600 and $1500 is not important [this is not meant as an insult. For many users, the price difference does not really matter.])
Go back a few years and basic system boxes were $1500 (or even $3000 to $4000 not all that long ago). Now the basic box is $500 if you stay just a little back from the bleeding edge (which I think is a good place to be).
You can still spend $1500 on a system and in many cases you should. If you buy a 19" flatscreen from Dell that is $800 right there.
Laptops were $4K. Now really decent laptops are available from name-brands for $2K with entry-level $1K. This is a real change.
The net effect is that the percentage of cost that the software represents is getting larger. With Windows, the price should go down as Microsoft's volume goes up. At least this is how a "normal", non monopolisitic market would work. And yes, Microsoft does discount Windows to major vendors, but even that price is going up and you can bet that Longhorn will go up again.
In many markets this will continue to work fine for Microsoft. There are markets on the edges where the Microsoft tax is getting less and less competitive. If you want to "deliver" a $200 computer, the hardware is there but using Windows software prohibits it. If you need workstations for dedicated - locked-down corporate settings (think Kiosks) then the tax seems even higher because it does 95% of the functality must be locked up anyway. This just means that there is room for other (more open) alternatives. All of this is good for competition we all think that competition is good (right).
If Longhorn ran on current "mainstream" PCs, Microsoft would be in trouble. Assuming that current PCs cost $600, in a couple of years, this will drop to $250. This would make Longhorn >50% of the price of the PC. The only way to keep the OS price hidden is to push the total hardware price up. Otherwise, people will realize that the Microsoft tax actually exists.
Perhaps a bit more detail of the engine will help.
The actual file-system driver in UML is patched to produce an "event log" for all file updates. Because this is UML, this log can run in user-space to the host OS.
The log itself includes events such as "close file after writing", rename file, create directory, set priviledges, etc.
The log itself is sent to a pipe. The pipe is dequeued by a daemon that builds transaction "blocks". A transaction block can contain one or more transactions. When a transaction block is closed is dependent on both time, block size, and whether a block is currently "in-flight" to the far end. If the engine is not currently moving data, we close a block after 2 seconds or 500K. If the engine is busy moving data to the far end, the timeout is enlarged to 60 seconds or 500K.
The actual transfer engine is a POST operation over HTTP. The sending end is a shell script that calls curl. The actual transfers are tagged with transaction numbers so that failed transactions can be retried. The receive end is a CGI application that calls a C program to post the actual updates to the file-system. The curl/cgi engine also has the ability to compress the data with compress/gzip/bzip2 (we use gzip as a compromise compression level for our speed of lines).
We could have used rysnc for the transfer itself (and actually started to engineer this early on). In the end, the transaction latency of rsync made it impractical and we needed a different level of functionality.
I developed a replicated filesystem that we use with our commercial email service. The filesystem is layered under UML (User Mode Linux) and cross-replicates files between two servers, on in California, and one in Pennsylvania.
I too looked at Coda and Inter-mezzo, but was not very satisfied with their stability and/or their ability to recover from outages.
The replication that we use relies on the update nature of MailDir with Courier Imap.
Our solution uses UML to post a transaction journel to the underlying host OS layer. Application level code then cross-posts filesystem updates using HTTP transactions with curl and Apache/cgi. Transactions are delayed about 2 seconds to coalesce multiple updates into a single network event. In general, we get about 5mbit of update thruput coast to coast and it is very rare that either system is more than a couple of seconds out of sync.
I am sorry that I cannot give you the code. While the code is Linux bases, we don't actually sell (distribute) it, so we keep it in-house for our own use. Perhaps my description will give you some ideas.
Slashdot Mirror
This is different. Cable companies are not blocking port 25 because they are trying to sell something competing. You could argue that blocking port 80 is because they are competing, but even then making the "you are doing this so you get the business instead" argument is hard to make stick.
With VOIP it is different. If an ISP is selling a VOIP offering and blocking the competitors, then they are using their blocking "to compete unfairly". With outbound mail thru SMTP, and to a lesser extent with the prohibition of web servers, the ISP is not trying to make another of their products more appealing.
Just imagine the uproar if Vonage paid ISPs to block UDP port 5060 destined to any network but theirs.
You dont understand how SIP works.
VOIP calls run exclusively over UDP packets. There is not a TCP packet to be found. SIP, or Session Initiation Protocol is a UDP handshake that is used to setup a connection. With consumer VOIP circuits, the client will send a SIP registration request to the SIP proxy server (Vonage in this case). The proxy server will reply with an OK. The actual payload of the UDP packets looks just like an HTTP transaction (complete with a GET and headers) and ditto for the reply. It is just not in a TCP stream. If a packet gets lost, then it is lost and the transaction does not happen.
The SIP client will nearly continually repeat this UDP registration followed by shorter "keep alive" exchanges. The idea is to keep any NAT router happy so that the channel now is end-to-end connected.
If the server needs to ring your phone, it now has an IP address and UDP port number that it can send a packet to. This then causes the SIP client to setup an RTP "connection". Again, these are UDP packets and TCP is nowhere to be found. The RTP connection is basically a set of UDP packets sent out very quickly. For a non-compressing codec (like G711.u [aka ulaw]), this means 50 UDP packets/second of about 220 bytes each. The packets go both ways at full speed (which is why VOIP does not work over dialup). There is no error detection. If a packet is lost, 20ms of voice is dropped.
So is a SIP client a server. I don't think so. I think it is wrong to describe a server as something that listens on a port. In the case of residential internet access, it is not the listening that the ISP does not like. It is the bandwidth and usage patterns. A better metric would be "is this a one to one communication". A web server is one to many. Ditto for streaming video. SIP is one to one. If you want to call SIP a server, then you should probably call an IM client a server as well.
What the ISPs are really doing is trying to figure out how to charge some people "more" when they can get away with it. It is not just "usage", but also an arbitrary categorization of what is residential access. From a purely network and traffic point of view, bittorrent should be the first thing outlawed. A local webserver on port 80 is nothing compared to a good torrent.
The other issue is "should an ISP be allowed to block competitors traffic". A lot of people argue against regulation of any kind. If you are one of these then you are a fool. If you leave a company completely without regulation, they will steal from you. There have to be limits to their behaviour. I have seen VOIP companies that claim, in the contracts, that they don't honor local number portability requests. They are saying that if you get a phone number from then that they will not give it up. Perhaps the regulations have not caught up to VOIP providers, but this policy is wrong, probably illegal, and the government should work to stop it. Similarily, if an ISP has a policy to hurt a competitors traffic so that their service works better, then that ISP is wrong. If this is not against the law, then the law should be enlarged to stop the practice. At the very least, this policy should be openly disclosed by the ISP to all of their customers up front.
It is about time for businesses to provide service to their customers instead of feeling like their customers are their property to leverage.
This type of discussion really worries me for "single owner" systems.
You have setup a system that will keep people away from the data unless you and only you try to access this. What happens if something happens to you. Your family might need your account numbers if you die, have a stroke, etc.
If you are protecting your child porn stash, then maybe this is the best solution. For things like credit card numbers, on-line banking, etc. you should "escrow" your passwords somewhere so that others can get to them if needed. This could be as simple as a printout of your passwords/accounts in your safe deposit box to having information kept by your lawyer.
Remember that bad things can happen beyond just hackers trying to get data.
And I am not just trolling for karma. My wife just had a friend die suddenly and one of the first questions from the family was "how do we get his laptops password". My anser was, "it depends, if he really secured it well, you are pretty much out of luck".
Forget all these mirrors. Just run a couple of dozen good seeds and BitTorrent will populate the planet, all with good MD5 sums.
After all, if the MPAA cannot figure out how to pollute Torrent files, it must be pretty tough.
Frys are good and evil at the same time. They are good because they are very large stores with lots of decent computer hardware, including lots of components. You can buy processors, memory, resistors, MBs, you name it. Not quite an electronics distributor (they are more retail than that) but they have a lot of stuff.
The stores themselver are huge (the size of most large grocery chain stores [~80,000 sf - a guess]). They are typically split into three parts. Computer hardware and accessories occupy about 40% of the store. Software and things like DVS are about 20%. The rest is home and car electronics (everything from portable phones to big screen TVs). They have >40 checkout registers. When they open a new store, I have seen >1hr lines to check out that line the perimiter of the store.
The problem with Frys is both their size and the people they hire. They use commissioned salepeople that arguably dont have a clue. If you want a taste of this, do a good search on "frys electronics employment application". There are at least three versions floating around.
On the whole, I am glad that we have a local Frys. There prices are not the best, you absolutely dont want to use them for "advise", but they are local and they usually do have what you need.
I don't know where you are located, but around here, I would go to a high-end electronics dealer that dealt in in-car entertainment systems, the kind where the kids can watch TV in the back seat. You should be able to find a video-in LCD display from 5 to 10". Most will probably run off 12V power, but this is not that hard to get out of a PC PS.
Around here (Orange County, California) this would be Frys, Best Buy, or one of the independent auto shops. And if you mod me down because I said Frys, then I agree with your judgement.
If you look at the page on a mirror and examine is closely, it looks like the source HTML came straight from a "real" CNN page and the new story was cut and pasted in. Even the ads are real.
So, technically, the parody site does violate the copyright of CNN for the HTML "code" on the page. This is more than just layout as it includes javascript and even content management comments. Even the links were copied intact so that they are now broken. Basically, a lazy parody site that would not take the time to create an "original" parody and just cut and pasted instead.
Now, I still think that CNN is being incredibly "stupid" in pursueing this. I also think that the DMCA is dumb (on a lot of grounds in addition to) not requiring that the nature of an infringement be specified in a complaint.
So I think thenationaldebate just needs to be a little less sloppy and not just use "save as" with other peoples web sites. Make it look like who you are parodying, but write it yourself.
Your ground-source heat pump is not all that unusual. I used to live in central Florida (Cocoa Beach), and almost everyone ran water-cycle heat pumps from artesian wells. 70 degree water all year. The savings there was on air conditioning efficiency. Plus you could water your lawn with it.
We used to use Nagios here to monitor a large number of services on a large number of servers. We eventually agandoned it and replaced our "is the server up" monitoring with simple scripts that call fping. The problem with nagios is that the process model starts to fall apart at several hundred monitored servers/services and we really did not want to dedicate a farm to monitoring.
You can push the data using rsync. Load the Windows / cygwin version of rsync/ssh on the windows box. Then sync the whole box up to a debian directory over ssh. If you get fancy you can build rotation sets, etc. rsync is very efficient at moving only what changes, handling include/exclude lists, etc. Great for backing up lots of data.
Do a google search on "rsync windows backup".
The only downside is that rync will "kill" your upstream internet connection (it is that efficient). Fortunately, there is a --bwlimit option so you can back off a little.
If you are looking for a commercial hoster with all of the scripts pre-built we are happy to help (sorry for the AD), but it is pretty easy to roll this yourself.
It does not matter.
...
The GPL says that
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
Section 3 says that "you may copy and distribute the program".
But the subscription license says that if you copy or distribute the program, then you incur a penalty. Thus you are not "free" to copy or distribute the program. "Free" means gratis and "free" it means liberty. If you are blacklisted from a site, then you are not free.
What you are arguing is that Sveasoft is saying, "go ahead and distribute the program, and we will then cancel your contract." Regardless of how you parse this, Sveasoft is trying to hinder you from distributing the program, thus Sveasoft is trying to restrict your "excersise of the rights granted herein".
Perhaps in this case the call is close, but consider what would happen if someone larger is involved.
A hypothetical company has 50 servers running RedHat Enterprise Linux. They pay redhat $40,000/year and think that it is worth it. A departmental programmer is donating time to a small parish library who wants to use RHEL, but cannot afford it. This programmer gives the library the RHEL GPL packages (and leaves out any RedHat copyright packages). By your logic it would be acceptable for RedHat to cancel the 50 server RHEL contract.
The policy at Sveasoft is meant as a restriction. It is not 100% effective because Sveasoft does not own the packages. It is still a restriction to distribution rights regardless.
Thanks for all the great replies.
I think that there is another way to view this.
In order to get the software, you have to have a subscription. The subscription is a contract between Sveasoft and you. Because you cannot get the GPL software without this contract, the contracts terms impact your use of, and rights to the GPL software. Thus the two contracts are linked.
In this case, their are terms of the Sveasoft contract that do restrict your use of the software. They say that if you redistribute pre-releases of the software then you lose rights that you would note lose if you did not redistribute. The wording of the GPL is very clear:
You may not impose any further restrictions on the recipients' excercise of the rights granted herein.
In this case the meaning of the subscription and what it includes does not really matter. In order to get the subscription you need to agree to the subscription license and that license restricts what you can do with the GPL software. While it does not say that I cannot redistribute the software entirely, it definately impacts my "excersise of the rights granted herein".
Imagine for a second how this could abuse the GPL. By allowing two licenses to be tied together, I can sell 100% proprietary software that is GPL just by having a second license that creates a very onerous penalty if your redistribute, or load onto multiple systems, or make modifications, or log on too many times. RedHat (or Suse, or whoever) could threaten to cancel Enterprise Linux contracts for users that redistribute 100% GPL packages that are part of their updates (bye bye White Box Linux). If you argue that this is mearly an unrelated license, then you have allowed anyone to create 100% proprietary and closed GPL packages by just wrapping them in another license.
The GPL says that if you receive the code, you are free to redistribute it under the GPL. This policy does not allow you to "freely" distribute the code.
... You may not impose any further restrictions on the recipients' exercise of the rights granted herein. ...
Consider a hypothetical license:
If you agree not to redistribute the package under the GPL the software
costs $50.
If you violate this agreement, the package costs $50,000.
The real problem here is that Sveasoft is not distributing the code under the GPL but instead under the GPL and under their license. This "combined" license is a modification to the GPL, which they cannot do.
The part of the GPL that is violated is:
While you can argue that terminating a "subscription" is not a restriction on rights. This is just wrong. If you get the code, you are free to do anything with it you want under the GPL. Except in this case, if you actually re-distribute the code, you are penalized for availing yourself of your rights.
If the FSF stated that their subscription policy was *not* a violation, they are wrong. Penalties for re-distribution is clearly a license restriction.
Hopefully, some group with actual copyrights (like the iptables people) will declare this policy in violation of the GPL and demand that Sveasoft stop.
Most shell accounts are disappearing because they are very unsafe for the hoster. Also, the prevelence of UML (User Mode Linux) lets hosters run virtual servers in security sandboxes so that the child application is more isolated from the host system.
UML virtuals behave like complete Linux servers with smaller RAM and disk sizes. You can load full distros and get a direct, public, IP address. Some hosters let you run IRC servers and some don't (many upstream providers hard-filter IRCD). In terms of software and services, you can run just about anything you want. Mail, FTP, ssh, IRC, Apache, Perl, PHP, MySql, etc. Plus you have full editors (vi, emacs) and compilers (gcc, java, etc.).
You can typically get these starting at about $12/mo. We sell them starting at $15/mo. They are more than shell accounts because the load you can place on a physical server is much smaller. In general, we only put 15-20 on a box to keep the underlying LoadAvg < 1.
Info on UML is available at:
http://user-mode-linux.sourceforge.net/
Have fun.
I have walked thru it many times. It is basically a hallway with opposing doors that cannot both open simultaniously. Guards watch the interior making it difficult to wheel out lots of gear without being noticed. Now, if there were machine guns, they were well hidden ;)
You are wrong.
Many banks do run in Co-los. We have neighbors in the co-los we are in that are banks, insurance companies, medical, etc. And I would feel very comfortable with my bank locating in some of the co-los that we are in.
Case in point are co-los with "real" security. Savvis (formerly Exodus) in Los Angeles (actually El Segundo for those that care) has armed guards, card key access, hand scanners, more security cameras than you can count, and man traps. If you need more, you can get private cages, rooms, and even bomb-proof vaults. And if you know of a "regulation" that states that your internet-connected servers cannot be located in a secured facility with bonded armed guards, I would like to read that reg. Personally, I think your statement is just a continuation of the "myth" that co-los are somehow less secure. While no place is 100% perfect, co-los are much "more secure" than the back room at your office.
Remember, that when I say co-lo, I don't mean "cheap-ass-servers.com" (someone quick, go register this as it appears to be available). There are many high-quality co-los from companies like Savvis, Switch and Data, and others that are run extremely professionally. If you are lucky enough to be in a good co-lo, you will get better up-time than you could possibly hope for in-house.
Only for those few souls that are still running green-screen. And I really was not trying to advertise (at least not too much) but was trying to get people to think about what is possible.
If anything, my "real" motive is to keep people from putting servers in-house. If your office has the same "pipe", "power", and "security" as a good co-lo, then you spent too much money building it.
After all, there are millions of square feet of unused co-lo at rock-bottom prices just begging for more space-heaters (er, servers) to keep the resident space-heaters (er, servers) company.
My personal opinion is that trying to reach this level of redundancy for a lot of companies is just not practical and that there are much better approaches.
... or AT&T ... or MCI ... or Sprint ... or Cogent)".
The idea here is to think of your internet connectivity as two different classes of services. You should place your internet reachable servers in a good co-lo. Get BGP lines from two different sources and multi-home the boxes. Don't run your own AS (use the upstreams space) but instead place your servers "close" to your provider's edge routers. In the end, you are BPGing the loop and it is hard for 100ft of cat-5 to fail. In the end, you have to ask yourself "Am I more qualified to keep my BPG up than is Level-3 (or Savvis
In terms of your office, stick to client-only type services. Get two "diverse" connections. This might be a T-1 and a DSL, or a DSL and a cable modem. By using completely different architechures, you can get incredible diversity without spending a bunch of money. You can then IPSEC your local net over the client-only connection back to your addresses in the co-lo and with the help of a little client-side monitoring, auto-switch when a line goes down.
We offer something similar as a part of our hosting offering for users with green-screen (telnet, serial terminal) applications. A client gateway application manages logical "connections" back to our multi-homed central servers walking around BPG router "flaps" and other transient outages that BGP does not even address.
Mirror
Mirror of images, all one one page. 39 images. 3.2 Megabytes total.
You are correct if you are going to route "big chunks" of address space. On the other hand, most of us (at least those with some colo machines at our disposal) don't have spare /24s laying around [and if you do you should give them back to ARIN]. Also, it is arguably better to watch 256 "random" addresses than 256 in a row, so watching a bunch of small blocks is actually better than grabbing a big contiguous block.
A couple of other points here. ARP does not actually create any extra traffic on the interface that is being watched. In this example, the ARP goes from eth0 to the upstream router. You are packet sniffing tap0. Thus tap0 will show absolutely zero outbound traffic (it cannot because there is no "client" application talking to it). Regardless, we are talking about IP here. If you have traffic reaching your interface that it not IP (and ARP is not IP), just why did the router forward it to you anyway.
If you have a lot of nets that need to be routed this way, you can still do it. There is nothing wrong with static routes that go thru 5 systems on the way to the tap device. These can cross local LAN segments and provided there are no firewall rules that disallow it, the effect is the same.
If your purpose is to dedicate resources to this project, then the dedicated network solutions is best. Otherwise, the virtual network solutions that use 'arp' and 'tap' devices gets you 100% of the same traffic to analyze.
My "best" choice if you want to watch a "lot" of addresses would be to run something like LaBrea that responds to "un ARPed" packets. This could be mangled to automatically setup the interface to forward unused addresses within the current block to a tap device. I have not tried this, but it would be fun and not too hard to implement.
The idea here is to catch traffic to otherwise unused network addresses. This does not require any of the stuff that seems to be implied here.
For example, say you have a Linux system in a colo somewhere (or on the end of a T-1 or some other >1 IP address static network). You have some IP addresses assigned to you that are otherwise not assigned. Here is how you can get all of the darknet functionality with your standard server.
Some example numbers (none of which are real)
Unused address to watch: 10.11.12.13
Interface on which you receive traffic: eth0
A fake interface to route to: tap0
Configure your server to ARP the extra addresses:
arp -Ds 10.11.12.13 eth0 -i eth0 pub
Setup a "tap" device to route the traffic to
tunctl -u nobody -t tap0
ifconfig tap0 10.11.12.13 netmask 255.255.255.0 broadcast 10.11.12.255 up
Setup a "route" to the device
ip route add 10.11.12.13 dev tap0
At this point the traffic should all route to the fake device tap0. You can run tcpdump on this, setup IP filter chains, run MRTG on it directly, etc. All without any extra hardware.
For those that work with UML (User Mode Linux), you already recognize this is exactly how you setup virtual UML networks.
This is also somewhat related to "tar pits" that just answer connect requests to addresses that have un-completed ARP requests.
Have fun.
Machine prices do work this way, you just aren't in a position to realize it (or you are in a position where the difference between $600 and $1500 is not important [this is not meant as an insult. For many users, the price difference does not really matter.])
Go back a few years and basic system boxes were $1500 (or even $3000 to $4000 not all that long ago). Now the basic box is $500 if you stay just a little back from the bleeding edge (which I think is a good place to be).
You can still spend $1500 on a system and in many cases you should. If you buy a 19" flatscreen from Dell that is $800 right there.
Laptops were $4K. Now really decent laptops are available from name-brands for $2K with entry-level $1K. This is a real change.
The net effect is that the percentage of cost that the software represents is getting larger. With Windows, the price should go down as Microsoft's volume goes up. At least this is how a "normal", non monopolisitic market would work. And yes, Microsoft does discount Windows to major vendors, but even that price is going up and you can bet that Longhorn will go up again.
In many markets this will continue to work fine for Microsoft. There are markets on the edges where the Microsoft tax is getting less and less competitive. If you want to "deliver" a $200 computer, the hardware is there but using Windows software prohibits it. If you need workstations for dedicated - locked-down corporate settings (think Kiosks) then the tax seems even higher because it does 95% of the functality must be locked up anyway. This just means that there is room for other (more open) alternatives. All of this is good for competition we all think that competition is good (right).
If Longhorn ran on current "mainstream" PCs, Microsoft would be in trouble. Assuming that current PCs cost $600, in a couple of years, this will drop to $250. This would make Longhorn >50% of the price of the PC. The only way to keep the OS price hidden is to push the total hardware price up. Otherwise, people will realize that the Microsoft tax actually exists.
Perhaps a bit more detail of the engine will help.
The actual file-system driver in UML is patched to produce an "event log" for all file updates. Because this is UML, this log can run in user-space to the host OS.
The log itself includes events such as "close file after writing", rename file, create directory, set priviledges, etc.
The log itself is sent to a pipe. The pipe is dequeued by a daemon that builds transaction "blocks". A transaction block can contain one or more transactions. When a transaction block is closed is dependent on both time, block size, and whether a block is currently "in-flight" to the far end. If the engine is not currently moving data, we close a block after 2 seconds or 500K. If the engine is busy moving data to the far end, the timeout is enlarged to 60 seconds or 500K.
The actual transfer engine is a POST operation over HTTP. The sending end is a shell script that calls curl. The actual transfers are tagged with transaction numbers so that failed transactions can be retried. The receive end is a CGI application that calls a C program to post the actual updates to the file-system. The curl/cgi engine also has the ability to compress the data with compress/gzip/bzip2 (we use gzip as a compromise compression level for our speed of lines).
We could have used rysnc for the transfer itself (and actually started to engineer this early on). In the end, the transaction latency of rsync made it impractical and we needed a different level of functionality.
Please excuse the ad here (mod down if you like).
I developed a replicated filesystem that we use with our commercial email service. The filesystem is layered under UML (User Mode Linux) and cross-replicates files between two servers, on in California, and one in Pennsylvania.
I too looked at Coda and Inter-mezzo, but was not very satisfied with their stability and/or their ability to recover from outages.
The replication that we use relies on the update nature of MailDir with Courier Imap.
Our solution uses UML to post a transaction journel to the underlying host OS layer. Application level code then cross-posts filesystem updates using HTTP transactions with curl and Apache/cgi. Transactions are delayed about 2 seconds to coalesce multiple updates into a single network event. In general, we get about 5mbit of update thruput coast to coast and it is very rare that either system is more than a couple of seconds out of sync.
I am sorry that I cannot give you the code. While the code is Linux bases, we don't actually sell (distribute) it, so we keep it in-house for our own use. Perhaps my description will give you some ideas.
The email offering is described at:
http://easyco.com/mail/index.htm