doc(ubuntu): add ubuntu 24.11 instructions #25
67
ubuntu.md
|
|
@ -3,7 +3,7 @@
|
|||
I chose to remove this from the Alma doc since I never made any demonstration for its purpose. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
Setting up rootless podman on a fresh ubuntu 24.10 server.
|
||||
|
||||
> [!WARNING]
|
||||
> Perform `sudo apt update && sudo apt upgrade` immediately. Perform reboot if necessary
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> Perform `sudo apt update && sudo apt upgrade` immediately. Reboot system.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
## SSH
|
||||
|
||||
|
|
@ -26,7 +26,9 @@ ssh-copy-id username@remote_host
|
|||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
We don't want to allow anyone to login as root remotely ever. You must be a
|
||||
`sudoer` with public key auth to elevate to root.
|
||||
|
||||
SSH into your server and run `sudoedit /etc/ssh/sshd_config` See [stackoverflow question](https://superuser.com/questions/785187/sudoedit-why-use-it-over-sudo-vi) for reasons to use sudoedit over sudo.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
SSH into your server and run `sudoedit /etc/ssh/sshd_config`
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
See [stackoverflow question](https://superuser.com/questions/785187/sudoedit-why-use-it-over-sudo-vi) for reasons to use sudoedit over sudo.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
```bash
|
||||
## Uncomment PasswordAuthentication and set value to no
|
||||
|
|
@ -48,7 +50,9 @@ rootless environment for our containers to run in.
|
|||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
## Install
|
||||
|
||||
```bash
|
||||
dnf install podman
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
sudo apt install podman
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
## Make sure podman is running
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
systemctl enable --now podman
|
||||
```
|
||||
|
||||
|
|
@ -58,47 +62,45 @@ systemctl enable --now podman
|
|||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
## Prepare host networking stack
|
||||
|
||||
## slirp4netns
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
## Pasta or slirp4netns
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
> [!NOTE]
|
||||
> This may not be necessary but my system is currently using it.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> As of Podman 5.0 Pasta is the default rootless networking tool.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
>
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> Podman 5.0 is available in standard Ubuntu repo since 24.10.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
```bash
|
||||
dnf install slirp4netns
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
```
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
## Install DNS server for `podman`
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> [!NOTE]
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> Not sure how to resolve these correctly yet but the journal logs it
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> so it's running for something.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
```bash
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
dnf install aardvark-dns
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
sudo apt install passt
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
```
|
||||
|
||||
## Allow rootless binding port 80+
|
||||
|
||||
### Option 1: Modify range of unpriveleged ports
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> [!NOTE]
|
||||
> This is only necessary if you are setting up the reverse proxy.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> This is only necessary if you are setting up the reverse proxy (or any service on ports <1024).
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
`sudoedit /etc/sysctl.conf`
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
```bash
|
||||
printf '%s\n' 'net.ipv4.ip_unprivileged_port_start=80' > /etc/sysctl.d/99-unprivileged-port-binding.conf
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
sysctl 'net.ipv4.ip_unprivileged_port_start=80'
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
## Add the following line and save
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
net.ipv4.ip_unprivileged_port_start=80
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
```
|
||||
|
||||
## Allow containers to route within multiple networks
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
### Option 2: Redirect using firewalls
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
See [jdboyd blog post for PARTIAL examples using UFW, iptables, and nftables](https://blog.jdboyd.net/2024/05/exposing-privileged-ports-with-podman/)
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
```bash
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
printf '%s\n' 'net.ipv4.conf.all.rp_filter=2' > /etc/sysctl.d/99-reverse-path-loose.conf
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
sysctl -w net.ipv4.conf.all.rp_filter=2
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
```
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
>[!WARNING]
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> IF UTILIZING THIS METHOD
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
>
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> CREATE RULES TO ALLOW SSH BEFORE ENABLING THE FIREWALL
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
## Prepare container user
|
||||
|
||||
This user will be the owner of all containers with no login shell or root
|
||||
privileges.
|
||||
|
||||
Note $ctuser is a placeholder, replace with your username
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
```bash
|
||||
# Prepare a group id outside of the normal range
|
||||
groupadd --gid 2000 $ctuser
|
||||
|
|
@ -120,18 +122,17 @@ usermod --add-subuids 200000-299999 --add-subgids 200000-299999 $ctuser
|
|||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
loginctl enable-linger $ctuser
|
||||
```
|
||||
|
||||
> [!TIP]
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> Optionally setup ssh keys to directly login to $ctuser.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> [!NOTE]
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> The login shell doesn't exist. Launch `bash -l` manually to get a shell or
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> else your `ssh` will exit with a status of 1.
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
## Setup $ctuser env
|
||||
|
||||
>[!NOTE]
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> See the following for reasons to use machinectl instead of su
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> [RedHat blog post](https://www.redhat.com/en/blog/sudo-rootless-podman)
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
>
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
> [reddit post](https://old.reddit.com/r/linuxadmin/comments/rxrczr/in_interesting_tidbit_i_just_learned_about_the/)
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
```bash
|
||||
# Switch to user (`-i` doesn't work without a login shell)
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
sudo -u $ctuser bash -l
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
# Switch to $ctuser
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
machinectl shell $ctuser
|
||||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
# Create dirs
|
||||
mkdir -p ~/.config/{containers/systemd,environment.d} ~/containers/storage
|
||||
# Prepare `systemd --user` env
|
||||
|
|
|
|||
|
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
Can we correct the capitalization of 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. 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 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 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. 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 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 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 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 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. I chose to remove this from the Alma doc since I never made any demonstration for its purpose.
by name do you mean simply 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. 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 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 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). 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 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. 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 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 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: 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 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 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. 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 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 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. 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. 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. Sounds good to me. I'll look at breaking out some notes for basic firewall rules.
|
||||
Can we correct the capitalization of
Ubuntuthroughout 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
sudoeditis 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.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
useraddfussed 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/storageis 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.