Agent system changed IP mid-scan

[GoogleCodeExporter]

I have a large file server that takes 2+ weeks to complete a full scan.  At 75% 
progress our operations guys shut it down, moved it to a new facility and 
allocated a new IP address.  I see that the scan service is still running and I 
don't want to lose the last two weeks of progress.  I want to check the status 
from the web administration interface but, of course, the OpenDLP server can't 
find the agent at its new IP.  How do I update the OpenDLP server's scan 
profile settings so it finds this server again at its new IP address?  Thanks.

Pierce

Original issue reported on code.google.com by xepier...@gmail.com on 14 Apr 2014 at 9:28

[GoogleCodeExporter]

You will have to go into the database and, for each table, change the old IP 
address to the new IP address. There is not a way to do this through the web 
interface.

Original comment by andrew.O...@gmail.com on 15 Apr 2014 at 1:48

[GoogleCodeExporter]

Thank you!  I'm not a SQL guru but I have at least managed to log into the 
query interface local to the server so I can list the tables and their fields.  
Could you please post the proper SQL statement to recursively go through all 
the tables and change one IP address to another IP address?  I'm very afraid of 
doing this wrong and perhaps this requires some knowledge of the database and 
significant tables to target.  Please help?

Original comment by xepier...@gmail.com on 15 Apr 2014 at 4:45

[GoogleCodeExporter]

mysql -u root -p YOURPASSWORD
use OpenDLP;
update systems set ip="new.ip.here" where ip = "old.ip.here";
quit;

Original comment by andrew.O...@gmail.com on 15 Apr 2014 at 4:59

[GoogleCodeExporter]

Thank you, that worked!  :)

Original comment by xepier...@gmail.com on 15 Apr 2014 at 6:37

[GoogleCodeExporter]

Oops, I spoke too soon.  So, the IP definitely updated in the scan profile but 
when I check the scan progress from the web interface it never updates.  I've 
tried restarting apache, mysql and even the whole opendlp server.  I've also 
stopped/started the agent scanning the fileserver.  No matter what, it's 
failing to update the opendlp server with the latest number of findings found, 
percent complete, etc.  Does the opendlp server have to change a local firewall 
setting or is there some other place were it specifies IPs it expects agent 
updates from?  

Original comment by xepier...@gmail.com on 15 Apr 2014 at 9:01

[GoogleCodeExporter]

Is this an agent or agentless scan? If it's agentless, is it Windows or UNIX?

Original comment by andrew.O...@gmail.com on 15 Apr 2014 at 9:33

[GoogleCodeExporter]

It's an agent-based scan on a Windows server.

Original comment by xepier...@gmail.com on 15 Apr 2014 at 10:13

[GoogleCodeExporter]

Perhaps the agent is trying to bind to a network interface that no longer 
exists?

Original comment by xepier...@gmail.com on 15 Apr 2014 at 10:14

[GoogleCodeExporter]

I'm thinking that the file server can't see the OpenDLP server from its new 
network location. I built some safeguards into OpenDLP for when client IP 
addresses changed (that's why I use a "tracking number" instead of IP 
addresses).

Can you go onto the file server and try to hit the OpenDLP's HTTPS server 
manually?

Original comment by andrew.O...@gmail.com on 16 Apr 2014 at 2:55

[GoogleCodeExporter]

So, we're definitely thinking the same way.  I actually asked that last 
question because I ran some manual tests from the browser local to the file 
server.  When I monitor those connection attempts from the firewalls, they are 
allowed but the browser does report that it could not reach the server.  Those 
are, however, the only attempts made by the file server to reach back to the 
OpenDLP server despite the fact that the agent is running.  So there are two 
problems:
1.  OpenDLP server is not responding to 443 requests from the fileserver at 
it's new location
2.  Fileserver agent doesn't appear be even attempting to communicate with the 
OpenDLP server (at least not any more).

Original comment by xepier...@gmail.com on 16 Apr 2014 at 8:47