Orez Praw

• AMD Athlon "Thunderbird" system with matching parts computer (one works, one doesn't).
• Dual P3 600Mhz Katmai system with 20GB hard drives and SCSI tape backup.
• Dual AMD Athlon system without case, with 8 15000 RPM SCSI hard drives.
• 17" computer monitor: very high quality, top of the line Samsung CRT.
• Monitor for IBM RS-6000.
• 30" 4:3 Samsung HDTV with HD Tuner.
• Inkjet printer, unknown condition.

If you are at all interested in these things, please send me an e-mail with the link above.

PDF Slides

NARAL didn't have a nice handy link this time, so I'm reposting their email here:

Contact the House Judiciary Committee Today!

The House Judiciary Committee heard Senator Dan McGee's (R- Laurel) SB 46 today, and is expected to hear SB 406 soon. Both are extreme constitutional amendments which would have devastating consequences for Montana women and families.

SB 46 and 406 would amend the Montana Constitution, eliminating privacy protections that have been in place in Montana for nearly 40 years. SB 46 seeks to amend our constitutional right to privacy to give the state a "compelling interest" in the protection of the unborn, and SB 406 seeks to redefine personhood in our state constitution as beginning at fertilization, a bill identical to the failed initiative CI-100.

These amendments would insert the government into every pregnancy and undermine private medical decisions made between a woman and her doctor.

Let's light up the Capitol switchboard with Montana's pro-choice majority!

You can leave a message for the entire House Judiciary Committee by
calling: 406-444-4800.

Use our phone script when you call:
"I'm a Montana resident and I'm calling to urge the members of the House Judiciary Committee to oppose SB 46 and SB406, two extreme constitutional amendments which would have devastating consequences for Montana women and families".

We cannot let our anti-choice opponents be the only voice that our legislators hear from. We are counting on you to demonstrate that amendments like these have no place in a state that values freedom and privacy.

And, let's not forget, this amendment will do nothing to reduce unintended pregnancies in Montana or support women who carry a
pregnancy to term.

Please help us flood the House Judiciary Committee with calls to let them know Montanans do not support divisive attacks on women's right to privacy!

Call 406-444-4800 today, and say "NO" to SB 46 and 406!

Someone else's thought's on it:
http://wulfgar.typepad.com/a_chicken_is_not_pillage/2009/02/handmaids.html

My previous post on the issue (before it made it through the Montana Senate): http://orezpraw.com/blog/montana-sb-46

The Rube Goldberg machine that is Debian's default ACPI suspend system is truly difficult to debug, let alone understand. It involves a variety of daemons, scripts and commands interacting in complex and redundant ways. Disabling one "feature" took me hours.

I have a Dell Latitude D620 with nVidia graphics (the following may not apply to systems with Intel graphics) with Debian 5.0 (Lenny) and both Gnome and KDE installed. With the default configuration, the laptop cannot correctly wake the display after being slept (ACPI S3 suspended). Fortunately, I've had this laptop for a while and could guess that the problem was that vbetool was being called to save/restore the video state. This laptop only resumes correctly when vbetool is not called. So, to disable vbetool, I edited the /etc/default/acpi-support file and set:

SAVE_VBE_STATE=false
POST_VIDEO=false
SAVE_VIDEO_PCI_STATE=false
USE_DPMS=false

But of course, the system still doesn't resume correctly. In my paranoia I decided something must still be calling vbetool. I hunted down the scripts that actually read these settings, pm-suspend. When I ran pm-suspend directly from the console, however, the computer resumed fine.

Then I decided to follow the chain of events from when the power button (I prefer this to the sleep button) is pressed to determine if pm-suspend was really being called by the button press. The sleep-button-pressed event is received by acpid and then sent to the X server via a shell script. The power-button-pressed event is received by acpid and the X server directly. acpid executes a maze of shell scripts which results in powersaved, or the X server receiving the event. kpowersave or gnome-power-manager receives the event from the X server.

Until I set EVENT_BUTTON_POWER="ignore" in /etc/powersave/events, both actions were executed at once and the computer tried to shut down and sleep at the same time. Afterwards, I was unable to reproduce this problem. It seems that if kpowersave/gnome-power-manager are running, acpid prefers to send the event to them but this doesn't seem to be 100% reliable.

If none of the daemons are running, acpid falls back to its scripted behavior which shuts the system down or asks KDE to shut the system down in the case of the power button. Alternately, in the case of the sleep button, it calls /usr/share/acpi-support/suspendorhibernate which checks /etc/default/acpi-support's SUSPEND_METHODS setting. By default this is SUSPEND_METHODS="dbus-pm dbus-hal pm-utils".

The dbus-pm method tries to contact gnome-power-manager to handle the suspend request, as configured in /usr/share/dbus-1/services/gnome-power-manager.service. If that fails, and it should because acpid should have already determined that gnome-power-manager wasn't running, suspendorhibernate falls back to the dbus-hal method. This method is the same that powersaved, gnome-power-manager, and kpowersave all eventually end up using internally anyway, by requesting via dbus that hal suspend the system.

If this method fails, for example if dbus isn't running suspendorhibernate calls pm-suspend directly.

If a daemon receives the suspend event or keypress, powersaved, kpowersave, or gnome-power-manager looks in its configuration and finds that you would like the system to sleep. So, it attempts to send the sleep request to hal via dbus. Note that you have to be in the powerdev group to have permission to do this, otherwise nothing happens at all.

Then, finally, as defined by /usr/lib/hal/scripts/linux/hal-system-power-suspend-hybrid-linux, hal calls pm-suspend. However, hal calls pm-suspend with command line arguments that override the settings in /etc/default/acpi-support. These overrides are controlled by hal's own property system. These properties are:

  power_management.quirk.vbe_post = true  (bool)
  power_management.quirk.vbemode_restore = true  (bool)

So, how do we disable the hal properties? Trying

sudo hal-set-property --udi /org/freedesktop/Hal/devices/computer --key power_management.quirk.vbe_post --bool false
sudo hal-set-property --udi /org/freedesktop/Hal/devices/computer --key power_management.quirk.vbemode_restore --bool false

allows the system to resume properly. Until, that is, I reboot, at which point hal forgets those properties. So, we must put something like:

<deviceinfo version="0.2">
  <device>
    <match key="power_management.quirk.vbe_post" bool="true">
       <merge key="power_management.quirk.vbe_post" type="bool">false</merge>
    </match>
    <match key="power_management.quirk.vbemode_restore" bool="true">
       <merge key="power_management.quirk.vbemode_restore" type="bool">false</merge>
    </match>
  </device>
</deviceinfo>

And, in the end, pm-suspend does cat mem >/sys/power/sleep, which works perfectly fine all by itself on my laptop.

From NARAL Montana:

Tomorrow morning, state Senator Dan McGee is having a hearing on SB 46,
an amendment to eliminate the right to privacy for pregnant women in
Montana. If this amendment passed, the state would have an interest in
every pregnancy whether a woman chose to access abortion care, had a
miscarriage or stillbirth, or was making decisions around pregnancy care
and birth.

I hope you will join us in asking Montana's Senators to vote "no" on
this dangerous amendment by clicking the link below.

https://secure.prochoiceamerica.org/site/Advocacy?cmd=display&page=UserAction&id=3471

Here is what I wrote:

One of the things I love about Montana is Montana's privacy protections. I demand that my privacy is protected in every aspect, including this one, and I am willing to vote for whoever will protect my privacy. I know that even though I am not female, laws like these can easily intrude on my own rights.

Here is what my Montana friends say about SB 46,

(05:07 PM) A: what the fucking shit
(05:07 PM) A: who is this asshole?
(05:07 PM) A: and how do I personally tell him to STFU?

(05:07 PM) B: Uhh...
(05:07 PM) B: what the sweet fuck

I agree with these sentiments. Furthermore, I would like to remind Dan McGee that when he begins to violate the privacy of others with laws like this, very soon his privacy will be violated by the law too.

I would also like to remind the supporters of SB 46 that when he imposes on a woman's health and right to choose that it affects everyone in the state negatively. Sickness is never good for a community, and neither are unwanted children.

Increased access to birth control, reproductive healthcare and accurate sexual education is UNAMBIGUOUSLY NECESSARY for any healthy community.

Update: I received the following reply almost immediately from my Montana senator, Ron Erickson:

Hi Joshua,
Though I would not put it exactly in your friend's language, I agree
that SB 46 is a terrible bill and I will vote against it.
Ron

Oh, look at all the little XMLs running around in the yard!

I wrote a patch to help LoudTwitter and b2evolution 2.4.6 play along together. Once you apply the patch you must configure LoudTwitter to use XML-RPC with an endpoint URL like http://orezpraw.com/blogs/xmlsrv/xmlrpc.php?blog=6. Instead of "6" you should put the ID of the blog you wish LoudTwitter to post on.

The problem was that LoudTwitter didn't specify a blog ID. This patch lets you override the blog ID with the standard b2evo GET/POST/COOKIE method, and if none of those are set falls back to the XML-RPC specified blog ID. The patch also fixes some brain-dead XML-RPC error reporting code in the same file that threw away the actual error message.

SpamAssassin, a wonderfully useful and effective product, contains a module called AutoWhitelist (AWL). The idea behind AutoWhitelist is to use a sender's SpamAssassin score history to improve scoring consistency. Unfortunately, it doesn't work as expected. Note that not all anti-spam packages mean the same thing by "auto-whitelisting," so this only applies to SpamAssassin.

From the SpamAssassin Wiki:

In short, the AWL is a score averaging system. It keeps track of the historical average of a sender, and pushes any subsequent mail towards that average.

More precisely from the SpamAssassin manual:

Senders are tracked using a combination of their From: address and their IP address. It then uses that average score to reduce the variability in scoring from message to message and modifies the final score by pushing the result towards the historical average. This improves the accuracy of filtering for most email.

Unfortunately it doesn't quite work like that. The biggest problem is that most email is spam and spammers use random IP addresses and often random From addresses. I tracked the AWL's effect on 411 spam messages, 7 (2%) of which AWL actually recognized because it had never seen remaining 411 message's IP/From combination before, rendering AWL useless. During the same period AWL recognized 6 (67%) of 18 ham messages. It is easy to see that AWL was doing nothing for the vast majority of mail coming to my account because almost all of it was spam with random IP/From addresses.

Another problem is that there is no limit to how far AWL can affect a spam's score. The module does allow you to reduce the amount that it affects a message's score from the default final score for a message being 50% historic mean for that sender and 50% current score from rules, to anything you want such as 10%/90%. However, there is no hard upper limit. I believe this is dangerous because given one message from a sender with a score of 30 and one with a score of 0, plausible scores, the default configuration will move the score 15 points across a threshold that is usually set around 3 or 5 points.

SpamAssassin does a lot of work to balance their rules, giving more accurate rules a larger point value. However, when AWL changes a message's score it typically has much more sway over the final score than any other individual rule, including Bayesian classification which I will discuss later.

The third problem is that the IP and From address pair doesn't guarantee that a sender is who they say they are. From the SpamAssassin Wiki:

A "sender" is identified using both the address they sent with, and their IP address, so spam claiming to be From you with forged headers will fail to get through.

Between open relays, insecure and broken servers, and IP spoofing, this simply isn't true. In fact, AWL creates an opportunity for a hacker to artificially change the classification of a legitimate sender. A message that SA rules will classify as a 30 point spam is easy to construct and all the hacker has to do is send a significant number of them with the real sender's IP and From address. For servers that do not deliver, reject or delete spam with a score over a certain threshold, this is a denial of service attack. Only cryptographic signatures can hope to protect against forged headers.

Configuration, ruleset, and rule debugging is more difficult with AWL. If a bad rule is introduced that scores valid messages as spam it could take months for it to push the score history far enough for the user to notice and have the problem fixed. Though debugging is still possible, it is delayed and inconvenient because the configuration changes are no longer fresh in the administrator's mind.

The fifth problem is that AWL and SpamAssassin's Bayesian classifier don't get along very well, especially when one's Bayes database is new. By default, and this is quite sensible, SpamAssassin disables Bayesian classification until it has examined 200 ham and 200 spam messages. The Bayesian classifier is very good at deciding whether or not a message is spam. When the 200 message thresholds are reached, it turns on and improves the accuracy of message scoring. However, since the AWL has been recording scores since before Bayes was enabled, it immediately starts working against Bayes. Though this effect will diminish over time it is not helpful unless you do not trust Bayes, in which case you should increase the thresholds or disable Bayes anyway.

Finally, Bayesian classification is simply better at doing what AWL is supposed to do. Since Bayes looks at the whole message, not just the IP and From addresses, it can use the history of a spammer with a static IP but random From addresses or the history of a spammer with random IPs but a static from address. Bayes primarily excels at identifying spammy content, however, which is much more important. Content is how a user determines if a message is unwanted or not. No matter who is sending the spam, if it is at all familiar the Bayesian classifier will mark it as such. Additionally, Bayes has a strictly limited effect on message score, unlike AWL.

Lakota Data took over the colocation facility where this blog is hosted on Tue, Aug 19, 2008 at 12:03 PM, with the following e-mail:

To whom it may concern:

We are pleased to announce that Lakota Data Center LLC is now managing facility in Suite 330 for NSN Data Center LLC (both companies wholly owned by Marie E. Collins). The continuity of ownership and technical assistants (with the exception of Linn Boyd), along with the improved organization and response time will enable us to build an even stronger and expanded data center. This change has also given us the opportunity to add more layers of redundancy and form strategic alliances which will better serve our customers.

NSN Data Center LLC is the legal less or of the data center located in suite 330 of the Binz Building at 1001 Texas Avenue under a ten year lease that began in 2006.

As of July 15th 2008 Linn Boyd is no longer employed by NSN Data Center LLC and Zogmo is no longer licensed to occupy (or conduct business in) the NSN Data Center or use any of the equipment (generators, UPS, risers, diesel, etc) or any of the utilities paid for by NSN Data Center or Marie E. Collins.

We look forward to continuing to provide our professional level of services in the Lakota Data Center.

Sincerely

Marie E. Collins

The exchanges I had with with the people who now owned the building were immensely unprofessional. For example a few hugely unprofessional and downright scary exchanges with them such as them demanding "Federal" sales tax or a "Federal" sales tax form, and my social security number in order to be exempted (I'm a Montana resident). In addition, they raised their rates by 11%, and my server began being suffering from intermittent power failures.

Their business invoices come from some mickey-mouse Quicken service which is impossible to understand. For example, billing periods are just "October" not "October 10th-November 10th".

They managed to completely mangle my address somehow, completely losing the suite number and multiplying the street number by 100. They then proceeded to email me angrily because I had not sent the forms that they had sent to someone else back in.

Three days ago they sent me an invoice for almost $300. I had sent them a check for $200 only two weeks previously and it was cashed and on my bank account by October 28th. I sent an email asking them to check their records, as this was obviously a mistake. Three days later I had received more generic invoices (specifically for an Invoice 2002, October and November, the Invoice number I had written on the cashed check), and

Joshua,

That will be fine after the account is brought at least current. The account is almost 3 months in arrears. Please call me later or email a Credit card that I can post the balance.

Best Regards,

was the only response I received from a human being, which I replied to patiently requesting that they check their books. Lakota Data Center did not reply to that and certainly not with threats of disconnection.

Today they shut off my service.

As you can imagine, I was more than a little upset. Then, after I get an angry phone call and interrupt my homework to deal with the situation I only get Lakota claiming that

I have sent you emails and made several calls to your office with no response. Unfortunately, since no payment was made today, this was our only recourse.

This is blatantly false, although I can imagine them losing my phone number just like they did my address. However, since their invoice system reaches my email address regularly I know that they have it.

Additionally they now claim, in the face of the evidence of my canceled check, "Invoice 1009 was for Aug. and Sept. The payment that I received and post on 10/17/08 posted against those. Invoice 2002 is for Oct. and Nov. and as we are almost at the end of the month, this was the only option that I had." Remember that I had written "Invoice 2002" on said check. Note also that "Lakota Data Center" did not even exist until late August. Additionally, at the time of their take-over I was current with the previous owners through September 12th. I told them this and I told them that I would not double-pay in an August 23rd email. There seemed to be no issue with this until now, and they continued sending me invoices for October and November, which I paid, and not for August and September.

Of course my last host only threatened to call the FBI on me because I was attacked, but that's another story.

On Wednesday I sent an email congratulating my Montana house district representative. She replied with a very awesome email:

Thanks, Joshua. I am glad to know you are out there and active. Wasn't it thrilling to hear the words 'gay and lesbian' repeatedly roll off the lips of Obama in his speeches? I was a delegate to the Democratic Convention and was very hopeful that he will be very helpful at the federal level in moving a number of the issues forward.

But the Montana legislature looks grim. The R's strongly in control of the Senate and the House tied, which means most bills will did on a tie vote. I have been there before.

At next week at the Caucus meetings, Sen. Christine Kaufman and I will probably figure out what bills we will try this session in the face of the numbers. Please stay in touch and thanks for your support.

- Diane Sands

This collection of links was posted on my girlfriend's blog:

The Department of Health and Human Services Moves to Define Contraception as Abortion

Senators Clinton and Murray Call on HHS to Stop Plans to Obstruct Family Planning Services

Hillary Clinton's Blog Post on Huffington Post: An Outrageous Attempt by the Bush Administration to Undermine Women's Rights

Petition Against the Department of Health and Human Services' Proposal (link can also be found at the end of Hillary's blog post)

I would like to thank the current administration for trying to create more unwanted children, undermine family planning, and hurt rape victims even more. But especially poor rape victims.

I've been hearing some hype about filesystem alignment. Hype from companies like ESX and EMC. So I did some research on the whole alignment issue (including doing a hex dump of a couple of ext2 filesystems). It seems to matter sometimes, but not as much as you might think.

As far as windows goes... it seems to be a complex subject. There is some confusion as to whether it's even possible to really align NTFS -- it may have weird internal offsets rendering this exercise pointless. However, all the online ricers are doing it. I seriously doubt that any alignment above the NTFS chunk size will matter.

Alignment has no effect on Linux unless you are making partitions on top of a RAID or VMWare device. Alignment has no effect when a RAID device has only a single filesystem on it with no partition table.

Ext2/3 can't really be sensitive to alignments any larger than it's own block size, period. Multiples of the block size specified at creation (usually 4KiB) due to their layout, so making 64 (32KiB) the start sector is as good as it gets for all ext2 partitions no matter what they are on. I suspect this to be the case for other Linux filesystems as well, possibly including GFS.

Note that none of this is really related to the ext2 stride option: this option is completely independent of FS alignment. It merely tries to prevent all of the inodes from ending up on a single disk of a RAID array. As an
example failing to do this could make all of a "find" or "ls" do I/O to only one of eight hard drives in a RAID 0. It only adjusts the distance between inode tables. It actually breaks alignment of block groups on purpose.

With VMWare there are so many potential layers in between the filesystem and the physical disk (including raid usually) it seems very reasonable to perform alignment as a misaligned block read would double quite a few CPU operations in complex setups, but again I seriously doubt the validity of any alignment bigger than the filesystem block size.

pvcreate --metadatasize will help with this but note that it pads up to the next 64KiB boundary so you want to put --metadatasize 255K rather than 256K if you want a 256KiB start alignment. pvs -o pe_start will display the current alignment. But again, the default 64KiB alignment should be ample for filesystems because its larger than the filesystem blocksize. I wouldn't worry about anything that's an LVM PV not on a DOS partition table, their minimum alignment is 64KiB (128 sectors), the same alignment that EMC/ESX recommend. If the LVM PV is on a DOS partition table, then I would align that PV's start sector.

Remember with LVM that your benchmarks aren't on even ground until you set the read ahead of the LV to the same as the RAID device, and linux doesn't do this for you. man hdparm.

Additionally if the raid stripe size is weird and not a multiple of the filesystem block size (usually 4KiB) it might be a good idea to use the least common multiple of both 4iK and the stripe size as the alignment.

In the end, the only time this is worth worrying about is when you are using a DOS/MBR partition table above a RAID or VMWare device. In that case I think setting the start sector with fdisk to 64 instead of 63 is valid, but 128 is
unnecessary. However EMC seems to like 128, and I would hope they know what they are talking about, and the 32KB waste is worth nothing on modern hard drives.

YMMV.

The details of the much-hyped and secretive big scary DNS flaw is out. The man who discovered it, Dan Kaminsky, succeeded in his stated objective: waiting until all major vendors released patches (except for DJB, which was already secure) before releasing the details of the exploit. He did this despite the fact that the exploit was a simple combination of existing exploits and the fact that he pissed everyone off. But that isn't nearly the stupidest thing about this whole debacle. This exploit is being touted as a design flaw in the DNS system itself.

But it isn't.

This attack depends on spoofing DNS responses from authoritative namesevers. The part of the attack that doesn't involve bailiwick trickery was well known previously but not considered as harmful because it was a race; yet it still poisoned DNS caches by spoofing responses from other nameservers. If the attacker can guess the transaction ID and source port first, he wins.

Doesn't this sound familiar? In fact its almost identical to a huge number of other attacks such as TCP sequence prediction attacks. DNS is an application layer protocol, and TCP is a transport layer protocol. So, how can they be affected by such similar attacks? The design flaw here isn't in the DNS system, it's in a much deeper system: your network.

The most effective way to prevent this attack is configure your routers so that people can not spoof the IP address of upstream DNS servers. Period.

If you run a network which allows packets to misrepresent which side of a router they originate from, then yes, you are vulnerable, especially if the wrong side has a faster network than authoritative nameserver. If you run a network which connects to other networks that allow this, then yes, you are vulnerable. Unfortunately this happens to include the internet, so we're stuck trying to squeeze out every last bit of protection against birthday attacks that should be useless in the first place.

This is a test of the blogosphere software on the blogosphere.