ISPConfig 3.0.5 Beta 1 released for testing

Hi Till,

maybe i have one litte bug with my Nginx/Postfix/Dovecot 2 / PHP Version 5.4.4.7 - Debian 7 installation , ca you hav a look pls. thx

Code:

PHP Warning: htmlentities() expects parameter 1 to be string, array given in /usr/local/ispconfig/server/mods-available/monitor_core_module.inc.php on line 707

Have a nice evening

 

Hello,
I have maybe one little bug.
If you one client installs 2 apps over apps installer, and after one of them remove over button delete app , this action destroy both apps.

tested on Debian 6, ISPConfig 3.0.5 Beta 1

thanks for great work!
Petr

EDIT:
Sorry, all look OK, because the problem is only when they are both apps in one VirtualHost (eg domain.ltd/web1, domain.ltd/web2 )

 

Hello, new ispconfig look good. I am on SVN last month.

I have few notes:

Databases:
Separating DBs and DB users is fine, but you should add option to create user with same name as DB in DB add form. Because now I have to go create user in one form and next create db.

Apache plugin:
I use apache and nginx as reverse proxy. I have to change every time port 80 to 82 in apache-plugin.php. Will be good, if You add some option to define default ports. Method with creating custom VHOST template is working, but it isnt clean, because in apache-plugin is code, which checking if apache is running, but if apache runs on :82 script is think that apache is stoped:

Code:

//* Test if apache starts with the new configuration file
$apache_online_status_before_restart = $this->_checkTcp('localhost',82);
...
//* Check if apache restarted successfully if it was online before
$apache_online_status_after_restart = $this->_checkTcp('localhost',82);

 

ubuntu 12.04 LTS(nginx, BIND, Dovecot, ISPConfig 3)

show mailwarn-log:

Code:

Unable to read /var/log/mail.warn

show ispc cron-log：

Code:

PHP Warning: file_put_contents(/var/www/clients/client1/web1/.htpasswd_stats): failed to open stream: Permission denied in /usr/local/ispconfig/server/lib/classes/system.inc.php on line 667

Debian 6 （nginx, BIND, Dovecot, ISPConfig 3）

show Mail Error-Log :

Code:

Nov 3 19:03:50 server2 postfix/smtpd[2391]: fatal: no SASL authentication mechanisms

show ispc cron-log：

Code:

PHP Notice: date_default_timezone_set(): Timezone ID '/PRC' is invalid in /usr/local/ispconfig/server/lib/app.inc.php on line 32

Virtual host on vSphere ESXi

 

I dont know if it was "my fault"/ my system but the installer did not create the sql table "directive_snippets" in the db -> error in the websites module.

 

It was a clean functioning 3.0.4.6 updated to 3.0.5 Beta 1 via cmd

 

The update did not process the /tmp/ispconfig3_install/install/sql/incremental/upd_0040.sql !
Thereby not adding the table. Might be the position to fix it.

 

no errors in the cmd: https://gist.github.com/4016544

 

And you never did a SVN update on this installation before? There was an issue that the upd_0040 file was modified in svn so if an svn installation was done between 08/22 and 09/06 the upd_0040 was already processed and is not reprocessed on later updates - so the changes (new snippets table) are not applied.

 

possible that I am mistaking.
where is the current sql state saved? i have the backup of the upgrade to look at. but where to look?

 

Have a look in the database "server" table in column "dbversion".

 

you are totally right: My fault. dbversion = 40 -> SVN version

My old version was not the stable release 4.0.4.6, sorry-

 

Am not sure if this is how it should function or its a bug ...

Basically deleting a database user with API using the command sites_database_user_delete($database_user_id) deletes the db user from the corresponding database server defined in ISPConfig, but it does not delete the db user in the Master ISPConfig database.

Lets say:

My Master is Server #1
My DB Server is Server #2

It deletes the db user in Server#2 but it does not in Server #1

Is this how it should function Till?

 

Till while in the creation of a domain name via API, I do set the following:

[.....]
'stats_password' => 'my_password',
'stats_type' => 'awstats',
[.....]

Expecting that Stats will be enabled automatically. Unfortunately, they are NOT. I have again to login to control panel to enable them. Is this how it functions or something missing?

NB: The /var/www/clients/client30/web49/web/stats/.htpasswd_stats wouldn't be created through API not until enabled through ISPConfig Panel.

 

Correct me if am wrong, otherwise noticed the following:

On the interface, under FTP accounts -> Options -> we are given "Uploadratio" and "Downloadratio" in MB. I think it should not be MB but in bytes.

I hit this snag when I couldnt download or upload anything above 100 bytes and yet I thought I had assigned 100MB upload / download ratio as indicated in Interface.