artodeto's free port

Thanks to the wonderful rustdesk howto, I was able to quickly setup my own rustdesk instance.

With this benefit, I know I have to maintain yet another software so I wrote a dead simple "update_rustdesk.sh" I want to share.

#!/bin/bash
####
# @ref: https://lab.uberspace.de/guide_rustdesk/
# @since: 2025-04-19
# @author: stev leibelt <artodeto@bazzline.net>
####

function _main ()
{
    local CURRENT_WORKING_DIRECTORY
    local INSTALLED_VERSION
    local LOCAL_BASE_PATH
    local VERSION_TO_DOWNLOAD

    CURRENT_WORKING_DIRECTORY=$(pwd)
    # adapt this line
    LOCAL_BASE_PATH="${2:-/home/<string: your_user>/rustdesk}"
    VERSION_TO_DOWNLOAD="${1}"

    if [[ -z "${VERSION_TO_DOWNLOAD}" ]];
    then
        echo ":: Usage"
        echo "   ${0} <string: latest_rustdesk_version> [<string: local_installed_path>"
        echo ""

        return 0
    fi

    if [[ ! -d "${LOCAL_BASE_PATH}" ]];
    then
        echo ":: Error"
        echo "   >>${LOCAL_BASE_PATH}<< is not a directory."
        echo ""

        return 10
    fi

    cd "${LOCAL_BASE_PATH}"

    if [[ ! -f ".current_version" ]];
    then
        echo ":: Error"
        echo "   >>${LOCAL_BASE_PATH}/.current_version<< is not a file."
        echo ""
        cd "${CURRENT_WORKING_DIRECTORY}"

        return 15
    fi

    INSTALLED_VERSION=$(cat ".current_version")

    if [[ "${INSTALLED_VERSION}" == "${VERSION_TO_DOWNLOAD}" ]];
    then
        echo ":: Nothing to do"
        echo "   ${INSTALLED_VERSION} already installed."
        echo ""
        cd "${CURRENT_WORKING_DIRECTORY}"

        return 0
    fi

    if [[ -d "new" ]];
    then
        rm -fr "new"
    fi

    supervisorctl stop rustdesk_hbbr
    supervisorctl stop rustdesk_hbbs

    mkdir -p "new"
    cd new
    if wget "https://github.com/rustdesk/rustdesk-server/releases/download/${VERSION_TO_DOWNLOAD}/rustdesk-server-linux-amd64.zip";
    then
        unzip -j rustdesk-server-linux-amd64.zip

        if [[ ! -f hbbr ]];
        then
            echo ":: Error"
            echo "   >>${LOCAL_BASE_PATH}/new/hbbr is not a file."
            echo ""
            cd "${CURRENT_WORKING_DIRECTORY}"

            return 30
        fi

        if [[ ! -f hbbs ]];
        then
            echo ":: Error"
            echo "   >>${LOCAL_BASE_PATH}/new/hbbs is not a file."
            echo ""
            cd "${CURRENT_WORKING_DIRECTORY}"

            return 32
        fi

        if [[ ! -f rustdesk-utils ]];
        then
            echo ":: Error"
            echo "   >>${LOCAL_BASE_PATH}/new/rustdesk-utils is not a file."
            echo ""
            cd "${CURRENT_WORKING_DIRECTORY}"

            return 34
        fi

        mv ../hbbr ../hbbr.previous
        mv ../hbbs ../hbbs.previous
        mv ../rustdesk-utils ../rustdesk-utils.previous

        mv hbbr ../
        mv hbbs ../
        mv rustdesk-utils ../

        echo "${VERSION_TO_DOWNLOAD}" > ../.current_version

        supervisorctl start rustdesk_hbbs
        supervisorctl start rustdesk_hbbr

        echo "   Switched from >>${INSTALLED_VERSION}<< to >>${VERSION_TO_DOWNLOAD}<<"
    else
        echo ":: Error"
        echo "   wget last exit code ${?}"
        echo ""
        cd "${CURRENT_WORKING_DIRECTORY}"

        return 20
    fi
}

_main "${@}"

You only have to adapt one line, all else should work out of the box.

I am not an heavy user of the nextcloud polls application, so this issue could be an oldie but goldie.

I am working on a nextcloud version 30.0.5.1 and I wanted to create a poll.

First discovery, all polls are gone and I was not able to configure anything Preference section. A tail on the nextcloud.log told me that apps/polls/lib/Controller/PollController.php is producing a unknown config key log entry.

Long story short, this link from the closed issue/3806 pointed me to the right direct.
Logged in as admin, I've opened the settings/admin/polls and disabled and enabled the Enable the poll creation globally option. After that and a page reload as a user, almost all is working fine. There is only one open issue with the "copy link to clipboard" option :-.

It took me some time and a push into the right direction to solve my puzzle.

My first solution is a fix for my all actors in one worker. The fix here was to remove the dramatiq setup call from within each actor and to centralize it in the one worker file before importing the actors per context.

My second solution is a fix for my one worker per context. The fix here was to add a state to the dramatiq setup to prevent creating brokers instances after broker instances.

With my code, you are now able to create python project that uses dramatiq and has multiple actors defined in multiple worker files.

Sounds simple but took me more than an week. Hope it prevents at least one to waste that time!

I am currently developing a cli application using typer.

As far as possible, I try to have strict separated bounded context. I ended up build two problems I need to solve. One problem was to create a adapter to enable each context to exchange well defined messages or data with another context. The second issue was a pure scale issue. There are moments were part of the application just iterates over an result set of gazillion (or "millausend" as the German's are saying) entries. The runtime was ramping minutes and this sucks.

I ended up evaluating task queue libraries in python. Based on my gut-feeling, I wanted to avoid celery since it is to complex and offers way more than I was search for. rq was an option but the mighty internet told me that it has its issues and is kind of outdated. taskq was almost the choice but tends to be a tool I would use but not for the area it was invented for. dramatiq was the choice. It was looking simple and claims to be written for python 3 from a maintainer of celery and focused on delivering 20 percent of the code base to fit in 80 percent of the celery use cases. Not feature complete but I must admit that I did not spend time to have a look on huey or arq.

Adding the first actor was super satisfying since I solved my scaling problem so hard that I need to reduce the number of workers to not break one of the other systems my code works with. Adding a second actor was also working fine since it was defined in the same context workers file.

As I've written down earlier, my code lives in one application but I have strong bounded contexts. The "fun" had started when I've written a third actor but this time in a second workers file. Still until today, I am not able to separate the actors into dedicated files and still run the dramatiq workers process while it is processing all queued messages.

I've tried a lot of example projects out there. Each example project just defines one actor, almost always the one actor mentioned in the documentation which was boring. I've updated dependencies to make an example still "workable" today. I found an issue that periodiq is not supporting python 3.12. And I've asked the maintainer of one example project if he has an idea why multiple actors are not working as expected.

At the end, I've created my own dramatiq example project. But this is an example project with multiple actors. Furthermore, this project shows the issues since it has multiple branches. Each branch shows a way to use dramatiq and lists the downside of this approach. I've used this example project to ask my question in the official dramatiq group. Let's see if there will be an answer on it.

I still hope that there is either an understanding issue on my side (like I use the tool simply wrong) or that I make a mistake in the setup and worker process creation.

Your takeaway is, that there is now at least one dramatiq example with multiple actors.