Closed carlalexander closed 8 years ago
$(hostname --fqdn)
can be replaced by $(hostname -f)
. Here's the new error:
dnsdomainname: command not found
I don't have access to a MacOS X system to test. I have asked specifically for MacOS X testers before merging the role, on IRC and on GitHub.
Does the script work if you change the shebang to #!/usr/bin/env bash
? What does your $PATH
look like, is /usr/local/bin
listed before /bin
(as it should be)?
Does hostname -f
return the full FQDN (at least 1 dot), or just a hostname?
What do you get when you run type dnsdomainname
in the terminal? I suppose that I can use an alternative method of getting the domain if this command is not available.
hostname -f
returns Carls-MacBook-Air-2.local
. So there's the dot. I suggested it because according to the man page on Linux -f
and --fqdn
are the same.
dnsdomainname
doesn't exist. I'm not sure what command to use for that one.
The other issue that I just looked at is that openssl
is out-of-date. So that's something to keep in mind as well for Mac OS X users. Also there was some notes when I installed it, I'll copy them here in case they're useful:
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
/usr/local/etc/openssl/certs
and run
/usr/local/opt/openssl/bin/c_rehash
This formula is keg-only, which means it was not symlinked into /usr/local.
Apple has deprecated use of OpenSSL in favor of its own TLS and crypto libraries
Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:
LDFLAGS: -L/usr/local/opt/openssl/lib
CPPFLAGS: -I/usr/local/opt/openssl/include
I will take care of the dnsdomainname
by parsing hostname -f
, I hope that MacOS X handles Bash variable substitution, you never know...
How out of date that OpenSSL is? Can it be updated? I suppose that if you provide me with functions that handle certificate request generation, key generation, signing, etc., they could be added to the script. That's how it supports both OpenSSL and GnuTLS right now, so one more shouldn't hurt.
Although, as with GnuTLS right now, I'm not sure how extensive Apple-TLS-based CA would be. From my experiments, GnuTLS CA is pretty limited, that's why I chose OpenSSL as a default CA.
Did the new shebang do the trick?
Yes! sorry forgot about that. The she bangs seems to have worked.
OK then, I'm working on updates to the role.
@carlalexander The https://github.com/debops/ansible-pki/pull/43 pull request should fix some issues on MacOSX.
Thanks will test it out soon. I'm flying tomorrow so weekend more likely.
I just tried it with your changes from #43. Works fine now!
I would vote for reopening this, since some issues still prevent this role from working on OS X:
TASK [debops.pki : Sign certificate requests for current hosts] ****************
fatal: [ec2-1-2-3-4.eu-central-1.compute.amazonaws.com -> localhost]: FAILED! => {"changed": false, "cmd": ["./lib/pki-authority", "sign-by-host", "ec2-1-2-3-4", "ip-172-31-49-63.eu-central-1.compute.internal"], "delta": "0:00:00.015779", "end": "2016-09-02 23:08:54.622601", "failed": true, "rc": 2, "start": "2016-09-02 23:08:54.606822", "stderr": "./lib/pki-authority: line 82: declare: -g: invalid option\ndeclare: usage: declare [-afFirtx] [-p] [name[=value] ...]", "stdout": "", "stdout_lines": [], "warnings": []}
@antoineco This is due to an old bash
version on MacOS X. I suppose that the pki-authority
and perhaps pki-realm
scripts would need to be rewritten in Python to fix that permanently. I wrote them in Bash initially because most things they do is move/link files around and run openssl
and certtool
commands. In Python, I would probably use the respective libraries instead, but I didn't have the drive to learn that at the time. At that moment I was also doing the complete role redesign, and Bash for me seemed a good idea for a first implementation.
Alternatively, you could update your Bash to 4.x version, that should work fine.
@drybjed you're right, I though the -g
flag was the issue but actually associative arrays are also a feature added in bash 4.2.
On OS X a simple brew install bash
will install GNU bash, version 4.3.46(1)-release (x86_64-apple-darwin15.5.0)
and your script will use it automatically. Thanks for your answer!
I've running tests with the new role on OSX. I can't get the PKI role to work at all. At first, I thought it was a server issue, but
pki-authority
runs on the local machine. This creates a bunch of issues.The first issue is with the bash 4.3.0 requirement. The requirement isn't a deal breaker in itself, but Apple has no intention of supporting GPLv3 versions of bash. This means that we can only install bash 4.3.0 using homebrew. We can't and shouldn't replace the bash executable found in
/bin/bash
.Because of this,
pki-authority
doesn't work. It runs using/bin/bash
which is always going to be on bash 3.2. You'll get this error:I fixed it by editing
pki-authority
to use/usr/local/bin/bash
. This got rid of the error, but that's not a long-term option.I also found another issue once the script could go a bit further.
$(hostname --fqdn)
throws this error on OSX:I haven't found a solution to this error. That said, I'm not sure the script is designed to run on OSX at all at this point. This is a pretty big problem for people that use DebOps on OSX. We can't run the
debops
command to run the default playbook without it failing.