Quoth Stacey Marshall on Tue, Jan 09, 2007 at 05:04:21PM +0000: > I am working toward a solution for the following Call Records: > > 6461591 dns/server should not use its config file as a dependency > 6461587 named(1M) CLI options should have corresponding SMF properties > > The issue I have is how to upgrade currently installed > network/dns/server instances such that the configuration file and execution > string command line options are retained. ... > One suggestion was that the replacement start method could be used to > populate the future settings. For this to work I presume an interim > setting would have to take place; for example this might take on the > following form: > > $ svcprop -p start/exec dns/server:default > /lib/svc/method/dns-server %m %i upgrade /usr/sbin/named -4 > > The start method could then update the required properties and > start/exec string accordingly; assuming permissions allow.
That could work. You would still need to use the upgrade file, though, since if the user customized the start method svccfg should notice the conflict, leave the user's settings alone, and issue a warning to the console. As such, it might be cleaner to do all of the work from the upgrade file. It's important to note that the upgrade file is executed at the end of the manifest-import service, so any upgrades which svccfg would do will have already been done. > One issue I see here is that to address 6461591 I had removed the > property from usr/src/cmd/bind/server.xml. But if its removed before > the upgrade then it will no longer exist! Looking at > usr/src/pkgdefs/SUNWbindr/postinstal [1] It seems that I may be able > to retrieve the current settings by writing to > /var/svc/profile/upgrade. Indeed it seems that this is where the new > manifest is imported. I could thus safely collect config_data/entities > values and append them also to the initial start/exec method as well, > meaning we'd have something like: > > $ svcprop -p start/exec dns/server:default > /lib/svc/method/dns-server %m %i upgrade /usr/sbin/named -4 > file://localhost/etc/named.conf > > And I do realize that I must consider that the configuration file may > have been overridden using the '-c' option on the start/exec line! Well since svccfg will upgrade the service before the upgrade file is run, you wouldn't have a chance to see the property if svccfg would delete it. But don't worry -- svccfg won't remove the property if the user has customized it. So if the property doesn't exist, you can assume it was the default. If it does exist then you can move it to the appropriate location and delete it yourself. Quoth Stacey Marshall on Wed, Jan 10, 2007 at 10:21:02AM -0800: > Having asked the question I wonder if perhaps the attached solution > would be acceptable? > > Basically it adds statements to postinstall which updates > /var/svc/profile/upgrade > to create necessary svccfg commands which are then executed after the new > manifest > has been imported. > ------- usr/src/pkgdefs/SUNWbindr/postinstall ------- > > --- - Wed Jan 10 18:28:18 2007 > +++ usr/src/pkgdefs/SUNWbindr/postinstall Wed Jan 10 18:27:51 2007 > @@ -54,17 +54,73 @@ > svcadm disable -s network/dns/server:bind9 > svccfg delete network/dns/server:bind9 > fi > _DEL_OBS_BIND9 > > -# Get rid of stale dependencies and start method > +# BIND 9.3.3 integration introduces smf_method(5) start script > +# Therefore need to upgrade each instance. > +cat >> $UPGRADE <<\_UPDATE_START_METHOD > + svc="network/dns/server" > + fupdate=/tmp/UPDATE_BIND > + rm -f $fupdate > + oset=$@ > + for inst in `svcs -H -o INST network/dns/server` You should only use full FMRIs in scripts, like "svc:/network/dns/server". And this might as well be $svc, eh? > + do Shouldn't you test that the start method of the instance points to a Sun-delivered named? That is, I don't think you should assume that every instance should be upgraded. The rest doesn't look bad. Please have the SMF team do a review, though. David
