I assume the server is freshly installed and does not have any keys preinstalled.
First things first:
1. Install stonevpn and openvpn
If you now try to run stonevpn, you will see it gives some errors, so...
2. Fix your openssl config file.
In particular fill the sections req_distinguished_name and in CA_default the dir location. I set mine to /etc/ssl/CA (you need to create this hierarchy).
3. Create the index.txt and serial files.
When running stonevpn -a we should get an empty list of client certificates. If you're here, so far so good.
4. Generate the server's certificate that will be used to sign all the other client certificates (steps taken from here). Do these in /etc/openvpn since this is by default in the /etc/stonevpn.conf. The names are also server.key and server.crt so it is better to just use these ones.
5. Next we need to update the pyOpenSSL to have support for X509Extensions. We can see that a simple test run will fail:
So we need to download and build pyOpenSSL.
6. Now we're good to go.
While the naming conventions are different, in spirit they do the same thing. The problem with this approach that if you do instead of:
you won't even notice it unless many hours of pointless debugging have passed.
Since we're developers here, some API calls would look like:
Note, that it doesn't mean this should be the final API. Personally I think the best looking API is something along the way that after the registration, you could call the API only via members of the on object. Something like this:
But I am convinced that the actual event types should be tied to the object that can generate them.
In my opinion this approach has these advantages:
The only drawback I can think of, is that you can't listen to events before they are registered, but I haven't yet seen any real life application where this actually happens.
Since FuseVPS is closing its doors (I was hosting this site at them with merely 5$ a month), I will need to switch from them. Since apparently their hardware layer provider decided to simply close their server without saying, guess what vendor I won't pick.
Original message from FuseVPS is here:
I regret to inform you that FuseVps will be closing its doors.
Due to complications with our dedicated server provider, Softlayer, we are unable to continue with FuseVps.
You may have noticed other OpenVZ providers discontinue their service at Softlayer over the last 12 months. While we cannot say this with certainty, we would not be surprised if they found the same difficulties we have.
If your server is located on Odin, Softlayer disconnected the public access with no warning. We have requested on numerous occassions this be put online for you to acquire backups, and Softlayer has refused. For all other servers, you will have until Feb. 28 to backup any data and move to a new provider.
All paypal subscriptions have been cancelled. You should not get invoiced. All accounts will run unsuspended until Feb. 28.
It has been an honor working with you, our wonderful clients.
Bye-bye FuseVPS I enjoyed using your services.
I just received recently an email that had it's title looking like:
Yes it actually writes that. When opening it I got a reassuring introduction:
But there still is a lie in there:
"is pretty close"
What if you have a "users" table, and all the properties for the users are in the "property" table. Would a select like this be efficient in PosgreSQL?
Surprisingly this is quite OK, since PostgreSQL won't be stupid enough to do the full Cartesian product. I love you PosgreSQL.
The one to rule them all. The browsers that is.
SharpKnight is an Android chess game.
MagicGroup is an eclipse plugin.