Central control of Cal/CardDAV (and possibly ActiveSync)

Feature
, , ,
#1

Discussion in this thread brought up this issue, but it’s a little broader of an issue and I think could use its own thread. We have three apps currently in the software center (SOGo, WebTop, and Nextcloud) with the capability of providing Cal/CardDAV services, but part of that involves redirecting /.well-known/something to the respective apps. Obviously we can’t simultaneously redirect /.well-known/caldav to both SOGo and WebTop, so we need a way to control which app will be used for requests.

We currently have a mechanism in place to address a comparable problem for ActiveSync, but I don’t think it’s an optimal solution–it relies on configuration properties for the respective apps (with the potential of conflicting settings, and then the need for rules to determine which takes precedence in the event of a conflict). I believe a better approach would be a single property of the form config set dav configuration caldav {none|nextcloud|sogo|webtop} carddav {none|nextcloud|sogo|webtop}.

I’m thinking it would be implemented like this:

  • We expose the setting in the server manager somewhere (as a drop-down, I’d think), including “none” as an option
  • This means the server manager needs to know what handlers are installed. A “brute force” way to achieve this would be to just check whether nethserver-{nextcloud|sogo|webtop5} are installed; a more elegant way would be to implement some sort of registry of handlers. Or just require the system admin to know what’s installed on his system, and expect he won’t choose poorly–though I’m not a fan of that plan.
  • No app sets itself as the handler for cal/carddav
  • Therefore, the user explicitly chooses among the available apps
  • When nethserver-blah is removed, it queries the dav property to see if it’s set as the cal/carddav handler. If so, it sets that handler to “none”.

In addition to resolving the conflict, this also would implement the necessary redirects for Nextcloud, which aren’t currently implemented at all. Thoughts?

3 Likes
Nextcloud and CalDAV
Nextcloud overview asks for password for sabre/dav and complains about database
#2

Just thinking out-loud here while trying to find the most simplified solution / mitigation:

Is it acceptable to bluntly forbid redirects on the default host for known conflicting web-services like card-, caldav and activesync? meaning it is only allowed in a (exclusive) virtual host?

#3

I wouldn’t think so. For one, WebTop doesn’t (yet) support being on its own virtual host. Second, even when the apps do support it, lots of users aren’t configured that way. Third, though I’m definitely guessing here, I get the impression that the /.well-known/whatever paths are intended to operate on the base domain, so that client apps can look up the relevant DAV information from a user’s email address. If my guess is correct, I’d think that making it operate only on a subdomain would rather defeat the purpose.

#4

(IMO) Which regarding to dav is misbehavior.

Agree

Also guessing; I think you right.
My best guess is this is related to the (auto)discover methods / strategies of clients.
http://sabre.io/dav/service-discovery/
https://wiki.z-hub.io/display/ZP/Configuring+Z-Push+Autodiscover

This wipes the most simplified approach a kind of the table :grinning:

#5

Interesting topic! /cc @giacomo @alep @stephdl

#6

Still thinking out-loud here:

What about a extra table with roughly this structure ?:

name type values
servicename service default subcriber
cardav service nextcloud
caldav service nextcloud
activesync service none
application subscriber capabilities
none subscriber carddav, caldav, activesync, servicename
webtop subscriber carddav, caldav, activesync
nextcloud subscriber carddav, caldav
sogo subscriber carddav, caldav, activesync
#7

If I’m understanding that right, it should do the job–though I’d have “default subscriber” set to “none” for all of them. This should be an explicit admin decision, IMO.

#8

Excuses for the lack of explanation, (i had to leave and) hoped it would be self explanatory enough.
The idea is to have a generic data-structure not limited to applications nor services known to cause conflicts as it stands now. For instance nethserver-horde could subscribe to this handler as well.

Agree, that is the geneal idea.
Although first-installed could be a feasible option too :question: => avoiding the need to configure a potentially conflicting service if you have no intentions to install a application which may cause this conflict.

#9

Just one question, because I don’t know how individual components work… Is it all about configuring Apache?

Priority of settings in Apache can be configured by changing the alphabetic order of config files. Maybe a symlink under /etc/httpd/conf.d is enough to pull a .conf file before others.

See httpd -S output to check vhost definitions, for instance.

#10

Yes, for the services we are discussing here.

As i understand it it is also related with the content of default-virtualhost.inc (1).
Which does not mean it can be the action to promote the desired webapp to be the default provider of a service.

(1) Quite frankly I never understood what default-virtualhost.inc actually does other than rewrite from http://whatever/sub to https://FQDN_Server/sub . Also to consider: Prevent the host-name of a webapp becoming the default server if it is warped in a virtual-host; hence the configuration files have names like zz_xx.conf

1 Like
#11

I waited a bit before joining the discussion since I’ve already faced the issue but didn’t find a good solution.
After reading all the ideas, I sadly still have the same opinion: there is no simple and clean solution.

Those URLs are valid for each host. So for the main FQDN, redirects must be placed under the default virtual host, for all other domain names, redirects should be placed inside the virtual hosts.

An uninstalled package can’t execute extra code, such logic must be implemented in a core package.

This is a good proposal, still we need something implemented in a core package to know if a package is the “first-installed”

IMHO, this is not a problem which needs a coded solutions.
Most of the servers don’t have multiple groupware installed: just choose between SOGo and WebTop.
Nextcloud groupware is not still mature enough, and if you want to test it just configure Nextcloud in a virtual host. And if you really want device auto-configuration for Nextcloud, just drop a template-custom.

For now, I think we can still face the issue adding a couple of lines inside the documentation.

1 Like
Nextcloud and CalDAV
#12

There isn’t a %postun section in the .spec file that could do this?

Why not? The alternative, apparently, is “you’re SOL if you want to have two packages installed that both do Cal/CardDAV (in addition to whatever you may want them to do)”. Granted, I’m thoroughly unimpressed with WebTop, between the atrocious performance, the opaque configuration, and the complete lack of official documentation (at least that I’ve been able to find), but having it installed shouldn’t preclude SOGo from working, or vice versa.

We’ve had nethserver-nextcloud as an “official” package for how many major releases, and this is the best answer? And it’s not only a matter of auto-configuration; the macOS calendar, at least, simply won’t work without this.

There has to be a better answer than “don’t install more than one groupware solution, and don’t expect the Nextcloud calendar to work without hand-coding.”

#13

This is one possible answer, but doesn’t look simple to implement. The registry/API definition should be in nethserver-httpd. The API consumers are the webapps listed above.

The problem from this point of view resembles what the alternatives command do. It could provide a backend for our solution.

As alternative I’m thinking about leaving each webapp the task of configuring a virtualhost with a dedicated host name from scratch (i.e. not including default-virtualhost.inc at all). Maybe that doesn’t fit all possible combinations, but seems still important for real use cases. I don’t remember if there’s something already done towards this…

Yes maybe not ideally perfect…

Can we start by writing down our desired use cases? For instance:

As a sysadmin I want to install nextcloud, sogo and webtop. I want to expose each one with its own domain, like mail.first.com, cloud.second.org and mail.third.net.

#14

Sure. In my case, I want to have WebTop and SOGo installed so that my users will have options (primarily for webmail), but I want to use the Nextcloud calendar with my clients (which include the macOS Calendar app). None of the apps is on a dedicated virtual host, and I’m not particularly interested in changing that (particularly with Nextcloud, since all the clients are set up to use www.mydomain.tld/nextcloud). So, my desired end state:

  • SOGo, WebTop, and Nextcloud are all installed on the base domain.
  • The admin can choose which Cal/CardDAV implementation is the target of the /.well-known/ redirection.
#15

It doesn’t look like a typical setup from my point of view. I understand why Giacomo spoke about template-custom.

However it could be useful during a migration from one groupware to the other… I think it could be done if we find a straight way for the implementation.

In any case there’s a significant QA work to avoid regressions! What do you think?

#16

Bumping for this question–wouldn’t a %postun section in nethserver-whatever be able to clean up config database entries?

#17

None of our packages uses RPM scriptlets to perform changes like that.

I’d prefer another solution for the “module cleanup” problem.

For instance install/uninstall scripts provided by the Software Center itself.

#18

There’s always more than one way to skin a cat, but it seems to me that the package itself is in the best position to determine if it’s been set as the default for something, and if so, to revert it on removal. Having a mechanism in RPM to do that directly seems like a cleaner way to handle this than requiring other scripts provided by the software center. But as long as it accomplishes the desired result, I’m not too particular about how it gets there.

1 Like
#19

Indeed the rpm is the best qualified to bring script removal

Often service are enabled and user are created by the %pre and I think that they are disabled by the %postun

After said that, there is a legend (or a good habit) to forbid all pre/post/preun/postun actions

#20

We are talking of two distinct abstraction layers

  • Individual RPM installation/removal (rpm scripts)
  • System wide configuration that occurs at module installation/removal (esmith)

Avoiding mixing them up is preferable

1 Like