Arch Linux User Repository

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.

@d2_ricci and @NukeCode87,

I have created some automation for speeding up the AUR release process for this package.

Please visit this repository and review the README for details:

https://gitlab.com/codrcodz/aur-minecraft-bedrock-server

My next task will be to run the automation described in that README via a CI/CD pipeline that will be scheduled to run every hour.

Until then, one of us can use this automation from any Arch-based host to generate a new AUR release anytime there is a new source zip release from the upstream vendor.

Nice job all. My son is super happy.

I did not realize til now that we were using the azureedge.net instead of the direct minecraft.net link

I will try and get the next update with the suggestion from @nukecode87's suggestions.

@NukeCode87 that also worked for me.

I added those changes, along with some comments in the PKGBUILD file to aid contributors in the future, and I cut a new release.

Thanks for the help. Good team effort. I'll work on automating the update process for future releases.

This worked for me.

# Maintainer: Alan Beale <the.mrabz@gmail.com>

pkgname=minecraft-bedrock-server
pkgver=1.21.42.01
pkgrel=1
pkgdesc="Minecraft Bedrock Server for Windows 10 and Xbox One versions of Minecraft"
arch=('x86_64')
url="https://www.minecraft.net/en-us/download/server/bedrock"
license=('custom')
noextract=('bedrock-server-${pkgver}.zip')
backup=(opt/minecraft-bedrock-server/{server.properties,permissions.json,whitelist.json,allowlist.json})
makedepends=('unzip')
source=("https://www.minecraft.net/bedrockdedicatedserver/bin-linux/bedrock-server-${pkgver}.zip"
        'minecraft-bedrock-server.service'
        'minecraft-bedrock-server.sysusers'
        'minecraft-bedrock-server.tmpfiles')

sha256sums=('6d352cb588e6cfeacba5c272e3b4acb669526029fb8afb35f0861e6afb274776'
            'cc08effe04701f1ca16a1edd153d12a94ed498e9a3e68a004b74189eef9edb81'
            'a7070301958b58f804bb8dee8b66ef23ad7460403f7ba2cfffb549e29ad834d5'
            '829ff9e583408fcc1d0436a6896ecbd3128f893dcbc2b0147130219a13586ae3')

DLAGENTS=("https::/usr/bin/curl -A 'Mozilla' -fLC - --retry 3 --retry-delay 3 -o %o %u")

build() {
    unzip -q bedrock-server-${pkgver}.zip -d tmp
    rm bedrock-server-${pkgver}.zip
}

package() {
    install -d "$pkgdir"/opt/minecraft-bedrock-server
    cp -r -fHip "$srcdir"/tmp/* "$pkgdir"/opt/minecraft-bedrock-server
    install -Dm 644 minecraft-bedrock-server.service -t "$pkgdir"/usr/lib/systemd/system/
    install -Dm 644 minecraft-bedrock-server.sysusers "$pkgdir"/usr/lib/sysusers.d/minecraft-bedrock-server.conf
    install -Dm 644 minecraft-bedrock-server.tmpfiles "$pkgdir"/usr/lib/tmpfiles.d/minecraft-bedrock-server.conf
}

Reading through the Minecraft EULA, we are free to redistribute. Why not host it on a git repo with the Microsoft EULA posted there under that page?

I don't think we'd even need to repackage it. Just the pain of manually uploading it there and moving the upstream URL to the new git.

Seems the windows side was experiencing similar issues and posted an updated fix.

I'm still reading through what they changed to get it working. https://www.reddit.com/r/Minecraft/s/OXmCv0Nhw2

@Abzie, good to know. I rarely visited the download page directly except to send you some hash and version updates occasionally, so I didn't notice this.

I'll do some more testing with various DLAGENTs then. Managing a user agent string is a much smaller lift that writing a whole Selenium script thing. It is annoying and I do understand why you wouldn't want to take that on.

Thanks again for all your previous work @Abzie.

If anyone figures out the right DLAGENT string to use before I do, feel free to post it here and I will test it and update the package.

The checkbox has been a thing for some time, long before they restricted direct downloads, I doubt you need to bypass a checkbox.

@Abzie, thanks for that. I used a headless chrome browser during my testing which resulted in the download hanging, so at that point I assumed that it was the checkbox and not the DLAGENT, but it very well could have been the DLAGENT (or maybe you need both).

Either way, re-hosting the source zip elsewhere (Option 2) definitely bypasses this issue. If both the DLAGENT and checkbox need to be addressed, it makes Option 1 that much harder to implement.

@codrcodz: please see my previous comment: https://aur.archlinux.org/packages/minecraft-bedrock-server#comment-995878

@d2_ricci, I added you as a co-maintainer. Feel free to update the SHAs and version strings in the PKGBUILD using the previous commits as a template for what all needs to be changed.

Be advised though that the crux of the issue here are the changes to the download requirements for that source zip file that you posted in your comment. The download page now has a checkbox on it (for acceptance of their license agreement) that must be clicked before a download will be allowed to take place.

Based on my testing, even if I scrape the page's source HTML and figure out the latest URL for the zip file, I can't just download it with wget or similar command-line tooling that doesn't support the page's new Javascript code, and even when switching to using a headless browser (chrome, firefox, etc), the download just hangs because the session data doesn't show that the checkbox has been clicked. I believe that their intent is to make automatic downloads painful for downstream package maintainers to ensure people are explicitly accepting the license agreement as opposed to implicitly accepting it and/or they want a better count of total downloads and stats around when they take place and by who.

This will require one of two approaches (that I can think of) to work-around it:

Option 1

Use something like Selenium along with a headless browser to click the checkbox so that the file can be downloaded automatically and then installed like usual.

Pros

• Does not attempt to bypass the license agreement acceptance requirement, so we are at lower risk of attracting the M$ Eye of Sauron (aka the collective eye of its horde of bored lawyers).
• We would still be allowing the user to pull the source zip directly from the upstream vendor, which is better from a security perspective.
• Does not require any additional infrastructure to host the source zip in an alternate location.

Cons

• Requires a lot of new build dependencies for this package (Selenium, Python, a browser, etc).
• I am not too familiar with Selenium or AUR package management yet, so there will be a bit of a learning curve for me to get this working.

Option 2

Scrape the page for new versions and send out automatic alerts to download them manually, and then upload and host them somewhere else that doesn't require crazy dependencies to automatically install the source zip.

Pros

• Does not require any new build dependencies or build method; just changes the source URL for the zip.
• Does not require me to learn Selenium, Python better, and we can incrementally, more slowly learn more about AUR packaging.

Cons

• Although I didn't see anything mentioned in the license agreement, M$ clearly put this new download method in place for a reason, and if we start hosting the source zip elsewhere, we risk attracting unwanted attention. If we go this route, I plan to post a link to the license agreement and pin it here to do our best to meet their intent.
• We would be hosting the source zip somewhere else, thereby taking on responsibility for the security of that file. We could mitigate some of that risk by using Gitlab's package repository feature to host the source code zip there, with appropriate security on the member accounts with access to that repository.
• Requires additional infrastructure (Gitlab or Github account) to host and manage updates; luckily, I'm pretty familiar with CI/CD pipelines, automation, and Gitlab's package repository, so this is a pretty minor con.

@d2_ricci, your thoughts (and anyone else's) on this would be greatly appreciated. If anyone else has ideas for options besides the two listed, I'm open to those as well.