racb and I had a quick chat and here's our take away:
1. sshd configs need to move to /etc/sshd/sshd_config.d/ , as is appropriate
2. we on CPC are going to go through our images and ensure we have config files in appropriate places. If there are .d/ directories available, we need to use them. If there are not, we should open bugs against the packages we are configuring to get .d/ folders added as we have requirements to provided initial configuration, and support automated updates
3. CPC is going to check our package update (apt-get update && apt-get dist-upgrade -y) on default images on Focal and Jammy to see what pops up now, and document behaviour to end users. This is not a release blocked
4. CPC is going to check `do-release-upgrade` from Focal to Jammy and document default behaviour
note that our default behaviour documentation won't be able to cover all end-user experiences. it just gives a baseline for expectations for "base" starting points.
our goal is to make sure end-users know the best non-interactive paths on the cloud using the Ubuntu default experiences (meaning we won't add instructions for all IT automation possibilities, but will document apt, needrestart, etc)
racb and I had a quick chat and here's our take away:
1. sshd configs need to move to /etc/sshd/ sshd_config. d/ , as is appropriate
2. we on CPC are going to go through our images and ensure we have config files in appropriate places. If there are .d/ directories available, we need to use them. If there are not, we should open bugs against the packages we are configuring to get .d/ folders added as we have requirements to provided initial configuration, and support automated updates
3. CPC is going to check our package update (apt-get update && apt-get dist-upgrade -y) on default images on Focal and Jammy to see what pops up now, and document behaviour to end users. This is not a release blocked
4. CPC is going to check `do-release- upgrade` from Focal to Jammy and document default behaviour
note that our default behaviour documentation won't be able to cover all end-user experiences. it just gives a baseline for expectations for "base" starting points.
our goal is to make sure end-users know the best non-interactive paths on the cloud using the Ubuntu default experiences (meaning we won't add instructions for all IT automation possibilities, but will document apt, needrestart, etc)