Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
We don't support diskless clients _except_ as a detail of how netinstall works. Well, why not support them? _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
How can we prevent chaos if the administrator is free to ignore all constraints. Why do you believe it s your duty to prevent chaos? If you really were so keen on preventing chaos and having it all work in a sane manner, you (plural) would have given us sgi's inst(1M), not go off on a tangent and attempt to reinvent an entire software management subsystem. _ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Reasons were given. You're not arguing the technical details. Perhaps he isn't, but I am. I'd characterize it differently. SVR4 packaging lets you run arbitrary code during pkg install, and the tools layered on top of SVR4 packaging created a plethora of contexts where said code must be able to run, and this creatd an unmanageable situation. That's a red herring. Or a strawman. Or a slippery slope. One of those, anyway (;-) You are presupposing (embedding) the conclusion that this was an unmanageable solution. But wait, who says that? And on what exactly is that based? All we needed in SVR4 packaging is automatic dependency resolution and the ability to point it to a repository of packages, and have true package clusters instead of metaclusters. You know, like sgi, IBM and hp had for the past twenty years, or so, likely longer. It is very, very wrong, in my experience, for a bunch of engineers, coding in an artificial environment, far, far from the trenches of their customers, to be deciding what their customers are and aren't allowed to do - by design! I'd be interested to hear from the IPS development team, how many of you have actual system engineering and sysadmin experience in customer environments? That's all. Thank you. I believe IPS + AI probably scales to the enterprise _now_. But I believe IPS is not ready for enterprise use in one sense: customers are not yet ready to use IPS packaging to do the things they are used to doing with SVR4, and we could make that transition easier. For example, a simple tool to create an SMF actuator from a developer-provided script would be nice. It's possible that there may yet be a use for my SVR4-IPS CAS/post* script migration tool. Customers want to be able to *encapsulate* consistently repeatable software configuration tasks associated with installing and running software, and meanwhile, the IPS development team is attempting to prevent them from doing exactly that. Some even claim that the software management (packaging) system is not for that. Well, who exactly is in the position to actually decide that? That's nothing but someone's definition. Meanwhile, there are things that people need to do, and can't. For instance, how can a package installed from an install server, on a *running* diskless client, install the package on that running system *and* start the newly installed SMF service *immediately*? _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
That is far from a given. In the short run, it requires some learning, but in the long run it will be a more stable execution environment than any sort of scripting in SVR4 packages ever provided. Pardon my lack of faith, but I'd love to know what that statement is based on! _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
I think what's missing there is a tool to make the above simpler: something that takes your start method, SMF FMRI, pkg FMRIs and incorporation FMRI and does the rest for you. Even better, if this work can be done once and made to support the use of profiles (as you suggest below) to do the configuration. Then the tool would be simpler still, as simple as you want it to be. The most important thing would be to be able to remotely (from the install server) fire up an SMF method/service, if the system is currently running like a diskless or an AutoClient would be, for example). If that capability were provided, then that would be the escape hatch. _ Windows Live™: Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
a b wrote: Should all portions of a package be optionally installable? subsystems (subproducts) should be optionally installable: the packager should be able to specify during prototype creation, which subproducts are to be installed by default, and which are included but wouldn't be installed, unless specifically selected. This is exactly what facets will do. Brock You worked with IRIX and inst(1M) Peter, I think you know what I'm talking about: inst keep * inst install default inst conflicts No conflicts inst go _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 18, 2009 at 09:59:28PM +0200, a b wrote: I think what's missing there is a tool to make the above simpler: something that takes your start method, SMF FMRI, pkg FMRIs and incorporation FMRI and does the rest for you. Even better, if this work can be done once and made to support the use of profiles (as you suggest below) to do the configuration. Then the tool would be simpler still, as simple as you want it to be. The most important thing would be to be able to remotely (from the install server) fire up an SMF method/service, if the system is currently running like a diskless or an AutoClient would be, for example). If that capability were provided, then that would be the escape hatch. We don't support diskless clients _except_ as a detail of how netinstall works. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Tue, 16 Jun 2009, Bart Smaalders wrote: Robert Milkowski wrote: So for example if I want to uninstall a package A I won't end-up with another 20 packages being installed automatically. I know one can check dependencies in advance but still... How would this happen? We don't support require dependencies that offer a choice; thus uninstall cannot cause other packages to be installed. If you install a package, we automatically install its dependencies. To do otherwise is madness. Sorry, a type - I meant that if a user tries to uninstall package A it should fail by default if there are other packages which needs to be uninstalled as they depend on A. If all of these packages are provided to pkg uninstall and there are no other packages which will need to be uninstalled due to dependencies then it should proceed. So lets say there are three packages: A, B and C where B and C depend on A. # pkg uninstall A Package A is required for packages: B, C Please provide --with-dependencies option to uninstall those packages as well. # pkg uninstall --with-dependencies A uninstalling A, B, C or there should be an option to force an uninstall without deps (like with rpm): # pkg uninstall --no-deps A uninstalling A WARNING packages: B, C depend on A and are not being uninstalled pkg fix should be able to fix such a case later on if run. If user would specify all three packages (in whatever order) then it should just work: # pkg uninstall A B C uninstalling A, B, C -- Robert Milkowski http://milek.blogspot.com ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Jun 17, 2009, at 4:16 AM, Robert Milkowski wrote: or there should be an option to force an uninstall without deps (like with rpm): This is specifically not planned. If user would specify all three packages (in whatever order) then it should just work: # pkg uninstall A B C uninstalling A, B, C This was fixed to work Apr 16, 2009. So, the latest version of pkg(5) available from pkg.opensolaris.org should work like this. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Robert Milkowski wrote: or there should be an option to force an uninstall without deps (like with rpm): # pkg uninstall --no-deps A uninstalling A WARNING packages: B, C depend on A and are not being uninstalled We don't want to support this, because it allows the user to break his system. * Why do you want to uninstall A, if B C depend on it? * What should the state of B C be, if A is forcibly removed? * We use package dependencies to prevent two packages from owning the same file at the same time, or having one package declare /usr/openwin a directory and other declare a symbolic link. How can we prevent chaos if the administrator is free to ignore all constraints. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Mon, 15 Jun 2009, Peter Tribble wrote: On Sat, Jun 13, 2009 at 1:24 AM, Bart Smaaldersbart.smaald...@sun.com wrote: Because the job of the packaging system is to manage software on the machine according to the constraints imposed on that software by its developer, and by the administrator. Yet you're denying administrators and customers the ability to impose those constraints. Dependencies are a case in point. They are simply input to a policy. A sensible default policy may be follow the dependencies and install everything along the way. Some others may want to say stop dead in your tracks if you need to install something that isn't already installed or that I've explicitly asked for. Another possibility is do what you're told and ignore any dependencies. All have their place. The packaging system should enable the implementation of those policies, not unconditionally force its own policy decisions on users. Agree in 100%. Most package managers (rpm in example) allow to install or remove a package without dependencies and sometimes it is useful. The default should be to install or uninstall with dependencies but unless these depended packages have been explicitly specified it should be at least interactive or an extra switch should be required IMHO. So for example if I want to uninstall a package A I won't end-up with another 20 packages being installed automatically. I know one can check dependencies in advance but still... -- Robert Milkowski http://milek.blogspot.com ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Arrg - and that should be more secure than using a postinstall script??? Sorry, but using an SMF Service for configuring an application makes developing of packages more complicated and will lead to lot of new errors I agree -- while somwhat simple for system administrators, SMF XML manifests are complex for developers. And I should know, since I wrote several manifests, and took part in the discussions of SMF's future. So using SMF in clever ways -- although doable, should not be an escape hatch just because the IPS group believes that no scripting should be allowed. The logic is fundamentally flawed: if I need to use SMF, then I need to use scripting anyway. Now, the only question is, will you make it hard or easy for the developers? Developers tend to be turned off by technology that's too complex and too hard to use. Who will you have develop in the end? Only the hardcore Solaris guys will stay with Solaris. Eveyone else will go elsewhere, where it's easier. And the biggest irony, the hardcode Solaris people like me will not want to bother; it's just easier to stick with System V packaging, or port sgi's inst(1M) and have all these issues solved, since sgi solved them ALL already. -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
If you want Oracle to run every time the machine boots, you should deliver an SMF manifest that sets up such a service. Mark it enabled s default, and set reset-fmri=svc:/system/manifest-import on the xml file that delivers the manifest. You're done. Hmmm, since Larry owns you now, I think you guys might very well be the ones doing that SMF manifest! (And that's a good thing.) (:-) The start method should take care of whatever needs to be done at first boot. Is this about not wanting to create SMF services? Partly, yes. SMF is not exactly what I'd call simple, let alone developer friendly. When I started developing SMF manifests, many, many things were just a big, undefined question mark, in spite of the documentation. Many things that I had to go and ask either Liane Praza or David Bustos directly. Otherwise, I'd still be stuck wandering in the dark, doing reverse engineering. What an enormous investment of time and effort to do that! We've since corrected some of the issues and David opened several CRs, but I would still hesitate to call SMF developer friendly. Let's face it: yes, SMF is powerful. But it's also complex to develop for. -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
If the packaging system is so inflexible that administrators are unable to define or implement the policies they need to, they have several options, including (a) being miserable, (b) violating the packaging system by going behind its back, (c) using a different packaging system. I'm not looking forward to living in such a world. Neither do I. +1. -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
UNIX admin wrote: The problem is, the server(s) onto which software is installed might already be running. In production. You cannot possibly expect that a cluster of servers running SWIFT transactions between Europe and the U.S., or any other financial software or mission critical software, must be rebooted in order to have the database automatically start! Of course not, and it's not required with IPS today. If you did want to be able to provision a new boot environment, it would be nice not to have to start Oracle as part of the postinstall script, though, wouldn't it? IPS requires that all packages be able to be installed into a non-running image, so we do not support scripting as package developers never seem to understand that the software they're installing might not be able to run right now. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Robert Milkowski wrote: So for example if I want to uninstall a package A I won't end-up with another 20 packages being installed automatically. I know one can check dependencies in advance but still... How would this happen? We don't support require dependencies that offer a choice; thus uninstall cannot cause other packages to be installed. If you install a package, we automatically install its dependencies. To do otherwise is madness. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Jun 16, 2009, at 4:24 PM, Bart Smaalders wrote: Robert Milkowski wrote: So for example if I want to uninstall a package A I won't end-up with another 20 packages being installed automatically. I know one can check dependencies in advance but still... How would this happen? We don't support require dependencies that offer a choice; thus uninstall cannot cause other packages to be installed. If you install a package, we automatically install its dependencies. To do otherwise is madness. To be clear, we do support optional dependencies, and whether those get installed is controlled by an image policy. However, whether a dependency is optional is up to the package creator. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Bernd Schemmer wrote: Hi, You'd write an SMF service (start method included) that does all the configuration, then you'd pacakage it (with corresponding dependencies on the pkgs that deliver the Oracl DB product), and you'd add this pkg to the incorporation that your machines install. Arrg - and that should be more secure than using a postinstall script??? Yes, it certainly should be; you can precisely control the privileges used for executing the service start method, which may well be far less than required to install software. Sorry, but using an SMF Service for configuring an application makes developing of packages more complicated and will lead to lot of new errors That is far from a given. In the short run, it requires some learning, but in the long run it will be a more stable execution environment than any sort of scripting in SVR4 packages ever provided. Dave ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Hi, That is far from a given. In the short run, it requires some learning, but in the long run it will be a more stable execution environment than any sort of scripting in SVR4 packages ever provided. Hmm, I'm not sure about that . But anyway - if this is the way to go we have to use it. What about the preinstall scripts, and post/pre remove scripts? regards Bernd Dave Miner wrote: Bernd Schemmer wrote: Hi, You'd write an SMF service (start method included) that does all the configuration, then you'd pacakage it (with corresponding dependencies on the pkgs that deliver the Oracl DB product), and you'd add this pkg to the incorporation that your machines install. Arrg - and that should be more secure than using a postinstall script??? Yes, it certainly should be; you can precisely control the privileges used for executing the service start method, which may well be far less than required to install software. Sorry, but using an SMF Service for configuring an application makes developing of packages more complicated and will lead to lot of new errors That is far from a given. In the short run, it requires some learning, but in the long run it will be a more stable execution environment than any sort of scripting in SVR4 packages ever provided. Dave -- Bernd Schemmer, Frankfurt am Main, Germany http://bnsmb.de/ M s temprano que tarde el mundo cambiar . Fidel Castro ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Mon, Jun 15, 2009 at 06:17:51PM +0200, Bernd Schemmer wrote: That is far from a given. In the short run, it requires some learning, but in the long run it will be a more stable execution environment than any sort of scripting in SVR4 packages ever provided. Hmm, I'm not sure about that . But anyway - if this is the way to go we have to use it. The reason the IPS approach is simpler has been explained entirely too many times :) What about the preinstall scripts, and post/pre remove scripts? My SVR4-IPS CAS and post* script migration prototype shows how one can use the IPS SMF actuator approach to implement CAS and postinstall/ postremove. (If nothing else, you can always keep using SVR4 CAS and post* scripting and adapt my SVR4-IPS migration prototype to your needs.) The only way that one could implement preinstall/preremove[*] would be by breaking up pkgs into pieces that must be installed/removed in a specific order, and that's just not practical. And, of course, there's no way whatsoever to do anything like 'checkinstall' and 'request' scripting in IPS -- which I do believe is a good thing. I'm not sure why one would need preinstall at all; in SVR4 packaging most of the things one might want to do in preinstall belong to checkinstall, and anything beyond that (e.g., anything involving use of installf/removef, or editing files) strikes me as a bug in the package. With IPS facets and variants I also don't see any need to have checkinstall scripting. Typical uses of SVR4 preremove scripting can be replaced with specific IPS features. For example, driver removal. Or to prevent removal of a pkg that's unsafe to remove from running images while still in use. IPS must (and mostly, if not entirely does) support these uses of preremove directly. Thus, not only is there no practical way to emulate SVR4 preinstall/ preremove/checkinstall pkg scripting with IPS, there's no reason to. Similarly, much of what request scripts often do can be replaced with IPS functionality, such as facets and variants. (I'm not entirely sure how relocatable pkgs / user images work in IPS, or how to use such features.) [*] One might be tempted to use an SMF actuator to implement preremove functionality when removing a pkg from a running image, but how's the service to distinguish between disabled by the sysadmin from disabled by IPS ahead of update and disabled by IPS ahead of removal? Even if SMF added a plethora of methods to allow for these distinctions, such actuators would never run on removal from an inactive image. Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Hi, Thus, not only is there no practical way to emulate SVR4 preinstall/ preremove/checkinstall pkg scripting with IPS, there's no reason to. That's the reason why I don't like the new approach: Someone decided what is useful and what not and we have to live with it ... When I compare IPS with SVR4 I would call SVR4 freedom to implement the best solution for your situation even if Sun never thought that it might be used this way and IPS you're only allowed to do what we think is useful. Nevertheless I think IPS is useful for Solaris running on a desktop computer (I'm using OpenSolaris on my Thinkpad for day-to-day usage and I'm very satisfied with Solaris and IPS there) but I don't think this is the right way to go for server in production. regards Bernd Nicolas Williams wrote: On Mon, Jun 15, 2009 at 06:17:51PM +0200, Bernd Schemmer wrote: That is far from a given. In the short run, it requires some learning, but in the long run it will be a more stable execution environment than any sort of scripting in SVR4 packages ever provided. Hmm, I'm not sure about that . But anyway - if this is the way to go we have to use it. The reason the IPS approach is simpler has been explained entirely too many times :) What about the preinstall scripts, and post/pre remove scripts? My SVR4-IPS CAS and post* script migration prototype shows how one can use the IPS SMF actuator approach to implement CAS and postinstall/ postremove. (If nothing else, you can always keep using SVR4 CAS and post* scripting and adapt my SVR4-IPS migration prototype to your needs.) The only way that one could implement preinstall/preremove[*] would be by breaking up pkgs into pieces that must be installed/removed in a specific order, and that's just not practical. And, of course, there's no way whatsoever to do anything like 'checkinstall' and 'request' scripting in IPS -- which I do believe is a good thing. I'm not sure why one would need preinstall at all; in SVR4 packaging most of the things one might want to do in preinstall belong to checkinstall, and anything beyond that (e.g., anything involving use of installf/removef, or editing files) strikes me as a bug in the package. With IPS facets and variants I also don't see any need to have checkinstall scripting. Typical uses of SVR4 preremove scripting can be replaced with specific IPS features. For example, driver removal. Or to prevent removal of a pkg that's unsafe to remove from running images while still in use. IPS must (and mostly, if not entirely does) support these uses of preremove directly. Thus, not only is there no practical way to emulate SVR4 preinstall/ preremove/checkinstall pkg scripting with IPS, there's no reason to. Similarly, much of what request scripts often do can be replaced with IPS functionality, such as facets and variants. (I'm not entirely sure how relocatable pkgs / user images work in IPS, or how to use such features.) [*] One might be tempted to use an SMF actuator to implement preremove functionality when removing a pkg from a running image, but how's the service to distinguish between disabled by the sysadmin from disabled by IPS ahead of update and disabled by IPS ahead of removal? Even if SMF added a plethora of methods to allow for these distinctions, such actuators would never run on removal from an inactive image. Nico -- Bernd Schemmer, Frankfurt am Main, Germany http://bnsmb.de/ M s temprano que tarde el mundo cambiar . Fidel Castro ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Sat, Jun 13, 2009 at 1:24 AM, Bart Smaaldersbart.smaald...@sun.com wrote: IPS will (when finished) strictly enforce the following policies: 1) All package dependencies are enforced: If a package has require dependencies, they will be installed. Packages may not be uninstalled if another package depends on them. Incorporations and minimum required versions are enforced. 2) The only action that's allowed to be duplicated in multiple packages that can be installed at the same time is a directory. If these restrictions are too onerous, you don't need a packaging system but tar or cpio may do what you want. So, you're saying that delivering software via tarballs is better than using IPS? Why do we feel this is the right choice? Because the job of the packaging system is to manage software on the machine according to the constraints imposed on that software by its developer, and by the administrator. Yet you're denying administrators and customers the ability to impose those constraints. Dependencies are a case in point. They are simply input to a policy. A sensible default policy may be follow the dependencies and install everything along the way. Some others may want to say stop dead in your tracks if you need to install something that isn't already installed or that I've explicitly asked for. Another possibility is do what you're told and ignore any dependencies. All have their place. The packaging system should enable the implementation of those policies, not unconditionally force its own policy decisions on users. If as an administrator you wish to break package dependencies, divide packages in half, etc, you need to repackage the software, because you're now using it in a manner un-envisioned (or perhaps seen only in a nightmare) by the original packager. All the tools necessary to do this will be part of OpenSolaris. And you'll support a system where someone has modified the dependencies of a package so the system doesn't work? They've done it in the approved fashion. The design of variants/facets was specifically targeted at allowing the package developer to describe a variety of different configuration options. If this mechanism doesn't provide sufficient flexibility, please speak up I've not completely explored the full range of options that facets would allow, but does it allow the installation of any particular facet without any other component of the package being installed? In particular, if documentation were a facet, would I be able to install the documentation on its own? (This is something I do all the time, so I can access documentation locally on my desktop where it's nice and snappy.) but allowing administrators to perform ad-hoc install-time overrides of the packaging system constraints is akin adding bpatch support to pkg. If the packaging system is so inflexible that administrators are unable to define or implement the policies they need to, they have several options, including (a) being miserable, (b) violating the packaging system by going behind its back, (c) using a different packaging system. I'm not looking forward to living in such a world. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Mon, Jun 15, 2009 at 10:32:09PM +0200, Bernd Schemmer wrote: Thus, not only is there no practical way to emulate SVR4 preinstall/ preremove/checkinstall pkg scripting with IPS, there's no reason to. That's the reason why I don't like the new approach: Someone decided what is useful and what not and we have to live with it ... Reasons were given. You're not arguing the technical details. Instead you seem unhappy with how the decision was made (without your input, I suppose). That's not a good enough argument. When I compare IPS with SVR4 I would call SVR4 freedom to implement the best solution for your situation even if Sun never thought that it might be used this way and IPS you're only allowed to do what we think is useful. I'd characterize it differently. SVR4 packaging lets you run arbitrary code during pkg install, and the tools layered on top of SVR4 packaging created a plethora of contexts where said code must be able to run, and this creatd an unmanageable situation. IPS gives you all sorts of freedoms, but only in a single context: running image context, and IPS greatly constrains what can be done in other contexts. Nevertheless I think IPS is useful for Solaris running on a desktop computer (I'm using OpenSolaris on my Thinkpad for day-to-day usage and I'm very satisfied with Solaris and IPS there) but I don't think this is the right way to go for server in production. I believe IPS + AI probably scales to the enterprise _now_. But I believe IPS is not ready for enterprise use in one sense: customers are not yet ready to use IPS packaging to do the things they are used to doing with SVR4, and we could make that transition easier. For example, a simple tool to create an SMF actuator from a developer-provided script would be nice. It's possible that there may yet be a use for my SVR4-IPS CAS/post* script migration tool. Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
UNIX admin wrote: What needs to happen is, after the package is deployed, the Oracle database processes are running, the TNS listener is accepting connections to the database, and the database is now ready to accept data. How do I install such a package in an alternate root? Or are such packages only installable on a running system? Designing features into the packaging system that are unusable in any context but a live install on a properly configured system is a major source of breakage. It is a requirement that the packaging system be able to install packages onto an alternate root. It is not a requirement that the packaging system be Turing complete, or that you can use it as a remote execution framework. You can implement this w/ actuators in IPS; it will require a SMF service to be running to handle your post-installation tasks. Note that packages built this way will actually work on alternate root install, with Oracle running once that environment is booted. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Mon, Jun 15, 2009 at 10:01 PM, Bart Smaaldersbart.smaald...@sun.com wrote: UNIX admin wrote: What needs to happen is, after the package is deployed, the Oracle database processes are running, the TNS listener is accepting connections to the database, and the database is now ready to accept data. How do I install such a package in an alternate root? Or are such packages only installable on a running system? Designing features into the packaging system that are unusable in any context but a live install on a properly configured system is a major source of breakage. It is a requirement that the packaging system be able to install packages onto an alternate root. It is not a requirement that the packaging system be Turing complete, or that you can use it as a remote execution framework. You can implement this w/ actuators in IPS; it will require a SMF service to be running to handle your post-installation tasks. Note that packages built this way will actually work on alternate root install, with Oracle running once that environment is booted. If that's the way to do it, and if it's possible to automatically convert scripting into services, then why not fold that functionality into the packaging system so that it creates the SMF services (or whatever) as required to get the scripts run in the correct context? It seems to me that the no scripting rule is more about the context in which the script runs rather than the existence or content of the script. In that case, going to software packagers and saying just write your script to run correctly on a live image and we'll make sure its gets run in the right time and place without you having to worry about all these other possible installation scenarios would be a big selling point. And the packagers wouldn't have to worry about implementing the SMF services, avoiding a big hole they could dig themselves into. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Mon, Jun 15, 2009 at 11:13 PM, Bart Smaaldersbart.smaald...@sun.com wrote: Peter Tribble wrote: If the packaging system is so inflexible that administrators are unable to define or implement the policies they need to, they have several options, including (a) being miserable, (b) violating the packaging system by going behind its back, (c) using a different packaging system. I'm not looking forward to living in such a world. Should all portions of a package be optionally installable? Yes, why not? In other words, should IPS support options to omit files from installation by regular expression? I hadn't though of it quite like that, but again, why not? You seem to want to treat packages of software as a development kit, to be edited and changed as desired. This is a fine idea, but rather different than the publisher had in mind. Fair point, and probably not that far off the mark. But underneath all this is the fact that the original developer/publisher pretty much has to choose one standard use case - I wouldn't expect every package to understand every single possible use to which it might be put, so what I'm looking for is the ability to let the package define the best behaviour for the common case, while allowing for different use cases. I've not completely explored the full range of options that facets would allow, but does it allow the installation of any particular facet without any other component of the package being installed? In particular, if documentation were a facet, would I be able to install the documentation on its own? (This is something I do all the time, so I can access documentation locally on my desktop where it's nice and snappy.) No. If you want to do this, we should publish the docs in separate packages, and reference them as faceted dependencies. A single group package (the equiv. of SUNWman today) could bring them all in. This is likely the direction we'll head anyway, since it greatly facilitates publishing. OK, thanks. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Peter Tribble wrote: If the packaging system is so inflexible that administrators are unable to define or implement the policies they need to, they have several options, including (a) being miserable, (b) violating the packaging system by going behind its back, (c) using a different packaging system. I'm not looking forward to living in such a world. Should all portions of a package be optionally installable? In other words, should IPS support options to omit files from installation by regular expression? You seem to want to treat packages of software as a development kit, to be edited and changed as desired. This is a fine idea, but rather different than the publisher had in mind. The function of a packaging system is to deliver the software as specified in the packaging manifest. The file ownership, permissions, dependencies, etc specified in a package are part of the design of that software system. Allowing edits by admins means that package can no longer satisfy any external dependencies, and may well not be functional by itself. I've not completely explored the full range of options that facets would allow, but does it allow the installation of any particular facet without any other component of the package being installed? In particular, if documentation were a facet, would I be able to install the documentation on its own? (This is something I do all the time, so I can access documentation locally on my desktop where it's nice and snappy.) No. If you want to do this, we should publish the docs in separate packages, and reference them as faceted dependencies. A single group package (the equiv. of SUNWman today) could bring them all in. This is likely the direction we'll head anyway, since it greatly facilitates publishing. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Peter Tribble wrote: If that's the way to do it, and if it's possible to automatically convert scripting into services, then why not fold that functionality into the packaging system so that it creates the SMF services (or whatever) as required to get the scripts run in the correct context? If you want Oracle to run every time the machine boots, you should deliver an SMF manifest that sets up such a service. Mark it enabled as default, and set reset-fmri=svc:/system/manifest-import on the xml file that delivers the manifest. You're done. The start method should take care of whatever needs to be done at first boot. Is this about not wanting to create SMF services? - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Mon, Jun 15, 2009 at 11:53:13PM +0100, Peter Tribble wrote: You can implement this w/ actuators in IPS; it will require a SMF service to be running to handle your post-installation tasks. Note that packages built this way will actually work on alternate root install, with Oracle running once that environment is booted. If that's the way to do it, and if it's possible to automatically convert scripting into services, then why not fold that functionality into the packaging system so that it creates the SMF services (or whatever) as required to get the scripts run in the correct context? I've posted a prototype. There's been little or no interest. I assume that means that manual pkg script migration is good enough for those doing that now, though that would mostly be engineers working on Solaris. Customers might have a different view (but see below). It seems to me that the no scripting rule is more about the context in which the script runs rather than the existence or content of the script. _Exactly_. In that case, going to software packagers and saying just write your script to run correctly on a live image and we'll make sure its gets run in the right time and place without you having to worry about all these other possible installation scenarios would be a big selling point. And the packagers wouldn't have to worry about implementing the SMF services, avoiding a big hole they could dig themselves into. I agree, but in practice developers will have to at least choose an SMF FMRI. That's because that way you get a handle that can be used to check self-assembly status (which my SVR4-IPS scripting tool does not give you, though it could, but at the cost of creating more interfaces and at the cost of not getting dependency evaluation in running of self-assembly). Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Hi, You'd write an SMF service (start method included) that does all the configuration, then you'd pacakage it (with corresponding dependencies on the pkgs that deliver the Oracl DB product), and you'd add this pkg to the incorporation that your machines install. Arrg - and that should be more secure than using a postinstall script??? Sorry, but using an SMF Service for configuring an application makes developing of packages more complicated and will lead to lot of new errors regards Bernd Nicolas Williams wrote: On Sat, Jun 13, 2009 at 05:15:28AM -0700, UNIX admin wrote: The only reasoning you've provided so far, are there are scripts so it won't work. Again, I see nothing in those scripts *that is actually needed for the driver to work on 2009.06* that IPS does not provide. OK, fair enough. Please explain how you would configure and create an Oracle database with an IPS package, completely automatically, without any DBA intervention whatsoever. You'd write an SMF service (start method included) that does all the configuration, then you'd pacakage it (with corresponding dependencies on the pkgs that deliver the Oracl DB product), and you'd add this pkg to the incorporation that your machines install. I think what's missing there is a tool to make the above simpler: something that takes your start method, SMF FMRI, pkg FMRIs and incorporation FMRI and does the rest for you. Even better, if this work can be done once and made to support the use of profiles (as you suggest below) to do the configuration. Then the tool would be simpler still, as simple as you want it to be. How would you do it via IPS, in his current incarnation? Remember, all the sysadmin should have to do is: 1. select the package (either through a web browser, or an automated profile) 2. select a component (which would include the DB creation and RMAN configuration subcomponents) 3. deploy. Nico -- Bernd Schemmer, Frankfurt am Main, Germany http://bnsmb.de/ M s temprano que tarde el mundo cambiar . Fidel Castro ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On 14.06.09 09:20, Bernd Schemmer wrote: Hi, You'd write an SMF service (start method included) that does all the configuration, then you'd pacakage it (with corresponding dependencies on the pkgs that deliver the Oracl DB product), and you'd add this pkg to the incorporation that your machines install. Arrg - and that should be more secure than using a postinstall script??? Sorry, but using an SMF Service for configuring an application makes developing of packages more complicated and will lead to lot of new errors And how could the postinstall start the database, if the install is not on the live system? In case of live upgrade we have seen a lot of errors, where packages were not trully relocatable. We also had packages and patches which could not be deployed properly to a jumpstart image. The package was checking for the architecture and as it was an x86 jumpstart server, it failed for a sparc package. Same if the package expects hardware, which is available on the client, but not on the install server. Best regards Michael ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
One click installation triggers, like we have right now with pkg(5)? Try clicking one of the Install links on the development package repository page on a 2009.06 system: http://pkg.opensolaris.org/dev/en/catalog.shtml No, that's not it. You're thinking in terms of payload, and payload alone. What I'm writing about are DNS servers, serving out live data after package installation has finished. Databases, configured and then created completely automatically, without the DBA ever even so much as logging onto the system. Firewalls, with rules loaded and activated upon package installation completely automatically, without any kind of human interaction whatsoever. I could go on, and on, and on. Everything is componentized and modularized. The key concept to take away from this is repeatability. Consistent repeatability. No more haphazard hacking in vi or emacs until you get it to work, and until a restore from tape is your only recourse to ever get it to work again, should you leave the post. -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
I can tell you that enterprise-level management functionality is in development for the sort of mass deployment you're talking in the pkg(5) project, the Automated Installer project, and others. If it's in development, that's great, although without knowing any details about it, it's hard to say whether it is what is needed, or something else. So what is it? I'll be quite open and honest in stating that but it works on a single system, for a single user! is the approach Sun took for years when implementing new technologies. For example, zones are one such perfect example, especially if we consider, that there can be up to 8192 zones per system. The tools provided were focused on a lone developer's system, not on server farms with tens of thousands of systems in lights out management environment. Which is precisely why it was a nightmare and lots of political games, to push such a solution through in an enterprise environment. And it should not be that way. My stance on this is: if it is developed to work for an ulimited number of systems (like JumpStart(TM) + Flash(TM)), then it will work with ease on a single user's system because it was designed to SCALE. -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
IPS will (when finished) strictly enforce the following policies: But will he be able to do the following: - create true hierarchichal bundles and work with namespaces, like sgi inst(1M), IBM's instalp(1M), and HP-UX's swinstall(1M) can handle? - specify which subsystems / subproducts are installed by default? For example, ssh.man would be installed per default (marked D), but ssh.doc would not, unless explicitly selected by the installation profile, or the sysadmin? - support image-like installation, like Flash(TM)? - be able to insert, remove, or otherwise manipulate configuration files of appliactions which do not implement INCLUDE keywords? Hey, I've got 22,000 servers to worry about. Works on a single user's system just wouldn't cut it! Even if I wanted to, I couldn't possibly muck around 22,000 times! I don't believe I'd be done during my lifetime! -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
The only reasoning you've provided so far, are there are scripts so it won't work. Again, I see nothing in those scripts *that is actually needed for the driver to work on 2009.06* that IPS does not provide. OK, fair enough. Please explain how you would configure and create an Oracle database with an IPS package, completely automatically, without any DBA intervention whatsoever. What needs to happen is, after the package is deployed, the Oracle database processes are running, the TNS listener is accepting connections to the database, and the database is now ready to accept data. SYS, and SYSTEM accounts have been set to random passwords, which have been stored at a private location, read-only by root. All Oracle catalog scripts (catalog.sql, catexp.sql, utlrp.sql, and so on) have been executed. RMAN has been configured. The database is configured to backup via RMAN. The database is ready to have the data pumped into her. How would you do it via IPS, in his current incarnation? Remember, all the sysadmin should have to do is: 1. select the package (either through a web browser, or an automated profile) 2. select a component (which would include the DB creation and RMAN configuration subcomponents) 3. deploy. How would you do that via IPS, today? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
1. select the package (either through a web browser, or an automated profile) Correction: I meant to write select the server, not select the package. -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
There is a difference between driver installation for IPS and for SVR4. Namely, installing an SVR4 package would load a driver immediately, while IPS purposefully does not (currently). To activate, you must reboot, or manually load the driver. What is the point of running a true UNIX system, which supports dynamically loadable modules, if one must reboot just to load the driver non-interactively? Rebooting is something I know in the Windows world. On UNIX, drivers are loaded dynamically, because the operating system is perfectly capable of it. Not providing for dynamic driver loading and forcing either a reboot or manual intervention is defeating one of the major reasons for choosing UNIX over alternatives like Windows. -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Sat, 13 Jun 2009 07:37:20 PDT UNIX admin tripivc...@hotmail.com wrote: [...] is defeating one of the major reasons [...] MAJOR reasons...? You must be joking. -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D + http://nagual.nl/ | nevada / OpenSolaris 2009.06 release + All that's really worth doing is what we do for others (Lewis Carrol) ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Sat, Jun 13, 2009 at 05:15:28AM -0700, UNIX admin wrote: The only reasoning you've provided so far, are there are scripts so it won't work. Again, I see nothing in those scripts *that is actually needed for the driver to work on 2009.06* that IPS does not provide. OK, fair enough. Please explain how you would configure and create an Oracle database with an IPS package, completely automatically, without any DBA intervention whatsoever. You'd write an SMF service (start method included) that does all the configuration, then you'd pacakage it (with corresponding dependencies on the pkgs that deliver the Oracl DB product), and you'd add this pkg to the incorporation that your machines install. I think what's missing there is a tool to make the above simpler: something that takes your start method, SMF FMRI, pkg FMRIs and incorporation FMRI and does the rest for you. Even better, if this work can be done once and made to support the use of profiles (as you suggest below) to do the configuration. Then the tool would be simpler still, as simple as you want it to be. How would you do it via IPS, in his current incarnation? Remember, all the sysadmin should have to do is: 1. select the package (either through a web browser, or an automated profile) 2. select a component (which would include the DB creation and RMAN configuration subcomponents) 3. deploy. Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting Why are you redirecting me to something I've obviously read, am referring to, and DO NOT agree with? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Wed, Jun 10, 2009 at 12:00:35AM -0700, UNIX admin wrote: To the best of my knowledge and belief, as of right now, SMF provides no capability for a one time run, so getting post-installation code to run via SMF is tricky, with one svcadm refresh, and one svccfg delete. This thread's been beat to death, but what the heck :) It is definitely possible to build one-shot SMF services, as well as transient services that do nothing when there's nothing for them to do. I've done it as a proof of concept. A service can disable itself. And a service can even remove itself. Because SMF out of the box doesn't provide a way to do the latter it took some cleverness, namely: use ctrun(1) with an argument command that is, effectively, a shell script that waits for the service's state to change to offline then removes the service, all the while the parent disables the service. Is it really practical to take the no scripting zone design so far as to force people to resort to backdoors and hacks via SMF, which SMF doesn't even rightly support yet? I mean, if I have to use SMF to do postinstall, I clearly have the need to execute code upon software installation and removal. Why refuse to give me capability to do that in the packaging system? The IPS team's arguments for no pkg install/remove time scripting are, IMO, rock-solid. I would prefer that there were more examples and better conventions and tools around self-assembly, but that's nothing compared to what IPS solves just by not allowing install-time scripting. Any engineer who's had to fix SVR4 package class action scripts knows this deep down. Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Fri, Jun 12, 2009 at 12:43 PM, Nicolas Williamsnicolas.willi...@sun.com wrote: On Wed, Jun 10, 2009 at 12:00:35AM -0700, UNIX admin wrote: To the best of my knowledge and belief, as of right now, SMF provides no capability for a one time run, so getting post-installation code to run via SMF is tricky, with one svcadm refresh, and one svccfg delete. This thread's been beat to death, but what the heck :) It is definitely possible to build one-shot SMF services, as well as transient services that do nothing when there's nothing for them to do. I've done it as a proof of concept. A service can disable itself. And a service can even remove itself. Because SMF out of the box doesn't provide a way to do the latter it took some cleverness, namely: use ctrun(1) with an argument command that is, effectively, a shell script that waits for the service's state to change to offline then removes the service, all the while the parent disables the service. Is it really practical to take the no scripting zone design so far as to force people to resort to backdoors and hacks via SMF, which SMF doesn't even rightly support yet? I mean, if I have to use SMF to do postinstall, I clearly have the need to execute code upon software installation and removal. Why refuse to give me capability to do that in the packaging system? The IPS team's arguments for no pkg install/remove time scripting are, IMO, rock-solid. I would prefer that there were more examples and better conventions and tools around self-assembly, but that's nothing compared to what IPS solves just by not allowing install-time scripting. Any engineer who's had to fix SVR4 package class action scripts knows this deep down. No-scripting is one IPS design choice that I fully agree with although I was a little skeptical long back. In fact many enterprises which do significant in-house software development enforce script-less packages whether on Linux or Solaris. A single script bug in a single package can bring a production server to it's knees. While this is good, thinking through the impact it will have on application and layered software packages and providing adequate hooks to take care of configuration issues should have been much higher priority in the IPS development action-items. For eg. there is currently no way to package the following HP driver with IPS and have it working properly: http://h2.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=encc=usprodTypeId=15351prodSeriesId=3186080prodNameId=3288103swEnvOID=2023swLang=8mode=2taskId=135swItem=MTX-30012bd09e11426b9b289142e4 It modifies a bunch of configuration files. Regards, Moinak. -- http://www.belenix.org/ http://moinakg.wordpress.com/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Moinak Ghosh wrote: While this is good, thinking through the impact it will have on application and layered software packages and providing adequate hooks to take care of configuration issues should have been much higher priority in the IPS development action-items. For eg. there is currently no way to package I'm fairly certain pkg(5) users preferred the priorities to be on fixing performance issues and adding basic functionality. As you are aware, resources are finite, and so the most important items were prioritised. It is regrettable that more resources were not available so that the work you are talking about could not have been done sooner, but was necessary. Significant strides have been made in memory usage reduction, performance improvements, documentation, publication, repository browser user interface, and other areas. the following HP driver with IPS and have it working properly: http://h2.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=encc=usprodTypeId=15351prodSeriesId=3186080prodNameId=3288103swEnvOID=2023swLang=8mode=2taskId=135swItem=MTX-30012bd09e11426b9b289142e4 It modifies a bunch of configuration files. Actually, after looking at that particular driver's postinstall/checkinstall, etc. scripts, it doesn't appear to do anything more than add a driver to the system or remove it. Nothing stands out as requiring scripting, and I don't see it modifying any true configuration files. The few scripting items that are there don't apply to OpenSolaris 2009.06, including, the bootenv.rc changes, and the jumpstart preparation. Regardless, you are right that there are some specific cases that will have to be dealt with. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Fri, Jun 12, 2009 at 10:14 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: While this is good, thinking through the impact it will have on application and layered software packages and providing adequate hooks to take care of configuration issues should have been much higher priority in the IPS development action-items. For eg. there is currently no way to package I'm fairly certain pkg(5) users preferred the priorities to be on fixing performance issues and adding basic functionality. As you are aware, resources are finite, and so the most important items were prioritised. It is regrettable that more resources were not available so that the work you are talking about could not have been done sooner, but was necessary. Significant strides have been made in memory usage reduction, performance improvements, documentation, publication, repository browser user interface, and other areas. the following HP driver with IPS and have it working properly: http://h2.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=encc=usprodTypeId=15351prodSeriesId=3186080prodNameId=3288103swEnvOID=2023swLang=8mode=2taskId=135swItem=MTX-30012bd09e11426b9b289142e4 It modifies a bunch of configuration files. Actually, after looking at that particular driver's postinstall/checkinstall, etc. scripts, it doesn't appear to do anything more than add a driver to the system or remove it. Nothing stands out as requiring scripting, and I don't see it modifying any true configuration files. The few scripting items that are there don't apply to OpenSolaris 2009.06, including, the bootenv.rc changes, and the jumpstart preparation. Regardless, you are right that there are some specific cases that will have to be dealt with. I have found in practice that the driver does not work unless the class-action scripts are allowed to execute. Regards, Moinak. -- http://www.belenix.org/ http://moinakg.wordpress.com/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Moinak Ghosh wrote: On Fri, Jun 12, 2009 at 10:14 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: the following HP driver with IPS and have it working properly: http://h2.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=encc=usprodTypeId=15351prodSeriesId=3186080prodNameId=3288103swEnvOID=2023swLang=8mode=2taskId=135swItem=MTX-30012bd09e11426b9b289142e4 It modifies a bunch of configuration files. Actually, after looking at that particular driver's postinstall/checkinstall, etc. scripts, it doesn't appear to do anything more than add a driver to the system or remove it. Nothing stands out as requiring scripting, and I don't see it modifying any true configuration files. The few scripting items that are there don't apply to OpenSolaris 2009.06, including, the bootenv.rc changes, and the jumpstart preparation. Regardless, you are right that there are some specific cases that will have to be dealt with. I have found in practice that the driver does not work unless the class-action scripts are allowed to execute. There is a difference between driver installation for IPS and for SVR4. Namely, installing an SVR4 package would load a driver immediately, while IPS purposefully does not (currently). To activate, you must reboot, or manually load the driver. We have been discussing this particular behaviour. There have been concerns about having just-delivered code run at package install time. The compromise may be that have the post-execute phase of the driver install loads all drivers that had been added or updated, so that at least all bits are on the system before the potential panic. Could this be why you believe the class-action scripts are necessary? Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Fri, Jun 12, 2009 at 10:33 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: On Fri, Jun 12, 2009 at 10:14 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: the following HP driver with IPS and have it working properly: http://h2.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=encc=usprodTypeId=15351prodSeriesId=3186080prodNameId=3288103swEnvOID=2023swLang=8mode=2taskId=135swItem=MTX-30012bd09e11426b9b289142e4 It modifies a bunch of configuration files. Actually, after looking at that particular driver's postinstall/checkinstall, etc. scripts, it doesn't appear to do anything more than add a driver to the system or remove it. Nothing stands out as requiring scripting, and I don't see it modifying any true configuration files. The few scripting items that are there don't apply to OpenSolaris 2009.06, including, the bootenv.rc changes, and the jumpstart preparation. Regardless, you are right that there are some specific cases that will have to be dealt with. I have found in practice that the driver does not work unless the class-action scripts are allowed to execute. There is a difference between driver installation for IPS and for SVR4. Namely, installing an SVR4 package would load a driver immediately, while IPS purposefully does not (currently). To activate, you must reboot, or manually load the driver. We have been discussing this particular behaviour. There have been concerns about having just-delivered code run at package install time. The compromise may be that have the post-execute phase of the driver install loads all drivers that had been added or updated, so that at least all bits are on the system before the potential panic. Could this be why you believe the class-action scripts are necessary? No. This particular driver *requires* a reboot to work even when using SVR4. So IPS not loading drivers immediately after install is not an issue. If all the files are not updated as needed then the driver does not work at all. Regards, Moinak. -- http://www.belenix.org/ http://moinakg.wordpress.com/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Moinak Ghosh wrote: On Fri, Jun 12, 2009 at 10:33 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: On Fri, Jun 12, 2009 at 10:14 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: the following HP driver with IPS and have it working properly: http://h2.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=encc=usprodTypeId=15351prodSeriesId=3186080prodNameId=3288103swEnvOID=2023swLang=8mode=2taskId=135swItem=MTX-30012bd09e11426b9b289142e4 It modifies a bunch of configuration files. Actually, after looking at that particular driver's postinstall/checkinstall, etc. scripts, it doesn't appear to do anything more than add a driver to the system or remove it. Nothing stands out as requiring scripting, and I don't see it modifying any true configuration files. The few scripting items that are there don't apply to OpenSolaris 2009.06, including, the bootenv.rc changes, and the jumpstart preparation. Regardless, you are right that there are some specific cases that will have to be dealt with. I have found in practice that the driver does not work unless the class-action scripts are allowed to execute. There is a difference between driver installation for IPS and for SVR4. Namely, installing an SVR4 package would load a driver immediately, while IPS purposefully does not (currently). To activate, you must reboot, or manually load the driver. We have been discussing this particular behaviour. There have been concerns about having just-delivered code run at package install time. The compromise may be that have the post-execute phase of the driver install loads all drivers that had been added or updated, so that at least all bits are on the system before the potential panic. Could this be why you believe the class-action scripts are necessary? No. This particular driver *requires* a reboot to work even when using SVR4. So IPS not loading drivers immediately after install is not an issue. If all the files are not updated as needed then the driver does not work at all. Can you indicate which specific files can not be updated by an equivalent IPS package for this driver? IPS supports a driver action that should handle everything this package needs. The only configuration files that I saw the scripts for the SVR4 package altering that are needed for OpenSolaris 2009.x were driver related files. See man pkg.5 for info about the driver action. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Fri, Jun 12, 2009 at 11:32 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: On Fri, Jun 12, 2009 at 10:33 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: On Fri, Jun 12, 2009 at 10:14 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: the following HP driver with IPS and have it working properly: http://h2.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=encc=usprodTypeId=15351prodSeriesId=3186080prodNameId=3288103swEnvOID=2023swLang=8mode=2taskId=135swItem=MTX-30012bd09e11426b9b289142e4 It modifies a bunch of configuration files. Actually, after looking at that particular driver's postinstall/checkinstall, etc. scripts, it doesn't appear to do anything more than add a driver to the system or remove it. Nothing stands out as requiring scripting, and I don't see it modifying any true configuration files. The few scripting items that are there don't apply to OpenSolaris 2009.06, including, the bootenv.rc changes, and the jumpstart preparation. Regardless, you are right that there are some specific cases that will have to be dealt with. I have found in practice that the driver does not work unless the class-action scripts are allowed to execute. There is a difference between driver installation for IPS and for SVR4. Namely, installing an SVR4 package would load a driver immediately, while IPS purposefully does not (currently). To activate, you must reboot, or manually load the driver. We have been discussing this particular behaviour. There have been concerns about having just-delivered code run at package install time. The compromise may be that have the post-execute phase of the driver install loads all drivers that had been added or updated, so that at least all bits are on the system before the potential panic. Could this be why you believe the class-action scripts are necessary? No. This particular driver *requires* a reboot to work even when using SVR4. So IPS not loading drivers immediately after install is not an issue. If all the files are not updated as needed then the driver does not work at all. Can you indicate which specific files can not be updated by an equivalent IPS package for this driver? IPS supports a driver action that should handle everything this package needs. The only configuration files that I saw the scripts for the SVR4 package altering that are needed for OpenSolaris 2009.x were driver related files. IPS does not handle the actions performed by these scripts: i.bootenv.rc i.devlink i.master r.bootenv.rc r.devlink r.master See man pkg.5 for info about the driver action. I know quite a bit about the guts of IPS having played extensively with the source code and also written a drop-in plugin that provides - you may dig a grave for me - arbitrary package scripting support! This is needed at my work till more extensive configuration support is provided by IPS. Anyway this is beside the point. Regards, Moinak. -- http://www.belenix.org/ http://moinakg.wordpress.com/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Moinak Ghosh wrote: On Fri, Jun 12, 2009 at 11:32 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: On Fri, Jun 12, 2009 at 10:33 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: On Fri, Jun 12, 2009 at 10:14 PM, Shawn Walkerswal...@opensolaris.org wrote: Moinak Ghosh wrote: the following HP driver with IPS and have it working properly: http://h2.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=encc=usprodTypeId=15351prodSeriesId=3186080prodNameId=3288103swEnvOID=2023swLang=8mode=2taskId=135swItem=MTX-30012bd09e11426b9b289142e4 It modifies a bunch of configuration files. Actually, after looking at that particular driver's postinstall/checkinstall, etc. scripts, it doesn't appear to do anything more than add a driver to the system or remove it. Nothing stands out as requiring scripting, and I don't see it modifying any true configuration files. The few scripting items that are there don't apply to OpenSolaris 2009.06, including, the bootenv.rc changes, and the jumpstart preparation. Regardless, you are right that there are some specific cases that will have to be dealt with. I have found in practice that the driver does not work unless the class-action scripts are allowed to execute. There is a difference between driver installation for IPS and for SVR4. Namely, installing an SVR4 package would load a driver immediately, while IPS purposefully does not (currently). To activate, you must reboot, or manually load the driver. We have been discussing this particular behaviour. There have been concerns about having just-delivered code run at package install time. The compromise may be that have the post-execute phase of the driver install loads all drivers that had been added or updated, so that at least all bits are on the system before the potential panic. Could this be why you believe the class-action scripts are necessary? No. This particular driver *requires* a reboot to work even when using SVR4. So IPS not loading drivers immediately after install is not an issue. If all the files are not updated as needed then the driver does not work at all. Can you indicate which specific files can not be updated by an equivalent IPS package for this driver? IPS supports a driver action that should handle everything this package needs. The only configuration files that I saw the scripts for the SVR4 package altering that are needed for OpenSolaris 2009.x were driver related files. IPS does not handle the actions performed by these scripts: You say that without showing specifics. I looked at these same files, and see nothing that our driver action cannot do that the driver needs. You need to convince me that this won't work ;) i.bootenv.rc bootenv.rc does not apply to Solaris 10 after update 1 or to OpenSolaris 2009.06 at all. See the comments in the file itself. i.devlink i.master r.devlink r.master The driver action provides these as far as I know. The only reasoning you've provided so far, are there are scripts so it won't work. Again, I see nothing in those scripts *that is actually needed for the driver to work on 2009.06* that IPS does not provide. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
This thread's been beat to death, but what the heck :) That's the spirit! (:-) It is definitely possible to build one-shot SMF services, as well as transient services that do nothing when there's nothing for them to do. Sure. I know that it can be done because I've done it. My point is that it's a hack, and that I shouldn't have to resort to clever ways of working around an architectural flaw, just because someone (Steven Hahn) believes that that particular architectural flaw is the right thing to do. Because I claim that he does not have enough experience to make such claims. In fact, I know he doesn't because if he did, he would have never written a no scripting zone essay! He should come and see thousands of components that some of Sun's biggest customers have built with preinstall, postinstall, preremove, postremove, and class files. All completely non-interactive. Installable on an unlimited number of systems. In parallel. At the click of a button in a web browser. -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
UNIX admin wrote: All completely non-interactive. Installable on an unlimited number of systems. In parallel. At the click of a button in a web browser. One click installation triggers, like we have right now with pkg(5)? Try clicking one of the Install links on the development package repository page on a 2009.06 system: http://pkg.opensolaris.org/dev/en/catalog.shtml Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Fri, Jun 12, 2009 at 9:50 PM, Shawn Walkerswal...@opensolaris.org wrote: UNIX admin wrote: All completely non-interactive. Installable on an unlimited number of systems. In parallel. At the click of a button in a web browser. One click installation triggers, like we have right now with pkg(5)? Nothing so crude. We're talking fully automated deployment and configuration of systems and applications, precisely to a customers exacting specifications. Really, the job of a packaging system within this environment is to do what it's told, move the bits, and get out of the way. It shouldn't be in the business of making decisions or trying to enforce policies off its own bat. All the interesting stuff is driven by scripting of some sort. If the packaging system helps us, then we'll take advantage of the facilities that it offers; if it hinders us then we'll have to find a way round it. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Peter Tribble wrote: On Fri, Jun 12, 2009 at 9:50 PM, Shawn Walkerswal...@opensolaris.org wrote: UNIX admin wrote: All completely non-interactive. Installable on an unlimited number of systems. In parallel. At the click of a button in a web browser. One click installation triggers, like we have right now with pkg(5)? Nothing so crude. We're talking fully automated deployment and configuration of systems and applications, precisely to a customers exacting specifications. You're right that the solution implemented there is not targeted towards enterprise or mass deployment, which is why it may appear 'crude' when you try to apply it to something it wasn't designed for. However, I think it is quite slick for single end-user system installs. I can tell you that enterprise-level management functionality is in development for the sort of mass deployment you're talking in the pkg(5) project, the Automated Installer project, and others. Really, the job of a packaging system within this environment is to do what it's told, move the bits, and get out of the way. It shouldn't be in the business of making decisions or trying to enforce policies off its own bat. All Which is exactly why the pkg(5) doesn't provide arbitrary scripting; its focus is only on moving the bits into the right places and doing the minimum amount of work necessary for the system to be able to use those bits. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Peter Tribble wrote: Really, the job of a packaging system within this environment is to do what it's told, move the bits, and get out of the way. It shouldn't be in the business of making decisions or trying to enforce policies off its own bat. All the interesting stuff is driven by scripting of some sort. If the packaging system helps us, then we'll take advantage of the facilities that it offers; if it hinders us then we'll have to find a way round it. IPS will (when finished) strictly enforce the following policies: 1) All package dependencies are enforced: If a package has require dependencies, they will be installed. Packages may not be uninstalled if another package depends on them. Incorporations and minimum required versions are enforced. 2) The only action that's allowed to be duplicated in multiple packages that can be installed at the same time is a directory. If these restrictions are too onerous, you don't need a packaging system but tar or cpio may do what you want. Why do we feel this is the right choice? Because the job of the packaging system is to manage software on the machine according to the constraints imposed on that software by its developer, and by the administrator. This is what permits us to (mostly) seamlessly upgrade from one release to another without package history files, special code in a release-specific upgrade program, etc. We use dependencies to make sure that files moving from one package to another are correctly handled, that editable files changing names or packages are correctly handled, etc. To allow the admin to defeat such controls w/ the use of a -f option means that utter breakage is the inevitable result. If as an administrator you wish to break package dependencies, divide packages in half, etc, you need to repackage the software, because you're now using it in a manner un-envisioned (or perhaps seen only in a nightmare) by the original packager. All the tools necessary to do this will be part of OpenSolaris. The design of variants/facets was specifically targeted at allowing the package developer to describe a variety of different configuration options. If this mechanism doesn't provide sufficient flexibility, please speak up but allowing administrators to perform ad-hoc install-time overrides of the packaging system constraints is akin adding bpatch support to pkg. - Bart -- Bart Smaalders Solaris Kernel Performance ba...@cyber.eng.sun.com http://blogs.sun.com/barts You will contribute more with mercurial than with thunderbird. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
The escape clause in IPS is to install a one-shot SMF service that can do whatever you want, like assemble a config file from multiple bits. To the best of my knowledge and belief, as of right now, SMF provides no capability for a one time run, so getting post-installation code to run via SMF is tricky, with one svcadm refresh, and one svccfg delete. Is it really practical to take the no scripting zone design so far as to force people to resort to backdoors and hacks via SMF, which SMF doesn't even rightly support yet? I mean, if I have to use SMF to do postinstall, I clearly have the need to execute code upon software installation and removal. Why refuse to give me capability to do that in the packaging system? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On 10 Jun 2009, at 08:00, UNIX admin wrote: The escape clause in IPS is to install a one-shot SMF service that can do whatever you want, like assemble a config file from multiple bits. To the best of my knowledge and belief, as of right now, SMF provides no capability for a one time run, so getting post- installation code to run via SMF is tricky, with one svcadm refresh, and one svccfg delete. The IPS docs give an example of doing this, so I think you're wrong. http://dlc.sun.com/osol/docs/content/2008.11/IMGPACKAGESYS/ipsdev.html The example could be a bit clearer IMO, eg it could include a template for a one-shot service, but it sure looks like it is describing what you want. pkg-discuss may be a better place for discussing this. Cheers, Chris ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
UNIX admin wrote: The escape clause in IPS is to install a one-shot SMF service that can do whatever you want, like assemble a config file from multiple bits. To the best of my knowledge and belief, as of right now, SMF provides no capability for a one time run, so getting post-installation code to run via SMF is tricky, with one svcadm refresh, and one svccfg delete. Is it really practical to take the no scripting zone design so far as to force people to resort to backdoors and hacks via SMF, which SMF doesn't even rightly support yet? I mean, if I have to use SMF to do postinstall, I clearly have the need to execute code upon software installation and removal. Why refuse to give me capability to do that in the packaging system? http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Just to be clear - we're still talking about this *in addition to* retaining the existing /opt model for 3rd party (or unbundled) products which choose to use it, correct? My issue with this model is that it doesn't account for existing products well. There are vendors out there in the world who already deliver to /opt on many platforms, who may not be interested in investing the effort to change their product to deliver into /usr since that might require them to change the names of their binaries to avoid naming collisions, plus issues of documentation and retraining of existing customers. If such a registry had existing since the beginning of time there would be few issues, but imposing it on an existing market can create problems for vendors and thus we should not force it. -Bob Nicolas Williams wrote: On Sat, Jun 06, 2009 at 02:05:29AM -0700, UNIX admin wrote: Not necessarily. A registry, for example, would allow us to solve that problem. Does such a solution exist as of now? Technically, yes. Roughly: the ARC is the registrar and the product itself is the registry database. But you can see that that's not flexible enough to enable third-party delivery into /usr. In order to allow that we'd need a bonafide namespace registry database, and we'd need registration rules tailored for a world in which third parties can deliver into /usr. Is it documented anywhere how to interface with it? Effectively, yes (see above, and filesystem(5)). Is it easy and convenient to use? Yes, it is, though in its current incarnation it doesn't support third-party regitrations (see above). More seriously... Implementing a registry wouldn't be difficult, from a technical point of view (one of the myriad web front-ends to an open source DB would do, perhaps with a bit of DJango thrown in to make the UI prettier). The crucial issues would be all political: a) community consensus for such a thing, b) funding to implement such a thing, and, finally, c) finding or creating, and funding, a body suitable to act as a registrar. I doubt Shawn's alone in wanting third-party software delivered into /usr. It makes a lot of sense to me, for example. Why should users have to manage their PATH at all? To me the missing component is namespace management. I'm open too to the possibility that 3rd party software delivery into /usr is bad for other reasons I've not considered. For one, even a registry couldn't prevent political conflicts over the namespace. IIRC we've already seen conflicts between unrelated FOSS projects being fought over in OpenSolaris discuss lists (psarc-ext and opensolaris-arc). But a popular namespace registry could actually help prevent such conflicts in the future, particularly if other distros were to use it. Nico ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Sat, Jun 06, 2009 at 10:25:06AM +0200, dick hoogendijk wrote: On Fri, 5 Jun 2009 14:55:50 -0500 Nicolas Williams nicolas.willi...@sun.com wrote: Not necessarily. A registry, for example, would allow us to solve that problem. Would this be something like the windows registry? I sure hope not. Not at all. I was thinking of a registry in the IANA (iana.org) sense. Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Sat, Jun 06, 2009 at 02:05:29AM -0700, UNIX admin wrote: Not necessarily. A registry, for example, would allow us to solve that problem. Does such a solution exist as of now? Technically, yes. Roughly: the ARC is the registrar and the product itself is the registry database. But you can see that that's not flexible enough to enable third-party delivery into /usr. In order to allow that we'd need a bonafide namespace registry database, and we'd need registration rules tailored for a world in which third parties can deliver into /usr. Is it documented anywhere how to interface with it? Effectively, yes (see above, and filesystem(5)). Is it easy and convenient to use? Yes, it is, though in its current incarnation it doesn't support third-party regitrations (see above). More seriously... Implementing a registry wouldn't be difficult, from a technical point of view (one of the myriad web front-ends to an open source DB would do, perhaps with a bit of DJango thrown in to make the UI prettier). The crucial issues would be all political: a) community consensus for such a thing, b) funding to implement such a thing, and, finally, c) finding or creating, and funding, a body suitable to act as a registrar. I doubt Shawn's alone in wanting third-party software delivered into /usr. It makes a lot of sense to me, for example. Why should users have to manage their PATH at all? To me the missing component is namespace management. I'm open too to the possibility that 3rd party software delivery into /usr is bad for other reasons I've not considered. For one, even a registry couldn't prevent political conflicts over the namespace. IIRC we've already seen conflicts between unrelated FOSS projects being fought over in OpenSolaris discuss lists (psarc-ext and opensolaris-arc). But a popular namespace registry could actually help prevent such conflicts in the future, particularly if other distros were to use it. Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Sat, 6 Jun 2009 10:25:06 +0200, you wrote: On Fri, 5 Jun 2009 14:55:50 -0500 Nicolas Williams nicolas.willi...@sun.com wrote: Not necessarily. A registry, for example, would allow us to solve that problem. Would this be something like the windows registry? I sure hope not. As Nicolas said, it can be a plain text file. /etc/passwd is sometimes called a registry or database. BTW, the SMF registry is an SQLite database. Quite open. Advantages: standaradized language to access it, high performance because keyvalues can be indexed. -- ( Kees Nuyt ) c[_] ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
I think self assembling means delivering multiple files, and your software explicitly looking for all those files to configure (or whatever) itself. For an example, consider how Apache's httpd.conf file is often configured to include other files via a glob, eg /etc/httpd/local/*.conf Yes, this is how every software with configuration files should function. Unfortunately, not all do; BIND DNS software is one such example, where it allows include in certain places, but not everywhere, so that it becomes necessary to inject per-network and per-host entries into the .conf file(s). But, how to achieve such a thing with IPS? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Hi, [...] I'm very carefully staying out of the /opt debate as I know I don't understand enough of the consequences of. That said, the first step in being able to get this fix in is to fix the existing packages in our distro, something we could definitely use some help with since the problems, I believe, may be relevant for the nevada and S10 distros as well. The first thing to settle in the /opt debate is: what are the rules for OpenSolaris? So far we have Shawn's opinion, but we don't know that it's authoritative. Third parties can reasonably think that they have a pressing need to resolve that issue. Then we can leisurely debate what the answer should be (as opposed to what it is). man filesystem on Indiana is speaking clearly. Even Sun IPS repositories are delivering non-bundled SW to /opt No 3rd party SW should go to /usr (non-compliant SW could reuse /usr/local). At least Indiana documentation is written in such way. Best regards, Milan ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On 7 Jun 2009, at 12:43, UNIX admin wrote: I think self assembling means delivering multiple files, and your software explicitly looking for all those files to configure (or whatever) itself. For an example, consider how Apache's httpd.conf file is often configured to include other files via a glob, eg /etc/httpd/local/*.conf Yes, this is how every software with configuration files should function. Unfortunately, not all do; BIND DNS software is one such example, where it allows include in certain places, but not everywhere, so that it becomes necessary to inject per-network and per-host entries into the .conf file(s). Agreed. But, how to achieve such a thing with IPS? The escape clause in IPS is to install a one-shot SMF service that can do whatever you want, like assemble a config file from multiple bits. Cheers, Chris ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Fri, 5 Jun 2009 14:55:50 -0500 Nicolas Williams nicolas.willi...@sun.com wrote: Not necessarily. A registry, for example, would allow us to solve that problem. Would this be something like the windows registry? I sure hope not. -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D + http://nagual.nl/ | nevada / OpenSolaris 2009.06 release + All that's really worth doing is what we do for others (Lewis Carrol) ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Not necessarily. A registry, for example, would allow us to solve that problem. Does such a solution exist as of now? Is it documented anywhere how to interface with it? Is it easy and convenient to use? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
That file is what we'd call an editable file, so neither package should clobber it -- instead IPS pkgs should be self-assembling (and SVR4 pkgs should use class action scripts). Yes, pkgadd(1M) and prototype(4) deal with this in terms of editable files, and class action scripts. But the other feature of IPS, self assembling - how does it work??? Does it allow for removing and inserting entries into files? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On 6 Jun 2009, at 10:09, UNIX admin wrote: That file is what we'd call an editable file, so neither package should clobber it -- instead IPS pkgs should be self-assembling (and SVR4 pkgs should use class action scripts). Yes, pkgadd(1M) and prototype(4) deal with this in terms of editable files, and class action scripts. But the other feature of IPS, self assembling - how does it work??? Does it allow for removing and inserting entries into files? I think self assembling means delivering multiple files, and your software explicitly looking for all those files to configure (or whatever) itself. For an example, consider how Apache's httpd.conf file is often configured to include other files via a glob, eg /etc/httpd/local/*.conf Cheers, Chris ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 04, 2009 at 06:09:23PM -0700, Brock Pytlik wrote: Nicolas Williams wrote: I want to say the same thing, but for now I can't quite agree. The namespace issues are important. At the very least IPS needs to deal sanely with: - two or more pkgs in one repository with actions I assume you mean actions which overlap? This may or may not be an issue, depending on what packages a user wants to install. It would be nice if we could (optionally) catch this at publication time and that's something we may work towards in the future. Of course, this doesn't solve the problem of third party software delivering conflicting actions, but at least we could be self-consistent. I don't necessarily think it a bug to allow pkgs with conflicting actions into a repository _as long as_ they are treated as mutually exclusive (including from incorporations). - a user trying to install one or more pkgs whose actions would conflict with those a pkg that's already installed Known bug: http://defect.opensolaris.org/bz/show_bug.cgi?id=3822 One thing that's holding this up is that there are issues with the current nevada pacakges delivering conflicts (see the dependent bugs of that bug). Until we deliver a self-consistent set of packages, IPS is somewhat constrained on what we can do. Understood. Until then I think /opt must continue to be the place where SW is delivered that is not integrated into OpenSolaris (with /contrib being a repository of wannabe integrated packages. And when these issues are addressed then the /opt issue can be revisited (though I think I'd still want to see a registry in place before we really kiss /opt goodbye). Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
No, that is the issue. Being outside the ARC process, guidance beyond what's in filesystem(5) (which comes from a product, Solaris, that's developed in the ARC process), is needed. Agreed. what happens if a project wants to deliver /bin/foo directly with OpenSolaris, via a consolidation, and a third-party has already registered that name? And: what happens, when package A delivers for example /etc/ipf.conf, and package B wants to deliver entries into that file, such as additional firewall rules, or removal of firewall rules? Now we have package A (let's call him a base package), and package B (let's call him an overlay package), which both claim /etc/opt/ipf.conf. How would this be handled, assuming there are about 20,000 systems on which this manipulation must be performed, perhaps as part of an automated provisioning process? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Nicolas Williams wrote: On Thu, Jun 04, 2009 at 06:09:23PM -0700, Brock Pytlik wrote: Nicolas Williams wrote: I want to say the same thing, but for now I can't quite agree. The namespace issues are important. At the very least IPS needs to deal sanely with: - two or more pkgs in one repository with actions I assume you mean actions which overlap? This may or may not be an issue, depending on what packages a user wants to install. It would be nice if we could (optionally) catch this at publication time and that's something we may work towards in the future. Of course, this doesn't solve the problem of third party software delivering conflicting actions, but at least we could be self-consistent. I don't necessarily think it a bug to allow pkgs with conflicting actions into a repository _as long as_ they are treated as mutually exclusive (including from incorporations). I'll put it this way. It's a nice feature to have since it lets the publisher ensure that the wad of software they're distributing is self-consistent. But, that's all it is, a nice feature for the publisher. It doesn't remove the need for install time checks because John Doe and Joe Schmo may both publish packages which deliver /usr/bin/foo, without ever knowing about the other's existence. Given that it's more an audit/safety check for the publisher, I think this can fall lower on our priorities since fixing the problem at installation time solves all instances of the problem, though admittedly less cleanly than preventing the issue at publication time. - a user trying to install one or more pkgs whose actions would conflict with those a pkg that's already installed Known bug: http://defect.opensolaris.org/bz/show_bug.cgi?id=3822 One thing that's holding this up is that there are issues with the current nevada pacakges delivering conflicts (see the dependent bugs of that bug). Until we deliver a self-consistent set of packages, IPS is somewhat constrained on what we can do. Understood. Until then I think /opt must continue to be the place where SW is delivered that is not integrated into OpenSolaris (with /contrib being a repository of wannabe integrated packages. And when these issues are addressed then the /opt issue can be revisited (though I think I'd still want to see a registry in place before we really kiss /opt goodbye). I'm very carefully staying out of the /opt debate as I know I don't understand enough of the consequences of. That said, the first step in being able to get this fix in is to fix the existing packages in our distro, something we could definitely use some help with since the problems, I believe, may be relevant for the nevada and S10 distros as well. Brock Nico ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Fri, Jun 05, 2009 at 12:13:15PM -0700, UNIX admin wrote: And: what happens, when package A delivers for example /etc/ipf.conf, and package B wants to deliver entries into that file, such as additional firewall rules, or removal of firewall rules? That file is what we'd call an editable file, so neither package should clobber it -- instead IPS pkgs should be self-assembling (and SVR4 pkgs should use class action scripts). ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Nicolas Williams wrote: [snip] Delivering software directly into /usr would be the easiest thing to do, but only the distribution vendor may do it safely; and anybody who is not a distribution vendor, or cannot afford the effort of integrating, or cannot afford to have their software bundled with the distro, is stuck without /opt, /etc/opt, and /var/opt. Not necessarily. A registry, for example, would allow us to solve that problem. Could you expand on the idea of a registry a bit? My impression is that to solve this problem, the proposal is to have a central repository at which everyone who makes a package for distribution on OpenSolaris registers the file locations and properties, symlink and hardlink locations and targets, and directory permissions. To be truly safe, would things like SMF service names and properties be needed as well? Is the proposal that to install any package, IPS would first check this registry to ensure the package was registered properly? Is there an example of another community where this has been done, and done well? My impression is that this seems like a solution with a lot of overhead which depends on buy in from the community to voluntarily register the packages they publish. As a side note, whoever is in charge of the registry would also probably need to take on adjudicating disagreements between package publishers about who has the right to specific files/links/etc, a job which seems difficult to say the least. Brock ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Fri, Jun 05, 2009 at 01:31:17PM -0700, Brock Pytlik wrote: Nicolas Williams wrote: I don't necessarily think it a bug to allow pkgs with conflicting actions into a repository _as long as_ they are treated as mutually exclusive (including from incorporations). I'll put it this way. It's a nice feature to have since it lets the publisher ensure that the wad of software they're distributing is self-consistent. But, that's all it is, a nice feature for the Maybe, but then, since it's possible to have conflicts between, say, /contrib and /release (and these can arise after integration into /contrib), it's really not possible to prevent conflicts at publish-time. That said, trying to do that does no harm. [...] I'm very carefully staying out of the /opt debate as I know I don't understand enough of the consequences of. That said, the first step in being able to get this fix in is to fix the existing packages in our distro, something we could definitely use some help with since the problems, I believe, may be relevant for the nevada and S10 distros as well. The first thing to settle in the /opt debate is: what are the rules for OpenSolaris? So far we have Shawn's opinion, but we don't know that it's authoritative. Third parties can reasonably think that they have a pressing need to resolve that issue. Then we can leisurely debate what the answer should be (as opposed to what it is). Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? You shouldn't be copying /usr/lib/isaexec into /opt/abcd/lib either. Yes, I know, which is the primary reason why I asked this question. isaexec works with hard links only. I have no way to guarantee, that /opt will not be a separate filesystem: it might be shared out via NFS from a different system, for instance; hard links cannot span filesystems, soft links do not work, copying isaexec does not work for several reasons, one of which is that IPS is a no scripting zone, and another, that by doing a one time copy in postinstall, the now private copy of isaexec in /opt would not get patched like the one in /usr/lib/ would. Do you have any concrete suggestions, other than your software is incorrectly packaged for OpenSolaris 200x? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
One solution is to create a little program that utilizes the isaexec API and accepts a pathname to an executable. See isaexec(3C). Thanks Moinak. I did exactly what you told me, and it worked, except that I replicated /usr/lib/isaexec functionality. As it turns out, a hard link is needed because of getexecname(3C), as follows: return(isaexec(getexecname(), argv, envp)); getexecname(3C) follows a symbolic link, so isaexec(3C) now has a wrong argument for *path. If I were to follow this approach, a small program with either a hardcoded path return(isaexec(/opt/abcd/bin/bla, argv, envp)); would have to be compiled for every single binary of every single product I deliver (think of it as one copy of isaexec(3C) per binary), or I would use one such isaexec in /opt/abcd/lib, but then I'm back to the hard links cannot span filesystems problem. Finally, a third approach would be to build my own parser similar to getexecname(3C), which would return the name of the symbollic link instead of the name of the target file, but this would require path reconstruction in order to pass to isaexec(3C) correctly. Any other ideas? -- This message posted from opensolaris.org ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Alternatively, you can deliver your own copy of isaexec. isaexec works with hard links only. I have no way to guarantee, that /opt will not be a separate filesystem: it might be shared out via NFS from a different system, for instance; hard links cannot span filesystems, soft links do not work, copying isaexec does not work for several reasons, one of which is that IPS is a no scripting zone, and another, that by doing a one time copy in postinstall, the now private copy of isaexec in /opt would not get patched like the one in /usr/lib/ would. Do you have any concrete suggestions, other than your software is incorrectly packaged for OpenSolaris 200x? See above. Your last alternative is to contribute the work to fix isaexec. I think you'll find that many engineers feel that it has several design issues, such as the one you've discovered, that need to be resolved. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Shawn Walker wrote: UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Uh, Shawn... you're conflating things **Sun** had not delivered to /usr/bin and instead used /usr/gnu with software **others**, who are not part of the distro, want to deliver to OpenSolaris. None of the documents you've referenced above indicate third parties should start delivering software to the UNIX system repository (/usr). In fact the ARC guidelines _specify_ /opt, /var/opt, /etc/opt and friends for Add-on system software or applications: http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. - Matt ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Matt Ingenthron wrote: Shawn Walker wrote: UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Uh, Shawn... you're conflating things **Sun** had not delivered to /usr/bin and instead used /usr/gnu with software **others**, who are not part of the distro, want to deliver to OpenSolaris. None of the documents you've referenced above indicate third parties should start delivering software to the UNIX system repository (/usr). In fact the ARC guidelines _specify_ /opt, /var/opt, /etc/opt and friends for Add-on system software or applications: http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. Otherwise, some of the same problems stated in there are going to occur with third-party software. It is my belief that most new users are going to expect to be able to user their software right away when they install it without modifying their $PATH. Others are free to interpret as they like, but that is my view. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Shawn Walker wrote: Matt Ingenthron wrote: Shawn Walker wrote: UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Uh, Shawn... you're conflating things **Sun** had not delivered to /usr/bin and instead used /usr/gnu with software **others**, who are not part of the distro, want to deliver to OpenSolaris. None of the documents you've referenced above indicate third parties should start delivering software to the UNIX system repository (/usr). In fact the ARC guidelines _specify_ /opt, /var/opt, /etc/opt and friends for Add-on system software or applications: http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. Could you reference where this was communicated? (I don't think you can) What you've supplied thus far has to do with software Sun has bundled. I've referenced where Sun has specified otherwise. Please use the ARC community to get this documented correctly if you're so sure of the change. Otherwise, some of the same problems stated in there are going to occur with third-party software. It is my belief that most new users are going to expect to be able to user their software right away when they install it without modifying their $PATH. Others are free to interpret as they like, but that is my view. Cheers, ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 04, 2009 at 11:15:45AM -0700, Matt Ingenthron wrote: Shawn Walker wrote: Matt Ingenthron wrote: Shawn Walker wrote: As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. There's no mention whatsoever of /opt in the opinion for PSARC/2005/185, and none in the final spec for PSARC/2007/048. /opt/sfw was never an official location -- the companion CD was not a product in ARC parlance. /usr/sfw *is* obsolete, and everything in there is moving out into /usr. Therefore /opt is still the location that 3rd parties should use _as far as the ARC is concerned. http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. Agreed. I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. You do (and I might, as you can see below), but the ARC clearly does not. Now, it's possible that for OpenSolaris we'd want to change that, and to the extent that changes for OpenSolaris haven't all been reviewed by the ARC, it's possible that what you say is, in fact, correct for OpenSolaris. If so, that would one more change to document to the ARC eventually, and also, that would be a change that should be communicated to OpenSolaris developers ASAP, including, for example, by making sure that filesystem(5) is different on OpenSolaris than on Nevada. I myself am not sure where third-party pkgs should install into. FOSS could always be integrated directly into OpenSolaris via the consolidation process, or perhaps via /contrib, in which case it will end up in /usr -- to me this argues for third parties packaging FOSS to install into /usr, and I'm not sure why non-FOSS should be treated differently in this regard. Right now I lean towards third parties installing code into /usr. Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Matt Ingenthron wrote: Shawn Walker wrote: Matt Ingenthron wrote: Shawn Walker wrote: UNIX admin wrote: The answer is that your software is not correctly packaged for OpenSolaris 200x :) Do you mind pointing out what exactly makes my software incorrectly packaged for OpenSolaris? Is there a formal specification document which details how and in what places Indiana expects to have software packaged? As noted in: PSARC/2005/185 Enabling serendipitous discovery PSARC/2007/048 Include GNU coreutils 6.7 PSARC/1991/061 Packaging rules for system extensions ...many bits of software are moving to /usr :) Death to /opt/sfw, /usr/sfw, etc. Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Uh, Shawn... you're conflating things **Sun** had not delivered to /usr/bin and instead used /usr/gnu with software **others**, who are not part of the distro, want to deliver to OpenSolaris. None of the documents you've referenced above indicate third parties should start delivering software to the UNIX system repository (/usr). In fact the ARC guidelines _specify_ /opt, /var/opt, /etc/opt and friends for Add-on system software or applications: http://opensolaris.org/os/community/arc/policies/install-locations/ Respectfully, I believe you are quite wrong on this. I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. Could you reference where this was communicated? (I don't think you can) My point was that for some of the same reasons that Sun is moving software from /usr/sfw, etc. to /usr are equally applicable to third-party software. What you've supplied thus far has to do with software Sun has bundled. I've referenced where Sun has specified otherwise. Please use the ARC community to get this documented correctly if you're so sure of the change. You're certainly welcome to do so; I have plenty of other things to do :) Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Nicolas Williams wrote: I myself am not sure where third-party pkgs should install into. FOSS could always be integrated directly into OpenSolaris via the consolidation process, or perhaps via /contrib, in which case it will end up in /usr -- to me this argues for third parties packaging FOSS to install into /usr, and I'm not sure why non-FOSS should be treated differently in this regard. Right now I lean towards third parties installing code into /usr. Which is why I believe it belongs in /usr. Again, I have no idea what ARC has or has not decided beyond the serendpituous discovery cases, etc. All I know is that the reasons stated for moving stuff from /usr/sfw, etc. seem equally applicable regardless of who provides the software. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
a b wrote: ...many bits of software are moving to /usr :) Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Consider that if I deliver my software in /usr (as a 3rd party unbundled applications vendor), I run an extremely high risk of: a) being overwritten by IPS, respectively your own updates b) my software overwriting your software. Work is scheduled to alter packaging system to prevent a user from installing packages with conflicting resources. It is actually desirable that some software delivers into the same place to allow it to replace another component. It appears that these architectural issue have not been thought throughly. The OpenSolaris distribution, as you are aware, is experimenting with changes that have not yet made it through ARC. Regardless, I don't see the issue here. Ubuntu, et al. are quite successful despite the lack of adherence to the Sys V filesystem specification from a user perspective. I won't debate the merits, etc. of this with your nor comment on what should or should not be done architecturally as that isn't my responsibility. I'll just simply say that I see no issue with packaging for /usr as most packages are moving towards, and that I believe most users will expect that. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
...many bits of software are moving to /usr :) Deliver to /usr; your life will be simpler, many users will thank you, and you won't have this issue. Consider that if I deliver my software in /usr (as a 3rd party unbundled applications vendor), I run an extremely high risk of: a) being overwritten by IPS, respectively your own updates b) my software overwriting your software. Death to /opt/sfw, /usr/sfw, etc. It appears that these architectural issue have not been thought throughly. You know, System V filesystem specification and /opt, exist for a reason. So do things like /usr/openwin, /usr/dt, /usr/sfw, and so on. The engineers didn't put them under separate directories out of wanton arrogance, but out of necessity. It is impractical to assume that every single entity, be it a person or an organization will actually be willing to go through the hoops to integrate into Indiana. What are commercial vendors going to do? Take Oracle, SAP, Legato NetWorker, Veritas and so on. A lot of these vendors deliver utilities which would overlap with the operating system applications and utilities. It is impractical to deliver into /usr; and delivering into /usr/product would create PATH hell, where one would have to have a discrete PATH added for every 3rd party / commercial product, which is impractical. Did you even consider these issues before you cried out Death to /opt/sfw? See above. Your last alternative is to contribute the work to fix isaexec. I think you'll find that many engineers feel that it has several design issues, such as the one you've discovered, that need to be resolved. I very well might, but fixing isaexec(3C) is not going to fix a no scripting zone issue, nor will it fix the architectural issues I described above. Indiana has a problem. And not just any problem, it has several serious architectural issues, and those are the worst kind of problems. I cannot simply solve these architectural issues with just code. Some consideration is needed as well, and not just on my part. _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
I disagree. For many of the same reasons stated in PSARC/2005/185, I believe even third-party software belongs in /usr. If you don't mind, would you please explain how software which enhances the OS yet works in a different way (such as for example 3rd party clustering software) would be able to deliver the payload, without overwriting binaries found in /usr/bin and /usr/lib, if the software were delivered into /usr? Are you saying that you expect a company like SAP or Symantec (or any other commercial vendor) to go through the integration into Indiana? Otherwise, some of the same problems stated in there are going to occur with third-party software. It is my belief that most new users are going to expect to be able to user their software right away when they install it without modifying their $PATH. It is my belief that Indiana will have an even bigger problem if it is architecturally incapable of supporting commercial applications. Do you also expect startups to bundle their commercial software, which might also require a paid-for license, into Indiana? _ Windows Live™: Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 04, 2009 at 04:34:52PM -0500, Shawn Walker wrote: Nicolas Williams wrote: I myself am not sure where third-party pkgs should install into. FOSS could always be integrated directly into OpenSolaris via the consolidation process, or perhaps via /contrib, in which case it will end up in /usr -- to me this argues for third parties packaging FOSS to install into /usr, and I'm not sure why non-FOSS should be treated differently in this regard. Right now I lean towards third parties installing code into /usr. Which is why I believe it belongs in /usr. Again, I have no idea what ARC has or has not decided beyond the serendpituous discovery cases, You surely can know: read the case materials/opinions. (They say nothing about /opt being deprecated.) etc. All I know is that the reasons stated for moving stuff from /usr/sfw, etc. seem equally applicable regardless of who provides the software. Maybe. The difference between third-party and ARC-reviewed software is this: the ARC manages the namespace to prevent conflicts, while third parties don't. Of course, there can be conflicts in /opt, but those are unlikely, particularly if third-parties use the stock symbol prefix tradition. Right now our only namespace management for things in /usr (in /usr/bin, ...) is this: first one there wins, and to win you need to a) ARC, b) integrate. If third parties can deliver straight into /usr/bin and friends then what should users do when conflicts arise? How will two parties resolve the conflict over a desirable name? Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 04, 2009 at 04:37:51PM -0500, Shawn Walker wrote: a b wrote: It appears that these architectural issue have not been thought throughly. The OpenSolaris distribution, as you are aware, is experimenting with changes that have not yet made it through ARC. Regardless, I don't see the issue here. Ubuntu, et al. are quite successful despite the lack of adherence to the Sys V filesystem specification from a user perspective. No, that is the issue. Being outside the ARC process, guidance beyond what's in filesystem(5) (which comes from a product, Solaris, that's developed in the ARC process), is needed. I won't debate the merits, etc. of this with your nor comment on what should or should not be done architecturally as that isn't my responsibility. I'll just simply say that I see no issue with packaging for /usr as most packages are moving towards, and that I believe most users will expect that. I want to say the same thing, but for now I can't quite agree. The namespace issues are important. At the very least IPS needs to deal sanely with: - two or more pkgs in one repository with actions - a user trying to install one or more pkgs whose actions would conflict with those a pkg that's already installed Additionally we could use a namespace registry (preferably one that could be used by Linux distros too). Even then we'd need rules as to whether new conflicts can be created, and conflict resolution. E.g., what happens if a project wants to deliver /bin/foo directly with OpenSolaris, via a consolidation, and a third-party has already registered that name? Nico -- ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
On Thu, Jun 04, 2009 at 08:11:48PM +0200, a b wrote: Consider that if I deliver my software in /usr (as a 3rd party unbundled applications vendor), I run an extremely high risk of: a) being overwritten by IPS, respectively your own updates b) my software overwriting your software. I agree. This has to be avoided. That does not mean that there's no way to enable third-party delivery into /usr (see my other reply). Death to /opt/sfw, /usr/sfw, etc. It appears that these architectural issue have not been thought throughly. PSARC certainly has discussed these issues at length. This is the first I hear that where third-party software goes is different for Nevada than for OpenSolaris. And I'm not sure that that's anything other than Shawn's opinion -- documentation is needed. See above. Your last alternative is to contribute the work to fix isaexec. I think you'll find that many engineers feel that it has several design issues, such as the one you've discovered, that need to be resolved. I very well might, but fixing isaexec(3C) is not going to fix a no scripting zone issue, nor will it fix the architectural issues I described above. Different issue. Indiana has a problem. And not just any problem, it has several serious architectural issues, and those are the worst kind of problems. I cannot simply solve these architectural issues with just code. Some consideration is needed as well, and not just on my part. I'm not sure I agree because I'm not sure that what Shawn said about /opt is anything other than personal opinion. IMO if IPS can deal sanely with conflicts, and preferably a registry is provided, then recommending /usr over /opt may be a good idea, but deprecating /opt wouldn't be a good idea for a long time yet. ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural
Nicolas Williams wrote: On Thu, Jun 04, 2009 at 04:37:51PM -0500, Shawn Walker wrote: a b wrote: [snip] I won't debate the merits, etc. of this with your nor comment on what should or should not be done architecturally as that isn't my responsibility. I'll just simply say that I see no issue with packaging for /usr as most packages are moving towards, and that I believe most users will expect that. I want to say the same thing, but for now I can't quite agree. The namespace issues are important. At the very least IPS needs to deal sanely with: - two or more pkgs in one repository with actions I assume you mean actions which overlap? This may or may not be an issue, depending on what packages a user wants to install. It would be nice if we could (optionally) catch this at publication time and that's something we may work towards in the future. Of course, this doesn't solve the problem of third party software delivering conflicting actions, but at least we could be self-consistent. - a user trying to install one or more pkgs whose actions would conflict with those a pkg that's already installed Known bug: http://defect.opensolaris.org/bz/show_bug.cgi?id=3822 One thing that's holding this up is that there are issues with the current nevada pacakges delivering conflicts (see the dependent bugs of that bug). Until we deliver a self-consistent set of packages, IPS is somewhat constrained on what we can do. Brock Additionally we could use a namespace registry (preferably one that could be used by Linux distros too). Even then we'd need rules as to whether new conflicts can be created, and conflict resolution. E.g., what happens if a project wants to deliver /bin/foo directly with OpenSolaris, via a consolidation, and a third-party has already registered that name? Nico ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural problem
UNIX admin wrote: My problem is simple: I want to deliver both 32- and 64-bit binary payload in my packages. In order for the system to run the correct binary, I use isaexec(3C). The problems start with the fact that I adhere strictly to the filesystem(5) manual page, respectively the System V filesystem specification. Since my payload falls under 3rd party and unbundled applications, it goes into /opt, and /etc/opt, and /var/opt, as per spec. Now, since /opt can be a separate filesystem, and isaexec does not work/operate with soft links, I'm forced to bundle my own copy of isaexec in /opt/abcd/lib/isaexec. A better but not perfect solution would be to copy /usr/lib/isaexec into /opt/abcd/lib/, but the IPS packaging system does not provide the postinstall facility, since it is a no scripting zone. Between isaexec working only with hard links and IPS not providing any way to execute scripts at installation time, do any of you have any suggestions how to solve this architectural problem? The answer is that your software is not correctly packaged for OpenSolaris 200x :) You shouldn't be copying /usr/lib/isaexec into /opt/abcd/lib either. Cheers, -- Shawn Walker ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] no scripting zone and isaexec(3C) == architectural problem
On Wed, Jun 3, 2009 at 6:54 PM, UNIX admin tripivc...@hotmail.com wrote: My problem is simple: I want to deliver both 32- and 64-bit binary payload in my packages. In order for the system to run the correct binary, I use isaexec(3C). The problems start with the fact that I adhere strictly to the filesystem(5) manual page, respectively the System V filesystem specification. Since my payload falls under 3rd party and unbundled applications, it goes into /opt, and /etc/opt, and /var/opt, as per spec. Now, since /opt can be a separate filesystem, and isaexec does not work/operate with soft links, I'm forced to bundle my own copy of isaexec in /opt/abcd/lib/isaexec. A better but not perfect solution would be to copy /usr/lib/isaexec into /opt/abcd/lib/, but the IPS packaging system does not provide the postinstall facility, since it is a no scripting zone. Between isaexec working only with hard links and IPS not providing any way to execute scripts at installation time, do any of you have any suggestions how to solve this architectural problem? One solution is to create a little program that utilizes the isaexec API and accepts a pathname to an executable. See isaexec(3C). Regards, Moinak. -- http://www.belenix.org/ http://moinakg.wordpress.com/ ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
