Hi there, I'm currently implementing a new hosting server setup so I will just give my two cents about my experience with ISPConfig. What is still buggy, what features would be cool etc. BUG "Something is wrong" with the "Max. Domain" setting, I believe. I often receive errors like the following when changing any information about a site (like traffic limit or something else). Even if the site only has 2 domains. (Which the textbox also said before). Note that I have also seen the number 6 instead of 13... FEATURE Wouldn't it be cool to relate the sites to the Hosting Plan that was initially selected when they were set up? Like that I could just say that some plan now has 10 more MB of space available and there would be no need for a mouseclick orgy across all sites. BUG Duplicate email aliases seem to be detected as they are not added. However there is no error message indicating that there was a duplicate. Not good. FEATURE It is not cool that I have to create a real user even if I only want an email forwarder. I would like to make a distinction between how many real users, forwarders etc. can be created. So much for today. Regards, ~jm
Has anyone else seen this behaviour? I've tested very carefully and have never realized such a behaviour... This is because ISPConfig creates real system users, not virtual users that are in a MySQL database.
Code: This website already has 13 domain(s). You cannot decrease the number of domains. Yes. i get this quite often. It appears to make any changes you have made without any problems, and then gives you the error. The number, in this case 13, is always equal to the number of users and nothing to do with domains. I haven't used any extra email aliases so can't comment, but will have a play later.
So here I am, back with more comments. If I click on a client, then choose to create a new site, it would be nice if the customer I came from was selected automatically. It is currently not possible to transfer a site between customers, sometimes that would be nicer than to have to backup, delete, re-create and restore the data. When I add a new site, the menu (tree structure) on the left is not reloaded automatically. When looking at a site without users, it is practically impossible to find out what the id is ("webXX"). Maybe one could just display that right to "ISP Site" in the right panel at the very top. Upon the deletion of an account the entire interface is reset and I have to click back to where I was... What if I would like to always add the same hosts to newly created domains. E.g. www, mail, .... Is there some location where I can put a "DNS template" or such? Although there is a "Max. number of domains" setting, it doesn't really do what it says, i.e. in fact it counts the hosts that have been set up for that site even if they are under the same domain. The manual may need to be revised in some places. For instance I only found out what Standard CGI really does by looking at the source... It is not possible to modify Bind options in named.conf since the whole config file is under control of ISPConfig and I cannot introduce a second options{} block at the very end (where it would be allowed). I would prefer to have an MX record per domain. E.g. mail.sld.tld where sld and tld are the respective second and top level domains of the site that I created. Right now (even if it was working) it seems like the hostname that was used to setup ISPConfig is used as the default MX. When using DNS Admin CNAME- and A-records for the same thing cannot be created. However, using the ISP Manager, that is very well possible. Resulting in a bind configuration that will only return SERVFAILs for the domains affected. It is cool, however somewhat annoying that ISPConfig even takes over network interface configuration (enables non-existent ones and, worse, disables interfaces not used by ISPConfig). This detail might be a candidate for an "expert" mode.
Ok forget the remark about the expert mode: $go_info["server"]["network_config"] in /home/admispconfig/ispconfig/lib/config.php seems to be the setting
By the way, it seems to me (I have no real proof or reason) that using a # in a password will make the password fail at some time. Maybe initially it is written correctly but then some cronjob which rewrites the passwords can't cope with it. I don't know.
Today, I have seen the following: after removing admin privileges from one user , adding a new user, and giving it admin privileges the webX directory looks like this: Code: drwxr-xr-x 10 web23_ftp web23 4096 2005-11-09 21:33 . drwxr-sr-x 64 root root 4096 2005-10-23 06:01 .. drwxrwxr-x 2 web23_ftp web23 4096 2005-10-03 03:59 cgi-bin -rw------- 1 web23_ftp web23 24 2005-11-09 21:33 .forward -rw-rw-r-- 1 root web23 28 2005-11-09 04:02 .htpasswd drwxr-xr-x 3 web23_ftp web23 4096 2005-11-02 00:30 log lrwxrwxrwx 1 root root 44 2005-11-09 21:33 Maildir -> /local/home/www/web23/user/web23_ftp/Maildir drwxrwxrwx 2 web23_ftp web23 4096 2005-10-03 03:59 phptmp -rw-r--r-- 1 root root 486 2005-11-09 21:33 .procmailrc drwx------ 2 web23_riviera web23 4096 2005-11-09 17:22 .spamassassin drwxr-xr-x 2 web23_ftp web23 4096 2005-10-03 03:59 ssl drwx------ 2 web23_riviera web23 4096 2005-11-09 17:22 tmp drwxr-xr-x 4 web23_ftp web23 4096 2005-11-09 17:36 user lrwxrwxrwx 1 root root 52 2005-11-09 21:33 .vacation.cache -> /local/home/www/web23/user/web23_ftp/.vacation.cache drwxr-xr-x 9 web23_ftp web23 4096 2005-10-16 20:28 web Now, web23_ftp is the admin user and web23_riviera is not. However there are still files belonging to web23_riviera (the old admin) in the root. :-(
Did you create the .spamassassin and the tmp folder manually? Because ISPConfig does not create such folders. Then it's ok that ISPConfig does not change the owners and permissions of these folders because it is possible that these folders need their current owners/permissions (because otherwise they might not work)...
Well I guess this is related to the fact that if I make a user the administrator of the site, its home directory becomes the root of the site. That's what the Maildir symlink into the user folder is there for I think, so the admin's mailbox will work. To make it all correct, once spamassassin has been activated for the (admin) user, one should also update the .spamassassin folder location correctly, or use a symlink like for the Maildir into the user/ folder...
But ISPConfig doesn't create a .spamassassin folder. It creates a .spamassassin script in /home/www/web<id>/user/<username> for each user.
well ispconfig creates the .spamassassin.rc script, that is true however spamassassin creates the .spamassassin folder upon execution in the user's home directory in order to store automatic whitelists etc.
What about sites which should not have mail but only web service? I have created one without MX records, however they are listed in the postfix configuration. Since we don't do the actual nameservice for these domains either, but only the hosting of the website, every time someone tries to send mail to one of those domains, they obviously fail. :-(
For this scenario ISPConfig has the external mailserver setting. Set the Mailserver in the settings for the website and for tzhe Co-Domain to external and your problem is solved.
I have also noticed strange behavior as far as the permissions are concerned (when switching admin users) on the tmp folder in the root of the site... i.e. it wasn't chown'ed to the new admin user or alike
custom procmail recipes like discussed here: http://www.howtoforge.com/forums/showthread.php?p=8372 (i hope someone is still enthusiastic about this features task
Hmm... wouldn't it be cool to symlink standard cgis from the webs into /root/ispconfig/... ? I know this could cause problems with the apache config (following symlinks) but I am just wondering what to do when I have a new version for a standard cgi... how do I update all webs with it? =-O
