Mac OS Server 3.1 upgrade causes Profile Manager not to start

Last modified: Mar 22, 2014 @ 14:12

We’re running a Mac OS X 10.9.2 server with Mac OS X Server 3.0.3. We only run Open Directory and Profile Manager on this server.

Today I upgraded our server to Mac OS X Server 3.1 and rebooted. After the reboot Open Directory came up but Profile Manager would not load. When I launched the Server Manager and went to Profile Manager I either got “Error -1″ or an error about the configuration not being readable.

After a bit of research I came across a post by andydvsn1824 on the Mac OS Server Forums with the solution that worked for me. He had an extra step in his solution that I didn’t need to perform and I’d wanted to repost the solution here in case something happens to the original post and so it’s in a nice step-by-step layout.

  1. Launch the Server Manager App
  2. Turn off any running services. In my case I shutdown Open Directory
  3. Close the Server Manager App
  4. Open Terminal and perform the following to backup and remove your current Profile Manager settings:
  5. Minimize Terminal
  6. Open up the Finder and go to ‘Applications’ and delete ‘Server’
    Note: Don’t worry your settings will be preserved. In fact you should get a message telling you so
  7. Close Finder and empty the trash
  8. Re-open Terminal and extract the backup we made of the Profile Manager files
  9. Launch the App Store
  10. Click ‘Purchases’
  11. Click ‘Install’ next to OS X Server
  12. Once the installation is complete close the App Store
  13. Launch the Server Manager App
  14. You should see Server Manager launch, request you accept the EULA and then run through a progress bar. Once this is complete I then started Open Directory and once that had started I started Profile Manager which started properly, was upgraded and retained all of my existing profiles and devices.

In retrospect you probably don’t need to delete the ‘ProfileManager’ directory and then restore it but definitely take a backup.

There also appears to be an issue with newly enrolled devices filling log files on your server. The recommended solution, which only works for 1 month, is to run the following command:

 

Apple is supposedly working on a patch (3.1.1?) for the logging issue and I assume the upgrade failure.

 

Sources

How to upgrade Gitlab 5.4 to 6.0 on CentOS 6 or RHEL6

Last modified: Aug 22, 2013 @ 10:19

The upgrade instructions found on Gitlab’s official website are what I followed to upgrade my installation of Gitlab.

The only alterations I’ve made are to match my unique configuration from earlier articles on this website.

If you haven’t already upgrade your Gitlab to 5.4 before proceeding with these instructions. I never wrote a 5.2 -> 5.3 or a 5.3 -> 5.4 upgrade guide. The procedure was fairly straight forward and I just followed the official documents offered by Gitlab and referred to my earlier upgrade posts for 5.0 -> 5.1 and 5.1 -> 5.2.

1. Backup all of your Gitlab Data first. I ran these commands but ended up with an error. I run other separate backups so I wasn’t concerned. You may have better luck.

 

2. Switch back to root and install a missing dependency and shutdown Gitlab and then switch back to sa_gitlab

 

3. Download the latest code

 

4. Update Gitlab Shell

 

5. Update Gitlab

 

6. Backup your old configuration files

 

7. Create new configuration files

 

8. Update the init script

 

9. Start-up Gitlab 6!

 

That’s it!

Proxy Settings pushed by GPO not applying to Windows 7 and Internet Explorer 9

I support a Windows 2003 Active Directory Domain, until today only Windows XP clients and Internet Explorer 8.

We use a proxy server to filter and monitor the internet and we push the configuration for that proxy server via Group Policy. Our current GPO works perfectly with Windows XP and Internet Explorer 8.

Today we got our first Windows 7 client and I noticed the proxy settings from our Windows 2003 Active Directory Domain were not applying top the Windows 7 machine running Internet Explorer 9.

It turned out there were two reasons the settings were not applying. The first is a no brainer. I hadn’t updated my Internet Explorer Group Policy Administrative Template to support Internet Explorer 9. That was easy enough to fix by going here and updating my Administrative Template.

After updating the Administrative Template I figured I’d be done. Turns out I was wrong. I ran ‘rsop.msc’ and ‘gpresult /r’ and both showed the proxy settings were being applied but Internet Explorer wasn’t using our proxy server.

Turns out there was a second problem and it was FAR more difficult to figure out. I did some research and found others complaining about this problem. Removing proxy settings for ‘GOPHER’ from their Internet Explorer GPO resolved the problem for the majority of these users. To remove GOPHER settings open up your group policy and make the following tweak:

This didn’t solve the problem for me but it may have had a hand in it.

The second thing I had to do in my case was to disable caching of auto-proxy scripts and disable changing automatic configuration settings. My understanding from the post I read was that the cache can become corrupt and cause a bunch of problems. To make this change open up your Internet Explorer GPO again and make the following changes:

Once I’d made both of those tweaks I ran a quick ‘gpupdate /force’ and that was it! Things started working properly.

There seems to be a bug in Internet Explorer 9, or at least the version I’m running, where if you go into the proxy settings under ‘Internet Options’ you won’t actually see your proxy servers name in the ‘Address:’ box. I’ll see if that clears up once I get Windows Updates working on these Windows 7 machines or when we get to Internet Explorer 10.

References

How to upgrade Gitlab 5.1 to 5.2 on CentOS 6 or RHEL6

Last modified: May 22, 2013 @ 14:52

This document assumes you’ve followed my previous post for deploying Gitlab on CentOS 6/RHEL6 and have already upgraded that deployment from 5.0 to 5.1.

If you haven’t already switched from the default version (1.7.1) of git that comes with CentOS 6 / RHEL6 to git 1.8.2.3 please follow this post first before continuing with these instructions. Even if you don’t care about that error message follow the instructions so you’re using git 1.8.2.3 instead of 1.7.1.

Now then. Lets get to it.

1. Stop gitlab and switch to sa_gitlab

 

2. Get the latest code for Gitlab and Gitlab-shell

 

3. Install libs, migrations, etc? (I stole this from the Gitlab guys)

 

4. Switch back to root and update the init script

 

5. Start up Gitlab

 

You should be good to go at this point. The first load took a while for me after the update.

 

References

Commit comments not appearing in Gitlab on CentOS

Last modified: May 23, 2013 @ 09:45

If you followed my earlier documentation, or simply installed Gitlab yourself on CentOS 6 you might run into this problem:

When you go to the ‘Files’ view of one of your repositories it won’t load any of the commit comments. It just appears to perpetually load.

If you look in your ‘production.log’ you’ll see an error like this:

It looks like this is a bug with git itself and not Gitlab.

There is a patch you can manually apply to your Gitlab deployment OR you could just upgrade git to the latest and greatest version. I chose to upgrade git. The below guide assumes you followed my original “How to install Gitlab 5.0 on CentOS 6 or RHEL6” guide. I’ve updated that guide to reflect these new steps.

1. Get logged in to your server and become ‘sa_gitlab’

 

2. Create a temp directory if you don’t have one and move into it

 

3. Download the latest source for git from https://code.google.com/p/git-core/downloads/list. As of this writing 1.8.2.3 is the latest version

 

4. Configure, compile and install git 1.8.2.3

 

5. Configure your environment so the new version of git overrides the default CentOS version

 

6. Re-export your path and verify which git is being used and it’s version

 

7. Update your gitlab.yml configuration file

 

8. Restart Gitlab

 

That’s it!

Update May 22nd, 2013 - Added step 7. Didn’t realise you had to edit the gitlab.yml file to point to the new git binary location. I assumed Gitlab used the git binary it found via PATH.