Pirate DNS

Some of the main characters in the peer to peer file sharing world, led by former Pirate Bay spokesperson Peter Sunde have announced their intentions to launch a competitor to the ICANN manged DNS system. ICANN is an independent non-profit organization, however it often complies with the wishes of the U.S. government. The alternative system will feature its own root server followed by a full naming system. The Pirate Bay is an infamous web site known for the coordination of illegal file sharing on the Internet who's servers are constantly on the move across the world while it's operators thumb their noses at law enforcement. The ultimate purpose of the so called “P2P DNS” project is to maintain an Internet free from censorship according to Sunde. The alternative root server can accomplish this by providing an alternative system to map familiar domain names such as google.com to the IP addresses that the Internet uses to route traffic.

The announcement of this alternative DNS system is immediately on the heels of the Department of Homeland Security seizing a number of domain names linked to websites that are linked to illegal files haring.  Sites such as Torrent-finder.com, DVDcollects, and TorrentFreak.com were taken over by the DHS and visitors were greeted by an image explaining the seizure.  In all, more than 70 domain names were seized.  Surprisingly, The Pirate Bay escaped this round of seizures despite them being a high profile target in the past.  Another popular torrent tracking site, Demonoid,com recently announced that it will be changing it's domain name to Demonoid.me.  The U.S. does not have jurisdiction over .me as it does over .com.

Excessive Kaseya Database Size

For years, we had set Kaseya to maintain 30 days of log files for workstations and servers that we manage.  However, a matter arose that made it really attractive to have access to a larger amount of historical data as what we wanted to double check was well beyond 30 days out.  There's nothing that could be done in that case, but can this headache be eliminated moving forward?  Kaseya support said that there would be no ill effects by upping this to 365 days or more, it would just cause the ksubscribers database to grow.  And since our database server was barely breaking a sweat, we made the change.

Fast forward about a year, and our previously 35GB ksubscribers database had ballooned up to well over 400GB, and everything involving Kaseya was dog slow.  The breaking point came when I could no longer get a reapply schema operation to complete.  It would fail at a different point each time, but not too far off from each other failure.  Since we were a couple revisions of Kaseya behind, and a new version was due to come out soon, I figured it was time to address this. Dropping the log retention back to 30 days did nothing, so I opened a ticket. 

The support tech found that the reapply schema failure was because the operation was timing out before completion due to the size of the database.  He was able to increase the timer so that it would finish, and then reset it back to it's original value.  He did not tell me what the value was or where I could find it and noted that leaving it too high would ultimately mask serious issues later on.  

Once we had a reapply schema completed, I was left with these steps to get the database size back under control.  We were told to only do this during a maintenance window, but since steps 2 and 3 took several days each, and everything ran fine while it was running, we couldn't do so.  Nobody can have a maintenance window on their main business app for a week or more.

1. Stop IIS and the Kaseya services.
2. In SQL Management Studio, run the following:
• DBCC SHRINKDATABASE('KSUBSCRIBERS')
3. Reindex / Rebuild the indexes.  We were provided with a stored procedure to do this, I'll have to dig it up but a Kaseya support tech should have it.
• exec [dbo].[sp_rebuildindexes]
4. Update the DB statistics.  Again, we were provided with a stored procedure to do this. 
• EXEC [dbo].[sp_update_stats]
• @dbs = N'ksubscribers'
5. Start IIS and Kaseya services.
6. Access Kaseya VSA web interface and double check the database size reported under System > Statistics. 
7. Run Reapply Schema.