https://bugzilla.wikimedia.org/show_bug.cgi?id=70054
Bug ID: 70054
Summary: [scap] Syncing wmf-config/PrivateSettings.php syncs
symlink and not file contents
Product: Wikimedia
Version: wmf-deployment
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Deployment systems
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected]
Web browser: ---
Mobile Platform: ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
