I'm reposting the work related stuff from my old blog, in reverse order. Now I can use the personal blog for personal stuff and this one for sysadmin/work stuff, and the two don't have to intermix.
This means that rather than posts getting pushed onto the stack, they're being enqueued, but the all-powerful google will still index them and make them searchable. Also, I'm making sure that the "new" old posts are tagged.
:wq
Scanning through the logs as they went flying by today, two of the scariest lines I've seen in a long time went flying past:
fileserver: 2009-Nov-25 17:29:08 ufs:
[ID 879645 kern.notice] NOTICE: /usr: unexpected free inode 1147, run fsck(1M) -o f
fileserver: 2009-Nov-25 17:29:13 ufs:
[ID 879645 kern.notice] NOTICE: /usr: unexpected free inode 1145, run fsck(1M) -o f
Now, /usr is important for any system, but a primary file server isn't something we can just take down for an hour to run fsck a couple times. Especially the day before a long weekend. So, how to fix this? Sun helpfully recommends rebooting into single user mode from alternate media (actually, `boot net -s` from the openboot prom, but good luck getting that to happen on a thumper), so the Sun docs are out.
Or are they? Squirreled away in the See Also section of the fsck(1M) man page is clri(1M). This little utility should clear out the data with zeroes and release the inode back into the free list. This is (almost) exactly right, as it will just delete the offending files. But...there are important things in /usr, so what are those inodes supposed to be?
There's an app a utility for that. ncheck(1M) will look at the disk and generate a list of pathnames from inode numbers or inode numbers from pathnames. I had already generated a list of suspects from the errors running `find` on /usr, but it's good to have confirmation.
fileserver# ncheck -i 1145,1147 /dev/md/rdsk/d20 /dev/md/rdsk/d20: 1145 /bin/hd 1147 /bin/hdadm
`ls -i` confirms that these indeed do map to these inode numbers, but ncheck is more complete in that it shows all the hard links to each file. So, now that I know the names of what I'm missing...what am I missing? These are symlinks into /opt/SUNWhd/hd/bin for the thumper and thor hard drive utilities hd and hdadm. The SUNWhd package installs them, so whenever triage is done, it's probably best if they are put back. Thankfully, they're just symlinks.
So, I don't need the data. The only problem with clri is that it won't muck with the directory listing for the file. That's not so much a failing of clri as a bonus (do one thing: clear a file), but if the directory isn't cleaned up, then fsck will fail just as hard. It may even try to undo all my hard work, and we can't have that. In a fit of insanity, I tried pulling up the directory in ed to see if I could do anything with it (it's just a file like everything else, right?), but that way lies even more madness. There must be a tool somewhere to do this (and be less prone to hunan error).
Back to the man pages, and I ran across fsdb(1M). It looks fairly useful, as it lets you debug the file system. If this is anything like gdb (and it slightly resembles it), this includes displaying various values, as well as editing them. But, the man page is very vague and doesn't give any indication of how to actually use it.
Enter the google. fsdb is a wrapper around the file system specific debugger, so the actual relevant man page is fsdb_ufs(1M). The syntax is based on something called adb, which looks like a horrible thing to program in. And I've written brainfuck before (editor's note: don't ever write anything in brainfuck).
So, the next step is to grab a test box and learn how to use this debugging tool. I hear tales on the intarblag that there is a zfs version, too. But for that, I could just have snapshots instead of a tarball in case I explode the real file system. And given some of the things you can do ("fill an area of disk with pattern p"), I fully expect to blow away a few test filesystems learning it.
:wq
This is a test blog post from BlogWriter Lite.
Though I haven't yet used it, BlogPress' free version has a camera button built in; I assume this works in conjunction with the integrated Picaso client to allow posting of images stored on the iPhone or taking images with the webcam and posting them immediately.
BlogWriter doesn't have any image support in the free version, but supposedly the full version does offer HTML and image support.
Neither program allows for turning the phone sideways and using the landscape keyboard, which would be really nice.
:wq
I just downloaded a couple mobile blogging apps for iPhone that support the Blogger API. BlogWriter and BlogPress both have free trial versions, so I figured my first attempt to get things working would be with them. If I can't connect at all to blogspot, then it's no money out of my pocket for the experiment.
A word from the not-so-wise: look up your username and password when setting up something on the iPhone. I could have posted this 3 hours earlier if I hadn't been entering the wrong password to my gmail account. Thank you, Firefox, for letting me forget.
After the 3 hours of learning about XML-RPC, the nasty guts of the original Blogger API, and how to integrate with Drupal/Joomla, I finally have two working mobile blogging apps.
BlogWriter seems to be aimed at a larger community of bloggers. It supports Blogger, WordPress, and anything that can speak the Blogger API at a custom URI.
BlogPress, despite being a portmanteau of Blogger and WordPress, only supports Blogger. The configuration is simple (provided you know your password), but it does require both Blogger/BlogSpot and Picaso credentials. They're the same now, though, and thankfully the app pre-filled my Picaso login information.
BlogPress also appears to be able to work with drafts; I don't yet know I'd they're only local to the iPhone or if it's integrated into the main Blogger web interface.
This just in: BlogPress doesn't turn sideways. Really a bummer because the iPhone keyboard is much easier to use in landscape orientation. Spellcheck and autocorrect can only do so much.
That's really all I have to compare until I actually use BlogWriter. So far, though, it looks like blogging on the iPhone is definitely doable, even without Google's SMS and e-mail hacks.
:wq
In the process of tweaking my uzbl config to be a little more vi(m)-like, I've made several modifications:
<<, >> (scroll to begin, end) are replaced with the more correct gg and G
b, m (next, previous page) are replaced with vimperator's H and L
t opens a new tab in uzbl-tabbed, so I removed it from the config
B (add bookmark) replaced with the more correct m
u (load bookmark) replaced with the more correct `
y2url is just long; y is the original vi(m) for it anyway
:q should also exit; unfortunately, this happens immediately and I haven't figured out how to require pressing
Swapped case on F, fl, and FL to match vimperator better
And finally, since google.com automagically moves the focus to its input area, I commented out the "home page." gh still goes to google, though.
I used to have ^W,h and ^W,l switch between tabs, but haven't gotten this to work correctly in the latest version of uzbl yet. Instead, Ctrl+Tab and Ctrl+Shift+Tab move between tabs.
And, of course, the colors have been modified. I find the color scheme I've got helps improve readability. It also color codes based on SSL/non-SSL, even with tabs that aren't selected.
My current complete config file can be viewed here.
:wq
Just found out that vim has spell check. If you use vim, this is all kinds of awesome. For the non-gvim among us :se spell is all you really need to know. Since I use vim with mutt to compose email, this is all kinds of awesome since now I don't have to worry about misspellinks in my email.
:wq