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/
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
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
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!
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
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
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
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
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
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
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
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,
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
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
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,
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
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
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
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.
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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:
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:
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
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:
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
+
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
...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
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
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
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
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
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
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
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
92 matches
Mail list logo
