SpectroServer on CentOS fails to start

[John OMahony]

Hi

I’ve just completed a test Spectrum install on CentOS Linux release 7.4.1708 (Core), however I get the following in VNM.OUT when I try to start the SpectroServer up.

ERROR: 

  The /var/opt/spectrum/SS/SpectroSERVER executable has the wrong file permissions.

 

  The /var/opt/spectrum/SS/SpectroSERVER process must start with the Effective User Id of ROOT.

  The owner of the /var/opt/spectrum/SS/SpectroSERVER executable should be ROOT and the Set User 

  Id Bit should be set. 

 

  The commands: chown root /var/opt/spectrum/SS/SpectroSERVER ; chmod u+s /var/opt/spectrum/SS/SpectroSERVER ;

  issued by ROOT will accomplish this.

 

For info I am starting using cmdC and have also tried startSS.pl

The SpectroServer executable looked good to me (owned by root with setuid bit set)…

[specadmin@spectrum-01 spectrum]$ ls -l SS/SpectroSERVER 

-rwsr-x---. 1 root specadmin 12841 Oct  3 13:15 SS/SpectroSERVER

[specadmin@spectrum-01 spectrum]$ 

 

However I ran the commands listed above anyway, but still get the same error.

I am pretty sure I have all the required libraries (but open to checking anythng anyone feels relevant). 

 

Anyone seen anything like this before?

Regards, John

[Edward Royston]

Is SELinux blocking it at all?

[John OMahony]

Hi Ed

Thanks for your suggestion. However I have just disabled SELinux, rebooted, and still have the same problem.

 

John

[Robert Kettles]

Permissions look good.  This is what it look like on my CentOS install:

 

[spectrum@speclinux SS]$ ls -la SpectroSERVER
-rwsr-x---. 1 root spectrum 14191 May  8 13:32 SpectroSERVER

 

You can try ldd SpectroSERVER to see if libraries are missing:

[spectrum@speclinux SS]$ ldd SpectroSERVER
    linux-vdso.so.1 =>  (0x00007ffeccfa6000)
    libmts64.so => /opt/SPECTRUM/lib/libmts64.so (0x00007f99dc1dc000)
    libsskrnl.so.1 => /opt/SPECTRUM/lib/../SS/libsskrnl.so.1 (0x00007f99dbda5000)
    libmoot.so.1 => /opt/SPECTRUM/lib/libmoot.so.1 (0x00007f99dbb8c000)
    libmdlsvutil.so.1 => /opt/SPECTRUM/lib/../SS/libmdlsvutil.so.1 (0x00007f99db95e000)
    libadcor.so.1 => /opt/SPECTRUM/lib/../SS/libadcor.so.1 (0x00007f99db688000)
    libgmmad.so.1 => /opt/SPECTRUM/lib/../SS/libgmmad.so.1 (0x00007f99db463000)
    libvlanfi.so.1 => /opt/SPECTRUM/lib/../SS/libvlanfi.so.1 (0x00007f99db224000)
    libvlanapi.so.1 => /opt/SPECTRUM/lib/libvlanapi.so.1 (0x00007f99db01c000)
    libIHapi.so.1 => /opt/SPECTRUM/lib/../SS/libIHapi.so.1 (0x00007f99dadd9000)
    libadisc.so.1 => /opt/SPECTRUM/lib/../SS/libadisc.so.1 (0x00007f99dab76000)
    libIfDisc.so.1 => /opt/SPECTRUM/lib/libIfDisc.so.1 (0x00007f99da96b000)
    libsv1mm.so.1 => /opt/SPECTRUM/lib/../SS/libsv1mm.so.1 (0x00007f99da727000)
    libicmp.so.1 => /opt/SPECTRUM/lib/../SS/libicmp.so.1 (0x00007f99da505000)
    libicmpserv.so.1 => /opt/SPECTRUM/lib/../SS/libicmpserv.so.1 (0x00007f99da2fc000)
    libmdlsvint.so.1 => /opt/SPECTRUM/lib/../SS/libmdlsvint.so.1 (0x00007f99d9e52000)
    libplcy.so.1 => /opt/SPECTRUM/lib/../SS/libplcy.so.1 (0x00007f99d9be5000)
    libssmm.so.1 => /opt/SPECTRUM/lib/../SS/libssmm.so.1 (0x00007f99d99b5000)
    libitc.so.1 => /opt/SPECTRUM/lib/libitc.so.1 (0x00007f99d97a1000)
    libpif.so.1 => /opt/SPECTRUM/lib/../SS/libpif.so.1 (0x00007f99d959a000)
    libgas.so.1 => /opt/SPECTRUM/lib/../SS/libgas.so.1 (0x00007f99d9300000)
    libems.so.1 => /opt/SPECTRUM/lib/../SS/libems.so.1 (0x00007f99d8fd0000)
    libalert.so.1 => /opt/SPECTRUM/lib/../SS/libalert.so.1 (0x00007f99d8d7d000)
    libdcm.so.1 => /opt/SPECTRUM/lib/../SS/libdcm.so.1 (0x00007f99d8b4d000)
    libmftypes.so.1 => /opt/SPECTRUM/lib/../SS/libmftypes.so.1 (0x00007f99d8908000)
    libPTTGlobal.so.1 => /opt/SPECTRUM/lib/libPTTGlobal.so.1 (0x00007f99d86f5000)
    libssorb.so.1 => /opt/SPECTRUM/lib/libssorb.so.1 (0x00007f99d83a6000)
    libssorbutil.so.1 => /opt/SPECTRUM/lib/libssorbutil.so.1 (0x00007f99d816f000)
    libssorbconvert.so.1 => /opt/SPECTRUM/lib/libssorbconvert.so.1 (0x00007f99d7f42000)
    libxparse.so.1 => /opt/SPECTRUM/lib/libxparse.so.1 (0x00007f99d7d0c000)
    libEaccsBase.so.1 => /opt/SPECTRUM/lib/../SS/libEaccsBase.so.1 (0x00007f99d7aff000)
    libProcedure.so.1 => /opt/SPECTRUM/lib/../SS/libProcedure.so.1 (0x00007f99d7839000)
    libgserv.so.1 => /opt/SPECTRUM/lib/libgserv.so.1 (0x00007f99d7544000)
    libwkmgr.so.1 => /opt/SPECTRUM/lib/libwkmgr.so.1 (0x00007f99d733b000)
    libcomm.so.1 => /opt/SPECTRUM/lib/libcomm.so.1 (0x00007f99d7124000)
    libssdbl.so.1 => /opt/SPECTRUM/lib/libssdbl.so.1 (0x00007f99d6db0000)
    libgag.so.1 => /opt/SPECTRUM/lib/../SS/libgag.so.1 (0x00007f99d6b85000)
    libsdmcor.so.1 => /opt/SPECTRUM/lib/libsdmcor.so.1 (0x00007f99d696f000)
    libSWcli.so.1 => /opt/SPECTRUM/lib/libSWcli.so.1 (0x00007f99d6746000)
    libhpse.so.1 => /opt/SPECTRUM/lib/../SS/libhpse.so.1 (0x00007f99d6491000)
    libsdmcasdm.so.1 => /opt/SPECTRUM/lib/../SS/libsdmcasdm.so.1 (0x00007f99d6245000)
    libxml2.so.2 => /opt/SPECTRUM/lib/../SS/libxml2.so.2 (0x00007f99d5ef7000)
    libdbutl.so.1 => /opt/SPECTRUM/lib/libdbutl.so.1 (0x00007f99d5cf0000)
    libUIgen.so.1 => /opt/SPECTRUM/lib/libUIgen.so.1 (0x00007f99d5acb000)
    libEpapi_ss.so.1 => /opt/SPECTRUM/lib/../SS/libEpapi_ss.so.1 (0x00007f99d588e000)
    libgmmintel.so.1 => /opt/SPECTRUM/lib/../SS/libgmmintel.so.1 (0x00007f99d55fd000)
    libgmm.so.1 => /opt/SPECTRUM/lib/libgmm.so.1 (0x00007f99d53f7000)
    libVPapi.so.1 => /opt/SPECTRUM/lib/libVPapi.so.1 (0x00007f99d5046000)
    libSpectrumVersion.so.1 => /opt/SPECTRUM/lib/libSpectrumVersion.so.1 (0x00007f99d4e43000)
    libGlobl.so.1 => /opt/SPECTRUM/lib/libGlobl.so.1 (0x00007f99d4b62000)
    libWrappers.so.1 => /opt/SPECTRUM/lib/libWrappers.so.1 (0x00007f99d494b000)
    libPort.so.1 => /opt/SPECTRUM/lib/libPort.so.1 (0x00007f99d4746000)
    libicutu.so.44 => /opt/SPECTRUM/lib/libicutu.so.44 (0x00007f99d44f4000)
    libicuio.so.44 => /opt/SPECTRUM/lib/libicuio.so.44 (0x00007f99d42e5000)
    libicui18n.so.44 => /opt/SPECTRUM/lib/libicui18n.so.44 (0x00007f99d3eb8000)
    libiculx.so.44 => /opt/SPECTRUM/lib/libiculx.so.44 (0x00007f99d3ca8000)
    libicule.so.44 => /opt/SPECTRUM/lib/libicule.so.44 (0x00007f99d3a67000)
    libicuuc.so.44 => /opt/SPECTRUM/lib/libicuuc.so.44 (0x00007f99d36da000)
    libicudata.so.44 => /opt/SPECTRUM/lib/libicudata.so.44 (0x00007f99d269a000)
    libz.so.1 => /opt/SPECTRUM/lib/libz.so.1 (0x00007f99d2483000)
    libcosnm64_r.so => /opt/SPECTRUM/lib/libcosnm64_r.so (0x00007f99d2244000)
    liborbcore64_r.so.8.0 => /opt/SPECTRUM/lib/liborbcore64_r.so.8.0 (0x00007f99d199a000)
    libvport64_r.so => /opt/SPECTRUM/lib/libvport64_r.so (0x00007f99d1744000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000031b5000000)
    librt.so.1 => /lib64/librt.so.1 (0x00000031b5400000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000031c0400000)
    libm.so.6 => /lib64/libm.so.6 (0x00000031b5c00000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000031bf800000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000031b4c00000)
    libc.so.6 => /lib64/libc.so.6 (0x00000031b4800000)
    /lib64/ld-linux-x86-64.so.2 (0x00000031b4400000)
    libpcre.so.1 => /opt/SPECTRUM/lib/libpcre.so.1 (0x00007f99d14fc000)
    libPTTClient.so.1 => /opt/SPECTRUM/lib/libPTTClient.so.1 (0x00007f99d12ed000)
    libvdlog64_r.so => /opt/SPECTRUM/lib/libvdlog64_r.so (0x00007f99d10c6000)
    liblmgr64.so => /opt/SPECTRUM/lib/liblmgr64.so (0x00007f99d0e3d000)
    libIsol.so.1 => /opt/SPECTRUM/lib/libIsol.so.1 (0x00007f99d0c38000)
    libcom.so.1 => /opt/SPECTRUM/lib/libcom.so.1 (0x00007f99d0a22000)

[John OMahony]

Hi Robert

I've done that and afraid it looks exactly the same as yours 

 

John

[Edward Royston]

John,

 

I have just upgraded one of my Spectrum CentOS VMs (albeit from 7.3 to 7.4). I also have another VM based on the same image. Both don't have the issues that you are indicating.

 

Can you start up the SCP?

 

Also, cross-check the actual filesystem privileges just in case it may have started up in RO mode. I have seen that happen elsewhere (albeit not with Spectrum) when disk space runs out and so things start only coming up upon bootup in RO mode. This is easily done by running a "mount” and checking the filesystem permissions in the brackets.

 

Regards,

Ed

[John OMahony]

Hi Ed

I did as you suggested using mount and looks like you may have led me to the issue ... this shows the partition has been mounted with nosuid 

 

/dev/mapper/local-var on /var type ext4 (rw,nosuid,relatime,data=ordered)

 

If you have some idea how to undo that I would be happy to hear any suggestions. Otherwise I will chase a sys admin in the morning.

 

Thanks for your help :-)

 

John

[Robert Kettles]

You'll need to edit your /etc/fstab and remove the nosuid option from the /dev/mapper/local-var entry and then reboot:

 

A complete fstab guide - Linux Stall 

 

You could potentially unmount /var and remount without reboot but I suggest doing this via reboot since I'm sure you'll have a number of files open on /var (syslog messages for starters) and you won't be able to unmount without having those files closed first.  Typically, systems will have file systems like /tmp or /var set to nosuid (and noexec) for security reasons so depending on your security policy, you may need to move Spectrum to a different partition.

[Edward Royston]

John,

 

Actually, to get rid of that nosuid you can do it from the command line in one hit without a reboot. However, you will need root privileges to do so….

 

mount -o remount,suid /var

 

That way you don't need to reboot to get things applied. Also, if this is non-production then I would probably shut things down first to make sure.

 

I would also suggest, as Rob mentions, to edit the /etc/fstab and remove the nosuid option. This will make the change permanent between reboots.

 

Just checked on my CentOS 7.4 VM, it looks like:

• I am not using LVM partitions
• All my mount points are set to defaults
• Strangely enough I am using XFS! Thought I had set this up initially as ext4. I must have just done a "standard VMware build” on it and ended up with the CentOS defaults.
  • /dev/sda3 on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
• I would not suggest that you copy these filesystem permissions - they are an example - however, Spectrum does work with them AND I am running SELinux in Enforcing mode.

 

Regards,

Ed

 

[Christophe_Sperandio]

You can "trace" the command to see where it fails. We do agree you try to run the SpectroSERVER with the Spectrum Admin User? Does it start if you run processd.pl with SS.idb setting autobootstart=Y ?

[John OMahony]

Thanks to EdRoyston for leading me to the solution  and to ketro01 for your help 

 

John

[Dan White]

... And I guess you've only run into this annoying nosetuid flag hassle(!) because your  $SPECROOT happens to be in the /var partition?

Because the rest of us have luckily chosen  /usr or some other more 'standard' location for running the program from that Linux doesn't need to protect so well against setuid malware etc?

-Dan.