freebsd-digitalocean
freebsd-digitalocean copied to clipboard
FreeBSD Port
Hi, was poking around with these scripts today and decided to write up a FreeBSD Port for them. Wanted to run it by you before submitting it.
It does avoid using update.sh
, doing basically the same things in a do-install
target and making use of the @sample
macro in the plist for handling the conf file.
Cool! And I see you work at DigitalOcean. :)
Before taking on the next step of making a package out of this, I was waiting on two things: the FreeBSD 11 release image to become available on DO so I can test/revise these scripts if needed, and I also needed to get some feedback on the IPv6 support. Even though I coded it in, I'm not using IPv6 anywhere (yet) so I'm not even sure if it works.
I've never officially made or submitted a package for the FreeBSD pkg repos, so I'd follow your lead on that. I looked over the zip file and it seems fine. As for the project itself, I would recommend that someone "in the know" take a good look over all of this and sanitize it before committing to an official package. You've got my support and blessing on whatever makes this better. Big thanks!
Hi there! Any news on this issue? Freebsd 11 was released on DO, I'd like to use your scripts :P
From a quick check, it should not break the installation, but I might have missed some detail.
Thanks in advance, very useful project! :-)
Andrea, the scripts work fine with FreeBSD 11.0-RELEASE. I cannot vouch for IPv6 support yet.
Just did some quick testing on an 11.0 droplet w/ IPv6, and it all looks good to me.
Wow! That never happens! Thanks for checking that. What do we need to do now to this project to make it FreeBSD pkg capable? Or is that a completely separate project? Perhaps I should read up on pkg creation/submission.
Chip, one more question you might have the resources to check for us. Would there be any legal issues with DO by using their name in the package? Lukas Schauer (@lukas2511) who did the Let's Encrypt shell script project (https://github.com/lukas2511/dehydrated) ended up having to rename it from "letsencrypt.sh" to "dehydrated" due to trademark issues. Before we make an official pkg, we probably should get clearance on the names "freebsd" and "digitalocean" to avoid a forced renaming later.
@icosahedral do you have any insight regarding the last comment?
I asked around a bit internally, and it doesn't look like we have an official policy, but I was pointed at koalalorenzo/python-digitalocean as an example of another 3rd party project that we don't mind. If you'd like an official reply, may need to hit up [email protected].
This whole issue has me wondering about the project name.
Other than FreeBSD-specific startup support and filesystem paths, which could be abstracted via the config file or OS hints, would there be interest in this plain Bourne shell script on any other OS? If so, having "freebsd" in the name is unnecessarily limiting. I imagine any Linux or other BSDs could adapt this for similar purposes.
Plus, how many FreeBSD packages and services have "freebsd" in the name aside from the 30+ "FreeBSD Project" doc packages? Virtually none that I could see. So if anything I'd drop the "freebsd-" prefix. That leaves "digitalocean" which is not descriptive enough. Getting rid of both eliminates trademark concerns.
So maybe renaming this project to something else makes better sense? Ideas...
- do-init
- do-startup
- do-config
Maybe "droplet-" instead of "do-" as a prefix? I think the only requirement is it should be an acceptable basename for the command line executable, config file, etc.
Comments/suggestions?
Hi guys, thank you for the replies ;-)
About the project name, I'd suggest to not rename the github project, at least to make ti simpler to find it on google :-P
Thank you again for the replies, good work!
Chip (@2bithacker), are you still interested in making a pkg for this? There's been some renewed interest in updating this for current DO FreeBSD images as well as adding some additional features. Having someone who works at DO to be the gatekeeper on the pkg seems like a really great idea.
Yeah, this is still relevant to my interests. I should have some time later this week to look at writing up a port Makefile.