Last modified: 2014-09-23 23:26:36 UTC
Chad tripped over this today in prod. He made a change to /a/common/wmf-config/PrivateSettings.php (which is a symlink to /a/common/private/PrivateSettings.php) and then ran `sync-file wmf-config/PrivateSettings.php` to sync the file with the cluster. This resulted in an rsync command similar to this running on each cluster host: sudo -u mwdeploy -n -- /usr/bin/rsync --archive --delete-delay --delay-updates --compress --delete --exclude=**/.svn/lock --exclude=**/.git/objects --exclude=**/.git/**/objects --exclude=**/cache/l10n/*.cdb --no-perms --include=/wmf-config --include=/wmf-config/PrivateSettings.php --exclude=* tin.eqiad.wmnet::common /usr/local/apache/common-local Scap is dutifully syncing the file that it was asked to sync, but that file is just a symlink so rsync will only actually sync a symlink and not the contents of the file the symlink points to on tin. The manual fix that a deployer can use is to run `sync-file private/PrivateSettings.php` instead to sync the actual file rather than the symlink. This seems error prone to say the least however. Scap should do something (at least emit a warning) when asked to sync a symlink. Ideally it could sync both the symlink and the target file but that may be too much magic.
I like warning you here - sometimes you want to sync out a symlink? Probably.
I can imagine how one get tricked in that: vim symlink.txt sync-file symlink.txt +1 on emitting a warning that a symlink is being send instead of the actual target.
