alright, thx for advice i´ll try it

Am Mittwoch, 17. Dezember 2014 14:44:45 UTC+1 schrieb dan (ddpbsd):
>
> On Wed, Dec 17, 2014 at 8:20 AM, horst knete <[email protected] 
> <javascript:>> wrote: 
> > Recompiling on the same system would do the job, but in order to do that 
> i 
> > have to uninstall ossec and compile it from source again right? 
> > 
>
> No need to uninstall, do an "upgrade." 
>
> > Am Mittwoch, 17. Dezember 2014 14:13:42 UTC+1 schrieb dan (ddpbsd): 
> >> 
> >> On Wed, Dec 17, 2014 at 5:39 AM, horst knete <[email protected]> 
> wrote: 
> >> > 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. 
> >> > 
> >> 
> >> Do you need to install it to a new system, or would just recompile it 
> >> on the same system be ok? 
> >> 
> >> > 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. 
> > 
> > -- 
> > 
> > --- 
> > 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] <javascript:>. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 

--- 
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