Rewrite for /principles/user/ Apache?

NethServer release 7.6.1810 (final)

I want to use a CardDAV server. I can use the one in SOGo but would prefer to use another such as Nextcloud. My problem is that the Apple macOS Contacts app has a problem connecting to any server address other than /principles/user/. Other contact apps work well as do iOS apps. But we need Contacts.app!

Contacts.app will easily find and connect correctly with my SOGo CardDAV server. It does this automatically once it knows the server address, a username and password.

But give it the path to a Nextcloud CardDAV server and it won’t connect. It defaults back to /principles/user/.

I’m guessing there’s a rewrite somewhere in Apache perhaps sending /principles/user/ to the SOGo CardDAV. If so, can I change that to send it to my Nextcloud CardDAV?

Thanks!

Help me out here! Here’s what I found guddlin* around…

There are some lines in /etc/httpd/conf.d/zzz_SOGo.conf

# SOGo dav auto-discovery support is enabled

RedirectMatch ^/(dav|cal|card)$ /SOGo/dav/
RedirectMatch ^/.well-known/(caldav|carddav)$ /SOGo/dav/

I assume these make SOGo the default DAV server.

I want Nextcloud to be my DAV server and, interestingly, even without SOGo installed that doesn’t happen. So do I need the redirect shown above edited and added to /etc/httpd/conf.d/zz_nextcloud.conf ? Could I comment out the lines in zzz_SOGo.conf and add the following to zz_nextcloud.conf ?

RedirectMatch ^/(dav|cal|card)$ /nextcloud/dav/
RedirectMatch ^/.well-known/(caldav|carddav)$ /nextcloud/dav/

However the address of my contacts is

https://my.server.tld./nextcloud/remote.php/dav/addressbooks/users/USER-ID>/contacts/

so perhaps my redirects should be

RedirectMatch ^/(dav|cal|card)$ /nextcloud/remote.php/dav/
RedirectMatch ^/.well-known/(caldav|carddav)$ /nextcloud/remote.php/dav/

What could possibly go wrong?!

Apart from

# ================= DO NOT MODIFY THIS FILE =================
# 
# Manual changes will be lost when this file is regenerated.
  • guddlin - a Scottish word meaning to put your hands into a river and bring out a fish :grinning:

Is this what you are looking for?
http://docs.nethserver.org/en/v7/nextcloud.html#caldav-and-carddav

Some CalDAV and CardDAV clients may have problems finding the proper sync URL and need automatic service discovery. Service discovery is enabled by default if a custom virtual host for Nexcloud has been configured.

To enable the service discovery even if Nextcloud is running on the main FQDN, under the nextcloud subfolder, please make sure you do not have WebTop or SOGo already installed. Then execute:

config setprop nextcloud Wellknown enabled
signal-event nethserver-nextcloud-update

OK, now I’m starting to feel the fish…

Maybe I really need to edit
/etc/e-smith/templates/etc/httpd/conf.d/zz_nextcloud.conf/10base

I wonder if I need to edit
my $wellknown = $nextcloud{'Wellknown'} || 'disabled';
to ‘enabled’ ?

And maybe
IfModule mod_dav.c
Dav off
/IfModule

needs Dav on ?

And then I’d have

    if ($wellknown eq 'enabled' && $vhost eq '') {
        $OUT .= "  \n\n# Enable webdav redirect\n";
        $OUT .= "  Redirect 301 /.well-known/host-meta /nextcloud/public.php?service=host-meta\n";
        $OUT .= "  Redirect 301 /.well-known/host-meta.json /nextcloud/public.php?service=host-meta-json\n";
        $OUT .= "  Redirect 301 /.well-known/webfinger /nextcloud/public.php?service=webfinger\n";
        $OUT .= "  Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav/\n";
        $OUT .= "  Redirect 301 /.well-known/caldav /nextcloud/remote.php/dav/\n";

I’m unsure what some of these lines do so any guidance appreciated.

Thanks!

Thanks, I will try that but already have SOGo. Can I simply remove it via the Software Centre or do I need some commands to clean up the config files? Or I could always try with a new clean install of Nethserver.

OK, thanks again, I tried that on a new NethServer install and it hasn’t worked for me.

As I say, fresh NS. Updated and only NextCloud (with Contacts) installed, no SOGo or WebTop.

Still no access to CardDAV on NextCloud via macOS Contacts.app.

The lines I expected to see changed remain as I posted above.

my $wellknown = $nextcloud{'Wellknown'} || 'disabled';

Maybe I don’t know how to issue these commands. I’m logged into the Terminal as the root user. Is that OK? Do I need to cd to a specific directory to issue these?

Thanks once more.

Yes, that’s OK. No need to run it from a specific directory.

The templates contain the code to generate the target file, in this case the changes should be found in the target: /etc/httpd/conf.d/zz_nextcloud.conf

Here another user experienced a related issue with mac OS, but don’t know if it was solved:

Hi
Even on the latest and greatest NethServer & NextCloud installation, I can’t get a current Mac (Anything newer than Mavericks) to sync the Contacts with NextCloud.
I’ve tried a custom domain (nextcloud.mydomain.com), I’ve updated the DB manually - see below.

-> The given commands do NOT change the DB at all:

config setprop nextcloud Wellknown enabled
signal-event nethserver-nextcloud-update

Even after rebooting ( a productive server!) - no change in the DB. (/etc/e-smith/db…)

Alas, sofar nothing helped. On my Macs It won’t work, period. I have a Parallels Mac under Mavericks, for the sole purpose of editing my Adressbook on a Mac. :frowning:

This should be fixed - most likely upstream fix needed, but still…
CardDAV works for current Macs on almost all other systems, and CalDAV works well on NextCloud. Why not CardDAV…!

My 2 cents

Well its kind of good to know its not just me and I did input all the commands correctly…

@danb35 seemed to be getting to the root of the problem. I know nothing but its clear to me there needs to be changes made to /etc/e-smith/templates/etc/httpd/conf.d/zz_nextcloud.conf/10base and the commands don’t do that. Did @danb35 ever get anywhere with this?

To be clear, Nextcloud Calendar works well on all Apple devices I have tried including macOS 10.14 ‘Mojave’. Nextcloud Contacts works well on iOS but doesn’t work with macOS Contacts.app on 10.14. I’ve now tried it on an older macOS version 10.11 ‘El Capitan’ and its fine there.

I don’t have any trouble logging in. I’m adding the address given by Nextclould Contacts but the macOS Contacts.app tends to remove it and leaves a greyed out /principals/users/ address. My assumption is that’s the “Wellknown” address which NethServer’s version of Nexcloud fails to redirect to /nextcloud/remote.php/dav. The difference between macOS 10.11 and later versions is that the Contacts.app will honour the server path to /nextcloud/remote.php/dav/addressbook/users/USER-ID/contacts/ whereas 10.14 won’t, no matter what you try and enter. Unfortunately I haven’t been able to find the Contacts.app plist where I might be able to edit the server path. But I think, and has been pointed out in other discussions, the fundamental problem lies with Nethserver.

For what its worth SOGo works. But I don’t like the way SOGo presents calendar and contacts accounts in the macOS native apps. If NextCloud is offered as part of NethServer it really ought to be able to be set up and used as easily as SOGo.

DG

Shall it be under ~/Library/Preferences/?
Maybe it is ~/Library/Preferences/com.apple.AddressBook.plist

Some tips for debugging contacts app, as well as some known bugs worth checking even if does not specify the same macos version.

Yes, but no! That’s the general app preferences. I guess window positions and the like. But it doesn’t have the account info. That, allegedly, is in ~/Library/Application Support/Address Book/Sources/ACCOUNT-ID/configuration.plist. But there is no configuration.plist there! A new directory (ACCOUNT-ID, its actually named like “517C4439-F92C-4458-8111-0EDCB1A391D9”) is created or each DAV account. It contains the database for that account but no configuration.plist. If it did I expect I could override the server path from /principals/users/.

I think this is a case of everyone is to blame :wink: Apple for messing up Contacts.app and NethServer for not setting the rewrite correctly when asked.