Dustin C. Hatch

[dustinhatch-blog]

Minimalist Gentoo Builds, Revisited

Last year (wow, time files), I posted a guide for building minimalist Gentoo systems for embedded devices like the Raspberry Pi using crossdev. The process I outlined there, while functional, was unweildy and confusing, and fell apart if you wanted to build multiple systems with different configurations. I have improved the process somewhat, making it easier to follow and eliminate the need to rebuild the toolchain for each system you want to build.

Since my last post, Minimalist Gentoo for the Raspberry Pi, the package set has changed somewhat:

app-shells/bash

app-arch/bzip2

sys-apps/coreutils

sys-apps/file

sys-apps/findutils

sys-apps/gawk

sys-apps/grep

app-arch/gzip

sys-apps/kbd

sys-apps/kmod

sys-apps/less

sys-apps/openrc

sys-apps/net-tools

sys-process/procps

sys-apps/sed

sys-apps/shadow

Staging Areas

As before, cross-compiling takes place in multiple stages. This time, there are only two:

build root

deployment root

Again, we'll be using the buildpkg FEATURES flag, so each package only has to be built once.

Build Root

The build root is where everything gets installed as the system is being built. This includes all the packages we want, plus their runtime dependencies, and their build dependencies as well.

Deployment root

While the build root could theoretically be copied as-is to the final filesystem, it's better to use the binary packages built in the build root and install them in an alternate location. In this way, only the desired packages and their runtime dependencies are installed on the final system, not build dependencies.

Crossdev

If you already have a crossdev toolchain you'll probably want to remove it and start over:

crossdev -C armv6j-hardfloat-linux-gnueabi

If you are prompted to recursively remove the directory, say yes.

Create a new toolchain (I still recommend the stable versions):

crossdev -S -t armv6j-hardfloat-linux-gnueabi

Configuration

The Portage configuration generated by crossdev is broken, so the easiest thing to do is start from scratch.

First, create the Portage configuration directory structure in your build root (I am using /var/tmp/rpi-build as my build root, but it can be whatever you want):

mkdir -p /var/tmp/rpi-build/etc/portage/profile

Next, create a make.defaults file in the profile directory and put the following content in it:

ARCH=arm ELIBC=glibc ACCEPT_KEYWORDS="arm" FEATURES="-news buildpkg" USE="arm bindist minimal"

This is necessary because Portage EAPI 5 made ARCH and ELIBC "profile-only" variables, so they can't go in make.conf anymore. The contents of make.conf are still important though, so create it next:

CFLAGS="-Os -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s --sysroot=/var/tmp/rpi-build" CXXFLAGS="${CFLAGS}" LDFLAGS="--sysroot=/var/tmp/rpi-build -Wl,--sysroot=/var/tmp/rpi-build -L=/usr/lib" # Add any other variables you like here, such as MAKEOPTS, USE, etc.

NOTE: The CFLAGS in this example are for a Raspberry Pi. If you are building for something else, like a Beagle Bone, make sure you adjust them accordingly. DO NOT, however, change or remove the --sysroot flag, as it is the key to making the whole thing work.

You can also create package.use, package.keywords, etc directories in /var/tmp/rpi-build/etc/portage, just like you would with a regular system.

Now, tell Portage to use this configuration instead of the default:

export ROOT=/var/tmp/rpi-build export PORTAGE_CONFIGROOT=$ROOT

Bootstraping the Build Root

In order to use the --sysroot flag for the compiler/linker, glibc and kernel-headers need to be installed in the target directory. We've created a chicken-and-egg problem by putting --sysroot in make.conf; if we try to build glibc in the sysroot, it will try to use the glibc already there (which of course doesn't exist). Thus, we have to temporarily override CFLAGS and LDFLAGS to get things going:

CLFAGS= LDFLAGS= armv6j-hardfloat-linux-gnueabi-emerge --oneshot --noreplace virtual/libc virtual/os-headers

This will reset the compiler and linker flags back to their defaults. While there's nothing wrong with that, the result will not be as highly optimized as it could be. You may want to specify a more complete CFLAGS instead.

Building Packages

Now that the build root is also a sysroot, building subsequent packages is a cinch:

armv6j-hardfloat-linux-gnueabi-emerge --usepkg --noreplace --changed-use bash bzip2 ...

All of these packages should build succesfully. If you add others, you may run into problems. For example, I wanted to build radvd, which depends on libdaemon. The version of libtool shipped with libdaemon is too dumb to understand the sysroot flag, so it fails trying to link with libraries in in the non-existant directory =/usr/lib. There are a few work-arounds, but the best thing to do is file a bug and help get the package fixed.

Deploying

Now that everything has been built and the binary packages have been created, it's time to deploy to the final system (SD card, etc.)

Make sure you follow the necessary instructions for creating and formatting your device's root filesystem (for the Raspberry Pi, see the Raspberry Pi page on Gentoo Wiki). I'll assume you've mounted the root filesystem at /mnt/raspberrypi

export ROOT=/mnt/raspberrypi

Create the empty top-level directories:

mkdir $ROOT/{boot,dev,proc,root,sys,tmp}

Install the binary packages that were created before:

armv6j-hardfloat-linux-gnueabi-emerge --usepkg --ask bash bzip2 ...

Copy the GCC runtime library:

cp /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libgcc_s.so.1 $ROOT/lib

Other Bits

The remaining pieces, like clock and timezone settings and the Kernel, are still relevant from my previous post. Check out the "Finishing Up" section.

Embuilder

I've written a tool called embuilder that handles all of this for you. It's not quite finished, and I've not written any documentation at all. It's designed to be able to work with multiple different projects by reading settings from a single configuration file. When I get time, I'll write more about it. For now, here's an example configuration file and usage:

# Project settings [embuilder] name = MyRPi # Portage configuration [portage] arch = arm ctarget = armv6j-hardfloat-linux-gnueabi # optional - directory containing extra portage configuration (not make.conf, though) ;configroot=configroot # A group of packages to install in addition to the basics [tools] packages = iproute2 nano dhcpcd eudev dropbear

Save the file somewhere. I keep each of my embedded system projects in a separate Mercurial repository. Then, pass the name of the configuration file and the path to the deployment root to the embuilder command:

embuilder myrpi.ini /mnt/raspberrypi

That's it. Embuilder will take care of creating the build root, building binary packages, and deploying everything to the deployment root. It has some other neat features, like post-install scripts, overlay files, etc. that I will cover soon.

[dustinhatch-blog]

CA SystemEdge: over-priced, over-hyped, over-engineered, under-developed, under-capable, with big promises and small benefits

[dustinhatch-blog]

Render reStructuredText Directly to Firefox

[reStructuredText](http://docutils.sourceforge.net/rst.html) is awesome. Anytime I need to write something in plain text, I mark it up using rST. It looks nice in plain text form, and can be rendered to HTML for improved presentation. Sometimes, as I am working on a document, I'd like to see what it looks like once rendered to HTML, to make sure I am thinking the same way the computer is. [Docutils](http://docutils.sourceforge.net/) ships with a nice little script called `rst2html` that will render a rST document as HTML, either to standard output or another file. What would be really nice is to be able to immediately preview the resulting HTML document in Firefox without the intermediate file. Unfortunately, Firefox doesn't read HTML from standard input, so `rst2html.py document.rst | firefox` doesn't work. I've come up with this workaround, however, that works just fine. Using `base64` and `xargs`, I construct a [Data URI](http://en.wikipedia.org/wiki/Data_URI_scheme) and instruct Firefox to open that: rst2html.py document.rst | base64 -w 0 | xargs -i firefox "data:text/html;charset=utf8;base64,{}"

[dustinhatch-blog]

Minimalist Gentoo for the Raspberry Pi

I've spent the last several days working on a minimalist build of Gentoo Linux for my [Raspberry Pi](http://www.raspberrypi.org/). By minimalist, I mean only the absolute smallest set of packages required to boot and log in. I intend to build another [MPD Appliance](https://plus.google.com/u/0/111156619169863248480/posts/TB7pB6xuU5Y), or something similar, with it, so I don't need a full-blown Gentoo installation. The bare minimum packages are: * busybox * coreutils * grep * findutils * net-tools * e2fsprogs * dosfstools * module-init-tools * sed * file * less * kbd * shadow * gzip * bzip2 * procps In addition, I installed the following to make my life easier: * bash * iproute2 * ntp * vim # Staging Areas Cross-compiling the system will take place in three stages: * Sysroot * Build root * Deployment root We'll take advantage of Portage's `buildpkg` *FEATURES* flag so that we don't have to compile everything three times. ## Sysroot This stage is where the toolchain will be built and installed. Because of how crossdev works, build-time dependencies of all of our required software will also have to be installed here. The toolchain will look for headers and shared objects in the directory hierarchy under the sysroot when when compiling and linking. Unfortunately, that means all the dependencies will end up being installed here as well as in the build root. ## Build Root This stage is where we'll actually build all the software we want to install on the Raspberry Pi. This intermediate stage is necessary because some software has runtime dependencies on toolchain components like glibc, and we can't install those in the sysroot because it will break the cross-compiling toolchain. ## Deployment Root This stage is the final destination for the packages we built in the build root: the SD card (or QEMU disk image, if you don't have a Raspberry Pi yet). While it isn't strictly necessary to separate the build and deployment roots, it can make it easier to correct problems that may arise, and speed things up if you're building for more than one device. # Crossdev The first thing you'll need to do is set up [Crossdev](http://www.gentoo.org/proj/en/base/embedded/cross-development.xml). The Raspberry Pi's System-on-a-Chip is a [Broadcom BCM2835](http://www.broadcom.com/products/BCM2835), which contains an [ARM1176JZF-S](http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf) CPU. I'll be using the GNU standard C library, so the toolchain tuple will be `armv6j-hardfloat-linux-gnueabi`. crossdev -S -t armv6j-hardfloat-linux-gnueabi Make sure to use the `-S` option for crossdev; the current unstable versions of the toolchain do not work together and GCC fails to build. This will create the "sysroot" stage in `/usr/armv6j-hardfloat-linux-gnueabi`, where we'll install the build-time dependencies for the software we want on the Pi. # Configuration Now that we have a working toolchain for cross compiling, we need to configure Portage to build the software how we want. We'll create a directory structure just like that of `/etc/portage` and fill it with a few important files. mkdir -p configroot/etc/portage/ cp /usr/armv6j-hardfloat-linux-gnueabi/etc/portage/make.conf configroot/etc/portage You will probably want to modify the `make.conf` file crossdev produces. For example, I made these changes: * Remove `~arm` from *ACCEPT_KEYWORDS* * Add the GCC flags to *MARCH_TUNE* for the Raspberry Pi, per the [RPi Wiki](http://elinux.org/RPi_Software#ARM). Note, `-Ofast` doesn't work very well, and I had trouble compiling several packages with it. Using `-Os` or `-O4` work just fine, though. * Add `cxx`, `unicode`, and `ipv6` *USE* flags. I also removed the `make-symlinks` *USE* flag because I will also install Bash and a few other packages that collide with Busybox when that's set. Next, you'll need to pick a profile. Crossdev defaults to the *embedded* profile, which is fine. You could also use the *arch/arm/armv6j* profile, but then you'll need to add some extra variables in `configroot/etc/portage/profile/make.defaults`, like `KERNEL` and `USERLAND`. ln -s /usr/portage/profiles/embedded configroot/etc/portage/make.profile You may also want to make `package.use`, `package.mask`, and/or `package.keywords` directories and populate them to your liking. I had to add `=sys-apps/coreutils-8.20` to `package.mask` due to [GNU Bug #12741](http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12741), for example. Finally, we need to prevent Portage from installing any of the toolchain components in the SYSROOT (they're already there) while we build the rest of the dependencies. You'll need a `package.provided` directory in `configroot/etc/portage/profile`, and it should contain the full atom for each of the four packages built by crossdev (binutils, gcc, glibc, and linux-headers): mkdir -p configroot/etc/portage/profile/package.provided touch configroot/etc/portage/profile/package.provided/crossdev To find the versions of the cross toolchain, use `equery`: equery list 'cross-armv6j-hardfloat-linux-gnueabi/*' Then, put each atom (with the proper category, not the cross category) and version on a separate line in `package.provided/crossdev`. Something like this: sys-devel/binutils-2.22-r1 sys-devel/gcc-4.5.4 sys-libs/glibc-2.15-r3 sys-kernel/linux-headers-3.6 Now, Portage won't pull in any of those packages when building the dependency tree for our packages. Now, set the PORTAGE_CONFIG environment variable to tell Portage to use the settings in this directory, instead of the one in /usr/armv6j-hardfloat-linux-gnueabi: export PORTAGE_CONFIGROOT=${PWD}/configroot # Install Build Dependencies No that we've got our cross toolchain, sysroot, and configuration ready to go, it is time to install the build dependencies for our packages. Put the list of packages you want to install in a variable (i.e. `install_pkgs="busybox coreutils …"`), and then install just their dependencies: armv6j-hardfloat-linux-gnueabi-emerge --onlydeps --buildpkg --oneshot --ask $install_pkgs # Installing in the Build Root Once all the build dependencies are installed, it is time to start the build root stage. The build root will be almost identical to the deployment root, so we'll everything in the build root first, so Portage will build a binary package and speed up the final step. Before installing anything, you need to remove the `package.provided/crossdev` file you created earlier. Since we're no longer installing things in the sysroot, we do want any toolchain components to be installed, if necessary. rm configroot/etc/portage/profile/package.provided/crossdev Next, set the `ROOT` environment variable to the absolute path of your build root directory: export ROOT=/home/dustin/raspberrypi Remember, the build root is **not** your Raspberry Pi's SD card, so don't use that path just yet. ## Installing baselayout Baselayout needs to be installed in two passes. Baselayout needs to be the first package installed on the system, or it will fail to create directories and symbolic links correctly. To ensure it gets installed before anything else, we explicitly install it, without dependencies: armv6j-hardfloat-linux-gnueabi-emerge --nodeps --buildpkg --ask baselayout This basically creates an empty directory structure and some symlinks for compatibility. Once that's done, we'll go ahead and install the rest of the base system: armv6j-hardfloat-linux-gnueabi-emerge --onlydeps --buildpkg --usepkg --ask baselayout This will pull in the rest of the core system packages, including sysvinit, OpenRC, etc. ## Installing Selected Packages Once baselayout is installed, it is time to install the rest of the core packages: armv6j-hardfloat-linux-gnueabi-emerge --buildpkg --usepkg --ask $install_pkgs You'll notice that most of the packages being installed at this point are binaries. That's because we've already compiled them in the sysroot, so we don't need to do it again. # Installing in the Deployment Root Finally! Now we actually get to install stuff on the SD card! Make sure you've partitioned and formatted the SD card correctly. See the [Raspberry Pi Gentoo Wiki Page](http://wiki.gentoo.org/wiki/Raspberry_Pi#Preparing_the_SD_card) for details. Mount the SD card partition you've designated as the root partition, and then reset the `ROOT` environment variable to point to it: mkdir /mnt/raspberrypi mount /dev/mmcblk0p2 /mnt/raspberrypi export ROOT=/mnt/raspberrypi/ Before installing anything, there are a few empty directories we need to make manually. They aren't created by any package, but are critical to boot the system: mkdir $ROOT/{boot,dev,proc,root,sys,tmp} Then, install the packages. Everything should just be binary merges at this point, so it won't take too long. armv6j-hardfloat-linux-gnueabi-emerge --usepkg --ask $install_pkgs # Finishing Up ## libgcc_s.so.1 On ARM, Bash (and possibly other packages) depend on the libgcc runtime. This confused me for a while, because on my other minimalist system (which runs on an Atom 230), I didn't need to install GCC and Bash worked fine. Fortunately, all you need is `libgcc_s.so.1` to make it happy, not the whole GCC installation. You can copy the one from the cross toolchain: cp /usr/lib/gcc/armv6j-hardfloat-linux-gnueabi/4.5.4/libgcc_s.so.1 $ROOT/lib/ ## Time Zone You need to set the time zone, just as you would on a full system: echo 'America/Chicago' > $ROOT/etc/timezone ln -snf /usr/share/zoneinfo/America/Chicago $ROOT/etc/localtime ## Root Password Setting the root password can be tricky. Although `passwd` has a `--root` option, it doesn't seem to work in any situation I've tried. Normally, I'd recommend blanking the password and forcing it to be set at first log in, but since the Raspberry Pi has no idea what time it is initially, password expiration doesn't work. Thus, you'll just have to blank the password and hope you remember to set it to something secure on your own. sed -i 's/^root:.*/root::::::::/' $ROOT/etc/shadow ## Services ### swclock Since the Raspberry Pi has no real-time clock, the *hwclock* service just complains. We'll remove it and add the *swclock* service instead. While not an accurate way of keeping time (setting the clock based on the mtime of a file created at last shutdown), it will hopefully at least get the clock in the right decade. rm $ROOT/etc/runlevels/boot/hwclock ln -s /etc/init.d/swclock $ROOT/etc/runlevels/boot/ ### Network If you have a Model B device and intend to use the Ethernet port, you can have it start at boot: ln -s net.lo $ROOT/etc/init.d/net.eth0 ln -s /etc/init.d/net.eth0 $ROOT/etc/runlevels/default ### NTP If you installed NTP, you'll want it to start at boot as well, so the time on the device is accurate: ln -s /etc/init.d/ntp-client $ROOT/etc/runlevels/default ln -s /etc/init.d/ntpd $ROOT/etc/runlevels/default ## Firmware, Kernel, and Modules Clone the Raspberry Pi firmware project on [Github](https://github.com/raspberrypi/firmware). This will get you the latest GPU firmware and bootloader, as well as a precompiled Linux kernel with modules. You can always compile your own kernel later, if you want. git clone git://github.com/raspberrypi/firmware.git Mount the first partition of your SD card and copy the firmware there: mount /dev/mmcblk0p1 /mnt/raspberrypi/boot cp firmware/boot/* /mnt/raspberrypi/boot Copy the pre-compiled kerne modules to the `/lib/` directory on your SD card's root partition: cp -a firmware/modules $ROOT/lib/ ## /etc/inittab You may want to make a couple of changes to `/etc/inittab`. First, I don't like the new *agetty* behavior of clearing the screen before displaying the login prompt, at least on the first TTY; it makes it difficult to see error messages during the boot process. To change it, add `--noclear` to the `c1` definition: sed -i 's/^c1\(.*\)agetty 38400\(.*\)/c1\1agetty --noclear 38400\2/' $ROOT/etc/inittab Also, the default inittab sets up a serial console on `/dev/ttyS0`, but that port doesn't exist on a Raspberry Pi. You can either comment out that line, or change it to use the UART port on the Pi: sed -i 's/ttyS0/ttyAMA0/g' $ROOT/etc/inittab ## /etc/fstab Finally, you need to make sure the `fstab` file in the deployment root is correct. For the Raspberry Pi, the SD card's block device will always be `/dev/mmcblk0`. Each partition will be numbered, starting with 1, and prefixed with a "p". The first partition would be `/dev/mmcblk0p1`, etc. Make sure you set the "type" column to `vfat` for the boot partition. # That's It... ...but don't get in a hurry! Make sure you sync all filesystem changes before you remove the SD card from your computer, since SD cards report writes as complete before actually committing them to the flash. sync ; sync ; sync umount /mnt/raspberrypi/boot umount /mnt/raspberrypi Now you can safely remove the SD card and pop it in your Raspberry Pi. Congratulations, and good luck!

[dustinhatch-blog]

Using PeerBlock lists on Linux

On Windows, [PeerBlock](http://www.peerblock.com/) is a firewall of sorts that blocks inbound and outbound communication with hosts based on their inclusion in one of several lists. It is commonly used to block parties that participate in anti-peer-to-peer activities (i.e. suing people for sharing content, even legitimately), advertisements, malware, etc. It blocks more traffic than one might expect, too. Unfortunately, there isn't a really good alternative for Linux. The original [PeerGuardian](http://sourceforge.net/projects/peerguardian/) for Linux appears to have been revived, but when I tired to use it, it didn't work and was incredibly unstable. The documentation was also pretty terrible. There are a few others, such as *moblock* and *iplist* that appear to have been dead for quite some time. Some other solutions exist, such as simple scripts that convert block lists into iptables rules, but depending on the size of the list, these would consume so many system resources it would be impossible to use the computer. Fortunately, the Linux kernel itself actually includes all the capabilities necessary to implement a large blacklist as part of the netfilter framework. We'll use the kernel packet filter and a relatively new feature called "IP sets" to create a high-performance index of the block lists. For this to work, you'll need to make sure your kernel supports iptables and IP sets: CONFIG_IP_NF_IPTABLES=y CONFIG_NETFILTER_XT_SET=y CONFIG_IP_SET=y CONFIG_IP_SET_HASH_NET=y You could also compile these features as modules and insert them at runtime: for mod in ip_tables ip_set xt_set ip_set_hash; do modprobe $mod; done You will also need the `iptables` and `ipset` utilities, as well as several standard command line tools like `curl`, `cut`, `gawk`, `grep`, and `gunzip`. Next, you'll need to create an IP set to hold the data from a blocklist. For modern kernels, the `hash:net` type works the best: ipset create LEVEL1 hash:net maxelem 262144 The identifier `LEVEL1` is the name of the set, which will be used later in the firewall rule. Notice the `maxelem` property which sets the maximum number of elements in the set. The default is 65536. You'll need to increase it if you want to use a large block list. This example is for the [Bluetack Level 1](http://www.iblocklist.com/list.php?list=bt_level1) list, which lists over 250,000 address ranges (totaling over 800 million addresses). Now that we've got the set created, it's time to populate it. Again, I'm using the Bluetack Level 1 list, but you can use any list you want. You can get several lists from [I-BlockList](http://www.iblocklist.com/). The `p2p` format lists are free, so that's what I'll use in this example. curl -L "http://list.iblocklist.com/?list=bt_level1&fileformat=p2p&archiveformat=gz" | gunzip | cut -d: -f2 | grep -E "^[-0-9.]+$" | gawk '{print "add LEVEL1 "$1}' | ipset restore -exist You can now view (some of) the contents of your IP set to make sure it worked: ipset list LEVEL1 | head You should see something like this: Name: LEVEL1 Type: hash:net Header: family inet hashsize 131072 maxelem 262144 Size in memory: 5868152 References: 0 Members: 213.17.157.224/28 61.95.132.192/27 184.73.76.96/30 81.58.24.80/29 Now it's time to tell the firewall to block hosts on these networks. To do that, we'll use two iptables rules: iptables -I INPUT -m set --match-set LEVEL1 src -j DROP iptables -I OUTPUT -m set --match-set LEVEL1 dst -j DROP Now you have a kernel-level firewall configuration doing exactly what PeerBlock does. Make sure you save your iptables configuration using your distribution's recommended method. On Gentoo, it's as simple as `rc-service iptables save`. You'll probably want to have your block list updated automatically. To do that, create a new IP set with a different name (such as `LEVEL1-updated`) and populate it with the same pipeline as before. Then, use the `ipset swap LEVEL1 LEVEL1-updated` command to replace the original set with the updated set. Then delete the temporary set with `ipset destroy LEVEL1-updated`.

[dustinhatch-blog]

Samba "ea support" Tips

At home, I use [Samba](http://www.samba.org/) as one of the methods for exposing the data on my file server to the rest of my network (the others being SFTP, FTPS, and NFS). In addition, I use [Folder Redirection](http://technet.microsoft.com/en-us/library/cc732275.aspx) and [Offline Files](http://technet.microsoft.com/en-us/library/gg277982%28v=ws.10%29.aspx) to keep my _Documents_, _Pictures_, and _Videos_ folders in sync on all of my machines. In order to maintain the nifty appearance of those special folders, the file attributes for the `desktop.ini` file in each one must be preserved. Samba can do this in one of two ways: * Mapping DOS file attributes to UNIX permissions * Storing the DOS attributes in [extended file attributes](http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#STOREDOSATTRIBUTES) I prefer the latter method since I also access the files from Linux machines, so changing the permissions of files is not appropriate. To enable storing of DOS attributes in extended file attributes, the following lines must be added to each share definition in `smb.conf`: ea support = yes map hidden = no map system = no map archive = no map readonly = no store dos attributes = yes In order for it to work, though, the filesytem containing the files must support extended attributes. My file server uses XFS, which needs no special mount options. Ext3/4 need the `user_xattr` mount option set. On occassion, I have noticed that sometimes, Samba seems to ignore the extended attribute values. Setting file attributes from Windows does nothing (i.e. the changes are not saved), and setting the `user.DOSATTRIB` extended attribute manually with `setfattr` has no effect. In all cases that I have encountered, this is because Samba encounters a file or directory from which it cannot read the extended attributes. For me, this has been because I had mounted a different filesystem that did not support extended attributes on a subdirectory of a share. Apparently, once Samba encounters one file it cannot read, it stops processing extended attributes altogether. The `user.DOSATTRIB` extended attribute contains a bit field indicating the state of each DOS attribute: Read-Only = 0x1 Hidden = 0x2 System = 0x4 Archive = 0x20 Use the `getfattr` command to view the current attributes: dustin@rigel ~/Documents $ getfattr -n user.DOSATTRIB desktop.ini # file: desktop.ini user.DOSATTRIB="0x6" Use the `setfattr` command to manually set a file's attributes: dustin@rigel ~/Documents $ setfattr -n user.DOSATTRIB -v '"0x6"' desktop.ini (Note the escaping of the quotes in the value; this is needed to force the extended attribute to contain a string instead of an integer)

[dustinhatch-blog]

Enable PowerShell Remoting with CredSSP using Group Policy

Windows PowerShell 2.0 has significantly improved the command-line experience for Windows administration, both for servers and clients. What makes it even better, though, is PowerShell Remoting, which uses Windows Remote Management (WinRM) to send commands between PowerShell sessions on different computers. WinRM is an implementation of WS-Management, an open, standardized SOAP-based web services protocol. In many ways, PowerShell Remoting is similar to SSH, although arguably less mature. # Manual Configuration ## Enable PowerShell Remoting Manually Enabling PowerShell 2.0 Remoting is simple, just run the following command from an elevated PowerShell session: Enable-PSRemoting -Force Once that's done, you can start using it to execute PowerShell commands from a remote host: Invoke-Command -ComputerName $remotehost -Command { Write-Host "Hello, world!" } Or, you can open an interactive session on the remote computer: Enter-PSSession -ComputerName $remotehost ## Enable CredSSP Manually CredSSP is a Security Support Provider introduced with Windows Vista that enables credential delegation. In other words, it allows the remote host to access the credentials that were used to authenticate the user, and pass them on to a third host. For example, when using either basic or Kerberos authentication (the default) when connecting to a remote PowerShell session, the user would not have access to a separate file server. When using CredSSP, however, the session credentials can be passed through to the file server. To enable CredSSP, both the client and the server must be configured to allow CredSSP. To enable CredSSP on the client side, run the following PowerShell command from an elevated session: Enable-WSManCredSSP -Role Client -DelegateComputer $remotehost **Note**: The `DelegateComputer` parameter specifies a list of remote hosts to which the client should be allowed to connect. It can accept wildcards, such as `*` for all hosts, or `*.mydomain.local` for any host on the `mydomain.local` DNS domain. If you specify a domain, however, you must always use the server's FQDN when connecting to it. To enable CredSSP on the server side, run the following PowerShell 2.0 command from an elevated session: Enable-WSManCredSSP -Role Server To connect to a remote host with PowerShell Remoting using CredSSP authentication, you need to specify the `Credential` and `Authentication` parameters: Enter-PSSession -ComputerName $remotehost -Credential (Get-Credential) -Authentication CredSSP **Note**: You must specify a fully-qualified username (such as [email protected] or DOMAIN\username) when prompted for credentials. The unfortunate drawback of using CredSSP is that the current implementation of the CredSSP provider for WinRM does not support delegating default credentials (i.e. the current user's credentials). Go vote for [Microsoft Connect Suggestion #498377](https://connect.microsoft.com/PowerShell/feedback/details/498377/credssp-should-allow-delegation-of-default-current-credentials) if this bothers you; hopefully Microsoft will fix it in a future release. As such, it is best to get a `PSCredential` object once and store it in a variable for reuse: $cred = Get-Credential $env:USERNAME@$env:USERDNSDOMAIN # Group Policy Configuration Enabling PowerShell Remoting and CredSSP manually is fine for only one or two hosts, but what if it needs to be done for every machine on a network? Luckily, Group Policy is able to make all the same configuration changes the `Enable-PSRemoting` and `Enable-WSManCredSSP` cmdlets do. There are several configuration pieces that must be set in order for everything to work correctly: * The *Windows Remote Management* service * Windows Firewall exceptions * Credential delegation * WinRM Client parameters * WinRM Service parameters In addition, some Active Directory objects may need to have permissions changed. It is probably best to group these settings into one or two separate GPOs, one for servers and one for clients, to keep them separate from the rest of the Group Policy settings that may already exist on the network. ## Server Settings To enable PowerShell Remoting on the server side, create a new GPO and link it an organizational unit containing the computer objects for the server machines. Open the GPO with the Group Policy editor and set the following options: ### Windows Remote Management Service 1. Navigate to *Computer Configuration > Windows Settings > Security Settings > System Services* 2. Locate the *Windows Remote Management (WS-Management)* service and double-click it 3. Tick the check box nexte to *Define this policy setting* and select *Automatic*. Click "OK" ### Windows Firewall Exceptions 1. Navigate to *Computer Configuration > Windows Settings > Security Settings> Windows Firewall with Advanced Security > Windows Firewall with Advanced Security - LDAP://{GPO-DistinguishedName} > Inbound Rules* 2. Right-click the pane at the right and choose *New Rule...* 3. Select *Predefined* and choose `Windows Remote Management` from the drop-down list. Click "Next" 4. Remove the tick next to `Windows Remote Management - Compatibility Mode (HTTP-In)`, but leave the one for `Windows Remote Management (HTTP-In)`. The "Compatibility Mode" rule provides an upgrade path for systems using WinRM prior to version 2.0 and should not be enabled unless there is a specific need for it. Click "Next" 5. Select *Allow the connection* and click "Finish" ### WinRM Service Parameters 1. Navigate to *Computer Settings > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service* 2. Double-click *Allow automatic configuration of listeners* 3. Select *Enabled* 4. In the box labeled *IPv4 filter*, enter a comma-separated list of IP address ranges to specify to which IP addresses the WinRM service should bind on the server. For example, `192.168.1.0-192.168.1.255` would allow the WinRM service to bind to network adapters with an IP address in that range, but no other adapter. 5. Do the same for *IPv6 filter*, using IPv6 addresses instead, or leave it blank to disable WinRM over IPv6 6. Click "OK" 7. Double-click *Allow CredSSP authentication* 8. Select *Enabled* 9. Click "OK" ## Client Settings To enable PowerShell remoting on the client side, create a new GPO and link it to an organizational unit containing the computer objects for the client machines. Open the GPO with the Group Policy editor and set the following options: ### Credential Delegation 1. Navigate to *Computer Settings > Administrative Templates > System > Credentials Delegation* 2. Double-click *Allow Delegating Fresh Credentials* 3. Select *Enabled* 4. Click "Show..." 5. Enter a list of service principal names representing hosts to which clients should be allowed to delegate credentials. Wildcards are allowed in the host name portion of the SPN. For example: * `WSMAN/Server01` — Allows delegation only to the server named `Server01`, and only using its single-label name * `WSMAN/Server01.mydomain.local` — Allows delegation only to the server named `Server01`, and only using its fully-qualified domain name * `WSMAN/*.mydomain.local` — Allows delegation to any host on the `mydomain.local` DNS domain, using their fully-qualified domain names only * `WSMAN/*` — Allows delegation to any host by any name 6. Click "OK" 7. Click "OK" ### WinRM Client Parameters 1. Navigate to *Computer Settings > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Client* 2. Double-click *Allow CredSSP authentication* 3. Select *Enabled* 4. Click "OK" 5. Double-click *Trusted Hosts* 6. Select *Enabled* 7. In the box labeled *TrustedHostList*, enter a comma-separated list of hosts the client should trust. Wildcards are allowed, and there is a special `` value meaning trust all single-label names. For example: * `Server01` — Trust only the server named `Server01`, and only using its single-label name * `server01.mydomain.local` — Trust only the server named `Server01`, and only using its fully-qualified domain name * `*.mydomain.local` — Trust any host on the `mydomain.local` DNS domain, using their fully-qualified domain names only * `` — Trust any host by single-label name * `*` — Trust any host by any name 8. Click "OK" # Troubleshooting Here are some common error messages and some troubleshooting tips for each: ## Operation timed out Enter-PSSession : Connecting to remote server failed with the following error me ssage : The WinRM client cannot complete the operation within the time specified . Check if the machine name is valid and is reachable over the network and firew all exception for Windows Remote Management service is enabled. For more informa tion, see the about_Remote_Troubleshooting Help topic. * Can you ping the machine using the same name you used for the `ComputerName` parameter? * If the settings are defined in Group Policy, has the machine performed a policy refresh? Force one by running `gpupdate /target:computer` with elevated privileges * Does the machine have the *Windows Remote Management (HTTP-In)* rules enabled in Windows Firewall? * Is the *Windows Remote Management (WS-Management)* service running on the machine? ## Policy does not allow delegation of user credentials Enter-PSSession : Connecting to remote server failed with the following error me ssage : The WinRM client cannot process the request. A computer policy does not allow the delegation of the user credentials to the target computer. Use gpedit. msc and look at the following policy: Computer Configuration -> Administrative T emplates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentia ls. Verify that it is enabled and configured with an SPN appropriate for the ta rget computer. For example, for a target computer name "myserver.domain.com", th e SPN can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.c om. For more information, see the about_Remote_Troubleshooting Help topic. * Make sure the name specified in the `ComputerName` parameter matches the SPN specified in the GPO. If the policy specifies a wildcard with a domain name, for example, make sure the `ComputerName` parameter is the fully-qualified domain name of the remote host, not just its single-label name ## The target computer is not trusted Enter-PSSession : Connecting to remote server failed with the following error me ssage : The WinRM client cannot process the request. A computer policy does not allow the delegation of the user credentials to the target computer because the computer is not trusted. The identity of the target computer can be verified if you configure the WSMAN service to use a valid certificate using the following co mmand: winrm set winrm/config/service '@{CertificateThumbprint=""}' Or you can check the Event Viewer for an event that specifies that the followin g SPN could not be created: WSMAN/. If you find this event, you ca n manually create the SPN using setspn.exe . If the SPN exists, but CredSSP can not use Kerberos to validate the identity of the target computer and you still w ant to allow the delegation of the user credentials to the target computer, use gpedit.msc and look at the following policy: Computer Configuration -> Administr ative Templates -> System -> Credentials Delegation -> Allow Fresh Credentials w ith NTLM-only Server Authentication. Verify that it is enabled and configured w ith an SPN appropriate for the target computer. For example, for a target comput er name "myserver.domain.com", the SPN can be one of the following: WSMAN/myserv er.domain.com or WSMAN/*.domain.com. Try the request again after these changes. For more information, see the about_Remote_Troubleshooting Help topic. * Make sure the remote host has a *Service Principal Name* starting with `WSMAN` and matching the value specified in the `ComputerName` parameter. To list a host's service principal names, run `setspn -l ` with elevated privileges on a domain controller. If a proper SPN does not exist, try restarting the *Windows Remote Management (WS-Management)* service, and check the *System* event log for event ID 10154. If that event exists, you will need to modify permissions in Active Directory in order for hosts to be able to register their SPNs correctly (see below) * Make sure you are specifying a fully-qualified user name in the `PSCredential` object passed to the `Credential` parameter (i.e. `DOMAIN\username` or `[email protected]`) # Modifying Active Directory Permissions **Note**: Perform these steps **ONLY** if you receive the "target computer is not trusted" error, Windows Remote Managment logs event ID 10154 in the System event log, and `setspn -l` does not list any `WSMAN/...` SPNs for the remote host! 1. Open ADSI Edit 2. Click *Action > Connect to...* 3. Under *Connection Point*, select *Select a well known Naming Context* and choose `Default naming context` 4. Under *Computer*, select *Default (Domain or server that you logged in to)* 5. If your domain controllers support it (i.e. you are running Active Directory Certificate Services), tick *Use SSL-based Encryption* 6. Expand the objects in the tree at the left until you find the container containing the computer object for the server exhibiting the issue, such as `CN=Computers` 7. Right-click on the container object and choose *Properties* 8. Click the *Security* tab 9. Click "Advanced" 10. Click "Add..." 11. In the box labeled *Enter the name of the object to select*, enter `NETWORK SERVICE` 12. In the drop-down list labeled *Apply to*, select `Descendant Computer objects` 13. Scroll all the way to the bottom of the *Permissions* list and tick the box in the *Allow* column for `Validated write to service principal name` 14. Tick *Apply these permissions to objects and/or containers within this container only* 15. Click "OK" 16. Click "OK" 17. Click "OK" 18. Repeat steps 6-17 for any container with computer objects for hosts on which PowerShell Remoting is enabled 19. Restart the *Windows Remote Management (WS-Management)* service on the affected hosts 18. Run `setspn -l ` with elevated privileges on a domain controller to verify that the SPN was correctly created

[dustinhatch-blog]

Diablo III: Imacah (my demon hunter) [updated]

[dustinhatch-blog]

Guild Wars 2 Beta: Beautiful water. The reflections didn't render correctly in the screenshot, but they look amazing in game.

[dustinhatch-blog]

Guild Wars 2 Beta: Underwater combat

[dustinhatch-blog]

Guild Wars 2 Beta: PUG killing the giant boar. Someone's cat is going the wrong way...

[dustinhatch-blog]

Guild Wars 2 Beta: Chopping down a tree!

[dustinhatch-blog]

Guild Wars 2 Beta: HD Screenshots

[dustinhatch-blog]

Guild Wars 2 Beta: "My Story" dialog between an NPC (left) and my toon (right)

[dustinhatch-blog]

Guild Wars 2 Beta: Mesmer combat with 2 illusions

[dustinhatch-blog]

Aisnolainadra: I earned this achievement: Favorful! #Rift

[dustinhatch-blog]

Growl Notifications in Outlook 2010

One particular UI feature that I have always felt like Windows was missing when compared to Linux was a universal notification mechanism. On Linux there is libnotify, and most desktop applications that send notifications can use it. On Windows, the closest thing we have are “notification balloons.” More often than not, though, applications either don’t use them or use them poorly (including Windows itself, as admitted by Microsoft in their official Notifications documentation).

Enter Growl for Windows. Growl has (apparently) been around for a while on OS X, but is now gaining popularity on Windows. I’ve used it (and a similar utility called Snarl) a couple of times in the past, but only recently has it become stable and usable enough that I can leave it permanently installed and running on my Windows computers. Even still, there are a couple of notification features that are missing, most notably new mail notifications from Outlook 2010.

I spent a bit of time today whipping up a quick VBA script for Outlook in order to remedy that problem. Here’s how to make it work:

Launch Outlook 2010 and hit Alt+F11 on the keyboard to bring up the Microsoft Visual Basic for Application IDE.

Click Insert > Module

Enter this code in the blank window on the right:

Option Explicit Const GrowlNotifyCmd As String = _ """C:\Program Files (x86)\Growl for Windows\growlnotify.exe""" Sub GrowlNotify(Item As Outlook.MailItem) Dim MailIcon As String MailIcon = Environ("LocalAppData") + "\Microsoft\Outlook\Mail.png" ' Register the application with Growl Shell (GrowlNotifyCmd + " /a:Outlook /r:""New Message"" " + _ "/ai:" + MailIcon + " .") ' Send a New Message notification Shell (GrowlNotifyCmd + " /a:Outlook /n:""New Message"" " + _ "/t:""New mail from " + Item.SenderName + """ " + _ """" + Item.Subject + """") End Sub

Click File > Save VbaProject.OTM

Close the Microsoft Visual Basic for Applications window

In the main Outlook window, make sure the Home ribbon tab is visible

Click Rules > Manage Rules & Alerts

Click the New Rule... button

Click Apply rule on messages I receive (under Start from a blank rule)

Click Next >

Click Next >; Click Yes when Outlook prompts to confirm the rule will be applied to every message

Scroll down in the Step 1: Select action(s) box and tick run a script

In the Step 2: Edit the rule description (click an underlined value) box, click a script

Select Project1.GrowlNotify from the Scripts box and click OK

Click Next >

Click Next >

In the Step 1: Specify a name for this rule box, enter Growl Notification

Click Finish

Click OK

In order for the notifications to have an icon, you'll need to download an image and save it on your computer. I like the Mail Icon from the Sleek XP Basic set by deleket, but you can pick any icon square icon at least 64x64 px. Save it to C:\Users\<username>\AppData\Local\Microsoft\Outlook\Mail.png, or adjust the path in the MailIcon constant in the script above.

Edit: After a day or so, this stopped working for me. It turned out to be related to Outlook's macro security settings. In order to get it to run again, I had to add a digital signature to my macro project. You can read more about that at Digitally sign your macro project