Ejabberd Upgrade 20.01 - HTTP Upload Issue?

NethServer Version: 7.7.1908
Module: ejabberd 20.01 20.01-0

After Upgrade of Ejabberd some days ago - I think according to following changes -
the HTTP Upload is not working any more.

I found that template expansion of /etc/ejabberd/ejabberd.yml does not expand the @HOST@ in my case correctly.

The template file
has followowing entry at the end of the file

if ($ejabberd{‘ModHttpUploadStatus’} eq ‘enabled’){
$OUT .= q(
docroot: “/var/lib/nethserver/ejabberd/upload/”
put_url: “https://@HOST@:5443/upload”
if ($ejabberd{‘ModHttpUploadQuotaStatus’} eq ‘enabled’){
$OUT .= qq(
max_days: $ejabberd{‘ModHttpUploadQuotaMaxDay’}

Specifically the line
put_url: "https://@HOST@:5443/upload"
has not been expanded correctly in my case:

After expansion, the file
shows the following:

docroot: “/var/lib/nethserver/ejabberd/upload/”
put_url: “https://@HOST@:5443/upload”

Changing file /etc/ejabberd/ejabberd.yml manually with the real FQN (instead or the @HOST@ ) in line to something like put_url: "https://myhost.mydomain.com:5443/upload" and restarting the ejabberd.service manually makes the HTTP Upload service working correctly.

Is this an issue in general or do I have some misconfiguration so that the @HOST@ is not expanded correctly?

AFAIK @HOST@ is a var for ejabberd to mean the url you used to reach the ejabberd server, it is not supposed to be replaced by another value

1 Like

ok, thanks for the information.

Then I have the issue that my public URL is different then the internal hostname.
E.g. in WebTop or NextCloud Modules it is possible to define PublicURL or TrustedDomains to reflect the external access.
In my case the internal host/domain is used inside the ejabberd config for the ejabberd Upload URL - which is then obviously not working.

Side topic: I found in /etc/ejabberd/ejabberd.yml that the Definition of “host” (I guess this is the variable defined to be used by ejabberd as you explained) is showing only the domain - hostname is missing. Anyway (as discibred above) this would not solve the situation anyway in my case.

loglevel: 4
log_rotate_size: 10485760
log_rotate_date: “”
log_rotate_count: 1
log_rate_limit: 100

– “xxxx.yyy”

So my unqualified guess would be that for ejabberd module also some kind of PublicURL variable should be introduced to be able to have different external URL for accessing ejabberd from outside.

Does it make sense to open a feature request for the public URL parameter?

You could try, at least we will understand better what you need

@stephdl I think it’s just a problem because the Nethserver domainname is a not resolvable local one like “local.lan” and therefore the download links are not working.

@jrieder You may use this custom template if it’s no option to change the Nethserver domain:
I use an internal domainname on one of my servers too and it’s a pain.
I can only recommend to use a public domain name as Nethserver domain just to avoid similar problems.

Create the custom template dir:

mkdir -p /etc/e-smith/templates-custom/etc/ejabberd/ejabberd.yml

Create the file /etc/e-smith/templates-custom/etc/ejabberd/ejabberd.yml/20Hostname:

   my $domain = $ejabberd{'Domain'} || $DomainName;
   $OUT .= "hosts:\n  - $domain"

Set the domain and apply config:

config setprop ejabberd Domain <YOURDOMAIN>
signal-event nethserver-ejabberd-update

1 Like

Any news?

Hello, sorry for the late reply as I was sick the entire week.
Today I could test the suggested approach by mrmarkuz:

However - not working as expected!

  • hosts: parameter then includes the external hostname: As all users are however bound to the internal domain name, no user can login any more. The ejabberd admin web page cannot be accessed any more. (In the ejabberd.yml config file all the admin users are configured still with the internal domain name - so also no admin user can login into the ejabberd webpage. ==> so actually not usable

  • I tested to use two virtual hosts in the “hosts:” section of ejaberd.yml. (Internal domain and external domain). Then the users can sign in again - assume with the internal domain. However then still no HTTP upload is possible as most probably each user (and the connected users are still bound to the internal domainname) would use each domain also for the HTTP uplink put_url (by using @HOST@ parameter in the put_url
    With this setup however the @HOST@ parameter in the put_url is mandatory - so cannot override this parameter to the external domain name.

So current solution I see is to have an “external” domain parameter replacing ONLY the HTTP upload put_url parameter and keeping in the hosts: only the internal domain.

Maybe I missed something and maybe there are better ideas?
Thanks and regards!

1 Like