Form missing on login

Now I’ve installed Corteza native from corteza-server-2022.3.1-linux-amd64.tar.gz on Ubuntu 20.04.
Starting with ./corteza-server serve-api shows no errors. But when opening localhost:18080 in the browser, shows only bakcground and header without the login form (see attachment).
What is here missing?

I would first look at the settings. Is internal (or any other type) login enabled?
Are you sure DB was provisioned without error?

Can you compare contents of your settings table to one generated from the docker instance?

If you started corteza-server directly, did you create an .env file or provided any kind of environmental variables?

Where can I set the login type?

Here are the environment variables (defined in bash.bashrc):
export DOMAIN=localhost
export PATH=/corteza/bin:$PATH
export LOG_DEBUG=true
export AUTH_JWT_SECRET=this-is-only-for-secret-purpose–make-sure-you-change-it-for-xxxxx
export HOME=/root
export HTTP_ADDR=
export DB_DSN=postgres://corteza:corteza@localhost:5432/corteza?sslmode=disable
export HTTP_WEBAPP_BASE_DIR=/corteza/webapp
export VERSION=2022.3.1
export STORAGE_PATH=/data
export _=/usr/bin/printenv
export OLDPWD=/corteza
export POSTGRES_USER=corteza
export POSTGRES_PASSWORD=corteza

The following messages are shown after starting corteza-server:
20:02:26.796 DEBUG http.waiting server/handlers.go:209 version route enabled: /version
20:02:26.799 DEBUG http.waiting server/handlers.go:226 health check route enabled: /healthcheck
20:02:26.800 INFO http server/server.go:68 starting HTTP server {“path-prefix”: “/”, “address”: “”}
20:02:26.853 DEBUG store.rdbms rdbms/rdbms.go:91 opening connection {“driver”: “postgres”, “dsn”: “pa:ca@localhost:5432/corteza?sslmode=disable”}
20:02:26.856 DEBUG store.rdbms rdbms/rdbms.go:91 setting connection parameters {“MaxOpenConns”: 256, “MaxLifetime”: “10m0s”, “MaxIdleConns”: 32}
20:02:26.862 DEBUG store.rdbms rdbms/rdbms.go:183 connected to the database
20:02:26.862 INFO app/boot_levels.go:188 running store update
20:02:26.862 INFO app/boot_levels.go:201 store upgrade running (to enable upgrade debug logging set UPGRADE_DEBUG=true)
20:02:26.975 INFO provision/roles.go:67 updating system role {“handle”: “super-admin”, “ID”: 0}
20:02:26.975 INFO provision/roles.go:67 updating system role {“handle”: “authenticated”, “ID”: 0}
20:02:26.975 INFO provision/roles.go:67 updating system role {“handle”: “anonymous”, “ID”: 0}
20:02:26.984 DEBUG app/boot_levels.go:663 system entities set {“users”: [281115476774400550, 281115476774466086, 281115476791177766], “roles”: [281115476757623334, 281115476757688870, 281115476757754406]}
20:02:26.994 INFO provision.pre-202109-roles provision/migrations_202109_roles.go:17 migrating pre-2021.9 roles
20:02:26.994 INFO provision.pre-202109-rbac-rules provision/migrations_202109_rbac.go:37 migrating RBAC rules to new format {“rules”: 0}
20:02:27.001 INFO provision.pre-202109-settings provision/migrations_202109_settings_cleanup.go:11 cleaning up pre-2021.9 settings
20:02:27.004 INFO provision.resource-translations provision/migrations_202109_resource_translations.go:28 migrating resource locales
20:02:27.007 INFO provision.resource-translations provision/migrations_202109_resource_translations.go:87 migrating compose namespaces {“count”: 0}
20:02:27.007 INFO provision.resource-translations provision/migrations_202109_resource_translations.go:107 migrating compose modules {“count”: 0}
20:02:27.007 INFO provision.resource-translations provision/migrations_202109_resource_translations.go:181 migrating compose pages {“count”: 0}
20:02:27.008 INFO provision/migrations_202203_report_identifiers.go:17 migrating report identifiers
20:02:27.009 INFO provision.config provision/config.go:50 importing all configs {“paths”: “provision/*”}
20:02:27.011 DEBUG provision.auth.oidc-auto-discovery provision/oidc.go:22 OIDC auto discovery provision {“envkey”: “PROVISION_OIDC_PROVIDER”, “providers”: “”}
20:02:27.014 INFO service/service.go:174 initializing store {“path”: “/data/system”}
20:02:27.015 DEBUG rbac.roles service/role.go:848 setting system roles {“roles”: [“super-admin”, “authenticated”, “anonymous”]}
20:02:27.015 DEBUG rbac.roles service/role.go:852 setting closed roles {“roles”: [“authenticated”, “anonymous”]}
20:02:27.015 DEBUG rbac.roles service/role.go:900 bypass role added {“ID”: 281115476757623334, “handle”: “super-admin”}
20:02:27.015 DEBUG rbac.roles service/role.go:910 authenticated role added {“ID”: 281115476757688870, “handle”: “authenticated”}
20:02:27.015 DEBUG rbac.roles service/role.go:905 anonymous role added {“ID”: 281115476757754406, “handle”: “anonymous”}
20:02:27.018 INFO service/service.go:156 initializing store {“path”: “/data/compose”}
20:02:27.029 INFO http.apigw apigw/service.go:304 loading Integration Gateway {“debug”: false, “log”: false}
20:02:27.030 INFO http.apigw apigw/service.go:312 request body logging is enabled, profiler use is prefered (APIGW_PROFILER_ENABLED) {“APIGW_LOG_REQUEST_BODY”: false}
20:02:27.030 WARN http.apigw apigw/service.go:317 profiler enabled only for routes with a profiler prefilter, use global setting to enable for all (APIGW_PROFILER_GLOBAL)
20:02:27.030 DEBUG http.apigw apigw/service.go:146 registering routes {“count”: 0}
20:02:27.030 DEBUG corredor corredor/service.go:228 watcher initialized
20:02:27.030 DEBUG workflow.session service/session.go:359 watcher initialized
20:02:27.030 DEBUG scheduler scheduler/service.go:116 starting{“delay”: “32.969840654s”, “interval”: “1m0s”}
20:02:27.030 DEBUG monitor monitor/monitor.go:36 watcher initialized {“interval”: “5m0s”}
20:02:27.035 DEBUG service.settings service/settings.go:68 registering new settings change listener {“prefix”: “smtp”}
20:02:27.036 INFO app/boot_levels.go:855 reloading SMTP configuration {“host”: “localhost”, “port”: 25, “user”: “”, “pass”: “”, “tsl-insecure”: false, “tls-server-name”: “”}
20:02:27.041 INFO auth auth/auth.go:202 auth server ready {“AUTH_BASE_URL”: “”, “AUTH_EXTERNAL_REDIRECT_URL”: “http://localhost/auth/external/{provider}/callback”}
20:02:27.041 DEBUG service.settings service/settings.go:68 registering new settings change listener {“prefix”: “auth.”}
20:02:27.041 DEBUG service.settings service/settings.go:68 registering new settings change listener {“prefix”: “resource-translations.languages”}
20:02:27.041 INFO auth auth/auth.go:354 running startup garbage collection
20:02:27.041 INFO auth auth/auth.go:362 starting garbage collecting process {“interval”: “15m0s”}
20:02:27.041 INFO app/servers.go:44 embedded web assets mounted {“url”: “/assets”}
20:02:27.044 INFO app/servers.go:62 client web applications enabled{“baseUrl”: “/”, “baseDir”: “/corteza/webapp”, “apps”: [“admin”, “compose”, “workflow”, “reporter”]}
20:02:27.044 INFO app/servers.go:82 JSON REST API enabled {“baseUrl”: “/api”}
20:02:27.047 INFO app/servers.go:101 API docs enabled {“baseUrl”: “/api/docs”}
20:02:27.047 DEBUG http server/handlers.go:209 version route enabled: /version
20:02:27.047 DEBUG http server/handlers.go:226 health check route enabled: /healthcheck
20:02:27.048 DEBUG http server/server.go:57 entering active state
20:02:52.749 INFO service.reminder service/reminder.go:308 stopped
20:02:52.749 DEBUG messagebus/service.go:103 quitting from messagebus listener
20:02:52.748 INFO http server/server.go:101 HTTP server stopped
20:02:52.749 INFO workflow.session service/session.go:311 stopped
20:02:52.749 INFO auth auth/auth.go:369 stopping gc {“error”: “context canceled”}
20:02:52.749 DEBUG http server/server.go:63 entering shutdown state

That output, at first glance, seems fine to me.

can you checkout the contents of the database to see how the settings are?
Run select * from settings where name like '%auth%';

it should be something similar to:

| rel_owner | name                                             | value              | updated_by | updated_at          |
|         0 | | false              |          0 | 2022-05-02 10:40:35 |
|         0 | auth.internal.password-reset.enabled             | false              |          0 | 2022-05-02 10:40:35 |
|         0 | auth.external.enabled                            | true               |          0 | 2022-05-02 10:46:34 |
|         0 | auth.mail.from-address                           | "info@example.tld" |          0 | 2022-05-02 10:46:34 |
|         0 | auth.mail.from-name                              | "Corteza"          |          0 | 2022-05-02 10:46:34 |
|         0 | auth.internal.enabled                            | true               |          0 | 2022-05-02 10:46:34 |
|         0 | auth.internal.signup.enabled                     | true               |          0 | 2022-05-02 10:46:34 |

Hi Tomaz,

Thank you for your answer. But now I’ve had enough of the problem and have reinstalled the computer as well the Docker version installed. With the help of Denis I created a working yaml file.

But your reference to the settings table in the database will probably help me with future questions about Installation of Corteza.

But I would like to ask a new question:
Corteza is open source and free to use. But Docker has been no longer free for companies with more than 250 employees since January 31, 2022. There will be a minimum of $5 per user
and month calculated. I.e. a small organizational unit in a larger company that wants to use Corteza must pay Docker fee.
The question arises as to how Planet Crust handles this. Planet Crust has
certainly more than 250 users and the price is under $5 per user per month.

My point is:
I think it would be useful if the Corteza project provided a description for
the native installation without Docker (including addons such as Corredor or Discovery). That would be facilitate the decision for Corteza for some commercial customers.