Product Update Server by The Omega Concern

In a nutshell:

  • Product: Product Update Server version 1.0 by The Omega Concern
  • Scripter: April Heaney
  • Your Technical Contact: April Heaney
  • Support Address: This email address is being protected from spambots. You need JavaScript enabled to view it.
  • Revision date: 2007-03-27
Thank you and congratulations on your purchase of The Omega Concern's Product Update Server. This system is robustly designed with commercial applications in mind, to provide a robust update and upgrade path for you and your customers. Please read these instructions before using your new Product Update Server.

The Omega Concern is dedicated to producing quality work at affordable prices, and we support everything we sell. April Heaney is your Technical Contact for this product, and can assist you with any problems with your server. All of our products are designed with the balance of impact on sim performance and ease of use in mind.

If you find one of our products to be causing lag, behaving in unexpected ways, or otherwise being a pest, we need to know so we can correct it. Also if you find the user interface to be confusing or otherwise difficult to use, please let us know and we will be happy to assist you.

If you need to contact your Technical Contact, please state your product name and version number upon first contacting your Technical Contact, or your reply may be delayed or lost.

You are eligible for all upgrades on this version, right up until version 2.0.

Your feedback is valued! If there's something you love, hate, or just think would be better if it were just a little different, we want to know. Your input directly influences the course of development and future features of Omega products.

Version History:
  • 1.0: Intial public release

1. The Concept
The idea behind an update server is in essence a simple one, though very important to anyone who has a product that may need future bug fixes or a product that one may wish to update for existing customers at a future time.

In the customer's product is an update script which contacts a server in-world with information about its product name and version. The server checks if the product's version number is lower than the current version the server itself contains. If so, the updated version of the product is delivered to the customer.

2. Product Walkthrough

I will describe how I, April Heaney, set up these update servers for the products sold by The Omega Concern.

I create a stack of three servers, and name them "X Update Server" A, B and C. The "A" server I create a name and password for with Object DNS, and use the script inside to complete registration. I take the *Products notecard into my inventory and delete it from inside of the three servers. I create an informative notecard to be delivered with the update and keep that in my inventory as well.

I then collect the SL addresses of the other two servers. I edit the Updater script that will go into the product these servers will deliver for, putting the addresses into the SERVERS list. I then edit the PRODUCT, VERSION, PASSWORD and VERB variables. Once done, I create a corresponding entry in the *Products card I have copied into my inventory.

I place the Updater script into the product, setting whatever event I wish to trigger the update check, and then pack the product into a box with any other materials I wish which I name the same as the PRODUCT variable and product name entry in the *Products card, and take that into my inventory.

I now take the box with the product, the *Product card, and the informative notecard and place copies of this set inside of each server. Then I click and select "Reset" from each server. They each cycle, the status indicator turns to yellow, and they announce their readiness to be set online.

I then set each one online, and then test the delivery with a not-current version of the product. It is wise to test this several times. :)

The stack of servers is now quite redundant and ready to start serving updates.

3. The Server
The server is where one places the products to be sent out as well as an optional notecard. As a rule of thumb, you are better off having more than one update server serving any single product. Better still is to use multiple update servers and to have one of them on "Object DNS" which is covered in section 5.

3.1. The Server Menu
Clicking on the server will drop down the server menu. The following options are available:
3.1.1. Address
This will cause the server to give you its Second Life email address. This is the address which needs to be listed in the Update script.

3.1.2. Email Logs
Sends the server delivery logs to the email address specified in the *Products card.

3.1.3. Debug
Toggles debugging mode. This allows one to see the link messages sent between the various scripts in the server to help determine if the system is functioning properly.

3.1.4. Set Online/Offline
This toggles whether the server is accepting incoming update checks.

3.1.5. Reread
Causes the server to reread the *Products card, but does not reset the current statistics.

3.1.6. Reset
This resets the entire server, including the request and served tallies.

3.2. The *Products card
The *Products card is used by the server to email logs to you and to set up the products inside.

With all strings, capitalization counts, and be careful not to accidentally include leading or trailing spaces, as this may cause problems. Also, the server uses double and triple colons as data field delimiters, so you should avoid using them in your strings, lest you end up with unexpected results.

While it is typical to use multiple servers per product, the server will accept multiple products, which can be configured one per line, as seen below:

// Uncomment and set your email address for logs to be sent to below
// If you do not want logs to be sent, simply do not uncomment this line
email:This email address is being protected from spambots. You need JavaScript enabled to view it.

// Below here, we have the listings for the product(s) you wish to have in this server. The format is:
// Product Name:version:password:notecard
// So for example, a valid entry may look like:
// My Widget:101:SecretPassword:My Widget Notes
Example Product:110:PassX541:Example Product Notes
Shiny Thing:200:SeCRet:None

The server collects the names of customers who have received an update from this server, and sends them to the email address in this card, if one is specified. This is an automatic email every 50 names, or if "Email Logs" is selected from the server menu.

In the example above, two products are in the server. The first one is "Example Product" which is currently at version 1.0.1, and thus is represented by the integer 101. The server does not take floating point numbers, so do not use decimal places. The password for this product is "PassX541". The password is mandatory for your own protection, creating a higher barrier to prevent someone from "gaming" your server and receiving free products, or simply overwhelming your server with bogus requests. Also to be delivered with any updates is the notecard named "Example Notes"

Do Note: Capitalization counts!

The second product is "Shiny Thing" which is at version 2.0, and thus represented by the integer 200. Its password is "SeCRet " (capitalization counts!) and for the note to be included, there is none, so we add "None" there. If the server doesn't find a note inside actually named "None" it will skip sending a note out along with the product.

The server will match incoming product names in a wildcard type of matching. Let's look at the "Example Product" example.

If the PRODUCT variable is "Example Product" you can have inside of your server an object named "Example Product 1.0" or "Example Product (Boxed)" or "Example Product Beta" etc. Similarly, you can have a notecard named "Example Product Notes" or "Example Product 1.0 Notes" and so on. For the object and notecard, as long as they start with the same string as the PRODUCT variable, the server will match and deliver.

After making the needed changes to the notecard and placing the product to be delivered inside of the server, click to bring up the server menu and select "Reread" or "Reset." The server will cycle and read the notecard, and if everything is set correctly it will tell you "Configuration read. Server ready to be set online."

4. The Updater Script

The updater script is placed into the product you wish to have checking in with the update server.

With all strings, capitalization counts, and be careful not to accidentally include leading or trailing spaces, as this may cause problems. Also, the server uses double and triple colons as data field delimiters, so you should avoid using colons in general in your strings, lest you end up with unexpected results.

How it would be set up to work with the "Example Product" above is given as an example:

// SERVERS: A list of the addresses of your update servers.
// This script will randomly choose one of these servers to contact.
list SERVERS = "This email address is being protected from spambots. You need JavaScript enabled to view it.", "This email address is being protected from spambots. You need JavaScript enabled to view it.";

These two update servers will be randomly picked for the sending of the update check. This helps provide some redundancy in the event that one of them is accidentally deleted, falls off-world, or otherwise undergoes some trauma that causes its UUID and thus its email address to change.

// PRODUCT: The name by which you wish to call your product in the update system
string PRODUCT = "Example Product";

This is the name of the product, and capitalization does count. It needs to be identical to the name entry in the *Products card.

// VERSION: This is an integer that represents the current version of your product.
// It does NOT take decimal values. 1.0 is not accepted. 10 or 100 however is.
integer VERSION = 109;

Again, this is the integer representation of the version number. This version indicates it is 1.09, which is not current with the version in the example above. When the product with this script checks in, the server will see that the version is less than what it has, 110, and will trigger an update delivery.

// PASSWORD: The password sent to the server to verify that this is a legitimate update request
string PASSWORD = "PassX541";

The password, which must also be identical to the entry in the *Products card in the server(s) to which this product connects.

// VERB: This can be SILENT or VERBOSE. SILENT means the update servers will not instant
// message customers with the status of their product. VERBOSE means that they will send IMs.
string VERB = "VERBOSE";

This determines if the server should send messages to the customer when there is no update available. You may wish to switch this to SILENT mode in the case of products that for example check in at regular intervals, as these messages will be shown as offline messages to an avatar who is not online at the moment the product checks in.

As given, the product will check for updates when it is rezzed in-world and when the script is reset. Any other event can be used to trigger an update check, the choice is yours.

Do remember to set the scripts to no-mod and no-transfer when placing them into your products.

5. About Object DNS
Object DNS is a free service provided by the folks over at W-Hat?. The web page for this service and to get an Object DNS name and password for your objects is: (external link)

Object DNS provides a method by which you can direct your product updates to the correct server(s) even if that server has had to be re-rezzed, which would mean its SL address would not be the same as you have hard-coded into your products with the update script.

Please note, Object DNS is a service of, and is not affiliated nor associated with The Omega Concern in any way. We simply find it to be a great service for this application and wish our customers to be able to benefit from it.

6. Errors and Troubleshooting and Security
The server displays, indicator light and messages are used to convey system state and errors to you. Some of the errors or issues you may encounter are below.

6.1. The "Requests" display reads "NO INV" - There is no object inside the server to deliver. These update servers are scripted to deliver objects, not clothing, body parts, scripts, notecards or landmarks. Have you a need to deliver such things from the server, simply place them into the contents of a single prim and follow the instructions above.

6.2. The indicator is red - This means the server has encountered a problem and is offline. Most likely causes for this are incorrect configuration in the *Products card, or no object being in inventory.

6.3. "Pass hash failed" and some gibberish - This indicates that a product checking in has attempted to do so with an incorrect password. If you have email logging on, this entry will be proceeded with "FAILED" and the owner's name and the timestamp of the attempt. This is useful information if someone has gotten the address for your update server and is attempting to crack your password.

6.4. "Key ### invalid. Delivery cancelled." - this means simply that for some odd reason, the key of the avatar from which this update request originated was missing or incomplete from the query. This is not a likely error unless the request itself was malformed.

6.5. "It doesn't work" - There are several things to check, including if the update scripts are sending to the correct address, if your region is having issues with object-object email, if the scripts in the product and in the server are all running, and so on. Try resetting the update script, resetting the server, and trying again. You may wish to turn on debugging mode to see if the server is receiving requests and if so, what that data is looking like.

6.6. Finally, in the event that -nothing- seems to work, DO NOT DELETE THE SERVER. This will cause its unique address to be lost permanently. Contact your Technical Contact and we can assist you to "Jump Start" the server by replacing the scripts and configuration cards inside, which will allow the server to retain its unique address and not cause a break in your update chain.

6.7. It is important to NOT place your update servers in an easily accessible location. While it is unlikely someone will be able to divine your passwords to get free products, it is simple to read the UUID of the servers and use that information to swamp your servers in a kind of denial of service attack. Keep them far from your place of business, or better yet, in another sim altogether.

7. In Conclusion
These update servers have been field tested at The Omega Concern for several months before we decided they were reliable enough to sell to the public. They have collectively been queried hundreds of thousands of times and delivered thousands of updates without fail. While Second Life likes to throw curve balls regularly, we are confident that these servers will bring you and your customers reliable and consistent service for the lifetime of your products.