Jump to content

Archived

This topic is now archived and is closed to further replies.

Mike

CentOS VM Deployment of ERAv6 on Hyper-V

Recommended Posts

Hi,

 

I was trying to install ERA v6 on an SBS2008 server and had a few issues, so I abandoned that route completely, and decided to use the supplied VM file to install the CentOS based system VM into Hyper-V (running on Server 2012R2).

 

I kept failing to get the system to deploy and I incorrectly thought it must be incorrect values in the OVF config files, so in the end I ran the OVF config using the barest minimum to get it working (just the new password and en-NZ as locale - everything else as default). Turns out the problem was actually caused by an external network problem in Hyper-V (which I fixed elsewhere), so my fancy config file probably would have worked if I'd realised in time.

 

I have now tried to re-edit my OVF config file to gain domain membership and AD groups. That doesn't appear to be working, and the name of the era server doesn't appear to be updating either. This leads me to believe that the OVF file is only being used on the first boot-up / configuration only, and is then ignored after that? Is that correct?

 

Is there a way to get the OVF file to be re-read to update the settings on the installation, or do I pretty much have to start again with the conversion of the VM file into the right format? The docs aren't very clear if the OVF file is a one-hit thing, or a means of re-configuring the system in the future.

 

I am also seeing errors about locale of server and setup being different, so I wonder if en-NZ is actually a supported location for the OVF anyway! If I need to re-deploy, I would want to get the correct value in that box next time.

 

I also have a few questions around updating of CentOS and ERA, but I'll leave those until I get the configuration correct!

 

The whole experience has made me concerned about the viability of using the supplied VM anyway, and wondering if I shouldn't just install ERA myself on-top of a copy of Windows Server 2012 / R2 (i.e a different box than my SBS install). It has been a VERY steep learning curve compared to ERAv5 which just worked. (I note other are equally frustrated with ERAv6, so glad it isn't just me finding problems - I'm normally good with new technology!)

 

Thanks in advance for your help,

 

Mike

Share this post


Link to post
Share on other sites

if it helps, I'm using VMs. Forget the CentOs VM if you're happier in a Windows environment (as I am). I have one Hyper-V already for SQL2014 so I've installed a second VM for ERA, and I'm supporting 160+ clients from it. It's working very well.

 

Jim

Share this post


Link to post
Share on other sites

Yeah, we only have about 30 clients here, so running a dedicated CentOS VM is possibly overkill anyway.

 

Ironically, the reason I jumped to the pre-made CentOS VM in the first place was because of problems getting it working on SBS2008 (which eventually ESET support have resolved anyway - but after I'd already removed it from that machine!).

 

The reason I persisted with the CentOS VM despite my initial problems, was that I decided that SBS2008 was probably the wrong place for it, even though ERAv5 had been happily running on that machine for several years. I think that dropping it onto a different Windows Server instance would make sense though.

 

I'm OK with Linux, although Nano was a bit of a pain (compared to other simple command line text editors).

 

We have a separate apps server which gets pretty low usage too, so I might use that machine for the task. I was planning to upgrade that machine to Server 2012 R2 and virtualise it in the near future, so utting it on that box would work. Save having extra cpu & memory overheads for another virtual machine & OS. It is also one less OS to manage and keep up to date!

Share this post


Link to post
Share on other sites

The appliance configuration is done only once after first reboot. It can't be reconfigured afterwards.

 

These are supported locales: ar-EG, cs-CZ, de-DE, en-US, es-CL, es-ES, fr-CA, fr-FR, hr-HR, it-IT, ja-JP, ko-KR, pl-PL, pt-BR, ru-RU, sk-SK, zh-CN, zh-TW

Share this post


Link to post
Share on other sites

@michalp

 

Thanks for the info. They are the conclusions I was coming to, but couldn't find in the documentation to prove either one.

 

If there was a way to re-run the startup wizard routine, that might be useful to reimport the settings from a changed OVF file.

 

It would also be great if these permitted locales were listed in the config help document for that OVF file.

 

Thanks

 

Mike

Share this post


Link to post
Share on other sites

I have been struggling to get rogue computer detection working with the ERA v6 virtual appliance on Hyper-V. I have been looking at the logs in /var/log/eset/RogueDetectionSensor/trace.log to try and figure it out.
 
The first problem was a lot of errors similar to this:
 
 

2015-07-03 09:34:27 Trace: OSDetector: 10.0.0.182 [Thread 7f0460dfa700]: Port number: 139 is closed. Failed with error: Permission denied. System error code: 13
2015-07-03 09:34:27 Trace: OSDetector: 10.0.0.182 [Thread 7f0460dfa700]: Port number: 22 is closed. Failed with error: Permission denied. System error code: 13

 
That looked like an SELINUX problem. The SELINUX violations are logged in /var/log/audit/audit.log:
 
 

type=AVC msg=audit(1435917536.372:13): avc:  denied  { getopt } for  pid=1454 comm="RDSensor" laddr=10.0.0.8 lport=54633 faddr=10.0.0.182 fport=139 scontext=system_u:system_r:rdsensor_t:s0 tcontext=system_u:system_r:rdsensor_t:s0 tclass=tcp_socket

 

I tried reinstalling the RDSensor by logging into a terminal as root and running eset_installers/RDSensor.sh. That reinstalled (and restarted) RDSensor along with its SELINUX policies, but it didn't seem to help.
 
To get rid of the "Permission denied" errors, I had to disable SELINUX by editing /etc/selinux/config and changing it to "permissive" mode and then reboot the system. ("permissive" mode still logs the SELINUX violations in /var/log/audit/audit.log, but ignores the violations.)
 
Unfortunately, the rogue computer detection still does not work. Here is an example of it attempting to scan a Windows 7 machine:
  

2015-07-03 09:59:04 Trace: PC Detection [Thread 7f0df1009700]: Computer with IPv4: 10.0.0.181
2015-07-03 09:59:44 Trace: CNetStat [Thread 7f0de21fc700]: Computer with IP: 10.0.0.181 has Netbios computer name W7-DAVE
2015-07-03 09:59:44 Trace: CNetStat [Thread 7f0de21fc700]: ip with: 10.0.0.181 resolved to: W7-DAVE.redacted.domain
2015-07-03 09:59:45 Trace: CNMapOSDetect [Thread 7f0de21fc700]: Starting OS detection on IP : 10.0.0.181
2015-07-03 09:59:45 Trace: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Port number: 139 is opened
2015-07-03 09:59:45 Information: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probes and waiting for responses
2015-07-03 09:59:45 Trace: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Using adapter: eth0
2015-07-03 09:59:45 Trace: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Filter Compile string is: "ip src host 10.0.0.181"
2015-07-03 09:59:45 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 0
2015-07-03 09:59:45 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 1
2015-07-03 09:59:45 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 2
2015-07-03 09:59:45 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 3
2015-07-03 09:59:45 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 4
2015-07-03 09:59:46 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 5
2015-07-03 09:59:46 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 6
2015-07-03 09:59:46 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 7
2015-07-03 09:59:46 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 8
2015-07-03 09:59:46 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 9
2015-07-03 09:59:46 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 10
2015-07-03 09:59:46 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Sending probe id: 11
2015-07-03 09:59:46 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Catching replies
2015-07-03 09:59:51 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: Time is up!
2015-07-03 09:59:51 Debug: OSDetector: 10.0.0.181 [Thread 7f0de21fc700]: 0 returned probes out of 12
2015-07-03 09:59:51 Warning: CInfoWorker [Thread 7f0de21fc700]: Info Worker warning: OS Detection on 10.0.0.181 failed: Not enough probes returned

2015-07-03 09:59:51 Trace: Basic Filter [Thread 7f0de21fc700]: Canceling machine: 10.0.0.181
2015-07-03 09:59:53 Trace: Basic Filter [Thread 7f0df1009700]: 10.0.0.181:Machine is not known. Not Filtered

I had the same problem with the failed OS detection probes when I tried a component installation of ERA v6 on an Ubuntu 14.04 server also running on Hyper-V.

Share this post


Link to post
Share on other sites

It would also be great if these permitted locales were listed in the config help document for that OVF file.

 

I also tried using an unsupported locale (en-GB in my case) the first time I installed the appliance, so having them documented would be good.

 

Here are a couple of other things I found useful:

 

  1. If installed under Hyper-V, run:

    yum install hyperv-daemons

    to make keyboard input behave properly in the Hyper-V RDP session to the Linux text console. Otherwise it's a bit random whether a character typed on the keyboard gets seen by the Linux kernel. (This seems to be a problem with Linux on Hyper-V in general - it's even worse on systems where there is no feedback when typing a password!)

  2. Set the time-zone to make the date and time strings in the logs more relevant to your location. This is controlled by the /etc/localtime file, which can be a copy of, or a symlink to, one of the time-zone files in /usr/share/zoneinfo. In my case, I used a symlink to the Europe/London time-zone file as follows: 

    ln -snf /usr/share/zoneinfo/Europe/London /etc/localtime

    There is also a time-zone name stored in the /etc/sysconfig/clock file on the line beginning "ZONE=". I edited that to use the same time-zone name. (I think it is used by CentOS's "system-config-date" utility, which isn't installed by default in the ERA applliance, but can be installed using yum. It has quite a few dependencies though, so probably not worth it.)

Share this post


Link to post
Share on other sites

Do you have "Enable mac address spoofing" enabled on the virtual machine where RD Sensor is running?

Share this post


Link to post
Share on other sites

Do you have "Enable mac address spoofing" enabled on the virtual machine where RD Sensor is running?

 

Thanks for the clue! Enabling mac address spoofing makes a difference. I have a VM running the CentOS ERA v6 server appliance and another VM running Ubuntu 14.04 with a component installation of ERA. I have turned on Mac Address Spoofing on both. The trace.log on both VMs now shows 9 probes out of 12 returning for a typical Windows 7 desktop machine, or 8 out of 12 for a Linux Samba server, and the machines are now showing up as rogue computers on the ERA web interface.

 

Thanks again for your help! (Now I just need to work out what to do with them!)

 

For the curious, mac address spoofing can be enabled on the VM under Hyper-V using this PowerShell command:

 

Set-VMNetworkAdapter -VMName MyVM -MacAddressSpoofing On

Share this post


Link to post
Share on other sites

Thanks again for your help! (Now I just need to work out what to do with them!)

You can deploy agent on those machines so that you can send a software install task to them to install Endpoint. Agent on particular computers will also move them to the appropriate dynamic group based on the criteria you specify for dynamic groups.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...