Rake assets:precompile fails with new install

(Jonathan Lin) #1

Hi guys, bootstrapping my web container is failing at assets:precompile

I, [2015-02-17T07:47:21.196448 #24415]  INFO -- : Writing /var/www/discourse/public/assets/images/docker-manager-ea64623b074c8ec2b0303bae846e21e6.png
rake aborted!
Errno::EEXIST: File exists - /var/www/discourse/public/uploads
/var/www/discourse/lib/sass/discourse_stylesheets.rb:88:in `compile'
/var/www/discourse/lib/sass/discourse_stylesheets.rb:38:in `block in compile'
/var/www/discourse/lib/sass/discourse_stylesheets.rb:35:in `synchronize'
/var/www/discourse/lib/sass/discourse_stylesheets.rb:35:in `compile'
/var/www/discourse/lib/tasks/assets.rake:81:in `block (3 levels) in <top (required)>'
/var/www/discourse/lib/tasks/assets.rake:80:in `each'
/var/www/discourse/lib/tasks/assets.rake:80:in `block (2 levels) in <top (required)>'
/var/www/discourse/vendor/gems/rails_multisite/lib/rails_multisite/connection_management.rb:86:in `block in each_connection'
/var/www/discourse/vendor/gems/rails_multisite/lib/rails_multisite/connection_management.rb:84:in `each'
/var/www/discourse/vendor/gems/rails_multisite/lib/rails_multisite/connection_management.rb:84:in `each_connection'
/var/www/discourse/lib/tasks/assets.rake:75:in `block in <top (required)>'
/var/www/discourse/lib/tasks/assets.rake:134:in `block in <top (required)>'
Tasks: TOP => assets:precompile:css
(See full trace by running task with --trace)
I, [2015-02-17T07:47:23.768710 #40]  INFO -- : Purging temp files
Bundling assets
Compiling css for default

RuntimeError: cd /var/www/discourse && su discourse -c 'bundle exec rake assets:precompile' failed with return #<Process::Status: pid 24413 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:105:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --verbose --without test --without development'", "su discourse -c 'bundle exec rake db:migrate'", "su discourse -c 'bundle exec rake assets:precompile'"]}

Any idea what’s wrong?

(Jeff Atwood) #2

Did you do anything weird / custom in the Docker container?

(Jonathan Lin) #3

Not particularly. I’ve deployed the exact same setup before. Re-running it is causing trouble :confused:

(Sam Saffron) #4

Is there some sort of security issue? what does the container config look like?

My guess is that somehow you changed permission on the host for the uploads directory shutting down access to it?

(Jonathan Lin) #5
# IMPORTANT: SET A SECRET PASSWORD in Postgres for the Discourse User

  - "templates/sshd.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
  - "templates/web.ssl.template.yml"

  - "80:80"
  - "443:443"
  - "2222:22"

  ## Which Git revision should this container use? (default: tests-passed)
  #version: tests-passed

  LANG: en_US.UTF-8
  ## TODO: How many concurrent web requests are supported?
  ## With 2GB we recommend 3-4 workers, with 1GB only 2
  UNICORN_WORKERS: {{ unicorn_workers }}

  ## TODO: configure connectivity to the databases
  # DISCOURSE_DB_USER: discourse
  DISCOURSE_DB_PASSWORD: {{ postgres_password }}
  DISCOURSE_DB_HOST: {{ db_ip_address }}
  DISCOURSE_REDIS_HOST: {{ redis_ip_address }}
  ## TODO: List of comma delimited emails that will be made admin and developer
  ## on initial signup example 'user1@example.com,user2@example.com'
  DISCOURSE_DEVELOPER_EMAILS: '{{ developer_emails }}'
  ## TODO: The domain name this Discourse instance will respond to
  DISCOURSE_HOSTNAME: '{{ hostname }}'
  ## TODO: The mailserver this Discourse instance will use
  DISCOURSE_SMTP_ADDRESS: {{ smtp_address }}         # (mandatory)
  DISCOURSE_SMTP_PORT: {{ smtp_port }}               # (optional)
  DISCOURSE_SMTP_USER_NAME: {{ smtp_username }}      # (optional)
  DISCOURSE_SMTP_PASSWORD: {{ smtp_password }}       # (optional)
  ## The CDN address for this Discourse instance (configured to pull)
  #DISCOURSE_CDN_URL: //discourse-cdn.example.com

  - volume:
      host: /var/discourse/shared/web
      guest: /shared
  - volume:
      host: /var/discourse/shared/web/var-log
      guest: /var/log

#Use 'links' key to link containers together, aka use Docker --link flag.
  - link:
      name: data
      alias: data

## The docker manager plugin allows you to one-click upgrade Discouse
## http://discourse.example.com/admin/docker
    - exec:
        cd: $home/plugins
          - mkdir -p plugins
          - git clone https://github.com/discourse/docker_manager.git

## Remember, this is YAML syntax - you can only have one block with a name
  - exec: echo "Beginning of custom commands"

  ## If you want to configure password login for root, uncomment and change:
  #- exec: apt-get -y install whois # for mkpasswd
  ## Use only one of the following lines:
  #- exec: /usr/sbin/usermod -p 'PASSWORD_HASH' root
  #- exec: /usr/sbin/usermod -p "$(mkpasswd -m sha-256 'RAW_PASSWORD')" root

  ## If you want to authorized additional users, uncomment and change:
  #- exec: ssh-import-id username
  #- exec: ssh-import-id anotherusername

  - exec: echo "End of custom commands"
  - exec: awk -F\# '{print $1;}' ~/.ssh/authorized_keys | awk 'BEGIN { print "Authorized SSH keys for this container:"; } NF>=2 {print $NF;}'

I’m using Ansible to automate stuff, hence the {{ vars }}

(Jonathan Lin) #6

Is it possible to enter the web container to snoop on things even though it failed to bootstrap?

(Kane York) #7

Nope, the container doesn’t “exist” anymore.

What do the permissions on /var/discourse/shared/web and subdirectories look like?

(Jonathan Lin) #8

Thanks @riking for pointing me in the right direction. I had the /var/discourse/shared/web directory owned by an app user before running bootstrap (created when I copied SSL files into /var/discourse/shared/web/ssl before running bootstrap). Didn’t realize a link meant that permissions were shared too.

Indeed my own problem, sorry for taking everyone’s time!

(Jeff Atwood) #9