Icicle Buttress – Trad/Multipitch

My good friend Wes and I climbed Icicle Buttress today.   The R&D route on Icicle Buttress is a classic trad route which is deemed as “easy”.  The “Leavenworth Rock” guide by Viktor Kramar describes the route as

This easy , roadside, multi-pitch route is very popular and has been the scene of several rescues and other oddball antics over the years.

Pitch 1 & 2: Wander up one of several 5- variations, aiming for the chimney to the right of Cocaine Crack.

Pitch 3: Climb the chimney to the right of Cocaine Crack.

Pitch 4: Either of 2 cracks can be taken to the top (5.6)

Our plan was to do a variation which uses a route to the right known as “Cocaine Connection” (route #27) — it’s a 5.7 bolted/trad route which connects to route #28 below the chimney as show in the route map below.

Icicle Buttress Route Map

Given the weather and rock conditions today, we looked at the 5.7 variation and I didn’t like the water run off we were seeing from up top — the slab was wet to the first bolt.  In the picture below, the area shown by the green line is the approximate described route when completely dry.

We started with the walk-up variation and I found a good place to set a belay anchor to prepare for the 2nd pitch.  It was here where I was contemplating the gully and the area to the right of it was wet, not favorable to cross.   This may have gained the ledge to the normal traverse to the chimney.  Wes saw a crack line that traversed to the left and up and looked like a reasonable approach.  I headed out on the ledge and traversed the crack.   It thinned out.  I tried calling to Wes but the river noise and wind prevented voice communications.  I realized I was committed on this line.

The green line is the 5.7 variation, the circled areas are approximate anchor stations in the first couple of pitches.  The 5.7 seems to have an anchor/belay station not noted in the book — I’d need to look at this closer when out on site again but from other pictures this seems to be the case now.

Icicle Buttress

Among several friends, we’ve agreed that the ratings in the Leavenworth book are sandbagged compared to other areas — e.g. we expect a 5.7 to have 5.8 moves. But I knew I definitely was not on a 5.6 (5.7) route at this point.   Comparatively, I regularly lead sport in the gym (comfortably) to 5.10b, I’m projecting 5.11+.   I’ve lead 5.8/5.9+ routes in Vantage and climb 5.10+ outdoors as a second.  Over the years, I’ve taken courses with International Mountain Guides, American Alpine Institute, Northwest Mountain Schools and Vertical World (Redmond) — the classes and training has proven invaluable.  We were no longer on a beginner trad climb.

[Edit: After reviewing another guide book (Rock Climbing Washington), Cocaine Crack is further left of where we were climbing but there is a 5.10a variation on R&D that is noted on page 280.  This variation "passes the prominent roof low on the route", is left of the gully and rejoins under the chimney.]

I needed to do more advanced weight shifting on my feet (than expected for a 5.6) to stay while I was placing gear and moving up on this line.  I reached a point to set another directional piece and then traverse right back towards the chimney entrance.   The pitch now involved a slab run-out with no place to set gear to protect.   I found my way to a crack system below the chimney, set my gear anchor, hooked in, backed myself up and then started taking in the slack.   Wes and I were only able to communicate by the rope and knowing the stages of our rope management.   Before our departure, I shared with Wes the steps we’d have at the belay anchors and we quickly reviewed on the first pitch but now we were unable to use voice commands and he was out of sight.

Happy that he understood the rope motions with pulling in the slack and keeping tension, etc.,  Wes was soon on belay and climbing.  I continued to belay as he made his way up the route, waiting for helmet to appear in my view as I waited to see him traverse to reach the slab area.  After a bit of belaying, I finally heard a voice command “Take!”.   I quickly set more tension and then the rope quickly loaded, I felt a jar and then I fully loaded the anchor system.  Wes had finished cleaning the last piece of gear on the traverse and then lost his footing and did a pendulum swing (but thankfully not a full whipper because of the angle of the pitch) and held directly below my position.

We were able to communicate at this point and I was able to lower him back on to the traverse section so he could regain footing and begin the traversal again.

As I mentioned, I have been fortunate to have taken part in some great training programs the last couple of years.  One of my favorite books on preparing for climbing is by John Long and Bob Gaines “Climbing Anchors, 2nd Edition”.  After a lot of field testing and lab stress testing, the authors have proposed the “equalette” rigging of cordelette as a preferred equalizing solution for anchor systems.  There are always pros and cons of all systems but I’ve become convinced this is a great system because of its ease of setup and versatility.  I am using this in both top rope (as a quadalette) and in trad-anchor systems as the equalette.

The anchor in place when Wes lost his footing was a three-piece gear anchor consisting of two cams and a nut near a constricting crack system at the base of the chimney.  All protective pieces held and the nut wedged further into the constriction.

After Wes completed the pitch, we continued the route, and up the chimney.  The weather started rolling in and a mist was dampening the rock.   We finished up the crack system to the finishing 5- walkup to the top of the buttress.   I guess the two notable cracks we saw before the finishing pitch were the 5.6 designated cracks, but they felt harder — perhaps it was the conditions.  The chimney is noted to be 5.5 but it seemed harder than other 5.8 chimneys that I have pulled, it’s short section, only a couple of moves but they seemed more difficult than other 5.8 chimneys that I’ve done.

I’m not sure if R&D is easy or a walk-up as you’d expect for a 5.6 route, perhaps we were way off — but I know the chimney and crack system is in the original R&D route.   I would not recommend this for beginner trad climbers and perhaps that is the reason for the note regarding “several rescues.”

It is one thing to study and practice rock climbing anchor systems and methodology, it is another to load and to know it is saving your life.  There is no “easy” 5.something — bomber placements and bomber anchors are a must.  The experts remind you, the books teach you, the guides show you — reality will verify it.


GitLab 4.2-Stable and LDAP with ActiveDirectory

Enabling LDAP on Gitlab 4.2-Stable seemed straightforward, but then I hit a number of issues with authentication outside of the GUI.

First, the documentation from the main link is woefully inadequate, but I stumbled upon this link on Setting up LDAP Auth which helped with some of the specifics.

The second issue I ran into authenticating against ActiveDirectory LDAP and GitLab is an error message that reports that accounts must have both an uid and an email.  It took a bit to track this down but finally I found a reference to this commit from a fork by “syndicut” which addresses a problem in the user mapping.  The config mapping as it exists in ldap.rb below fails because the mapping does not move beyond the initial check — a .respond_to? check is added to handle the lookups correctly.   There are some posts that refer to changing the order to work around the problem, I applied the code changes in ldap.rb so that it works as expected.

@@config = {
	'name' => 'cn',
	'first_name' => 'givenName',
	'last_name' => 'sn',
	'email' => ['email', 'mail', 'userPrincipalName'],
	'phone' => ['telephoneNumber', 'homePhone', 'facsimileTelephoneNumber'],
	'mobile' => ['mobile', 'mobileTelephoneNumber'],
	'nickname' => ['uid', 'userid', 'sAMAccountName'],
	'title' => 'title',
	'location' => {"%0, %1, %2, %3 %4" => [['address', 'postalAddress', 'homePostalAddress', 'street', 'streetAddr$
	'uid' => 'dn',
	'url' => ['wwwhomepage'],
	'image' => 'jpegPhoto',
	'description' => 'description'

Another critical issue that I hit was related to LDAP auth with git over https versus ssh.
Basically, I want to authenticate over LDAP when cloning or creating a new git repo such as:

git clone https://gitlab.mydomain.com/test-project.git "Test Project"

This one was a bit more involved but I found a reference to an issue tracking this and a related pull request. GitLab Pull Request 2557 adds support to authenticate users in the grack module. Once this is applied, the git over https scenario works with LDAP authenticated users.

Finally, I wanted to restrict user logins to those groups with GitLab permissions. GitLab/OmniAuth-Ldap Pull Request 3 and GitLab Pull Request 2497 from user dimaj updates omniauth-ldap to apply a more general ldap filter rather than a specific uid filter when validating logins.  Applying these changes will enforce a user’s membership in a specific security group.

I have one remaining issue to address and that’s to enforce TLS over 389 with ActiveDirectory. This currently fails to authenticate in simple_tls mode and I have more debugging and digging through commits to find or fix this particular failure case.

Gitlab 4.0-Stable on Ubuntu 12.04, SSL & Apache2

After a bunch of trial and error, I was able to get GitLab running on Apache2 supporting large payloads with SSL.
Special thanks to some pointers on the passenger module install from Nick Yeoman.

  • Configure gitlab.yml for SSL
## GitLab settings
  ## Web server settings
  host: gitlab.<your-domain>
  port: 443
  https: true
  • Install the passenger module for Ruby & Apache2:
sudo gem install passenger
sudo passenger-install-apache2-module

The passenger installer will note that these lines will need to be added to the Apache config:

LoadModule passenger_module /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.15/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.15
PassengerRuby /usr/local/bin/ruby
  • Enable rewrite for http: -> https: (optional)
sudo a2enmod rewrite
  • Create the gitlab conf in apache2
sudo vim /etc/apache2/sites-available/gitlab
LoadModule passenger_module /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.19/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/lib/ruby/gems/1.9.1/gems/passenger-3.0.19
PassengerRuby /usr/local/bin/ruby

<VirtualHost *:80>
        ServerName gitlab.<your.domain>

        # Redirect from HTTP to HTTPS
        RewriteEngine   on
        RewriteCond     %{SERVER_PORT} ^80$
        RewriteRule     ^(.*)$ https://%{SERVER_NAME}$1 [L,R]
<VirtualHost *:443>
        ServerName gitlab.<your.domain>
        ServerAdmin gitlab@<your.domain>

        SSLEngine On
        SSLCertificateFile /etc/apache2/ssl/<cert.file>
        SSLCertificateKeyFile /etc/apache2/ssl/<cert.key>
        SSLCertificateChainFile /etc/apache2/ssl/<chain-file.crt>

        # Point this to your public folder of gitlab
        DocumentRoot /home/gitlab/gitlab/public
        <Directory /home/gitlab/gitlab/public>
                # This relaxes Apache security settings.
                AllowOverride all
                # MultiViews must be turned off.
                Options -MultiViews

        CustomLog /var/log/apache2/gitlab-access.log combined
        ErrorLog  /var/log/apache2/gitlab-error.log
  • Enable the site and restart Apache2
a2ensite gitlab
sudo service apache2 restart

ARM/MSVC Build Environment Script

I added a Perl script to the repository Build/CopyBuildToolset.cmd at https://github.com/bawoodruff/BeagleBoard.  More details on the repo is here.

The script documentation is lacking and I’ll add more in the next few days.

The script populates the Build directory with a toolset from the Windows 7 DDK/SDK and Visual Studio 11 for the ARM installations and copies minimal Windows SDK headers to build the supporting Windows based tools for PE image conversion and ROM image signature for the BeagleBoard as part of the build toolset.

The script uses the MSVCToolChainForARM.INI file which describes the source locations and target layout for the tool chain.  A few sample snippets from the .INI are below.   The first column describes the file source which is one of ddk, sdk or msvc.

ddk,    bin\x86\amd64\build.exe,                        amd64
ddk,    bin\x86\build.exe,                              x86
ddk,    bin\x86\binplace.exe,                           x86
sdk,    Bin\rc.exe,                                     x86
sdk,    Bin\RcDll.Dll,                                  x86
sdk,    Bin\x64\rc.exe,                                 amd64
sdk,    Bin\x64\RcDll.Dll,                              amd64
sdk,    Include\BaseTsd.h,                              sdk\inc
msvc,   VC\bin\x86_arm\armasm.exe,                      vc\x86_arm
msvc,   VC\bin\x86_arm\c1.dll,                          vc\x86_arm
msvc,   VC\bin\x86_arm\c1ast.dll,                       vc\x86_arm

The first column describes the file source which is one of ddk, sdk or msvc.  These are currently defined in the script as below and can be configured with command line options –ddk, –msvc, –sdk respectively.   The script currently assumes it is running under the beagle.cmd environment and that BEAGLE_BUILD_PATH has been set to the Build directory of the enlistment.

my %srcPathMap = (
  ddk     => 'C:\\WinDDK\\7600.16385.1',
  msvc    => 'C:\\Program Files (x86)\\Microsoft Visual Studio 11.0',
  sdk     => 'C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A'
Given this configuration, the build script copies the files as described in the .INI (second column) to the Build directory and target destination directories (third column).
When completed, a CMD.exe launching beagle.cmd specifying the ARM build type will be ready to build the XLoader image.
c:\windows\System32\cmd.exe /k c:\beagleboard\build\beagle.cmd arm
C:\BeagleBoard>cd OS

C:\BeagleBoard>rem bcz is an alias for build.exe -cZ

BUILD: Compile and Link for ARM
BUILD: Start time: Sat Jan 05 09:58:50 2013
BUILD: Examining c:\beagleboard\os directory tree for files to compile.
BUILD: rmdir /q/s c:\beagleboard.obj.arm\os
1>BUILD: Compiling (NoSync) c:\beagleboard\os\bootloader\board directory
2>BUILD: Compiling (NoSync) c:\beagleboard\os\bootloader\common directory
3>BUILD: Compiling (NoSync) c:\beagleboard\os\bootloader\disk directory
4>BUILD: Compiling (NoSync) c:\beagleboard\os\bootloader\drivers directory
5>BUILD: Compiling (NoSync) c:\beagleboard\os\bootloader\filesystem\fat directory
6>BUILD: Compiling (NoSync) c:\beagleboard\os\bootloader\runtime directory
1>Assembling - bootloader\board\arm\platform.s
6>Assembling - bootloader\runtime\arm\_div10.s
5>Compiling - bootloader\filesystem\fat\fat.c
3>Compiling - bootloader\disk\part.c
2>Compiling - bootloader\common\cmd_load.c
4>Compiling - bootloader\drivers\serial.c
6>Assembling - bootloader\runtime\arm\_delay.s
6>Assembling - bootloader\runtime\arm\_dcc.s
6>Compiling - bootloader\runtime\board.c
1>Compiling - bootloader\board\omap3530beagle.c
4>Compiling - bootloader\drivers\k9f1g08r0a.c
5>Compiling - bootloader\filesystem\fat\file.c
6>Compiling - bootloader\runtime\div0.c
6>Compiling - bootloader\runtime\dcc.c
4>Compiling - bootloader\drivers\ns16550.c
6>Compiling - bootloader\runtime\ecc.c
4>Compiling - bootloader\drivers\omap24xx_i2c.c
5>Compiling - bootloader\filesystem\fat\generating code...
6>Compiling - bootloader\runtime\printf.c
2>Building Library - c:\beagleboard.obj.arm\os\bootloader\common\obj\arm\common.lib
3>Building Library - c:\beagleboard.obj.arm\os\bootloader\disk\obj\arm\disk.lib
1>Building Library - c:\beagleboard.obj.arm\os\bootloader\board\obj\arm\board.lib
6>Compiling - bootloader\runtime\_udiv.c
4>Compiling - bootloader\drivers\generating code...
5>Building Library - c:\beagleboard.obj.arm\os\bootloader\filesystem\fat\obj\arm\fat.lib
6>Compiling - bootloader\runtime\generating code...
4>Building Library - c:\beagleboard.obj.arm\os\bootloader\drivers\obj\arm\drivers.lib
100>BUILD: Compiling c:\beagleboard\os\bootloader\runtime directory
100>Building Library - c:\beagleboard.obj.arm\os\bootloader\runtime\obj\arm\runtime.lib
1>BUILD: Compiling and Linking c:\beagleboard\os\bootloader\cpu directory
1>Assembling - bootloader\cpu\arm\start.s
1>Compiling - bootloader\cpu\cpu.c
1>Compiling - bootloader\cpu\gpio.c
1>Compiling - bootloader\cpu\mmc.c
1>Compiling - bootloader\cpu\sys_info.c
1>Compiling - bootloader\cpu\generating code...
1>Linking Executable - c:\beagleboard.obj.arm\os\bootloader\cpu\obj\arm\x-load.exe
1>MUI_COMMENT: Not Localizeable X-Load.exe
1>Binplacing - c:\beagleboard.obj.arm\os\bootloader\cpu\obj\arm\mlo
BUILD: Finish time: Sat Jan 05 09:58:56 2013

    38 files compiled
    6 libraries built
    1 executable built
    1 file binplaced


ARM Development

My current development environment includes an ARM Cortex-A8 / TI DM3730 based BeagleBoard-xM and the Flyswatter2 JTAG Debugger. As part of my introduction to the environment, I modified the XLoader boot loader and developed a set of tools by borrowing from the Windows 8 DDK/SDK and Visual Studio C++ (MSVC) ARM compiler and assembler.  Using this Microsoft ARM tool chain generates COFF based images rather than ELF as with the GNU toolchain.  To address COFF images, I also created a coff2bin tool to generate the loader image from the linked image.

My plan is to modify the loader to expose a KD interface so that debugging can be performed with WinDBG rather than GDB.

These efforts are really only intended to gain more low-level experience on the ARM hardware, demonstrating how to configure the MSVC tool chain to generate the relevant Thumb-2 code.

My current public GIT repo is at https://github.com/bawoodruff/BeagleBoard where I will keep a shadow of the MSVC build environment that I’m using and a set of scripts to populate the tools directories based on installed DDK/SDK/MSVC tool chains.

GIT repository for ARM/BeagleBoard-XM development environment

I’ve created a shadow of the base build environment at https://github.com/bawoodruff/BeagleBoard which will contain the base X-Loader sources and build environment.

This environment uses the makefile.def/build.exe style command line build configured for ARM, below is the output from build as an example:

BUILD: Compile and Link for ARM
BUILD: Start time: Wed Jan 02 19:08:08 2013
BUILD: Examining k:\projects\beagleboard directory tree for files to compile.
BUILD: rmdir /q/s k:\projects\beagleboard.obj.arm
1>BUILD: Compiling (NoSync) k:\projects\beagleboard\os\bootloader\board directory
2>BUILD: Compiling (NoSync) k:\projects\beagleboard\os\bootloader\common directory
3>BUILD: Compiling (NoSync) k:\projects\beagleboard\os\bootloader\disk directory
4>BUILD: Compiling (NoSync) k:\projects\beagleboard\os\bootloader\drivers directory
5>BUILD: Compiling (NoSync) k:\projects\beagleboard\os\bootloader\filesystem\fat directory
6>BUILD: Compiling (NoSync) k:\projects\beagleboard\os\bootloader\runtime directory
1>Assembling - os\bootloader\board\arm\platform.s
2>Compiling - os\bootloader\common\cmd_load.c
6>Assembling - os\bootloader\runtime\arm\_div10.s
3>Compiling - os\bootloader\disk\part.c
4>Compiling - os\bootloader\drivers\serial.c
6>Assembling - os\bootloader\runtime\arm\_delay.s
4>Compiling - os\bootloader\drivers\k9f1g08r0a.c
1>Compiling - os\bootloader\board\omap3530beagle.c
6>Assembling - os\bootloader\runtime\arm\_dcc.s
5>Compiling - os\bootloader\filesystem\fat\fat.c
2>Building Library - k:\projects\beagleboard.obj.arm\os\bootloader\common\obj\arm\common.lib
3>Building Library - k:\projects\beagleboard.obj.arm\os\bootloader\disk\obj\arm\disk.lib
4>Compiling - os\bootloader\drivers\ns16550.c
4>Compiling - os\bootloader\drivers\omap24xx_i2c.c
5>Compiling - os\bootloader\filesystem\fat\file.c
6>Compiling - os\bootloader\runtime\board.c
4>Compiling - os\bootloader\drivers\generating code...
5>Compiling - os\bootloader\filesystem\fat\generating code...
1>Building Library - k:\projects\beagleboard.obj.arm\os\bootloader\board\obj\arm\board.lib
6>Compiling - os\bootloader\runtime\div0.c
6>Compiling - os\bootloader\runtime\dcc.c
6>Compiling - os\bootloader\runtime\ecc.c
5>Building Library - k:\projects\beagleboard.obj.arm\os\bootloader\filesystem\fat\obj\arm\fat.lib
6>Compiling - os\bootloader\runtime\printf.c
4>Building Library - k:\projects\beagleboard.obj.arm\os\bootloader\drivers\obj\arm\drivers.lib
6>Compiling - os\bootloader\runtime\_udiv.c
6>Compiling - os\bootloader\runtime\generating code...
100>BUILD: Compiling k:\projects\beagleboard\os\bootloader\runtime directory
100>Building Library - k:\projects\beagleboard.obj.arm\os\bootloader\runtime\obj\arm\runtime.lib
1>BUILD: Compiling and Linking k:\projects\beagleboard\os\bootloader\cpu directory
1>Assembling - os\bootloader\cpu\arm\start.s
1>Compiling - os\bootloader\cpu\cpu.c
1>Compiling - os\bootloader\cpu\gpio.c
1>Compiling - os\bootloader\cpu\mmc.c
1>Compiling - os\bootloader\cpu\sys_info.c
1>Compiling - os\bootloader\cpu\generating code...
1>Linking Executable - k:\projects\beagleboard.obj.arm\os\bootloader\cpu\obj\arm\x-load.exe
1>MUI_COMMENT: Not Localizeable X-Load.exe
1>Binplacing - k:\projects\beagleboard.obj.arm\os\bootloader\cpu\obj\arm\mlo
BUILD: Finish time: Wed Jan 02 19:08:10 2013

    38 files compiled
    6 libraries built
    1 executable built
    1 file binplaced



JavaSvc Released – December 3, 2011

JavaSvc is a native C++ Windows service for hosting a Java class/application in a Windows service context.  JavaSvc uses JNI to host a Java VM and to provide the Windows service context for the Java application.   JavaSvc is completely configurable via a .INI file to provide drag/drop installation.   Sample .INI configurations for Minecraft and CraftBukkit are provided.

Changes for

Added additional support for separate class for a shutdown plugin, required for
Bukkit plugins with Minecraft.

Added support for context class loaders — and will enumerate threads looking for
the specified class if the global FindClass() fails.

JavaSvc- MD5: 22fbae2a2f0339e33095e7c45c02f972

JavaSvc Released

JavaSvc is a native Java VM host which will register and run a Java class as a Windows service.

The primary motivation in developing this host was to provide an environment to host a Java based service in a restricted context (Network Service) rather than a common practice of using the active user’s interactive account.  Using a system account provides a mitigation to the security concern of maintaining least-privilege for these Java based components.

After searching for solutions to simplify the configuration process for running a Java based service on Windows, I opted to develop my own solution as I didn’t find anything that was trivial to configure and copy/drag/drop to install.

JavaSvc- MD5: ddc13da6ce3e2e23fdde269677a071a0

Tags: Minecraft, Bukkit, Server, Java, Windows, Service