Stephen Hahn wrote:
> * "C. Bergstr?m" <cbergstrom at netsyncro.com> [2008-11-26 11:55]:
>
> (These are really questions for smf-discuss at opensolaris.org. I'm not
> closely working on smf(5) at the moment.)
>
>
>> 2) Building svc/* is a pita in a few ways..
>> a. It pulls in objects from other places so to avoid static libs being
>> built.. (or is just (ab)using the fact that it's in onnv and assumes a
>> monolithic build
>>
>
> It's actually because we support building on a system with older
> versions of the libraries--we build a native version of the possibly
> newer svc.configd and svccfg.
>
>
>> b. during the build it also bootstraps the base *.db (which is perfectly
>> logical 99.9% of the time)
>> c. There's a lot of deps involved here.. from perl to a rather long list
>> in my notes...
>> ( /usr/bin/perl -w listsvcs.pl -e generic_open.xml inetd_generic.xml
>>
>>> check_open.enabled)
>>>
>
> Yep.
>
>
>> Because of some of the small changes I made to svc.* I expected problems,
>> but even with -kv -m milestone=none I was able to hang the start-up process
>> in a way to completely render sending break over serial useless.. (It hung
>> tip/c-kermit.. etc) (On the console if I wasn't redirecting I could F1+a,
>> but typing stacks isn't fun) I know how to work-around that now and it
>> will be included in my final docs..
>>
>
> The seed is determined to be critical. If one was planning a
> substantial alteration of the startup portion of the graph, a new
> membership for the seed repository would be required.
>
>
>> Is there any from ground up guide/docs on how to bootstrap svc's *.db?
>>
>
> None that I know of. The original seed repository was constructed
> based on working through the various supported boot scenarios, of
> which there are many. OpenSolaris-distro will probably support fewer
> such scenarios--but there are new ones coming, too.
>
>
>> Here's some of my references currently
>> cmd/svc/seed/Makefile
>> cmd/svc/milestone/README
>>
>> cmd/svc/milestone/README.share
>> (really interesting in parts.. small nit.. the reference to failsafe should
>> be removed or even better added back into OpenSolaris, but I can understand
>> why it was removed.. so...)
>>
>
> I'm sure we'd take corrections/patches to these documents.
>
>
>> I also think the concept of sbd was lost somewhere since this pulls a 404
>> (maybe it's behind the firewall?)
>> cmd/svc/profile/README - http://solsec.eng.sun.com/sbd/
>>
>
> This link is probably covered in the "secure by default" pages for the
> security project:
>
> http://opensolaris.org/os/community/security/projects/sbd/
>
>
>> On a mostly default Opensolaris install I see about 90 services started..
>> From here my goal is to document each one and try to establish a milestone
>> just above single user, but still absolute minimum with all networking.
>> (This has probably been done -minus the documenting)
>>
>
> It depends on what you want to be active, beyond single-user. It's
> probably worth noting that new milestones that you wish to use with
> "svcadm milestone" require support in svc.startd(1M) and probably
> elsewhere.
>
> But I recommend asking on smf-discuss--they're the experts.
>
Oopse. thanks for you and Shane pointing this out.. My focus hasn't been
on smf until now and missed this list..
afaik.. I can't attach patch to the bugzilla.. (even if rumor is that
will soon change) Anyway.. 1) the above are nits and 2) I doubt anyone
outside myself or a Sun employee has really cared to read them much..
When it comes to building against a multilib based system there's other
more elegant ways to depend on specific versions than
LIBSQLITE = $(ROOT)/usr/lib/libsqlite.o
To really explain why this should be avoided is an entirely different
thread I won't bore anyone here with..
--------------
I'm done some basic optimizations on smf parts and during the build
for m in ../milestone/boot-archive.xml ../milestone/devices-local.xml
../milestone/global.xml ../milestone/identity.xml
../milestone/local-fs.xml ../milestone/manifest-import.xml
../milestone/minimal-fs.xml ../milestone/multi-user.xml
../milestone/name-services.xml ../milestone/network-initial.xml
../milestone/network-loopback.xml ../milestone/network-physical.xml
../milestone/restarter.xml ../milestone/root-fs.xml
../milestone/single-user.xml ../milestone/usr-fs.xml
../../dlmgmtd/dlmgmt.xml ../../rpcbind/bind.xml; do \
echo $m; \
SVCCFG_DTD=../dtd/service_bundle.dtd.1 \
SVCCFG_REPOSITORY=/work/onnv-gate/usr/src/cmd/svc/seed/common.db \
SVCCFG_CONFIGD_PATH=../configd/svc.configd \
../svccfg/svccfg import $m; \
done
I get this nice little core I need to debug
svccfg_libscf.c:1884: scf_transaction_commit() failed with unexpected
error -1. Aborting.
sh: line 2: 15122: Abort(coredump)
*** Error code 6
It's triggered on..
../milestone/global.xml \
../milestone/multi-user.xml
../milestone/restarter.xml
../milestone/console-login.xml \
../../cmd-inet/usr.lib/inetd/inetd-upgrade.xml \
../milestone/network-service.xml
../../nscd/name-service-cache.xml
I've changed dev env in the middle of all this and hoping to dodge
debugging this until after I get network is up on the target.. (which as
I'm finding out may not be svc related, but some other issue entirely)
So then comes questions like..
1) Are any of these critically important (looks to be yes, but maybe I
can get network up w/o it)
2) Where does common.db/global.db go after after the build or where/how
does the initial database get built/populated?
Thanks
./C
