Charm Needed: VPN endpoint

Reported by Mark Mims on 2011-11-23
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Juju Charms Collection
Medium
John Patterson

Bug Description

Provide a VPN endpoint to proxy user communication to the deployed internal juju environment... several options: openvpn, ssh, ssl, etc

"VPN" implies isolation, but this is more about access... maybe name the charm accordingly

Related branches

lp:~nextrevision/charms/precise/openvpn/trunk
Merged into lp:charms/openvpn at revision 6
Marco Ceppi: Approve on 2014-01-29
Matt Bruzek: Approve (+1) on 2014-01-28
John Patterson (nextrevision) wrote :

I'm currently working on an implementation for the community version of OpenVPN. I have the charm mostly completed and am running through the first serious phase of testing in the next few days. Hoping to have it ready quite soon.

Changed in charms:
assignee: nobody → John Patterson (nextrevision)
status: New → Incomplete
John Patterson (nextrevision) wrote :

This charm provides the OpenVPN service as maintained in the Ubuntu package archives. Going through the process of creating a charm like this has brought up a number of questions, and while the charm in my testing appears to be fully functional, I would greatly appreciate feedback on a few items as well as anything else you feel would be nice to add in future releases.

1) Is providing a way via a configuration option for managing users a bad idea? I.e. juju set openvpn users="johnd,joed,janed".
2) Should I look at implementing a method to manage the CRL via a similar manner or just leave all user administration to be done manually (minus the initial user)?
3) Is there a more logical/secure way of transferring certificates off the server than the one currently implemented?
4) I'm having a bit of a rough time figuring out what this charm can provide and ways to integrate it with other charms. Would adding a future VPN interface through which other charms can connect be accessible via the VPN be useful? Any other suggestions?
5) Upgrading the charm by running the install hook would wipe out all certificates/keys and render issued certs/keys invalid. Is it even necessary to include that hook in this charm?
6) Would HA/failover/scaling be worthwhile in this charm (trying to determine the intended audience)?

I'm hoping this charm can be something really useful and would greatly appreciate any input you have.

Thanks!

Changed in charms:
status: Incomplete → In Progress
Marco Ceppi (marcoceppi) wrote :

Hi John!

Thanks for submitting this, we really appreciate it. Sorry for the delay in review we'll have this looked at shortly!

John Patterson (john-n) wrote :

Hey Marco,

Thanks for the update. Just for clarification, this charm is the "community" version of OpenVPN instead of the "Access Server" version, the latter being a more presentable wrapper around the former. So by no means is it a replacement, just a different option for those wanting OpenVPN.

Thanks!

Marco Ceppi (marcoceppi) wrote :

Reviewing this now!

Marco Ceppi (marcoceppi) wrote :

Hi John,

Thanks again for the submission. This charm looks great, I just had a few questions prior to promulgation:

- The vpn-server hooks are currently empty, is that expected?
- The copyright isn't assigned to anyone, just simply "Copyright 2013"
- The readme makes no mention of the domain configuration option, also it's something that's only used during install for the cert. Should/Is it possible to re-configure the certificate during deployment? If so most of that logic will likely need to be copied if not moved to the config-changed hook to facilitate this. If it can't be moved it needs to be documented in the README

Otherwise, awesome work! Look forward to promulgating this to the store soon!

Changed in charms:
status: In Progress → Incomplete
John Patterson (nextrevision) wrote :

Hey Marco,

Thanks for reviewing this and sorry it took so long to get around to making the changes. Below is a description of what I did based on your follow up:

- Removed the empty hooks and removed a "provides" section in the metadata.yaml (will this cause blocking proofing errors?)
- Updated the copyright
- Added the domain variable to the documentation
- Added (hopefully) some clarification on pre/post installation settings in the overview and other sections

No functional code changes were made. So it should be good unless you spot anything else.

Thanks!

Changed in charms:
status: Incomplete → In Progress
Jorge O. Castro (jorge) on 2013-09-25
Changed in charms:
importance: Undecided → Wishlist
importance: Wishlist → Medium
Marco Ceppi (marcoceppi) wrote :

Thanks for your submission! This has been promulgated!

Changed in charms:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers