FAQ
Dears all,

I was testing my localusers facter by puppetmaster fileserver but i'd
got in error

Could not retrieve localusers: No such file or directory - /etc/
puppet/whitelist

I was pretending the file was served by fileserver of puppetmaster
doing in init.pp :

file { "/etc/puppet/whitelist":
ensure => present,

Just before to call a facter.


I don't pretty sure but seems to me a issue about workflow

Client pluginsync -> Client discover system Facts -> Master
compilation -> Client apply catalog -> Client report.


Is there any way to get a file from puppetmaster to be read it by a
facter ?.

If it's not, I appreciate any suggestion about it.

Thanks in advanced,
eduardo.

--
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

  • Eduardo at Jul 4, 2012 at 7:37 pm
    To be more clear about my first intend. it had init.pp like :

    file { "/etc/puppet/whitelist":
    ensure => present,
    source => 'puppet:///files/whitelist',
    }

    $users_local = split($localusers, '[,]')



    ----- facter
    require 'etc'

    Facter.add("localusers") do
    setcode do

    # Whitelist users to exclude for checking valid ssh users

    whitelist = Array.new

    File.readlines("/etc/puppet/whitelist").each { |line|

    whitelist << line.chomp
    }
    -----


    On 4 jul, 15:07, eduardo wrote:
    Dears all,

    I was testing my localusers facter by puppetmaster fileserver but i'd
    got in error

    Could not retrieve localusers: No such file or directory - /etc/
    puppet/whitelist

    I was pretending the file was served by fileserver of puppetmaster
    doing in init.pp :

    file { "/etc/puppet/whitelist":
    ensure => present,

    Just before to call a facter.

    I don't pretty sure but seems to me a issue about workflow

    Client pluginsync -> Client discover system Facts -> Master
    compilation -> Client apply catalog -> Client report.

    Is there any way to get a file from puppetmaster to be read it by a
    facter ?.

    If it's not, I appreciate any suggestion about it.

    Thanks in advanced,
    eduardo.
    --
    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.
  • Jcbollinger at Jul 5, 2012 at 3:43 pm

    On Wednesday, July 4, 2012 2:37:06 PM UTC-5, eduardo wrote:
    To be more clear about my first intend. it had init.pp like :

    file { "/etc/puppet/whitelist":
    ensure => present,
    source => 'puppet:///files/whitelist',
    }

    $users_local = split($localusers, '[,]')



    ----- facter
    require 'etc'

    Facter.add("localusers") do
    setcode do

    # Whitelist users to exclude for checking valid ssh users

    whitelist = Array.new

    File.readlines("/etc/puppet/whitelist").each { |line|

    whitelist << line.chomp
    }
    -----


    On 4 jul, 15:07, eduardo wrote:
    Dears all,

    I was testing my localusers facter by puppetmaster fileserver but i'd
    got in error

    Could not retrieve localusers: No such file or directory - /etc/
    puppet/whitelist

    I was pretending the file was served by fileserver of puppetmaster
    doing in init.pp :

    file { "/etc/puppet/whitelist":
    ensure => present,

    Just before to call a facter.

    I don't pretty sure but seems to me a issue about workflow

    Client pluginsync -> Client discover system Facts -> Master
    compilation -> Client apply catalog -> Client report.

    Is there any way to get a file from puppetmaster to be read it by a
    facter ?.

    If it's not, I appreciate any suggestion about it.

    Facter runs after pluginsync (if enabled) and before any resources (such as
    your whitelist file) are synchronized. It must be so because the master
    needs the node facts to compile a catalog, and the agent uses the catalog
    to synchronize resources.

    What you are attempting to do sounds dubious, however. If the master knows
    what users are supposed to be whitelisted (in order to provide the needed
    file) then it shouldn't need facter to tell it.


    John

    --
    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/-/1DOQXx9ya-IJ.
    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.
  • Eduardo at Jul 5, 2012 at 3:58 pm
    Thanks you john for your answer. I comment you something that work
    well for me.

    I think get a solution while reading puppet cookbook. It's based on
    run stages.

    I have site.pp :

    import 'sync_files.pp'

    Then, sync_files.pp is :

    class sync_files {
    notify { "sync whitelist file": }
    file { "/etc/puppet/whitelist":
    ensure => present,
    owner => root,
    group => root,
    mode => 644,
    source => 'puppet:///files/whitelist',
    }
    }

    And finally insert the following two sentences into class updssh

    stage { "first": before => Stage["main"] }

    class { "sync_files": stage => "first" }

    That's all. Testing results are good enough.

    Regards,
    eduardo.



    On 5 jul, 11:43, jcbollinger wrote:
    On Wednesday, July 4, 2012 2:37:06 PM UTC-5, eduardo wrote:

    To be more clear about my first intend. it had init.pp  like :
    file { "/etc/puppet/whitelist":
    ensure => present,
    source => 'puppet:///files/whitelist',
    }
    $users_local =  split($localusers, '[,]')
    ----- facter
    require 'etc'
    Facter.add("localusers") do
    setcode do
    # Whitelist users to exclude for checking valid ssh users
    whitelist = Array.new
    File.readlines("/etc/puppet/whitelist").each { |line|
    whitelist << line.chomp
    }
    -----
    On 4 jul, 15:07, eduardo wrote:
    Dears all,
    I was testing my localusers facter by puppetmaster fileserver but i'd
    got in error
    Could not retrieve localusers: No such file or directory - /etc/
    puppet/whitelist
    I was pretending the file was served by fileserver of puppetmaster
    doing in init.pp :
    file { "/etc/puppet/whitelist":
    ensure => present,
    Just before to call a facter.
    I don't pretty sure but seems to me a issue about workflow
    Client pluginsync -> Client discover system Facts -> Master
    compilation -> Client apply catalog -> Client report.
    Is there any way to get a file from puppetmaster to be read it by a
    facter ?.
    If it's not, I appreciate any suggestion about it.
    Facter runs after pluginsync (if enabled) and before any resources (such as
    your whitelist file) are synchronized.  It must be so because the master
    needs the node facts to compile a catalog, and the agent uses the catalog
    to synchronize resources.

    What you are attempting to do sounds dubious, however.  If the master knows
    what users are supposed to be whitelisted (in order to provide the needed
    file) then it shouldn't need facter to tell it.

    John
    --
    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.
  • Eduardo at Jul 5, 2012 at 4:16 pm
    John the whitelist is a dynamic file create/update by administrators,
    so puppetmaster don't know about whilelist's content.
    I pretending to get advantage of fileserver funcionality (instead of
    any other remote copy tool like rsync) in order to get centralized
    copy of the file whitelist to all nodes.

    Regards,
    eduardo.
    On 5 jul, 11:58, eduardo wrote:
    Thanks you john for your answer. I comment you something that work
    well for me.

    I think get a solution while reading puppet cookbook. It's based on
    run stages.

    I have site.pp :

    import 'sync_files.pp'

    Then, sync_files.pp is :

    class sync_files {
    notify { "sync whitelist file": }
    file { "/etc/puppet/whitelist":
    ensure => present,
    owner => root,
    group => root,
    mode => 644,
    source => 'puppet:///files/whitelist',
    }

    }

    And finally insert the following two sentences into class updssh

    stage { "first": before => Stage["main"] }

    class { "sync_files": stage => "first" }

    That's all. Testing results are good enough.

    Regards,
    eduardo.

    On 5 jul, 11:43, jcbollinger wrote:






    On Wednesday, July 4, 2012 2:37:06 PM UTC-5, eduardo wrote:

    To be more clear about my first intend. it had init.pp  like :
    file { "/etc/puppet/whitelist":
    ensure => present,
    source => 'puppet:///files/whitelist',
    }
    $users_local =  split($localusers, '[,]')
    ----- facter
    require 'etc'
    Facter.add("localusers") do
    setcode do
    # Whitelist users to exclude for checking valid ssh users
    whitelist = Array.new
    File.readlines("/etc/puppet/whitelist").each { |line|
    whitelist << line.chomp
    }
    -----
    On 4 jul, 15:07, eduardo wrote:
    Dears all,
    I was testing my localusers facter by puppetmaster fileserver but i'd
    got in error
    Could not retrieve localusers: No such file or directory - /etc/
    puppet/whitelist
    I was pretending the file was served by fileserver of puppetmaster
    doing in init.pp :
    file { "/etc/puppet/whitelist":
    ensure => present,
    Just before to call a facter.
    I don't pretty sure but seems to me a issue about workflow
    Client pluginsync -> Client discover system Facts -> Master
    compilation -> Client apply catalog -> Client report.
    Is there any way to get a file from puppetmaster to be read it by a
    facter ?.
    If it's not, I appreciate any suggestion about it.
    Facter runs after pluginsync (if enabled) and before any resources (such as
    your whitelist file) are synchronized.  It must be so because the master
    needs the node facts to compile a catalog, and the agent uses the catalog
    to synchronize resources.
    What you are attempting to do sounds dubious, however.  If the master knows
    what users are supposed to be whitelisted (in order to provide the needed
    file) then it shouldn't need facter to tell it.
    John
    --
    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.
  • Eduardo at Jul 5, 2012 at 4:33 pm
    I need a facter because each node have different users. The facter
    return a list of local users that not are into whitelist (unique).

    ----------------------------

    whitelist = Array.new
    File.readlines("/etc/puppet/whitelist").each { |line|
    whitelist << line.chomp
    }

    locals = Array.new

    Etc.passwd {|u|
    locals << u.name unless u.dir[0,5] != "/
    home"
    }

    ret = locals - whitelist
    ret.join(',')

    ----------------------------
    On 5 jul, 12:16, eduardo wrote:
    John the whitelist is a dynamic file create/update by administrators,
    so puppetmaster don't know about whilelist's content.
    I pretending to get advantage of fileserver funcionality (instead of
    any other remote copy tool like rsync) in order to get centralized
    copy of the file whitelist to all nodes.

    Regards,
    eduardo.

    On 5 jul, 11:58, eduardo wrote:






    Thanks you john for your answer. I comment you something that work
    well for me.
    I think get a solution while reading puppet cookbook. It's based on
    run stages.
    I have site.pp :
    import 'sync_files.pp'
    Then, sync_files.pp is :
    class sync_files {
    notify { "sync whitelist file": }
    file { "/etc/puppet/whitelist":
    ensure => present,
    owner => root,
    group => root,
    mode => 644,
    source => 'puppet:///files/whitelist',
    }
    }
    And finally insert the following two sentences into class updssh
    stage { "first": before => Stage["main"] }
    class { "sync_files": stage => "first" }
    That's all. Testing results are good enough.
    Regards,
    eduardo.
    On 5 jul, 11:43, jcbollinger wrote:
    On Wednesday, July 4, 2012 2:37:06 PM UTC-5, eduardo wrote:

    To be more clear about my first intend. it had init.pp  like :
    file { "/etc/puppet/whitelist":
    ensure => present,
    source => 'puppet:///files/whitelist',
    }
    $users_local =  split($localusers, '[,]')
    ----- facter
    require 'etc'
    Facter.add("localusers") do
    setcode do
    # Whitelist users to exclude for checking valid ssh users
    whitelist = Array.new
    File.readlines("/etc/puppet/whitelist").each { |line|
    whitelist << line.chomp
    }
    -----
    On 4 jul, 15:07, eduardo wrote:
    Dears all,
    I was testing my localusers facter by puppetmaster fileserver but i'd
    got in error
    Could not retrieve localusers: No such file or directory - /etc/
    puppet/whitelist
    I was pretending the file was served by fileserver of puppetmaster
    doing in init.pp :
    file { "/etc/puppet/whitelist":
    ensure => present,
    Just before to call a facter.
    I don't pretty sure but seems to me a issue about workflow
    Client pluginsync -> Client discover system Facts -> Master
    compilation -> Client apply catalog -> Client report.
    Is there any way to get a file from puppetmaster to be read it by a
    facter ?.
    If it's not, I appreciate any suggestion about it.
    Facter runs after pluginsync (if enabled) and before any resources (such as
    your whitelist file) are synchronized.  It must be so because the master
    needs the node facts to compile a catalog, and the agent uses the catalog
    to synchronize resources.
    What you are attempting to do sounds dubious, however.  If the master knows
    what users are supposed to be whitelisted (in order to provide the needed
    file) then it shouldn't need facter to tell it.
    John
    --
    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.
  • Jcbollinger at Jul 5, 2012 at 9:26 pm

    On Thursday, July 5, 2012 11:33:03 AM UTC-5, eduardo wrote:
    I need a facter because each node have different users. The facter
    return a list of local users that not are into whitelist (unique).
    Maybe it would be fruitful to come at this from a different direction. For
    what purpose do you want this data? There may be a better way to achieve
    your objective.


    John

    --
    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/-/pdZuwQWFJbIJ.
    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.
  • Eduardo at Jul 6, 2012 at 6:05 pm
    Hi john, This data are need for check a valid users on nodes. We are
    pretending massive load accounts by ENC. The batch (json) is prepare
    by external program which, in our scenario is a normal way to create
    accounts. But users can create new accounts by 'hand' when they log in
    because they have sudo, for those new ones we want to set disable
    (nologin). Meanwhile there are a set of user admins (we are) which
    should be not disable even when they are not into batch json.
    They are into whitelist (admin,deploy,etc,etc) , so they should be
    exclude at checkout for disable accounts. That is done by the facter.

    As you can see it's non-normal scenario.

    Do you see any problem about solution based on run stages ?.

    Thanks you,
    eduardo.
    On 5 jul, 17:26, jcbollinger wrote:
    On Thursday, July 5, 2012 11:33:03 AM UTC-5, eduardo wrote:

    I need a facter because each node have different users. The facter
    return a list of local users that not are into whitelist (unique).
    Maybe it would be fruitful to come at this from a different direction.  For
    what purpose do you want this data?  There may be a better way to achieve
    your objective.

    John
    --
    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.
  • Jcbollinger at Jul 6, 2012 at 7:26 pm

    On Friday, July 6, 2012 1:05:47 PM UTC-5, eduardo wrote:
    Hi john, This data are need for check a valid users on nodes. We are
    pretending massive load accounts by ENC. The batch (json) is prepare
    by external program which, in our scenario is a normal way to create
    accounts. But users can create new accounts by 'hand' when they log in
    because they have sudo, for those new ones we want to set disable
    (nologin). Meanwhile there are a set of user admins (we are) which
    should be not disable even when they are not into batch json.
    They are into whitelist (admin,deploy,etc,etc) , so they should be
    exclude at checkout for disable accounts. That is done by the facter.

    As you can see it's non-normal scenario.
    Yes. Here's what I think you're saying:

    1) Your ENC is going to feed data for a large number of users to the
    puppetmaster, either via a class parameter or via a global variable.

    2) Your custom fact is going to report to the puppemaster some or all of
    the known system users, excluding all users on the whitelist

    3) Some class is going to combine the data from these sources to generate
    User resources that manage the ENC-specified and discovered users to, among
    other things, disable login for the users that do not appear in the first
    source.

    I still don't see the point of relying on a client-side whitelist, though.
    Why do you need to filter whitelisted users from the fact value on the
    client side? Why can't you do it on the master instead?

    Do you see any problem about solution based on run stages ?.
    >

    As I said before, run stages cannot overcome the problem of ensuring the
    whitelist is up to date on the client when facter runs. Unless you can
    tolerate use of an outdated file, an external client-side whitelist simply
    will not work.

    If you are using pluginsync (recommended) then possibly you could cook the
    whitelist entries directly into the custom fact code. That's ugly, but
    it's your best bet for ensuring that the custom fact uses an up-to-date
    whitelist.

    Overall, though, I think your plan runs very much against the Puppet
    grain. I have been known sometimes to admonish folks that "Puppet is not a
    script engine," but never before have I heard a deployment plan that tried
    so hard to use it as one. If you continue this way then I don't think
    you'll be satisfied with the result. It may be worthwhile to consider
    other configuration management systems.

    From a higher perspective, if you're fighting node admins who have
    sufficient privilege to manage users then you have chosen a losing game.
    If you give *me* that much access to a box then it's mine. Do not give
    administrative privileges to people you do not trust.


    John

    --
    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/-/b8_-nyExAwoJ.
    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.
  • Eduardo at Jul 6, 2012 at 8:34 pm
    John I really appreciate all your effort to help me.
    You are very close to my scenario (points 1 , 2 , 3)
    I still don't see the point of relying on a client-side whitelist, though.
    Why do you need to filter whitelisted users from the fact value on the
    client side? Why can't you do it on the master instead?
    Ok, i'm going to re-check it.
    If you are using pluginsync (recommended) then possibly you could cook the
    whitelist entries directly into the custom fact code. That's ugly, but
    it's your best bet for ensuring that the custom fact uses an up-to-date
    whitelist.
    Well this way i'll have to change a facter whenever whitelist change.
    The up-to-date is not critical between cycle agent (30 min) in this
    case.
    Overall, though, I think your plan runs very much against the Puppet
    grain. I have been known sometimes to admonish folks that "Puppet is not a
    script engine," but never before have I heard a deployment plan that tried
    so hard to use it as one. If you continue this way then I don't think
    you'll be satisfied with the result. It may be worthwhile to consider
    other configuration management systems.
    Agree, i'm taking note from you and from book 'Pulling Strings with
    Puppet' when say :

    Caution ➡ Puppet is probably not ideal to populate large numbers of
    users and groups to provide user access for nodes and applications.
    Puppet is best used to populate nodes with users for running
    applications and services, systems administration, and management.
    From a higher perspective, if you're fighting node admins who have
    sufficient privilege to manage users then you have chosen a losing game.
    If you give *me* that much access to a box then it's mine. Do not give
    administrative privileges to people you do not trust.
    Agree too John , but i have not choice , it's an scenario created by
    my employers.

    Thanks you. I'm going to recheck filter whitelisted.

    Best Regards,
    eduardo.
    On 6 jul, 15:26, jcbollinger wrote:
    On Friday, July 6, 2012 1:05:47 PM UTC-5, eduardo wrote:

    Hi john, This data are need for check a valid users on nodes. We are
    pretending massive load  accounts by ENC. The batch (json) is prepare
    by external program which, in our scenario is a normal way to create
    accounts. But users can create new accounts by 'hand' when they log in
    because they have sudo, for those new ones we want to set disable
    (nologin). Meanwhile there are a set of user admins (we are) which
    should be not disable even when they are not into batch json.
    They are into whitelist (admin,deploy,etc,etc) , so they should be
    exclude at checkout for disable accounts. That is done by the facter.
    As you can see it's non-normal scenario.
    Yes.  Here's what I think you're saying:

    1) Your ENC is going to feed data for a large number of users to the
    puppetmaster, either via a class parameter or via a global variable.

    2) Your custom fact is going to report to the puppemaster some or all of
    the known system users, excluding all users on the whitelist

    3) Some class is going to combine the data from these sources to generate
    User resources that manage the ENC-specified and discovered users to, among
    other things, disable login for the users that do not appear in the first
    source.

    I still don't see the point of relying on a client-side whitelist, though.
    Why do you need to filter whitelisted users from the fact value on the
    client side?  Why can't you do it on the master instead?

    Do you see any problem about solution based on run stages ?.



    As I said before, run stages cannot overcome the problem of ensuring the
    whitelist is up to date on the client when facter runs.  Unless you can
    tolerate use of an outdated file, an external client-side whitelist simply
    will not work.

    If you are using pluginsync (recommended) then possibly you could cook the
    whitelist entries directly into the custom fact code.  That's ugly, but
    it's your best bet for ensuring that the custom fact uses an up-to-date
    whitelist.

    Overall, though, I think your plan runs very much against the Puppet
    grain.  I have been known sometimes to admonish folks that "Puppet is not a
    script engine," but never before have I heard a deployment plan that tried
    so hard to use it as one.  If you continue this way then I don't think
    you'll be satisfied with the result.  It may be worthwhile to consider
    other configuration management systems.

    From a higher perspective, if you're fighting node admins who have
    sufficient privilege to manage users then you have chosen a losing game.
    If you give *me* that much access to a box then it's mine.  Do not give
    administrative privileges to people you do not trust.

    John
    --
    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.
  • Eduardo at Jul 7, 2012 at 4:07 am
    Hi John, I build a custom function to filter whitelisted.
    I didn't realized that custom functions can call facter by lookupvar.

    Thanks you for your suggestions.

    Best Regards,
    eduardo.

    On 6 jul, 16:34, eduardo wrote:
    John I really appreciate all your effort to help me.
    You are very close to my scenario (points 1 , 2 , 3)
    I still don't see the point of relying on a client-side whitelist, though.
    Why do you need to filter whitelisted users from the fact value on the
    client side?  Why can't you do it on the master instead?
    Ok, i'm going to re-check it.
    If you are using pluginsync (recommended) then possibly you could cook the
    whitelist entries directly into the custom fact code.  That's ugly, but
    it's your best bet for ensuring that the custom fact uses an up-to-date
    whitelist.
    Well this way i'll have to change a facter whenever whitelist change.
    The up-to-date is not critical between cycle agent (30 min) in this
    case.
    Overall, though, I think your plan runs very much against the Puppet
    grain.  I have been known sometimes to admonish folks that "Puppet is not a
    script engine," but never before have I heard a deployment plan that tried
    so hard to use it as one.  If you continue this way then I don't think
    you'll be satisfied with the result.  It may be worthwhile to consider
    other configuration management systems.
    Agree, i'm taking note from you and from book 'Pulling Strings with
    Puppet' when say :

    Caution ➡ Puppet is probably not ideal to populate large numbers of
    users and groups to provide user access for nodes and applications.
    Puppet is best used to populate nodes with users for running
    applications and services, systems administration, and management.
    From a higher perspective, if you're fighting node admins who have
    sufficient privilege to manage users then you have chosen a losing game.
    If you give *me* that much access to a box then it's mine.  Do not give
    administrative privileges to people you do not trust.
    Agree too John , but i have not choice , it's an scenario created by
    my employers.

    Thanks you. I'm going to recheck filter whitelisted.

    Best Regards,
    eduardo.

    On 6 jul, 15:26, jcbollinger wrote:






    On Friday, July 6, 2012 1:05:47 PM UTC-5, eduardo wrote:

    Hi john, This data are need for check a valid users on nodes. We are
    pretending massive load  accounts by ENC. The batch (json) is prepare
    by external program which, in our scenario is a normal way to create
    accounts. But users can create new accounts by 'hand' when they log in
    because they have sudo, for those new ones we want to set disable
    (nologin). Meanwhile there are a set of user admins (we are) which
    should be not disable even when they are not into batch json.
    They are into whitelist (admin,deploy,etc,etc) , so they should be
    exclude at checkout for disable accounts. That is done by the facter.
    As you can see it's non-normal scenario.
    Yes.  Here's what I think you're saying:
    1) Your ENC is going to feed data for a large number of users to the
    puppetmaster, either via a class parameter or via a global variable.
    2) Your custom fact is going to report to the puppemaster some or all of
    the known system users, excluding all users on the whitelist
    3) Some class is going to combine the data from these sources to generate
    User resources that manage the ENC-specified and discovered users to, among
    other things, disable login for the users that do not appear in the first
    source.
    I still don't see the point of relying on a client-side whitelist, though.
    Why do you need to filter whitelisted users from the fact value on the
    client side?  Why can't you do it on the master instead?
    Do you see any problem about solution based on run stages ?.
    As I said before, run stages cannot overcome the problem of ensuring the
    whitelist is up to date on the client when facter runs.  Unless you can
    tolerate use of an outdated file, an external client-side whitelist simply
    will not work.
    If you are using pluginsync (recommended) then possibly you could cook the
    whitelist entries directly into the custom fact code.  That's ugly, but
    it's your best bet for ensuring that the custom fact uses an up-to-date
    whitelist.
    Overall, though, I think your plan runs very much against the Puppet
    grain.  I have been known sometimes to admonish folks that "Puppet is not a
    script engine," but never before have I heard a deployment plan that tried
    so hard to use it as one.  If you continue this way then I don't think
    you'll be satisfied with the result.  It may be worthwhile to consider
    other configuration management systems.
    From a higher perspective, if you're fighting node admins who have
    sufficient privilege to manage users then you have chosen a losing game.
    If you give *me* that much access to a box then it's mine.  Do not give
    administrative privileges to people you do not trust.
    John
    --
    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.
  • Jcbollinger at Jul 5, 2012 at 9:09 pm

    On Thursday, July 5, 2012 11:16:56 AM UTC-5, eduardo wrote:
    John the whitelist is a dynamic file create/update by administrators,
    so puppetmaster don't know about whilelist's content.
    If the file is served by the master, then the master can know whatever it
    needs to know about its content. Ideally, Puppet would have the data in
    raw form, so as to generate the file for nodes, but it can also be made to
    parse the file it's about to serve by any one of several means. For
    example, you can call a parsing script (or maybe just 'cat') via the
    generate() function. Or if the file is generated via a template then you
    can store the generated content in a class variable, or else just process
    the template again. Or you can write a class in Ruby DSL that does pretty
    much anything you want.

    I pretending to get advantage of fileserver funcionality (instead of
    any other remote copy tool like rsync) in order to get centralized
    copy of the file whitelist to all nodes.
    Serving the file via Puppet is a perfectly fine and appropriate thing to
    do. The point, however, is that the file doesn't need to have already been
    served for the master (who is serving it) to know what's in it. Facter is
    the wrong way to get at the data in that case.


    John

    --
    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/-/FxJo4gyWB50J.
    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.
  • Jcbollinger at Jul 5, 2012 at 9:23 pm

    On Thursday, July 5, 2012 10:58:54 AM UTC-5, eduardo wrote:
    Thanks you john for your answer. I comment you something that work
    well for me.

    I think get a solution while reading puppet cookbook. It's based on
    run stages.

    I have site.pp :

    import 'sync_files.pp'

    Then, sync_files.pp is :

    class sync_files {
    notify { "sync whitelist file": }
    file { "/etc/puppet/whitelist":
    ensure => present,
    owner => root,
    group => root,
    mode => 644,
    source => 'puppet:///files/whitelist',
    }
    }

    And finally insert the following two sentences into class updssh

    stage { "first": before => Stage["main"] }

    class { "sync_files": stage => "first" }

    That's all. Testing results are good enough.
    What you have posted does not solve the problem you originally posed.
    Specifically, it does not cause the whitelist to be updated prior to being
    processed by facter.

    Fact collection happens once each cycle, after plugin sync, and before any
    compilation. A single catalog is then produced and applied, containing all
    the resources declared in all the stages. Run stages merely affect the
    order in which resources are applied relative to one another; they cannot
    make any resources be applied before fact collection.

    I can only suppose that you are picking up a stale whitelist in your tests.


    John

    --
    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/-/E0-7hikA2pAJ.
    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
postedJul 4, '12 at 7:07p
activeJul 7, '12 at 4:07a
posts13
users2
websitepuppetlabs.com

2 users in discussion

Eduardo: 8 posts Jcbollinger: 5 posts

People

Translate

site design / logo © 2022 Grokbase