Susan, Thanks for the info about rpc.metad. I don't mind the error message at all, in fact I think it may be helpful to people that want to use disk sets.
All we do with SVM is mirror the root disks. No other disks in the system. Standalone system. No disk sets used. My problem is really that - I jumpstart a system - have jumpstart configure the mirrored /, /var and swap - I disable rpc/meta (in the site.xml during jumpstart) - I reboot - rpc/meta is set to enabled again - I disable rpc/meta - I reboot - rpc/meta is set to enabled again - ... during the first few - 3 to 5 - reboots only! I suspect it is happening during the start of the svc:/system/ mdmonitor service on a Solaris 10 06/06 system. The startup runs more than just the mdmonitord (split out in to metasync and mdmonitor service in OpenSolaris). I think I have narrowed it down to the 'metadevadm -l -r' invocation during startup. Still trying to understand it. We don't run rpcbind on secured builds and I want all services depending on rpcbind disabled in our build as delivered by jumpstart. Right now I have to "svcadm disable rpc/meta; init 6;" five times before rpc/meta stays off! - mo On 19 Sep 2006, at 23:57, Susan Kamm-Worrell wrote: > Moritz, > > Yes, when you create a metadb replica, the meta service becomes > enabled. This allows the user to create disksets. rpc.metad must be > already running on all nodes that will be sharing disks before the > diskset is created which is why it is enabled when the > first metadb replica is created. > > What is rpc.metad for? > When creating and managing a diskset, the rpc.metad daemon will run > needed actions and checks on the other nodes in the diskset. > > You can disable the svc:/network/rpc/meta service if you need for > security reasons, but you (obviously) won't be able to create a > diskset > without this service enabled. You may also encounter some errors like > network/rpc/meta:default: service(s) not online in SMF > that can be ignored. > > I think that most users won't mind that rpc.metad is enabled when > a metadb replica is created. For the user that has disabled > the meta service, I don't think that you should be getting an > error message unless you are attempting an action that would > required the meta service to be running. Currently, just running > the metadb command will print this error when only a > 'metadb -s <diskset>' should cause this error message. > > What's your opinion? Is the error message a problem? > > Susan > > > Moritz Willers wrote: >> K. Let's change subject as this seems related but is not quite on >> topic. >> Yes, I suspect that bit of code as well. And I suspect it to be >> somehow triggered out of the mdmonitor startup script. >> The system has mirrored root disks and has the metadb replicas >> that go with it. That does not imply that I need a running >> rpc.metad, does it? I never understood what that daemon does, >> but the manpage seems to imply it's there to *remotely* manage >> disksets. We don't use disksets and we certainly won't want them >> to be remotely managed. >> I want a secured system with reduced services - i.e. no rpcbind, >> no rpc.metad, and a lot more disabled - but mirrored root disks >> for redundancy. Surely that must be possible. Certainly always >> has been. >> What in SVM thinks that it needs to enable rpc.metad just because >> I have metadb replicas? >> - mo >> On 15 Sep 2006, at 21:39, Tom Whitten wrote: >>> I think that I missed the original posting on this, so I don't >>> have all of >>> the context. Nontheless, I'll climb out on the limb and try to >>> answer your >>> question. :-) >>> >>> Do you have any metadbs (Solaris Volume Manager replicas) on >>> your system? >>> If so, the SVM code is probably enabling the services. See the >>> meta_smf_enable function in >>> http://cvs.opensolaris.org/source/xref/on/usr/src/lib/lvm/ >>> libmeta/ common/meta_smf.c. >>> >>> tom >>> >>> Moritz Willers writes: >>> >>>> What confuses me on this one is that I should be able to >>>> disable rpc/meta and mdmonitor should come online fine. It >>>> does. But something keeps reenabling rpc/meta at boot! Any idea >>>> what that might be? >>>> >>>> # svcs -xv >>>> svc:/network/rpc/bind:default (RPC bindings) >>>> State: disabled since Fri Sep 15 12:42:02 2006 >>>> Reason: Disabled by an administrator. >>>> See: http://sun.com/msg/SMF-8000-05 >>>> See: man -M /usr/share/man -s 1M rpcbind >>>> Impact: 5 dependent services are not running: >>>> svc:/network/rpc/meta:default >>>> svc:/system/mdmonitor:default >>>> svc:/milestone/multi-user:default >>>> svc:/milestone/multi-user-server:default >>>> svc:/system/zones:default >>>> # svcadm disable rpc/meta >>>> # svcs -xv >>>> # init 6 >>>> >>>> ... >>>> >>>> # svcs -xv >>>> svc:/network/rpc/bind:default (RPC bindings) >>>> State: disabled since Fri Sep 15 12:49:41 2006 >>>> Reason: Disabled by an administrator. >>>> See: http://sun.com/msg/SMF-8000-05 >>>> See: man -M /usr/share/man -s 1M rpcbind >>>> Impact: 1 dependent service is not running: >>>> svc:/network/rpc/meta:default >>>> # svcs -l rpc/meta >>>> fmri svc:/network/rpc/meta:default >>>> name SVM remote metaset services >>>> enabled true >>>> state offline >>>> next_state none >>>> state_time Fri Sep 15 12:50:40 2006 >>>> restarter svc:/network/inetd:default >>>> dependency require_all/restart svc:/network/rpc/bind (disabled) >>>> >>>> and after another reboot mdmonitor and the rest fail to come up >>>> again. >>>> >>>> How can I track what enables a service? - mo >>>> >>>> >>>> This message posted from opensolaris.org >>>> _______________________________________________ >>>> smf-discuss mailing list >>>> smf-discuss at opensolaris.org >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> smf-discuss mailing list >> smf-discuss at opensolaris.org > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2130 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/smf-discuss/attachments/20060920/9a451937/attachment.bin>
