Collabora-online: The requested URL /loleaflet/dist/admin/admin.html was not found on this server

I installed and configured collabora-online, but I must have missed a point, as it does not work yet. The service is started according to system status loolwsd, but I cannot access

https://lool.ourdomain.com/loleaflet/dist/admin/admin.html
-> The requested URL /loleaflet/dist/admin/admin.html was not found on this server.

I doublechecked that I followed the instructions in handbook.

dns entry is existing, and after installation I have issued

config setprop loolwsd VirtualHost lool.ourdomain.com and signal-event nethserver-collabora-update. Also checked that the entry was successfully added to existing letsencrypt certificate.

How can I find out, if its listening to some other address or what else could be the culprit?

For me it worked after running:

loolconfig set-admin-password
signal-event nethserver-collabora-update    # maybe enough restarting loolwsd service

If you get the login prompt when accessing the URL but fails to login, try cleaning browser cache or accessing the URL in a private/incognito window.

hi dnutan,

I am making some progress. Having started with a completely new nethserver installation, I installed nextcloud. Then collabora-online. I made sure that lethsencrypt is in place and virtual host is set to lool.ourdomain.com.

After following the documentation I now am able to access the admin page, which asks me for a password. Initially it did not accept the password, not even with private tab. A reboot of nethserver fixed that. So I am now able to login and see the admin page @https://lool.ourdomain.com/loleaflet/dist/admin/admin.html :slight_smile:

Unfortunately it does not work yet within nextcloud. I downloaded and activated Collabora Online app, and made sure it is active. In settings I checked that URL of Collabora-Online Server is set to:
https://lool.ourdomain.com. But when I hit apply, it takes a long time with saving… until it writes saved in green, just like it could not access collabora online server. When I try to open a odt document, after a while there is a message that collabora online could not be loaded and I should try later.

Got me thinking. Maybe a firewall problem, because of my elegant network setup (putting an opnsense router vm in proxmox infront of everything else, which gets the external ip and acts as gateway for all the vm’s behind) established with the wonderfull help of Andy_Wismer :slight_smile:

I will check and report back.

Andy, I have a question. I checked with my private gentoo server where I have collabora online successfully running on the same host, as nextcloud. I had to setup proxypass, and following the relevant part of my vhost configuration:

ProxyPass /loleaflet http://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet http://127.0.0.1:9980/loleaflet
ProxyPass /hosting/discovery http://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery http://127.0.0.1:9980/hosting/discovery
ProxyPass /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities
ProxyPassMatch “/lool/(.*)/ws$” ws://127.0.0.1:9980/lool/$1/ws nocanon
ProxyPass /lool/adminws ws://127.0.0.1:9980/lool/adminws
ProxyPass /lool http://127.0.0.1:9980/lool
ProxyPassReverse /lool http://127.0.0.1:9980/lool

As I am able to see the admin page of lool admin interface @https://lool.ourdomain.com/loleaflet/dist/admin/admin.html as described in the documentation (it asks for username and password and providing them, I can login!) could it be, that in opnsense is blocking something, thus it is not working within nextcloud? Do I need to configure opnsense for port 9980? And if so, what port forward rule should that be?

As said, all prerequisites are working, the final part, that is not working is after activating the collabora online connector app within nextcloud I cannot open an office document within my nextcloud instance on the nethserver nextcloud.

Or am I searching in the wrong place? On my gentoo server the error log is found @/var/log/libreoffice-online\loolwsd.log But I don’t find any similar log in /var/log within nethserver…

It is a low priority question anyway, as I have onlyoffice successfully up and running as alternative, and besides that I am 3 weeks oon vacation now :smiley:

On the other side, it would be cool having the ability to show both possibilities to my compagnons and let them decide which they like better :wink:

Hi

Do you have the possibility to test it “directly” - without going thru the firewall?
Like maybe using SSH/22 and Port forwarding over that?

Test it and see if you can access the page correctly.

Just to verify it’s not to do with opnsense/firewall…

Sometimes certain things aren’t accessible from outside the LAN (temporarily).
Like certain printers / nas geht the IP from DHCP, you think you can access them from VPN. But no, there’s NO Gateway in those machines, until you put one in…
That’s why it’s always a good idea to have a “local agent”, if mostly working via VPN.

Good luck

Andy

Well, I thought so too, but do not know, how to acheive this. Only if I could set a rule in opnsense temporary to open up every port just for testing, but how that rule should look like? On the other side, I mean the proxy pass thingy is to just for localhost ip so it seems strange if opnsense would be the blocker.

And as I can access the admin page from outside it is strange that it does not work within nextcloud instance anyway.

If I only would have a log to check…

Just define a custom port, set that eg to 10-65535 (Ports are 1-65535)…
You can define a start port - if you don’t set an end port, it’s for a single port.
If you DO set an end port, that’s a range of Ports from XXX to YYYY…

If using NAT, set it in the NAT menu, that will make the needed firewall entries automatically…

OPNsense has readable logs (see firewall/protocoll), so does NethServer/Nextcloud.

Andy

I will try out, though I have to be carefully, as I must not portforward the custom port, I am using to ssh to the proxmox host, else I am not able to connect to it anymore.

I had another idea to test, which almost makes me sure, it cannot be a problem on opnsense. You know why? I tried the same test from within my vm on the green network, that way opnsense should not be in the way, right? And its the same thing, so it might have nothing to do with the opnsense firewall after all?

I still hesitate to change opnsense rules as I am afraid by doing it wrongly, I cut my connection to ssh. I will think about for good before proceeding and in the meantime I also will try to activate some logging of loolwsd that maybe could give a hint of the real source of the problem.

As a security precaution I may even switch the /etc/network/interfaces to the one, I directly access the host bypassing opnsense. That way if anything goes south, I reset the host via webinterface and can re-establish connection as the host gets the ip directly after reboot.

Thanks for your fast reply :slight_smile:

Good point, maybe better examine the liveview/opnsense and nethserver firewall logs first. I’ll do and report back, but it could take some time :slight_smile:

You can start the port range from 10-21 and a second NAT with Ports 23-65535

or, if using 2222 for SSH, then 2 NAT rules:

Ports 10-2221
and
Ports 2223-65535

Port 2222 points to SSH and STAYS that way! :slight_smile:

But you’re right, if a local machine can’t get the page, the firewall isn’t going to change anything.

Also, you now see why I dislke having a firewall running on my Nethserver. Even with AD (a virtualization inside a virtualization) things can get difficult, let alone using additional ports and proxies.

Like this, the firewall doesn’t interfere with what a local machine sees directly…

True, thanks again for pointing on the obvious :slight_smile: I need that from time to time :smiley:

For me the most critical port is the one I access the ProxMox Host via cert. based ssh login, and that one can be left untouched as you wrote.

The nice thing about something like this: The NethServer has it’s own firewall and can protect itself.
So quickly opening a whole range of ports is not that serious a problem, especially if only for a few short tests.

OPNsense does make it easy to do a range or two for tests lke that!

:slight_smile:

Absolutely. I like the way we setup things more and more :smiley:

Less interconnected problems, making life difficult.

Each box is, in itself, a working blackbox, and does NOT interfere with anything else on the network.

Changing accessibility / NAT or firewall rules will never disrupt internal processes, like a VM viewing an internally hosted webpage…

This does give a lot of flexibility - if for troubleshooting or daily usage is up to you, the admin.

:slight_smile:

You are also aware of the possibility in OPNsense to do config-backups automatically to your Nextcloud instance? The SSL has to be “official”, though. Lets Encrypt is fine, though, that’s recognized.

Another cool feature is the restore itself. You can restore the whole thing, or just parts like VPN config, users or firewall stuff…

I’ll have a look. Doing config-backups automized seems a good thing to have. But I’ll have to “officialise” ssl for opnsense too, only have this setup for nethserver until now. Until now, I just use the backup feature of ProxMox which is incredibly fast on a little vm like the one opnsense is running.

I will probably do more tests the next days, with the port opening but I start to think the problem is somewhere else. Reading another post I just did:

su - lool followed by loolwsd status and guess what, there is:

wsd-05203-05203 2020-02-21 20:18:39.007141 [ loolwsd ] INF Initializing wsd. Local time: Fri 2020-02-21 21:18:39+0100. Log level is [8].| common/Log.cpp:191
wsd-05203-05203 2020-02-21 20:18:39.007204 [ loolwsd ] INF Setting log-level to [trace] and delaying setting to configured [warning] until after WSD initialization.| wsd/LOOLWSD.cpp:904
wsd-05203-05203 2020-02-21 20:18:39.007249 [ loolwsd ] WRN SSL support: SSL is disabled.| wsd/LOOLWSD.cpp:991
wsd-05203-05203 2020-02-21 20:18:39.007322 [ loolwsd ] INF NumPreSpawnedChildren set to 1.| wsd/LOOLWSD.cpp:1018
wsd-05203-05203 2020-02-21 20:18:39.007341 [ loolwsd ] INF MAX_CONCURRENCY set to 4.| wsd/LOOLWSD.cpp:1026
wsd-05203-05203 2020-02-21 20:18:39.007358 [ loolwsd ] INF Maximum concurrent open Documents limit: 10| wsd/LOOLWSD.cpp:1098
wsd-05203-05203 2020-02-21 20:18:39.007367 [ loolwsd ] INF Maximum concurrent client Connections limit: 20| wsd/LOOLWSD.cpp:1099
wsd-05203-05203 2020-02-21 20:18:39.007382 [ loolwsd ] TRC Pre-reading directory: /bin//loleaflet/dist| wsd/FileServer.cpp:460
Aborted
-bash-4.2$ -

So the warning about ssl support being disabled caught my attention.

But thanks again for bringing those really cool features to my mind, giving me the opportunity to learn much more about opnsense.


Restoring just a “part” of the config, like users…

OPNsense doesn’t need an official SSL, just Nextcloud…

You also have the option of encrypted backups of opnsense - or not. I prefer unencrypted - i make sure no one else has access. But i once was really glad, when a client couldn’t find the Swisscom VDSL document (Zugangsdaten). That would have meant a 3-5 day delay with no internet or telephone, as they will only send these infos with registered mail…
This info was in the backup file, in clear text!

:slight_smile:

Ah, ok. Understood. Even better :slight_smile:

Off topic: Looked at the last 500 lines of /var/log/messages. omg :slight_smile:
I definitely have to change ssh and disable passwordauth thus switch to cert based on the nethserver too as I have done already longtime ago for the host system. Way better than enabling fail2ban to eliminate all those useless logentries. :slight_smile:

cert based is much faster and secure, too!

Yep, was just too lazy to do that on nethserver yet, but those entries two or three attempts per second make me think I should do it better sooner than later :smiley: Will have to check other vms like opnsense, fogserver and pihole too, but I think, ssh ports are not open there…