Need help with ISPConfig 3 Update

[midcarolina]

Does anyone know how I can correct the update of ISPConfig 3.0.3.3 to 3.0.4 I still can't log into the CPanel. It wasn't coming up at all, now it will at least display. Running the update again doesn't work. Returns a hostname not found error every time. This is the ispconfig log at the time of original update.
Also, the mail systems for all websites are down. All mail stays stuck in the clientmqueue.


WARNING - DB::connect()-> mysql_select_db MySQL server has gone away
31.10.2011-13:57 - WARNING - DB::connect()-> mysql_select_db MySQL server has gone away
31.10.2011-13:57 - WARNING - DB::connect()-> mysql_select_db MySQL server has gone away
31.10.2011-13:57 - WARNING - DB::connect()-> mysql_select_db MySQL server has gone away
31.10.2011-13:57 - WARNING - DB::connect()-> mysql_select_db MySQL server has gone away
31.10.2011-13:57 - WARNING - DB::connect()-> mysql_select_db MySQL server has gone away
31.10.2011-13:57 - WARNING - DB::connect()-> mysql_select_db MySQL server has gone away
31.10.2011-13:57 - WARNING - DB::connect()-> mysql_select_db MySQL server has gone away
31.10.2011-13:57 - WARNING - DB::connect()-> mysql_select_db MySQL server has gone away
31.10.2011-13:57 - WARNING - DB::connect()-> mysql_select_db MySQL server has gone away

[till]

The mysql server seems to be stopped. Start it with:

/etc/init.d/mysql start

[midcarolina]

No, this ispconfig error log occurred at exactly the same time I did the upgrade. There are about 40 websites on this server and they all run just fine. I just can't log into the CPanel. It is not linked to the database anymore or something. I've tried everything. The password can't be reset through mail because that is down too. Terrible. I've tried to do an update a dozen times and always get the error that the host cannot be found.

[HermannS]

@midcarolina
i had similar problems after a upgrade yesterday from 3.0.3.3 to 3.0.4. After doing the upgrade via ISPconfig Websystem, i had no access. I did research many things, because users don't get mail and also ftp and sasl don't work anymore.

in short: many files had 0 byte size and it was not so easy to find them
thanks god there was sometimes a copy with attached tilde symbol.
Look at the following files and restore them if necessary:

/usr/local/ispconfig/interface/lib/config.inc.php (restored from /tmp/ispcon...)

/usr/local/ispconfig/server/lib/config.inc.php
(same as above, written in a thread and modified the dbispconfig user and password and db name at line 66, using the dbispconfig user and a 32 char password)

/usr/local/ispconfig/server/lib/mysql_clientdb.conf (root mysql db account, restored also from /tmp/ispcon...)

/tmp/ispconfig3_install/install/lib/update.lib.php
(change line 127 to
$conf['postfix']['vmail_mailbox_base'] = '/var/vmail';
<- hard link to vmail inserted because otherwise it breaks the update
------ these files are for redoing the update with php -q update.php-----

after doing the update again it runs through and the webgui starts again but some services doesn't run. i found the following as 0 byte files.

/etc/postfix/sasl/smtp.conf
/etc/default/saslauthd
/etc/mydns.conf (mydns don't run)
/etc/vlogger-dbi.conf
i simply copied the copy in the same dir over it.

in /etc/postfix/.header_checks, body_checks, nested_header_checks 0 bytes doesn't matter.
check also /etc/apache2/sites-available/ispconfig* files and 0 byte files

now all services runs and also the WebGui, but no changes in guy can be done because they all remain endless in the job queue. The server.sh script runs every minute and reports nothing to do. Log doesn't show anything. mysql database is repaired and i deleted many old entries in sys_datalog and sys_remoteaction.
@till: can you give a hint?

the status page shows not 3.0.4 but the old 3.0.3.3 and not status pages or protocols are refreshed since yesterday morning.

But thumbs up for ispconfig and the developers.


i listed changes with
>ls -latr in reverse time order to evaluate what changed

[till]

@till: can you give a hint?

The problem is most likely caused by this "... and i deleted many old entries in sys_datalog and sys_remoteaction. ...". The sys_datalog contains all changes of the last 30 days, these changes should not be deleted manually or the system is not able to find the last change and will stop the processing of changes.

You can reset the process queue by changing the value of the field "updated" in the server table to 0.

[till]

@HermannS: Maybe you can give me a hint of what might have caused this problem on your server. Have you disabled any php functions in php.ini or did you do any other changes which might cause php to fail to write files? I tested the update many times and I'am not able to get it to fail in a way that 0Byte files get written by PHP.

Which tutorial did you use to install your server and have you modified any config files after the initial setup?

[HermannS]

Originally Posted by till

@HermannS: Maybe you can give me a hint of what might have caused this problem on your server. Have you disabled any php functions in php.ini or did you do any other changes which might cause php to fail to write files? I tested the update many times and I'am not able to get it to fail in a way that 0Byte files get written by PHP.

Which tutorial did you use to install your server and have you modified any config files after the initial setup?

thanks, i wrote 0 in the server at updates, the system protocol shows my change but the job queue remains undone.
also the Übersicht anzeigen show the old status info and on klick to more information the link disappears but nothin' happens.


i installed the official debian tutorial, all worked then perfect.

for security reasons i disabled in php.ini a lot of functions because i had some unwanted visitors (c99_):
disable_functions ="symlink,shell_exec,exec,proc_close,proc_open,pop en,system,dl,passthru,escapeshellarg,escapeshellcm d,myshellexec,c99_buff_prepare,c99_sess_put,fpasst hru"

i think the shell_exec, or exec causes the failure.

[till]

also the Übersicht anzeigen show the old status info and on klick to more information the link disappears but nothin' happens.

Thats something different, its just a broken more link. See here:

http://bugtracker.ispconfig.org/inde...s&task_id=1834

for security reasons i disabled in php.ini a lot of functions because i had some unwanted visitors (c99_):
disable_functions ="symlink,shell_exec,exec,proc_close,proc_open, pop en,system,dl,passthru,escapeshellarg,escapeshellcm d,myshellexec,c99_buff_prepare,c99_sess_put,fpasst hru"

i think the shell_exec, or exec causes the failure.

Ok, that explains the problem. ISPConfig can not work if you disabled these functions for cli scripts. Disabling these functions will also stop the server part and jobqueue processing, or at least they will not result in a usable configuration.

Debian has 3 different php.ini files, you can disable these functions safely in the apache2/php.ini and the cgi/php.ini, but dont disable any functions in the cli/php.ini as nearly all functions you blacklisted are required. By the way, disabling shell functions for shell scripts does not make sense anyway, as the cli php.ini is for shell scripts like the ispconfig server and update scripts only.

[HermannS]

Originally Posted by till

Thats something different, its just a broken more link.
ISPConfig uses 3 different php.ini files, you can disable these functions safely in the apache2/php.ini and the cgi/php.ini, but dont disable any functions in the cli/php.ini as nearly all functions you blacklisted are required. By the way, disabling shell functions for shell scripts does not make sense anyway, as the cli php.ini is for shell scripts like the ispconfig server and update scripts only.

the problem is most of the time between keyboard an chair.
ok, but i modified only apache2/php.ini but not cli/php.ini

so when the update runs through the webgui the apache2 php.ini is used, right?
The manual update "php -q update.php" did run because it ruses /cli/php.ini

but does this explain not why the cron job (cli?) doesn't find any changes, may be there is a permission clue?

and i did not understand the "update=1" in server.php because in table server is no field named "update". so the result is no true...

$server_db_record = $app->db->queryOneRecord("SELECT * FROM server WHERE update = 1 AND server_id = ".$conf['server_id']);

i found no cgi/php.ini on my server.

[till]

so when the update runs through the webgui the apache2 php.ini is used, right?

No. The gui sets just a flag in the mysql database and the update is run trough cli. The gui has no permissions to alter any config files on the server, so it can not install a update.

So if you did not modify the cli php.ini, then the problem must be related to something else, or your php binary uses the apache php.ini. Did you install the php binaries from debian or did you get them from another source like dotdeb?

I'am a bit astonished that you dont have a cgi php.ini, as thats present on all of my Debian systems which are installed as described in the perfect setup guide.

$server_db_record = $app->db->queryOneRecord("SELECT * FROM server WHERE update = 1 AND server_id = ".$conf['server_id']);

This code is not used, its commented out.