Sam Falkner's WeblogSam Falkner's Weblog |
|
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...
-
-manpath=(/usr/share/man)
-
-for dir in $path
-do
- mdir=${dir%/*}/man
- test -d $mdir && manpath=($manpath $mdir)
-done
I was happy to play a very small roll in this putback to Nevada. Thanks Mike! Posted at 11:18PM May 25, 2008 by samf in Solaris |
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: http://blogs.sun.com/roller/resources/samf/perforcexml.txt 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 instanceFirst, 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:
# 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 machineWe 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:
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:
svc:/application/perforce/p4d:alt
svc:/application/perforce/p4d:default
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. ClosingI 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: OpenSolaris Solaris SMF Perforce Posted at 12:00PM Feb 09, 2006 by samf in Solaris | |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||