Question: send invitation with the owner's account

[josecelano]

Can invitations be sent using the owner's account? I get the error "You do not have enough invites!"

I can't find any docs.

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[HDVinnie]

Hello. Please try and keep the issue tracker to issues and requests only.

You can add invites to your account a few ways. Easiest being by going to Staff Dashboard. Select User Search. Find your account and click edit. Then adjust your invites count.

[josecelano]

Hello. Please try and keep the issue tracker to issues and requests only.

You can add invites to your account a few ways. Easiest being by going to Staff Dashboard. Select User Search. Find your account and click edit. Then adjust your invites count.

OK, thank you!! I was looking there but didn't see it :-/:

Where should I ask these questions?

[HDVinnie]

Unfortunately at the time we only offer support to subscribers on Polar via our Discord server. While it might not be practical for all, subscribers have helped this FOSS project continue and are needed to do so. It's a large and time consuming project and currently one of the very few out there actively maintained.

[josecelano]

Unfortunately at the time we only offer support to subscribers on Polar via our Discord server. While it might not be practical for all, subscribers have helped this FOSS project continue and are needed to do so. It's a large and time consuming project and currently one of the very few out there actively maintained.

Hey @HDVinnie I understand, I'm also contributing to a BitTorrent Index. I'm installing the Index to check a fully featured index. Ours is still very simple and we want to define our roadmap. I would like to write a post about the installation process on our blog. Is that OK for you? I only want to let more people know about this index and also give our feedback about the software, especially the installation process. We plan to use our blog not only for internal stuff but also to promote the BitTorrent ecosystem.

[HDVinnie]

Unfortunately at the time we only offer support to subscribers on Polar via our Discord server. While it might not be practical for all, subscribers have helped this FOSS project continue and are needed to do so. It's a large and time consuming project and currently one of the very few out there actively maintained.

Hey @HDVinnie I understand, I'm also contributing to a BitTorrent Index. I'm installing the Index to check a fully featured index. Ours is still very simple and we want to define our roadmap. I would like to write a post about the installation process on our blog. Is that OK for you? I only want to let more people know about this index and also give our feedback about the software, especially the installation process. We plan to use our blog not only for internal stuff but also to promote the BitTorrent ecosystem.

That is 100% fine with me and thanks for understanding. I will note that we will be releasing v8.2.0 this weekend which adds about 450 commits. Master vs v8.x.x branch which includes some big changes. You might want to wait for that to be released and then run php artisan git:update to get latest code. I will also note that the default unit3d uses php queue announce for tracker. One of the core devs @Roardom however has created UNIT3D-Announce which is written in rust. We have been having it used in prod on a few sites now and should be released soon.

[josecelano]

Unfortunately at the time we only offer support to subscribers on Polar via our Discord server. While it might not be practical for all, subscribers have helped this FOSS project continue and are needed to do so. It's a large and time consuming project and currently one of the very few out there actively maintained.

Hey @HDVinnie I understand, I'm also contributing to a BitTorrent Index. I'm installing the Index to check a fully featured index. Ours is still very simple and we want to define our roadmap. I would like to write a post about the installation process on our blog. Is that OK for you? I only want to let more people know about this index and also give our feedback about the software, especially the installation process. We plan to use our blog not only for internal stuff but also to promote the BitTorrent ecosystem.

That is 100% fine with me and thanks for understanding. I will note that we will be releasing v8.2.0 this weekend which adds about 450 commits. Master vs v8.x.x branch which includes some big changes. You might want to wait for that to be released and then run php artisan git:update to get latest code. I will also note that the default unit3d uses php queue announce for tracker. One of the core devs @Roardom however has created UNIT3D-Announce which is written in rust. We have been having it used in prod on a few sites now and should be released soon.

Wow! Cool!, I will wait and update it! By the way, I knew about that tracker, and I was wondering why you decided to build your own tracker in Rust, there are many robust alternatives:

• https://github.com/torrust/torrust-tracker (I'm contributing to this one)
• https://github.com/greatest-ape/aquatic
• https://github.com/Power2All/torrust-actix

What are your particular requirements, if any?

[Roardom]

What are your particular requirements, if any?

The biggest priority was reducing database load. Every announce will need to update the following tables:

• history: maintains record of total upload/download user has contributed on each torrent. Also saves total seedtime, immune status, and a few other things used for hit and run calculation.
• peers: maintains a copy of the tracker's peers to save state when shutting down, and to view the peers through the front-end, and to join with other database tables.
• torrents, maintains seeder, leecher and times_completed counts that can be sorted by on the torrent search page (normalized sorting by count of the peers relation takes too long). Also keeps a balance of total upload - total download (Again, denormalized for performance). If this is not 0, it signifies one of the peers is cheating (or there's current swarm activity).
• users: keeps track of the denormalized total upload and download of a user. This stat is used in a lot of places like navbar, group promotion calculation, and more. Keeping it normalized would be too slow.

As far as I'm aware (I've looked through most of these at some point in time), all the trackers listed don't keep these sorts of statistics, and when they're backed by an sql store, they only run one sql query per update, which becomes a huge bottleneck. UNIT3D-Announce follows a design more similar to gazelle's ocelot, where all updates are batched into longer INSERT ... ON DUPLICATE KEY UPDATE ... queries on the primary key to minimize database load.

It also keeps track of failed updates, and re-inserts them into the next queued update upon failure. Unlike ocelot, even if the tracker is receiving more announces than the database can keep up with, all updates will eventually be inserted, although delayed, since all announces of the same user/torrent combination will be merged and count as a single update. And the tracker operator can control the frequency of records to be updated per second, which can be useful when restarting the tracker and old rtorrent clients with weak exponential backoff flood the server creating a ddos.

There are also other features like freeleech tokens, personal freeleeches, featured torrents, leech slots, peer_id blacklist, and connectable port checking that weren't really offered by anything in the ecosystem and I didn't want to modify ocelot to suit our database schema plus any other future features. We also want to integrate inline bonus point calculation into the tracker eventually as well since that takes a good 30 seconds of blocking upserts every hour currently.

What the trackers you listed offer that UNIT3D-Announce doesn't however is better performance on the tracker side. While I optimized the tracker to handle 50-100k+ req/s/core on modern hardware, I've never reached the numbers seen in those repos. UDP support also seems efficient (although I haven't looked into it too much yet and not sure if it would be suitable for private tracker use). In any case, UNIT3D-Announce now hovers on less than 0.5% cpu usage in prod with mysql using substantially more, so the database remains the bottleneck. Nginx and TLS also add a substantial amount of overhead too (Especially since libtorrent clients don't support sending multiple announces per http connection). I also didn't optimize the handling of clearing stale peers and currently blocks all other announces for the under half a second it takes to iterate through all the peers.

Hopefully that provides the info you seek, let me know if you have any other questions.

[josecelano]

Hi @Roardom, thank you for your detailed response!

What are your particular requirements, if any?

The biggest priority was reducing database load. Every announce will need to update the following tables:

• history: maintains record of total upload/download user has contributed on each torrent. Also saves total seedtime, immune status, and a few other things used for hit and run calculation.
• peers: maintains a copy of the tracker's peers to save state when shutting down, and to view the peers through the front-end, and to join with other database tables.
• torrents, maintains seeder, leecher and times_completed counts that can be sorted by on the torrent search page (normalized sorting by count of the peers relation takes too long). Also keeps a balance of total upload - total download (Again, denormalized for performance). If this is not 0, it signifies one of the peers is cheating (or there's current swarm activity).
• users: keeps track of the denormalized total upload and download of a user. This stat is used in a lot of places like navbar, group promotion calculation, and more. Keeping it normalized would be too slow.

That's something interesting I have not considered. I like the idea of using events and subscribers to build the database projections (maybe something customizable via plugins) but that could have performance issues. I've collected al the discussions about statistics:

https://github.com/torrust/torrust-tracker/discussions/820

It's definitively a missing feature if you want to connect the tracker to an index. We are about to release the version 3.0.0. After relating, we want to review our roadmap together, collecting feedback from users/community. I want to research what the indexes need from a tracker, and your tracker looks like a good one to learn, considering it is built on purpose for an advanced index.

As far as I'm aware (I've looked through most of these at some point in time), all the trackers listed don't keep these sorts of statistics, and when they're backed by an sql store, they only run one sql query per update, which becomes a huge bottleneck. UNIT3D-Announce follows a design more similar to gazelle's ocelot, where all updates are batched into longer INSERT ... ON DUPLICATE KEY UPDATE ... queries on the primary key to minimize database load.

I guess you mean this tracker: https://github.com/WhatCD/Ocelot (just to confirm).

It also keeps track of failed updates, and re-inserts them into the next queued update upon failure. Unlike ocelot, even if the tracker is receiving more announces than the database can keep up with, all updates will eventually be inserted, although delayed, since all announces of the same user/torrent combination will be merged and count as a single update. And the tracker operator can control the frequency of records to be updated per second, which can be useful when restarting the tracker and old rtorrent clients with weak exponential backoff flood the server creating a ddos.

What are you using, a buffer? a queue? I will take a look at the code in the next weeks and, of course, before implementing any new feature related to statistics in our tracker.

There are also other features like freeleech tokens, personal freeleeches, featured torrents, leech slots, peer_id blacklist, and connectable port checking that weren't really offered by anything in the ecosystem and I didn't want to modify ocelot to suit our database schema plus any other future features. We also want to integrate inline bonus point calculation into the tracker eventually as well since that takes a good 30 seconds of blocking upserts every hour currently.

That's a lot of stuff. I have in mind a generic event store so users can build their own statistics. Maybe we can provide a "plugin" example with the most common statistics.

What the trackers you listed offer that UNIT3D-Announce doesn't however is better performance on the tracker side. While I optimized the tracker to handle 50-100k+ req/s/core on modern hardware, I've never reached the numbers seen in those repos. UDP support also seems efficient (although I haven't looked into it too much yet and not sure if it would be suitable for private tracker use). In any case, UNIT3D-Announce now hovers on less than 0.5% cpu usage in prod with mysql using substantially more, so the database remains the bottleneck. Nginx and TLS also add a substantial amount of overhead too (Especially since libtorrent clients don't support sending multiple announces per http connection). I also didn't optimize the handling of clearing stale peers and currently blocks all other announces for the under half a second it takes to iterate through all the peers.

Yes, the Torrust Tracker is not the fastest one. The more features you add, the fewer requests you can't handle. The tracker's performance increases significantly when you disable statistics, logging, etcetera. Some trackers are specifically designed to be fast, but I suppose they can only be used for public trackers.

Regarding UDP, it's not suitable for a private tracker. At least officially, there is no specification to run a private UDP tracker. We don't support it. I don't know any implementation, although I was researching a little bit some months ago, and in theory, it could be possible to implement one.

Hopefully that provides the info you seek, let me know if you have any other questions.

That was perfect, thank you very much! Maybe in the future, I would appreciate more feedback if we decide to implement more complex statistics features.

[Roardom]

It's definitively a missing feature if you want to connect the tracker to an index. We are about to release the version 3.0.0. After relating, we want to review our roadmap together, collecting feedback from users/community. I want to research what the indexes need from a tracker, and your tracker looks like a good one to learn, considering it is built on purpose for an advanced index.

Most people seem to prefer Gazelle as their favorite framework as an end-user. It was developed by WhatCD many years ago now: https://github.com/whatcd/gazelle. The most updated forks are probably https://github.com/opsnet/gazelle and https://github.com/biotorrents/gazelle, and maybe https://github.com/empornium/luminance as well.

Unfortunately, being mostly designed by ancient php versions without a framework, they had quite the spaghetti code which has earned them a bad name with many developers not enjoying the quirks it has. The forks have made it one of their main goals to clean up the code, but it's a never ending process with just how large the codebase is.

Side note: Originally years ago before gazelle, tbdev was one of the first torrent trackers. Many ancient sites still use it. It was forked to xbtit, which itself had forks (premium ones). These trackers use xbt as their backend (https://github.com/OlafvdSpek/xbt). There was also U-232. UNIT3D was first started by a team of devs that were moving from xbtit wanting to skip past gazelle's spaghetti code and rewrite another tracker from the ground up in a modern framework.

I guess you mean this tracker: https://github.com/WhatCD/Ocelot (just to confirm).

Correct. Its most updated forks are probably https://github.com/opsnet/ocelot and https://github.com/empornium/radiance. Many sites don't open source their modifications unfortunately. Same thing with the indexers.

It also keeps track of failed updates, and re-inserts them into the next queued update upon failure. Unlike ocelot, even if the tracker is receiving more announces than the database can keep up with, all updates will eventually be inserted, although delayed, since all announces of the same user/torrent combination will be merged and count as a single update. And the tracker operator can control the frequency of records to be updated per second, which can be useful when restarting the tracker and old rtorrent clients with weak exponential backoff flood the server creating a ddos.

What are you using, a buffer? a queue? I will take a look at the code in the next weeks and, of course, before implementing any new feature related to statistics in our tracker.

An IndexMap (https://docs.rs/indexmap/) indexed by (user_id, torrent_id) for history, (user_id, torrent_id, peer_id) for peers (peer id given by the bittorrent client), torrent_id for torrents, and user_id for users. I first load all the users, torrents, and everything into memory so I don't need to fetch them from the database every announce and only have to update them given I already know their key. Most statistics are updated using deltas so I can simply add the deltas together while they're queued up if there's already an update for the same record in queue, otherwise I insert a new record into the IndexMap. Every x seconds (configurable - but currently limited to seconds, I want to change this to milliseconds in the future), ~4000 records are popped off (not too many that we go over mysql's 65k binding limit), and upserted into the database. If the query fails, those records are pushed back onto the front of the indexmap, ready for the next interval.

The tracker itself is fairly small. Half the codebase size consists of the lock file. The main loop is in src/announce.rs. src/scheduler consists of the queues/buffers (they're not really queues because each entry is updatable while it's queued, but not sure what to call them). src/tracker consists of all the tracker state outside of the queues.

There are also other features like freeleech tokens, personal freeleeches, featured torrents, leech slots, peer_id blacklist, and connectable port checking that weren't really offered by anything in the ecosystem and I didn't want to modify ocelot to suit our database schema plus any other future features. We also want to integrate inline bonus point calculation into the tracker eventually as well since that takes a good 30 seconds of blocking upserts every hour currently.

That's a lot of stuff. I have in mind a generic event store so users can build their own statistics. Maybe we can provide a "plugin" example with the most common statistics.

Most of this stuff is handled by the php portion of UNIT3D. It sends an api call to the tracker every time a freeleech token is used, personal freeleech is bought, torrent is featured, leech slots are updated, peer_id is blacklisted, etc. so that it can update its hashmaps. We had to do our connectable port checking inline otherwise we were getting deadlocks in the database from too many queries happening at once.

Regarding UDP, it's not suitable for a private tracker. At least officially, there is no specification to run a private UDP tracker. We don't support it. I don't know any implementation, although I was researching a little bit some months ago, and in theory, it could be possible to implement one.

Well I suppose I can toss out that performance improvement idea then, shucks.

Hopefully that provides the info you seek, let me know if you have any other questions.

That was perfect, thank you very much! Maybe in the future, I would appreciate more feedback if we decide to implement more complex statistics features.

Feel free to ping me if you ever need anything.

[josecelano]

Hi @Roardom, Thank you! I like your "index history summary", and I think it would make a good blog post. I've been working on BitTorrent projects for only two years, and I have not found in general good documentation or good articles about tools, tutorials, software comparisons, etc. THis was the best list of trackers and what software they are using I have found so far: https://hdvinnie.github.io/Private-Trackers-Spreadsheet/

Thank you for giving me an idea about how the tracker works internally. Maybe I could get some ideas to improve the way we share statistics between the tracker and the index. We are using a REST API but I don't think it is efficient (and we are only importing the number of leechers and seeders from the tracker). I have been trying to improve the performance a little bit with mini optimizations: https://github.com/torrust/torrust-index/issues/569.

I suppose your tacker and index use the same database. I mean the index just make API calls to update the tracker in-memory data but the tracker shares statistics with the index directly using the same database? If it's not the case, how you get the statistics from the tracker?

[Roardom]

I suppose your tacker and index use the same database. I mean the index just make API calls to update the tracker in-memory data but the tracker shares statistics with the index directly using the same database? If it's not the case, how you get the statistics from the tracker?

Yes, they share the same database. In essence, the tracker is just a write-behind cache.

When UNIT3D-Announce is started, it connects to the mysql database and fetches all torrents in a single query and loads it into an IndexMap. When a new torrent is uploaded on UNIT3D, it sends a REST HTTP api call to UNIT3D-Announce to insert the new torrent into the IndexMap.

[josecelano]

Unfortunately at the time we only offer support to subscribers on Polar via our Discord server. While it might not be practical for all, subscribers have helped this FOSS project continue and are needed to do so. It's a large and time consuming project and currently one of the very few out there actively maintained.

Hey @HDVinnie I understand, I'm also contributing to a BitTorrent Index. I'm installing the Index to check a fully featured index. Ours is still very simple and we want to define our roadmap. I would like to write a post about the installation process on our blog. Is that OK for you? I only want to let more people know about this index and also give our feedback about the software, especially the installation process. We plan to use our blog not only for internal stuff but also to promote the BitTorrent ecosystem.

That is 100% fine with me and thanks for understanding. I will note that we will be releasing v8.2.0 this weekend which adds about 450 commits. Master vs v8.x.x branch which includes some big changes. You might want to wait for that to be released and then run php artisan git:update to get latest code. I will also note that the default unit3d uses php queue announce for tracker. One of the core devs @Roardom however has created UNIT3D-Announce which is written in rust. We have been having it used in prod on a few sites now and should be released soon.

Hi @HDVinnie I've just written a draft for the blog post in our blog:

https://github.com/torrust/torrust-website/pull/237

I will:

• Continue using it for a few days and review it with colleagues.
• Wait until you release the v8.2.0 version and update our installation.
• Publish the blog post.

Feel free to let me know if you have any comments or suggestions. It's not a comprehensive review because this is the first index I've installed and the only one I know apart from the one I'm contributing to.

[HDVinnie]

Unfortunately at the time we only offer support to subscribers on Polar via our Discord server. While it might not be practical for all, subscribers have helped this FOSS project continue and are needed to do so. It's a large and time consuming project and currently one of the very few out there actively maintained.

Hey @HDVinnie I understand, I'm also contributing to a BitTorrent Index. I'm installing the Index to check a fully featured index. Ours is still very simple and we want to define our roadmap. I would like to write a post about the installation process on our blog. Is that OK for you? I only want to let more people know about this index and also give our feedback about the software, especially the installation process. We plan to use our blog not only for internal stuff but also to promote the BitTorrent ecosystem.

That is 100% fine with me and thanks for understanding. I will note that we will be releasing v8.2.0 this weekend which adds about 450 commits. Master vs v8.x.x branch which includes some big changes. You might want to wait for that to be released and then run php artisan git:update to get latest code. I will also note that the default unit3d uses php queue announce for tracker. One of the core devs @Roardom however has created UNIT3D-Announce which is written in rust. We have been having it used in prod on a few sites now and should be released soon.

Hi @HDVinnie I've just written a draft for the blog post in our blog:

https://github.com/torrust/torrust-website/pull/237

I will:

• Continue using it for a few days and review it with colleagues.

• Wait until you release the v8.2.0 version and update our installation.

• Publish the blog post.

Feel free to let me know if you have any comments or suggestions. It's not a comprehensive review because this is the first index I've installed and the only one I know apart from the one I'm contributing to.

Awesome. Will definitely give it a read and provide feedback when I get home. UNIT3D v8.2.0 has been released and you can simply run sudo php artisan git:update and say yes to all steps.

Also if you use discord we're more then happy to invite you to our server to chat more easily if that works for you.

[josecelano]

Unfortunately at the time we only offer support to subscribers on Polar via our Discord server. While it might not be practical for all, subscribers have helped this FOSS project continue and are needed to do so. It's a large and time consuming project and currently one of the very few out there actively maintained.

Hey @HDVinnie I understand, I'm also contributing to a BitTorrent Index. I'm installing the Index to check a fully featured index. Ours is still very simple and we want to define our roadmap. I would like to write a post about the installation process on our blog. Is that OK for you? I only want to let more people know about this index and also give our feedback about the software, especially the installation process. We plan to use our blog not only for internal stuff but also to promote the BitTorrent ecosystem.

That is 100% fine with me and thanks for understanding. I will note that we will be releasing v8.2.0 this weekend which adds about 450 commits. Master vs v8.x.x branch which includes some big changes. You might want to wait for that to be released and then run php artisan git:update to get latest code. I will also note that the default unit3d uses php queue announce for tracker. One of the core devs @Roardom however has created UNIT3D-Announce which is written in rust. We have been having it used in prod on a few sites now and should be released soon.

Hi @HDVinnie I've just written a draft for the blog post in our blog: torrust/torrust-website#237 I will:

• Continue using it for a few days and review it with colleagues.
• Wait until you release the v8.2.0 version and update our installation.
• Publish the blog post.

Feel free to let me know if you have any comments or suggestions. It's not a comprehensive review because this is the first index I've installed and the only one I know apart from the one I'm contributing to.

Awesome. Will definitely give it a read and provide feedback when I get home. UNIT3D v8.2.0 has been released and you can simply run sudo php artisan git:update and say yes to all steps.

Also if you use discord we're more then happy to invite you to our server to chat more easily if that works for you.

Hi @HDVinnie, I've updated the application, but I got some errors:

Error 1

git fetch origin
[============================] (Done!)fatal: detected dubious ownership in repository at '/var/www/html'
To add an exception for this directory, call:

    git config --global --add safe.directory /var/www/html

Error 2

git checkout origin/master -- resources/views/mediahub/tv/season/show.blade.php
[============================] (Done!)error: pathspec 'resources/views/mediahub/tv/season/show.blade.php' did not match any file(s) known to git

Error 3

In ClassLoader.php line 576:

  include(/var/www/html/vendor/composer/../nunomaduro/collision/src/Adapters/Laravel/IgnitionSolutionsRepository.php): Failed to open stream: No such file or directory

And it seems the update did not finish well because the app is in maintenance mode:

https://www.unit3d-demo.com/

My discord username is josecelano. I've sent you an invitation request.

[Roardom]

I should've replied awhile ago but I'm unfamiliar with the installer/updater (I use git with the sail docker environment documented in the wiki). Also not sure if you've made it into the UNIT3D discord yet.

Looking through https://github.com/HDInnovations/UNIT3D-Community-Edition/blob/master/app/Console/Commands/GitUpdater.php, looks like it runs the following:

git fetch origin
git diff ..origin/master --name-only

and then shows you these files that need to be updated.

Then it runs the following:

php artisan down
git add .
git diff master --name-only
rm -rf <gitupdate path>
mkdir <gitupdate path>

Then it loops over all the files that weren't added and copies them here for a backup:

cp -Rfp <filepath> <gitupdate path>/<filepath>

Then it follows:

git fetch origin
git reset --hard origin/master

Then it loops over and restores the backed up files:

cp -Rfp <gitupdate path>/<filepath> <filepath> 

Then:

git add .
git checkout origin/master -- bun.lockb
git checkout origin/master -- composer.lock

It will then show you the conflicting files:

git checkout origin/master -- <filepath>

So all of the above are commands you don't have to worry about since you made no changes to the code (Unless maybe you changed some of the config files). Following that, the main update process can start:

1. Update migrations: php artisan migrate.
2. Clear cache: php artisan clear:all_cache.
3. Update the unit3d config git fetch origin && git checkout origin/master -- config/unit3d.php
4. Set cache: php artisan set:all_cache.
5. Compile JS assets: bun install bun run build.
6. Set permissions chown -R www-data: storage bootstrap public config
7. Restart the supervisor: supervisorctl reread && supervisorctl update && supervisorctl reload
8. Restart PHP: systemctl restart php8.3-fpm
9. Bring site back out of maintenance mode php artisan up

Unfortunately this GitUpdater script is quite old and none of the maintainers use it anymore and we just type the commands into the terminal directly when updating the site copying from the wiki or have or own shell scripts used for updating. This has caused a few bugs to appear over time (e.g. it was written before safe.directory became a thing).

Since you obviously know what you're doing when it comes to the command line, I would recommend simply using git to manage updates, pulling from the master branch whenever there's a new update, and running the commands here whenever code has changed: https://github.com/HDInnovations/UNIT3D-Community-Edition/wiki/Server-Management-(UNIT3D-v8.x.x).

Hope that helps!

[josecelano]

I should've replied awhile ago but I'm unfamiliar with the installer/updater (I use git with the sail docker environment documented in the wiki). Also not sure if you've made it into the UNIT3D discord yet.

Looking through https://github.com/HDInnovations/UNIT3D-Community-Edition/blob/master/app/Console/Commands/GitUpdater.php, looks like it runs the following:

git fetch origin
git diff ..origin/master --name-only

and then shows you these files that need to be updated.

Then it runs the following:

php artisan down
git add .
git diff master --name-only
rm -rf <gitupdate path>
mkdir <gitupdate path>

Then it loops over all the files that weren't added and copies them here for a backup:

cp -Rfp <filepath> <gitupdate path>/<filepath>

Then it follows:

git fetch origin
git reset --hard origin/master

Then it loops over and restores the backed up files:

cp -Rfp <gitupdate path>/<filepath> <filepath> 

Then:

git add .
git checkout origin/master -- bun.lockb
git checkout origin/master -- composer.lock

It will then show you the conflicting files:

git checkout origin/master -- <filepath>

So all of the above are commands you don't have to worry about since you made no changes to the code (Unless maybe you changed some of the config files). Following that, the main update process can start:

1. Update migrations: php artisan migrate.
2. Clear cache: php artisan clear:all_cache.
3. Update the unit3d config git fetch origin && git checkout origin/master -- config/unit3d.php
4. Set cache: php artisan set:all_cache.
5. Compile JS assets: bun install bun run build.
6. Set permissions chown -R www-data: storage bootstrap public config
7. Restart the supervisor: supervisorctl reread && supervisorctl update && supervisorctl reload
8. Restart PHP: systemctl restart php8.3-fpm
9. Bring site back out of maintenance mode php artisan up

Unfortunately this GitUpdater script is quite old and none of the maintainers use it anymore and we just type the commands into the terminal directly when updating the site copying from the wiki or have or own shell scripts used for updating. This has caused a few bugs to appear over time (e.g. it was written before safe.directory became a thing).

Since you obviously know what you're doing when it comes to the command line, I would recommend simply using git to manage updates, pulling from the master branch whenever there's a new update, and running the commands here whenever code has changed: https://github.com/HDInnovations/UNIT3D-Community-Edition/wiki/Server-Management-(UNIT3D-v8.x.x).

Hope that helps!

Hi @HDVinnie, Thank you for the detailed response. Before you could reply, I was able to activate the site again by removing the lock file for maintenance mode. The app seemed to work, but some parts didn't look like they did after the fresh installation.

I've just executed the steps you told me (I'm using the latest commit 5125cd33d), and I don't see new errors in the Laravel Log, but still, some UI components are not aligned correctly, like this:

But that seems to be the only problem. I've tried using Brave, Chrome, and Firefox.