Closed Giuliano69 closed 3 years ago
Everyone is going to organize their directories a bit differently. For me and all of my clients, we use /opt/alfresco as a softlink to the versioned install directory. That way, when we do upgrades we create a new versioned directory and move the link. Rolling back then is just a matter of moving the link back.
As this is just an example project and because everyone has different layout preferences, I'm going to close this as a "won't fix" because it will work as-is if you have your directories set up properly before running the playbook.
Interesting, thanks for sharing the idea !
this means that your "new" install will have a completely independent Alfresco + Tomcat+ActiveMQ install... but what about Postgres ? It is not a docker, so the database/tables keep the same for ALL the installations... if the database becomes broker, because of the new install, aren't you at risk of loosing the data ? If you use a new database you loose the old data...
BTW Just to better understand: Let's say we want to test to ACS 7 with the "symbolik link system" ... (will ansible work for ACS7 ?)
Lets FIRST unlink current /opt/alfreso, and link some other dir as ln -s acs7_dir /opt/alfresco and THEN install the new ACS7
Of course the ansible script will work with the "usual" values
alf_home: "/opt/alfresco"
alf_data: "{{ alf_home }}/alf_data"
alf_install_dir: /opt/alfresco-7.0-a2
search_install_dir: '{{ alf_install_dir }}/alfresco-search-services'
BUT installing the search services in a SIBLING directory the ansible installer will try to write to /opt/alfresco-7.0-a2 where the user alfresco does NOT have write permissions... Raising the same problem again... Alfresco user just owns /opt/alfresco (the one we linked), not the siblings dirs ... So we get stuck again ... Am I missing something?
Yes, each install has its own completely independent install. Databases should not be on the same server. If the database is on the same server, it would NOT be installed in the /opt/alfresco directory. That is a good thing because for an upgrade you just let the new Alfresco version upgrade the schema. If you need to roll back you do a dump and load of the database from the backup you took just prior to the upgrade.
When you create the version specific directory and you create the soft link, make sure the alfresco user/group is the owner of both the version specific directory and the link.
Hi When running installSearch.yml, it runs tasks/doInstallSearch.yml that in turn will provide
that ... will FAIL.
the problem seems to me related to the directory position/definition in the var file:
In simpler words, it's a matter of file owner/permission the alfresco user is the owner of the /opt/alfresco folder , and because of that can correctly create any directory he wants inside(under) /opt/alfresco. BUT to create a sibling directory of /opt/alfresco, i.e. another directory INSIDE /opt (e.g. /opt/alfresco-6.2.0-ga) , the alfresco user should ALSO OWN the /opt directory, BUT usually this is not the normal situation, and the dir creation is correctly denied.
To let the script work I had to change the owner of /opt to alfresco.... the error vanished.
One quick fix would be to change alf_install_dir into:
alf_install_dir: {{alf_home}}/alfresco-6.2.0-ga
so that search_install_dir could be freely created inside..Is there any special need to keep the install dir as a SIBLING of /opt/alfresco, (i.e. /opt/alfresco-6.2.0-ga) , instead of the simpler SON /opt/alfresco/alfresco-6.2.0-ga that stays INSIDE /opt/alfresco ? Can we make the change ?