Posts by mikerhyner

    Yes, panel is running well besides that problem.


    Because if I run the cronjob script maually, the log bind mounts are done, I guess that the @reboot cronjob will be started before mysql server(mariadb on my system to be exact, but shouldn't matter) is up & running.


    For the moment as a "dirty" hack, I've added a sleep before perl, so the line within /etc/cron.d/imscp looks like this:
    @reboot root sleep 30; perl /var/www/imscp/engine/tools/imscp-httpd-logs-mngr > /var/log/imscp/imscp-httpd-logs-mngr.log 2>&1

    OK thank. But I get an error message (cannot connect to database) as the cronjob kicks in within /var/log/imscp/imscp-httpd-logs-mngr.log:


    [^[[0;31mFATAL^[[0m] iMSCP::Bootstrapper::boot: Unable to connect to the SQL server: DBI connect('database=imscp;host=localhost;port=3306','root',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /var/www/imscp/engine/tools/../PerlLib/iMSCP/Database/mysql.pm line 102



    ql.pm line 102


    Where do you catch up the password for mysql root user?


    Possibly helpful, I've installed:
    - Debian 7.8
    - MariaDB 5.5
    - i-mscp 1.2.9

    Issue:
    When rebooting the i-mscp server, all the bind mounts providing log file access to the users to /var/www/virtual/<main_domain>/logs/<domain> are missing.
    That bind mounts are not added to "/etc/fstab" (in difference to the bind mounts of the CronJobs and InstantSSH Plugins), but interestingly, after a configuration change (or de-activating, then activating a domain), the mount commands will be executed... but obviously, I don't want to manually disable and enable every domain manually to get the bind mounts back!


    Expected Results:
    After a server reboot, all mounts are there again. Imho, this can be done trough:
    a) adding the mount commands to the fstab (can get huge, so probably not a really good idea)
    b) triggering the code part that executes the bind mount commands when the imscp_daemon is started


    Or do I miss something (e.g. startup script) so that doesn't happen?


    Version: 1.2.9, Build: 20150703, Codename: Andromeda


    Thank you for having a look on that...

    After an i-mscp upgrade, the file /etc/imscp/bind/parts/db.tpl will be overwritten. That's not such a huge problem, as I've written a script to replace the file after the update among other files getting overwritten.


    But now I have the problem, that during the upgrade, all DNS Zonefiles under /var/cache/bind/ will be rewritten based on the default "db.tpl" template. After changing back the template according our needs, we should have a quick method to re-write all DNS Zonefiles again, deriving from our (replaced) Zone template. Is there a possibility besides deactiviating and activiating every single user / domain (should be one of the steps conducted by the system when deactivating or activating a domain)?


    Unfortunatley, that doesn't work:
    http://blog.grufo.com/2010/11/…template-geaendert-wurde/
    (used imscp instead of ispcp of course!)


    Thank you very much for a short hint as it's very painful to fiddle with each single user within the GUI...