Rookie 0 Posted April 6, 2017 Share Posted April 6, 2017 I've installed Agent 6.5 x86_64 version with shell script on my CentOS 6.8 systems. Installation proceeds fine (I tried both the server assisted with username/password and the offline with certificates), there are no errors during install, but the Agent never starts and registers with ERA Server. What I've noticed is that the files in /etc/init.d aren't created, so I cannot use service eraagent start (or stop, status etc) and the only way I can start Agent is if I run /opt/eset/RemoteAdministrator/Agent/ERAAgent --daemon --pidfile=/var/run/eraagent.pid from /etc/init/eraagent.conf Running initctl list gives me the following: eraagent stop/waiting Running initctl start eraagent gives me eraagent start/running, process 1705 , but rerunning initctl list afterwards shows the same eraagent stop/waiting Output from trace.log is the following 2017-04-06 13:31:28 Information: [Thread 7f73eaad9700]: Loading ESET modules from /var/opt/eset/RemoteAdministrator/Agent/Modules/ 2017-04-06 13:31:28 Error: Service [Thread 7f73eaad9700]: ReloadModules: LoadLoader failed with 5000 I would guess something is wrong with the installation script, but I am not bash expert to fix it so I can use the eraagent service in normal way with service <service_name> <start,stop,status> Tried it both on a dev system, and a completely clean CentOS 6.8 minimum install, please advise Link to comment Share on other sites More sharing options...
ESET Staff MartinK 375 Posted April 6, 2017 ESET Staff Share Posted April 6, 2017 It is normal that /etc/init.d file are not present -> AGENT uses upstart on CentOS 6 system. As you already found out, instead of service, command initctl should be used to control daemon lifecycle. This is different on ubuntu-based operating system, where service command is modified so that it can control both SysV and also upstart based daemons. Provided trace.log shows that there is something wrong and modules from directory /var/opt/eset/RemoteAdministrator/Agent/Modules/ cannot be loaded. Could you please check content of this directory? Multiple *.dat files are expected to be located there since installation. In case files will be present, I would recommend to temporarily disable SELinux on this system using command setenforce 0 and try to re-start eraagent daemon (or check for SELinux AVC revords in audit log prior). There is also possibility that modules are not able to load because of system configuration - any chance you are using temporary directory mounted with noexec parameter? Link to comment Share on other sites More sharing options...
Rookie 0 Posted April 6, 2017 Author Share Posted April 6, 2017 (edited) Hi Martin, Here is the content of the folder: total 9.1M drwxr-x--- 2 root root 4.0K Apr 6 12:48 . drwxr-x--- 5 root root 4.0K Apr 6 12:55 .. -rw-r----- 1 root root 68K Nov 4 07:46 em000_64.dat -rw-r----- 1 root root 877K May 28 2016 em001_64.dat -rw-r----- 1 root root 5.7M Feb 11 01:27 em017_64.dat -rw-r----- 1 root root 2.5M Feb 1 01:27 em039_64.dat SELinux is disabled on all of my servers This is an output from mount command mount /dev/vda2 on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) /dev/vda1 on /boot type ext2 (rw) /dev/vda8 on /home type ext4 (rw,nodev) /dev/vda6 on /tmp type ext4 (rw,noexec,nosuid,nodev) /dev/vda5 on /var type ext4 (rw) /dev/vda3 on /var/log type ext4 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) Seems like /tmp is mounted with noexec parameter, and workaround on that one? Also, why does the Agent starts when I manually run /opt/eset/RemoteAdministrator/Agent/ERAAgent --daemon --pidfile=/var/run/eraagent.pid ? Edited April 6, 2017 by Rookie Link to comment Share on other sites More sharing options...
ESET Staff MartinK 375 Posted April 6, 2017 ESET Staff Share Posted April 6, 2017 36 minutes ago, Rookie said: Seems like /tmp is mounted with noexec parameter, and workaround on that one? Also, why does the Agent starts when I manually run /opt/eset/RemoteAdministrator/Agent/ERAAgent --daemon --pidfile=/var/run/eraagent.pid ? In case /tmp cannot be used because of noexec, AGENT should use fallback location. Seems that it works fine when started by user account (I guess $HOME is used), but it does not work when started as daemon. If I recall correctly, there is also possibility to define alternative location for loading modules (instead of /tmp) using environment variables, but I will have to check tomorrow. What security products are you using on this machine? I would expect the same problem also with it... Link to comment Share on other sites More sharing options...
Rookie 0 Posted April 7, 2017 Author Share Posted April 7, 2017 So far none, but on those Linux servers we want to put File Security for Linux for which we have licenses Link to comment Share on other sites More sharing options...
ESET Staff MartinK 375 Posted April 7, 2017 ESET Staff Share Posted April 7, 2017 Seems that failing operation is performed either in directory /tmp or in directories specified by environment variables HOME or MODMAPDIR. At least one of directory from this list has to be mounted with "exec" support. Link to comment Share on other sites More sharing options...
Rookie 0 Posted April 7, 2017 Author Share Posted April 7, 2017 Well, changing options on /tmp is out of the question, since our environment comes from a configuration management, and I really don't want to have exec on /tmp. How can I set up those variables? I was running installation and both the service starting manually from root account Link to comment Share on other sites More sharing options...
ESET Staff MartinK 375 Posted April 7, 2017 ESET Staff Share Posted April 7, 2017 For quick test, modification of startup script (/etc/init/eraagent.conf) so that daemon is started with defined environment variable should be sufficient. For example adding: env MODMAPDIR=/var/opt/eset/RemoteAdministrator/Agent/ and restarting daemon should be sufficient. Any other directory with enabled exec attributes could be used. Link to comment Share on other sites More sharing options...
Rookie 0 Posted July 7, 2017 Author Share Posted July 7, 2017 thanks Martin, that helped me a lot. Link to comment Share on other sites More sharing options...
Recommended Posts