[Creating a Customer via API does not create a standard Subdomain]

Okay, thank you for your fast response. The froxlor support works always amazing!
I've just created the following bug report:
https://github.com/froxlor/Froxlor/issues/1307

[Creating a Customer via API does not create a standard Subdomain]

21 minutes ago, d00p said:

ssl if enabled globally is set to true by default, and if no ssl-ip is given explicitly (which is the case when adding std.subdomains) froxlor falls back to the default-ssl-ip setting. Now if SSL is enabled, and Domain-SSL = 1 (which is true) and NO ssl-ips are given, then the exception you got is returned...

In the admin panel:

IP-Adresse
Welche Haupt-IP-Adresse hat der Server?

 

Standard-IP/Port-Kombination
Welche IP/Port-Kombination sollen standardmäßig verwendet werden?

 

Standard SSL IP/Port-Kombination
Welche ssl-fähigen IP/Port-Kombination sollen standardmäßig verwendet werden?

are all set, do I miss something?

[Creating a Customer via API does not create a standard Subdomain]

10 minutes ago, d00p said:

Do you have default ssl-ips in System-Settings -> Default SSL IP/Port ? If not, froxlor cannot fallback to valid ssl-ips when creating a (std-sub)domain with ssl=1

Yes, port 80 and ssl on port 443, like usual, all domains are using them and they are working fine. looks like there's some SSL part missing in the API call in the background.

[Creating a Customer via API does not create a standard Subdomain]

The same experience I just have by creating a new customer, with only a standard subdomain in the admin panel. No error message, no subdomain is created. The switch for creating a standard subdomain, which I've turned on, is just turned off, when I go back to the customers settings. I think that it's the same issue.

The System-Log shows the following: " [API] Unable to add standard-subdomain: Wenn SSL aktiviert ist, muss eine SSL IP/Port angegeben werden"

The form to create a new customer doesn't have any SSL options.

In the past subdomains were created without problems and they are running with SSL flawlessly.

[DKIM content removed from panel-domains table, after changing from dkim-milter to Rspamd]

1 hour ago, d00p said:

Well, it would have been converted for you if you've enabled "antispam" ...

....

You may try, but as said, I cannot guarantee or support third party / custom solutions

Thank you for your fast answers!

Well, I see no reason, to not enable "antispam", so far no problem, but what is going to be converted, is there another Hashing method used to generate the key-pairs?

The hashes have been generated and managed with Froxlor before, that's why it surprised me that they got removed.

[DKIM content removed from panel-domains table, after changing from dkim-milter to Rspamd]

Recently I've noticed that DKIM signatures were missing on outgoing emails.

Well, obviously I should read this guide before...
https://docs.froxlor.org/latest/general/migration-guide/2.2.html

However I wouldn't expect updating Froxlor or switching from Milter to Rspamd, resulting in key removal, why is that made this way?

Luckily, the old keys are still existing in /etc/postfix/dkim. Can I just restore them, by placing them back in the panel-domains table or is there more that needs to be done? Is there an API way to restore the keys?

Is there a way to re-enable DKIM for all domains and generate new keys, If they don't exist?

Recently added domains are stored with dkim-id starting by 1, would it work by only changing that to the number following the last old one?

[can not log in after update to newest version]

Now I have had a look at the HTTP requests. What happens is not the same as when I try to log in with the wrong password. In summary, the following happens:

Request: POST index.php, what is striking here is the cookie line of the request, in which the PHPSESSID variable is set twice with two different values!
Response: 302 to customer_index.php, Set-Cookie: PHPSESSID=(new value)

Request: customer_index.php, Cookie: PHPSESSID set twice again
Response: 302 to index.php

No error message appears, as after entering an incorrect password,

After deleting the cookies in the browser, the login also worked under Windows!

Conclusion: something messes up the Session Cookie.

[can not log in after update to newest version]

Same I have here with an account from a client. From my linux machine the login works fine, from a windows machine not. I didn't dive into the used login procedure, but I guess that the cause is something with the character set.
I've noticed issues with an previous froxlor version from the last year, where it helped to remove the browser cache. On both machines, Linux and Windows, I've been using Firefox.

[Let's Encrypt Fehlermeldung]

Jetzt habe ich diesen Fehler auch bekommen. (Version 2.0.19-1)

Zwei Dinge:

1. Wenn man nach der Fehlermeldung wieder zum Formular geht, ist alles wieder leer, das ist kein Problem, aber etwas ärgerlich.

2. Wenn eine Neue Domain angelegt wird und die DNS-Einträge von Froxlor angelegt werden müssen, geht das in die Hose.

Letzteres habe ich mit einem 'Workaround' gelöst, indem ich die domain zuerst ohne Let's Encrypt angelegt habe.
 

[SSH access with libnss-extrausers]

Hello, I'm trying to provide an SSH shell access to customers on an Debian Bullseye.

So far the usernames are shown properly in the system but the loggin in with SSH is rejected. The path in "/var/lib/extrausers/passwd" is always set to "/bin/false" even if I set the "List of available shells" in Froxlor on "/bin/bash", while the cronjob does create the files.

Any Idea, why the path is not what I would expect to be set in the passwd file?