Planet GSLUG

February 17, 2010

Mark Foster

February 12, 2010

Bryan McLellan

Setting a permanent Windows Hostname on EC2

In less than obvious fashion, Amazon EC2 Windows Server AMIs reset their hostname on startup due to the Ec2ConfigService. To disable this feature, select ‘EC2ConfigService Settings’ from the start menu, and uncheck the first checkbox under ‘Set Computer Name’

by btm at February 12, 2010 07:56 AM

January 25, 2010

Andrew Gray

News: Trisquel Linux FTW

I have a 64-bit proc in my newish laptop, and I wanted to try gNewSense, but it doesn't natively support 64-bit in the default ISOs (and I didn't feel like building it from scratch). So I gave Trisquel GNU/Linux a try.

Trisquel is Ubuntu-based, but just as obsessed with freedom as gNewSense; in fact, the FSF is giving away Trisquel USB-stick installers to new members I believe. The project is still young, and centered in Spanish primarily, but the English version is great.

I'm trying to get involved by setting up a PPA for things like updated Ekiga, VLC, Icecat, and such along with a Trisquel-using friend from IRC. Deb packaging is harder than I thought!

Also, not using the official nVidia driver for Linux comes at its costs; 3D renders at about 1 frame/second. That's fine for me, though, since I don't really use 3D anymore.

by Andrew Gray (sweetandy@gmail.com) at January 25, 2010 11:36 AM

January 22, 2010

Bryan McLellan

Configuration Management vs Meatcloud: 5 reasons CM wins

First, a bit of social commentary.

Sometimes we refer to the way something ought to be accomplished as the RightWay[tm], sarcastically noting that every best practice contains a certain degree of opinion. As we dedicate more time to doing something our way, we become invested in it being the RightWay, and risk becoming defensive about our choices. Adam Jacob calls this “survivorship-bias,” and I’ve spent some time listening to him think about what he feels the risks are, and considering them myself. When we make significant personal investment in a choice, it becomes a personal challenge to remain impartial about the merits of that choice over time.

I’ve previously said that Configuration Management is the act of programatically configuring your systems. Cloud computing says that building servers is undifferentiated heavy lifting; unless your service is building servers, you should really let someone else do it and focus on the product or service you’re actually trying to sell. Configuration Management is the first step in bringing this same ideology to configuring systems. We are not in the business of selling configured servers any more than we are in the business of providing coffee to our employees, we happen to do both. We build our systems to enable our business to conduct business. In my case, operations is enabling our customers to use the web product that we develop.

We are all members of the Configuration Management community, because we believe it is ultimately a better process for building systems. We naturally have different ideas about how that process should execute, which among other differentiating factors is often that “goals are different but are left unstated” in the community. The level of preference here and resulting fragmentation is not any different than holding an opinion over what open source operating system one should use for a specific task. The merits of our choices are worth discussing, but the implication that tools and libraries should all come to the same conclusions about design is like implying that the world only needs one type of hammer.

So, defining the meatcloud as the established notion that having your internet presence grow forms a direct relationship with hiring more people to rack servers, install software, and update configuration files; I asked around a little, why do we think Configuration Management is better?

  • Abstractation
  • You don’t need to be a mechanic to drive a car, should you need to be a subject matter expert on Apache to run a webserver? Infrastructure as code shows us how and the resulting communities are starting to implement this. When we spend less time getting the parts working, we can spend more time innovating better solutions with the parts.

  • Self-documenting
  • Ever rebuild a server that someone built long ago and is no longer with the organization, and find many small parts necessary to make it work that nobody bothered to write down? Placing those small changes and required files in configuration management ensures that even if the code doesn’t run flawlessly on an upgraded operating system, you know everything that went in to making it work. Since you’re configuring the system through configuration management, a lot less falls through the cracks because documentation is often an afterthought to getting the system working.

  • Consistency and Repeatability
  • What is on that system? Everything you told CM to put there. ‘Golden image‘ disk images often leave you in the aforementioned situation where you don’t know how to recreate them, but often you don’t know what else ended up there. Configuration Management allows you to build many copies of the same system easily, from scratch every time.

  • Agility
  • Did sales tell you they had fifty customers and it turned out to be five hundred? How long will it take you to build the extra servers by hand? How many extra people do you have to put into the meatcloud to get that done in time? Business requirements always change, and slow moving businesses are at a disadvantage to dealing with this. The inability to build and deploy servers fast enough should never be a reason your business fails.

  • Flexibility, or Don’t Repeat Yourself
  • Three applications on one server? Or one application on three servers? Apache doing different jobs on multiple servers? Moving applications between servers and leveraging existing infrastructure code for new projects is easy. We automate tasks that are repeatable, but often scripts are written to accomplish one repeatable task. Here we say, how can we treat configuration as sets of modular tasks that we can mix and match?

by btm at January 22, 2010 10:21 PM

January 18, 2010

Trevor Bramble

Torchlight, Wine, and the Case of the Missing Audio

There was an innocuous-seeming update to Wine a few days ago, and upon attempting to play the one game I have installed via Wine, Runic Games’ astonishingly awesome dungeon-crawler, Torchlight, I found it suddenly mute. Which is not really how I like to play it. So I was perturbed.

After a few minutes of rechecking all of my audio mixer settings to make sure nothing had put them in disarray while I wasn’t looking, I turned to Google. There was the usual collection of outdated forum entries and unrelated flotsam, but one of the hits prompted me to visit the Wine App DB.

Lo and behold, there was a new addition to Torchlight's entry, leading to this bug report, #21248 "No sound in Torchlight, needs mmdevapi implemented".

I’m not familiar with how Wine development generally works, but I’m disturbed by the contents of that report. The audio is apparently silent because only partially implemented code has been put in place that (I assume) diverts the game’s audio to subsystems that don’t exist yet. It seems bizarre to me that incomplete code would not be checked into a parallel branch of development until it’s complete, but again, I’m not familiar with the Wine development traditions; maybe there’s a good reason.

In any case, after seeing a workaround described in the bug report, “Try adding the mmdevapi = none override in winecfg?”, I set out to discover exactly how one does that. Back in the day that was done in a configuration file, but now it’s in the GUI.

So the exact steps to fix it are:

  1. Open Winecfg

  2. Go to Libraries tab

  3. Enter “mmdevapi” and click Add

  4. Select the new mmdevapi entry and click Edit

  5. Select “disable”, then OK both windows.

  6. Upon restarting Wine, Torchlight should now be its awesome, atmospheric self again.

by Trevor Bramble at January 18, 2010 04:01 AM