OS X Server Intégration continue ipa dissortingbution

Même problème ici.

Initialement, la solution Xcode Server prête à l'emploi fonctionnait et n'importe quel appareil pouvait installer .ipa généré par le bot Xcode. Après un ou deux jours, il s'est brisé soudainement et aucun des appareils ne pouvait plus download, affichant simplement:

Impossible de se connecter à http://www.example.com

Tracing log sur mon iPhone, je pourrais également voir l'appareil essayant de se connecter à https://www.example.com:20343/api/integrations . Ce service Web Xcode utilise apparemment un certificate d' autorité racine Xcode Server auto-signé (au lieu du certificate sélectionné dans l'application de gestion OS X Server) et tout client ayant besoin d'accéder à ces requêtes de service Web est mal signé.

Un message sur les Forums des développeurs Apple m'a guidé à la configuration de Xcode Server Apache situé ici (merci Paul Verity ):

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

ou dans OS X Server 4.1.5:

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

Contenant une section qui expose le service Web via le site Web habituel de Xcode Server:

 <IfModule mod_proxy.c> 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 </IfModule> 

Intéressant / xcode / API / requests sont signés en utilisant le bon certificate et sont donc acceptés par tout client. (Vous pouvez le tester en accédant à votre server Xcode en ajoutant / xcode / api / intégrations après l'URL de votre server.C'est juste un service Web JSON.Si le certificate de votre server est signé par une autorité valide, il sera accepté sans aucun problème.)

Cela conduit à ma solution en deux étapes (en supposant que votre server est derrière un routeur / pare-feu):

1. Rediriger les ports TCP publics 20300, 20343 vers le port TCP privé 443 dans votre pare-feu / routeur De cette façon, les requests de service Web sont transmises au server Xcode qui utilise le certificate correct qui est automatiquement accepté par le périphérique. Xcode utilise également les ports 20344 et 20345, mais laisse ceux pour d'autres connections. Remarque: ces modifications peuvent être remplacées si le server OS X gère un routeur Apple et que vous réactivez XCode sous "Services publics".

2. Demande de proxy / api et / socketio au service web local Le server ne connaît pas / api alors ajoutez les lignes suivantes à la section mod_proxy.c dans votre file 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 

Pensées finales / notes:

Je ne suis pas sûr si nous devrions considérer le webservice utilise un certificate auto-signé un bogue. Il se pourrait aussi que Apple fournisse un file de configuration incorrect. Peut-être que dépouiller la partie / xcode sur les lignes ProxyPass au lieu de les append serait suffisant.

Si le certificate SSL avait été installé sur OS X Server, vous avez rencontré ce problème après avoir mis à jour OS X. Vous l'avez corrigé en ajoutant à nouveau le certificate p12 dans l'application Serveur -> Certificats, puis redémarrez. Le certificate peut être importé à partir de l'application Keychain.

J'ai eu le même problème sur deux installations différentes de Xcode Server.

Lors de la première installation, le server Xcode était derrière un pare-feu / proxy. Donc, le port 20343 n'a tout simplement pas pu être atteint. J'ai corrigé cela en envoyant un https://externalname.com:20343 par https://internal.ip.address.here:20343

C'est la configuration de nginx que j'ai utilisée pour cela:

 server { listn 20343; server_name xcode.foo.com; access_log /var/log/nginx/xcode.access.log; error_log /var/log/nginx/xcode.error.log; ssl on; ssl_certificatee /root/foo_com/foo_com.crt; ssl_certificatee_key /root/foo_com/foo_com.key; ssl_session_timeout 5m; ssl_protocols SSLv3 TLSv1 TLSv1.1 TlSv1.2; ssl_ciphers ALL:!ADH:!aNULL:!PSK:!MD5:!AES:!EXPORT:+HIGH:!MEDIUM:!LOW:!SSLv2; ssl_prefer_server_ciphers on; ssl_session_cache shared:syncserver:4m; location / { proxy_set_header Host $http_host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_redirect off; proxy_read_timeout 120; proxy_connect_timeout 10; proxy_pass https://192.168.0.8:20343; } } 

Lors d'une seconde installation, où mon server Xcode était sur une IP entièrement publique, le problème était différent: pour une raison quelconque, mon terminal n'acceptait pas correctement le certificate racine que Xcode Server utilise pour le server Node.js qui s'exécute sur le port 20343.

Vous pouvez find ma solution pour ce cas ici: Xcode bot install link requête time out