Oz Linden

That's really there to make a 24 hour day match somewhere in RL; if the day length isn't an integer factor (or multiple) of 24 the day will move anyway.

If you have reason to believe that uplift has adversely affected something on your region, you should file a Support request to ask that it be moved back to the datacenter (but keep reading to find out how to do so in a way that will work). You can tell whether or not a region has been uplifted by going there and looking at the simulator hostname in the Help > About dialog: if it ends in ".lindenlab.com" it's in the datacenter, if it ends in ".amazon.com" or ".secondlife.io" it's uplifted. Be aware of a couple of things before you make a request to be moved back: I have asked Support to collect specific information about exactly what has failed and exactly how it has failed for any such request. If we don't get this information, we can't fix whatever it is and we're likely to leave the region uplifted until we can get the data we need. We are trying to move all of the regions as soon as we can (consistent with carefully listening, and watching all our internal metrics, for problems after each move). This process is going to move as quickly as we can make it happen, so your region(s) will be uplifted pretty soon. We encourage you to actively participate in this process rather than hide from it and hope someone else solves your problem before it affects you. If your region is among the last to move, the time available to address your problem may be very very short; it will be better to have detected it early. Lucia has been testing on the beta grid and other early-uplift regions, and we're very much aware of and working on solutions for the particular problem they have reported; follow Lucias example. If you report a problem and we can observe it and we think it likely that moving back will fix it (there is some chance that the problem is not a result of the simulator uplift), then we'll move it back while we work on a fix. We have the vast majority of our development resources focused on this migration, but if we don't know about a problem we won't fix it. If we don't fix it, there will come a time in the near future when moving it back will no longer be an option. Overall, this is going very well; as April said in her post last night - please be patient with us. Really, this is going to be better very soon. PS. That note about possible performance problems is true... it's possible ... but mostly what we've seen in the regions uplifted so far is that it's better.

If you're a landowner, yes. In World > About Land you can set the day length and the offset; this shows how I've set them for my in-world office space to match my home office in New Hampshire:

We've been working hard on the Uplift of Second Life. If you have not been following this project, that's what we're calling the migration of our Second Life simulators, services, and websites from a private datacenter to hosting in The Cloud (Amazon Web Services). It's a massive, complicated project that I've previously compared to converting a steam-driven railroad to a maglev monorail -- without ever stopping the train. This undertaking has at times been smooth sailing, at other times a very bumpy ride. We wanted to share some more of the story with you. Our goal has been to move SL incrementally to give ourselves the best chance of minimizing awareness among the residents that these changes were happening. We feel we’ve done better than we expected, but of course it’s the bumps in the road that are most noticeable to our residents. We apologize for recent service disruptions, although what’s perhaps not apparent is the progress we’ve made -- and the improvements in performance that have quietly taken place. First, the rough spots: Region Crossings One of the first troubles we found was that region crossings were significantly worse between a cloud region and a datacenter region. We did a deep dive into the code for objects (boats, cars, planes, etc) and produced an improvement that made them significantly faster and more reliable even within the datacenter. This has been applied to all regions already and was a good step forward. Group Chat stalls Many users have reported that they are not able to get messages in some of their groups; we're very much aware of the problem. The start of those problems does coincide with when the chat service was uplifted; unfortunately the problems did not become clear until moving that service back to the datacenter was not an option. We haven’t been able to get that fixed as quickly as we would like, but the good news is that we have some changes nearly ready that we think may improve the service and will certainly provide us with better information to diagnose it if it isn't fixed. Those changes are live on the Beta grid now and should move to the main grid very soon. Bake Failures Wednesday and especially Thursday of this past week were bad days for avatar appearance, and we're very much aware of how important that is. The avatar bake service has actually been uplifted for some time - it wasn't moving it that caused the problem, but another change to a related service. The good news is that thanks to a great cross-team effort during those two days we were able to determine why an apparently unrelated simulator update triggered the problem and got a fix deployed Thursday night. Increased Teleport Failures We have seen a slight increase in the frequency of teleport failures. I know that if it's happened to you it probably doesn't feel like a "slight" problem, especially since it appears to be true that if it's happened to someone once, it tends to keep happening for a while. Measured over the entire grid, it's just under two percentage points, but even that is unacceptable. We're less sure of the specific causes for this (including whether or not it's Uplift related), but are improving our ability to collect data on it and are very much focused on finding and fixing the problem whatever it is. Marketplace & Stipend Glitches We've had some challenges related to uplift for both the Marketplace and the service that pays Premium Stipends. Marketplace had to be returned to the datacenter yesterday, but we'll correct the problems that required the rollback and get it done soon. The Stipends issues were both good and bad for users; there were some delays, but on the other hand we sent some users extra stipends (our fault, you win - we aren't taking them back); those problems are, we believe, solved now. Perhaps the above makes it sound as though Uplift is in trouble. While this week in particular has seen some bumps in the road, it's actually going well overall. Lots of the infrastructure you don't interact with directly, and some you do, has been uplifted and has worked smoothly. For a few weeks, almost all of the regions on the Beta grid have been running in the cloud, and over the last couple of weeks we've uplifted around a hundred regions on the main grid. Performance of those regions has been very very good, and stability has been excellent. We expect to be uplifting more regions in the next few working days (if you own a region you'd like included, submit a Support Ticket and we'll make it happen). Uplift of the Release Candidate regions, which will bring the count into the thousands, will begin soon. When we're confident that uplifted regions are working well at that larger scale, we'll be in a position to resume region sales, so if you've been waiting - the wait is almost over. Overall, the Uplift project is on track to be complete or very nearly so by the end of this year (yes, 2020… I know I've said "fall" before and people have noted that I didn't say what year 🙂 ; the leaves haven't finished falling at my house yet…). It's likely that there will be other (hopefully small) temporary disruptions during this process, but we promise we'll do all we can to avoid them and fix them as fast as we can. This migration sets the stage for some significant improvements to Second Life and positions us to be able to grow the world well into the future.

Please contact Billing Support and describe for them in as much detail as possible exactly what problem you're seeing.

One additional thing we've seen in recent testing: Simulator hostnames are a little longer in AWS, so if something is storing them somewhere that limits the length, you may want to make sure it's long enough for the new names.

At the very least we would have to add a different asset type because formatting would confuse scripts

I wrote this response in the other thread that may be of interest to those working on how to authenticate to an external server:

I'm afraid that I don't have a suggestion for you there. 2009 was before my time ... I can assure you that protecting script sources is very much top-of-mind around here.

This thread exists specifically to alert you to the fact that measures like those will no longer work (indeed, they will cause your service to fail) and give you a chance to replace those checks with something more secure. For example, if you have an HTTP GET operation to an external server, you can create your own authentication signature with something like: # The SharedSecret value is known by the server as well string SharedSecret = "a975c295ddeab5b1a5323df92f61c4cc9fc88207"; string request_params; # # ... code that builds the request_params string # string url = "https://myserver.example.com/api/2.0/operation"; # The timestamp ensures that even if the request_params are all the # same as some earlier request, the authenticator will be different string timestamp = llGetTimestamp(); string authenticator = llSHA1String( timestamp + SharedSecret + request_params ); key request_id = llHTTPRequest( url + "?" + request_params, [ "HTTP_CUSTOM_HEADER", "X-Script-Auth", timestamp + "," + authenticator ], ""); When the server gets the request, it can read the X-Script-Auth header and the parameter string, do the same SHA1 hash, and compare the authenticators. An approach like the above is far more secure than using the IP address or hostname of the requestor as an authenticator, since it proves that the requesting script is not merely some script running in SL - it's the script you wrote that has your secret value in it.

Support can help with beta grid login issues.... file a case

The cloud uplift version does not add or subtract any features. There are some changes that may affect the remote service - see this post

something like this is best dealt with as a Support request, so I'll leave it to them

This is most likely DNS caches not updating to your new server uniformly; it should correct itself in time.

We're working on it. We only recently got our tools updated sufficiently to do so (some part of the most recent Xcode is needed).

Really, "source authentication" that was just an IP address check wasn't worth much to begin with. Yes, it would filter out some of the annoying but unsophisticated generic attacks on web servers, but it didn't really tell you that requests were coming from the scripts you expected (anyone on any region with any script would have the same IP range that legit scripts did), or that it wasn't an attack. If that's what you had, no change is needed to the in-world content to keep it working because just removing the IP address check at the server will allow the in-world scripts to work. Adding a more secure verification that requests are really coming from the specific scripts you expect will be a bit more work, but that would have been worthwhile anyway.

It doesn't change that setting at all (at least not yet). The point of that setting is to use the internal browser for 'trusted' content created by the Lab. The fact that web servers implemented by Residents in LSL ended up in a subdomain of 'lindenlab.com' was actually a flaw in that design, and part of why we're (nearly) eliminating the use of the corporate domain for addressing of things within SL (to reassure viewer developers: we're not changing the domain of the login servers - that would be too much trouble). Whether or not there should be a setting that adds services within 'secondlife.io' to the list for the internal browser is an interesting question.

We can probably lengthen that (assuming that doesn't result in unmanageable litter); I'll look into it on Monday.

The script can add a custom header that has that signature in its value; there's no need for the proxy to be involved at all.

We don't own the IP addresses (AWS does), so we can't create an authoritative reverse lookup for them. There are lots of DDOS protection services out there for web sites, but for reasons I hope are obvious we can't make recommendations. Oh ... and also, we're mostly stopping using 'lindenlab.com' for the backend service domains (it's mostly being replaced by 'secondlife.io' or some subdomain of that).

it would be easier if any questions or updates were all in that one thread in any event, thanks for your testing. I don't know whether or not this build has all the latest region crossing updates

Unfortunately implementing your suggestion would not be nearly as easy as you might think and would in the end not provide a strong assurance. This is why we're making a special effort to publicize these changes well before they start appearing on the main grid. We are well aware that making changes to LSL behavior that are potentially not backwards-compatible has the potential to break content, so we're very careful about doing so. In particular, changes that require scripts to be updated are especially problematic since they're so often relied upon by people who can't update the script. In this case though, it's the remote service that requires adjustment, so our hope is that most will be maintained by someone capable of removing any checks like those (after all, someone is paying for the web server, so they presumably can update it).

No

Using IP addresses and DNS names as an authentication method isn't a good idea even when it appears to work. A much better approach would be to put a secret string in your script and send a hash of that secret and the message along with the message. The server knows the secret, so it can verify that the message is authentic. This verifies not only that it's coming from some simulator, but that the source knows the secret.

The first testing region for these HTTP changes is available now: Cloud Sandbox 4 on the Aditi (beta) grid If you have difficulty logging in to that grid, it may be because your account has not been copied there; submit a Support request to get that fixed.