Dell OpenManage Essentials

Last reply by 01-31-2022 Solved
Start a Discussion
2 Bronze
2 Bronze
2308

Creation of world writable log files

Hi,

I have a number of servers running CentOS 7 and the srvadmin suite seems to be creating world writable log files in /var/log.

-rw-rw-rw- 1 root root 525 Oct 21 17:42 storelibdebugit.txt.1
-rw-rw-rw- 1 root root 105 Oct 22 04:26 storelibdebugit.txt
-rw-rw-rw- 1 root root 570 Oct 22 04:26 storelibdebug.txt.1
-rw-rw-rw- 1 root root 124 Oct 22 04:26 storelibdebug.txt

We are running version 9.5.0-4063.16816.el7.x86_64 of various srvadmin* packages. We have other servers running older versions of srvadmin that we are not seeing this happen with.

Is there a configuration file somewhere where the creation of these files is prevented (or not created with these permissions)? Or something that can be set using omconfig?

Thanks.

Solution (1)

Accepted Solutions
2166

Hello markP,

 

Thank you for the information.

 

In the R410, two of the hard drives appear to be non Dell.

FRMW, Firmware for - Disk 2 in Backplane 0 of PERC 6/i Adapter Controller 0 in Slot 1 ( Version : 0103 )

FRMW, Firmware for - Disk 3 in Backplane 0 of PERC 6/i Adapter Controller 0 in Slot 1 ( Version : 0103 )

 

They may be the ones triggering the storelibdebug.

If you look in OMSA under storage do you see yellow triangle? This isn't necessarily a problem just a labeling of a non-Dell drive. You may even see not certified on the drive properties.

If you have the ability to pull those drives for test see if the messages continue.  Or you may try this to suppress the non certified indication :  https://dell.to/2YgLDzE

 

 

I notice the newer server R340 has OMSA 9.3 (older version than on the Older server R410 has OMSA 9.5)

If you are not having problems with newer server R340 I'd recommend leave it as is.

For the older server R410 try previous versions of OMSA and check results

Note: we have not validated or support CentOS and the R410 has only been validated up to RHEL6.

 

Try earlier versions of OMSA and check results:

 

Start with 9.2 and check results. If necessary then try 9.1.03 check results

 

OMSA v9.2.0 : https://dell.to/3waICNI

Patch v9.2.0.2 : https://dell.to/2YgLE6G

 

 

OMSA v9.1.03 : https://dell.to/3CUihpy

 


Dell -Charles R
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell

Did I answer your query? Please click on ‘Accept as Solution’. ‘Kudo’ the posts you like!

View solution in original post

Replies (9)
2274

Hello markP,

 

It looks like it could be from storage services.  Maybe being written by dsm_om_shrsvcd.

That is not a necessary service to run OMSA, it’s the Shared service.

 

Does it stop if you stop that service?

 

 


Dell -Charles R
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell

Did I answer your query? Please click on ‘Accept as Solution’. ‘Kudo’ the posts you like!

2 Bronze
2 Bronze
2252

Hi Charles,

Apologies for the delay in responding, been on a break from work for a couple of days.

 

I cannot see any reference to that shared service the command "srvadmin-services.sh status". would this be the correct place to look?

Thanks,

Mark

2273

Hello markP,

 

See if you have debug turned on and turn it off:

 

1) Locate the file /etc/srvadmin/sm/ini/stsvc.ini (OMSA 6.2 and older) or / opt / dell / srvadmin / etc / srvadmin-storage /stsvc.ini (OMSA 6.2 and newer)

 

2) Look for "Enable/disable dscomsm.log at startup of the systems management data manager."

 

3) Change from "Debug=On" to "Debug=Off"

 

4) Change"DebugLevels = 0,0,0,0,0,0,0,0,0,0" "

 

5) Restart OMSA Data Manager services:

Linux: Enter the command "/etc/init.d/dataeng restart"


Dell -Charles R
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell

Did I answer your query? Please click on ‘Accept as Solution’. ‘Kudo’ the posts you like!

2253

Hi Charles,

 

I checked the file in question and debug was already set to off. The debug levels were slightly different so I changed them to match what you've said. When restarting the services it still gets generated.

2 examples of what is put in below.

cat storelibdebugit.txt:


Fri Oct 29 17:12:17.233 2021 : 140319034402624: DiscoverCtrl: OSSpecificInit failed with rval:0x8002
Fri Oct 29 17:12:17.233 2021 : 140319034402624: InitLib: DiscoveryCtrl failed, retVal=0x8002
Fri Oct 29 17:12:18.497 2021 : 140318837217024: ProcessLibCommandIT: Library Init has not been done yet
Fri Oct 29 17:12:19.820 2021 : 140318863259392: ProcessLibCommandIT: Library Init has not been done yet

cat storelibdebug.txt
Fri Oct 29 17:12:19.800 2021 : 140318863259392: get_os_channel_target_lun: failed to open handle to device errno 0x2 devname /dev/sdkm
Fri Oct 29 17:12:19.801 2021 : 140318863259392: GetDeviceSCSIAddress: get_os_channel_target_lun dev_num 0x12a dev_name /dev/sdkm failed!! rval 0xffffffff
Fri Oct 29 17:12:19.801 2021 : 140318863259392: get_os_channel_target_lun: failed to open handle to device errno 0x2 devname /dev/sdkn
Fri Oct 29 17:12:19.801 2021 : 140318863259392: GetDeviceSCSIAddress: get_os_channel_target_lun dev_num 0x12b dev_name /dev/sdkn failed!! rval 0xffffffff

Could these indicative of an issue somewhere maybe with the raid config or the way the operating system has been built onto the disk?

2250

Hello markP,

 

 

I'll engage a Systems Management engineer to take a look.

Could you provide the following for a system that does work and a system that doesn't work :

 

 : System Model

 : OS and version

 : OMSA version

 : iDRAC , BIOS , PERC and HDD firmware version

 : What kind of drives are installed and are they Dell or non-Dell

 

 

Also on a system that is having the issue: was it working fine previously then started having the condition?

 If so what was done around that time?

 

Have you tried an uninstall, reboot, reinstall?

 


Dell -Charles R
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell

Did I answer your query? Please click on ‘Accept as Solution’. ‘Kudo’ the posts you like!

2194

Thanks Charles,

One of our systems that is exhibiting this behaviour is as below:

R410

BIOS, BIOS ( Version : 1.12.0 )
FRMW, Firmware for - Disk 0 in Backplane 0 of PERC 6/i Adapter Controller 0 in Slot 1 ( Version : S527 )
FRMW, Firmware for - Disk 1 in Backplane 0 of PERC 6/i Adapter Controller 0 in Slot 1 ( Version : S527 )
FRMW, Firmware for - Disk 2 in Backplane 0 of PERC 6/i Adapter Controller 0 in Slot 1 ( Version : 0103 )
FRMW, Firmware for - Disk 3 in Backplane 0 of PERC 6/i Adapter Controller 0 in Slot 1 ( Version : 0103 )
FRMW, PERC 6/i Adapter Controller 0 Firmware ( Version : 6.3.3.0002 )
FRMW, SAS/SATA Backplane 0:0 Backplane Firmware ( Version : 1.07 )
FRMW, iDRAC ( Version : 1.06.00.00 )

omreport - 9.5.0-4063.16816.el7.x86_64

Centos 7 - 3.10.0-1160.31.1.el7.x86_64

 

and one that isn't:

R340

[ ]2 PERC H730P Adapter Controller 0 Firmware
Current Version : 25.5.5.0005 Upgrade to : 25.5.9.0001, Criticality : Recommended, Type : Firmware

[ ]3 iDRAC
Current Version : 3.30.30.30 Upgrade to : 5.00.10.20, Criticality : Recommended, Type : Firmware

[ ]4 BIOS
Current Version : 1.2.0 Upgrade to : 2.6.3, Criticality : Urgent, Type : BIOS

[-]7 Firmware for - Disk 0 in Backplane 1 of PERC H730P Adapter Controller 0
Current Version : EE05 Same as : EE05, Criticality : Recommended, Type : Firmware

omreport:
9.3.0-3465.14818.el7.x86_64

Centos 7 - 3.10.0-1160.42.2.el7.x86_64

disks: pair of 300GB 15K sas drives (what came with the server from Dell)

 

Have checked another couple of servers showing this and they are also version 9.5.0-4063.16816.el7.x86_64 of the omreport packages

We haven't tried uninstalling and reinstalling. Do you think it's worth a try (or possibly something specific to 9.5.0-4063.16816.el7.x86_64)?

Nothing in particular has triggered the condition that i can tell, it's just that we've recently started more in depth security scans of our servers and flagged this as a vulnerability.

2167

Hello markP,

 

Thank you for the information.

 

In the R410, two of the hard drives appear to be non Dell.

FRMW, Firmware for - Disk 2 in Backplane 0 of PERC 6/i Adapter Controller 0 in Slot 1 ( Version : 0103 )

FRMW, Firmware for - Disk 3 in Backplane 0 of PERC 6/i Adapter Controller 0 in Slot 1 ( Version : 0103 )

 

They may be the ones triggering the storelibdebug.

If you look in OMSA under storage do you see yellow triangle? This isn't necessarily a problem just a labeling of a non-Dell drive. You may even see not certified on the drive properties.

If you have the ability to pull those drives for test see if the messages continue.  Or you may try this to suppress the non certified indication :  https://dell.to/2YgLDzE

 

 

I notice the newer server R340 has OMSA 9.3 (older version than on the Older server R410 has OMSA 9.5)

If you are not having problems with newer server R340 I'd recommend leave it as is.

For the older server R410 try previous versions of OMSA and check results

Note: we have not validated or support CentOS and the R410 has only been validated up to RHEL6.

 

Try earlier versions of OMSA and check results:

 

Start with 9.2 and check results. If necessary then try 9.1.03 check results

 

OMSA v9.2.0 : https://dell.to/3waICNI

Patch v9.2.0.2 : https://dell.to/2YgLE6G

 

 

OMSA v9.1.03 : https://dell.to/3CUihpy

 


Dell -Charles R
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell

Did I answer your query? Please click on ‘Accept as Solution’. ‘Kudo’ the posts you like!

2149

Hi Charles,

 

We don't use the GUI for OMSA at all so couldn't say what it's reporting. Having gone through a few of our servers it does seem to be only the ones on 9.5.xxxx that are reporting. I shall try running an older version to see if we're still seeing the issue.

Thanks for your help with this!

1692

Hi Charles,

Apologies for the delayed response. re-installing version 9.3 seems to have done the trick. Many thanks for your assistance.

 

Kind regards,

Mark

Latest Solutions
Top Contributor