The Good: On the panel server I can still create a new website through the ISPConfig console as normal. Using an NGINX (release 9) webserver with php-fpm and the option to use a socket - it creates the php5/fpm/pool.d *.conf file and corresponding nginx/sites-available *.vhost as expected, with the two tied together through their reference of a /var/lib/php5-fpm/*.sock The Bad: On a dedicated server for websites in the ISPConfig multi-server cluster, using the same options as above, this no longer happens. What I get is NO /etc/nginx/sites-*/*.vhost file created AND a /etc/php5/fpm/pool.d/*.conf for the website BUT no longer using a socket; instead, I get: Code: listen = 127.0.0.1:**** listen.allowed_clients = 127.0.0.1 How would I look into solving this? Possible Scenario I recently upgraded all my ISPConfig3 servers in the cluster to 3.0.5.4p9. At the same time (possible just before) I upgraded the NGINX webserver on this troubled server that I am having problems with. I had to blow out the old NGINX configurations (purged) and then I reinstalled them. I noticed that the new NGINX server did not come with the sites-available / sites-enabled pair of directories and instead was wanting to use a simple conf.d daemon directory which it referenced with an include statement from within /etc/nginx/nginx.conf Unsure of how ISPConfig would be able to deal with missing sites-* directories (and having since tested and failed without them) I put them in manually. Existing sites ran fine, but the above problem now exists on any attempt to build new sites - and old sites get damaged if/when the ISPConfig3 panel is pushed to rebuild the files in those directories. Any guidance would be appreciated.
Use the debug mode: http://www.faqforge.com/linux/debugging-ispconfig-3-server-actions-in-case-of-a-failure/ to find out why ispconfig can not write the config anymore.
Thanks, Till. Somehow the 'system > server config > web > server type' got switched to apache - hence the failure. What is the method to change it back to nginx? I do not see an input for this, is it a database setting? EDIT: In mysql DB of the damaged webserver 'table[server] > column[config] there is a blob with the line 'server_type=apache' . I figure that has to be it. The panel server listing for this damaged server still shows it as an nginx server though. Just an FYI. Not sure how that happened. Fixing it now. Thanks for the help. EDIT2: Ooos, no, I was wrong. The panel server does have references to it being an apache server. And the blob text has some configurations for apache in it as well. I'm futzing with it now (looking at how a good working nginx server is referenced). I'm not against a life preserver if you throw it!
Yes, it's a database setting, there is a config text field in the "server" database table, edit it with phpmyadmin, the config in that field is in ini format, change the value to "nginx".
I changed the 'server_type' value back to nginx both in the panel and the damaged webserver, but the problem still comes down to this: Code: The nginx plugin cannot be used together with the apache2 plugin. So I did a diff of the server > config text (between the panel and damaged webserver) and the only line I saw that might be contributing to the system still wanting to use 'apache2' was 'fastcgi_config_syntax' which I change from 1 to 2 - thinking that might be telling which directives (apache2 / nginx) to use since you have directives for both servers in that one config text blob. >> No good. I reset that back to the original value. I can still build new websites in the panel server. I have tried: rebooting the panel server with the new 'server_type' value of nginx logging out/in the panel server rebooting the damaged webserver with the updated 'server_type' value of nginx Same problem exists. Not sure why ISPConfig ever made changes towards an Apache server - none of my servers in the ISPConfig cluster have Apache2 installed. Appreciate any more help on the matter.
I can run websites on the damaged webserver by putting the proper config files (php5, nginx) in place - essentially copying them over from the panel server or rebuilding them manually. Therefore, I know the 'damage' on the damaged server is only in how ISPConfig3 is building new sites - essentially believing that the webserver is an apache server and not nginx. The server.table.config blob .ini settings have both apache and nginx settings in them. While the 'server_type' has been reset to nginx, ISPConfig still treats it like an apache server. What other setting is in play for ISPConfig3 to make the determination that a webserver is either nginx or apache?
SOLUTION: There is an 'apache2_plugin.inc.php' that 'is_link' checked which throws the error (mentioned above) if it exists. Removing that link solved my problem (along with - probably - the solutions taken above). For me, the link was located on the 'damaged' (slave) server at /usr/local/ispconfig/server/plugins-enabled/apache2_plugin.inc.php. The check which threw the errror (above) was at /usr/local/ispconfig/server/plugins-available/nginx_plugin.inc.php as it's presence halted the nginx routine that was about to execute. I could not find a function that would check and install that symlink for apache2 - which seems really weird to me. Perhaps an install script(?), but how did it get installed while I was reloading nginx? FWIW: I found an old /etc/apache2 config directory that never got purged from my system. Perhaps there is an ISPConfig3 check for that presence which brought about the symlink? Thanks Till
