install

Event Calendar是一个在线事件日程

Installation shouldn't be too difficult, but it may take some tweaking to
get it to work.  The only outside requirements are postgresql, a web
server, php, and preferably SSL.  Authentication is done using user
accounts on the local system (/etc/shadow).  If you're reading this, then
you've probably untarred the source already, so starting from there:

1. Move the calendar and auth directories to some web-accessible place,
preferably with SSL access too.  Don't forget to change the uid of the 
files so your web server can read them.

$ mv calendar /var/www/
$ mv auth /var/www/
$ chown -R root:www-data /var/www/auth /var/www/calendar

2. Create two postgresql databases (I use srccalendar and auth) and input
the table schema (and some sample data) from the included sql-dumps.

$ createdb auth
$ createdb srccalendar
$ psql -f sql-dumps/auth.sql auth
$ psql -f sql-dumps/srccalendar.sql srccalendar

3. If you don't already have a postgres user, you'll need to create one,
possibly two, for calendar access.  (These are users in the postgresql
database, not unix users.)  Grant the appropriate access to the tables. I
give read-only access to guest and read-write to another user.  Nobody
needs to write to the location, category, weekday, or audience tables,
although the associated lists should be writeable for event creation.  No
one should be able to write to the permissions table in the auth db
either, that's not necessary. 

$ createuser guest
$ createuser foo
$ psql auth
auth=> grant select on last_login,permissions,session to guest;
auth=> grant select,insert,update,delete on last_login,session to foo;
auth=> grant select on permissions to foo;
auth=> \connect srccalendar
srccalendar=> grant select on srcaudience,srcaudiencelist,srccategory,
srccalendar-> srccategorylist,srcevent,srclocation,srcweekday,
srccalendar-> srcweekdaylist,srcindex to guest;
srccalendar=> grant select on srcaudience,srccategory,srcweekday,
srccalendar-> srclocation to foo;
srccalendar=> grant select,insert,update,delete on srcevent,srcindex,
srccalendar-> srcweekdaylist,srccategorylist,srcaudiencelist to foo;

4.  Edit calendar/sql/sql.php3 so the functions connect as the appropriate
users.

5.  Edit calendar/includes/config.inc to meet your needs.  You may also
want to edit header.inc and footer.inc to match your site's layout, 
although I would appreciate some sort of recognition to remain at the
bottom.

6.  Install the appropriate authentication utilities from the php-utils
directory.  There's a Makefile in php-utils to help with this.  By
default it installs things in /usr/local/php3/, but you can change this in
php-utils/auth-whatever/Makefile.  Current options for authentication are
shadow, PAM, and NIS.  shadow gets its information directly from
/etc/shadow.  PAM passes a username and password to PAM.  NIS currently
works the same as shadow, but contacts an NIS server for information.
Some of these things need to be setuid root, so you should su before
installing.  The Makefile also makes them executable only by root and
whatever group is specified in the Makefile (which should be the group of
your web server).

$ cd php-utils
$ su

# make auth-shadow	- OR -
# make auth-pam		- OR -
# make auth-nis

# make shadow-install	- OR -
# make pam-install	- OR -
# make nis-install

7.  Set up access for users to approve, modify, etc events in the
calendar.  This is done in the permissions table in the auth database.  A
given row in permissions will contain some user's unix user ID, a number
signifying permissions, and a location ID to which the given permissions
apply (or -1 if they apply to all locations).  For instance, to grant
access for user spaz (with unix user ID 42) to approve and modify his own
events, use the following statement in psql:

auth=>  insert into permissions ( user_id, location_id, permissions )
auth=>  values ( 42, -1, 17 );

A list of permissions is found in auth/permissions.php3.  Permissions are
combined using a bitwise OR.  Permissions to approve submitted
modifications use the Modify bits, *not* the Approve bits.  This is so, on
the off chance that you only want somebody able to approve but not modify
events, they can't submit a modification and then approve it.

If I'm leaving anything out, or if you need help, e-mail
[e-mail], and I'll see what I can do.  You can also check
the accompanying file "DESIGN" for some more information on how the
calendar works.