Posts by claude79

    Hi DragonZX, thanks for your answer.

    I cannot use imscp-autoinstall, so I need to use your second option.
    I cannot find anything to synchronise in /etc/imscp/imscp.conf. The only password related to mysql I found is the root password, which I think is not what i'm looking for.
    Is this bug related to $cfg['Servers'][$i]['controluser'] = 'pma_user'; and password ?

    could you please be a little more precise about how I should synchronise those files ? Thanks a lot for your help.


    Using i-MSCP 1.2.17
    Build: 20160312

    I cannot login using phpmyadmin autologin from admin panel.
    Credits are OK, I can login without problem using /pma URL, but when I click on "phpmyadmin" button, I get this error message: "An error occurred during authentication."

    Which logs should I check to resolve this ? Thanks, Claude.

    for some reason, the plugin is not working with URL jobs (it's working fine with shell jobs).
    when I create a new cron job for my users, it just goes back to "Vue d'ensemble" page, without any error message. If I go back to the cron jobs page, it shows nothing "Rien a été trouvé - Désolé". Of course I get no emails.

    plugin version 1.1.0
    i-MSCP 1.1.22
    Build: 20150206
    Codename: Eagle
    Linux debian wheezy

    the logfile "Plugin_module_CronJobs.log" is empty. I tried to install the instantssh plugin, but it doesn't help.
    thanks for help, regards, Claude.

    EDIT: i found this in my syslog, not sure if it's related:

    Apr 16 17:23:01 XX /usr/sbin/cron[3775]: (*system*imscp) RELOAD (/etc/cron.d/imscp)
    Apr 16 17:23:01 XX cron[3775]: Error: bad username; while reading /etc/cron.d/imscp
    Apr 16 17:23:01 XX /usr/sbin/cron[3775]: (*system*imscp) ERROR (Syntax error, this crontab file will be ignored)

    EDIT2: looks like these messages are not related to this bug. looks like I found a second problem :-)

    EDIT3: OK, I found the bug. this line is wrong in file /etc/cron.d/imscp:
    @daily * * * root /var/www/imscp/engine/backup/imscp-backup-all yes &>/var/log/imscp/imscp-backup-all-mngr.log
    should remove the stars...

    The problem with the crontab plugin remains...


    I'm using i-MSCP 1.1.1 with default Pydio Version 5.2.0 - 2014-01-21. I'm not able to update this setup, so updating is not a solution for me.

    Sometimes (about 1/10), I encounter a bug when I use Pydio: after I login, it "freezes" (the four little squares are still moving) for 5-10 seconds. When I'm lucky, I finally can access the directories and everything is fine, but sometimes it doesn't even show the directory structure and I have to login again to access the files.

    Here is what's in pydio logs:


    06-02-14 16:34:43 XXX.XXX.XXX.XXX ERROR class.ftpAccessWrapper.php error l.321 message=ftp_chdir(): Commande CWD exécutée avec succès

    This message is quite strange: it's an ERROR message, saying that some command (CWD) actually succeed...

    I don't see anything in proftpd logs.

    I've searched the web, and it seems like there is a bug with FTP layer in PHP. I don't know if my issue is related to this: (see here for example: or here:…ss-message-with-ftp-chdir)

    thanks for your hep, regards, Julien

    J'ai trouvé un comportement étrange dans l'interface d'administration des revendeurs, cela me semble un bug:

    Lors de l'édition (comme revendeur) d'un utilisateur, il n'est pas possible de renvoyer les données de connexion sans régénérer le mot de passe.
    Par exemple, si l'utilisateur a perdu ses données de connexion, ou qu'il souhaite les recevoir sur un autre email, si on clique sur "Envoyer les nouvelles données d'authentification" puis "mise à jour", l'email ne sera pas envoyé si les cases "mot de passe" et "confirmation du mot de passe" ne sont pas régénérées. Aucun message d'erreur n'est affiché.

    Par exemple, cela empêche que l'administrateur puisse s'envoyer à lui-même les coordonnées d'un utilisateur (par exemple pour l'aider si celui n'arrive pas à se connecter). Cela oblige à régénérer à chaque fois un nouveau mot de passe, ce qui n'est pas souhaitable.

    bug trouvé dans la version :
    i-MSCP 1.1.1Build: 20140216Codename: Eagle

    Well, after some more research, it looks like opendkim is actually DNSSEC-ready
    I tried to validate some email I sent from GMail, and the warning was still there...
    BUT it looks like gmail is NOT using DNSSEC, so the problem is not on my side.

    Some more testing is needed (trying to find a DNSSEC-enabled free email provider to do the tests...)


    When trying to validate DKIM key, the plugin will allways warn "insecure key", even if the key is validated correctly.
    That's because the key has not been received with DNSSEC, and so it is "insecure".

    To resolve this issue, one must add "TrustAnchorFile" configuration to /etc/opendkim.conf

    Unfortunately, it seems like opendkim has not been compiled/configured with ubound (--with-unbound), so it cannot resolve DNSSEC and the warning will not go away.

    May I suggest that next version of the plugin adresses this issue ? As a bonus, it would be awsome to be able to actually SIGN emails with openDKIM when using a signed dns zone for the domain (DNSSEC is not implemented within I-MSCP, but it's possible to make it work with a little bit of configuration...)

    Thanks, Julien