Merge pull request #1 from YunoHost-Apps/testing

Testing

LICENSE

@@ -1,4 +1,33 @@
-File containing the license of your package.
+Copyright (c) 2023-2025 Timothy Jaeryang Baek (Open WebUI)
+All rights reserved.
 
-More information here:
-https://choosealicense.com/
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from
+   this software without specific prior written permission.
+
+4. Notwithstanding any other provision of this License, and as a material condition of the rights granted herein, licensees are strictly prohibited from altering, removing, obscuring, or replacing any "Open WebUI" branding, including but not limited to the name, logo, or any visual, textual, or symbolic identifiers that distinguish the software and its interfaces, in any deployment or distribution, regardless of the number of users, except as explicitly set forth in Clauses 5 and 6 below.
+
+5. The branding restriction enumerated in Clause 4 shall not apply in the following limited circumstances: (i) deployments or distributions where the total number of end users (defined as individual natural persons with direct access to the application) does not exceed fifty (50) within any rolling thirty (30) day period; (ii) cases in which the licensee is an official contributor to the codebase—with a substantive code change successfully merged into the main branch of the official codebase maintained by the copyright holder—who has obtained specific prior written permission for branding adjustment from the copyright holder; or (iii) where the licensee has obtained a duly executed enterprise license expressly permitting such modification. For all other cases, any removal or alteration of the "Open WebUI" branding shall constitute a material breach of license.
+
+6. All code, modifications, or derivative works incorporated into this project prior to the incorporation of this branding clause remain licensed under the BSD 3-Clause License, and prior contributors retain all BSD-3 rights therein; if any such contributor requests the removal of their BSD-3-licensed code, the copyright holder will do so, and any replacement code will be licensed under the project's primary license then in effect. By contributing after this clause's adoption, you agree to the project's Contributor License Agreement (CLA) and to these updated terms for all new contributions.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

conf/.env

@@ -0,0 +1,37 @@
+# Ollama URL for the backend to connect
+# The path '/ollama' will be redirected to the specified backend URL
+OLLAMA_BASE_URL='http://localhost:11434'
+OPENAI_API_BASE_URL=''
+OPENAI_API_KEY=''
+# AUTOMATIC1111_BASE_URL="http://localhost:7860"
+# For production, you should only need one host as
+# fastapi serves the svelte-kit built frontend and backend from the same host and port.
+# To test with CORS locally, you can set something like
+# CORS_ALLOW_ORIGIN='http://localhost:5173;http://localhost:8080'
+CORS_ALLOW_ORIGIN='https://__DOMAIN__'
+# For production you should set this to match the proxy configuration (127.0.0.1)
+FORWARDED_ALLOW_IPS='127.0.0.1'
+# DO NOT TRACK
+SCARF_NO_ANALYTICS=true
+DO_NOT_TRACK=true
+ANONYMIZED_TELEMETRY=false
+DEFAULT_LOCALE=__LANGUAGE__
+ADMIN_EMAIL=__MAIL__
+ENV="prod"
+WEBUI_NAME="Open WebUI for YunoHost"
+PORT=__PORT__
+DATA_DIR="__DATA_DIR__"
+ENABLE_SIGNUP=false
+#LDAP
+ENABLE_LDAP=true
+LDAP_SERVER_HOST=127.0.0.1
+LDAP_SERVER_PORT=389
+LDAP_USE_TLS=false
+LDAP_VALIDATE_CERT=false
+LDAP_SEARCH_BASE=ou=users,dc=yunohost,dc=org
+LDAP_SEARCH_FILTERS=(|(permission=cn=openwebui.main,ou=permission,dc=yunohost,dc=org))
+LDAP_ATTRIBUTE_FOR_USERNAME=uid
+LDAP_ATTRIBUTE_FOR_MAIL=mail
+DEFAULT_USER_ROLE=user
+LDAP_APP_DN=''
+LDAP_APP_PASSWORD=''

conf/nginx.conf

@@ -1,25 +1,15 @@
 #sub_path_only rewrite ^__PATH__$ __PATH__/ permanent;
 location __PATH__/ {
 
-  # Path to source
-  alias __INSTALL_DIR__/;
-
-### Example PHP configuration (remove it if not used)
-  index index.php;
-
-  # Common parameter to increase upload size limit in conjunction with dedicated PHP-FPM file
-  # client_max_body_size 50M;
-
-  try_files $uri $uri/ index.php;
-  location ~ [^/]\.php(/|$) {
-    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
-    fastcgi_pass unix:/var/run/php/php__PHP_VERSION__-fpm-__APP__.sock;
-
-    fastcgi_index index.php;
-    include fastcgi_params;
-    fastcgi_param REMOTE_USER $remote_user;
-    fastcgi_param PATH_INFO $fastcgi_path_info;
-    fastcgi_param SCRIPT_FILENAME $request_filename;
-  }
-### End of PHP configuration part
+  proxy_pass        http://127.0.0.1:__PORT__/;
+  proxy_redirect    off;
+  proxy_set_header  Host $host;
+  proxy_set_header  X-Real-IP $remote_addr;
+  proxy_set_header  X-Forwarded-Proto $scheme;
+  proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
+  proxy_set_header  X-Forwarded-Host $server_name;
+
+  proxy_http_version 1.1;
+  proxy_set_header Connection "upgrade";
+  proxy_set_header Upgrade $http_upgrade;
 }

conf/systemd.service

@@ -1,5 +1,5 @@
 [Unit]
-Description=Small description of the service
+Description=User-friendly AI Interface (Supports Ollama, OpenAI API, ...)
 After=network.target
 
 [Service]
@@ -7,9 +7,11 @@ Type=simple
 User=__APP__
 Group=__APP__
 WorkingDirectory=__INSTALL_DIR__/
-ExecStart=__INSTALL_DIR__/script
+EnvironmentFile=__INSTALL_DIR__/.env
+ExecStart=/usr/bin/bash -c 'source __INSTALL_DIR__/venv/bin/activate &&  open-webui serve --port __PORT__'
 StandardOutput=append:/var/log/__APP__/__APP__.log
 StandardError=inherit
+TimeoutStartSec=300
 
 ### Depending on specificities of your service/app, you may need to tweak these
 ### .. but this should be a good baseline

config_panel.toml.example

@@ -1,303 +0,0 @@
-#:schema https://github.com/YunoHost/apps/raw/main/schemas/config_panel.v1.schema.json
-
-## Config panel are available from webadmin > Apps > YOUR_APP > Config Panel Button
-## Those panels let user configure some params on their apps using a friendly interface,
-## and remove the need to manually edit files from the command line.
- 
-## From a packager perspective, this .toml is coupled to the scripts/config script,
-## which may be used to define custom getters/setters. However, most use cases
-## should be covered automagically by the core, thus it may not be necessary
-## to define a scripts/config at all!
- 
-## -----------------------------------------------------------------------------
-## IMPORTANT: In accordance with YunoHost's spirit, please keep things simple and 
-## do not overwhelm the admin with tons of misunderstandable or advanced settings.
-## -----------------------------------------------------------------------------
-
-## The top level describe the entire config panels screen.
-
-## The version is a required property. 
-## Here a small reminder to associate config panel version with YunoHost version
-## | Config | YNH    | Config panel small change log                           |
-## | ------ | ---    | ------------------------------------------------------- |
-## | 0.1    | 3.x    | 0.1 config script not compatible with YNH >= 4.3        |
-## | 1.0    | 4.3.x  | The new config panel system with 'bind' property        |
-version = "1.0"
-
-## (optional) i18n property let you internationalize questions, however this feature 
-## is only available in core configuration panel (like yunohost domain config).
-## So in app config panel this key is ignored for now, but you can internationalize
-## by using a lang dictionary (see property name bellow)
-# i18n = "prefix_translation_key"
-
-################################################################################
-#### ABOUT PANELS
-################################################################################
-
-## The next level describes web admin panels
-## You have to choose an ID for each panel, in this example the ID is "main"
-## Keep in mind this ID will be used in CLI to refer to your question, so choose
-## something short and meaningfull.
-## In the webadmin, each panel corresponds to a distinct tab / form
-[main]
-
-## Define the label for your panel
-## Internationalization works similarly to the 'description' and 'ask' questions in the manifest
-# name.en = "Main configuration"
-# name.fr = "Configuration principale"
-
-## (optional) If you need to trigger a service reload-or-restart after the user
-## change a question in this panel, you can add your service in the list.
-services = ["__APP__"]
-# or services = ["nginx", "__APP__"] to also reload-or-restart nginx
-
-## (optional) This help properties is a short help displayed on the same line
-## than the panel title but not displayed in the tab.
-# help = ""
-    
-    ############################################################################
-    #### ABOUT SECTIONS
-    ############################################################################
-
-    ## A panel is composed of one or several sections.
-    ##
-    ## Sections are meant to group questions together when they correspond to
-    ## a same subtopic. This impacts the rendering in terms of CLI prompts
-    ## and HTML forms
-    ##
-    ## You should choose an ID for your section, and prefix it with the panel ID
-    ## (Be sure to not make a typo in the panel ID, which would implicitly create
-    ## an other entire panel)
-    ##
-    ## We use the context of pepettes_ynh as an example,
-    ## which is a simple donation form app written in python,
-    ## and for which the admin will want to edit the configuration
-    [main.customization]
-
-    ## (optional) Defining a proper title for sections is not mandatory
-    ## and depends on the exact rendering you're aiming for the CLI / webadmin
-    name = ""
-
-    ## (optional) This help properties is a short help displayed on the same line
-    ## than the section title, meant to provide additional details
-    # help = ""
-    
-    ## (optional) As for panel, you can specify to trigger a service 
-    ## reload-or-restart after the user change a question in this section.
-    ## This property is added to the panel property, it doesn't deactivate it.
-    ## So no need to replicate, the service list from panel services property.
-    # services = []
-    
-    ## (optional) By default all questions are optionals, but you can specify a
-    ## default behaviour for question in the section
-    optional = false
-        
-    ## (optional) It's also possible with the 'visible' property to only
-    ## display the section depending on the user's answers to previous questions.
-    ##
-    ## Be careful that the 'visible' property should only refer to **previous** questions
-    ## Hence, it should not make sense to have a "visible" property on the very first section.
-    ##
-    ## Also, keep in mind that this feature only works in the webadmin and not in CLI
-    ## (therefore a user could be prompted in CLI for a question that may not be relevant)
-    # visible = true
-
-        ########################################################################
-        #### ABOUT QUESTIONS
-        ########################################################################
-
-        ## A section is compound of one or several questions.
-
-        ## ---------------------------------------------------------------------
-        ## IMPORTANT: as for panel and section you have to choose an ID, but this
-        ## one should be unique in all this document, even if the question is in
-        ## an other panel.
-        ## ---------------------------------------------------------------------
-        
-        ## You can use same questions types and properties than in manifest.yml 
-        ## install part. However, in YNH 4.3, a lot of change has been made to
-        ## extend availables questions types list.
-        ## See: TODO DOC LINK
-        
-        [main.customization.project_name]
-        
-        ## (required) The ask property is equivalent to the ask property in 
-        ## the manifest. However, in config panels, questions are displayed on the
-        ## left side and therefore have less space to be rendered. Therefore, 
-        ## it is better to use a short question, and use the "help" property to
-        ## provide additional details if necessary.
-        ask.en = "Name of the project"
-
-        ## (required) The type property indicates how the question should be 
-        ## displayed, validated and managed. Some types have specific properties.
-        ## 
-        ## Types available: string, boolean, number, range, text, password, path
-        ## email, url, date, time, color, select, domain, user, tags, file.
-        ##
-        ## For a complete list with specific properties, see: TODO DOC LINK
-        type = "string"
-        
-        ########################################################################
-        #### ABOUT THE BIND PROPERTY
-        ########################################################################
-
-        ## (recommended) 'bind' property is a powerful feature that let you 
-        ## configure how and where the data will be read, validated and written. 
-
-        ## By default, 'bind property is in "settings" mode, it means it will 
-        ## **only** read and write the value in application settings file.
-        ## bind = "settings"
-
-        ## However, settings usually correspond to key/values in actual app configurations
-        ## Hence, a more useful mode is to have bind = ":FILENAME". In that case, YunoHost
-        ## will automagically find a line with "KEY=VALUE" in FILENAME
-        ## (with the adequate separator between KEY and VALUE)
-        ##
-        ## YunoHost will then use this value for the read/get operation.
-        ## During write/set operations, YunoHost will overwrite the value
-        ## in **both** FILENAME and in the app's settings.yml
-
-        ## Configuration file format supported: yaml, toml, json, ini, env, php,
-        ## python. The feature probably works with others formats, but should be tested carefully.
-
-        ## Note that this feature only works with relatively simple cases
-        ## such as `KEY: VALUE`, but won't properly work with
-        ## complex data structures like multilin array/lists or dictionnaries.
-        ## It also doesn't work with XML format, custom config function call, php define(), ...
-
-        ## More info on TODO
-        # bind = ":/var/www/__APP__/settings.py"
-
-
-        ## By default, bind = ":FILENAME" will use the question ID as KEY
-        ## ... but the question ID may sometime not be the exact KEY name in the configuration file.
-        ## 
-        ## In particular, in pepettes, the python variable is 'name' and not 'project_name'
-        ## (c.f. https://github.com/YunoHost-Apps/pepettes_ynh/blob/5cc2d3ffd6529cc7356ff93af92dbb6785c3ab9a/conf/settings.py##L11 )
-        ##
-        ## In that case, the key name can be specified before the column ':'
-        
-        bind = "name:/var/www/__APP__/settings.py"
-
-        ## ---------------------------------------------------------------------
-        ## IMPORTANT: other 'bind' mode exists:
-        ## 
-        ## bind = "FILENAME" (with no column character before FILENAME)
-        ## may be used to bind to the **entire file content** (instead of a single KEY/VALUE)
-        ## This could be used to expose an entire configuration file, or binary files such as images
-        ## For example:
-        ## bind = "/var/www/__APP__/img/logo.png"
-        ##
-        ## bind = "null" can be used to disable reading / writing in settings.
-        ## This creates sort of a "virtual" or "ephemeral" question which is not related to any actual setting
-        ## In this mode, you are expected to define custom getter/setters/validators in scripts/config:
-        ##
-        ## getter: get__QUESTIONID()
-        ## setter: set__QUESTIONID()
-        ## validator: validate__QUESTIONID()
-        ##
-        ## You can also specify a common getter / setter / validator, with the 
-        ## function 'bind' mode, for example here it will try to run 
-        ## get__array_settings() first.
-        #  bind = "array_settings()"
-        ## ---------------------------------------------------------------------
-        
-        ## ---------------------------------------------------------------------
-        ## IMPORTANT: with the exception of bind=null questions,
-        ## question IDs should almost **always** correspond to an app setting
-        ## initialized / reused during install/upgrade.
-        ## Not doing so may result in inconsistencies between the config panel mechanism
-        ## and the use of ynh_add_config
-        ## ---------------------------------------------------------------------
-
-        ########################################################################
-        #### OTHER GENERIC PROPERTY FOR QUESTIONS
-        ########################################################################
-        
-        ## (optional) An help text for the question
-        help = "Fill the name of the project which will received donation"
-
-        ## (optional) An example display as placeholder in web form
-        # example = "YunoHost"
-
-        ## (optional) set to true in order to redact the value in operation logs
-        # redact = false
-
-        ## (optional) for boolean questions you can specify replacement values 
-        ## bound to true and false, in case property is bound to config file
-        # useful if bound property in config file expects something else than integer 1
-        yes = "Enable" 
-        # useful if bound property in config file expects something else than integer 0
-        no = "Disable" 
-
-        ## (optional) A validation pattern
-        ## ---------------------------------------------------------------------
-        ## IMPORTANT: your pattern should be between simple quote, not double.
-        ## ---------------------------------------------------------------------
-        pattern.regexp = '^\w{3,30}$'
-        pattern.error = "The name should be at least 3 chars and less than 30 chars. Alphanumeric chars are accepted"
-
-        ## Note: visible and optional properties are also available for questions
-
-
-        [main.customization.contact_url]
-        ask = "Contact url"
-        type = "url"
-        example = "mailto: contact@example.org"
-        help = "mailto: accepted"
-        pattern.regexp = '^mailto:[^@]+@[^@]+|https://$'
-        pattern.error = "Should be https or mailto:"
-        bind = ":/var/www/__APP__/settings.py"
-
-        [main.customization.logo]
-        ask = "Logo"
-        type = "file"
-        accept = ".png"
-        help = "Fill with an already resized logo"
-        bind = "__INSTALL_DIR__/img/logo.png"
-        
-        [main.customization.favicon]
-        ask = "Favicon"
-        type = "file"
-        accept = ".png"
-        help = "Fill with an already sized favicon"
-        bind = "__INSTALL_DIR__/img/favicon.png"
-
-        
-    [main.stripe]
-    name = "Stripe general info"
-    optional = false
-
-        # The next alert is overwrited with a getter from the config script
-        [main.stripe.amount]
-        ask = "Donation in the month : XX €
-        type = "alert"
-        style = "success"
-
-        [main.stripe.publishable_key]
-        ask = "Publishable key"
-        type = "string"
-        redact = true
-        help = "Indicate here the stripe publishable key"
-        bind = ":/var/www/__APP__/settings.py"
-
-        [main.stripe.secret_key]
-        ask = "Secret key"
-        type = "string"
-        redact = true
-        help = "Indicate here the stripe secret key"
-        bind = ":/var/www/__APP__/settings.py"
-        
-        [main.stripe.prices]
-        ask = "Prices ID"
-        type = "tags"
-        help = """\
-        Indicates here the prices ID of donation products you created in stripe interfaces. \
-        Go on [Stripe products](https://dashboard.stripe.com/products) to create those donation products. \
-        Fill it tag with 'FREQUENCY/CURRENCY/PRICE_ID' \
-        FREQUENCY: 'one_time' or 'recuring' \
-        CURRENCY: 'EUR' or 'USD' \
-        PRICE_ID: ID from stripe interfaces starting with 'price_' \
-        """
-        pattern.regexp = '^(one_time|recuring)/(EUR|USD)/price_.*$'
-        pattern.error = "Please respect the format describe in help text for each price ID"

doc/ADMIN.md

@@ -1,3 +1,2 @@
-This is a dummy admin doc for this app
-
-The app install dir is `__INSTALL_DIR__`
+You can start using open webui with ollama (after installing it from yunohost catalog) immediately.
+Here is the guide to manage ollama from open webui : https://docs.openwebui.com/getting-started/quick-start/starting-with-ollama/

doc/ADMIN_fr.md

@@ -1,3 +1 @@
-Ceci est une fausse doc d'admin pour cette app
-
-Le dossier d'install de l'app est `__INSTALL_DIR__`
+Vous pouvez commencer à utiliser Open WebUI avec Ollama immédiatement (après l'avoir installé depuis le catalogue Yunohost). Voici le guide pour gérer Ollama depuis Open WebUI : https://docs.openwebui.com/getting-started/quick-start/starting-with-ollama/

doc/DESCRIPTION.md

@@ -1 +1 @@
-This is a dummy description of this app features
+Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform designed to operate entirely offline. It supports various LLM runners like Ollama and OpenAI-compatible APIs, with built-in inference engine for RAG, making it a powerful AI deployment solution.

doc/DESCRIPTION_fr.md

@@ -1 +1 @@
-Ceci est une fausse description des fonctionalités de l'app
+Open WebUI est une plateforme d'IA auto-hébergée, extensible, riche en fonctionnalités et conviviale, conçue pour fonctionner entièrement hors ligne. Elle prend en charge divers exécuteurs LLM comme Ollama et les API compatibles OpenAI, avec un moteur d'inférence intégré pour RAG, ce qui en fait une solution de déploiement d'IA puissante.

doc/POST_INSTALL.md

@@ -1,7 +1,2 @@
-This is a dummy disclaimer to display after the install
-
-The app url is <https://__DOMAIN____PATH__>
-
-The app install dir is `__INSTALL_DIR__`
-
-The app id is `__ID__`
+After installation, wait some minutes for the app to complete startup. 
+The first user to login will be granted admin rights. 

doc/POST_UPGRADE.md

@@ -1 +0,0 @@
-This is a dummy disclaimer to display after upgrades

doc/PRE_INSTALL.md

@@ -1 +1 @@
-This is a dummy disclaimer to display prior to the install
+This app requires huge ressources 

doc/PRE_INSTALL_fr.md

@@ -1 +1 @@
-Ceci est un faux disclaimer à présenter avant l'installation
+Cette application requiert beaucoup de ressources 

doc/PRE_UPGRADE.md

@@ -1 +0,0 @@
-This is a dummy disclaimer to display prior to any upgrade

manifest.toml

@@ -7,12 +7,12 @@ name = "Open WebUI"
 description.en = "User-friendly AI Interface (Supports Ollama, OpenAI API, ...)"
 description.fr = "Interface IA conviviale (Supporte Ollama, API OpenAI, ...)"
 
-version = "0.6.15~ynh1"
+version = "0.6.13~ynh1"
 
 maintainers = ["DeMiro5001"]
 
 [upstream]
-license = "BSD 3-Clause"
+license = "BSD-3-Clause"
 website = "https://openwebui.com/"
 admindoc = "https://docs.openwebui.com/getting-started/"
 userdoc = "https://docs.openwebui.com/category/-tutorials"
@@ -23,35 +23,22 @@ yunohost = ">= 12.0.9"
 helpers_version = "2.1"
 
 architectures = "all"
-multi_instance = true
+multi_instance = false
 
-ldap = false
+ldap = true
+sso = false
 
-# FIXME: replace with true, false, or "not_relevant".
-# Not to confuse with the "ldap" key: the "sso" key corresponds to wether or not a user is *automatically logged-in*
-# on the app when logged-in on the YunoHost portal.
-sso = "?"
-
-# FIXME: replace with an **estimate** minimum disk and RAM requirements. e.g. 20M, 400M, 1G...
-disk = "50M"
-ram.build = "50M"
-ram.runtime = "50M"
+disk = "10G"
+ram.build = "250M"
+ram.runtime = "2G"
 
 [install]
     [install.domain]
-    # this is a generic question - ask strings are automatically handled by YunoHost's core
     type = "domain"
 
-    [install.path]
-    # this is a generic question - ask strings are automatically handled by YunoHost's core
-    type = "path"
-    default = "/example"
-
     [install.init_main_permission]
-    # this is a generic question - ask strings are automatically handled by YunoHost's core
-    # This won't be saved as setting and will instead be used to initialize the SSOwat permission
     type = "group"
-    default = "visitors"
+    default = "all_users"
 
     [install.language]
     ask.en = "Choose the application language"
@@ -61,60 +48,28 @@ ram.runtime = "50M"
     default = "fr"
 
     [install.admin]
-    # this is a generic question - ask strings are automatically handled by YunoHost's core
     type = "user"
 
-    [install.password]
-    # this is a generic question - ask strings are automatically handled by YunoHost's core
-    # Note that user-provided passwords questions are not automatically saved as setting
-    help.en = "Use the help field to add an information for the admin about this question."
-    help.fr = "Utilisez le champ aide pour ajouter une information à l'intention de l'administrateur à propos de cette question."
-    type = "password"
-
 [resources]
-    # See the packaging documentation for the full set
-    # of explanation regarding the behavior and properties for each of those
 
     [resources.sources]
 
     [resources.sources.main]
-    # This will pre-fetch the asset which can then be deployed during the install/upgrade scripts with :
-    #    ynh_setup_source --dest_dir="$install_dir"
-    # You can also define other assets than "main" and add --source_id="foobar" in the previous command
-    url = "https://github.com/foo/bar/archive/refs/tags/v1.2.3.tar.gz"
-    sha256 = "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
+    url = "https://github.com/open-webui/open-webui/archive/refs/tags/v0.6.13.tar.gz"
+    sha256 = "fac82929489b70f38ee2bb2a1ce7857d431c94417f48142eb3574947b8beed8c"
 
-    # These infos are used by https://github.com/YunoHost/apps_tools/blob/main/autoupdate_app_sources/autoupdate_app_sources.py
-    # to auto-update the previous asset urls and sha256sum + manifest version
-    # assuming the upstream's code repo is on github and relies on tags or releases
-    # See the 'sources' resource documentation for more details
-
-    # autoupdate.strategy = "latest_github_tag"
+    autoupdate.strategy = "latest_github_tag"
 
     [resources.system_user]
-    # This will provision/deprovision a unix system user
 
     [resources.install_dir]
-    # This will create/remove the install dir as /var/www/$app
-    # and store the corresponding setting $install_dir
 
     [resources.data_dir]
-    # This will create/remove the data dir as /home/yunohost.app/$app
-    # and store the corresponding setting $data_dir
 
     [resources.permissions]
-    # This will configure SSOwat permission for $domain/$path/
-    # The initial allowed group of user is configured via the init_main_permission question (public=visitors, private=all_users)
     main.url = "/"
 
     [resources.ports]
-    # This will pick a random port for reverse-proxying and store it as the $port setting
 
     [resources.apt]
-    # This will automatically install/uninstall the following apt packages
-    # and implicitly define the $phpversion setting as 8.0 (if phpX.Y-foobar dependencies are listed)
-    packages = "mariadb-server, deb1, deb2, php8.3-foo, php8.3-bar"
-
-    [resources.database]
-    # This will automatically provision/deprovison a MySQL DB and store the corresponding credentials in settings $db_user, $db_name, $db_pwd
-    type = "mysql"
+    packages = "ffmpeg, python3-venv, python3-pip, python3-dev" 

scripts/backup

@@ -4,17 +4,11 @@
 # IMPORT GENERIC HELPERS
 #=================================================
 
-# Keep this path for calling _common.sh inside the execution's context of backup and restore scripts
 source ../settings/scripts/_common.sh
 source /usr/share/yunohost/helpers
 
 ynh_print_info "Declaring files to be backed up..."
 
-### N.B. : the following 'ynh_backup' calls are only a *declaration* of what needs
-### to be backuped and not an actual copy of any file. The actual backup that
-### creates and fills the archive with the files happens in the core after this
-### script is called. Hence ynh_backups calls take basically 0 seconds to run.
-
 #=================================================
 # BACKUP THE APP MAIN DIR
 #=================================================
@@ -25,54 +19,27 @@ ynh_backup "$install_dir"
 # BACKUP THE DATA DIR
 #=================================================
 
-# Only relevant if there is a "data_dir" resource for this app
-# NB: $data_dir is not backuped during safety-backup-before-upgrades,
-# because the data dir may be huge and we don't want to just yolo-create a 10+ GB archive just for upgrades.
-# On the other hand, $data_dir is also *not* removed by default in the "app remove" step unless --purge is used
-# This means that even if the upgrade fails and the backup is restored, the data are still there.
 ynh_backup "$data_dir"
 
 #=================================================
 # BACKUP SYSTEM CONFIGURATION
 #=================================================
 
-# Backup the PHP-FPM configuration
-ynh_backup "/etc/php/$php_version/fpm/pool.d/$app.conf"
-
-# Backup the NGINX configuration
 ynh_backup "/etc/nginx/conf.d/$domain.d/$app.conf"
 
-# Backup the systemd service unit
 ynh_backup "/etc/systemd/system/$app.service"
 
-# Backup the logrotate configuration
 ynh_backup "/etc/logrotate.d/$app"
 
-# Backup the Fail2Ban config
-ynh_backup "/etc/fail2ban/jail.d/$app.conf"
-ynh_backup "/etc/fail2ban/filter.d/$app.conf"
+#ynh_backup "/etc/fail2ban/jail.d/$app.conf"
+#ynh_backup "/etc/fail2ban/filter.d/$app.conf"
 
 #=================================================
 # BACKUP VARIOUS FILES
 #=================================================
 
-ynh_backup "/etc/cron.d/$app"
-
-ynh_backup "/etc/$app/"
-
-# NB: /var/log is not backuped during safety-backup-before-upgrades, same as $data_dir
 ynh_backup "/var/log/$app/"
 
-#=================================================
-# BACKUP THE MYSQL DATABASE
-#=================================================
-ynh_print_info "Backing up the MySQL database..."
-
-### (However, things like MySQL dumps *do* take some time to run, though the
-### copy of the generated dump to the archive still happens later)
-
-ynh_mysql_dump_db > db.sql
-
 #=================================================
 # END OF SCRIPT
 #=================================================

scripts/change_url

@@ -31,6 +31,10 @@ ynh_config_change_url_nginx
 #=================================================
 
 ## do any changes to files that reference specific installation domain/path, i.e. regenerate configs etc
+ynh_config_add --template=".env" --destination="$install_dir/.env"
+
+chmod 400 "$install_dir/.env"
+chown "$app:$app" "$install_dir/.env"
 
 #=================================================
 # START SYSTEMD SERVICE

scripts/config

@@ -1,96 +0,0 @@
-#!/bin/bash
-# In simple cases, you don't need a config script.
-
-# With a simple config_panel.toml, you can write in the app settings, in the
-# upstream config file or replace complete files (logo ...) and restart services.
-
-# The config scripts allows you to go further, to handle specific cases
-# (validation of several interdependent fields, specific getter/setter for a value,
-# display dynamic informations or choices, pre-loading of config type .cube... ).
-
-#=================================================
-# IMPORT GENERIC HELPERS
-#=================================================
-
-source /usr/share/yunohost/helpers
-
-ynh_abort_if_errors
-
-#=================================================
-# RETRIEVE ARGUMENTS
-#=================================================
-
-install_dir=$(ynh_app_setting_get --key=install_dir)
-
-#=================================================
-# SPECIFIC GETTERS FOR TOML SHORT KEY
-#=================================================
-
-get__amount() {
-    # Here we can imagine to have an API call to stripe to know the amount of donation during a month
-    local amount=200
-
-    # It's possible to change some properties of the question by overriding it:
-    if [ "$amount" -gt 100 ]; then
-    cat << EOF
-style: success
-value: $amount
-ask:
-  en: A lot of donation this month: **$amount €**
-EOF
-    else
-    cat << EOF
-style: danger
-value: $amount
-ask:
-  en: Not so much donation this month: $amount €
-EOF
-    fi
-}
-
-get__prices() {
-    local prices
-    prices="$(grep "DONATION\['" "$install_dir/settings.py" | sed -r "s@^DONATION\['([^']*)'\]\['([^']*)'\] = '([^']*)'@\1/\2/\3@g" | sed -z 's/\n/,/g;s/,$/\n/')"
-    if [ "$prices" == "," ]; then
-        # Return YNH_NULL if you prefer to not return a value at all.
-        echo YNH_NULL
-    else
-        echo "$prices"
-    fi
-}
-
-#=================================================
-# SPECIFIC VALIDATORS FOR TOML SHORT KEYS
-#=================================================
-validate__publishable_key() {
-
-    # We can imagine here we test if the key is really a publishable key
-    (is_secret_key "$publishable_key") &&
-        echo 'This key seems to be a secret key'
-}
-
-#=================================================
-# SPECIFIC SETTERS FOR TOML SHORT KEYS
-#=================================================
-set__prices() {
-
-    #---------------------------------------------
-    # IMPORTANT: setters are triggered only if a change is detected
-    #---------------------------------------------
-    for price in $(echo "$prices" | sed "s/,/ /"); do
-        frequency=$(echo "$price" | cut -d/ -f1)
-        currency=$(echo "$price" | cut -d/ -f2)
-        price_id=$(echo "$price" | cut -d/ -f3)
-        sed "d/DONATION\['$frequency'\]\['$currency'\]" "$install_dir/settings.py"
-
-        echo "DONATION['$frequency']['$currency'] = '$price_id'" >> "$install_dir/settings.py"
-    done
-
-    #---------------------------------------------
-    # IMPORTANT: to be able to upgrade properly, you have to save the value in settings too
-    #---------------------------------------------
-    ynh_app_setting_set --key=prices --value="$prices"
-}
-
-#=================================================
-ynh_app_config_run "$1"

scripts/install

@@ -7,52 +7,29 @@
 source _common.sh
 source /usr/share/yunohost/helpers
 
-### Install parameters are automatically saved as settings
-###
-### Settings are automatically loaded as bash variables
-### in every app script context, therefore typically these will exist:
-### - $domain
-### - $path
-### - $language
-### ... etc
-###
-### Resources defined in the manifest are provisioned prior to this script
-### and corresponding settings are also available, such as:
-### - $install_dir
-### - $port
-### - $db_name
-### ...
-###
-### $app is the app id (i.e. 'example' for first install,
-### or 'example__2', '__3'... for multi-instance installs)
+mail=$(ynh_user_get_info --username=$admin --key=mail)
 
 #=================================================
 # INITIALIZE AND STORE SETTINGS
 #=================================================
 
-# If you need to, you can define custom settings
-# (or remove this section entirely if not relevant for you)
-foo="bar"
-ynh_app_setting_set --key=foo --value=$foo
-
-ynh_app_setting_set --key=php_upload_max_filesize --value=50M
-ynh_app_setting_set --key=php_post_max_size --value=50M
-
 #=================================================
 # DOWNLOAD, CHECK AND UNPACK SOURCE
 #=================================================
 ynh_script_progression "Setting up source files..."
 
-### `ynh_setup_source` is used to install an app from a zip or tar.gz file,
-### downloaded from an upstream source, like a git repository.
-### `ynh_setup_source` use the file manifest.toml
-
-# Download, check integrity, uncompress and patch the source from manifest.toml
 ynh_setup_source --dest_dir="$install_dir"
 
-### $install_dir will automatically be initialized with some decent
-### permission by default... however, you may need to recursively reapply
-### ownership to all files such as after the ynh_setup_source step
+chown -R "$app:www-data" "$install_dir"
+
+pushd $install_dir
+ python3 -m venv venv
+ echo "source $install_dir/venv/bin/activate" >> $install_dir/.bashrc
+ source "$install_dir/venv/bin/activate"
+ pip install open-webui
+ deactivate
+popd
+
 chown -R "$app:www-data" "$install_dir"
 
 #=================================================
@@ -60,137 +37,25 @@ chown -R "$app:www-data" "$install_dir"
 #=================================================
 ynh_script_progression "Adding $app's configuration files..."
 
-### You can add specific configuration files.
-###
-### Typically, put your template conf file in ../conf/your_config_file
-### The template may contain strings such as __FOO__ or __FOO_BAR__,
-### which will automatically be replaced by the values of $foo and $foo_bar
-###
-### ynh_config_add will also keep track of the config file's checksum,
-### which later during upgrade may allow to automatically backup the config file
-### if it's found that the file was manually modified
-###
-### Check the documentation of `ynh_config_add` for more info.
-
-ynh_config_add --template="some_config_file" --destination="$install_dir/some_config_file"
-
-# FIXME: this should be handled by the core in the future
-### You may need to use chmod 600 instead of 400,
-### for example if the app is expected to be able to modify its own config
-chmod 400 "$install_dir/some_config_file"
-chown "$app:$app" "$install_dir/some_config_file"
-
-### For more complex cases where you want to replace stuff using regexes,
-### you shoud rely on ynh_replace (which is basically a wrapper for sed)
-### When doing so, you also need to manually call ynh_store_file_checksum
-###
-### ynh_replace --match="match_string" --replace="replace_string" --file="$install_dir/some_config_file"
-### ynh_store_file_checksum "$install_dir/some_config_file"
+ynh_config_add --template=".env" --destination="$install_dir/.env"
+
+chmod 400 "$install_dir/.env"
+chown "$app:$app" "$install_dir/.env"
 
 #=================================================
 # SYSTEM CONFIGURATION
 #=================================================
 ynh_script_progression "Adding system configurations related to $app..."
 
-### `ynh_config_add_phpfpm` is used to set up a PHP config.
-### You can remove it if your app doesn't use PHP.
-### `ynh_config_add_phpfpm` will use the files conf/extra_php-fpm.conf
-### If you're not using these lines:
-###   - You can remove these files in conf/.
-###   - Remove the section "BACKUP THE PHP-FPM CONFIGURATION" in the backup script
-###   - Remove also the section "REMOVE PHP-FPM CONFIGURATION" in the remove script
-###   - As well as the section "RESTORE THE PHP-FPM CONFIGURATION" in the restore script
-###     with the reload at the end of the script.
-###   - And the section "PHP-FPM CONFIGURATION" in the upgrade script
-
-# Create a PHP-FPM config (with conf/extra_php-fpm.conf being appended to it)
-ynh_config_add_phpfpm
-
-# Create a dedicated NGINX config using the conf/nginx.conf template
 ynh_config_add_nginx
 
-### `ynh_config_add_systemd` is used to configure a systemd script for an app.
-### It can be used for apps that use sysvinit (with adaptation) or systemd.
-### Have a look at the app to be sure this app needs a systemd script.
-### `ynh_config_add_systemd` will use the file conf/systemd.service
-### If you're not using these lines:
-###   - You can remove those files in conf/.
-###   - Remove the section "BACKUP SYSTEMD" in the backup script
-###   - Remove also the section "STOP AND REMOVE SERVICE" in the remove script
-###   - As well as the section "RESTORE SYSTEMD" in the restore script
-###   - And the section "SETUP SYSTEMD" in the upgrade script
-
-# Create a dedicated systemd config
 ynh_config_add_systemd
 
-### `yunohost service add` integrates a service in YunoHost. It then gets
-### displayed in the admin interface and through the others `yunohost service` commands.
-### (N.B.: this line only makes sense if the app adds a service to the system!)
-### If you're not using these lines:
-###   - You can remove these files in conf/.
-###   - Remove the section "REMOVE SERVICE INTEGRATION IN YUNOHOST" in the remove script
-###   - As well as the section "INTEGRATE SERVICE IN YUNOHOST" in the restore script
-###   - And the section "INTEGRATE SERVICE IN YUNOHOST" in the upgrade script
-
-### Additional options starting with 3.8:
-###
-### --needs_exposed_ports "$port" a list of ports that needs to be publicly exposed
-###                               which will then be checked by YunoHost's diagnosis system
-###                               (N.B. DO NOT USE THIS if the port is only internal!!!)
-###
-### --test_status "some command"  a custom command to check the status of the service
-###                               (only relevant if 'systemctl status' doesn't do a good job)
-###
-### --test_conf "some command"    some command similar to "nginx -t" that validates the conf of the service
-###
-### Re-calling 'yunohost service add' during the upgrade script is the right way
-### to proceed if you later realize that you need to enable some flags that
-### weren't enabled on old installs (be careful it'll override the existing
-### service though so you should re-provide all relevant flags when doing so)
-yunohost service add "$app" --description="A short description of the app" --log="/var/log/$app/$app.log"
-
-### `ynh_config_add_logrotate` is used to configure a logrotate configuration for the logs of this app.
-### Use this helper only if there is effectively a log file for this app.
-### If you're not using this helper:
-###   - Remove the section "BACKUP LOGROTATE" in the backup script
-###   - Remove also the section "REMOVE LOGROTATE CONFIGURATION" in the remove script
-###   - As well as the section "RESTORE THE LOGROTATE CONFIGURATION" in the restore script
-###   - And the section "SETUP LOGROTATE" in the upgrade script
-
-# Use logrotate to manage application logfile(s)
-ynh_config_add_logrotate
-
-# Create a dedicated Fail2Ban config
-ynh_config_add_fail2ban --logpath="/var/log/nginx/${domain}-error.log" --failregex="Regex to match into the log for a failed login"
-
-#=================================================
-# SETUP APPLICATION WITH CURL
-#=================================================
-
-### Use these lines only if the app installation needs to be finalized through
-### web forms. We generally don't want to ask the final user,
-### so we're going to use curl to automatically fill the fields and submit the
-### forms.
+yunohost service add "$app" --description="User-friendly AI Interface (Supports Ollama, OpenAI API, ...)" --log="/var/log/$app/$app.log"
 
-# Installation with curl
-ynh_script_progression "Finalizing installation..."
-ynh_local_curl "/INSTALL_PATH" "key1=value1" "key2=value2" "key3=value3"
+ynh_config_add_logrotate
 
-#=================================================
-# START SYSTEMD SERVICE
-#=================================================
-ynh_script_progression "Starting $app's systemd service..."
-
-### `ynh_systemctl` is used to start a systemd service for an app.
-### Only needed if you have configure a systemd service
-### If you're not using these lines:
-###   - Remove the section "STOP SYSTEMD SERVICE" and "START SYSTEMD SERVICE" in the backup script
-###   - As well as the section "START SYSTEMD SERVICE" in the restore script
-###   - As well as the section"STOP SYSTEMD SERVICE" and "START SYSTEMD SERVICE" in the upgrade script
-###   - And the section "STOP SYSTEMD SERVICE" and "START SYSTEMD SERVICE" in the change_url script
-
-# Start a systemd service
-ynh_systemctl --service="$app" --action="start"
+#ynh_config_add_fail2ban --logpath="/var/log/nginx/${domain}-error.log" --failregex="Regex to match into the log for a failed login"
 
 #=================================================
 # END OF SCRIPT

scripts/remove

@@ -7,45 +7,21 @@
 source _common.sh
 source /usr/share/yunohost/helpers
 
-### Settings are automatically loaded as bash variables
-### in every app script context, therefore typically these will exist:
-### - $domain
-### - $path
-### - $language
-### - $install_dir
-### - $port
-### ...
-
-### For remove operations:
-### - the core will deprovision every resource defined in the manifest **after** this script is ran
-### this includes removing the install directory, and data directory (if --purge was used)
-
 #=================================================
 # REMOVE SYSTEM CONFIGURATION
 #=================================================
 ynh_script_progression "Removing system configurations related to $app..."
 
-### This should be a symetric version of what happens in the install script
-
-ynh_config_remove_fail2ban
-
-ynh_config_remove_logrotate
-
-# Remove the service from the list of services known by YunoHost (added from `yunohost service add`)
 if ynh_hide_warnings yunohost service status "$app" >/dev/null; then
     yunohost service remove "$app"
 fi
 ynh_config_remove_systemd
 
-ynh_config_remove_nginx
-
-ynh_config_remove_phpfpm
-
-# Remove other various files specific to the app... such as:
+#ynh_config_remove_fail2ban
 
-ynh_safe_rm "/etc/cron.d/$app"
+ynh_config_remove_logrotate
 
-ynh_safe_rm "/etc/$app"
+ynh_config_remove_nginx
 
 #=================================================
 # END OF SCRIPT

scripts/restore

@@ -14,10 +14,6 @@ source /usr/share/yunohost/helpers
 ynh_script_progression "Restoring the app main directory..."
 
 ynh_restore "$install_dir"
-
-### $install_dir will automatically be initialized with some decent
-### permissions by default... however, you may need to recursively reapply
-### ownership to all files such as after the ynh_setup_source step
 chown -R "$app:www-data" "$install_dir"
 
 #=================================================
@@ -26,53 +22,29 @@ chown -R "$app:www-data" "$install_dir"
 ynh_script_progression "Restoring the data directory..."
 
 ynh_restore "$data_dir"
-
-### (Same as for install dir)
 chown -R "$app:www-data" "$data_dir"
 
-#=================================================
-# RESTORE THE MYSQL DATABASE
-#=================================================
-ynh_script_progression "Restoring the MySQL database..."
-
-ynh_mysql_db_shell < ./db.sql
-
 #=================================================
 # RESTORE SYSTEM CONFIGURATION
 #=================================================
 ynh_script_progression "Restoring system configurations related to $app..."
 
-### This should be a symetric version of what happens in the install script
-
-ynh_restore "/etc/php/$php_version/fpm/pool.d/$app.conf"
-
 ynh_restore "/etc/nginx/conf.d/$domain.d/$app.conf"
 
 ynh_restore "/etc/systemd/system/$app.service"
 systemctl enable "$app.service" --quiet
-
-yunohost service add "$app" --description="A short description of the app" --log="/var/log/$app/$app.log"
+yunohost service add "$app" --description="User-friendly AI Interface (Supports Ollama, OpenAI API, ...)" --log="/var/log/$app/$app.log"
 
 ynh_restore "/etc/logrotate.d/$app"
 
-ynh_restore "/etc/fail2ban/jail.d/$app.conf"
-ynh_restore "/etc/fail2ban/filter.d/$app.conf"
-ynh_systemctl --action=restart --service=fail2ban
+#ynh_restore "/etc/fail2ban/jail.d/$app.conf"
+#ynh_restore "/etc/fail2ban/filter.d/$app.conf"
+#ynh_systemctl --action=restart --service=fail2ban
 
 #=================================================
 # RESTORE VARIOUS FILES
 #=================================================
 
-ynh_restore "/etc/cron.d/$app"
-ynh_restore "/etc/$app/"
-
-### For apps with huge logs, you might want to not backup logs every time:
-### The mkdir call is just here in case the log directory was not backed up.
-### mkdir -p "/var/log/$app"
-### chown $app:www-data "/var/log/$app"
-### ynh_restore "/var/log/$app/" || true
-###
-### For other apps, the simple way is better:
 ynh_restore "/var/log/$app/"
 
 #=================================================
@@ -80,11 +52,6 @@ ynh_restore "/var/log/$app/"
 #=================================================
 ynh_script_progression "Reloading NGINX web server and $app's service..."
 
-### Typically you only have either $app or PHP-FPM but not both at the same time...
-ynh_systemctl --service="$app" --action="start"
-
-ynh_systemctl --service="php$php_version-fpm" --action=reload
-
 ynh_systemctl --service=nginx --action=reload
 
 #=================================================

scripts/upgrade

@@ -7,19 +7,6 @@
 source _common.sh
 source /usr/share/yunohost/helpers
 
-### Settings are automatically loaded as bash variables
-### in every app script context, therefore typically these will exist:
-### - $domain
-### - $path
-### - $language
-### - $install_dir
-### - $port
-### ...
-
-### In the context of upgrade,
-### - resources are automatically provisioned / updated / deleted (depending on existing resources)
-### - a safety backup is automatically created by the core and will be restored if the upgrade fails
-
 #=================================================
 # STOP SYSTEMD SERVICE
 #=================================================
@@ -27,85 +14,30 @@ ynh_script_progression "Stopping $app's systemd service..."
 
 ynh_systemctl --service="$app" --action="stop"
 
-#=================================================
-# ENSURE DOWNWARD COMPATIBILITY
-#=================================================
-ynh_script_progression "Ensuring downward compatibility..."
-
-ynh_app_setting_set_default --key=php_upload_max_filesize --value=50M
-ynh_app_setting_set_default --key=php_post_max_size --value=50M
-
-### N.B. : the following setting migration snippets are provided as *EXAMPLES*
-### of what you may want to do in some cases (e.g. a setting was not defined on
-### some legacy installs and you therefore want to initiaze stuff during upgrade)
-
-# If db_name doesn't exist, create it
-# ynh_app_setting_set_default --key=db_name --value="$(ynh_sanitize_dbid --db_name=$app)"
-
-# If install_dir doesn't exist, create it
-# ynh_app_setting_set_default --key=install_dir --value="/var/www/$app"
-
 #=================================================
 # DOWNLOAD, CHECK AND UNPACK SOURCE
 #=================================================
-ynh_script_progression "Upgrading source files..."
-
-### ynh_setup_source can wipe the destination dir if called with --full_replace.
-### On upgrade, that is certainly what you want, to remove any old source file that
-### does not exist in the new version of the software.
-### You can list with --keep every file/directory to *not* wipe or overwrite,
-### useful for configuration files, data directories, or plugins.
-# Download, check integrity, uncompress and patch the source from manifest.toml
-ynh_setup_source --dest_dir="$install_dir" --full_replace --keep=".env data"
-
-### $install_dir will automatically be initialized with some decent
-### permissions by default... however, you may need to recursively reapply
-### ownership to all files such as after the ynh_setup_source step
-chown -R "$app:www-data" "$install_dir"
 
-#=================================================
-# UPDATE A CONFIG FILE
-#=================================================
-ynh_script_progression "Updating $app's configuration files..."
-
-### Same as during install
-###
-### The file will automatically be backed-up if it's found to be manually modified (because
-### ynh_config_add keeps track of the file's checksum)
-
-ynh_config_add --template="some_config_file" --destination="$install_dir/some_config_file"
+pushd $install_dir
+ ynh_exec_as_app $install_dir/pip install -U open-webui
+popd
 
-# FIXME: this should be handled by the core in the future
-### You may need to use chmod 600 instead of 400,
-### for example if the app is expected to be able to modify its own config
-chmod 400 "$install_dir/some_config_file"
-chown "$app:$app" "$install_dir/some_config_file"
-
-### For more complex cases where you want to replace stuff using regexes,
-### you shoud rely on ynh_replace (which is basically a wrapper for sed)
-### When doing so, you also need to manually call ynh_store_file_checksum
-###
-### ynh_replace --match="match_string" --replace="replace_string" --file="$install_dir/some_config_file"
-### ynh_store_file_checksum "$install_dir/some_config_file"
+chown -R "$app:www-data" "$install_dir"
 
 #=================================================
 # REAPPLY SYSTEM CONFIGURATION
 #=================================================
 ynh_script_progression "Upgrading system configurations related to $app..."
 
-### This should be a literal copypaste of what happened in the install's "System configuration" section
-
-ynh_config_add_phpfpm
-
 ynh_config_add_nginx
 
 ynh_config_add_systemd
 
-yunohost service add "$app" --description="A short description of the app" --log="/var/log/$app/$app.log"
+yunohost service add "$app" --description="User-friendly AI Interface (Supports Ollama, OpenAI API, ...)" --log="/var/log/$app/$app.log"
 
 ynh_config_add_logrotate
 
-ynh_config_add_fail2ban --logpath="/var/log/nginx/${domain}-error.log" --failregex="Regex to match into the log for a failed login"
+#ynh_config_add_fail2ban --logpath="/var/log/nginx/${domain}-error.log" --failregex="Regex to match into the log for a failed login"
 
 #=================================================
 # START SYSTEMD SERVICE