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.
SolusVM v1.16 + Security Updates
SolusVM v1.16.00 has been released.
Security
This release contains security updates as instructed in an external audit conducted by Rack911.
It is advised that you update to v1.16.00 as soon as possible to take advantage of the security changes made within the system. We will release further information about any issues found in due course.
If your version of SolusVM still displays v1.15.04 as the newest update you can initiate a manual update within your master from SSH with the following command: sh /scripts/upcp as the version numbers may be cached for a short while.
Fixes/Changes/Features
Added IPv6 subnets http://docs.solusvm.com/v2/Default.htm#Configuration/IPv6/IPv6-Subnets.htm
Added ipv6subnets output variable to the admin API vserver-create call
Fixed bug where ftp backups were not enabling correctly
Added column removal in node listings
Fixed a bug in the dhcpd functions
Added logrotate scripts
Fixed bug in admin API vserver-vnc call where it would return the socket host as a local address if using sockets on the master
Comments
OMG awesome
Thx for the post, good news on the IPv6 subnets (like really good news) but I am surprised to see in the documentation that no provision for conversion has been made or touched upon?
Few questions on the ipv6 subnets then which no doubt a few people are thinking.
Will it specifically avoid creating subnets that already contain addresses generated at random from the previous system?
Is there now or will there be something put in place to properly convert from one method to the other, right now it seems the steps I would have to take are?
1) Select a VPS
2) Click IP's button
3) Click the x next to each IPv6 address assigned
4) Remove the IP's from whmcs after finding the corresponding account.
5) Assign new IPv6 range
6) Update WHMCS with new IPv6 range.
7) Email customer with new IPv6 info.
Is that about the top and bottom of it?
Please upgrade LES when you have time :P
lol, I think the above needs answering first or I will end up killing LES
RIP LES, Long Live LES
Someone found something else in Solus that is vulnerable?
Okay sir
I suppose I should have: @soluslabs
@soluslabs what's the current proper way for submitting bug reports?
I asked that a number of weeks ago, you just submit a ticket.
Now I wonder from which provider will I get a subnet first.
How ipv6 subnets interract with ebtables? There were problem with single ipv6 and ebtables (solusvm doesnt create rule for ipv6), is it fixed or still need to use hook?
/64 welcome addition, seems to work well.
However a little concerned about interaction with pdns PTR records. Clients only see 1 PTR entry for the /64 in solusvm panel with no way of manually adding ipv6 address's from their subnet.
Hopefully this will make a future release, until that is resolved I am reluctant to make /64 the default.
@solusvm Any progress with user created backups that were promised in 1.16?
Seems when I add an Ipv6 subnet to my solus with this update, it doesn't actually create the entry, you add it, it says "success, click HERE" you click HERE, and it takes you to my most recent block added (which was an IPv4 block).
Edit: Forcing an upcp via cli appears to fix this.
IPv6 range added to a VPS, but only pings the first IPv6 of the block, the rest of the IPv6 in this range (VPS) don't ping it :S
Sounds like IPv6 still has some way to go in Solus.
But is a start
Not at the minute but we've just written the routines to cross-reference the singular IPv6 table. It will be added in a 1.16.x release.
This will still pass through the hook at this moment in time.
This is something we are addressing now.
Might be worth putting a ticket in as it all depends on your subnet configuration.
Fair enough, well I don't really want to do 60,000+ clicks to clean it up manually and start again or end up with duplication so I will wait for 1.16.x sorry @XxNisseGamerxX it is currently only a viable option for new nodes so LES wont be going this way for some time I suspect, I will delay Russia until this is available.
That is only half a job.
Why does it look like SolusVM is just rushing out releases to beat competition? I think SolusVM needs to take a step back and think before making any rushed out releases.
I also did think this. Quality > Quantity.
They probably did rush it out, but because there was an important security update included that couldn't wait. Can't blame them for this, security patches take priority.
They will probably fix the outstanding issues with incremental patches in the next days / weeks. I think they promised a minor release every week or so. At least they are out of their letargy period and seem to be actually trying to do something and improve things.
Yeah, Steven from Rack911 said it was "very important that you update to this release" on VPSB.
@rds100 in any case including a security fix with a release including new features is somewhat stupid, the security fix should be released independently of anything else
Because WHMCS would need to be updated as the callback does not seem to work with this and as you said I would then need to reassign every VPS a range, still around 30,000 clicks, no thanks.
I totally appreciate that this was a rush release and as @rds100 said it was critical that they pushed the release out so I would rather wait for the working version, it makes more sense to have half a feature than an gaping hole.
So I have one of my VPSes with the new SolusVM, and I am a bit confused.
The IPV6 block now shows up in my openvz as
inet6 addr: 2602:xxxx:x:x::/64
Do I have to manually assign the addresses (i.e. ::1, ::2) to interfaces in my system to use the addresses?
I already tried that (ip a a 2602:xxxx:x:x::1/64 dev venet0) but this didn't work apparently and the IP address still was not pingable. A "ip route get 2602:xxxx:x:x::1" on the host node showed that it was being routed to eth0 instead of venet0 (which of course has been shown by ip route get 2602:xxxx:x:x::). I will submit a ticket at Soluslabs later regarding that. Either it's some OpenVZ specific configuration I've overlooked on my private servers or SolusVM seems to be buggy on that.
End User Backup feature what you said in the blogpost?
Update: will be there after minor updates
Thanks.
Interesting solus has really been active since virtualizor released lots of new updates, well good thing for solus users means solus is trying there best so it seems, i am a virtualizor fan though, say no more.