# [OmniOS-discuss] file system organisation for pkg packages

Eric Sproul esproul at omniti.com
Thu Sep 26 16:15:56 UTC 2013

- Previous message: [OmniOS-discuss] file system organisation for pkg packages
- Next message: [OmniOS-discuss] file system organisation for pkg packages
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Thu, Sep 26, 2013 at 10:55 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
    > from a system management point of view I like to have a simple rule
    > to decide where the config is and where the 'data' is ...
    >
    > so keeping the application in /opt/vendor is perfect for the static
    > part of the application ...
    >
    > but having the configuration and the data in the same tree makes it
    > harder to know what is part of the distribution and what is part of
    > the application ...
    >
    > I can obviously use symlinks to fix things, but it would be great
    > if there were some admin friendly suggestions ...

    I completely agree.  Local and/or app-specific configuration, data,
    logs. etc. belongs in an entirely different location that is not under
    packaging control.  For example, at OmniTI, we have Apache in
    /opt/apache22, but all app data lives under /www, so the httpd.conf is
    in /www/etc, logs are in /www/logs, etc.  In most of our projects,
    /www is an SCM checkout, where httpd.conf and an SMF manifest are
    under project-specific control.

    This model has worked well for us, because everyone can share a
    package that delivers a few sample files for bootstrapping new
    projects, but stays out of the way of the project-specific pieces.

    In my personal opinion, having multiple providers trying to deliver
    bits to the same set of shared directories just invites collisions and
    misery.

- Previous message: [OmniOS-discuss] file system organisation for pkg packages
- Next message: [OmniOS-discuss] file system organisation for pkg packages
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list