[CentOS-virt] Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set triggers domU kernel WARNING, then domU becomes unresponsive

[Adi Pircalabu]

Has anyone seen this recently? I couldn't replicate it on:
- CentOS 6 running kernel-2.6.32-696.16.1.el6.x86_64, 
kernel-lt-4.4.105-1.el6.elrepo.x86_64

- CentOS 7 running 4.9.67-1.el7.centos.x86_64

But I can replicate it consistently running "xl -v vcpu-set  
" on:

- CentOS 6 running 4.14.5-1.el6.elrepo.x86_64
- CentOS 7 running 4.14.5-1.el7.elrepo.x86_64

dom0 versions tested with similar results in the domU:
- 4.6.6-6.el7 on kernel 4.9.63-29.el7.x86_64
- 4.6.3-15.el6 on kernel 4.9.37-29.el6.x86_64

Noticed behaviour:
- These commands stall:
top
ls -l /var/tmp
ls -l /tmp
- Stuck in D state on the CentOS 7 domU:
root 5  0.0  0.0  0 0 ?D11:20   0:00 
[kworker/u8:0]
root   316  0.0  0.0  0 0 ?D11:20   0:00 
[jbd2/xvda1-8]

root  1145  0.0  0.2 116636  4776 ?Ds   11:20   0:00 -bash
root  1289  0.0  0.1  25852  2420 ?Ds   11:35   0:00 
/usr/bin/systemd-tmpfiles --clean
root  1290  0.0  0.1 125248  2696 pts/1D+   11:44   0:00 ls 
--color=auto -l /tmp/
root  1293  0.0  0.1 125248  2568 pts/2D+   11:44   0:00 ls 
--color=auto -l /var/tmp

root  1296  0.0  0.2 116636  4908 pts/3Ds+  11:44   0:00 -bash
root  1358  0.0  0.1 125248  2612 pts/4D+   11:47   0:00 ls 
--color=auto -l /var/tmp


At a first glance it appears the issue is in 4.14.5 kernel. Stack traces 
follow:


-CentOS 6 kernel-ml-4.14.5-1.el6.elrepo.x86_64 start here-
[ cut here ]
WARNING: CPU: 4 PID: 60 at block/blk-mq.c:1144 
__blk_mq_run_hw_queue+0x9e/0xc0
Modules linked in: intel_cstate(-) ipt_REJECT nf_reject_ipv4 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_multiport iptable_filter ip_tables 
ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state 
nf_conntrack libcrc32c ip6table_filter ip6_tables dm_mod dax 
xen_netfront crc32_pclmul crct10dif_pclmul ghash_clmulni_intel 
crc32c_intel pcbc aesni_intel glue_helper crypto_simd cryptd aes_x86_64 
coretemp hwmon x86_pkg_temp_thermal sb_edac intel_rapl_perf pcspkr ext4 
jbd2 mbcache xen_blkfront
CPU: 4 PID: 60 Comm: kworker/4:1H Not tainted 4.14.5-1.el6.elrepo.x86_64 
#1

Workqueue: kblockd blk_mq_run_work_fn
task: 8802711a2780 task.stack: c90041af4000
RIP: e030:__blk_mq_run_hw_queue+0x9e/0xc0
RSP: e02b:c90041af7c48 EFLAGS: 00010202
RAX: 0001 RBX: 88027117fa80 RCX: 0001
RDX: 88026b053ee0 RSI: 88027351bca0 RDI: 88026b072800
RBP: c90041af7c68 R08: c90041af7eb8 R09: 8802711a2810
R10: 7ff0 R11: 0001 R12: 88026b072800
R13: e8d04d00 R14:  R15: e8d04d05
FS:  2b7b7c89b700() GS:88027350() 
knlGS:

CS:  e033 DS:  ES:  CR0: 80050033
CR2: ff600400 CR3: 00026d953000 CR4: 00042660
Call Trace:
 blk_mq_run_work_fn+0x31/0x40
 process_one_work+0x174/0x440
 ? xen_mc_flush+0xad/0x1b0
 ? schedule+0x3a/0xa0
 worker_thread+0x6b/0x410
 ? default_wake_function+0x12/0x20
 ? __wake_up_common+0x84/0x130
 ? maybe_create_worker+0x120/0x120
 ? schedule+0x3a/0xa0
 ? _raw_spin_unlock_irqrestore+0x16/0x20
 ? maybe_create_worker+0x120/0x120
 kthread+0x111/0x150
 ? __kthread_init_worker+0x40/0x40
 ret_from_fork+0x25/0x30
Code: 89 df e8 06 2f d9 ff 4c 89 e7 41 89 c5 e8 0b 6e 00 00 44 89 ee 48 
89 df e8 20 2f d9 ff 48 8b 5d e8 4c 8b 65 f0 4c 8b 6d f8 c9 c3 <0f> ff 
eb aa 4c 89 e7 e8 e6 6d 00 00 48 8b 5d e8 4c 8b 65 f0 4c

---[ end trace fe2aaf4e723042fd ]---
-CentOS 6 kernel-ml-4.14.5-1.el6.elrepo.x86_64 end here-

-CentOS 7 kernel-ml-4.14.5-1.el7.elrepo.x86_64 start here-
[  116.528885] [ cut here ]
[  116.528894] WARNING: CPU: 3 PID: 38 at block/blk-mq.c:1144 
__blk_mq_run_hw_queue+0x89/0xa0
[  116.528898] Modules linked in: intel_cstate(-) ip_set_hash_ip ip_set 
nfnetlink x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper cryptd 
intel_rapl_perf pcspkr nfsd auth_rpcgss nfs_acl lockd grace sunrpc 
ip_tables ext4 mbcache jbd2 xen_netfront xen_blkfront crc32c_intel
[  116.528919] CPU: 3 PID: 38 Comm: kworker/3:1H Not tainted 
4.14.5-1.el7.elrepo.x86_64 #1
[  116.529007] Code: 00 e8 7c c5 45 00 4c 89 e7 e8 14 4b d7 ff 48 89 df 
41 89 c5 e8 19 66 00 00 44 89 ee 4c 89 e7 e8 2e 4b d7 ff 5b 41 5c 41 5d 
5d c3 <0f> ff eb b4 48 89 df e8 fb 65 00 00 5b 41 5c 41 5d 5d c3 0f ff

[  116.529034] ---[ end trace a7814e3ec9a330c6 ]---
[  147.424117] [ cut here ]
[  147.424150] WARNING: CPU: 2 PID: 24 at block/blk-mq.c:1144 
__blk_mq_run_hw_queue+0x89/0xa0
[  147.424160] Modules linked in: ip_set_hash_ip ip_set nfnetlink 
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul 
ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper cryptd 
intel_rapl_perf pcspkr nfsd auth_rpcgss nfs_acl lockd grace sunrpc 
ip_tables ext4 mbcache jbd2 xen_netfront xen_blkfront crc32c_intel
[  

Re: [CentOS] upgrading python

[Larry Martell]

On Mon, Dec 11, 2017 at 5:57 PM, Kenneth Porter  wrote:
> On 12/11/2017 2:50 PM, Larry Martell wrote:
>>
>> ExecStart=/usr/bin/scl enable python27 bash; /usr/bin/uwsgi --emperor
>> /etc/uwsgi/sites
>
>
> You probably want:
>
> ExecStart=/usr/bin/scl enable python27 '/usr/bin/uwsgi --emperor
> /etc/uwsgi/sites'
>
> See:
>
> https://linux.die.net/man/1/scl

With that change it starts, but still with 2.7.5:

*** Starting uWSGI 2.0.13.1 (64bit) on [Mon Dec 11 17:47:19 2017] ***
compiled with version: 4.8.5 20150623 (Red Hat 4.8.5-4) on 28 July 2016 12:32:18
os: Linux-3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016
nodename: padev
machine: x86_64
clock source: unix
detected number of CPU cores: 8
current working directory: /etc/uwsgi/sites
detected binary path: /usr/bin/uwsgi
chdir() to /usr/local/motor/motor
your processes number limit is 195775
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /usr/local/motor/motor.sock fd 3
Python version: 2.7.5 (default, Sep 15 2016, 22:37:39)  [GCC 4.8.5
20150623 (Red Hat 4.8.5-4)]
*** Python threads support is disabled. You can enable it with
--enable-threads ***
Python main interpreter initialized at 0x13a75e0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 1115752 bytes (1089 KB) for 10 cores
*** Operational MODE: preforking ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x13a75e0
pid: 25616 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 25616)
spawned uWSGI worker 1 (pid: 25693, cores: 1)
spawned uWSGI worker 2 (pid: 25694, cores: 1)
spawned uWSGI worker 3 (pid: 25695, cores: 1)
spawned uWSGI worker 4 (pid: 25696, cores: 1)
spawned uWSGI worker 5 (pid: 25697, cores: 1)
spawned uWSGI worker 6 (pid: 25699, cores: 1)
spawned uWSGI worker 7 (pid: 25700, cores: 1)
spawned uWSGI worker 8 (pid: 25701, cores: 1)
spawned uWSGI worker 9 (pid: 25702, cores: 1)
spawned uWSGI worker 10 (pid: 25703, cores: 1)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Kenneth Porter]

On 12/11/2017 2:50 PM, Larry Martell wrote:

ExecStart=/usr/bin/scl enable python27 bash; /usr/bin/uwsgi --emperor
/etc/uwsgi/sites


You probably want:

ExecStart=/usr/bin/scl enable python27 '/usr/bin/uwsgi --emperor 
/etc/uwsgi/sites'

See:

https://linux.die.net/man/1/scl

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Larry Martell]

On Mon, Dec 11, 2017 at 5:43 PM, Clint Dilks  wrote:
> On Tue, Dec 12, 2017 at 11:31 AM,  wrote:
>
>> Pete Biggs wrote:
>> > On Mon, 2017-12-11 at 15:44 -0600, Frank Cox wrote:
>> >> On Mon, 11 Dec 2017 16:32:06 -0500
>> >> Larry Martell wrote:
>> >>
>> >> > Can I make that the default python?
>> >>
>> >> ~/.bashrc
>> >>
>> > No. I'm not entirely sure that is a good idea! No, not all.
>> >
>> > 'scl enable python27 bash' creates a *new* shell with the correct
>> > environment.  As each invocation of bash reads .bashrc, it will also
>> > create another new shell which will then read .bashrc and create
>> > another shell 
>> >
>> > Depending on the speed of your machine and disks and how much memory
>> > you have, it will take a few seconds to a few minutes to grind your
>> > machine to a halt.
>>
>> The simplest way is to .  I definitely wouldn't make it the default python, but I have made it the
> default for a particular user as long as they are not root.
>
> In the past I have got python27-mod_wsgi and httpd24-httpd working together
> by doing things like httpd24-httpd by doing things like
>
>
> cat /opt/rh/httpd24/root/etc/sysconfig/httpd
>
> export PATH=/opt/rh/python27/root/usr/bin:$PATH
> export
> LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

I am running nginx and uWSGI. I added this to /etc/systemd/system/uwsgi.service:

ExecStart=/usr/bin/scl enable python27 bash; /usr/bin/uwsgi --emperor
/etc/uwsgi/sites

But it did not start:

   Loaded: loaded (/etc/systemd/system/uwsgi.service; enabled; vendor
preset: disabled)
   Active: failed (Result: start-limit) since Mon 2017-12-11 17:20:36
EST; 6s ago
  Process: 24492 ExecStart=/usr/bin/scl enable python27 bash;
/usr/bin/uwsgi --emperor /etc/uwsgi/sites (code=exited,
status=1/FAILURE)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Clint Dilks]

On Tue, Dec 12, 2017 at 11:31 AM,  wrote:

> Pete Biggs wrote:
> > On Mon, 2017-12-11 at 15:44 -0600, Frank Cox wrote:
> >> On Mon, 11 Dec 2017 16:32:06 -0500
> >> Larry Martell wrote:
> >>
> >> > Can I make that the default python?
> >>
> >> ~/.bashrc
> >>
> > No. I'm not entirely sure that is a good idea! No, not all.
> >
> > 'scl enable python27 bash' creates a *new* shell with the correct
> > environment.  As each invocation of bash reads .bashrc, it will also
> > create another new shell which will then read .bashrc and create
> > another shell 
> >
> > Depending on the speed of your machine and disks and how much memory
> > you have, it will take a few seconds to a few minutes to grind your
> > machine to a halt.
>
> The simplest way is to . 
>   mark
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

I definitely wouldn't make it the default python, but I have made it the
default for a particular user as long as they are not root.

In the past I have got python27-mod_wsgi and httpd24-httpd working together
by doing things like httpd24-httpd by doing things like


cat /opt/rh/httpd24/root/etc/sysconfig/httpd

export PATH=/opt/rh/python27/root/usr/bin:$PATH
export
LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[m . roth]

Pete Biggs wrote:
> On Mon, 2017-12-11 at 15:44 -0600, Frank Cox wrote:
>> On Mon, 11 Dec 2017 16:32:06 -0500
>> Larry Martell wrote:
>>
>> > Can I make that the default python?
>>
>> ~/.bashrc
>>
> No. I'm not entirely sure that is a good idea! No, not all.
>
> 'scl enable python27 bash' creates a *new* shell with the correct
> environment.  As each invocation of bash reads .bashrc, it will also
> create another new shell which will then read .bashrc and create
> another shell 
>
> Depending on the speed of your machine and disks and how much memory
> you have, it will take a few seconds to a few minutes to grind your
> machine to a halt.

The simplest way is to . https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Pete Biggs]

On Mon, 2017-12-11 at 15:44 -0600, Frank Cox wrote:
> On Mon, 11 Dec 2017 16:32:06 -0500
> Larry Martell wrote:
> 
> > Can I make that the default python?
> 
> ~/.bashrc
> 
No. I'm not entirely sure that is a good idea! No, not all.

'scl enable python27 bash' creates a *new* shell with the correct
environment.  As each invocation of bash reads .bashrc, it will also
create another new shell which will then read .bashrc and create
another shell   

Depending on the speed of your machine and disks and how much memory
you have, it will take a few seconds to a few minutes to grind your
machine to a halt.

P.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Pete Biggs]

> > > > 
> > > > Or use Software Collections, the Python27 package from there has 2.7.13
> > > > 
> > > >  https://www.softwarecollections.org/en/scls/rhscl/python27/
> > > > 
> > > >  https://wiki.centos.org/AdditionalResources/Repositories/SCL
> > > 
> > > I followed the instructions at the first link and I still only seem to
> > > have 2.7.5. How can I specify a newer version?
> > Hi, perhaps reading https://www.softwarecollections.org/en/ and
> > https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.
> > 
> > Have you done scl enable python27 bash in your current shell?
> 
> Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type
> that command in each new shell. Can I make that the default python? I
> want django and uWSGI to use that version.
> 

I believe doing something like

  source scl_source enable python27

in .bashrc will do that. But the scl_source command is a fairly recent
addition so hopefully you have it. See:

  https://access.redhat.com/solutions/527703

Try it from a command line first before committing it to your .bashrc

There are some things on the web about using django and uWSGI with
software collections. For instance:

  https://developers.redhat.com/blog/tag/django/

but I know nothing about any of the applications so I don't know how
relevant this is.

P.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Johnny Hughes]

On 12/11/2017 03:32 PM, Larry Martell wrote:
> On Mon, Dec 11, 2017 at 4:25 PM, Clint Dilks  
> wrote:
>> On Tue, Dec 12, 2017 at 10:09 AM, Larry Martell 
>> wrote:
>>
>>> On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs  wrote:
 On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
> On 05.12.2017 14:05, Larry Martell wrote:
>> I am running CentOS 7 and I have python version:
>>
>> Python 2.7.5 (default, Sep 15 2016, 22:37:39)
>>
>> I need a newer version of 2.7 to pick up a bug fix. How can I do that
>> (without breaking anything in CentOS)?
>
> you could use the anaconda software, it is independent of the OS
> regards
>
>

 Or use Software Collections, the Python27 package from there has 2.7.13

  https://www.softwarecollections.org/en/scls/rhscl/python27/

  https://wiki.centos.org/AdditionalResources/Repositories/SCL
>>>
>>> I followed the instructions at the first link and I still only seem to
>>> have 2.7.5. How can I specify a newer version?
> 
>> Hi, perhaps reading https://www.softwarecollections.org/en/ and
>> https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.
>>
>> Have you done scl enable python27 bash in your current shell?
> 
> Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type
> that command in each new shell. Can I make that the default python? I
> want django and uWSGI to use that version.

You likely can not make it the default python .. because all the system
based things will likely break.

However, you CAN add (call) the correct environment to your startup
scripts for the proper deamons in init, which should run the required
servers with the version of python that you want.

The whole purpose of SCLs is to allow multiple versions of the same
items to run together on a given machine, and you can pick the one you
need for a give application/server service .. WHILE, not breaking 9in
the case of python) things like yum :).



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Kenneth Porter]

On 12/11/2017 1:32 PM, Larry Martell wrote:

Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type
that command in each new shell. Can I make that the default python? I
want django and uWSGI to use that version.


The "default" python is a dependency for many other system packages, so 
changing it without understanding what effect it will have on other 
parts of the system would be dangerous. The idea behind Software 
Collections is that you only affect the packages that truly need the 
newer version.


How are you launching django and uWSGI? I'd suggest putting the SC 
command in their startup scripts to keep the new version confined to them.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Frank Cox]

On Mon, 11 Dec 2017 16:32:06 -0500
Larry Martell wrote:

> Can I make that the default python?

~/.bashrc

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Larry Martell]

On Mon, Dec 11, 2017 at 4:25 PM, Clint Dilks  wrote:
> On Tue, Dec 12, 2017 at 10:09 AM, Larry Martell 
> wrote:
>
>> On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs  wrote:
>> > On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
>> >> On 05.12.2017 14:05, Larry Martell wrote:
>> >> > I am running CentOS 7 and I have python version:
>> >> >
>> >> > Python 2.7.5 (default, Sep 15 2016, 22:37:39)
>> >> >
>> >> > I need a newer version of 2.7 to pick up a bug fix. How can I do that
>> >> > (without breaking anything in CentOS)?
>> >>
>> >> you could use the anaconda software, it is independent of the OS
>> >> regards
>> >>
>> >>
>> >
>> > Or use Software Collections, the Python27 package from there has 2.7.13
>> >
>> >  https://www.softwarecollections.org/en/scls/rhscl/python27/
>> >
>> >  https://wiki.centos.org/AdditionalResources/Repositories/SCL
>>
>> I followed the instructions at the first link and I still only seem to
>> have 2.7.5. How can I specify a newer version?

> Hi, perhaps reading https://www.softwarecollections.org/en/ and
> https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.
>
> Have you done scl enable python27 bash in your current shell?

Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type
that command in each new shell. Can I make that the default python? I
want django and uWSGI to use that version.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Clint Dilks]

On Tue, Dec 12, 2017 at 10:09 AM, Larry Martell 
wrote:

> On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs  wrote:
> > On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
> >> On 05.12.2017 14:05, Larry Martell wrote:
> >> > I am running CentOS 7 and I have python version:
> >> >
> >> > Python 2.7.5 (default, Sep 15 2016, 22:37:39)
> >> >
> >> > I need a newer version of 2.7 to pick up a bug fix. How can I do that
> >> > (without breaking anything in CentOS)?
> >>
> >> you could use the anaconda software, it is independent of the OS
> >> regards
> >>
> >>
> >
> > Or use Software Collections, the Python27 package from there has 2.7.13
> >
> >  https://www.softwarecollections.org/en/scls/rhscl/python27/
> >
> >  https://wiki.centos.org/AdditionalResources/Repositories/SCL
>
> I followed the instructions at the first link and I still only seem to
> have 2.7.5. How can I specify a newer version?
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

Hi, perhaps reading https://www.softwarecollections.org/en/ and
https://www.softwarecollections.org/en/scls/rhscl/python27/ will help.

Have you done scl enable python27 bash in your current shell?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] upgrading python

[Larry Martell]

On Tue, Dec 5, 2017 at 8:22 AM, Pete Biggs  wrote:
> On Tue, 2017-12-05 at 14:16 +0100, Kai Grunau wrote:
>> On 05.12.2017 14:05, Larry Martell wrote:
>> > I am running CentOS 7 and I have python version:
>> >
>> > Python 2.7.5 (default, Sep 15 2016, 22:37:39)
>> >
>> > I need a newer version of 2.7 to pick up a bug fix. How can I do that
>> > (without breaking anything in CentOS)?
>>
>> you could use the anaconda software, it is independent of the OS
>> regards
>>
>>
>
> Or use Software Collections, the Python27 package from there has 2.7.13
>
>  https://www.softwarecollections.org/en/scls/rhscl/python27/
>
>  https://wiki.centos.org/AdditionalResources/Repositories/SCL

I followed the instructions at the first link and I still only seem to
have 2.7.5. How can I specify a newer version?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Broadcom BCM4352 on Centos 7

[Akemi Yagi]

On Mon, Dec 11, 2017 at 2:14 AM, Gary Stainburn  wrote:

> Hi Folks
>
> I'm trying to get my internal WiFi working and I'm following the
> instructions
> here:
>
> https://wiki.centos.org/HowTos/Laptops/Wireless/Broadcom
>
> My adaptor is:
>
> [gary@gary ~]$ lspci|grep Broad
> 08:00.0 Network controller: Broadcom Limited BCM4352 802.11ac Wireless
> Network
> Adapter (rev 03)
> [gary@gary ~]$
>
> However, I've failed at step 2 as I cannot find any Linux / STA / WL
> drivers
> when I search the support page linked.
>
> Can anyone suggest how I can fix this, or suggest another web page I can
> follow?
>

​As far as I know, the contents on the CentOS wiki are for CentOS 7.3 (or
earlier) and a patch is needed to use the driver under 7.4.

You may want to go to the ELRepo article that is referenced on that page (
http://elrepo.org/tiki/wl-kmod
​ )​. The ELRepo instructions are up to date and should cover EL7.4.

Akemi
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Broadcom BCM4352 on Centos 7

[Johnny Hughes]

On 12/11/2017 04:14 AM, Gary Stainburn wrote:
> Hi Folks
> 
> I'm trying to get my internal WiFi working and I'm following the instructions 
> here:
> 
> https://wiki.centos.org/HowTos/Laptops/Wireless/Broadcom
> 
> My adaptor is:
> 
> [gary@gary ~]$ lspci|grep Broad
> 08:00.0 Network controller: Broadcom Limited BCM4352 802.11ac Wireless 
> Network 
> Adapter (rev 03)
> [gary@gary ~]$ 
> 
> However, I've failed at step 2 as I cannot find any Linux / STA / WL drivers 
> when I search the support page linked.
> 
> Can anyone suggest how I can fix this, or suggest another web page I can 
> follow?
> 

http://www.broadcom.com/support/802.11/linux_sta.php

That should give you the latest broadcom 43xx driver.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-docs] wiki.centos.org .. what's next ?

[Илья]

GitLab?
= wiki + md + git + OpenID



>Понедельник, 11 декабря 2017, 12:41 +03:00 от Fabian Arrotin 
>:
>
>On 11/12/17 10:22, Thibaut Perrin wrote:
>> Hello Fabien,
>> 
>> First, thank you for even trying for what seems to be an impossible task :(
>> 
>> Quick points : 
>> - if it was decided not to continue, what would happen to the current
>> wiki ? Dismantled or would it remain as read-only for documentation
>> purpose ?
>> - What about Sphinx < http://www.sphinx-doc.org/en/stable/ > ? seems to be
>> frequentely used nowadays
>> - As you mentioned, a solution of the type of github with pull requests
>> for documentation updates might be a solution here. 
>> 
>> There is a wiki feature < https://guides.github.com/features/wikis/ > on
>> Github. I don't know to which extend it would fit the needs of the project.
>> 
>> Hope this helps,
>> 
>> Thibaut
>
>So far there is no decision, reason why I started this thread :)
>I guess our target would be to convert (and sanitize ?) existing content
>anyway as we don't want to lose such content. Then either replacing
>wiki.centos.org with new solution (but trying to keep the same structure
>so that all the things in cache for search engines and/or articles
>pointing to wiki can still work) or move to something different and
>indeed keeping existing wiki.centos.org in Read-Only mode
>
>I'd like to avoid Github specifically but having something else that
>would permit to use ACO (https://acccounts.centos.org) as auth source. I
>already played with gitea and it works with openid so self-hosted git
>instance using ACO works fine. (but that's a different thread)
>
>We should divide all parts into specific areas. Benefits of using .md
>means being able to switch to something else even later and not be tied
>to $yet_another_tool to generate the web part. (just my idea)
>
>-- 
>Fabian Arrotin
>The CentOS Project |  https://www.centos.org
>gpg key: 56BEC54E | twitter: @arrfab
>
>___
>CentOS-docs mailing list
>CentOS-docs@centos.org
>https://lists.centos.org/mailman/listinfo/centos-docs


С уважением, Дорохов И.А.
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

[CentOS] Broadcom BCM4352 on Centos 7

[Gary Stainburn]

Hi Folks

I'm trying to get my internal WiFi working and I'm following the instructions 
here:

https://wiki.centos.org/HowTos/Laptops/Wireless/Broadcom

My adaptor is:

[gary@gary ~]$ lspci|grep Broad
08:00.0 Network controller: Broadcom Limited BCM4352 802.11ac Wireless Network 
Adapter (rev 03)
[gary@gary ~]$ 

However, I've failed at step 2 as I cannot find any Linux / STA / WL drivers 
when I search the support page linked.

Can anyone suggest how I can fix this, or suggest another web page I can 
follow?

Cheers
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-docs] wiki.centos.org .. what's next ?

[Fabian Arrotin]

On 11/12/17 10:22, Thibaut Perrin wrote:
> Hello Fabien,
> 
> First, thank you for even trying for what seems to be an impossible task :(
> 
> Quick points : 
> - if it was decided not to continue, what would happen to the current
> wiki ? Dismantled or would it remain as read-only for documentation
> purpose ?
> - What about Sphinx  ? seems to be
> frequentely used nowadays
> - As you mentioned, a solution of the type of github with pull requests
> for documentation updates might be a solution here. 
> 
> There is a wiki feature  on
> Github. I don't know to which extend it would fit the needs of the project.
> 
> Hope this helps,
> 
> Thibaut

So far there is no decision, reason why I started this thread :)
I guess our target would be to convert (and sanitize ?) existing content
anyway as we don't want to lose such content. Then either replacing
wiki.centos.org with new solution (but trying to keep the same structure
so that all the things in cache for search engines and/or articles
pointing to wiki can still work) or move to something different and
indeed keeping existing wiki.centos.org in Read-Only mode

I'd like to avoid Github specifically but having something else that
would permit to use ACO (https://acccounts.centos.org) as auth source. I
already played with gitea and it works with openid so self-hosted git
instance using ACO works fine. (but that's a different thread)

We should divide all parts into specific areas. Benefits of using .md
means being able to switch to something else even later and not be tied
to $yet_another_tool to generate the web part. (just my idea)

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab



signature.asc
Description: OpenPGP digital signature
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

Re: [CentOS-docs] wiki.centos.org .. what's next ?

[Thibaut Perrin]

Hello Fabien,

First, thank you for even trying for what seems to be an impossible task :(

Quick points :
- if it was decided not to continue, what would happen to the current wiki
? Dismantled or would it remain as read-only for documentation purpose ?
- What about Sphinx  ? seems to be
frequentely used nowadays
- As you mentioned, a solution of the type of github with pull requests for
documentation updates might be a solution here.

There is a wiki feature  on
Github. I don't know to which extend it would fit the needs of the project.

Hope this helps,

Thibaut


On 11 December 2017 at 10:00, Fabian Arrotin  wrote:

> it's all in the title : what's next for wiki.centos.org ?
>
> As a reminder, current wiki.centos.org instance is powered by moinmoin
> (https://moinmo.in/) but quite an old version (moin-1.5.8-3.el6.noarch)
>
> Recently I had a quick look at trying to update/upgrade that version to
> something newer/supported, but it's a nightmare : the data conversion
> just kill the target server (oom) and no way to know why. When trying to
> get help from moin people in their irc server, I was answered that such
> old version wasn't supported, and that those upgrade scripts themselves
> aren't supported either, so nobody would help finding why they'd be
> buggy without having access to the full data.
>
> Of course exposing the whole wiki instance (including user/pass) isn't
> an option, so except if somebody has really a clue about what can go
> wrong with the update script from 1.5 to 1.6 (and then it has to be done
> for each major.minor upgrade, so all that in a chained operation), the
> migration will be impossible.
>
> That's why I'd like to discuss a possibility to move wiki to something
> else, and that's even why we should discuss the need for a wiki itself.
>
> If we want to continue to have community written/maintained content,
> should be still use a wiki or something else ? Moin was selected ~10y
> ago for its simplicity and online editing, but in 2017, most people (dev
> and ops) are probably using other workflows, like git/pull-requests/etc.
>
> So what about exploring other possibilities ?
>
> I don't have a real proposal (even if mkdocs.org , simple solution with
> Markdown, combined with git would be perfect for me) but just wanted to
> start a dedicated thread so that we can think about the future of
> wiki.centos.org
>
> Opinions ? Proposals ? anything else ? Fee free to comment :-)
>
>
> --
> Fabian Arrotin
> The CentOS Project | https://www.centos.org
> gpg key: 56BEC54E | twitter: @arrfab
>
>
> ___
> CentOS-docs mailing list
> CentOS-docs@centos.org
> https://lists.centos.org/mailman/listinfo/centos-docs
>
>
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

[CentOS-docs] wiki.centos.org .. what's next ?

[Fabian Arrotin]

it's all in the title : what's next for wiki.centos.org ?

As a reminder, current wiki.centos.org instance is powered by moinmoin
(https://moinmo.in/) but quite an old version (moin-1.5.8-3.el6.noarch)

Recently I had a quick look at trying to update/upgrade that version to
something newer/supported, but it's a nightmare : the data conversion
just kill the target server (oom) and no way to know why. When trying to
get help from moin people in their irc server, I was answered that such
old version wasn't supported, and that those upgrade scripts themselves
aren't supported either, so nobody would help finding why they'd be
buggy without having access to the full data.

Of course exposing the whole wiki instance (including user/pass) isn't
an option, so except if somebody has really a clue about what can go
wrong with the update script from 1.5 to 1.6 (and then it has to be done
for each major.minor upgrade, so all that in a chained operation), the
migration will be impossible.

That's why I'd like to discuss a possibility to move wiki to something
else, and that's even why we should discuss the need for a wiki itself.

If we want to continue to have community written/maintained content,
should be still use a wiki or something else ? Moin was selected ~10y
ago for its simplicity and online editing, but in 2017, most people (dev
and ops) are probably using other workflows, like git/pull-requests/etc.

So what about exploring other possibilities ?

I don't have a real proposal (even if mkdocs.org , simple solution with
Markdown, combined with git would be perfect for me) but just wanted to
start a dedicated thread so that we can think about the future of
wiki.centos.org

Opinions ? Proposals ? anything else ? Fee free to comment :-)


-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab



signature.asc
Description: OpenPGP digital signature
___
CentOS-docs mailing list
CentOS-docs@centos.org
https://lists.centos.org/mailman/listinfo/centos-docs

Re: [CentOS] Problems with dnscrypt's package from EPEL

[C. L. Martinez]

Sorry Stephen. I have enabled another dnscrypt process in port 6355 to
test ... But no luck.

On the other side, I am not sure if dnscrypt the problem. I have
replaced unbound by dnsmasq and voila! ... All it is working very fast
(and dnsmasq only spends 75 MiB of RAM, when unbound spends 400 MiB).
And no more SERVFAIL errors ... But I don't understand where is the
problem with unbound.conf's file then. Using same config for dnscrypt
and unbound in a FreeBSD vm, all works ok.

On Sun, Dec 10, 2017 at 8:10 PM, Stephen John Smoogen  wrote:
> Not sure if this is a factor yet, but your forwardzone is looking for
> 3 ports but only 2 ports are configured in the systemd startup.. so
> are 1/3 of all lookups going to fail? Or is the 6355 a 'given' (aka it
> will be set up whether 6353 and 6354 are setup?)
>
> On 9 December 2017 at 16:45, C. L. Martinez  wrote:
>> On Sat, Dec 09, 2017 at 10:25:41PM +0100, C. L. Martinez wrote:
>>> On Sat, Dec 09, 2017 at 03:03:52PM -0500, Stephen John Smoogen wrote:
>>> > On 9 December 2017 at 14:04, C. L. Martinez  wrote:
>>> > > Hi all,
>>> > >
>>> > >  I have installed dnscrypt's rpm package from EPEL repo under a CentOS 
>>> > > 7.4 and using unbound as a resolver. But, I see constant timeouts and 
>>> > > responses are very slow ... Using same config in a Debian 9 virtual 
>>> > > machine, all works ok.
>>> > >
>>> > >  I think the problem is with dnscrypt's rpm package provided by EPEL. 
>>> > > Anyone have seen similar problems?
>>> > >
>>> >
>>> > Can you give some more information on what you are seeing and how you
>>> > have it set up? I can try to duplicate it in EPEL and/or put in bugs
>>> > on the package.
>>> >
>>> >
>>>
>>> Of course and thanks in advance Stephen. My dnscrypt startup scripts use 
>>> the following options:
>>>
>>> [Service]
>>> Type=forking
>>> PIDFile=/var/run/dnscrypt-cs.pid
>>> ExecStart=/usr/sbin/dnscrypt-proxy \
>>>   --daemonize \
>>>   --user=nobody \
>>>   --pidfile=/var/run/dnscrypt-cs.pid \
>>>   --ephemeral-keys \
>>>   --resolver-name=cs-fi \
>>>   --logfile=/tmp/cs.log \
>>>   --local-address=127.0.0.1:6354
>>> Restart=on-abort
>>>
>>> [Service]
>>> Type=forking
>>> PIDFile=/var/run/dnscrypt-ipredator.pid
>>> ExecStart=/usr/sbin/dnscrypt-proxy \
>>>   --daemonize \
>>>   --user=nobody \
>>>   --pidfile=/var/run/dnscrypt-ipredator.pid \
>>>   --ephemeral-keys \
>>>   --resolver-name=ipredator \
>>>   --logfile=/tmp/ipredator.log \
>>>   --local-address=127.0.0.1:6353
>>> Restart=on-abort
>>>
>>> And unbound.conf is:
>>>
>>> server:
>>>   interface: 127.0.0.1
>>>   interface: 172.22.54.4
>>>   interface: ::1
>>>   port: 53
>>>   do-ip6: no
>>>   do-udp: yes
>>>   do-tcp: yes
>>>   num-threads: 1
>>>
>>>   access-control: 0.0.0.0/0 refuse
>>>   access-control: 127.0.0.0/8 allow
>>>   access-control: ::0/0 refuse
>>>   access-control: ::1 allow
>>>   access-control: 172.22.54.0/29 allow
>>>   access-control: 172.22.55.1 allow
>>>
>>>   hide-identity: yes
>>>   hide-version: yes
>>>
>>>   do-not-query-localhost: no
>>>   val-permissive-mode: yes
>>>   val-clean-additional: yes
>>>   module-config: "validator iterator"
>>
>> Oops .. sorry. There are more options in unbound.conf's file:
>>
>> remote-control:
>> control-enable: yes
>> control-use-cert: yes
>> control-interface: 127.0.0.1
>>
>> forward-zone:
>> name: "."
>> forward-addr: 127.0.0.1@6353
>> forward-addr: 127.0.0.1@6354
>> forward-addr: 127.0.0.1@6355
>>
>> Sorry.
>>
>> --
>> Greetings,
>> C. L. Martinez
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
>
>
>
> --
> Stephen J Smoogen.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos