Posts about til

tags: #til | #windows

2013-09-15 12:00

TIL: Installing Windows 7 on a non-default drive

(originally from https://web.archive.org/web/20150423071752/http://ajcsystems.com/blog/blog/2013/09/15/til-installing-windows-7-on-a-non-default-drive/)

Quick one: today I learned that, when installing Windows 7 on a machine with multiple hard drives, it will refuse to install to a drive which is not set as the default boot device in the BIOS.

It doesn’t tell you this is why it won’t install, of course. It just says “I couldn’t find a valid drive to install to, go read the setup log to find out more.” If you’re inclined to figure out this problem, you then have to Google around a bit to actually find the location of the setup log files, read them through “type setupact.log”, and then happen to run into an error that could be interpreted as being related to BIOS boot order.

Hopefully this note saves somebody the several hours that I wasted today on this. =P

tags: #code | #python | #til

2012-10-10 12:00

Regular Expression Non-Capturing Groups (or, what’s "(?:" mean?)

(originally from https://web.archive.org/web/20150422001421/http://ajcsystems.com/blog/blog/2012/10/10/regular-expression-non-capturing-groups-or-whats-mean/)

When I was working recently on changing poodledo‘s parser from using a lexer to using regular expressions, I found myself implementing some crazy logic to try and ignore the results from matched groups whose matches I didn’t actually want (since I was using parentheses for their “pick one of these two alternatives” function instead of their “pull out this specific chunk as a match” function).

For example, take the string “task title @context name #due date”. Starting with the at-sign, I want to match all words until some other symbol is reached; or, to avoid confusing the parser, match everything following the at-sign and between two square brackets. Here’s the regex I came up with:

(^|\W)@([\b ]?(([\w\"\'.@]+ )*[\w\"\'.@]+)[\b]??|[\b(.+?)\b])

Using this regex, though, gave me a lot of extraneous matching groups:

>>> q = r'(^|\W)@([\b ]?(([\w\"\'.@]+ )*[\w\"\'.@]+)[\b]??|[\b(.+?)\b])'
>>> task = 'task title @context name #due date'
>>> re.findall(q, task)
[(' ', 'context name', 'context name', 'context ', '')]

How do I determine programmatically which of these groups is the one I want?

Digging around in the Python regex documentation, I found a section about non-capturing groups, which seemed like it would save me a significant amount of sanity. Apparently, Perl-5-compatible regular expression parsers often implement a regex extension syntax by following an open parenthesis with a question mark, and then some other symbols that indicate which extension is in use. In this specific case, “(?:” indicates a group whose matches shouldn’t be captured in the output list. Eureka!

>>> q = r'(?:^|\W)@(?:[\b ]?((?:[\w\"\'.@]+ )*[\w\"\'.@]+)[\b ]??|[\b(.+?)\b])'
>>> re.findall(q, task)
[('context name', '')]

Now the only logic I need is “Ignore matching groups which are empty”, my sanity is preserved, and all is well with the world.

tags: #openstack | #til

2012-10-02 12:00

The Unbearable Lightness of User-Data

(originally from https://web.archive.org/web/20150423071705/http://ajcsystems.com/blog/blog/2012/10/02/the-unbearable-lightness-of-user-data/)

When you launch an instance in OpenStack, it has a big empty box called “User Data”:

image

I never knew what that box was for until today.

How it’s provided

If an image is configured to use cloud-init, when it starts up it will curl a special path:

$ curl http://169.254.169.254/2009-04-04/user-data/

Since this is a link-local “I don’t have a DHCP address yet” IP, it will work even before networking is configured. The output from this URL is whatever you put in “User Data”.

How it’s used

cloud-init has a bunch of different tweaks it can apply as an instance launches; it can run apt-get upgrade, import ssh keys, disable sshd PasswordAuthentication, run arbitrary commands, and much more. This sample config will give you a pretty good idea about the full capabilities of cloud-init.

Basic example

When you launch an instance, put the following in “User Data”:

#cloud-config
ssh_pwauth: True

This will make cloud-init enable PasswordAuthentication in sshd (which it otherwise disables by default), so that you don’t need to use a key to log in to the instance.

tags: #linux | #mac os x | #til

2007-02-12 12:00

Caveats when migrating from Mac OS X to Linux for serving Mac OS X home folders

(originally from https://web.archive.org/web/20150422203246/http://ajcsystems.com/blog/page/2/)

Also known as, “Things I wish I’d known about on Friday, part 1″. :-P

  1. Mac OS X is, generally speaking, case-insensitive. It’s possible to format a disk with a case-sensitive version of HFS+, but that’s not usually done and (I imagine) not well supported or documented. The underlying BSD layer will accept any case for filenames, and preserves the case of files as they are created, but does not actually care about it when accessing them.

    Samba hosted on a Linux box, on the other hand, cares quite a bit about case. By default, the “case sensitive” parameter is set to “auto”, which means “no for Windows clients and yes for everybody else”. Mac OS X reports itself as a Samba client, of course, which means that the Samba server assumes it is asking for a case-sensitive file or folder and attempts to serve it. Unfortunately, it’s not.

    As a workaround, it’s possible to set “case sensitive = no” as a share-level option for shares accessed in Mac OS X, which works to a point. Finder will properly ignore the case of files when requesting them from the Samba server (or, more likely, will accept a filename of any case as a successful open), but other apps in OS X do not honor this setting. Notably among them in my testing is Microsoft Word.

    Dealbreaker. =( I had to go manually rename the home folders of each user that uses the Samba server to match the case of their usernames in the Active Directory (which is CamelCase).

  2. Network mounts over the AFP protocol will permit users to save files which contain various scary characters in their names (such as slashes, question marks, asterisks, etc.). Network mounts over Samba do not permit these characters, and mangle the filenames for display by the user agent. The mangled filenames look much like the Windows backward-compatible-long-file-names (i.e. 6CHARS~1), probably on purpose. Mac OS X Server does its magic by way of the UTF-8-MAC file encoding, which as far as I can tell is supported only on Mac OS X Server’s version of Samba. :'(

    I have 5,000 or so files to rename now.

There’s more, but I have to take a call, so that’ll all be in part 2.