Domain Server Operation 101 - Words of Wisdom

#1

So since High Fidelity, Inc wants you to all become the new hosts, let me hand over some words of wisdom about keeping your worlds operational and running well. This is going to be a quick crash course, so here we go:

+ 04/07/2019 - Initial Guide
+ 04/09/2019 - Added "Enable Multi-Kick for Logged In Users"
+ 05/04/2019 - Added updated oven links

Shameless Plug

Use the spawn spacer – Seriously, I made this open source for a reason! A spawn spacer will distribute how people come into your domain so you don’t have everyone stacking on top of each other. It takes seconds to install and your visitors will thank you for not randomly popping into each other’s heads.

Beginner

  • Use Whitelists – I cannot stress the importance of this, but seriously, even if your domain doesn’t use scripted items, put a script whitelist in your domain! This is gateway number 1 towards some nasty stuff and is often overlooked. Without a whitelist, script kiddies can just directly paste the code into the URL spot and have their work run from there.

  • But don’t rely on mpassets.highfidelity.comUntil this flaw is addressed, avoid whitelisting this domain unless you have Fluffy’s filter installed! At this time, anyone can upload anything to the marketplace, published or not, and it all goes to the same location. This has been an issue since the marketplace’s introduction and hasn’t been addressed. If you absolutely must use it, please use a filter (filters are not beginner friendly, but I cannot stress that enough).

  • Lock your stuff down – This one is also often overlooked. Under no circumstances should your landing platform be unlocked, yet this is very common. Unlocked items can be edited. Disabled create rights for users? Create rights and the ability to edit are two separate things, so while a user cannot create new items, they can still edit what is already there. Pair that with the first thing in this list and you can see where things can go wrong. Very wrong.

  • Place a cube at your landing point – This has to do with how things tend to load in High Fidelity, but primitives load first. If the domain is still loading, there is a chance the floor will not load immediately. Using a primitive as a fall back can help a lot.

  • Use Descriptions – In your domain’s settings, you can define a description of your domain. It is a small touch, but it can help people know more about what there is to do there.

  • Use Tags – This one is heavily underused. Under your domain’s settings in the Description area, you can define searchable tags for your domain. While completely not documented, GoTo does use these. If you want to have your domain become accessible for mobile devices, be sure to add ‘mobile’ as a listed tag for your domain. Tags also appear in your domain’s info page, so keep it spruced up! Is your place a hangout? Club? A place for games? Be sure to use those tags!

  • Specify a maximum capacity and redirection location – Sadly this is one thing High Fidelity Inc didn’t really think about: what place will now serve as a common redirection if the domain is at capacity? Anyhow, you should at least specify a maximum capacity to your domain as to not have it bogged down. The numbers listed on Digital Ocean’s page are over-provisioned like no tomorrow, so keep that also in mind. For example, a 2 core, 2GB of ram server should be able to house at least 20 people, not 5-6. The numbers haven’t been updated in while and now that they’re relying on the community to do it, they should seriously consider fixing that!

  • Don’t let everyone have permanent create rights – If you are going to give create rights, don’t give everyone full create rights unless that is your plan. Temporary Rez rights are more than enough in most cases. Just remember to assign the lifetime of temporary entities under Entities in your domain’s settings.

  • Don’t keep Replace Content on yourself – Even if you are the owner, don’t keep Replace Content active unless you actually want to replace the content of your domain. This is used for loading preset content for an entire domain, so whatever was built will be destroyed if this is used. While it’s highly unlikely it can be abused, it’s better safe than sorry. Turn it off.

  • Enable Multi-Kick for Logged In Users – This option makes it so in the event of banning someone, it will also ban their machine ID. The reason this is important is in the event the user create another account or tries to come in anonymously, this will block them from returning due to being banned via their machine’s ID.
    NOTE: THIS CAN BE FAKED BUT IS NOT VERY COMMON! KEEP THIS IN MIND!

Intermediate

UPDATED!

  • Bake that **** - I will post a link to the oven tools as of v0.81.0, but please bake your items before using them. Sure, this is what the ATP (Asset Server) is for, but as I will explain later, that isn’t a good idea. Yes, even your avatar can be baked and I highly suggest it. It does make your CPU go crazy for a while but after all that is done, it will never have to be done again (unless they change the baking protocols).

    Legacy

    Zip: http://voxel.flamesoulis.com/flamesoven.zip
    7z: http://voxel.flamesoulis.com/flamesoven.7z

    v0.82.1 (Latest) - Adds FSTs to everything

    Zip: http://voxel.flamesoulis.com/oven/flameoven_v0.82.1.zip
    7z: http://voxel.flamesoulis.com/oven/flameoven_v0.82.1.7z

    Keep in mind that the primary benefit of baking your stuff (including your avatar) is that the model will load first and textures will be streamed to the client. This takes advantage of the multi-threaded download functions of the interface and, in the case of avatars, let your presence be seen even if the user is still downloading you (embedded textured FBX files require the entire file to be downloaded before the model will appear). Baked models are also more friendly on the GPU for both PC and mobile!

  • Don’t use the ATP for models – Unless you have a major reason for doing so, avoid using the ATP for hosting your models. In comparison to HTTP, the ATP system is just very slow and gives your server an unneeded workout. On top of that, it will attempt to bake very model given, which can be helpful in some cases, but honestly, you can do a better job yourself and have it hosted on an Amazon S3 (or even your own server if you’re clever enough).

  • Use the ATP for private scripts – While not advisable for models, the ATP is useful enough for housing simple scripts like the spawn spacer and tip jar scripts. In fact, it’s a good idea since it isn’t as straight forward to access, so no one can directly read anything put in there. Use this to your advantage!

Still in development, will update shortly

26 Likes
#2

Thanks Flame! I have been thinking about building a domain for a while

1 Like
#3

Thank you so much Flame! Will update my domain accordingly :slight_smile:

1 Like
#4

But ATP is more secure then http that is pretty easy accessable. Yes you can use .htaccess, but still.

#5

re whitelists
I believe until HIFI can provide us with the securities we all crave the users who have been asked to shoulder the burden of hosting the community needs to think about creating a shared whitelist system.

Everyone and their dog who wants to can wreak havoc in seemingly endless ways.

Trust is one thing, but the whitelist is the only lock that prevents this proxy shit.

But Judas that would stop new users enjoying the platform.

I think a comprehensive user list can be taken from the forum. Invite only didn’t stop gmail taking off.

The griefing fraternity are likely responsible for HIFIs change of direction, endless bullshit.

Who would go on this list?

Well by and large even the people I don’t like aren’t hell bent on destroying the community and platform.

In 5 years, I’ve only seen a couple.

Is it possible to cut paste a whitelist of names into the sandbox thing?

Is it possible to link a whitelist to a server holding the names?

2 Likes
#6

Flame, this is indispensable! This kind of helpful community provided information is exactly why I love coming here to read every day. I will soon embark on my first domain and you bet I will follow your words of wisdom very closely.

Hap ?;O)

3 Likes
#7

Yes, the ATP is more secure, but it’s also a lot slower. For resources you aren’t too concerned about, it’s best to use HTTP. Also, there is a way to secure content on HTTP that I think can be done with some clever htaccess trickery (using nginx atm so… guess same principal?), but I’m still on the fence about releasing that trick yet (can’t reveal all the cards in your hand).

Well, in regards to whitelists, I meant Script whitelists. Access whitelists are a whole other matter, but I do agree that it’d be interesting to have some better tools like account age (assuming not anonymous).

I should have more typed up a bit later.

1 Like
#8

I would also add, never run a domain server on a computer where you have sensitive/personal information, i.e. your normal day to day use computer.

Why? Simple.

As with any server, you could be running code that could be exploited giving a remote user access to things you would not want accessed.

Consider the number of exploits leveraged for software that’s both widely used and actively hardened (apache, openSSL etc etc etc), yet, still exploited versus lesser well audited software, which this certainly is, and you may see that your exposure might be greater than minimal.

2 Likes
#9

And remeber, if your not using it turn it off
like the devs do
saves the enviroment and prevents the accidental creation of a community

2 Likes
#10

Someone I know was specifically complaining about how bad the Linux build issue was. Apparently the Windoze edition of hifi relies on things that come as standard parts of Windoze, or that just install readily straight out of the box into Windoze without you needing to do anything beyond that to then compile and install HiFi interface and stuff from the current sources. To have the HiFi system on a Linux box, or at least on the fairly common version of Linux that person was using, you have to install a lot of bleeding-edge stuff onto it that break or change stuff under the hood of the current version of Linux. Basically, so s/he was saying, you had to convert your Linux into some experimental version of it and THEN try to compile HiFi on it, and s/he wasn’t interested in converting their regular desktop machine over to that bleeding-edge-experimental Linux MERELY to pop in at a HiFi meeting… since that Linux machine is the regular, primary desktop machine s/he does most, mundane things on, and installing all the needed stuff for it would break too many things on that machine.

3 Likes
#11

I completely agree. It’s been a hard push to get that all going, but in the case of Interface on Linux… yeah, have fun with that. Part of it is due to VR incompatibilities, but as per the last meeting, it seems finally High Fidelity got their act together and realized that having a better desktop experience is pretty important just as having a good and better VR experience is.

I would say canny it but… dear god, I’m starting to get tired of hearing that.

Anyhow, this topic will mostly focus on server operation. Interface stuff would be best suited to someone who actually builds Interface, which isn’t myself. Also, building the Windows version requires similar sorcery because of their love of environment variables. Seriously, it’s annoying.

Anyhow, will have a few more updates for the guide shortly.

#12

Yeah, but the point s/he was making is you had to change a bunch of stuff in the kernel of Linux before you could compile and run the Interface, while in WIndoze you just had to install a bunch of stuff to compile Interface. And s/he doesn’t want to run Windoze.

#13

What distro are they using? I didn’t have to do any of that when compiling back then, and that was in Fedora!

#14

The LTS version of Ubuntu, apparently.

edited to add:
I went back to my chat logs with them, and pretty much what they said (I have corrected a few typos here and there) was:

“I am not wanting to back port to Ubuntu 16, it doesn’t compile on Ubuntu 18, vcpdu cant even see its own config files, they are using bleeding edge libs and built tools that no packages are available for, everything has to be custom compiled, even qt and python. I am not breaking my system for it to work. I have no idea why they insist on using bleeding edge, when windows forces them to use stable for those versions, its obviously not required else it would’nt run on 16.”

Disclaimer: I know nothing about Linux, other than I’ve occasionally poked LiveCDs with a stick, and I have an ancient turn-a-machine-into-a-netpliance distro running as my email machine, so really personally have no real knowledge of the voracity of the above comments, I’m merely passing it on to you guys to examine, FWIW, YMMV, not valid where prohibited by law, and if it leaves a buildup, on ANYthing, I’m coming back for a refund.

#15

It honestly isn’t that bad. I use Ubuntu 18.04, and it does not take that much work to compile hifi. To be honest, it doesn’t sound like she’s followed the build instructions, which point you to a hifi package for Qt, and tells you which dependencies to install from Ubuntu’s repos. To be fair, the docs are not well maintained, but those docs get you most of the way there. vcpkg pulls and builds anything more exotic for you during the CMake step and some extra environment variables will get you a release version.

Under no circumstances should setting up a build environment for High Fidelity break anyone’s system.

#16

Q if the linux people all love linux so much why dont they agree on and compile a version and share it?
A cos theres 1.2 billion versions of linux and they cant agree which one they should use

i use windows cos "££%% U
:stuck_out_tongue:

#17

I use windows because linux is a bug pain and torture with hard and software. Something simple like a secondlife viewer where already a drama. I bet hify is 70 times worse.

And not sure uf steamVR works on linux. And then all the windows programs i payed for nit work on linux. and…

Well you get it,

#18

Please note this discussion should be referring to the server builds and operation of them. Interface is an entirely different beast itself and I won’t dismiss the issues it presents for Linux, but I would like to keep the focus on servers and how to operate them.

#19

This is super helpful, thank you for writing this up. I run a few domains but am not very tech savvy - I use the whitelisting feature to control people’s access to my domain but am unfamiliar with how to put a script whitelist in my domain. You’ve made it clear this is important so I want to do it immediately, I could use some guidance here, thanks!

#20

Sure!

First, open your domain-server’s page and click on Settings -> Entities.

Then click on Advanced Settings.
image

Scroll down and you will find “Entitiy Scripts Allowed from:” which is the script whitelist.
image

There you go!

2 Likes