cgipaf is a combination of three cgi programs:
All programs use PAM for user authentication, systems without PAM are only supported if they use the standard password file location (/etc/passwd /etc/shadow) and standard crypt or md5 passwords. If a password is changed it is possible to run a script to update SAMBA passwords, NIS configuration, etc.
The mail configuration is done by procmail by default, mailcfg.cgi creates a .procmailrc in the user's home directory. If autoreply is enabled the autoreply message is stored in ~/vacations.txt. When a user enables mail forwarding the user can choose to keep the messages. If you want to use another auto responder like vacation you can define an external script to update the user's mail configuration. A perl script with vacation support is included see examples/ for an example config.
For the user authentication viewmailcfg.cgi creates a cookie, this cookie is stored in the accessdb. mailcfg.cgi reads the cookie out the accessdb and compares it with the cookie send by the users browser. Users with too many invalid logins can be locked. The minimum and maximum uid can be set in the configuration file, so you can specify a range of uid's that are allowed to use cgipaf. CGIpaf has access control lists support this allow you to deny or allow access to groups or users.
You can specify html files with a few PHP extensions for the login screen and error messages. It's possible to use a redirect for the error messages, instead of plain html files.
The CGIpaf cgi's are suid root programs, this means they run as root. Viewmailcfg.cgi and mailcfg.cgi runs as the user when the authentication is completed. All suid programs are a security risk, I try to keep them so secure as possible...
If you use CGIpaf on the internet you must use CGIpaf over https otherwise the users passwords are send unencrypted over the internet.
I finally got a stable place for my homepage ( http://staf.patat.org ).
thanks to "de pirre" for hosting my site.
The current locations are:
Has a problem when you try to download the debian package with apt-get, because they add an ad to the Package file. Please use the main site http://staf.patat.org/debian/ to download the debian package with apt-get.
The last one is hosted by my current employer, we're in the middle of a reorganization (again :-(.
Due the current economical situation I'm not sure my employer will continue to provide free webspace.
... or will continue to pay me.
If you're unable to access the website check http://freshmeat.net/projects/cgipaf for the correct location.
http://groups.yahoo.com/group/cgipaf/
Post message | cgipaf@yahoogroups.com |
Subscribe: | cgipaf-subscribe@yahoogroups.com |
Unsubscribe: | cgipaf-unsubscribe@yahoogroups.com |
List owner: | cgipaf-owner@yahoogroups.com |
Please post your questions / install problems to the mailinglist. I usually read my private email at the evening after my work but I follow the mailinglist during the workday, so you'll get the answer faster in the mailinglist. Your problem can be useful to the other CGIpaf users...
CGIpaf is Free software published under the GNU General Public License. see http://www.gnu.org/licenses/gpl.html for more information.
CGIpaf should compile and run on most GNU/Linux distributions. Slackware is only supported if you compile CGIpaf without PAM support since Slackware doesn't support PAM. Both passwd types (standard crypt, md5) are supported on a non-PAM system. Blowfish and others aren't supported.
CGIpaf works on Solaris ( only tested on solaris 8 )
There is a problem with CGIpaf with PAM on solaris 9 - I didn't had the time to debug it -
FreeBSD is supported, add --host=freebsd to ./configure this will compile CGIpaf with FreeBSD support but without PAM support.
NetBSD is supported in development release see http://staf.patat.org/cgipaf/develop/ for more information.
Unfortunately OpenBSD isn't supported (yet). I hope to start a port some day.
CGIpaf might work on other Un*ces with pam support. Systems without pam support are only supported if they use the standard password file location /etc/passwd /etc/shadow and standard crypt or md5 passwords.
CGIpaf uses only standard libraries that are installed on most common Un*x installations, you need the development packages ( headers files etc ) to compile CGIpaf.
List of required libraries:
No! CGIpaf only emulate a few PHP functions ( include and echo ) in his html files.
If you need full PHP support you've to use a redirect.
CGIpaf depends on ndbm or compatible library, you need the development files to compile it. If ndbm and
the development files aren't installed on your system install them, look for a gdbm or ndbm package
If ndbm isn't installed on standard location on your system ( e.g. /opt ) try to create symbolic links:
ln -s /opt/lib/libndbm.so /usr/lib/libndbm.so ln -s /opt/include/db1/ndbm.h /usr/include/ndbm.h
and rerun ./configure
To compile CGIpaf with PAM support you need the PAM development files, which aren't install on every default installation. Look for a package with a name like *libpam-dev and install it. ( Type apt-get install libpam0g-dev on a Debian GNU/Linux system )
To compile cgipaf with cracklib support you need the libcrack development files... If you've a system with PAM support try to enable cracklib support through PAM (see below).
On a non-PAM system set "cracklib" to "on" and "cracklib_dictpath" you your
cracklib dict path.
The cracklib_dictpath is the path to the dictionary filename without the extension ( .pwi ), not the
directory path.
The correct_dictpath on Debian ( potato and woody ) is /var/cache/cracklib/cracklib_dict, on RedHat 6.2
you'll have to use /usr/lib/cracklib_dict.
On a non-pam system cgipaf uses a lock file in /var/lock if this directory doesn't exists on your system passwd.cgi will end with "Can't create lockfile" error. Create /var/lock or update pam.h to your own needs.
Yes, passwd.cgi doesn't support SAMBA passwords directly but you can use a "run_success" script.
run_success "/usr/sbin/smbpasswd -U %{name} > /dev/null 2>&1" "%{password}\n%{password}\n"
CGIpaf doesn't support NIS directly, but it's possible to update the NIS password on the master NIS server and run pwupdate (8) through run_success
run_success "/usr/lib/yp/pwupdate > /dev/null 2>&1"
CGIpaf should support ldap through PAM, although I didn't had the time to test it...
This can have several reasons...
If you've enabled cracklib in cgipaf and the cracklib_dictpath to a invalid location passwd.cgi will end with a internal server and an error message in your webserver error log. Try to disable cracklib if this resolves the problem see "How do I enable cracklib password testing".
Another reason is possible BUG or misconfiguration in cgipaf, the error_log of your webserver and the syslog messages ( set loglovel to 7 ) should give more information.
Set the loglevel to 7 in cgipaf.conf, this will send debug messages to your system's syslog
CGIpaf supports PAM and standard Un*x password files ( /etc/passwd /etc/shadow ).
BSD uses different passwd locations. On a Net|FreeBSD system /etc/passwd_master is updated and copied
to pwdb by the pw_mkdb command.
OpenBSD isn't (yet) supported...
On a pam system: CGIpaf needs "auth" and "account" entries in his PAM configuration. If you don't set the pam_service directive CGIpaf uses the "passwd" service name. The passwd pam service ( /etc/pam.d/passwd ) usually doesn't have an entry for user authentication, therefor /etc/pam.d/other has to have a line auth set to pam_unix.so.
auth required pam_unix.so
account required pam_unix.so
If you don't like this for security reason etc, you can set the pam_service directive to "cgipaf" and create
the file /etc/pam.d/cgipaf that looks like this
auth required pam_unix.so
account required pam_unix.so
password required pam_unix.so md5
Or better copy your system passwd configuration and add the lines for "auth" and "account".
On a PAM system: CGIpaf should support password testing trough PAM. Enable cracklib support in your PAM configuration.
On a non pam system you've to set the cracklib directive to "on" and cracklib_dictpath to you system's cracklib dictpath.
CGIpaf deletes or replaces the user's ~/.procmailrc after a user has updated his mail configuration.
It's possible to copy the your .procmailrc and restore it when autoreply and mailforwarding is disabled
by the run_before_mailcfg and run_after_mailcfg directives.
Another alternative is to use .forward/vacation instead of procmail see examples/ for more information.
The user's .forward is deleted after a mail configuration update. If you don't like this you can disable the internal mail configuration and use your own run_mailcfg script. See examples/ for perl example with vacation support.
CGIpaf uses "/cgi-bin" in his action fields, if you use another cgi-bin location eg ( /cgi-bin/cgipaf ) you have to update:
Basically CGIpaf is web interface to configure procmail, so you need a mailserver with procmail support. Check the documentation of you mailserver howto enable procmail.
Yes! You can modify the php file that come with the installation of cgipaf. Please note that
CGIpaf doesn't have full PHP support it only emulates two PHP function (echo and include).
If you need full PHP support or what to use another web scripting language you've to use a Redirect.
e.g.:
msg_success redirect http://your_webserver/pwchanged.php?name="%{name}"
Will redirect to http://your_webserver/pwchanged.php?name="loginname" after a user has succeed to update his password.
Yes! You can disable the internal .procmailrc updater of CGIpaf and define an external script to update the user's mail configuration. See examples/ for a vacation example.
You'll have to update mailcfg_login.php, the default maxlength for the password field is 16 If you need to support longer passwords update mailcfg_login.php
<td><input name="passwd" type="password" size="8" maxlength="16"></td>
^^^^^^^^^^^^^^
CGIpaf started as GNU/Linux project I needed to create site that allowed users to update their mailconfiguration. I have added solaris support because we it at my work and I was tired to explain users how they've to update their Un*x password.
I've added slackware 8.0, FreeBSD and NetBSD support because some users requested a port to these platforms. I hoped that I could reuse the BSD code for the OpenBSD port, but the odds were against me. The BSD port doesn't works without trouble on OpenBSD versions.
I still want to support FreeBSD with PAM enabled ( the non-pam code works fine, but PAM is more flexible ) the authentication works but the PAM password changer doesn't -weird-.
The OpenBSD port is still in the pipeline.