At the Forge - Sharing Calendars
Over the last few months, we have explored the iCalendar standard and the ways in which it allows us to create our own calendars, as well as work with remote ones.
But if you think about it for a moment, you'll realize we are missing a key piece of functionality. We have seen how easy it is to create our own local calendars. We have seen how we can retrieve remote calendars. We have even seen how we can create and distribute remote calendars, generating events dynamically from a Web/database application. But we have never considered how an individual Sunbird user might be able to share his or her calendar with other people.
Anyone who has worked in even a medium-sized organization knows that scheduling appointments can be difficult. Having access to everyone's calendar, and being able to schedule meetings for them, is an increasingly useful feature for our software to have. If every change I make to my calendar is available for everyone to see, it will be easier for them to schedule meetings when I will be around. (Or when I won't be around, if they want to keep something secret from me.) I used to ask clients why they use Microsoft Exchange as a mail server, given the availability of excellent open-source alternatives; inevitably, the answer would have more to do with the calendar support in Outlook and Exchange, rather than the e-mail functionality.
This month, we close our exploration of Sunbird and iCalendar with a look at how we can publish calendars to a central repository for others to share. The results might not be as slick or smooth as some of the commercial alternatives, but as with many other types of software in the open-source world, I believe that this is rapidly changing, and that we soon will see open-source calendar servers that are equal or superior to their proprietary counterparts.
Before we try to share a calendar, we should define exactly what we mean by sharing. You might think that shared calendars are stored in a single place and accessed by multiple calendar programs simultaneously. Although it is theoretically possible to configure Sunbird, or any other iCalendar-compatible program, such as Evolution, in this way, this is not what we would typically expect.
Basically, a shared calendar in the iCalendar world is an iCalendar file that is available for retrieval from a publicly accessible server. That iCalendar file might be updated once per hour or once per year; much like an RSS feed or a Weblog, there is no way to know how often a particular calendar file might be updated. For this reason, we need to make several assumptions: 1) everyone who is interested in this particular calendar is subscribed to it; 2) every subscriber downloads an updated version of the calendar on a regular basis, at least once per day; and 3) the calendar's manager publishes all changes and updates to the public server as soon as they are made.
In other words, the sharing does not take place in real time at all, but rather depends on all of the participating users to publish and retrieve updates on a regular basis. Between updates, a calendar user sees only the most recently downloaded iCalendar file, which is stored on his or her local computer. If a calendar subscriber is scheduled to retrieve updates only once per day, it is quite possible that he or she will miss last-minute updates to the calendar. Just how often someone should subscribe to calendar updates depends on the nature of the organization, how important it is to get updates and the load that might be placed on the server. After all, a server that can provide daily updates to 100 people might have trouble providing hourly updates to 10,000 people.
The easiest way to publish files on the Web is to use the old standby for file transfer, FTP. FTP has gone almost unused on my server for some time now, in no small part because of security concerns, but if you are working on a system that is properly secured, or if you would rather not use WebDAV (described below), FTP is a workable and simple way to share Web calendars.
On my server, running ProFTPd, I decided to create a new user (calendar) with a password (cal4atf). To ensure that this user cannot be used for remote logins or other mischief, I would like to give it a shell of /sbin/nologin, or perhaps /bin/false—both of which are programs that simply exit, without giving a malicious user any chance to log in and take advantage of my system. The problem with this approach is that FTP servers allow only users whose shell is in /etc/shells to log in. This presents us with something of a dilemma. We want to give the calendar user a non-interactive shell, but we also want the user to be able to use FTP. But, adding /sbin/nlogin to /etc/shells might open a security hole on our system. A simple solution is to copy /sbin/nologin to /sbin/nologin-but-yesftp and to add a line in /etc/shells with the latter shell's name.
Normally, non-anonymous users logging in via FTP are shown their own home directories. By default, ProFTPd goes one step further than this, forbidding users from going outside of their own home directories. Thus, we can rest assured that even if a malicious user gets a hold of our calendar user name and password, the worst that he or she can do is destroy or modify our calendar files. This is obviously not something we want to encourage, and in a production environment, you undoubtedly would want better security—giving everyone a unique user name and password, for example. But for this simple demonstration, we will forge ahead with our single calendar user, knowing that a security breach might well take our shared calendar files with it.
Assuming that we have configured FTP appropriately, how can we publish our calendar? From within Sunbird, we select the calendar we want to publish, which is called My Calendar by default. A menu pops up, the last option of which says, Publish entire calendar. If you select this option, a small dialog box opens, asking for the URL to which you intend to publish the calendar.
It goes without saying that the URL will begin with ftp://, but what comes after that? Assuming that the user name and password are as we indicated above, and that the server is calendar.lerner.co.il, we can access it as ftp://calendar:email@example.com/calendar.ics.
As you can see, we separate the user name and password with colons, and then put an @ sign between the password and the server name. Following the server is the name of the file we want to save. Although theoretically it can have any name or suffix, the .ics suffix is considered quite standard and ensures that all of the programs involved will understand the MIME types.
Now, let's say I make a change to my calendar. Must I now manually upload it to the server, going through this same procedure again? No, there is a way around this. Click on the calendar's name to get the same menu that you have already seen. Instead of selecting Publish entire calendar, select Edit calendar. This opens a dialog box that includes, among other things, a text field into which you can enter a URL, as well as a check box indicating that the calendar should be published whenever a change is made. I had mixed results using this functionality, although it worked more often than not and did a good job of keeping my appointments synchronized on different systems.
Subscribing to the shared calendar is similar to publishing it. Enter the full URL, including user name and password, and any iCalendar-compatible program should retrieve and display it. Of course, the configuration that we have put in place requires that the program can handle HTTP authentication.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide