stephan (Germany)

Q: After Updating to Server 4.1 Open directory and LPAD gone

Hello,

 

two days ago I discovered that Open directory was not working on our Server (Mac Mini 2012). I suspect it stopped working after updating to 10.10.3 and OS-X Server 4.1. When I try to start Open directory in the Server App the Server App prompts: Unable to load Replica List. When I try to recreate my Open directory Server I Get: OD Server already exists.

 

I get the following log entries:

 

LDAP Log

 

Apr 11 22:03:02 server.seju.eu slapd[925]: @(#) $OpenLDAP: slapd 2.4.28 (Feb 24 2015 21:45:59) $

  root@osx202.apple.com:/BinaryCache/OpenLDAP/OpenLDAP-499.32.4~1/Objects/servers/slapd

Apr 11 22:03:02 server.seju.eu slapd[925]: daemon: SLAP_SOCK_INIT: dtblsize=8192

Apr 11 22:03:02 server.seju.eu slapd[925]: TLS: OPENDIRECTORY_SSL_IDENTITY identity preference overrode configured olcTLSIdentity "APPLE:server.seju.eu"

Apr 11 22:03:02 server.seju.eu slapd[925]: slap_add_listener: opened additional listener 'ldaps:///'

Apr 11 22:03:02 server.seju.eu slapd[925]: bdb(dc=server,dc=seju,dc=eu): unable to allocate memory for mutex; resize mutex region

Apr 11 22:03:02 server.seju.eu slapd[925]: bdb_db_open: database "dc=server,dc=seju,dc=eu" cannot be opened, err 12. Restore from backup!

Apr 11 22:03:02 server.seju.eu slapd[925]: bdb(dc=server,dc=seju,dc=eu): txn_checkpoint interface requires an environment configured for the transaction subsystem

Apr 11 22:03:02 server.seju.eu slapd[925]: bdb_db_close: database "dc=server,dc=seju,dc=eu": txn_checkpoint failed: Invalid argument (22).

Apr 11 22:03:02 server.seju.eu slapd[925]: backend_startup_one (type=bdb, suffix="dc=server,dc=seju,dc=eu"): bi_db_open failed! (12)

Apr 11 22:03:02 server.seju.eu slapd[925]: bdb_db_close: database "dc=server,dc=seju,dc=eu": alock_close failed

Apr 11 22:03:02 server.seju.eu slapd[925]: slapd stopped.

 

 

 

Open Directory Log

 

2015-04-11 21:57:10.624284 CEST - AID: 0x0000000000000000 - opendirectoryd (build 382.20.2) launched...

2015-04-11 21:57:10.752590 CEST - AID: 0x0000000000000000 - Logging level limit changed to 'error'

2015-04-11 21:57:10.916732 CEST - AID: 0x0000000000000000 - Initialize trigger support

2015-04-11 21:57:10.951833 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/SystemCache.bundle'

2015-04-11 21:57:10.958469 CEST - AID: 0x0000000000000000 - Module: SystemCache - failed to load persistent state - Input/output error

2015-04-11 21:57:10.962533 CEST - AID: 0x0000000000000000 - Registered node with name '/Active Directory' as hidden

2015-04-11 21:57:10.962833 CEST - AID: 0x0000000000000000 - Registered node with name '/Configure' as hidden

2015-04-11 21:57:10.963182 CEST - AID: 0x0000000000000000 - Discovered configuration for node name '/Contacts' at path '/Library/Preferences/OpenDirectory/Configurations//Contacts.plist'

2015-04-11 21:57:10.963194 CEST - AID: 0x0000000000000000 - Registered node with name '/Contacts'

2015-04-11 21:57:10.963438 CEST - AID: 0x0000000000000000 - Registered node with name '/LDAPv3' as hidden

2015-04-11 21:57:10.966901 CEST - AID: 0x0000000000000000 - Registered node with name '/Local' as hidden

2015-04-11 21:57:10.968600 CEST - AID: 0x0000000000000000 - Registered node with name '/NIS' as hidden

2015-04-11 21:57:11.031990 CEST - AID: 0x0000000000000000 - Discovered configuration for node name '/Search' at path '/Library/Preferences/OpenDirectory/Configurations//Search.plist'

2015-04-11 21:57:11.032007 CEST - AID: 0x0000000000000000 - Registered node with name '/Search'

2015-04-11 21:57:12.343838 CEST - AID: 0x0000000000000000 - Discovered configuration for node name '/LDAPv3/127.0.0.1' at path '/Library/Preferences/OpenDirectory/Configurations/LDAPv3/127.0.0.1.plist'

2015-04-11 21:57:12.343888 CEST - AID: 0x0000000000000000 - Registered subnode with name '/LDAPv3/127.0.0.1'

2015-04-11 21:57:13.549377 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/legacy.bundle'

2015-04-11 21:57:13.551131 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/search.bundle'

2015-04-11 21:57:13.554053 CEST - AID: 0x0000000000000000 - '/Search' has registered, loading additional services

2015-04-11 21:57:13.554064 CEST - AID: 0x0000000000000000 - Initialize augmentation support

2015-04-11 21:57:13.557920 CEST - AID: 0x0000000000000000 - Successfully registered for Kernel identity service requests

2015-04-11 21:57:13.557940 CEST - AID: 0x0000000000000000 - Adjusting kernel ID cache (100 -> 250) and membership cache (100 -> 500)

2015-04-11 21:57:13.575235 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/PlistFile.bundle'

2015-04-11 21:57:13.578418 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/FDESupport.bundle'

2015-04-11 21:57:13.583810 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/AppleID.bundle'

2015-04-11 21:57:13.615788 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/ConfigurationProfiles.bundle'

2015-04-11 21:57:13.619666 CEST - AID: 0x0000000000000000 - Registered subnode with name '/Local/Default'

2015-04-11 21:57:13.632498 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/ldap.bundle'

2015-04-11 21:57:13.845588 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/AppleODClientLDAP.bundle'

2015-04-11 21:57:13.849664 CEST - AID: 0x0000000000000000 - Loaded bundle at path '/System/Library/OpenDirectory/Modules/AppleODClientPWS.bundle'

Mac mini, OS X Yosemite (10.10.3), Server 4.1

Posted on Apr 11, 2015 1:45 PM

Close

Q: After Updating to Server 4.1 Open directory and LPAD gone

  • All replies
  • Helpful answers

Previous Page 2
  • by MrHoffman,

    MrHoffman MrHoffman Apr 21, 2015 7:16 AM in response to stephan (Germany)
    Level 6 (15,627 points)
    Mac OS X
    Apr 21, 2015 7:16 AM in response to stephan (Germany)

    1) That is common and reasonable advice for a client computer system.  Client computers get their services from servers.  You're running a server now, and you want and need your local clients to use your server(s) for the various local network services.   Accordingly, the details of the local requisite network configuration will necessarily change.

     

    2) I don't know about Apple's configuration assistant here.  I enter the domain or subdomain entries and the translations into Server.app. The default OS X Server install for folks that don't already have a local DNS server — if that is what you are referring to here — is enough to get your server going with correct forward and reverse DNS — and it is configured with a one-host DNS zone entry.   The next step toward establishing a DNS server is to add the target zone configuration, and then delete the installation-default zone entry from the configuration.

     

    2a) I'm not certain where you're headed here, and will repeat some advice: do not use your external domain name and your external host name on your internal network.  Use a subdomain of that domain, or use a different domain.   Do not have the same domain name configured in your internal network, and in your external DNS services.  Do not refer to the dynamic DNS provider here.

     

    Your host will have your internal domain name, with your internal host, with your internal DNS, from your internal server.  Preferably in your own registered domain.  Again, a "registered" domain name is not what you get from a dynamic DNS provider.  You "only" get permission to use a subdomain within a domain that the provider has registered.

     

    To create an externally-accessible WWW host, create a CNAME (alias) entry in the public DNS, and create a WWW alias entry in the local web server.

     

    Unless you want the local host to be named WWW, you're not creating a DNS entry for your host using WWW.

     

    Web services use a different mechanism for accessing the host — they use the specified name and the DNS server associated with the web browser, and then pass the text name of the web server in the HTTP or HTTPS traffic.  This means that the web server gets the name of the host the client asked for, and can then present that host.  This host name does not need to be known in local DNS services, it only needs to be configured as a "virtual host" — what Apple tends to call a "site" — to be available to requesting browsers.

     

    2a) the "search domain" is not necessary.  It's a convenience that's the local default domain that gets tried when some client asked for "stephan" as the host name, and did not specify the fully-qualified "stephan.example.com." host name or the not-fully-qualified "stephan.example.com" host name.  This is unrelated to that WWW host, nor with the DNS resolution, nor with the web server virtual host configuration.

     

    2b) Are you going to be doing eCommerce or such, or sensitive content?  If so, you're going to have a whole project for security and data integrity here such as the incorporation of a DMZ and a proper firewall, probably also a move off of a dynamic DNS provider, and — in aggregate — that's rather more of a discussion than I'm prepared to add to this thread.  If not, don't bother serving HTTPS port 443 here, which means you don't need a certificate, which means you also don't need to know about multi-domain certificates (also known as unified communications certificates) or other details of certificate-based security.  I would not want to be doing this stuff from a dynamic IP address.

     

    2c) that's the multi-domain or UCC cert mentioned in 2b.

     

    The example.net domain is one of the three domain names that are reserved for use in discussions and code examples.  These three domains — example.net, example.org and example.com — do not actually exist, should not be configured in your local DNS, and should never be seen in real networks.

     

    There are probably several thousand new top-level domains coming online, so picking a short domain name is getting easier, but picking your own bogus domain name is getting harder.  (Years ago, Microsoft had encouraged some of their users to set up domains in the then-unregistered .local top-level domain, and that later became a real and registered top-level domain.  Hence... problems with Bonjour and its use of .local top-level domain.  But I digress.)

     

    My use of example.net for an internal network and example.com hosts for the external network is to avoid having to deal with two pools of DNS servers both authoritative for the same domain name, and also to avoid having to enter a usually much longer subdomain name as often as arises when that approach is used; a domain registration, versus having to type a longer name all the time.   (In your case here, also so that you have ownership over the domain within your network, and cannot end up colliding with some real domain.)   The different domain name also means I can very easily then tell if the service is externally accessible — www.example.com would be, in the example configuration — and www.example.net — or whatever you've chosen as example.net, your internal domain name — would not be.  Hosts configured with the example.com domain would have public static IP addresses, and hosts using example.net would have internal (usually static) IP addresses from the private (NAT'd) address space.  A subdomain of a real and registered domain does also work here, it's just that it appears you do not yet have a registered domain if you're using a subdomain of your dynamic DNS provider.

     


     

    In general... This assumes your firewall is not an incompetent device, and that your firewall can correctly "reflect" the traffic sent to your public IP address back into your network.   Mid-grade and higher-end firewalls can do this, but some of the cheap gear cannot.

     


     

    In general...  If you're going to be serving data publicly, you'll really want to look at a firewall with DMZ capabilities, as a breach to your web server can allow the attackers to access everything, and delete everything.  If you have internal data on the same server that's offering public web sites and particularly via some content management system, all of that data is potentially (or actually) at risk in a server breach.

     


     

    In general... I'd encourage getting some more formal help here, as I'm inferring — no offense is intended — that you're really not yet comfortable with DNS and web services and certificates and security and the rest.   Mistakes here can unfortunately take a while to clean up, too.   The web servers I deal with get probed nearly continuously, and they each get scanned for more than a few known-vulnerabilities multiple times a day.  Any internet-connected server will suffer equivalent activities.  This goes well beyond DNS, of course.   This also means keeping backups, and preferably backups that cannot be accessed by the server by default, so that — if there is a successful attack — the attacker cannot access and delete the backups.

     

    There are also various different ways to configure DNS, and the "best" approach depends on local requirements and local expectations and — where there are options — local choices.

     

    There are a number of these sorts of "details" on the path to running your own server, too.  DNS is just the tip of what will be a big — and quite possibly fun — learning experience.  (There are, however, good reasons why folks host their web servers and mail servers.)

  • by essandess,

    essandess essandess Apr 22, 2015 12:49 AM in response to MrHoffman
    Level 1 (28 points)
    Applications
    Apr 22, 2015 12:49 AM in response to MrHoffman

    I'm going to disagree with MrHoffman's good DNS advice. Assuming that you don't really, really need to isolate your public facing services in a DMZ (I expect most OS X Servers simply reside behind a router firewall), it often makes sense to use the same domain name on the LAN as on the Internet. First, Server.app services are secured with a certificate tied to ONE domain name. You'll want to authenticate to those services whether on the LAN or the Internet, and setting internal DNS to point your domain to a LAN address does this. Second, it's a lot simpler to configure and use clients for a single domain, and let DNS determine whether the packets stay on the LAN, rather than one configuration for LAN and a separate configuration for the Internet.

     

    Also, variable IP addresses can work fine with ddclient, available through Macports or brew. In practice many ISP's variable IP's are don't change for years, and it's easy to configure ddclient to test your IP every few minutes and automatically update your DNS records if your IP changes.

     

    Finally, whether you site your server in a DMZ or on the LAN behind a router firewall, TB hard drives are cheap, so there's no excuse not to keep multiple, independent, offline backups.

  • by MrHoffman,

    MrHoffman MrHoffman Apr 22, 2015 10:01 AM in response to essandess
    Level 6 (15,627 points)
    Mac OS X
    Apr 22, 2015 10:01 AM in response to essandess

    Using the same domain name inside and outside does mean you have to track any external DNS changes on your internal servers, such as when a hosted service such as mail or web changes, your local DNS has to be updated to reflect that.

     

    For this specific case and particularly given the external DNS here is a dynamic provider, I would not use that DNS subdomain internally.  You may or will change those providers, or that provider can reconfigure or be bought out or reorganized or bankrupt or changes their business names.  That then means you get to change all your internal DNS, as well as everything that references that domain externally.  Hence my suggestion to get a real and registered domain.

     

    The presence of a DMZ is for security — having the same domain name across the internal network and the DMZ does work correctly.  If you're inclined, you can set up the server in the DMZ as a DNS replica, if you're willing to poke a hole through to your primary internal DNS server.  Or just run it as a subset DNS server, since all it has to know about is itself.

     

    Rather than ddclient — which is certainly an option — a mid-grade firewall can also deal with dynamic DNS on your behalf, and automatically update the public-facing dynamic DNS server when the ISP address changes.

     

    FWIW, one variety I've had reasonable success with is the ZyXEL ZYWALL USG series.  Those USG devices are not going to teach you the basics of IP and DNS and do expect you're familiar with the basics, but the menus are reasonably clear and consistent and complete, and the L2TP VPN can be gotten to work with the OS X clients, and most or all of that series do support DMZ configurations.   The mid-grade USG versions support multiple network uplinks for redundancy, and that works.  (Other than having purchased various ZyXEL gear, I have no connections with that company.)

Previous Page 2