Last modified: 2014-08-27 22:25:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T71042, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 69042 - Labs instances rely on unpuppetized firewall setup to connect to databases
Labs instances rely on unpuppetized firewall setup to connect to databases
Status: NEW
Product: Analytics
Classification: Unclassified
Wikimetrics (Other open bugs)
unspecified
All All
: Unprioritized normal
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 61897
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-02 10:10 UTC by christian
Modified: 2014-08-27 22:25 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Script to inject needed DNAT rules to connect to labsdb (1.63 KB, application/octet-stream)
2014-08-02 10:10 UTC, christian
Details

Description christian 2014-08-02 10:10:58 UTC
Created attachment 16127 [details]
Script to inject needed DNAT rules to connect to labsdb

After rebooting wikimetrics-dev1, the instance could not connect to the databases.

The reason was missing DNATs in firewall configuration.

I could not find this requirement documented, nor puppetized.

Is it documented somewhere?

If not ... let's puppetize DNAT rules (if they are not yet).

(Since I needed something right away, I wrote setup_dnat_rules.sh (see attachment), which contains the (somewhat redundant) DNAT rules from staging.
Maybe it helps someone else in the future)
Comment 1 nuria 2014-08-05 09:31:06 UTC
I do not remember us having to do this when we set up neither dev or staging when we fist set them up, which indicates that something might have changed on labs setup. 

I do not think this should be a bug on our end but we should confirm with otto 1st whether this needs to be puppetized.
Comment 2 christian 2014-08-05 09:57:25 UTC
(In reply to nuria from comment #1)
> I do not remember us having to do this when we set up neither dev or staging
> when we fist set them up, [...]

It might be a new thing or not. I do not know.

But we're fighting it once in a while:
* at least on 2014-07-24 there was also need to do it [1],
* when I rebooted a machine some days ago,
* just now (2014-08-05), we again needed to reboot a machine.

Tim's bug that I linked above is from 2014-02-25.
So I doubt it's a new thing.

> I do not think this should be a bug on our end [...]

I wanted a place to track it on our end.
And I wanted a place to put the DNAT script.
Hence, I filed it for us for now, and linked Tim's bug.


[1] http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-analytics/20140724.txt

  [13:53:26] <milimetric> qchris: do you have any idea how to iptables-restore this: http://paste.ubuntu.com/7847723/
Comment 3 Tim Landscheidt 2014-08-05 15:43:41 UTC
AFAIK, the replica DB servers were never accessible under the enwiki.labsdb:$STANDARDPORT scheme without additions to /etc/hosts and iptables on the client side.
Comment 4 christian 2014-08-15 12:22:34 UTC
This bug hit us again today.

See http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-analytics/20140815.txt
starting on [12:05:53]
Comment 5 christian 2014-08-27 22:25:20 UTC
Automatic loading of iptables settings is getting implemented in

  https://gerrit.wikimedia.org/r/#/c/156599/

Once that has been merged, the issue decreases to how to create
/etc/iptables.conf automatically.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links