I have seen some of the FTP posts, but none seem to be quite what I'm looking for. I want to be able to query the McAfee FTP/HTTP DAT sites to see if there is a newer DAT available. Only query, nothing else.
The FTPGet() UDF actually retrieves the file, plus you need to know the name of the file to get. I would only know that the file will be something like "dat-XXXX.zip". Where XXXX is the DAT version. To determine whether it is newer I plan on comparing that to the DAT I currently have to see if it's newer.
I was looking at the OS built in FTP, but it seems a bit cumbersome and I don't know if that FTP can return the exist or not exist to Kix.
This could also be done using McAfee's HTTP site, but I'm not sure how that would be done either. I've toyed with the wget program, but again that will retrieve the file, which I don't want to do.
Would it be easier if I just retrieved the file to a temp location and then do the compare? Or if anyone knows of a way to query without the retrieve I would greatly appreciate it.
Well FTP does not support an If Exist contruct directly. You might be able to do some listing to a temporary file and then parse the temporary file though.
Here is something that works well on the Symantec site which I'm sure could be modified to work on McAfee's site if wanted.
Thanks for the posts. I think what I'm going to end up doing is using the FTPGet() UDF and picking up the delta.ini file that Shawn recommended. Then I'll do my compare. This process is only going to be used for notification and not the actual download.
Thanks for the replies. And I see Shawn already replied with the FTPGet code that I will need.
PS - I read a post about the FTPGet() showing up as VBS/Psyme (Trojan) and the auto-email from the boards I got at work was picked up by McAfee. Sure enough it was tossed into the quarantine. Heh, oh well.
No size or date check needed for Symantec as they update every day - if wanted there is even one that is updated hourly but I think that's a bit overkill.
Registered: 2000-09-15
Posts: 5809
Loc: Harrisburg, PA USA
Well I see in one of the post above he mentions notification. But why? Does he not have ePO running on a schedule to update the DATs? Avert sends out new DAT notifications...
The notification I was talking about was an email that gets sent to my team. The script runs at 7am everyday to let us know that ePO has the latest DAT. It's a quick and easy way for those in my team that aren't as familiar with ePO to know if there is an issue with the DATs or not.
Putting the why question aside. I do have a problem with the script. Here is my FTPGet command. Code:
When I check the C:\delta.ini file, it is not the current file. I browse to that location with IE and grab the file and it is the latest version. Here is the example of the contents of the delta.ini file. I'll give what FTPGet gives me and what browsing manually gives.
FTPGet Version [Contents] LatestIncremental=621 Created=Mon Jan 2 04:40:00 2006 CurrentVersion=4665
Manually browsing via IE Version [Contents] LatestIncremental=626 Created=Mon Jan 9 04:40:00 2006 CurrentVersion=4670
Am I doing something wrong with the FTPGet command?
I think (personally) that you are running into IE cache issues, here is a snippet of knowledge base:
Microsoft Internet Explorer Cache issues
Internet Explorer implements caching for GET requests. Authors who are not familiar with HTTP caching expect GET requests not to be cached, or for the cache to be avoided as with the refresh button. In some situations, failing to circumvent caching is a bug. One solution to this is using POST request method, which is never cached, but is intended for non-idempotent operations. A solution using the GET request method is to include a unique querystring with each call, as shown in the example below.
Alternatively, force the XMLHTTPRequest object to retrieve the content anyway by including this in the request:
req.open("GET", "xmlprovider.php"); req.setRequestHeader("If-Modified-Since", "Sat, 1 Jan 2000 00:00:00 GMT"); req.send(null);
The source link for above is here. Thinking maybe you could try this "GET request" work-around I highlighted in the first paragraph. Studying this more closely myself.