-
All replies
-
Helpful answers
-
Jul 24, 2011 9:08 PM in response to krisvhby sjnorcross,I have the same question. If anyone has successfully migrated iCal, please post directions.
Thanks.
-
Jul 25, 2011 12:32 AM in response to krisvhby dreness,Hello,
If you do an in-place upgrade from Snow Leopard Server to Lion Server, you can see how the calendar data upgrade happens by watching /var/log/caldavd/error.log (which contains log messages other than errors, depending on the log level). Lion Server's iCal Server sees the old calendar data in its DocumentRoot when it starts up and then imports it into postgres. You can do the same thing to manually upgrade the data; just copy the contents of your old calendar server DocumentRoot to "/Library/Server/Calendar and Contacts/Documents" (i.e. the 'calendars' directory). Keep in mind that calendar data is strongly associated with the GUIDs of your various user / group / location / resource receords, so be sure to restore or migrate Open Directory data if you have not already. Once calendar data has been imported, it will be moved from the 'calendars' directory to 'calendars-migrated'; this data is no longer needed by the service, it's just there to make you feel warm and fuzzy.
Note that you cannot import data in this way for any users who have already logged into your Lion calendar server; this is because the data import / upgrade is a one-way, one-time process that is not able to merge the incomming data with any data that may have already been created for that user in postgres. To see a list of GUIDs that have logged into your calendar server:
sudo psql -U _postgres caldav -c "select * from calendar_home"
This returns a list like:
resource_id | owner_uid
-------------+--------------------------------------
1 | E989942B-AD6C-4C75-9845-49B72E800389
(1 row)
You can then look up these GUIDs to find the username:
woot:~ admin$ dscl /Search search /Users GeneratedUID E989942B-AD6C-4C75-9845-49B72E800389
admin GeneratedUID = (
"E989942B-AD6C-4C75-9845-49B72E800389"
)
It's also possible to nuke and pave the calendar server database by running the following commands. This might be useful if you've got old data to import or migrate, and you've already logged in with users who have data to import. NOTE: this will DELETE ALL YOUR CALENDAR DATA FROM POSTGRES. Don't do this unless you really mean it. (of course it's possible to delete a given user's calendar home without nuking all other data, I just haven't spent time to figure that out yet - you can't simply delete rows from calendar_home due to forgeign key constraints)
sudo serveradmin stop calendar
sudo dropdb -U _postgres caldav
sudo calendarserver_bootstrap_database
sudo serveradmin start calendar
Running calendarserver_bootstrap_database should log stuff like:
Database User 'caldav' exists
Database 'caldav' created
Successfully installed schema version 3
Now that we have a fresh calendar server db, we can prove that it's a blank slate:
bash-3.2# psql -U _postgres caldav -c "select * from calendar_home"
resource_id | owner_uid
-------------+-----------
(0 rows)
HTH,
-dre
Message was edited by: dreness - be sure to stop calendar service before blowing away the caldav db
Message was edited by: dreness, a bit more explanation around why you'd want to use the nuke / pave procedure.
-
Aug 12, 2012 8:48 AM in response to krisvhby jmca,I'm having some trouble with these commands. If I stop the calendar server and run dropdb I get an error asking if the server is running. If I start the calendar server and run dropdb I get an error that there is one other user accessing the database..
host:~ ladmin$ sudo dropdb -U _postgres caldav
dropdb: could not connect to database postgres: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?
I'm running Lion Server 10.7.4. Has something changed?
Thanks,
-- jmca
-
Aug 21, 2012 12:35 AM in response to drenessby Philip Woods,I'm getting the same error as jmca. Lots of stuff online about how to fix if you're using homebrew postgres, but I'm not. Using standard 10.7.4 installation.
-
Mar 26, 2015 12:11 AM in response to jmcaby BDEFX,I think I've finally figured this out. I've added 2 commands to dreness procedure to NUKE and PAVE the caldav database with postgres. Apparently addressbook and calendar use the same database so they both have to be stopped before you can use dropdb. But, if you stop all of the postgres services via serveradmin, you will also end up stopping postgres itself. This is why some of us have gotten the "could not connect to database" error. So manually starting postgres ensures that dropdb will have something to talk to . . .
sudo serveradmin stop calendar
sudo serveradmin stop addressbook
sudo serveradmin start postgres
sudo dropdb -U _postgres caldav
sudo calendarserver_bootstrap_database
sudo serveradmin start calendar
sudo serveradmin start addressbook
The above commands are what worked for me after many hours of trial and error, and lots of Googling. I was able to get my data migrated from Snow Leopard ical to Lion ical, but I was never able to get my users in open directory to access the migrated data. I migrated the GUIDs but could not make it work. After about a week of trying on and off, I gave up and reinstalled Snow Leopard server. I wish I understood this process better. The Apple docs say you can migrate with little or no command line effort but that is clearly not the case for many of us. Now I know why I put off this upgrade for so long.
Thanks to all who have shared their knowledge and experience.