njeirath
commented
7 years ago @aliasguru Can you specify which version of Ubuntu your AMI was based off of?
The quick answer is to reference the very last section named "Nginx Path" in the Tutorial and validate that the "Nginx Path" field is being set appropriately on the "Setup Job" tab under the "Add Workers" section (this will depend on the version of Ubuntu you used).
Some more background on why the issue may be occurring:
CORS is a security mechanism implemented by most browsers to prevent web applications from making calls to servers on a different domain CORS details. This occurs in the dashboard because the domain of the site is brenda-web.com (or localhost if running locally) and this page is trying to access data on a different domain (54.236.31.153 in your case). To prevent this from being an error, HTTP provides for the Access-Control-Allow-Origin header which can be set to a particular domain on the server or simply '*' to allow all origins.
To serve up the data from each of the workers to drive the dashboard functionality we install a light weight web server Nginx. This is automatically installed by the startup script when brenda-web starts up an EC2 instance. We setup a couple cron jobs to push relevant files to the folder where nginx serves up files and also set the Access-Control-Allow-Origin header to '*' to allow all cross domain connections.
The full startup script can be seen on the brenda-web site under the "Setup Job" tab at the very bottom in the text area labeled "Startup Script", I've pulled out the relevant portion of the script below:
sudo apt-get -y install nginx
sudo sed -i '29 i\ add_header 'Access-Control-Allow-Origin' '*';' /etc/nginx/sites-enabled/default
sudo echo "* * * * * root tail -n1000 /mnt/brenda/log > /usr/share/nginx/html/log_tail.txt" >> /etc/crontab
sudo echo "* * * * * root cat /proc/uptime /proc/loadavg $B/task_count > /usr/share/nginx/html/uptime.txt" >> /etc/crontab
if ! [ -d "$B" ]; then
for f in brenda.pid log task_count task_last DONE ; do
ln -s "$B/$f" "/root/$f"
sudo ln -s "$B/$f" "/usr/share/nginx/html/$f"
done
fi
sudo service nginx restartThe high level steps in the script are to
- Install nginx
- Setup the Access-Control-Allow-Origin header in the nginx configuration
- Setup a few cron jobs to populate the directory from which nginx serves web pages
- Restart nginx
Since you're receiving the CORS error that suggests that something went wrong during the startup process and the appropriate headers weren't set in the nginx config file. If you're able to make it public, the AMI ID you're using would help so I can spin up a worker to see what might be going on. Otherwise any logs you're able to provide from the worker startup would be helpful or at the very least the version of Ubuntu you're using.
aliasguru
I've created a custom brenda AMI on AWS and am successfully rendering with it. I can use Brenda-web to submit jobs just fine. The only thing I don't know what to do about is an issue in the Dashboard: A few of the details don't update. These are:
When debugging the site, I noticed in the console that the communication with the AMI failed because of a CORS error. It basically tells me that "No Access-Control-Allow-Origin header is present on the requested resource. This happens when brenda-web tries to read the uptime.txt file from the server.
However, using one of the provided AMIs works just fine. So my question really is: What do I need to do to enable CORS communication in my custom AMI?
The exact error in Firefox (German I'm afraid): Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf http://54.236.31.153/uptime.txt?d=1508143629217. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt).