Revert to earlier version

Discussion in 'Installation/Configuration' started by alisoncc, Aug 1, 2013.

  1. alisoncc

    alisoncc New Member


    tend to be more of a Drupal developer than a Sysadmin. A year or so back I built two Centos 6.x servers using the "Perfect Server" process. One is a Drupal development machine and the other is a low traffic production system. Both are essentially single user systems - myself. Regularly log in as root. Used the "Perfect Server" setup as it manages Postfix, Dovecot, RKHunter, etc. etc.

    Everything was working just fine, Drush (Drupal shell) archive and restores, Awstats, PhpMyAdmin, etc. etc. Then I upgraded to the lastest version of ISPConfig, and it has proven to be a disaster. So much has fallen over with the new security directory implementations it's unbelievable. I could easily migrate Drupal sites from development to production. For instance Drush archive-restore deletes the web directory and rebuilds it. No longer works. Tried things like chattr -i, etc. etc. without success. Awstats has also stopped updating, etc.

    So my question is "Is it feasible to revert to an earlier version of ISPConfig without too much pain?" Or, heavens forbid - undo much of the enhanced directory security?
    Last edited: Aug 1, 2013
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    To revert to earlier version you need a backup of your server from the point before the update.

    Btw. you can disable the directory protection under System > server config > web.

    Awstats works fine here and there are also no problems with uploading of sites with the new directory security scheme, we have some drupal sites here as well and all work fine. Maybe you installed your drupal systems wrong in the first way by e.g. placing files in wrong folders. The user has the same permissions in the "web" directory as before. Most likely you try to upload files to other directories instead of the "web" directory which shall not be possible. HTML and php files have to be copied to the "web" directory, files that shall kept private and that shall not be accessible by http have to be copied into the "private" directory.
  3. alisoncc

    alisoncc New Member

    Thanks for that. It's done.

    My Drupal installs are stock standard. It's Drush that had the problem. Drush archive-restore deletes the web directory in it's entirity and then rebuilds it. As it couldn't delete it, it fell over.

    Regards Alison
    PS if I set "Make web folders immutable (extended attributes)" to off, do I have to manually change them? Or will ISPConfig now set them to -i ?
    Last edited: Aug 1, 2013
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    Run tools > Resync to apply the changes to all existing websites.
  5. alisoncc

    alisoncc New Member

    Thanks all sorted now. Knew nothing about that "immutable" setting before. It did cause me a great deal of grief. Don't you hate it when computers tell you you can't do something, even as a superuser. Pull its power plug out if it's not careful. :p
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    The problem with allowing to delete the web folder or other folders where the client has access to is that it can bring down apache and all sites on your server. So if you have a client that wants to trick you or which just accidently deletes a folder, then apache might fail to start / restart and this affects all clients and not only the site were the folder was deleted. It does not even have to be a client, if one of your sites get hacked then the attacker can bring down apache on the whole server by deleting one of the folders of this site.

    The problem is drush here, it should not delete a folder that has already the correct name and permisions as its unnescessary to do that. At least drush should have a option for such a mode.

Share This Page