Pourquoi macOS Sequoia utilise openrsync et l’impact sur la sync build distant
Apple a remplacé dans macOS Sequoia l’ancien rsync par openrsync ; les raisons tiennent surtout à la politique de licence GPLv3. Le rsync système 2.6.9 est ancien, et rsync 3.x est sous GPLv3 – Apple a adopté openrsync (BSD) pour éviter les contraintes de distribution. Pour les développeurs, openrsync est plus léger et plus performant, mais il se comporte différemment de rsync 3.x pour le mode daemon distant (rsync daemon), les ACL et une partie de la synchronisation des droits. Si votre pipeline en dépend, il faut trancher : continuer avec rsync 3.x via Homebrew, ou accepter les limites d’openrsync et adapter les scripts.
Pour la synchronisation build distant, l’impact porte surtout sur trois points : la compatibilité des vérifications incrémentales et du transfert delta, le degré de conservation des droits et timestamps en destination, et la compatibilité avec les commandes rsync existantes en CI (GitHub Actions, Jenkins, etc.). Pour un usage limité à « sync local → répertoire distant », openrsync suffit souvent ; dès qu’il s’agit de mode daemon, d’ACL complexes ou de sync multi-nœuds, il vaut mieux rester sur rsync complet.
Comparaison rsync vs openrsync : droits, ACL, daemon distant
Tableau des capacités utiles pour la sync build distant – openrsync système vs rsync 3.x Homebrew.
| Capacité | openrsync système (Sequoia) | rsync 3.x Homebrew | Impact sur la sync build |
|---|---|---|---|
| Incrément / delta | oui | oui | Les deux gèrent la sync incrémentale, peu de différence |
| Daemon distant | limité ou différent | complet | Si la CI récupère les artefacts via rsync:// : privilégier rsync Homebrew |
| ACL / attributs étendus | partiel | complet | Pour une conservation stricte des droits : rsync 3.x |
| --fake-super | prévu (roadmap openrsync) | oui | Utile si on veut garder les droits complets en non-root |
| Maintenance / mise à jour | avec l’OS | brew upgrade rsync | À long terme plus de souplesse avec Homebrew |
En résumé : si vous ne faites qu’un push incrémental « local/CI → répertoire Mac distant » sans daemon ni ACL complexes, vous pouvez essayer d’abord l’openrsync système. Sinon, installez brew install rsync de façon homogène sur les nœuds de build et utilisez explicitement /opt/homebrew/opt/rsync/bin/rsync ou un PATH qui le priorise, pour ne pas mélanger avec l’openrsync système.
Setups recommandés : rsync Homebrew / rsync Docker / SFTP
Trois approches courantes et leurs cas d’usage.
- rsync Homebrew : Sur le Mac distant,
brew install rsync, puis la CI ou la machine locale appelle ce rsync via SSH. Adapté si l’accès SSH est déjà standardisé et que vous voulez garder toute la puissance de rsync. Veillez à ce que le PATH privilégie la version Homebrew par rapport à l’openrsync système. - rsync Docker : Faire tourner rsync 3.x en conteneur sur le Mac distant pour figer version et comportement. Utile en environnement multi-nœuds / multi-OS, mais ajoute la gestion des images et du réseau.
- Passerelle SFTP + isolation de répertoires : Pas de daemon rsync ; upload/download des artefacts build via SFTP, avec des droits de répertoire stricts et de l’audit. Adapté quand la priorité est la séparation des droits, l’audit et la livraison multi-rôles ; si vous avez besoin de sync incrémentale, vous pouvez l’ajouter dans des « répertoires autorisés » avec rsync over SSH au-dessus de SFTP.
En pratique, beaucoup d’équipes combinent : SFTP pour l’accès et les droits, rsync pour les gros syncs incrémentaux – SFTP garantit que seuls les comptes autorisés accèdent aux répertoires définis, rsync assure le transfert incrémental efficace à l’intérieur.
ENOSPC, ECONNREFUSED et autres échecs de sync courants
Cinq étapes pour diagnostiquer et corriger.
# 1. Vérifier quel rsync est utilisé (éviter le mélange avec openrsync)
which rsync
/opt/homebrew/bin/rsync --version
# 2. Vérifier SSH et l’espace disque destination (éviter ENOSPC)
ssh user@remote-mac "df -h /path/to/dest"
ssh user@remote-mac "df -i /path/to/dest" # inodes épuisés ?
# 3. Vérifier que la destination écoute (éviter ECONNREFUSED)
# Avec daemon rsync : netstat -an | grep 873
# Avec rsync over SSH : sshd actif, pare-feu autorise 22
# 4. Dry-run pour voir ce qui serait transféré
rsync -avzn --delete ./build/ user@remote-mac:/path/to/dest/
# 5. Exécution réelle avec log
rsync -avz --delete ./build/ user@remote-mac:/path/to/dest/ 2>&1 | tee rsync.log
ENOSPC : disque ou inodes destination pleins – nettoyer la cible, archiver les anciens artefacts ou agrandir ; optionnellement ajouter en CI une étape « vérifier l’espace disque avant sync ».
ECONNREFUSED : le service distant n’écoute pas ou un pare-feu bloque – avec SSH vérifier sshd et le port 22 ; avec daemon rsync vérifier le port 873 et rsyncd.conf.
Permission denied / droits : le propriétaire du répertoire destination doit correspondre à l’utilisateur SSH ; si vous dépendez d’ACL/--fake-super, pour une conservation complète des droits privilégiez rsync Homebrew et sa doc.
Checklist de décision : rsync/openrsync vs hébergement SFTP selon l’équipe et l’OS
- Une seule machine / un seul nœud, openrsync Sequoia suffit : utiliser le rsync système, et dans les scripts ne pas dépendre du daemon ni d’ACL complexes.
- CI multi-nœuds, besoin de daemon ou de droits stricts : installer rsync Homebrew sur tous les nœuds et utiliser son chemin de façon fixe.
- Priorité à la séparation des droits, à l’audit et à la livraison multi-rôles : mettre en place une passerelle SFTP et l’isolation de répertoires, éventuellement rsync over SSH dans les répertoires autorisés.
- Réduire la dépendance à une machine ou à une version de rsync : confier l’hébergement des artefacts build à un service Mac distant avec SFTP – le fournisseur assure la disponibilité et la politique des droits, local/CI ne fait qu’upload, download et vérification.
rsync et openrsync couvrent la plupart des cas de « sync incrémentale au niveau répertoire » ; ce qui fait la différence, c’est l’homogénéité des versions, un chemin cohérent et un diagnostic rapide en cas de problème. Quand l’équipe grandit et que la conformité ou l’audit deviennent importants, rsync seul ne suffit souvent plus – il faut une couche d’accès claire (comme SFTP) et un environnement distant stable.
Pourquoi macOS Sequoia a remplacé le rsync système par openrsync ?
Pour des raisons de licence GPLv3 incompatibles avec la politique Apple, Apple a remplacé l’ancien rsync par openrsync (licence BSD) dans macOS Sequoia. openrsync est plus léger et plus performant, mais se comporte différemment de rsync 3.x pour le mode daemon distant, les ACL et une partie de la sync des droits – à prendre en compte pour la sync build distant.
Rsync ou SFTP pour synchroniser les artefacts de build sur Mac distant ?
Si l’équipe utilise déjà rsync de façon homogène et a besoin d’incrémental et de checksums, on peut continuer avec rsync 3.x via Homebrew. Si la priorité est la séparation des droits, l’audit et la livraison multi-rôles, une passerelle SFTP avec isolation de répertoires est souvent plus simple à gérer. Les deux peuvent coexister : SFTP pour l’accès et les droits, rsync pour les gros syncs incrémentaux.
ENOSPC ou ECONNREFUSED pendant un sync – comment diagnostiquer ?
ENOSPC indique disque ou inodes destination pleins – nettoyer ou agrandir la cible. ECONNREFUSED indique que le service distant n’écoute pas ou qu’un pare-feu bloque – vérifier sshd, le daemon rsync ou le port SFTP, et le réseau/pare-feu entre la machine locale et le Mac distant.
Entretenir les versions rsync/openrsync et déboguer réseau et disque sur vos propres Mac ou nœuds CI prend du temps. Si vous préférez vous concentrer sur la livraison métier, vous pouvez confier la synchronisation des artefacts build et le contrôle des droits à un hébergement Mac distant : SFTPMAC fournit un SFTP stable et l’isolation de répertoires, compatible avec la sync incrémentale rsync over SSH – nous nous occupons de la disponibilité et de la politique des droits, vous vous concentrez sur le build et la release.