DigitalNigel

Hey all! You’ve probably noticed that I’m using a new blogging system. I finally got tired of maintaining the old one, so this is what happens. Anyway, so far I’m pretty pleased, and hope you are as well.

Also note that some content from the older posts may be listed as [UNAVAILABLE]. When transitioning the systems, I went through each post and confirmed all the links and whatnot worked properly. If I couldn’t find a suitable replacement for broken links, I marked them as [UNAVAILABLE]. So, sorry that totally awesome thing I was referencing isn’t there anymore. Sucks to be you.

Anyway, enjoy!

I’ve got an iPad and iPhone, I only got the small ones (16GB) and with a significant amount of music, I’ve frequently had to clear off less used apps for space. Then yesterday I thought about it some more, and remembered the tickbox in iTunes that says “Convert higher bit rate songs to 128 kbps AAC.”

I didn’t really think most of my library was of high enough bit rates to really benefit from conversion, but thought I would try it anyway.

Well, a few hours later, after iTunes finished converting everything, I had reduced space usage of music on my iPhone from 11.1GB down to 8.4GB. A pretty significant difference. So I’m pretty pleased.

To summarize, if you’re short on space on your iDevice, you might try this one out.

I’ve been using a neat app on my iPhone called Photosynth, that stitches together images into scenes. After which, you have the option to upload your “photosynth” to the website, where you can view them on a larger screen.

For the most part, it’s been pretty smooth, and has worked well, until I tried to upload one of my photosynths today. The app would just jump to saying “Network error.” Any other photosynths I had taken would upload fine, but this particular one would fail. I tried hitting retry a few times, I tried cancelling and restarting the upload, I tried force quitting the photosynth app. Nothing seemed to work.

Finally, after asking google to only give me RECENT results, I found this tip: If you hit retry five times, it will regenerate the upload file. Apparently I never hit retry five times, and everything else I did wasn’t good enough. That seems pretty silly. Anyway, it’s working now, so hopefully that helps somebody.

By the way, here’s the link: Photosynth Forums

So, I recently went and updated my google password, as I do every so often, and managed to get most things updated fairly quickly. However, it seems I forgot about my asterisk server.

I have my asterisk server configured to connect in with my Google Voice account via jabber, just like GTalk does, so I can use my desk phone to make and receive phone calls. Seeing as how I don’t make or receive a ton of calls, I didn’t really notice that asterisk could no longer connect to Google Voice. That is, until the server started crashing…

At first it crashed, and I didn’t really look too deeply into it. The server I have asterisk running on is a VM running on VirtualBox on my mac. VirtualBox isn’t known for having rock solid kernel drivers, so I chocked it up to a fluke. Then I went and took a look this afternoon at my system stats graphs, and noticed the ram was totally used up, and the swap space was rapidly diminishing. Doing a little digging I saw it was the asterisk process, and logging into the asterisk CLI, saw a billion errors about it complaining of an incorrect password.

A-HA!

Anyway, to cut a long story short, I fixed the password and now asterisk is happy and not making my server all crashy. Also I filed a bug report. I kinda figure crashing a system is not the intended failure mode for an incorrect password.

Here’s some pretty graphs of memory and swap usage during the crashy period.

So, as I’ve mentioned, I’ve got a new mac, running OSX Lion Server. It comes with this little program (that is in rather un-apple style, rather lack luster) called Server.app. It’s supposed to help you manage the various server functions OSX comes with built in. However, I’ve run into issues where when logging in to the Server.app interface, it rejects my password. I saw this once, and had been screwing with some stuff, so I just reinstalled OSX as I didn’t have anything I really cared about.

Well, now it’s been a few weeks, and I just installed an update for OSX and all of a sudden my logins to Server.app are failing again. (Apple, fix this. This is BS.) Anyway, I hadn’t really done anything I could think of that would screw this up, so I did a bit of google searching, and found this forum post.

Worked immediately. Thank xenu. Apple needs to fix this crap. This is rather uncharacteristic for them.

Also, just in case in the future that forum link stops working, here’s a copy of what the instructions are. Fully quit Server.app. Open the terminal application and enter

“sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.servermgrd.plist”

Then re-open Server.app and everything should work.

Hope my little bit of turmoil helps somebody, and a special thank you to macrumors forum member patrick0brien for doing some digging and finding this answer.

Proxies offer a lot of control for providing a means of managing what people in their enterprises can (or can’t) view on the internet, caching files to reduce bandwidth usage, and scan incoming files for viruses before then even end up on an end user machine.

For a desktop system that stays put and is always connected to the corporate network, this is a simple matter of configuring the browsers with the proxy information and you’re all set. However, in the case of a laptop, it’s not quite this easy.

If you configure a laptop in the same way that you configure a desktop, as soon as the employee takes their laptop home, or on a business trip, or to the coffee shop down the street, their internet won’t work. For an IT guy, it’s a simple fix. Just disable the proxy settings in the browser while you’re out, and re-enable them when you’re back in the office. In reality, end users aren’t IT guys. That’s why they hire IT guys instead of doing it themselves. We need an automatic solution for configuring the proxy based on where the user is.

Well, one option would be to install some third party piece of software to manage that for you. I’m not very inclined towards that. That means that each laptop needs to be manually configured each time there is a change, and you’re also adding another puzzle piece to an already complicated puzzle of systems administration.

The second option is what’s known as WPAD. It’s a system designed by Netscape back in 1996 (yes, 15 years ago). That relies on two options. One is that you can use the DHCP server to point a client towards a javascript file that tells the browser how to connect to the proxy. Problems are that not all DHCP servers support this, and not all browsers support this. In some cases, those are some big pitfalls. The second option is via DNS. In this option you create a subdomain of your local network for WPAD. So say your laptop’s hostname was laptop01.dyn.example.org, the system would look for wpad.dyn.example.org/wpad.dat, failing that would search for wpad.example.org/wpad.dat, failing that would search for wpad.org/wpad.dat, failing that would fail. Now I’m sure you can see where the issue is with this, “But wait! We don’t own wpad.org! We own example.org.” My answer to that is “Exactly.” This can and has been exploited. Also, like in the DHCP example, wpad.dat is a javascript file, and is executed EVEN IF JAVASCRIPT IS TURNED OFF IN THE BROWSER. NOT GOOD!

This is where I was stuck. Recently, I was setting up a new macbook for one of my end users, and had to configure the proxy. We discounted the idea of third party software right away, we toyed with the idea of the DNS option, didn’t like it, DHCP might have been an option for us, but our DHCP is served by a windows domain controller, and macs don’t like how they pass the extra information like the bits for WPAD. Hmmm… Then I found this…

It seems that Apple has provided me an out. Automatic proxy configuration lets me put in the address of the server and the filename for our wpad file, as wpad.dat and whatever.pac both do the same thing in the same way, and in the case that the system can’t reach our server, it fails over to running with NO proxy. Sounds perfect!

But wait! There’s more! Macs don’t configure the proxy settings in the browser. Proxy settings are a system wide setting. This way, it’s not only the browsers that automatically work, it’s everything on the system that uses the internet.

Apple may have a garden with some damn high walls around some of its products, but damn do they do a good job of making them easy to use.