Did you ever found an solution to this?

Im afraid i also have to reinstall our ossec server in order to increase 
the max_agents setting and absolutely dont want to connect to every of the 
200 agents, and restart or reauthentificate them.

Thanks

Am Donnerstag, 21. März 2013 19:29:07 UTC+1 schrieb Dustin Lenz:
>
> Hello Dan and all,
>
> I followed this procedure in an attempt to migrate OSSEC to new hardware 
> but it did not work.  I copied over client.keys, ossec.conf, 
> internal_options.conf, local_rules, and all the rids files as suggested but 
> received the agents could not connect to the new server afterward.  They 
> just sat there saying:
>
> 2013/03/21 13:52:28 ossec-agentd: INFO: Trying to connect to server (
>> 192.168.1.21:1514).
>> 2013/03/21 13:52:28 ossec-agentd: INFO: Using IPv4 for: 192.168.1.21 .
>
>
> The server had a couple interesting things to say:
>
> 2013/03/21 13:51:44 ossec-analysisd(1210): ERROR: Queue '/queue/alerts/ar' 
>>> not accessible: 'Connection refused'.
>>
>> 2013/03/21 13:51:44 ossec-analysisd(1301): ERROR: Unable to connect to 
>>> active response queue.
>>
>>
> The server also spit this out via email:
>
> Mar 21 13:55:17 ossec01 kernel: ossec-remoted[4520]: segfault at 7d1 ip 
>> 0000000000423078 sp 00007fff73f898e0 error 4 in ossec-remoted[400000+50000]
>>
>
>  Please let me know your thoughts.
>
> thanks,
>
> Dustin
>
>
> On Wednesday, June 27, 2012 6:23:10 AM UTC-7, dan (ddpbsd) wrote:
>>
>> On Wed, Jun 27, 2012 at 9:17 AM, anonymous <[email protected]> wrote: 
>> > Dan, 
>> > 
>> > Thanks for the breakdown and quick response. The server IP will 
>> definitely 
>> > change - since they're using centralized config all I'd need to do on 
>> the 
>> > agents is replace the <server> element in the agent's local ossec.conf 
>> > right? (for ease of migration I'm thinking I'll just create a new 
>> ossec.conf 
>> > containing the correct server IP and then drop it onto all of the 
>> agents). 
>> > 
>>
>> That should work. Again, I've never tried any of this. It's worked for 
>> others on the list though. 
>>
>> > Also, is it absolutely necessary to kill all of the processes on the 
>> agents 
>> > before the switch and then restart them after the switch? I think they 
>> have 
>> > 50 or 60 windows boxes and I'm trying to streamline if at all possible. 
>> > Would it be ok to just drop the ossec.conf file on the agents then 
>> after the 
>> > new server is up, restart the agent services? (theoretically this would 
>> make 
>> > them load the new ossec.conf and would save some time...) 
>> > 
>>
>> No idea. You could try it. If you do, let us know. :) 
>>
>> Stopping the processes is the best way to do it. Other ways may work, 
>> but I'd be afraid of rids issues. You could turn that off I guess, but 
>> it's not something I would want to try. 
>>
>> > Your continued response is sincerely appreciated! 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > -----Original Message----- From: dan (ddp) 
>> > Sent: Wednesday, June 27, 2012 6:32 AM 
>> > To: [email protected] 
>> > Subject: Re: [ossec-list] migrating ossec server - work involved? 
>> > 
>> > 
>> > On Wed, Jun 27, 2012 at 2:33 AM, Glenn Roberts <[email protected]> 
>> > wrote: 
>> >> 
>> >> Hello, 
>> >> 
>> >> My client wants to migrate the ossec manager server from a CentOS box 
>> to a 
>> >> different CentOS box on a different network. Is there an easy way to 
>> do 
>> >> this? I’ve setup ossec several times but am weary of migrating due to 
>> >> needing to re-authenticate all the agents and any other caveats I may 
>> not 
>> >> know of lol. Any suggestions, advice, previous experiences would be 
>> >> appreciated!! 
>> > 
>> > 
>> > Stop all of the OSSEC processes (agents and server). Install OSSEC on 
>> > the new server. Copy configuration files, including client.keys, to 
>> > the new server. Copy the rids files over (/var/ossec/queue/rids I 
>> > think) to the new server. 
>> > 
>> > On the agents you'll have to change the server-ip setting if the 
>> > server's IP changed (also check for this in the new server's 
>> > ossec.conf). If it hasn't changed, I don't think you'll have to do 
>> > anything. 
>> > 
>> > Start the OSSEC processes on the server. Then start the OSSEC 
>> > processes on the agents. Cross your fingers. ;) 
>> > 
>> > Make sure you backup everything you want to keep. This process 
>> > "should" work, but can't be guaranteed. 
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to