search

thegooddata / social

GNU General Public License v2.0
0 stars 0 forks source link

Cannot deploy to Production using Capistrano #45

Closed josereyero closed 9 years ago

josereyero commented 9 years ago

Today I've been trying some production deployment and it failed, apparently because of a file permissions issue. (The previous staging deployment went fine, without any issue)

This is the full output

$ cap production deploy

atrandafir commented 9 years ago

I'm afraid I cannot help too much with this issue, maybe @agonbar can look into it.

My feedback:

agonbar commented 9 years ago

I've never had access to the capistrano recipes but the tgd user is in the www-data group. So no permission problems, but if someone tells me the directories I can double check. Also I'm dealing with some problems in db-pre, this could be the cause.

El mié., 24 de jun. de 2015 19:52, Alexandru Trandafir Catalin < notifications@github.com> escribió:

I'm afraid I cannot help too much with this issue, maybe @agonbar https://github.com/agonbar can look into it.

My feedback:

  • I have no access to modify permissions, I can only login as tgd user and I think it is the same system user that runs the capistrano command isn't it?
  • One thing that looks somehow weird to me is that capistrano is trying to do something to assets and protected directories, is openatrium using those directories? as far as I know those dir names are used in webapp but I think not by openatrium. So are you running the right capistrano tool? Anyways looks weird to me that it did stopped working.

— Reply to this email directly or view it on GitHub https://github.com/thegooddata/social/issues/45#issuecomment-114955781.

agonbar commented 9 years ago

I've changed the permissions to be even more loose, try again and post the log in case of failure please.

josereyero commented 9 years ago

Not working yet, same errors.

I've been digging into both staging and production servers and by looking at file permissions, this is the differences I've found:

Could we just try chown tgd:tgd -R /srv/openatrium/shared -- that is where the problem seems to be?

Note: Openatrium is not using that folders but the capistrano script seems to do it, maybe they have some use for webapp, I don't know.

(We cannot change it for everything because there are some files, in /srv/openatrium/current/sites/default/ that need gid set to www-data)

agonbar commented 9 years ago

If someone knows exactly the folders used I can change them to tgd. Still tdg is in the group www-data so it should work anyway.

El jue., 25 de jun. de 2015 12:12, Jose Reyero notifications@github.com escribió:

Not working yet, same errors.

I've been digging into both staging and production servers and by looking at file permissions, this is the differences I've found:

  • Files in production server /srv/openatrium are owned by www-data:www-data
  • Same files in staging server (where the deployment does work) are owned by tgd:tgd

Could we just try chown tgd:tgd -R /srv/openatrium/shared -- that is where the problem seems to be?

Note: Openatrium is not using that folders but the capistrano script seems to do it, maybe they have some use for webapp, I don't know.

(We cannot change it for everything because there are some files, in /srv/openatrium/current/sites/default/ that need gid set to www-data)

— Reply to this email directly or view it on GitHub https://github.com/thegooddata/social/issues/45#issuecomment-115198677.

josereyero commented 9 years ago

I've done some quick research and found this:

"On Linux you must be the file owner (or root) to change the modification time to a time other than the current time. There are some other restrictions as well. man utime for complete details." http://stackoverflow.com/questions/953098/change-file-time-touch

Tested on my local box and it happens to be true. So please:

chown tgd -R /srv/openatrium/shared

agonbar commented 9 years ago

Its ok if I do it in all shared? I remember it gave problems last time in the platform, if Marcos is ok, I do it right now.

El jue., 25 de jun. de 2015 17:07, Jose Reyero notifications@github.com escribió:

I've done some quick research and found this:

"On Linux you must be the file owner (or root) to change the modification time to a time other than the current time. There are some other restrictions as well. man utime for complete details." http://stackoverflow.com/questions/953098/change-file-time-touch

Tested on my local box and it happens to be true. So please:

chown tgd -R /srv/openatrium/shared

— Reply to this email directly or view it on GitHub https://github.com/thegooddata/social/issues/45#issuecomment-115287191.

josereyero commented 9 years ago

Issue fixed, thanks. Latest deployment went fine.

atrandafir commented 9 years ago

Sorry I'm coming late to the discussion.

Happy to hear it got fixed. As I said before I have no idea why the capistrano tool is using those directories, why it worked before and now it stopped working.

It looks to me as if we were using the "webapp" deployment script to deploy "social".

So it is strange behaviour. Anyway happy to hear it got fixed.

And just last thing to add.. the name of the directories "assets" and so on, look like belonging to the webapp, but they are not the webapp's directories because they are under /srv/openatrium/ and not /srv/webapp/ so it is like the tool creates the "webapp" shared directories under the "social" application directory.

josereyero commented 9 years ago

@atrandafir, Yes, those seem to be webapp folders -OA doesn't use them at all- but I think we're just reusing the scripts and have been doing it always.

The only thing that has changed since last deployment, some time ago, is I think, folder/files ownership. For some reason -which I don't know- they were all chown www-data:www-data. But if you look at the latest deployment -today- that folders have the right ownership which is tgd:tgd

tgd@lnd-app00:~$ ls -l /srv/openatrium/releases/ total 80 drwxrwxr-x 13 www-data www-data 4096 Jun 6 2014 20140606215930 drwxrwxr-x 13 www-data www-data 4096 Jun 6 2014 20140606221750 drwxrwxr-x 13 www-data www-data 4096 Jun 6 2014 20140606222202 drwxrwxr-x 13 www-data www-data 4096 Jun 9 2014 20140609102404 drwxrwxr-x 13 www-data www-data 4096 Jun 9 2014 20140609103616 drwxrwxr-x 13 www-data www-data 4096 Jun 13 2014 20140613155735 drwxrwxr-x 13 www-data www-data 4096 Jun 16 2014 20140616142204 drwxrwxr-x 13 www-data www-data 4096 Jun 24 2014 20140624190450 drwxrwxr-x 13 www-data www-data 4096 Jun 25 2014 20140625164050 drwxrwxr-x 13 www-data www-data 4096 Jul 1 2014 20140701210029 drwxrwxr-x 13 www-data www-data 4096 Jul 2 2014 20140702073807 drwxrwxr-x 14 www-data www-data 4096 Aug 7 2014 20140807090551 drwxrwxr-x 14 www-data www-data 4096 Sep 10 2014 20140910153329 drwxrwxr-x 14 www-data www-data 4096 Sep 16 2014 20140916184440 drwxrwxr-x 14 www-data www-data 4096 Oct 15 2014 20141015200534 drwxrwxr-x 14 www-data www-data 4096 Oct 19 2014 20141019173337 drwxrwxr-x 14 www-data www-data 4096 Nov 26 2014 20141126113617 drwxrwxr-x 14 www-data www-data 4096 Dec 23 2014 20141223161035 drwxrwxr-x 14 www-data www-data 4096 Feb 3 20:46 20150203204616 drwxrwxr-x 14 tgd tgd 4096 Jun 26 15:32 20150626153246 (latest deployment)