Everybody Staze...

Nobody leavz...

  • Home
  • About Me
    • LinkedIn
    • Lab
  • Contact
  • Links
  • Reviews
  • Sitemap
  • Weather
You are here: Home / Archives for Coding

Missing OD Attributes

2009/09/18 By staze

A while back, when 10.5 first shipped, my boss and I were intrigued by iCal Server. And after getting it going, we found that for some reason, we couldn’t set a calendar server for our users. We’d set the calendar in Workgroup Manager (WGM hereafter), hit save, and right after that, WGM would uncheck the box, and set it back to none. Something was weird with our accounts. My boss deleted his account and recreated it, and that fixed it. So, the problem was obviously something with the “old” accounts on the system (e.g. the accounts that had been migrated from 10.1 -> 10.2 -> 10.3 -> 10.4 -> 10.5. Some attribute didn’t get added.

At first glance, the obvious missing one was there was only one authAuthority entry in our user accounts. Just the ApplePasswordServer entry, no Kerberosv5 entry. And deleting and recreating his account remedied that. So, I put it on the back burner because we figured out that iCal Server was kinda buggy, and later found out that the iPhone couldn’t write to it, just read (no good). When 10.6 was announced, and we heard that iCal Server 2 supported read/write from the iPhone (with version 3.x+ of the iPhone software), I started thinking about it again. So, I looked at the attribute, and figured out that a single “sed” would create the attribute I needed. So, I coded up this. And figured, problem solved.

Alas, it was not. While testing a migration of 10.4 email (cyrus) to a 10.6 server (dovecot) using the migrate_mail_data.pl script, I noticed at the end, the script renames the imap spool folders after the user’s UUID. It failed to rename them for several users (like me) because we didn’t have a UUID. Then it hit me, iCal Server’s URLs contain the UUID for the user. No UUID, no iCal Server calendar. DOH! So, I took the Kerberos script, changed it a bit (using uuidgen), and batch added UUIDs for all the users that didn’t have them (Script here. Re-ran the migrate_mail_data.pl script, and viola, all the spools got renamed. Now, I’m not sure if this really fixes the iCal Server 1 problem, since I don’t have an iCal Server set up, but iCal Server 2 works (though, it works differently, so this issue doesn’t occur). I also got word from a bug I filed about the initial issue, that Apple thinks 10.6 fixed it, so I’d imagine when you upgrade your OD server to 10.6, it adds missing attributes.

More later, work related. Thought I should keep topics distinct.

Filed Under: Coding, Sys Admin Tagged With: 10.6, authAuthority, GeneratedUID, iCal Server, Kerberos, Open Directory, UUID, uuidgen

Moving wordpress tables

2009/08/22 By staze

This also applies to renaming table prefixes within the same database.

Previously on my server, I had 3 databases that I used actively. One for this website, one for another, and one for my power/gas data. The two websites are both wordpress.

So, just a few moments ago, I consolidated those tables into one database. I had to change the table prefix for one of the sites so both sites tables could coexist within the same database (and not have collisions). After changing the wp-config.php to reflect this change, the site loaded up. The problem is, I tried to go into the admin page, and I get “You do not have sufficient permissions to access this page”.

A lot of the info on the wordpress site doesn’t really cover this issue. Luckly, this does. Basically, you need to go into the “usermeta” table, and change the “meta_key” values from the previous prefix_capabilities, and prefix_user_level, to the new prefix_capabilities and new prefix_user_level. Then go into the options table and change prefix_user_roles to the new prefix_user_roles.

Once that’s done, things should work. You can certainly use the SQL statements he has on his site, but I had a hard time following what he was saying. So, I did it by hand once I figured it out.

Thanks very much, and hopefully I’ll have more later tonight or tomorrow.

(p.s. Sorry about the quality of the camera image. I’m working on it…)

Filed Under: Coding Tagged With: moving tables, MySQL, Wordpress

MySQL geekout

2009/08/14 By staze

So, I’ve spend the last week or so adding some new features to the site. Mainly for my power usage, but you’ll also notice gas usage info now.

Anywho, to do all this, I’ve been digging into MySQL, which until now I knew enough to do a "select * from table where id=x". I knew really nothing about query optimization, how to find out how long a query took, etc.

So, after some reading, I find out about “explain”. Okay, so I start looking through queries, and digging around for answers.

First, I’ll say the system MySQL is running on it a G4, 1.67ghz. 2gig of ram, and mysql’s main settings are:

skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
thread_cache_size = 8
query_cache_size = 16M
myisam_sort_buffer_size = 64M
thread_concurrency = 2
skip-thread-priority

Now, I am sure these aren’t ideal… but it’s what I’ve gotten based on one of the template my.cnf files, as well as some googling.

Examples: 200k row table. Each row has 8 columns. One primary key on id, and another index on datetime.

Query 1: "select datetime,kw,temp from power where date(datetime)=20090802;"
Query takes, 0.28 seconds, returns 1440 rows. Explain tells me it’s doing a simple “where”, looking at 200k rows, but that it’s not using a key, or index. Hmm… okay.
Query 2: "select datetime,kw,temp from power where datetime >= 20090802 and datetime < date(20090802 + interval 1 day);"
Query takes, .03 seconds, returns 1440 rows. Explain tells me it's also doing a where, but it's using the datetime index, and only looking at 1363 rows (no idea why that's less than 1440). Huh.

So, question. Why is MySQL not smart enough to realize that the first query should be equal to the second? Who knows... lot of people ask the question online though, why "date(datetime)" doesn't use the "datetime" index. *shrugs*

The other issue I ran into is finding all the dates in the table, in a way that first finds years, then months for those years, then days for those months. Previously, I was doing three queries against the 200k row table, that went something like:

"select distinct year(datetime) from power;"
"select distinct month(datetime) from power where year(datetime)=$year;"
"select day(datetime) from power where month(datetime)=$month and year(datetime)=$year;"

I can hear you cringe from here. It's horrible, but it worked. Each query obviously looked at all 200k rows, and took anywhere from .6-.8 seconds.

So, needless, all three of those took about 2-3 seconds to run, concurrently. ugh. So, what to do? I couldn't think of a good way to speed those times up much with just the one 200k row table, so, I created another table. This table simply holds dates (in date format, as well as year, month, and day), and then daily summaries. So I can easily grab data from this table with either a full date, or just the year, month, or day. I then have indexes for date, year, month, day, and (year,month). Now, when I do the above queries (without the year(), month(), or day() functions) I get results in basically 0.00 seconds (that's what mysql tells me anyway. So, all three running results in basically an instant set of days, months, and years. So, the archive page for power loads all but instantly now, where it used to take a couple seconds.

Back when I first switched to mysql, I figured I was going to have to do this, since it just seemed the logical way to do it. I had a table already set up, I just wasn't populating it (I need to figure out triggers now, so maybe I can have mysql do the population on its own). And ultimately, it's how I handled my flat file setup before. There was a "history" file, and then individual day files. *sigh* Takes figuring something out manually in order to kick someone out of being lazy. I mean, with 200k rows, it was being slow. What happens when I have a year worth of data (about 526k rows). Where, a year worth of data in this summary table is only what, 365 (so, one would expect queries to be about 1500x faster, if things worked linearly) rows?

So, that's it. That's what's kept me busy the past few days. I still have some more stuff I want to add, but I'm pretty happy at this point. Things are faster, and all and all, my server shouldn't come crashing down now when google spiders my site. =)

Have a great weekend. Hopefully I'll post more by Sunday.

UPDATE:
Just made a change to the daily graph system. Since my work yesterday, it was not easy to get to todays power usage info, because the dateselect.php was grabbing info from the summary table, which only contained days in the past. I've just changed how that table is updated. Now, nightly, the previous days row is updated, and the current day is added to the table with just the date, year, month, and day. So, it'll now show up in the dateselect. I think, now that I think about it, I'm going to add a link to the front page for todays info.

More later.

Filed Under: Coding Tagged With: MySQL

« Previous Page
Next Page »

Weather

Categories / Archives

  • Apple
  • Coding
  • Electronics
  • Energy
  • Home Ownership
  • Miscellany
  • Politics
  • Prius
  • Sys Admin
  • Travel
  • Uncategorized
  • Work
  • June 2026
  • April 2026
  • August 2025
  • April 2025
  • January 2024
  • February 2021
  • July 2020
  • January 2020
  • April 2019
  • March 2018
  • February 2018
  • June 2017

Copyright © 2026 · Staze On Genesis Framework · WordPress · Log in