OS X Server Continuous Integration ipa distribution

后端 未结 3 2200
悲哀的现实
悲哀的现实 2021-02-14 17:50

We have a osx server configured with SSL cert and enabled Xcode. Everything worked fine before updating OSX Server to 3.2.1 and Xcode 6.0.1.

The problem we have is that

3条回答
  •  野性不改
    2021-02-14 18:27

    Same issue here.

    Initially the out-of-the-box Xcode Server solution worked and any device could install .ipa generated by the Xcode bot. After one or two days it suddenly got broken and none of the devices could download anymore, just displaying:

    Cannot connect to www.example.com

    Tracing log on my iPhone I could also see the device trying to connect to https://www.example.com:20343/api/integrations. This Xcode webservice is apparently using a self-signed Xcode Server Root Authority certificate (instead of the certificate selected in the OS X Server management application) and since any client need to access this webservice requests are incorrectly signed.

    A post on the Apple Developer Forums guided me to the Xcode Server Apache configuration located here (thank you Paul Verity):

    /Library/Developer/XcodeServer/CurrentXcodeSymlink/Contents/Developer/usr/share/httpd_xcs.conf

    or in OS X Server 4.1.5:

    /Library/Developer/XcodeServer/CurrentXcodeSymlink/Contents/Developer/usr/share/xcs/httpd_xcs.conf

    Containing a section that exposes the webservice through the regular Xcode Server website:

    
        ProxyPass /xcode/api https://127.0.0.1:20343/api retry=0 timeout=30
        ProxyPassReverse /xcode/api https://127.0.0.1:20343/api
        ProxyPass /xcode/socketio http://127.0.0.1:20300 retry=0 timeout=30
        ProxyPassReverse /xcode/socketio http://127.0.0.1:20300
    
    

    Interestingly /xcode/api/ requests are signed using the correct certificate and thus are accepted by any client. (You can test it by accessing your Xcode server by adding /xcode/api/integrations after your server's URL. This is just a JSON webservice. If your server's certificate is signed by a valid authority it will be accepted without any problems.)

    This leads to my two step solution (Assuming your server is behind a router/firewall):

    1. Redirect Public TCP ports 20300, 20343 to private TCP port 443 in your firewall/router This way, the webservice requests are forwarded to the Xcode Server that is using the correct certificate that is automatically accepted by the device. Xcode also uses ports 20344 & 20345, but leave those for other connections. Note: these changes can be overwritten if you have OS X server managing an Apple Router and re-toggle XCode under "Public Services".

    2. Proxy /api and /socketio request to the local webservice The server does not known /api so add the following lines to the mod_proxy.c section in your httpd_xcs.conf:

    ProxyPass /api https://127.0.0.1:20343/api retry=0 timeout=30
    ProxyPassReverse /api https://127.0.0.1:20343/api
    ProxyPass /socketio http://127.0.0.1:20300 retry=0 timeout=30
    ProxyPassReverse /socketio http://127.0.0.1:20300
    

    Final thoughts/notes:

    I'm not sure if we should consider the webservice is using a self-signed certificate a bug. It might as well be an issue that Apple is providing an incorrect configuration file. Maybe stripping off the /xcode part at the ProxyPass lines instead of adding them would be sufficient.

提交回复
热议问题