FAQ
Afternoon all.

I've been reading around on Puppet and Oracle, and have come up with a few
links that suggest how to get Oracle installed and base configured, which
has got me started in the right direction on that.

My next challenge is maintaining Oracle database specific configuration on
the relevant hosts. This contains various elements, such as /etc/oratab,
/etc/oranfstab (as we're using dNFS), various NFS mounts required for a
given database, and a few other bits and pieces...
Ideally, it would be a 1-to-1 relationship between a given host and a given
DB. However that's unlikely in our env - We're more likely to have 1 or
multiple databases on a given host, which all need to be maintained.

My initial thoughts are to use something like hiera to maintain this
configuration data.
Is this my best approach? Any other suggestions? Anyone doing this for
real?

Basically, any info/pointers you give me is greatly appreciated.

Regards
Gavin

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Tim Mooney at Oct 24, 2012 at 5:12 pm

    In regard to: [Puppet Users] Puppet & Oracle Database config management,...:

    My next challenge is maintaining Oracle database specific configuration on
    the relevant hosts. This contains various elements, such as /etc/oratab,
    /etc/oranfstab (as we're using dNFS), various NFS mounts required for a
    given database, and a few other bits and pieces...
    Ideally, it would be a 1-to-1 relationship between a given host and a given
    DB. However that's unlikely in our env - We're more likely to have 1 or
    multiple databases on a given host, which all need to be maintained.

    My initial thoughts are to use something like hiera to maintain this
    configuration data.
    Is this my best approach? Any other suggestions? Anyone doing this for
    real?
    We're doing it, but not particularly well.

    We mostly configure the prereqs for Oracle -- packages, user & group,
    limits.d entries, profile.d shell settings, sysctl, paths, etc. We use
    puppet's file shipping for tnsnames.ora. I don't think we're actually
    managing /etc/oratab; the first run of puppetizing our db servers left
    some content that we allow the DBA to change directly.

    I am using hiera for the sysctl settings, along with a bit of logic in
    the manifest for whether AMM is in use or hugepages.

    We too have multiple databases per host, which complicates things
    somewhat.

    If you come up with something you feel is even moderately elegant,
    consider sharing it on the forge.

    Tim
    --
    Tim Mooney tim.mooney@ndsu.edu
    Enterprise Computing & Infrastructure 701-231-1076 (Voice)
    Room 242-J6, IACC Building 701-231-8541 (Fax)
    North Dakota State University, Fargo, ND 58105-5164

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Gavin Williams at Oct 25, 2012 at 11:03 am
    Tim

    Cheers for the info.

    Have you got any examples of the hiera config you're using?

    Cheers
    Gavin
    On Wednesday, 24 October 2012 18:13:01 UTC+1, Tim Mooney wrote:

    In regard to: [Puppet Users] Puppet & Oracle Database config
    management,...:
    My next challenge is maintaining Oracle database specific configuration on
    the relevant hosts. This contains various elements, such as /etc/oratab,
    /etc/oranfstab (as we're using dNFS), various NFS mounts required for a
    given database, and a few other bits and pieces...
    Ideally, it would be a 1-to-1 relationship between a given host and a given
    DB. However that's unlikely in our env - We're more likely to have 1 or
    multiple databases on a given host, which all need to be maintained.

    My initial thoughts are to use something like hiera to maintain this
    configuration data.
    Is this my best approach? Any other suggestions? Anyone doing this for
    real?
    We're doing it, but not particularly well.

    We mostly configure the prereqs for Oracle -- packages, user & group,
    limits.d entries, profile.d shell settings, sysctl, paths, etc. We use
    puppet's file shipping for tnsnames.ora. I don't think we're actually
    managing /etc/oratab; the first run of puppetizing our db servers left
    some content that we allow the DBA to change directly.

    I am using hiera for the sysctl settings, along with a bit of logic in
    the manifest for whether AMM is in use or hugepages.

    We too have multiple databases per host, which complicates things
    somewhat.

    If you come up with something you feel is even moderately elegant,
    consider sharing it on the forge.

    Tim
    --
    Tim Mooney Tim.M...@ndsu.edu<javascript:>
    Enterprise Computing & Infrastructure 701-231-1076
    (Voice)
    Room 242-J6, IACC Building 701-231-8541 (Fax)
    North Dakota State University, Fargo, ND 58105-5164
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/m5o5k9zdf_AJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Tim Mooney at Oct 25, 2012 at 5:20 pm

    In regard to: Re: [Puppet Users] Puppet & Oracle Database config...:

    Have you got any examples of the hiera config you're using?
    As I said, it's pretty rough.

    class oracledb::sysctl(
    $use_amm = false,
    $large_mem_pages = '0',
    $hugetlb_gid = '1001',
    ) {

    validate_bool($use_amm)
    validate_string($large_mem_pages)
    validate_string($hugetlb_gid)

    if ( $use_amm and ($large_mem_pages != '0')) {
    fail("\$use_amm must be false when \$large_mem_pages is not 0\n")
    }

    #
    # The basic settings that should always be present. Can be overridden
    # via hiera().
    #

    # sem, default is '250 32000 100 128'
    sysctl::set{'kernel.sem':
    value => hiera('oracle_sysctl_sem', '250 32000 100 128')
    }

    # shmmni
    sysctl::set{'kernel.shmmni':
    value => hiera('oracle_sysctl_shmmni', '4096'),
    require => Sysctl::Set['kernel.sem'],
    }

    # file_max
    sysctl::set{'fs.file-max':
    value => hiera('oracle_sysctl_file_max', '6815744'),
    require => Sysctl::Set['kernel.shmmni'],
    }

    sysctl::set{'fs.aio-max-nr':
    value => hiera('oracle_sysclt_aio_max_nr', '1048576'),
    require => Sysctl::Set['fs.file-max'],
    }


    # ip local port range.
    sysctl::set{'net.ipv4.ip_local_port_range':
    value => hiera('oracle_sysctl_ip_local_port_range', '9000 65500'),
    require => Sysctl::Set['fs.aio-max-nr'],
    }

    # network buffer defaults
    sysctl::set{'net.core.rmem_default':
    value => hiera('oracle_sysctl_rmem_default', '262144'),
    require => Sysctl::Set['net.ipv4.ip_local_port_range'],
    }

    sysctl::set{'net.core.rmem_max':
    value => hiera('oracle_sysctl_rmem_max', '4194304'),
    require => Sysctl::Set['net.core.rmem_default'],
    }

    sysctl::set{'net.core.wmem_default':
    value => hiera('oracle_sysctl_wmem_default', '262144'),
    require => Sysctl::Set['net.core.rmem_max'],
    }

    sysctl::set{'net.core.wmem_max':
    value => hiera('oracle_sysctl_wmem_max', '1048576'),
    require => Sysctl::Set['net.core.wmem_default'],
    }

    sysctl::set{'vm.swappiness':
    value => hiera('oracle_sysctl_swappiness', '0'),
    require => Sysctl::Set['net.core.wmem_max'],
    }

    #
    # Only if AMM is false and $large_mem_pages > 0 do we set these
    #
    if (!$use_amm and ($large_mem_pages > 0)) {
    sysctl::set{'vm.nr_hugepages': value => $large_mem_pages }
    #1001 is the dba group which the oracle user belongs to
    sysctl::set{'vm.hugetlb_shm_group': value => $hugetlb_gid }
    }
    }


    We've talked about having the sysctl class also make certain that
    /dev/shm is mounted and of the appropriate size if $use_amm is true, but
    that hasn't been done yet.

    All of the other setup (limits.conf, paths, user, groups) happens in
    oracledb::serverbase, which doesn't use hiera and is more or less specific
    to our environment.

    Tim

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Fatmcgav at Oct 25, 2012 at 6:05 pm
    Tim

    Cool, Cheers for that.
    Some good food for thought there...

    Cheers again.
    Gav
    On Oct 25, 2012 6:20 PM, "Tim Mooney" wrote:

    In regard to: Re: [Puppet Users] Puppet & Oracle Database config...:

    Have you got any examples of the hiera config you're using?
    As I said, it's pretty rough.

    class oracledb::sysctl(
    $use_amm = false,
    $large_mem_pages = '0',
    $hugetlb_gid = '1001',
    ) {

    validate_bool($use_amm)
    validate_string($large_mem_**pages)
    validate_string($hugetlb_gid)

    if ( $use_amm and ($large_mem_pages != '0')) {
    fail("\$use_amm must be false when \$large_mem_pages is not 0\n")
    }

    #
    # The basic settings that should always be present. Can be overridden
    # via hiera().
    #

    # sem, default is '250 32000 100 128'
    sysctl::set{'kernel.sem':
    value => hiera('oracle_sysctl_sem', '250 32000 100 128')
    }

    # shmmni
    sysctl::set{'kernel.shmmni':
    value => hiera('oracle_sysctl_shmmni', '4096'),
    require => Sysctl::Set['kernel.sem'],
    }

    # file_max
    sysctl::set{'fs.file-max':
    value => hiera('oracle_sysctl_file_max'**, '6815744'),
    require => Sysctl::Set['kernel.shmmni'],
    }

    sysctl::set{'fs.aio-max-nr':
    value => hiera('oracle_sysclt_aio_max_**nr', '1048576'),
    require => Sysctl::Set['fs.file-max'],
    }


    # ip local port range.
    sysctl::set{'net.ipv4.ip_**local_port_range':
    value => hiera('oracle_sysctl_ip_local_**port_range', '9000 65500'),
    require => Sysctl::Set['fs.aio-max-nr'],
    }

    # network buffer defaults
    sysctl::set{'net.core.rmem_**default':
    value => hiera('oracle_sysctl_rmem_**default', '262144'),
    require => Sysctl::Set['net.ipv4.ip_**local_port_range'],
    }

    sysctl::set{'net.core.rmem_**max':
    value => hiera('oracle_sysctl_rmem_max'**, '4194304'),
    require => Sysctl::Set['net.core.rmem_**default'],
    }

    sysctl::set{'net.core.wmem_**default':
    value => hiera('oracle_sysctl_wmem_**default', '262144'),
    require => Sysctl::Set['net.core.rmem_**max'],
    }

    sysctl::set{'net.core.wmem_**max':
    value => hiera('oracle_sysctl_wmem_max'**, '1048576'),
    require => Sysctl::Set['net.core.wmem_**default'],
    }

    sysctl::set{'vm.swappiness':
    value => hiera('oracle_sysctl_**swappiness', '0'),
    require => Sysctl::Set['net.core.wmem_**max'],
    }

    #
    # Only if AMM is false and $large_mem_pages > 0 do we set these
    #
    if (!$use_amm and ($large_mem_pages > 0)) {
    sysctl::set{'vm.nr_hugepages': value => $large_mem_pages }
    #1001 is the dba group which the oracle user belongs to
    sysctl::set{'vm.hugetlb_shm_**group': value => $hugetlb_gid }
    }
    }


    We've talked about having the sysctl class also make certain that
    /dev/shm is mounted and of the appropriate size if $use_amm is true, but
    that hasn't been done yet.

    All of the other setup (limits.conf, paths, user, groups) happens in
    oracledb::serverbase, which doesn't use hiera and is more or less specific
    to our environment.

    Tim

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@**
    googlegroups.com <puppet-users%2Bunsubscribe@googlegroups.com>.
    For more options, visit this group at http://groups.google.com/**
    group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en>
    .
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Fatmcgav at Oct 25, 2012 at 6:18 pm
    Tim

    Cool, Cheers for that.
    Some good food for thought there...

    Cheers again.
    Gav
    On Oct 25, 2012 6:20 PM, "Tim Mooney" wrote:

    In regard to: Re: [Puppet Users] Puppet & Oracle Database config...:

    Have you got any examples of the hiera config you're using?
    As I said, it's pretty rough.

    class oracledb::sysctl(
    $use_amm = false,
    $large_mem_pages = '0',
    $hugetlb_gid = '1001',
    ) {

    validate_bool($use_amm)
    validate_string($large_mem_**pages)
    validate_string($hugetlb_gid)

    if ( $use_amm and ($large_mem_pages != '0')) {
    fail("\$use_amm must be false when \$large_mem_pages is not 0\n")
    }

    #
    # The basic settings that should always be present. Can be overridden
    # via hiera().
    #

    # sem, default is '250 32000 100 128'
    sysctl::set{'kernel.sem':
    value => hiera('oracle_sysctl_sem', '250 32000 100 128')
    }

    # shmmni
    sysctl::set{'kernel.shmmni':
    value => hiera('oracle_sysctl_shmmni', '4096'),
    require => Sysctl::Set['kernel.sem'],
    }

    # file_max
    sysctl::set{'fs.file-max':
    value => hiera('oracle_sysctl_file_max'**, '6815744'),
    require => Sysctl::Set['kernel.shmmni'],
    }

    sysctl::set{'fs.aio-max-nr':
    value => hiera('oracle_sysclt_aio_max_**nr', '1048576'),
    require => Sysctl::Set['fs.file-max'],
    }


    # ip local port range.
    sysctl::set{'net.ipv4.ip_**local_port_range':
    value => hiera('oracle_sysctl_ip_local_**port_range', '9000 65500'),
    require => Sysctl::Set['fs.aio-max-nr'],
    }

    # network buffer defaults
    sysctl::set{'net.core.rmem_**default':
    value => hiera('oracle_sysctl_rmem_**default', '262144'),
    require => Sysctl::Set['net.ipv4.ip_**local_port_range'],
    }

    sysctl::set{'net.core.rmem_**max':
    value => hiera('oracle_sysctl_rmem_max'**, '4194304'),
    require => Sysctl::Set['net.core.rmem_**default'],
    }

    sysctl::set{'net.core.wmem_**default':
    value => hiera('oracle_sysctl_wmem_**default', '262144'),
    require => Sysctl::Set['net.core.rmem_**max'],
    }

    sysctl::set{'net.core.wmem_**max':
    value => hiera('oracle_sysctl_wmem_max'**, '1048576'),
    require => Sysctl::Set['net.core.wmem_**default'],
    }

    sysctl::set{'vm.swappiness':
    value => hiera('oracle_sysctl_**swappiness', '0'),
    require => Sysctl::Set['net.core.wmem_**max'],
    }

    #
    # Only if AMM is false and $large_mem_pages > 0 do we set these
    #
    if (!$use_amm and ($large_mem_pages > 0)) {
    sysctl::set{'vm.nr_hugepages': value => $large_mem_pages }
    #1001 is the dba group which the oracle user belongs to
    sysctl::set{'vm.hugetlb_shm_**group': value => $hugetlb_gid }
    }
    }


    We've talked about having the sysctl class also make certain that
    /dev/shm is mounted and of the appropriate size if $use_amm is true, but
    that hasn't been done yet.

    All of the other setup (limits.conf, paths, user, groups) happens in
    oracledb::serverbase, which doesn't use hiera and is more or less specific
    to our environment.

    Tim

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@**
    googlegroups.com <puppet-users%2Bunsubscribe@googlegroups.com>.
    For more options, visit this group at http://groups.google.com/**
    group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en>
    .
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Stefan Schulte at Oct 24, 2012 at 5:46 pm

    On Wed, Oct 24, 2012 at 03:03:28PM +0100, fatmcgav wrote:
    Afternoon all.

    I've been reading around on Puppet and Oracle, and have come up with a few
    links that suggest how to get Oracle installed and base configured, which
    has got me started in the right direction on that.

    My next challenge is maintaining Oracle database specific configuration on
    the relevant hosts. This contains various elements, such as /etc/oratab,
    /etc/oranfstab (as we're using dNFS), various NFS mounts required for a
    given database, and a few other bits and pieces...
    Ideally, it would be a 1-to-1 relationship between a given host and a given
    DB. However that's unlikely in our env - We're more likely to have 1 or
    multiple databases on a given host, which all need to be maintained.

    My initial thoughts are to use something like hiera to maintain this
    configuration data.
    Is this my best approach? Any other suggestions? Anyone doing this for
    real?

    Basically, any info/pointers you give me is greatly appreciated.

    Regards
    Gavin

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
    A collegue of mine wrote an oracle::server class that makes sure
    directories, users, groups and NFS mounts are in place. The class will
    also install oracle itself with an exec resource (silent install). The
    exec resource will not run the installer directly but will launch a
    wrapperscript. It basically looks like

    exec { 'Install_Oracle':
    command => "/path/to/nas/share/install_oracle${version}.sh",
    creates => "/u01/some/path/log/install_oracle${version}.done.log",
    }

    The wrapper script will launch a slient install and will create the
    .done.log file afterwards. This was in our opinion the best way to keep
    puppet from installing the software in each puppet run. The
    oracle::server class does nothing that is related to a specific
    instance.

    We then have an oracle::instance define that installs instance related
    files. The define has a similar exec resource that can install a single
    instance (I guess the command is dbca or similar).

    To manage oratab entries we use a custom type I've written:
    https://github.com/stschulte/puppet-oracle

    We do not use hiera to store instance related data (instance name,
    charset, homedirectory) we use parameterized classes (oracle::server) and
    defines (oracle::instance) with parameters at node level in site.pp

    -Stefan

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Gavin Williams at Oct 25, 2012 at 11:25 am
    Stefan

    Thanks again for some really good info.

    Are your oracle::* classes something that you could share?
    And cheers for linking the oratab type, that looks really useful, and looks
    like it could easily be extended to cover oranfstab aswell... May well fork
    that and tweak it as appropriate :)

    Cheers again
    Gavin
    On Wednesday, 24 October 2012 18:46:22 UTC+1, Stefan Schulte wrote:
    On Wed, Oct 24, 2012 at 03:03:28PM +0100, fatmcgav wrote:
    Afternoon all.

    I've been reading around on Puppet and Oracle, and have come up with a few
    links that suggest how to get Oracle installed and base configured, which
    has got me started in the right direction on that.

    My next challenge is maintaining Oracle database specific configuration on
    the relevant hosts. This contains various elements, such as /etc/oratab,
    /etc/oranfstab (as we're using dNFS), various NFS mounts required for a
    given database, and a few other bits and pieces...
    Ideally, it would be a 1-to-1 relationship between a given host and a given
    DB. However that's unlikely in our env - We're more likely to have 1 or
    multiple databases on a given host, which all need to be maintained.

    My initial thoughts are to use something like hiera to maintain this
    configuration data.
    Is this my best approach? Any other suggestions? Anyone doing this for
    real?

    Basically, any info/pointers you give me is greatly appreciated.

    Regards
    Gavin

    --
    You received this message because you are subscribed to the Google
    Groups "Puppet Users" group.
    To post to this group, send email to puppet...@googlegroups.com<javascript:>.
    To unsubscribe from this group, send email to
    puppet-users...@googlegroups.com <javascript:>.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.
    A collegue of mine wrote an oracle::server class that makes sure
    directories, users, groups and NFS mounts are in place. The class will
    also install oracle itself with an exec resource (silent install). The
    exec resource will not run the installer directly but will launch a
    wrapperscript. It basically looks like

    exec { 'Install_Oracle':
    command => "/path/to/nas/share/install_oracle${version}.sh",
    creates => "/u01/some/path/log/install_oracle${version}.done.log",
    }

    The wrapper script will launch a slient install and will create the
    .done.log file afterwards. This was in our opinion the best way to keep
    puppet from installing the software in each puppet run. The
    oracle::server class does nothing that is related to a specific
    instance.

    We then have an oracle::instance define that installs instance related
    files. The define has a similar exec resource that can install a single
    instance (I guess the command is dbca or similar).

    To manage oratab entries we use a custom type I've written:
    https://github.com/stschulte/puppet-oracle

    We do not use hiera to store instance related data (instance name,
    charset, homedirectory) we use parameterized classes (oracle::server) and
    defines (oracle::instance) with parameters at node level in site.pp

    -Stefan
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/jYddiBfR6mwJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Gavin Williams at Nov 2, 2012 at 2:23 pm
    Afternoon all...

    I've started looking at coding this into our framework now, and have hit a
    possible stumbling block...

    Currently, I've got a fact that reads out the configured Oracle SIDs in
    /etc/oratab and sticks that into an 'oracle_sids' fact.
    I've also got a Property (oracle_required_sids) against the host in Foreman
    which contains a comma separated lists of SIDs that *should* be configured
    on the host.

    What I want to do is compare those 2 lists, and action any changes... So if
    there's a SID in the oracle_required_sids var that isn't in oracle_sids,
    then it should be created. If there's a SID in the oracle_sids var that
    isnt in oracle_required_sids, then it should be removed...
    I've established that Looping isn't something that Puppet currently
    handles, so I'm looking for an alternative method...

    Any ideas???

    Cheers
    Gavin
    On Wednesday, 24 October 2012 15:03:45 UTC+1, Gavin Williams wrote:

    Afternoon all.

    I've been reading around on Puppet and Oracle, and have come up with a few
    links that suggest how to get Oracle installed and base configured, which
    has got me started in the right direction on that.

    My next challenge is maintaining Oracle database specific configuration on
    the relevant hosts. This contains various elements, such as /etc/oratab,
    /etc/oranfstab (as we're using dNFS), various NFS mounts required for a
    given database, and a few other bits and pieces...
    Ideally, it would be a 1-to-1 relationship between a given host and a
    given DB. However that's unlikely in our env - We're more likely to have 1
    or multiple databases on a given host, which all need to be maintained.

    My initial thoughts are to use something like hiera to maintain this
    configuration data.
    Is this my best approach? Any other suggestions? Anyone doing this for
    real?

    Basically, any info/pointers you give me is greatly appreciated.

    Regards
    Gavin
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/vVqh2Lk0dYYJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Stefan Schulte at Nov 2, 2012 at 6:41 pm

    On Fri, Nov 02, 2012 at 07:23:54AM -0700, Gavin Williams wrote:
    Afternoon all...

    I've started looking at coding this into our framework now, and have hit a
    possible stumbling block...

    Currently, I've got a fact that reads out the configured Oracle SIDs in
    /etc/oratab and sticks that into an 'oracle_sids' fact.
    I've also got a Property (oracle_required_sids) against the host in Foreman
    which contains a comma separated lists of SIDs that *should* be configured
    on the host.

    What I want to do is compare those 2 lists, and action any changes... So if
    there's a SID in the oracle_required_sids var that isn't in oracle_sids,
    then it should be created. If there's a SID in the oracle_sids var that
    isnt in oracle_required_sids, then it should be removed...
    I've established that Looping isn't something that Puppet currently
    handles, so I'm looking for an alternative method...

    Any ideas???

    Cheers
    Gavin
    You can use the oratab type from https://github.com/stschulte/puppet-oracle
    to describe the entries you do want (this assumes every instance has the same
    ORACLE_HOME):

    $instances = split($oracle_required_sids, ',')
    oratab { $instances:
    ensure => present,
    home => '/u01/app/oracle/product/10.1.0/db_1',
    atboot => yes,
    }

    This will make sure the instances are present in the oratab file. This
    will not remove unmanaged entries. But you can use the resources type do
    that:

    resources { 'oratab':
    purge => true
    }

    You don't even need your oracle_sids fact that way.

    -Stefan

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Gavin Williams at Nov 4, 2012 at 9:18 pm
    Ok, that would work...

    One further question though... How could I use that to trigger a further process when creates a new oratab entry?
    As there's various other things that are needed for the db such as a folder structure, 5 nfs mounts, and oranfstab changes... Guess I could wrap all of that up into a single define.. Would just need some way of triggering it...

    Gav

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/J3BYMRCexjYJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Gavin Williams at Nov 22, 2012 at 12:18 pm
    Ok, I've come back to this functionality, and need to move it along...

    My challenge now is how I can use the oratab resource to trigger other
    actions...

    So if oratab creates a new entry in /etc/oratab, then I want to ideally
    call a define which will go away and create the require directory
    structure, mount NFS volumes and add details to fstab...

    Any ideas???

    Cheers
    Gavin
    On Sunday, 4 November 2012 21:18:13 UTC, Gavin Williams wrote:

    Ok, that would work...

    One further question though... How could I use that to trigger a further
    process when creates a new oratab entry?
    As there's various other things that are needed for the db such as a
    folder structure, 5 nfs mounts, and oranfstab changes... Guess I could wrap
    all of that up into a single define.. Would just need some way of
    triggering it...

    Gav
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Y9KKvZSoRN8J.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Gavin Williams at Nov 22, 2012 at 2:33 pm
    Search and ye shall find...

    Some more searching and came back with:
    http://serverfault.com/questions/418758/how-to-set-up-a-handler-for-a-notification-or-subscription-in-a-defined-type

    Tweaked the config and it worked as expected... Although it's possibly
    highlighted an issue whereby the notify is getting triggered on every
    run... Not only when a new entry is created...
    Probably me misunderstanding the Notify functionality...

    If that is the case, is there another way I could achieve it?

    Cheers
    Gav
    On Thursday, 22 November 2012 12:18:02 UTC, Gavin Williams wrote:

    Ok, I've come back to this functionality, and need to move it along...

    My challenge now is how I can use the oratab resource to trigger other
    actions...

    So if oratab creates a new entry in /etc/oratab, then I want to ideally
    call a define which will go away and create the require directory
    structure, mount NFS volumes and add details to fstab...

    Any ideas???

    Cheers
    Gavin
    On Sunday, 4 November 2012 21:18:13 UTC, Gavin Williams wrote:

    Ok, that would work...

    One further question though... How could I use that to trigger a further
    process when creates a new oratab entry?
    As there's various other things that are needed for the db such as a
    folder structure, 5 nfs mounts, and oranfstab changes... Guess I could wrap
    all of that up into a single define.. Would just need some way of
    triggering it...

    Gav
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/V_ORr6UZEzYJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Stefan Schulte at Nov 23, 2012 at 8:24 pm

    On Thu, Nov 22, 2012 at 04:18:02AM -0800, Gavin Williams wrote:
    Ok, I've come back to this functionality, and need to move it along...

    My challenge now is how I can use the oratab resource to trigger other
    actions...

    So if oratab creates a new entry in /etc/oratab, then I want to ideally
    call a define which will go away and create the require directory
    structure, mount NFS volumes and add details to fstab...

    Any ideas???

    Cheers
    Gavin
    Why do you need the resource to "trigger" anything? I guess you are
    already using puppet to define your instances so you can do something
    like

    define oracle::instance($home, ...) {

    # some instance specific subdirectory
    file { "/u01/app/oracle/admin/${name}":
    ensure => directory}
    }

    # some instance specific mount
    mount { ...${name}:
    ensure => mounted,
    }

    file { "responsefile_for_${name}":
    ensure => file,
    content => template("responsefile.cfg.erb",
    }

    exec { "install_db_${name}"
    command => 'some_wrapperscript_around_dbca_to_install_instance_with_responsefile',
    creates => 'some_flagfile_the_wrapperscript_creates_on_success',
    require => File["responsefile_for_${name}"],
    }

    oratab { $name:
    ensure => present,
    home => $home,
    atboot => yes,
    }
    }

    -Stefan

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedOct 24, '12 at 2:03p
activeNov 23, '12 at 8:24p
posts14
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase