[sudo-users] script runs using sudo but not as root

[Mike Gallamore]

The cfengine script "just" maintains the permissions on the common  
security files (group, sudoers, shadow and passwd for example), and  
makes sure that all the nodes are configured with the same nfs mounts.

It was kept on a NFS directory because all the other systems in the  
VLAN are PXE booted off this fileserver, so it is the only system that  
isn't going to be reinstalled on a frequent basis. The script gives:

/opt/cfengine/sbin/cfagent: symbol lookup error: /opt/cfengine/sbin/ 
cfagent: undefined symbol: db_create

When run as root, but not when sudoed from other user accounts or even  
root. Binary incompatibility, anything is possible I suppose, but the  
version of cfengine wasn't changed, it was installed on the 64-bit  
nodes, but it was already installed and working on the 32-bit nodes  
for years. Could it be something as simple as a binary log file being  
touched last by a 64-bit node and then the 32-bit ones can no longer  
read it? Not sure how to determine that.
On Jan 21, 2009, at 8:04 PM, Russell Van Tassell wrote:

>
> Well, sounds like you eliminated too many details... such as even  
> saying
> what or how the script fails -- what does it fail to do?  What are the
> errors you're receiving?
>
> Given that cfengine touches things on an NFS-mounted partition, could
> this be the infamous root to nobody mapping issue?  Myself, running a
> cfengine system I've always found it easier to keep the files on a  
> local
> disk (but I don't completely know your application here, either).
>
> Given that running it as root (ie. not using sudo), I'd expect that  
> your
> setup is causing the problem ... generally checking permissions, you
> tend to "just run as root and see if it works" and assume that if root
> works, it's a permission problem.  With NFS, you tend to do the
> opposite... run as a different user and, if it breaks as root, chances
> are it's NFS.
>
> Also, if you're running in 64 and 32 bit clusters, are you sure it's  
> not
> as simple as having introduced some binary incompatibilities in your
> upgrade?
>
> Again, without real specifics, it's tough to "see" the problem, here.
> My guess, however, is that it's not a sudo problem (ie. since it  
> breaks
> when run from a root login); and since most folks tend to cron  
> cfengine
> to run regularly (or use cfrun), I'm still not clear on sudo's role,
> here (or the "sudo failure").
>
> Russell
>
>
> On Wed, Jan 21, 2009 at 10:00:45AM +0100, Mike Gallamore wrote:
>> I tried to eliminate some of the details to help make the problem  
>> more
>> understandable.
>>
>> The script is the run_cfengine.sh script which as you can expect runs
>> GNU's cfengine on the client. These systems are part of a cluster, up
>> until recently they were all running CentOS 4.3. I upgraded 8 of the
>> nodes to 64-bit CentOS 5.2. All the files that cfengine touches  
>> reside
>> on a NFS mounted disk array.
>>
>> The strange thing is that the cfengine configuration wasn't touched,
>> as wasn't the files that are pushed over to the cluster nodes (eg.  
>> the
>> sudoers file). The 64-bit nodes cfengine script works, but the older
>> 32-bit nodes gotten broken somehow in the process.
>>
>> The problem is more of "what is sudo doing right?", because even if
>> I'm logged in as root the script fails when I try to run it, but if I
>> run it using sudo it runs without a problem. As my first email showed
>> hopefully with the included sudoers file, our sudo setup is as basic
>> as it can get, root and our three administrators have all sudo  
>> rights.
>> No changes to how paths are inherited or anything, sudo is running
>> under the environment of the calling user as per default.
>> On Jan 20, 2009, at 7:40 PM, Russell Van Tassell wrote:
>>
>>> On Tue, Jan 20, 2009 at 01:31:54PM +0100, Mike Gallamore wrote:
>>>> I have  a strange problem were a script that is owned by root,  
>>>> gives
>>>> an error when run as root but not when run using sudo. Anyone seen
>>>> this before? Know of  a way to fix it?
>>>>
>>>> Info:
>>>> sudo version 1.6.7p5
>>>> system running CentOS 4.3
>>>
>>> Think you might need to be a bit more specific, here (ie. what's the
>>> command that's failing).
>>>
>>> Any chance it's running on a remote filesystem or similar where the
>>> root
>>> user is mapped to something like "nobody" or similar?
>>>
>>>
>>>
>>> -- 
>>> Russell M. Van Tassell
>>> russell at loosenut.com
>>>
>>> Do not read this fortune under penalty of law.  Violators will be
>>> prosecuted.  (Penal Code sec. 2.3.2 (II.a.))
>
> -- 
> Russell M. Van Tassell
> russell at loosenut.com
>
> "When in doubt, tell the truth."                           - Mark  
> Twain