Out of curiosity, how should the website page look like if it runs correctly?
If everything runs correctly, you should be able to navigate to the configured frontend port, login as “root” with password “rootroot”, and then go to My Almond and type commands normally.
In the terminal, the frontend will not show “Control channel to EngineManager[0] severed”.
We managed to get the website working by changing the target domain (the backend / frontend worked fine as you said). It seems that the website can be accessed normally and the login system also works fine. However, the Almond itself seems to not work for some reason? The command line doesn’t output anything when we try to give it a command. The example below is trying to use the ABC news device.
The logs in the console also doesn’t show anything.
Is there some config variable that we have accidently changed? Our goal is to reuse both the existing NLP and the Thingpedia (the web Almond only option).
Also, we are making a device that can filter news using a remote service that we have created. Is there any way to add the developer key to our own Almond so we can test it there without waiting for it to be approved?
I’m not sure why it’s not showing anything, given that it seems that the connection between the frontend and the backend occurs correctly. It might be an origin problem from the browser to the frontend. How did you set SERVER_ORIGIN in the config file?
As for setting a dev key, you’ll need to apply this PR Add the ability to set a default developer key by gcampax · Pull Request #880 · stanford-oval/almond-cloud · GitHub
Some other student group asked for this functionality and I wrote it. They later told me it kind of worked but didn’t work completely, so it was never merged. Someone could pick it up and finish it if desired.
SERVER_ORIGIN is set to our own domain where the website can be accessed.
What do you mean by apply the pull request? Can we just pull from it and follow the changes in the respective files?
If the issue is not SERVER_ORIGIN, it would be good to see why the connection is dropping. The Firefox/Chrome inspector or network tab might have a hint, or there might be some logging in the terminal. When you refresh the conversation page, in the backend terminal it should show something like “Handling new direct connection for X”, where X is the user id that is connecting.
To apply the PR, switch to the indicated branch, merge master, rebuild, deploy.
The console log looks like this:
I navigated to the page, then entered
help, then refreshed the page, then entered get ABC news
It seems that it somehow cannot find the assets?
Yeah if the JS fails to load that’s a configuration problem. Did you set or change ASSET_CDN by any chance?
it’s still ./assets. Should this instead point somewhere else?
No that shouild be correct. What do you get if you navigate to http://personal.xhlife.com.au/assets/javascripts/conversation-bundle.js manually?
Also, do you have a conversation-bundle.js file in public/javascripts/ at all? If not, you did not build/install correctly. Do npm install to rebuild.
It shows an error page:
It should be in the directory, but at which stage of the deployment was that supposed to be build at? Maybe after yarn global add github:stanford-oval/almond-cloud?
Either way since its not working now, in which directory would we run npm install ?
I’m sorry, it looks like the documentation was out of date. You shouldn’t be using yarn, you should be running npm. Otherwise the build will be incomplete.
You want something like:
git clone https://github.com/stanford-oval/almond-cloud
cd almond-cloud
npm install
npm link
(the last command might need sudo, depending on how/where you installed node)
Wait, if we use git clone, then what about the next stages where we change the config file and create the new directory for the backend? We can technically restart from scratch since the only change from the main repository is in the config file right?
The steps after the install operate exactly the same as before. At the end of the installation process, you still have an almond-cloud command, and Almond still loads the configuration file from /etc/almond-cloud.
If we follow your steps here, then:
Step 2: We end at /almond-cloud
Step 3: We copy the config file to /etc/almond-cloud/config.js (leaving the original config from step 2 intact)
Step 4: We do the bootstrap
Step 5: We run the backend at /srv/almond-cloud/workdir
Step 6: We run the frontend at /srv/almond-cloud/workdir
So step 3-6 will be done inside the /almond-cloud directory?
To clarify:
- you don’t need to copy the config.js file to /etc/almond-cloud, you need to create a new file with the configuration variables that you want to override
- it doesn’t matter where you run the bootstrap
I’m more asking about how the resulting directories would look like. Would etc and srv be inside almond-cloud or are they on the same level as it?
/etc is an absolute path, it is exactly inside the root directory /
The current directory when you run the frontend + backend is whatever you want it to be, there is no special need for it to be /srv. It must not be inside the git clone though.
Typically, the layout is:
- /opt/almond-cloud : git clone with sources
- /etc/almond-cloud : configuration files
- /var/lib/almond-cloud or /srv/almond-cloud : state directory (cwd for the almond processes)
This follows the Filesystem Hierarchy Standard (also documented as man hier).
Ok, I think it would be better if we redid the whole thing then to follow this layout. Currently its very messy and unclear where each directory is created. I guess if we want to store it in a github, it would also be best to put them inside those directories (maybe only the main almond-cloud directory + the changed config.js file)?
Those are absolute paths. You can’t put them anywhere, it’s just not how paths work.
I don’t know what you want to put on GitHub. GitHub is for source code and maybe configuration files. You can fork the almond-cloud repository and make your changes there if you need to, but it doesn’t look like you need any change to the main source. State files (the stuff in /srv) definitely do not belong in Git. Configuration files are iffy because they’re usually not public, and also site specific so there is no point in sharing them with anyone.
Realistically, the only thing you want to put in GitHub is the skills you built.