Starting with version 1.21.50.10, this AUR package uses an automated process for doing the following:
This automated process does NOT test the functionality of the new source code itself. The upstream vendor (Mojang) may release non-functional software or change how it must be installed.
In either case, this AUR package may successfully install, but the Bedrock Minecraft server may not launch or run properly.
The automation might fail to increment this package to the latest version if there is a major change to the release mechanism used by the upstream vendor of the source zip file (i.e. they move it to a totally new URL, they significantly change the layout of the download page, et cetera).
The current download page is hosted here:
The "Minecraft Dedicated Server software for Ubuntu (Linux)" source zip file is the one that should be referenced in the PKGBUILD file for this AUR package.
Please report any issues with the AUR package build automation, the AUR package PKGBUILD file contents, or the systemd unit files used to run the server in a comment here.
Issues with the upstream vendor's source code should be reported to the upstream vendor.
If you are curious to see how the AUR package build automation works to automatically increment the package version each time there is a new release by the upstream vendor, please visit this page:
Good ole M$, you will now see the following message in the console log on startup:
================ TELEMETRY MESSAGE ===================
Server Telemetry is currently not enabled.
Enabling this telemetry helps us improve the game.
To enable this feature, add the line 'emit-server-telemetry=true'
to the server.properties file in the handheld/src-server directory
======================================================
If you do wish to enable "telemetry", add the line to /opt/minecraft-bedrock-server/server.properties.
Out of curiosity, had anyone had errors with updating with paru? Specifically the zst not found, missing or corrupt? I do a paru -Scc and that fixes it but I find it odd having to do this every time for the past few months.
This is unrelated to the AUR DDoS as I check status before I update.
Done. I sent you a merge request with the code I used to update from 1.21.90.4 to 1.21.91.1. I also opened an issue I ran into with a missing folder/file when trying to run it from a clean environment. I have almost no docker experience and didn't feel confident I know the best solution for that issue, though I suspect its as simple as creating the missing folder & file.
@NukeCode87,
Looking at the main.go in that Bedrock release repo, it looks like there is actually a Mojang-provided API endpoint (https://net-secondary.web.minecraft-services.net/api/v1.0/download/links) that will respond with only the latest download URLs by default. That makes the process even more simple. With that, the need to scrape the dynamic webpage goes away, as does relying on this extra repository maintained by someone else. I can easily cut the automation over to using that API URL instead.
Here is the current json from that API endpoint, as an example:
{
"result": {
"links": [
{
"downloadType": "serverBedrockWindows",
"downloadUrl": "https://www.minecraft.net/bedrockdedicatedserver/bin-win/bedrock-server-1.21.90.4.zip"
},
{
"downloadType": "serverBedrockLinux",
"downloadUrl": "https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-1.21.90.4.zip"
},
{
"downloadType": "serverBedrockPreviewWindows",
"downloadUrl": "https://www.minecraft.net/bedrockdedicatedserver/bin-win-preview/bedrock-server-1.21.100.21.zip"
},
{
"downloadType": "serverBedrockPreviewLinux",
"downloadUrl": "https://www.minecraft.net/bedrockdedicatedserver/bin-linux-preview/bedrock-server-1.21.100.21.zip"
},
{
"downloadType": "serverJar",
"downloadUrl": "https://piston-data.mojang.com/v1/objects/6e64dcabba3c01a7271b4fa6bd898483b794c59b/server.jar"
}
]
}
}
@NukeCode87,
That looks promising. I can add that into the existing automation to grab the latest version instead of the way I was doing it previously. I will have some free time tomorrow to work on that. Feel free to fork the automation repo and work on it yourself in the meantime if you're comfortable doing so. MRs are always welcome. :-D
Manually updated to 1.21.90.4.
I believe the automated update pipeline is broken because of some changes that MS has made to the download page. The download page from MS previously provided you with a link hidden in the HTML on page load (until you clicked Accept on the license it was disabled, but still present). We were previously able to read that and download it without really interacting with the page. Now, however, the HTML you get is essentially junk unless you have JavaScript enabled. It is going to take some tinkering to get the automated updates working again.
I'd read that it updated automatically. Maybe something went wrong in that process or it requires some specific configuration? Mine didn't update, even after restarting the service. No errors are seen in the log either.
@codrcodz Thanks for the reply. I was forwarding ports using the default ones, but the others couldn't connect. I changed the ports to 5773 and 5779 and set up port forwarding to these new ones, and they were able to connect with my public IP and the new port. It works perfectly. 😊
@laWiskaPY had a great question.
"It works for local play, but I can't get it to work so others from other networks can connect. This should be able to do it, right?"
Yes and no. This package can be part of a remotely-accessible self-hosted Minecraft Bedrock server solution, but there are some other pieces to the puzzle.
A big piece is a client-side configuration that must be made. Namely, you need a workaround to enable custom servers on remote Bedrock clients, which do not natively support them in the same way that Java Minecraft clients do. If the Bedrock client is natively hosted on or VPNed into the same network as the Bedrock server, and that server is presenting the server on the default port, the client should auto-detect the server automagically, otherwise, you need to perform this client-side configuration.
This Github project outlines a method for presenting your self-hosted Bedrock server to remote clients. The DNS server described in this project can be self-hosted, or you can just leverage the one already being hosted by the project's maintainer. The former is slightly more secure, but either approach requires at least some level of trust in the maintainer.
https://github.com/Pugmatt/BedrockConnect
Once you have made the client-side changes described in the README of that project, you will also need to do some port forwarding on your router (if hosting from a computer inside your home network). This step will be router-specific, so I cannot provide much more than generic help with this part, but the goal will be to forward a port on your router's IP to one on the computer hosting the Minecraft Bedrock server. The default Bedrock port is 19132. You can change this in the server's configuration, but I would not recommend it in most cases. If you are not sure what your router's public IP address is, you can hit this URL from a browser on a machine inside of your network and it will return your router's public IP address.
If you want, you can make a DNS entry, (if you have a domain name), and you can point a DNS A record at that public IP address. If your router's IP changes frequently, consider using a DNS provider that supports dynamic DNS, and host a daemon on a machine in your home network that will update the record with the DNS provider as your IP changes.
Alternately, you can just reference the server by IP and not worry about the DNS entry at all. You can also host it on a virtual machine in a public cloud if you do not want to worry about configuring port forwarding on your router, but that will cost you a hosting fee, of course.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
Self-Hosting a Remotely-Accessible Minecraft Bedrock Server From Your Home Network
@laWiskaPY had a great question.
Yes and no. This package can be part of a remotely-accessible self-hosted Minecraft Bedrock server solution, but there are some other pieces to the puzzle.
A big piece is a client-side configuration that must be made. Namely, you need a workaround to enable custom servers on remote Bedrock clients, which do not natively support them in the same way that Java Minecraft clients do. If the Bedrock client is natively hosted on or VPNed into the same network as the Bedrock server, and that server is presenting the server on the default port, the client should auto-detect the server automagically, otherwise, you need to perform this client-side configuration.
This Github project outlines a method for presenting your self-hosted Bedrock server to remote clients. The DNS server described in this project can be self-hosted, or you can just leverage the one already being hosted by the project's maintainer. The former is slightly more secure, but either approach requires at least some level of trust in the maintainer.
https://github.com/Pugmatt/BedrockConnect
Once you have made the client-side changes described in the README of that project, you will also need to do some port forwarding on your router (if hosting from a computer inside your home network). This step will be router-specific, so I cannot provide much more than generic help with this part, but the goal will be to forward a port on your router's IP to one on the computer hosting the Minecraft Bedrock server. The default Bedrock port is 19132. You can change this in the server's configuration, but I would not recommend it in most cases. If you are not sure what your router's public IP address is, you can hit this URL from a browser on a machine inside of your network and it will return your router's public IP address.
https://ipv4.icanhazip.com/
If you want, you can make a DNS entry, (if you have a domain name), and you can point a DNS A record at that public IP address. If your router's IP changes frequently, consider using a DNS provider that supports dynamic DNS, and host a daemon on a machine in your home network that will update the record with the DNS provider as your IP changes.
Alternately, you can just reference the server by IP and not worry about the DNS entry at all. You can also host it on a virtual machine in a public cloud if you do not want to worry about configuring port forwarding on your router, but that will cost you a hosting fee, of course.