Everything went smooth except that the running server appears with “dev” protocol instead of 2022.1.0 and configurable from the :40100 port (nice new the server setup).
I’m stuck however on how to have it be compatible with 2022.1.0.
We really need to understand this for two main motivations:
Some of our teachers have linux but NOT Ubuntu 18.04, where server installation is trivial. On Ubuntu 20.04 installation without docker is definitely not trivial. They would love to have a private server for their schools running on linux 20.04.
Our main server is running Debian so I definitely need to run server on it without buying a new hardware infrastructure
Thanks for any hints, and sorry if this had been already explained. In such case thanks for pointing to url or pages.
I have not looked at the Docker building in a few weeks when I had problems myself building the image. The Dockerfiles’s use vircadia-builder to build the image and it’s done in two phases to try to create a smaller Docker image (the building of Qt creates a several gigabyte image). vircadia-builder changed to use a binary Qt for Ubuntu 18.04 but it has to build Qt for 20.04 which is what takes the 14h). The current state of the build scripts don’t work for 18.04 because it doesn’t know how to install the binary Qt in the second phase.
I need to revisit the build scripts and figure out what needs doing but a short term fix could be to create a single Dockerfile that uses vircadia-builder for Ubuntu 18.04 which would use the binary Qt.
I don’t understand what you’re saying about getting “dev” protocol. The build scripts, by default, clone the “master” branch which should be the latest release. If you want the 2022.1.0 release, setting the environment variable to that tag (“export VIRCADIA_TAG=2022.1.0”). If that’s not working, it’s a bug.
I thought I did it specifying the first parameter of buildDS.sh, I need to look at the script more in deep, in theory it should be relatively easy to be sure it takes a specific tag. Thanks for answering and kudos for the docker image idea
buildDB.sh takes that parameter but buildBase.sh doesn’t. Not a consistent UI. It’s better to use the environment variable so the tag is set in both scripts.
Also, changing the version of Ubuntu is not perfect as it needs to be manually changed in multiple places – both in the “FROM” statement and in the later “–get-source-deps” parameter to vircadia-builder.
I’m not a Docker wizard so, if there is another way to build a reasonable size image I’d be excited to hear it. I also need to talk to Dale about how to install Qt when the binary version is used.
I took much part of the week end trying to recompile the docker image trying to specify 2022.1.0, but had no luck. What is strange is that apparently it is compiling the 2022.1.0 version, but when launching the server it keeps in showing dev and so I could not connect from standard client. Surely I am missing something or I am doing some error.
I have seen that vircadia on github has forked your repository so it seems it is a valuable asset for core developer and community.
Can I suggest if @Kalila or others core-devs would help in producing an “official” docker image that can be used in such situation where you cannot start from a real server on ubuntu 18.04?
The “official” way of producing a server with 18.04 is NOT working under docker since docker is lacking systemctl support (or at least I wasnt able to make it run).
If you start from Ubuntu 18.04 image the process should be quite rapid, and core-developers should know very well how to handle possible problems coming from docker.
Again it would be really powerful, and High Fidelity did provide a docker image full working that I successfully used years ago.
Still keep trying. I observed that vircadia builder is assuming DEV if called without a specific release-type. Since I havent found any documentation so far about vircadia builder I added in Dockerfile_base (in addition to downgrading to 18.04 to have a quicker build in the two locations suggested by @Misterblue , also the following where added the --release-type=production parm
RUN cd /opt/vircadia/vircadia-builder \
&& ./vircadia-builder \
--repo=$REPO \
--tag=$TAG \
--build=domain-server,assignment-client,ice-server \
--destdir /opt/vircadia \
--release-type=production \
--auto
Building for Ubuntu 18.04 uses the binary Qt. The second phase of the build expects the Qt executable to be in /opt/vircadia/qt5-install/lib but Qt is not there if the binary Qt is installed. This causes the executables that vircadia-builder creates (/opt/vircadia/install_master/run_domain-server) to fail since Qt is not present there.
It would be nice if vircadia-builder had an --install-binary-qt parameter that would do the magic to install the binary Qt if it was available. The run scripts would also have to be enhanced.
Ok after the nth rebuilding it seems now working!
the client could connect. The only thing still strange is that the version declared by the nodes is empty, so probably allows every client version to connect to.
Unless this is a problem I think I eventually managed to solve the problem.
In such case should I push a pull request on your github to add the --release-type=production in the Dockerfile_base ?
Or should it be simply specified in the README?
I understood the thing about the qt, but as I wrote the problem was in having the version named DEV in the nodes which were preventing any connection from outside.
Still to be solved how to make version be completely equivalent to the “official” distro.
It worked with ubuntu 20.04, even if on the 12 core server it took a couple of hours
