Oremj’s Blog

Updates from October, 2009

• 

  WordpressMU: changing domain names.

  oremj 12:12 pm on October 27, 2009 | 0 Permalink
  

  Unfortunately, changing domain names in WordPressMU is a manual process. It’s something I’ve come across often and have to look it up each time. Here’s what I did, so I don’t have to look it up again. Original idea from Boris Masis.

  1. Drop and run this script in the root wpmu directory:

  <?php
  define('WP_INSTALLING', true);
  require_once('wp-load.php');
  
  $old_domain = 'olddomain.com';
  $new_domain = 'newdomain.com';
  
  $query = "UPDATE wp_site SET domain = '$new_domain' where domain = '$old_domain'";
  $wpdb->query($query);
  
  $query = "UPDATE wp_blogs SET domain = REPLACE(domain, '$old_domain', '$new_domain')";
  $wpdb->query($query);
  
  $querystr ="SHOW TABLES LIKE 'wp_%_options'";
  
  $tables = $wpdb->get_results($querystr, ARRAY_N);
  
  echo count($tables);
  $query = "";
  if ($tables){
    foreach ($tables as $table){
      $query = 'UPDATE '.$table[0]." SET option_value = REPLACE(option_value,'$old_domain','$new_domain')";
      $wpdb->query($query);
    }
  }
  ?>
  

  2. Edit wp-config.php and set “DOMAIN_CURRENT_SITE” to the appropriate domain.

  That’s it, everything should work properly.

   

  Reply Click here to cancel reply.

  Name (required)

  Email (required)

  Web Site

   
• 

  Operations Status Dashboard

  oremj 10:37 am on September 21, 2009 | 5 Permalink
  

  Often when we have an operational issue or outage confusion occurs. We are taking a step to resolve this confusion by creating a status dashboard similar to Google and Twitter. It is mostly a prototype at this point. How can we make this service more useful? Feedback is greatly appreciated.

   
• 

  Efficiently Updating Web Sites on Web Clusters

  oremj 10:29 am on March 14, 2008 | 1 Permalink
  

  Recently, we ran in to a problem with our web content sync setup.

  Old Setup:

  • Host all web bits on two admin servers
  • Pull via rsync from admin01 server to the apache servers on 5 min staggered cron

  That setup worked fairly well for us for quite a long time, but it doesn’t scale. At about 18 or 20 apache servers pulling at 5 min intervals the admin server was constantly pegged from all the rsync processes scanning the file system.

  We needed something with state, but something that was simple. Revision control has state, but would the operations be quick enough to be useful? It turns out Git was pretty well suited for the task.

  New setup:

  • Host all bits on admin servers
  • Commit bits on admin01 on a 5 minute cron in to git
  • Pull commits via Git to apache servers

  This new setup scales very well, because we only need one file system scan per 5 minutes instead of 20+. The Git fetches are very fast.

  Initial installation:

  admin01:/etc/xinetd.d/git-daemon:
  
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = /usr/bin/git-daemon
server_args = --inetd --export-all --verbose /www
log_on_failure += USERID
}


  Admin01: Import /www:
  
cd /www
git-init
git-add .
git-commit -m 'Initial Import'


  Apache Servers initial setup:
  
git-clone git://admin01/www


  Commit Cron on admin01 (add any new files and delete any removed files from the repo):
  
#!/bin/bash
lockfile="/tmp/git.lock"
if [ -f $lockfile ]; then
if kill -0 $(cat $lockfile); then
echo "$0 appears to be already running."
exit 1
fi
fi
echo $$ > $lockfile
cd /www
/usr/bin/git-add .
/usr/bin/git-commit -a -m "AUTO COMMIT: `date +%FT%T`"
rm -f $lockfile

  Fetch Cron on the apache servers (fetches origin and then resets the /www to origin):

  
#!/bin/bash
cd /www;
/usr/bin/git-fetch && /usr/bin/git-reset --hard origin;