doc(ubuntu): add ubuntu 24.11 instructions #25

Can we correct the capitalization of Ubuntu throughout the document, including the filename?

Can we correct the capitalization of `Ubuntu` throughout the document, including the filename?

I would rather this specify the parameters directly in the commandline, instead of depending on the defaults and the helper questions. It is not always possible to tab-complete or list the files in a directory while providing answers to an interactive CLI tool, which makes it rather easy to overwrite existing keys. Since you made a warning against such a mistake, let's just add the name to the commandline here to lead people more carefully.

Do you have any more official reference material for this? I do agree that sudoedit is more appropriate, but StackOverflow is not a resource that I have found to be reliable. I always have to slightly or heavily modify any answers, and that requires me to just go read a manpage or online docs anyway. We can just summarize the reason here as well.

Do you have any more official reference material for this? I do agree that `sudoedit` is more appropriate, but StackOverflow is not a resource that I have found to be reliable. I always have to slightly or heavily modify any answers, and that requires me to just go read a manpage or online docs anyway. We can just summarize the reason here as well.

You removed the sysctl -w ... command from my Alma doc here, but that command allows you to activate this setting without rebooting.

You removed the `sysctl -w ...` command from my Alma doc here, but that command allows you to activate this setting without rebooting.

Can some brief example be added directly to the doc here? I don't love linking to a personal blog, but there aren't many resources about this specific use-case out there. Hopefully their blog doesn't go offline anytime soon.

I did not know this. Can you clarify what range would be automatically generated, what size it is, and how to inspect it here in the document? I don't see this in the linked tutorial either.

I would like to remove this parameter entirely, since we're locking up the user anyway to prevent password login at all. I seem to remember that useradd fussed with me about omitting the password, but maybe we can discard it without needing to do extra cleanup?

I would like to remove this parameter entirely, since we're locking up the user anyway to prevent password login at all. I seem to remember that `useradd` fussed with me about omitting the password, but maybe we can discard it without needing to do extra cleanup?

I don't think Reddit is an appropriate resource to link out to either, especially since they are heavily restricting users from accessing content on their platform unless you login and do not use any VPN. Could the information from the RH blog post be summarized briefly here instead?

I would like to clarify why ~/containers/storage is created as well. I don't think it gets utilized in this doc, so there isn't any indication as to what it's for.

I would like to clarify why `~/containers/storage` is created as well. I don't think it gets utilized in this doc, so there isn't any indication as to what it's for.

I chose to remove this from the Alma doc since I never made any demonstration for its purpose.

by name do you mean simply ssh-keygen -t ed25519 ?

by name do you mean simply `ssh-keygen -t ed25519` ?

Sadly I cannot find a solid official reference for this one, the manpage is probably the best. I think the top/accepted answer is fairly reasonable/simple but i think we could remove the link either way.

It is missing from that specific command in the Alma doc, you do however have it in the command right after it. I removed the second command from my docs because it is already the default. However, do you think maybe we should add it back? It doesn't really do any harm and ensures proper setup

I'm on the fence with this one now, enabling a firewall before adding rules to allow SSH could lock someone out of their server. In any case, I think i found two better sources debian wiki and baeldung port redirection We could include one or both, or just remove that option entirely.

I'm on the fence with this one now, enabling a firewall before adding rules to allow SSH could lock someone out of their server. In any case, I think i found two better sources [debian wiki](https://wiki.debian.org/Firewalls-local-port-redirection) and [baeldung port redirection](https://www.baeldung.com/linux/port-redirection) We could include one or both, or just remove that option entirely.

I followed your guide but it wasn't until the end where I ran podman system migrate I ran into an error. I just took it as differences between our distros.

My initial server user
/etc/subuid:mainuser:100000:65536
/etc/subgid:mainuser:100000:65536

User created for containers
This had 4 entries: the two we add from docs, plus the two following
/etc/subuid:containeruser:165536:34464
/etc/subgid:containeruser:165536:34464

I followed your guide but it wasn't until the end where I ran `podman system migrate` I ran into an error. I just took it as differences between our distros. ``` My initial server user /etc/subuid:mainuser:100000:65536 /etc/subgid:mainuser:100000:65536 User created for containers This had 4 entries: the two we add from docs, plus the two following /etc/subuid:containeruser:165536:34464 /etc/subgid:containeruser:165536:34464 ```

Do we expect people to copy/paste or write these in? If copy/paste we could take advantage of $HISTCONTROL provided it is set to ignore lines starting with space (it is set by default on my system).

I will try to summarize, i think the github issues the reddit thread pointed to better explain it. https://github.com/systemd/systemd/issues/825#issuecomment-127917622 and https://github.com/systemd/systemd/pull/1022#issuecomment-136133244

Specifically the filename, at least, but I'm not sure why this line is different from the Alma doc at all.

The main issue is that the top answer can change at any time, or be edited out from underneath us. This doesn't happen super often, but it's just something I rather avoid.

Additionally, I'm not sure why we are doing a sudo edit at all. In the Alma doc, I use the /etc/ssh/ssh_config.d/ directory. Isn't this just as good, or maybe even better because it's easier to copy and paste? Should I be revising this in the Alma doc instead?

The main issue is that the top answer can change at any time, or be edited out from underneath us. This doesn't happen super often, but it's just something I rather avoid. Additionally, I'm not sure why we are doing a sudo edit at all. In the Alma doc, I use the `/etc/ssh/ssh_config.d/` directory. Isn't this just as good, or maybe even better because it's easier to copy and paste? Should I be revising this in the Alma doc instead?

I had sysctl ... in both, but this one was missing -w. If Ubuntu has sane default already for the second option, there's probably no reason to add it back unless there's risk of Ubuntu changing it. Seems unlikely yeah?

I'll defer to you because I don't use Ubuntu.

I had `sysctl ...` in both, but this one was missing `-w`. If Ubuntu has sane default already for the second option, there's probably no reason to add it back unless there's risk of Ubuntu changing it. Seems unlikely yeah? I'll defer to you because I don't use Ubuntu.

Baeldung gives me content farm vibes, even if it's sort of okay at relaying mostly real information. I'm gonna have to avoid that one because I personally just don't trust what they're doing in that place. The Debian wiki looks good.

I run all my self-hosting out of my home network, where I don't need a firewall at the server itself. I have a firewall at the edge of my network handling any intrusion prevention and filtering. If someone is running on a VPS remotely instead, for example, they probably do need to work on their firewall directly. I could see some firewall tips becoming a separate document maybe, just to cover a few sticky points about things like this. What do you think?

Baeldung gives me content farm vibes, even if it's sort of okay at relaying mostly real information. I'm gonna have to avoid that one because I personally just don't trust what they're doing in that place. The Debian wiki looks good. I run all my self-hosting out of my home network, where I don't need a firewall at the server itself. I have a firewall at the edge of my network handling any intrusion prevention and filtering. If someone is running on a VPS remotely instead, for example, they probably **do** need to work on their firewall directly. I could see some firewall tips becoming a separate document maybe, just to cover a few sticky points about things like this. What do you think?

Hmm, I'm not sure then. My brain is foggy on some of the details for initial config of the system because my POC server has drifted a fair bit away from the actual doc after the past 2 months working on this project.

I see now that I have this:

rbm:100000:65536
ct:231072:65536
ct:300000:100000

Really unclear why that is, unless it's some post-setup edits I did because I also rebuilt my container user without rebuilding my whole server from scratch.

Hmm, I'm not sure then. My brain is foggy on some of the details for initial config of the system because my POC server has drifted a fair bit away from the actual doc after the past 2 months working on this project. I see now that I have this: ``` rbm:100000:65536 ct:231072:65536 ct:300000:100000 ``` Really unclear why that is, unless it's some post-setup edits I did because I also rebuilt my container user without rebuilding my whole server from scratch.

It'll be a mix of manual typing and copy/paste. The commands often require an edit, especially because I don't advise anywhere to create a shell variable or env var for $ctuser. That would result in empty string if the user is just pasting commands, which will error in every case in these docs I believe.

I thought of the space trick too. I think that's pretty iffy to expect people to leave the leading space in their commands.

However, on some (all?) systems you can just cat /etc/shadow to see the user's password. If someone can get to the bash history, they can also already sudo to any user unless additional restrictions are in place right? I don't know the best solution here, which is why I just didn't address it probably.

It'll be a mix of manual typing and copy/paste. The commands often require an edit, especially because I don't advise anywhere to create a shell variable or env var for `$ctuser`. That would result in empty string if the user is just pasting commands, which will error in every case in these docs I believe. I thought of the space trick too. I think that's pretty iffy to expect people to leave the leading space in their commands. However, on some (all?) systems you can just `cat /etc/shadow` to see the user's password. If someone can get to the bash history, they can also already sudo to any user unless additional restrictions are in place right? I don't know the best solution here, which is why I just didn't address it probably.

The github comments are from Poettering himself, so they're a very reasonable reference.

Additionally, the reverse proxy isn't even a required thing. I have only prepared a quadlet for caddy specifically so far. I have this in my Alma doc because it was part of my personal process and setup, but maybe we don't need to include it.

Additionally, the reverse proxy isn't even a required thing. I have only prepared a quadlet for `caddy` specifically so far. I have this in my Alma doc because it was part of my personal process and setup, but maybe we don't need to include it.

Permission issues, atleast on Ubuntu I can't write to either of those without sudo/sudoedit. I do like /etc/ssh/ssh_config.d/ better though. I will revert to your commands and append sudo to them. Had to modify slightly using tee to write to file

Permission issues, atleast on Ubuntu I can't write to either of those without sudo/sudoedit. I do like `/etc/ssh/ssh_config.d/` better though. I will revert to your commands and append sudo to them. Had to modify slightly using tee to write to file

You're correct, i think maybe the firewall part should be a separate document. We should probably keep the caddy part considering selfhosters/consumers of the guide will be using a reverse proxy.

I think leaving the command as is. I think maybe we just leave the note which should allow people to search for the solution on their own. There are plenty of resources on that.

Sounds good to me. I'll look at breaking out some notes for basic firewall rules.