Conversation
This is completely untested but will be the basis of experimenting with Claude in a container to follow all of the directions and iterate on the document until it works end to end.
| .. note:: | ||
|
|
||
| **Container environments:** If running in a Docker container without systemd, use | ||
| ``sudo service mysql start`` instead of systemctl commands. |
There was a problem hiding this comment.
I suspect this is Claude being confused about something it tried to run, we should probably just pick service and try not to worry about the layers underneath
| redis-cli ping | ||
| # Should return: PONG | ||
|
|
||
| 5. Install and Configure Memcached |
There was a problem hiding this comment.
Not sure that we should worry about both memcached and redis, should probably just focus on a redis install at this point?
| pip list | grep -i celery | ||
| # Should show Celery | ||
|
|
||
| 11. Install Node.js Dependencies and Build Assets |
There was a problem hiding this comment.
This is repeated at step 17, I suspect it got confused and didn't know to copy the files so did it twice?
| # Create superuser with --noinput (non-interactive) | ||
| ./manage.py lms createsuperuser --username admin --email admin@example.com --noinput --settings=production | ||
|
|
||
| # Set the password using Python |
There was a problem hiding this comment.
This is silly, I think we can just set the DJANGO_SUPERUSER_EMAIL / DJANGO_SUPERUSER_PASSWORD / DJANGO_SUPERUSER_USERNAME env vars
bmtcril
left a comment
bmtcril
left a comment
There was a problem hiding this comment.
Still some work to do, but want to get other eyes on it
|
Closing / reopning to kick RtD |
|
@bmtcril just FYI it seems like RTD is taking about 10 minutes to report build status back to GH. Clicking into the build you can see status & view the built docs. |
|
@sarina yeah, yesterday RtD was dying in the middle of building and failed to report status back at all |
| Install JavaScript dependencies and build static assets: | ||
|
|
||
| .. code-block:: bash | ||
|
|
||
| npm clean-install | ||
| npm run webpack | ||
|
|
||
| # SASS compilation must run with virtual environment activated | ||
| source venv/bin/activate | ||
| PATH="$PATH:/opt/edx-platform/node_modules/.bin" python scripts/compile_sass.py --env=production | ||
|
|
||
| .. note:: | ||
|
|
||
| This step may take 10-20 minutes and requires significant memory. The webpack | ||
| build and SASS compilation are separate steps because the SASS compilation | ||
| script requires access to Python packages in the virtual environment. Running | ||
| ``npm run build`` directly will fail because it doesn't activate the venv before | ||
| running the SASS compilation script. |
There was a problem hiding this comment.
I think this will work fine but it seems a bit over-complicated. You can just activate the python venv before running npm run build, and Sass complition will succeed. This should work just as well:
npm clean-install
source venv/bin/activate
npm run build # includes npm run webpack, and npm run compile-sass
|
@bmtcril are you still planning to pursue this PR? |
Yes, probably after the Verawood cut |
musaabhasan
left a comment
musaabhasan
left a comment
There was a problem hiding this comment.
I left two security-focused notes on the manual deployment guide. Both are small documentation changes, but they matter because readers may copy this into long-lived learning platform environments rather than temporary local sandboxes.
|
|
||
| .. code-block:: bash | ||
|
|
||
| wget -qO - https://www.mongodb.org/static/pgp/server-7.0.asc | \ |
There was a problem hiding this comment.
Creating the MongoDB user does not by itself make MongoDB require authentication. Unless this guide also adds security.authorization: enabled to mongod.conf and restarts mongod, local clients can still connect without credentials, while later steps give the impression that the password is enforced. I would add an explicit hardening step after user creation, keeping bindIp local for single-host installs or calling out firewall/TLS requirements for remote MongoDB.
| "MONGO_PASSWORD": "your_mongodb_password" | ||
| } | ||
|
|
||
| Create ``/edx/etc/cms.auth.json`` with the same structure. |
There was a problem hiding this comment.
Before moving on, this should probably set restrictive permissions on /edx/etc/*.auth.json because those files contain the Django SECRET_KEY and database passwords. With /edx chowned broadly to the current user above, the default umask may leave secrets readable by more accounts than intended. A short step such as chmod 600 for single-user dev, or chmod 640 with ownership assigned to the runtime service account/group, would make the production-facing path safer.
4 participants
This is a first pass doc authored iteratively with Claude Code in a fresh Ubuntu 24.04 Docker container. The different commits show the progress as we worked through various install pitfalls and eventually got to a working build with the essential MFEs all connecting. As near as I can tell everything was running, but it has not been thoroughly tested.
An important note is that I did no installation or configuration work. I set up Claude Code, told it to write the install doc, then had it perform all of the steps, fixing the doc as it went. A record of the final session is here.
There are large chunks of leftover documentation about the process and testing at the bottom, which I think are actually really useful for hunting down common issues and I'd argue that they should stay in one form or another.
Known issues: