Managed VPS hosting services from Star Dot Hosting

Click here for a free quote for managed vps hosting!


I thought I’d update our blog to let everyone know that we offer our extensive managed services catalog on our VPS infrastructure!

If you are looking for high quality managed services from systems administrators with extensive experience, then contact our sales department for a consultation / quotation!

Find below just a SAMPLE of some of the managed services we provide :

Support Services
– 24/7/365 Technical Support (Ticketing system)
– 24/7/365 Alert monitoring on-call rotation pager system
– Online Customer Service Center

Linux Administration
– Installs, reinstalls and updates
– Trouble Shooting and configuration
– Apache configuration, optimization & Setup
– Linux X64 installation, optimization and maintenance
– Security optimizations
– Proactive and reactive maintenance
– Installs, reinstalls and updates
– Trouble Shooting and configuration

Managed MySQL and MSSQL
– MySQL and MS SQL first time install service
– MySQL maintenance and troubleshooting

24/7/365 System Availability
– Availability monitoring (Ping and Synthetic Transactions)
– Performance monitoring of key server parameters
– Graphing and trending

Security Services
– Routine Security Patching
– Routine Security scanning and auditing
– Penetration testing, SQL Injection
– Quarterly security audit reporting
– Dedicated hardware firewalls for all clients

Hardware Maintenance
– Hardware failure alerting and monitoring

Offsite Backups
– Remote off-site backups per 50gb nightly

Click here for a free quote for managed vps hosting!

Massive Amazon Route53 API Bind Zone Import Script

Hello there,

Occasionally some of our managed services work has us dealing directly with other cloud providers such as Amazon. One of our clients set a requirement to migrate over 5,000 domain’s to Amazon’s Route53 DNS service.

There was little doubt that this could be automated, but since we have never done this massive of a deployment through Amazon’s API directly, we thought it might be interesting to post the process as well as the script through which we managed the import process.

Essentially the script utilizes a master domain name list file as its basis for looping through the import. The master list refers to the bind zone files and imports them into Amazon’s Route53 via the Cli53 tool package.

One final note, the script outputs all completed domain imports into a CSV file with the following format :

This is because when facilitating the actual nameserver change request, all the nameservers assigned to domains when imported to Route53 are randomly generated, so the script has to keep track of these nameserver/domain associations.

The script isn’t perfect and could benefit from some optimizations and more error checking (it does a lot of error checking already, however), but here it is in its entirety. We hope you will have some use for it!

Checking and repairing mysql replication automatically


MySQL replication has been known to easily break, as a result of a large multitude of potential causes.

Sometimes the replication can even break if an erroneous query is executed on the master server.

With all the potential issues that may break replication, we thought it prudent to write an automated check script that can run on a scheduled basis (i.e. every 10-15 minutes), check the Slave status, report on any errors if applicable and attempt to repair replication.

We have built this script to exit and send mail alerts if any step of the checking and repairing process fails or generates an error in itself.

The script also generates a lock file to ensure that no more than one check process can run at any given time. We feel this script could be best used for scenarios for remote MySQL slaves, for example. Adding this extra layer may ensure a more reliable replication.

The repair process is simply 3 MySQL Commands :

The above directives assume that you have a with the mysql master server information statically set. No CHANGE MASTER commands have to be executed as a result. Resetting the slave clears the error and resumes replication, and all the queries missed during the time it failed should be queued and applied after it starts again.

Here is the script :