Sunday May 25, 2008

goodbye MANPATH

I don't usually blog about every config file change I make, but here's one I'm particularly happy with, as it's removing a kludge. This is a change made to my zsh configuration that only runs on Solaris:

-# Sun's annoying man command...
-for dir in $path
-    mdir=${dir%/\*}/man
-	test -d $mdir && manpath=($manpath $mdir)

I was happy to play a very small roll in this putback to Nevada.

Thanks Mike!

Thursday Feb 09, 2006

SMF Manifest for Perforce

If you want to run a Perforce server from Solaris 10 or greater, you should be using SMF instead of /etc/init.d scripts or inetd. I haven't seen a SMF manifest for a Perforce server as of yet; so, I created one. It handles p4d (the main server) and p4p (the proxy server).

You can grab it from here:

The manifest itself has a quick "cheat sheet" to run either p4d (the "main" server) or p4p (the proxy server). But let's look at the more correct way to configure and run the services, and then we'll look at how to run multiple instances of the services.

Importing the manifest and configuring a default instance

First, let's take the downloaded "perforcexml.txt" file and put it in its proper place; then import it into SMF. Assume you've saved perforcexml.txt in /tmp.

# cd /var/svc/manifest/application
# mv /tmp/perforcexml.txt ./perforce.xml
# chown root:sys perforce.xml
# chmod 644 perforce.xml
# svccfg import perforce.xml

Notice that we didn't edit perforce.xml. Now, let's configure it from within SMF. We'll make the following assumptions:

  • The "p4d" and "p4" executables are in /usr/local/perforce/bin.
  • The perforce user with administrative privileges is named "bob". This is a perforce user -- not the same thing as a login in /etc/passwd.
  • The root of the perforce repository is /var/perforce.
  • We'll take the default for all other parameters, e.g. the tcp port number.
# svccfg
svc:> select p4d
svc:/application/perforce/p4d> editprop

editprop throws us into $EDITOR, your favorite editor. From here, we make the following changes:

# Property group "executables"
# delprop executables
# addpg executables application
setprop executables/client = astring:"/usr/local/perforce/bin/p4"
setprop executables/server = astring:"/usr/local/perforce/bin/p4d"

# Property group "options"
# delprop options
# addpg options application
# setprop options/journal = astring: (journal)
# setprop options/port = astring: (1666)
setprop options/adminuser = astring:"bob"
setprop options/root = astring:"/var/perforce"

The lines that we changed are the lines that are now uncommented. Save and quit your editor.

svc:/application/perforce/p4d> quit
# svcadm refresh p4d

We're ready! Make sure that /var/perforce is owned by daemon (the login that will actually be running the p4d daemon), and kick it off.

# chown daemon /var/perforce
# svcadm enable p4d
# svcs -x

Woohoo! No problems! If there had been a problem, "svcs -x" would have shown it. Test a perforce client against the server. If there are any problems, check "svcs -x" again.

The usual caveats apply: if you kill p4d, or run "p4 admin stop", SMF will immediately restart p4d. To stop the p4d server correctly, run "svcadm disable p4d". This will correctly shut down p4d (via "p4 admin stop").

Starting a second instance on the same machine

We can use SMF to start another Perforce repository on the same machine. The two instances can be administered separately (e.g. one can be taken down while the other one is active).

For the second instance, we'll assume the following:

  • The root directory of its Perforce repository is /var/altperforce.
  • The administrative user is "carl".
  • We will use tcp port 1667 (since 1666 was already taken by the first server).
  • In SMF terms, the second instance will be called "alt". The first one was called "default". The name of the first doesn't matter as much until you create a second.

When creating the second instance, we will want to borrow some of the properties from the default instance. The "editprop" command comes in handy here. If your favorite editor allows you to save a range of lines, then you can save the relevant section to a temporary file.

# svccfg
svc:> select p4d
svc:/application/perforce/p4d> editprop

Now we save the following lines into a temporary file:

# Property group "options"
# delprop options
# addpg options application
# setprop options/journal = astring: (journal)
# setprop options/port = astring: (1666)
# setprop options/adminuser = astring: (bob)
# setprop options/root = astring: (/var/perforce)

Now quit your editor, and we'll create the new instance.

svc:/application/perforce/p4d> add alt
svc:/application/perforce/p4d> select alt
svc:/application/perforce/p4d:alt> editprop

We will see the following:

select svc:/application/perforce/p4d:alt

Now read the temporary file into your editor, and edit it to look like this:

select svc:/application/perforce/p4d:alt

# Property group "options"
# delprop options
addpg options application
# setprop options/journal = astring: (journal)
setprop options/port = astring:"1667"
setprop options/adminuser = astring:"carl"
setprop options/root = astring:"/var/altperforce"

Save and quit your editor. We're almost done!

svc:/application/perforce/p4d:alt> quit
# chown daemon /var/altperforce
# svcadm refresh p4d
svcadm: Pattern 'p4d' matches multiple instances:

Oops, things really have changed! Let's do it right:

# svcadm refresh p4d:alt
# svcadm enable p4d:alt
# svcs -x

Success. The same technique can be applied for p4p (the proxy server). The configurable options for p4p are pretty much the same as p4d.


I hope you find this useful. This was my first learning experience for SMF, and it was really fun. But it's just a small sample of what SMF can do.

If I make any more changes to this manifest, either from your feedback or from changes to Perforce itself, I will blog about it here.

Technorati tags:



« July 2016