[OpenIndiana-discuss] complaint about dovecot in sfe IPS not starting.

Jonathan Adams t12nslookup at gmail.com
Mon Feb 25 15:02:12 UTC 2013


actually, probably the issue is more with the fact that the package
went into maintenance, it would probably be better to go offline if
the configuration files wasn't there ...

however it trying to run allowed the script to output that the config
files didn't exist ... so maybe it _is_ best leaving it the way it is.

On 25 February 2013 14:50, Jim Klimov <jimklimov at cos.ru> wrote:
> On 2013-02-25 14:54, Dmitry Kozhinov wrote:
>>
>> I am not accusing anyone, but just trying to understand:
>> Why not make a package so that it would run out-of-the-box?
>>
>> When you buy a car, imagine that engine would not start unless you:
>> - Kick right rear tire;
>> - Open and close trunk lid;
>> - You name what else...
>>
>> Maybe those who know what-to-do (to simply get a package running) feel
>> themselves gurus, which is cool, but obviously making things go this way
>> condemns the great OS into extinction.
>
>
>
> The steps you've described are more akin to the need to pick correct
> dependencies and rule out possible conflicts of several implementations,
> as also happens to be needed - and indeed, such packages should be
> fixed.
>
> There are many other packages which can work "as is" either because
> they need no custom configuration (i.e. an office suite), or because
> they can use some system configs (default domain name, UNIX user ids)
> and thus not require customization - although that is often needed
> down the road. For example, a web browser might need proxy settings
> if it doesn't consult http_proxy envvars, or trust to your corporate
> CA root, and those settings are too custom to distribute in a common
> repository (though in a corporate setting you might like to maintain
> your own repo with common settings baked into packages).
>
> And there are programs which require configuration. You can't go around
> that - an LDAP server or a database needs to know its root suffix name
> and unique administrative login credentials, its clients - also. Even
> getting to work something as simple as an NTP client might require that
> you provide your preferred NTP servers (i.e. ones in your LAN, or from
> your nearby ISP); relaying from sendmails through a common single relay
> requires you to set the DS option (aka smarthost), etc.
>
> What *could* be done better in such cases is provision of SMF manifests
> to integrate the services, including dependencies on config files - so
> that if the service fails to start, "svcs -xv" can better show you why.
> And also I've just recently raised an RFE to have a common svcadm option
> to enable/restart/clear an SMF service instance in one command and not
> caring about the service's previous state.
>
> There are many examples of programs which include separate steps of
> installation (which provides files onto a filesystem) and configuration
> (which customizes the setup and enables services). Often the config
> programs can implement a "silent" mode, so that they don't ask questions
> interactively but rather read prepared answer-files (usually made by
> saving another config session's results into a special format).
>
> Remember that the packaging paradigm, especially with IPS, considers the
> delivery of packaged software into non-executing OS images (i.e. into an
> inactive local zone), and any configuration would run only in this zone
> context when it boots. This is assumed more reliable than the preinstall
> and postinstall scripts in SVR4 which were written before local zones
> were invented and never changed since then. Some packages now use some
> hackery like SMF services which do the same tasks to configure the
> custom installation and self-destruct or hide. I am not sure how well
> this works along with de-configuration and removal of packages (i.e.
> preremove/postremove in SVR4 terms) and how upgrades are differentiated.
>
> HTH,
> //Jim
>
> PS: At least, in many cases we are beyond DIY car sales, where you get
> boxes of components, a purse of tools and documentation - and build
> your car just like you would assemble an IKEA bed. Though, this is not
> yet always the case in IT (nor is it generally possible for each and
> any package).
>
> Being, apparently, from Russia you should know that this is not very
> much a joke - a reform of the car industry did once suggest such
> distribution of cars: factories don't do a very high quality job
> anyway, so people often have to take new cars apart and rebuild them.
> Distributing boxes of pieces would save everyone time and money ;)
>
> //Jim
>
>
>
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss



More information about the OpenIndiana-discuss mailing list