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
You can change the VNC password in Wyvern already via a button. I'll look into disabling access to it though.
Thanks for the info about the spamming, this is one of the things that will be fixed in the rewrite.
I'm not sure what you mean by that. Do you mean add the option to enable/disable console access?
@KuJoe
Not only do I fully agree that a (hopefully good and not only browser accessible) console is an absolute must, but I also suggest to create longer passwords (min.len 15), ideally also containing "special chars" for console access.
It's the base version installed via YUM, it's identical to what is installed on our SolusVM KVM node.
EDIT:
Wyvern Node: Package 2:qemu-kvm-0.12.1.2-2.491.el6_8.7.x86_64 already installed and latest version
SolusVM Node: Package 2:qemu-kvm-0.12.1.2-2.491.el6_8.7.x86_64 already installed and latest version
I'll increase the character count and add a few special characters for good measure.
Yes. Checkbox on, bound to external IP; not checked, connected to loopback (or just removed from command line).
Now that's really strange. You may have something built NOT from the standard repos that might be causing a library colission, or something else. You may have found a magical command line/firmware set that makes it unstable. Really, will have to ldd your binaries and compare the libs used, and debug the command line.
Have a good trip!
I agree. Console access should be explicitely turned on in the panel. Even more it should trigger a limited time port opening, say 3 hours and only from the source IP from which the panel was accessed.
As for qemu and BSD I remember that I once had to research something similar for a provider. linux worked fine but BSD didn't. iirc it was some disk related parameter.
qemu again: I'd advise against using (not self built) packages. It's much better to build them oneself for such critical stuff. From what I see here I'd guess that running ./configure --help would be helpful ...
One thing is clear: If it works with 1 GB RAM then that might provide some clues but is definitely not the problem issue. Both FreeBSD 10 and 11 run without any trouble and comfortably in 256 MB. I know for sure because I had not only name servers and mail servers but also http running in it.
I can also confirm this.
By the way, has anyone tried to install NetBSD on KuJoe's system? If FreeBSD and OpenBSD fail, I guess that NetBSD also fails.
Don't leave a security to chance. With every new VPS the chances for attackers rises. In addition if you trust VNC server as it is, after few tries to login with invalid password it will start to deny every new connections until restart. This will make customers upset, because they won't be able to use VNC.
In my opinion VNC colsole should be disabled by default and only enabled for OS installs (try to link it with mounting .iso) and when customer enables it for themselves (with estimated usage time). In addition to that, VNC should be only accessible for the IP used in CP to enable it. Later you can code management for whitelising IPs, so the customers can add other IPs.
@MrPsycho
Yes and no. No, vnc should not be available only on installs; that's be nonsensical. But yes, access should be limited and controlled (see my post above).
Btw., I'm not under the impression that @KuJoe is easy about security. He immediately reacted positively on an advice from me. But you should also see the nature of software beta testing. vnc security is important but it's not at the core right now. I take it that KuJoe right now is most concerned about the Wyvern core functionality and that, once that works well, will look at related issues such as vnc security.
@bsdguy Maybe I was not sufficiently clear (starting a day without coffee
), but I meant pretty much the same as you. Clarifying there should be two options to have VNC enabled:
enabled manually via CP for predefined time with option to extend that time
while installing OS (mount button should be linked to VNC enable button)
In both cases VNC should be protected with firewall, that grants access only to whitelisted IPs.
I don't like the firewall/whitelisting idea but I will definitely add the ability to enable and disable VNC in Wyvern along with a longer randomly console generated password.
The only reason why you should use a paid cert is for the warranty they offer. Is a data leak caused by the SSL or the SSL company, there is a warranty that will cover any fees related to the downtime or leak.
It is why EV SSLs have $1,500,000 of warranty.
You just pulled that out of your ass, bother reading the actual warranty document.
So hostile.
Warm and sweet LET
I doubt it as well. That it fails right when OBSD hands off from init really has me confused because that failure is hard-every time. I don't know what it might possibly tickle in QEMU to do that, but it does.
FYI VNC has an 8 character max password length so you can make it as long as you want, it won't use more than the first 8 characters.
Francisco
Is impressive that in 2017 vnc still have such limitation.
You should have seen me on my IRC days.
Just out of curiousity and risking derailing this topic. How does this actually work? What's the insurance for? Do they ever pay out and what for? Sorry if this is a dumb question but I can seriously not think of a single case where I would need insurance on a certificate.
It's bullshit- like flight insurance. If somehow the data is compromised and used nefariously, the insurance is supposed to pay to get everything back to normal with all fees/et al.
Kind of like the guy who used to advertise his social security number, and then 4chan (I think?) decided to make his life hell. Don't know if he's around anymore, but haven't seen those commercials in about a decade.
Cheers Just what I was thinking. Chances of them screwing up are slim I guess. Compared to the chance of data being compromised as a result of a faulty setup on the user's end that is. And if they messed up I'd sue anyway.
The biggest reason not to use an LE certificate is: Anyone who knows what LE is will know you're too hokey to buy your own certificate. That's really what it boils down to.
I'm not current for the very-latest DSS, but I won't doubt that it will (eventually) have provisions against LE/free certificates, but there was nothing specific about that under Requirement 2.4, the last time I was certified. Yes, keys/certificates currently fall under 2.4 (as far as 3.0 is concerned)- Maintain an inventory of system components that are in scope for PCI DSS.
Since this is the second time I read this in the last few days, I'll ask. Where did you actually read an ssl warranty that say anything about data compromised etc.? The only thing the warranty is about is in case THEY didn't follow THEIR OWN certificate issuing procedures.
Happy to be proven wrong, link me the docs (anyone)!
The last time I actually read (bothered) with what was covered, I was running Apache/Strongbox with a Thawte certificate. I just assume the terms are still the same, because I've never been actually called out that this may have changed drastically in 20 years.
Thanks @WSS - Thawte 's one I hadn't looked at, so it was a nice chance. This is what it seems to be now:
The CPS (mentioned in the iii) ):
I believe the warranty was actually supplemental, but if you cruise around in the wayback machine, you'll find virtually every SSL certificate vendor had some "XX,XXX" guarantee. I don't care to dig through a lifetime ago of archives to bother. I'd rather just throw my Solaris 2.6 5/98 books at your head.
They still do and EVs go to some $ millions in warranty - it's just that the warranty covers ... nothing really
This is why I post about it every time I see someone mentioning about the warranty.
No, please no, they used to make those things real heavy back in the day
All I know was that our lawyers spent at least a week talking to Thawte about them, and what they'd cover. It was the only way we were able to get a top-3 broadcast network as a client back then. Don't care anymore.
They were made out of paper that came from this thing called trees. Maybe you've seen pictures of them- I don't know. The big FaceGoogleZon disk crash of 2104 took out pretty much all records before 2100. Now, all we have are memories that we'll get wiped if we dare speak of them..
Ah, memories.
No- that's just more jumbled data. I seem to recall that as being "Genderfluid Models: 2020"