I'm basing this on the branch where I merged the backend in, so YMMV. Anyway, I used remote_import to pull a CiviCRM site between an Aegir2 server and an Aegir3 server. It worked quite well, except for some stale file paths. Specifically, files/civicrm/ConfigAndLog/Config.IDS.ini Interestingly, it contained the correct filter_path but tmp_path and HTML_Purifier_Cache both point to the old platform path.

I expected a 'Verify' task might re-write this file, but it didn't appear to. Perhaps these are set somewhere in the DB? Anyway we should probably look at having this file re-generated on 'Verify' tasks, if it isn't already.

Comments

ergonlogic created an issue. See original summary.

bgm’s picture

bgm CreditAttribution: bgm commented

The Config.IDS.ini should be deleted after such operations. CiviCRM will regenerate it on the next run. The file should normally be deleted if the cache was flushed. Sometimes permissions problems make it impossible to delete the file.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

I ran into this again today. When we used remote_import to clone a site from another Aegir server. Config.IDS.ini is writeable by 'aegir'. Perhaps this path is cached somewhere in the database, and so the file gets re-written with stale data?

Anyway, neither verifying the site, nor clearing caches was sufficient to fix it. I had to manually update the paths to the correct ones.

One possible work-around for this would be to ensure that platforms on the sources and destination servers are identical. We'll test this, and report back results.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented
Issue summary: View changes
josephleon’s picture

josephleon CreditAttribution: josephleon as a volunteer commented

There is a confirmed workaround for this, you have to make sure that both the platform and the site have the same names from where you are importing them.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

This is caused by an upstream change in CiviCRM that Aegir doesn't properly support yet. Basically, there's a setting that specifies the path for temporary files, and it isn't getting reset when we clone a site, nor does clearing caches help directly.

Assuming that the site is inaccessible, the initial work-around works like so:

  • login to the server via SSH
  • become the 'aegir' user
  • navigate to the site directory
  • edit files/civicrm/ConfigAndLog/Config.IDS.ini
  • update the "tmp_path" setting to use the new site URL (at this point it probably points to the site that was cloned from)
  • save the file.
  • run: chown aegir:www-data files/civicrm/upload/ -R

Now the site ought to be accessible, and its upload temporary file directory ought to be writable by the web user. To ensure these settings remain, do the following:

  • visit civicrm/admin/setting/path
  • note the "Temporary Files" field, which will continue to point to the path of the site that was cloned
  • update that field to use the new site URL in the path
  • click "Save"
  • then visit civicrm/admin/setting/updateConfigBackend
  • click "Cleanup caches"
ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic commented

Refer to this discussion: https://hefring.mig5.net/bot/log/aegir/2015-12-23#T603338

bgm’s picture

bgm CreditAttribution: bgm commented

Is it safe to close this issue? I feel like it has been fixed by other issues, including the work done to set proper permissions.