ISPConfig 2.2.4 released
 

ISPConfig 2.2.4 is available for download.

This ISPConfig release introduces support for
SuPHP, chrooted SSH accounts, Spam white- and
blacklists, support for URIBL blacklists and a tool
for moving sites between clients.
The following packages were updated: ClamAV 0.88.3,
Spamassassin 3.1.3, mod_ssl 2.8.27-1.3.36,
Openssl 0.9.8b, Apache 1.3.36, and several
minor bugs were fixed.


Detailed Changelog
------------------

- Added: Support for suPHP.
- Added: Support for chrootSSH in shell accounts.
- Added: Added a tool to move a website from one customer
to another one.
- Added: New feature: Spam whitelist and blacklist.
- Added: New Feature: Webalizer statistics can now be turned on
or off for each web site individually.
- Added: Added URIBL blacklist support for SpamAssassin to
the user settings.
- Update: Apache 1.3.36
- Update: Spamassassin 3.1.3
- Update: mod_ssl 2.8.27-1.3.36
- Update: Openssl 0.9.8b
- Update: ClamAV 0.88.3
- Update: Enhanced Whois script.
- Update: Code cleanup. Path variables used in includes are
now defined as constants.
- Update: Disabled directory listings in the ISPConfig web site.
- Update: Added a message at the end of the installation process
telling users where to log in and how.
- Update: Changed the default document root for ISPConfig
websites from /home/www to each distribution's
suExec doc_root (e.g. /var/www for Debian, Ubuntu,
Fedora, CentOS, Mandriva, /srv/www for newer SuSE
versions, etc.)
- Update: Replaced old quota.rc.master procmail recipe with a
more reliable one.
- Update: Web interface: Added a block for changes to items
that are currently being updated (-> data consistency).
- Update: Changed the way root's crontab is created during
installation/update (to avoid problems with cron).
- Update: Block access to the recycle bins while the system
is being updated.
- Bugfix: Fixed: No error message when Duplicate Secondary
DNS records are entered.
- Bugfix: Fixed problem where proftpd said that address/port
... are already in use.
- Bugfix: Fixed email regular expression: email addresses can
now also begin with digits (0-9).
- Bugfix: Fixed bug where /root/ispconfig/scripts/shell/backup.php
tried to zip symlinks.
- Bugfix: Added missing images in the help area.
- Bugfix: Delete .vacation.cache if autoresponder message changes
or if autoresponder is turned on/off.
- Bugfix: Changed regular expression for domains.


Download
--------

http://www.ispconfig.org/downloads.htm

Forums
------

http://www.howtoforge.com/forums


Installation Instructions
-------------------------

Download the ISPConfig-2.2.4.tar.gz from sourceforge.net

http://prdownloads.sourceforge.net/i...ar.gz?download


Installation on the shell as root user:

tar xvfz ISPConfig-2.2.4.tar.gz
cd install_ispconfig
./setup

The installer automatically detects the installed ISPConfig version and performs an update.

I'm updating right now!

** update **

No problems for me with the update.. Thank you again team ISPconfig!

Same here :)

till,

Is there a reason why the ISPconfig team still did not fix the "Open DNS servers" warning/error?

(I've fixed the /root/ispconfig/isp/conf/named.conf.master again myself)

I can still get out of the users SSH dir and read a lot of stuff when SSH'ing with a test account :/

Personally I dont see a problem in this behaviour that is the default in many BIND and linux installations. Though if you dont like others to use your nameserver, you can change it iby modifying the BIND template as you already did.

Sure, first you will have to install a patched SSH daemon as chrooting is not supported by SSH by default.

See step 2 in this howto:
http://www.howtoforge.com/chrooted_ssh_howto_debian

Then you will have to enable it in ISPConfig in the file config.inc.php, set:

$go_info["server"]["ssh_chroot"] = 1;

The user account will be chrooted for every user with SSH enabled that you create or update.

Updated, no problems, look like everything is working normally.. Oh, i did have some cert error problem after update, so i recreated cert manually and its working now..

By updating/renewing the certificates in 2.2.4...is it correct to answer by not to encrypt them? I remember the HowTo told me so...

Yeah, leave it empty..