Quoth Milan Jurik on Mon, May 15, 2006 at 08:27:07PM +0200:
> On Mon, 15 May 2006, David Bustos wrote:
> >Quoth Milan Jurik on Sun, May 14, 2006 at 12:51:16PM +0200:
> >>Does it mean that SMF Profiles will be like MS Windows registry?
> >
> >I don't think so. Do you have a specific characteristic in mind?
>
> One big binary blob? OK, with documented structure, but still one binary
> blob, accesible only through some API. Nobody will try to correct it by
> hand after incident probably.
It's true that the repository is like the registry in that they are
both opaque. This project is not changing that, though. Like I said,
this project will in fact make it easier for the administrator to reduce
the cost of repository corruption.
The API is a necessary part of the repository because it allows us to
add features under the covers, like this project.
> And only for services now, but why not to extend to applications also. Add
> some rights management...
Now that's starting to sound like the registry. We'll add functionality
as it's called for, but that's a separate discussion.
> >> In this
> >>case some SQLite files probably etc.?
> >
> >Like the rest of it, in-repository profiles will be kept in a database,
> >which is currently SQLite. Profiles will have external representations,
> >however. Most likely, this will be some sort of collection of manifest
> >files, which are XML.
>
> Yes, some default settings will be in XML files, I understand. But
> settings made by admins will be only in SQLite (or in XML file if exported
> by hand).
Is your concern that there is only one copy of the customization, or
that it is not visible in a text editor?
On large installations I expect administrators to accumulate most
customizations into a profile, which will be loaded into the repository
on each machine.
> >> No text files for easy editing with
> >>vi-like editors?
> >
> >Outside of the repository, profiles will almost certainly be
> >human-editable. Inside the repository, they won't be, just like the
> >rest of the repository.
>
> But main store will be SQLite. Not temporary but main.
We will not make the datastore an editable text file. That would
encourage services to bypass the API and prevent us from implementing
projects like this.
> >> Problem restoring after corruption of SQLite data files?
> >
> >Backups of the repository are made automatically. It's true that
> >customization data is kept solely in the repository, but this project
> >would allow administrators to keep that data outside of it, so if
> >anything, this project will increase reliability.
>
> Backups are made automatically after boot and manifest-import. But not
> every changing of property will mean reboot of machine (I hope). So that
> automatic backups will be made also in running system?
>
> Admins should care of some new structure (blackbox) in their systems?
> Backuping one big binary file? OK, we can export big set of XML files, so
> that it will be closer to /etc files, but still very different to the
> actual situation.
>
> Can I make 'cp /etc/svc/repository.db backups' safely on running system?
> Probably not because svc.configd has O_RDWR for it.
I think you can if you pstop svc.configd first. This does seem like
a deficiency, though. I've filed
6425993 Manual repository backups
for you.
> And what about distribution of config "files" to other machines? With
> 'svccfg'?
That's one of the goals of this project. You should be able to export
customizations you've made into a profile so that you can distribute it
to other machines.
> SMF is nice for service management. Not very different interface to init.d
> structure in reality and brings enhancements. After system troubles I know
> from my memory which services I want to start on that machine. But moving
> some "/etc file" configs to "through API accessible" blob?
>
> What will be benefits for admins/users/customers?
1. Each service doesn't have to write its own parser.
2. We can implement profiles without rewriting all services.
3. We can implement a distributed repository without rewriting all
services.
See also
http://blogs.sun.com/roller/page/lianep?entry=smf_repository_design_choices .
David
