• Mar 25, 2014

    Another Stab at using OS X Server

    I've had a few run-ins (as I like to call them) with OS X Server in the course of my career. I've been very comfortable with UNIX/Linux machines for a long time (I compiled my own Linux kernels when I was right out of college) and found them to be quite reliable and highly configurable. The lack of a GUI didn't scare me and I thought it was a plus as there are tons of options for services like Apache and named (DNS) and a there was no way that a GUI could expose all of them.

    In one of my contract positions, we were using a Linux box until a new IT person came in and bought an Xserve with OS X Server thinking that since he was comfortable with OS X, the server was the next logical step. While OS X Server runs on UNIX, the friendly GUI hides lots of options, some of which are necessary to running a successful server and some of which are needed when the server does something stupid. So now you have the GUI modifying settings and devs modifying settings via the command line in order to work around deficiencies in the GUI. It was just a recipe for disaster. After awhile, we resigned the Xserve to specific tasks and put the more important services on a Linux box.

    My next run in with OS X Server came a few years later when the company I contracted for and then went to work for already had an investment in 4 or so Xserves. They were chosen because the lead IT guy was more comfortable with OS X than with UNIX/Linux (he was more of a desktop support guy and not a server guy). In this setup, we had to use Open Directory and I managed to unify the boxes and spread out the services. Open Directory was a nightmare because sometimes it just returned errors with no way to fix them. Again, the GUI hid things (including ways to fix problems) that would have been simple using a command line. We eventually put a few Linux boxes on the network and ran more core services on those; the Xserves still handled FileMaker Server (that's another nightmare for another day) and Open Directory. The only saving grace for Open Directory was the GUI for user management as sending LDAP commands to populate it was probably worse than dealing with OS X Server.

    I had completely put OS X Server behind me when Apple announced Xcode Server at the last WWDC. It intrigued me, but I ignored it until last week when I went ahead and created a Mavericks virtual machine and put Server on it. It was quite painless and actually looked like it had some useful features. Xcode Server, VPN, and Caching were the primary things that I couldn't do from OS X out of the box. (I already had FTP, for my scanner, and Apache going on my media center.) After I ran the VM for a day or so, I decided to take a leap of faith and install server right on my media center and not in a VM. I was reassured in this decision after seeing some articles on how to remove it. In the olden days, OS X Server was as a separate install and couldn't be removed. I've been running Mavericks Server for about a week now and it has been great, unlike my previous run-ins with the product. While it is still not perfect (Xcode Server needs some work), it is looking good. I had have to hack on a config file for the web server to do proxying as my security system runs a local service on port 8000 and in order to protect it with SSL, I had to setup SSL on the web server and proxy it, but that was just a matter of adding:

    
     ProxyPass / balancer://balancer-group/
     ProxyPassReverse / balancer://balancer-group
     
          BalancerMember http://localhost:8000

    to the config file for the site. The downside is that if I touch the site setup, my changes will get blown away.

    While playing around with the Profile Manager today, I think I discovered the biggest problem with OS X Server in the past...Open Directory. In order to do MDM (Mobile Device Management) in Profile Manager, you have to turn on Open Directory. I quickly cancelled out of that and ended that experiment. I mentioned Open Directory to a co-worker who also used to do IT and he had the exact same feeling about Open Directory that I do; I hate it. I know that's pretty strong, but that service has had many, many problems that I'm unwilling to risk my server to turn that on as I have no use for it. Maybe a company that has a dedicated IT guy has no problem with IT, but if you leave Open Directory out of OS X Server, I think Apple has a fine small business server product.

    For developers, OS X Server is now free and if you're like most geeks, you already have a machine running all the time, so might as well install OS X Server and take advantage of the caching and maybe play around with Xcode Server.

  • Mar 25, 2014

    Code Signing Woes on Xcode Server

    Following up on my post from yesterday, I've discovered that Xcode Server does something very strange in the build process. After the build, it creates a .ipa file that is suitable to install on an iOS device and a .xcarchive file that contains the .dSYM file as well as the .app file which is the .ipa file before it has been packaged up. The packaging process is basically putting the .app file in a Payload directory, zipping it up and changing the .zip extension to .ipa. Sounds simple enough and unzipping the .ipa should yield a file identical to the .app. Unfortunately this is not the case. If you run the following command:

    codesign --display --entitlements - AppName.app

    on the .app in the xcarchive and on the .app that is extracted from the .ipa file, you will get different results.

    From the .ipa, I get:

    


    application-identifier
    123324243AS.com.something.something
    keychain-access-groups
    
        123324243AS.com.something.something

    from the .app, I get:

    ??qq?



    application-identifier
    123324243AS.com.something.something
    aps-environment
    production
    get-task-allow
    
    keychain-access-groups
    
        123324243AS.com.something.something

    It appears that the code signing entitlement, aps-environment is missing from the .ipa Xcode Server built. I can't figure out why this is the case, but it does show that I'm not crazy and my setup works. The .ipa I create myself and upload to TestFlight works because my simple packaging script doesn't re-codesign the .app.

    So I have 2 choices when uploading to the app store:
    1. Do what I described yesterday and that is resign the app on my desktop machine

    1. Take the .app file out of the xcarchive, zip it up and upload that.

    Xcode Server does mangle the product and I'm not sure that is intentional. I should file a bug with Apple to see if they can fix it in the future.

    I'd love to be proven wrong on this whole setup. If you have more information, please let me know.

  • Mar 24, 2014

    Using Xcode Server for Builds

    At last year's WWDC, Apple introduced Xcode Server for doing continuous integration. Lots of people have tried to use it with mixed results. Recently after dealing with our build server for work (we use Jenkins), I decided to give Xcode server a try for one of my projects.

    I was hesitant at first to use OS X Server (which includes Xcode Server) as I've had poor results with it in the past. It intrigued me often that I decided to install server and see where it went. OS X server install was a breeze and so was setting up Xcode Server.

    I created a "Bot" from Xcode on my development machine and saw that it failed when the server tried to build it. No problem, I searched the Internet and all the results said to add the repository from the server instead of when creating the bot. Perfect, I did that and then the build succeeded. Yeah! I also added my Team to Xcode server so it could pull down provisioning profiles and create a certificate to build.

    I checked the log and found 2 problems. First, I have a run script build phase that puts the version number in the Settings.bundle that failed and second, it was being signed using the wrong mobile provisioning profile.

    I decided to tackle the second problem first. Through my searches, I found that I needed to put the mobile provisioning profile (an AdHoc one) in /Library/Server/Xcode/Data/ProvisioningProfiles. No problem. Next I also found that I needed to put the certificate and private key for the profile in the System keychain as the Xcode Server runs under _teamserver which doesn't have its own keychain. I did that as well and found the problem didn't go away. I started thinking about it and found that sometimes Xcode ignores the Automatic Distribution Code Signing Setting. So, I removed my Team and deleted all the other mobile provisioning profiles. Bingo, now my app was building and being signed correctly.

    Next step was to figure out my build phase. After dumping the environment variables, I found that in order to put files in the .app after the build, I had to set my script phase to be:

    shortversionnumber=`/usr/libexec/PlistBuddy -c "print CFBundleShortVersionString" ${BUILT_PRODUCTS_DIR}/${INFOPLIST_PATH}`
bundleversionnumber=`/usr/libexec/PlistBuddy -c "print CFBundleVersion" ${BUILT_PRODUCTS_DIR}/${INFOPLIST_PATH}`
shortversionnumber=`echo $shortversionnumber '('$bundleversionnumber')'`
  • Mar 12, 2014

    The downside of parking meters

    San Diego is in the process of replacing regular parking meters with ones that are called multi-space meters. These are ones that give you a ticket that you place on your dash. I thought that these were neat as I could just pay with a credit card as I usually don't have change around. My wife, however, pointed out the problem with these is that the minimum is 1 hour on the meter which costs $1.25. I didn't think much of it until I had to pick something up today and found a meter with some time left on it; I dropped a quarter in it (I do have some quarters in my car) and got another 12 minutes which was plenty of time for my errand.

    It turns out that the pay and display meters do take change and apparently you can put less than $1.25 in them. So the lesson is that I still need to have quarters in my car for times that I think I'll be at a meter less than an hour; otherwise, paying by credit card is quite convenient. Now if the city could just get with the game and figure out some micropayment strategy with lower transaction fees, maybe they could reduce the minimum amount to go cashless.