Is My Blog Working?

November 1, 2011

By nikky

Whilst dig­ging into the inner work­ings and doc­u­men­ta­tion of the nifty wp-super-cache plu­gin that the blogs net­work uses, I stum­bled upon ismyblogworking.com, which will run var­i­ous checks and give you a pretty good overview of your returns, fea­tures, and other “impor­tant stuff.” There are also quick links to val­i­date your HTML, feed, and check the raw HTTP headers.

You can view the page for this blog here:

http://ismyblogworking.com/blogs.uw.edu/nikky

As you can see, the feed is not being cached for some rea­son. Some­thing to look into!

Edit: Oddly enough, it appears the feed is being cached, but it isn’t serv­ing that to ismyblogworking.com. There may be rewrite rules some­where in the user­a­gent that are pre­vent­ing that behaviour.

Code Highlighting

October 28, 2011

By nikky

 
#login h1 a{
  width: 350px;
  height: 145px;
  background: url(http://staff.washington.edu/nikky/images/thundercats/yellow.png) no-repeat center center !important;
}
function uw_login_title() {
  return 'UW Blogs Network Home Page';
}
my $i;
$i++;

 

1

codycodecode
codycodecodye

Layout Tweaks

October 26, 2011

By nikky

There have been two updates to the default theme over the past 24 hours, both of which should enhance the user expe­ri­ence quite significantly.

The first addi­tion is the abil­ity to dis­play your blog name and sub­ti­tle over the main header image, such as is what you see with my own blog. Note that you will need to have the header image on in order to have your text prop­erly over­layed. (Thanks to the UW Web team for mak­ing this change!)

Sec­ondly, the “meta” wid­get has been hard­coded to exist beneath the page left nav­i­ga­tion. This should help users find the RSS feeds and assist admin­is­tra­tors in quickly log­ging in and access­ing their site admin­is­tra­tive interface.

Ovid Rebooted 09/14/2011

September 15, 2011

By nikky

The fol­low­ing mes­sage was sent to the mysql-users-ovid mail­ing list. Now would be an excel­lent time to sign up for it if you haven’t already.

 

[This mes­sage is being sent to mem­bers of the mysql-users-ovid mail­ing
list because you asked to be noti­fied about ser­vice impacts regard­ing
your MySQL server.]

If you are receiv­ing mul­ti­ple mes­sages regard­ing your MySQL server
reboot­ing, please read the instruc­tions at the bot­tom of this email.

OUTAGE INFORMATION
==================
Sys­tem: ovid21.u.washington.edu

Restart Date: Approx­i­mately 1:30pm, Wednes­day, Sep­tem­ber 14th, 2011

Rea­son: Sys­tem unresponsive.

Details: The web devel­op­ment server ovid.u.washington.edu, which is
attached to homer.u.washington.edu, was rebooted to fix an unre­spon­sive
sys­tem. This will impact any staff, fac­ulty, depart­men­tal, or
course Web sites that rely on a MySQL server. Sites based on Word­Press,
Medi­aWiki, Dru­pal, and sim­i­lar sys­tems will be unable to func­tion
prop­erly until the your MySQL server comes back online.

Action may be required
======================

If your MySQL server has a cron job set up to auto­mat­i­cally restart
your server, then no action is nec­es­sary; your MySQL server should be
back online. More infor­ma­tion about set­ting up a cron job to han­dle this
task can be found at this website:

http://www.uw.edu/itconnect/web/publishing/mysql-admin.html#cron

If you do not have a cron job set up, or need to start your MySQL
server man­u­ally, then you will want to refer to these instruc­tions on
how to bring your MySQL server back online:

http://www.uw.edu/itconnect/web/publishing/mysql-admin.html#restart

If you are receiv­ing Mul­ti­ple mysql.starter emails
==================================================

Some users are report­ing that they are receiv­ing emails every five
or fif­teen min­utes noti­fy­ing them that their MySQL server was
restarted. Despite the fact that the MySQL server appears to be online,
it is not report­ing its oper­a­tional sta­tus prop­erly and the
mysql.starter script is attempt­ing to reboot it.

To fix this issue, please fol­low these steps:

1) Man­u­ally kill your cur­rently run­ning MySQL server. Step one of
“reset­ting your pass­word” explains how to do this:

http://www.washington.edu/itconnect/web/publishing/mysql-admin.html#reset

2) Start your MySQL server using this command:

~/mysql/bin/mysqld_safe &

3) If these reboot mes­sages stop, then you have
fixed the issue. If they con­tinue, please con­tact us using the
details below.

–
UW Infor­ma­tion Tech­nol­ogy Cus­tomer Ser­vices
help at uw.edu
206.221.5000

Host Key Images

September 8, 2011

By nikky

A nifty fea­ture of Open-SSH is the abil­ity to dis­play an unique image that is cre­ated from a hostkey pat­tern. If you’re using SSH often, it’s very easy to add an auto­matic dis­play of it. If you’re run­ning Linux on your desk­top, just add the fol­low­ing to your .ssh/config file:

VisualHostKey yes

The basic idea of the visual key is that every time you log in, you’ll see this image and mem­o­rize its shape. If the shape changes, then you know some­thing or some­one may be attempt­ing a Man-in-the-middle attack or doing some­thing oth­er­wise nasty to the sys­tems. So for instance, I know that the SSH Key for ovid and homer looks like Scan­di­navia to me. Here’s an exam­ple of this in action:

--> [10:19] nikky@romulus % ssh ovid
Host key fingerprint is 22:c7:83:db:1c:c5:7d:10:15:23:f5:64:36:af:b5:b2
+--[ RSA 1024]----+
|          ++=.=  |
|       . . o * o |
|        o . . . o|
|     o .   .   o.|
|    o * S    ... |
|     * +      o  |
|    . o      E   |
|                 |
|                 |
+-----------------+

Here’s the key/image for dante/vergil:

--> [10:24] nikky@romulus % ssh vergil                                ~
Host key fingerprint is 3e:a9:04:66:2f:91:a4:fc:aa:6e:0e:50:48:84:e0:db
+--[ RSA 1024]----+
|=o               |
|+.               |
|... .            |
| ooo .           |
|..oE*   S        |
|.  + + . .       |
|.   o o +        |
|.. . o . .       |
|=+.   .          |
+-----------------+

I haven’t really decided what this one looks like, but the “ooo” pat­tern and “…” right above it is a lit­tle unusual, so that may be the marker I look for.

As a reminder, if you ever get a notice that the hostkey has changed or your SSH pro­gram sends you a very nasty-looking error mes­sage, DO NOT ENTER YOUR PASSWORD and con­tact us. This change may have been as innocu­ous as a new server being brought online with improved secu­rity cer­tifi­cates, or may be a rogue sys­tem that is inter­cept­ing your con­nec­tion. It’s always a good idea to check with us.

When .htaccess files go wrong

September 7, 2011

By nikky
The free game with every graph­ics card deal has finally back­fired for AMD and Code­mas­ters. Due to a lack of .htac­cess, 1.7 mil­lion keys for a free copy of DiRT 3 on Steam have been leaked.
 

Seems like a fairly good reminder of how impor­tant .htac­cess files are in pro­tect­ing crit­i­cal infor­ma­tion online. Just because you don’t pub­li­cize the file loca­tion doesn’t mean some­one can’t find it. Always protect!

Source: Slash­dot

Drupal Documentation Updated for 7.7

August 24, 2011

By nikky

The IT Con­nect Dru­pal Instal­la­tion Doc­u­men­ta­tion has been updated to reflect the lat­est changes to the Dru­pal install process. The issue with .htac­cess files no longer ship­ping with the sites/default/files is still occur­ring. For now, I’m rec­om­mend­ing that you should edit the .htac­cess file man­u­ally if and when these issues occur. It’s not entirely clear when Dru­pal is cre­at­ing this file.

Revenge of the Load Charts

August 22, 2011

By nikky

If you haven’t guessed by now, I love load graphs. They’re inter­est­ing and can often reveal oth­er­wise hid­den aspects of a server. We’ve had a lot of inter­est­ing events hap­pen recently on our uni­form access sys­tems, and there’s noth­ing to wrap all of those up with a recap involv­ing load graphs!

Aesop01 Reboot

One our file­servers, aesop01, was taken down at 6:30am this morn­ing for brief hard­ware main­te­nance. This sup­ports the /rc11 and /rc12 file sys­tems, which is about half of our Unix home direc­to­ries. The down­time was brief, and MySQL caches any calls until the filesys­tem returns, how­ever, this also gen­er­ates a large amount of load as MySQL tends to freak out when the filesys­tem sud­denly stops respond­ing. Let’s take a look:

All them MySQLs freakin’ out

As all of those MySQL processes are on hold, it also holds up the depts servers to a cer­tain extent:

Depts are patiently await­ing MySQL

This was a brief ser­vice impact and should resolve the out­ages we’ve been expe­ri­enc­ing over the past few weeks.

The “Blip”

Much like the bloop, we some­times see “blips” that just ran­domly appear and just as quickly dis­ap­pear. Here we see the courses servers sud­denly uptick between 1am and 2am:

 

The nor­mally sta­ble courses servers sud­denly uptick for an hour.

Now the weird part: a few hours before the response time for courses01 sud­denly jumped from ~10ms to ~30ms for two hours:

As sud­denly as this shelf appears on courses01, it sud­denly dis­ap­pears. But wait! A few hours later, this sud­denly appears on courses02:

 

My the­ory for this one is that there was a web spi­der that was hit­ting a page on courses that was gen­er­at­ing unusual load patterns.

Ovid21 shell forking

Some­times, even the folks in IT mess up. I was expe­ri­ent­ing with some ksh and zsh con­fig­u­ra­tions, and man­aged to get into a shell loop, where a ksh shell would imme­di­ately launch zsh, which would imme­di­ately launch ksh. 3000 shells later, I man­aged to stop the process, but not before giv­ing ovid a good thrashing:

Cre­at­ing 3000 threads

Luck­ily this was a very brief impact.

File­server par­tial outage

I’m pretty sure I saved some load charts from one of these occur­rences, but I can’t find them in my usual place. I could man­u­ally gen­er­ate them again, but I don’t have time for that right now. I have a ‘find‘ com­mand scan­ning my drive for a likely name, so there’s still hope I saved it in some unusual location!

Cronjob and Full Paths

August 22, 2011

By nikky

tl;dr: Run­ning cron­jobs with scp fails. Use “/usr/local/bin/scp” instead.

Longer Ver­sion:

A par­tic­u­larly vex­ing and not all-together intu­itive issue is that a com­mand that works per­fectly fine in your ter­mi­nal, such as ‘scp file.txt nikky@otherhost.cac.washington.edu:~,‘ fails when put into your crontab on a Uni­form Access sys­tem with the mes­sage of “Scp: com­mand not found.”

This is a result of the fact that the cron dae­mon doesn’t have the scp loca­tion in its path. scp is located at “/usr/local/bin/scp,” which you can find your­self using the “whereis” com­mand, like such:

--> [9:12] nikky@ovid21 % whereis scp                                         
scp: /usr/local/bin/scp

The solu­tion? Replace “scp” with “/usr/local/bin/scp”

So this: scp file.txt nikky@otherhost.cac.washington.edu:~ becomes this: /usr/local/bin/scp file.txt nikky@otherhost.cac.washington.edu:~

 

« Previous Page — Next Page »