Problem enrolling Linux JDS with the JSS

stevehahn
Contributor

I've got a CentOS VM (yes, I know, not actually supported) with JDS installed. When I try to enroll with the JSS, I get this error in the log:

2014-09-27 02:13:34,352 INFO Creating configuration file for https://casper.lynda.com:8443/
2014-09-27 02:13:34,932 INFO Starting Enrollment
2014-09-27 02:13:34,939 ERROR Communication error with the JSS 
2014-09-27 02:13:34,939 ERROR (77, 'Problem with the SSL CA cert (path? access rights?)')
Traceback (most recent call last):
  File "<string>", line 1143, in _perform
error: (77, 'Problem with the SSL CA cert (path? access rights?)')
2 ACCEPTED SOLUTIONS

paesbiger
New Contributor

We have the same issue, it works perfect to connect with Curl from the JDS to casper but the jamfds cannot run.

In our case the update coincided exactly with a security release for some NSS tools. A downgrade to these versions made everything come back to life:

nss x86_64 3.16.1-4.el6_5 sl6rolling-security nss-sysinit x86_64 3.16.1-4.el6_5 sl6rolling-security nss-tools x86_64 3.16.1-4.el6_5 sl6rolling-security nss-util x86_64 3.16.1-1.el6_5 sl6rolling-security

View solution in original post

were_wulff
Valued Contributor II

Hey all,

Just to let you know, we did get this behavior filed as a defect this afternoon. For reference, the ID number is D-007767.

If you'd like to contact your Technical Account Manager to open up a case and get it attached to the defect for tracking, please feel free to get in touch with them by sending an e-mail to support@jamfsoftware.com, giving them a call, or using the My Support section of JAMF Nation.

The current workaround is to roll back the packages that @paesbiger posted further up in the thread.

Thanks!
Amanda Wulff
JAMF Software Support

View solution in original post

20 REPLIES 20

lkrasno
Contributor II

Have you already ruled potential firewall issues?

Have a look at :

http://stackoverflow.com/questions/17064601/curl-not-working-error-77-for-ssl-connections-on-centos-for-non-root-users

rdwhitt
Contributor II

RHEL6.5 here. We just upgraded our test environment from 9.31 to 9.51 and are seeing this message after upgrading the root JDS. Our child JDSs have not been updated yet and are still communicating with the JSS as usual. Firewall rules are fine and permissions on the certs look fine.

I'll be playing with this today and let you know if I find anything.

alden
New Contributor

Me too. :(

winningham_2
Contributor

ditto...
This does appear to be related to the upgrade to JAMF 9.51 as our pre-upgrade environment (through testing) works without a hitch. Any previous to 9.51 JDS downloaded package works, but nothing since the upgrade was enacted. An upgrade fails with error 77 as well. So that is now NEW packages get replicated/deployed and no upgrade from a non 9.51 JDS can occur.

UPDATE: Some other JDS sites are using Ubuntu and those were upgraded without issue. So it appears to be limited to RedHat-based distributions, if anyone else would like to confirm that. In the meantime, I have opened up a ticket with JAMF so see if they are aware of the issue.

stevehahn
Contributor

Strange thing is, we're still on Casper 9.32 and so I'm trying to install JDS 9.3. It seems this is not just a 9.51 issue.

paesbiger
New Contributor

We have the same issue, it works perfect to connect with Curl from the JDS to casper but the jamfds cannot run.

In our case the update coincided exactly with a security release for some NSS tools. A downgrade to these versions made everything come back to life:

nss x86_64 3.16.1-4.el6_5 sl6rolling-security nss-sysinit x86_64 3.16.1-4.el6_5 sl6rolling-security nss-tools x86_64 3.16.1-4.el6_5 sl6rolling-security nss-util x86_64 3.16.1-1.el6_5 sl6rolling-security

alden
New Contributor

Rolling back to the previous nss packages fixed it for us to - thanks. Now if we can just get JAMF and RedHat to figure out what is broken.

were_wulff
Valued Contributor II

Hey all,

Just to let you know, we did get this behavior filed as a defect this afternoon. For reference, the ID number is D-007767.

If you'd like to contact your Technical Account Manager to open up a case and get it attached to the defect for tracking, please feel free to get in touch with them by sending an e-mail to support@jamfsoftware.com, giving them a call, or using the My Support section of JAMF Nation.

The current workaround is to roll back the packages that @paesbiger posted further up in the thread.

Thanks!
Amanda Wulff
JAMF Software Support

stevehahn
Contributor

stevehahn
Contributor
yum downgrade nss nss-sysinit nss-tools nss-util nss-softokn

Once NSS was downgraded, I was able to enroll successfully. Thanks again!

rdwhitt
Contributor II

This worked for us as well. Although initially I re-ran the installer after downgrading instead of just enrolling...which was hilarious since the packages just end up getting upgraded again.

mbracco
Contributor

My, do you have in the meantime a fix for that ? When will ads be compatible with rhel7 ?

jonathan_spiva
New Contributor

Downgrading didn't work for an install today, any other ideas.

stevehahn
Contributor

As @rdwhitt alluded to, you install JDS and have the enrollment fail, then downgrade nss, then re-enroll with ```
sudo jamfds enroll
```

In my experience, doing a full reinstall after downgrading nss didn't work.

matt_jamison
Contributor

Thanks @stevehahn ! Tried to run the full installer again and got the error, even after a downgrade. Ran the jamfds enroll command and all is well now!

@jonny74bit Downgrade the packages and just run jamfds enroll. Don't run the full installer again.

jonathan_spiva
New Contributor

Something cake'ed up the downgrade. After a few magic 'yum' commands to fix the downgrade the "jamf enroll" worked fine. Thanks for the help!

jrepasky
New Contributor III

Jonny what perhaps were those magic yum commands?

ahindistan
New Contributor

Hit the same issue. Downgrade did not help.

rdwhitt
Contributor II

Keep in mind that right now you will likely have to downgrade twice in a row since the NSS packages were updated again.

If you run "yum list nss" and see 3.16.1-4.el6_5, you should be good.

If you see 3.16.1-14.el6, run the downgrade command twice.

matt4836
Contributor II

During a jumpstart today we noticed that you needed to create a symlink of the /usr/bin/httpd binary to /usr/bin/apache2

Apparently the script is designed for Ubuntu, and on Red Hat the binaries have different names.