Hello I just tried (twice to upgrade to Barracuda / Octopus 2.0.5 (from 2.0.4) and i got not plateform added in the folder 006, the one created after the upgrade. I have a message telling me that i have finalised the upgrade successfully but when i look at my folder supposed to contain newly installed plateform , i see nothing.
I tried to follow what is written in the doc, starting by Barracuda and then Octopus.
I have attached the log and other required files as required.
Best Regards
Yaz

CommentFileSizeAuthor
#7 output.txt283.59 KByazzou
#5 output.txt256.52 KByazzou
USER.octopus.cnf_.txt1.04 KByazzou
octopus_log.txt1.45 KByazzou
install.txt8.93 KByazzou
barracuda_log.txt6.42 KByazzou
barracuda.cnf_.txt945 bytesyazzou

Comments

omega8cc’s picture

omega8cc commented
Title: UPGRADING to OCTOPUS 2.0.5 fails » no new platforms added
Component: Code » Miscellaneous
Status: Active » Closed (works as designed)

Some extra empty directories are expected, it is not an issue. You didn't post any errors here, so I assume you should probably edit _PLATFORMS_LIST in the USER.octopus.cnf file, so I tend to close this as a duplicate of #1422082: How to install additional platforms with the Octopus script, on an existing Octopus instance? unless you will post any real errors.

See also: http://drupalcode.org/project/octopus.git/blob/HEAD:/OCTOPUS.sh.txt#l143

yazzou’s picture

yazzou commented

In my file :

_PLATFORMS_LIST="D7P D6P OAM MNS NSM DCE UCT OEE AQ7 AQ6 OPC COD OSR DCS"

None of them were added after update, i have said yes when asked if i wanted to add some plateforms during the update process, but nothing happened.

yazzou’s picture

yazzou commented

Just to make sure : Should I run BARRACUDA script everytime, before running OCTOPUS , or just running the latter is just fine ?

omega8cc’s picture

omega8cc commented

You shouldn't run these scripts directly, unless you know what are you doing. The proper method to run upgrades, first with barracuda and then with octopus wrappers is explained in the docs.

If there are any issues, you should turn on debugging - _DEBUG_MODE=YES - both in .barracuda.cnf and .USER.octopus.cnf before running these upgrades and attach the full output so we could help you further.

yazzou’s picture

yazzou commented
StatusFileSize
new output.txt256.52 KB

Hello
I run it again and here is the output.
Thanks

omega8cc’s picture

omega8cc commented
Status: Closed (works as designed) » Active

So, have you really read the output?

nsxxxx:~# octopus up-stable all
load is 116 while maxload is 1888
Octopus upgrade for User /data/disk/USER

This Aegir Instance is already up to date!
If you wish to run/force the upgrade again,
please specify desired upgrade mode:
aegir, platforms or both - as shown below

Usage: octopus up-stable all {aegir|platforms|both}

It says in bold what to do, so please run:

octopus up-stable all both

and attach the output.

yazzou’s picture

yazzou commented
StatusFileSize
new output.txt283.59 KB

When i try it does not even ask me if i want to add even the basic plateforms. I a bit stuck i have to say.Here is the output again
Thanks

omega8cc’s picture

omega8cc commented
Status: Active » Closed (works as designed)

The log says that you already have all latest platforms installed and they are in the 005 tree, not 006, which is empty if exists and it is OK.

UPGRADE C: Shared platforms code v.005 (latest available) will be used for this install

yazzou’s picture

yazzou commented

Well if i look in the 005 folder, i see for exemple for drupal 7 this version : drupal-7.18.1-prod . I wanted to update D7 sites to make them run on 7.19. After reading again the changed log i noticed that on the latest release of Barracuda no update has been integrated for D7. I was worried when i saw about D7.19 that it is security relase.

So i think it should be fine, as you say. I ll wait the integration of D7.19 to run the upgrade scipt again.
Thank you very much for taking time to help me !

omega8cc’s picture

omega8cc commented

Ah, that explains everything, because latest Drupal core based platforms will be included in BOA-2.0.6, scheduled for release this weekend.

omega8cc’s picture

omega8cc commented

Also, note that BOA already protects you by default from many (most) XSS attacks, so some Drupal security releases are not really required to be used immediately. This was also the case with previous security release, which didn't affect any BOA based system at all, because the access to install.php is denied already.

Anonymous’s picture

Anonymous (not verified) commented

A question for clarification, please.

Is it best practice NOT to do a drush based upgrade of Octopus hosted sites from one minor version of Drupal to another?

I recently did this, and logged-in via SSH as the o1.ftp user could not upgrade from 7.18 to 7.19, with error message returned: "failure to successfully upgrade core " and "Could not write to drupal root". I checked my permissions and the install profile was set to 755, with the owner being 111 and the group being 100. I was able to upgrade to 7.19 by changing the permissions to 775, for some of the default install profiles, but NOT for any of my 7.18 static install profile sites.

Wen I tried to do the upgrade to 7.19 on the /static/ custom install profiles, drush returnd a success message, but when I ran "mup" again, it told me that the update still needed to take place. Looking into the site itself, clearly no update had taken place, even though drush reported success.
I was only able to upgrade to 7.19 on the static, custom install profile sites by logging in as the root user and running "upc", which the first time falsely reported success again, but then when I ran "up", there was actual success in updating the install profile to 7.19.

My questions are the following: (I may not be posting this in the right place, but don't want to open a new issue if I am incorrectly using BOA so I have opend this discussion: http://groups.drupal.org/node/283143 ):

1.) Should I NOT do these manual minor release upgrades to the drupal core at all, as this thead suggests?

2) Do I run any risks to the install profiles and sites built on them by running drush commands as the root user?

3. I noticed that some of the install profiles and some sites had the permissions set to 111:100 (o1:aegir), and others had permissions set to 999:100 (o1.ftp:aegir). I imagine they should all be either one or the other. Which one is correct, please?

Thank you.

omega8cc’s picture

omega8cc commented

@EdNet These permissions are in place exactly to *not* allow you to do things the wrong way. What you are trying to do is *totally wrong* and against Aegir entire concept. Please read *all* articles linked at: http://omega8.cc/library/aegir-basics