2/25/06

S
S
L

Wow, what a lecture we had in MCSE425 (ISA Server 2003) Thursday evening. We were talking about how ISA server deals with filtering encrypted traffic. My instructor started off by saying, "Does everyone know how SSL works?" Everyone nodded... It's basic, it encrypts the data-payload of a standard HTTP packet, and authenticates communication. Easy, right?

Well one student said: "Could you clear it up a bit?" Well, most of the class was thinking... "Gee, this is gonna be a quick lecture on how SSL works, and then we'll be done." Well, that was before we figured out that we didn't have a clue how SSL really worked.

We knew that it had to do with certificates, but we thought it had to do specifically with Public Key Infrastructures... Well, it seems it doesn't (although, Wikipedia says it has more to do with PKI than my instructor said... hmm). From what I got from the lecture, SSL connections (HTTPS in particular) work like this:

Client: I want to go to https://www.secure.com/, so I'm gonna need a certificate... HELP!
Certificate Server: the certificate for https://www.secure.com is {cert101}
Client: Okay! Thanks, Certificate Server!
Client: I want to go to https://www.secure.com, I've got this certificate that says to encrypt my communications in such-a-way... So ENCRYPTION ENABLED! Request secure communication with server, key (randomnumbers910832here)
SecureServer: 'Aight! Communication with (randomnumbers910832here) accepted. So... do you have a certificate for this communication?
Client: Yup! Here it is: {cert101}
SecureServe: 'Aight! That's the cert. Wadda need kid?
Client: I wanna go here, do this, upload this, download that, and spend mucho monies on your site.
SecureServer: Okay!
Client: Alight, I think I've run out of money... I'm gonna go away now and watch my credit debt pile up. Laterz!
SecureServer: Mwahahahaha.... *ahem* I mean, okay. Closing connection.

The problem was really the start of communication... It's still a little foggy to me... The client gets the cert from the cert server... Okay, great. But anyone could do that!

Two, when the client goes "I want to go to https://www.secure.com, and I'll encrypt my communication in such-a-way" -- in what way does it encrypt the traffic? And how does the SecureServer know how to decrypt the traffic? I think the traffic is encrypted using the randomnumbers key, but then how would the server be able to decrypt it? Oiii, this still isn't clear enough for me, but since my instructor was turning a dozen shades of red with frustration, I decided not to ask him about it anymore... I think I got the jist of it anyway.

Relevant Links:
TCP/IP Guide: HTTP Security and Privacy,
Wikipedia: Secure Sockets Layer,
Wikipedia: HTTPS

TCP/IP Seminar!
On a side note, I went to that TCP/IP seminar yesterday... It was informative, although the problem was that it was very "bringing old network professionals up to date" with utilities and what-not stuff... Some of the stuff was replay for my class, where other bits were new stuff that was a bit irrelevant to our class... But then again, the seminar was geared toward network professionals that have been in the field, and want a second opinion or to be brought up to speed on some topics. If you take that into account, it was a decent seminar.

I did work a bit with some utilities (Ethereal is so very cool), but my favorite part of the whole thing was watching him PuTTY into Linux boxes and control them and the trip into the server room, where most of the servers are Linux boxes assembled by Penguin Computing! That is so very sweet. I don't recall what distribution he said he was using, I'll have to ask Royce that later. He also mentioned that he's using SmoothWall as his firewall! Totally sweet.

2/19/06

Image hosting by TinyPic

It just fixed itself.... but no one but me needs to know that fact!

A few days ago, I was running Suzi like usual... I had just started watching an anime video in KPlayer, full screen, when I realized that I had seen the video before. Being lazy like I am, I hit Alt + F4, which is supposed to stop the video, close the video file, and close KPlayer, returing me to the KDE desktop and to the most recent window or application that I was using... Well, for some reason when I do this every now and then, it'll crash KWIN (the portion of KDE that manages the windows and K-bar). With KWIN crashed, there's almost nothing accessible in KDE. The front most window is stuck there, the file menu is usually still there, and the front most windows can be closed, allowing data to be saved (if luck is on one's side...). Sometimes the File menu isn't there, and there's nothing to be done about that, accept try to work around without being able to close that window (and it being permanently stuck in the foreground).

This time, I was able to close several windows, accept one of the konqueror windows (which mysteriously lost it's file menu). An odd thing that I noticed when I was preparing to log out of my session, was that the Gnome desktop manager (Nautilus, I believe is it's name, although that may only be the name of the file browser) was actually managing my desktop -- which looked pretty damn odd. I couldn't click on anything, but my icons and the way the desktop looked was in an obvious gnome look. After a bit of pondering, I decided to keep going with this "emergency shutdown process" -- I was mostly worried about the applications that I wasn't able to shutdown... I keep several apps in the KDE system tray (Gaim, Amarok, Mozilla Thunderbird, and Mozilla Sunbird) -- each of these apps can have a bad experience if they are left running when I log out of the system, especially the Mozilla applications, they can easily get a file-lock on the profile, which can take some work to undo (finding the lock file can be quite the pain at times).

Since there wasn't anyway for me to access these applications, aside from going to a tty session and killing them by hand (which would have had the same affect of doing a log-out without shutting them down) I decided to just go ahead and log out and hope for the best. When I returned to KDE, things were looking good: the desktop icons were in the correct spots (a tell-tale sign of KDE/SUSE problems is when the desktop icons shuffle themselves into the upper left corner of the screen), and amarok, gaim, thunderbird, and sunbird all started without a hitch! Yeah! The deities of Linux were with me that day!

But after awhile of using the OS, I noticed something... Amarok has an OSD that displays the name of the song it just started playing for five seconds, and then disappears. It was now displaying the name of the song before it started playing it... It was quite odd. And then I noticed something else... The songs weren't changing, they were transitioning via a fade! Amarok has never done any fading that I've noticed before! And to top matters off, the spectrum analyzer (the bar things at the bottom of the amarok window -- also in XMMS and WinAmp and others) which has never worked for me suddenly started working. w00t! I'm soo happy, but I find it odd that it just started working out of the blue!

2/17/06

Image hosting by TinyPic
SUSE Baby!

Alright, so I was thinking, Gee, I'm not really happy with that Gentoo machine... It doesn't work the way I want it to, and it's really difficult to use the damn thing... Grrr, I wish I had a decent linux file server! and then I realized that I hadn't tried out the latest and greatest version of SUSE (version 10.1 beta 3)... So, I went to OpenSUSE.org, did a little research, and decided that it would be nice to try out 10.1b3... I haven't messed around with the 10.0 virtual machine in ages (nor have I messed around with the Windows Server 2003 VM in ages either, but I digress), so I figured that it's high time that I update the VM... And if 10.1b3 works out well, it shall be time to say BEGONE, foul operating system! and then usher in SUSE 10.1b3.

Either way, it should be fun to experiment for a while. I think the downloads should be done by tomorrow evening... Although, next week is pretty busy (8 extra work hours, plus a TCP/IP suite seminar in Ithaca on Friday -- going to that instead of work).

Miki-ni Update...
Last Friday, I was playing around with creating a copy of a DVD in Linux, and I was having a minor issue, so I decided to head over to Miki (my Windows 2000 Pro machine) and see if I could get the files off using Windows... When I KVMed over to Miki, I was greated with:
KERNEL_STACK_INPAGE_ERROR 0x00000000 (0x00000077, 0xC000000E, 0x00000000, 0x01AB0000) Oh joy... A BSoD. I noted the message, and restarted my machine.

Upon reboot from a BSoD, there's one thing that every computer user should do: look at the Event Viewer. So I rebooted my computer to do just that. The reboot was successful... There's some possible risky situations to keep in mind when rebooting from a BSoD:

Risky Situation 1: after blue screen, OS or hardware failure prevents booting...
[ status: avoided ]
Risky Situation 2: after rebooting from a blue screen error, OS is not usable for troubleshooting due to other errors thwarting usability of the OS
[ status: my computer made a "spin down" sound followed by a "spin up" sound. The sound of hard drives powering off and on... Quite the bad sign, wouldn't you say? ]

When the first spin down occurred, for a moment my computer lagged. I had lost control of the OS as one of the drives had spun down and, after only a moment, spun back up... But at least the system came back up. Maybe it wasn't the hard drive? Just some odd sound? I knew better, but it was a thought that would keep me from freaking out that my anime/file server had crapped out on me... And the OS had returned to my control anyway, so it could have been a fluke... Although, an error like an HDD spin-down isn't something that just happens for no reason.

So I clicked on Event Viewer, and as I was moving my mouse to click on the "System" subfolder (where any HDD errors, possibly page file errors, and other major system faults would be reported, and might hint to a reason for the BSoD error I received) - that when it happened again!! One of my HDDs spun down again, locking the system where it was at. This time, when the drive spun-up again, there was no recovery. My screen was locked in the same spot that was was... Keyboard and mouse were unresponsive.

I waited for about five minutes, without regaining any type of control. But when I heard the drive spin down for the third time, I could only think that this was no fluke, there was either a very hardware fault on one of my drives (*gasp!*) or that my power supply wasn't able to power all of my devices at the same time

The PSU being a FOUR year old, a no-name-brand (Nobilis), low wattage (230 watt, I believe), and suffering though nearly continuous use since 2002, I figured that it may be the PSU (power supply)... If it was, it may explain all the odd errors in the system, including page file errors, odd BSoD errors, and worst of all, if it is the PSU, it could eventually lead to damage to other components to the system... Since I figured that the most sensitive part of my system is the PSU, I decided to replace that!

A fix was in immediate need, but with Andrew still sleeping it wasn't possible... Rebooting to see if the error persisted was foolish (such obvious PSU trouble could easily cause more damage to the system if I power-cycled the machine). The best thing to do was to power off the machine, get back into bed, and deal with it after work. So, that's what I did (surprisingly, I wasn't worried about Miki-ni, and put the computer out of my mind shortly after I turned it off).

Later that evening, I was able to get to work on the machine. A PSU transplant:

For some reason, after a long day under near-zero conditions of sleep, I always seem to have trouble staying asleep. But, after a short two-hour nap, I felt refreshed enough to attend to Miki-ni. The plan of action was simple: do a power supply unit (PSU) transplant from Experiment8 to Miki-ni.

Notice: any type of hardware modification to any computer is potentially dangerous, and may void your warranty.

Miki-ni being so old --and custom built by a small-time computer shop in my home town, it had no warranty. And doing a PSU transplant is analogous to doing a heart transplant in surgery... Everything needs to go perfectly, since the PSU supplies the "blood" (DC current energy) to the computer's internal organs (components).

Since Ex8 was just sitting around doing nothing (it has gentoo installed to it, but without a monitor, keyboard, or mouse, it wasn't being of any use -- not to mention that I wasn't able to setup my "gentoo file-server" like I wanted...) I decided to work that that machine before Miki-ni... Ex8 had a relatively new PSU, a 400 watt baby that I installed when Ex8's PSU died about four months ago --at the time, I was having trouble with Miki-ni's PSU, and thought about replacing it, but wanted to try out this "ALLIED" PSU [image] before actually installing it in Miki-ni... And now was the time for the testing to be over, and the full blown installation to be underway.

The removal of the Allied PSU from Ex8 went as easy as silk. Opened the case, undid the molex connectors [image] from the drives [image], the motherboard connector [image], and all other remaining connectors, removed the PSU from the case, and sat it aside. (images from google image search, and not from my personal machine)

The removal of the Nobilis PSU from Miki-ni wasn't as simple. Undoing the molex connectors, and all most other remaining connectors was simple, but the connector for the motherboard was placed in under my hard drives in a spot that is inaccessible without removing my "drive cage" - a total pain to get in and out... But possible.

Once the cage was out, I had to pull the 20-pin motherboard connector, which after being seated for four years was nearly impossible to remove. The securing latch on the connector actually broke away when I removed the connector from the system!

The easy part was installing the Allied PSU, but there is a scientific methodology to dealing with power supply units...
  1. On the first boot, never hook everything into the machine and attempt to boot it... If anything should go wrong, a limited number of components in the system would be at risk of damage. Although knowing this, the last time I reconfigured my system (just over a year ago) that it wouldn't boot the OS without all the harddrives hooked in together, but at least keeping the drives to a minimum would allow me to see if the system would run (or fry) itself.... PASSED: Due to having all the HDDs unhooked and none of the input devices (Keyboard, Mouse) or output devices (Speakers, Monitor) all the system did was beep.
  2. Test Two: The big test: would risk all of the system, accept for my CDRW/DVDROM, 250 GB anime drive and my 100 GB storage drive. A necessary risk. So, with my system laying on the floor, with it's guts plainly exposed, I hooked in the one required item to the computer: the power plug (risking the monitor, keyboard, and mouse was again unnecessary). Pressing power produced the expected results (no smoke, error beeps for having no keyboard or monitor). This is a good sign, I thought to myself, time to go to the next stage.
  3. The final test is a boot-up of all devices: And once again the system began to successfully start up, I cheered with delight! The computer was booting, with all components successfully loaded. I was abled to access all of my drives, read and write information, and all looked good. It was time for some stress relief: once I had determined that the system was doing well (no odd system failures or error messages) I played a song for my computer - "Oingo Boingo: Weird Science" [ Lyrics ], it seemed appropriate ^_^


Fast Forward: One Week Later
There was one thing that I noticed about Miki-ni while I was in there working on the hardware: the system was getting really dusty. I hadn't had the time in ages to actually dust out the system, so it's about time for that. I managed to get my hands on a new can of compressed air today, and that's what's going to be happening to Miki-ni as soon as that last download finishes.

But other than the dust, there have been no odd errors... ShareScan crashed a few times, but I think that was just the application, and had nothing to do with the PSU, or anything else that is related to hardware. Only time will tell if this was the right decision, or if I was just looking in the wrong direction, but so far, things are looking good.

2/2/06

That's one odd IT Failure, after a long weekend....

Preproduction

Computers
  • Miki-ni (a.k.a. "the Desktop"): OS Windows 2000 Pro, SP4. Relevant Software: ZoneAlarm 6 (Trusted Zone).
  • Miki-chan (a.k.a. "the Laptop): OS Windows 2000 Pro, SP4. Relevant Software: ZoneAlarm 6 (Trusted Zone).
  • Suzi-lnx: OS SUSE 9.3. Relevant Software SUSE Firewall (Internal Zone).

Network Setup
DHCP offline (college reasons, details superfluous to this entry)
Physical CAT5e connection to college network removed in the process of troubleshooting early on

The Network That Wasn't

When I got back from my brother's wedding, I wanted to do one thing: transfer some anime (kyou kara maou) over to Miki-ni. Since the network was down anyway, I unhooked my link to the college network and reconfigured my computers to have statically assigned IP addresses (since Miki-chan can't get a DHCP address on campus), and with the DHCP server inaccessible to us anyway, it seemed like the logical thing to do.

Miki-ni: 172.16.5.10
Miki-chan: 172.16.5.9
Suzi-LNX: 172.16.5.8
I added Suzi-LNX in there because I wanted to show episode one to James (who was over visiting at the time).

I was able to transfer episode one from Miki-chan to Suzi-LNX without any problem, and after we watched it, I wanted to transfer all the rest to Miki-ni, so I wouldn't have to keep my laptop on all night transferring files from it to Suzi... Doing one big download to Miki-ni seemed like a better idea, Miki-ni is my fileserver anyway.

And that's where all laws of IT-physics seemed to break down. Miki-ni and Miki-chan could not see one another on the network. The ping command didn't work at all...
C:\>ping miki-chan
Request timed out.
Request timed out.
Request timed out.
Request timed out.
C:\>


And worse:
C:\>ping 172.16.5.9
Request timed out.
Request timed out.
Request timed out.
Request timed out.
C:\>


And the same was true for pinging Miki-ni from Miki-chan. I just couldn't get the two machines to work together. Eventually, I set them both to DHCP (knowing that they would get an APIPA address, which should allow them to communicate over the network) I figure that I must have done something wrong -- like configuring the IP settings wrong, or maybe even having the firewall set wrong, so I turned off the firewall, and with their new APIPA addresses, communications should be easy as pie.

But it wasn't. Miki-ni and Miki-chan couldn't see one another nor could they ping one another. They were on the same subnet and had valid APIPA addresses, but they couldn't ping one another. At this point, I was desperate. I restarted both machines, swapped out their CAT5e ethernet cabling for different CAT5e wiring... To no avail. Both machines still couldn't ping one another, let alone get files transferred... You would think that a 5 year college veteran like me, with an associate degree in CIS, and with nearly a dozen Microsoft Networking classes under his belt, I would be able to get a laptop and a desktop (running the same OS, without a firewall) to be able to access one another... But no. Andrew (my roommate) suggested that I use my USB flash drive - but that would have been a lot of work (I wanted to transfer 5 GB of data, and the USB drive is only 512 MB, not to mention that Miki-chan and Miki-ni both have only USB 1.1, so they are pretty limited when it comes to USB).

Eventually, I decided to switch back to a static address (a 192.168.1.z) on all the machines to see if I could get that to work... But once again no... By this time, James had long since left... There wasn't much point in staying around when I'm trying to fix a problem like this, because I'll stay there and work it right into the ground before I give up on it. And that's exactly what I did. It took me a while but eventually I was able to get Suzi to see Miki-chan, and I downloaded all of Kyou Kara Maou over to Suzi (and started watching, as a reward to myself).

What was really odd about this hole situation was that in the beginning, Suzi and Miki-chan could access one another, but never could Miki-chan and Miki-ni see one another. And, as soon as I put Miki-ni on the network with a static address, I couldn't access Miki-chan from Suzi either... I'm not sure if that was a fluke, or if there was something from Miki-ni that was interfering with CIFS/SMB connections. Another oddity was that throughout this entire process, it seems that Suzi was able to access Miki-ni the entire time!

I did notice something odd, that may have been why some of my connections were being so odd... At the end, when I would ping Miki-chan from Linux, the first 7 to 10 ICMP echo requests would not be responded to, I'd see something like this:
indigo@Suzi-lnx:~> ping 172.16.5.9
PING 172.16.5.9 56(84) bytes of data.
64 bytes from 172.16.5.9: icmp_seq=9 ttl=245 time=236 ms
64 bytes from 172.16.5.9: icmp_seq=10 ttl=245 time=175 ms
64 bytes from 172.16.5.9: icmp_seq=11 ttl=245 time=171 ms

--- 172.16.5.9 ping statistics ---
11 packets transmitted, 3 received, 73% packet loss
indigo@Suzi-lnx:~>


And even when I used Suzi to access Miki-chan, there was a noticeable delay in communication... At first, it took a while between the time I hit "Okay" at the login prompt and the directories were displayed, and then again, when I hit copy on the files of anime and pasted those files over into Suzi, there was another delay... Each seemed to be right around ten seconds long too... Mystery... Maybe, there wasn't a problem with Miki-ni, but maybe there was some type of delay in communication with Miki-chan that caused the default way that windows works to not be able to communicate with it (note that windows has a default maximum ICMP echo request of 4, where as Linux has no default maximum (on any distribution that I've used at least... and SUSE 9.3 is no different).

But, after over two hours of work on this, with only a round-about solution, I decided to at least reward myself for my efforts... I watched episode two of Kyou Kara Maou... And now I'm addicted! Eeaakk! ^_^