Posts by DragonZX

  • php settings in control panel

    Quote from DZII


    Question about php settings in control panel if you increase the Upload Max Filesize,Post Max size,Memory Limit,Max Execution Time should you keep it off in php settings section of control panel so it can not be changed or should the settings in control panel allow a user to increase it up to max of what is set in php.ini


    I have it set to yes in the php settings section of control panel so they can be changed but it keeps telling me Value for the PHP post_max_size directive must be between 0 and 10. I have increased them in the php.ini and restarted server


    If you know you will need to increase theses should it be done in master before adding a user/domain


    What for? Master php.ini is just a template for others. You'll be able to change it for client in the panel, if you need or for each virtual host you need directly in php.ini.

  • не могу загрузить файл через ajaxplorer

    На тестовом сервере воспроизвести ошибку не удается.
    1. Попробуйте загрузить под другой учетной записью/другим доменом
    2. Каталог на FTP выставлен по умолчанию?
    3. Возможна ли загрузка через FTP-клиент (FileZilla/Total Commander/Far Manager)
    4. Попробуйте принудительно вручную обновить пакеты севера (apt-get update && apt-get upgrade)
    [hr]
    http://www.grandviewstudio.com…n.move-uploaded-file.html
    Но я не понимаю причем здесь папка tmp... Но действия выше все же нужны.

  • не могу загрузить файл через ajaxplorer

    1. Убедитесь что права на директорию выставлены верно (пользователь-владелец каталога совпадает с пользователем папки htdocs).
    2. Проверьте права на папку /var/www/imscp/gui/data/tmp (vu2000, 700)
    3. Если не помогает опишите, какие конкретно действия Вы совершали до этого.

  • PHP Compitibility plugin

    Quote from gOOvER


    Older CMS are also EOL :). If someone use joomla 1.0.x, i think he must handle this alone. ;)


    That's may be great, if it an corporative hosting with 20-40 sites.
    If it's over 100 or thousands?
    So it's not a security hole if: user choose himself to use 5,2 or 5,4 (just to change a binary)...
    If user use oldstable CMS, it's his problem of security, but I need to make an ability.
    As I understand, php makes a security hole for script, not an whole server... So it's enough to localise it for client.
    The reality in Asia is in the developers full of ego, developing on oldstable CMS or FoxPro, etc. Just they didn't know nothing else. It's an 60% of clients.
    The client is always right...

  • PHP Compitibility plugin

    Quote from gOOvER


    I'm against it. older php Versions are EOL and it's a big Security Issue.


    Agree with you, but it's the only way to support oldstable CMS (as I said, it's a plugin, so we must have an ability to enable and disable it). I didn't see another way.
    But I'll think about security. So, a lot of hostings are popular in case, that they are still using PHP 5.2... We need to find a compromise.
    So, it must be "as is" solution.

  • PHP Compitibility plugin

    As a problem:
    Some of clients has sites on Joomla 1.0 and old Drupal. We can't told them to update, then they just will be lost. So in that case, some of hosters uses Omega 1.0.6 and older.
    We may make a plugin with a custom choose of php, using custom packages, custom CGI configs...
    Just an idea. Because it's the greatest problem.

  • Как правильно писать тикеты

    Как правильно создать тикет на нашем багтрекере


    В течение нескольких месяцев, мы обнаруживаем тикеты, которые нам не удается понять. Хотелось бы привести пример правильно оформленного тикета, но сначала мы должны напомнить вам некотрые правила оформления, которым вы должны следовать при создании тикетов:


    • Когда Вы создаете тикет, у него должен быть понятен заголовок. Такие заголовки как "ошибка при установке" без какой-либо дополнительной информации не несет смысловой нагрузки и будет нами проигнорирован.
    • Вы должны указывать версию i-MSCP, которую Вы используете.
    • Вы должны предоставить нам информацию о Вашем дистрибутиве, его кодовое название, а также версию PHP, если вы сообщаете о баге, связанном с PHP. Также, Вы должны предоставить информацию о модуле Apache, который Вы используете (itk, fcgi..). Так же и для imap/pop сервера (courier, dovecot).
    • Вы должны указывать четкое описание проблемы, а также последовательность действий для её воспроизводства.
    • Если Вы уже исправили ошибку, Вы должны создать секцию под названием "Fix proposal" в Вашем тикете и, по возможности, прикрепить патч.
    • Вы должны пмсать текст тикета только на английском (доступном для понимания). Тикет только с заголовком и только ссылкой на наш форум будет отклонен. Также бесполезно писать тикеты со ссылками на темы, отличающихся от английских.
    • Вы должны указывать вставленный текст в скобках {{{ <PASTED TEXT> }}}


    [hr]


    Пример тикета:


    Заголовок:


    Bug - Unable to delete domain aliases when using shared mount point and HTTP redirection


    Тело:


    In some contexts (eg, when using a shared mount point and when the HTTP redirection is enabled), it's not possible to delete a domain alias.


    How to reproduce


    1. Create domain.com account
    2. Create alias1.com domain alias with mount point set to /xx/aa and HTTP redirection enabled
    3. Create alias2.com domain alias with mount point set to /xx/aa and HTTP redirection enabled
    4. Create alias3.com domain alias with mount point set to /xx/aa and HTTP redirection enabled


    Then, if now we try to delete one of those domain aliases, we are getting an error such as:


    Code
    1. cp cannot evaluate directory...


    The bug occurs because when we are using HTTP redirection, the mount point is not created and so, the cp command cannot evaluate an inexistent directory.


    Fixes proposal


    1. On backend side


    When deleting a domain alias, we must ensure the shared mount point exist before trying to save its content.


    2. On gui side


    If HTTP redirection is enabled, the mount point seems to be unneeded and the input field to define it should be hidden in the GUI to avoid such inconsistency. Of course, we must allow to edit the mount point when we are editing the domain alias and when the HTTP redirection of it is disabled.


    Note: This bug surely occurs with subdomains created in same way. Must be confirmed.


    Additional info:
    Distribution: Debian Squeeze
    PHP: 5.3