HIDS copy schedule from one server to another

[Anthony_141]

We loaded HIDS a few weeks ago and have a customer schedule we made.

We want to duplicate this schedule to another server running HIDS, but are having issues.

This thread below talks about directories (like
/var/opt/ids/gui/SurveillanceSchedules) that do not exist on our system:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=860677

Our schedules seem to live in /var/opt/ids/schdules but you can't copy the files there to the other server and have them seen by the other HIDS.

So, with the latest HIDS - how can I make a schedule on one server and import that same schedule on another server running HIDS?

[Pierre Pasturel]

Hi Anthony -

If you want to run the same schedule on a different agent host managed by the same HIDS admin GUI/CLUI, use the CLUI or GUI to activate the schedule on that other agent host.

You are encouraged to manage all schedules on the server running the *admin* GUI or CLUI. Starting with the latest HIDS release (v4.1), the Surveillance Schedules (managed by the *admin* GUI/CLUI) are saved in /etc/opt/ids/schedules/*.txt files and the Surveillance Groups are saved in /etc/opt/ids/schedules/groups/.txt.

Please refer to the following sections of the HIDS V4.1 Admin Guide:
http://docs.hp.com/en/5992-0705/ch05s01.html
http://docs.hp.com/en/5992-0705/apes01.html


The /var/opt/ids/schedule file contains the activated schedule on the server running the HIDS *agent* sensor. Never copy /var/opt/ids/schedule from an agent host into /etc/opt/ids/schedules on your admin host, as they are not compatible. The one on the agent host is in "expanded" form, while the one on the admin host is in "unexpanded" form (i.e., it refers to groups by name and the group contents are in separate files, allowing more than one schedule to refer to the same Surveillance Group).

Also note that the agent can also be configured to run on the admin host.

I'm assuming you are not trying to move/copy your schedules/groups from one admin host to another. That would involve a tar-ing up of files in /etc/opt/ids/schedules on one admin host and installing them on the other admin host in the same location. You must make sure to preserve the permissions and owner/group on the *.txt files.

Hope this helps.

Pierre

[Anthony_141]

We have 2 servers in a Serviceguard cluster and both were installed with admin+agent HIDS. So, both servers administer themselves and do not monitor anything else.

[Anthony_141]

If we did tar up /etc/opt/ids/schedules to copy it to the other system, should we have the schedule down first before we do the taring?

[Pierre Pasturel]

> If we did tar up /etc/opt/ids/schedules to copy it to the other system, should we have the schedule down first before we do the taring?

When populating /etc/opt/ids/schedules, you do not need to stop an activated schedule first. However, you do want to make sure that the HIDS Admin GUI is not running; otherwise, the GUI will write over some or all of your installed files.

Pierre

[Anthony_141]

I suspect after the copy and expanding the tar files we would need to stop and restart the schedule on the other host for the changes to take effect?

[Pierre Pasturel]

Yes, you would need to activate the new schedule in order for the agent to use it. The easiest way is to use the /opt/ids/bin/idsadmin --activate invocation from the command line (or do it from the idsadmin interactive menu). You can also use the GUI to activate the schedule. Although not generally recommended, you can copy /var/opt/ids/schedule from one agent to another and then send the HUP signal to the agent (see Admin Guide), but the admin GUI/CLUI won't be able to manage any "expanded" schedule that is manually placed in /var/opt/ids/schedule on an agent host.

Pierre

[Anthony_141]

Something is still not correct.

The schedule we want to copy is on server "B".

On "B", I stopped the schedule, stopped the agents, then CPIO'd the contents of /etc/opt/ids/schedules.

I sent that CPIO file over to "A".

On "A", I stopped the agent and the schedule.

I did:
1) mv /etc/opt/ids/schedules /etc/opt/ids/schedules.old (made backup copy of current schedule)
2) extracted the CPIO file from "B" into /etc/opt/ids/schedule.

I looked in /etc/opt/ids/schedule and it had the correct permissions and file ownership. It had the schedule from "B" (I could tell by the file size of our schedule).

However, when I start this schedule on "A", the file /var/opt/ids/schedule (the activated schedule) was the old size not the new size.

Shouldn't /var/opt/ids/schedule be the new size and also match the same size at that of "B" which is where it supposedly came from?

[Anthony_141]

I just went into the GUI again on "A" to see how it was doing, and I got the message that there was a parse error on our schedule. This is despite the fact that I "undid" all the prior changes (put back the original /etc/opt/ids/schedules).

[Anthony_141]

I reput the original schedule on "A" and now am not getting the parsing error.

So, near as I can tell, "A" is back to how it was before I tried copying our schedule from "B".

[Pierre Pasturel]

Hi Tony -
Use cksum or md5sum to make sure that you transferred the group files:

% cksum /etc/opt/ids/schedules/groups/*.txt
% cksum /etc/opt/ids/schedules/*.txt

The detection template properties reside in the group files.

Pierre

[Anthony_141]

cksum's showed a difference in one of the group files - I retarred and "recloned" and at the moment the /var/opt/ids/schedules are the same size.

I followed the same procedure as the first time (agents down, etc.) before taking the CPIO snapshot, so I'm not sure who they could have been different.

In any case, we can add the cksum checks to our procedures for next time.

[Anthony_141]

cksum's showed a difference in one of the group files - I retarred and "recloned" and at the moment the /var/opt/ids/schedules are the same size.

I followed the same procedure as the first time (agents down, etc.) before taking the CPIO snapshot, so I'm not sure how they could have been different.

In any case, we can add the cksum checks to our procedures for next time.

[Anthony_141]

Tar or CPIO files from /etc/opt/ids/schedules from one host to another. Run cksum commands to make sure all files are the same. Make sure all files and permissions are the same. Activate the schedule on the server.