foss

Introducing the OERu Tech Blog

dave — Thu, 08 Sep 2016 01:00:54 +0000

Introducing the OERu Tech Blog

Blog tags

free & open source

technology

kanban

devops

foss

dave Thu 08/09/2016 - 13:00

The Open Education Resource universitas (OERu) is an open organisation from top to bottom. Our entire technological infrastructure (with a couple exceptions) is built with and on Free and Open Source Software to which I normally refer as "FOSS".

We are committed to using FOSS for our infrastructure because:

it is consistent with our "open" philosophy for education - if our educational materials and all our OERu planning processes are "open on principle", then delivering them on "closed" (or, more precisely, "proprietary") technologies would be a clanging bit of cognitive dissonance. There's even a word for it: "prefigurative" - use means that are consistent with your desired end.
it allows us to use "best-of-breed" technologies (in the web-space, most innovation happens as FOSS first), combining many single-purpose solutions together in a modular way - via the open standards, open data formats, and open APIs they all support - to form a robust, feature-rich and secure communications and collaboration infrastructure. If a better solution to one of our requirements emerges, we can rapidly adapt our systems to adopt it, ensuring we are responsive and offer a fresh, state-of-the-art, well-supported and technically excellent platform.
our partner institutions collaborators become familiar with these tools, and if they find any of them valuable, they can champion their adoption by their home institutions, helped by the instructions provided by this blog or our FOSS code repositories. The money saved and flexibility gained by our partner institutions by doing so are likely to be of substantially greater value than their annual OERu membership fees!
Perhaps most importantly, none of our collaborators or learners are ever compelled to accept dubious (and usually exploitative) proprietary software Terms and Conditions to be part of our community. We respect our community's right to privacy and personal data sovereignty from the ground up.

Physical Infrastructure

Our infrastructure is currently hosted on FOSS Ubuntu and Debian Linux systems provides by four IaaS (Infrastructure as a Service) providers:

our MediaWiki infrastructure, the star of which is Wikieducator.org, is hosted on Amazon's "Elastic Compute" EC technology (located in the US, in our case), running Ubuntu Linux 14.04.
the rest of our self-hosted infrastructure, hosted on a high-specification virtual machine, "Hetzner", also running Ubuntu Linux 14.04 (based in Germany). More on the many services provided by Hetzner below.
more recently, we have created hosting for some of our new services on Azure, taking advantage of an annual grant given to qualifying non-profit organisations by Microsoft. We run Ubuntu Linux 16.04 hosts there. We ensure we do not make use of any proprietary Azure capabilities in any of our automated scripts so that we can shift hosting providers with minimal cost and inconvenience if/when Microsoft changes their free-hosting policy.
in 2018, we also received sponsored hosting capacity from NZ's own cloud service provider - whose cloud offering is entirely open source software built on open stack - Catalyst Cloud. We host our code repositories on their infrastructure. Many thanks to Catalyst!

Incidentally, the FOSS operating system, Linux, is the most widely used hosting platform on the Internet today, and Ubuntu is the most widely used "distribution" of Linux.

Externally hosted

We also make use of some externally hosted commercial FOSS services (we pay them for their services) to provide all the functionality we require:

OnlineGroups.Net for our family of mailing lists.
Mautic for our newsletter and user-engagement needs (Update 2017-06-16: due to substantial price increases for the hosted Mautic service, we are moving to a self-hosted version set up like this).
Update 2017-06-16: we have adopted a new open source Kanban planning tool, Kanboard, and we're supporting the developer by paying for the hosted service.

Web Applications

We host and maintain a number of websites "that do stuff", otherwise known as web applications. These include:

Our Course website which acts as a platform for per-course and per-cohort course websites, generated automatically via an OERu innovation: our course "snapshot" process from learning materials formulated on Wikieducator that are transformed into fully-formed, partner-institution-branded websites. Built on the WordPress blog platform, running in "multisite" mode.
Our main OERu Website - which provides information about the organisation relevant to both learners and partners. It is built on the Silverstripe Content Management System (CMS).
This Technology Blog... which is built on the Drupal CMS (version 8).

Web Services

To maintain control and flexibility, we self-host a myriad of useful web-based resources and services. These include:

our data sharing/digital artefact-storage site, comparable to having our own "Dropbox", is NextCloud.
our collaborative document editing platform is Etherpad-Lite.
our two "next generation" online forums, Community (for educators and OERu collaborators) and Forums (for learners), built on Discourse.
our chat system, a Rocket.Chat instance, similar to the proprietary Slack platform, replaces our venerable geeks-only platform, IRC (Internet Relay Chat).
our planning system, an instance of the Wekan "virtual Kanban board" (Update 2017-06-16: although we still use this a bit, we have found we prefer Kanboard)
our link shortening service is an instance of YourLS.
our issue tracking service is an instance of Mantis Bug Tracker (Update 2017-06-16: we've retired this as it wasn't quite the right fit for our users)
our integrated link sharing "course resource bank" is Semantic Scuttle.
our website usage tracking system built with Piwik.
Update 2017-06-16: we have recently set up a Mastodon instance to facilitate training our learners in the use of social networking without having to resort to a proprietary freedom-compromised platform. Here's how we did it.
Update 2017-06-16: we have a NextCloud instance, linked to a Collabora Online office suite instance, a concurrent editing application similar to Google Docs/Sheets. Howto coming soon!
Update 2017-09-22: we have a Lime Survey instance, replacing our use of Google Forms for conducting web-based surveys and polls.

Code Repositories

We have a convention of documenting (including instructions, source code, and configuration examples) all of our individual implementations FOSS implementations. We have multiple projects for public reference stored at both Bitbucket (we have repositories in both the Wikieducator and the OER Foundation projects - Bitbucket is a source code "forge" run by Atlassian in Australia) and Github (a forge run by Github in the US).

Over time, a few of us will be writing up some blog posts on specific technologies to introduce them in a gentle way to those for whom terms like "git" and "pull request" do not yet have a respectable technology-related connotation.

Our Toolbox

To build and maintain our infrastructure, we use a cornucopia of additional FOSS tools. Among these are text editors, monitoring systems, backup tools, debugging environments, "devops" platforms, container technologies, and many others. We'll no doubt cover some of these in future blog posts.

A couple noteworthy tools that all of our institutional partners should know about include:

we get all of our SSL (Secure Sockets Layer) certificates, that help keep our users' information secure and private by providing browser-to-server end-to-end encryption from Let's Encrypt, at no cost. We encourage everyone else to do likewise! Here's our Let's Encrypt howto.
OpenSSH (Secure SHell) - which ships with all Linux systems of which we're aware - it's the way we access all of our remote systems securely from anywhere.

Add new comment

From FOSS to LibreSoftware - it's about clarity and values

dave — Thu, 12 Oct 2023 00:18:46 +0000

From FOSS to LibreSoftware - it's about clarity and values

Blog tags

foss

libre software

dave Thu 12/10/2023 - 13:18

Any reader of this site will notice that we often talk about 'Free and Open Source Software' which we usually abbreviate as FOSS. For those who aren't intimately familiar with the history, trajectory, and nuances (warning - they are big topics) of the Free Software and Open Source Software camps - both subsets of information technology, itself a subset of digital technology - its significance is both arcane and something of a barrier to understanding.

Free Software has always had the very unfortunate ambiguity in the English-speaking world due to the word "Free" having two major meanings: free as in liberty or freedom or speech, or free as in gratis or no-cost. It seems that for most, they focus on the latter meaning and miss the point of the name. It's a constant battle to explain it to people ('free as in freedom, not free as in beer" is what you'll often hear). But, as any marketer will tell you, if you have to explain it, it's a failed band.

To be clear, even though most 'Free Software' is available at no cost, that is coincidental. The word Free in this case does not refer to cost, but rather the freedoms available to the users of the software. It is quite possible for 'Free Software' to be both 'commercial', and available at a cost, taking into account that any user has the freedom to distribute the source code at any price they want, including gratis.

The term "open source" is better marketing, in that it describes some relatively unambiguous properties of software - that the source code is available for others to view and, usually, do other things with, with various strings attached, depending on the perspective of the onlooker - but it fails to connote any of the philosophical values held by those who engage in creating, maintaining, and using it. It describes a few properties of a software project, but it doesn't offer insight into why that software is open source, which many of us think is crucially important.

In light of these short comings of both Free and Open Source Software as terms to describe what is important to us at the OER Foundation, we have started referring to 'LibreSoftware' instead. Even though, in the Angelosphere, schools are rapidly (but foolishly, in my opinion) decommissioning their Latin departments, most English-speakers have a passing familiarity with the world 'libre' - the root of liberty. It doesn't have the ambiguities of 'free', and it succinctly puts the affordances of 'Free Software' front-and-centre. It also brings us English-speakers in line with many other cultures with romance languages, where libre is well understood. So that's why we've started talking about LibreSoftware instead of FOSS.

Add new comment

OERF FOSS Tech Hosting Conventions

dave — Sun, 29 Aug 2021 23:44:43 +0000

OERF FOSS Tech Hosting Conventions

Blog tags

overview

docker

docker-compose

mariadb

nginx

ubuntu linux

ssh

restic

let's encrypt

git

gitlab

foss

dave Mon 30/08/2021 - 11:44

At the OER Foundation we host an array of Free and Open Source Software (FOSS) services. To keep things manageable, we have established a set of conventions to which we adhere, and I'm describing them here in case it's helpful to others who can either learn from, or improve on, our experience.

To begin with, we use Ubuntu Linux for all of our hosts. We deploy the current Long Term Support (LTS) version of Ubuntu (at the time of this writing, it's 20.04) on commodity Linux hosting services, like Digital Ocean and Hetzner.

Host access

We access all our hosts on the command line, via secure, end-to-end encrypted connections, using OpenSSH. We don't use a server management tool (neither an open source one, like ISPConfig or Webmin, nor proprietary ones like Plex or CPanel). They would just slow us down. We prefer the efficiency and power afforded us by SSH. At any given time, I'm logged into a half a dozen remote systems, issuing updates, deploying code, diagnosing issues, checking resource usage, shoring up disk space, or tweaking Docker configurations.

Software on the host

On the host, we run the following:

We run etckeeper on each server to track changes in configuration. In general, we have these changes pushed to a central server to provide a reference in the event of a disaster (e.g. the server is compromised and needs to be 'nuked from orbit'...).
The Nginx web server - it's our reverse proxy of choice. All of our Let's Encrypt certificates terminate at the host server, greatly simplifying the deployment of the individual services running on it.
The Postfix SMTP server - it's our outgoing mailserver of choice, and we set it up as a smarthost, so that the server can send status and administrative messages to us via our MailCow email infrastructure using authenticating secure SMTP.
The Docker containerisation framework using the Docker Compose system to coordinate collections of containers that work together to provide specific services. Docker allows us to run a bunch of effectively independent Linux systems, each with potentially different sets of complex software dependencies, efficiently and reliably on a single host.
For each service, with an individual domain or subdomain name, we get a Let's Encrypt SSL certificate using the letsencrypt scripting toolchain. It is free of cost, and easy to build into our workflow, so it's a 'no-brainer' as far as we're concerned, ensuring all of our sites protect the data of their users with full encrypted links!
For applications we deploy that depend on the MySQL database, we run a single instance of the fully MySQL-compatible MariaDB on our host, and the Docker containers connect to it via the internal network. We do it this way to easy the process of backing up the various MariaDB databases, which would be much more fiddly if we were running a bunch of individual MariaDB or MySQL instances in Docker containers. We use MariaDB because we prefer its development model, design decisions, and the fact that it's not being run by the Oracle Corporation, which owns the MySQL project.
We use Restic to perform remote encrypted incremental file backups for the filesystems on each server. We send them to a development server we have which has oodles of disk space (BTRFS RAID1 if you're curious) for safekeeping.

When each new Ubuntu LTS release comes out, we tend to create an install image for our commodity hosting provider (most recently, Digital Ocean), which has all these things pre-installed.

Docker deployments

For the various services we deploy using Docker - more specifically, using the very handy Docker Compose scripting toolchain, we have a bunch of conventional practices.

We put all our Docker Composer recipes in a common directory: /home/docker - each service goes in a directory using the domain name of that service. For example, this Tech blog, tech.oeru.org is in the directory /home/docker/tech.oeru.org on our server about.oerfoundation.org. Each service directory has a docker-compose.yml file which defines the collection of Docker containers making up each service. It also specifies the local directors in which data we want to make persistent, even surviving the removal of relevant Docker containers. In the case of this site, the containers include an Nginx webserver container which submits requests delivered to it by our hosts's Nginx reverse proxy to a PHP scripting engine container which, in turn, consults the Drupal 8 source code making up the site, and the MariaDB on the host which stores the data. There is also a PHP container which automatically runs the behind-the-scenes automated 'cron' tasks that every Drupal site requires.
We store that per-service persistent data in a similarly named directory under /home/data, so this site's data is stored in /home/data/tech.oeru.org. That data includes, in the case of this site, an Nginx directory, with a generic Drupal website configuration, and a directory to contain all the Drupal 8 core source code and that for theme, module, and library dependencies. In a few cases, where we're using tools with specialised Docker deployment practices, like Mailcow, BigBlueButton, and Discourse, the persistent data for the site is stored under the /home/docker directory to avoid unnecessarily complicating our use of those tools. So our conventions are just that - not hard and fast, if there's a good reason to compromise them.

Keeping track

For all of our service configurations, and, in particular our Docker deployments, we use Git to provide source code versioning and management. We also use it to deploy code that we have developed ourselves. Where possible, we use (and contribute back to!) upstream git repositories supplied by the communities surrounding many of the FOSS services we offer. We see that as doing our part to be good, contributing FOSS community members.

All of our git repositories are held on our own, self-hosted Gitlab instance: https://git.oeru.org - anyone is welcome to peruse the repositories, and we invite anyone interested in contributing to request a an account (give us an idea of what you're interested in doing and how you'd like to participate!).

Add new comment

Configuring a Linux server to send email via the Postfix SMTP server using an external authenticating SMTP host

dave — Mon, 02 Aug 2021 02:08:28 +0000

Configuring a Linux server to send email via the Postfix SMTP server using an external authenticating SMTP host

Blog tags

ubuntu linux

postfix

smtp

18.04

free & open source

foss

20.04

22.04

dave Mon 02/08/2021 - 14:08

Just about any and every server needs to be able to send email - whether it's end-user-email, like password recovery services for a website to emails to system administrators reporting on the status of system backups and errors. The problem is that it's non trivial (understatement) to set up a mail server properly.

This howto assumes you have a Linux server (these instructions are for Ubuntu 22.04 and 20.04, although it should work on earlier versions of Ubuntu server and Debian Linux with minor changes, and the concepts will be very similar on other Linuxen) with a static IP address, with one or more fully-qualified-domain-names (fdqn) pointing at that address, and you have SSH-based access to it. I've previously provided tips on how to get to this stage.

Authenticating SMTP

To send email, you need access to a server, somewhere on the Internet, that provides the Simple Mail Transfer Protocol (SMTP) service. It's an open standard, and for most of the history of the Internet, email services have been mostly provided by Free and Open Source Software (FOSS) tools - the first SMTP was called "Sendmail" and it was fully FOSS, and it's still in use today (although it has mostly been superseded by faster, more secure systems, the best of which are also FOSS).

At the OERu, we use the Docker-based installation of the amazing, completely FOSS MailCow project to provide our organisational email services. I might cover that set up in a future tutorial here, because MailCow makes an otherwise almost intractable problem - hosting your own email service - much more tractable. Having a MailCow set up means we can offer "full service" email for any number of domains and users and aliases with all the bells and whistles including incoming and outgoing mail with all the virus scanning (we don't really need it because we use Linux desktops, but for other folks it's useful) and dynamic spam filtering services you'd expect from a much larger operation: Team MailCow have done an amazing job in pulling together a comprehensive set of FOSS applications to provide all the conceivable requirements of a full-fledged, multi-domain email system, including shared calendaring, contacts, and webmail. A great companion to your organisation's MailCow server would be a BitWarden password safe server (also FOSS)... just sayin'.

So, now, assuming that we have a MailCow server or some other functionally equivalent SMTP service available (apparently you can do this with Gmail, if you're a paying using although because of Google's terms of use, we recommend finding a more trustworthy solution), we have the option of "authenticated SMTP" for outgoing email using credentials we can set up. For example, in MailCow, we can specify a domain we host, like say oeru.org (and for which we've defined an MX record and a few other relevant records as guided by MailCow administrative web interface). On top of that, we can specify a mailbox for a dedicated "send stuff from remote relay hosts" email address using that domain, like smtp@oeru.org, with a strong password. With that, we can securely send email using that email address as the username and that password from anywhere we have access to the Internet.

The only tricky part is that we have to ensure that whatever "reply to" email address we specify from our applications, say notifications@tech.oeru.org, is using a domain we also host on the same server, and that there's an email alias of that email address defined and set as "allow to send from smtp@oeru.org" in the MailCow interface. If we haven't made sure of that, our mail server is likely to reject sending emails with that "mismatching" email address. This is a basic spam deterrence measure, which is for the best, despite sometimes making a email system administrator's life harder.

Once we've got that (and it's easy once you've done it once or twice - I'm mostly writing this down now so I don't have to try to re-remember every time I need to set up a new server - and I hope it helps others, too), we can set up any server we control to send secure (and spam-filter-resilient) email. For what it's worth, too, MailCow uses Postfix as its SMTP server component (there're a bunch of other components, too).

Postfix SMTP with SmartHost

The first thing you need to do to create a postfix smarthost is to install the postfix application on a new server (this assumes you're logged in with a user who has "sudo" - aka admin - permissions):

sudo apt update && sudo apt install postfix bsd-mailx

During the install, you'll be asked to select a bunch of configuration parameters. Select the defaults except:

Select "Internet Site with Smarthost",
fill in the domain name for your server,
the domain name and port (in the form [smtp server domain]:[port], e.g. smtp.oeru.org:587 ) of your "smarthost" who'll be doing the authenticating SMTP for you, and
the email address to which you want to receive system-related messages.

After that's done, you can proceed.

Next Steps

For the rest of this tutorial, you'll need to do the following. First, select your text editor. I use vim, but if you're new to the command line, I recommend using nano - it's more straightforward:

EDIT=`which nano` or EDIT=`which vim`

sudo $EDIT /etc/aliases

We need to make sure the "root" user points to a real email address. Add a line at the bottom which says (replacing [your email] with your email :) )

root: [your email]

After which you'll need to convert the aliases file into a form that postfix can process, simply by running this:

sudo newaliases

Then we have to define the authentication credentials required to convince your mail server that you're you!

sudo $EDIT /etc/postfix/relay_password

The resulting file only needs one line with three bits of information:

[smtp server domain] [user name]:[password]

for example:

smtp.oeru.org smtp@oeru.org:SomeObscurePassw0rd

Then save the file and, like the aliases file, run the conversion process (which uses a slightly different mechanism):

sudo postmap /etc/postfix/relay_password

Finally, we'll edit the main configuration file for Postfix to tell it about all this stuff:

sudo $EDIT /etc/postfix/main.cf

If your SMTP server uses port 25 (the default for unencrypted SMTP) you don't have to change anything, although most people nowadays prefer to use StartTLS or otherwise encrypted transport to at least ensure that your SMTP authentication details (at least) are transferred encrypted. That means using port 587 or 465. If you're using either of those ports, find the "relayhost = [your server name]" line... and add your port number after a colon, like this

relayhost = [your server name]:[server port]

or, for example:

relayhost = smtp.oeru.org:465

Next, add the following lines at the bottom of the file:

# added to configure accessing the relay host via authenticating SMTP smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/relay_password smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

# if you're using Ubuntu prior to 20.04, uncomment (remove the #) the
# earlier line smtp_tls_security_level = may to save errors in 'postfix check' # and comment this line (by adding a # at the start) smtp_tls_wrappermode = yes

And, finally, comment out the line smtp_tls_security_level = may higher in the file - careful not to confuse it with the very similar smtpd_tls_security_level variable (note the extra '''d''' in `smtpd...`) line.

Save the file, and then check that your syntax is correct:

sudo postfix check

If it is (running the command returns no errors, and it might not return anything at all - that's a good thing!), then you can run

sudo postfix reload

to get postfix to reload its configurations and you can test out your new smarthost-configured SMTP server!

If not, the output of the check command will usually give you a helpful insight into what is wrong with your configuration... you'll also find that looking at the mail log is very helpful and offers great insights:

sudo less +G /var/log/mail.log

and if you're not able to fix it based on those, you'll find postfix is widely documented and has rich set of easily discoverable resources out there on the web - a search engine is your best resource!

Testing your outgoing email

By default, a command line application called "mail" is installed as part of the bsd-mailx package we installed alongside postfix. You can use it to send test email from the command line on your host to verify you've got things working correctly! The stuff in <> are the keys to hit at the end of the line...

$ mail you@email.domain<ENTER>

Subject: Testing from your.relay.server.domain<ENTER> Testing postfix remote host<ENTER> <CTRL-D> Cc:<ENTER>

Typing <CTRL-D> (hold down the Control or Ctrl key on your keyboard and press the "d" key) will finish your message, showing you a "CC:" field, in which you can type in other email addresses if you want to test sending to multiple addresses. When you then hit <ENTER>, it will attempt to send this email. It might take a few minutes to work its way through to the receiving email system (having to run the gauntlet of spam and virus filters on the way).

You can also always check the postfix system logs to see what postfix thinks about it using the command above. Hit <SHIFT-F> to have the log update in real time.

Done

Now you've got working outgoing email from your server. That means many higher-level web applications you might install on your infrastructure will work out-of-the-box, because what you've set up, for example, enables the default PHP email service and that used by other stacks.

Sending from Docker Containers

You can configure your server so you can reference it from services you run from Docker containers on your host. You do this by referencing the host, like via an ad hoc SMTP server on your container like msmtp, and you can just reference it as 172.17.0.1, which is the default base IP for Docker hosts from the perspective of Docker containers. You might find it's different on your particular install. In that case, you have to make your Postfix SmartHost accept email for sending from the Docker containers on that server. There're quite a few examples of that among my Docker recipes on the OERu's git repository.

Add new comment

Working from home

dave — Tue, 17 Mar 2020 20:11:13 +0000

Working from home

Blog tags

covid-19

working from home

foss

dave Wed 18/03/2020 - 09:11

In light of the current global pandemic, there's lots of interest out there on "working remotely" or "working from home". We've been doing a for years, and it has a lot of advantages... here's how we do it....

The OER Foundation (we're the charitable foundation that coordinates the OERu) is a "remote organisation". There is no central office - after all only two of us work for the Foundation full time. We both work from our homes, in Mosgiel and Christchurch, two centres about 5 hours drive apart in the South Island of New Zealand. We also have colleagues, who dedicate part of their time to our projects, based at Otago Polytechnic in Dunedin. Despite our small (but plucky) team, we collaborate with educators at 40+ tertiary institution partners (universities and polytechnics) in 5 continents around the world who amplify our efforts... Luckily for us, we both have the benefit of high speed internet access and a knowledge of Free and Open Source Software (FOSS) and how to make it work for our requirements - and scale for a global audience of educators and learners!

How we work

At the OER Foundation, we're task oriented (not time oriented - no timesheets). Every week, I have a set of standard tasks I undertake, as do my colleagues, and we have to get them done. For example, I "go around the (virtual) traps" at the start of each week to ensure all our remote systems are up-to-date and secure as possible. When those are done, we have a bunch of longer term (important-but-not-urgent) projects that are under way, scheduled in a kanban board (we use either our NextCloud's "Desk" plug-in or the very fine Kanboard FOSS app) or by agreement.

During the day we have frequent communication and collaboration among our small team, as well as with the broader group of OERu partner representatives - our Rocket.Chat system is our virtual meeting room and water cooler for both meeting and informal discussion.

A few of us meet online for a video chat each day to catch up on the days work, talk strategy, and socialise a bit. We usually have our chats using Jitsi Meet, which is triggered by Rocket.Chat. Lately, we've been using Big Blue Button a lot more for our catchups, just to mix it up a little - they're both great for small groups (Big Blue Button also supports much larger groups).

Here's a table laying out our "work from home" stack:

Technology category	Specific FOSS technology	Replaces
Desktop/Laptop Computers	Lenovo Thinkpads
Operating System	Ubuntu Linux or Linux Mint	Microsoft Windows, Apple MacOS
Email service	Mailcow (self-hosted - how to do it)(commercial service)	Google Mail, Microsoft Outlook, Fastmail
Email client (reading/composing)	Thunderbird (desktop), SOGo (webmail - built into Mailcow)	Microsoft Outlook, Apple MailApp, Gmail, Hotmail, etc.
Web browser	Chromium or Firefox or Brave	Google Chrome, Microsoft IE or Edge, Apple Safari
Chat service, video conf	Rocket.Chat (self-hosted - how to do it)(commercial service) - (access via browser, or desktop and mobile interfaces)	Slack, Discord, Gitter, Microsoft Teams
Document management and sharing	NextCloud Hub (self-hosted - how to do it)(commercial service - gov't and education discounts available)	Dropbox, Google Drive, Microsoft OneDrive
Collaborative documents	NextCloud's OnlyOffice integration (self-hosted - how to do it)(commercial service - gov't and education discounts available)	Google Docs, MS Office 365
Kanban project management	NextCloud's Deck app or Wekan	Trello, MS Project
Shared calendaring and contacts	NextCloud's Calendaring and Contact apps	MS Outlook, iCal, Google Calendars
Scheduling (timezone aware)	NextCloud's Poll app (part of NextCloud)	Doodle Polls
Password manager (share and personal)	BitWarden (self-hosted - how to do it)	LastPass, 1Password, Keepassx, etc.
Video Conferencing (< 8 participants)	Jitsi Meet (externally hosted) browser-based or mobile apps (all FOSS)	Google Hangouts, Apple Facetime, Microsoft Skype
Video Conferencing (webinars, hundreds of participants, breakout rooms, etc.)	Big Blue Button (self-hosted)(commercial service one, two) browser-based, mobile apps available - if you want to try it yourself (gratis) go to the NZOSS' "Work from home" page.	Zoom
Social Media	Mastodon (self-hosted)	Twitter

Outside of that stack of software applications, we use lots of other FOSS apps on the desktop, like Inkscape (for vector drawings, replacing Adobe Illustrator), Krita and Gimp (to modify images, replacing Adobe Photoshop), Kdenlive (to edit video), LibreOffice (to edit PDFs, documents, spreadsheets, drawings, presentations, replacing MS Office), Audacity (editing audio like voice-overs and podcasts), and many others, and many dozens of development tools to produce digital artefacts. If you're looking for a FOSS tool to do a job, let us know - perhaps we can help you find one that's suitable!

If you want to learn more about our cloud infrastructure - which involves a whole additional constellation of FOSS technologies - here's a review of our 2018 technology stack (here's an updated version in early 2023), with which we are providing a full online university...