© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
OK. I apologize. I was attempting to run a test over cell connection and that wasn't the best connection for a remote console connection.
So I just re-ran the test over a better Internet connection. I can now confirm you were correct that the ports compartments and buckets being disabled were in fact the problem.
OK, so that leads me to some questions about how to be sure others don't run into this problem.
Objective:
* Attempting to get maas to function properly in an air-gapped environment
System Requirements:
* An *exact* replica of https:/
rsync -avv --info=
* properly set up webserver to serve up repo
* naturally your egress FW rules will require port 873 to the addresses above to be open in order to rsync.
* Attempting to create an internal apt repo differing from the repo above using something like apt-mirror or the like will require a bit of massaging and will likely be error prone.
MaaS Requirements:
* CHANGE ONLY THE FIRST TWO PRIMARY REPOSITORY ENDPOINT **URLS**! Both must be changed to match your internal address. Leave everything else alone!!!! *DO NOT CHANGE ANYTHING ELSE*
- anything differing will likely cause issues with enlisting/
* Obviously any additional repositories maintained besides the main two repos will likely not be problematic.
For me, the local apt repository has been a true thorn in my side during implementation and testing. While I understand the necessity for the tight coupledness, none of this was documented.
One thing that was not tested was leaving the two primary addresses alone and adding an additional internal repo with the necessary tooling (not documented to the best of my knowledge).
-------
I think now that this issue is confirmed to not necessarily be a bug (however, very unintuitive), it was definitely less than ideal and at least requires documentation.