Highlighted
Absent Member.
Absent Member.
559 views

Can I install a second smart connector on a linux VM cut?

Jump to solution

Recently installed a syslog smartconnetor on a linux VM cut and successfully sending data over to logger.  Now I am wondering if its possible to install another smart connector on the same VM cut or do I have to bring up a separate cut?  If it is possible, do I just rerun the arcsight bin file?   Thanks!

Labels (2)
0 Likes
1 Solution

Accepted Solutions
Highlighted

Mike,

My appology for being unclear on that point.

The 'bin' (linux), or for that matter the 'exe' (windows), is executed for each invididual SmartConnector that you wish to install and configure. The single 'bin' contains the entire framework and all device specific capabilites for the entire premium (ArcSight provided and supported) SmartConnector options list.

Each execution of the 'bin' will have the same identical first few screens, one being the installation location which will default per O/S type. When you are on this screen you will need to fully qualify the desired installation location for the specific SmartConnector that you are going to install during this execution, e.g. syslog, WUC,... , in the example path heirarchy I suggested, e.g. once you choose where you want things '/opt/..., '/etc/...',... Note that yo do not even have to use that type of heirarchy, there is nothing preventing you from installing one SmartConnector in /opt and another in /etc/home/WUC. In my first example  was just showing a 'suggested structure' to use to organize your installation.

Each installation will use the root path that you provide in the destination folder, note that at this level the SmartConnectors doesn't do any naming that would suggest anythig about the specific connector being installed, it cannot because you haven't gotten to selecting the actual connector yet. What each and every install will do is use your specified installation path and then place everything in ../current. This may seem somewhat 'curious' at first glance...

Over time you may find that you update a SmartConnector noe or more times. You could/would use the same specified path however you are not required to! One of the 'nice' things about estabishing the heirarchy early on is as you go through updates you can make a copy of 'current' in the same level of your specified path, note that installation documentation makes some mention of backing up your current installation as a method for rollback. The entire SmartConnector installation is 100% self contained, except for any 'services' installation, e.g. /etc/init.d/..., script, and therefore you could simply renate current to something, e.g. current -> syslog.5.1.2.3.4 where 5.1.2.3.4 is the version of the connector that you had been running and are updating. In this way you can later still run that instance of the SmartConnector is there is a need to 'rollback' or you could even simply rename the current 'current' and pt the older version back in current. Antoher benefit of this is that your properties, tunings, etc, over time are preserved and you could take them from an older verion and update the current 'current' version once the installation is complete.

Doing the above you have a 'history' of the specific connector over time, which of course you can prune or otherwise deal with using your own strategy for such updates over time.

You need not do as per the above however you may wish to institure some consistency and also ensure rollback capabilities. You can also consider that installation some dsort of 'bundle' and yes you could tar-ball it up, move it, make any specific host changes necessary, get the service in /etc/init.d taken care of and those 'move' connectors around as needed. One such example is you build up a VM 'cut' with multiple SmartCOnnectors and then later decide that you want a 1-VM to 1-SmartConnector, or visa-verse and use moving around as a convenience, or just as simply you could install from scratch.

Options, options, options!

So,...

Yes, use the same bin, over and over again...

Thank you,

Doug

View solution in original post

0 Likes
6 Replies
Highlighted

You may got either route.

If you find it easy, convenient and preferred to administer VM's and think of each VM as a specific SmartConnector then go this route. One major benefit of going this route would be if you wished to deploy more than one SmartConnector that bound a specific port, something that would limit the VM as well as a non-VM solution, such as UDP:514 for Syslog.

If alternatively you wish to run multiple, non-specific port contending, SmartConnectors then you may do so. In this case you would probably want to create some sort of folder heirarchy because each SmartConnector will install with the same folder structure below the root installation directory and you will need something to differentiate them. For example if you decided that /etc/home was your prefered 'root' folder location then you might wish to install the Syslog in /etc/home/smartconnectors/syslog to take the UDP:514 feeds then later you decided to collect windows events logs you might wish to install the Windows Unified Connector in /etc/home/smartconectors/windowsunified.

The amount of system resources required will vary with each SmartConnector. You may wish to think of each SmartConnector as ~ 1 CPU and 1GB of RAM for easy calculation however do not be surprised when CPU consumprion exceeds 1 CPU, particularly if you begin following other iRock threads and make configuration changes to increase performance and event rate processing.

For either case you would then use the same bin distribution.

Subsequent to an installation you may even find that you wish to run multiple of a specific SmartConnector and to do so you can do so on additional servers, VM or otherwise, for any number of reasons, e.g. specific loading is high and you wish to reduce per-SmartConnector event rate, you wish to deploy distributed SmartConnectors 'near' the event source, you wish to isolate traffic by 'business vertical' such as isolate PCI events due to scoping.

Thank you,

Doug

0 Likes
Highlighted
Absent Member.
Absent Member.

Doug,

Thanks for the info!

Assuming I am installing it on the same cut running the syslog smartconnector, would I just re-rerun the bin file to install the additional smart connector?  Or would I modify the current smart connector?  Thanks again!

0 Likes
Highlighted

Mike,

My appology for being unclear on that point.

The 'bin' (linux), or for that matter the 'exe' (windows), is executed for each invididual SmartConnector that you wish to install and configure. The single 'bin' contains the entire framework and all device specific capabilites for the entire premium (ArcSight provided and supported) SmartConnector options list.

Each execution of the 'bin' will have the same identical first few screens, one being the installation location which will default per O/S type. When you are on this screen you will need to fully qualify the desired installation location for the specific SmartConnector that you are going to install during this execution, e.g. syslog, WUC,... , in the example path heirarchy I suggested, e.g. once you choose where you want things '/opt/..., '/etc/...',... Note that yo do not even have to use that type of heirarchy, there is nothing preventing you from installing one SmartConnector in /opt and another in /etc/home/WUC. In my first example  was just showing a 'suggested structure' to use to organize your installation.

Each installation will use the root path that you provide in the destination folder, note that at this level the SmartConnectors doesn't do any naming that would suggest anythig about the specific connector being installed, it cannot because you haven't gotten to selecting the actual connector yet. What each and every install will do is use your specified installation path and then place everything in ../current. This may seem somewhat 'curious' at first glance...

Over time you may find that you update a SmartConnector noe or more times. You could/would use the same specified path however you are not required to! One of the 'nice' things about estabishing the heirarchy early on is as you go through updates you can make a copy of 'current' in the same level of your specified path, note that installation documentation makes some mention of backing up your current installation as a method for rollback. The entire SmartConnector installation is 100% self contained, except for any 'services' installation, e.g. /etc/init.d/..., script, and therefore you could simply renate current to something, e.g. current -> syslog.5.1.2.3.4 where 5.1.2.3.4 is the version of the connector that you had been running and are updating. In this way you can later still run that instance of the SmartConnector is there is a need to 'rollback' or you could even simply rename the current 'current' and pt the older version back in current. Antoher benefit of this is that your properties, tunings, etc, over time are preserved and you could take them from an older verion and update the current 'current' version once the installation is complete.

Doing the above you have a 'history' of the specific connector over time, which of course you can prune or otherwise deal with using your own strategy for such updates over time.

You need not do as per the above however you may wish to institure some consistency and also ensure rollback capabilities. You can also consider that installation some dsort of 'bundle' and yes you could tar-ball it up, move it, make any specific host changes necessary, get the service in /etc/init.d taken care of and those 'move' connectors around as needed. One such example is you build up a VM 'cut' with multiple SmartCOnnectors and then later decide that you want a 1-VM to 1-SmartConnector, or visa-verse and use moving around as a convenience, or just as simply you could install from scratch.

Options, options, options!

So,...

Yes, use the same bin, over and over again...

Thank you,

Doug

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

Doug,

Thanks for the help.  It seemed I had to stop the current syslog smartconnector service from running while I installed the additional service.  Looks like its up and running now!  Thanks again!

0 Likes
Highlighted

Mike,

Curious.

The multiple SmartCOnnectors are entirely unrelated, each in its own path.

If, however, you are trying to run two or more SmartConnectors of type syslog, specifically with each trying to bind UDP:514 (syslog default), then that would possibly be related as would you somehow naming them the same thing and also stepping on the /etc/init.d/

As I noted in first response they must be seperate and not compete for a specific unique resourse such as the listening port. i.e. in such a case then only one per server (VM) can be installed.

Did you install a second syslog connector?

Thank you,

Doug

0 Likes
Highlighted
Absent Member.
Absent Member.

Doug,

The two smart connectors are mutually exclusive (not two instances of syslog).  When trying to install the netflow smart connector, the system barked at me asking "Please stop the arcsight smartconnector and try again".  Only after stopping the curent syslog service would it let me install the additional service.  But yes i was able to get the smart connector installed and can see my EPS rise.  Thanks again!

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.