The site is telling me I've hit 500 blog entries:

 Kool Aid Served Daily
Link 	http://blogs.sun.com/tdh
Permission 	ADMIN
Description 	For the Adrenaline Junkie
Members: 	1
Today's hits: 	3240

	New Entry
Entries (500)
Comments (281)
Theme
Settings 

And they said this Internety thing would never take off!

In Setting up a Development Project Gate, I showed you the steps I took to setup a shared development gate. The only thing I left out was the automatic push to a Mercurial repository on OpenSolaris. I'll take you through these steps now.

By the way, thanks to Dave Marker for sharing how ONNV does this and writing some Python tools to automate the majority of the push.

Get a repository

First you need to get a project leader for your project to create a workspace for you on hg.opensolaris.org. They can do this by logging to OpenSolaris and going to the project page. Then they select 'SCM Management'. Next 'Add Repository' and remember to click the Mercurial radio button on the next screen. The page is pretty explanatory and the only thing to remember is that it might spew up a message about the project already existing. It also seems to take 5-10 minutes for the project space to show up.

Which if you know about it is okay. You can take this time to configure who has commit rights. (You'll need one account for sure, more on that later.)

As evidenced in Setting up a NFS41 gate, I had a hard time figuring out where the gate was located. It can be reached as:

hg clone ssh://anon@hg.opensolaris.org/hg/<PROJECT>/<GATE-NAME>

Note you need to configure anonymous access on the repository page for this to work. I'm not sure, but I believe this also implies anyone can write back to the gate. Tie this in with a lack of tools to maintain the gate out there (including deletion) and you can see this might be a problem.

Configure a SSH public key

This part is the scary part - scary in that you have to decide if you want automatic pushes or manual pushes.

Manual pushes

If you want manual pushes, then you need to make sure you have a SSH public key setup as described in opensolaris.org SSH key help. Then whenever you want to push a change, you would do:

hg push -R <your gate> -e "ssh -q -F ssh://<YOUR OSOL USERNAME>@hg.opensolaris.org/hg/<PROJECT>/<GATE-NAME>"

You don't have to read much more of the rest of this entry, except perhaps to make sure your proxy host is correct.

Automatic pushes

If you want automatic pushes, then you need to configure a special key pair without a passphrase. Note that this is a risk you need to manage yourself. It needs to be blank because you don't want to even store the passphrase anywhere. I've done this type of thing in the past for production systems and the trick is that you want to lock down the box you have stored the private version of the key

Follow the directions as described in opensolaris.org SSH key help to publish this key. Note that no-one will know that this passphrase is empty for this key. They still need the private copy of the key. We have to make sure that is locked down tight!

• Use a system with a non-standard root password.
• Strictly control admin access to the system
  • Don't hand out the root password.
  • Don't make sudo too permissive.
• Pick a non-global account to store the data in.
• Make sure the permissions are 700 on the directory where the key is stored.
• If you share that homedir, make sure to read The myth of security with AUTH_SYS, which means:
  • Do not accept the default access list ooptions.
  • Set root= or use anon=-1.
  • Set the rw= and/or ro= hosts appropriately.
  • Strongly consider kerberizing the share.

There is probably more you can do, so the first thing is to accept responsibility for this setup.

Okay, having scared you, it is now time to configure this special ssh configuration:

[nfs4hg@aus1500-home ~/tmp]> mkdir opensolaris
[nfs4hg@aus1500-home ~/tmp]> chmod 700 opensolaris/
[nfs4hg@aus1500-home ~/tmp]> cp ~/opensolaris/* .
[nfs4hg@aus1500-home ~/tmp]> more config 
Host *.org
        GlobalKnownHostsFile /pool/nfs4hg/opensolaris/known_hosts
        ProxyCommand /usr/lib/ssh/ssh-socks5-proxy-connect -h 192.18.43.19 %h %p
        IdentityFile /pool/nfs4hg/opensolaris/id_dsa
        User <YOUR OSOL USERNAME>

You'll have to figure out whether or not you need the proxy configuration or not. And you will need to fix-up the paths for the GlobalKnownHostsFile and IdentityFile.

Also note that I've got this account already setup with a ~/.ssh directory to allow integrations to the gate. It doen't have DS keys, but I like to keep these apart. And note that id_dsa and id_dsa.txt are the keypair that you generated with the empty passphrase.

Edit hook/updateoso.py

In the copy of hook/updateoso.py I got from ssh://anon@hg.opensolaris.org/hg/scm-migration/onnv-gk-tools, I had the following minor diffs:

[nfs4hg@aus1500-home ~]> diff /pool/onnv-gk-tools/hook/updateoso.py onnv-gk-tools/hook/updateoso.py
33c33
< OSOREPO = "ssh://hg.opensolaris.org/hg/nfsv41/nfs41-gate"
---
> OSOREPO = "ssh://hg.opensolaris.org/hg/onnv/onnv-gate"
43c43
< This script must be run as user "nfs4hg".
---
> This script must be run as user "onhg".
76c76
<     home = pwd.getpwnam("nfs4hg")[5]
---
>     home = pwd.getpwnam("onhg")[5]
95c95
<     if utility.check_user("nfs4hg", m) is False:
---
>     if utility.check_user("onhg", m) is False:
97c97
<         m.write('''Can't update OpenSolaris. User != "nfs4hg"\n''')
---
>         m.write('''Can't update OpenSolaris. User != "onhg"\n''')

Note that I grabbed this script right after Dave Marker put it back, so I got a cutting edge version of it. I know he is about to change it such that the user and osol path are configurable variables outside of this file. I.e., you would make changes in a project specific configuration file.

Anyway, once those changes are made, go a head and make sure this line is enabled in your official clone's hgrc:

# These hooks are run from bghook() in the background
bg-changegroup.0 = python:hook.updateoso.updateoso

I'm assuming you have modeled your development gate ala onnv (and as I described in Setting up a Development Project Gate). If you haven't, then I think all you need to do is add this as the last bg.changeroup entry in your gate's hgrc.

And now you are good to go!

You might want to do the manual push I described above to seed the gate.

I'm pretty used to referencing variables inside print blocks in Perl. I'm not at all comfortable with Python. I have a block of code that I want to change the 'onhg' to come out of a config file. So I set up a scratch directory and make a bare bones implementation:

[th199096@jhereg etc]> ls -laiR ~/scratch/
/home/th199096/scratch/:
total 42
       749 drwxr-xr-x   3 th199096 staff          4 Oct  6 16:36 .
         3 drwxr-xr-x  39 th199096 staff         55 Oct  6 16:35 ..
       752 drwxr-xr-x   2 th199096 staff          6 Oct  6 16:42 etc
       750 -rwxr-xr-x   1 th199096 staff       1297 Oct  6 16:42 updateoso.py

/home/th199096/scratch/etc:
total 25
       752 drwxr-xr-x   2 th199096 staff          6 Oct  6 16:42 .
       749 drwxr-xr-x   3 th199096 staff          4 Oct  6 16:36 ..
       753 -rw-r--r--   1 th199096 staff       1052 Oct  6 16:40 __init__.py
       754 -rw-r--r--   1 th199096 staff        243 Oct  6 16:41 __init__.pyc
       751 -rwxr-xr-x   1 th199096 staff         94 Oct  6 16:42 config.py
       756 -rw-r--r--   1 th199096 staff        257 Oct  6 16:42 config.pyc

Where the config file simply has:

GATE_USER = "onhg"
GATE_GROUP = "gk"

OSOREPO = "ssh://hg.opensolaris.org/hg/onnv/onnv-gate"

And the updateoso has:

import os, pwd, subprocess, sys

from mercurial import hg, repo
from mercurial.node import hex

sys.path.insert(1,
    os.path.realpath(os.path.join(os.path.dirname(__file__), "..")))
from etc import config

__USAGE = """
updateoso.py [-n] <-R repo root>
    -n: dry run, no email sent (displayed on stdout)
    -R: root dir of repo (where .hg is)

Attempt to send changes to 
%s

This script must be run as user "onhg".
You should set up RBAC and use pfexec(1).
""" % (config.OSOREPO)
__USAGE = __USAGE.strip()

print >> sys.stderr, __USAGE

Well, in isolation, I can already see what I am going to have to do. All I need to do is replace the 'ohng' with a %s and add a second argument:

[th199096@jhereg ~/scratch]> diff updateoso.py updateoso.py.first 
39c39
< This script must be run as user "%s".
---
> This script must be run as user "ohng".
41c41
< """ % (config.OSOREPO, config.GATE_USER)
---
> """ % (config.OSOREPO)

And we get:

[th199096@jhereg ~/scratch]> ./updateoso.py
updateoso.py [-n] <-R repo root>
    -n: dry run, no email sent (displayed on stdout)
    -R: root dir of repo (where .hg is)

Attempt to send changes to 
ssh://hg.opensolaris.org/hg/onnv/onnv-gate

This script must be run as user "onhg".
You should set up RBAC and use pfexec(1).

I ought to be able to test this inside the interactive shell:

[th199096@jhereg ~/scratch]> python
Python 2.4.4 (#1, Aug 25 2008, 03:30:42) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import updateoso
updateoso.py [-n] <-R repo root>
    -n: dry run, no email sent (displayed on stdout)
    -R: root dir of repo (where .hg is)

Attempt to send changes to 
ssh://hg.opensolaris.org/hg/onnv/onnv-gate

This script must be run as user "onhg".
You should set up RBAC and use pfexec(1).
>>> config.GATE_USER = "duke"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'config' is not defined

Okay, I should have known that wasn't going to work. It would probably work in the code (we'll see later), but for now this will work:

>>> updateoso.config.GATE_USER = "duke"
>>> reload(updateoso)
updateoso.py [-n] <-R repo root>
    -n: dry run, no email sent (displayed on stdout)
    -R: root dir of repo (where .hg is)

Attempt to send changes to 
ssh://hg.opensolaris.org/hg/onnv/onnv-gate

This script must be run as user "duke".
You should set up RBAC and use pfexec(1).
<module 'updateoso' from 'updateoso.pyc'>

To be honest, I knew the reference would work, but I expected it to be reset. In retrospect, I can see that I reloaded updateoso and etc/config. Just something to get used to. I could force it to 'reset' via:

>>> reload(etc/config)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'etc' is not defined
>>> from etc reload(config)
  File "<stdin>", line 1
    from etc reload(config)
                  ^
SyntaxError: invalid syntax
>>> reload(updateoso.config)
<module 'etc.config' from 'etc/config.pyc'>
>>> reload(updateoso)
updateoso.py [-n] <-R repo root>
    -n: dry run, no email sent (displayed on stdout)
    -R: root dir of repo (where .hg is)

Attempt to send changes to 
ssh://hg.opensolaris.org/hg/onnv/onnv-gate

This script must be run as user "onhg".
You should set up RBAC and use pfexec(1).
<module 'updateoso' from 'updateoso.pyc'>

Took me a bit to figure out the syntax.

Okay, can I see the change from the script:

[th199096@jhereg ~/scratch]> diff updateoso.py updateoso.py.second 
45,48d44
< 
< config.GATE_USER = "gark"
< print >> sys.stderr, __USAGE
< 

I don't expect this to work. And it doesn't.

This script must be run as user "onhg".
...
This script must be run as user "onhg".

How about a test driver script?

[th199096@jhereg ~/scratch]> more test.py 
import updateoso

print "Now change the user"

updateoso.config.GATE_USER = "nark"

reload(updateoso)

And that works:

This script must be run as user "onhg".
...
Now change the user
...
This script must be run as user "nark".

I just had a mini-power outage where all of my screens and printer went off. So did my Sun Ray. My heart is still beating fast from the shock.

I was right in the middle of an important editing session and was just then doing a save. All I could think of was did I get it in time or not?

It didn't matter - my Sun Ray server is on UPS. My Sun Ray had powered back up and I unlocked the screen in under 30 seconds. I could even see that I had just saved the file.

In case you can't tell, I love my Sun Ray setup. My office is quiet, my "machine room" is loud.