Basic config questions / Apple device problems

[macsrwe]

As a non-developer left in the lurch by Apple's discontinuation of calendar service in Apple Server, and as someone completely unfamiliar with underlying calendar protocols, I have a lot of very basic questions.

I gave up trying to port Radicale to macOS, endeavoring instead to port it to an Ubuntu VM running on our OS X server because there was a prepared package available for Ubuntu and I need to get something running quickly. I followed all the instructions I could find.

I have it to the point where systemd claims it's "started," and I can see it listening to port 5232 in netstat. have connected to the server's port 5232 by hand from Terminal on macOS, and got it to throw an XML response back at me, so it looks operational.

However, we're an all-Apple shop, so we need to use this with the macOS and iOS calendar clients. I can't get either one to talk to it. When I try to specify an account, both tell me that they can't validate my userid with the service (quite possibly they can't even talk to the service, if it involves more than simple traffic on port 5232).

Question #1: In researching other people's tickets, and in looking in the advanced pane in iOS, I see there is a URL involved. Is it assumed that the machine running Radicale has a web server already active? Because I don't -- nothing in the documentation said I needed to set one up, and I created this VM strictly to run calendars.

Question #2: I see from at least one ticket that several years ago, it was necessary to specify one set of connection parameters and fail, then specify a different set to succeed. Although it sounds like voodoo, I don't doubt it. Is that sort of voodoo still necessary today, or has someone since fixed it to work more straightforwardly? What are the parameters that work with macOS/iOS today?

Question #3: The introductory webpage has a line saying, "Run behind a reverse proxy." Is this MANDATORY? I can't tell from the presentation. If optional, what advantage would doing that give me?

[mookie-]

You can add a webserver/proxy in front of radicale but you don't have to do it to use it. In my opinion it's better to have a reverse proxy which handles e.g. the SSL.

I can't tell you how to configure the calendar on macos, I've just found this older blogpost for a previous version, but it might help you (http://christian.kuelker.info/doc/radicale/calendars-todo-lists-and-contacts-with-radicale.html#apple-mac-os-x) Perhaps you should try to access the webinterface (https://radicale.org/configuration/#web) and create your calendar first and then add it to macos.

[return42]

Hi @macsrwe, I agree with @mookie, further more: @holian7 has a similar setup. He did a lot of research, may it helps to have a look at:

• SSL #879
• Cert #893
• iOS Client: #786 and #870

[Tntdruid]

I run it as service whit over 2k clients and it works, dont see the need to use proxy, we use imap for auth.

[macsrwe]

Aaargh.

The Kuelker link covers how to access it from iOS clients, but not how to install it on macOS. The Radicale webpage says installation on macOS is "to be supplied." I had already given up installing it on macOS because of this.

Even worse, #870 seems to indicate that even accessing Radicale from iOS 12 clients is entirely broken, and I don't see any resolution. That's a deal-breaker, since iOS 12 is in play here.

The "webinterface" link provided describes two config settings, but says nothing about how you actually access the webinterface, a puzzler on a machine on which we haven't configured any webserver.

And heaven help me, I don't want to enter the swamp of mistranslating German.

I feel like a fellow asking how best to set up an account to ship daily packages by air, and receiving advice instead on how to assemble his own experimental aircraft. Sorry, but I suspect this community has no real feel for how daunting this all is to someone who just needs to replace a turnkey end-user package like Apple Server.

I believe I will abandon this project entirely and follow another option, which is to take the server box I am replacing, and leave it running on the network doing nothing but handling calendars, while the newer and faster box handles everything else. This is something I can arrange without having to learn a whole new skillset, and it will buy me time until someone gets around to offering a turnkey calendar server for the MacOS to replace what Apple decommissioned.

Thanks for your help.

[Tntdruid]

Works fine on iOS 12

[return42]

@macsrwe you have to think about your mindset ..

Sorry, but I suspect this community has no real feel for how daunting this all is to someone who just needs to replace a turnkey end-user package like Apple Server ... This is something I can arrange without having to learn a whole new skillset, and it will buy me time until someone gets around to offering a turnkey calendar server for the MacOS to replace what Apple decommissioned.

First, you paid Apple a lot and they left you alone in the rain. Second, you don't want to learn new skills or even work together with the community. And now you asking non profit contributors for help and if they do not give you a ready-made solution for your scenario right away you are annoyed?

Can you imagine how much that disappoints me?

[macsrwe]

First, you paid Apple a lot and they left you alone in the rain… And now you asking non profit contributors for help, and if they do not give you a ready-made solution for your scenario right away you are annoyed?

Actually, I paid Apple $21.25 for a totally turnkey (and documented) package with remote backup server and calendar server functionality that I needed to add to a used Mini server that was already doing many other things for us and still is. For the three years of service I got out of it, I can't complain about the price (and Apple hasn't shed the remote backup product, just moved it into the base OS). I would have been willing to pay maybe three times that price for a replacement calendar package… but not (if I may speak frankly) for a bag of parts, a tube of glue, and a spotty set of assembly instructions. I'm not here because I'm "looking for something free," I'm here because I'm looking for something reasonable that works, and free is the only option you chose to offer.

Apple (uselessly) recommends four packages to replace the functionality they yanked: two packages in the "bag" state, and two that either require or emulate MS Exchange and are priced accordingly outrageously (e.g., $200/year), and I'd rather adopt a Nigerian prince than introduce Exchange into my workflow. (Curiously, of the two in the "bag" state, neither one has any real support for installation directly onto macOS, exposing Apple's recommendations as a CYA sham at best.)

Second, you don't want to learn new skills or even work together with the community.

It's quite possible that I was coding commercially while your parents were still learning long division. But I'm well retired now. I've built my share of Heathkits over the years, but I'm no more interested in rolling my own calendar server at this stage in my life than I would be in building my own TV remote. I'm looking for a product, not a project. I can't predict how many people in the same position will be coming here due to Apple's recommendation, but you will probably be seeing more.

Can you imagine how much that disappoints me?

Don't take it personally because I've decided your package is too far removed to be dragged into the market niche that I needed it to be in. I realized that, and moved on. I'm not "annoyed," I just didn't find what I was looking for.

You folks were right up front about what Radicale was: somebody's student project, didn't implement the entire standard, no price, no support. And the "support" here was better than the dead silence I received at Apple's #1 replacement suggestion (the one with actual Apple roots, yet has no more working macOS installation instructions than you do). But the help came in the form of additional small bags of parts. There were no "here is a tested set of steps you can use to ABC." Everything required hand-filing and hand-fitting. I've been around long enough to know that means a perpetual investment in self-support every time the wind changes direction, and I'd rather pay a modest price to benefit from free market division of labor performed by people who enjoy doing these things.

I'm not slamming you because of what you are offering. I'm just letting you know that Apple has pasted a target on your back by recommending you for a niche you don't occupy, and that you shouldn't be surprised if you see more of this style of demand in the future.

[return42]

@macsrwe this (like many other projects on github, gitlab ...) is a open source project, not a product. Sorry, that we can't help you. Most of the users (like me) are also contributors .. in one way or another .. even testing a setup and sending a bug report or supporting other users in discussion is already a contribution to evolve such a project and everyone is welcome to become a part of this great community.