2.1. Running the
2.1.1. ShimmerCat permission denied error:¶
Failed when generating new toy certificate: /root/.config/mousebox: fileExist: permission denied (Permission denied)
Take a look to the
user_group on your
sc_pack.conf.yaml. Suppose that you have there:
Make sure the user you are running the
sc_pack supervisord with is the same as the one on the sc_pack.conf.yaml.
If your command line is showing:
(venv) root@host1:~/test/new-test$ it means you are running it with the user
root which is probably what is causing that error.
You are running the sc_pack commands with a user different than the one you specified on the
You have at least two options to deal with it:
keep running the
root, but change the
user_group: sudo(or whatever value the command
$ groupsreturns and fits better to your deployment).
change the user on your command line to be the one you set on the
$ sudo su <user>. e.g
$ sudo su sc_packfor the example above.
$ sc_pack create command to update the sc_pack directories with the new user permissions.
It is important that the user and group we set on the sc_pack.conf.yaml are the owner of the directory and sub-directories of the
install-dir we set on the
We try to do it automatically on the
$ sc_pack create, but if it does not work for you, or you want to discard this kind of errors you can run:
$ chown -R user:user_group install_dir
Let’s suppose you have
install_dir: /home/shimmercat/test/shimmercat-accelerator on the sc_pack.conf.yaml.
$ chown -R sc_pack:sc_pack /home/shimmercat/test/shimmercat-accelerator
The complete log messages for ShimmerCat are on
/<install_dir>/shimmercat/data/shimmercat.log, for the
install_dir we are using as example, it should be at
2.1.2. Celery amqp.exceptions.AccessRefused¶
Celery logs are on
First thing to check is that you have updated the:
- deployment_site_long_name: <your_name16> - deployment_site_long_secret: <your_secret16>
on your sc_pack.conf.yaml. e.g
- deployment_site_long_name: ccca6552567d530d - deployment_site_long_secret: 416b652640725369
because those are the user and password celery uses to connect to the broker.
Secondly you should make sure you have already updated your
devolve.yaml with the domain you created on the ShimmerCat Accelerator platform, because the domain is used by celery to get tasks that belong just to a queue linked to the domain the sc_pack is configured for.
You can find messages like this below on the logs when celery starts:
-------------- firstname.lastname@example.org v4.1.0 (latentcall) ---- **** ----- --- * *** * -- Linux-4.15.0-42-generic-x86_64-with-Ubuntu-18.04-bionic 2018-12-07 09:22:26 -- * - **** --- - ** ---------- [config] - ** ---------- .> app: sc_app:0x7fb6ad2a6dd8 - ** ---------- .> transport: amqp://ccca6552567d530d:**@amqp.staging.c.shimmercat.com:5675/skyloft - ** ---------- .> results: redis://amqp.staging.c.shimmercat.com:6379/ - *** --- * --- .> concurrency: 1 (prefork) -- ******* ---- .> task events: ON --- ***** ----- -------------- [queues] .> -public.ccca6552567d530d/example-accelerator.shimmercat.com-85a9f71efa2b11e8a9cb4ccc6affcafd exchange=opt_pipeline.public(direct) key=instructions-public.ccca6552567d530d/vlad-accelerator.shimmercat.com
You should see the deployment_site_long_name in several places on this message above, otherwise something is wrong. Take a special look to:
[queues] .> -public.ccca6552567d530d/example-accelerator.shimmercat.com-85a9f71efa2b11e8a9cb4ccc6affcafd exchange=opt_pipeline.public(direct) key=instructions-public.ccca6552567d530d/vlad-accelerator.shimmercat.com
and more specifically to:
.> -public.ccca6552567d530c/example-accelerator.shimmercat.com, where your deployment_site_long_name should there and
also the domain you created on the ShimmerCat Accelerator. If those values don’t match then you should look into your
sc_pack.conf.yaml and check the
deployment_site_long_name, and also on the
devlove.yaml and check that the domain you created on the ShimmerCat Accelerator is there in too.
Thanks a lot for your time, and keep reading!