@natvps_uk said:
The reason to go with RSA is down to support, all of our templates support it out of the box and it should simplify the community templates quite a lot.
Dropbear ed25519 support is fairly recent and is not available on all of the distros that we offer meaning that ed25519 support would provide a poor user experience.
You shouldn't be picky about algorithm.
Just let the user specify contents of authorized_keys file.
Whatever user enters there are automatically uploaded to every new server.
Yes, long-bit RSA keys are still safe, but ed25519 provides lighter and faster performance (which is unnoticeable in almost every scenario). Since your control panel is a somewhat new one, I though both very stable algorithm and cutting-edge algorithm will be support. It's just like you are supporting mp3 format instead of opus in a new project.
Now that you mentioned ed25519 may be supported in future, I guess it's fine to everyone.
Yoursunny said what I want: users just paste their keys, which the control panel appends to authorized_keys.
@natvps_uk said:
The reason to go with RSA is down to support, all of our templates support it out of the box and it should simplify the community templates quite a lot.
Dropbear ed25519 support is fairly recent and is not available on all of the distros that we offer meaning that ed25519 support would provide a poor user experience.
You shouldn't be picky about algorithm.
Just let the user specify contents of authorized_keys file.
Whatever user enters there are automatically uploaded to every new server.
Yes, long-bit RSA keys are still safe, but ed25519 provides lighter and faster performance (which is unnoticeable in almost every scenario). Since your control panel is a somewhat new one, I though both very stable algorithm and cutting-edge algorithm will be support. It's just like you are supporting mp3 format instead of opus in a new project.
Now that you mentioned ed25519 may be supported in future, I guess it's fine to everyone.
Yoursunny said what I want: users just paste their keys, which the control panel append to authorized_keys.
I get this, and understand both of your points above but RSA is supported on all of our templates, and is supported by most/all distros.
We're going for stability/support rather than cutting edge to provide the best end user experience overall. Once all of our templates support ed25519 we will look to implement it although with the future community templates release we can't guarantee that these templates will support ed25519.
We will add support when possible, if you want to use a ed25519 key its pretty simple, ensure that your ssh server supports it and add it to your authorized keys file.
@natvps_uk said: So when a user uploads an unsupported key what happens then? They create a support ticket creating unnecessary support and have an overall poor experience or fall back to using password based auth which we are trying to avoid.
Well, I believe the omniscient MaxMind will solve that case in the first step.
Oh the above is a joke. Honestly speaking, I don't think it's a problem, because all your service is "unmanaged", so I don't think you should or will offer support in such annoying cases. Plus most your competitors offer "rescue mode" in such case, which the user alone can handle.
@natvps_uk said: We will add support when possible, if you want to use a ed25519 key its pretty simple, ensure that your ssh server supports it and add it to your authorized keys file.
Thanks for explaining.
I think most people have adopted this way:
1. Set root password or paste a public key (if support) when order;
2. log into the system;
3. Config sshd_config to disable password login;
Maybe you should give users a choice to "opt in" for your compulsory key login, if the control panel you bought has that option.
@bliss said: Maybe you should give users a choice to "opt in" for your compulsory key login, if the control panel you bought has that option.
We wrote the control panel in house so additions like this are possible, SSH keys will eventually become compulsory for all instances although there is no planned date for deprecating password based login.
2 major deployments in one day! This one has been requested a lot by our clients.
We have added bandwidth monitoring, we will be adding some dashboards in a future release to allow Micronode users to drill down into their bandwidth usage in a time series graph for both RX and TX.
This new release allows clients to see their combined usage per VPS/Instance.
Please note that whilst it is out of a 1000GB total this is just a guideline and your services will not be suspended if you breach this figure unless you are impacting the network performance for the entire node in which case you will be reminded that network is fair use, usage stats are reset monthly on the 1st of each month.
@natvps_uk said:
2 major deployments in one day! This one has been requested a lot by our clients.
We have added bandwidth monitoring, we will be adding some dashboards in a future release to allow Micronode users to drill down into their bandwidth usage in a time series graph for both RX and TX.
This new release allows clients to see their combined usage per VPS/Instance.
Please note that whilst it is out of a 1000GB total this is just a guideline and your services will not be suspended if you breach this figure unless you are impacting the network performance for the entire node in which case you will be reminded that network is fair use, usage stats are reset monthly on the 1st of each month.
@natvps_uk said:
SSH Key support has been released for instance customers. This will eventually be available for VPS' as well, hopefully in the next release.
SSH Keys must be in the ssh-rsa format, ssh-dss keys are not supported.
It should be fairly self explanatory but documentation will follow.
When creating a new instance and providing SSH Key, will there be an option to have pw auth disabled by default? I believe this was the case with e.g. Lunanode.
@natvps_uk said:
SSH Key support has been released for instance customers. This will eventually be available for VPS' as well, hopefully in the next release.
SSH Keys must be in the ssh-rsa format, ssh-dss keys are not supported.
It should be fairly self explanatory but documentation will follow.
When creating a new instance and providing SSH Key, will there be an option to have pw auth disabled by default? I believe this was the case with e.g. Lunanode.
Not currently:
It is still down to the client to disable password based login, the way this works currently is a 100 character randomly generated password is set for root - this is never stored and is generated on the node therefore it is never passed in transit either.
Its unlikely that password based login will be removed due to the possibility of community templates using different SSH clients making this fairly tricky although its still very secure using this method.
@natvps_uk said:
SSH Key support has been released for instance customers. This will eventually be available for VPS' as well, hopefully in the next release.
SSH Keys must be in the ssh-rsa format, ssh-dss keys are not supported.
It should be fairly self explanatory but documentation will follow.
When creating a new instance and providing SSH Key, will there be an option to have pw auth disabled by default? I believe this was the case with e.g. Lunanode.
Not currently:
It is still down to the client to disable password based login, the way this works currently is a 100 character randomly generated password is set for root - this is never stored and is generated on the node therefore it is never passed in transit either.
Its unlikely that password based login will be removed due to the possibility of community templates using different SSH clients making this fairly tricky although its still very secure using this method.
@natvps_uk said: Announcement:
We have disabled vswap for instances users on the UK nodes, this was being heavily abused by people creating 64MB instances and forcing everything into swap. As this node is on HDDs it was impacting the limited disk performance fairly substantially.
Along with this change we will be looking at provisioning a new UK node on SSDs, we will not be forcing a migration although VPS users can request to migrate to this node (whilst stocks last) and instance users can simply deploy a new instance on this node.
We do not yet have a date for the provisioning of the SSD UK node although we will announce it here.
We're sorry for any inconvenience this may cause, in the meantime we will be offering additional RAM to instance users that were previously relying on vswap, simply open a ticket and we will allocate the memory you require - you will not need to re-provision your instance. Please note that this offer will not apply to newly created instances - Instances should be provisioned with the amount of resources that you require and not intentionally underspec'd.
We never advertised or sold the fact that these services came with vswap, we simply added it to help with lower specification instances and we will continue to do so on SSD nodes.
I opened a ticket but still no reply since 6 days. May you please take a look? Ticket number is #LKX-040803. Thank you in advance.
I like your offer very much. Everthing is stable except the VMs which rely on vswap.
@natvps_uk said: Announcement:
We have disabled vswap for instances users on the UK nodes, this was being heavily abused by people creating 64MB instances and forcing everything into swap. As this node is on HDDs it was impacting the limited disk performance fairly substantially.
Along with this change we will be looking at provisioning a new UK node on SSDs, we will not be forcing a migration although VPS users can request to migrate to this node (whilst stocks last) and instance users can simply deploy a new instance on this node.
We do not yet have a date for the provisioning of the SSD UK node although we will announce it here.
We're sorry for any inconvenience this may cause, in the meantime we will be offering additional RAM to instance users that were previously relying on vswap, simply open a ticket and we will allocate the memory you require - you will not need to re-provision your instance. Please note that this offer will not apply to newly created instances - Instances should be provisioned with the amount of resources that you require and not intentionally underspec'd.
We never advertised or sold the fact that these services came with vswap, we simply added it to help with lower specification instances and we will continue to do so on SSD nodes.
I opened a ticket but still no reply since 6 days. May you please take a look? Ticket number is #LKX-040803. Thank you in advance.
I like your offer very much. Everthing is stable except the VMs which rely on vswap.
We will get back to you, there is a backlog on support at the moment and you are in a queue.
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Deutsche Telekom (Hamburg) [1.82 km]: 11.315 ms
Testing download speed........
Download: 1396.56 Mbit/s
Testing upload speed.............
Upload: 220.54 Mbit/s
Our South Korea location is now back in stock for Instance users with a few minor changes.
Korea is by far the most expensive node we have, we have just substantially upgraded this to allow stock in this location for the foreseeable future.
Down to the cost of bandwidth in this location and the amount of abuse on this node we have limited the bandwidth to 100GB per month per instance credit.
None of our instance users have used this much bandwidth in the last 4 months therefore we don't believe it will cause too much drama however this was a decision that we did not take lightly and it is the only way we can profitably sustain this location.
We will give all users that need more bandwidth the opportunity to purchase more at cost. We pay £0.01 per GB in this location and we would be happy to pass this cost on to any client that wishes to have more Bandwidth in this location.
We also have plans to implement a new Asian location with unlimited bandwidth fairly soon.
For anyone that does not currently have a KR instance enjoy the new stock!
@natvps_uk said:
Down to the cost of bandwidth in this location and the amount of abuse on this node we have limited the bandwidth to 100GB per month per instance credit.
Does 100GB count on egress only or sum of both directions?
What happens if the 100GB limit is reached?
Does the network connection get suspended, or does it have snail speed unmetered network?
Suppose an account has 2 credits, one expiring on Nov 15 and another expiring on Dec 01.
The account has one Korea container, whose RAM and storage do not exceed one credit.
In the month of November, how much bandwidth can be used, 100GB or 150GB or 200GB?
We accept Karma donations for the last flan. 🍮 affbrr
@natvps_uk said:
Down to the cost of bandwidth in this location and the amount of abuse on this node we have limited the bandwidth to 100GB per month per instance credit.
Does 100GB count on egress only or sum of both directions?
Both directions.
What happens if the 100GB limit is reached?
Does the network connection get suspended, or does it have snail speed unmetered network?
We get notified and contact the client to arrange a mutual agreement. If the client wants to pay for additional bandwidth they will have that option, failing that it would be service suspension.
Suppose an account has 2 credits, one expiring on Nov 15 and another expiring on Dec 01.
The account has one Korea container, whose RAM and storage do not exceed one credit.
In the month of November, how much bandwidth can be used, 100GB or 150GB or 200GB?
200GB, the bandwidth limit starts in the 1st of the month and ends on the 1st of the following month.
WireGuard no.
Provider refuses to load the kernel module, despite that it's literally one line modprobe wireguard, at least for LXC based location such as Amsterdam.
WireGuard-go yes.
But it's buggy and slow userspace implementation instead of polished and fast kernel implementation.
We accept Karma donations for the last flan. 🍮 affbrr
@yoursunny said:
WireGuard no.
Provider refuses to load the kernel module, despite that it's literally one line modprobe wireguard, at least for LXC based location such as Amsterdam.
WireGuard-go yes.
But it's buggy and slow userspace implementation instead of polished and fast kernel implementation.
well that's a shame, i hope there's some explanation why they refused to do it. security concern maybe? but that's high unlikely.
I'll wait a bit until they respond i guess (for refusing to load the kernel module) otherwise-- meh userspace is good enough i guess
Fuck this 24/7 internet spew of trivia and celebrity bullshit.
@natvps_uk said: Absolutely a security concern, I doubt the wireguard team support this and I’d be even more surprised if it was tested officially on OpenVZ.
If security is a high priority, then you should just stop that micro-node control panel and switch to other widely used ones.Because I don't your developing skills can match that widely used ones'.
Most providers here don't offer that control panel, actually as far as I know, none of the providers here use that.
@natvps_uk said: Absolutely a security concern, I doubt the wireguard team support this and I’d be even more surprised if it was tested officially on OpenVZ.
If security is a high priority, then you should just stop that micro-node control panel and switch to other widely used ones.Because I don't your developing skills can match that widely used ones'.
Most providers here don't offer that control panel, actually as far as I know, none of the providers here use that.
On the other hand, wireguard has been absorbed into the kernel for more than 2 years.
If you really think wireguard might breach security holes, then compile and run a customized kernel.
@yoursunny said: Provider refuses to load the kernel module, despite that it's literally one line modprobe wireguard
Absolutely a security concern, I doubt the wireguard team support this and I’d be even more surprised if it was tested officially on OpenVZ.
We can’t just load kernel modules on a shared kernel without fully understanding the risks.
WireGuard kernel module is officially tested on LXC.
In fact, it's designed for such use cases: network namespaces.
Thus, you can safely load this module in Amsterdam location that uses LXC.
We accept Karma donations for the last flan. 🍮 affbrr
@yoursunny said: Provider refuses to load the kernel module, despite that it's literally one line modprobe wireguard
Absolutely a security concern, I doubt the wireguard team support this and I’d be even more surprised if it was tested officially on OpenVZ.
We can’t just load kernel modules on a shared kernel without fully understanding the risks.
WireGuard kernel module is officially tested on LXC.
In fact, it's designed for such use cases: network namespaces.
Thus, you can safely load this module in Amsterdam location that uses LXC.
I’m happy to enable it in LXC locations, that’s really not an issue.
The issue here is the lack of support on OpenVZ and the fact that we have to compile the module with several patches and maintain it.
@natvps_uk said:
We have disabled vswap for instances users on the UK nodes, this was being heavily abused by people creating 64MB instances and forcing everything into swap. As this node is on HDDs it was impacting the limited disk performance fairly substantially.
Instances should be provisioned with the amount of resources that you require and not intentionally underspec'd.
Ubuntu 22.04 apt update command crashes on 64MB without swap, even if I stopped everything.
I think it should be acceptable to use some swap during installation and upgrades, but not during normal operation.
I deleted UK instance and created Germany instances, which has swap.
There's no way to modify a loadbalancer, so I have to delete and re-create it too.
This causes downtime because TLS certificate isn't provisioned on the new loadbalancer right away.
In an attempt to reproduce the apt update failure, I created another UK instance but it has swap again.
Does this mean the UK SSD node has arrived?
We accept Karma donations for the last flan. 🍮 affbrr
@natvps_uk said:
We have disabled vswap for instances users on the UK nodes, this was being heavily abused by people creating 64MB instances and forcing everything into swap. As this node is on HDDs it was impacting the limited disk performance fairly substantially.
Instances should be provisioned with the amount of resources that you require and not intentionally underspec'd.
Ubuntu 22.04 apt update command crashes on 64MB without swap, even if I stopped everything.
I think it should be acceptable to use some swap during installation and upgrades, but not during normal operation.
I deleted UK instance and created Germany instances, which has swap.
There's no way to modify a loadbalancer, so I have to delete and re-create it too.
This causes downtime because TLS certificate isn't provisioned on the new loadbalancer right away.
Loadbalancer and instance editing is coming very soon, the work is almost complete we just need to write tests. It should be available as a beta by the end of the week - happy to add your account to the beta program.
This will allow you to add additional RAM to an instance for maintenance then remove it afterwards. It will also allow you to add and remove instances from an LB without any downtime although if the dns name isn’t changing the cert will likely not be regenerated - they remain cached for 24 hours.
@natvps_uk said:
We have disabled vswap for instances users on the UK nodes, this was being heavily abused by people creating 64MB instances and forcing everything into swap. As this node is on HDDs it was impacting the limited disk performance fairly substantially.
Instances should be provisioned with the amount of resources that you require and not intentionally underspec'd.
Ubuntu 22.04 apt update command crashes on 64MB without swap, even if I stopped everything.
I think it should be acceptable to use some swap during installation and upgrades, but not during normal operation.
I deleted UK instance and created Germany instances, which has swap.
There's no way to modify a loadbalancer, so I have to delete and re-create it too.
This causes downtime because TLS certificate isn't provisioned on the new loadbalancer right away.
In an attempt to reproduce the apt update failure, I created another UK instance but it has swap again.
Does this mean the UK SSD node has arrived?
Having the same problem. Not able to install security updates.
Createt a ticket a while ago... still no reply :-(
@natvps_uk said:
We have disabled vswap for instances users on the UK nodes, this was being heavily abused by people creating 64MB instances and forcing everything into swap. As this node is on HDDs it was impacting the limited disk performance fairly substantially.
Instances should be provisioned with the amount of resources that you require and not intentionally underspec'd.
Ubuntu 22.04 apt update command crashes on 64MB without swap, even if I stopped everything.
I think it should be acceptable to use some swap during installation and upgrades, but not during normal operation.
I deleted UK instance and created Germany instances, which has swap.
There's no way to modify a loadbalancer, so I have to delete and re-create it too.
This causes downtime because TLS certificate isn't provisioned on the new loadbalancer right away.
In an attempt to reproduce the apt update failure, I created another UK instance but it has swap again.
Does this mean the UK SSD node has arrived?
Having the same problem. Not able to install security updates.
Createt a ticket a while ago... still no reply :-(
@natvps_uk said: We have disabled vswap for instances users on the UK nodes, this was being heavily abused by people creating 64MB instances and forcing everything into swap.
Maybe you should offer 280MB ram as minimum. locale-gen will fail because of OOM in 256MB VPS.
@natvps_uk said: We have disabled vswap for instances users on the UK nodes, this was being heavily abused by people creating 64MB instances and forcing everything into swap.
Maybe you should offer 280MB ram as minimum. locale-gen will fail because of OOM in 256MB VPS.
Or you may limit the OS to alpine.
It’s down to the user to decide how much ram they want. We originally limited it to 128MB and we got complaints so reduced it 64MB.
Users can upgrade their resources at anytime for VPS clients they just need to open a ticket and we will invoice accordingly. For instance users they just need to reprovision their instance with the resources that they require.
Keep in mind that all locations other than our UK nodes come with 256Mb Vswap as standard.
@Ympker said:
I am running 2x128mb vps ubuntu 20.04. No issues
It's not only about running, and I'm sure your vps are running stably with 128MB.
Some installations or updates need more ram than just running the service.
I wish there could be something like ram burst, which temporarily assigns more ram from host, say 256MB more ram for 1 minute, and only once weekly (to prevent abuse).
@bliss said:
Some installations or updates need more ram than just running the service.
I wish there could be something like ram burst, which temporarily assigns more ram from host, say 256MB more ram for 1 minute, and only once weekly (to prevent abuse).
Yes, that's the instance editing feature they is coming soon™.
The resources would come from your credit.
The idea is keeping a portion of your credit(s) unallocated, so that you can add the reserve resources to one instance at a time during upgrades.
Still not enough?
Buy more credits!
This is already better than most other VPS providers.
@natvps_uk said:
Loadbalancer and instance editing is coming very soon.
This will allow you to add additional RAM to an instance for maintenance then remove it afterwards.
We accept Karma donations for the last flan. 🍮 affbrr
if I install WG on 64MB ram just for simple web browsing/ YT streaming (total of 5 hours per day at most) and ssh to my other vms, will it be abusing the server? can it handle the task?
if that's a problem then i would re-create it with 128MB
@yoursunny said:
There's no way to modify a loadbalancer, so I have to delete and re-create it too.
This causes downtime because TLS certificate isn't provisioned on the new loadbalancer right away.
It's been 8 hours and the new loadbalancer still hasn't provisioned TLS certificate.
$ curl -i https://summer-host-storage.yoursunny.dev/robots.txt
curl: (60) SSL: no alternative certificate subject name matches target host name 'summer-host-storage.yoursunny.dev'
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
We accept Karma donations for the last flan. 🍮 affbrr
if I install WG on 64MB ram just for simple web browsing/ YT streaming (total of 5 hours per day at most) and ssh to my other vms, will it be abusing the server? can it handle the task?
if that's a problem then i would re-create it with 128MB
I am running ovpn+wg on a 128mb ram vps just fine. 64mb would probably work just as well for wg
Comments
Yes, long-bit RSA keys are still safe, but ed25519 provides lighter and faster performance (which is unnoticeable in almost every scenario). Since your control panel is a somewhat new one, I though both very stable algorithm and cutting-edge algorithm will be support.
It's just like you are supporting mp3 format instead of opus in a new project.
Now that you mentioned ed25519 may be supported in future, I guess it's fine to everyone.
Yoursunny said what I want: users just paste their keys, which the control panel appends to authorized_keys.
MicroLXC is lovable.
I get this, and understand both of your points above but RSA is supported on all of our templates, and is supported by most/all distros.
We're going for stability/support rather than cutting edge to provide the best end user experience overall. Once all of our templates support ed25519 we will look to implement it although with the future community templates release we can't guarantee that these templates will support ed25519.
We will add support when possible, if you want to use a ed25519 key its pretty simple, ensure that your ssh server supports it and add it to your authorized keys file.
Well, I believe the omniscient MaxMind will solve that case in the first step.
Oh the above is a joke. Honestly speaking, I don't think it's a problem, because all your service is "unmanaged", so I don't think you should or will offer support in such annoying cases. Plus most your competitors offer "rescue mode" in such case, which the user alone can handle.
MicroLXC is lovable.
Thanks for explaining.
I think most people have adopted this way:
1. Set root password or paste a public key (if support) when order;
2. log into the system;
3. Config sshd_config to disable password login;
Maybe you should give users a choice to "opt in" for your compulsory key login, if the control panel you bought has that option.
MicroLXC is lovable.
We wrote the control panel in house so additions like this are possible, SSH keys will eventually become compulsory for all instances although there is no planned date for deprecating password based login.
Micronode 1.2.6 Released!
Changelog
Added:
* Bandwidth Monitorning
Changed:
Fixed:
2 major deployments in one day! This one has been requested a lot by our clients.
We have added bandwidth monitoring, we will be adding some dashboards in a future release to allow Micronode users to drill down into their bandwidth usage in a time series graph for both RX and TX.
This new release allows clients to see their combined usage per VPS/Instance.
Please note that whilst it is out of a 1000GB total this is just a guideline and your services will not be suspended if you breach this figure unless you are impacting the network performance for the entire node in which case you will be reminded that network is fair use, usage stats are reset monthly on the 1st of each month.
This is great. Thank you.
MicroLXC is lovable.
When creating a new instance and providing SSH Key, will there be an option to have pw auth disabled by default? I believe this was the case with e.g. Lunanode.
Ympker's VPN LTD Comparison, Uptime.is, Ympker's GitHub.
Not currently:
You almost always reply instantly to my posts lol
Gotcha, thanks
Ympker's VPN LTD Comparison, Uptime.is, Ympker's GitHub.
I opened a ticket but still no reply since 6 days. May you please take a look? Ticket number is #LKX-040803. Thank you in advance.
I like your offer very much. Everthing is stable except the VMs which rely on vswap.
We will get back to you, there is a backlog on support at the moment and you are in a queue.
New Primary Location!
We have added a new permanent location to Micronode instances, Limburg, Germany 🇩🇪.
Node Specifications:
This is available immediately for instance customers. VPS customers will have to wait another few days before we get an offer out.
For anyone wanting to try this who doesn’t currently have instance credits they can be purchased here: https://clients.natvps.uk/index.php?rp=/store/micronode-instances/1-credit
YABS from an Instance:
i am happy to see Germany node.
congrats and i wish you good sales.
Still waiting for Finland loc.
Btw, some bugs when creating SSH Key.
If you press back, it will show false slider info like RAM and Storage.
https://microlxc.net/
My 96MB Germany instance running wireguard
Awesome! Happy to see Germany along with 10Gbps
Ympker's VPN LTD Comparison, Uptime.is, Ympker's GitHub.
Loving it:
Ympker's VPN LTD Comparison, Uptime.is, Ympker's GitHub.
@natvps_uk
Success! Your instance has bow been created!Is it a typo or intended?
https://microlxc.net/
Typo, now fixed.
Our South Korea location is now back in stock for Instance users with a few minor changes.
Korea is by far the most expensive node we have, we have just substantially upgraded this to allow stock in this location for the foreseeable future.
Down to the cost of bandwidth in this location and the amount of abuse on this node we have limited the bandwidth to 100GB per month per instance credit.
None of our instance users have used this much bandwidth in the last 4 months therefore we don't believe it will cause too much drama however this was a decision that we did not take lightly and it is the only way we can profitably sustain this location.
We will give all users that need more bandwidth the opportunity to purchase more at cost. We pay £0.01 per GB in this location and we would be happy to pass this cost on to any client that wishes to have more Bandwidth in this location.
We also have plans to implement a new Asian location with unlimited bandwidth fairly soon.
For anyone that does not currently have a KR instance enjoy the new stock!
Does 100GB count on egress only or sum of both directions?
What happens if the 100GB limit is reached?
Does the network connection get suspended, or does it have snail speed unmetered network?
Suppose an account has 2 credits, one expiring on Nov 15 and another expiring on Dec 01.
The account has one Korea container, whose RAM and storage do not exceed one credit.
In the month of November, how much bandwidth can be used, 100GB or 150GB or 200GB?
We accept Karma donations for the last flan. 🍮 affbrr
Both directions.
We get notified and contact the client to arrange a mutual agreement. If the client wants to pay for additional bandwidth they will have that option, failing that it would be service suspension.
200GB, the bandwidth limit starts in the 1st of the month and ends on the 1st of the following month.
can you use wireguard / wireguard-go in this one?
Fuck this 24/7 internet spew of trivia and celebrity bullshit.
WireGuard no.
Provider refuses to load the kernel module, despite that it's literally one line
modprobe wireguard, at least for LXC based location such as Amsterdam.WireGuard-go yes.
But it's buggy and slow userspace implementation instead of polished and fast kernel implementation.
We accept Karma donations for the last flan. 🍮 affbrr
well that's a shame, i hope there's some explanation why they refused to do it. security concern maybe? but that's high unlikely.
I'll wait a bit until they respond i guess (for refusing to load the kernel module) otherwise-- meh userspace is good enough i guess
Fuck this 24/7 internet spew of trivia and celebrity bullshit.
Userspace is good enough.
https://microlxc.net/
Glad to hear that we think alike.
MicroLXC is lovable.
Absolutely a security concern, I doubt the wireguard team support this and I’d be even more surprised if it was tested officially on OpenVZ.
We can’t just load kernel modules on a shared kernel without fully understanding the risks.
If security is a high priority, then you should just stop that micro-node control panel and switch to other widely used ones.Because I don't your developing skills can match that widely used ones'.
Most providers here don't offer that control panel, actually as far as I know, none of the providers here use that.
MicroLXC is lovable.
If security is a high priority, then you should just stop that micro-node control panel and switch to other widely used ones.Because I don't your developing skills can match that widely used ones'.
Most providers here don't offer that control panel, actually as far as I know, none of the providers here use that.
On the other hand, wireguard has been absorbed into the kernel for more than 2 years.
If you really think wireguard might breach security holes, then compile and run a customized kernel.
MicroLXC is lovable.
They don’t have access to it, it’s our in house panel.
We take security seriously, the panel is pentested regularly and we follow best practices.
On the other hand wireguard-go has been considered stable for years, it is used on the Windows application for example.
We can’t just add every kernel module someone asks for, that’s not how we work.
This! @natvps_uk 's business, @natvps_uk 's rules!
WireGuard kernel module is officially tested on LXC.
In fact, it's designed for such use cases: network namespaces.
Thus, you can safely load this module in Amsterdam location that uses LXC.
We accept Karma donations for the last flan. 🍮 affbrr
I’m happy to enable it in LXC locations, that’s really not an issue.
The issue here is the lack of support on OpenVZ and the fact that we have to compile the module with several patches and maintain it.
Ubuntu 22.04
apt updatecommand crashes on 64MB without swap, even if I stopped everything.I think it should be acceptable to use some swap during installation and upgrades, but not during normal operation.
I deleted UK instance and created Germany instances, which has swap.
There's no way to modify a loadbalancer, so I have to delete and re-create it too.
This causes downtime because TLS certificate isn't provisioned on the new loadbalancer right away.
In an attempt to reproduce the
apt updatefailure, I created another UK instance but it has swap again.Does this mean the UK SSD node has arrived?
We accept Karma donations for the last flan. 🍮 affbrr
Loadbalancer and instance editing is coming very soon, the work is almost complete we just need to write tests. It should be available as a beta by the end of the week - happy to add your account to the beta program.
This will allow you to add additional RAM to an instance for maintenance then remove it afterwards. It will also allow you to add and remove instances from an LB without any downtime although if the dns name isn’t changing the cert will likely not be regenerated - they remain cached for 24 hours.
Having the same problem. Not able to install security updates.
Createt a ticket a while ago... still no reply :-(
DM me the ticket number, I’ll take a look.
Maybe you should offer 280MB ram as minimum.
locale-genwill fail because of OOM in 256MB VPS.Or you may limit the OS to alpine.
MicroLXC is lovable.
It’s down to the user to decide how much ram they want. We originally limited it to 128MB and we got complaints so reduced it 64MB.
Users can upgrade their resources at anytime for VPS clients they just need to open a ticket and we will invoice accordingly. For instance users they just need to reprovision their instance with the resources that they require.
Keep in mind that all locations other than our UK nodes come with 256Mb Vswap as standard.
I am running 2x128mb vps ubuntu 20.04. No issues
Ympker's VPN LTD Comparison, Uptime.is, Ympker's GitHub.
It's not only about running, and I'm sure your vps are running stably with 128MB.
Some installations or updates need more ram than just running the service.
I wish there could be something like ram burst, which temporarily assigns more ram from host, say 256MB more ram for 1 minute, and only once weekly (to prevent abuse).
MicroLXC is lovable.
Yes, that's the instance editing feature they is coming soon™.
The resources would come from your credit.
The idea is keeping a portion of your credit(s) unallocated, so that you can add the reserve resources to one instance at a time during upgrades.
Still not enough?
Buy more credits!
This is already better than most other VPS providers.
We accept Karma donations for the last flan. 🍮 affbrr
genuinely asking:
if I install WG on 64MB ram just for simple web browsing/ YT streaming (total of 5 hours per day at most) and ssh to my other vms, will it be abusing the server? can it handle the task?
if that's a problem then i would re-create it with 128MB
wg uses next to nothing, I used to run 60 wg tunnels on 256MB machines.
Free NAT KVM | Free NAT LXC
It's been 8 hours and the new loadbalancer still hasn't provisioned TLS certificate.
We accept Karma donations for the last flan. 🍮 affbrr
I am running ovpn+wg on a 128mb ram vps just fine. 64mb would probably work just as well for wg
Ympker's VPN LTD Comparison, Uptime.is, Ympker's GitHub.