Backup and Restore Lion Wiki

Posted: November 7th, 2011 | Author: | Filed under: Blog, Collaboration, Mac OS X Server, Migrate | Tags: | No Comments »

Backup the Collaboration Database

on the server running the wiki open a terminal and paste the following into the file










BACKUPFILE=`date +%Y%m%d`-wikibackup.tar.gz
/usr/bin/pg_dump -U $PGUSER collab -c -f /Library/Server/PostgreSQL/Backup/collab.sql
tar -cvzf /Users/admin/Backups/$BACKUPFILE /Library/Server

Save and exit the file, then do the following

chmod +x
sudo ./

This will create the file wiki-backup.tar.gz in the /Users/admin/Backups folder

Prep the migration file

Copy this file to the new server, untar it.

Then follow this procedure.

1. Open and turn on wiki
2. Open terminal and find pgsql process (ps aux | grep pgsql) , copy it to clipboard
3. Stop wiki server
4. open terminal and enter  psql -U _postgres -d collab -f /Library/Server/PostgreSQL/Backup/collab.sql

5. a bunch of shit will fly by, forget about it.

6. copy the Wiki folder from our backup into /Library/Server

7. Repair permissions
8. Turn on wiki, pray

Resolving HomeSync Errors on SMB

Posted: October 27th, 2010 | Author: | Filed under: Active Directory, Collaboration, Mac OS X Server, Snow Leopard | Tags: , , , , , , , | No Comments »

This is a follow up post in regards to my previous update:

A client of mine is being plagued with HomeSync errors on a Windows backed file server. One user in particular had over 2,000 file sync conflict issues, two others had around 70. After investigating the logs I believe I have an explanation as to why HomeSync is failing. To understand my theory I’m going to explain a bit about permissions on the Mac side.

When any Mac users logs into the desktop their home is mounted from the server into a “magic” folder. I say “magic” because technically it’s not a folder, it’s a program. The directory “/Network/Servers” is an auto mount program, if you enter this directory on the command line or in the GUI and specify a sub directory, such as “/Network/Servers/” the computer will try to contact over AFP, NFS, and SMB, to get a share listing and then display that listing as subfolder to the FQDN. For our example we would receive the following folder listing as user1: user1$ ls -al /Network/Servers/
total 36
drwx—— 1 user1 wheel 16384 26 Oct 15:17 Homes user1$

We see here that there is only one entry “Homes” but notice the owner and group. The owner seems fine, user1, however the group is “wheel” Wheel is a local group on every Macintosh that is more or less a system group. The share is mounted as group wheel because the mounting program runs as “wheel” Thus all the directories inside of user1’s home folder also have the group “wheel”

Let’s compare group owner to what is assigned when we mount the share manually:

vaW80401YGAGZ:Volumes user1$ ls -al /Volumes
total 72
drwxrwxrwt@ 9 root admin 306 26 Oct 22:11 .
drwxrwxr-t 30 root admin 1088 26 Oct 13:14 ..
drwx—— 191 user1 DOMAIN\domain users 6450 21 Oct 11:05 CurrentProjects
drwx—— 1 user1 DOMAIN\domain users 16384 26 Oct 15:17 Homes
drwx—— 1 user1 DOMAIN\domain users 16384 26 Oct 15:36 Production
drwx—— 31 user1 DOMAIN\domain users 1010 15 Oct 14:11 Promo
drwx—— 41 user1 DOMAIN\domain users 1350 26 Oct 20:53 SCANS
lrwxr-xr-x 1 root admin 1 26 Oct 13:13 Workstation -> /
drwx—— 23 user1 DOMAIN\domain users 738 26 Oct 15:26 joost

See that? The group is different! The mac mounts the directory as the proper default group “DOMAIN/domain users” for the user user1. I know this is the default group for user1 by asking the AD server details about the user1 user:

vaW80401YGAGZ:Volumes user1$ id user1
uid=421864987(user1) gid=1278872894(DOMAIN\domain users) etc……

Now that we understand a little about permission sets in the Mac world I’ll explain my theory.

When I a HomeSync user authenticates for the first time the Mac must mount their home directory in /Network/Servers and thus the group owner is set to “wheel.” The contents of the users home directory is then copied to “/Users/” for our continued example it would be /Users/user1. Here’s the kicker: when the Mac wants to do any HomeSync after the initial is complete, it does not mount the user’s home directory to /Network/Servers. Instead the Mac mounts the home directory to /Volumes like a standard manual mount. Therefore the group ownership in the user’s local home folder DOES NOT match the group ownership of the user’s server side home folder. Thus, HomeSync tries to update the server side’s group ownership to the group “wheel.” This is usually when all the errors start spewing out of HomeSync because the Windows server has no record in Active Directory of the group “wheel”

I then went on to test my theory. I changed the group ownership for three separate user’s LOCAL home folders from “wheel” to “DOMAIN/domain users” For one user this resolved 68 of 70 HomeSync errors. For two others it resolved all of them.

There are other problems regarding HomeSync that are not included in this above mentioned theory such as illegal characters. For one example, Parallels is installing files into ~/Applications that have the { } characters in them. This is causing more problems to the HomeSync users. I have excluded this directory from synchronizing, however there are more HomeSync issues because of these illegal characters.

Zimbra and Open Directory with SSL

Posted: October 17th, 2009 | Author: | Filed under: Collaboration, Zimbra | No Comments »

I have Zimbra Collaboration Suite installed for my personal network at home and wanted to integrate it to Open Directory for authentication purposes. The problem is though that Zimbra does not make this easy, especially when dealing with SSL certificates. Here’s what I did step by step (oooh baby)

Install Zimbra

1. Download and install the Zimbra package,

1.1 Next, verify your DNS is setup correctly. The server you’re installing Zimbra onto must have a DNS record, this record must be the server’s hostname as well as the domain’s MX.

1.2 the via SSH run
/opt/zimbra/libexec/ as ROOT

1.3 Zimbra will assume that the machine’s hostname is also its TLD. Which 99% of the time is not the case. You can enter your TLD when it asks.

2. Enter admin password (3, 4) Enter License (19) Return (r)
If your Zimbra server is installed onto the Open Directory Master or Replica, change the LDAP port to be 390 (1,3)
Apply Changes (a)

3. Import the Open Directory’s LDAP SSL certificate into Zimbra as a trusted certificate.

  • Copy the appropriate OD’s ssl cert into the /tmp folder on the Zimbra Server. The default cert is located at /etc/certificates/Default.crt
  • if using self-signed cert X.509 these files would be /etc/certs/ca.crt
  • once copied run this command:
  • sudo keytool -import -keystore /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/lib/security/cacerts -storepass changeit -alias LDAPAUTH -file /tmp/Default.crt

  • erase the cert in /tmp
  • restart zimbra sudo -u zimbra /opt/zimbra/bin/zmcontrol stop and then start

    4. Navigate to https://servername:7071 in your web browser to enter the admin console of Zimbra

    5. Configure Zimbra to use the external LDAP as its domain authentication method

  • Expand domains arrow
  • Select your domain and click configure authentication
  • Select External LDAP
  • Enter IP and select SSL
  • for filter enter (&(objectClass=inetOrgPerson)(objectClass=posixAccount)(uid=%u))
  • enter the LDAP base
  • we are not using DN/Password, skip this step
  • test the configuration by using testuser/password credentials
  • 6. Configure Zimbra to use the external LDAP GAL

  • Select configure GAL
  • Select External
  • ServerType – LDAP, enter your Open Directory Master IP, select SSL
  • for filter enter (&(|(cn=*%s*)(sn=*%s*)))
  • for autocomplete enter (|(uid=%s*)(givenname=%s*)(mail=%s*))
  • enter the LDAP base – note the auto populated entry will be for the local ldap
  • we are not using DN/Password, skip this step
  • use GAL sync settings at default (click next)
  • test the configuration by searching for a partial match on the user name – ie: if the username is “testuser”, search for “test” or first or last name of the test user, this data was entered into the info box in workgroup manager
  • if test results are successful, click “Finish”
  • Provisioning Users

    For manual batch user provisioning of Open Directory users to Zimbra:

  • Enter all the accounts into a text file called userlist.txt with the following structure. Make sure you use the user’s shortname for the prefix in their email address
      ca user1@host.tld “”
      ca user2@host.tld “”
      ca user3@host.tld “”
  • Then dump that text file into the zmprov command as follows
    • sudo /opt/zimbra/zmprov < userlist.txt

    For manually provisioning Open Directory users to Zimbra:

  • SSH into Zimbra server
    • sudo /opt/zimbra/bin/zmprov ca user@domain.tld ""