At the Forge - Sharing Calendars
FTP is fine for some tasks, but it has a number of drawbacks. To begin with, you might not want to run an FTP server on your computer, given its history of security problems. You also might prefer to have everything run over HTTP for performance reasons or because you can encrypt the transmission over SSL. For a variety of reasons, then, you might want to consider another alternative: mod_dav.
DAV, or Distributed Authoring and Versioning, makes it possible to create and modify files on a server, rather than just retrieve and read them. That is, DAV turns HTTP into a read-write protocol. DAV has been around for a number of years already, and mod_dav modules for Apache 1.x and 2.x have existed for some time. I am still using Apache 1.x on my main server, but it should be equally easy to install and use mod_dav for Apache 2.x.
To begin with, you need to download mod_dav (see the on-line Resources). Because I had compiled Apache with DSO (shared object) capabilities, I didn't have to recompile it from scratch in order to incorporate mod_dav. I merely had to tell it where to find apxs, the automatically generated Perl program that gives Apache modules all of the information they need in order to compile without the Apache source code. After unpacking the mod_dav source code, I typed:
Once done, I compiled and installed mod_dav:
make make install
I double-checked to make sure that my Apache configuration file, httpd.conf, was still intact after the modifications provided by make install. Following that, I configured Apache to include a new named virtual server, which I called davcal.lerner.co.il:
<VirtualHost 188.8.131.52> ServerName davcal.lerner.co.il ServerAdmin email@example.com # Directory and file names not beginning with / # are relative to ServerRoot ServerRoot /usr/local/apache/v-sites/davcal.lerner.co.il DocumentRoot www ErrorLog logs/error-log CustomLog logs/access-log combined CustomLog logs/referer-log referer DAVLockDB DAVLock <Directory /usr/local/apache/v-sites/davcal.lerner.co.il/www/> DAV On <Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> AuthName "Calendar DAV access" AuthType basic AuthUserFile passwd Require user calendar </Limit> </Directory> </VirtualHost>
Notice the DAV-specific directives in the above configuration section. I have set up where the DAV locking will reside with DAVLockDB, obviously outside of the HTTP-accessible DocumentRoot directory. I then turn DAV on for a particular directory and limit DAV access to the calendar user, with a password specified in an external file. That password file, which is also outside of the Web site's root directory, is created and updated with the standard htpasswd program, located by default in /usr/local/apache/bin.
Finally, notice that our <Limit> section specifies limits only for potentially dangerous requests. The standard HTTP GET request, by contrast, requires no user name or password. This is a good configuration if you want to let anyone subscribe to your calendar but give limited access for publishing and modifying the calendar file. If this calendar were going to be used in a business, you probably would want to limit access to it as well, perhaps by giving each user his or her own password.
We can publish this calendar by bringing up (once again) the Publish entire calendar dialog for a particular calendar. This time, we use an HTTP URL, without specifying a user name or password: http://davcal.lerner.co.il/calendar.ics.
This publishes the calendar to the site, as you can tell by looking at the appropriate directory on the server. You similarly can publish the calendar using WebDAV each time the calendar is updated, just as we saw before.
Finally, we can subscribe to this calendar using the same techniques that we have seen in previous months. Choose Subscribe to remote calendar from the File menu and enter the URL for this calendar file. Thanks to the magic of WebDAV, we even can use the same URL for writing and reading the file.
Although the open-source world might not have a fancy back-end calendar system like Microsoft Exchange, solutions exist that are more flexible and more than good enough for most groups.
I should note that Sunbird does appear to have some problems with publishing and subscribing; if nothing else, meetings that were listed as private on my Sunbird application continued to be marked in that way when the file was uploaded—and were then displayed as private when I subscribed to the calendar with a different program. Moreover, Sunbird continues to be slow when working with large calendars; however, that problem has been noted by the Sunbird developers and presumably will be fixed in the coming months.
There is also the promise of a new server for handling iCalendar files in Novell's Hula Project. Since Novell acquired both Ximian and SUSE, Hula is one of the most-hyped new projects to emerge from that combination. If Hula does indeed include iCalendar support, I will be curious to see how it improves on the FTP and WebDAV solutions I have outlined above. Until then, there are workable solutions that satisfy my own needs, as well as those of many other small organizations looking to collaborate with each other.
Resources for this article: /article/8323.
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!
- Stunnel Security for Oracle
- SourceClear Open
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Google's SwiftShader Released
- 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