About config/nginx/app.conf in bundled_ssl of v2.2.0-latest

[shinobifuku]

I cloned SEB Server v2.2.0-latest from GitHub to an Ubuntu server and tried to run the bundle_ssl container. However, after executing docker compose up -d, I could not access the server from the browser. When I checked the running status with docker ps, I found that seb-server-proxy was repeatedly restarting. The logs showed that the cause was an inability to reach the sps-server (not found).

I compared the config/nginx/app.conf files of the bundle and bundle_ssl versions, and found the following differences besides the certificate-related settings:

bundle version:

location /sps-web/ {
proxy_pass http://sps-webservice:8090/;
}
location /sps-gui/ {
proxy_pass http://sps-guiservice:3000/;
}

bundle_ssl version:

location /sps-web/ {
proxy_pass http://sps-server:8090/;
}
location /sps-gui/ {
proxy_pass http://sps-gui:3000/;
}

Since the bundle version works correctly, I modified the bundle_ssl app.conf to use sps-webservice and sps-guiservice in the same way. After rebuilding, the seb-server-proxy restart loop stopped and I was able to access the SEB Server admin UI via the browser.

My question is: does this mean that the config/nginx/app.conf provided for the bundle_ssl setup in the v2.2.0-latest package contains incorrect (or outdated) settings? Or did I make a fundamental mistake, and the original app.conf should work as-is?

[anhefti]

Hi

After I've checked the two different app.conf nginx configuration from the different setups, I see you are right about that. Tanks you for reporting.

We changed the names of the services so that they have the same names over all setups. And forgot the change the names within app.config in the bundled_ssl setup.

I now changed added the correct names to the setup and it should work now.

Thank you again, best regards

[shinobifuku]

Thank you for the fix. I cloned the repository again from GitHub and confirmed that the bundled_ssl/config/nginx/app.conf file has been updated.

I’m not sure if I should open a separate thread for this, but I’d like to ask an additional question regarding the installation of the SEB Server.

As I mentioned earlier, after modifying app.conf to match the bundled version, the SEB Server admin interface was mostly working correctly. However, when trying to use the screen proctoring features, some errors has occured like as 'Failed to get access token for SEB Screen Proctoring Service: Error requesting access token'. I wanted to resolve that issue, but since I had made my own changes to app.conf, I suspected that my modification might have caused the error—so I asked first to confirm whether my changes were correct.

Thanks to your response, I understand now that the authentication error was not caused by my changes to app.conf. So I pulled the updated SEB Server again and, after starting it with docker compose up -d, I checked the startup logs using docker logs seb-server. Before even attempting any screen-proctoring-related actions, I noticed that several errors were already being output, even though nothing had been connected yet.

Error querying database. Cause: java.sql.SQLSyntaxErrorException: (conn=44) Table 'SEBServer.webservice_server_info' doesn't exist

The error may exist in ch/ethz/seb/sebserver/webservice/datalayer/batis/mapper/WebserviceServerInfoRecordMapper.java (best guess)

The error may involve ch.ethz.seb.sebserver.webservice.datalayer.batis.mapper.WebserviceServerInfoRecordMapper.selectMany-Inline

The error occurred while setting parameters

SQL: select id, uuid, service_address, master, update_time from webservice_server_info

Cause: java.sql.SQLSyntaxErrorException: (conn=44) Table 'SEBServer.webservice_server_info' doesn't exist

and

25.11.2025 04:00:53.977 INFO [main]:[ch.ethz.seb.SEB_SERVER_INIT] ----> **** Start Migration ************************************
25.11.2025 04:00:54.259 WARN [main]:[org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor] DB: Duplicate column name 'townhall_room' (SQL State: - Error Code: 1060)
25.11.2025 04:00:54.487 WARN [main]:[org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor] DB: Unknown table 'SEBServer.seb_security_key_registry' (SQL State: - Error Code: 1051)
25.11.2025 04:00:54.696 WARN [main]:[org.flywaydb.core.internal.sqlscript.DefaultSqlScriptExecutor] DB: Data truncated for column 'name' at row 6 (SQL State: - Error Code: 1265)
25.11.2025 04:00:54.767 INFO [main]:[ch.ethz.seb.SEB_SERVER_INIT] ----> Migration finished, new current version is: 36 --> new seb settings v2 2
25.11.2025 04:00:54.767 INFO [main]:[ch.ethz.seb.SEB_SERVER_INIT] ----> **** End Migration **************************************

I don’t recall seeing anything in the manual mentioning that initial configuration of the database or similar steps were required. Are these errors expected even in a normal, healthy setup?

P.S.
This time, I also tested it with the bundled version, and the same error occurred there as well.

[anhefti]

Hi,

The first error: Table 'SEBServer.webservice_server_info' doesn't exist, can happen when seb-server starts up the first time, when there is no Database and the Database has to be created from seb-server on startup Migration Task (this also applies to sps-webservice). The seb-server application constantly ties to register itself as alive on the database. But for the first time, if there is no database yet or the table hasn't been created, this error appears. It should go away as soon as the Database has been created and the migration process is over.

The warnings in the migration process can be ignored. They also should only appear on the fist startup. On your example the migration ends with no errors and with version 36, which is the correct last migration version for SEB Server 2.2.x,

So as I can see here, your initial startup seems to be functional and the Database should be ready.

When you have problems connecting to integrated Screen Proctoring or if SEB Clients connect connect to SEB Server, this is mostly related to configuration issues. The sps-webservice also initializes a Database and adds an API user account for SEB Server to be managed by SEB Server. In your case it seems that seb-server is not able to connect to sps-webservice with this generated API account. You can check the fallowing:

As for default the seb-server settings to connect to sps-webservice are in docker-compose.yml file:

    # Screen Proctoring settings and passwords
    # NOTE: these must match with the respective equivalents on sps-webservice
    - sebserver_feature_exam_seb_screenProctoring_bundled_url=https://${DNS_NAME}/sps-web
    - sps_sebserver_client_secret=${SEBSERVER_PWD}
    - sps_sebserver_password=${SEBSERVER_PWD}

Make sure that your SEB Server is available under the given URL above over HTTPS. If not, you need to adapt this. If seb-server does reach seb-webservice but cannot proberly authenticate, make sure sps_sebserver_client_secret and sps_sebserver_password are not changed and match the related passwords in sps-webservice:

- sebserver_client_secret=${SEBSERVER_PWD}
- sps_init_sebservount_password=${SEBSERVER_PWD}

The default templates that we offer might not work out of the box on every environment and might need some minor modifications for different environments.

If you are not able to find the cause of the connection error from seb-server to sps-webservice, please send us the seb-server logs as well as the sps-webservice logs at the time you tried to apply the Screen Proctoring to an Exam and it failed, Please also make sure the URL sown in the dialog is correct and accessible.

[shinobifuku]

Thank you for the reply.

I am relieved to know that the displayed error messages can be safely ignored.

I checked the points you indicated.

Before describing the check results, I would like to explain the current environment.

I am working with the bundled_ssl version. Since this is still in testing, the server is blocked by the university-wide firewall to prevent access from outside the campus, and its hostname and IP address are not publicly exposed. Therefore, I created a self-signed certificate on the server, placed the required files in config/nginx/certs, ran docker compose pull, and installed the root certificate into the test client PC’s certificate store. As a result, the browser can connect to SEB Server over HTTPS without showing any certificate warnings.

After pulling SEB Server from GitHub, the only file I modified before running docker compose pull / up -d was the .env file. I changed the two password fields and the DNS_NAME as follows.
(Note: for privacy, the domain part of DNS_NAME has been replaced with foo.bar.)

SEBSERVER_PWD=MyPasswordHere
DB_SA_PWD=MyPasswordHere
DNS_NAME=sebserv-test.foo.bar.ac.jp

I did not change the docker-compose.yml file, so it is exactly the same as described in:
“As for default the seb-server settings to connect to sps-webservice are in docker-compose.yml file:”
Therefore, since I did not change items such as - sebserver_client_secret=${SEBSERVER_PWD}, I believe there is no mismatch in passwords.

With this setup, I can access https://sebserv-test.foo.bar.ac.jp/ from the browser without any problems.

One thing that concerns me is that in the screenshot you provided, the Service URL is shown as http://localhost:8090. In my case, this field shows https://sebserv-test.foo.bar.ac.jp/sps-web.

I am attaching the log files for seb-server and sps-webservice below. Aside from replacing the domain portion with foo.bar, I have not modified them. Also, to keep the logs as simple as possible, the only actions performed were:

Added user sps_test and granted Exam Administrator and Institutional Administrator privileges

Logged into SEB Server as sps_test and added a new “Exam with URL” from Exam Administration → Exam

After saving, configured the Screen Proctoring Settings and clicked Save Settings, which resulted in an error.
And even when I register the Institute, create the Connect configuration, and set up the Exam configuration in the proper order, the same error still occurs when I proceed to Exam with URL and try to save the Screen Proctoring Settings.
seb-sps-logs.zip

Thank you for your assistance.

P.S.
When I look at the docker-compose.yml file, I notice several entries—such as sps_gui_redirect_port= in the sps-webservice: block—where the port number is not specified. Is this correct as-is, or am I supposed to set the appropriate port numbers myself?

[anhefti]

Hi,

I see, thanks for providing the necessary information.

Self signed certificates can be a problem when integrating other Systems like Moodle or other LMS since they do not accept self signed certificates when they are setup properly. But this seems not to be the Problem here.

But first to your PS question:

P.S.
When I look at the docker-compose.yml file, I notice several entries—such as sps_gui_redirect_port= in the sps-webservice: block—where the port number is not specified. Is this correct as-is, or am I supposed to set the appropriate port numbers myself?

The provided setup is supposed to run on default ports (HTTP --> 80, HTTPS --> 443). If you use these default ports, as you probably do, due to your information above, the port settings can be empty. The whole setup is designed to run SEB Server on a server-host that is exposed to the internet and has proper HTTPS configuration either by the host machine itself or external proxy (bundled) or by the setup within the reverse proxy (bundled_ssl).

The URL to the Screen Proctoring service https://sebserv-test.foo.bar.ac.jp/sps-web seems to be okay to me. In the logs you provided I can see the following...

SEB Server tries to connect to sps-webservice but fails due to:

04:44:07.712 ERROR [http-nio-0.0.0.0-8080-exec-9]:[ch.ethz.seb.sebserver.webservice.servicelayer.session.impl.proctoring.SPS_API$ScreenProctoringServiceOAuthTemplate] Failed to get access token for SEB Screen Proctoring Service: Error requesting access token.
  --> I/O error on POST request for "https://sebserv-test.foo.bar.ac.jp/sps-web/oauth/token": sebserv-test.foo.bar.ac.jp; nested exception is java.net.UnknownHostException: sebserv-test.foo.bar.ac.jp
  --> sebserv-test.foo.bar.ac.jp

We can see that it is a UnknownHostExcpetion. It failed to reslove the DNS name for your server "sebserv-test.foo.bar.ac.jp". In the sps-webservice logs file, on the other hand, I see nothing, no authentication error or even a broken connection. This means that the request from seb-webservice never get to the sps-webservice and this seems not to be an authentication error but an netwokring issue. This is most probably due to your network or firewall blocking the Request from seb-webservice or do not recognizance it as coming from within your network. There might be different ways you can solve this:

• Make sure https://sebserv-test.foo.bar.ac.jp/sps-web is available from within seb-webservice docker container and make sure your host where SEB Server is running on is part of the internal network or is recognized by your firewall as part of internal network.
• Instead of the DNS name use the IP address of the Host where SEB Server is running on. This should also work and skips DNS name resolving.

I hope this helps. If you want to make a proper productive setup later on, valid HTTPS certificates are needed, especially if you want to work with third party system like Moodle or other LMS.

[shinobifuku]

Thank you for your reply.

At this point, I’m not considering any integration with an LMS. I plan to ask about LMS support in a separate thread later, but our university’s environment is rather unusual, so there’s a high chance that SEB Server may not support it anyway. For now, my main goal is simply to get the basic system working.

I have a few questions, because there are some parts of your explanation that I still don’t fully understand.

This is most probably due to your network or firewall blocking the Request from seb-webservice or do not recognizance it as coming from within your network

All SEB Server–related containers are running on the same physical server using docker-compose. I may be misunderstanding something, but according to the documentation, all the components communicate through Docker’s internal network. Because of this, I don’t think the university firewall is blocking the communication. Also, I don’t believe our university blocks HTTP or HTTPS in this way.
The only remaining possibility would be the firewall on the server itself, but I haven’t changed any of its default settings.

Then there was your second comment:

It failed to reslove the DNS name for your server

Based on this, I suspected that the containers might not be using our internal (LAN) DNS. So I added our university DNS server’s IP address at the top of the "dns" list in /etc/docker/daemon.json and restarted Docker.
The browser still shows the same error, but the SEB Server logs changed. In the updated logs, not only the Screen Proctoring settings but also the synchronization with the SPS when adding a new user (with Institutional Administrator and Exam Administrator roles) now fail. All of these look like certificate-related errors.

From this, I am assuming the following:

1. Not only external communication, but also internal communication between containers is being made via the external HTTPS URL, such as
   https://sebserv-test.foo.bar.ac.jp/sps-web

2. The server certificate for sebserv-test.foo.bar.ac.jp is self-signed. From inside the SEB Server containers, this certificate is not trusted, so any HTTPS request results in a certificate validation error.

I believe these two points are the cause.

Regarding the self-signed certificate: at this testing stage I have no choice but to use it. Even if I want to use a free certificate such as Let’s Encrypt, issuing it requires making the test server accessible from outside the university. However, according to university policy, doing so requires strong security measures, specific firewall settings, and an official security review, so this is quite difficult during early software evaluation.
There seem to be ways to issue a certificate without exposing the server externally by adding certain DNS records, but this also requires going through internal procedures and is a high hurdle.

According to the official documentation — Overview (https://seb-server-setup.readthedocs.io/en/latest/overview.html
) — in the section “Connections and Routing: 1–9”, item 7 states:

“7: SEB Server connection to Screen Proctoring webservice. (this can be internal via docker network or external via DNS)”

From this, I assumed that if all services communicate only via the internal Docker network, certificate issues should be avoided.

Your advice also said:

“Instead of the DNS name use the IP address of the Host where SEB Server is running on. This should also work and skips DNS name resolving.”

However, I don’t know how to configure the system in this way.
Which configuration settings do I need to change so that the Service URL can be switched to an internal connection—like http://localhost:8090 in the screenshot you provided—using HTTP (without TLS) and not relying on the external DNS? Needless to say, access to the SEB Server and SPS Server administration interfaces from outside must still go through the external URLs, such as https://sebserv-test.foo.bar.ac.jp and https://sebserv-test.foo.bar.ac.jp/sps-web.

[anhefti]

Hi

All SEB Server–related containers are running on the same physical server using docker-compose.

It depends on the configuration and on the specific connection. both seb-server and sps-webservice as well communicate internally within docker network with the database. But the Rest API of this services are exposed to the outside as well as are accessible internally through the docker network as usual.

For the default template that you use, the database connections are internally in docker network but the connection from seb-server to sps-webservice API is configured externally as you can see, when you use a DNS name for the Screen Proctoring Connection.
Also the SEB Clients needs to access seb-server API as well as sps-webservice API from outside either via DNS or via direct IP address of the host.

According to the official documentation — Overview (https://seb-server-setup.readthedocs.io/en/latest/overview.html
) — in the section “Connections and Routing: 1–9”, item 7 states:

“7: SEB Server connection to Screen Proctoring webservice. (this can be internal via docker network or external via DNS)”

Point 7. is currently not possible for a single host setup since there is only one sps-webservice API configuration for SEB Client as well as for seb-server. Since SEB Client always needs to connect to sps-webservice from outside, it is necessary to configure this connection to be accessible from outside. For Kubernetes like setups this would be possible, I assume, but not for the single host setup.
I will try to state this better in the documentation and if possible, to be able to use different connection configuration details for seb-server and SEB Clients to connect to sps-service. But this would need a feature request and actual implementation.

Proposal:

Since you do not want to expose your SEB Server setup yet, we recommend to use the bundled setup with no SSL termination running on port 80 that is the default port for HTTP. Configuring SEB Server to run in localhost would also be possible but then you are not able to connect with SEB Clients from the outside.

So instead of your DNS name you should be able to give the direct IP address of the Host SEB Server is running on in the .env file. And you have to change the https to http all over the docker-compose.yml file. This should work as far as I know.

Then the host where SEB Server is running on must allow outgoing HTTP Requests to its own IP. This should be the case with Docker default and if there is no network/firewall defined from the host machine that does not allow outgoing HTTP requests from the host. You can test this by bashing into the running seb-server container and try to make a HTTP(S) request from inside the container, with a curl for example.

Hope this helps.

[shinobifuku]

Thank you very much for all your support so far.

To start with the conclusion: I was able to get everything working, including Screen Proctoring. However, the suggested approach did not work in my case, so I ended up taking a completely different route.

Following your advice:

“So instead of your DNS name you should be able to give the direct IP address of the Host SEB Server is running on in the .env file. And you have to change the https to http all over the docker-compose.yml file. This should work as far as I know.”

I modified the .env file (the bundled one, not bundled_ssl) and the docker-compose.yml accordingly and rebuilt the setup. From the logs I confirmed that access was happening via IP instead of the server name, so it initially looked fine. However, after adding a user with Institutional & Exam Admin permissions, the seb-server logs showed:

02.12.2025 01:01:03.177 WARN [asyncService-1]:[ch.ethz.seb.sebserver.webservice.servicelayer.session.impl.proctoring.SPS_API$ScreenProctoringServiceOAuthTemplate] SPS Service Connection refused
02.12.2025 01:01:03.178 ERROR [asyncService-1]:[ch.ethz.seb.sebserver.webservice.servicelayer.session.impl.proctoring.ScreenProctoringAPIBinding] Failed to synchronize user account with SPS for user: 451b1614-0298-4669-ac65-5ae61d9cd9aa

This indicated that SPS user account synchronization was still failing, and the sps-guiservice continued to show certificate-related errors.

Based on these observations, I concluded that the only solution was to make each SEB Server container trust the server running with a self-signed certificate—in other words, to install the root certificate inside each container.

I rebuilt the images for the three containers (seb-server, sps-webservice, and sps-guiservice) using the original images as a base, and modified each Dockerfile to copy ca.crt into the appropriate location inside the container and register it as a trusted certificate. After updating docker-compose.yml to use these new images, I ran docker compose build and then docker compose up -d. With this setup, everything started working correctly.

I was a bit unsure at first, but based on the following points, I believe the system is now functioning properly:

• No errors occur during user-account synchronization.
• I can log in to /sps-gui/ using the created accounts.
• Enabling Screen Proctoring in “Exam with Link” and saving no longer causes errors.
• I can now view the client’s SEB screen through /sps-gui/.

With this, I can finally move on to functional and performance testing.

Once again, thank you very much for your patient and detailed support. It has been extremely helpful.

P.S.
This was my first time working with Docker, but wrestling with SEB Server has helped me understand it a little better.

[anhefti]

Hi,

I'm very glad that it finally worked for your testing - setup.

I'm still convinced that there must be an easier solution by just adapt the configuration and environment variables to work without SSL at all. And the fact that you received a SSL validation error at some point seems to indicate to me that there was still SSL and HTTPS involved/configured within the docker-compose-yml. But I also never had time to test the setup and suggestions I supposed to you in real I only know that we use all the systems without SSL for our development and it should work somehow.

But if I find time someday, I will try to make a setup completely without SSL for testing purposes, but as you now know, it usually takes some time with Docker to figure it all out and make it work exactly how you want it to work :)

Best regards