We do a lot of secure FTP. In regards to you point #2, it isn't a routing issue as such, it's a NAT issue. The FTP protocol includes the IP address of the client machine in the data portion of the packets. NATting firewalls have to change not only the headers of the initial FTP packets, but have to reach into the data packets and change the IP addresses as well. FTPS encrypts packets from the get-go, so what happens is the NAT firewalls change the packet headers, but don't change the client IP in the data. So the server tries to respond to the IP address in the data packet, which are usually IANA private, and definitely wrong no matter what, and it doesn't work.
There are several solutions. Some FTP clients that support FTPS have a spot where you can tell them what their outside IP address will be. It inserts that address into the data packet so the firewall doesn't have to change it. That works OK for people who have a static external address. It doesn't work well for road warriors. A more robust solution is FTPES. That protocol modification does the initial negotiations (which the NAT firewalls have to change) unencrypted, and then switches over to encrypted for passwords and data transmits.
SFTP can also a good choice, but on Linux FTP servers the user setup is different. FTP servers can be given a list of users & passwords separate from the host's user setup. SFTP is really SSH, and so the users are typically given accounts on the box. This isn't necessarily a problem, it's just different.
Our SAN is keeping 4 copies of the data (2 local and 2 remote) and it costs us about $3.50 per GB/month over 3 years for SAN and bandwidth, but without power or data-center space factored in. I think you're paying a little too much.
I'm not saying that there aren't people who would like to see it changed. I'm questioning their ability to actually do it. Have the language syntax defined by an ANSI or ISO if you're that worried about it.
To actually manage to fork the language, they would have to get a group of enough people who all wanted to see the same changes in the language to actually agree to undertake the work themselves. It will never happen. They would then have to convince other, less militant users (the other 99.5% of the Java users) that their implementation of the language is better than Sun's. It will never happen.
If forking a language was feasable, I think that you would see a lot more of it. It might be possible to make a superset of a language that could work and might go on to have some life of its own, but if the fork breaks the existing language code it would be dead on arrival.
(Of course, the forking issue is going to be a major sticking point...)
I don't understand why Sun would be up in arms over the possibility of a fork. Python isn't forking. Perl isn't forking. PHP isn't forking. I find it unlikely that there would ever be the groundswell necessary to fork the entire language in a different direction. Sun will be leading the direction of Java for as long as they wish to - free or not.
I don't understand. They are already differentiating between their customers at a bandwidth level. You can pay $10 for dialup, $40 for 3Mbps, or $70 for 6Mbps. (I pulled the numbers out of my ass - they are just to illustrate the point.) They are trying to extort money from content providers pure and simple. They are saying to a content provider (who likely isn't their customer at all,) "If you don't pay us we won't pass your packets." What would be said if Google started blocking access from netblocks owned by certain ISPs if the ISPs didn't pay for the traffic that their customers were causing? It's a money grubbing tactic by the ISPs, pure and simple. If they can't make it on what they are charging their clients, then they need to cut costs or raise their prices, not extort money from others. Carriers need to be carriers and treat packet A in the same manner as they treat Packet B.
The phone companies are covered by common carrier status. It protects the phone company from most litigation and liability provided that they treat every call equally. If they start monitoring the calls or treating some calls differently than others, they lose those protections. The same standards should apply to Internet traffic. If they want to start differentiating service levels, then they should be liable for the problems that they cause.
They're not talking about classifying traffic based on type, they're talking about classifying based on source & destination. They are already being paid to carry traffic. They should be treated by the same common carrier criteria that phone companies are subject to for voice transmissions. It would be like your cellular carrier wanting to charge you extra to not drop your calls. It's BS.
It's been some months since we bought these. I got mine from http://www.hacom.net/. I did a little research on this, and what the guy really sold to us was a Light CV860A with the 533MHz fanless CPU. These units seem to be a little more common now. The hacom site has links to debian CF install with a 2.6 kernel.
But, there's nothing really odd about them. They are just small computers. They'll boot from a USB CD, and you can install an OS. I bought a 512 MB flash card to start and just did a plain Debian install. It worked just fine. You'll want to make sure that you mount heavily written folders to RAM drives (like/tmp,/var, etc.) because CF is limited in the number of write cycles that it can withstand, but beyond that, it's no different that installing on any other machine. It's basically just a standard install, plus a RAM disk, a few/etc/fstab entries, and maybe a custom script or two if you want to save/restore the contents of your logs from/var between reboots.
We gave about $400 for boxes with 512MB and no disk. We supplied the CF aftermarket.
How is the performance of the Geode CPU?
Well, performance typically depends on load. We use them as endpoints for remote users, so they vpn back to the office and run X with rdesktop so the users can access the terminal server. We also set them up to do firewall/NAT so that the folks who have other computers at home can share the broadband access with other machines. I haven't had any complaints. We run 512MB of RAM in them, and mount/tmp &/var as ramdrives. There are a lot of good articles about how to set them up. The http://www.hacom.net/ site had some good stuff, but seems to be down now.
I'd be using it to run Astaro firewall, which is kind of a pig for CPU and RAM
I'm not familiar with this, so I couldn't say. We're not typically processor bound with what we do, and these work OK. We went for the versatility, and these things really have it.
Greetings: http://openbrick.org/ is a community of folks doing this kind of stuff. I have purchased a couple of boxes from a US distributor (http://www.hacom.net/ and have been really happy. They have 3 ethernet ports, so they make great firewalls. We use CF cards for storage because we don't need the storage, but you can put little laptop harddrives in them, so you could make a file/print box if you wanted to. They'll boot off of a USB CD, so installation is a breeze. I run Debian, but have installed openbsd for kicks, also. They're cool enough that they don't need an internal fan, so they're quiet too.
I have nothing but nice things to say about them. The US distributor only takes paypal, but he has always delivered without problems. He even called back to see if I liked it.
Because if my options are a cable modem from Comcast or dial-up, I don't have any real options. Maybe someone will run fiber out here, or put up wireless, but until then, you sometimes have to take what you are given.
I think that you are overestimating Apple's ability to produce a stable system on x86 hardware. Part of Microsoft's problem (and Linux's for that mater) is the amazing diversity of hardware available on the x86 platform. Someone's got to write all those drivers, and because they are kernel level code, when you screw them up bad things can happen to the stability of the system.
I wouldn't call it an insurmountable problem, but it wouldn't be as easy as cross-compiling the source code, either.
Re:I want a filter dammit. Server side doesn't cut
on
DSPAM v2.10 Released
·
· Score: 1
Server side filters do not generally block the email from coming to you like a virus filter might. They typically tag the message with some text that is consistent and you can filter on that using client side rules, if you wish.
It might add [[SPAM]] to the beginning of the subject if it thinks that the message is spam. It leaves the ultimate decision up to the user how to deal with it.
It does not ever block any mail from coming to you.
After a certain point, it simply becomes easier for someone to break into the building and steal the machines containing the data. Or bribe an employee for the data. At some point you have to be able to justify the amount of money that you're spending against the risk involved.
But, it does matter. There is still a ton of equipment being manufactured (I'm in the medical industry) that is used for data collection and monitoring that simply has an ethernet jack on it. You plug it into the network, and the server software prods it for data once in a while. Since it's patient data, I can't just broadcast it to the whole world. In a wireless environment, my options are to plug in a wireless to ethernet bridge and run WEP for the encryption, or set up a whole vpn style solution for each device, with VPN capable hardware endpoints for each device.
Don't think that the manufactures of this equipment are going to change their devices, either. The devices are regulated and any changes require recertification by the government. Plus, at 10's of thousands of dollars a pop, I couldn't afford to rebuy it anyway.
There will always be a need for wireless equipment (either part of the radio, or in-line with it) to be able to encrypt and decrypt data that moves over the wireless link.
I still don't understand why people get so wrapped up on encryption at the AP level.
Because every wireless device is not a computer with the processor availble to encrypt and decrypt data. We have lots of wired devices that are wireless enabled by adding a ethernet to wireless bridge. We have legacy systems that still run over telnet. I'll grant you that WEP is not the perfect solution, and that manually changing the keys every quarter is a pain, but making legacy equipment operate in a new environment sometimes takes a hack.
Just out of curiousity, why would you need a whole new domain record to do this? It's fairly common practice to only accept mail from machines listed in a domain's MX record already, and that seems to work pretty well. Using this you could add hosts that were outbound-only for a domain, but I think that might actually be of limited use.
Tom's Harware loves doing stunts like this. They've run processors without coolers just to see what happens, and they investigated problems with the early AMD thermal diodes. Check it out
I have comcast in Indy and while they might block an odd port here and there, I've had no trouble running ssh & msrdp inbound. I don't run web or mail, but the last time that I checked, the only ports that they were blocking were BackOrifice and something else that I can't remember right off the top of my head. You might try it out and see what you get.
I took a job which requires about 150 miles of travel per day, so I purchased the car for basic transportation. I purchased the manual transmission model due to personal preference, YMMV (literally) with the automatic model. On average, I get between 52 and 58 mpg on basic highway driving at 65 mph. Air conditioning will take 5 mpg off of that. Traveling at 75 mph will drop another 5 to 8 off of that. Wind and weather conditions can effect the mileage as well. Stop and go driving in town with the air on will net me 35 to 40 mpg. Drafting semis on the Interstate at 75 mph will get you 60+ mpg.
I'm a big guy - 6'4" and 250 lbs, and I fit in the machine pretty well. I have about an inch of headroom left. I can get the seat far enough back, but no one but a child would be able to sit behind me.
I paid less than $20000 for it - plus there is a one-time $2000 tax-deduction, so that's a bonus.
I've put about 16000 miles on it so far. It drives and handles like any other 4 cylinder basic transportation car I've ever driven. The torque is better, though, so I don't feel like I'm going to have to get out and push while trying to get onto the Interstate.
Some nits: It takes 0W20 oil, which I've had trouble finding. The good news is that oil changes are only every 5000 miles. It doesn't have much cargo capacity - total weight is only 800 lbs. You can really tell the difference when you have it full. The rear seats don't fold down like a standard Civic (the batteries sit on the rear axle), so the trunk is a little confining. I would only rate it at one-dead-body.
Overall, it's been great regular transportation. I liked it alot better than the other Honda hybrid. That car was smaller and lighter and got pushed around on the Interstate. This is a regular Civic in most every way except the powertrain.
Slashdot Mirror
Greetings:
We do a lot of secure FTP. In regards to you point #2, it isn't a routing issue as such, it's a NAT issue. The FTP protocol includes the IP address of the client machine in the data portion of the packets. NATting firewalls have to change not only the headers of the initial FTP packets, but have to reach into the data packets and change the IP addresses as well. FTPS encrypts packets from the get-go, so what happens is the NAT firewalls change the packet headers, but don't change the client IP in the data. So the server tries to respond to the IP address in the data packet, which are usually IANA private, and definitely wrong no matter what, and it doesn't work.
There are several solutions. Some FTP clients that support FTPS have a spot where you can tell them what their outside IP address will be. It inserts that address into the data packet so the firewall doesn't have to change it. That works OK for people who have a static external address. It doesn't work well for road warriors. A more robust solution is FTPES. That protocol modification does the initial negotiations (which the NAT firewalls have to change) unencrypted, and then switches over to encrypted for passwords and data transmits.
SFTP can also a good choice, but on Linux FTP servers the user setup is different. FTP servers can be given a list of users & passwords separate from the host's user setup. SFTP is really SSH, and so the users are typically given accounts on the box. This isn't necessarily a problem, it's just different.
Good luck.
As long as we're on the topic, anyone have any success connecting the Android 2.2 Mail app to a courier-imapd server? ...
No, but I am successfully connecting against a dovecot imap server over SSL. Works like a champ.
Our SAN is keeping 4 copies of the data (2 local and 2 remote) and it costs us about $3.50 per GB/month over 3 years for SAN and bandwidth, but without power or data-center space factored in. I think you're paying a little too much.
I'm not saying that there aren't people who would like to see it changed. I'm questioning their ability to actually do it. Have the language syntax defined by an ANSI or ISO if you're that worried about it.
To actually manage to fork the language, they would have to get a group of enough people who all wanted to see the same changes in the language to actually agree to undertake the work themselves. It will never happen. They would then have to convince other, less militant users (the other 99.5% of the Java users) that their implementation of the language is better than Sun's. It will never happen.
If forking a language was feasable, I think that you would see a lot more of it. It might be possible to make a superset of a language that could work and might go on to have some life of its own, but if the fork breaks the existing language code it would be dead on arrival.
I don't understand. They are already differentiating between their customers at a bandwidth level. You can pay $10 for dialup, $40 for 3Mbps, or $70 for 6Mbps. (I pulled the numbers out of my ass - they are just to illustrate the point.) They are trying to extort money from content providers pure and simple. They are saying to a content provider (who likely isn't their customer at all,) "If you don't pay us we won't pass your packets." What would be said if Google started blocking access from netblocks owned by certain ISPs if the ISPs didn't pay for the traffic that their customers were causing? It's a money grubbing tactic by the ISPs, pure and simple. If they can't make it on what they are charging their clients, then they need to cut costs or raise their prices, not extort money from others. Carriers need to be carriers and treat packet A in the same manner as they treat Packet B.
The phone companies are covered by common carrier status. It protects the phone company from most litigation and liability provided that they treat every call equally. If they start monitoring the calls or treating some calls differently than others, they lose those protections. The same standards should apply to Internet traffic. If they want to start differentiating service levels, then they should be liable for the problems that they cause.
They're not talking about classifying traffic based on type, they're talking about classifying based on source & destination. They are already being paid to carry traffic. They should be treated by the same common carrier criteria that phone companies are subject to for voice transmissions. It would be like your cellular carrier wanting to charge you extra to not drop your calls. It's BS.
Yes, but probably less than the cost of all the new computers to support the app.
Greetings:
/tmp, /var, etc.) because CF is limited in the number of write cycles that it can withstand, but beyond that, it's no different that installing on any other machine. It's basically just a standard install, plus a RAM disk, a few /etc/fstab entries, and maybe a custom script or two if you want to save/restore the contents of your logs from /var between reboots.
It's been some months since we bought these. I got mine from http://www.hacom.net/. I did a little research on this, and what the guy really sold to us was a Light CV860A with the 533MHz fanless CPU. These units seem to be a little more common now. The hacom site has links to debian CF install with a 2.6 kernel.
But, there's nothing really odd about them. They are just small computers. They'll boot from a USB CD, and you can install an OS. I bought a 512 MB flash card to start and just did a plain Debian install. It worked just fine. You'll want to make sure that you mount heavily written folders to RAM drives (like
Greetings:
We are a nutty lot.
Life's a lot easier when you can buy them for work. Spend other people's money and get paid to play around with the stuff.
The great thing is that with CF cards so cheap, you can get a couple and giving the thing an "OS transplant" is as easy as switching out the cards.
We gave about $400 for boxes with 512MB and no disk. We supplied the CF aftermarket.
Well, performance typically depends on load. We use them as endpoints for remote users, so they vpn back to the office and run X with rdesktop so the users can access the terminal server. We also set them up to do firewall/NAT so that the folks who have other computers at home can share the broadband access with other machines. I haven't had any complaints. We run 512MB of RAM in them, and mount
Greetings:
http://openbrick.org/ is a community of folks doing this kind of stuff. I have purchased a couple of boxes from a US distributor (http://www.hacom.net/ and have been really happy. They have 3 ethernet ports, so they make great firewalls. We use CF cards for storage because we don't need the storage, but you can put little laptop harddrives in them, so you could make a file/print box if you wanted to. They'll boot off of a USB CD, so installation is a breeze. I run Debian, but have installed openbsd for kicks, also. They're cool enough that they don't need an internal fan, so they're quiet too.
I have nothing but nice things to say about them. The US distributor only takes paypal, but he has always delivered without problems. He even called back to see if I liked it.
Because if my options are a cable modem from Comcast or dial-up, I don't have any real options. Maybe someone will run fiber out here, or put up wireless, but until then, you sometimes have to take what you are given.
I wouldn't call it an insurmountable problem, but it wouldn't be as easy as cross-compiling the source code, either.
Server side filters do not generally block the email from coming to you like a virus filter might. They typically tag the message with some text that is consistent and you can filter on that using client side rules, if you wish.
It might add [[SPAM]] to the beginning of the subject if it thinks that the message is spam. It leaves the ultimate decision up to the user how to deal with it.
It does not ever block any mail from coming to you.
And if you are using WEP, you aren't really securing that data right now.
That's not strictly true. The main attacks against WEP are passive listening attacks which require between 5 and 6 million packets to break. Changing the keys before half that many packets are transmitted is the policy that we're using. These are low transmission devices, so that works out to about once a quarter.
After a certain point, it simply becomes easier for someone to break into the building and steal the machines containing the data. Or bribe an employee for the data. At some point you have to be able to justify the amount of money that you're spending against the risk involved.
Either way, it doesn't matter...
But, it does matter. There is still a ton of equipment being manufactured (I'm in the medical industry) that is used for data collection and monitoring that simply has an ethernet jack on it. You plug it into the network, and the server software prods it for data once in a while. Since it's patient data, I can't just broadcast it to the whole world. In a wireless environment, my options are to plug in a wireless to ethernet bridge and run WEP for the encryption, or set up a whole vpn style solution for each device, with VPN capable hardware endpoints for each device.
Don't think that the manufactures of this equipment are going to change their devices, either. The devices are regulated and any changes require recertification by the government. Plus, at 10's of thousands of dollars a pop, I couldn't afford to rebuy it anyway.
There will always be a need for wireless equipment (either part of the radio, or in-line with it) to be able to encrypt and decrypt data that moves over the wireless link.
I still don't understand why people get so wrapped up on encryption at the AP level.
Because every wireless device is not a computer with the processor availble to encrypt and decrypt data. We have lots of wired devices that are wireless enabled by adding a ethernet to wireless bridge. We have legacy systems that still run over telnet. I'll grant you that WEP is not the perfect solution, and that manually changing the keys every quarter is a pain, but making legacy equipment operate in a new environment sometimes takes a hack.
Just out of curiousity, why would you need a whole new domain record to do this? It's fairly common practice to only accept mail from machines listed in a domain's MX record already, and that seems to work pretty well. Using this you could add hosts that were outbound-only for a domain, but I think that might actually be of limited use.
I haven't checked that account since it was @home.com. Good luck getting anything but a bounce. It's a nice try though. Points for effort.
Yes, but -1 Stupid isn't one of the options.
Tom's Harware loves doing stunts like this. They've run processors without coolers just to see what happens, and they investigated problems with the early AMD thermal diodes. Check it out
Greetings:
I run distributed.net on my laptop. When the power is unplugged, the program notices and suspends operation until mains power is returned.
It's so nice when someone thinks these things through beforehand.
Greetings:
I have comcast in Indy and while they might block an odd port here and there, I've had no trouble running ssh & msrdp inbound. I don't run web or mail, but the last time that I checked, the only ports that they were blocking were BackOrifice and something else that I can't remember right off the top of my head. You might try it out and see what you get.
I took a job which requires about 150 miles of travel per day, so I purchased the car for basic transportation. I purchased the manual transmission model due to personal preference, YMMV (literally) with the automatic model. On average, I get between 52 and 58 mpg on basic highway driving at 65 mph. Air conditioning will take 5 mpg off of that. Traveling at 75 mph will drop another 5 to 8 off of that. Wind and weather conditions can effect the mileage as well. Stop and go driving in town with the air on will net me 35 to 40 mpg. Drafting semis on the Interstate at 75 mph will get you 60+ mpg.
I'm a big guy - 6'4" and 250 lbs, and I fit in the machine pretty well. I have about an inch of headroom left. I can get the seat far enough back, but no one but a child would be able to sit behind me.
I paid less than $20000 for it - plus there is a one-time $2000 tax-deduction, so that's a bonus.
I've put about 16000 miles on it so far. It drives and handles like any other 4 cylinder basic transportation car I've ever driven. The torque is better, though, so I don't feel like I'm going to have to get out and push while trying to get onto the Interstate.
Some nits: It takes 0W20 oil, which I've had trouble finding. The good news is that oil changes are only every 5000 miles. It doesn't have much cargo capacity - total weight is only 800 lbs. You can really tell the difference when you have it full. The rear seats don't fold down like a standard Civic (the batteries sit on the rear axle), so the trunk is a little confining. I would only rate it at one-dead-body.
Overall, it's been great regular transportation. I liked it alot better than the other Honda hybrid. That car was smaller and lighter and got pushed around on the Interstate. This is a regular Civic in most every way except the powertrain.