Posts by Kika

    hmm, you have right, i didn't think that the user want to upload files to other directories. I will try to create a new working version today which based on this things.

    Using paths as */htdocs will prevent users to delete/rename/move ... any folder named htdocs in any part of user directory tree even if is not related to a mount point. Imagine scenario:
    User do not know what to do with default folders but he do not want to remove then so he copy all folder in a folder named save. After he realize mistake, he want move folders back. He can not do that. He copy them back and the want to remove those folders. He can not.
    I think we can safe remove this protection, will not affect servers (just some warnings on apache restart). What you think about?

    I think that we need this protection. I tried what you wrote:

    1, i created a folder named htdocs within domain.tld/htdocs
    I can delete this because the rule for ~/htdocs/* give me right for this

    2, i created a folder named htdocs within domain.tld/subdomain/htdocs
    I could delete this too, but something wrong, because i could delete domain.tld/subdomain/htdocs too. I found the error. See this new conf please:

    So i revoke all access from users and now they can delete from error, htdocs, cgi-bin and from subdomains htdocs and cgi-bin. If they create folder named htdocs than they could delete that.

    Turning off DelayEngine and use fail2ban is a solution but I remember that for etch (or sarge?) regexp for proftpd was broken. Can / should we count on fail2ban for this?
    If yes should we provide own regexp for proftpd or use default?

    The regexp was incorrect in the old fail2ban 0.8.1, but the new is correct. The problem was only one character, the ":" was replaced by "-" in the log, but the new default regexp contains ":" and "-" too (my proftpd filter revision: 677).

    I hadn't time until now to view this problem, but it's not a new problem.

    When i try to login than the server wait about 17-20sec before i see the filelist. This is a little slow server (Genuine Intel(R) CPU 2160 @ 1.80GHz, 4GB RAM), but this time is very long.

    I disabled the DelayEngine, but the connection time seems too high too (12-15sec)

    I disabled the processing the imscp domain confs, and the connection time was only 1sec. I found 63 file in this directory, this is not too much, this is my smallest server.

    I created a new directory with only one domains.conf and after include that the connection time was 1-1,5sec.

    The solution step by step

    1. open /etc/proftpd/proftpd.conf

    In my conf this was the default settings but maybe you have other, so check this values:

    1. UseReverseDNS offIdentLookups off

    The default value of "DelayEngine" parameter is "on" because security reason! See . I disabled this because i think that my real users doesn't want to attack my server, and the fail2ban will ban IP addresses with too many wrong logins (

    In the last line of the proftpd.conf i edited the include path:

    1. Include /etc/proftpd/imscp2

    After this save and close the proftpd.conf.

    Create the new config directory /etc/proftpd/imscp2

    Save the next block into that directory as domain.conf.

    I found the "disabled" directory didn't exist in the default imscp conf, i inserted that into this conf without grant any permission for users.

    Restart the proftpd.

    I suggest new properties for domains:
    - register_globals (admin + reseller + user)
    - display_errors (admin + reseller + user)
    - disable_functions because exec function may need for some project (admin + reseller)
    - post_max_size (admin + reseller)
    - upload_max_filesize (admin + reseller)
    - global field for admin to add some lines to all php.ini (like zend optimizer, ioncube or others)[hr]
    + one-click function to recreate all config files after edit the imscp template ;)

    i upgraded with this script and it works perfectly.

    Thanks :)

    I have a suggestion: The upgrade script ask information from me instead of reading the imscp.conf. Maybe the reading the values from imscp.conf is more secure than ask the user ;)