pki-authority doesn't work on OSX

[carlalexander]

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:

line 62: declare: -g: invalid option

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:

hostname: illegal option -- - 

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.

[carlalexander]

$(hostname --fqdn) can be replaced by $(hostname -f). Here's the new error:

dnsdomainname: command not found

[drybjed]

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.

[carlalexander]

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

[drybjed]

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?

[carlalexander]

Yes! sorry forgot about that. The she bangs seems to have worked.

[drybjed]

OK then, I'm working on updates to the role.

[drybjed]

@carlalexander The https://github.com/debops/ansible-pki/pull/43 pull request should fix some issues on MacOSX.

[carlalexander]

Thanks will test it out soon. I'm flying tomorrow so weekend more likely.

[carlalexander]

I just tried it with your changes from #43. Works fine now!

[antoineco]

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": []}

[drybjed]

@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.

[antoineco]

@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!