You compile your code so well!
Stallion 2 - pictures and daily updates :)
- Thread starter Francisco
- Start date
I have $20+ account credit with BuyVM for emergency use.
I got delayed a little bit on backups due to some visual changes I wanted to make.
Francisco
So I need some feedback.
Right now I'm plotting out how to handle the 'mounting' feature but I've hit a snag.
As of right now, someone could max out their diskspace with whatever, create a snapshot, then run a reinstall. They could then 'mount' the old snapshot and have 2x the diskspace. While it sounds like an insane idea, some users can be very cheap
So my proposal is to add a timer and or job lock to mounting. Once you mount the FS your VPS will be marked as busy until either the job finishes automatically after XY minutes/hours or you click 'unmount backup'.
Personally, I'm in favour and I'll explain why. Due to how we're 'mounting' the backups into a VPS, resetting/reinstalling/etc will make the mount drop anyway. If you're pulling backups/etc, then you wouldn't want someone else (or even just yourself) tampering inside stallion.
Granted, there will be a catch that will automatically clear the 'mount' flag if you issue a restart from inside your VPS anyways.
Right now I'm figuring 4 hours as the maximum mount time to be a reasonable amount. If you can't pull your backups within that amount of time then you should probably restore the whole damn thing anyway.
Feedback?
Francisco
Right now I'm plotting out how to handle the 'mounting' feature but I've hit a snag.
As of right now, someone could max out their diskspace with whatever, create a snapshot, then run a reinstall. They could then 'mount' the old snapshot and have 2x the diskspace. While it sounds like an insane idea, some users can be very cheap
So my proposal is to add a timer and or job lock to mounting. Once you mount the FS your VPS will be marked as busy until either the job finishes automatically after XY minutes/hours or you click 'unmount backup'.
Personally, I'm in favour and I'll explain why. Due to how we're 'mounting' the backups into a VPS, resetting/reinstalling/etc will make the mount drop anyway. If you're pulling backups/etc, then you wouldn't want someone else (or even just yourself) tampering inside stallion.
Granted, there will be a catch that will automatically clear the 'mount' flag if you issue a restart from inside your VPS anyways.
Right now I'm figuring 4 hours as the maximum mount time to be a reasonable amount. If you can't pull your backups within that amount of time then you should probably restore the whole damn thing anyway.
Feedback?
Francisco
We will be but if you get someone that writes very few changes but is simply a pusher box? Then it can still get abused heavily.
Francisco
telephone
New Member
How about just doing what SolusVM does for their 'Serial Console':
- Limited to one active session per VPS
- Drop-down list with available 'mounting' time blocks: 1 hour, 2 hours, 3 hours, 4 hours (maximum)
- User has the option to unmount early (cancel/finished button)
- At the appointed time limit, forcefully unmount
Other than that, I'd add a hard limit to the number of hours per day a backup can be mounted (per VPS):
- Backups can only be mounted for 12 hours a day (use DB row to keep track)
- This will prevent users from continuously mounting backups via a bot
Well, the thing with the unmounting is that if mount doesn't happen cleanly, it'll force power off the VPS to make sure it gets handled.
I was also thinking that the path we mount it to be partially randomized, that way you can't easily automate it.
We'd make a folder in /.stallion-3412edasdadasd or what have you and mount there. The folder would be different every time, that way there's no chance of overlapping with a users already existing folders and limits how easily a user can work around that. Granted, a bind mount would do it but that's still a lot of jiggering around to save a few dollars.
Francisco
I was also thinking that the path we mount it to be partially randomized, that way you can't easily automate it.
We'd make a folder in /.stallion-3412edasdadasd or what have you and mount there. The folder would be different every time, that way there's no chance of overlapping with a users already existing folders and limits how easily a user can work around that. Granted, a bind mount would do it but that's still a lot of jiggering around to save a few dollars.
Francisco
fixidixi
Active Member
To be honest I'm really i happy that there is still one place where i dont have to adblock that crappy google translate..
update: to be on the positive side: or there should be an option to turn it permanently on/off for a client
Last edited by a moderator:
Aldryic C'boas
The Pony
So, here's another update several folks have asked for:
Pushed some code this morning that I've been working on - you can now login with your email address on file instead of the PonyVM#### generated username.
Pushed some code this morning that I've been working on - you can now login with your email address on file instead of the PonyVM#### generated username.
mojeda
New Member
Finally! Thank you, I always forget my PonyVM ID and have to go scavenge in my email.
Since we've been talking about the anycast/floating stuff getting integrated soon, I figured i'd necro this thread and include some early screenshots to the changes we're making to the IP Addresses interface.
As you can see, we've moved the 'reverse dns' link and put it into the sub menu. We had way too many people that didn't really 'get' the way we had it setup so it was best to simply redo it. I might get rid of the caret on the drop down menu, not sure yet.
On each IP you'll notice we include the hostname of the VPS that has that IP floating, just to make it a bit easier for the users to know where IP addresses are coming from.
ANYCAST IP's are always marked as floating/high availability just to make our lives easier with binding and such. With that being said, every OpeNVZ VPS, no matter the plan, will be getting an 'ha0' interface inside their service that they will push HA addresses over. KVM's won't need this, instead they'll be able to bind to the appropriate interface (eth0 for public, eth1 for internal).
I was originally wanting to live AJAX the add/delete option for IP's and such, but due to the delay OpenVZ can inflict on binding/unbinding large amounts of IP's, I felt it would feel a lot quicker if we just kept going with the 'save changes' way.
Francisco
As you can see, we've moved the 'reverse dns' link and put it into the sub menu. We had way too many people that didn't really 'get' the way we had it setup so it was best to simply redo it. I might get rid of the caret on the drop down menu, not sure yet.
On each IP you'll notice we include the hostname of the VPS that has that IP floating, just to make it a bit easier for the users to know where IP addresses are coming from.
ANYCAST IP's are always marked as floating/high availability just to make our lives easier with binding and such. With that being said, every OpeNVZ VPS, no matter the plan, will be getting an 'ha0' interface inside their service that they will push HA addresses over. KVM's won't need this, instead they'll be able to bind to the appropriate interface (eth0 for public, eth1 for internal).
I was originally wanting to live AJAX the add/delete option for IP's and such, but due to the delay OpenVZ can inflict on binding/unbinding large amounts of IP's, I felt it would feel a lot quicker if we just kept going with the 'save changes' way.
Francisco
Last edited by a moderator:
I personally would really enjoy having the IP RAWR.RAWR.RAWR. Can I put in a request for that?
Joking aside, could you clarify the hostname and the IPs? I Don't see that on the screenshot or maybe I overlooked it?
Joking aside, could you clarify the hostname and the IPs? I Don't see that on the screenshot or maybe I overlooked it?
I blanked out the IP address
I'll take a new screenshot and just firebug in a random IP address.
Francisco
OH WAIT.I blanked out the IP address
I'll take a new screenshot and just firebug in a random IP address.
Francisco
Is the hostname UNDER the IP?
DomainBop
Dormant VPSB Pathogen
I already claimed the vaginalcyst.co.cc rDNS...
I hate you guys
Most of the data in here is compliments of bfj and co' in #frantech, they were the main bug testers.
Francisco