[00:14:34] Coren|airport, I have the feeling with all these tools users, the database has slowed down a bit. [00:14:52] Which? [00:14:58] Tolls-DB? [00:15:08] replication [00:15:36] I've never seen in over a few % use. [00:16:02] But locks may make it seem much slower at times. [00:17:38] Probably going to have to put a query killer in place even though I hoped we wouldn't have to though. [00:18:10] On toolserver I can load https://toolserver.org/~quentinv57/tools/sulinfo.php?username=Cyberpower678&showinactivity=1&showblocks=1&showlocked=1 in about 20 seconds. [00:18:46] Wasn't the issue with sulinfo the roundtrip between pmtpa and eqiad? [00:19:15] Here, with the necessary modifications, such as switching to the indexed tables, https://tools.wmflabs.org/quentinv57-tools/tools/sulinfo.php?username=Cyberpower678&showinactivity=1&showblocks=1&showlocked=1 loads in about 70-80 seconds [00:19:22] Coren|airport, ^ [00:20:01] https://bugzilla.wikimedia.org/show_bug.cgi?id=53987 [00:20:04] Sulu of is being eaten by the latency. The move toe quad will solve that one [00:20:27] Sulinfo* stupid autocorrect [00:29:15] Coren|airport, I commented ther. [00:29:26] When do you suppose this move will take place? [00:30:26] Coren|airport, ^ [00:30:38] A great deal of the open stack infrastructure is in place. I'm hoping I'll be able to open the other tool labs infrastructure in a couple weeks [00:31:21] Coren|airport, awesome. Can you keep me posted? [00:31:49] That will be made very conspicuous on labs-l [00:31:59] :) [00:58:09] hi [00:58:19] PHP Warning: socket_sendto(): unable to write to socket [111]: Connection refused in /data/project/quentinv57-common/common/class/socket.class.php on line 187 [00:58:22] What might that mean? [01:05:22] anyone? [01:09:21] Cyberpower678: ping [01:09:29] actually, let's discuss in #wmt [01:09:45] pong [02:25:08] Hey folks, I appear to have "lost" four instances - I was reconfiguring one of them, hit save and it told me that instance didn't exist. Now my instance list is empty for the project. [02:25:37] this is the "account-creation-assistance" project [02:35:22] and they're back. nevermind (or thanks) [02:53:20] hi all [02:53:41] so.. I'm trying to connect to a toll labs db instance without success so far [02:54:01] ERROR 2003 (HY000): Can't connect to MySQL server on 'commonswiki.labsdb' (110) [02:54:51] dschwen_: what command are you using? [02:55:02] mysql ;-P [02:55:26] I copied the s4.labsdb commonswiki.labsdb line from tool labs /etc/hosts [02:55:45] Try mysql --defaults-file=~/replica.my.cnf -h commonswiki.labsdb [02:55:46] Oh, I should mention that I'm trying to connect from a different project :-) [02:55:57] or oh? [02:56:12] dschwen_: mysql --defaults-file=~/replica.my.cnf -h commonswiki.labsdb == same error? [02:56:12] connecting from tool labs works without a hitch [02:56:22] try "sql commonswiki"? [02:56:52] I'm pretty much using that commans (not sql, that does not exist) [02:56:56] dschwen_, you would likely need to SSH into labs to access the database. [02:57:09] into tool-labs more precisely. [02:57:20] Giftpflanze mentioned that he connects to tool labs db all the time [02:57:39] and coren seemed to indicate that it is possible to connect from outside [02:57:49] Are you trying to access the DB from outside tools? [02:57:51] I _am_ on labs [02:57:56] just not on tools [02:58:01] on my own project [02:58:02] dschwen_, I'd love to know how to get access to tool labs dbs from outside tool labs (but inside labs) too :P [02:58:04] Oh. [02:58:05] You need to SSH into tools. [02:58:17] Are you sure? [02:58:34] That's the only way I know of and probably the only way at the time. [02:58:59] Different projects are like different data centers. :p [02:59:09] They're not connected. [02:59:38] hm, that is not true at all Cyberpower678 [02:59:47] they share the 10 net [02:59:56] but the s4.labsb is a 192 ip [03:00:04] dschwen_, It's supposed to be an analogy. [03:00:15] yeah, sure, but it is a bad one [03:00:19] I know. [03:00:36] a project can provide a service for a different project [03:00:43] But I'm pretty sure there is no way to access replication without SSHing into tools. [03:00:50] At least for now. [03:01:32] That might change when they switch to equad [03:02:09] hm, there is no instance that maps to s4 [03:02:22] it could have been possible [03:02:34] dschwen_, my understanding is that the db replicas were physical machines [03:02:39] I can see all tools instances (VMs) from my project [03:02:45] oh, right [03:02:52] I think I remember that now [03:03:44] * Cyberpower678 goes back to coming up with a workaround with the DB latency issue. [03:04:14] really confusing though, it is not clear to me how that IP is routed from tool-labs [03:04:29] dschwen_, I try not to think about it. :p [03:04:45] well ssh tunnel... [03:09:38] stwalkerster, what [03:09:47] 's going on with your project/ [03:11:09] Cyberpower678, ? [03:11:43] I'm looking at Ganglia and it looks like you're using -800M of memory. [03:12:10] w00t. [03:12:52] stwalkerster, are you upgrading the memory? [03:12:58] stwalkerster, http://ganglia.wmflabs.org/latest/graph.php?r=20min&z=xlarge&c=account-creation-assistance&m=load_one&s=by+name&mc=2&g=mem_report [03:13:15] nope, I'm trying to poke some instances into life [03:13:58] Your poking's doing a lot more than that [03:15:20] well aparently running "cd /data/project" crashes my shell. I've no idea what it's doing [03:38:09] btw, do I need to opt my project into ganglia? [03:38:17] the fastcci graphs are all empty [03:38:25] no [05:35:10] If I'm using the web proxies thing on Special:NovaProxy, how do I get the original IP address of the web request (like an XFF header)? [05:38:09] is there a sys admin around by chance? I'm still dealing with a bad permissions issue. [05:38:56] I ran the take script the other day, and it borked the permissions on all my files; now I no longer have access to them under EITHER my original login or the tools login [07:56:00] hm, dschwen_ is gone [09:38:15] hi, can we access PhpMyAdmin on the labs tool instance ? [11:02:14] libgcc_s.so.1 must be installed for pthread_cancel to work [11:02:37] when running PHP via SGE [11:02:47] jsub -N phptest "php -r 'echo 1;'" [11:47:04] hoo: php needs more mem. try: jsub -N -mem 500m phptest "php -r 'echo 1;'" – btw it's mentioned in the help docs [11:47:54] Wasn't default mem 256 in SGE? [11:48:24] thanks, will give it a try [11:52:19] hoo: jsub -N phptest -mem 500m "php -r 'echo 1;'" , of course ;) [14:26:14] Cyberpower678: can you please check https://bn.wikipedia.org/wiki/%E0%A6%9F%E0%A7%87%E0%A6%AE%E0%A6%AA%E0%A7%8D%E0%A6%B2%E0%A7%87%E0%A6%9F:Statustop ? [14:31:49] my script isn't working. So asking you is there any problem with that template. [15:02:39] Pratyya, why don't you tell me more? What's not working exactly. Last time I checked, the script was working as should. [15:03:03] can you please come to bn wiki once? Cyberpower678 [15:03:17] I'm already there. [15:04:04] Unfortunately, I can't read Bangali. [15:04:17] then use https://bn.wikipedia.org/wiki/%E0%A6%AC%E0%A7%8D%E0%A6%AF%E0%A6%AC%E0%A6%B9%E0%A6%BE%E0%A6%B0%E0%A6%95%E0%A6%BE%E0%A6%B0%E0%A7%80:Pratyya_Ghosh/StatusChanger.js to your skin. [15:04:25] Cyberpower678: ^ [15:04:49] Then you know {{statustop}} at your talkpage may help. [15:07:03] I believe that statustop template is creating problem. [15:07:56] see https://bn.wikipedia.org/wiki/%E0%A6%AC%E0%A7%8D%E0%A6%AF%E0%A6%AC%E0%A6%B9%E0%A6%BE%E0%A6%B0%E0%A6%95%E0%A6%BE%E0%A6%B0%E0%A7%80:Pratyya_Ghosh/Top_icons. [15:08:02] No status in this page. [15:08:07] Cyberpower678: ^ [15:09:00] Lemme check some things [15:09:53] What's Bengali for User [15:10:33] ব্যবহারকারী [15:14:31] Cyberpower678: any luck ? [15:16:35] Working on it. Unfortunately, working with a foreign language makes it difficult. [15:20:29] Cyberpower678: 你说得对！ [15:33:58] Is there a sys admin around by chance? I'm still dealing with a bad permissions issue. I ran the take script the other day, and it borked the permissions on all my files; now I no longer have access to them under EITHER my original login or the tools login. [15:34:24] Seeing as the Toolserver is set to be closed on Monday, I'm rather anxious to get my tools migrated this weekend [15:34:31] Magog_the_Ogre, chmod doesn't work? [15:35:18] Magog_the_Ogre: when TS is closed will the code still be able to be moved? [15:35:19] No, there was some sort of kernel or tool bug [15:35:30] yes it can still be moved but my tools will be down, huh [15:35:32] Or will it all be deleted? [15:35:34] okay [15:35:46] Cyberpower678, the permissions look like this: [15:35:48] ls: cannot access /data/project/magog/UserData/logger.properties: Permission denied [15:35:48] total 0 [15:35:48] ?????????? ? ? ? ? ? logger.properties [15:35:58] (that's for ls -l) [15:36:08] Magog_the_Ogre, lemme look. [15:37:11] Magog_the_Ogre, You probably already tried this but... [15:37:17] become magog [15:37:21] yup [15:37:31] I don't have access on either bc of bad permissions [15:37:37] chmod 775 /data/project/magog/UserData/logger.properties [15:38:21] Magog_the_Ogre_: chmod u+x /data/project/magog/UserData/ should fix it. [15:38:22] chmod: changing permissions of `replica.my.cnf': Operation not permitte [15:38:27] Magog_the_Ogre, ^ [15:39:02] Magog_the_Ogre_: Oh. chmod ug+x /data/project/magog/UserData/ actually [15:39:28] * anomie momentarily forgot that "drw-rwSr-x" means group doesn't have x either [15:40:22] anomie, it gave me errors when I tried as magog. when I tried as local-magog, it didn't emit any errors, but it still didn't fix the problem. >_> [15:40:42] Cyberpower678: BTW, 644 would be better for plain files. [15:41:19] Magog_the_Ogre_: You still get the permision denied when using ls -l ? [15:41:26] probably, but that's academic; no one is going to try to execute my logger files [15:41:31] correct, anomie [15:41:37] anomie, I usually like to have full access for user and group [15:41:56] while leaving the other to be able to read and execute. [15:42:04] Cyberpower678: I meant 664. The point is no x bits set on a non-executable file. [15:42:08] * anomie typoed [15:42:36] Oh. [15:42:44] I could use that too. [15:48:05] Magog_the_Ogre_: I'm out of ideas then, it looks to me like "ls -l /data/project/magog/UserData/logger.properties" should be working for you now. Sorry. [15:48:51] Hi. [15:49:06] How can someone get a list of irc.wikimedia.org channels? [15:56:45] anomie, I've stated this a few times already [15:56:48] the permissions are borked [15:56:57] it was either a tool error or a kernel error [15:57:02] I need a sudoer to fix it [15:57:12] (I'm not trying to sound rude, sorry if I am) [15:57:30] I figured as much, I jsut wanted to be sure. [15:58:16] Magog_the_Ogre_: The chmod command should have fixed the borked permissions. So I guess it must be some permission I can't see, or something borked at a lower level. It's odd that the ls -l on your file works fine for me from my account. [16:00:05] anomie, tell me if you get any stderr notices when you run this command: ls /data/project/magog -l -R > /dev/null [16:00:40] omg [16:00:44] Magog_the_Ogre_: No stderr notices [16:00:46] it worked this time [16:00:48] I just fixed it [16:00:49] ugh [16:01:02] I had run the chmod on my local Ubuntu computer, not on my ssh [16:01:05] sorry guys, and thanks anomie [16:01:18] Magog_the_Ogre_: You're welcome [16:33:54] hey guys, anyone know what this means? $ take * [16:33:54] 13px-Red_x.svg.png: You need to share a group with the file [16:42:59] Magog_the_Ogre, I've had that before. It turned out what I was trying to take didn't exist. [16:48:45] thanks cyberpower [16:48:59] does anyone know the new tusc url? [16:49:43] the tool incorrectly lists tools.wikimedia.de as the server still: http://tools.wmflabs.org/tusc/index.html [16:58:41] Is tusc still going to exist? Or should people use OAuth (with JWT for identity verification) instead? [16:59:51] (well, I suppose it'll exist as long as things need it, but...) [17:07:04] anomie, I've got something amusing for you. [17:07:06] local-quentinv57-tools@tools-login:~$ webservice restart [17:07:06] Retarting webservice....... [17:08:08] anomie, From what I've heard, TUSC is going to be obsolete and be replaced with OAuth [17:08:47] * anomie goes to add JWT fetching-and-verification to oauth-hello-world [17:37:47] Hello Luxo! [17:37:57] Hi huh [17:38:15] admin here? >The program 'jpegtran' is currently not installed. To run 'jpegtran' please ask your administrator to install the package 'libjpeg-turbo-progs'< I need this program... [17:38:17] Could you make your tool work with GET requests like it used to? [17:38:35] * huh is referring to "guc" [17:39:21] oh dear [17:39:32] TUSC being obsolete will complicate things, a lot [17:40:17] huh, I don't like this. On the toolserver, I had up to 20 requests/minute from web crawler, and it got always "Max user connections exceeded" because of this. [17:40:24] Ah. [17:40:58] they follow the links on all the contributions-pages in the wikis etc.. [17:41:33] Luxo, it's breaking ACC though. We need that tool. [17:42:11] does anyone know where the documentation is on oauth? I don't want to sound lazy, but my search didn't immediately pull something up, and if someone else knows where it is, why go searching? :) [17:42:12] Magog_the_Ogre_: Did you try using TUSC, just replacing http://tools.wikimedia.de/~magnus/ with http://tools.wmflabs.org/tusc/? [17:42:57] https://www.mediawiki.org/wiki/Extension:OAuth#Using_OAuth [17:43:12] https://www.mediawiki.org/wiki/OAuth = disambig [17:43:36] Magog_the_Ogre_: There are some instructions at https://www.mediawiki.org/wiki/Extension:OAuth#Using_OAuth, and there's also http://tools.wmflabs.org/oauth-hello-world/ and https://www.mediawiki.org/wiki/User:CSteipp/OAuth_Training_Dec2013 [17:44:14] Magog_the_Ogre_: And you can ask me if you have questions, or csteipp if he happens to be around. [17:45:03] Coren|airport: >The program 'jpegtran' is currently not installed. To run 'jpegtran' please ask your administrator to install the package 'libjpeg-turbo-progs'< if you have some time left, I would be happy :-) [17:45:16] Cyberpower678: what means 'ACC'? [17:45:30] Account Creation Assistance. [17:45:43] It's been a highly depended on tool. [17:45:44] Luxo: File a request in bugzilla, so it doesn't get lost. https://bugzilla.wikimedia.org/enter_bug.cgi?product=Wikimedia%20Labs&component=tools&format=guided [17:46:09] anomie: ok thx [17:47:17] Luxo, ^^^^ [17:47:43] Cyberpower678: why does guc break it? [17:47:57] just press the button [17:48:46] huh, because we have a button that is supposed to fill out the link for and take us straight to the query. Instead, it takes us to a request page. [17:49:28] Making it more work. I know that sounds lazy but if you handle 20 requests at a time, that's 20 extra clicks needing to be done. [17:50:24] Luxo: ^ [17:51:07] But we might be dropping guc altogethor. [17:51:21] And replacing it with something else. [17:51:23] Oh? [17:51:51] I'm working on a replacement, since that tool takes a while to get results. [17:53:08] Will it just be for ACC or for all? [17:55:20] Cyberpower678: the main problem is, that it takes its time to connect to 7 servers and more than 400 databases. It would be faster if it would just search the most used wikis, e.g. the top 200. [17:55:52] Have you considered using union? [17:58:01] Luxo, try using union. There are significant speed improvements. [17:58:21] And it's more like 852 wikis [17:59:23] Cyberpower678: yeah don't know the number. what's union? [17:59:34] It's faster. [17:59:49] e.g. 106 vs 19 seconds [17:59:49] Luxo, combining multiple select statements into one. [18:00:18] Essentially, you connect to a slice and ping all of the DBs simulataneously.' [18:00:48] I retrieved results from 815 wikis in 2.745 seconds. [18:01:20] It does require some significant restructuring of code though. [18:01:33] not sure if it's worth it [18:01:41] Blame Hoo man if it's actually slower. [18:02:05] I got faster results, so I'm going to try and finish the new code structure. [18:03:37] It's good to bypass network latency... but it can be horrible to manage in the application :P [18:13:49] Cyberpower678: I'll try it [18:15:07] Luxo, let me know how that works. [18:30:41] I need an SQL expert. [19:19:15] Cyberpower678: good tip. much, much faster! [19:19:35] Can somoene look at this API call and tell me why it returns the wrong results? [19:19:35] Luxo, you already have it running? [19:19:37] https://en.wikipedia.org/w/api.php?action=query&list=usercontribs&format=json&uclimit=10&ucuser=Loginnigol&titles=Foobar [19:20:01] I thought if you sepcied "titles" on the API it will only return results for that article [19:20:02] Cyberpower678: http://tools.wmflabs.org/guc/test/index.php [19:20:28] FutureTense: see api.php's doc [19:20:33] It isn't a uc* param [19:20:37] Luxo, nice [19:20:49] hmm, its on the sandbox page [19:20:51] See https://en.wikipedia.org/w/api.php under "* list=usercontribs (uc) *" part [19:20:52] maybe in error [19:21:40] Cyberpower678: seems to work, I'll update the live version... [19:21:51] whats the diff betwen a param and prop on the call then? [19:22:12] hello [19:22:13] oh, the prop specifies what you want back?? [19:22:22] Luxo can I speak to you for a moment [19:22:50] Withoutaname: yes of corse :-) [19:23:10] Luxo, can you re-enable the use of get? [19:23:38] I really appreciate your crosswiki IP checker tool, and I was wondering if you can give some of the wikis a little more time to transition over to wmflabs [19:23:51] I'm aware of the impending toolserver deprecation however [19:24:15] there's currently a notice saying only two days left to switch over and I noticed that only a day ago [19:25:49] Withoutaname: I think you are speaking about the redirect from the old tool. It's not me shutting down the toolserver. I can't do anything, the accounts there expiring at the 06.01. [19:28:09] Yeah they said they'd leave toolserver up for awhile though [19:28:14] to make the transition smoother [19:28:23] I'd be thinking you can give us a week or so to reconfigure [19:28:49] or was it set to autoexpire after a certain date? [19:29:51] how long will the redirect stay up [19:30:01] ill give notice to the relevant wikis now [19:31:36] Withoutaname: The only information I have is that all accounts will expire at this date. I did the command to renew my account, but I don't know if they will expire them anyway. The redirect works as long as the toolserver is up. [19:32:37] Ask a toolserver administrator how they will handle it. [19:34:42] Hi again Withoutaname. [19:35:01] If it's renewed toolserver will remain running. [19:35:15] Toolserver will die tomorrow, or the day after. [19:35:19] I think Monday. [19:35:28] huh, no it won't [19:35:33] Really? [19:35:45] It's not dying for a while. [19:35:57] I'm hearing some conflicting reports [19:35:57] the accounts will be disabled though [19:35:59] right? [19:36:12] luxo's tool says its a redirect and will be deprecated in 2 days [19:36:12] Well, it is now tha DaB. has left, but it won't be shut down. [19:36:28] yet toolserver will remain for a while [19:36:30] which is it [19:36:39] https://meta.wikimedia.org/wiki/Future_of_Toolserver [19:36:47] "but on 2013-11-11 the admins wrote all users encouraging them to delete their data and promising to disable all accounts (and hence tools) on 2014-01-06" [19:37:02] Today is 2014-01-04 [19:37:23] yes that was the notice I got [19:37:38] Withoutaname: my tool says that because that's the only information I have. Maybe they will not shut down. then the redirect will stay alive. [19:37:52] alright [19:38:23] you probably got that from the page linked up there as well, it's understandable [19:39:56] so only parts of toolserver are being deprecated on that date, is this correct? [19:40:29] I suggested in #mediawiki to reedy that [[tools:]] wikilinks be changed to point to wmflabs, but he said it'll break a lot of links [19:40:40] Withoutaname: it will break a lot of links [19:40:45] I know they set the accounts to expire on the 6th. But as far as I am concerned you can still renew and I did. [19:40:51] I added the [[toollabs:]] prefix to the interwiki map though [19:41:01] that helps a lot [19:41:13] you should give notice on meta's centralnotice [19:41:25] I could do that, but not sure I should [19:41:43] Add it to [[m:CentralNotice/Calendar]] and [[m:RFH]] and I'll consider it [19:42:07] I think global message... erm "massmessage" (thanks legoktm) would be better [19:42:19] otherwise I'd have to go to every wiki and ask them to change luxo's tool after 2014-01-06 [19:42:24] massmessage sounds good [19:42:32] A bot could do that :P [19:42:40] one with editinterface rights [19:43:23] http://lists.wikimedia.org/pipermail/toolserver-l/2013-November/006379.html [19:43:40] "The toolserver will run until June 30th 2014." [19:43:47] It would be cool if tools:$1 redirected to tool labs, and had a special "fix" for $1 beginning with "~" that forwarded to a similar tool on labs (if it exists) or to toolserver [19:44:17] because TS links are like tool:~foo/*, but tool labs is like toollabs:foo/* [19:44:28] sorry for bold [19:44:48] bold? [19:45:14] *xyz* is bold at least in ChatZilla. like this *xyz* [19:45:51] The only bold I say is the last *xyz* [19:46:37] the problem is that most TS links are someting like ~/user/tool and most Labs links are just /tool, since people are supposed to separate projects by tool rather than user [19:47:06] Yes. [19:47:49] So I think it would be good if tools: went to ToolLabs for links not starting with "~", and for links starting with "~" either went to toolserver or to a similar tool on labs [19:48:15] (like making ~luxo contribs go to guc) [19:49:22] thats's what redirects are for [19:49:31] how bout "Please examine any [[tools:]] links and change them to [[toollabs:]] if you can find an appropriate existing tool on wmflabs [19:49:46] But if toolserver is down, we can't have HTTP redirects from there [19:50:15] huh: Accunts are being expired to "weed out" the unused/unmaintained ones; but the toolserver itself remains for another 6 months. [19:50:16] ^ that, ~luxo is currently redirecting to guc but it says it will be deleted in a couple days [19:50:33] huh: The redirectes will remain valid indefinitely. [19:50:37] Coren: Ah! [19:50:39] Good. [19:50:41] alright [19:50:43] good [19:50:49] Then Luxo shouldn't delete the redirect [19:51:06] I can do a http redirect again... [19:51:21] Even when the hardware is decomissioned, someone else (maybe WMCH, maybe WMF) will keep the toolserver.org domain and keep a webserver up to maintain the redirects. [19:51:37] Fantastic. [19:52:15] Some of those links are /all over/; trying to change them would be a nightmare at best. Much easier to just keep the redirects live. [19:52:17] Thanks for all your work Luxo [19:52:30] I just use your tool as an example because its the one I use the most [19:52:40] it's not to blame you or anything [19:52:57] As someone who monitors changes on small wikis and cross-wiki vandalism, it is immensely useful [19:55:03] Withoutaname: your direct redirect is back ;) [19:55:27] thanks [20:16:00] Hello. [20:16:53] Anyone here good with jstart or submitting jobs for continuous run? [20:23:54] Coren: ^^^^^ [20:24:13] JohnLewis: What's up? [20:25:01] We are trying to submit a PHP job. [20:25:20] We get errors. [20:25:31] /var/spool/gridengine/execd/tools-exec-08/job_scripts/2072510: line 4: 26748 Aborted (core dumped) /data/project/irc-wmt/bots/masters/bot-operator.php [20:25:46] libgcc_s.so.1 must be installed for pthread_cancel to work [20:28:10] Coren: ^ [20:28:34] huh: That's in the FAQ. You need moar memory. :-) [20:29:03] https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help#Why_am_I_getting_errors_about_libgcc_s.so.1_must_be_installed_for_pthread_cancel_to_work.3F [20:30:40] D'oh, should have RFTM [20:30:50] thanks Coren, and sorry for not looking there first [20:31:20] No worries. :-) [20:31:24] Coren: maybe those errors can be caught in some way, with a note added to the .err? [20:32:06] not sure how, though, because it would need to be at the qsub level -- any wrapper script would also get killed [20:33:41] valhallasw: Why? It's a kind of rite for - almost - every php dude :P [20:34:02] Hedonil: I'm a big fan of self-explanatory systems. [20:34:24] valhallasw: me too, but I like funny things as well ;) [20:34:35] anomie, what would an error code like "Error Code: 1142. SELECT command denied to user 'u3045'@'10.4.0.220' for table 'ipblocks_ipindex' [20:34:35] " tell you? [20:34:44] Coren: wrong database [20:34:57] er, Cyberpower678 [20:34:58] >_< [20:35:04] howso? [20:35:14] Cyberpower678: Which database? [20:35:27] anomie, ipblocks_ipindex [20:35:38] Cyberpower678: database, not table. [20:35:44] Cyberpower678: i.e. which wiki [20:35:44] sorry. [20:35:57] I meant abwiki and a bunch of others. [20:36:42] Cyberpower678: abwiki or abwiki_p? [20:36:51] MariaDB [abwiki_p]> select * from abwiki.ipblocks_ipindex limit 1; [20:36:52] ERROR 1142 (42000): SELECT command denied to user 'u1092'@'10.4.0.220' for table 'ipblocks_ipindex' [20:37:04] MariaDB [abwiki_p]> select * from abwiki_p.ipblocks_ipindex limit 1\G [20:37:05] *************************** 1. row *************************** [20:37:05] abwiki_p [20:38:09] Oops hold on. [20:38:29] Yeah, I'm actually asking that question for a reason ;-) [20:39:06] There's a bug... [20:39:08] Thank you. [20:39:17] You're welcome :-) [20:39:34] (again, a better error message would be *awesome* for this) [20:40:24] Hmm. You can "show tables" to see that ipblocks_ipindex doesn't exist in 'abwiki', but the select gives a permission error rather than a table-does-not-exist error. [20:40:27] Go MySQL. [20:40:31] Why are there DBs without _p ? [20:40:45] huh: Those are the DBs that have the real tables. [20:40:56] Then the _p only has views that access those tables. [20:42:36] And in MySQL, it's easy to grant permissions to "every table in any database ending in _p", instead of having to maintain permissions for every database individually. [20:45:41] Okay. Thanks for the info. [22:51:12] hello [22:51:20] Anyone here know about sockets and PHP? [22:52:31] Please, someone [22:52:55] JackPotte, ^ [22:53:03] hello again Cyberpower678 [22:53:06] Hi [22:53:23] JackPotte, do you think you can help huh out? [22:54:09] I know PHPmailer, fopen and so on, but not the sockets function yet [22:54:14] JackPotte: let's discuss in #wmt -- you remember that channel, right? We're going to revive it but having problems with PHP and sockets [22:54:36] Maybe you can still help. [22:54:53] yes I was connected on it before Quentinv57 resined [22:55:14] He's back, and we've been working on bringing the bots back. [22:55:24] good new [22:55:27] +s [22:55:29] * huh also used the channel a few years ago [23:23:53]