[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20041001: bigbird (cont.)

>From: Gerry Creager n5jxs <address@hidden>
>Organization: AATLT, Texas A&M University
>Keywords: 200410010304.i9134kUE020346 LDM bigbird

Gerry,

I got on bigbird and noticed that the user 'ldm' was in the wheel
group.  This looked wrong, so I edited /etc/group and changed the
setup.  I then decided to blow away the LDM build and start from
scratch.  When I got to the last installation step, I found that I was
no longer able to use sudo.

The upshot of all of this is tha the LDM is not currently running and
won't run.  When I try to start it, pqact dumps core.  This is a
situation I do NOT understand!

I noticed that you upgraded bigbird to Fedora Core 2.  Ordinarily, I
would suspect that the problem in getting the LDM to run had something
to do with that, but since I am running FC2 on a box here in my office
I know that things should work OK.

Anyway, It seems that you added ldm to the wheel group so that it could
have sudo capabilities.  Am I incorrect in remembering that this was
not the case previously?  Is it possible to add sudo capabilities for
'ldm' without adding it to the wheel group?  If yes, could you please
do this.  I would if I could, but I can't since the 'ldm' account no
longer has sudo capabilities.

I guess I shot myself in the foot while trying to get to the bottom of
why the LDM installation would not run after a standard and complete
installation.

Sorry for the hassle.

Tom

>I'll change ownership back on them now and restart.  Makes sense, but 
>the changes allowed me to get things working!
>
>More inline
>
>Unidata Support wrote:
>>>From: Gerry Creager N5JXS <address@hidden>
>>>Organization: Texas A&M University -- AATLT
>> 
>> 
>> Hi Gerry,
>> 
>> 
>>>Is happier now.  2TB raid in place using 3Ware hardware (7506-12).
>>>We're config'd for RAID5 with one hot-spare drive.
>> 
>> 
>> Sounds good.  After the extreme disappointment in the performacne of
>> the RAID card I tried (TX2000) and not great performance of your
>> HighPoint cards, I look forward to getting a feel for how well the
>> 3Ware card works.
>
>For reference, with the HighPoint OR the Promise cards, initialization 
>of a 2TB system took 8-12 hours.  With the 3Ware 7506-12, it took 2 hrs. 
>  For the record, xfs formatting took 2 clock seconds.
>
>>>ldm is running.  I'll advise when I'm a little more coherent, but 
>>>somehow permissions in ~ldm/bin got screwed up and rpc.ldmd was owned by 
>>>root.
>> 
>> 
>> rpc.ldmd and hupsyslog are _supposed_ to be owned by root.  This is
>> done in the last step of the LDM install:
>> 
>> <as root>
>> cd ~ldm/ldm-6.0.14/src
>> make install_setuids
>
>Made the changes, now 'ldmadmin watch' shows nothing.  And looking at 
>interface activity, it's not happy.  So: Now I've gotten it back to 
>where I had it, and it's still not happy.  Earlier it was at least 
>snagging data and writing same to the array.
>
>And I'm running out of time for today.  I've gotta finish a survey to 
>send out to the SURA SCOOP (ocean and coastal community) on data and 
>system security.
>
>>>It was starting, we just couldn't look at the result.  It didn't 
>>>appear in 'top' 'cause we were looking for processes owned by ldm, not root!
>> 
>> 
>> This is strange.  I will take a look when I get a chance.
>
>Yeah.  Lots about this install has been strange.  But I think we're most 
>of the way back.  Still a couple of issues.  I've had to go back to a 
>different SMP kernel than the latest (2.6.8) and I'm investigating 
>what's happening there.  Also, with the 2.6.5 SMP kernel, I see some 
>i8042 AUX and interrupt errors, that I don't get with uniprocessor 
>stuff.  I believe, but am checking on, that the APIC isn't called in 
>uniprocessor mode, but is called in SMP mode.  If that is the case, 
>there's either a hosed bit of kernel code or a hosed bit of hardware, 
>and I'll eventually figure out which.  The 2.6.8 failure is due to the 
>8042 issue leading to a kernel panic and hard stop.
>
>I've got it config'd to run in uniproc mode by default as that comes up 
>clean and "just works!" but if I can get to it on boot I will boot into 
>the working SMP version.
>-- 
>Gerry Creager -- address@hidden
>Network Engineering -- AATLT, Texas A&M University     
>Cell: 979.229.5301 Office: 979.458.4020
>FAX:  979.847.8578 Pager:  979.228.0173
>Office: 903A Eller Bldg, TAMU, College Station, TX 77843
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.

>From address@hidden  Fri Oct  1 12:29:53 2004

Really all wheel does in Linux is allow a clean, and somewhat privileged 
access to sudo.  In some of the older unix's it's got other actions 
available, but it's mostly legacy in Linux.

Using wheel for sudo is the way things were for the entire life of 
bigbird, so that's not a change.

Also, since wheel's not implicated in user/group permissions for the ldm 
stuff, I don't think that was hosing things up.

I think I can clean it up pretty easily; no harm done.  The other thing 
is:  Data's flowing fast and furious now, and ldmwatch says ldm's running.

The move to FC2 was intentional.  I've other systems running it, and 
sans problems, so I knew it would/should run.  The ldm problem predated 
the upgrade; the combination of the code misbehaving and knowing it'd 
run fine on FC2 was enough for me to do the upgrade to check out whether 
the full upgrade and all (236!) updates after the base ISO upgrade would 
help.

ldm's got explicit sudo rights now and still is not in wheel...

I'm sitting in the office if we need to chat on the phone:  979.458.4020

Hope this helps
gerry

Unidata Support wrote:
>>From: Gerry Creager n5jxs <address@hidden>
>>Organization: AATLT, Texas A&M University
>>Keywords: 200410010304.i9134kUE020346 LDM bigbird
> 
> 
> Gerry,
> 
> I got on bigbird and noticed that the user 'ldm' was in the wheel
> group.  This looked wrong, so I edited /etc/group and changed the
> setup.  I then decided to blow away the LDM build and start from
> scratch.  When I got to the last installation step, I found that I was
> no longer able to use sudo.
> 
> The upshot of all of this is tha the LDM is not currently running and
> won't run.  When I try to start it, pqact dumps core.  This is a
> situation I do NOT understand!
> 
> I noticed that you upgraded bigbird to Fedora Core 2.  Ordinarily, I
> would suspect that the problem in getting the LDM to run had something
> to do with that, but since I am running FC2 on a box here in my office
> I know that things should work OK.
> 
> Anyway, It seems that you added ldm to the wheel group so that it could
> have sudo capabilities.  Am I incorrect in remembering that this was
> not the case previously?  Is it possible to add sudo capabilities for
> 'ldm' without adding it to the wheel group?  If yes, could you please
> do this.  I would if I could, but I can't since the 'ldm' account no
> longer has sudo capabilities.
> 
> I guess I shot myself in the foot while trying to get to the bottom of
> why the LDM installation would not run after a standard and complete
> installation.
> 
> Sorry for the hassle.
> 
> Tom
> 
> 
>>I'll change ownership back on them now and restart.  Makes sense, but 
>>the changes allowed me to get things working!
>>
>>More inline
>>
>>Unidata Support wrote:
>>
>>>>From: Gerry Creager N5JXS <address@hidden>
>>>>Organization: Texas A&M University -- AATLT
>>>
>>>
>>>Hi Gerry,
>>>
>>>
>>>
>>>>Is happier now.  2TB raid in place using 3Ware hardware (7506-12).
>>>>We're config'd for RAID5 with one hot-spare drive.
>>>
>>>
>>>Sounds good.  After the extreme disappointment in the performacne of
>>>the RAID card I tried (TX2000) and not great performance of your
>>>HighPoint cards, I look forward to getting a feel for how well the
>>>3Ware card works.
>>
>>For reference, with the HighPoint OR the Promise cards, initialization 
>>of a 2TB system took 8-12 hours.  With the 3Ware 7506-12, it took 2 hrs. 
>> For the record, xfs formatting took 2 clock seconds.
>>
>>
>>>>ldm is running.  I'll advise when I'm a little more coherent, but 
>>>>somehow permissions in ~ldm/bin got screwed up and rpc.ldmd was owned by 
>>>>root.
>>>
>>>
>>>rpc.ldmd and hupsyslog are _supposed_ to be owned by root.  This is
>>>done in the last step of the LDM install:
>>>
>>><as root>
>>>cd ~ldm/ldm-6.0.14/src
>>>make install_setuids
>>
>>Made the changes, now 'ldmadmin watch' shows nothing.  And looking at 
>>interface activity, it's not happy.  So: Now I've gotten it back to 
>>where I had it, and it's still not happy.  Earlier it was at least 
>>snagging data and writing same to the array.
>>
>>And I'm running out of time for today.  I've gotta finish a survey to 
>>send out to the SURA SCOOP (ocean and coastal community) on data and 
>>system security.
>>
>>
>>>>It was starting, we just couldn't look at the result.  It didn't 
>>>>appear in 'top' 'cause we were looking for processes owned by ldm, not root!
>>>
>>>
>>>This is strange.  I will take a look when I get a chance.
>>
>>Yeah.  Lots about this install has been strange.  But I think we're most 
>>of the way back.  Still a couple of issues.  I've had to go back to a 
>>different SMP kernel than the latest (2.6.8) and I'm investigating 
>>what's happening there.  Also, with the 2.6.5 SMP kernel, I see some 
>>i8042 AUX and interrupt errors, that I don't get with uniprocessor 
>>stuff.  I believe, but am checking on, that the APIC isn't called in 
>>uniprocessor mode, but is called in SMP mode.  If that is the case, 
>>there's either a hosed bit of kernel code or a hosed bit of hardware, 
>>and I'll eventually figure out which.  The 2.6.8 failure is due to the 
>>8042 issue leading to a kernel panic and hard stop.
>>
>>I've got it config'd to run in uniproc mode by default as that comes up 
>>clean and "just works!" but if I can get to it on boot I will boot into 
>>the working SMP version.
>>-- 
>>Gerry Creager -- address@hidden
>>Network Engineering -- AATLT, Texas A&M University    
>>Cell: 979.229.5301 Office: 979.458.4020
>>FAX:  979.847.8578 Pager:  979.228.0173
>>Office: 903A Eller Bldg, TAMU, College Station, TX 77843
>>
> 
> --
> **************************************************************************** <
> Unidata User Support                                    UCAR Unidata Program <
> (303)497-8643                                                  P.O. Box 3000 <
> address@hidden                                   Boulder, CO 80307 <
> ---------------------------------------------------------------------------- <
> Unidata WWW Service              http://my.unidata.ucar.edu/content/support  <
> ---------------------------------------------------------------------------- <
> NOTE: All email exchanges with Unidata User Support are recorded in the
> Unidata inquiry tracking system and then made publicly available
> through the web.  If you do not want to have your interactions made
> available in this way, you must let us know in each email you send to us.


-- 
Gerry Creager -- address@hidden
Network Engineering -- AATLT, Texas A&M University      
Cell: 979.229.5301 Office: 979.458.4020
FAX:  979.847.8578 Pager:  979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843