You have chosen to sponsor your bid up to a maximum amount of .
Custom Server Monitor / DynDNS Updater / FTP Backup I am looking for an intelligent software tool that sits on a dedicated webserver and is able to execute rule based DYNDNS requests for 1 - 100 sites. Essentially, the program will follow a ruleset to reroute server failures via a HTTPS/SSL/MD5 command to update a site's A or MX records, sync up FTP sites and securely update DNS servers to ensure maximum uptime of monitored sites. There are a number of programs out there already that do this, and open source code can be used, as this program is not for resale but will be used for commercial use. This program must work correctly upon delivery, be very well tested and most of all STABLE to run for long periods of time with no memory leaks. If you don't know how to return things to the heap or write solid code, please do not bid. I don't care what language you write in, provided it runs cleanly and doesnt overwhelm the resources of the machine. Stability is paramount and bug free operation is a must.
1. Run as a service under Windows 2003 server but also run under Windows XP.
2. Poll X (anywhere from 10 - ~100) sites via a port 80 request and search for expected text. Should also be able to "ping" a mailserver to establish connectivity as well. If web/mail server fails for a defined period of time (or polls), update appropriate DNS record.
3. If a site fails to connect, email server fails to respond, unusually high latency is detected, or expected text is not found, connect to DYNDNS server via HTTPS/SSL or MD5 and send updated X record. (A, MX, etc). Various DYNDNS services have different methods of updating, but most rely on a simple HTTPS command. There are over 100 DynDns services that should be able to be configured to work with this program, so it should be robust enough to ideally interpret (or simply be configured to detect) different success and failure messages and act accordingly. Many DYNDNS programs support HTTP updates but obviously, the program should connect via port 443 and not port 80 to establish the HTTPS connection. Each IP should be able to connect to a different DYNDNS service if need be.
4. Maintain a list of defined, prioritized IP addresses for each site. If IP1 fails, check for IP2's expected text and if found, send DynDNS request to change A record to Site 2's IP. Multiple backup IP addresses should be able to be defined for each site. Worst case, the dedicated machine would simply host the site via IIS. If IP1 returns to service and stays up for a configurable amount of time, then switch back to the "primary" IP address that hosts the site. In essence, it should default to the highest "live" priority site on the list for the given site. If IP1 is down and IP3 is hosting the site, then IP2 returns to service while IP1 is still down, update DNS record to reflect IP2's address. When IP1 becomes available, set DNS record to reflect IP1. If for some reason all IP records fail to return the appropriate information, send an email to a defined address for that site and optionally be able to run a program.
5. Should support sending global email updates to a configurable email address per site if a site is down for a defined period of time. This should be able to be turned off, and monitoring for any site should be hot toggleable without having to stop the monitoring. Emails should optionally be sent every X minute until site is restored, and optionally be sent when the site has been restored. The program should also be able to send an email to a definable address when the site is operating on the local server (e.g. all other options have failed).
6. Configureable times to run the server monitor should be able to be set. E.g. run through the list every X seconds. Skip monitoring of sites that are being ignored.
7. This application is designed to be run for months and months without reboots. Therefore, this program should not have any memory leaks, crash bugs, overflows, etc and should be able to recover from power off states, reboots, etc and resume automatically. If the program crashes, it should reload itself. Maximum uptime of this program is critical.
8. A fairly simple GUI is required to allow for configuration and monitoring. The GUI would show a green light for sites that are defined as up, grey for manually inactive, red for down and orange for (configurable amounts of) high latency. The GUI should show a basic bar graph of the last 3 - 5 polls for the given IP, the average latency of the last 10 - 20 polls, the last response provided by the server, and a status of remaining seconds left before it polls the server list. (Mockups of GUI layout will be provided).
9. The program must be able to login to each site's list of FTP servers and update all of the FTP sites defined for each individual site. For example, SITE-A may have 3 FTP sites associated with it that all should contain the exact same files. The program should be able to login to FTP1, update the files then close the connection, login to FTP2 and FTP3 and then move on to SITE-B, until finished. After trying to login several times, if a site still continues to update, it should send an email notifying which site failed to update. The program should be able to resume from lost connections where it left off and handle basic FTP errors without crashing.
Note: A local and remote default directory should be able to be defined for each IP address. In order to avoid having to upload large amounts of graphics, the program should check the remote FTP site first. If all of the files and file sizes matchup perfectly, then do nothing. If a file exists on the remote site but not on the local site, ignore it. If a file exists locally but not on the remote site, upload it. If the file exists locally and remotely, overwrite the remote file with a local copy unless the filesizes are exactly equal.
Certain local directories should be ignored from being uploaded and this should be configurable (cgi-bin, etc).
The option should exist to trigger the FTP batch sync at a certain configurable time. The program must also be able to manually initiate an FTP request to sync (upload to FTP server) 1 IP, 1 site, or all sites. Program should be able to manually (or chron controlled) upload local copy of defined website to all IP addresses associated with the given defined website to ensure that all sites contain the same files.
Other Requirements: Complete, stable, bug free and tested, compiled program code.
Full Source Code is required and will be inspected prior to payment.
Complete and Exclusive rights to all software code. To help prevent crashes and bloating, no logging code is required.
Software with Similar Features: A1Server Monitor DirectUpdate WS_FTP
Final Deliverables must include: 1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done.
2) Deliverables must be in ready-to-run condition, as follows (depending on the nature of the deliverables):
a) For web sites or other server-side deliverables intended to only ever exist in one place in the Buyer's environment--Deliverables must be installed by the Seller in ready-to-run condition in the Buyer's environment.
b) For all others including desktop software or software the buyer intends to distribute: A software installation package that will install the software in ready-to-run condition on the platform(s) specified in this bid request.
3) All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc).
Windows Server 2003 (as a service), Windows XP