I have a question hopefully someone here can help me out with. I have a
module that I didn''t write, I got it from the github. it''s
the postgres
module. I''m running on CentOS 5. In the module there is this:
case $ensure {
present: {
exec { "Create $name postgres db":
command => "/usr/bin/createdb $ownerstring $name",
user => "postgres",
unless => "/usr/bin/psql -l | grep ''$name
*|''" *** This
line causes an error
}
}
The *** line causes puppet to error out like so:
debug: //Node[myhost.mydomain.com]/Postgres::Role[voiceob]/Exec[Create puser
postgres role]: Executing check ''/usr/bin/psql -c
''\du'' | grep ''puser *|''''
debug: Executing ''/usr/bin/psql -c ''\du'' | grep
''puser *|''''
err: //Node[myhost.mydomain.com]/Postgres::Role[puser]/Exec[Create puser
postgres role]: Failed to retrieve current state of resource:
(This produces no output if the user doesn''t exist in postgres.)
Nothing more on the error line. Interestingly enough, if I remove the
''|''
(pipe) after the psql part of the command, it doesn''t error. However,
it
doesn''t do what I need it to do. I have tried it without the unless
line
and it works perfectly. Again, it doesn''t do what I need it to do that
way
though. I have searched the message boards and wiki to no avail.
Can any of you shed some light on why this wouldn''t work?
TIA
Drew
--
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.
On Wednesday 24 Feb 2010 20:59:54 Andrew Hamilton wrote:> I have a question hopefully someone here can help me out with. I have a > module that I didn''t write, I got it from the github. it''s the postgres > module. I''m running on CentOS 5. In the module there is this: > > case $ensure { > present: { > exec { "Create $name postgres db": > command => "/usr/bin/createdb $ownerstring $name", > user => "postgres", > unless => "/usr/bin/psql -l | grep ''$name *|''" *** This > line causes an error > } > } > > The *** line causes puppet to error out like so: > > debug: //Node[myhost.mydomain.com]/Postgres::Role[voiceob]/Exec[Create > puser postgres role]: Executing check ''/usr/bin/psql -c ''\du'' | grep > ''puser *|'''' debug: Executing ''/usr/bin/psql -c ''\du'' | grep ''puser *|'''' > err: //Node[myhost.mydomain.com]/Postgres::Role[puser]/Exec[Create puser > postgres role]: Failed to retrieve current state of resource: > > (This produces no output if the user doesn''t exist in postgres.) > > Nothing more on the error line. Interestingly enough, if I remove the ''|'' > (pipe) after the psql part of the command, it doesn''t error. However, it > doesn''t do what I need it to do. I have tried it without the unless line > and it works perfectly. Again, it doesn''t do what I need it to do that way > though. I have searched the message boards and wiki to no avail. > > Can any of you shed some light on why this wouldn''t work? > > TIA > > Drew >I''m not sure why that doesn''t work but I remember some problems I had with psql in postgres setup, I think I eventually started changing the output format to something different, e.g. the above would be: psql -P format=unaligned -tc "\\du ${name} |grep ''^ *${name}''" Just an idea, for alternative approach. Regards, Michael -- Michael Gliwinski Henderson Group Information Services 9-11 Hightown Avenue, Newtownabby, BT36 4RT Phone: 028 9034 3319 ********************************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract. If you have received this email in error please notify support@henderson-group.com John Henderson (Holdings) Ltd Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. Registered in Northern Ireland Registration Number NI010588 Vat No.: 814 6399 12 ********************************************************************************* -- 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.
Have you checked out what that command does when you run it from the command line? Does it complete successfully? What is the return code? Possibility 1: Your version of Puppet (you didn''t say which) is not correctly preserving the inner single quotation marks around ''$name *|''. This seems unlikely, but I''m having trouble seeing why else the command would actually fail, as opposed to returning *some* result, even if it were the wrong one. Michael''s suggestion of changing the output format might provide a workaround in that case. Alternatively, if you''re not on the latest Puppet then you could try upgrading. Possibility 2: (?) The fact that the command runs without error when you remove the (pipe) rules out pretty much everything else I came up with. Do note, by the way, that the ''unless'' command is buggy in any event, because it will return the wrong result when there is an existing database with a name suffix that matches your database''s name. Depending on the psql output details, there may be other possibilities for unintended matches. That in itself would be an excellent reason to look into taking tighter control of the psql output format, or else inserting an additional filter between psql and grep (which could be another grep). If your database name contains regex metacharacters (e.g. ''.''), then that also would present a possibility of unintended matches. -- 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.
Thanks for the replies and other possibilities. I''m using version 0.25.2 of puppet. I did a different kind of workaround mostly by doing the same thing with a straight psql command with no pipe. ie. "/usr/bin/psql -c ''select * from pg_user where usename = ''myuser''" This at least seems to not error, however it still tried to create the user even though it existed on subsequent runs of puppetd --test. So still not quite getting what I expect. I''m going to try Michael''s suggestion and see if it has something to do with the formatting of the return value. Drew On Thu, Feb 25, 2010 at 7:31 AM, jcbollinger <John.Bollinger@stjude.org>wrote:> Have you checked out what that command does when you run it from the > command line? Does it complete successfully? What is the return > code? > > Possibility 1: Your version of Puppet (you didn''t say which) is not > correctly preserving the inner single quotation marks around ''$name > *|''. This seems unlikely, but I''m having trouble seeing why else the > command would actually fail, as opposed to returning *some* result, > even if it were the wrong one. Michael''s suggestion of changing the > output format might provide a workaround in that case. Alternatively, > if you''re not on the latest Puppet then you could try upgrading. > > Possibility 2: (?) The fact that the command runs without error when > you remove the (pipe) rules out pretty much everything else I came up > with. > > Do note, by the way, that the ''unless'' command is buggy in any event, > because it will return the wrong result when there is an existing > database with a name suffix that matches your database''s name. > Depending on the psql output details, there may be other possibilities > for unintended matches. That in itself would be an excellent reason > to look into taking tighter control of the psql output format, or else > inserting an additional filter between psql and grep (which could be > another grep). If your database name contains regex metacharacters > (e.g. ''.''), then that also would present a possibility of unintended > matches. > > -- > 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. > >-- 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.
I tried Michael''s suggestion above and when running it from the command line, it does complete successfully. It returns 0 when the user exists and 1 when it doesn''t. Does that make sense? Anyway, inserting the pipe back into it produces the same error as before. It''s perplexing... Thanks, Drew On Thu, Feb 25, 2010 at 9:21 AM, Andrew Hamilton <andrew80k@gmail.com>wrote:> Thanks for the replies and other possibilities. I''m using version 0.25.2 > of puppet. I did a different kind of workaround mostly by doing the same > thing with a straight psql command with no pipe. ie. > > "/usr/bin/psql -c ''select * from pg_user where usename = ''myuser''" > > This at least seems to not error, however it still tried to create the user > even though it existed on subsequent runs of puppetd --test. So still not > quite getting what I expect. I''m going to try Michael''s suggestion and see > if it has something to do with the formatting of the return value. > > Drew > > > On Thu, Feb 25, 2010 at 7:31 AM, jcbollinger <John.Bollinger@stjude.org>wrote: > >> Have you checked out what that command does when you run it from the >> command line? Does it complete successfully? What is the return >> code? >> >> Possibility 1: Your version of Puppet (you didn''t say which) is not >> correctly preserving the inner single quotation marks around ''$name >> *|''. This seems unlikely, but I''m having trouble seeing why else the >> command would actually fail, as opposed to returning *some* result, >> even if it were the wrong one. Michael''s suggestion of changing the >> output format might provide a workaround in that case. Alternatively, >> if you''re not on the latest Puppet then you could try upgrading. >> >> Possibility 2: (?) The fact that the command runs without error when >> you remove the (pipe) rules out pretty much everything else I came up >> with. >> >> Do note, by the way, that the ''unless'' command is buggy in any event, >> because it will return the wrong result when there is an existing >> database with a name suffix that matches your database''s name. >> Depending on the psql output details, there may be other possibilities >> for unintended matches. That in itself would be an excellent reason >> to look into taking tighter control of the psql output format, or else >> inserting an additional filter between psql and grep (which could be >> another grep). If your database name contains regex metacharacters >> (e.g. ''.''), then that also would present a possibility of unintended >> matches. >> >> -- >> 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. >> >> >-- 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.
It looks to me like something is replacing your command before it gets executed. I have no idea what could be doing that but what is being entered as /usr/bin/psql -l | grep ''$name *|'' is then being changed to /usr/bin/psql -c ''\du'' | grep ''puser *|'' so -l is being changed to -c ''\du''. Both of these are valid psql commands. On 25/02/2010 16:34, Andrew Hamilton wrote:> I tried Michael''s suggestion above and when running it from the > command line, it does complete successfully. It returns 0 when the > user exists and 1 when it doesn''t. Does that make sense? Anyway, > inserting the pipe back into it produces the same error as before. > It''s perplexing... >-- Trevor Hemsley Infrastructure Engineer ................................................. * C A L Y P S O * Brighton, UK OFFICE +44 (0) 1273 666 350 FAX +44 (0) 1273 666 351 ................................................. www.calypso.com This electronic-mail might contain confidential information intended only for the use by the entity named. If the reader of this message is not the intended recipient, the reader is hereby notified that any dissemination, distribution or copying is strictly prohibited. * P * /*/ Please consider the environment before printing this e-mail /*/ -- 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.
This is probably my fault. I''m doing two different things here. One is creating a database if it doesn''t exist and the other is creating a user if it doesn''t exist. I''m probably mixing the two in my comments though I didn''t mean to. My next test was to wrap it in a /usr/bin/test to see if I could normalize it somehow. I think the logic is backward though. Wrapping it in the /usr/bin/test worked, but on subsequent runs tried to create the user again. I changed it to onlyif and it seemed to work to prevent it from retrying, but then it wouldn''t create it if it didn''t exist. It''s like something is flipping the logic. Thanks. On Thu, Feb 25, 2010 at 9:43 AM, Trevor Hemsley <trevor.hemsley@codefarm.com> wrote:> It looks to me like something is replacing your command before it gets > executed. I have no idea what could be doing that but what is being entered > as > > > /usr/bin/psql -l | grep ''$name *|'' > > > is then being changed to > > > /usr/bin/psql -c ''\du'' | grep ''puser *|'' > > > so -l is being changed to -c ''\du''. Both of these are valid psql commands. > > > On 25/02/2010 16:34, Andrew Hamilton wrote: > > I tried Michael''s suggestion above and when running it from the command > line, it does complete successfully. It returns 0 when the user exists and > 1 when it doesn''t. Does that make sense? Anyway, inserting the pipe back > into it produces the same error as before. It''s perplexing... > > > -- > > Trevor Hemsley > Infrastructure Engineer > ................................................. > * C A L Y P S O > * Brighton, UK > > OFFICE +44 (0) 1273 666 350 FAX +44 (0) 1273 666 351 > > ................................................. > www.calypso.com > > This electronic-mail might contain confidential information intended only > for the use by the entity named. If the reader of this message is not the > intended recipient, the reader is hereby notified that any dissemination, > distribution or copying is strictly prohibited. > > * P * * Please consider the environment before printing this e-mail * > > -- > 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. >-- 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.
So this is really getting to me and I can''t seem to figure it out. From the documents:> unlessIf this parameter is set, then this exec will run unless the command > returns 0 >I interpret this to be the return value of the command and not the output of the command. So if the return value of my command is 0 then the command will not run, yet I can verify that the return value of the command is 0, yet it still runs. Unless I have this backwards and my interpretations are incorrect. Thanks, Drew On Thu, Feb 25, 2010 at 10:01 AM, Andrew Hamilton <andrew80k@gmail.com>wrote:> This is probably my fault. I''m doing two different things here. One is > creating a database if it doesn''t exist and the other is creating a user if > it doesn''t exist. I''m probably mixing the two in my comments though I > didn''t mean to. > > My next test was to wrap it in a /usr/bin/test to see if I could normalize > it somehow. I think the logic is backward though. Wrapping it in the > /usr/bin/test worked, but on subsequent runs tried to create the user > again. I changed it to onlyif and it seemed to work to prevent it from > retrying, but then it wouldn''t create it if it didn''t exist. It''s like > something is flipping the logic. > > Thanks. > > > On Thu, Feb 25, 2010 at 9:43 AM, Trevor Hemsley < > trevor.hemsley@codefarm.com> wrote: > >> It looks to me like something is replacing your command before it gets >> executed. I have no idea what could be doing that but what is being entered >> as >> >> >> /usr/bin/psql -l | grep ''$name *|'' >> >> >> is then being changed to >> >> >> /usr/bin/psql -c ''\du'' | grep ''puser *|'' >> >> >> so -l is being changed to -c ''\du''. Both of these are valid psql commands. >> >> >> On 25/02/2010 16:34, Andrew Hamilton wrote: >> >> I tried Michael''s suggestion above and when running it from the command >> line, it does complete successfully. It returns 0 when the user exists and >> 1 when it doesn''t. Does that make sense? Anyway, inserting the pipe back >> into it produces the same error as before. It''s perplexing... >> >> >> -- >> >> Trevor Hemsley >> Infrastructure Engineer >> ................................................. >> * C A L Y P S O >> * Brighton, UK >> >> OFFICE +44 (0) 1273 666 350 FAX +44 (0) 1273 666 351 >> >> ................................................. >> www.calypso.com >> >> This electronic-mail might contain confidential information intended >> only for the use by the entity named. If the reader of this message is not >> the intended recipient, the reader is hereby notified that any >> dissemination, distribution or copying is strictly prohibited. >> >> * P * * Please consider the environment before printing this e-mail * >> >> -- >> 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. >> > >-- 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.
On Thursday 25 Feb 2010 23:19:33 Andrew Hamilton wrote:> > unlessIf this parameter is set, then this exec will run unless the > > command returns 0 > > I interpret this to be the return value of the command and not the output > of the command. So if the return value of my command is 0 then the > command will not run, yet I can verify that the return value of the > command is 0, yet it still runs. Unless I have this backwards and my > interpretations are incorrect. >Yes, that''s right, it''s the return value that matters. And since grep returns 0 if match was found and 1 otherwise, this really should work. For reference here''s how my exec for creating users looks like (after expanding some parameters): ---- exec { "psql:${name}": command => "psql -c \"CREATE ROLE \\\"${name}\\\"", unless => "psql -P format=unaligned -tc ''\\du ${name}'' |grep ''^ *${name}''", user => ''postgres'', path => [''/bin'', ''/sbin'', ''/usr/bin'', ''/usr/sbin'', ''/usr/local/bin'', ''/usr/local/sbin''], logoutput => on_failure, require => [Service[''postgresql''], User[''postgres''], } ---- Basically ''-P format=unaligned'' makes psql print tuples without spaces used to align their width, it uses the default separator (|) but that can be changed with fieldsep option. And the ''-t'' option makes it print tuples only (without headers and footer). That should produce exactly one line if the user already exists or none otherwise, the grep is mostly used to get that return value right. If that doesn''t work for you, maybe try changing the field separator (i.e. ''-P fieldsep=,'' or sth) and see if you can work with that. Regards, Michael -- Michael Gliwinski Henderson Group Information Services 9-11 Hightown Avenue, Newtownabby, BT36 4RT Phone: 028 9034 3319 ********************************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract. If you have received this email in error please notify support@henderson-group.com John Henderson (Holdings) Ltd Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. Registered in Northern Ireland Registration Number NI010588 Vat No.: 814 6399 12 ********************************************************************************* -- 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.
On Friday 26 Feb 2010 16:03:41 Andrew Hamilton wrote:> I can''t thank you enough. This worked perfectly for me. I don''t know how > it is functionally different than what I had before, but nevertheless this > is exactly what I needed. Thanks again. > > Drew >Heh, yeah, that''s the thing, it isn''t really functionally different, I''m not sure why what you had before didn''t work. Might be something psql specific. Anyway, glad I could help. All the best, Michael -- Michael Gliwinski Henderson Group Information Services 9-11 Hightown Avenue, Newtownabby, BT36 4RT Phone: 028 9034 3319 ********************************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract. If you have received this email in error please notify support@henderson-group.com John Henderson (Holdings) Ltd Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. Registered in Northern Ireland Registration Number NI010588 Vat No.: 814 6399 12 ********************************************************************************* -- 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.
I actually think I figured it out what the difference was. In the set up you sent me, you have the "path" defined. In my setup I didn''t and was using grep without the fully qualified path. Other than that, it escapes me for what it could have been. I''ve been happily rolling along since though. Drew On Wed, Mar 3, 2010 at 5:11 AM, Michael Gliwinski < Michael.Gliwinski@henderson-group.com> wrote:> On Friday 26 Feb 2010 16:03:41 Andrew Hamilton wrote: > > I can''t thank you enough. This worked perfectly for me. I don''t know > how > > it is functionally different than what I had before, but nevertheless > this > > is exactly what I needed. Thanks again. > > > > Drew > > > > Heh, yeah, that''s the thing, it isn''t really functionally different, I''m > not > sure why what you had before didn''t work. Might be something psql > specific. > > Anyway, glad I could help. > > All the best, > Michael > > > -- > Michael Gliwinski > Henderson Group Information Services > 9-11 Hightown Avenue, Newtownabby, BT36 4RT > Phone: 028 9034 3319 > > > ********************************************************************************************** > The information in this email is confidential and may be legally > privileged. It is intended solely for the addressee and access to the email > by anyone else is unauthorised. > If you are not the intended recipient, any disclosure, copying, > distribution or any action taken or omitted to be taken in reliance on it, > is prohibited and may be unlawful. > When addressed to our clients, any opinions or advice contained in this > e-mail are subject to the terms and conditions expressed in the governing > client engagement leter or contract. > If you have received this email in error please notify > support@henderson-group.com > > John Henderson (Holdings) Ltd > Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern > Ireland, BT36 4RT. > Registered in Northern Ireland > Registration Number NI010588 > Vat No.: 814 6399 12 > > ********************************************************************************* > > -- > 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. > >-- 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.