you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
Okay, that's fair enough. Just wanted to make sure 😂
Hmm, when running @Nyr scripts (ovpn/wg) on NL vps it gets stuck at this (connectivity issue? worked fine on UK)
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
Sadly not, but I can rent a huge garage for like 75 bucks p/m
That’s cheap! Garages here are like £100 per month and they hardly fit a single car! I’d snap your hands off for a garage for that price in the UK. My car collection is currently spread across a few locations 😰
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
Sadly not, but I can rent a huge garage for like 75 bucks p/m
That’s cheap! Garages here are like £100 per month and they hardly fit a single car! I’d snap your hands off for a garage for that price in the UK. My car collection is currently spread across a few locations 😰
Its the size of a big van with the ability to walk all around it, and as high as 2 stories. Not sure if I can still rent them from the city (depends if tenants are paying their rent)
you said you didn't want to disclose NL location/provider, but before I run a vpn on there: is it actually in a DC with a hosting company, or is it hosted in a private individual's basement as in Calin?
It’s not in a DC but it is located in a secure unit. Definitely not in Calins basement 😂
Okay, that's fair enough. Just wanted to make sure 😂
Hmm, when running @Nyr scripts (ovpn/wg) on NL vps it gets stuck at this (connectivity issue? worked fine on UK)
This is now resolved, it was a routing issue which is now resolved.
For anyone else seeing generally strange networking behaviour on this node the issues should be resolved. Please let me know if you continue to see issues, whilst this is a bonus location we still want it to be as usable and stable as possible!
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.
Didn't want to make a ticket, but FYI the tun/tap button for Romania doesn't seem to be working (doesn't reboot the vps, tried manually rebooting after and still wasnt turned on). The server is/was up at the time I tried (ssh'ed into it) and the button works fine for other locations. Rebooting from the control panel also works fine, just the tun/tap that isn't working.
Edit: Guess it doesn't matter now because @Calin's servers seem to be getting DDoS'ed again right now lol...
@edip said:
My 256m UK instance is extremely slow. I mean computing speed wise. Network speed is good but even apt update takes 3mins.
Its possible that you are being throttled. We do have automated throttling in place for users that are hammering the disks. Open a ticket and we can investigate. I just timed a apt-update on that node and it is not even close to that slow on a 256mb instance.
@soulchief said:
Didn't want to make a ticket, but FYI the tun/tap button for Romania doesn't seem to be working (doesn't reboot the vps, tried manually rebooting after and still wasnt turned on). The server is/was up at the time I tried (ssh'ed into it) and the button works fine for other locations. Rebooting from the control panel also works fine, just the tun/tap that isn't working.
Edit: Guess it doesn't matter now because @Calin's servers seem to be getting DDoS'ed again right now lol...
@edip said:
My 256m UK instance is extremely slow. I mean computing speed wise. Network speed is good but even apt update takes 3mins.
Its possible that you are being throttled. We do have automated throttling in place for users that are hammering the disks. Open a ticket and we can investigate. I just timed a apt-update on that node and it is not even close to that slow on a 256mb instance.
root@micronode-UK-NAT:~# time apt update
Hit:1 http://security.debian.org buster/updates InRelease
Hit:2 http://ftp.debian.org/debian buster InRelease
Get:3 http://ftp.debian.org/debian buster-updates InRelease [56.6 kB]
Fetched 56.6 kB in 1s (50.3 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
@edip said:
My 256m UK instance is extremely slow. I mean computing speed wise. Network speed is good but even apt update takes 3mins.
Its possible that you are being throttled. We do have automated throttling in place for users that are hammering the disks. Open a ticket and we can investigate. I just timed a apt-update on that node and it is not even close to that slow on a 256mb instance.
root@micronode-UK-NAT:~# time apt update
Hit:1 http://security.debian.org buster/updates InRelease
Hit:2 http://ftp.debian.org/debian buster InRelease
Get:3 http://ftp.debian.org/debian buster-updates InRelease [56.6 kB]
Fetched 56.6 kB in 1s (50.3 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
real 0m14.025s
user 0m1.530s
sys 0m0.444s
That seems about right considering the node is on HDDs. We will be getting a UK node on SSDs fairly soon.
@edip said:
My 256m UK instance is extremely slow. I mean computing speed wise. Network speed is good but even apt update takes 3mins.
Its possible that you are being throttled. We do have automated throttling in place for users that are hammering the disks. Open a ticket and we can investigate. I just timed a apt-update on that node and it is not even close to that slow on a 256mb instance.
@edip said:
My 256m UK instance is extremely slow. I mean computing speed wise. Network speed is good but even apt update takes 3mins.
Its possible that you are being throttled. We do have automated throttling in place for users that are hammering the disks. Open a ticket and we can investigate. I just timed a apt-update on that node and it is not even close to that slow on a 256mb instance.
@edip said:
My 256m UK instance is extremely slow. I mean computing speed wise. Network speed is good but even apt update takes 3mins.
Its possible that you are being throttled. We do have automated throttling in place for users that are hammering the disks. Open a ticket and we can investigate. I just timed a apt-update on that node and it is not even close to that slow on a 256mb instance.
@edip said:
My 256m UK instance is extremely slow. I mean computing speed wise. Network speed is good but even apt update takes 3mins.
Its possible that you are being throttled. We do have automated throttling in place for users that are hammering the disks. Open a ticket and we can investigate. I just timed a apt-update on that node and it is not even close to that slow on a 256mb instance.
Almost certainly being throttled, DM me your micronode username and I'll take a look
I've lifted the IO throttle, please try again now
Thanks! It's definitely faster now;
real 0m6.157s
user 0m1.589s
sys 0m0.895s
After first provision, I couldn't enable tun/tap so I just reinstalled OS several times, hoping I'll fix it. But it got fixed only after a ticket . I think that's the cause for throttling.
@natvps_uk said:
This is now resolved, it was a routing issue which is now resolved.
For anyone else seeing generally strange networking behaviour on this node the issues should be resolved. Please let me know if you continue to see issues, whilst this is a bonus location we still want it to be as usable and stable as possible!
NL can ping your other locations fine, but can't ssh your UK host or CA or SK
ssh: connect to host xxx…. port xx21: Connection timed out
ssh: connect to host yyy… port xx21: Connection timed out
ssh: connect to host aaa… port xx21: Connection timed out
Can't ping an IPV6 address
PING government.nl(bbbb::::)) 56 data bytes
From cccc::::(dddd::::): icmp_seq=1 Destination unreachable: No route
@natvps_uk said:
Please remove our node IPs from this post.
Never share node IPs publicly!
If this is a policy, it needs to be added to the ToS.
Otherwise, it's merely a suggestion.
"Share publicly" needs to be defined too.
For example, if a customer installs Asterisk telephony server and creates an SRV record pointing to the IPv4+port, the DNS record technically reveals the node IP.
We accept Karma donations for the last flan. 🍮 affbrr
@natvps_uk said:
Please remove our node IPs from this post.
Never share node IPs publicly!
If this is a policy, it needs to be added to the ToS.
Otherwise, it's merely a suggestion.
"Share publicly" needs to be defined too.
For example, if a customer installs Asterisk telephony server and creates an SRV record pointing to the IPv4+port, the DNS record technically reveals the node IP.
Yeah I’m going to add it, I mean a records are fine. Sharing the IPs on a public forum not so much.
@natvps_uk said:
Please remove our node IPs from this post.
Never share node IPs publicly!
If this is a policy, it needs to be added to the ToS.
Otherwise, it's merely a suggestion.
"Share publicly" needs to be defined too.
For example, if a customer installs Asterisk telephony server and creates an SRV record pointing to the IPv4+port, the DNS record technically reveals the node IP.
Yeah I’m going to add it, I mean a records are fine. Sharing the IPs on a public forum not so much.
My bad! Everybody wants to avoid what Calin's going through.
Did more testing and it's not just ssh, curl fails too.
Edit: Inbound curl works. Outbound curl (from NL) fails. Didn't want to bug support with a ticket but if it helps I'll get one open
@natvps_uk said:
Please remove our node IPs from this post.
Never share node IPs publicly!
If this is a policy, it needs to be added to the ToS.
Otherwise, it's merely a suggestion.
"Share publicly" needs to be defined too.
For example, if a customer installs Asterisk telephony server and creates an SRV record pointing to the IPv4+port, the DNS record technically reveals the node IP.
Yeah I’m going to add it, I mean a records are fine. Sharing the IPs on a public forum not so much.
My bad! Everybody wants to avoid what Calin's going through.
Did more testing and it's not just ssh, curl fails too.
Edit: Inbound curl works. Outbound curl (from NL) fails. Didn't want to bug support with a ticket but if it helps I'll get one open
SSH from NL to KR now fails rejecting my correct key. Same key works from a third host.
It's as if I'm connecting to a different host, but the ECDSA fingerprint is the same. (retrieved and converted using: dropbearkey -y -f /etc/dropbear/dropbear_ecdsa_host_key | ssh-keygen -l -f - -E sha256)
SSH from NL to CA now fails rejecting correct key
No progress:
SSH from NL to UK fails, no connection
Curl from NL to everywhere still fails
SSH from NL to KR now fails rejecting my correct key. Same key works from a third host.
It's as if I'm connecting to a different host, but the ECDSA fingerprint is the same. (retrieved and converted using: dropbearkey -y -f /etc/dropbear/dropbear_ecdsa_host_key | ssh-keygen -l -f - -E sha256)
SSH from NL to CA now fails rejecting correct key
No progress:
SSH from NL to UK fails, no connection
Curl from NL to everywhere still fails
Interesting, I can’t replicate this on my side.
DM me your Micronode username and I’ll take a look
@yoursunny Just for you we got the SSH keys feature tested today.
Key Management
Provisioning
We're not going to enforce keys immediately and the option for password based auth remains for now. This will be phased out.
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.
This will be deployed to production on Thursday AM.
@natvps_uk said: SSH Keys must be in the ssh-rsa format, ssh-dss keys are not supported.
I thought ed25519 algorithm is more modern, isn't it?
You're right, its more modern but not necessarily safer. A 4096 bit RSA key is considered secure.
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.
Thats not to say that we won't support ed25519 in the future but right now for the initial release RSA is the only supported algorithm.
@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.
We accept Karma donations for the last flan. 🍮 affbrr
@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.
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.
We will allow other algorithms going forwards although for this initial release and the foreseeable future we will only be supporting RSA.
Comments
Plot twist: it's in @skorupion basement.
We accept Karma donations for the last flan. 🍮 affbrr
Will try later, thanks. On UK Instance this worked fine, so might be routing with NL.
Ympker's VPN LTD Comparison, Uptime.is, Ympker's GitHub.
I can confirm that no basements have been used in the hosting of this node.
Just what you would say if you were hosting out of Calin's basement.
The Yeti has left the building.
If it was hosted in Calins basement it would have already been DDos'd 6 times and have 70% uptime. - Sorry Calin, I know you're working on this
Numbers can be fudged. I am watching you. 🤪
The Yeti has left the building.
Korea will be back in stock soon, Singapore is possibly coming although it’s likely a few months away.
Worked out as well as a free unrequested refund from Advin Servers> @yoursunny said:
Sadly not, but I can rent a huge garage for like 75 bucks p/m
Synteq Technical Support, Technical Writer.
Contact me at: +1 (307) 428 8111 or [email protected]
Woohoo, Calin is back on line.
Edit: Okay, forget what I've said.
More off than online. 40% loss.
That’s cheap! Garages here are like £100 per month and they hardly fit a single car! I’d snap your hands off for a garage for that price in the UK. My car collection is currently spread across a few locations 😰
Its the size of a big van with the ability to walk all around it, and as high as 2 stories. Not sure if I can still rent them from the city (depends if tenants are paying their rent)
Synteq Technical Support, Technical Writer.
Contact me at: +1 (307) 428 8111 or [email protected]
This is now resolved, it was a routing issue which is now resolved.
For anyone else seeing generally strange networking behaviour on this node the issues should be resolved. Please let me know if you continue to see issues, whilst this is a bonus location we still want it to be as usable and stable as possible!
The Yeti has left the building.
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.
Didn't want to make a ticket, but FYI the tun/tap button for Romania doesn't seem to be working (doesn't reboot the vps, tried manually rebooting after and still wasnt turned on). The server is/was up at the time I tried (ssh'ed into it) and the button works fine for other locations. Rebooting from the control panel also works fine, just the tun/tap that isn't working.
Edit: Guess it doesn't matter now because @Calin's servers seem to be getting DDoS'ed again right now lol...
My 256m UK instance is extremely slow. I mean computing speed wise. Network speed is good but even apt update takes 3mins.
Its possible that you are being throttled. We do have automated throttling in place for users that are hammering the disks. Open a ticket and we can investigate. I just timed a apt-update on that node and it is not even close to that slow on a 256mb instance.
I'll take a look once the nodes are back online
Mines pretty slow too, and my server just idles.
That seems about right considering the node is on HDDs. We will be getting a UK node on SSDs fairly soon.
This is mine;
edit: I just created a ticket
Almost certainly being throttled, DM me your micronode username and I'll take a look
I've lifted the IO throttle, please try again now
Thanks! It's definitely faster now;
real 0m6.157s
user 0m1.589s
sys 0m0.895s
After first provision, I couldn't enable tun/tap so I just reinstalled OS several times, hoping I'll fix it. But it got fixed only after a ticket
. I think that's the cause for throttling.
The Yeti has left the building.
NL can ping your other locations fine, but can't ssh your UK host or CA or SK
ssh: connect to host xxx…. port xx21: Connection timed out
ssh: connect to host yyy… port xx21: Connection timed out
ssh: connect to host aaa… port xx21: Connection timed out
Can't ping an IPV6 address
PING government.nl(bbbb::::)) 56 data bytes
From cccc::::(dddd::::): icmp_seq=1 Destination unreachable: No route
Please do the needful
Please remove our node IPs from this post.
Never share node IPs publicly!
We’ll look into the issue
If this is a policy, it needs to be added to the ToS.
Otherwise, it's merely a suggestion.
"Share publicly" needs to be defined too.
For example, if a customer installs Asterisk telephony server and creates an SRV record pointing to the IPv4+port, the DNS record technically reveals the node IP.
We accept Karma donations for the last flan. 🍮 affbrr
Yeah I’m going to add it, I mean a records are fine. Sharing the IPs on a public forum not so much.
My bad! Everybody wants to avoid what Calin's going through.
Did more testing and it's not just ssh, curl fails too.
Edit: Inbound curl works. Outbound curl (from NL) fails. Didn't want to bug support with a ticket but if it helps I'll get one open
Please could you try now
A little progress:
SSH from NL to KR now fails rejecting my correct key. Same key works from a third host.
It's as if I'm connecting to a different host, but the ECDSA fingerprint is the same. (retrieved and converted using: dropbearkey -y -f /etc/dropbear/dropbear_ecdsa_host_key | ssh-keygen -l -f - -E sha256)
SSH from NL to CA now fails rejecting correct key
No progress:
SSH from NL to UK fails, no connection
Curl from NL to everywhere still fails
Interesting, I can’t replicate this on my side.
DM me your Micronode username and I’ll take a look
DMed, thanks!
@yoursunny Just for you we got the SSH keys feature tested today.
Key Management
Provisioning
We're not going to enforce keys immediately and the option for password based auth remains for now. This will be phased out.
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.
This will be deployed to production on Thursday AM.
Hi @natvps_uk DM'ed you.
https://microlxc.net/
Unfortunately, the payment method is not friendly to China
Works as intended.
We accept Karma donations for the last flan. 🍮 affbrr
@natvps_uk Do you mind installing wireguard kernel module on the uk host, which will facilitate wireguard on guest VPS. Thank you.
MicroLXC is lovable.
You can use wireguard without the kernel module, I believe there are several releases available that do not require it.
We are not able to install it on the node but somebody here should be able to assist you with the installation.
https://github.com/Nyr/wireguard-install
Wrong thread. Pls delete.
https://microlxc.net/
No not going to do it since you asked for it.
The Yeti has left the building.
Micronode 1.2.1 Released!
Changelog
Added:
* SSH Key Support
Changed:
* Build process now detects if node is offline.
Fixed:
* Fixed bug causing RO instances to sometimes fail to have network connectivity after deployment.
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.
I thought ed25519 algorithm is more modern, isn't it?
MicroLXC is lovable.
You're right, its more modern but not necessarily safer. A 4096 bit RSA key is considered secure.
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.
Thats not to say that we won't support ed25519 in the future but right now for the initial release RSA is the only supported algorithm.
You shouldn't be picky about algorithm.
Just let the user specify contents of
authorized_keysfile.Whatever user enters there are automatically uploaded to every new server.
We accept Karma donations for the last flan. 🍮 affbrr
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.
We will allow other algorithms going forwards although for this initial release and the foreseeable future we will only be supporting RSA.