Implement the ability to change the ssh port to match what is in the gitea config

[christhomas]

This request just adjusts the ssh_config file to being a template, then applies the SSH_PORT value against it so it can be equal to the value which is being set inside the gitea configuration. It was previously hard-coded

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@b282d4e). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #7286   +/-   ##
=========================================
  Coverage          ?   41.22%           
=========================================
  Files             ?      467           
  Lines             ?    63342           
  Branches          ?        0           
=========================================
  Hits              ?    26111           
  Misses            ?    33822           
  Partials          ?     3409

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b282d4e...554a17d. Read the comment docs.

[zeripath]

There is no gitea.ini in docker/root/etc/templates/

[christhomas]

you need to check the files changed and you'll find it

[christhomas]

here see: docker/root/etc/templates/app.ini → docker/root/etc/templates/gitea.ini

[zeripath]

Sorry I missed that.

I think that's a breaking change unfortunately - it's already indirected from /etc/templates/app.ini to ${GITEA_CUSTOM}/conf/app.ini so I'm not certain that it needs to be changed.

[christhomas]

Why is it a breaking change? I can't see anything broken in the container that I built using this and I have online right now. What am I missing?

[techknowlogick]

Thanks for the continuation.

I’m not sure about this change for a few reasons, this is a breaking change due to the file rename (some downstream users reference it specifically), this port can be remapped using flags in the docker run command, as well we plan on moving to the built in ssh server which would allow this port to be defined without having to modify the openssh server.

[christhomas]

can you give an example of downstream users who use this file? Since it's in the docker root, it only applies to the docker configuration.

any downstream users can just adjust the file paths if they find their images don't work anymore. The change was to properly illustrate what file is configuring what software. Since I moved sshd_config to being a template too. It made more sense to have files named after the project they were configuring than a generic and ambiguous app.ini filename. In any case, I would like to know what downstream people you're referring to. But if you're insistent on the name being app.ini, I don't care enough about it to make a big deal about it, the problem I have is the port 22 for the openssh. I just wanted to be consistent in how the software defined it's filenames: app.ini is ambigious, gitea.ini is not.

the port is hardcoded to server on port 22 as per the sshd_config file, even if gitea changes the port it can't be actually changed to match what gitea is reporting. Thats the bug that is being fixed here. That gitea can report the ssh_port is 10022 and ssh is listening on port 22. It's not consistent.

in the meantime between now and the time that you actually do the change to the ssh server. I suggest we focus on fixing the actual bugs and then this issue can be "deprecated" when that happens. There is no reason why the software should be inconsistent until that time. Which is an undetermined point in the future.

[zeripath]

@techknowlogick I think this might actually be reasonable - we don't have rootless docker yet and this gives a reasonable feature for a very small changeset.

My only concern is the change from /etc/templates/app.ini to /etc/templates/gitea.ini - which although I agree would be a better name (/etc/templates/gitea/app.ini would be even better) - I don't think we should just change that right now. I can't guarantee that that change won't break other users who mutate the docker and given the isolated nature of docker containers I'm not certain that it matters that the name isn't perfect.

[christhomas]

This isn't a mountain I want to die on, I'll just change the filename. I care more about the ssh_config, I just felt that having app.ini and sshd_config next to each other meant a bit of ambiguity and I'm very active at my company in providing a consistent naming scheme and pushing towards a more perfect setup rather than leave things to rot and become even more inconsistent over time. I'm the main guy writing the docker setups there.

Give me a minute, I'll change it and push another change

[techknowlogick]

Thanks for PR :) Please note that the blocked label is just so this doesn't accidentally get merged into 1.9 which is in freeze mode right now. This will be merged into 1.10

[zeripath]

We need to add a breaking notice to docker to say that we're now shadowing /etc/sshd_config

[christhomas]

Would you like me to do that? If so, please let me know which files I should edit since I'm not part of your typical release team and I have no experience with your protocols. I can make the edits today if you let me know.

[zeripath]

TBH I don't know where to put it - It's more of a changelog thing really.

We have had a couple of users who have complained about us changing the dockerfiles before - unfortunately it's effectively part of our API.

[christhomas]

Then I guess it goes in the changelog then and we just have to assume that people read them :)

I could go on to explain that it's just a part of developing a tool that sometimes things change and people need to learn to cope with adapting themselves.

Otherwise, we end up making ourselves hostage to our past. Afraid to change things in case one person gets upset about it.

[techknowlogick]

Yes, a changelog item. So the label breaking label applied would take care of this when generating the changelog. Nothing else needs to be done.