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
