Hey ABC, It's Mike looks like, and we're took a huge duty this morning here DEF called me because things are going
down from his point of view on that. And once I got some acid and then both of and liars routers. We were
essentially down wanted flap. I don't know 510 times. Or so I don't have any contact information for either server
crazy. Or and later anywhere that I can find, but I assume I lost it or I don't know, maybe never gave it to me
either way. I don't have any lost DVDs or anything like that anyway. So when do much good to call him without any
of that me know when you get this. Just give me a call. I think it's we're screwing the recovered now but clear
they had some for a major an orange on them and i kinda wanna know what was planned to where they had to sue us
for whatever the heck happened. Anyway, give me a call back. Bye.

Yup.  Clear as mud.  Moon, that spells mud.

$ traceroute -n 204.11.246.1
traceroute to 204.11.246.1 (204.11.246.1), 30 hops max, 38 byte packets
 1  192.168.1.1  0.840 ms  0.732 ms  0.706 ms
 2  10.24.128.1  7.551 ms  7.231 ms  7.209 ms
 3  72.175.110.32  6.933 ms  7.140 ms  7.491 ms
 4  72.175.110.5  7.344 ms  7.208 ms  7.785 ms
 5  * * 72.175.110.10  8.682 ms
 6  * 66.62.136.49  23.260 ms *
 7  * * *
 8  * 66.62.3.45  53.182 ms *
 9  * 66.62.4.69  51.422 ms  49.599 ms
10  * 66.62.227.38  76.780 ms *
11  * * 204.11.246.1  70.323 ms

$ traceroute -n www.google.com
traceroute: unknown host www.google.com
mloftis@skate:~$ traceroute -n www.google.com
traceroute: Warning: www.google.com has multiple addresses; using 74.125.155.104
traceroute to www.l.google.com (74.125.155.104), 30 hops max, 38 byte packets
 1  192.168.1.1  1.023 ms  0.818 ms  0.925 ms
 2  10.24.128.1  6.773 ms  5.834 ms  6.351 ms
 3  72.175.110.32  7.953 ms  7.516 ms  7.720 ms
 4  72.175.110.5  8.018 ms  7.763 ms  7.953 ms
 5  * * *
 6  * * 66.62.136.57  23.241 ms
 7  * * 206.81.80.17  26.476 ms
 8  * 209.85.249.32  30.348 ms 209.85.249.34  26.190 ms
 9  * * *
10  216.239.48.32  43.728 ms 209.85.250.144  31.932 ms *
11  * * *
12  * 209.85.254.150  31.430 ms *
13  74.125.155.104  31.823 ms  33.693 ms  32.124 ms
mloftis@skate:~$ traceroute -n bresnan.com   
traceroute: unknown host bresnan.com
mloftis@skate:~$ traceroute -n bresnan.com
traceroute to bresnan.com (67.228.105.43), 30 hops max, 38 byte packets
 1  192.168.1.1  0.908 ms  0.726 ms  0.707 ms
 2  10.24.128.1  152.426 ms  7.691 ms  9.535 ms
 3  72.175.110.30  7.923 ms  7.017 ms  7.179 ms
 4  * 72.175.110.6  6.996 ms *
 5  72.175.110.12  7.314 ms  7.451 ms  7.656 ms
 6  66.62.136.57  23.256 ms  22.095 ms *
 7  * 206.81.80.140  26.763 ms  28.088 ms
 8  * * 67.228.118.134  27.284 ms
 9  67.228.96.106  26.758 ms  25.920 ms *
10  * * *
11  * * *
12  * * *
13  * *
mloftis@skate:~$ traceroute -n 4.2.2.2    
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 38 byte packets
 1  192.168.1.1  1.510 ms  0.772 ms  0.740 ms
 2  10.24.128.1  6.342 ms  7.520 ms  6.095 ms
 3  72.175.110.30  7.793 ms  7.856 ms  8.101 ms
 4  * * *
 5  72.175.110.12  11.328 ms  7.737 ms  8.208 ms
 6  66.62.136.49  22.695 ms * *
 7  4.53.146.97  26.475 ms * *
 8  * 4.68.105.30  35.334 ms *
 9  * * 4.69.132.49  50.060 ms
10  * * 4.69.134.214  42.683 ms
11  * * 4.68.123.38  43.659 ms
12  * * *
13  4.2.2.2  44.358 ms  44.613 ms *
mloftis@skate:~$

Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 192.168.1.1                       0.0%    11    0.8   0.9   0.8   1.1   0.1
 2. 10.24.128.1                       0.0%    11    7.1   7.4   6.4  11.3   1.3
 3. 72.175.110.32                     0.0%    11   11.5  10.1   6.5  21.5   4.9
 4. 72.175.110.5                      0.0%    11    7.3   8.1   6.9  15.2   2.4
 5. 72.175.110.10                    70.0%    11    8.2   7.8   7.4   8.2   0.4
 6. 66.62.136.57                     50.0%    11   23.6  23.4  23.0  23.9   0.4
 7. 206.81.80.17                     45.5%    11   25.2  28.1  24.9  39.6   5.7
 8. 209.85.249.32                    27.3%    11   28.8  27.0  25.2  29.4   1.5
 9. 72.14.239.12                     77.8%    10   37.0  43.3  37.0  49.5   8.8
10. 216.239.48.32                    44.4%    10   32.5  32.2  31.6  32.7   0.5

And I need to get a better template/theme/skin for my blog.  Argh.  Well, you get the idea.

For a while now I’ve had a +12VDC wall wart that I use occasionally.  It always caused weird heating though in regulators.  I was never sure why, the multi-meter read it as having a fairly stable +12VDC.  I finally hooked it up to an oscilloscope today…well now atleast  I know why…

It’s supposed to be producing +12VDC, center positive.  What you’re looking at is the center pin (tip) on the yellow (CH1) channel, and the ring  (or barrel) on CH2.  The trigger is on CH1 @ the rising edge of the wave at 20V.  As you can see it’s getting voltages as high as +65V and as low as -110V.  It follows the AC line perfectly, the cycle time measured by the scope almost exactly matches that of the AC line.  In fact if I trigger on the AC line (this scope can trigger from it’s AC line input) the waveform stays completely steady.

The second picture shows in red what a multi-meter reads.  Which the scope reproduces by differencing CH1-CH2.  The ripple is a bit better when it has a load but it’s still producing these ridiculously high voltages.

So, it’s producing +12V…sorta.  Only as a function of the difference between it’s own +/- reference.  Even a good multimeter can be fooled by a bad signal.  Normally you’d probably never even notice this because you’d hook your multimeter up to your projects GND which is usually the – on the power supply.  If you’d tied this wall warts – to GND, you’d either cook it, or hit it’s current limiter, or both.  This little sucker is probably going to be dismantled and tossed.

BEWARE CHEAP WALL-WARTS!

It’s entirely possible that they intentionally deleted things (maliciously) but even if they did, there should be an alternate archive system.

All too often backups get abused into trying to be archives, and it just does not work.  This is so common tat many backup systems have bent to this.  It’s so common that one that doesn’t gets asked so often they usually write a FAQ about it as AMANDA has done.

So folks, if you need archives, get a proper archiving system and quit trying to bastardize perfectly good backup software into doing it.  There are many archiving systems out here.  And no they’re not cheap.  Why?  Because a database archive, an e-mail archive, and a file archive all have very different properties.

This process sucks a little bit because unlike everyone else Debian still doesn’t support PVM inside of their installer.  So you have to fire up a full HVM environment and use debootstrap, OR, convert that (HVM) environment to a PVM.

Everything was fine getting the initial HVM bootstrap env up, but nothing he did would get pygrub to fire up the kernels, it kept complaining (when run interactively) that it could not find the kernel.

# pygrub /dev/zvol/dsk/p0/zvol2
Traceback (most recent call last):
  File "./pygrub", line 658, in ?
    chosencfg = run_grub(file, entry, fs)
  File "./pygrub", line 509, in run_grub
    g = Grub(file, fs)
  File "./pygrub", line 198, in __init__
    self.read_config(file, fs)
  File "./pygrub", line 388, in read_config
    raise RuntimeError, "couldn't find bootloader config file in the image provided."
RuntimeError: couldn't find bootloader config file in the image provided.

This was to say the least, VERY irritating.  And we couldn’t figure out why.  We tried messing with the partition tables, the menu.lst, everything.  Until I remembered a problem with mke2fs -t ext2 NOT producing 2.4.x compatible ext2 filesystems and began to wonder if that is what happened here.  Sure enough, running mke2fs from Debian 4 and not Debian 5 produced a working system.  Solaris’ pygrub is completely useless in providing a good error, only providing the traceback above.

Hopefully this will help some poor soul trying to get Debian 5 inside a PVM running on Solaris or OpenSolaris.

I have a bit of egg on my face.  I trusted the LSI people a bit too much.  There was a critical race problem in their driver for the 84016E …  to their credit they fixed it in June.  I found a workaround before we figured that bit out, thank god Solaris’ fault management systems, psradm to the rescue, since it was a race problem with unaligned mutexes, using that and offlining all the other CPUs solved it a treat. To LSI’s discredit they updated some pages but not others.  I installed 1.17 driver version, current was 1.23.  If you looked at the 84016E page the day I downloaded it was 1.17.  Sun pointed out 1.23 was available on the 8888ELP page.  I downloaded and installed that, very happy from then on out.  To LSI’s credit there was a human answering the phone immediately, late Sunday, who could get someone working on the problem right away.  I’d already worked around the issue so was ok to let it sit till first thing Monday AM.  Even Sunday, immediately got a person who was willing and able to start a case, get it in front of their actual-people-who-do-the-development.

Despite the page update issues, and crash, LSI wins for having support (and english to boot) and being ready and willing to at least try to solve the problem.  If it were an emergency still they were willing to (for a *reasonable* hourly fee mind you) get someone working on it right away that Sunday even.  I call this a Good Thing.  So, despite the VERY rough start LSI still wins me over in the end because of customer support.

What problem is this that I am speaking of? LACK OF INDEXES. Seriously. If you have a sessions table, and you’re searching for old sessions to expire YOU NEED AN INDEX ON THE TIME COLUMN.

Another fun one is seeing ‘delete’ functions that don’t take care of the extra data referencing the main table, this is largely MySQL’s fault for not having foreign key support until lately. It really is the database’ job to deal with that.

1.8 million sessions occupying about 500MB or so, bringing a server down to it’s knees. CREATE INDEX sessions_last_active_idx ON sessions (last_active); and suddenly everything is 100% kosher.

What I am saying is, either find someone who has a damned clue to design your DB Schema INCLUDING INDEXES with you, and review your EVERY SELECT, DELETE AND UPDATE, or learn how to do it yourself, or don’t write the app.

Well I made the leap to Windows 7 after having to buy a new laptop (long story short the desktop is dead). Upon upgrading to Win7 RC1, as the laptop came with Vista, my Time Capsule disks stopped working with a mysterious username/password error number 86. I never was able to find out what the hell that meant, but I made an educated guess that Microsoft had disabled some of the old password standards, say NTLM maybe.

That turns out to be the case. These same instructions will probably get Windows XP and Windows 2000 shares to work with Vista and Win7.

Open the Local Security Policy MMC applet, you can do this by searching for Security in the start menu or from the command prompt by typing:

%windir%\system32\secpol.msc /s

Once there open the Local Policies folder, then the Security Options view. From there find “Network security: LAN Manager authentication level” – you will probably find this is set to “Send NTLMv2 response only” – change this to “Send LM & NTLM – use NTLMv2 session security if negotiated” – this does lower your security level but is pretty much required to work with anything pre-vista.

Further down you should see “Network security: Minimum session security for NTLM SSP based (including secure RPC) clients” – you may have to make sure that both require boxes there are unchecked as well.

This should get your Time Capsule, Airport Disks, and Pre-Vista SMB/CIFS shares working again!