If you're in CA I'm guessing that SBC (Pacbell/whatever you know them as) is the local telco that provides the fiber service to your prem. I think you should be able to get diverse pathing from them. It will cost you some $$$, but is sounds like your organization is willing to pay for redundancy. They should be willing to do diverse pathing to your local CO, or diverse pathing to separate COs. You ought to be able to get strands going out of two separate conduits from your building, and completely separate conduits all the way to your local CO, or another nearby CO. You could have a CO SONET node in your closeset CO as well as a CO SONET node in a nearby CO and feed to your upstream provider from there (dunno if your upstream is PBI, which should definately do this, or another provider, who should as well). That way you can set up a healing SONET ring that will survive (in theory) a fiber cut (yes, they do happen. Even in our lovely CA:P ) or a CO outage (as long as your upstream can feed you from both COs). If you have a large enough netblock you should be able to get a connection from a second Internet provider and run BGP with them. Your problem then will be summarization at close by peering point, which is a complexity that you can get around (at a $$$ cost, of course). Just be aware that CO failures, cable cuts, and peering point failures all do happen, but you can always minimize or mostly eliminate if your organization is willing to make a dollar committment to it.
For the record, I am not an expert on this, but I have a bit of experience under my belt.
Bringing a qualified electrician along when looking for new office space. Or at least having an electrician give it a looking over before you sign a lease. They should be able to look at the power coming into the building as well as the current distribution system within the building and give you some idea as to whether or not it could meet your needs.
Total available amperage to your offices doesn't always do you a whole lot of good if you can't get the circuits you need to your server rooms. Be sure to discuss with the landlord any plans you may have to add or move existing circuits around.
That link isn't exactly what they want. I'm pretty sure they need a PA-MC-T3 card. I had thought that the PA-MC-T3 might not be supported in the FlexWan blades, but I checked and I was wrong, so you could go with a FlexWan with a PA-MC-T3. Also, on the paying list issue, I agree. You shouldn't have to pay MSRP on your Cisco gear. If you can't get a break, ask your telco. They might be a large Cisco reseller and could get you a good price (esp if you're starting order bigger pipes from them). They are going to be seeing the monthly recurring $$$ from this DS3, so they might be very willing to give you a good discount on the routing gear.
This kinda goes back to what I was saying here and here. Again, we need more information from the requestor. Driving 12Mbps out of a HSSI might not meet their needs if they are going channelized to pull a bunch of DS1s into a DS3. I can't really think a way off the top of my head to do that with a 3600+HSSI without your telco/upstream doing some fancy stuff. One way the telco could do it is term the DS3 on one of their boxes and hand the traffic back off to the customer across a point-to-point DS3 terminating on a customer 3600+HSSI router. That would take a lot of the control out of the hands of the customer and would cost the telco a bit of money. I'd imagine the cost would offset the savings of buying a 3600 with a HSSI instead of a 7x00 with PA-MC-T3. I've agree with you that if you can't justify a one time $30k cost that you've got to think really hard about what you're doing. Maybe the original poster works in public sector where you can often get dirt cheap telco rates so the one time equipment costs look really really high compared to monthly recurring. The more I think about this Ask Slashdot the more I want to know the driving factors behind it. Perhaps a channelized DS3 isn't the right solution for them. I really wish they'd given us some insight into their design goals with this project...
Maybe, maybe not... I took a quick peek at those cards and they both looked like clear channel DS3. I'm kinda going along on fuzzy memory here, but I think that if its channelized you need a M13 framer on the board to break out the T1s. I don't think you'll be able to do that in software. Something like this card may do the trick, but its only appears to have WinNT and VxWare support. The problem with the clear channel cards is you have to break the DS3 down into DS1 channels and provide framing on those channels which is quite I think is generally done in hardware.
I'd say that if you're pulling in a channelized DS its prolly not coming from your ISP. You generally see people pull those in if they have a bunch of remote sites that need DS1 connectivity. You'll run the DS3 to a CO MUX and break the DS1s out of there. As far as getting a cheap cisco router to handle a channelized DS3, you might be out of luck. I'm pretty sure there's not a card for the 2600/3600 series to do that. I think that the smallest card may be a PA-MC-T3 which means you're looking at a 7200/7300 style box. Getting those up to $30k is pretty easy, depending on the options you need. I'd personally shy away from running a linux box with a channelized DS3 board. If you have problems with your line just about anyone you work with will be able to help you troubleshoot a Cisco with a channelized DS3 board. If you do end up going with a Linux box make sure that you can do things like run BERT on the DS1 channels. Otherwise troubleshooting will be a bitch.
Some paging providers still offer TAP interfaces, you may just have to switch paging providers. I think we are currently using a TAP interface to send pages to a 'page group' that has all of the NOCish ppl in it so we only have to make one outgoing call to page everyone with UP/DOWNS. IIRC we worked for a while with a Nextel rep and were able to get TAP access for text messaging to Nextel phones, so if you're a Nextel shop you may want to look into that. I don't know if you can get page groups with the Nextel TAP interface, I seem to remember the paging interface having to make many calls to Nextel to get the page out to everyone.
If you are talking about a 'large-ish' local network then splitting 10/8 into smaller blocks looks pretty good on paper. You can split it into/16s and delegate those to departmental level net admins who will then divide them into/24s for individual VLANS. It helps if you do a big plan upfront. This way if let say you know that HR, accounting, and marketing are restricted to one site you can assign them a glob of/16s that you can summarize on the routers to keep the routing tables nice and small. You can also assign ranges to classes of machines. For example if you knew that all your 'all company' web servers lived in the 10.10.10/24 range and the Citrix farm that fronts for your HR system lived in the 10.10.11/24 range and you had a subnet with users that just needed access to the HR system and the 'all company' web servers you could write a quick acl to permit http and https to 10.10.10/24 and ica to 10.10.11/24. This is a lot easier that consulting your IP database and looking up the IPs of all the web servers and all the HR Citrix boxen and crafting a nasty long ACL. Now, if you're just talking about your home LAN it prolly doesn't matter what you use. If you're planning on VPNing into your work network life will be easier if you pick a range that doesn't overlap with any of the RFC1918 addys they use. As for the people who are suggesting that if you have a large network you need to pick ranges that don't overlap with networks you plan to interface with, I wouldn't worry too much. Most companies that interface with with other networks on regular basis have ranges of 'legit' IPs that they use for extranet connections. Or they're used to playing the firewall NAT game. Doing the "network to firewall/NAT to outside agency firewall/NAT to outside agency network" thing usually isn't that bad. People get good at it after while. Once you've done a few it'll be just another annoyance.:P
When you talk about 'reliability' it sounds like you are talking about longevity. In addition to hw failures you also have to worry about the AP's ability to be upgraded to keep up with new authentication/authorization methods and other such software/firmware improvements. That is the biggest difference between the low end and the high end APs. We use Cisco APs and bridges for this very reason. We were steered this direction because we are a Cisco shop, so I'm not by any means trying to steer people towards Cisco APs. That being said, we have been happy with them, but I also know of people who have AP installs using other 'high-end' APs with similar success. At my home I have a Linksys box (one of the gateway/wireless/4 port hub boxes) and it has been working alright for a couple years now. With earlier firmware revs the wireless would occasionally drop, but with the later revs its been pretty good.
I currently use a SprintPCS PCMCIA card (Sierra Wireless AirCard 550) for wireless internet access. This is the card that I have been the happiest with. Our entire wide area network support group uses these and we have been pretty satisfied with them. Over the past couple years we have used Nextel, Ricochet, and AT&T. Here is my summary of our experiances with these providers:
Nextel: The service we had was called "Packet Data Gold" or something to that effect. We used this service for the most part with tethered phones (i1000+, i90c, i700+ with PC link cable). We also had one PCMCIA card (don't remember the model #). We had major problems getting this service working right. They had serious problems delivering pure IP access. It looked like their service was optimized for web surfing through one of their proxies and it was a bitch to get them to let us have IP access. Admittedly we were fairly earlier adopters of this service, so I'm sure it's improved somewhat, although I think they speeds are still 56k. The PCMCIA card we used had a built in battery that needed to be charged up, which was a nice feature for saving batteries on your laptop, but I'd rather buy an extended life laptop battery instead of carrying an extra charger around with me.
Ricochet: GREAT! but limited. In the ricochet service areas it was great, but this isn't really a viable nation wide solution. And that whole going out of business thing kinda put a damper on it:). But I guess they are back now, but they still don't have nation wide coverage.
SprintPCS: You never get 'ISDN' speed, but its faster most cell based wireless I've used. You *may* get near isdn speed down, but the latency makes it feel much slower. It feels kind of like using a slow sat link or something. So, its definately not as good as a decent 802.11b connection, but its better than any of the other services I've used. The coverage has been good for me (most of my travel is limited to CA though, so YMMV). This service is ideal if you are going to areas with sprintpcs coverage and you need a decent method of getting IP access to things. When I use my service I am typically doing one or more of the following activities: VPNing somewhere, SSHing somewhere, surfing the web, running Lotus Notes/Domino Admin, working with 'office-ish' files (word docs, xls's, visio files, etc), running mmc consoles. The service is responsive enough that I'm usually able to have a web browsing session going while I'm telnet-ed/ssh-ed into a couple routers and nothing feels *too* slow. You can definately feel that you're on a wireless link, but its MUCH better than no access at all. It isn't cheap, as you've noted, but I think its worth it. One other thing we have noticed is that when you have three or four users in the same area heavily using the service it really bogs down. I don't know how they backhaul the data from the cell sites, but it appears that this channel can be overloaded by too many users.
If I was on the road more I would probably compliment my SpintPCS connection with a TMOBILE hotspot account so that I could enjoy faster net access from a starfucks/kinkos/etc. Pricey, but worth it if you need access while you travel. One thing you need to check out is that any VPN clients you use are compatable with your wireless network interface. Some of them act as regular NICs pretty well and some of them don't. You should try to get your hands on a card or phone/dongle combo and test out your apps ahead of time so you don't have any suprises. I'm sure there's something I'm leaving out here cuz I've just kinda rambled this off the top of my head, so I'll post a followup if I think of any more gotchas.
We all carry nextel phones or pagers and get text messages from our alerting system when things go down. When I see something go down and I'm somewhere I can vpn in I'll usually do so and check to see if any of my coworkers on actively vpn-ed in and give them a beep to see if they are already working on the problem and see if they need any help. If there isn't anyone looking at it and I'll usually jump on in and get to work and the next person who takes a peek will see me and we'll talk they'll get a feel for what's going on, the extent of the problem, etc. This works pretty well for us (we are small, 10 person group and pretty much know where each other are the evenings/weekends). We also have an answering service that has a formal 'on call' list, so if a customer calls with a problem they'll just call down the list until someone answers. We rotate the list around every quarter, or therabouts, so the 'primary' person changes. I often volunteer for the top spot on the list because I'm pretty flexible and don't have a wife/kids and don't mind being called. This works out well because if I'm not able to fix it we have a list they can call down and everybody pulls their weight so no one really feels bad if they have to hand it off down the list now and then. I'm guessing that since you are looking for a more formal schedule that this sort of 'loose' system may not be the right answer for you, but it may be the right answer for others. We have separate call out lists for some more specialized systems (oracle, router folks, mainframe, telecomm) so that when there is a problem with a specialized system you get the more experianced people first. Our managers are also at the bottom of the list, so if all else fails the call will go to a person who has a complete phone list and a good idea of where people are so they can start call people's alternate numbers and what not. This system also allows for quite a bit of flexiblity people. Our 'tradespeople' (aka union) side of the house where there are MOU's or something relating to off hours support has a more formal policy, but they also have financial incentive (time and a half type stuff) for being on call, so there isn't usually a lack of people willing to be on call. One thing that we have considered, that may work for you, is dumping our answering service for a PBX based application. That way customers could be routed through a menu tree (yeah, people just love those...) that would identify the area of the their problem and then page out the people on call for that area. You can tie something like that in with your calandering/scheduling system so that only people who have time marked as free are paged. You would have to incorperate some sort of checking to ensure that you had at least a primary and alternate for any given time, but it should be doable. I am coming from a shop where people are generally will to be on call when possible, so we don't often run into a situation where someone has to give up something just to be on call, so YMMV with this type of system.
IIRC you can keep fast user switching with the Cisco VPN client. The reason it has to disable fast user switching is that it installs a chains a non-fast user switching GINA.dll thingy. This is used for the 'Make VPN connection before Windows starts' functionality. If you search the Cisco site (maybe look in bug tracker) you can find a work around to allow fast user switching with the VPN client installed. I think you might even be able to enable the spawn before windows capability as well as fast user switching. I don't remember the specifics because I don't use the user switching stuff, but one of our users did, and we gave him the work around and it worked for them.
There are a plethora of 'enhancements' in AS 2.1 ( which I guess is now Red Hat EL-AS ) that Oracle can take advantage of. You may want to give this whitepaper a read for some in depth look at some of the "Performance, Reliability, and Manageability Encnhancements on Red Hat Linux AS 2.1" I'm not a big time Oracle person, but my understanding is that many of these enhancements are only applicable on larger systems (by larger I mean 2+ CPU/>2Gb RAM). Here is a feature chart comparing EL-AS, EL-WS, and EL-ES. As you can see you there are differing levels of support for things like ia64, large amounts of RAM, and >2 CPUs. This definately isn't at 'salesmen screwing with you' type of thing. There are definately some things to consider when deciding between going with AS or not. I would have some concerns about this becuase you are asking slashdot about this when there is a decent amount of data on redhat.com explaining the differences between their different OS releases. If, as you claim, you have in house people with the skillsets to manage you linux systems you might not even need redhat at all, just roll your own that meets your needs. If, on the other hand, you require and OS that is certified by your other software vendors then your purchasing decision will be swayed by that requirement, and most likely swayed towards the AS/EL-?? line of products (or suse or ). Bleah. Enough rambling and spelling mistakes for this post.
You asked about color laser, but if all you're looking for is decent color prints you might want to take a look at Oki Digital LED printers. I'm not a printing expert and I'm really not sure of the advantages and disadvantages of LED vs traditional laser printing, but I do know that our users who have been using an Oki 7000 series for a while really like it.
I'm guessing that you've probably already included this in your planning, but I'll throw it out here anyhow: See if you can negotiate with your local cable television francise holders to use some of their right of way for your fiber. Or when they do an area build out to pay the incremental cost to put a bunch of strands in the ground for you in addition to whatever they are laying. I think that cable companies are required to offer 'Institutional Networks (I-Nets)' to the localities with the franchise rights during negotiations and from what I've gathered they have ended up in some cases of passing a $1/sub/month "Franchise Fee" onto the customer to pay for these I-Nets. I think they are required to offer this under some federal program or another. YMMV on how easy your cable company is to work with. I've been involved with a tad bit of this from the technical perspective so my knowledge on the politics and other issues is a bit lacking. But from what I've seen cable companies have rolled out provider managed as well as franchise holder managed systems around the country. But the negotiations seem to take forever. And the contracts are usually pretty long term (decade+) and the rollouts often stretch over a few years, but in the end if well planned they seem to be a cost effective way of getting bandwidth around a local region. It sounds like what you're doing may be an extesion of this, where you've looked at what you could get from the cable companies seeking franchise rights and realized that for what seems to be a minimal monthly expense you can wire the local residents up too. IIRC Ashland, Oregon has done something along these lines (I'm actually not sure if this was the City of Ashland, or the county Ashland is in, but I'd guess their City Manager could get you pointed in the right direction). My only advice is just make sure you have clearly defined goals and that all the stakeholders are on the same page before you start. If all goes well the residents will be super happy. And happy constituents usually means votes, which means someone high up will love you if you can pull this off under their watch:P
After reading the text of SB1386 (the Bill referenced in this article) I think the Slashdot blurb on this was a bit misleading. California isn't demanding "Public Disclosure Of Break-Ins." This makes it sound like whenever there is a break in it must be disclosed. This isn't really the case. Notifications only have to take place when the following criteria is met: "personal information" means an individual's first name or first initial and last name in combination with any one or more of the following data elements, when either the name or the data elements are not encrypted:
(1) Social security number.
(2) Driver's license number or California Identification Card number.
(3) Account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual's financial account.
(f) For purposes of this section, "personal information" does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records.
As for this "investigation" loophole this only applies to ongoing investigations being conducted by law enforcement agencies. I know that a large company may have a bit more clout in getting an investigation started, but even so they can only delay disclosure if "a law enforcement agency determines that the notification will impede a criminal investigation." So I'm not sure how big of a "loophole" this is.
As for the notification methods, it doesn't look like full public disclosure is what the bill is aiming at. It looks more like they just want the people who's information was compromised to be notified. Here is the section on notification: (g) For purposes of this section, "notice" may be provided by one of the following methods:
(1) Written notice.
(2) Electronic notice, if the notice provided is consistent with the provisions regarding electronic records and signatures set forth in Section 7001 of Title 15 of the United States Code.
(3) Substitute notice, if the agency demonstrates that the cost of providing notice would exceed two hundred fifty thousand dollars ($250,000), or that the affected class of subject persons to be notified exceeds 500,000, or the agency does not have sufficient contact information. Substitute notice shall consist of all of the following:
(A) E-mail notice when the agency has an e-mail address for the subject persons.
(B) Conspicuous posting of the notice on the agency's Web site page, if the agency maintains one.
(C) Notification to major statewide media.
(h) Notwithstanding subdivision (g), an agency that maintains its own notification procedures as part of an information security policy for the treatment of personal information and is otherwise consistent with the timing requirements of this part shall be deemed to be in compliance with the notification requirements of this section if it notifies subject persons in accordance with its policies in the event of a breach of security of the system.
So there doesn't appear to be what I would consider a "full disclosure" requirement anywhere in this. It looks like you've got to notify the people who's info got out, which seems reasonable to me.
I had read about early attempts to use this technology to power trains, but I seem to recall some heat dissapation problems. I believe it was when these locamotives were stationary beneth things like overpasses and tunnels that they had problems with the output from the jets burning/melting things. My guess would be that they solve this using some of the same technologies they use to reduce the heat signature of aircraft.
Check and make sure that the IPs that you "own" are in portable address space. I've known companies that have contractually "owned" IPs, but they were non-portable, so it didn't really do them much good.
As far as I know you can't do this. In order for a server to auth your token it would have to know what the token was seeded with. When you buy tokens they send you a floppy disk with a file on it that needs to be read by the server before it can authenticate your token.
Nextel is the only solution I've found to be reliable in delivery. I'll admit that you do get ocasional delay in delivery, but it always gets there. In my region(northern cal) the delivery times are better than any other service I've used. If you require two way messaging you can use their WAP 2 way messaging interface. We've used several pager and phone messaging providers and nextel is the only one we've been fairly satisfied with.
I've seen x86 hardware running linux being used to control bells, lights, radios, etc at firestations for dispatch alerting. It was done with some custom made hardware controlled from the serial port that had relays that were used to control the devices. It was a headless solution that took all its user input from at keypad and display on a multiline text lcd. I'm pretty sure the relay box and software was custom for this, but you may be able to find a vendor that sells gear like this. So, yes, its possible, but no I don't know of an off the shelf solution.
Slashdot Mirror
If you're in CA I'm guessing that SBC (Pacbell/whatever you know them as) is the local telco that provides the fiber service to your prem. I think you should be able to get diverse pathing from them. It will cost you some $$$, but is sounds like your organization is willing to pay for redundancy. They should be willing to do diverse pathing to your local CO, or diverse pathing to separate COs. You ought to be able to get strands going out of two separate conduits from your building, and completely separate conduits all the way to your local CO, or another nearby CO. You could have a CO SONET node in your closeset CO as well as a CO SONET node in a nearby CO and feed to your upstream provider from there (dunno if your upstream is PBI, which should definately do this, or another provider, who should as well). That way you can set up a healing SONET ring that will survive (in theory) a fiber cut (yes, they do happen. Even in our lovely CA :P ) or a CO outage (as long as your upstream can feed you from both COs). If you have a large enough netblock you should be able to get a connection from a second Internet provider and run BGP with them. Your problem then will be summarization at close by peering point, which is a complexity that you can get around (at a $$$ cost, of course). Just be aware that CO failures, cable cuts, and peering point failures all do happen, but you can always minimize or mostly eliminate if your organization is willing to make a dollar committment to it.
For the record, I am not an expert on this, but I have a bit of experience under my belt.
Bringing a qualified electrician along when looking for new office space. Or at least having an electrician give it a looking over before you sign a lease. They should be able to look at the power coming into the building as well as the current distribution system within the building and give you some idea as to whether or not it could meet your needs.
Total available amperage to your offices doesn't always do you a whole lot of good if you can't get the circuits you need to your server rooms. Be sure to discuss with the landlord any plans you may have to add or move existing circuits around.
Has anyone tried the Kyocera ceramic ball pens? I've always wanted to know how well they write.
That link isn't exactly what they want. I'm pretty sure they need a PA-MC-T3 card. I had thought that the PA-MC-T3 might not be supported in the FlexWan blades, but I checked and I was wrong, so you could go with a FlexWan with a PA-MC-T3.
Also, on the paying list issue, I agree. You shouldn't have to pay MSRP on your Cisco gear. If you can't get a break, ask your telco. They might be a large Cisco reseller and could get you a good price (esp if you're starting order bigger pipes from them). They are going to be seeing the monthly recurring $$$ from this DS3, so they might be very willing to give you a good discount on the routing gear.
This kinda goes back to what I was saying here and here. Again, we need more information from the requestor. Driving 12Mbps out of a HSSI might not meet their needs if they are going channelized to pull a bunch of DS1s into a DS3. I can't really think a way off the top of my head to do that with a 3600+HSSI without your telco/upstream doing some fancy stuff. One way the telco could do it is term the DS3 on one of their boxes and hand the traffic back off to the customer across a point-to-point DS3 terminating on a customer 3600+HSSI router. That would take a lot of the control out of the hands of the customer and would cost the telco a bit of money. I'd imagine the cost would offset the savings of buying a 3600 with a HSSI instead of a 7x00 with PA-MC-T3.
I've agree with you that if you can't justify a one time $30k cost that you've got to think really hard about what you're doing. Maybe the original poster works in public sector where you can often get dirt cheap telco rates so the one time equipment costs look really really high compared to monthly recurring.
The more I think about this Ask Slashdot the more I want to know the driving factors behind it. Perhaps a channelized DS3 isn't the right solution for them. I really wish they'd given us some insight into their design goals with this project...
Maybe, maybe not...
I took a quick peek at those cards and they both looked like clear channel DS3. I'm kinda going along on fuzzy memory here, but I think that if its channelized you need a M13 framer on the board to break out the T1s. I don't think you'll be able to do that in software. Something like this card may do the trick, but its only appears to have WinNT and VxWare support. The problem with the clear channel cards is you have to break the DS3 down into DS1 channels and provide framing on those channels which is quite I think is generally done in hardware.
I'd say that if you're pulling in a channelized DS its prolly not coming from your ISP. You generally see people pull those in if they have a bunch of remote sites that need DS1 connectivity. You'll run the DS3 to a CO MUX and break the DS1s out of there. As far as getting a cheap cisco router to handle a channelized DS3, you might be out of luck. I'm pretty sure there's not a card for the 2600/3600 series to do that. I think that the smallest card may be a PA-MC-T3 which means you're looking at a 7200/7300 style box. Getting those up to $30k is pretty easy, depending on the options you need.
I'd personally shy away from running a linux box with a channelized DS3 board. If you have problems with your line just about anyone you work with will be able to help you troubleshoot a Cisco with a channelized DS3 board.
If you do end up going with a Linux box make sure that you can do things like run BERT on the DS1 channels. Otherwise troubleshooting will be a bitch.
Some paging providers still offer TAP interfaces, you may just have to switch paging providers. I think we are currently using a TAP interface to send pages to a 'page group' that has all of the NOCish ppl in it so we only have to make one outgoing call to page everyone with UP/DOWNS. IIRC we worked for a while with a Nextel rep and were able to get TAP access for text messaging to Nextel phones, so if you're a Nextel shop you may want to look into that. I don't know if you can get page groups with the Nextel TAP interface, I seem to remember the paging interface having to make many calls to Nextel to get the page out to everyone.
If you are talking about a 'large-ish' local network then splitting 10/8 into smaller blocks looks pretty good on paper. You can split it into /16s and delegate those to departmental level net admins who will then divide them into /24s for individual VLANS. It helps if you do a big plan upfront. This way if let say you know that HR, accounting, and marketing are restricted to one site you can assign them a glob of /16s that you can summarize on the routers to keep the routing tables nice and small. You can also assign ranges to classes of machines. For example if you knew that all your 'all company' web servers lived in the 10.10.10/24 range and the Citrix farm that fronts for your HR system lived in the 10.10.11/24 range and you had a subnet with users that just needed access to the HR system and the 'all company' web servers you could write a quick acl to permit http and https to 10.10.10/24 and ica to 10.10.11/24. This is a lot easier that consulting your IP database and looking up the IPs of all the web servers and all the HR Citrix boxen and crafting a nasty long ACL. :P
Now, if you're just talking about your home LAN it prolly doesn't matter what you use. If you're planning on VPNing into your work network life will be easier if you pick a range that doesn't overlap with any of the RFC1918 addys they use.
As for the people who are suggesting that if you have a large network you need to pick ranges that don't overlap with networks you plan to interface with, I wouldn't worry too much. Most companies that interface with with other networks on regular basis have ranges of 'legit' IPs that they use for extranet connections. Or they're used to playing the firewall NAT game. Doing the "network to firewall/NAT to outside agency firewall/NAT to outside agency network" thing usually isn't that bad. People get good at it after while. Once you've done a few it'll be just another annoyance.
When you talk about 'reliability' it sounds like you are talking about longevity. In addition to hw failures you also have to worry about the AP's ability to be upgraded to keep up with new authentication/authorization methods and other such software/firmware improvements. That is the biggest difference between the low end and the high end APs. We use Cisco APs and bridges for this very reason. We were steered this direction because we are a Cisco shop, so I'm not by any means trying to steer people towards Cisco APs. That being said, we have been happy with them, but I also know of people who have AP installs using other 'high-end' APs with similar success.
At my home I have a Linksys box (one of the gateway/wireless/4 port hub boxes) and it has been working alright for a couple years now. With earlier firmware revs the wireless would occasionally drop, but with the later revs its been pretty good.
I currently use a SprintPCS PCMCIA card (Sierra Wireless AirCard 550) for wireless internet access. This is the card that I have been the happiest with. Our entire wide area network support group uses these and we have been pretty satisfied with them. Over the past couple years we have used Nextel, Ricochet, and AT&T. Here is my summary of our experiances with these providers:
:). But I guess they are back now, but they still don't have nation wide coverage.
Nextel:
The service we had was called "Packet Data Gold" or something to that effect. We used this service for the most part with tethered phones (i1000+, i90c, i700+ with PC link cable). We also had one PCMCIA card (don't remember the model #). We had major problems getting this service working right. They had serious problems delivering pure IP access. It looked like their service was optimized for web surfing through one of their proxies and it was a bitch to get them to let us have IP access. Admittedly we were fairly earlier adopters of this service, so I'm sure it's improved somewhat, although I think they speeds are still 56k. The PCMCIA card we used had a built in battery that needed to be charged up, which was a nice feature for saving batteries on your laptop, but I'd rather buy an extended life laptop battery instead of carrying an extra charger around with me.
Ricochet:
GREAT! but limited. In the ricochet service areas it was great, but this isn't really a viable nation wide solution. And that whole going out of business thing kinda put a damper on it
SprintPCS:
You never get 'ISDN' speed, but its faster most cell based wireless I've used. You *may* get near isdn speed down, but the latency makes it feel much slower. It feels kind of like using a slow sat link or something. So, its definately not as good as a decent 802.11b connection, but its better than any of the other services I've used. The coverage has been good for me (most of my travel is limited to CA though, so YMMV). This service is ideal if you are going to areas with sprintpcs coverage and you need a decent method of getting IP access to things. When I use my service I am typically doing one or more of the following activities: VPNing somewhere, SSHing somewhere, surfing the web, running Lotus Notes/Domino Admin, working with 'office-ish' files (word docs, xls's, visio files, etc), running mmc consoles. The service is responsive enough that I'm usually able to have a web browsing session going while I'm telnet-ed/ssh-ed into a couple routers and nothing feels *too* slow. You can definately feel that you're on a wireless link, but its MUCH better than no access at all. It isn't cheap, as you've noted, but I think its worth it. One other thing we have noticed is that when you have three or four users in the same area heavily using the service it really bogs down. I don't know how they backhaul the data from the cell sites, but it appears that this channel can be overloaded by too many users.
If I was on the road more I would probably compliment my SpintPCS connection with a TMOBILE hotspot account so that I could enjoy faster net access from a starfucks/kinkos/etc. Pricey, but worth it if you need access while you travel. One thing you need to check out is that any VPN clients you use are compatable with your wireless network interface. Some of them act as regular NICs pretty well and some of them don't. You should try to get your hands on a card or phone/dongle combo and test out your apps ahead of time so you don't have any suprises. I'm sure there's something I'm leaving out here cuz I've just kinda rambled this off the top of my head, so I'll post a followup if I think of any more gotchas.
We all carry nextel phones or pagers and get text messages from our alerting system when things go down. When I see something go down and I'm somewhere I can vpn in I'll usually do so and check to see if any of my coworkers on actively vpn-ed in and give them a beep to see if they are already working on the problem and see if they need any help. If there isn't anyone looking at it and I'll usually jump on in and get to work and the next person who takes a peek will see me and we'll talk they'll get a feel for what's going on, the extent of the problem, etc. This works pretty well for us (we are small, 10 person group and pretty much know where each other are the evenings/weekends). We also have an answering service that has a formal 'on call' list, so if a customer calls with a problem they'll just call down the list until someone answers. We rotate the list around every quarter, or therabouts, so the 'primary' person changes. I often volunteer for the top spot on the list because I'm pretty flexible and don't have a wife/kids and don't mind being called. This works out well because if I'm not able to fix it we have a list they can call down and everybody pulls their weight so no one really feels bad if they have to hand it off down the list now and then. I'm guessing that since you are looking for a more formal schedule that this sort of 'loose' system may not be the right answer for you, but it may be the right answer for others. We have separate call out lists for some more specialized systems (oracle, router folks, mainframe, telecomm) so that when there is a problem with a specialized system you get the more experianced people first. Our managers are also at the bottom of the list, so if all else fails the call will go to a person who has a complete phone list and a good idea of where people are so they can start call people's alternate numbers and what not. This system also allows for quite a bit of flexiblity people. Our 'tradespeople' (aka union) side of the house where there are MOU's or something relating to off hours support has a more formal policy, but they also have financial incentive (time and a half type stuff) for being on call, so there isn't usually a lack of people willing to be on call. One thing that we have considered, that may work for you, is dumping our answering service for a PBX based application. That way customers could be routed through a menu tree (yeah, people just love those...) that would identify the area of the their problem and then page out the people on call for that area. You can tie something like that in with your calandering/scheduling system so that only people who have time marked as free are paged. You would have to incorperate some sort of checking to ensure that you had at least a primary and alternate for any given time, but it should be doable. I am coming from a shop where people are generally will to be on call when possible, so we don't often run into a situation where someone has to give up something just to be on call, so YMMV with this type of system.
IIRC you can keep fast user switching with the Cisco VPN client. The reason it has to disable fast user switching is that it installs a chains a non-fast user switching GINA.dll thingy. This is used for the 'Make VPN connection before Windows starts' functionality. If you search the Cisco site (maybe look in bug tracker) you can find a work around to allow fast user switching with the VPN client installed. I think you might even be able to enable the spawn before windows capability as well as fast user switching. I don't remember the specifics because I don't use the user switching stuff, but one of our users did, and we gave him the work around and it worked for them.
There are a plethora of 'enhancements' in AS 2.1 ( which I guess is now Red Hat EL-AS ) that Oracle can take advantage of. You may want to give this whitepaper a read for some in depth look at some of the "Performance, Reliability, and Manageability Encnhancements on Red Hat Linux AS 2.1" I'm not a big time Oracle person, but my understanding is that many of these enhancements are only applicable on larger systems (by larger I mean 2+ CPU/>2Gb RAM).
Here is a feature chart comparing EL-AS, EL-WS, and EL-ES. As you can see you there are differing levels of support for things like ia64, large amounts of RAM, and >2 CPUs. This definately isn't at 'salesmen screwing with you' type of thing. There are definately some things to consider when deciding between going with AS or not. I would have some concerns about this becuase you are asking slashdot about this when there is a decent amount of data on redhat.com explaining the differences between their different OS releases. If, as you claim, you have in house people with the skillsets to manage you linux systems you might not even need redhat at all, just roll your own that meets your needs. If, on the other hand, you require and OS that is certified by your other software vendors then your purchasing decision will be swayed by that requirement, and most likely swayed towards the AS/EL-?? line of products (or suse or ).
Bleah.
Enough rambling and spelling mistakes for this post.
I think that Dasher could be used as an alternative to handwriting recognition on these.
You asked about color laser, but if all you're looking for is decent color prints you might want to take a look at Oki Digital LED printers. I'm not a printing expert and I'm really not sure of the advantages and disadvantages of LED vs traditional laser printing, but I do know that our users who have been using an Oki 7000 series for a while really like it.
...just as soon as we convert to the metric system.
I'm guessing that you've probably already included this in your planning, but I'll throw it out here anyhow: See if you can negotiate with your local cable television francise holders to use some of their right of way for your fiber. Or when they do an area build out to pay the incremental cost to put a bunch of strands in the ground for you in addition to whatever they are laying. I think that cable companies are required to offer 'Institutional Networks (I-Nets)' to the localities with the franchise rights during negotiations and from what I've gathered they have ended up in some cases of passing a $1/sub/month "Franchise Fee" onto the customer to pay for these I-Nets. I think they are required to offer this under some federal program or another. YMMV on how easy your cable company is to work with. I've been involved with a tad bit of this from the technical perspective so my knowledge on the politics and other issues is a bit lacking. But from what I've seen cable companies have rolled out provider managed as well as franchise holder managed systems around the country. But the negotiations seem to take forever. And the contracts are usually pretty long term (decade+) and the rollouts often stretch over a few years, but in the end if well planned they seem to be a cost effective way of getting bandwidth around a local region. It sounds like what you're doing may be an extesion of this, where you've looked at what you could get from the cable companies seeking franchise rights and realized that for what seems to be a minimal monthly expense you can wire the local residents up too. IIRC Ashland, Oregon has done something along these lines (I'm actually not sure if this was the City of Ashland, or the county Ashland is in, but I'd guess their City Manager could get you pointed in the right direction). :P
My only advice is just make sure you have clearly defined goals and that all the stakeholders are on the same page before you start. If all goes well the residents will be super happy. And happy constituents usually means votes, which means someone high up will love you if you can pull this off under their watch
Don't buy conflict diamond CPUs!
After reading the text of SB1386 (the Bill referenced in this article) I think the Slashdot blurb on this was a bit misleading. California isn't demanding "Public Disclosure Of Break-Ins." This makes it sound like whenever there is a break in it must be disclosed. This isn't really the case. Notifications only have to take place when the following criteria is met: "personal information" means an
individual's first name or first initial and last name in combination
with any one or more of the following data elements, when either the
name or the data elements are not encrypted:
(1) Social security number.
(2) Driver's license number or California Identification Card
number.
(3) Account number, credit or debit card number, in combination
with any required security code, access code, or password that would
permit access to an individual's financial account.
(f) For purposes of this section, "personal information" does not
include publicly available information that is lawfully made
available to the general public from federal, state, or local
government records.
As for this "investigation" loophole this only applies to ongoing investigations being conducted by law enforcement agencies. I know that a large company may have a bit more clout in getting an investigation started, but even so they can only delay disclosure if "a
law enforcement agency determines that the notification will impede a
criminal investigation." So I'm not sure how big of a "loophole" this is.
As for the notification methods, it doesn't look like full public disclosure is what the bill is aiming at. It looks more like they just want the people who's information was compromised to be notified. Here is the section on notification:
(g) For purposes of this section, "notice" may be provided by one
of the following methods:
(1) Written notice.
(2) Electronic notice, if the notice provided is consistent with
the provisions regarding electronic records and signatures set forth
in Section 7001 of Title 15 of the United States Code.
(3) Substitute notice, if the agency demonstrates that the cost of
providing notice would exceed two hundred fifty thousand dollars
($250,000), or that the affected class of subject persons to be
notified exceeds 500,000, or the agency does not have sufficient
contact information. Substitute notice shall consist of all of the
following:
(A) E-mail notice when the agency has an e-mail address for the
subject persons.
(B) Conspicuous posting of the notice on the agency's Web site
page, if the agency maintains one.
(C) Notification to major statewide media.
(h) Notwithstanding subdivision (g), an agency that maintains its
own notification procedures as part of an information security policy
for the treatment of personal information and is otherwise
consistent with the timing requirements of this part shall be deemed
to be in compliance with the notification requirements of this
section if it notifies subject persons in accordance with its
policies in the event of a breach of security of the system.
So there doesn't appear to be what I would consider a "full disclosure" requirement anywhere in this. It looks like you've got to notify the people who's info got out, which seems reasonable to me.
I had read about early attempts to use this technology to power trains, but I seem to recall some heat dissapation problems. I believe it was when these locamotives were stationary beneth things like overpasses and tunnels that they had problems with the output from the jets burning/melting things. My guess would be that they solve this using some of the same technologies they use to reduce the heat signature of aircraft.
Check and make sure that the IPs that you "own" are in portable address space. I've known companies that have contractually "owned" IPs, but they were non-portable, so it didn't really do them much good.
As far as I know you can't do this. In order for a server to auth your token it would have to know what the token was seeded with. When you buy tokens they send you a floppy disk with a file on it that needs to be read by the server before it can authenticate your token.
Nextel is the only solution I've found to be reliable in delivery. I'll admit that you do get ocasional delay in delivery, but it always gets there. In my region(northern cal) the delivery times are better than any other service I've used. If you require two way messaging you can use their WAP 2 way messaging interface. We've used several pager and phone messaging providers and nextel is the only one we've been fairly satisfied with.
I've seen x86 hardware running linux being used to control bells, lights, radios, etc at firestations for dispatch alerting. It was done with some custom made hardware controlled from the serial port that had relays that were used to control the devices. It was a headless solution that took all its user input from at keypad and display on a multiline text lcd. I'm pretty sure the relay box and software was custom for this, but you may be able to find a vendor that sells gear like this. So, yes, its possible, but no I don't know of an off the shelf solution.