search for: 11043

Hi, what is the workaround for this? https://www.nginx.com/blog/php-fpm-cve-2019-11043-vulnerability-nginx/ in either CentOS 7 or 8 ? thanks --- Thomas Stephen Lee

...odprobe.conf lnet option > should be this: > > > options lnet networks=o2ib(ib0) > > (not ''o2ib0''). It still seems to want the TCP connection: Lustre: Added LNI 36.122.255.1 at o2ib [8/64] Lustre: Lustre Client File System; info at clusterfs.com LustreError: 11043:0:(events.c:401:ptlrpc_uuid_to_peer()) No NID found for 36.121.255.201 at tcp LustreError: 11043:0:(client.c:58:ptlrpc_uuid_to_connection()) cannot find peer 36.121.255.201 at tcp! LustreError: 11043:0:(ldlm_lib.c:312:client_obd_setup()) can''t add initial connection LustreError: 11043:0:(o...

Hi Marius, Will make the changes and see how it goes. On the other hand https://cbs.centos.org/koji/buildinfo?buildID=27138 if the above was released we could just install and migrate to rh-php73-php, which is not affected as per https://access.redhat.com/security/cve/cve-2019-11043 thanks --- Thomas Stephen Lee On Thu, Oct 31, 2019 at 8:40 PM Marius ROMAN <marius at roman.systems> wrote: > On 10/31/19 10:49 AM, Thomas Stephen Lee wrote: > > Hi, > > > > what is the workaround for this? > > > > https://www.nginx.com/blog/php-fpm-cve-20...

...039] read(4, <unfinished ...> [pid 11038] time( <unfinished ...> [pid 11039] <... read resumed> "\377\377\377\377", 16384) = 4 [pid 11038] <... time resumed> NULL) = 1191827978 [pid 11039] select(7, [3 4], [3], NULL, NULL <unfinished ...> [pid 11038] kill(11043, SIGUSR2 <unfinished ...> [pid 11043] <... select resumed> ) = ? ERESTARTNOHAND (To be restarted) [pid 11039] <... select resumed> ) = 1 (out [3]) [pid 11038] <... kill resumed> ) = 0 [pid 11043] --- SIGUSR2 (User defined signal 2) @ 0 (0) --- [pid 11039] wr...

On Thu, Oct 31, 2019 at 02:19:05PM +0530, Thomas Stephen Lee wrote: > > Hi, > > what is the workaround for this? > > https://www.nginx.com/blog/php-fpm-cve-2019-11043-vulnerability-nginx/ > > in either CentOS 7 or 8 ? https://access.redhat.com/security/cve/cve-2019-11043 -- Jonathan Billings <billings at negate.org>

...e changes and see how it goes. > > On the other hand > > https://cbs.centos.org/koji/buildinfo?buildID=27138 > > if the above was released we could just install and migrate to > rh-php73-php, which is not affected as per > > https://access.redhat.com/security/cve/cve-2019-11043 > > thanks > > --- > Thomas Stephen Lee > > On Thu, Oct 31, 2019 at 8:40 PM Marius ROMAN <marius at roman.systems> wrote: > >> On 10/31/19 10:49 AM, Thomas Stephen Lee wrote: >>> Hi, >>> >>> what is the workaround for this? >>>...

...ll make the changes and see how it goes. > > On the other hand > https://cbs.centos.org/koji/buildinfo?buildID=27138 > > if the above was released we could just install and migrate to > rh-php73-php, which is not affected as per > https://access.redhat.com/security/cve/cve-2019-11043 > > thanks > > --- > Thomas Stephen Lee > > On Thu, Oct 31, 2019 at 8:40 PM Marius ROMAN <marius at roman.systems> <marius at roman.systems> wrote: > > > On 10/31/19 10:49 AM, Thomas Stephen Lee wrote: > > Hi, > > what is the workaround for this...

...NA to work. I reset it, have admin access, updated the firmware, and have the same SIP settings as best I can tell as I do on the 941. I configured a new extension (I'm using Druid), and I've checked sip.conf and it appears valid. I'm getting: May 31 12:04:01 NOTICE[2987]: chan_sip.c:11043 handle_request_register: Registration from '2345 <sip:2345@192.168.1.7>' failed for '192.168.1.69' - Username/auth name mismatch And I've reset the password 3 or 4 times. So I'm a bit at a loss. Any hints/tips are greatly appreciated. TIA, Brian

On 10/31/19 10:49 AM, Thomas Stephen Lee wrote: > Hi, > > what is the workaround for this? > > https://www.nginx.com/blog/php-fpm-cve-2019-11043-vulnerability-nginx/ > > in either CentOS 7 or 8 ? > > thanks > > --- > Thomas Stephen Lee > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos The simplest is to condition...

Hello, I tried a few months ago to use IMAP with Asterisk; I used either 1.4 or the latest SVN at that time (sorry, don't remember). After a day I had to remove it since Asterisk crashed, mostly in the IMAP client code (the code of UW IMAP). My users wants IMAP back (they loved it) but not in the price of crash... I could not reproduce the crashes at the lab. They only occour on the

...rt 223, 30 hops max 1 192.168.91.202 0.416 ms 0.161 ms 0.140 ms 2 192.168.91.202 [closed] 0.423 ms 0.340 ms 0.331 ms Indeed, ICMP packets generated by router got their source address translated to the address of host2 - tcpdumping on host1 gives: 14:21:40.188036 IP (tos 0x0, ttl 1, id 11043, offset 0, flags [none], length: 40) 10.0.0.1.47825 > 192.168.91.202.223: S [tcp sum ok] 1355768057:1355768057(0) win 0 14:21:40.188258 IP (tos 0xc0, ttl 64, id 28403, offset 0, flags [none], length: 68) 192.168.91.202 > 10.0.0.1: icmp 48: time exceeded in-transit 14:21:40.189829 IP (tos 0x0...

...code in my previous email because the code seems a little too long and complicated. You can refer to the detailed C code and LLVM IR code on http://llvm.org/bugs/show_bug.cgi?id=16843 There are four attachments for our C code and LLVM IR code: nestedloop.c (http://llvm.org/bugs/attachment.cgi?id=11043): the simplified C code. nestedloop.ll (http://llvm.org/bugs/attachment.cgi?id=11044): the basic LLVM IR code. nestedloop.preopt.ll (http://llvm.org/bugs/attachment.cgi?id=11045): the preprocessed LLVM IR code. nestedloop.prepare.ll (http://llvm.org/bugs/attachment.cgi?id=11046): the LLVM IR code a...

...resupuesto (S-1-5-21-1085031214-299502267-1801674531-11035) -> presupuesto Documanager (S-1-5-21-1085031214-299502267-1801674531-11029) -> documanager Consulta en Sala (S-1-5-21-1085031214-299502267-1801674531-11023) -> consultasala Soporte Tecnico (S-1-5-21-1085031214-299502267-1801674531-11043) -> soportetec SAI (S-1-5-21-1085031214-299502267-1801674531-11037) -> sai Domain Users (S-1-5-21-1085031214-299502267-1801674531-513) -> users Power Users (S-1-5-32-547) -> root Domain Computers (S-1-5-21-1085031214-299502267-1801674531-515) -> domcomp Domain Admins (S-1-5-21-108503...

thanks again for your sharp eye and speedy response. i have corrected the typos in the IP in the masq file. I am sorry to have to ask for more help but my pc''s on the local network can''t reach the dmz webserver using the webserver''s local or Public IP address. I need to be able to do this in order to test the split DNS setup for the network. Using ethereal on the

On 08/15/2013 03:32 AM, Star Tan wrote: > Hi all, Hi, I tried to reproduce your findings, but could not do so. > I have investigated the 6X extra compile-time overhead when Polly compiles the simple nestedloop benchmark in LLVM-testsuite. (http://188.40.87.11:8000/db_default/v4/nts/31?compare_to=28&baseline=28). Preliminary results show that such compile-time overhead is resulted by

...ail because the code seems a little too long and complicated. > You can refer to the detailed C code and LLVM IR code on http://llvm.org/bugs/show_bug.cgi?id=16843 > There are four attachments for our C code and LLVM IR code: > > > nestedloop.c (http://llvm.org/bugs/attachment.cgi?id=11043): the simplified C code. > nestedloop.ll (http://llvm.org/bugs/attachment.cgi?id=11044): the basic LLVM IR code. > nestedloop.preopt.ll (http://llvm.org/bugs/attachment.cgi?id=11045): the preprocessed LLVM IR code. > nestedloop.prepare.ll (http://llvm.org/bugs/attachment.cgi?id=11046): the...

Hi all, I have investigated the 6X extra compile-time overhead when Polly compiles the simple nestedloop benchmark in LLVM-testsuite. (http://188.40.87.11:8000/db_default/v4/nts/31?compare_to=28&baseline=28). Preliminary results show that such compile-time overhead is resulted by the complicated polly-dependence analysis. However, the key seems to be the polly-prepare pass, which introduces

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

...5 0 0.02 56065 penalty.ll 1 2377 0 0.01 2352 0 0.01 2352 PercentPrinter.ll 6 21343 0 0.01 21307 0 0.01 19541 perimeter.ll 1 12967 0 0.01 12934 0 0.01 12934 perlin.ll 6 22935 0 0.01 22920 0 0.01 22920 Perm.ll 7 10057 0 0.01 10038 0 0.01 10038 perrmesg.ll 4 56145 0 0.01 56111 0 0.01 52565 pfloat.ll 2 11043 0 0.01 11016 0 0.01 11016 pgcd.ll 1 9321 0 0.01 9294 0 0.01 9294 pgm.ll 10 51048 0 0.01 51026 0 0.01 51026 phalf.ll 1 1984 0 0.01 1957 0 0.01 1957 picmp.ll 1 8188 0 0.01 8161 0 0.01 8161 pidiv.ll 1 13345 0 0.01 13318 0 0.01 13318 pifft.ll 39 263480 0 0.03 263455 0 0.03 256056 pi.ll 2 7771 0 0.01 77...

...-0.025 3 3851 1191 1191 0.2125 1.7625 -0.025 3 4697 1192 1192 0.2125 1.7875 -0.025 3 5952 1193 1193 0.2125 1.8125 -0.025 3 7077 1194 1194 0.2125 1.8375 -0.025 3 8396 1195 1195 0.2125 1.8625 -0.025 3 10120 1196 1196 0.2125 1.8875 -0.025 3 11043 1197 1197 0.2125 1.9125 -0.025 3 10420 1198 1198 0.2125 1.9375 -0.025 3 9107 1199 1199 0.2125 1.9625 -0.025 3 8371 1200 1200 0.2125 1.9875 -0.025 3 8084 1201 1201 0.2125 2.0125 -0.025 3 7707 1202 1202 0.2125 2.0375 -0.025 3 7204 1203 1203 0.2125...