Thanks for the feedback Alan. Responses inline... gary Alan Coopersmith wrote: > Tom Childers wrote: > >> My apologies, I just sent out links to documents that cannot be accessed >> outside of Sun. The documents are attached. >> > > Materials in open cases on sac.eng get mirrored out to the ARC community on > opensolaris.org automatically - it just takes a while (usually within a day > unless it breaks - ask Plocher for details). > > > >> * Support for automated patching and updating of products shall be >> implemented. >> * The installer should verify operating system dependencies before >> installing the product. >> * The installer should verify the existence of any dependent and/or >> required software versions before installing the product. [...] >> * Installation procedures shall verify that the product installation >> (or upgrade or patch) has been completed successfully. >> > > So these would all be satisfied by just delivering IPS packages right? > For (Open)Solaris, yes. If a product has its own installer, then these points would have to be satisfied within that installer. > >> * Installation procedures shall log all user input. >> > > except for sensitive data like passwords, surely. > > Oh yes... >> * An uninstaller will be included with each product installation. >> > > Is this necessary for products installed via a packaging system? > Wouldn't just a list of packages to remove via rpm/ips/pkgrm suffice in > most cases? > You are correct. As with a product with its own installer, then it would have to provide its own uninstaller. > > >> * The product shall provide a means to check and validate the >> ownership and protection of its files. Configuration files that >> contain sensitive information (such as user names and passwords) >> shall be protected from read or write access by any other user >> except the owner of the product installation. >> > > Are pkg verify (IPS) & pkgchk considered sufficient for products installed > as packages? > Yes. > >> * The product shall ensure that no files exist that can prevent the >> product from running (i.e., lock files, temporary files, etc.) >> > > What does this mean - products can't have lock files or other files that > would ever stop them from running? Or that they need to make sure those > files are all removed at some given time? (If so, when?) > The latter. Take Mozilla and Firefox for example. There are times when the process(es) stop running, and a lock file is left open. You cannot restart the application. You have to know that its execution is being prevented because a lock file exists (Joe user may not know that and has to log a service desk call). This is intended to prevent that scenario.
When? Application startup. > > >> * The product shall validate internal and external parameters to >> function and method calls. >> > > Given the size of the ARC case for just getting printf() to check for > NULL pointers, I imagine it would take decades to do this for even a > small portion of the Solaris libraries. (On the other hand, having a > rule recorded that says we need to do this would reduce the arguing in > such ARC cases.) > I realize there are pros and cons to this. The intent is to help backline support and Sustaining in localizing problems. Validation could also introduce performance issues. We have to determine when/where this is done. Obviously not on functions and methods that are called many times a second. > >> * The product shall detect and report if utilized resources (for >> example, memory and disk space) are being depleted, along with >> recommendations as to what should be done. >> > > Every program on the system needs to implement it's own memory leak checker? > That would be nice....probably very unreasonable and improbable to do however. To reduce the number of service calls related to performance, we'd like to notify the customer if an application is utilizing/is responsible for the consumption of disk/memory before the system performance is degraded to the point the system appears hung. In other words, "Am I the application causing this?". Make sense? > >> * Product events (errors) shall utilize the Solaris Fault Manager >> for reporting and diagnosis. >> > > Isn't FMA only for hardware faults, not software errors? (Certainly I've > never seen anything to suggest most of the software I work on should use FMA, > or even could - if this is intended to be wider spread, much more > documentation, > sample code, and advocacy is needed to get the word out.) > > As Darren pointed out, no. ZFS and even FMA itself uses it. SMF uses the message scheme. -- /Gary Lengyel/ /Sr. Staff Engineer, Software Architect/ /Serviceability Engineering/ /Service Delivery Enablement, Global Customer Services/ /877-522-2081, x51952/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20080826/e1a13de8/attachment.html>
