Maybe I should make this bit
change every so often?
I’m back teaching again, something that makes me very happy. Got a couple of Cisco courses, and we’re getting to the end of semester. In class last Thursday, the conversation took a turn towards cupcakes.
Before you know it, behold:
The collision of sugar and segments. Packets and piping. Cisco and Cupcakes.
And now, should probably get back to CCNP prep!
So, I finally sat and passed my CCNA exam, and now almost a month later, I’ve finally posted about it here!
The biggest take away for me from the whole process was how much easier it was to focus and study once I’d booked the exam in. It was hard work, sure, but once I’d taken away the option of doing it later, or doing some other exam first perhaps, everything happened a lot quicker.
Having said all that, it was certainly my intention to start studying for the next exam straight after I did the CCNA. Obviously not having learned from experience, I have taken until pretty much right now to actually decide what that next exam should be. Should I start my CCNP? Do CCNA Security? Knock out a couple of Sun exams? All perfectly valid options, and by having options I was thinking about them, and not getting any study done. So, as of 20 minutes ago, I’ve booked in for my CCNA Security exam for late September.
Now that I’ve got my date, I know what I need to do between now and then. Looking forward to the challenge!
We’ve got a script that parses install logs for each Solaris client looking for errors and then generating a summary report of what happened and what went wrong. It works well, but until recently, it’s been quite limited as it only flagged variations of the words Error and Warning. That was ok originally, but the install scripts got more complicated and it’s now been out grown.
After seeing a few variations on “cannot”, including “can not”, “can’t” and “could not” and “couldn’t” showing up in the logs, I thought it’d be interesting to audit some of the common unix commands we use in the scripts and see what sort of words they use to describe errors. It turned out to be quite a long list.
These are all taken from Solaris 10 10/08 clients. Where relevant I’ve kept them case sensitive.
The thing about most unix commands is that they’re generally not very chatty. There’s a good chance if they’re producing any sort of output at all, it’s probably an error of some description. With that in mind, it’s quite possible there’s a much more elegant way of writing the parse scripts.
Don’t worry, it’s not a trick question. I honestly don’t know just yet. If I did, I’d be writing a post called “How to share an automounted directory using NFS in Solaris 10″. I dream that one day soon I can do that.
In the meantime, I’m writing up the scenario that doesn’t work in the hope that it a) provides me with a blinding flash of insight, b) lets other people know it’s not just them or c) prompts someone who knows the answer to drop it in the comments. Come on, you know you want to!
I’ve got a machine running Solaris 10 10/08 with several user accounts. Home directories for these accounts are in /export/home/. They are being automounted in /home. I want to share the /home/username directories using NFS. Should be simple right?
/etc/auto_master:
/home auto_home -nobrowse
/etc/auto_home:
fred box1:/export/home/fred
/etc/dfs/dfstab:
share -F nfs /home/fred
After confirming that NFS is running and online (svcs -a | grep nfs), we activate the shares:
# shareall share_nfs: /home/fred: Operation not applicable
Sharing /export/home/fred works just fine.
The official Sun docs suggest that the “Operation not applicable” error means I should contact my vendor for an upgrade. Right. I’m fairly sure this was working in Solaris 8, but need to double check.
It seems to be that XScreenSaver won’t load for regular users in Solaris 10 (update 6, 10/08) using JDS.
This means that a regular user can’t lock their workstation screen or have the screensaver come on. Typically, an error message along the lines of “XScreenSaver failed to load” pops up when the user logs in.
Pretty annoying all round.
Happily, it’s an easy fix. Edit your .profile and add /usr/openwin/bin to your $PATH variable.
Log out. When you log back in, you should see a “Lock Screen” option on your menu and screensavers should kick in.
So after a little bit of stuffing around with missed deliveries, I finally have my new iPod Shuffle. Happy days!
I ordered it last Wednesday morning. I think it was the size of it, and wanting to buy something so that Mactalk got a cut that won me over so quickly. This seemed like the perfect opportunity.
iPod Shuffle TNT Package ready to open
Obviously it came well packaged…
iPod Shuffle in box
The only difference to the standard retail packaging was a bit of white plastic wrapped around the outside of the plastic box.
You could pretty much buy these in vending machines now...
iPod Shuffle in packaging, ready to crack open 
Headphone plug and 3 way switch
iPod Shuffle from the back.
I got mine laser engraved. Figured if I was buying online, I may as well take advantage of the free engraving service. I won’t be getting a case for it (really not that much to protect!), so the engraving will be pretty much the only unique identifier on it. I suspect lots of people will end up with these, so easier to have it personalised. The engraving is top quality too. There is about 1cm of horizontal space to engrave on, and they’ve fitted 12 perfectly legible characters on one line. Apple really have a good machine for doing this!
iPod Shuffle sync cable
The USB sync cable is perfectly compact, just like the shuffle. I plug it into the back of my desktop keyboard and – kind of obviously – it seems made for it. It’s about 7-8cm long, so it won’t be a hassle to pack if you want to use your shuffle as removable storage.
It really is tiny.
I’ll reiterate what pretty much everyone is saying. This iPod is TINY. A miniturised Nano. About the size of a recent model USB drive, the build quality is amazing for something this small. It’s machined. Refined. Engineered. Metallic. It’s got that all metal feel that I love about my MacBook Pro. It’s all class.
The whole kit.
All of the playback controls are on the headphones. The controls work well, the voiceover thing is pretty cool. Much better than I’d expected based on the promo video on the Apple site. The sound quality is decent enough for what I plan on using this for (commuting & exercise). When I want big sound, I’ll plug my big headphones into the laptop. So, I’m happy. It’ll be interesting to see if a remote cable accessory is on the market soon to allow people who do what to use their own headphones to do so if they wish.
All in all, I’m really happy with it. I wouldn’t want it as my only iPod, but for having on hand for when you just want to listen to something and don’t hugely care what, it is perfect. Well done Apple!
I’ve been working on a Rails app that automatically builds shell scripts. It pulls a bunch of prewritten code out of an SQLite database and writes it out in order to a text file.
Only problem is there are some rouge line ending sneeking to the database. I’m developing on Solaris 10 where the default line ending is a line feed character (LF, 0×0A). For reasons I don’t understand, Rails and/or SQLite is using an LF CR combination on all of the code that was entered through a text field and saved to the database. When it gets spat back out into the shell script text file and I try to execute it, Korn chokes. Korn expects LF line endings in text files and that’s all there is to it.
After poking around to uncover where the line ending might be being set, I decided it’d be easier to tweak the three places in the Ruby script where code was being outputted to the text file and modify the line ending there.
finalscript << assertion.snippet.code.delete("\x0D") << "\n"
Essentially we’re deleting all of the CR characters from the chunk of code, leaving just the LF which keeps Korn happy.
I’m not totally happy with it as a solution, but it works, it was fast and cheap and solves something that probably doesn’t affect too many people.
For much of the time since I got my iPhone last July, I’ve found the touch screen to be quite intermittant. Sometimes it works brilliantly, often I might as well have a phone wth no buttons.
I don’t know what kind of dark magic Apple have used to make the iPhone work, but it only responds to fingers (or at least, nothing else I’ve tried tapping it with – pens, pencils, erasers – works).
It later occured to me that my hands are often quite dry. No skin crackingly dry, but they could probably do with moisturising more often than I do. So I began a quick experiment.
Every time my screen becomes non responsive, I go moisten my hands under a tap. In a pinch, I lick my finger (yeh gross, whatever. This is *science*.)
Seems to do the trick pretty much every time.
Guess it’s off to buy some moisturiser then – for the sake of my hands and my iPhone!
Following OpenSolaris rendering itself completely non-booting, I’ve moved back to running Solaris 10 u6 (10/08) on my Ultra20. I’m really not sure what caused the crash, but I couldn’t recover from in the amount of time I wanted to spend (not much) and really I should be focussed on Solaris 10 anyway.
So, how to setup the new box – knowing the end goal is to have a solid development workstation I can use for Ruby, Rails and Solaris development as well as general testing and hacking around… These are my notes. While the end result does work, it took a fair bit of effort getting there. It was a learning experience and ultimately I’m glad of it.