New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
It was killed when I tried to install wireguard. Could you please double check?
natvps enabled swap
Yeah it should be enabled especially on low memory vps.
Never, its 64MB for a reason.
You are using it wrong.
The Kernel is new enough to have the wg kernel module build in.
Means you don't need wireguard-dkms or anything else.
With apt-get install wireguard-tools --no-install-recommends it works fine.
If 64MB is not enough for you, you can go for the 128MB Package.
I can confirm that wireguard running smoothly on 128 MB vps (and also openvpn and zerotier daemon).
User that run nyr wireguard install script, need modified particular line:
apt-get install wireguard-tools --no-install-recommends... (somehow, I run uninstalled one or two packages ... which I think generate QR code on terminal ).My bad. I tried Nyr's script on Debian 10 and the apt-get install process was killed. But it works flawlessly on Debian 12.
The script from Nyr does not even use the native wg kernel module.
It does install more stuff, makes sense on a kernel that does not support wg but otherwise its overhead, especially on 64MB.
Wireguard uses little to no memory, you could even run a bunch of wireguard links on 64MB.
CPU gonna be the bottleneck.
That makes sense, thank you for brief information. Learn something new here.
Second this. Do you plan on using the native wg kernel in the following releases, @Nyr ?
I will take a look at this. When the script was designed, this was no factor and I never updated it. I will see what is the best way to make absolutely sure that the kernel module is available and working inside containers, and if this can be reliably detected, I will change this.
I have an existing account from years ago with no active containers.
I am trying to deploy one, but when I login to the dashboard, it shows "Quota exceeded" and no way to deploy it. Am I missing something?
Maybe it was locked due to inactivity. I think @Neoon can help you.
41e4-7130-513a-1142
I'm curious. Thank you.
Seems to be a bug, when you have zero containers, the dashboard looks a bit fucked.
However, technically you didn't exceeded your quota so.
Just head over to https://microlxc.net/index.php?p=deploy and you be fine.
Thank you!
Yea as usual its a JOIN that is causing the issue, should be a LEFT JOIN.
Since you have no machines, otherwise returns no data which explains why the Dashboard is in a broken state if you have zero containers.
I fix it later.
Could you please check the microRO node, @Neoon ?
Failed to contact Node, please try again later.We changed something yesterday that broke the /64 which the Node is currently using.
Should be working again.
eeed-bb26-bb22-1353
I have been looking at this, and will be implemented with a bigger installer update which will be out in April. Reason for the delay is that while this particular change is simple by itself, it would make no sense to add complexity with some required changes for distros which will stop being supported in 3 months.
Fixed, thanks for the bug report.
Hello,
I had forgotten I had already attempted to sign up, and tried again today. So I have two codes:
41e4-7130-513a-1142
and from today:
5d46-b4f3-a4b9-3a37
I couldn't find any email confirming activation or account creation, and the reason I did it again was that the webpage had reset so that initial code was gone.
Did that first code "work" and if so, how do I login? If not, what should I expect from this second attempt? Thank you!
EDIT: OK, it's all good and running, thank you.
You are never asked for an email, the whole signup runs over the forum.
If you just close your browser tab, before completing it, it will just expire.
You can provide your email afterwards but this is optional and only used for notifications regarding your containers when they about to expire or getting terminated.
Good news everyone, Romania has been upgraded to a /64 prefix per container.
The old prefix will continue to work, however there is currently no button to apply the new network configuration so you essentially stuck on the old prefix until you terminate and deploy again. Reinstall won't change or modify your current allocation.
Or you wait until the Feature is available, possibly this week.
Big thanks to @host_c
I restocked some Locations, even if the Node shows available it can be that its suddenly out of stock due to running out of disk.
I modified the system to track storage usage too, because of the increased density, it doesn't reflect that yet.
Groningen needs a maintenance before it can get any restocks, possibly in the next weeks.
Will there be restocking of Nanokvm anytime soon ? @Neoon
The Nodes are full, so unlikely.
Since the Traffic allocations have been upgraded in SG and JP, kudos to @Abd / https://webhorizon.net
All Packages in JP have been upgraded by +50GB.
SG has only one regional Package, mediumSG which also has been upgraded by +50GB.
If someone really needs 250GB in SG, I can create a regional SG package with 250GB allocation, for 256MB and smoler.
Depending on traffic usage, it might be bumped to 300GB, but will see.
Thnx for all the work. Any update on V6 on JP Equinix?
Still waiting for the /48 allocation from @Abd but he said.
He is going to roll out routed IPv6 subnets for everyone in this Location, hence the delay.
So no idea.