Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
root can not change passwords in smit 1
- Thread starter june54
- Start date
Hi Screwloose/June,
No offense taken. To some extent I agree with you.
ODM changes are indeed not to be taken lightly, and if your in anyway unsure of the validity of my advice, then by all means verify the procedures with IBM support first. Esp given that its a Production System.
In this situation however we are only adding one entry to the ODM repository containing the SMIT definitions only. It is a definition which already exists on the other (functional) systems. Also, the whole sm_cmd_opt ObjectClass only contains definitions to control the behaviour of SMIT. If it was a more expansive ObjectClass (such as CuAt etc) there is no way I would have made the above suggestions.
The only impact, in the case of this particular ObjectClass being totally corrupted, is the breaking of SMIT. Awkward by all means, but not the end of the world. Such a situation could easiliy be remedied by restoring the backed up ODM file, or by restoring the raw /usr/lib/objrepos/sm_* files from the last valid backup.
At the same time this particular addition is actually simple enough, and can easily be backed out using one odmdelete command.
Also, please note that June has already successfully executed an odmget against this ObjectCLass, indicating that the links already exist in /etc/objrepos (or the ODMDIR is already set to the /usr/lib/objrepos directory).
Having said all this, there is the other issue of the relevent ODM entry being missing in the first place.
This indicates that the integrity of the ODM may be in question (beyond just this simple entry). This is a serious issue that can not be encompassed via a forum, and would need support from IBM (or a highly qualified AIX professional).
Also, the issue raised by Screwloose is not one to be taken lightly.
I have over 20 years admin experience in UNIX, with over 12 of those years working exclusively with AIX. But you only have my word on this.
If you ever feel concerned regarding the validity of any advise posted on the forums (or the risk involved), then please do not act without first validating the process with IBM support (or a trusted professional).
Just my 2 cents worth ;-)
____________________
Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debuging Mondays code.
No offense taken. To some extent I agree with you.
ODM changes are indeed not to be taken lightly, and if your in anyway unsure of the validity of my advice, then by all means verify the procedures with IBM support first. Esp given that its a Production System.
In this situation however we are only adding one entry to the ODM repository containing the SMIT definitions only. It is a definition which already exists on the other (functional) systems. Also, the whole sm_cmd_opt ObjectClass only contains definitions to control the behaviour of SMIT. If it was a more expansive ObjectClass (such as CuAt etc) there is no way I would have made the above suggestions.
The only impact, in the case of this particular ObjectClass being totally corrupted, is the breaking of SMIT. Awkward by all means, but not the end of the world. Such a situation could easiliy be remedied by restoring the backed up ODM file, or by restoring the raw /usr/lib/objrepos/sm_* files from the last valid backup.
At the same time this particular addition is actually simple enough, and can easily be backed out using one odmdelete command.
Also, please note that June has already successfully executed an odmget against this ObjectCLass, indicating that the links already exist in /etc/objrepos (or the ODMDIR is already set to the /usr/lib/objrepos directory).
Having said all this, there is the other issue of the relevent ODM entry being missing in the first place.
This indicates that the integrity of the ODM may be in question (beyond just this simple entry). This is a serious issue that can not be encompassed via a forum, and would need support from IBM (or a highly qualified AIX professional).
Also, the issue raised by Screwloose is not one to be taken lightly.
I have over 20 years admin experience in UNIX, with over 12 of those years working exclusively with AIX. But you only have my word on this.
If you ever feel concerned regarding the validity of any advise posted on the forums (or the risk involved), then please do not act without first validating the process with IBM support (or a trusted professional).
Just my 2 cents worth ;-)____________________
Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debuging Mondays code.
- Thread starter
- #22
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
june54,
You can use the the smit ODM entries from a known good system without modifying the entries on your production system.
1. Create a directory to contain the good files, for instance /home/june54/smitodm
2. Copy /usr/lib/objrepos/sm_* files from the known good machine into the new directory
3. Execute the following:
cd /home/june54/smitodm
ODMDIR="" smitty passwd
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
You can use the the smit ODM entries from a known good system without modifying the entries on your production system.
1. Create a directory to contain the good files, for instance /home/june54/smitodm
2. Copy /usr/lib/objrepos/sm_* files from the known good machine into the new directory
3. Execute the following:
cd /home/june54/smitodm
ODMDIR="" smitty passwd
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
- Status
Similar threads
- Locked
- Question