They could be wireless. It might not be easily detectable as cameras.. the frequency range in use could be kept obscure.
There could also be decoy transceivers designed to prevent triangulation of the signal, e.g. impossible to tell the precise location and difference between decoys and real cameras.
You can't look at a picture in your web browser and automatically know where the cameras are.
The border region is massive, there are many lakes and bodies of water in the region, and it should be almost impossible to figure out where these cameras are, unless you happen to know the specific area where the camera happens to be, extremely well.
Probably unless you're border patrol agent, drug trafficker, a local, or an illegal, you have absolutely no chance at all of recognizing the area, which is probably on federal border property.
And probably even 99% of the locals would have no chance of recognizing the body of water or characteristics as a specific area.
The various Texas border regions are approximately 100,000 square miles.
Finding a pinhole camera over such a large area is akin to looking for a specific grain of sand on the beach.
Imagine how many different places the cameras could be if they weren't just in Texas.
The border is massive, and 21 cameras cannot possibly cover a significant portion.
It's good as a pilot project, but the border is thousands of miles long.
Would-be illegal immigrants will eventually get word about regarding which reasons are "safest" or that they're most likely to succeed at in crossing.
Probably forested most geographically hostile areas, where cameras can't easily be placed, are going to be more favored crossing points.
The low number of border agents places them at significant advantage to catching or outrunning illegal immigrants in geographically hostile areas where vehicles can't ride.
Especially if any of the illegal immigrants have "invisibility cloaks", EMPs, or other technological sophistication involved in their efforts.
I believe the term is "crowdsourcing", or in this case, "sponsored crowdsourcing", where the citizens want their border protected, and there is not enough manpower or money for the government to do it.
However, I doubt it will catch on much, unless there is incentive/award to successfully identify illegal crossing that requires a high 'hit ratio' or low rate of false reports to claim a reward.
It is not vigilantism for citizens to assist law enforcement in enforcing the laws of the country.
It is responsible citizenship, and it is getting involved, which are good things.
For a virtualized server, encrypt your data partition. Include an/etc/cryptab entry, and a script in the normal boot process that will mount the encrypted volume.
If they do something simple like single mode boot, or a Knoppix CD..
The decrypt script will not execute.
Even more interesting, would be if the decrypt script were disguised by making it a binary program, and the script requires another server to SSH in with a pre-arranged public key authentication and actually perform the final cryptsetup operation to activate the volume.
Be prepared to switch providers and file criminal charges against them under the Computer Fraud and Abuse act.
As for mitigating the chance of root compromise:
Use a server with a remote SP, eg iLO, DRAC, that has virtual serial port
Enable login via serial port
In BSD: Mark Console as insecure in/etc/ttys
Set a BIOS password to be required for configuration changes. This will be a fairly strong deterrant if your server stores BIOS info in NVRAM. Specialized knowledge will be required of your specific server hardware to jumper the right pin for BIOS password bypass
Set Hard drives FIRST in the boot order, so the system will not boot from removable media.
Set a bootloader password, e.g. for Linux systems, set a grub password, that will be required to change OS boot options.
Enable hard drive encryption. E.g. on a clean install of OSes such as Fedora, you will be provided an option to encrypt your boot drive.
The downside of HDD encryption is: if a password is required to start the system, then it will be down after every reboot/power cycle, until you key in your password.
The use of iLO, DRAC, etc, remove KVM over IP to your server, or remote serial port (if you select serial), allows you to enter the password remotely.
The presence of neutral microbes offers resource competition against random microbes taking up residence, especially harmful ones.
Since there is competition, new Microbes of any sort, are less likely to flourish unchecked, than if there was no competition.
Think of how many computer users would be using MacOS or Linux KDE, if Windows didn't exist, or if Microsoft were to suddenly drop dead and stop making new versions of Windows that were successful at competing for placement on people's computers.
The loss/extinction of some of these neutral, or even beneficials microbes could be quite bad, if it makes humans more vulnerable to spontaneous intrusion by others and digestive system issues.
The less diversity in the neutral microbes... the more likely that a malicious microbe releases one toxin that happens to kill them all.
No it's not a "fine" answer. Whenever "Reload in X" will cause a more widespread issue than a misconfig, or reload can disrupt an even more important network/function served by your router, than the one you are making changes to.
You may be trading an outage or disruption of 10% of your LAN subnets due to misconfig, for a global Enterprise outage or 50% outage, including mission-critical subnets, due to reload of a key router (possibly mitigated by redundancy, but possibly not). Oh, and the auto-reload blew away the logs needed to review/help trace whatever was wrong too...
Remember your workstation can blue screen (for unrelated reason) just after you type "reload in X".
Just because it's all the vendor gives you, and the best you can do, does not mean it is a fine, safe, or good, answer.
There's a difference between "having a good answer", and making do with an obviously deficient solution (such as reload in X)
"reload in X" works in a brute-force sledgehammer sort of way, and in some cases it might be acceptable, especially for edge devices in small branch offices, where the overall effect to the enterprise is miniscule, but it also has serious drawbacks.
The 10-20 minute delay for a router to reboot, alone, during which it is completely out, is a serious deficiency with the command.
If some emergency is forcing you to make significant changes outside a maintenance window "commit confirmed 3" is 10000% safer on your router-that-handles-thousands-of-your-subnets than "reload in 3"
The difference is the severity of what happens should you not confirm or cancel the rollback/reboot in time.
Cisco's kron can't do what JunOS commit/rollback/snapshot does; frankly, kron, and most IOS configuration management options are very feeble. In fact, JunOS commit/rollback allows you to compare (diff), show you only the changes, and rollback to any prior version of the config. No configuration change is made until a 'commit' is done.
All changes occur at the commit, so if you make a series of changes to an existing firewall rule, you can re-check them as many times as you want after typing them, before placing all the changes into effect.
This reduces the chance of error in the first place.
You can write pre-commit scripts to validate configs for common errors, before an attempt will even be made to apply them, as you would expect from proper configuration management systems,.
Only the specific services whose config is being changed normally see any disruption...
You may misconfig that disrupts a part of your network for a time.
Selected auto-rollback, allows you to undo your change without taking down the entire router, without so much as bouncing other services, such as routing protocol adjacencies, RIP peers, OSPF adjs, BGP peers, etc, which would definitely bounce with "reload in X", and can cause longer term disruptions, including spanning tree hits, and such..
In some environments, that is frustrated by other (lazy) technical staff, who immediately start automatically blaming _every_ problem they find for the next few weeks, on that one change, without even doing any helpful troubleshooting, or finding any reason at all to suggest it might be the case.
The problem is unrelated and would happen anyways, but because they heard of a recent change, there is a cognitive bias towards immediately suspecting the new change, just because it's a change they know about.
"I didn't change anything, so if I just started getting a few problem reports it must be your change"
This is the sort of thing that may annoy some technical workers, and possibly cause them to not report certain minor changes as widely as they could.
Desktop support should not care much, for example, if the network team changes security measures on routers protecting administration access, or performs regular password changes, there are lots of minor changes that don't merit announcing.
It's trouble enough that technical staff (esp. Desktop admin types) often seem to automatically think perfectly innocent network devices, routers, firewalls, switches, need to rebooted, before exhausting obvious causes like software/Windows problems.
"Someone was getting '504 page not found' errors trying to reach some web site.. so i'm power cycling the router labelled "Catalyst 6509-E core switch" in the wire closet, to see if it helps.. (You're doing what??)"
Router's LAN Interface -> Patch Panel -> Ethernet Port Under your desk -> Straight cable plugged into other port under your desk -> Patch Panel -> Firewall/Security Appliance Outside LAN Interface.
So by kicking out that cable, you separate LAN from router...
Or, by kicking out power to the 5-port hub under your desk you temporarily used to sniff traffic between the firewall and your site's edge router.
Until one afternoon when the janitor unplugs something from a power strip under your desk, to get an outlet for their vacuum, and the main router happens to go down....
I think it's taken for granted as an expected part of the job, that the minimum things engineers/architects are supposed to do is prevent emergencies from happening.
If a bad enough emergency does happen, they might get fired for 'not doing their job', but they'll rarely ever get commended when their design works and protects the enterprise against certain doom.
Except by other engineers... I think (to some extent), that's just life.
How's a non-technical person supposed to tell the difference between the network being stable because it was well designed, and the network being stable, because the thing that can bring it all down just hasn't ever happened to have had any issues yet?
You'd be surprised how long a network with crucial issues can appear on the surface to be just fine, only to one day have a catastrophe due to the poor design, years later, when least expected....
Only network engineers are really qualified to really give this type of credit.. whereas any bimbo off the street can see when someone fixed an emergency [even if their own mistake caused it -- from many people, you will not get an admission of guilt, by avoiding admitting it, they can make it appear they are cleaning up after someone or something else]:)
"reload in 10" on a core router or switch (eg a massive switch that also has routing duties) is insane, and will probably impact the entire network, for 20-30 minutes, if you accidentally lock yourself out (but don't otherwise impact anything) and fail to cancel that reload.
In addition, reload is risky, and the equipment may fail to come back up correctly.
Sorry, it's not anywhere close to comparable to the configuration management features in JunOS.
"Reload in X" is a bad answer, and should never be done, except on equipment that doesn't matter that much, or at a time when an hour of downtime is completely expected and acceptable.
See how much approval you have to get when the network is down because of a failed GBIC.
Redundancies against component failure are very good for the enterprise, but also make it harder for engineers to do their job, since "nobody notices that something has gone wrong".
Perhaps the real redundancies should be reserved for the absolute most business-critical things.
Make sure less important things are non-redundanct and arranged in a way, so that if any link or GBIC does fail, something noticeable to management will stop working, and cannot be restored without fixing the broken thing.
My personal favorite thing about JunOS is "commit confirmed 10"
This can be a lifesaver, if you fat fingered something, and you break even your ability to access to the device, your transaction should roll back in 10 minutes.
If nothing goes wrong, you have 9 minutes to do some simple sanity checks, make sure your LAN is still working, and then get back to your CLI session and confirm the change.
you'll almost always get an "are you sure" before you do something stupid, and definitely before you do something irreversible.
Except it's not really true.
An example would be you accidentally hit the 'Save' button for a document after making a major error such as blowing away important text..
Then you panic and exit the program... go back to My Documents, to re-open the file, only to find the file is still blank.
There are thousands of similar cases.
Accidentally dragging files to some folder, and forgetting about them..
accidentally dragging folders to the trash...
But may favorite is... acidentally visiting a website with a drive-by malware downloader, or downloading and trying to install a file with malware undetectable by any common antimalware.
In that case, the damage is most severe, and potentially quite irreversible (without formatting)
Too slow to use Facebook intensively and have a seamless experience, with Video and everything..
their service.
Even though their service may be advertised at 6 Megs peak, doesn't necessarily mean customers will get a service that allows them to have the best experience with services that benefit low-latency.
For example, their "3 Megs" peak, connection, may only provide the customer 1 meg most of the time, with bursts up to 3 megs.
They could believe that their service degraded on the low-end version so much that, you need a 3 meg service choice to reliably get 1.5 megs, and a 6 meg service to reliably get 3 megs without some serious latency and packet loss at those bitrates.
Well, I find that Simple file sharing, for basic documents, and upload/download.. usually works fine.
But have you tried running applications on the Windows XP clients utilizing backend/database files on a samba share, when the app requires locking files, keeping those locks for extended periods of time, and sharing those files between multiple simultaneous users?
I speak specifically of using applications that utilize a shared Access or Jet database on a share, but to some extent, even things like Shared spreadsheets (with multiple users opening the same spreadsheet at the same time, using that particular functionality).
Visual sourcesafe.
And a bunch of other apps of this nature.
In my experience Samba generally works well for file sharing, but it's often a pain to try to make certain apps work right on Samba file shares, even though they work perfectly on file shares hosted on a Windows server.
I've actually had issues that resulted in data corruption of 3rd party apps' data served by RHEL5 samba.
And (more rarely) in Windows clients getting disconnected from Samba servers during active data transfers.
And even applications not wanting to work at all.
They worked fine when their database file was moved to a Windows server.
It may be fine for some file sharing, but I think it's a real stretch to say there are zero compatibility issues left between Samba and Windows.
If proprietary filesystems are on the table, how about VxFS ?
Another possibility is to use FAT with cross-platform backup software.
Maybe you don't need a filesystem at all: if this really is for backups...
why not just create lots of extended partitions on the device and use TAR ?
AKA tar cf/dev/sdbXX -V 'VOLUME_A'/backup
That's crude and hard to keep organized, but also effective. Also, Some proprietary backup products that will work on a FAT filesystem, and not require large file support, even to backup large files
Or utilize a tool such as WINRAR that allows you to "split" a RAR file across multiple archives in chunks of a certain size, then store these files on a FAT filesystem.
FAT is the most cross-platform, oldest. But has known issues with fragmentation, and lack of journaling, effects reliability.
You could divide your backup volume into 2 partitions:
one DOS/FAT partition with the bootable image and files required to 'load a virtual machine' that can see the files on the other partition in the preferred data format such as ZFS or FFS (e.g. pre-allocated eager zeroed thick VMware VMDK with 'split into 2gb files' enabled).
Then you just make sure the system you plug the drive into can boot a VM, with your "backup/file access environment"
You think there are no compatibility problems between a Linux fileserver running Samba and NFS, and a Windows machine?
First of all, the stock NFS implementation available in 2003 R2 doesn't work as well as you might imagine...
And Windows clients frequently have compatibility issues with Samba servers all the time, especially when Microsoft releases updates to the client software.
Esp. when it comes to things like domain membership, and file permission.
That said, the compatibility snags are minor compared to raw filesystem compatibility across multiple OSes.
You do realize, most of large ISPs' bread and butter are big companies that bring their own IP ranges?
Their customers aren't subject to blacklisting, their own infrastructure is kept well apart from blocks that are assigned to customers.
Blacklisting doesn't hurt the big ISPs themselves, it hurts subscribers and smaller ISPs.
Frankly, huge ISPs need so many ip addresses legitimately, that the 5% or so of their ranges getting blacklisted may just be their cost of doing business.
ISP subdelegations are handed out to the little guys.
You take what you get, and you won't know it's blacklisted, until you're already paying for the service.
The little guy (unless an ISP themselves) is usually too little to negotiate custom terms like "approving/vetting their IP allocation against existing blacklisting"
Community (and perhaps regulatory) pressure is the best tool to make big players do anything.
Also, many see reduction of spam as a noble goal.
However, for big corporations, taking care of every spam source may not be feasible, or it may be a massively expensive undertaking.
This is not likely to be looked on favorably by the suits. It's cheaper to acquire more IPs.
No, then your inbound traffic for your/24 advertisements starts coming in from the other ISP you have not ceased the announcement to.
And your outbound traffic stops going to the ISP who killed their peering session with you (since the routing process on your router will immediately withdraw the routes advertised by that particular upstream peering session which is no longer "up").
Well, this is all assuming the spammer has a proper (expensive) multi-homed setup, which I doubt too.
In truth it's not necessary. The spammer may very well have a bunch of NAT boxes in front of all their spam sources. When an ISP turns them off, or they detect an inability to perform their "liveness" test on a given link, their spam sources just immediately swap over to a different NAT box in their spamnet.
One or more DirectAccess servers running Windows Server 2008 R2 with two network adapters: one that is connected directly to the Internet, and a second that is connected to the intranet
It will be a cold day in Hell before I
plug a Windows system in both outside and inside the firewall.
Seriously, is Microsoft suggesting you hang pwn me signs on your servers too?
To be clear. Best practices has been and always will be to place a firewall between all your servers and the internet.
It would make more sense if the requirement was to plug one NIC into a trusted DMZ for remote access users to attach to (and gain slightly-elevated privileges), and another NIC into a less-trusted DMZ, to accept only valid DirectAccess traffic.
I wouldn't say it's so clear. A contract issue is definitely a legal issue, and depends on the terms of the contract, and also what country a provider operates in, and what is legal in that country..
In many countries, the policy of coercing customers into providing access may run afoul of the Data Protection / Wiretap acts, according to the customer information stored on that equipment.
Also, no matter what the terms of a contract actually say, certain acts such as extortion are always illegal, and a contract cannot allow illegal actions, no matter what the words say.
Forcing someone to give a provider full access to their collocated servers, or else lose a service critical to them that they had paid for, is highly irregular, a compromise of their privacy, possibly their customer's privacy.
If, e.g. an e-commerce web site is hosted on the equipment, it is fair to assume such a server many contain information subject to the Data Protection act, such as names, addresses.
And likely to result in action.. that is, assuming the customer wasn't a spammer.
The issue isn't so much gaining unauthorized access to a spammer's "empty" server... it's
forcing entry to a legitimate server or tampering with their equipment (if you were mistaken about them being a spammer).
Slashdot Mirror
They could be wireless. It might not be easily detectable as cameras.. the frequency range in use could be kept obscure.
There could also be decoy transceivers designed to prevent triangulation of the signal, e.g. impossible to tell the precise location and difference between decoys and real cameras.
They're relying on obscurity.
You can't look at a picture in your web browser and automatically know where the cameras are.
The border region is massive, there are many lakes and bodies of water in the region, and it should be almost impossible to figure out where these cameras are, unless you happen to know the specific area where the camera happens to be, extremely well.
Probably unless you're border patrol agent, drug trafficker, a local, or an illegal, you have absolutely no chance at all of recognizing the area, which is probably on federal border property.
And probably even 99% of the locals would have no chance of recognizing the body of water or characteristics as a specific area.
The various Texas border regions are approximately 100,000 square miles. Finding a pinhole camera over such a large area is akin to looking for a specific grain of sand on the beach.
Imagine how many different places the cameras could be if they weren't just in Texas.
The border is massive, and 21 cameras cannot possibly cover a significant portion.
It's good as a pilot project, but the border is thousands of miles long.
Would-be illegal immigrants will eventually get word about regarding which reasons are "safest" or that they're most likely to succeed at in crossing.
Probably forested most geographically hostile areas, where cameras can't easily be placed, are going to be more favored crossing points.
The low number of border agents places them at significant advantage to catching or outrunning illegal immigrants in geographically hostile areas where vehicles can't ride.
Especially if any of the illegal immigrants have "invisibility cloaks", EMPs, or other technological sophistication involved in their efforts.
I believe the term is "crowdsourcing", or in this case, "sponsored crowdsourcing", where the citizens want their border protected, and there is not enough manpower or money for the government to do it.
However, I doubt it will catch on much, unless there is incentive/award to successfully identify illegal crossing that requires a high 'hit ratio' or low rate of false reports to claim a reward.
It is not vigilantism for citizens to assist law enforcement in enforcing the laws of the country. It is responsible citizenship, and it is getting involved, which are good things.
For a virtualized server, encrypt your data partition. Include an /etc/cryptab entry, and a script in the normal boot process that will mount the encrypted volume.
If they do something simple like single mode boot, or a Knoppix CD..
The decrypt script will not execute.
Even more interesting, would be if the decrypt script were disguised by making it a binary program, and the script requires another server to SSH in with a pre-arranged public key authentication and actually perform the final cryptsetup operation to activate the volume.
Be prepared to switch providers and file criminal charges against them under the Computer Fraud and Abuse act.
As for mitigating the chance of root compromise:
The presence of neutral microbes offers resource competition against random microbes taking up residence, especially harmful ones.
Since there is competition, new Microbes of any sort, are less likely to flourish unchecked, than if there was no competition.
Think of how many computer users would be using MacOS or Linux KDE, if Windows didn't exist, or if Microsoft were to suddenly drop dead and stop making new versions of Windows that were successful at competing for placement on people's computers.
The loss/extinction of some of these neutral, or even beneficials microbes could be quite bad, if it makes humans more vulnerable to spontaneous intrusion by others and digestive system issues.
The less diversity in the neutral microbes... the more likely that a malicious microbe releases one toxin that happens to kill them all.
No it's not a "fine" answer. Whenever "Reload in X" will cause a more widespread issue than a misconfig, or reload can disrupt an even more important network/function served by your router, than the one you are making changes to.
You may be trading an outage or disruption of 10% of your LAN subnets due to misconfig, for a global Enterprise outage or 50% outage, including mission-critical subnets, due to reload of a key router (possibly mitigated by redundancy, but possibly not). Oh, and the auto-reload blew away the logs needed to review/help trace whatever was wrong too...
Remember your workstation can blue screen (for unrelated reason) just after you type "reload in X".
Just because it's all the vendor gives you, and the best you can do, does not mean it is a fine, safe, or good, answer. There's a difference between "having a good answer", and making do with an obviously deficient solution (such as reload in X)
"reload in X" works in a brute-force sledgehammer sort of way, and in some cases it might be acceptable, especially for edge devices in small branch offices, where the overall effect to the enterprise is miniscule, but it also has serious drawbacks.
The 10-20 minute delay for a router to reboot, alone, during which it is completely out, is a serious deficiency with the command. If some emergency is forcing you to make significant changes outside a maintenance window "commit confirmed 3" is 10000% safer on your router-that-handles-thousands-of-your-subnets than "reload in 3"
The difference is the severity of what happens should you not confirm or cancel the rollback/reboot in time.
Cisco's kron can't do what JunOS commit/rollback/snapshot does; frankly, kron, and most IOS configuration management options are very feeble. In fact, JunOS commit/rollback allows you to compare (diff), show you only the changes, and rollback to any prior version of the config. No configuration change is made until a 'commit' is done.
All changes occur at the commit, so if you make a series of changes to an existing firewall rule, you can re-check them as many times as you want after typing them, before placing all the changes into effect. This reduces the chance of error in the first place.
You can write pre-commit scripts to validate configs for common errors, before an attempt will even be made to apply them, as you would expect from proper configuration management systems,.
Only the specific services whose config is being changed normally see any disruption...
You may misconfig that disrupts a part of your network for a time. Selected auto-rollback, allows you to undo your change without taking down the entire router, without so much as bouncing other services, such as routing protocol adjacencies, RIP peers, OSPF adjs, BGP peers, etc, which would definitely bounce with "reload in X", and can cause longer term disruptions, including spanning tree hits, and such..
In some environments, that is frustrated by other (lazy) technical staff, who immediately start automatically blaming _every_ problem they find for the next few weeks, on that one change, without even doing any helpful troubleshooting, or finding any reason at all to suggest it might be the case.
The problem is unrelated and would happen anyways, but because they heard of a recent change, there is a cognitive bias towards immediately suspecting the new change, just because it's a change they know about.
"I didn't change anything, so if I just started getting a few problem reports it must be your change"
This is the sort of thing that may annoy some technical workers, and possibly cause them to not report certain minor changes as widely as they could. Desktop support should not care much, for example, if the network team changes security measures on routers protecting administration access, or performs regular password changes, there are lots of minor changes that don't merit announcing.
It's trouble enough that technical staff (esp. Desktop admin types) often seem to automatically think perfectly innocent network devices, routers, firewalls, switches, need to rebooted, before exhausting obvious causes like software/Windows problems.
"Someone was getting '504 page not found' errors trying to reach some web site.. so i'm power cycling the router labelled "Catalyst 6509-E core switch" in the wire closet, to see if it helps.. (You're doing what??)"
Not power, the Ethernet feed :)
Router's LAN Interface -> Patch Panel -> Ethernet Port Under your desk -> Straight cable plugged into other port under your desk -> Patch Panel -> Firewall/Security Appliance Outside LAN Interface.
So by kicking out that cable, you separate LAN from router...
Or, by kicking out power to the 5-port hub under your desk you temporarily used to sniff traffic between the firewall and your site's edge router.
Until one afternoon when the janitor unplugs something from a power strip under your desk, to get an outlet for their vacuum, and the main router happens to go down....
I think it's taken for granted as an expected part of the job, that the minimum things engineers/architects are supposed to do is prevent emergencies from happening.
If a bad enough emergency does happen, they might get fired for 'not doing their job', but they'll rarely ever get commended when their design works and protects the enterprise against certain doom.
Except by other engineers... I think (to some extent), that's just life.
How's a non-technical person supposed to tell the difference between the network being stable because it was well designed, and the network being stable, because the thing that can bring it all down just hasn't ever happened to have had any issues yet?
You'd be surprised how long a network with crucial issues can appear on the surface to be just fine, only to one day have a catastrophe due to the poor design, years later, when least expected....
Only network engineers are really qualified to really give this type of credit.. whereas any bimbo off the street can see when someone fixed an emergency [even if their own mistake caused it -- from many people, you will not get an admission of guilt, by avoiding admitting it, they can make it appear they are cleaning up after someone or something else] :)
Yes.. the only problem with this approach, is that now robot Santa might judge you naughty for lying, and fill your stocking with nasty things :-/
"reload in 10" on a core router or switch (eg a massive switch that also has routing duties) is insane, and will probably impact the entire network, for 20-30 minutes, if you accidentally lock yourself out (but don't otherwise impact anything) and fail to cancel that reload.
In addition, reload is risky, and the equipment may fail to come back up correctly.
Sorry, it's not anywhere close to comparable to the configuration management features in JunOS.
"Reload in X" is a bad answer, and should never be done, except on equipment that doesn't matter that much, or at a time when an hour of downtime is completely expected and acceptable.
See how much approval you have to get when the network is down because of a failed GBIC.
Redundancies against component failure are very good for the enterprise, but also make it harder for engineers to do their job, since "nobody notices that something has gone wrong".
Perhaps the real redundancies should be reserved for the absolute most business-critical things.
Make sure less important things are non-redundanct and arranged in a way, so that if any link or GBIC does fail, something noticeable to management will stop working, and cannot be restored without fixing the broken thing.
My personal favorite thing about JunOS is "commit confirmed 10"
This can be a lifesaver, if you fat fingered something, and you break even your ability to access to the device, your transaction should roll back in 10 minutes.
If nothing goes wrong, you have 9 minutes to do some simple sanity checks, make sure your LAN is still working, and then get back to your CLI session and confirm the change.
you'll almost always get an "are you sure" before you do something stupid, and definitely before you do something irreversible.
Except it's not really true.
An example would be you accidentally hit the 'Save' button for a document after making a major error such as blowing away important text..
Then you panic and exit the program... go back to My Documents, to re-open the file, only to find the file is still blank.
There are thousands of similar cases.
Accidentally dragging files to some folder, and forgetting about them.. accidentally dragging folders to the trash...
But may favorite is... acidentally visiting a website with a drive-by malware downloader, or downloading and trying to install a file with malware undetectable by any common antimalware.
In that case, the damage is most severe, and potentially quite irreversible (without formatting)
Too slow to use Facebook intensively and have a seamless experience, with Video and everything..
their service.
Even though their service may be advertised at 6 Megs peak, doesn't necessarily mean customers will get a service that allows them to have the best experience with services that benefit low-latency.
For example, their "3 Megs" peak, connection, may only provide the customer 1 meg most of the time, with bursts up to 3 megs.
They could believe that their service degraded on the low-end version so much that, you need a 3 meg service choice to reliably get 1.5 megs, and a 6 meg service to reliably get 3 megs without some serious latency and packet loss at those bitrates.
Well, I find that Simple file sharing, for basic documents, and upload/download.. usually works fine.
But have you tried running applications on the Windows XP clients utilizing backend/database files on a samba share, when the app requires locking files, keeping those locks for extended periods of time, and sharing those files between multiple simultaneous users?
I speak specifically of using applications that utilize a shared Access or Jet database on a share, but to some extent, even things like Shared spreadsheets (with multiple users opening the same spreadsheet at the same time, using that particular functionality).
Visual sourcesafe.
And a bunch of other apps of this nature.
In my experience Samba generally works well for file sharing, but it's often a pain to try to make certain apps work right on Samba file shares, even though they work perfectly on file shares hosted on a Windows server.
I've actually had issues that resulted in data corruption of 3rd party apps' data served by RHEL5 samba. And (more rarely) in Windows clients getting disconnected from Samba servers during active data transfers.
And even applications not wanting to work at all. They worked fine when their database file was moved to a Windows server.
It may be fine for some file sharing, but I think it's a real stretch to say there are zero compatibility issues left between Samba and Windows.
If proprietary filesystems are on the table, how about VxFS ?
Another possibility is to use FAT with cross-platform backup software. Maybe you don't need a filesystem at all: if this really is for backups... why not just create lots of extended partitions on the device and use TAR ?
AKA tar cf /dev/sdbXX -V 'VOLUME_A' /backup
That's crude and hard to keep organized, but also effective. Also, Some proprietary backup products that will work on a FAT filesystem, and not require large file support, even to backup large files
Or utilize a tool such as WINRAR that allows you to "split" a RAR file across multiple archives in chunks of a certain size, then store these files on a FAT filesystem.
FAT is the most cross-platform, oldest. But has known issues with fragmentation, and lack of journaling, effects reliability.
You could divide your backup volume into 2 partitions: one DOS/FAT partition with the bootable image and files required to 'load a virtual machine' that can see the files on the other partition in the preferred data format such as ZFS or FFS (e.g. pre-allocated eager zeroed thick VMware VMDK with 'split into 2gb files' enabled).
Then you just make sure the system you plug the drive into can boot a VM, with your "backup/file access environment"
You think there are no compatibility problems between a Linux fileserver running Samba and NFS, and a Windows machine?
First of all, the stock NFS implementation available in 2003 R2 doesn't work as well as you might imagine...
And Windows clients frequently have compatibility issues with Samba servers all the time, especially when Microsoft releases updates to the client software. Esp. when it comes to things like domain membership, and file permission.
That said, the compatibility snags are minor compared to raw filesystem compatibility across multiple OSes.
You do realize, most of large ISPs' bread and butter are big companies that bring their own IP ranges?
Their customers aren't subject to blacklisting, their own infrastructure is kept well apart from blocks that are assigned to customers. Blacklisting doesn't hurt the big ISPs themselves, it hurts subscribers and smaller ISPs.
Frankly, huge ISPs need so many ip addresses legitimately, that the 5% or so of their ranges getting blacklisted may just be their cost of doing business.
ISP subdelegations are handed out to the little guys.
You take what you get, and you won't know it's blacklisted, until you're already paying for the service.
The little guy (unless an ISP themselves) is usually too little to negotiate custom terms like "approving/vetting their IP allocation against existing blacklisting"
Community (and perhaps regulatory) pressure is the best tool to make big players do anything.
Also, many see reduction of spam as a noble goal.
However, for big corporations, taking care of every spam source may not be feasible, or it may be a massively expensive undertaking.
This is not likely to be looked on favorably by the suits. It's cheaper to acquire more IPs.
And which point is that?
No, then your inbound traffic for your /24 advertisements starts coming in from the other ISP you have not ceased the announcement to.
And your outbound traffic stops going to the ISP who killed their peering session with you (since the routing process on your router will immediately withdraw the routes advertised by that particular upstream peering session which is no longer "up").
Well, this is all assuming the spammer has a proper (expensive) multi-homed setup, which I doubt too.
In truth it's not necessary. The spammer may very well have a bunch of NAT boxes in front of all their spam sources. When an ISP turns them off, or they detect an inability to perform their "liveness" test on a given link, their spam sources just immediately swap over to a different NAT box in their spamnet.
It will be a cold day in Hell before I plug a Windows system in both outside and inside the firewall.
Seriously, is Microsoft suggesting you hang pwn me signs on your servers too?
To be clear. Best practices has been and always will be to place a firewall between all your servers and the internet.
It would make more sense if the requirement was to plug one NIC into a trusted DMZ for remote access users to attach to (and gain slightly-elevated privileges), and another NIC into a less-trusted DMZ, to accept only valid DirectAccess traffic.
No legal problem there. It's a contract issue.
I wouldn't say it's so clear. A contract issue is definitely a legal issue, and depends on the terms of the contract, and also what country a provider operates in, and what is legal in that country..
In many countries, the policy of coercing customers into providing access may run afoul of the Data Protection / Wiretap acts, according to the customer information stored on that equipment.
Also, no matter what the terms of a contract actually say, certain acts such as extortion are always illegal, and a contract cannot allow illegal actions, no matter what the words say.
Forcing someone to give a provider full access to their collocated servers, or else lose a service critical to them that they had paid for, is highly irregular, a compromise of their privacy, possibly their customer's privacy.
If, e.g. an e-commerce web site is hosted on the equipment, it is fair to assume such a server many contain information subject to the Data Protection act, such as names, addresses.
And likely to result in action.. that is, assuming the customer wasn't a spammer.
The issue isn't so much gaining unauthorized access to a spammer's "empty" server... it's forcing entry to a legitimate server or tampering with their equipment (if you were mistaken about them being a spammer).