| cpaelzer | good morning | 06:28 |
|---|---|---|
| lordievader | Good morning | 07:13 |
| ak5 | hi, I ws upgrading mysql when my ssh crapped out (wasn't in tmux lel) and now I am having issues with it not being configured, tried a bunch of things like `dpkg --reconfigure -a` and removing and reinstalling it... any ideas? https://paste.ubuntu.com/p/QN2v4RvZjR/ | 08:21 |
| rbasak | ak5: could you edit /var/lib/dpkg/info/mysql-server-5.7.postinst please? Where it says "set -e", make it "set -ex". Then attempt "dpkg --configure mysql-server-5.7" again and pastebin the result. The change will show us where it's failing, and hopefully then I'll have a better idea of what's going on. | 08:33 |
| ak5 | will do | 08:34 |
| ak5 | rbasak: https://paste.ubuntu.com/p/vPdY7Zf9tS/ | 09:02 |
| ak5 | sorry that took a while | 09:02 |
| rbasak | Looking | 09:05 |
| rbasak | Still looking | 09:12 |
| rbasak | ak5: I can't make sense of this. | 09:23 |
| rbasak | ak5: please could you also pastebin /var/lib/dpkg/info/mysql-server-5.7.postinst ? I'd like to check I'm comparing against the right thing | 09:23 |
| rbasak | Oh | 09:25 |
| rbasak | I'm comparing against the wrong thing | 09:25 |
| rbasak | OK I've made sense of that pastebin now | 09:27 |
| rbasak | ak5: can you check /var/log/mysql/error.log please? | 09:27 |
| ak5 | checking | 09:36 |
| ak5 | rbasak: https://paste.ubuntu.com/p/4XktNmTjsn/ | 09:37 |
| ak5 | rbasak: sorry I dropped and didn't notice :( | 10:21 |
| ak5 | It's very strange that uninstall and reinstall doesn't work | 10:22 |
| ak5 | is it a dpkg issue? | 10:22 |
| rbasak | ak5: do you have another mysqld process running? | 10:42 |
| rbasak | It's not a dpkg issue | 10:42 |
| rbasak | It's something up with your MySQL installation | 10:42 |
| ahasenack | rbasak: hi, good morning. I updated https://code.launchpad.net/~ahasenack/ubuntu/+source/ubuntu-advantage-tools/+git/ubuntu-advantage-tools/+merge/337213 | 11:12 |
| ahasenack | if you could please take another look | 11:12 |
| ahasenack | commits are on top, no rebase | 11:12 |
| ak5 | rbasak: ok I am going to nuke everything mysql related and try again | 11:12 |
| ak5 | I am not using mysqld anywhere else | 11:13 |
| rbasak | ak5: please make a note of the steps you take. If it happens again and we know exactly what you did, that'll make it much easier to understand what is going on, identify a bug if there is one, etc. | 11:20 |
| rbasak | ahasenack: ack | 11:21 |
| ahasenack | thanks | 11:23 |
| ahasenack | rbasak: it also looks like the zstd packages haven't migrated to proposed | 11:23 |
| rbasak | ahasenack: stuck in binNEW I expect. Needs an AA? | 11:23 |
| rbasak | ahasenack: yeah: https://launchpad.net/ubuntu/xenial/+queue?queue_state=0&queue_text= | 11:24 |
| rbasak | ahasenack: does the cronjob really need to be hourly? | 11:25 |
| rbasak | Nothing else is hourly by default. | 11:25 |
| ahasenack | rbasak: the livepatch daemon checks in hourly with the livepatch server | 11:26 |
| ahasenack | that's why I used hourly | 11:26 |
| rbasak | It's not running by default though presuably? | 11:26 |
| ahasenack | no, it's not | 11:26 |
| ahasenack | note that "ua status" doesn't ping the network | 11:27 |
| ahasenack | rbasak: I pinged #ubuntu-devel about zstd | 11:34 |
| ahasenack | rbasak: I'll also ping them again about sssd stuck in excuses | 11:35 |
| ahasenack | I have a file I can just copy & paste by now :) | 11:35 |
| ahasenack | hm, I seem to have misplaced that file | 11:36 |
| rbasak | ahasenack: when you need an AA, #ubuntu-release is where people tend to ask | 11:36 |
| ahasenack | I did ask there first (sssd) iirc | 11:37 |
| ahasenack | found it | 11:39 |
| rbasak | ahasenack: you're still making a blocking call to $UA_STATUS (which is bash) on first run, no? | 12:05 |
| rbasak | ahasenack: AIUI, 50-motd-news doesn't do that. It exits if the cache isn't present if run from PAM. | 12:05 |
| ahasenack | rbasak: on the very first one, yes, if there is no cache | 12:05 |
| ahasenack | you rather we just exit if there is no cache? | 12:06 |
| ahasenack | note that the first call also creates the cache | 12:06 |
| rbasak | I'd rather we not have bash ever run on the critical path | 12:06 |
| rbasak | The first login is still a critical path | 12:06 |
| ahasenack | ok | 12:06 |
| ahasenack | I'll fix that | 12:06 |
| ahasenack | rbasak: this update will take a bit longer, as it breaks a lot of tests | 12:31 |
| jamespage | coreycb: do you think we should do the same thing re boost headers in percona-xtrabackup as I've done in pxc 5.7 | 13:24 |
| jamespage | i.e just repack the upstream tarball with the required headers | 13:24 |
| coreycb | jamespage: i would say yes if xtrabackup has a hard dependency on a specific version of boost | 13:25 |
| coreycb | jamespage: and it's not in distro | 13:25 |
| jamespage | coreycb: same with mysql and friends | 13:26 |
| jamespage | coreycb: I've pushed my bundle-boost.sh changes to the jp-review-fixes branch for pxc57 | 13:26 |
| coreycb | jamespage: ok taking a look | 13:27 |
| Isla_de_Muerte | Guys any ideas why the First Byte is that shtty now with SSL https://www.webpagetest.org/result/180216_AD_02d43cf636c0cd19f17ef216943bdefb/ ? I've checked a lot of stuff, tried to fix some others but it seems like it sucks.. | 13:28 |
| jamespage | coreycb: I'm having a tinker with switching to gcc-7 as well | 13:28 |
| lordievader | Isla_de_Muerte: What kind of setup are you using? (I'm getting A on that test for my own website) | 13:37 |
| coreycb | jamespage: that seems better, creates a single orig tarball now? | 13:38 |
| jamespage | coreycb: yes allowing us to using gbp + pristine-tar again | 13:38 |
| coreycb | jamespage: cool. maybe we can do that for horizon sometime. | 13:38 |
| lordievader | Isla_de_Muerte: Looking at the explanation of that test I barely made it 389/400 ms. | 13:39 |
| Isla_de_Muerte | lordievader, Ubuntu 14.04, Apache 2.4.7, OpenSSL 1.0.1f, created the CA through webmin with LetsEncrypt | 13:39 |
| Isla_de_Muerte | Without SSL that site was full A :/ | 13:39 |
| lordievader | Isla_de_Muerte: The full explanation of the first byte time: The target time is the time needed for the DNS, socket and SSL negotiations + 100ms. A single letter grade will be deducted for every 100ms beyond the target. | 13:40 |
| lordievader | Isla_de_Muerte: Are you forcing a cipher for which you do not have hardware acceleration? | 13:41 |
| Isla_de_Muerte | lordievader, I've made the cipher changes based on ssllabs test, didn't really check them out tbh | 13:42 |
| lordievader | Isla_de_Muerte: Does your webserver prefer an AES cipher and does your cpu support AES? | 13:43 |
| Isla_de_Muerte | lordievader, hmm the server is using Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz let me check it out | 13:46 |
| lordievader | Oh, that supports AES. | 13:46 |
| Isla_de_Muerte | Yeah it does according to cpuinfo :P | 13:47 |
| patdk-lap | well, what cipher is being used? | 13:51 |
| patdk-lap | aes is NOT the issue | 13:51 |
| rbasak | ahasenack: in apt.sh, if you're using --force-confold you should probably also use the matching ucf flag | 13:51 |
| rbasak | It's an environment variable IIRC | 13:51 |
| patdk-lap | doesn't matter if you had no hardware support or not, AES it not the problem | 13:51 |
| ahasenack | rbasak: no idea what that is | 13:51 |
| Isla_de_Muerte | patdk-lap, isn't that dependable on the browser/etc ? | 13:52 |
| Isla_de_Muerte | Or I have no idea what I am saying | 13:52 |
| patdk-lap | depends on the browser and the server | 13:52 |
| ahasenack | rbasak: is this new in this version, or was the same code just moved to the apt.sh "module"? | 13:52 |
| patdk-lap | but if you don't know what is being used, how can you fix it? | 13:52 |
| rbasak | ahasenack: it might be in my diff because it moved | 13:52 |
| patdk-lap | how do you even know what is wrong | 13:52 |
| rbasak | ahasenack: to be clear, this isn't a review comment. | 13:53 |
| rbasak | Just something that might want fixing as it might bite some time | 13:53 |
| patdk-lap | lordievader, please, the bulk data cipher is not the problem | 13:53 |
| Isla_de_Muerte | patdk-lap, like I previously said I followed ssllabs and editing the apache confi file to the following: | 13:53 |
| Isla_de_Muerte | SSLProtocol ALL -SSLv2 -SSLv3 | 13:53 |
| Isla_de_Muerte | SSLHonorCipherOrder on | 13:53 |
| Isla_de_Muerte | SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS +RC4 RC4" | 13:53 |
| ahasenack | rbasak: worth noting down so it's not forgotten | 13:53 |
| rbasak | ahasenack: yeah that's why I mentioned it :) | 13:53 |
| ahasenack | rbasak: feel free to add it as a review comment, or a bug to be fixed | 13:53 |
| patdk-lap | Isla_de_Muerte, so that is what you perfer, but WHAT WAS USED? | 13:54 |
| patdk-lap | and following ssllabs is great, for SECURITY, not speed | 13:54 |
| rbasak | ahasenack: the shell code is good quality, but its structure means that it's hard to understand the packaging implications of the entire package without reading all the shell code | 13:54 |
| ahasenack | lots of indirections indeed | 13:54 |
| patdk-lap | though, your not following ssllabs at all, cause you have rc4 enabled? | 13:54 |
| lordievader | patdk-lap: Then please explain what the problem is. | 13:55 |
| Isla_de_Muerte | patdk-lap, sorry, I really do not know how I can see that. I've got rc4 enabled for older browsers | 13:55 |
| ahasenack | rbasak: thanks for the careful review | 13:55 |
| patdk-lap | lordievader, pki time | 13:55 |
| patdk-lap | as it always is | 13:55 |
| patdk-lap | if it was aes that was the issue, the download would take longer, but setup time would remain the same | 13:56 |
| patdk-lap | aes is NOT used during session setup | 13:56 |
| lordievader | Any way to reduce the delay? Or is it a simple, heavy calculation, takes time, type of thing? | 13:57 |
| patdk-lap | it's a heavy calculation | 13:57 |
| lordievader | Ok, sorry for mentioning AES -.- | 13:57 |
| patdk-lap | just change it to use something not so heavy | 13:57 |
| patdk-lap | since we don't know what is being used, since he likely didn't log it | 13:57 |
| patdk-lap | we have no idea what to change from and to | 13:57 |
| lordievader | Isla_de_Muerte: ^ | 13:57 |
| patdk-lap | DHE is heavy as crap | 13:57 |
| patdk-lap | https://wiki.mozilla.org/Security/Server_Side_TLS | 13:58 |
| ahasenack | rbasak: got the tests fixed finally | 13:58 |
| ahasenack | Ran 97 tests in 7.776s | 13:58 |
| patdk-lap | mozilla balanaces speed first, over pure best encryption for their recommendations | 13:58 |
| ahasenack | but I need some small refactoring now to avoid code duplication | 13:58 |
| Isla_de_Muerte | Thanks for the info and help guys. I'll look how to log this, figure out what is being used and change it | 13:59 |
| patdk-lap | most systems can do around 80 RSA transactions a second | 13:59 |
| patdk-lap | that means 80 connections a second :) | 14:00 |
| patdk-lap | unless you have session reuse (tickets/tokens) and the user previously visited your site | 14:00 |
| sforshee | sbeattie, jjohansen: we keep having test errors on the apparmor config options as we move between having and not having stacking patches, what do you guys think of making the test something like this (unstested)? http://paste.ubuntu.com/p/WYPvYFQVbM/ | 14:00 |
| patdk-lap | but that isn't what your solving for here | 14:00 |
| patdk-lap | and if your like mine | 14:05 |
| patdk-lap | it will be 0.2 seconds fast | 14:05 |
| patdk-lap | but considering yours is 0.4, you will only resolve 0.2 seconds of your issue | 14:05 |
| patdk-lap | the rest is just you have so many files | 14:05 |
| patdk-lap | so many little images is the issue | 14:06 |
| sforshee | sbeattie, jjohansen: or rather like this - http://paste.ubuntu.com/p/Z53PktVDzh/ | 14:07 |
| Neo1 | postfix is MTA agent that transport mail form MUA to other MTA or to local mail inbox | 14:12 |
| Neo1 | with SMTP | 14:12 |
| Neo1 | relay them to other MTA | 14:13 |
| Neo1 | after this his work is done | 14:13 |
| Neo1 | after transfering or delivering the message postfix job ends | 14:13 |
| Neo1 | other servers are responsible for getting message to the end users | 14:14 |
| Neo1 | firewall is not an application... this is concept... | 14:17 |
| Neo1 | Email is the largest network on the planet | 14:19 |
| coreycb | jamespage: finally got congress and magnum uploaded, they were fun. | 15:40 |
| jjohansen | sforshee: I'm fine with that | 16:32 |
| Isla_de_Muerte | patdk-lap, DHE it is | 16:37 |
| patdk-lap | try using one from the mozilla link I posted | 16:38 |
| patdk-lap | hopefully that will drop DHE down the list some | 16:38 |
| patdk-lap | odd though, cause ssllabs claims you should be using ecdhe and not dhe with your current config :( | 16:39 |
| Isla_de_Muerte | I don't even have dhe on my config file tbh | 16:41 |
| patdk-lap | also remember, your first hit is a redirect to ssl | 16:41 |
| patdk-lap | and that is a good 0.3s delay you cannot fix | 16:41 |
| patdk-lap | it's in your config | 16:41 |
| patdk-lap | cause you don't have !DHE | 16:41 |
| Isla_de_Muerte | Oh | 16:41 |
| patdk-lap | and it's enabled by default | 16:41 |
| Isla_de_Muerte | Didn't know that | 16:42 |
| Isla_de_Muerte | Yeah I know about the redirect, was comparing to google (lol) which takes way less time | 16:42 |
| Isla_de_Muerte | But I doubt I can lower that part | 16:42 |
| patdk-lap | where is the redirect happening | 16:42 |
| patdk-lap | hopefully in the webserver, aka, apache/nginx/... | 16:42 |
| patdk-lap | and not via php | 16:43 |
| Isla_de_Muerte | htaccess | 16:43 |
| patdk-lap | ok | 16:43 |
| ahasenack | rbasak: latest fix (don't generate the cache at login, ever) pushed | 16:46 |
| ahasenack | thanks | 16:46 |
| sdeziel | Isla_de_Muerte: the HTTP->HTTPS redirection can be reduced with HSTS | 16:47 |
| sdeziel | Isla_de_Muerte: but yeah, on the first visit there is a latency hit due to the redirection | 16:47 |
| Isla_de_Muerte | sdeziel, ty I will look it up! | 16:48 |
| patdk-lap | sdeziel, not for a first time visitor | 16:48 |
| patdk-lap | so it wont help in this specific test case no, returning users, sure | 16:48 |
| sdeziel | patdk-lap: indeed, for that there is HSTS preload but that's a different can of worms ;) | 16:50 |
| patdk-lap | yep | 16:50 |
| patdk-lap | saw someone that did preload | 16:51 |
| patdk-lap | the sample hsts they lifted from a tutorial had the preload tag in it | 16:51 |
| patdk-lap | and it was added into all the browsers | 16:51 |
| patdk-lap | and he couldn't figure out why non-http wasn't working | 16:51 |
| sdeziel | wow, I thought you needed to opt-in in addition to having the flag | 16:52 |
| patdk-lap | nope, the prelog tag is the optn flag | 16:52 |
| patdk-lap | preload | 16:52 |
| patdk-lap | now, google doesn't *automatically find* your website | 16:52 |
| patdk-lap | but on a google crawl of it, or if you submit the website, it will get added | 16:52 |
| sdeziel | https://hstspreload.org/: "If a site sends the preload directive in an HSTS header, it is considered to be requesting inclusion in the preload list and may be submitted via the form on this site." | 16:53 |
| sdeziel | not 100% clear to me if the form submission is needed or not ;) | 16:53 |
| patdk-lap | it's not | 16:53 |
| patdk-lap | a google crawl will also get it added | 16:53 |
| sdeziel | good to know. Fortunately, there is a removal form but it must take a while to percolate to all the users | 16:54 |
| patdk-lap | very long, next release, everyone to upgrade, ... | 16:54 |
| Isla_de_Muerte | Cipher : DHE-RSA-AES256-SHA Hmm !DHE doesn't change a thing | 16:54 |
| patdk-lap | didn't do something right | 16:54 |
| patdk-lap | oh, it doesn't call it DHE in openssl but DH | 16:56 |
| patdk-lap | so you have ot use !DH | 16:56 |
| Isla_de_Muerte | Cipher : RC4-SHA /facepalm | 16:57 |
| Isla_de_Muerte | This is supposed to be last resort fml.. | 16:58 |
| patdk-lap | I don't get why your selection of chrome is using such old ciphers | 16:58 |
| sdeziel | Isla_de_Muerte: your cipher list looks good from here: https://paste.ubuntu.com/p/HQH2KDVbtf/ | 17:01 |
| Isla_de_Muerte | sdeziel, hmm first byte is still the same -.-' | 17:03 |
| patdk-lap | ECDHE-RSA-AES128-GCM-SHA256 | 17:04 |
| patdk-lap | that is what webpagetest is doing with me, using the same settings as you | 17:04 |
| patdk-lap | well, not good at all | 17:04 |
| patdk-lap | but very secure, and if you don't support ecdha, well, you are left to using crap | 17:04 |
| patdk-lap | Isla_de_Muerte, use one of the ones from the mozilla page I posted | 17:05 |
| Isla_de_Muerte | patdk-lap, will try that now | 17:05 |
| patdk-lap | the backwards compatable/old clients one will get what you want | 17:05 |
| patdk-lap | but will keep it as secure as possible for those old clients | 17:06 |
| sdeziel | patdk-lap: what's wrong performance-wise with ECDHE-RSA-AES128-GCM-SHA256 ? | 17:08 |
| patdk-lap | the fact it isn't using it? | 17:08 |
| patdk-lap | but using DHE-RSA instead | 17:09 |
| patdk-lap | ECDHE is much faster than DHE | 17:09 |
| patdk-lap | for me, it's using ECDHE, but for him it isn't | 17:09 |
| patdk-lap | no idea why it's not | 17:09 |
| sdeziel | AFAICT, the IP I poked didn't even offerred a DHE cipher-suite | 17:10 |
| sdeziel | Isla_de_Muerte: is there a pool of server behind that name? | 17:10 |
| Isla_de_Muerte | sdeziel, I have disabled DHE atm, there are a few domains on that IP | 17:11 |
| patdk-lap | ssllabs said it did DHE when I tested it like an hour ago | 17:11 |
| sdeziel | Isla_de_Muerte: tuning ECDHE vs DHE will only shrink the pink'ish line in those waterfal | 17:13 |
| patdk-lap | yep | 17:16 |
| sdeziel | Isla_de_Muerte: with Firefox, I get TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 which means this part is good | 17:16 |
| patdk-lap | the only thing you can do, except to physically reloate your server | 17:16 |
| Isla_de_Muerte | sdeziel, I just got the same with FF 57 now | 17:16 |
| sdeziel | from here, TLS setup takes ~120ms | 17:17 |
| sdeziel | and I seem to be 100ms away from the box | 17:17 |
| sdeziel | (well, 100ms RTT) | 17:17 |
| patdk-lap | I'm just concerned with the crazy cipher list he had, it's not quick across the board | 17:17 |
| patdk-lap | and that should fixup that *benchmark* website | 17:17 |
| sdeziel | Isla_de_Muerte: do you have Keepalive enabled? | 17:18 |
| patdk-lap | sdeziel, did you flush your ssl tickets/tokens? | 17:18 |
| patdk-lap | sdeziel, he has to | 17:18 |
| Isla_de_Muerte | Yes, keepalive is on | 17:18 |
| sdeziel | patdk-lap: yep, fresh private instance | 17:18 |
| patdk-lap | I don't think a private instance resolved ticket caching | 17:19 |
| Isla_de_Muerte | patdk-lap, tried the Mozilla recommendations, got worse results, reactivated previous ones for now again | 17:19 |
| sdeziel | Isla_de_Muerte: after 3-4 clicks, I saw a new TLS connection being established so you might want to bump the number of requests you accept as keepalive | 17:20 |
| patdk-lap | link? | 17:20 |
| Isla_de_Muerte | https://www.webpagetest.org/result/180216_DR_55b37aeab2368a96af92d1f5ff3f7021/ | 17:20 |
| Isla_de_Muerte | sdeziel, I am restarting apache the last X minutes, maybe that;s why | 17:20 |
| patdk-lap | isla, don't take that website as 100% proof | 17:21 |
| patdk-lap | their systems run shared, and is affected greatly by other load | 17:21 |
| sdeziel | yeah, I find the dev tools in browser to be good enough most of the time | 17:21 |
| patdk-lap | I can run the same test 10 times and get highly different results | 17:21 |
| Isla_de_Muerte | patdk-lap, yeah I don't I just find it weird that before the SSL I was getting good results on that, pingdom etc and now I am ~1-2secs extra | 17:21 |
| patdk-lap | well, in this case it says your redirect to https took a long time to download | 17:22 |
| patdk-lap | but if you notice the pink part got a LOT better | 17:22 |
| patdk-lap | down to .2 instead of .4 | 17:22 |
| patdk-lap | so don't change the ssl ciphers back | 17:22 |
| patdk-lap | as that improved | 17:22 |
| patdk-lap | all the pink bars are shorter, except that last one | 17:22 |
| patdk-lap | and that is likely due to other issue in their testing | 17:23 |
| sdeziel | Isla_de_Muerte: have you considered fronting the site with a MITM like Cloudflare an such? | 17:23 |
| sdeziel | if you don't care about the privacy implication, this is usually a magic wand ;) | 17:24 |
| Isla_de_Muerte | patdk-lap, just for reference old cipher conf: https://tools.pingdom.com/#!/bXnlmN/http://www.seedboxcenter.com | 17:24 |
| Isla_de_Muerte | new one: https://tools.pingdom.com/#!/d2XAdu/http://www.seedboxcenter.com | 17:24 |
| patdk-lap | so old is 1.51, and new is 1.42 | 17:25 |
| Isla_de_Muerte | I am mainly focusing on the 2nd line/bar, maybe that is just stupid | 17:26 |
| patdk-lap | ssl on new is 176, and ssl on old is 188 | 17:26 |
| Isla_de_Muerte | sdeziel, I am just trying to figure out if I am doing something wrong atm :P It might be normal to take that long dunno | 17:26 |
| patdk-lap | it's the only thing you can do | 17:26 |
| patdk-lap | you can't change how long dns takes, and it's already fast | 17:26 |
| patdk-lap | you cannot change how long it takes to connect to your server, unless you use a cdn | 17:27 |
| patdk-lap | so you can only do two things | 17:27 |
| patdk-lap | make ssl faster | 17:27 |
| patdk-lap | make page deliever/generation faster | 17:27 |
| patdk-lap | oh, what *might* help | 17:27 |
| Isla_de_Muerte | Last link before SSL: https://www.webpagetest.org/result/180208_2W_13870833ff7ddff2762c99b657acd43c/1/details/#waterfall_view_step1 | 17:27 |
| patdk-lap | is tuning your tcp stack | 17:27 |
| patdk-lap | dunno what kernel your using | 17:27 |
| patdk-lap | yes, but without ssl, your not doing a redirect, so no extra 0.5sec there | 17:28 |
| Isla_de_Muerte | True that | 17:28 |
| patdk-lap | and you have no ssl setup time, so no .2 to .4 seconds | 17:28 |
| sdeziel | realistically, once you are settled on HTTPS with HSTS and Google noticed, every legit client will likely connect with HTTPS right from the start so that redirection problem will only slowdown bots | 17:30 |
| patdk-lap | ip route | while read p; do ip route change $p initcwnd 45 initrwnd 45; done | 17:31 |
| patdk-lap | run that on your server, and retest :) | 17:32 |
| patdk-lap | actually this also | 17:32 |
| patdk-lap | sysctl net.ipv4.tcp_slow_start_after_idle=0 | 17:32 |
| patdk-lap | that should help it send your certificates faster for ssl | 17:32 |
| patdk-lap | but not sure how much that is affecting you | 17:32 |
| patdk-lap | but I have that set on all my servers so | 17:33 |
| patdk-lap | added as an ifup.d script | 17:33 |
| patdk-lap | helps for small tcp sessions | 17:33 |
| patdk-lap | but now we are really getting over it, for tuning things :) | 17:34 |
| sdeziel | Isla_de_Muerte: OCSP stapling would improve connection time too but it's a pain to configure | 17:34 |
| patdk-lap | isn't that enabled by default on trusty+ | 17:35 |
| patdk-lap | and no, it won't matter anymore | 17:35 |
| patdk-lap | chrome no longer does oscp checks | 17:35 |
| patdk-lap | and firefox never defaulted to doing them | 17:35 |
| sdeziel | patdk-lap: no, not enabled by default | 17:35 |
| patdk-lap | no, chrome removed support | 17:36 |
| sdeziel | patdk-lap: hmm, looks like you are right, OCSP checks were disabled for DV certs | 17:39 |
| Isla_de_Muerte | patdk-lap, changed the sysctl | 17:47 |
| Isla_de_Muerte | it looks like the sites are loading faster now | 17:47 |
| Isla_de_Muerte | will look into the ip route now | 17:47 |
| patdk-lap | the sysctl tells linux not to do a tcp slow start | 17:47 |
| patdk-lap | the route command tells it to allow upto x packets on the first burst without a confirmation, if your window size allows it, so mine above would be 45 packets | 17:48 |
| patdk-lap | the default used to be 3, but was raised several years ago due to the ssl issue and google search to 10 | 17:48 |
| patdk-lap | 10 will JUST handle a 2k rsa certificate | 17:48 |
| patdk-lap | most cdn's have raised theirs to 30 or so | 17:49 |
| patdk-lap | https://blog.imaginea.com/look-at-tcp-initcwnd-cdns/ | 17:50 |
| patdk-lap | gives you a good overview what/why/... and what others are using | 17:51 |
| patdk-lap | and is actually updated/recent :) | 17:51 |
| Isla_de_Muerte | patdk-lap, ty for the link! Looking into it now | 17:51 |
| patdk-lap | this ONLY matters fir that first byte :) | 17:51 |
| patdk-lap | or if you just want to serve small webpages/grapics really fast | 17:52 |
| patdk-lap | thinking an ad server | 17:52 |
| patdk-lap | normally the firstbite can fit in the normal default these days of 10, but with ssl, that won't be the case if your using 4k rsa certificates, but you where using 2k, so not sure if this applied directly to you, but still something to think about | 17:53 |
| Isla_de_Muerte | patdk-lap, can I see what are the settings atm? | 17:54 |
| patdk-lap | ya, let me remember how, but it should be 10 | 17:54 |
| patdk-lap | unless your using like 12.04 or something older | 17:55 |
| Isla_de_Muerte | 14.04 | 17:55 |
| patdk-lap | https://www.cdnplanet.com/tools/initcwndcheck/ | 17:56 |
| patdk-lap | ss -nli | grep cwnd | 18:00 |
| patdk-lap | shows the values for current active connections | 18:00 |
| Isla_de_Muerte | patdk-lap, yy you were right, 10 it is | 18:07 |
| Isla_de_Muerte | So I basically run -> ip route | while read p; do ip route change $p initcwnd 45 initrwnd 45; done | 18:09 |
| Isla_de_Muerte | Do I need to restart anything after that? tyvm for all the help xD | 18:09 |
| patdk-lap | nope | 18:09 |
| sdeziel | don't forget IPv6 routes :) | 18:09 |
| patdk-lap | maybe apache, but | 18:09 |
| patdk-lap | probably need more changes to handle ipv6 | 18:10 |
| Isla_de_Muerte | Hmm it doesn't seem anything changed :P | 18:15 |
| Isla_de_Muerte | when I run ss -nli | grep cwnd I get the same results | 18:15 |
| Isla_de_Muerte | restarted apache to just in case | 18:15 |
| patdk-lap | as I said, it will only show connections in use | 18:16 |
| patdk-lap | if the connection is closed, you won't see it | 18:17 |
| Isla_de_Muerte | Ah okie | 18:17 |
| patdk-lap | your likely only seeing your old ssh sessions and stuff | 18:17 |
| patdk-lap | when you type, ip route | 18:17 |
| patdk-lap | make sure the default line, has those params on it | 18:17 |
| Isla_de_Muerte | I can see initcwnd 45 initrwnd 45 | 18:18 |
| Isla_de_Muerte | next to the lines | 18:18 |
| Odd_Bloke | smoser: Would you be able to review/merge https://code.launchpad.net/~philroche/simplestreams/bionic-i386-ova-not-expected/+merge/337885 please? | 18:18 |
| Odd_Bloke | (I'd ask Rob, but he's out ill today.) | 18:18 |
| smoser | Odd_Bloke: yeah, i'll get that. i'm going to replace the \ though. but other than taht. | 18:26 |
| Odd_Bloke | smoser: I'm sure philroche will be mortally offended. ;) | 18:29 |
| Isla_de_Muerte | sdeziel, enabled HSTS too xD | 18:45 |
| Isla_de_Muerte | ty for all the help and info guys patdk-lap xD | 18:46 |
| sdeziel | np | 18:46 |
| patdk-lap | what does it look like now? | 18:48 |
| Isla_de_Muerte | patdk-lap, according to webpagetest the same or a bit worse at random times (well actually it can take from 2sec-5sec) on pingdom it is still stable, nothing changed | 18:49 |
| Isla_de_Muerte | On my browser I think a bit faster | 18:50 |
| patdk-lap | well, I expect pingdom was already using ECDHE | 18:50 |
| patdk-lap | maybe try using a different area, dullas is always the most busy/congested | 18:50 |
| Isla_de_Muerte | I just kept it that because all my previous tests were based on that | 18:52 |
| smoser | Odd_Bloke: favors do not go un-remembered.... | 19:10 |
| smoser | could you look at https://code.launchpad.net/~smoser/simplestreams/trunk.fix-bionic-tools/+merge/337892 | 19:10 |
| smoser | found that when trying to test on bionic | 19:10 |
| smoser | and then https://code.launchpad.net/~smoser/simplestreams/trunk.python3-make-test-data/+merge/337893 | 19:28 |
| smoser | found *that* as i was verifying my change in xenial, and had forgotten about python2 | 19:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!