I've not had much time to really investigate this error since I'm just
finishing up my AMIs but has anyone seen anything like this when
creating users as part of the base role at bootstrap?
If I log in immediately after and run chef-client, everything works
fine. It only happens at bootstrap as part of the base role I created.
I've never been able to reproduce by logging on to the server and it occurs
even when I execute chef-client twice, though when i at the end of my
bootstrap do a /etc/init.d/chef-client start everything works normally.
I haven't gone too far in investigating because the bootstrap still ends up
working with the init.d start of chef-client but I may look again tonight
now that I know someone else is experiencing it.
I've not had much time to really investigate this error since I'm just
finishing up my AMIs but has anyone seen anything like this when
creating users as part of the base role at bootstrap?
I've never been able to reproduce by logging on to the server and it occurs
even when I execute chef-client twice, though when i at the end of my
bootstrap do a /etc/init.d/chef-client start everything works normally.
I haven't gone too far in investigating because the bootstrap still ends up
working with the init.d start of chef-client but I may look again tonight
now that I know someone else is experiencing it.
I've not had much time to really investigate this error since I'm just
finishing up my AMIs but has anyone seen anything like this when
creating users as part of the base role at bootstrap?
I just realized that same return code is something I've seen in Nagios
before too when executing plugins. In fact, it's a similar MO - runs
fine from an interactive session but doesn't from an automated
session.
It's generally something to do with the environment that the script is
running under or a permissions error.
And I think I found it:
[root@domU ~]# export PATH=/usr/bin
[root@domU ~]# groupadd -g 504 testgroup
-bash: groupadd: command not found
[root@domU ~]# echo $?
127
It looks like chef-client isn't importing the path environment
variables. Maybe it should be calling groupadd with the full path?
This is on a CentOS ec2 bootstrap.
Can't tell at this point if it's a bug with Chef or with
net-ssh-multi. Still investigating.
On Wed, Dec 8, 2010 at 6:34 PM, Sean OMeara someara@gmail.com wrote:
I've never been able to reproduce by logging on to the server and it occurs
even when I execute chef-client twice, though when i at the end of my
bootstrap do a /etc/init.d/chef-client start everything works normally.
I haven't gone too far in investigating because the bootstrap still ends up
working with the init.d start of chef-client but I may look again tonight
now that I know someone else is experiencing it.
I've not had much time to really investigate this error since I'm just
finishing up my AMIs but has anyone seen anything like this when
creating users as part of the base role at bootstrap?
I just realized that same return code is something I've seen in Nagios
before too when executing plugins. In fact, it's a similar MO - runs
fine from an interactive session but doesn't from an automated
session.
It's generally something to do with the environment that the script is
running under or a permissions error.
And I think I found it:
[root@domU ~]# export PATH=/usr/bin
[root@domU ~]# groupadd -g 504 testgroup
-bash: groupadd: command not found
[root@domU ~]# echo $?
127
It looks like chef-client isn't importing the path environment
variables. Maybe it should be calling groupadd with the full path?
This is on a CentOS ec2 bootstrap.
Can't tell at this point if it's a bug with Chef or with
net-ssh-multi. Still investigating.
On Wed, Dec 8, 2010 at 6:34 PM, Sean OMeara someara@gmail.com wrote:
I've never been able to reproduce by logging on to the server and it occurs
even when I execute chef-client twice, though when i at the end of my
bootstrap do a /etc/init.d/chef-client start everything works normally.
I haven't gone too far in investigating because the bootstrap still ends up
working with the init.d start of chef-client but I may look again tonight
now that I know someone else is experiencing it.
I've not had much time to really investigate this error since I'm just
finishing up my AMIs but has anyone seen anything like this when
creating users as part of the base role at bootstrap?
It's a custom one that's been really stripped down and the
centos5-gems bootstrap template. I just did another test after
modifying the template and was able to fix it.
I added:
export PATH=$PATH:/usr/sbin on the line before the bootstrap
chef-client call. This is one of those Redhat-isms. /sbin/ and
/usr/sbin are NOT in the system-wide path by default. They're only
available to root so it feels like the issue is that the login scripts
are being ignored by net-ssh-multi possibly because it's not running
with a tty?
On Wed, Dec 8, 2010 at 10:11 PM, Sean OMeara someara@gmail.com wrote:
I just realized that same return code is something I've seen in Nagios
before too when executing plugins. In fact, it's a similar MO - runs
fine from an interactive session but doesn't from an automated
session.
It's generally something to do with the environment that the script is
running under or a permissions error.
And I think I found it:
[root@domU ~]# export PATH=/usr/bin
[root@domU ~]# groupadd -g 504 testgroup
-bash: groupadd: command not found
[root@domU ~]# echo $?
127
It looks like chef-client isn't importing the path environment
variables. Maybe it should be calling groupadd with the full path?
This is on a CentOS ec2 bootstrap.
Can't tell at this point if it's a bug with Chef or with
net-ssh-multi. Still investigating.
On Wed, Dec 8, 2010 at 6:34 PM, Sean OMeara someara@gmail.com wrote:
I've never been able to reproduce by logging on to the server and it occurs
even when I execute chef-client twice, though when i at the end of my
bootstrap do a /etc/init.d/chef-client start everything works normally.
I haven't gone too far in investigating because the bootstrap still ends up
working with the init.d start of chef-client but I may look again tonight
now that I know someone else is experiencing it.
I've not had much time to really investigate this error since I'm just
finishing up my AMIs but has anyone seen anything like this when
creating users as part of the base role at bootstrap?
It's a custom one that's been really stripped down and the
centos5-gems bootstrap template. I just did another test after
modifying the template and was able to fix it.
I added:
export PATH=$PATH:/usr/sbin on the line before the bootstrap
chef-client call. This is one of those Redhat-isms. /sbin/ and
/usr/sbin are NOT in the system-wide path by default. They're only
available to root so it feels like the issue is that the login scripts
are being ignored by net-ssh-multi possibly because it's not running
with a tty?
On Wed, Dec 8, 2010 at 10:11 PM, Sean OMeara someara@gmail.com wrote:
I just realized that same return code is something I've seen in Nagios
before too when executing plugins. In fact, it's a similar MO - runs
fine from an interactive session but doesn't from an automated
session.
It's generally something to do with the environment that the script is
running under or a permissions error.
And I think I found it:
[root@domU ~]# export PATH=/usr/bin
[root@domU ~]# groupadd -g 504 testgroup
-bash: groupadd: command not found
[root@domU ~]# echo $?
127
It looks like chef-client isn't importing the path environment
variables. Maybe it should be calling groupadd with the full path?
This is on a CentOS ec2 bootstrap.
Can't tell at this point if it's a bug with Chef or with
net-ssh-multi. Still investigating.
On Wed, Dec 8, 2010 at 6:34 PM, Sean OMeara someara@gmail.com wrote:
I've never been able to reproduce by logging on to the server and it occurs
even when I execute chef-client twice, though when i at the end of my
bootstrap do a /etc/init.d/chef-client start everything works normally.
I haven't gone too far in investigating because the bootstrap still ends up
working with the init.d start of chef-client but I may look again tonight
now that I know someone else is experiencing it.
I've not had much time to really investigate this error since I'm just
finishing up my AMIs but has anyone seen anything like this when
creating users as part of the base role at bootstrap?
Well that's good to know allthough I won't be running with 6 until
CentOS catches up. Either way, the bootstrap template is for version 5
so I added the export line and made a pull request
On Wed, Dec 8, 2010 at 11:13 PM, Sean OMeara someara@gmail.com wrote:
probably. You'll be glad to know it works fine on fedora/rhel6.
It's a custom one that's been really stripped down and the
centos5-gems bootstrap template. I just did another test after
modifying the template and was able to fix it.
I added:
export PATH=$PATH:/usr/sbin on the line before the bootstrap
chef-client call. This is one of those Redhat-isms. /sbin/ and
/usr/sbin are NOT in the system-wide path by default. They're only
available to root so it feels like the issue is that the login scripts
are being ignored by net-ssh-multi possibly because it's not running
with a tty?
On Wed, Dec 8, 2010 at 10:11 PM, Sean OMeara someara@gmail.com wrote:
I just realized that same return code is something I've seen in Nagios
before too when executing plugins. In fact, it's a similar MO - runs
fine from an interactive session but doesn't from an automated
session.
It's generally something to do with the environment that the script is
running under or a permissions error.
And I think I found it:
[root@domU ~]# export PATH=/usr/bin
[root@domU ~]# groupadd -g 504 testgroup
-bash: groupadd: command not found
[root@domU ~]# echo $?
127
It looks like chef-client isn't importing the path environment
variables. Maybe it should be calling groupadd with the full path?
This is on a CentOS ec2 bootstrap.
Can't tell at this point if it's a bug with Chef or with
net-ssh-multi. Still investigating.
On Wed, Dec 8, 2010 at 6:34 PM, Sean OMeara someara@gmail.com wrote:
I've never been able to reproduce by logging on to the server and it occurs
even when I execute chef-client twice, though when i at the end of my
bootstrap do a /etc/init.d/chef-client start everything works normally.
I haven't gone too far in investigating because the bootstrap still ends up
working with the init.d start of chef-client but I may look again tonight
now that I know someone else is experiencing it.
I've not had much time to really investigate this error since I'm just
finishing up my AMIs but has anyone seen anything like this when
creating users as part of the base role at bootstrap?
Well that's good to know allthough I won't be running with 6 until
CentOS catches up. Either way, the bootstrap template is for version 5
so I added the export line and made a pull request
On Wed, Dec 8, 2010 at 11:13 PM, Sean OMeara someara@gmail.com wrote:
probably. You'll be glad to know it works fine on fedora/rhel6.
It's a custom one that's been really stripped down and the
centos5-gems bootstrap template. I just did another test after
modifying the template and was able to fix it.
I added:
export PATH=$PATH:/usr/sbin on the line before the bootstrap
chef-client call. This is one of those Redhat-isms. /sbin/ and
/usr/sbin are NOT in the system-wide path by default. They're only
available to root so it feels like the issue is that the login scripts
are being ignored by net-ssh-multi possibly because it's not running
with a tty?
On Wed, Dec 8, 2010 at 10:11 PM, Sean OMeara someara@gmail.com wrote:
I just realized that same return code is something I've seen in Nagios
before too when executing plugins. In fact, it's a similar MO - runs
fine from an interactive session but doesn't from an automated
session.
It's generally something to do with the environment that the script is
running under or a permissions error.
And I think I found it:
[root@domU ~]# export PATH=/usr/bin
[root@domU ~]# groupadd -g 504 testgroup
-bash: groupadd: command not found
[root@domU ~]# echo $?
127
It looks like chef-client isn't importing the path environment
variables. Maybe it should be calling groupadd with the full path?
This is on a CentOS ec2 bootstrap.
Can't tell at this point if it's a bug with Chef or with
net-ssh-multi. Still investigating.
On Wed, Dec 8, 2010 at 6:34 PM, Sean OMeara someara@gmail.com wrote:
I've never been able to reproduce by logging on to the server and it
occurs
even when I execute chef-client twice, though when i at the end of my
bootstrap do a /etc/init.d/chef-client start everything works normally.
I haven't gone too far in investigating because the bootstrap still ends
up
working with the init.d start of chef-client but I may look again
tonight
now that I know someone else is experiencing it.
I've not had much time to really investigate this error since I'm just
finishing up my AMIs but has anyone seen anything like this when
creating users as part of the base role at bootstrap?