fmt:/etc# ls -l *id
-rw-r--r-- 1 root root 18 Dec 30 06:06 subgid
-rw-r--r-- 1 root root 18 Dec 30 06:06 subuid
fmt:/etc# cat *id
root:100000:65536
root:100000:65536
fmt:/etc#
This allows root to create unprivileged LXC containers, but not anybody else.
subuid and subgid files need to have one entry per user, on non-overlapping ranges.
Once assigned, the range cannot change, otherwise the user's containers cannot start again.
I'd suggest deriving user ranges from their uids.
@yoursunny Thanks for yet another of your helpful and interesting comments!
@yoursunny said: This allows root to create unprivileged LXC containers, but not anybody else.
Do you see any issue with allowing non-root users to create their own containers? I was thinking of trying to set up LXC so that the containers each had their own IPv4 and IPv6/64.
@yoursunny said: I'd suggest deriving user ranges from their uids.
I haven't tried this yet, but it seems like a wonderful way to use getent and awk to derive user ranges! I would enjoy more context. For example, I took a quick look at the server's getent(1) man page. But that man page provided little historical context.
May I please ask where did you get this idea? Do you have a link to an LXC setup tutorial that discusses this method? I did a quick Google search and didn't find this idea for configuring user ranges.
@Not_Oles said: @yoursunny Thanks for yet another of your helpful and interesting comments!
@yoursunny said: This allows root to create unprivileged LXC containers, but not anybody else.
Do you see any issue with allowing non-root users to create their own containers? I was thinking of trying to set up LXC so that the containers each had their own IPv4 and IPv6/64.
A container created by a non-root user would not have more privileges than that user.
Address assignment is the next step: network bridge and lxc-usernet file.
@yoursunny said: I'd suggest deriving user ranges from their uids.
I haven't tried this yet, but it seems like a wonderful way to use getent and awk to derive user ranges! I would enjoy more context. For example, I took a quick look at the server's getent(1) man page. But that man page provided little historical context.
You can safely run this command line to see its effect.
It only prints the subuid map, but does not modify any files.
May I please ask where did you get this idea? Do you have a link to an LXC setup tutorial that discusses this method? I did a quick Google search and didn't find this idea for configuring user ranges.
These come from subuid manpage.
In my own server I only have one entry lxc:100000:65536 that allows a user named lxc to create containers.
We accept Karma donations for the last flan. 🍮 affbrr
Happy New Year everyone! I hope you continue to enjoy our time on this server!
I especially thank those who have thanked me for and posted replies to my server setup reports. Some of these have drawn so few thanks and so few comments that I considered no longer posting setup updates and transcripts.
For example, here's a recent update that did not previously get posted:
Since you are new here at LES we can say that your being new helps us celebrate the new in the New Year.
Do you want to share a little about who and where you are and what you want to do on the server?
Thanks!
Tom
Thank you, I wish you a happy new year, I am a student from China, I already have two vps, but I haven't used alpine yet, so I want to try it, I will run a web service on it or telegram bot or something
Since you are new here at LES we can say that your being new helps us celebrate the new in the New Year.
Do you want to share a little about who and where you are and what you want to do on the server?
Thanks!
Tom
Thank you, I wish you a happy new year, I am a student from China, I already have two vps, but I haven't used alpine yet, so I want to try it, I will run a web service on it or telegram bot or something
Access control for LXD is based on group membership.
The root user and all members of the lxd group can interact with the local daemon.
Anyone with access to the LXD socket can fully control LXD, which includes the ability to attach host devices and file systems.
In contrast, LXC doesn't have a local daemon.
Each user can launch their own unprivileged containers, without being able to access other users' containers.
We accept Karma donations for the last flan. 🍮 affbrr
May we please go easy on this kind of language here in this thread? Yes, I do appreciate the linguistic humor, maybe"tinker" vs "tinkle." But there are plenty enough other threads for humor. Thanks very much!
@drunekndog said: Why not LXD? It's a lot more usable than plain LXC.
Hi! LXD probably is okay. Certainly I have nothing against LXD. I myself haven't got to LXD yet. As of course you know, LXD is built on top of LXC. I imagined it might be a good idea to learn a little about how the LXC foundation worked before moving on to LCD.
Since you are new here at LES we can say that your being new helps us celebrate the new in the New Year.
Do you want to share a little about who and where you are and what you want to do on the server?
Thanks!
Tom
Thank you, I wish you a happy new year, I am a student from China, I already have two vps, but I haven't used alpine yet, so I want to try it, I will run a web service on it or telegram bot or something
I am a university student. In fact, I am not learning computer related, but I am very interested in the computer. We learned C. Now I want to learn Python during the holidays
Since you are new here at LES we can say that your being new helps us celebrate the new in the New Year.
Do you want to share a little about who and where you are and what you want to do on the server?
Thanks!
Tom
Thank you, I wish you a happy new year, I am a student from China, I already have two vps, but I haven't used alpine yet, so I want to try it, I will run a web service on it or telegram bot or something
I am a university student. In fact, I am not learning computer related, but I am very interested in the computer. We learned C. Now I want to learn Python during the holidays
Apologies @yoursunny! I am keeping the list locally. I haven't yet updated the subuid and subgid files on the server. I assumed I maybe could update the files on the server one time after the list seemed to be complete.
Due to your constant and careful study of everything in all six directions, you caught my laziness.
Guys, almost the last chance for this batch of LXC chicken. The next batch might be awhile. . . . Anybody else wanna jump on the LXC train?
@yoursunny said: Address assignment is the next step: network bridge and lxc-usernet file.
Just got a copy of the bridge setup I have been using elsewhere. 🔜 I hope. Thank you!
Been using metalvps as a build machine for the multiple VPSs running NixOS. Compiling software from source on this thing is fast!
It usually take my own PC 20 minutes to finish compiling Zerotier (NixOS doesn't keep its binary on their repo for licensing reasons) but just couple minutes on metalvps!
@drunekndog said:
Why not LXD? It's a lot more usable than plain LXC.
Why not LXC?
It's a lot more efficient than fancy LXD.
I don't buy this; it seems a lot like complaints about ipv6 using more resources than ipv4: it may exist in theory, but it's unlikely to make a big impact in practice.
An important technical limitation of LXD is the lack of isolation between host machine users authorized to create containers.
Access control for LXD is based on group membership.
The root user and all members of the lxd group can interact with the local daemon.
Anyone with access to the LXD socket can fully control LXD, which includes the ability to attach host devices and file systems.
In contrast, LXC doesn't have a local daemon.
Each user can launch their own unprivileged containers, without being able to access other users' containers.
@Not_Oles said:
Is it too crazy just to give each container its own static WAN IPv4 and IPv6/64 ?
I'd rather use NAT'ed IPv4, so that more containers can be accommodated.
auto lxcbr0
iface lxcbr0 inet static
bridge-ports eth1
Bridging containers directly on the physical port may result in the containers' MAC addresses becoming visible on the physical network.
I don't know about Cloudie, but doing this in KVM would get filtered in Virtualizor, and doing this on Hetzner would trigger infraction warning letter.
We accept Karma donations for the last flan. 🍮 affbrr
Since you are new here at LES we can say that your being new helps us celebrate the new in the New Year.
Do you want to share a little about who and where you are and what you want to do on the server?
Thanks!
Tom
Thank you, I wish you a happy new year, I am a student from China, I already have two vps, but I haven't used alpine yet, so I want to try it, I will run a web service on it or telegram bot or something
I am a university student. In fact, I am not learning computer related, but I am very interested in the computer. We learned C. Now I want to learn Python during the holidays
@raveen2k3 said:
hey ,
What are The Requirements to get this :-P
hey ,
Congrats on your First Post
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
Thanks for your helpful, relevant, and interesting comments!
@yoursunny said: I'd rather use NAT'ed IPv4, so that more containers can be accommodated.
May I please ask, how many containers do you think we should accommodate?
@yoursunny said: Bridging containers directly on the physical port may result in the containers' MAC addresses becoming visible on the physical network.
I don't know about Cloudie, but doing this in KVM would get filtered in Virtualizor, and doing this on Hetzner would trigger infraction warning letter.
What we previously did at Hetzner was assign VMs an IPv4/32. If I understand correctly, having the VMs use link layer prevented the issue of the VM MAC addresses becoming visible. A difference between what formerly was at Hetzner and what is happening now at Cloudie was that, at Hetzner, the extra IPs were out of band relative to the server's main IPv4. The /etc/network/interfaces file formerly in use at Hetzner looked something like that shown below.
May I please ask, assuming for the purpose of the question that we stick to assigning VMs individual IPv4s and do not do NAT, would assigning IPv4/32s to the VMs mitigate the MAC address leak without having the extra IPs out of band with respect to the main IP? If no, could adding an additional main IPv4 and gateway from Cloudie plus using link layer solve the MAC address leak problem as it apparently did at Hetzner?
May I please ask what do others think about whether we should do NAT or assign individual IPs? And, how many containers do others think we should have?
root@fsn1 ~ # cat /etc/network/interfaces
### Hetzner Online GmbH installimage
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
iface lo inet6 loopback
auto enp7s0
iface enp7s0 inet static
address 157.90.35.101
netmask 255.255.255.255
gateway 157.90.35.65
pointopoint 157.90.35.65
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up echo 0 > /proc/sys/net/ipv4/conf/enp7s0/send_redirects
iface enp7s0 inet6 static
address 2a01:4f8:251:595a::2
netmask 128
gateway fe80::1
post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
auto vmbr0
iface vmbr0 inet static
address 157.90.35.101
netmask 255.255.255.255
bridge_ports none
bridge_stp off
bridge_fd 0
bridge_maxwait 0 pre-up brctl addbr vmbr0
post-up ip route add 148.251.166.96/32 dev vmbr0
pre-down ip route del 148.251.166.96/32 dev vmbr0
post-up ip route add 148.251.166.97/32 dev vmbr0
pre-down ip route del 148.251.166.97/32 dev vmbr0
[ . . . ]
post-up ip route add 148.251.166.111/32 dev vmbr0
pre-down ip route del 148.251.166.111/32 dev vmbr0
iface vmbr0 inet6 static
address 2a01:4f8:251:595a::2
netmask 64
root@fsn1 ~ #
@yoursunny said: I'd rather use NAT'ed IPv4, so that more containers can be accommodated.
May I please ask, how many containers do you think we should accommodate?
Typically, I create one LXC container for each app or use case.
In my closet server, there are separate containers for C++ development and Go development, plus one for push-up video encoding (ffmpeg with iGPU access).
MetalVPS-fmt has dozens of accounts.
You would eventually run out of dedicated IPv4 if everyone wants an IPv4.
Thus, NAT is unavoidable.
would assigning IPv4/32s to the VMs mitigate the MAC address leak
In my closet server, I just let the MAC addresses leak, and the home router gives each container its own IPs.
Datacenter switches might not like this.
In my KVM servers, the bridge for LXC containers has NAT'ed IPv4 and routed IPv6.
It's defined in Netplan.io like this:
I see from your profile that you are new here. Welcome to LES! It is great to meet you!
Want to introduce yourself? I'm sure everyone would be interested to know your name, where you are from, and something about your Linux experience. Also, what do you want to do on the server?
I don't know whether this is at all correct, but here, quoting from above, I fixed a couple of little mistakes. The changed lines are followed by comments.
@Not_Oles said: Next up: lxc-usernet file, maybe tomorrow, it's getting late here:
fmt:~# man lxc-usernet # Works!
fmt:~# cat /etc/lxc/lxc-usernet
cat: can't open '/etc/lxc/lxc-usernet': No such file or directory
fmt:~#
Okay, it's tomorrow already!
From man lxc-usernet(5):
This file consists of multiple entries, one per line, of the form:
user type bridge number
So here's lxc-usernet:
fmt:~# ls /etc/lxc
default.conf
fmt:~# touch /etc/lxc/lxc-usernet # The busybox version of ed editor can edit existing files but seemingly can't create files!
fmt:~# cat /etc/subuid
root:100000:65536
notoles:1000000000:65536
localhost:1002000000:65536
Fritz:1005000000:65536
yoursunny:1018000000:65536
subenhon:1022000000:65536
fmt:~# ed /etc/lxc/lxc-usernet # ed editor allows me to see what was printed in the terminal just before I started editing.
0
a
notoles veth lxcbr0 1 # I am guessing that root doesn't need an entry in the lxc-usernet file, but I am not sure.
localhost veth lxcbr0 1
Fritz veth lxcbr0 1
yoursunny veth lxcbr0 1
subenhon veth lxcbr0 1
.
w
113
q
fmt:~#
LXC still is not expected to work yet partly because lxcbr0 isn't present because /etc/network/interfaces hasn't been updated yet. There is no bridge in the current setup. I sent the possible new interfaces configuration to Cloudie, so we will see what he says.
Hi @yoursunny! Thanks for letting me know your preference! Would it be okay with you to leave the lxc-usernet number at 1 until we hopefully find that everyone can make a container that works? Then we could increase the number. However, if you or anyone else needs a larger number from the beginning, please just let me know, and I will increase the number.
I see from your profile that you are new here. Welcome to LES! It is great to meet you!
Want to introduce yourself? I'm sure everyone would be interested to know your name, where you are from, and something about your Linux experience. Also, what do you want to do on the server?
I'm looking forward to hearing more from you!
Best wishes and kindest regards,
Tom
Hi
Actually I'm new to this forum kind of stuffs , More like this is first forum I've joined .
And I'm Actually from India,
I've been Using a Debian 11 for nearly a year , I'm new to linux community though
I've been looking for a free server to host some of python projects , most likely telegram and Discord Bots That I've made ,
Also I've never used any other distro than debian, i would love to explore a new distro :-)
Comments
Friendly greetings!
I would like to have one thx
This allows root to create unprivileged LXC containers, but not anybody else.
subuid and subgid files need to have one entry per user, on non-overlapping ranges.
Once assigned, the range cannot change, otherwise the user's containers cannot start again.
I'd suggest deriving user ranges from their uids.
We accept Karma donations for the last flan. 🍮 affbrr
Hi @g121!
Best wishes for a Happy New Year!
Since you are new here at LES we can say that your being new helps us celebrate the new in the New Year.
Do you want to share a little about who and where you are and what you want to do on the server?
Thanks!
Tom
@yoursunny Thanks for yet another of your helpful and interesting comments!
Do you see any issue with allowing non-root users to create their own containers? I was thinking of trying to set up LXC so that the containers each had their own IPv4 and IPv6/64.
I haven't tried this yet, but it seems like a wonderful way to use
But that man page provided little historical context.
getentandawkto derive user ranges! I would enjoy more context. For example, I took a quick look at the server's getent(1) man page.May I please ask where did you get this idea? Do you have a link to an LXC setup tutorial that discusses this method? I did a quick Google search and didn't find this idea for configuring user ranges.
Thanks again and a very happy new year!
A container created by a non-root user would not have more privileges than that user.
Address assignment is the next step: network bridge and lxc-usernet file.
You can safely run this command line to see its effect.
It only prints the subuid map, but does not modify any files.
These come from subuid manpage.
In my own server I only have one entry
lxc:100000:65536that allows a user named lxc to create containers.We accept Karma donations for the last flan. 🍮 affbrr
Happy New Year
Happy New Year everyone! I hope you continue to enjoy our time on this server!
I especially thank those who have thanked me for and posted replies to my server setup reports. Some of these have drawn so few thanks and so few comments that I considered no longer posting setup updates and transcripts.
For example, here's a recent update that did not previously get posted:
Man pages update
I was wondering why I couldn't seem to see many man pages on the server. Looking around on Google, I found that, in Alpine, man pages frequently are an additional package with the name $package-doc. I found a neat trick at https://georgegarside.com/blog/technology/alpine-linux-install-all-man-pages/:
apk list -I | sed -rn '/-doc/! s/([a-z-]+[a-z]).*/\1/p' | xargs -tI§ apk add §-docThis trick seemed to work to install a lot of the man pages which were not installed because I didn't add $package-doc to
apk add $package.I won't post the lengthy output of this command, but I have it if anybody wants to see it.
If you find a man page that still seems missing, please let me know, and I will try to add it. Thanks!
Are people interested in continuing setup update posts?
Thank you, I wish you a happy new year, I am a student from China, I already have two vps, but I haven't used alpine yet, so I want to try it, I will run a web service on it or telegram bot or something
Hi @g121!
Could you please post your ed25519 public key?
May I please ask whether you are a high school student or a university student? Are you studying or do you want to study computer engineering?
Best wishes!
Tom
Maybe I should at least look around a little. . . .
Anybody else want in on LXC? Thanks!
Noted. Thanks for your help!
Hmm, the subuid manpage doesn't seem to be installed on fmt. How did I miss it? What apk package has it?
Why not LXD? It's a lot more usable than plain LXC.
Why not LXC?
It's a lot more efficient than fancy LXD.
An important technical limitation of LXD is the lack of isolation between host machine users authorized to create containers.
From LXD installation:
In contrast, LXC doesn't have a local daemon.
Each user can launch their own unprivileged containers, without being able to access other users' containers.
We accept Karma donations for the last flan. 🍮 affbrr
>
I'd love to Tinkle with lxc..
Hi @localhost!
You are in. But it's not quite ready yet. So please keep watching this thread, and maybe helping me out with the configuration.
May we please go easy on this kind of language here in this thread? Yes, I do appreciate the linguistic humor, maybe"tinker" vs "tinkle." But there are plenty enough other threads for humor. Thanks very much!
Hi! LXD probably is okay. Certainly I have nothing against LXD. I myself haven't got to LXD yet. As of course you know, LXD is built on top of LXC. I imagined it might be a good idea to learn a little about how the LXC foundation worked before moving on to LCD.
Thanks @yoursunny! I appreciate your mentioning efficiency and isolation.
Do we get a fancy LCD screen once we aced the LXC game?
DM us for private tracker invite.
Redacted. Wrong thread clicked.
Cloudcone | Crunchbits | Dartnode | Dedirock | Georgedatacenter | Gigahost | Hostbilby | Host-c | Hostdzire | Hostsailor | Namecrane | Nuyek | Realtoxmedia | Servarica | Terabit | Tnahosting | Virmach
I would like to try it.
Count me in.Thanks!
You are in!
I'm interested, can i use this for building APKs ?
it will involve abuild and aports;
https://wiki.alpinelinux.org/wiki/Include:Abuild
https://wiki.alpinelinux.org/wiki/Aports_tree
Fuck this 24/7 internet spew of trivia and celebrity bullshit.
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIATk14TvQ1rBHNPAIvStuSK6OsHQKn8gXxkYa890+4TP
I am a university student. In fact, I am not learning computer related, but I am very interested in the computer. We learned C. Now I want to learn Python during the holidays
Maybe. But also maybe you are posting in the way you described yourself on your LES profile?
Best wishes!
Hi @g121!
Hope you have fun learning Python! Hope your new account can help you learn!
You should be able to get in via IPv4 or IPv6 with your ssh key using something like:
ssh [email protected] -p 42365Your account password is in a file in your home directory. Please change your password.
Please let us know if you can login okay!
I am looking forward to seeing your post here in this thread about fun stuff you accomplish on the server. Congrats in advance!
Best!
Tom
unfortunately, yes
Fuck this 24/7 internet spew of trivia and celebrity bullshit.
May I jump in also @Not_Oles 😁
https://microlxc.net/
None of the
subuidsubgidsettings are actually deployed :'(We accept Karma donations for the last flan. 🍮 affbrr
Yep! Welcome again, @Fritz!
Apologies @yoursunny! I am keeping the list locally. I haven't yet updated the subuid and subgid files on the server. I assumed I maybe could update the files on the server one time after the list seemed to be complete.
Due to your constant and careful study of everything in all six directions, you caught my laziness.
Guys, almost the last chance for this batch of LXC chicken. The next batch might be awhile. . . . Anybody else wanna jump on the LXC train?
Just got a copy of the bridge setup I have been using elsewhere. 🔜 I hope. Thank you!
Thanks Tom for letting me in. 😘
https://microlxc.net/
Been using metalvps as a build machine for the multiple VPSs running NixOS. Compiling software from source on this thing is fast!
It usually take my own PC 20 minutes to finish compiling Zerotier (NixOS doesn't keep its binary on their repo for licensing reasons) but just couple minutes on metalvps!
DM us for private tracker invite.
Okay, here are the /etc/sub*id files.
👨💻
I don't buy this; it seems a lot like complaints about ipv6 using more resources than ipv4: it may exist in theory, but it's unlikely to make a big impact in practice.
Ooh, completely missed this. Thanks for the info!
Today's updates; add bridge-utils-doc
New /etc/network/interfaces ?
Currently installed:
Is it too crazy just to give each container its own static WAN IPv4 and IPv6/64 ?
Does the following look right for a first pass at the new /etc/network/interfaces?
Next up:
lxc-usernetfile, maybe tomorrow, it's getting late here:I'd rather use NAT'ed IPv4, so that more containers can be accommodated.
Bridging containers directly on the physical port may result in the containers' MAC addresses becoming visible on the physical network.
I don't know about Cloudie, but doing this in KVM would get filtered in Virtualizor, and doing this on Hetzner would trigger infraction warning letter.
We accept Karma donations for the last flan. 🍮 affbrr
All working> @Not_Oles said:
All working ,thank you for everything you do
hey ,
What are The Requirements to get this :-P
hey ,
Congrats on your First Post
"A single swap file or partition may be up to 128 MB in size. [...] [I]f you need 256 MB of swap, you can create two 128-MB swap partitions." (M. Welsh & L. Kaufman, Running Linux, 2e, 1996, p. 49)
Just tell @Not_Oles how great he is so he can add the quote to his wall of self-gratification.
Hi @yoursunny!
Thanks for your helpful, relevant, and interesting comments!
May I please ask, how many containers do you think we should accommodate?
What we previously did at Hetzner was assign VMs an IPv4/32. If I understand correctly, having the VMs use link layer prevented the issue of the VM MAC addresses becoming visible. A difference between what formerly was at Hetzner and what is happening now at Cloudie was that, at Hetzner, the extra IPs were out of band relative to the server's main IPv4. The /etc/network/interfaces file formerly in use at Hetzner looked something like that shown below.
May I please ask, assuming for the purpose of the question that we stick to assigning VMs individual IPv4s and do not do NAT, would assigning IPv4/32s to the VMs mitigate the MAC address leak without having the extra IPs out of band with respect to the main IP? If no, could adding an additional main IPv4 and gateway from Cloudie plus using link layer solve the MAC address leak problem as it apparently did at Hetzner?
May I please ask what do others think about whether we should do NAT or assign individual IPs? And, how many containers do others think we should have?
Typically, I create one LXC container for each app or use case.
In my closet server, there are separate containers for C++ development and Go development, plus one for push-up video encoding (ffmpeg with iGPU access).
MetalVPS-fmt has dozens of accounts.
You would eventually run out of dedicated IPv4 if everyone wants an IPv4.
Thus, NAT is unavoidable.
In my closet server, I just let the MAC addresses leak, and the home router gives each container its own IPs.
Datacenter switches might not like this.
In my KVM servers, the bridge for LXC containers has NAT'ed IPv4 and routed IPv6.
It's defined in Netplan.io like this:
There's also a systemd service that sets static binding of container IP ranges (each container gets IPv4 /24 and IPv6 /116) and MAC addresses.
I don't know what to do in interfaces file, as it's no longer preferred for Ubuntu.
We accept Karma donations for the last flan. 🍮 affbrr
Hi @raveen2k3!
I see from your profile that you are new here. Welcome to LES! It is great to meet you!
Want to introduce yourself? I'm sure everyone would be interested to know your name, where you are from, and something about your Linux experience. Also, what do you want to do on the server?
I'm looking forward to hearing more from you!
Best wishes and kindest regards,
Tom
I don't know whether this is at all correct, but here, quoting from above, I fixed a couple of little mistakes. The changed lines are followed by comments.
Okay, it's tomorrow already!
From man lxc-usernet(5):
So here's lxc-usernet:
LXC still is not expected to work yet partly because lxcbr0 isn't present because /etc/network/interfaces hasn't been updated yet. There is no bridge in the current setup. I sent the possible new interfaces configuration to Cloudie, so we will see what he says.
Best wishes and kindest regards!
Need larger numbers, e.g. 16.
root account shouldn't be used except for modifying system settings.
We accept Karma donations for the last flan. 🍮 affbrr
Hi @yoursunny! Thanks for letting me know your preference!
Would it be okay with you to leave the lxc-usernet number at 1 until we hopefully find that everyone can make a container that works? Then we could increase the number. However, if you or anyone else needs a larger number from the beginning, please just let me know, and I will increase the number.
Tshark and friends
Thanks ;-)
Hi
Actually I'm new to this forum kind of stuffs , More like this is first forum I've joined .
And I'm Actually from India,
I've been Using a Debian 11 for nearly a year , I'm new to linux community though
I've been looking for a free server to host some of python projects , most likely telegram and Discord Bots That I've made ,
Also I've never used any other distro than debian, i would love to explore a new distro :-)