System Administration
How to determine the number of bits used when generating a CSR
I was looking for an answer to this question today and stumbled across a page on the MaximumASP site, which indicates that looking at the first few characters of the CSR will provide the answer.
I still want to do a bit of research to verify that what they have said is true, but it seems to be, based on my limited test. I generated CSRs for 512-, 1024-, 2048-, 4096-, 8192-, and 16384-bits* and examined the first few characters. My generated CSRs for 512- and 1024-bits matched the MaximumASP page. Here are my results.
Microsoft LifeCam software crashes
Microsoft LifeCam software crashes upon startup. It seems to not be specific to my parent’s computer, but several potential solutions have been proposed. Here’s what I tried.
- Moved 04Geometric*.dll files from C:\Program Files\Microsoft LifeCam\Effects directory into C:\Program Files\Microsoft LifeCam\Effects Backup per this post. — This one change has allowed the camera software to run normally.
At the same time, the Skype software crashes, also when the camera kicks in. I assumed that it’s the same problem in both cases, but that assumption seems to be invalid.
I started Skype after making the change mentioned above and Skype still crashed after selecting the web cam.
I created a Visual Backup 2 directory as a sibling to the other one and moved all the other DLL files from the Effects directory into it and started teh LifeCam software again. It ran and didn’t show any effects from which to choose, as expected. I disabled TrueColor and closed the software, hoping that would help Skype. A few seconds later the LifeCam software crashed.
Inspecting the error report technical details that were sent to Microsoft showed that the LifeCam software was still at least referencing the moved DLL files, so I moved them completely outside the LifeCam directory tree and tried again. Same results.
The next thought was make sure that we had the most recent version of the software installed. One of the forum posts gave a link to the Microsoft page with the software and I downloaded both the most recent LifeCam software and the firmware update for the camera. The firmware program indicated that the camera was already up-to-date (which doesn’t surprise me as I applied the firmware update the day I unboxed the camera), and an inspection of the Version tab of the properties of one of the LifeCam executable files indicated that it was already at version 3.21 (the same as the software I just downloaded). I decided to try reinstalling the software anyway and was told that I had to uninstall and reboot first. So I did.
After the reboot, I noticed that the camera was still listed in the My Computer window, so I right-clicked and chose Properties. A quick Test Camera yielded an all-is-well dialog box. Going back to My Computer and double-clicking on the camera brought up a window with the live camera feed. Closing the window worked fine–no crash. I looked for the C:\Program Files\Microsoft LifeCam directory and it’s nowhere to be found. Just to see what would happen, I started Skype and selected the camera for both the audio and video devices and clicked on Save. Normally Skype crashed at this point, but it didn’t this time. I grabbed my laptop and started a video call between it and my parent’s computer and everything worked just as it should. Even ending the call didn’t result in a Skype crash like it used to.
At this point, I’m considering the issue resolved. The only thing I wish we still had is the TrueColor correction, but I’m willing to live without it if it means that Skype isn’t crashing.
The easy way to make dig more useful: .digrc
I’ve been a long-time “dig” user (on Mac and Linux) to retrieve DNS records before I start transferring a domain to a new registrar. Every time I issue the same dig commands to gather the data I need and put it in a text file for easy reference later. Dig always outputs way more information than I need and I end up fishing through most of it to find the one or two lines that interest me.
$ dig jssm.com any
; <<>> DiG 9.3.6-APPLE-P2 <<>> jssm.com any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37409
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;jssm.com. IN ANY
;; ANSWER SECTION:
jssm.com. 7200 IN MX 5 ALT1.ASPMX.L.GOOGLE.com.
jssm.com. 7200 IN MX 0 ASPMX.L.GOOGLE.com.
jssm.com. 7200 IN A 216.98.141.250
jssm.com. 7200 IN A 69.72.142.98
jssm.com. 7200 IN SOA ns8.zoneedit.com. soacontact.zoneedit.com. 1255263341 14400 7200 950400 7200
jssm.com. 7200 IN NS ns17.zoneedit.com.
jssm.com. 7200 IN NS ns8.zoneedit.com.
;; Query time: 62 msec
;; SERVER: 172.16.0.100#53(172.16.0.100)
;; WHEN: Tue Mar 9 10:10:20 2010
;; MSG SIZE rcvd: 203
Dig Options
After perusing the man page for dig, I discovered the magical combination of options that hides all the stuff I don’t want to see while still returning all the data I do want to see: +nostats +nocomments +nocmd +noquestion +recurse.
Now my command is messy, cumbersome, and difficult to remember, but I have what I want:
$ dig +nostats +nocomments +nocmd +noquestion +recurse jssm.com any
jssm.com. 7200 IN MX 0 ASPMX.L.GOOGLE.com.
jssm.com. 7200 IN MX 5 ALT1.ASPMX.L.GOOGLE.com.
jssm.com. 7200 IN A 69.72.142.98
jssm.com. 7200 IN A 216.98.141.250
jssm.com. 7200 IN SOA ns8.zoneedit.com. soacontact.zoneedit.com. 1255263341 14400 7200 950400 7200
jssm.com. 7200 IN NS ns8.zoneedit.com.
jssm.com. 7200 IN NS ns17.zoneedit.com.
.digrc
I was delighted to see that dig supports a .digrc file for setting default options. I simply plopped the options I like into my ~/.digrc file all on a single line, issued my simple query, and voila! just the data I need without the extra stuff I don’t.
$ dig jssm.com any
jssm.com. 7200 IN MX 0 ASPMX.L.GOOGLE.com.
jssm.com. 7200 IN MX 5 ALT1.ASPMX.L.GOOGLE.com.
jssm.com. 7200 IN A 69.72.142.98
jssm.com. 7200 IN A 216.98.141.250
jssm.com. 7200 IN SOA ns8.zoneedit.com. soacontact.zoneedit.com. 1255263341 14400 7200 950400 7200
jssm.com. 7200 IN NS ns8.zoneedit.com.
jssm.com. 7200 IN NS ns17.zoneedit.com.
Bonus Syntax
I also discovered that dig supports multiple queries on the command line. I can now issue a single command and get all the DNS information I need for a domain:
$ dig jssm.com any www.jssm.com any mail.jssm.com any
jssm.com. 7200 IN MX 5 ALT1.ASPMX.L.GOOGLE.com.
jssm.com. 7200 IN MX 0 ASPMX.L.GOOGLE.com.
jssm.com. 7200 IN A 216.98.141.250
jssm.com. 7200 IN A 69.72.142.98
jssm.com. 7200 IN SOA ns8.zoneedit.com. soacontact.zoneedit.com. 1255263341 14400 7200 950400 7200
jssm.com. 7200 IN NS ns17.zoneedit.com.
jssm.com. 7200 IN NS ns8.zoneedit.com.
www.jssm.com. 7200 IN CNAME wfb.zoneedit.com.
wfb.zoneedit.com. 951 IN A 216.98.141.250
wfb.zoneedit.com. 951 IN A 69.72.142.98
mail.jssm.com. 7200 IN CNAME ghs.google.com.
CentOS
Installing Virtual Machine Additions
# rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-53.1.4.el5.src.rpm
Hacking
Disclaimer: The information on this page is for information purposes only. I have collected these links as part of my continuous learning on computer security.
SQL Server
This page gives information gathered on SQL Server.
Smitty's Thoughts 