Notes on Ruth2 settings (edited)

Starflower’s usual appearance (no mesh body). Skin is Eloh Eliot’s Wrath (LE) from Seven Deadly Sins. Somewhat punky today. Standing on the sea bed. No distractions here!
Starflower’s twelve-year-old “makeup all over my face” look with a mesh body. This needs needed to be fixed before I can could use Ruth2.

In the use of mesh avatars, I have come late to the party. I’d been meaning to try it for ages but I’d simply avoided the effort until lately when I felt slightly shamed when appearing in photos for Thirza Ember’s amazing Hypergrid Safari. I am her latest fan – I am sure she has lots. She is REALLY nice.

However, it’s going to take me a lot longer to migrate than I had expected. The feet and hands are loads better – probably the biggest “tell” that somebody is or isn’t using a mesh avatar. Surprisingly, there were some initial disadvantages for me but I resolved these. The settings appear to be rather different.

The head was really different. I simply couldn’t just migrate my shape settings directly. The chin is was smaller to the point of overbite, the eyes less normally or naturally sunken, i.e. slightly bulging with too little eye sockets, making makeup bleed out all over my face. The cheekbones seemed lower and the ears are clearly were different too. I will need to make changes and assess whether or not I can use the Ruth2 head and still look like myself. It currently makes made me look rather like a twelve year old. I no longer look characteristically like myself. This, I think, is the main thing I need to resolve by spending time altering the settings to approximate my current facial appearance.

[Ed.] Modifying the sliders does seem to have resolved my issues with the head. The settings are NOT the same as those required for the system avatar. You will need to tweak yours, as I did. Here follows a guide to what I had to do to approximate my system avatar appearance with Ruth2. (Your avatar may be different, so this will be purely as a guide to what you may need to do in achieving something similar.)

body fat +10

egg head -20
upper cheeks +20
cheek bones +20

eye opening +30
eye depth -10
eye bags +10

mouth corner +10

chin angle -10

torso muscles +20
shoulders +10
love handles +10
belly size +10

butt size -20
saddle bags -10
foot size +35

The hips were massively wider. I had to lower the sliders by 10%.

[Ed.] It now seems that it was not the hips but “saddle bags” and “butt size” combined with low “love handles” and “belly size” settings that made the hips look large.

The feet are great but they no longer work with my shoes. They are smaller even than the zero setting that I was previously using on the system avatar, so I may have had to experiment with the foot position settings, which appear to allow different angles, as well as increase the foot size to fill my shoes. Again, if I can’t wear my shoes then this is going to be rather difficult to sustain. [Note: different angles don’t work, as has been pointed out to me, as this makes the angle of the shoe change as well as the foot.]

[Ed.] After some more experimentation, it is possible to modify my shoes. The strange heel-in-foot thing of the system avatar wearing system shoes with heels > 0 is no more, thank goodness. You may need to use existing transparent system shoes as previously, as I did, or use the ones supplied in the Ruth2 Extras package (although altering the hover height of your avatar by about 1-2 points, depending on your shoe height, will have a similar effect). I am guessing that mine are something like the equivalent of 3″ heels in RL: these are 100 on the slider, even though I used the medium rather than the high foot. (I’ve also done some flat shoes with the flat foot.) The shoe mask will no longer be required. Obviously I had to reposition the shoes to make sure that no bits of feet showed through (and I had to widen the circumference of the straps slightly, but this is specific to my particular shoes). My feet were previously size 0 but now size 35. You may find that your shoes behave differently. Note that mine are prim shoes, not mesh. The Ruth2 avatar is definitely MUCH better than the system avatar. It is even worth shoe problems. However, you may well find that you can resolve these.

Lastly, the HUD only allows certain colours of nails by default. I often wear light blue, dark green or black nails. It does offer grey, which is better than nothing. I shall have to investigate if it It can be hacked in order to provide different colours than the rather staid range of default colours. The hands are otherwise great, though.

[Ed.] The HUD for the Ruth2 Business mesh avatar does allow nail colours to be altered by altering the notecard inside. Hooray! (Note: you will need to get the vectors for the colours, which can be obtained from the viewer by going to the colour picker and copying them from there. Firestorm makes this easy.)

It was surprisingly easy to use Ruth2. It’s a shame that IARs can only be imported directly into the Library on standalones rather than grids. I’d like to make Ruth2 and Roth2 available to my users. Oh yeah, I have precisely one other occasional or semi-regular user (who comes largely to humour me, being such a kind sort of chap and a really good friend.)

[Ed.] To clarify, you can pick up these avatars without using IARs but it would still be good to be able to put them into the library on a grid so that new registrants can use them.

I have no comment to make on Roth2 because I really don’t have an opinion on male bodies. They seem to be serviceable enough: and that is the extent of my personal expertise. It is, I admit, a gap in my education. Along with Hieratic, the biodiversity of yams, solar physics and crochet.

I have also made no real effort to acquire mesh clothes, with the result that my appearance, while radically improved from 2007 (when I even had a system skin and system hair!), is rather dated, maybe a decade or so out of date by OpenSim/SL standards. I really need a plain mesh skirt to replace my flexi skirt that I use as a component of nearly everything.

[Ed.] I have been given some guidance on the matter of mesh skirts and there may be a free one. Thank you to my kind advisor, who I shall not name here, but who dropped by out of the kindness of his own heart and took a LOT of trouble to help me out and inspire me to sort things out with Ruth2 ❤ What an absolutely lovely thing to do. Aren’t people nice in OpenSim grids?! Hooray! 🙂

Starflower’s original system skin and hair re-created from 2007. Old school! My current shape (shown here) evolved from the original one.

That was the first time I had been anywhere in company (more than two people) in the metaverse for years. The people all seemed polite and nice, which was refreshing after many less pleasant experiences in SL. But it did all seem rather like a blast from the past for me and very SL-like otherwise. I felt a lot less hermit-like because Apollo and Thirza were there, so at least I felt like I slightly knew somebody or had been invited, rather than just gatecrashing a random party and hiding at the back. This is my normal modus operandi at parties, as you may not be surprised to hear. Anyway, a big thank you to them for including me and being so kind.

Next time: back to more boring details about TLS implementation in OpenSim! 😀

TLS (“SSL”) Quirks in OpenSim

This is not a post about my ongoing struggles to make OpenSim work with TLS and communicate properly with other grids, using a transparent Nginx reverse proxy. I suspect there may be one or two bugs to report but I am still investigating numerous issues, particularly around why the XMLRPC method verify_agent seems to fail to reach the target grid consistently – is it my proxy settings or is it something in OpenSim?

I am going to write about the alleged “out of band” TLS settings, a topic which confused me for some time. You will find these in Robust[.HG].ini (for my earlier work on TLS for the simulator, please see my earlier post, which makes edits to OpenSim.ini). In fact, despite my earlier credence in this statement, it is potentially misleading. It is in fact possible to add a native HTTPS port to the simulator, to set it as the main listener port rather than as the additional port, and to set it up with TLS provided externally. There are some considerable quirks in this system – and one major drawback that means that you will continue to need to use an external reverse proxy like Nginx to operate a grid using TLS.

I will be studiously avoiding the common and erroneous use of the term SSL for TLS, since the use of SSL instead of its successor TLS for HTTPS and similar protocols has long been compromised and is both insecure and deprecated. In fact it is wisest only to use TLS versions 1.2 and 1.3 if at all possible, never version 1.0. It may still be necessary to use version 1.1 for some limited purposes but I shall not address that further here. Both 1.0 and 1.1 have been deprecated by major browsers since March 2020.

The settings in question under [Network] are https_listener, https_main and https_external (of which the latter remains undocumented, even in OpenSimDefaults.ini).

The first of these, https_listener = True, adds an additional secure HTTPS (TLS) port as documented. You will also need to set https_port = 9002 (or whatever suits your setup, but I am popularising 9002 and 9003 for the defaults for TLS), cert_path = “path/to/cert.p12” (location of the X509 certificate) and cert_pass = “yourpassword”, as well as possibly needing to look again under [Startup] at NoVerifyCertChain = true and NoVerifyCertHostname = true (set to false if you are using a certificate authority to validate your certificates via LetsEncrypt or some other authority).

The next setting https_main = True sets the main listener as the HTTPS port. However, whether by design or by oversight, it does not transfer any of the HTTP handlers (use show http-handlers on the Robust console to show these) to the HTTPS listener port. This is a problem for Hypergrid (and presumably for the purposes of all the other handlers too!) since you will be unable to verify the identity of the agent and the client without the relevant XMLRPC methods. For this reason, setting up a grid to use TLS still requires the use of Nginx as a reverse proxy. (I am still having problems getting this to work despite successful manual XMLRPC calls to the ports with cURL to check that the correct results are in fact returned from the server.) This quirk is really quite annoying but I do not know if there is some reason for it. Since this is the main public port, I can see no reason not to switch it over or duplicate these endpoints. Another less important quirk is that port is not replaced, irrespective of how you set https_main, and that https_port is additional, similar to the situation on the simulator that I documented in my earlier post. This is no problem: you don’t have to let it through your firewall.

Ed. [2022-02-18 10:58]: Are the missing HTTP handlers related to this commit?

The third quirk relates to the entirely undocumented https_external setting. I discovered this by looking at the code in Framework/NetworkServersInfo.cs (and, for example, in the OpenSim Mantis such as in this feature request). This is a very peculiar setting indeed because, if https_external = True and https_listener = True together, the https_port port will be added without TLS i.e. it will be reachable only by the protocol http:// and not by https:// on the server. It will then require an external proxy like Nginx to provide the latter (for which see my comments above on the ongoing issues that I am testing). In essence, despite the name https_port, it is then an additional HTTP port without any of the HTTP handlers that are provided on port. You then have two plain HTTP ports. That seems rather eccentric, but it works and is logical, though it is counter-intuitive. You wouldn’t guess this without some help, especially as it isn’t documented.

To summarise, the description of these settings as only being useful for “out of band” purposes like the remote console is still accurate because the HTTP handlers are not available, whether it is the secondary or the main public port on the Robust server. If these were transferred and/or duplicated then it follows that it would also be of primary use in setting up TLS on Robust without the need for a reverse proxy. I would like to see this happen: it might help with my struggles with the Hypergrid with TLS.

I hope this post is of use to OpenSim developers, testers and grid admins alike. I will document what I suspect may be problems/bugs in using TLS with reverse proxies in another post when I can (still testing).

Lastly, I repeat my assertion that this is a priority matter and that all grids should at least use TLS for the login server so that passwords are not broadcast in the clear – Ed. note that the SceneGate viewer actually warns you about this by default unless you tell it not to after the first time. That is the industry standard for a reason. I accept the arguments about the excessive overheads of encryption for other purposes, although I am reminded of SL being hacked by giant penises back in the day and thus suggest that it might be an idea to secure some other public data transmissions too. The overheads are not that much in practice on modern hardware and with modern compression standards, and you don’t need to use TLS on the internal port (usually 8003) unless you really need to open that up to the Internet i.e. simulators on remote machines will need to connect to your Robust services or you split services over multiple remote machines. Most of the rest of the Internet now uses HTTPS for almost everything, certainly for the Web, FTP, SSH, e-mail and so on. That bring me to a final observation: there are no TLS settings for the internal port in this situation, so you would still need to use Nginx as a reverse proxy for this. Correction: there is no separate setting but, when https_main = True and https_listener = True, both the private port and the https_port are served over HTTPS unless http_external is also set. Should this be documented more precisely? There is a use case for these settings existing in such a situation, although most people probably wouldn’t need to use them unless they anticipate running a public grid to which others can connect regions. It’s a bit problematic too if you want no HTTPS on the firewalled internal port (where there is no need for the encryption overhead) but you do want it on the public-facing port.