Quoth Milan Jurik on Tue, May 16, 2006 at 11:30:00PM +0200: > On Mon, 15 May 2006, David Bustos wrote: > >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: ... > >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. > > I'm still trying to understand how it reduce the cost of repository > corruption. E.g. if repository (one file) will be corrupted then admin > will lost every change for every service after the latest backup.
If the customizations were not loaded from a profile, then it will not reduce the cost. > >The API is a necessary part of the repository because it allows us to > >add features under the covers, like this project. > > But API can cover also standard Unix way - files and filesystem structure. The standard Unix way is insufficient and not extensible. > >>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. > > Yes, but this project will start it. > > I understand why SMF needs its "temporary" binary blob. But it is not so > big problem, in the situation when system is in some troubles you can > bypass SMF and work with services manually. But if configuration will be > in repository, you cannot bypass it so easily. Services critical to repository recovery must be manually startable. Since this project only creates the infrastructure for services to move their configuration into the repository, without actually doing so for any services, it is up to those service authors to ensure that this criterion is met. > >>>> 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? > > What is more admin friendly, bunch of svccfg commands or one text file? In > my case, I like more to edit some /etc files than e.g. to run ldapclient > command. I agree. But keeping configuration in editable text files of varying syntax precludes transactionality, low-level consistency, and system-wide configuration coordination, like profiles. If you know of a way around this, please show us a prototype. > >>>> 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. > > What is the difference between: > > svccfg setprop someprop = value > > vs. > > vi /etc/some_directories/service.conf > svcadm reload service > > OK, in the first situation you will set only one property, so service will > not need to parse everything. But many times you will run svccfg more than > one, it can lead up to more work for service, many repetitive things. This assertion is incorrect, since services only need to reread their configuration on svcadm refresh, not each property change. The larger issue of administrative ease-of-use is important to us, but when it stands in the way of features like transactionality, snapshots, roll-back, and profiles, which we believe also contribute to administrative ease-of-use, we must forge ahead. You could argue that one could implement snapshots and profiles with plain files, but doing so would be enormously complex and would only introduce more points of failure and misunderstanding into the system. > >>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 > > Is it save to pstop it? Yes. Clients will hang in the meantime, but after startup, clients rarely access the repository. > >a deficiency, though. I've filed > > > > 6425993 Manual repository backups > > > >for you. > > OK, thank you (I added to interest list for this bug myself). Small side > effect :-) But still how frequently will be done automatic backup, or that > will be only during boot as today? More frequent automatic backups sounds like a reasonable request. Is that what you're asking for? > >>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. > > Some dedicated daemon/service or through XML files? Almost certainly XML files. > >>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. > > There could be small library which can parse files with structure e.g. > "name: value". No binary blob needed. Many present configs can be > recycled. Ok, go code it. > > 2. We can implement profiles without rewriting all services. > > Through some wrappers for every service, for every service different one. I'm not sure what you mean. > > 3. We can implement a distributed repository without rewriting all > > services. > > Distributed? You mean reimplementation of scp command? No. I mean that if a service requests a property which is not on the local machine, it would fall through to some network machine, so you could configure multiple machines from one store. > >See also > >http://blogs.sun.com/roller/page/lianep?entry=smf_repository_design_choices . > > Interesting (I think I read it some months ago): > > 3. Single point of access. > Single point of failure. I'm not against binary blobs. E.g. postfix is > using them also. And sendmail has also its config in recomputed files. But > both are only temporary, not main store. Main store is human readable, > many files, not one big. Human-readable configuration files are also a single point of failure. Like I said above, administrative convenience is valued, but it was standing in the way of progress. > 4. Access control. > It is not in SMF now, I think. And this will lead to more MSWin registry > way. Write access control is present. See smf_security(5). > All others could be solved also in the files way, I think. How would you make text files transactional? Making only certain parts of a configuration file changeable by certain people would require breaking the file up. Once you did that, how would you take atomic snapshots? How would you implement profiles which could change some parts of the configuration without others? Wouldn't you have to put each line into a separate file? Certainly, you could find ways to do all of these things through the traditional read(2)/write(2) interface, but the way we've chosen is much, much simpler. > Why should > Solaris lost Unix "nearly everything is file" way? Who was discussing this > with admins/customers? I tried it today with 2 my friends, both are > working with Solaris quite a lot and are very knowledgeable and for them > even SMF for services is strange. But they can accept it for its benefits. > But repository of configs? > I asked for admin's benefits. Not developer's. It's true that manipulating configuration in the repository isn't as easy as it could be today. We're working on that (see, for example, http://opensolaris.org/os/project/vpanels ). We think the benefits resulting from the repository, present and future, justify the current inconvenience. And the lack of loud complaints seems to support that. David
