While taking apart the three-tube gun assembly - where each gun is a small 7" high-power single-color TV tube - to separate the lens assemblies from the CRT, the last "lens" was actually the glass cover for a reservoir containing a clear viscous fluid. Said fluid promptly exited the chamber, and I'm not sure I could have been any more surprised. I was not expecting my TV to drool all over my carpet.
It turns out that this is optical grade ethylene glycol (anti-freeze), and it's used as a coolant for the CRT. These things put out tremendous amounts of heat, and this apparently draws it away from the face of the tube. It also seems to be serving as part of the first lens to focus the beam before the real lenses get it.
There was not one iota of clue that this was a surprise waiting to happen: not in the user's manual, not a label on the tubes, not a mention in the "Be careful around the tubes" stickers right next to the tubes. I don't think I could have been more surprised.
Prestone™ for my TV: who knew?
]]>I'm way, way late for this election cycle, but have finally finished my customary analysis of the ballot measures in the upcoming California general election. I have been writing about these for years, posting them to the web since 2000, and normally I have them done far in advance.
But a crushing workload (I have no life) has kept me from spending the many hours required to complete this until today. Four days before the election is not really very helpful, but it's better late than never.
My analysis is nonpartisan, and mainly viewed from a libertarian perspective. I try to find what the measure is really about, and this cycle was surprised to find that most of the measures didn't have many hidden agendas (even if the titles were a little misleading).
This was very slow slogging, but I really do read nearly everything I can find on the measures. I save every political mailer I receive, and it's taken weeks of off-and-on work to finish this.
But it's done, and I believe it offers a fair view of the issues. Mainly I care that you make an educated vote: if my commentary gets you to vote the other way for reasons that matter to you, my job is done.
]]>I've been engaged in building a custom LDAP directory with OpenLDAP on a Linux system, and it's been pretty slow slogging. The net is full of resources for how to use LDAP for authentication, or to hook a mailserver into an existing directory, but very little for building entirely new systems from scratch. "Schema design" is going to be mostly self taught.
Though I could do what I want with MySQL, I really believe that a hierarchical, nonrelational system is a better fit to my application, (particularly because of better distributed, partitionable replication) but I still have a long learning curve ahead of me.
I had one particular error when defining a schema, and Google did not help me, so I'll plant the resolution here for the next one down this road.
After creating a schema to define the object of interest, trying to start the server produced an error message:
user-defined ObjectClass has inappropriate SUPerior
I'm defining a network device to be monitored, and that includes a whole raft of attributes. Hostname, IP address, description, parameters to various types of monitoring, and so on. This also includes SNMP credentials to make these queries.
objectclass ( myObjectClass:1
NAME 'mySnmpCredentials'
DESC 'All the stuff needed to access SNMP'
AUXILIARY
MAY ( mySnmpVersion
$ mySnmpCommunity
$ mySnmpUseTCP
$ mySnmpAuthKey
$ mySnmpEncrKey ) )
objectclass ( myObjectClass:2
NAME 'myDevice'
DESC 'A monitored device'
SUP ( top $ mySnmpCredentials ) STRUCTURAL
MUST ( cn $ myHostname )
MAY ( myEnabled
$ myDescription
$ myComments
$ myDnsIPAddress
$ myDnsAliases
$ myDnsTxtRecord
$ myBGPRouteCountType
$ myBGPRouteCountEnabled ) )
Though a myDevice object works fine when all the attributes are provided in a long list, attempting to abstract out the SNMP credentials (which are likely to be used elsewhere in this same form) produced the above error.
It turns out that using AUXILIARY for the mixin object is responsible for this: changing it to ABSTRACT fixed it right up.
It's not entirely clear to me what the difference is between STRUCTURAL and AUXILIARY object types, and it appears that some servers don't enforce a distinction.
]]>Scenarios: customer's office working late (by myself), a stack of 5 Dell PowerEdge servers that were quite old but still entirely functional. All were purchased in 2000, were no longer under warranty (Dell apparently won't sell extended warranty coverage for servers past 5 years). One machine simply needed an upgrade from Red Hat 9 to something newer, so I was to wipe and reload. Did a quick network backup of the data, rebooted the machine and pushed the eject button on the CD-ROM to load the first disc.
Or not. Heard a small buzzing sound for about the right amount of time, but no ejectage was seen. Hmmm. Used the paperclip eject method, and one end of a rubber drive belt popped out. Guess that belt reached end of life - it happens, I'll just swap one of the other units in.
Or not. All five units had the same failure - not a working CD-ROM in the stack. Well that's sure a nasty turn, but no matter: I had just bought a new USB CD-ROM drive and had it in my car.
Or not. This "new" unit purchased from Fry's was in fact a customer return, and it had a sticker on the side noting the condition of the product: "Missing USB cable". How about that! I'll just scrounge around the office for a USB cable and get cracking.
Or not. Scoured the IT supply cabinet and all over the office - not a spare USB cable in the place. Not a lot of choices at the office supply store, but found one suitable. Returned ready to reload.
Or not. These old PowerEdge units simply do not support USB booting - Dell added that a generation or two later. Well ok, so we'll just replace the drives: cheap CD-ROM drives suitable for OS loading couldn't be more than $40-$50, right? And they can be picked up at the office supply place.
Or not. These are SCSI units, not IDE, and are more expensive and harder to find. At this point I decided that God won this round, so I headed home.
I had a few old SCSI CD-ROM drives on my shelf, and was able to return another day to complete the job, but the string of hurdles (especially all five NEC CD-ROM units failing the same way) was something I'd certainly not have been able to plan for.
]]>Help us put an end to junk faxes once and for all. It's time to get paid back for the paper and wasted supplies that junk faxes have cost you. Did you know that you oculd get $25 to $100 for each junk fax advertisement sent to your fax machine?
This is a public announcement from StopFaxNow.com, a group dedicated to informing people about the recent changes taking place in the law. Our goal is to help people like you put a STOP to the companies behind unsolicited faxes.
If you were sent COMMERCIAL FAX ADVERTISING, like a product of some kind, a hot stock or travel offering, or some locak service, without your prior consent, the advertiser's behind those faxes may be liable and you could be receiving a settlement for each fax.
As of August 1, 2006, we have completed our new national database of collection organizations that will legally persue junk fax offenders and send you a portion of the money they receive. All you do is mail them your unwanted junk faxes, up to four years old, and they do the rest. These companies are starting to make a real difference and their hard work is paying off.
We offer this list free of charge so take advantage of it. Now join the crusade to stop junk faxes and help make it un profitable for them to continue business!
Log on to our website at www.stopfaxnow.com and register today. Our site also contains free resources, articles, tools and tips that will help you stop fax spammers. And while you are there, be sure to sign up for our quarterly newslatter designed to keep you informed of all the latest news and events as they happen.
WWW.STOPFAXNOW.COM
OK, so what's this about? Google shows nothing, and the website itself is kinda thin on details, but my overall impression is that this borders on a scam, but is not quite one (though this is subject to change).
The law in some areas provide for damages if one gets unsoliciated faxes - and I get at least a dozen a week: grrr - and this looks to me like a front for collection agencies or attorneys who plan to make a business out of going after the senders.
By getting people to send in their fax spam, they crank up the damages, then share a portion of the fine/penalty with those who were part of the "class" (term not used in the legal sense).
Superficially this has some minor appeal - sue the spammers! - but the fact that the fax itself had no header or removal information seems to put it in the same category as the objectional material.
The website itself contains very thin information, and their "resources" are really just a few links to the common places (the FTC, the FCC). It looks contrived to me, not a real "resource center".
We do see some hint about what they have in mind:
In the month of October, we will focus on retiring your old fax machine and show you how to receive all your fax documents over the internet, or by using a fax modem right inside your computer. This will give you the ability to print only the documents you want, delete the ones you don't and minimize the use of your supplies, saving you money!
Hmmm, so they'll offer some kind of e-fax service perhaps? I think we have those already, and the other proprietors don't resort to spamming to push their business.
Looking into stopfaxnow.com domain, we find it registered in Hong Kong:
Registrant:
Ling Corporation
35 Central Plaza
18 Harbour Road
Hong Kong, Hong Kong 142587
The webservers are located there too, and this all just looks really suspicious considering they're shooting for targets in the United States.
Until I get more information, I'm giving this a thumbs down. Anybody else know anything about these guys?
]]>Those days are long gone.
Every time I have to spec memory for a server, I start to wallow in all the various attributes: DDR, ECC, Registered, PC1600, Dual-Ranked, etc. and even when looking at a full list of required specs, there's always the fear that I'm somehow missing a parameter that matters.
For instance: I once bought a stack of RAM upgrades for some Dell Optiplex workstations, but found that only DIMMs with chips on both sides were supported, not DIMMs with chips on only one side. Huh? I assume this has something to do with rank or bank, but they flat-out did not work. This was not listed anywhere in the specs for the RAM, and it contributes to this "I don't know how to order RAM" mentality.
While researching this today, I ran across an outstanding Flash presentation from Corsair that covers almost all of this. It's quite technical but doesn't require a BSEE to follow, and it's by far the most informative reference I've ever seen.
I learned, for one thing, what "Registered" memory is, and it made perfect sense. In unregistered RAM, the address lines from the memory controller go to each individual chip on each DIMM, and this can be 4, 8, or even 32 chips on a single stick. As more DIMMs are added, this presents a growing electrical load on the output of the memory controllers: how can the memory controller drive all those inputs?
By adding a register - kind of like a buffer - at the edge of the DIMM, the memory controller sees one load per DIMM, not 4 or 8 or more, and this allows for much electrically cleaner address signals.
They even covered how to read a timing spec such as 2.5-3-3-7-1T, and how it's even possible that half a clock can be involved (in DDR RAM, data is transferred on the both the rising and falling edges of the clock).
It's just an outstanding presentation:
Corsair - Memory Basics
The only real missing area is a discussion on single- versus dual- ranked memory and the cost/performance tradeoffs involved. I think this presentation is slightly dated, so this area of ranking (not banking!) may not have settled down yet.
]]>It's just a great mechanism, there there is a lot of good guidance out there. My favorite is Troubleshooting RPC over HTTPS by fellow MVP Rodney Buike, but I've found a corner case which caused me to waste a maddening amount of time.
My environment is an SBS2003 machine hosted at a data center, and 100% of the real users being remote, not part of the domain, and with no access to any of the NETBIOS-ish protocols that Outlook normally uses to talk with Exchange.
Furthermore, the machine's real hostname uses the .lan extension (others typically use .local), as we didn't want to use our real company domain because Windows would then want to "own" it. So by calling it sbs.company.lan, Active Directory wouldn't interfere with the rest of our DNS.
The gotcha is during initial setup of the mailbox, you must enter the internal hostname of the Exchange server, and this will fail the first time. The remote users are not in the same data center, have no access to the .company.lan nameservers, so of course name lookup will fail. This is expected!
Simply clicking through these error messages allows you to get to the [More Settings] button to configure the Exchange Proxy Settings in the Connections tab. At this point you'll enter the external name of the machine (https://sbs.company.com) to allow it to make the actual TCP connection to the IIS-based proxy.
Once the proxy is configured, it becomes the exclusive communications channel for this session to Exchange. Then later, when Outlook tries to connect, it passes the internal name (found in the initial setup screen) over the protocol exchanged via the proxy.
My mistake was using the external name (the hostname of the proxy) where Outlook wanted the name of the Exchange server. Even though the proxy was indeed making the proper SSL connection, the use of the wrong name passed over the protocol failed the connection.
My familiarity with DNS was leading me astray: "that name can't resolve" got me to use the external hostname, and it always failed.
It turns out that SBS users have a little bit of extra help configuring this: the RWW (Remote Web Workplace) default website on the SBS server itself. When visiting the site (http://sbs.example.com/Remote) and logging in, there is a Configure Outlook via the Internet link in the box on the left; it provides instructions filled in with the particular parameters required.
So we learned something here, though I don't think I appreciate the difficulty of debugging this.
]]>The easy part is getting them access - the hard part is making sure it's secure, and it got overwhelming quickly to see how many choices and variation there were.
So I undertook a comprehensive survey of the available choices and produced another Tech Tip which looks to have pretty wide coverage of the technology in question. In addition to the background and details, I include a set of Pro and Con lists for each one, which hopefully will guide somebody into making the proper tradeoffs.
It's mainly intended for SBS2003 users — SBS has some special features not available elsewhere — but should nevertheless still be useful to most of the Windows Server variants.
]]>This is not as easy as it sounds. There's no direct network call to make, because the shell itself is not connected to the network (it's insulated by a pseudo-tty), and the indirect methods are not widely portable. This information is usually found in the utmpx structure, but is not always readily available (the who command on SCO UnixWare doesn't seem to expose this information).
So I wrote a program, whoamIP, to make a best effort at retrieving this information, and so far it works properly on SCO UnixWare, SCO Open Server, and on Linux.
Feedback (especially on portability issues) is welcomed.
]]>Most of the actual graphical parts of the driver are more or less unchanged, but the housekeeping and support functions differ enough to make this a challenge the first time. A few of the really trivial changes were not obvious, and I burned days and days trying to track them down.
Microsoft's documentation on this is really thin, and I looked all over the internet without success for some comprehensive guidance, so I decided to write a Tech Tip on the subject.
I started taking notes almost immediately, keeping track of big or little issues as I found them, and ended up with something that covers the major points pretty well. It doesn't replace understanding how print drivers work, of course, but for somebody thrown into the deep end of the pool with a "Convert this driver" directive, it should save a lot of time.
Unixwiz.net Tech Tip: Converting Win32 Kernel-mode Print Drivers to User Mode
]]>So I wrote up the whole process in another one of my Tech Tips in the hopes that it will encourage others to make a go of it. It's an easy process - try it!
Unixwiz.net Tech Tip: Slipstreamed Driver Installation of SBS 2003
]]>If some unrelated process (say, a network backup) started competing for resources, it wasn't uncommon for this to turn into a cascading meltdown. I've seen dozens of polling jobs running at once while checking the system in the morning, and the only solution was to just kill everything, let the system settle down, accept the hours of lost data, and let things pick back up with a clean slate.
With the premise that missing a single polling period is superior to swamping the machine, I created a tool, lockrun, which wraps the given command line (such as a cron job) with the protection of a lockfile.
If a new polling period comes around, but the lockfile is still in use from the previous job, it will exit with an error message which is routed to the user via cron's normal email mechanisms. This way, we'll never have two of these jobs running at the same time.
This is a bit more sophisticated than just touching a lockfile or storing a PID in a file: this uses actual file locking, whose locks are automatically released when the program exits for any reason. This includes killing with -9, core dumping, or even a system crash. There are no files to clean up at system boot time either.
I'll note that this is not really a solution to the problem: the real problem was an underpowered machine (which we have since remedied), and it doesn't replace a proper queuing mechanism. Instead, this is a fail-safe to prevent system meltdown, and it's really served us well.
I've been using this for months on all cron jobs which have any chance at running long, and it's been completely bulletproof as far as I can tell.
I hope it's useful to others.
]]>It's ready.
It was easier that most because there were only two Statewide propositions, and the agendas are a lot more transparent. This made for much more straightforward analysis.
California Ballot Analysis - June 6 2006This is meant to elaborate on the issues, not tell you how to vote, and as always, I welcome thoughtful feedback or bug reports.
]]>I write Windows print drivers, mostly built on the Microsoft OEM PostScript driver using customization DLLs, and I spent days tracking down a problem where DrvStartDoc() was called with no job ID. This is part of the interface, and the driver depended on getting it, but even though it worked for months, upgrading to Word 2003 broke it. No Job ID.
After days of research I figured it out: DrvStartDoc() can be called more than once per document. The first time it's called with the Job ID as expected, but if the application does a ResetDC(), we'll get called again with the new DEVMODE. Those subsequent calls don't get the Job ID.
The solution is to save the Job ID into the OEM PDEV (pdevobj->pdevOEM) the first time we see it, and to be sure to implement the ResetPDEV() call to copy the private OEM PDEV as it gets reset. I had omitted the ResetPDEV() call, thinking it was not necessary, so the saved Job ID was discarded when the application changed the DEVMODE.
Even without the ResetPDEV / ResetDC, this is necessary if the application is printing via a metafile, which is set via the Enable advanced printing features checkbox in the Advanced tab in printer properties. Without proper PDEV management, it will break badly.
]]>Syracuse University, CIS785 requires Best Practices for UNIX chroot() Operations
Rensselaer Polytechnic Institute, CSCI.4220 requires An Illustrated Guide to IPSec
I'm sure that these are requirements by the individual professors rather than being a formal part of the curriculum, but it's welcome nonetheless.
How cool is that? :-)
]]>