Georg_R

Q: User profiles disappear after Open Directory service restart

Hi there!

 

I have noticed strange (as I estimate it) behaviour of the Profile Manager service.

Setup:

- server with OS X 10.9.3 and Server 3.1.1 installed

- clean Open Directory setup

- one test user added to the Workgroup

 

Scenario 1:

OD and PM services are running, user profile created in PM. After OD is restarted the profile dissappears. The same behaviour is observed for group profiles, but never for the devices (or device groups) profiles.

 

Scenario 2:

OD and PM services are running, user profile created in PM. After server restart the profile is still where it should be.

 

I was able to recreate the situation three times on three different machines.

 

Is this a bug or normal logic in Server?

If it's a logic behaviour how is it possible to keep the user and group profiles when the OD service is restarted?

Thanks.

OS X Server

Posted on May 22, 2014 7:06 AM

Close

Q: User profiles disappear after Open Directory service restart

  • All replies
  • Helpful answers

  • by COETech,

    COETech COETech May 29, 2014 12:29 PM in response to Georg_R
    Level 1 (5 points)
    May 29, 2014 12:29 PM in response to Georg_R

    I think this is related to what we see.

     

    Go into the Profile Manager web interface and find the Group. Check under Members to see if they are listed. If not click the Reload/Refresh button for the group. This seems to force PM to read OD and finds the group members.

     

    The problem seems to be that PM uses a query to find the members of the groups in OD, but this information isn't kept persistently in PM.

     

    This means that if users are logging in to download user profiles, they won't see the profiles until an admin goes in and clicks the reload/refresh button for the group.

  • by COETech,

    COETech COETech May 30, 2014 2:31 PM in response to COETech
    Level 1 (5 points)
    May 30, 2014 2:31 PM in response to COETech

    I've tried setting the User profile to Auto Download, what periodically happens is that PM will remove the User profile (it doesn't see that the user is in the group), but if you refresh/reload from the PM web interface that group, it will reinstall the profile.

    Again seems to be a bug in that PM doesn't keep persistent info from OD on who is a member of a group.

  • by MrHoffman,

    MrHoffman MrHoffman May 30, 2014 3:48 PM in response to Georg_R
    Level 6 (15,637 points)
    Mac OS X
    May 30, 2014 3:48 PM in response to Georg_R

    This isn't normal.

     

    OS X Server 3.1.2 lists various Profile Manager fixes.

     

    Verify DNS services, too:

     

    sudo changeip -checkhostname

     

    Launch Console.app and see if there are any relevant errors being logged, as well.

  • by Georg_R,

    Georg_R Georg_R Jun 1, 2014 11:45 PM in response to Georg_R
    Level 1 (10 points)
    Jun 1, 2014 11:45 PM in response to Georg_R

    Hi everybody!

    First of all thank you for your help.

    I didn't have time to try the solutions with 3.1.1, because 3.1.2 became available for download.

    After upgrade to 3.1.2 the problem has gone. I have tried several times already, now it behaves as supposed: you turn OD service off and then back on and the profiles are just at the same place as they were.

  • by Georg_R,

    Georg_R Georg_R Jun 3, 2014 12:31 AM in response to Georg_R
    Level 1 (10 points)
    Jun 3, 2014 12:31 AM in response to Georg_R

    Today after an OD service restart the problem came back. The profiles dissappeared. I restarted the server itself as well as the PM service. When trying to start PM service the following message is repeated several times before it starts working:

     

         serveradmin[2887]: NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9843)

     

     

    sudo changeip -checkhostname shows everything is ok.

     

    It looks like there is some problem with the Open Directory, cause replication stop working sometimes too (log entry form a replica):

     

         Node: /LDAPv3/127.0.0.1, Module: AppleODClientPWS - unable to read Password Server response - socket error on      socket fd 12: Resource temporarily      unavailable (5205)

     

    And then:

     

         slapd[40176]: slap_client_connect: URI=ldap://tm.accidentlaw.ru:389 ldap_sasl_interactive_bind_s failed (-2)

         slapd[40176]: do_syncrep1: client_connect failed (-1) - searchbase(cn=authdata) URI(ldap://tm.accidentlaw.ru:389)

  • by MrHoffman,

    MrHoffman MrHoffman Jun 3, 2014 6:01 AM in response to Georg_R
    Level 6 (15,637 points)
    Mac OS X
    Jun 3, 2014 6:01 AM in response to Georg_R

    The cited domain is incorrectly configured outside your network for this sort of thing, so I'll assume that you're using NAT and a parallel DNS server(s) inside your network.  There should be references only to your internal DNS server(s) on your NAT'd network, and no references to any DNS servers off your NAT'd network.

     

    OD doesn't look to be working, or isn't reachable, or is balking. 

     

    Check that the server certificate(s) in use are valid, current, and that they match the host name(s) in use for the server(s) you're working with.

     

    Failing that and if running a master and this is connecting to a replica, I'd likely demote the OD replica and then re-promote it, as a test.

     

    Have current OD and system backups before proceeding, etc.

  • by Georg_R,

    Georg_R Georg_R Jun 3, 2014 6:28 AM in response to MrHoffman
    Level 1 (10 points)
    Jun 3, 2014 6:28 AM in response to MrHoffman

    Correctly, we have external DNS and an internal one, which is the only available to the clients on the local network. The internal DNS server has the default gateway stated as the forwarding server. The local DNS server has both NS-record for the DNS-Server and A-records for both OD Master and OD Replica.

     

    When trying to look up the domain name inside the local network the result is the following:

     

    Trying "accidentlaw.ru"

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26211

    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

     

    ;; QUESTION SECTION:

    ;accidentlaw.ru.                              IN          ANY

     

    ;; ANSWER SECTION:

    accidentlaw.ru.                    10800          IN          SOA          accidentlaw.ru. admin.accidentlaw.ru. 2014051621 3600 900 1209600 300

    accidentlaw.ru.                    10800          IN          NS          mx.accidentlaw.ru.

    accidentlaw.ru.                    10800          IN          MX          0 mx.accidentlaw.ru.

     

    ;; ADDITIONAL SECTION:

    mx.accidentlaw.ru.          10800          IN          A          192.168.0.5

     

    Received 123 bytes from 192.168.0.5#53 in 157 ms

     

     

    mx.accidentlaw.ru is the OD replica and tm.accidentlaw.ru is the master:

     

    Trying "tm.accidentlaw.ru"

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26200

    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

     

    ;; QUESTION SECTION:

    ;tm.accidentlaw.ru.                    IN          ANY

     

    ;; ANSWER SECTION:

    tm.accidentlaw.ru.          10800          IN          A          192.168.0.91

     

    ;; AUTHORITY SECTION:

    accidentlaw.ru.                    10800          IN          NS          mx.accidentlaw.ru.

     

    ;; ADDITIONAL SECTION:

    mx.accidentlaw.ru.          10800          IN          A          192.168.0.5

     

    Received 84 bytes from 192.168.0.5#53 in 77 ms

     

    The certificates are valid. I have also tried to re-select them in the Server app.

    I have also recreated replica a couple of weeks ago, but will give it another try a little later.

     

    MrHoffman, do you think exporting users, recreating OD Master, importing users and recreating replicas can be a solution?

  • by Georg_R,

    Georg_R Georg_R Jun 3, 2014 6:38 AM in response to Georg_R
    Level 1 (10 points)
    Jun 3, 2014 6:38 AM in response to Georg_R

    By the way, I have noticed that replica is experiencing some problems with replication process:

     

    Jun  3 12:56:18 mx.accidentlaw.ru slapd[53990]: do_syncrep1: CONNECTED(0x7f8fc8e110e0) searchbase(cn=authdata) URI(ldap://tm.accidentlaw.ru:389)

    Jun  3 12:56:18 mx.accidentlaw.ru slapd[53990]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (32) No such object

    Jun  3 12:56:18 mx.accidentlaw.ru slapd[53990]: do_syncrep2: rid=001 (32) No such object

    Jun  3 12:56:18 mx.accidentlaw.ru slapd[53990]: do_syncrepl: rid=001 rc -2 retrying

    Jun  3 12:57:18 mx.accidentlaw.ru slapd[53990]: slap_client_connect: URI=ldap://tm.accidentlaw.ru:389 ldap_sasl_interactive_bind_s failed (-2)

    Jun  3 12:57:18 mx.accidentlaw.ru slapd[53990]: do_syncrep1: client_connect failed (-1) - searchbase(cn=authdata) URI(ldap://tm.accidentlaw.ru:389)

    Jun  3 12:57:18 mx.accidentlaw.ru slapd[53990]: do_syncrep1[done]: si_ld(0x0) Can't contact LDAP server (-1)

    Jun  3 12:57:18 mx.accidentlaw.ru slapd[53990]: do_syncrepl: rid=001 rc -1 retrying

    Jun  3 12:58:18 mx.accidentlaw.ru slapd[53990]: do_syncrep1: CONNECTED(0x7f8fc8d86340) searchbase(cn=authdata) URI(ldap://tm.accidentlaw.ru:389)

     

    Doe sit mean all of these problems are coming from OD master?

  • by Georg_R,

    Georg_R Georg_R Jun 3, 2014 6:54 AM in response to Georg_R
    Level 1 (10 points)
    Jun 3, 2014 6:54 AM in response to Georg_R