We've got plenty of pressure with deadlines looming, new projects, and other 'people issues'. But the pressure I'm writing about today is torque.
For serial adapters that screw on (DB25, DE9, etc.), you shouldn't need to tighten them more than finger-tight. The screws are meant to keep the connector from being pulled out if the cable is tugged. Most of the small threaded nuts and screw-end on the adapters are not made for serious torque, and will likely break, or strip, if you apply too much pressure.
Finger-tight for you may be tighter than finger-tight for someone else that might need to work on the gear later. I don't want to make someone have to go get tools to remove serial adapters.
This goes for the screws for mounting your gear in cabinets or relay racks. You can tighten these hand-tight, but don't set your screw-gun to be an impact wrench! The lowest settings will probably be fine. (If it's not, you should make sure that you haven't cross-threaded the screw to begin with, rather than cutting new threads in the rails...because aluminum rails will strip easily, and steel rails will chew your screws easily. Let's try to not damage any parts today.)
The other damage that occurs from too much pressure is damaging the screwdriver bits and the screw-tops. It starts when the screw stops, and the drill keeps going, and the screwdriver bit starts to round over the screw head, but it's starting to damage the screwdriver bit as well! This makes it easier for the screwdriver bit to round over the next screwheads. (Take a good look at the philips bit in your screwgun today. If you don't have good, straight edges, it's time to turn down the torque, and either get out the file to renew your bit, or use a new replacement bit.)
The pressure you will save, will be the pressure on you in your next emergency. You'll be able to quickly remove an adapter without needing to go get tools. Your tools will easily remove and install screws, and your screws and rack rails won't be damaged by 'the last guy that worked on them'.
Once you set the torque on your screwgun to only 1 or 2, keep checking it, since there are probably other folks that borrow it. They'll likely change the setting, and not put it back. When you find it has been changed, you may be able to share this note with the culprit, and make things just a bit nicer in your shop.
20070422
Use the correct serial adapters, and trust them.
Today was a service window, and I was working in an old part of the network. I stumbled onto a broken DE9-toRJ45 adapter, dangling by it's wires. I swapped it out for a new one, from the proper vendor for the terminal servers in use, but there was no response via conserver.
"It was working fine last week." I'm told.
Looking further, I found a poor RJ45 termination, but the signals on on my signal tracer looked odd as well. This led me to the other end of the cable, where I found that I was looking at a USOC-Rolled cable (old CDDI-type wiring). This would have been a 'null-modem' if they had been using Cisco console servers, but they were not. Instead, they had only a couple leads correctly connected, and signal ground was not one of them. After a bit of frustration reaching more consoles, and reterminating those cables to be straight-through again, the network was back under our control. But why had they failed?
"But they've always worked like that." I'm told.
The wiring of the Cisco adapters, the null-modem (USOC-Rolled) cables, and the non-Cisco console servers wiring scheme had meant that signal reference was really be derived from the equipment chassis, across the power systems ground, between the console servers and the controlled devices. Today was they day that newer, fatter power circuits were installed, and moving the gear to different Power Distribution Units were too much.
The signal reference ground pin is extremely important, to prevent data errors, possible equipment damage, and possible injury to staffl handling the connections! (I'll share my 'bad ground, smoking gun' story another day, when I have more time.)
Using the correct adapters, and correct wiring, will lead to predictable results. Mixing and matching parts you have laying around with specialty cables will eventually cause you more headaches, and possibly more money than you will save. And the chances are good that you'll need to 'do it the right way' sooner or later. If your shop is as busy as the places I've been, you may as well do it right in the first place, because you may not have time to do it right later without sacrificing weekends or vacation time.
"It was working fine last week." I'm told.
Looking further, I found a poor RJ45 termination, but the signals on on my signal tracer looked odd as well. This led me to the other end of the cable, where I found that I was looking at a USOC-Rolled cable (old CDDI-type wiring). This would have been a 'null-modem' if they had been using Cisco console servers, but they were not. Instead, they had only a couple leads correctly connected, and signal ground was not one of them. After a bit of frustration reaching more consoles, and reterminating those cables to be straight-through again, the network was back under our control. But why had they failed?
"But they've always worked like that." I'm told.
The wiring of the Cisco adapters, the null-modem (USOC-Rolled) cables, and the non-Cisco console servers wiring scheme had meant that signal reference was really be derived from the equipment chassis, across the power systems ground, between the console servers and the controlled devices. Today was they day that newer, fatter power circuits were installed, and moving the gear to different Power Distribution Units were too much.
The signal reference ground pin is extremely important, to prevent data errors, possible equipment damage, and possible injury to staffl handling the connections! (I'll share my 'bad ground, smoking gun' story another day, when I have more time.)
Using the correct adapters, and correct wiring, will lead to predictable results. Mixing and matching parts you have laying around with specialty cables will eventually cause you more headaches, and possibly more money than you will save. And the chances are good that you'll need to 'do it the right way' sooner or later. If your shop is as busy as the places I've been, you may as well do it right in the first place, because you may not have time to do it right later without sacrificing weekends or vacation time.
20070413
Kudos to the Cyclades folks
Their product was developed across three continents, and sometimes you could find grammatical errors in their on-line tech notes (perhaps because the authors first language was not English?), but I have not found any techical errors in the command-line instructions of the older files.
To be honest, I occassionally took some liberties, trying to optimize the steps that they had outlined. But, if things didn't work the way I expected, I have always had success when I did it exactly the way they typed it.
As someone who owns and operates on a bunch of older Cyclades gear, I'm very thankful that Avocent has retained the old Cyclades files at http://global.cyclades.com. Access to the old information has proven to be invaluable for upgrading older units to newer code.
And, as a fan of documentation (see my Console Connection Guides...), I tip my hats to those who made sure that the original instructions were spot-on correct, every time! Thanks, folks! I hope the Avocent team will follow well in your footsteps.
-Z-
To be honest, I occassionally took some liberties, trying to optimize the steps that they had outlined. But, if things didn't work the way I expected, I have always had success when I did it exactly the way they typed it.
As someone who owns and operates on a bunch of older Cyclades gear, I'm very thankful that Avocent has retained the old Cyclades files at http://global.cyclades.com. Access to the old information has proven to be invaluable for upgrading older units to newer code.
And, as a fan of documentation (see my Console Connection Guides...), I tip my hats to those who made sure that the original instructions were spot-on correct, every time! Thanks, folks! I hope the Avocent team will follow well in your footsteps.
-Z-
20070408
Going back to the beginning
"I am waiting for you, Vizzni! You told me to go back to the beginning, so I have. When a job went wrong, you went back to the beginning!" - Inigo Montoya, Princess Bride -
Today's topic is a lesson in Change Control, sort of. More like Pre-Change Control.
Most manufacturers post their upgrade instructions. Some of these instructions are fine. Some are even exceptional. But few manufacturers offer instructions for how to downgrade their code. Yet, if an upgrade goes wrong, you will probably want a fall-back plan, to get you back where you were, at least until you can get the vendor to help past the problem(s).
Most console server devices store their OS and boot files in FLASH. But many of them cannot store more than one version of the OS in the on-board FLASH at a time. So, the upgrade process will overwrite the old version. If you plan to revert to the original version, you need to gather a few things before you start;
If your device has MD5 implemented, so that you can check the new version for integrity, you should also use MD5 to display the checksum for the current version before you start. (If you need to load the old version back again, you should know what the checksum will be.)
You keep all of the software CDs that came with your devices when they are new, right? (At least ONE copy for each platform, and for each different software version as you collect them.) You should also mark them (the CDs, Manuals, etc.) for the software version they contain. The cost of a bookcase is cheaper then an evening of your wasted time because you cannot easily find the information you need.
"But my vendor keeps all of this stuff on-line. Why bother to keep the old stuff?" you ask. Let me offer a few cases that happen more often than you might expect;
Keep the versions in separate directories, since sometimes the image names are identical, and you don't want to overwrite the old files when you add the newer files. Then, you will be ready to upgrade when the time comes, and you'll also be ready to downgrade again, if needed.
-Z-
Today's topic is a lesson in Change Control, sort of. More like Pre-Change Control.
Most manufacturers post their upgrade instructions. Some of these instructions are fine. Some are even exceptional. But few manufacturers offer instructions for how to downgrade their code. Yet, if an upgrade goes wrong, you will probably want a fall-back plan, to get you back where you were, at least until you can get the vendor to help past the problem(s).
Most console server devices store their OS and boot files in FLASH. But many of them cannot store more than one version of the OS in the on-board FLASH at a time. So, the upgrade process will overwrite the old version. If you plan to revert to the original version, you need to gather a few things before you start;
- A copy of the current code version
(You may be able to TFTP the file to a server from the device!) - At least a byte-count for the installed currently installed version
- Better is to have the MD5 checksum hash for the currently installed version
If your device has MD5 implemented, so that you can check the new version for integrity, you should also use MD5 to display the checksum for the current version before you start. (If you need to load the old version back again, you should know what the checksum will be.)
You keep all of the software CDs that came with your devices when they are new, right? (At least ONE copy for each platform, and for each different software version as you collect them.) You should also mark them (the CDs, Manuals, etc.) for the software version they contain. The cost of a bookcase is cheaper then an evening of your wasted time because you cannot easily find the information you need.
"But my vendor keeps all of this stuff on-line. Why bother to keep the old stuff?" you ask. Let me offer a few cases that happen more often than you might expect;
- The vendor goes out of business, and the website goes away.
- The vendor sells the product line, and the new vendor kills it off.
- The vendor gets acquired, and the old website goes away.
- The vendor decides old software is "support", and is worth money.
- Newer versions of software are too big to fit into the FLASH in your device.
- The upgrade instructions had a mistake.
- The new code doesn't like your old hardware.
- The vendor decides to remove old versions from the web, to encourage the adoption of newer versions.
Keep the versions in separate directories, since sometimes the image names are identical, and you don't want to overwrite the old files when you add the newer files. Then, you will be ready to upgrade when the time comes, and you'll also be ready to downgrade again, if needed.
-Z-
Subscribe to:
Posts (Atom)