Installing IPython Notebook on Redhat

I wanted in install IPython Notebook and got tripped up on sqlite dependencies.  Here is what worked:


# Install support libraries for python 2.7
yum groupinstall -y 'development tools'
yum install -y zlib-devel bzip2-devel openssl-devel xz-libs wget sqlite-devel

# Prepare, build and install python 2.7 as an alternate (don't mess with system python 2.6)
cd /usr/src
wget https://www.python.org/ftp/python/2.7.8/Python-2.7.8.tgz
tar xzf Python-2.7.8.tgz
cd Python-2.7.8
./configure
make altinstall

# Make sure Python 2.7 exec is available
export PATH="/usr/local/bin:$PATH"

# Check Python 2.7 and sqlite before moving forward
python2.7 -c 'import sqlite3'  # should have no output, especially errors

# Install setup tools (needed to install pip)
cd ..
wget --no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-1.4.2.tar.gz
tar -xvf setuptools-1.4.2.tar.gz
cd setuptools-1.4.2

# Install setup toos into python 2.7
python2.7 setup.py install


# Install pip
cd ..
curl https://raw.githubusercontent.com/pypa/pip/master/contrib/get-pip.py | python2.7 -
pip --version

# Use pip to install ipython notebook
pip install "ipython[notebook]"

# start it up (in background—maybe should use screen)
# Note use of ip parm to avoid issue with not runnin IPV6, per:
# https://github.com/ipython/ipython/issues/5802

# cd to the directory that you want to serve your notebooks from and…
ipython notebook --ip 127.0.0.1

# the --ip 127.0.0.1 was to avoid a problem with not running IPv6 (you may be able to leave that off)

# Then open http://localhost:8888/ and you should be up and running

Most of the python is derivative of this page:

http://bicofino.io/blog/2014/01/16/installing-python-2-dot-7-6-on-centos-6-dot-5/

But in my case, that one comment by Teodor-Bogdan Barbieru was key... including sqlite-devel in the prerequisites.  The above probably works on Centos too.

Gnome Desktop Blank Screen (spinner never goes away)

UPDATE:  The root cause of this issue was that GDM AutomaticLogin was enabled in /etc/gdm/custom.conf but the login account had an expired password.  The problem went away when this was resolved.

Using the Cloudera CDH Quickstart VM 5.1 converted to a VMware template and running on ESXi 5.5, I was frequently getting a never ending spinner on the console to the graphical desktop (so basically, there was a blank black screen with the spinning "beachball").  It wasn't totally repeatable but it was happening more than half the time.  The VM uses Centos 6.5 under the hood.  

The fix was to kill the gnome gdm-simple-slave process, which then automatically restarts.  This would cause the console to flash and then the desktop would come up.  This command will do it:

pkill -o -f gdm-simple-slave

You can either ssh directly into the machine to run this, or do a Ctrl-Alt-F6 to switch the console to a command line and run it.

I'm not sure what the underlying problem is that's causing this but at least this can get past it.

Git ignore pattern in a file not working? Watch out for spaces on the line!

I couldn't figure out why a git ignore pattern applied via:

git config --global core.excludesfile

wasn't working.  Turns out there were spaces at the end of the pattern line that were preventing it from working.  According to the docs, spaces at the end of lines aren't supposed to matter:

Trailing spaces are ignored unless they are quoted with backlash ("\") 

ref:  http://git-scm.com/docs/gitignore

However, it did in this case.  Perhaps this is just an issue with Git on Windows.

TIP:  Use the following to test out your ignore patterns in dry run mode via -n:

git add -n *

Ambari Cluster Provisioning Failure -- No More Mirrors To Try

Saw this when trying to re-provision a cluster after doing an "ambari-server reset" (Ambari 1.6.1 on Redhat 6.5):

Fail: Execution of '/usr/bin/yum -d 0 -e 0 -y install hadoop-yarn' returned 1. Error Downloading Packages:

  hadoop-yarn-2.4.0.2.1.5.0-695.el6.x86_64: failure: hadoop/hadoop-yarn-2.4.0.2.1.5.0-695.el6.x86_64.rpm from HDP-2.1: [Errno 256] No more mirrors to try.

  hadoop-2.4.0.2.1.5.0-695.el6.x86_64: failure: hadoop/hadoop-2.4.0.2.1.5.0-695.el6.x86_64.rpm from HDP-2.1: [Errno 256] No more mirrors to try.

  zookeeper-3.4.5.2.1.5.0-695.el6.noarch: failure: zookeeper/zookeeper-3.4.5.2.1.5.0-695.el6.noarch.rpm from HDP-2.1: [Errno 256] No more mirrors to try.

The solution was to do a "yum clean all" on the agents and retrying (requires doing all the "ambari-server reset" and agent cleanup again).

Debugging Gotcha With .Net's System.Diagnostics.Debugger.Break()

In developing a SharePoint feature deployed at web application scope, I was trying to attach the debugger to the w3wp.exe process so I could see what was going on in my code. I used the iisapp command to try and pick the logical process... no dice. So then I connected to ALL of the w3wp process (there were 5 for them). It still wouldn't hit my breakpoint. So then I threw a

System.Diagnostics.Debugger.Break();

statement into my feature's code. When the feature activated, as expected I was given the option of selecting the debugger I wanted to use. So I chose my current VS2008 session. And here's the kicker--the next thing that happens is a dialog pops up telling you that "There is no source available at the current location". Now I had already dealt with all kinds of problems with missing symbols getting to this point, and I thought this was just the next level in the rathole I had been down on that issue. I was about to give up, but then I notided that the Call Stack pane was actually showing that the process was stopped down inside the System.Diagnostics assembly (which makes sense). All I had to do was a Debug > "Step Out" and I was back in my code, ready to debug.

SharePoint Feature Scope Changes Ignored

The Problem

I ran into a situation where I had deployed a broadly scoped feature and then narrowed the feature scope down, but the feature was acting like it still had the original scope settings. The feature was a delegate control to deploy JQuery using the AdditionalPageHead delegate control, just like Jan Tielens described here. When I had the feature scoped to the site collection (Scope="Site"), it was auto-deploying across the site collection as expected. But then when I tightened the scope down to specific websites (Scope="Web") and added a Scope="false" to make it require manual activation, it was behaving as if the it was still scoped at the site collection and was still auto-deploying. This continued even when I completely deleted the solution.

The Fix

After completely deleting the solution, I updated the solution and feature with new GUIDs. Thereafter, it behaved as expected. It seemed to behave like some remenant of the solution wasn't fully removed by from the solution store even though the solution was deleted. Here's a related forum posting on the issue. If it was something I did wrong, then I doubt changing the feature and solution GUIDs would have fixed it--that's my story anyway.

I'll also mention that I tried developing this with VSeWSS 1.3 but was frustrated by it always creating an assembly (even for the "empty" project template) which couldn't be removed without breaking things. I fell back to STSDEV which is remains my tool of choice.