[NBLUG/talk] Entering the age of dumb. Advice on cloud storage for my desktop stuff

Rick Moen rick at linuxmafia.com
Wed Mar 14 16:28:28 PDT 2018


Quoting Robert Thille (rthille at gmail.com):

> /me goes off to look at Baikal....
> Sees 'requires: PHP'
> 
> /me Nope Nope Nope.


Man after my own heart, you.

I wrote about all of this stuff, with scathing comments about PHP
dependencies in numerous oft-suggested tragic wastes of time like
ownCloud, about six months ago on the SVLUG mailing list and the GoLUG
one (central Florida), where one Brad Maggard opened the discussion with
a leading question (quoted much further down) almost certainly
implicitly asking GoLUG to start outsourcing part of its operation to
Google proprietary hosted SaaS software (Google Calendar).   Here are
some excerpts from my comments to _that_ Brad Maggard rhetorical
question, that might interest.  (Skipping horrible things that I did NOT
recommend, and going straight to the good one:)


---<snippity>---

[...]
But then there's:

o  Radicale.  Written in Python 3.3 w/pip (yay), and is _small_.  Does
CalDAV (calendars, todo-lists) and CardDAV (contacts).  GPLv3.  And
that's _it_.  Doesn't require a goshdarned SQL database.  No XML or Java
servlet brain damage.  Simple textfile configuration.  And it's claimed
to JustWork[tm] out of the box.  Just that one dependency.  Doesn't
require superuser rights.  Manages multiple calendars and address books.
http://radicale.org/documentation/
https://www.floreo.info/2017/08/09/use-radicale-to-get-your-own-shared-calendar/

Brad Maggard, why don't you try setting _that_ up?  You can get it going
on the machine in front of you as http://localhost:5232/ in five
minutes.  If you agree it's good, get it going on a Raspberry Pi 3, put
that on a static IP, have Steve Litt point DNS for ical.golug.org to it,
and presto!  GoLUG would have a flexible general-purpose iCalendar
/CalDAV facility.

But let me guess:  Your idea was just for Steve Litt to maintain an
outsourced GoLUG calendar on Google Calendar, wasn't it?  ;->

[...]

Bonus links for people interested in the Radicale CalDAV/CardDAV daemon:

https://evilshit.wordpress.com/2013/11/19/how-to-install-a-caldav-and-carddav-server-using-radicale/
   Run-through of configuring setup (from tarballs) and client access.

http://christian.kuelker.info/doc/radicale/calendars-todo-lists-and-contacts-with-radicale.html#clients-to-use-radicale
   Setup of Radicale 0.7.1 and 0.9 under Linux (Debian Wheezy) and usage
under Linux, Mac OS X and iPad in brief.  (He chose to install from
tarballs because the packages in Debian Wheezy were then, mid-2016,
too old for his liking.)

https://blog.dskwrk.com/2016/01/30/Host-your-own-Radicale-CalDAV-and-CardDAV/
   Very quick and simple setup of Radicale from .deb on Debian behind
   nginx.  Uses iPhone as an example client setup.

https://wiki.archlinux.org/index.php/Radicale
   As usual for the ArchLinux wiki, useful details.

https://www.williamjbowman.com/blog/2015/07/24/setting-up-webdav-caldav-and-carddav-servers/
  Another nginx setup.  He compiles pieces needed.  Client setup
  described for iPhone and for a CardDAV CLI client called pyCardDAV.

https://partofthething.com/thoughts/host-your-own-contacts-and-calendars-and-share-them-across-devices/
  Apache HTTPd as reverse proxy for Radicale.  Distro-neutral.  Covers
  a bunch of client software on sundry platforms.

https://ubuntuforums.org/showthread.php?t=2212134
  Interesting perspetive.  User has ruled out Radicale and some
  other promising options because calendar invitations to be supported
  and able to go to both internal and external addresses.  (Knowing
  _what your requirements are_ is indeed crucial.)

https://www.mkonrad.net/2014/06/05/running-your-own-caldav-server.html
  More valuable perspective.  User liked Radicale's very lightweight
  nature, but found that appointments sometimes were missing in his
  calendar client, and found that a Radicale admirer had already
  chased this problem down to access limitations in the single-file
  *.ics calendar datastore, and is attempting to address this in a
  Radicale fork named Calpyso, written by Keith Packard of X11 fame,
  https://keithp.com/blogs/calypso/, https://keithp.com/calypso/ ,
  storing one event per vcalendar/vcard file instead.

  Note:  The Radicale Web pages states that the Radical daemon _does_ now 
  support exactly that sort of non-default back-end called 'multifilesystem',
  which uses per-contact files rather than single files.  This is quite
  possibly courtesy of Keith Packard's good, cooperative attitude to the
  parent project.  Go, Keith!

https://www.techrepublic.com/blog/linux-and-open-source/create-an-easy-to-use-linux-calendar-sharing-server/
  Another simple setup runthrough, on Ubuntu from a standard .deb.
  Explains client setup for Evolution and Thunderbird.

http://blog.pingoured.fr/index.php?post/2011/11/13/Radicale%2C-host-your-own-calendar
  Runthrough for RHEL/Fedora starting with a source RPM.
  Example client setup with Evolution.

https://www.youtube.com/watch?v=WlkF79-KCPo
  Video runthrough on something called OpenMediaVault, a
  Debian-based NAS.

https://wiki.debian.org/Radicale
  Very simple Debian docs / runthrough, using Apache HTTPd.

https://www.gerrywilliams.net/2017/07/install-radicale-caldav-server/
  Simple setup on CentOS 7.

https://petermolnar.net/replacing-baikal-with-radicale-for-carrdav-and-caldav/
  As URL suggests, user fled from Baïkal, and describes conversion to
  Radicale.

https://umij.wordpress.com/2016/12/24/setting-up-radicale-on-a-raspberry-pi/
  Example setup on a Raspberry Pi running Raspbian.  (See, I wasn't
  exaggerating.)

---<snippity>---


This is an area ripe for a proper, real, skeptical survey by someone
resistant to the siren call of overengineered and security-bereft (e.g.,
PHP-based) sludge, and with the patience and free time to do real-world
testing.  The IT press lacks the good judgement to bypass sludge, so,
if this is ever to happen, I guess it'll have to be up to us old,
cynical sysadmins and user-group greybeards.

It should be noted that one of the ways that the lightweight,
surprisingly-not-sucky alternatives win is by eschewing the complexity
of supporting live, Web-medisted editing of iCalendar/vCard/etc.
content, and instead merely host and mediate access to such files.  
I.e., they punt on replicating every last feature of Google Calendar.

Therefore, in their usage model, you are editing/managing your
calendar/events/cards data _elsewhere_, not online in real time a la
Google Calendar and other baroqueware monstrosities.  I covered Linux
options for such editing earlier in the GoLUG thread.  

And, of course, running through my posts was the very attitude Brad
Haggard found shockingly retro, e.g., 'Screw all of this fashionable
outsourcing to other people's hosted proprietary code and not even
having custody of your own data.  Screw overengineered baroque software
with poor security and excessive feature lists that nobody really needs.
Has nobody learned from 40 years of open source?'

Right below was the leading question that set me off:


---<snippity>---

Brad Maggard had an interesting suggestion:

> Suggestion: add iCalendar for meetings to golug.org

Cool idea.  But have you surveyed the software required
for meaningfully hosting, and for maintaining/editing, a schedule file
in iCalendar (RFC 5545) format?  Preferably using Linux and open source,
and certainly not by outsourcing the job to some huge cloud-computing
company, right?</deadpan>

I've intermittently looked into this question for the LUGs in my area,
because it seems a really fine idea -- and then you get into the
complications.

Simple, locally-run (as opposed to outsourced to one of those huge cloud
computing companies with proprietary infrastructure and a Web front-end)
open-source viewing/editing programs on Linux for iCalendar ('*.ics')
files are a bit thin on the ground.  Orage (formerly Xfcalendar), a nice
little app most often bundled with Xfce, will do it.  It's really not
bad at all, and is growing on me.
http://www.kolumbus.fi/~w408237/orage/

Then there's the 'Lightning' scheduling XUL extension for Thunderbird
and Seamonkey (no longer compatible with Firefox because it's dropped
XUL support), which was long the go-to way of dealing with iCalendar
information not because it was great but rather because there wasn't
much else.

The classic Mulberry graphical e-mail client for Unixes, no longer
proprietary and available since 2007 under Apache License 2.0, has
iCalendar support -- but Linux people tend to forget it even exists.
http://mulberrymail.com/

KDE's Kontact PIM/groupware thing, specifically the KOrganizer portion
of that suite, does iCalendar in some way, if you don't mind a whole lot
of KDE plumbing that arrives with it.
https://userbase.kde.org/KOrganizer
So does Claws Mail with the optional vCalendar plugin.

Other than Orage and Lightning, iCalendar support is mostly hidden among
a mess of overblown 'groupware' monstrosities (Zarafa, Kopano, Zimbra,
SoGO, Simple Groupware, Horde, Open-Xchange) and some CMSes & such
(Textpattern, Plone, WordPress, RT, Mootle, SPIP, Semantic MediaWiki,
Tiki Wiki, Tryton, TYPO3, OLAT, Drupal).  Most of the latter are
primarily _server_-side implementations, with client edit/view access to
the iCalendar file contents usually via Web front ends.  Not simple,
locally-run open-source viewing/editing programs for Linux, in other
words.  For that, you are stuck with Orage, Thunderbird/Lightning,
Seamonkey/Lightning, KOrganizer, Mulberry, or Claws Mail w/vCalendar
plugin.  Or Evolution, if you're up for a GNOME monstrosity.  (I'm not.)

But then, you start looking closer, and talking to users of calendar
information, and realise that the Wave of the Future[tm] is no longer
just hosting an iCalendar file on a public Web site, like, 'Hey, our
schedule is always posted as http://golug.org/golug.ics . Enjoy!'

You do that, and people say that's great, but what about making it
editable in-situ over the Web using CalDAV?  Because it turns out that
offering iCalendar scheduling via plain http is no longer what people
expect, but rather CalDAV-wrapped http in _addtion_ to just a plain
downloadable .ics file:  Your Web server is now expected to have all the
CalDAV extensions, and eachhosted calendar gets accessed using (1) a
Calendar-id string, (2) a Main URL, and (3) a CalDAV URL.  Adolfo
Villafiorita's page gives a bunch of the annoying details:
http://ict4g.net/adolfo/notes/2015/07/04/determing-url-of-caldav.html
[...]


---<snippity>---

That was actually where I started ripping through all of the mostly
ghastly oft-suggested server-side software options -- DAViCal,
Web2project, Baïkal, NextCloud, ownCloud, Sun Java System Calendar
Server, Apple Darwin Calendar and Contacts Server -- before finally
describing _Radicale_, and contrasting its refreshing lack of stupid
design, language, and scope errors with the rest.

I hope the above is useful.




More information about the talk mailing list