Got me a brand new *FAST* VPS

[__]

This is admittedly more of a theoretical exercise.

Thought so.

I was thinking about a sub domain that isn’t indexed and requires login

That’s what I usually do.

And I use htpasswd, so it doesn’t rely on the application for authentication.

Is it really an unchecked gateway though?

Well, I wasn’t quite sure of the context of your question. If there were multiple people authorized to pull in changes, or if all commits were pushed to the server automatically (even if it was to a dev repo and not the live site), then it wouldn’t be a risk I would take.

And, at the end of the day, if you auto-push from github, then an attacker doesn’t need your ssh keys: just to break into your account. It could conceivably bring your last line of defense down to the level of session hijacking.

I would make a copy of your release server or setup a VM on my home network and get some ip addresses from my isp to link with my test domain name.

I don’t think this level of effort is necessary. As long as your dev environment is reasonably similar to your live environment, you should be fine. And you certainly don’t need to buy extra IPs (just edit your hosts file, or run a local nameserver).

The main reason I put an actual dev site on the server (as opposed to “just” a repo), is because it is an opportunity to do last-minute testing in a known identical environment.

I think I found the answer to this question

Hey, pretty cool.

[nixnerd]

All of what has just been said is super awesome…

I think I’m going to use containers and contain/separate all my domains.

Then, I’ll have a container just for tests. Although, apparently this isn’t suitable for testing package updates/upgrades. So… I’m going to just use VirtualBox for that. It seems like the easiest option. Test of VirtualBox before I update my PC. Test on my PC before I update Server. Then… update server.

The nice thing about containers is each one has its own separate domain. So… a test container is no problem :)

[__]

apparently this isn’t suitable for testing package updates/upgrades.

How so?

[nixnerd]

Well, as I understand it, containers share a common kernel. See, they don’t attempt to pretend they’re their own machine. They’re not a fully blown VM. So, they are separate, but the kernel is the one thing that links them. I would think a kernel update is the most prone to breaking all your packages… therefore, it just won’t work.

[nixnerd]

See, they don’t attempt to pretend they’re their own machine.

For this reason, the performance server-wide is much better than with an emulator or VM. Containers don’t hog system resources that they’re not using… like a Xen or KVM situation.

[__]

Ah. gotcha.

[Author]

Posts