[09:16:02] (03CR) 10jenkins-bot: Localisation updates from https://translatewiki.net. [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/401385 (owner: 10L10n-bot) [09:17:00] (03CR) 10jenkins-bot: Localisation updates from https://translatewiki.net. [labs/tools/heritage] - 10https://gerrit.wikimedia.org/r/401915 (owner: 10L10n-bot) [11:05:39] hi folks, i was trying to mount my labs folder as a sftp disk with transmit (mac) and i can't. it says "the server protocol or authorization method is currently unsupported by transmit disk". are labs servers any of these listed here? https://library.panic.com/transmit5/transmit-disk/ [11:12:14] you can use SFTP just fine to the labs servers [11:12:58] you know you need a key to even authenticate to labs right? [11:15:39] I have it, and I use it just fine [11:15:58] i want to "mount it as a disk" so I can manipulate files as if they were in my laptop [11:16:21] it is much more comfortable to code like this instead of replacing the files every time [11:17:15] but it gives me a software error in "to mount as a disk" and perhaps is due to the labs servers compatibility with my software (Transmit) [11:17:21] this is what it says in the link I posted [11:17:27] i wanted to confirm [11:18:03] what version do you have? [11:18:42] and what version of MacOS are you using? [11:19:11] 5.0.5 Transmit, and High Sierra [11:19:20] hmm okay so thats not the problem [11:20:16] oh I just see this: Unsupported configurations: "Servers that use SSH keys that are stored in Transmit and/or Panic Sync" [11:20:25] "The server protocol or authorization method is currently unsupported by Transmit Disk." [11:20:44] :S [11:20:47] i see [11:21:02] no workaround... [11:21:11] yea, I guess so [11:21:52] until they support it, you are kind of out of luck with that program :s [11:23:11] i see [11:23:19] do u know any alternative that allows mounting as a disk? [11:29:35] well after some searching I found out that something like SSHFS could work [11:29:55] but then again, I don't use MacOS so its hard for me to test [11:32:59] ok, i'll try that. thanks [11:34:32] no problem [11:35:59] marmick: fyi, sshfs requires fuse (short for filesystem in userspace) [11:37:10] not sure about how Transmit works (first time hearing it) [11:37:58] zhuyifei1999_: transmit is very comfortable (well, when that worked, it used to be) [11:38:11] now trying that alternative [11:40:25] great, it does work :) in few hours i'll know if the mounted folder is stable :) [17:24:23] !log tools rebooting tools-paws-worker-1019 to verify repair of T184018 [17:24:28] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL [17:24:28] T184018: Remove overlay from kernel blacklist on toolforge - https://phabricator.wikimedia.org/T184018 [18:15:43] i have the issue again where i can create a new instance but not SSH to it. i did it 3 times in a row. first time it worked. the next 2 times it doesnt. [18:16:18] mutante: ugh. Hopefully just bad RNG luck. Is there one I can try to poke at at bit? [18:16:49] if the initial puppet run breaks they mostly end up bricks [18:17:04] we still don't have a reasonable way to grab a serial console [18:17:12] bd808: instance httpd-crap in project planet [18:17:30] first step: i created an instance and applied puppet::self role [18:17:45] i was able to SSH to it but i shouldn't have applied the self::role before running it once on central master [18:18:06] so i tried to fix that, removed the role again, deleted key and all that [18:18:15] but couldn't get it to run [18:18:28] so i deleted the instance again and create a fresh one.. this time without applying any roles [18:18:38] to just run it once and _then_ apply puppet:;self this time [18:18:49] this new instance i can't SSH to [18:19:00] so i deleted that too and made a third instance [18:19:23] though it's still Permission denied (publickey) [18:19:46] i also tried both my dzahn user and the root user [18:22:11] arg, i didn't remove self: in prefix puppet [18:22:24] probably that';s why the first run failed and couldnt install my key [18:22:32] let me try that again :) [18:23:48] mutante: ah! yeah having self hosted puppet master from the initial boot can be problematic sometimes [18:23:57] it bits us in tools too [18:23:59] i learned that from apergos [18:24:05] but i made the additional mistake to have it in prefix puppet [18:24:14] and the new instance starts with same prefix [18:26:07] yea, so i am on another new one now using root@ [18:26:31] cleaning up that one i mentioned earlier [18:30:13] i ran puppet once on regular master, THEN i applied puppet::self, deleted puppet ssl dir, ran puppet again [18:30:30] now i'm back to the " The certificate retrieved from the master does not match the agent's private key." though [18:30:47] (but i already moved the ssl dir...) [18:31:06] mutante: that;s normal for the setting up self. It can take 2 rounds to get it all working [18:31:43] the puppet run fails though [18:32:31] right. you have to clean the client's certs again -- https://wikitech.wikimedia.org/wiki/Help:Standalone_puppetmaster#Step_2:_Setup_a_puppet_client [18:32:54] it really should work the first time, but I've seen it take 2 tries [18:34:34] hmm. i have repeated it maybe 5 times now [18:36:09] it's still set to use labs-puppetmaster.. hmm [18:36:44] reads the docs again [18:38:22] mutante: is this full self-hosted or are you pointing it at an existing puppetmaster in the project? [18:38:57] i would like self-hosted [18:38:58] for this one [18:39:33] i saw the line " Only if the client is the puppetmaster itself, run also: sudo rm /var/lib/puppet/server/ssl/ca/signed/$(hostname -f).pem" [18:39:36] I don't think the master can be stretch [18:39:44] `/var/lib/puppet/server/ssl/ca' (No such file or directory) [18:40:14] I think there is still something that requires all the puppetmasters to be jessie [18:40:46] * bd808 could be misremembering that [18:40:58] oh! well ok, i will try with jessie [18:43:11] now i see "Beware of using Debian Stretch." :p [18:43:22] thanks, ok [19:01:27] bd808: https://tools.wmflabs.org/admin/tool/projanalysis shows no info but https://toolsadmin.wikimedia.org/tools/id/projanalysis does. Any reason the former can't use data from the latter? [19:09:57] harej: hmmm... it should already. [19:11:26] oh. it gets filtered out because there is no url in the generated json [19:12:02] harej: you can see the raw toolinfo.json for all the Striker descriptions at https://toolsadmin.wikimedia.org/tools/toolinfo/v1/toolinfo.json [19:12:34] I think that Hay's throws that out because of the empty URL [19:13:28] And therefore Striker ignores it? [19:13:46] we could probably consider that to be a bug in Striker's generated toolinfo data I guess [19:14:03] It will only fill in the URL if you check the "This is a webservice" box [19:14:29] Oh also, is there a list of Cloud VPS web proxies? [19:15:05] i.e. all of the .wmflabs.org domains? [19:15:15] harej: yes -- https://tools.wmflabs.org/openstack-browser/proxy/ [19:15:30] Delightful, thank you [19:17:26] those are all the proxied *.wmflabs.org other than tools.wmflabs.org. There are others which are not using the proxy (VPS instances with public IPs) [19:17:53] I don't think we've made a nice list of them anywhere [19:18:36] we could add that to openstack-browser by adding something that reads from the OpenStack Designate API [19:24:47] What is the likelihood that they contain anything interesting? [19:28:12] harej: I'm sure there are a few that host things you'd like to know about. The only reason to have a static IP is to be able to do interesting things like https://meta.wikimedia.org/wiki/Telnet_gateway [19:49:18] So they have wmflabs subdomains but have their own IP instead of the web proxy [19:49:45] correct [22:43:38] !log git upgrading all instances to linux-image-4.9.0-5-amd64 (security) [22:43:41] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Git/SAL [22:43:49] !log phabricator upgrading all instances to linux-image-4.9.0-5-amd64 (security) [22:43:51] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Phabricator/SAL [23:21:49] !log shinken Noticed shinken-wm was missing from IRC, restarted ircecho service [23:21:51] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Shinken/SAL