More on the mofo track.

Posted by Joshua Schmidlkofer Mon, 02 Jun 2008 20:15:00 GMT

You have to give Microsoft credit. They were 66% correct. That’s about 150% better than normal. Seriously. Todays fun is imported from the land of broken-wmi-crap.

The Bug

After the super-exciting side affect of an asshat package manager, a Microsoft standard-issue-busted-software problem has cropped up:

Event Type: Error
Event Source: MSExchangeSA
Event Category: Monitoring
Event ID: 9097
Description:
The MAD Monitoring thread was unable to connect to 
WMI, error '0x8004100e'.

The Microsoft Article purported to fix this is 33% wrong. They list the major components, and the MSExchangeSA error does indeed subside. Side-note: I found that I had to re-do the steps listed in the TID - AFTER a reboot. ???

The Tragedy

However, I discovered a new pain after my joy: the Message Tracking Center returns WBEM error 0x80041010. Translate this, “missing wmi class”. I did a number of searches (lots of hits from mis-informed TID-spouting ‘do-holes) and finally located this article in Google Groups. He walks through re-creating WMI, and other neat things. I skipped ahead, as I had done all of this before.

I followed his testing advice - I couldn’t get the remote testing to work - local testing showed that root\microsoftExchangeV2 only had 73 out of 74 classes. Frustrated I briefly considered a by-hand comparison with a functioning server. I chose to plow ahead, based on this guys informative nature and clear expertise - and it paid off:

The Missing Command

mofcomp.exe -n:root\cimv2\applications\exchange “c:\winnt\system32\wbem\msgtrk.mof”

In my case the command was actually:

mofcomp.exe -n:root\cimv2\applications\exchange msgtrk.mof

The Apathy

This worked when Microsoft Failed. I feel semi-indifferent. I think this is Microsofts chief tactic for dealing with “haters who want stuff that works”. Entropy from the titanic marketing efforts makes the efforts get them to change them almost worthless.

As a side note, I did submit feedback at the support site. Maybe someone will see it?

biggest mofos on the planet

Posted by Joshua Schmidlkofer Sat, 31 May 2008 23:43:00 GMT

I hate Microsoft. I truly do. These assholes are simply unbelievable. I cannot articulate the fury and frustration which I feel at this moment. Seriously. The insanity of whatever policy drives them is beyond the measure of intelligent people.

I cannot write a scathingly witty post about overcoming them. I have redacted this blog once, but this is beyond endurance.

A client has a Windows 2003 SBS network. They started out on “Volume Licensing”, and the previous admin upgraded to a “2003 SBS R2 Retail” license. Let me tell you - THAT was a joke. You pay Microsoft to run an install off of a CD labeled “R2 Technologies”. This ~$400 investment runs in about 10 minutes or less. The largest change is the “2003 SBS R2” BRANDING. The f*ck*ng BRANDING. That’s right - half a dozen pictures which appear in places.

Whatever, we commenced the upgrade and transition to the Transition Pack. This leveraged our current investment, and actually allows us to virtualize. The problem is that the Transition Pack doesn’t ship with an Exchange 2003 cd.

I do not have enough swear words to make this pain go away. Anyone who knows ANYTHING knows you cannot remove DS from an Exchange Server. You must first uninstall Exchange. Then you may remove/demote/whatever. Then you simply reinstall Exchange.

In our case, we want to move Exchange to server Two, DS to server Three and deprecate server One. We cannot. We don’t have the media. The Exchange media which came with the SBS install requires installation on Windows 2003 SBS. Anyone who tells me I didn’t plan ahead and “see what I got” deserves to be anally raped by rabid coyotes.

This is so stupid and frustrating. I paid $1400.00 to get a two CD pack which migrates SBS 2003 to 2003 Standard. It also came with paper that allows me to migrate Exchange 2003. Oh, and the “rights” to “buy” media from a “fulfillment” center.

Ripping off a product managers head and sh*tt*ng down his throat is more like fulfillment here.

MSSQL - Relocating Database Files

Posted by Joshua Schmidlkofer Wed, 21 May 2008 23:12:00 GMT

There are a ton of articles, esp from Microsoft, regarding moving SQL Server data and log files. After our storage expansion we wanted to move the data and logs for several databases, all of which participated in replication by one means or another.

I didn’t find any articles specifically mentioning what I was doing, however, I decided the best approach was to test moving the files in the same way you relocate MSSQL System Databases. It worked, and I thought I would mention it here.

If you’ve never done this, it’s quite simple.

  • Locate the files (and logical names)
  • Alter Database to change the new location on next startup.
  • Stop MSSQL
  • Relocate the files (locations form step 1).
  • Restart MSSQL

Locate

SELECT name, physical_name AS LogicalName, FileName
FROM sys.master_files
WHERE database_id = DB_ID(N’REPLDB0’);

Alter

ALTER DATABASE REPLDB0 MODIFY FILE
( NAME = ‘REPLDB0_Data’, FILENAME = ‘D:\MSSQL\Data\REPLDB0.mdf’ ); ALTER DATABASE REPLDB0 MODIFY FILE
( NAME = REPLDB0_Log’, FILENAME = ‘E:\MSSQL\Logs\REPLDB0_1.ldf’ );

Relocate

Stop MSSQL, using the paths already seen, move the files and restart MSSQL. Just don’t screw it up.

Idiots in Power

Posted by Joshua Schmidlkofer Sat, 05 Apr 2008 22:47:00 GMT

Why is it that normal people don’t run more successful projects? See this ticket regarding Paludis. Paludis is a C++ replacement for Portage. Portage is a squirrels nest and even though the ebuild system is pretty nice, portage itself is pretty lame.

Disclosure

In the interest of fairness, I would point out: The Paludis site flatly refuses to say anything about the project. Therefore being run by a complete asshole isn’t contradictory to any previous statements.

Summary

The gist of the ticket is that Paludis doesn’t support certain types of parallelism and the developer(s) refuse to do anything sane in order to prevent, notify or clearly document the danger of it. This danger is apparently readily realized by users.

Examples of sanity might be:

  • Warn people it’s not supported.
  • Make some sort of method for restricting parallel execution.
  • ADD A NOTE TO A FAQ

Evidence

What does the Paludis think of a notice about the dangers of parallel runs of the software they publish:

chaoflow: “What about preventing parallel paludis runs or at least a FAQ or some other way of explicitly telling people, that parallel paludis operations are not supported?”
ciaranm: “Preventing parallel runs is a security hole. And an FAQ entry is pointless – parallel executions are fine so long as they stick to certain operations.”
chaoflow: “Wouldn’t it be nice to have documented, which operations are fine for parallel execution?”
ciaranm: “Not really. If you don’t already know, you shouldn’t be doing it at all.”

Very Dense

This is clearly beyond the scope of Paludis. See this conversation:
chaoflow: “What about preventing parallel paludis runs?”
ciaranm: “Preventing parallel runs is a security hole.”
chaoflow: “Could you elaborate on that?”
ciaranm: “It’s an inversion. A non-root user can obtain the locks and prevent root from being able to do anything for an arbitrarily long time.”

This stunning display of logic and intellect is what passes for success over at Paludis. Even I can think of a few methods to help prevent this:

  • Make an override mechanism. Easy enough, right?
  • Enable super-users to kill the offending process.
  • Put the lockfile in a secured-location.
  • Use shared memory, and make use of ipcrm to kill rogue locks.
  • Observe that a security /hole/ involves some sort of exploitation of a system. A DoS involves prevention of normal operation. This doesn’t even make a legitimate DoS.

Blackhole

The stupidity doesn’t end there:

chaoflow: “And way way better would be some simple locking inside of paludis preventing bad things from happening.”
ciaranm: Paludis is not there to protect you from yourself.

ciaranm must see this as an incredibly clever way of saying “go f* yourself.”. ciaranm seems to be an incredibly dense idiot. Why is an f’d up system preferable to some logic which may lead to the inconvenience of cleaning up a rogue lock?

Paludis IS a security hole - It just might fuck up your system, if you run it in parallel with itself, but it certainly won’t try to tell you that. I am guilty too.

Evidence of What's Wrong with Java 1

Posted by Joshua Schmidlkofer Sun, 09 Mar 2008 18:29:00 GMT

I was literally looking for a “change-log” type document describing the differences between Java 1.4, 1.5 and 1.6. This was what I found.

An Open Letter, to OpenDNS 1

Posted by Joshua Schmidlkofer Thu, 06 Mar 2008 05:11:00 GMT

I am having more and more problems with OpenDNS. I have dropped it’s usage at my house, and I am dropping it all my business locations. Your “website is down thing” is not only a huge pain in the ass, but it’s generally wrong.

1 in 10 are right. The other 9 are erroneous reports that Google spreadsheets or docs or gmail is down. It’s asinine. I have been using OpenDNS for a long time, but this shit is busted.

I use Verizon at home, and my colleagues use Comcast and Qwest and SpeakEasy. All of us are having an escalating case of the “not-quite-working-rights”. Cliff - my friend - dropped you last week due to spurious outage reports. Once I get redirected to your site, I have a whole new dimension of pain, since it poisons my DNS servers. I want to shout expletives [at you] when DNS get’s hosed. I want to make hating your service a religion. It’s funny how aggravating DNS anomalies can be. I would rather deal with my providers consistent shit than someone else’s bowel-cramping madness.

I loved your past client-centric focus. I loved the speed and response time. Your service was great. You are ruining DNS.

  • Signed Frustrated-beyond-the-point-of-reason

Machines Are Not Human

Posted by Joshua Schmidlkofer Sat, 12 Jan 2008 01:23:00 GMT

The only people on the planet interested (consciously) in worshiping and serving lower forms of life are PETA wackos. However, the folks at Verizon want you to know something: When you call them, you are on equal footing with machines. Call with any problem: New service, old service, complaint, billing, whatever. The cooly superior mock-human voice answers and immediately attempts to gently “take command” of the conversation. She doesn’t understand, she has no sanity or insanity. She cannot hear you. It’s a feeble fakery.

She comprehends nothing except one or two word statements. Like an NSA voice monitor, she waits for ‘trigger’ words to stimulate a response. Yet, she STOPS to give assent to your individual words. “Ok, I think you want to …..”. The herky, unnatural slow pace of the conversation is mind-numbing. There is nothing elegant about it. She tries to emulate the flow of conversation, only when she cuts off mid-word, it’s eerie.

In science fiction every reasonable robot is servile in all circumstances. Apart from the violent kill-them-all types, the most dangerous types are just like the Verizon helper. In “good” robots, the demeanor, though placid, can often be mistaken for more human failings e.g. arrogance or said superiority. However, time and again they bear out the simple nature and duty of caring for the humans they obey.

The ‘naughty’ robots, hereafter “VBots” live in a sick little world of pure logic. They are simple or complex, either have emotions or don’t. However, their defining characteristic is an absolute absence of compassion or empathy. This becomes a malfeasant danger when it’s coupled with absolute certainty of being correct (in the complex type), or abysmal limitations in the Verizon type.

The voice on the phone is not cool or confident. It’s a cast iron bitch. Oh she will talk with you. But f*ck you if you think this is going your way. She forces you into a rote pattern of behavior. Sneering at mumbled/cursed/shouted requests for a human, her lack of inflection hints that you’re below average for requiring human assistance.

Beginning in the call centers of antiquity, managers have sought for sovereign control of each call.
Inbound

  • Keep those call times down.
  • Stay on target.
  • Avoid lengthy greetings
  • Never admit wrong doing
  • Apologize only in vagaries.
  • Keep those call times down.

Outbound

  • Stick to the script, blah, blah, blah.
  • Maintain control of the call, move in the direction you want.
  • Never allow the mark to answer ‘no’.
  • Stick to the script, blah, blah, blah.
  • Always ask pointed questions, which dictate polite responses, not refusals.
  • Act suprised when they change directions in tone or don’t stick with the program, etc.
  • Stick to the script, blah, blah, blah.

You have the idea. A talented agent can coax you into any place he wants and make you feel as if it’s your idea. Managers hate these people, but that’s not important right now. What is important? These talented people are able to do what machines cannot: Keep you under control without subjugating you or pissing you off.

Deep in the surgically sterile world of evil, emotionless IVR (Interactive Voice Response) systems are made to hate you. Sometimes, it’s sheer desperation for someone to pick up the damn phone, but most often, it’s because IVRs hemorrhage less money on consumer happiness than those underpaid, over-worked sweat-shop workers who live in the call center.

The machines can’t despise you, because the machines can’t ‘do’ anything. They don’t exist as a conscious being. Like unto flu viruses are these machines.

A virus can serve life, or tear it down. Viri are essentially self-replicating processes which do something constructive for the bigger picture or break it apart. The destructive virus, like a brain child of entropy, is bent on consuming, disorganizing and killing any living body more complex and larger than itself. Viruses tend to cause FEVERS - doing thier part in the much feared HEAT DEATH of the Universe. IVR’s generate massive amount of CPU, RAM and hard drive heat. DACs and ADCs are more lik exhaust manifolds than a chips. In other words VBots are just like the viruses. At the end of thier wicked road is the death of everything. And Verizon is helping.

Next time you call a machine, relax - tension creates more body heat and tears you down. Try to cool off and don’t fret about the IVRs, that heat death is millions of years away.

I hate Verizon for this crime against humanity. Even if I go on using their product. Who shall I complain to? The Internets, that’s who.

VMWare Server and NAT.

Posted by Joshua Schmidlkofer Wed, 31 Oct 2007 19:56:00 GMT

I setup VMWare Server on Gentoo the other day. It was pretty much easy. After install, cleanup all the .vmware folders in various home directories. Assign users with priv's to the 'vmware' group.

User Setup

gpasswd -a vmadmin vmware
Run the vmware-config.pl - Note the network numbers.

Network Setup

e.g.
  • Host-only: 172.16.42.0/24
  • NAT: 10.51.1.0/24
Vmware will NAT on the 10.51.1.0 network. Linux will have something like:
  • vmnet0 172.16.42.1
  • vmnet8 10.51.1.1
Next, fixup /etc/xinetd.d/vmware-authd
--- vmware-authd~       2007-10-13 13:26:18.830128814 -0700
+++ vmware-authd        2007-10-13 13:36:42.833942428 -0700
@@ -10,5 +10,5 @@
     user            = root
     server          = /opt/vmware/server/sbin/vmware-authd
     type            = unlisted
-    only_from      =
+    only_from      = 0.0.0.0/0
 }

Firewall Setup

Once you get a guest running, you discover that DHCP on the NAT network provides a gateway of 10.51.1.2. That is great for VMWare-based NAT setup. See /etc/vmware/vmnetX/nat/nat.conf to tweak the NAT settings. I wanted to use shorewall, complete with NAT and port forwarding. I installed/configured shorewall. After that, I setup the NAT and port-forwarding rules. Finally, I connected to the Guest OSs which I wanted to expose, assigned static IPs and set thier default gateway to .1 instead of .2. This effectively removed them from the control of VMware nat. And that was is awesome.