Hi Sarah thanks for the review. See my comments inline. ginnie > > > Hi Ginnie, > > This is looking really good. I do have some comments and questions: > > Section 8: > Remote Logging: > -It isn't clear to me exactly how this would work. You indicate that when a > client boots it would be able to setup remote logging, possibly via > wanboot.conf. How would a client get a wanboot.conf file if it was booted > from media? Does remote logging mean network boot? I don't think that is what > you mean, so can you clarify this a bit more? > The context that we've been looking at has been AI and VMC. The plan for both is to make use of the wanboot.conf file, AI via the network and VMC via including the wanboot.conf file on the AI image it uses. The wanboot method enables us to log across subnets.
Bootable AI could be extended to have an option to do remote logging. For other media installs, we would have to take a look at it. > -You responded to John F with: > >Installadm will be enhanced to setup up logging when an install service > >is created. The idea is to make this seamless. > > It looks as if you are proposing to set a logging service up automatically > with the setup of an AI service. Why would we do that by default? Is it > expected that AI clients will automatically log remotely? That's the design choice Dave, Sanjay and I made. It seems like less configuration overhead to accomplish both in one step. It is available and in place if the AI clients invoke remote logging. > If that is the thought, what are the implications from a security point of > view to our customers if this is the choice. > From my reading of wanboot, and I admit that I'm still learning about it, there are secure wanboot installation configuration set ups that are available. > -General question.. what if the user has a webserver setup somewhere but they > don't want to setup the wanboot logging server? Couldn't we just write the > file remotely to the server that is setup already? Perhaps I don't understand > exactly how the wanboot logging server helps or what it provides exactly. > The wanboot.conf file includes the url of the remote server, so that the client knows where to log to. The logging service will log where it is told to log. It just needs the location information to log to. That's one reason I left the init_handler() arguments as kwargs in 11.2. I thought it would be good to leave the options open. > Section 8.1 Client Side > -It might be good for the client to check network connectivity before making > a request to add the http handler. > Ok. I'll update the order of the list. > -Also, since logging goes through the engine, would the engine connect to the > remote logging service as opposed to the client? And error if it couldn't add > the handler? > In order for the http handler to be added, it requires the url as a parameter. The engine will have to query the network and get the wanboot.conf file. The url is located in the wanboot.conf file. Then it will pass that info to the logger on the system where the engine is running. There is no logging module on the server side. The logger sets up and opens the handler, passes the preamble to verify that information can be passed. Then that handler waits for information to be passed. It's passed via http. On the receiving end there is a CGI script that deposits the information into the default file location. > Section 11.1: > Would it be better to use a nvlist or something equivalent as the input > parameter to the init() method? So, it could be extensible without changing > the method signature? > That's a good idea. I prefer that too. It will make it easier for applications to customize. The engine init method would probably also need to have this too since it's passing it through. > Section 11.5: > Is it close_logger() or close_logging()? I think it maybe it should just be > close() since it is on the logger object we know what it means. > That's easy. I can certainly do that. > thanks, > sarah > -- > This message posted from opensolaris.org > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
