[00:08:47] Krenair: both aleady have labs projects with their respective names [00:08:50] icinga and shinken [00:09:03] put them in there, new instances but existing project [00:09:34] https://wikitech.wikimedia.org/wiki/Nova_Resource:Shinken [00:09:41] https://wikitech.wikimedia.org/wiki/Nova_Resource:Icinga [00:10:48] I'm not in icinga, and I'm not an admin in shinken [00:10:54] 6Labs, 10Tool-Labs: nodejs jobs fail with a v8 fatal error - https://phabricator.wikimedia.org/T113826#1676967 (10DanielFriesen) 3NEW [00:11:00] i just added you [00:12:40] !log icinga added krenair [00:12:43] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Icinga/SAL, Master [00:25:23] (03PS1) 10Jean-Frédéric: Fix parsing of source URLs [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/241253 (https://phabricator.wikimedia.org/T112461) [00:27:02] (03CR) 10Jean-Frédéric: [C: 032] Fix parsing of source URLs [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/241253 (https://phabricator.wikimedia.org/T112461) (owner: 10Jean-Frédéric) [00:27:17] (03Merged) 10jenkins-bot: Fix parsing of source URLs [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/241253 (https://phabricator.wikimedia.org/T112461) (owner: 10Jean-Frédéric) [00:29:06] mutante, thanks. what about shinken? [00:36:18] (03PS1) 10Jean-Frédéric: Commenting out be-x-old configuraiton [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/241255 (https://phabricator.wikimedia.org/T112415) [00:36:31] (03CR) 10Jean-Frédéric: [C: 032] Commenting out be-x-old configuraiton [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/241255 (https://phabricator.wikimedia.org/T112415) (owner: 10Jean-Frédéric) [00:36:44] (03Merged) 10jenkins-bot: Commenting out be-x-old configuraiton [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/241255 (https://phabricator.wikimedia.org/T112415) (owner: 10Jean-Frédéric) [00:52:32] (03PS1) 10Jean-Frédéric: Make link for registrant_url in API HTML output [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/241258 (https://phabricator.wikimedia.org/T112462) [00:52:46] (03CR) 10Jean-Frédéric: [C: 032] Make link for registrant_url in API HTML output [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/241258 (https://phabricator.wikimedia.org/T112462) (owner: 10Jean-Frédéric) [00:53:00] (03Merged) 10jenkins-bot: Make link for registrant_url in API HTML output [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/241258 (https://phabricator.wikimedia.org/T112462) (owner: 10Jean-Frédéric) [00:53:46] Krenair: what mutante said :) [00:54:52] yuvipanda, so what about shinken? [00:55:05] Krenair: I can make you admin [00:55:56] Krenair: you're already projectadmin [00:56:24] Not according to the page... [00:57:06] Krenair: according to special:novaproject you are [00:57:09] SMW lies because SMW [00:57:14] * Krenair grumbles [00:57:15] yes I am [00:57:18] don't trust iiitttt [00:57:22] thanks yuvipanda/mutante [00:57:26] yw [00:57:39] I'll actually use this later, first I need to get some sleep [00:57:43] * Krenair waves [00:58:09] Krenair: cya [01:07:08] Coren: https://phabricator.wikimedia.org/T113756? [01:08:19] 6Labs, 10Tool-Labs: SMTP service on toolserver.org down - https://phabricator.wikimedia.org/T113756#1677074 (10yuvipanda) I restarted exim on the box, is it better now? [01:09:41] is there some rule that an instance cannot hav the same name as the project? [01:09:47] no... [01:09:49] why? [01:09:54] oh, it could be actaully [01:10:05] yuvipanda: No it isn't. [01:10:07] since both $instancename.$projectname.eqiad.wmflabs and $instancename.eqiad.wmflabs are valid [01:10:08] I'm trying to create sentry.sentry.eqiad.wmflab and get errors [01:10:08] * Coren checks. [01:10:13] Coren: I just restarted exim [01:10:24] tgr: yeah I think DNS might freak out. try sentry-01 [01:10:26] ps faux [01:10:37] thx [01:11:01] Coren: yeah it was dead and I restarted it [01:11:07] yuvipanda: It's not starting right - trying to figure out why. [01:11:10] Coren: ALERT: exim paniclog /var/log/exim4/paniclog has non-zero size, mail system possibly broken [01:11:11] ok [01:11:12] thanks [01:11:17] I still don't know anything about mail unfortunately [01:11:30] Ah. Out of space. [01:14:31] 6Labs, 10Tool-Labs: Install composer on tools-login - https://phabricator.wikimedia.org/T104789#1677078 (10yuvipanda) Let's just do the git checkout + symlink option via puppet? We can make it a composer::install class or something and include it in both tools and integration [01:24:13] Hm. Not it. [01:24:23] * Coren attempts to figure out wth is going on. [01:25:25] ok [01:27:54] No errors. No diagnostic. Just doesn't start smtp. [01:28:19] * Coren tries to hit it with a hammer. [01:40:51] ... something changed /etc/default/exim4 [01:43:40] QUEUERUNNER='queueonly' [01:45:00] It comes from puppet. [01:45:02] * Coren grumbles. [01:53:11] 6Labs, 10Tool-Labs: SMTP service on toolserver.org down - https://phabricator.wikimedia.org/T113756#1677087 (10scfc) No, the host's SMTP service is still unreachable: ``` scfc@tools-mail:~$ sudo exim -v -M 1ZeuQb-0001fr-MR delivering 1ZeuQb-0001fr-MR Connecting to toolserver.org [10.68.16.162]:25 ... failed:... [02:03:32] Coren: can you keep ^ updated as well? [02:03:56] Hrmph. Yeah, though I have pithy little to say for now. [02:05:12] ok [02:05:15] 6Labs, 10Tool-Labs: SMTP service on toolserver.org down - https://phabricator.wikimedia.org/T113756#1677106 (10coren) Yeah, something in puppet is actually disabling the SMTP daemon in `/etc/defaulst/exim4`. I'm trying to track down what changed now. [02:14:07] Ah, looks like some of the defaults have changed in base. [02:24:15] yuvipanda: found the culprit, patch in -operations. [02:39:05] 6Labs, 10Tool-Labs, 5Patch-For-Review: SMTP service on toolserver.org down - https://phabricator.wikimedia.org/T113756#1677125 (10scfc) Now it rejects (I suppose) valid addresses: ``` scfc@tools-mail:~$ sudo exim -v -M 1ZeuQb-0001fr-MR delivering 1ZeuQb-0001fr-MR Connecting to toolserver.org [10.68.16.162]:... [03:17:52] 6Labs, 10Tool-Labs: qmaster chokes on old jobs from hosts that have been renamed - https://phabricator.wikimedia.org/T113614#1677139 (10scfc) Changing the order of shutting down would make sense :-). I'll try that next time. [03:29:40] 6Labs, 10Tool-Labs, 5Patch-For-Review: Remove modules/toollabs/files/host_aliases - https://phabricator.wikimedia.org/T109485#1677141 (10scfc) After the mishap with T113614, to get `tools-webgrid-generic-1404` working again I did: 1. Restart `gridengine-exec` and `gridengine-master`. The master kept compla... [03:37:07] 6Labs, 10Tool-Labs, 5Patch-For-Review: Remove modules/toollabs/files/host_aliases - https://phabricator.wikimedia.org/T109485#1677143 (10scfc) Forgot: `tools-webgrid-generic-1404.eqiad.wmflabs` was referenced as submit host, so I added the `.tools.` variant and removed the old host name. [05:49:38] hi yuvipanda. are you still around? [05:49:43] yes [05:49:54] there is one typo apparently [05:49:55] sorry, I got sick and was not around for some hours [05:50:00] also give me access? [05:50:03] no its ok [05:50:05] you have access [05:50:07] take care of yourself [05:50:09] oh [05:50:24] yeah, now you're in there. :-) [05:52:17] ah yes [05:55:01] 6Labs, 10Tool-Labs, 6Design Research Backlog, 6Learning-and-Evaluation, and 2 others: Organize a (annual?) toollabs survey - https://phabricator.wikimedia.org/T95155#1677197 (10leila) [05:57:57] 6Labs, 10Tool-Labs, 6Design Research Backlog, 6Learning-and-Evaluation, and 2 others: Organize a (annual?) toollabs survey - https://phabricator.wikimedia.org/T95155#1677198 (10leila) [09:29:01] PROBLEM - Puppet failure on tools-webgrid-lighttpd-1407 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [09:57:19] 6Labs, 7Database: Missing record in replica - https://phabricator.wikimedia.org/T89689#1677289 (10Ankry) @Krenair , can you verify if the orphaned revisions exist also in the production database? IMO, it is likely. They all seem to be related to page move process and likely created because of some bug. At leas... [10:28:49] Hi [10:29:27] there is high replication lag on all wikisource databases [10:29:36] anybody knows why? [10:59:20] ankry: looks ok on enwikisource https://en.wikisource.org/w/api.php?action=query&meta=siteinfo&siprop=dbrepllag&sishowalldb= [11:05:56] Reedy: SELECT (UNIX_TIMESTAMP()-UNIX_TIMESTAMP(MAX(rev_timestamp))) FROM enwikisource_p.revision; gives 66583 seconds on Quarry [11:06:21] http://tools.wmflabs.org/betacommand-dev/cgi-bin/replag report it as 18 hours lags, which one to trust? [11:06:39] Oh [11:06:54] Reedy, it's production you showed :) [11:06:54] Replag to labs... [11:08:08] 6Labs, 10Tool-Labs, 5Patch-For-Review: Packages from the aptly server are not installable - https://phabricator.wikimedia.org/T112699#1677319 (10valhallasw) I've been planning to set up the 'tool' tools.dpkg as place to build all our packages. It might make sense to also use that as place to sign the aptly u... [11:29:48] phe: you will need to take the results of that replag with some understanding [11:30:14] phe: it uses the last edit to the site to compute the lag, so on inactive projects the value can be skewed [11:30:48] Betacommand: neither plwikisource nor enwikisource seem to be inactive [11:31:27] ankry: not a problem, just wanted you to be aware of the possible flaw in reported datra [11:31:38] sure [11:33:34] ankry: wasnt sure of any othe way to reliably check the lag other than to query the RC table for the most recent action and use that as a comparison point [11:38:40] Betacommand: no revision newer than 20150925151503 is visible in plwikisource_p while there are over 500 newer on production (and more than 300 of them dated yesterday) [11:39:12] ankry: OK [12:22:17] 6Labs: `pr_index`to be replicated to Labs public databases - https://phabricator.wikimedia.org/T113842#1677380 (10Billinghurst) 3NEW [12:28:04] 6Labs: `pr_index`to be replicated to Labs public databases - https://phabricator.wikimedia.org/T113842#1677391 (10Reedy) [12:28:51] what is the opposite of "become"? [12:30:27] I think you'd change the other word [12:31:50] I cannot become 'billinghurst' [12:31:57] (03PS1) 10Ricordisamoa: Initial commit [labs/tools/wikidata-slicer] - 10https://gerrit.wikimedia.org/r/241296 [12:32:07] tools.stewardbots@tools-bastion-01:~$ become wikisource-bot [12:32:07] You are not a member of the group tools.wikisource-bot. [12:32:21] it is unidirectional [12:33:23] just exit out a level [12:33:27] Ctrl + D [12:33:45] d'oh [12:33:51] thx [12:34:24] I knew that, obviously captured in the moment [12:40:16] (03PS2) 10Ricordisamoa: Initial commit [labs/tools/wikidata-slicer] - 10https://gerrit.wikimedia.org/r/241296 [12:57:48] (03PS3) 10Ricordisamoa: Initial commit [labs/tools/wikidata-slicer] - 10https://gerrit.wikimedia.org/r/241296 [13:01:30] 6Labs, 7Database: Missing record in replica - https://phabricator.wikimedia.org/T89689#1677404 (10Krenair) 5Open>3Resolved They all appear to me. [14:14:03] 6Labs, 10Tool-Labs, 10Wikimedia-Mailing-lists: Shutdown toolserver-l mailman list - https://phabricator.wikimedia.org/T113845#1677781 (10Multichill) Looks like someone already started doing this: ``` Dear sender, this mailing list has been closed. Please use the list labs-l to discuss topics regarding ToolL... [14:14:12] 6Labs, 10Tool-Labs, 10Wikimedia-Mailing-lists: Shutdown toolserver-l mailman list - https://phabricator.wikimedia.org/T113845#1677782 (10Multichill) p:5Triage>3Lowest [14:28:49] 6Labs, 10Tool-Labs, 10Wikimedia-Mailing-lists: Shutdown toolserver-l mailman list - https://phabricator.wikimedia.org/T113845#1677791 (10JohnLewis) This should be left for @nosy79 being the listadmin who did this. [14:39:21] wikibugs: behave [14:40:38] it's not wikibugs, it's the bug spammers! [14:40:45] but I'm confused it's not throttling as it should [14:42:26] * valhallasw`cloud blames James_F :-p [14:42:33] * James_F grins. [14:42:35] Sorry. [14:42:46] lemme see if I can get the throttling fixed... [14:43:05] valhallasw`cloud: just ban James_F from phab [14:43:19] :-P [14:43:29] Or make him go have a weekend [14:43:32] Banning seems easier [14:43:33] Reedy: Never! [14:43:51] Reedy: I'm flying back home tomorrow, so I have to get all my weekend working in today. [14:44:04] haha <3 [14:45:11] Hmm. Do I make a revert patch of legoktms patch and mark as do not merge to keep track of stuff? [14:51:54] Reedy: You can keep track locally pretty trivially… [14:52:33] * Reedy fixes one [15:24:38] ankry: It should be fixed now. Might take a while to catch up [15:30:51] I will provide soon a reliable way to check replication lag, if you promise to stop hitting random databases :-) [15:32:33] 6Labs, 10Tool-Labs, 10Labs-Infrastructure, 3Labs-Sprint-115: Can't delete security group rules after OpenStack upgrade - https://phabricator.wikimedia.org/T112492#1678282 (10scfc) JFTR: Worked for me and Tools/default/80 as well. Thanks! [16:11:56] 6Labs: `pr_index`to be replicated to Labs public databases - https://phabricator.wikimedia.org/T113842#1678309 (10Glaisher) [16:11:58] 6Labs, 10Wikimedia-Labs-General, 6operations, 7Database, 7Tracking: (Tracking) Database replication services - https://phabricator.wikimedia.org/T50930#1678308 (10Glaisher) [18:56:22] PROBLEM - Puppet failure on tools-webgrid-lighttpd-1411 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [19:03:02] 6Labs, 10Tool-Labs: croptool creates huge temporary files - https://phabricator.wikimedia.org/T107328#1678537 (10Danmichaelo) Interesting. I guess files are left in some cases when the tool runs out of memory because of huge files. I could add a limit on how large files the tool will try loading. [19:09:56] Reedy: o.O which patch? [19:10:04] legoktm: ? [19:10:42] [07:45:12] Hmm. Do I make a revert patch of legoktms patch and mark as do not merge to keep track of stuff? [19:11:05] legoktm: oh, your patch adding the phpcs excludes [19:11:19] I was meaning mark my revert as do not merge, not yours :P [19:11:49] legoktm: Seen what we've got done so far today? (plus amir has done a load of long lines) [19:11:49] https://github.com/wikimedia/mediawiki/blob/master/phpcs.xml#L3-L10 [19:12:08] omggggggg [19:12:11] <33333 [19:12:33] https://gerrit.wikimedia.org/r/#/c/241341/ [19:12:43] wait [19:12:43] if you fancy looking at stupid test failures due to whitespace changes :/ [19:12:50] did anyone make it voting? [19:13:00] JamesF has made a patch to do it [19:13:02] Not been merged [19:13:14] That's https://gerrit.wikimedia.org/r/#/c/241312/ [19:13:26] hmm, I was going to file an upstream bugs about the indentation with tabs one [19:13:44] We do have a few that need fixing [19:14:06] well for https://gerrit.wikimedia.org/r/#/c/241341/2/tests/phpunit/includes/resourceloader/ResourceLoaderStartUpModuleTest.php,cm [19:14:15] using spaces there is ok, because it's in a stinrg [19:14:17] string* [19:15:02] ohh, filing a bug for that? [19:15:08] makes sense [19:15:22] Down to sub 500 errors [19:15:38] uh, warnings [19:15:44] :DD [19:15:51] brb, I have to run to the store [19:16:39] 365 long lines still to fix though [19:16:40] lol [19:21:11] PROBLEM - Puppet failure on tools-checker-01 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [19:31:25] RECOVERY - Puppet failure on tools-webgrid-lighttpd-1411 is OK: OK: Less than 1.00% above the threshold [0.0] [19:57:14] yuvipanda, shall we get rid of labs-dnsrecursor*.openstack.eqiad.wmflabs now? [19:57:36] am thinking if there is other stuff we wanna do there [19:58:04] maybe we could automate the public floating ip / internal ip thing [19:58:12] it is manually specified now [19:59:11] yuvipanda, well shall I at least get rid of the old one? [20:00:41] oh yeah sure [20:09:34] legoktm: https://github.com/squizlabs/PHP_CodeSniffer/issues/722 [20:10:23] yuvipanda, does shinken not work on jessie? [20:10:59] krenair no our manifests don't. [20:11:13] fixing that might be nice because Jessie has a newer version... [20:11:26] ours don't because we share some puppet code between icinga and shinken [20:11:57] but there is going to be work done to modernize our icinga puppet stuff this quarter... [20:11:59] dunno [20:12:00] it fails because of ircecho depending on python-irclib [20:12:11] which has been replaced with python-irc [20:12:23] ah that isn't too hard to fix I guess [20:12:39] just a conditional should do... [20:12:58] https://phabricator.wikimedia.org/P2097 [20:15:03] yuvipanda, trusty appears to have different issues [20:15:22] no python3-ldap3? [20:17:11] test [20:20:59] do we have python3-ldap3 on precise? [20:23:39] shinken-01.shinken.eqiad.wmflabs is trusty... [20:24:20] That has misc::labsdebrepo though, weirdly [20:25:58] Only jessie has python{2,3}-ldap3 bundled by upstream [20:26:25] Package: python3-ldap3 [20:26:25] Status: install ok installed [20:26:54] (from shinken-01, a ubuntu-14.04-trusty (deprecated 2015-02-03) instance) [20:28:07] tools-login has python-ldap3 installed but apt-cache madison python-ldap3 shows nothing? :| [20:29:38] which suggests it was dpkg -i'ed manually, I think? Or that it's no longer in one of the apt repos...? [20:33:46] valhallasw`cloud, shinken-01 shows nothing for "apt-cache madison python3-ldap3" as well [20:34:25] modules/shinken/manifests/shinkengen.pp: 'python3-ldap3', # Custom package of https://pypi.python.org/pypi/python3-ldap [20:34:57] valhallasw`cloud: is that on Jessie ? [20:35:19] hashar: ? [20:35:30] failure to find python3-ldap3 [20:35:38] no, trusty [20:35:52] jessie packages python3-ldap3 [20:36:28] ops have some history of the apt.wm.o repos [21:21:51] yuvipanda, valhallasw`cloud: so, what can I do about this? [21:22:15] ldap3 or rest of shinken? [21:22:43] file a bug and i I'll out the library on apt.wm.o tomorrow [21:22:48] Krenair: I'm not sure. The python3-ldap3 package seems to be different from the one in jessie [21:22:49] and hand install it in the meantime? [21:22:53] https://pypi.python.org/pypi/python3-ldap doesn't even exist anymore [21:23:40] but you can try to install https://packages.debian.org/jessie/python/python3-ldap3 I suppose [21:39:12] (03PS1) 10Polybuildr: Add MediaWiki-Codesniffer to -releng [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/241468 [21:41:23] valhallasw`cloud, yuvipanda: I had to manually install the dependency python3-pyasn1 [21:41:45] Starting arbiter: [21:41:46] FAILED: AttributeError: 'NoneType' object has no attribute 'configuration_errors' (full output is in /tmp/bad_start_for_arbiter) [21:42:39] I don't expect shinken to work on Jessie [21:42:44] our roles at least [21:42:45] This isn't Jessie. [21:42:49] This is Trusty. [21:42:49] ah ok [21:42:59] Okay, wtf: [21:43:50] https://phabricator.wikimedia.org/P2099 [21:44:35] if hg is None... hg.configuration_errors.append? [21:45:28] hahaha [21:45:30] yessss [21:45:37] I think I might have patched that by hand [21:45:48] which might have been my last act before stopping actively working on it [21:49:15] :| [21:51:14] yup. [21:51:17] terrible [21:51:38] part of the reason I have reccomended that we not consider shinken for our next round of evaluations for monitoring [21:52:16] [1443304303] Error : Configuration is incorrect, sorry, I bail out [21:52:17] Helpful [21:54:16] krenair if you look through the output there is an error report somewhere way up [21:55:29] somewhere in here? [21:55:32] https://phabricator.wikimedia.org/P2100 [21:58:36] yes [21:58:41] just at the top [21:58:50] Valhalla contact is unknown [21:59:13] the rest might be because shinkengen hasn't run? [21:59:33] private-contacts.cfg: contact_name valhallasw [21:59:50] yes it has a password and hence wasn't puppetized I guess [22:01:17] ah [22:01:20] yeah :/ [22:03:01] won't be responsive for a bi [22:03:04] bit [22:03:08] heading out [22:09:03] PROBLEM - Puppet staleness on tools-webgrid-lighttpd-1402 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [43200.0] [22:15:06] Krenair: feel free to reset my password if that's convenient [22:15:29] do you want it reset or something? [22:16:32] Hello guys! [22:16:47] I'm starting some tests on labs [22:17:14] and I would like to know how can I access the replica db to run some queries using PHP [22:19:44] valhallasw`cloud? [22:20:37] I created an app for tests here https://tools.wmflabs.org/edcounter/ [22:21:10] I tried to create a db connection but I'm not able to do it through sockets [22:27:47] yuvipanda, I ran shinkengen and it still has some errors [22:27:57] (I created a dummy private-contacts.cfg without the real password) [22:34:01] RECOVERY - Puppet staleness on tools-webgrid-lighttpd-1402 is OK: OK: Less than 1.00% above the threshold [3600.0] [22:39:58] rodrigo have you looked at the docs? [22:40:01] !help [22:40:01] !documentation for labs !wm-bot for bot [22:40:09] !documentation [22:40:19] I need some guidance here :-) [22:40:19] well done, wm-bot [22:40:44] !documentation [22:40:49] https://wikitech.wikimedia.org/wiki/Help:Tool_Labs [22:40:55] is full docs [22:41:00] has a section on database [22:41:48] I'm able to access the database throug scripts [22:41:58] I executed some queries there [22:42:08] but I was not able to connect through PHP [22:42:39] the documentation should have info on what host to connect to and where to find your username and password [22:44:06] Krenair: no, I thought my account gave you issues in setting up shinken? [22:44:28] valhallasw`cloud, no [22:44:55] it's unpuppetised weirdness, but it's no real problem [22:45:13] not for what I'm doing anywaty [22:45:15] anyway* [22:45:31] Ok! [22:46:55] I tried it, but I'm receiving that message Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) [22:47:52] don't use sockets then? [22:48:10] and mysql won't be on the local server [22:48:12] Rodrigo: the server isn't local [22:48:27] connect to a server like "enwiki.labsdb" [22:48:33] depending on what wiki you want, use a different server [22:48:48] ptwiki [22:49:49] I got it [22:49:53] my bad! [22:51:17] done ;-0 [23:05:28] yuvipanda, is shinkengen supposed to just leave empty files? [23:06:57] /etc/shinkengen.yaml is missing the LDAP proxyagent password :| [23:07:26] that's made it generate useful files [23:07:39] now shinken starts [23:21:54] valhallasw`cloud, any idea why it might not be getting the ldap password correctly? [23:22:17] modules/shinken/templates/shinkengen.yaml.erb uses <%= @ldap_pass %> [23:22:44] and the class which uses that template has this as a default: $ldap_pass = $passwords::ldap::labs::proxypass [23:23:25] which looks very much set in labs/private