DietPi-Software | Komga: FOSS comic/manga server

[himura95]

Software request

Formal software information

• Software title | Komga
• Short description | Open source media server for comics/mangas/BDs with API and OPDS support
• Official URL (if available) | https://komga.org/
• GitHub URL (if available) | https://github.com/gotson/komga
• (Official) install documentation | https://komga.org/installation/jar.html

Are there similar/alternative software titles available with DietPi-Software?

Ubooquity

What makes your requested software better than the above solutions, if available?

It is an active project and fully open source,

How can DietPi make the installation easier or compatible, than following the install instructions or do APT installation, if available?

Like ubooquity

Can you provide the installation steps that you would suggest DietPi-Software to do?

Like ubooquity

Are you willing to help maintaining the software installation, e.g. in case of needed setup changes due to updates etc.? This is not needed, but could speed up our decision to implement it, as man power is always a topic :wink:.

Sorry, I am totally unexperienced in bash coding.

Vote for this software on FeatHub: https://feathub.com/MichaIng/DietPi/+144

[himura95]

I try to help the Komga integration :

Latest Komga.jar : https://github.com/gotson/komga/releases

dietpi-software :

Menu

        #------------------
        software_id=140

        aSOFTWARE_NAME[$software_id]='Komga'
        aSOFTWARE_DESC[$software_id]='a free and open-source home server for your comics and ebooks library'
        aSOFTWARE_CATEGORY_INDEX[$software_id]=2
        aSOFTWARE_TYPE[$software_id]=0
        aSOFTWARE_REQUIRES_JAVA_JRE_JDK[$software_id]=1
        aSOFTWARE_ONLINEDOC_URL[$software_id]=''

Installation

        software_id=140 # Komga
        if (( ${aSOFTWARE_INSTALL_STATE[$software_id]} == 1 )); then

            Banner_Installing

            INSTALL_URL_ADDRESS='https://dietpi.com/downloads/binaries/all/Komga.jar'
            G_CHECK_URL "$INSTALL_URL_ADDRESS"

            mkdir -p $G_FP_DIETPI_USERDATA/komga
            G_RUN_CMD wget "$INSTALL_URL_ADDRESS" -O $G_FP_DIETPI_USERDATA/komga/Komga.jar

        fi

Launch

        software_id=140 # Komga
        if (( ${aSOFTWARE_INSTALL_STATE[$software_id]} == 1 )); then

            Banner_Configuration

            local usercmd='useradd -rMU'
            getent passwd komga &> /dev/null && usercmd='usermod -a'
            $usercmd -G dietpi -s $(command -v nologin) komga

            mkdir -p $G_FP_DIETPI_USERDATA/{ebooks,comics}

            cat << _EOF_ > /etc/systemd/system/komga.service
[Unit]
Description=Komga (DietPi)
After=dietpi-boot.service network.target

[Service]
User=komga
WorkingDirectory=$G_FP_DIETPI_USERDATA/komga
ExecStart=/usr/bin/java -Xmx768m -jar Komga.jar --server.port=2037 --spring.profiles.active=claim --spring.datasource.url=jdbc:h2:./database.h2 --komga.libraries-scan-cron="* 1 * * * ?" --komga.threads.analyzer=1

[Install]
WantedBy=multi-user.target
_EOF_

            # Permissions
            chmod +x $G_FP_DIETPI_USERDATA/komga/Komga.jar
            chown -R komga:dietpi $G_FP_DIETPI_USERDATA/komga

        fi

Uninstall

software_id=140 # Komga
        if (( ${aSOFTWARE_INSTALL_STATE[$software_id]} == -1 )); then

            Banner_Uninstalling

            if [[ -f '/etc/systemd/system/komga.service' ]]; then

                systemctl disable --now komga
                rm -R /etc/systemd/system/komga.service*

            fi
            getent passwd komga&> /dev/null && userdel -rf komga
            [[ -d $G_FP_DIETPI_USERDATA/komga]] && rm -R $G_FP_DIETPI_USERDATA/komga

        fi

After install > navigate to http://localhost:2037/swagger-ui.html and input an email/password, and validate for create the admin user. (https://komga.org/installation/user-accounts.html#configure)
Navigate to http://localhost:2037 and use the email/password you created just before.

Info : https://komga.org/

[quyentruong]

when will this app be implemented to dietpi-software ?

[MichaIng]

I totally forgot about the basically finished implementation above. Will have a look for next release, looks well done!

[gotson]

Komga dev here, the onboarding is much easier now with no need to go to swagger anymore, it's built-in the ui now.

[MichaIng]

Many thanks for your information. For my reference: https://komga.org/installation/webui.html#create-user-account
Is there a way to pre-create the user account via CLI or config file before starting the service and adjust the values afterwards? Would be safer when for some reason the port is opened to www.

I'll read a bid into the docs anyway to verify the ExecStart= command options above, limit memory based on actually available total system memory and such. Probably better to set those via config file and avoid overriding it via command options. More transparent to user and we can decide on reinstalls (existing config file) which options we want to reset (compatibility with the whole setup) and which custom user choices we want to preserve.

[gotson]

There is a noclaim profile that would create a user on startup, and output a random password in the logs. It is not very user friendly though, and building any kind of automatic parsing tool on those logos would be brittle and unadvised.

There is no option to create by cli or config file.

The webui or the swagger to claim the server are using the same api, and would expose the same risk. The api expects a login and password in custom headers to reduce risk of logging in proxies.

I consider it less risky than most popular software which don't have security enabled by default, like radarr, sonarr etc. Those software could be harmful if unsecured, since they enable disk operations. Komga is no touch and read only in contrast.

As for the configuration, some are in config, but the configuration of the max memory for example is a jvm configuration, not an application configuration, and hen E must be set via command line or environment variable.

[MichaIng]

Many thanks. Yeah not a big issue, especially since it runs on a custom port, not 80/443 exposed. Unlikely that this is exposed to www without user knowledge.

Indeed, Java options of course must be passed via command option. Not too difficult as well to change, and we even offer to do that safely via whiptail GUI (dietpi-services) which uses a drop-in config at /etc/systemd/system/komga.service.d/ hence can be easily reverted and survives reinstalls.

[MichaIng]

Okay, implementation done. Logging has been moved to /var/log/komga/, i.e. RAM disk by default on DietPi. Is there a way to cleanly disable file logging completely? The systemd unit logs to journal already which in RAM as well, lasts until poweroff (as long as you don't run an extremely syslog intensive system for a longer time) and nicely sortable. So a /var/log tmpfs file logging is not really necessary.

How to adjust the log level?

@himura95 about two settings you suggested above I could not find any infos:

• threads.analyzer
• spring.profiles-active claim (as opposed to noclaim?)

What do they do?

[gotson]

You can disable the default file logging by adding the following configuration:

logging.file.name: ""

---

Adjusting the log level is quite flexible, and can be done per logger/class. To adjust the root logger, you can use:

logging.level.root: WARN

The following levels are valid: TRACE, DEBUG, INFO, WARN, ERROR.

---

threads.analyzer has been removed and is not used anymore.

spring.profiles-active: claim has been removed, and is now the default.

All the configuration options are described in the documentation.

I think the one that could make sense would be:

• komga.remember-me.key: if you can generate a random string during install, that would be useful.
• komga.database.file: i suppose you already tweaked this one to match your directory structure.

[MichaIng]

Great, obsolete settings have been removed, "remember me" feature enabled via $(openssl rand -hex 32) generated random key, file logging disabled and log level reduced to warnings. Logs can be checked via journalctl -u komga and file logging can be easily enabled via config file, as documented in our online docs: https://dietpi.com/phpbb/viewtopic.php?p=26858#p26858

@gotson
Yes the database files have been moved to our directory structure. As you say "All the configuration options", logging.level.root is missing in your docs 😉.

I adjusted the Java maximum heap memory usage to be 20% of available total memory (including swap) but min 200 MiB, and made this the standard for all our Java applications now. I'll run some tests if this works fine. Min 2 GiB memory is assured by default on DietPi systems via auto-sized swap file, but I'll check if 1 GiB (=> 200 MiB Java max mamory) works. A saw a fresh x86_64 install yesterday with -Xmx768m took > 500 MiB, but AFAIK Java applications are able to deal with less. Lets see if there is any negative impact.

EDIT: Works fine, tested with -Xmx128m, of course with large libraries and multiple users more might be required, but this can and should be increased when really receiving the java.lang.OutOfMemoryError.
Remember-me cookie is set and functions 👍.

EDIT2: Works fine on Stretch (Java 8) as well. Bullseye has still Java 11 as default, but Java 14 is in the repo already, Java 15 in pipeline on Sid. But this is something we need to test with all Java applications we offer, once the Debian Bullseye default changes.

[gotson]

Awesome. Komga is tested on CI with Java 8 and Java 11.

Since other Java versions are not LTS I didn't test on it. The next LTS will be Java 17.

[MichaIng]

Based on the speed of new Java releases now, I guess Debian will as well have Java 17, otherwise stay with Java 11 as they surely will not ship a non-LTS version as well.