1. About zones as a software domains.

I talk to zone team askin about what will it cost in terms of development (hope 
they'll come here to discuss it). Replay was that zones with shared /usr is 
already quite light weight - not shared area does not really take too much 
space etc.

As I understand there are some other concerns about zones being heavyweight, 
will be really usefull to list all this concerns here. So may be we may resolve 
it and resolve software domains this way.

2. About user install

I also talk to Rich McAllister and he describeed me his vision. He like for any 
user to be able to install some (not any) software like compilers etc. to do 
initial testing and evaluation. In general thing which rehular users doing 
already now using tar-balls etc. This use-case does not require complete 
isolation and Rich OK with checking software consistency only when it is 
installed but does no commitmen to keep it consistent on System level - same as 
for tar-balls.  So if sysadmin somehow change somehow System software we will 
not check user software consistancy, if it is broken this way - up to the user 
who install it to fix it.

So this is not actually software domains but just user level installation to 
cover existing practice of delivering software by tar-balls etc.

So we see (me and Rich McAlister) how this request can be done:

1. We introduce new type of packages which may be pkgadd by any customer in 
their own home directory (some keyword in pkginfo set by package developers), 
This packages may be installed by regular user for testing-evaluation. However 
sysadmin also able to install this package on the system if it pass 
test-evaluation if needed.

2. Each user will have his/her own registry - contents file and var/sadm/pkg 
where all his/her software will be registered and which pkgadd will refer to in 
addition to system contents file.

3. Pkgadd and patchadd on system level will not check user contents file and do 
not care if software installed by user will be broken (and it affects only user 
- no big deal, same commitment level we now have for tar-balls)

4. Pkgadd on user level will check system as well as user software and will not 
install software if it is incompatible or require some other software to be 
installed. Here we raizing our commitment level in comparison to tar-ball 
commitment level.

5. Patchadd will check system and user software but will not applay patches to 
nonuser software but instead check if it is up to required level. This way if 
sysadmin install already same patch it will just update user software as it 
doing this right now for partially installed patches, but is patch not yet 
installed then it refuse to update only user software and make it inconsistent 
this way.

In general concept of user-root priveleges should be introduced in 
package/patch dependancy check. But it is clear and understandable. We can 
start implementing this right now. It is bit more complex that what we have 
right now but it is not new dimention of complexity.

vassun
 
 
This message posted from opensolaris.org

Reply via email to