* [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 @ 2017-11-21 15:47 Alexander Hermes 2017-11-21 16:17 ` Scott Mayhew 0 siblings, 1 reply; 8+ messages in thread From: Alexander Hermes @ 2017-11-21 15:47 UTC (permalink / raw) To: linux-nfs Folks, I'm looking for some guidance on how to troubleshoot/debug an issue with (S= ELinux) labels over NFS that we've been having as a result of a kernel upgr= ade - description below. I looked around on http://linux-nfs.org but was not able to find how to deb= ug this kind of issue with labels - everything I found relates to more fund= amental issues like mounts plain not working.=20 With apologies for sending this to the devel mailing list, could you please= help me get to the bottom of this? Or redirect me to somewhere / someone t= hat can? Thank you very much, Alexander Hermes ---- ## Summary In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from= 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS = v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label= support - attempting to change labels on a mounted file leads to "Operatio= n Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to th= e earlier kernel version the issue goes away. ## Background As part of our gitlab HA deployment we use NFS to host data on a back end s= erver that is then mounted by application servers (cf. https://docs.gitlab.= com/ce/administration/high_availability/nfs.html). To do this we have a fai= rly typical setup where the server (in this example "enfigitback2-devel") e= xports a bunch of mounts via /etc/exports which are then mounted on a coupl= e of application servers ("enfigitfront1-devel" / "enfigitfront2-devel"). ## The issue On the new kernel I am not able to change or view the SELinux labels of fil= es / directories mounted on the client: ``` [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/= gitlab/.ssh/authorized_keys chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' t= o 'system_u:object_r:ssh_home_t:s0': Operation not supported [root@enfigitfront2-devel ~]# uname -r 3.10.0-693.2.2.el7.x86_64 ``` On the old kernel I am: ``` [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t /var/opt/= gitlab/.ssh/authorized_keys [root@enfigitfront1-devel ~]# uname -r 3.10.0-327.36.2.el7.x86_64 ``` We can't keep using the old kernel forever so I'd like to get to the bottom= of this - what could this be due to? How can I debug this further to under= stand where the "Operation not supported" is coming from? ## Server details Distro: CentOS 7.3 / 7.4 Kernel (`uname -r`):=20 * 3.10.0-514.10.2.el7.x86_64 (server) * 3.10.0-693.2.2.el7.x86_64 (client - new) * 3.10.0-327.36.2.el7.x86_64 (client - old) nfs-utils: RPM package version 1.3.0 =20 Server mount option example: /export/.ssh 172.18.10.148(rw,sync,no_root_squash) 172.18.10.151(rw,sync,no= _root_squash) Client mount options (/etc/fstab): enfigitback2-devel.datcon.co.uk:/export/.ssh /var/opt/gitlab/.ssh nfs= defaults,soft,v4.2,rsize=3D1048576,wsize=3D1048576,noatime,_netdev,loo= kupcache=3Dnone 0 0 ## Debugging I've done ### Mounting by hand I tried to mount one of the exported mounts "by hand" using `mount` and fou= nd the following: * mounting the same export on a different mount point using the same option= s as in /etc/fstab yields a mount that has the same issue * mounting with `nosharecache` results in a mount that *does not* have the = issue. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 2017-11-21 15:47 [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 Alexander Hermes @ 2017-11-21 16:17 ` Scott Mayhew 2017-11-21 18:30 ` Alexander Hermes 0 siblings, 1 reply; 8+ messages in thread From: Scott Mayhew @ 2017-11-21 16:17 UTC (permalink / raw) To: Alexander Hermes; +Cc: linux-nfs On Tue, 21 Nov 2017, Alexander Hermes wrote: > Folks, > > I'm looking for some guidance on how to troubleshoot/debug an issue with (SELinux) labels over NFS that we've been having as a result of a kernel upgrade - description below. > I looked around on http://linux-nfs.org but was not able to find how to debug this kind of issue with labels - everything I found relates to more fundamental issues like mounts plain not working. > > With apologies for sending this to the devel mailing list, could you please help me get to the bottom of this? Or redirect me to somewhere / someone that can? > > Thank you very much, > > Alexander Hermes > > ---- > > ## Summary > > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label support - attempting to change labels on a mounted file leads to "Operation Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to the earlier kernel version the issue goes away. > > ## Background > > As part of our gitlab HA deployment we use NFS to host data on a back end server that is then mounted by application servers (cf. https://docs.gitlab.com/ce/administration/high_availability/nfs.html). To do this we have a fairly typical setup where the server (in this example "enfigitback2-devel") exports a bunch of mounts via /etc/exports which are then mounted on a couple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel"). > > ## The issue > > On the new kernel I am not able to change or view the SELinux labels of files / directories mounted on the client: > > ``` > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys > chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' to 'system_u:object_r:ssh_home_t:s0': Operation not supported > [root@enfigitfront2-devel ~]# uname -r > 3.10.0-693.2.2.el7.x86_64 > ``` > On the old kernel I am: > > ``` > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys > [root@enfigitfront1-devel ~]# uname -r > 3.10.0-327.36.2.el7.x86_64 > ``` > > We can't keep using the old kernel forever so I'd like to get to the bottom of this - what could this be due to? How can I debug this further to understand where the "Operation not supported" is coming from? > > ## Server details > Distro: CentOS 7.3 / 7.4 > Kernel (`uname -r`): > * 3.10.0-514.10.2.el7.x86_64 (server) > * 3.10.0-693.2.2.el7.x86_64 (client - new) > * 3.10.0-327.36.2.el7.x86_64 (client - old) > nfs-utils: RPM package version 1.3.0 > > > Server mount option example: > /export/.ssh 172.18.10.148(rw,sync,no_root_squash) 172.18.10.151(rw,sync,no_root_squash) Add "security_label" to the export options above. If you don't see "security_label" listed in the exports(5) man page then you need to upgrade your nfs-utils package. -Scott > > Client mount options (/etc/fstab): > enfigitback2-devel.datcon.co.uk:/export/.ssh /var/opt/gitlab/.ssh nfs defaults,soft,v4.2,rsize=1048576,wsize=1048576,noatime,_netdev,lookupcache=none 0 0 > > ## Debugging I've done > > ### Mounting by hand > I tried to mount one of the exported mounts "by hand" using `mount` and found the following: > * mounting the same export on a different mount point using the same options as in /etc/fstab yields a mount that has the same issue > * mounting with `nosharecache` results in a mount that *does not* have the issue. > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 2017-11-21 16:17 ` Scott Mayhew @ 2017-11-21 18:30 ` Alexander Hermes 2017-11-27 13:51 ` Scott Mayhew 0 siblings, 1 reply; 8+ messages in thread From: Alexander Hermes @ 2017-11-21 18:30 UTC (permalink / raw) To: Scott Mayhew; +Cc: linux-nfs > Folks, >=20 > I'm looking for some guidance on how to troubleshoot/debug an issue with = (SELinux) labels over NFS that we've been having as a result of a kernel up= grade - description below. > I looked around on http://linux-nfs.org but was not able to find how to d= ebug this kind of issue with labels - everything I found relates to more fu= ndamental issues like mounts plain not working.=20 >=20 > With apologies for sending this to the devel mailing list, could you plea= se help me get to the bottom of this? Or redirect me to somewhere / someone= that can? >=20 > Thank you very much, >=20 > Alexander Hermes >=20 > ---- >=20 > ## Summary >=20 > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel fr= om 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NF= S v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux lab= el support - attempting to change labels on a mounted file leads to "Operat= ion Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to = the earlier kernel version the issue goes away. >=20 > ## Background >=20 > As part of our gitlab HA deployment we use NFS to host data on a back end= server that is then mounted by application servers (cf. https://docs.gitla= b.com/ce/administration/high_availability/nfs.html). To do this we have a f= airly typical setup where the server (in this example "enfigitback2-devel")= exports a bunch of mounts via /etc/exports which are then mounted on a cou= ple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel"). >=20 > ## The issue >=20 > On the new kernel I am not able to change or view the SELinux labels of f= iles / directories mounted on the client: >=20 > ``` > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t=20 > /var/opt/gitlab/.ssh/authorized_keys > chcon: failed to change context of=20 > '/var/opt/gitlab/.ssh/authorized_keys' to=20 > 'system_u:object_r:ssh_home_t:s0': Operation not supported=20 > [root@enfigitfront2-devel ~]# uname -r > 3.10.0-693.2.2.el7.x86_64 > ``` > On the old kernel I am: >=20 > ``` > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t=20 > /var/opt/gitlab/.ssh/authorized_keys > [root@enfigitfront1-devel ~]# uname -r > 3.10.0-327.36.2.el7.x86_64 > ``` >=20 > We can't keep using the old kernel forever so I'd like to get to the bott= om of this - what could this be due to? How can I debug this further to und= erstand where the "Operation not supported" is coming from? >=20 > ## Server details > Distro: CentOS 7.3 / 7.4 > Kernel (`uname -r`):=20 > * 3.10.0-514.10.2.el7.x86_64 (server) > * 3.10.0-693.2.2.el7.x86_64 (client - new) > * 3.10.0-327.36.2.el7.x86_64 (client - old) > nfs-utils: RPM package version 1.3.0 >=20 > =20 > Server mount option example: > /export/.ssh 172.18.10.148(rw,sync,no_root_squash)=20 > 172.18.10.151(rw,sync,no_root_squash) Add "security_label" to the export options above. If you don't see "securi= ty_label" listed in the exports(5) man page then you need to upgrade your n= fs-utils package. -Scott >=20 > Client mount options (/etc/fstab): > enfigitback2-devel.datcon.co.uk:/export/.ssh /var/opt/gitlab/.ssh n= fs defaults,soft,v4.2,rsize=3D1048576,wsize=3D1048576,noatime,_netdev,l= ookupcache=3Dnone 0 0 >=20 > ## Debugging I've done >=20 > ### Mounting by hand > I tried to mount one of the exported mounts "by hand" using `mount` and f= ound the following: > * mounting the same export on a different mount point using the same=20 > options as in /etc/fstab yields a mount that has the same issue > * mounting with `nosharecache` results in a mount that *does not* have th= e issue. >=20 >=20 Hi Scott, Thank you for pointing out "security_label". I have applied the option... /export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label) 172.18.1= 0.151(rw,sync,no_root_squash,security_label) and rebooted both server and client (in that order), but I still see the sa= me behaviour as before on the server with the uplevel kernel: [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt= /gitlab/.ssh/authorized_keys chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' = to 'system_u:object_r:ssh_home_t:s0': Operation not supported I notice that the exports(5) man page mentions " This will only work if all= clients use a consistent security policy." under security_label. I'm not s= ure what a "consistent security policy" means - what does this mean in term= s of options/configuration?=20 Thanks for the help, Alex ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 2017-11-21 18:30 ` Alexander Hermes @ 2017-11-27 13:51 ` Scott Mayhew 2017-11-27 15:57 ` J. Bruce Fields 0 siblings, 1 reply; 8+ messages in thread From: Scott Mayhew @ 2017-11-27 13:51 UTC (permalink / raw) To: Alexander Hermes; +Cc: linux-nfs On Tue, 21 Nov 2017, Alexander Hermes wrote: > > Folks, > > > > I'm looking for some guidance on how to troubleshoot/debug an issue with (SELinux) labels over NFS that we've been having as a result of a kernel upgrade - description below. > > I looked around on http://linux-nfs.org but was not able to find how to debug this kind of issue with labels - everything I found relates to more fundamental issues like mounts plain not working. > > > > With apologies for sending this to the devel mailing list, could you please help me get to the bottom of this? Or redirect me to somewhere / someone that can? > > > > Thank you very much, > > > > Alexander Hermes > > > > ---- > > > > ## Summary > > > > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label support - attempting to change labels on a mounted file leads to "Operation Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to the earlier kernel version the issue goes away. > > > > ## Background > > > > As part of our gitlab HA deployment we use NFS to host data on a back end server that is then mounted by application servers (cf. https://docs.gitlab.com/ce/administration/high_availability/nfs.html). To do this we have a fairly typical setup where the server (in this example "enfigitback2-devel") exports a bunch of mounts via /etc/exports which are then mounted on a couple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel"). > > > > ## The issue > > > > On the new kernel I am not able to change or view the SELinux labels of files / directories mounted on the client: > > > > ``` > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t > > /var/opt/gitlab/.ssh/authorized_keys > > chcon: failed to change context of > > '/var/opt/gitlab/.ssh/authorized_keys' to > > 'system_u:object_r:ssh_home_t:s0': Operation not supported > > [root@enfigitfront2-devel ~]# uname -r > > 3.10.0-693.2.2.el7.x86_64 > > ``` > > On the old kernel I am: > > > > ``` > > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t > > /var/opt/gitlab/.ssh/authorized_keys > > [root@enfigitfront1-devel ~]# uname -r > > 3.10.0-327.36.2.el7.x86_64 > > ``` > > > > We can't keep using the old kernel forever so I'd like to get to the bottom of this - what could this be due to? How can I debug this further to understand where the "Operation not supported" is coming from? > > > > ## Server details > > Distro: CentOS 7.3 / 7.4 > > Kernel (`uname -r`): > > * 3.10.0-514.10.2.el7.x86_64 (server) > > * 3.10.0-693.2.2.el7.x86_64 (client - new) > > * 3.10.0-327.36.2.el7.x86_64 (client - old) > > nfs-utils: RPM package version 1.3.0 > > > > > > Server mount option example: > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash) > > 172.18.10.151(rw,sync,no_root_squash) > > Add "security_label" to the export options above. If you don't see "security_label" listed in the exports(5) man page then you need to upgrade your nfs-utils package. > > -Scott > > > > > Client mount options (/etc/fstab): > > enfigitback2-devel.datcon.co.uk:/export/.ssh /var/opt/gitlab/.ssh nfs defaults,soft,v4.2,rsize=1048576,wsize=1048576,noatime,_netdev,lookupcache=none 0 0 > > > > ## Debugging I've done > > > > ### Mounting by hand > > I tried to mount one of the exported mounts "by hand" using `mount` and found the following: > > * mounting the same export on a different mount point using the same > > options as in /etc/fstab yields a mount that has the same issue > > * mounting with `nosharecache` results in a mount that *does not* have the issue. > > > > > > > Hi Scott, > > Thank you for pointing out "security_label". I have applied the option... > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label) 172.18.10.151(rw,sync,no_root_squash,security_label) > > and rebooted both server and client (in that order), but I still see the same behaviour as before on the server with the uplevel kernel: > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys > chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' to 'system_u:object_r:ssh_home_t:s0': Operation not supported > > I notice that the exports(5) man page mentions " This will only work if all clients use a consistent security policy." under security_label. I'm not sure what a "consistent security policy" means - what does this mean in terms of options/configuration? I'm assuming that means you don't want some clients using full labeled NFS, others mounting with the context= mount option, and others with SELinux completely disabled. With labeled NFS, the creation and enforcement of labels happens on the client side and the server just stores the labels. Anyways, I missed the fact that your clients are using an earlier kernel. In order to get the desired behavior when mounting an NFS server that is using the "security_label" export option, you're pretty much going to need to run an updated kernel on the clients too... specifically one with commit 0b4d3452b "security/selinux: allow security_sb_clone_mnt_opts to enable/disable native labeling behavior". AFAIK CentOS 7.4 should have it (because RHEL 7.4 has it). -Scott > > Thanks for the help, > Alex > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 2017-11-27 13:51 ` Scott Mayhew @ 2017-11-27 15:57 ` J. Bruce Fields 2017-11-28 10:09 ` Alexander Hermes 0 siblings, 1 reply; 8+ messages in thread From: J. Bruce Fields @ 2017-11-27 15:57 UTC (permalink / raw) To: Scott Mayhew; +Cc: Alexander Hermes, linux-nfs On Mon, Nov 27, 2017 at 08:51:37AM -0500, Scott Mayhew wrote: > On Tue, 21 Nov 2017, Alexander Hermes wrote: > > > > Folks, > > > > > > I'm looking for some guidance on how to troubleshoot/debug an issue with (SELinux) labels over NFS that we've been having as a result of a kernel upgrade - description below. > > > I looked around on http://linux-nfs.org but was not able to find how to debug this kind of issue with labels - everything I found relates to more fundamental issues like mounts plain not working. > > > > > > With apologies for sending this to the devel mailing list, could you please help me get to the bottom of this? Or redirect me to somewhere / someone that can? > > > > > > Thank you very much, > > > > > > Alexander Hermes > > > > > > ---- > > > > > > ## Summary > > > > > > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label support - attempting to change labels on a mounted file leads to "Operation Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to the earlier kernel version the issue goes away. > > > > > > ## Background > > > > > > As part of our gitlab HA deployment we use NFS to host data on a back end server that is then mounted by application servers (cf. https://docs.gitlab.com/ce/administration/high_availability/nfs.html). To do this we have a fairly typical setup where the server (in this example "enfigitback2-devel") exports a bunch of mounts via /etc/exports which are then mounted on a couple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel"). > > > > > > ## The issue > > > > > > On the new kernel I am not able to change or view the SELinux labels of files / directories mounted on the client: > > > > > > ``` > > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t > > > /var/opt/gitlab/.ssh/authorized_keys > > > chcon: failed to change context of > > > '/var/opt/gitlab/.ssh/authorized_keys' to > > > 'system_u:object_r:ssh_home_t:s0': Operation not supported > > > [root@enfigitfront2-devel ~]# uname -r > > > 3.10.0-693.2.2.el7.x86_64 > > > ``` > > > On the old kernel I am: > > > > > > ``` > > > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t > > > /var/opt/gitlab/.ssh/authorized_keys > > > [root@enfigitfront1-devel ~]# uname -r > > > 3.10.0-327.36.2.el7.x86_64 > > > ``` > > > > > > We can't keep using the old kernel forever so I'd like to get to the bottom of this - what could this be due to? How can I debug this further to understand where the "Operation not supported" is coming from? > > > > > > ## Server details > > > Distro: CentOS 7.3 / 7.4 > > > Kernel (`uname -r`): > > > * 3.10.0-514.10.2.el7.x86_64 (server) > > > * 3.10.0-693.2.2.el7.x86_64 (client - new) > > > * 3.10.0-327.36.2.el7.x86_64 (client - old) > > > nfs-utils: RPM package version 1.3.0 > > > > > > > > > Server mount option example: > > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash) > > > 172.18.10.151(rw,sync,no_root_squash) > > > > Add "security_label" to the export options above. If you don't see "security_label" listed in the exports(5) man page then you need to upgrade your nfs-utils package. > > > > -Scott > > > > > > > > Client mount options (/etc/fstab): > > > enfigitback2-devel.datcon.co.uk:/export/.ssh /var/opt/gitlab/.ssh nfs defaults,soft,v4.2,rsize=1048576,wsize=1048576,noatime,_netdev,lookupcache=none 0 0 > > > > > > ## Debugging I've done > > > > > > ### Mounting by hand > > > I tried to mount one of the exported mounts "by hand" using `mount` and found the following: > > > * mounting the same export on a different mount point using the same > > > options as in /etc/fstab yields a mount that has the same issue > > > * mounting with `nosharecache` results in a mount that *does not* have the issue. > > > > > > > > > > > > Hi Scott, > > > > Thank you for pointing out "security_label". I have applied the option... > > > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label) 172.18.10.151(rw,sync,no_root_squash,security_label) > > > > and rebooted both server and client (in that order), but I still see the same behaviour as before on the server with the uplevel kernel: > > > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys > > chcon: failed to change context of '/var/opt/gitlab/.ssh/authorized_keys' to 'system_u:object_r:ssh_home_t:s0': Operation not supported > > > > I notice that the exports(5) man page mentions " This will only work if all clients use a consistent security policy." under security_label. I'm not sure what a "consistent security policy" means - what does this mean in terms of options/configuration? > > I'm assuming that means you don't want some clients using full labeled > NFS, others mounting with the context= mount option, and others with > SELinux completely disabled. With labeled NFS, the creation and > enforcement of labels happens on the client side and the server just > stores the labels. So also for example if the clients disagree about how to label files in your home directory, or something, then things will likely break. I don't know how big a problem that is in practice. --b. > > Anyways, I missed the fact that your clients are using an earlier > kernel. In order to get the desired behavior when mounting an NFS > server that is using the "security_label" export option, you're pretty > much going to need to run an updated kernel on the clients too... > specifically one with commit 0b4d3452b "security/selinux: allow > security_sb_clone_mnt_opts to enable/disable native labeling behavior". > AFAIK CentOS 7.4 should have it (because RHEL 7.4 has it). > > -Scott > > > > > > Thanks for the help, > > Alex > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 2017-11-27 15:57 ` J. Bruce Fields @ 2017-11-28 10:09 ` Alexander Hermes 2017-11-28 17:23 ` Scott Mayhew 0 siblings, 1 reply; 8+ messages in thread From: Alexander Hermes @ 2017-11-28 10:09 UTC (permalink / raw) To: J. Bruce Fields, Scott Mayhew; +Cc: linux-nfs > On Tue, 21 Nov 2017, Alexander Hermes wrote: >=20 > > > Folks, > > >=20 > > > I'm looking for some guidance on how to troubleshoot/debug an issue w= ith (SELinux) labels over NFS that we've been having as a result of a kerne= l upgrade - description below. > > > I looked around on http://linux-nfs.org but was not able to find how = to debug this kind of issue with labels - everything I found relates to mor= e fundamental issues like mounts plain not working.=20 > > >=20 > > > With apologies for sending this to the devel mailing list, could you = please help me get to the bottom of this? Or redirect me to somewhere / som= eone that can? > > >=20 > > > Thank you very much, > > >=20 > > > Alexander Hermes > > >=20 > > > ---- > > >=20 > > > ## Summary > > >=20 > > > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kerne= l from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result= , NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux= label support - attempting to change labels on a mounted file leads to "Op= eration Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting= to the earlier kernel version the issue goes away. > > >=20 > > > ## Background > > >=20 > > > As part of our gitlab HA deployment we use NFS to host data on a back= end server that is then mounted by application servers (cf. https://docs.g= itlab.com/ce/administration/high_availability/nfs.html). To do this we have= a fairly typical setup where the server (in this example "enfigitback2-dev= el") exports a bunch of mounts via /etc/exports which are then mounted on a= couple of application servers ("enfigitfront1-devel" / "enfigitfront2-deve= l"). > > >=20 > > > ## The issue > > >=20 > > > On the new kernel I am not able to change or view the SELinux labels = of files / directories mounted on the client: > > >=20 > > > ``` > > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t=20 > > > /var/opt/gitlab/.ssh/authorized_keys > > > chcon: failed to change context of=20 > > > '/var/opt/gitlab/.ssh/authorized_keys' to > > > 'system_u:object_r:ssh_home_t:s0': Operation not supported=20 > > > [root@enfigitfront2-devel ~]# uname -r > > > 3.10.0-693.2.2.el7.x86_64 > > > ``` > > > On the old kernel I am: > > >=20 > > > ``` > > > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t=20 > > > /var/opt/gitlab/.ssh/authorized_keys > > > [root@enfigitfront1-devel ~]# uname -r > > > 3.10.0-327.36.2.el7.x86_64 > > > ``` > > >=20 > > > We can't keep using the old kernel forever so I'd like to get to the = bottom of this - what could this be due to? How can I debug this further to= understand where the "Operation not supported" is coming from? > > >=20 > > > ## Server details > > > Distro: CentOS 7.3 / 7.4 > > > Kernel (`uname -r`):=20 > > > * 3.10.0-514.10.2.el7.x86_64 (server) > > > * 3.10.0-693.2.2.el7.x86_64 (client - new) > > > * 3.10.0-327.36.2.el7.x86_64 (client - old) > > > nfs-utils: RPM package version 1.3.0 > > >=20 > > > =20 > > > Server mount option example: > > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash) > > > 172.18.10.151(rw,sync,no_root_squash) > >=20 > > Add "security_label" to the export options above. If you don't see "se= curity_label" listed in the exports(5) man page then you need to upgrade yo= ur nfs-utils package. > >=20 > > -Scott > >=20 > > >=20 > > > Client mount options (/etc/fstab): > > > enfigitback2-devel.datcon.co.uk:/export/.ssh /var/opt/gitlab/.ssh = nfs defaults,soft,v4.2,rsize=3D1048576,wsize=3D1048576,noatime,_netd= ev,lookupcache=3Dnone 0 0 > > >=20 > > > ## Debugging I've done > > >=20 > > > ### Mounting by hand > > > I tried to mount one of the exported mounts "by hand" using `mount` a= nd found the following: > > > * mounting the same export on a different mount point using the=20 > > > same options as in /etc/fstab yields a mount that has the same=20 > > > issue > > > * mounting with `nosharecache` results in a mount that *does not* hav= e the issue. > > >=20 > > >=20 > >=20 > >=20 > > Hi Scott, > >=20 > > Thank you for pointing out "security_label". I have applied the option.= .. > >=20 > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label)=20 > > 172.18.10.151(rw,sync,no_root_squash,security_label) > >=20 > > and rebooted both server and client (in that order), but I still see th= e same behaviour as before on the server with the uplevel kernel: > >=20 > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var= /opt/gitlab/.ssh/authorized_keys > > chcon: failed to change context of=20 > > '/var/opt/gitlab/.ssh/authorized_keys' to=20 > > 'system_u:object_r:ssh_home_t:s0': Operation not supported > >=20 > > I notice that the exports(5) man page mentions " This will only work if= all clients use a consistent security policy." under security_label. I'm n= ot sure what a "consistent security policy" means - what does this mean in = terms of options/configuration?=20 >=20 > I'm assuming that means you don't want some clients using full=20 > labeled NFS, others mounting with the context=3D mount option, and=20 > others with SELinux completely disabled. With labeled NFS, the=20 > creation and enforcement of labels happens on the client side and the=20 > server just stores the labels. So also for example if the clients disagree about how to label files in you= r home directory, or something, then things will likely break. I don't kno= w how big a problem that is in practice. --b. >=20 > Anyways, I missed the fact that your clients are using an earlier=20 > kernel. In order to get the desired behavior when mounting an NFS=20 > server that is using the "security_label" export option, you're pretty=20 > much going to need to run an updated kernel on the clients too... > specifically one with commit 0b4d3452b "security/selinux: allow=20 > security_sb_clone_mnt_opts to enable/disable native labeling behavior". > AFAIK CentOS 7.4 should have it (because RHEL 7.4 has it). >=20 > -Scott >=20 >=20 > >=20 > > Thanks for the help, > > Alex > > -- Hi, Thanks for the reply. Yes, I imagine there'd be problems if clients are con= fused about what labels are applied, but I just wanted to check if anyone k= new of that actually preventing other clients from reading or setting label= s at all (throwing "Operation not supported" errors). It sounds from what y= ou are saying like that is _not_ the case. Scott, I just want to clarify your comment about clients using an earlier k= ernel. Since my original message we now have the following kernels Server: 3.10.0-693.5.2.el7.x86_64 Client (working): 3.10.0-327.36.2.el7.x86_64 Client (non-working): 3.10.0-693.2.2.el7.x86_64 So it's the _working_ client which has the down-level kernel. Are you sayin= g it needs to be up-level also for this to work? Or do you mean that all of= the versions are too old somehow?=20 This was working when all servers were down-level (CentOS 7.3 kernel so 3.1= 0-327) _without_ the "security_label" exports option - did the new kernel t= ighten the security such that this is now required? Separately, do either of you know of a sensible way I can debug the root ca= use for the issue further (to get a more detail why "Operation not supporte= d" is thrown)? I don't know the kernel source at all so just reading the co= de is not viable for me (without some guidance), but is there some logging = or more verbose output I can turn on? Alex ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 2017-11-28 10:09 ` Alexander Hermes @ 2017-11-28 17:23 ` Scott Mayhew 2017-11-29 15:52 ` Alexander Hermes 0 siblings, 1 reply; 8+ messages in thread From: Scott Mayhew @ 2017-11-28 17:23 UTC (permalink / raw) To: Alexander Hermes; +Cc: J. Bruce Fields, linux-nfs On Tue, 28 Nov 2017, Alexander Hermes wrote: > > On Tue, 21 Nov 2017, Alexander Hermes wrote: > > > > > > Folks, > > > > > > > > I'm looking for some guidance on how to troubleshoot/debug an issue with (SELinux) labels over NFS that we've been having as a result of a kernel upgrade - description below. > > > > I looked around on http://linux-nfs.org but was not able to find how to debug this kind of issue with labels - everything I found relates to more fundamental issues like mounts plain not working. > > > > > > > > With apologies for sending this to the devel mailing list, could you please help me get to the bottom of this? Or redirect me to somewhere / someone that can? > > > > > > > > Thank you very much, > > > > > > > > Alexander Hermes > > > > > > > > ---- > > > > > > > > ## Summary > > > > > > > > In upgrading our servers from CentOS 7.3 to 7.4 we upgraded the kernel from 3.10.0-327.36.2.el7.x86_64 to 3.10.0-693.2.2.el7.x86_64. As a result, NFS v4.2 mounts mounted via /etc/fstab at boot do not have proper SElinux label support - attempting to change labels on a mounted file leads to "Operation Not Supported". `ls -lZ` shows the incorrect labels. Upon rebooting to the earlier kernel version the issue goes away. > > > > > > > > ## Background > > > > > > > > As part of our gitlab HA deployment we use NFS to host data on a back end server that is then mounted by application servers (cf. https://docs.gitlab.com/ce/administration/high_availability/nfs.html). To do this we have a fairly typical setup where the server (in this example "enfigitback2-devel") exports a bunch of mounts via /etc/exports which are then mounted on a couple of application servers ("enfigitfront1-devel" / "enfigitfront2-devel"). > > > > > > > > ## The issue > > > > > > > > On the new kernel I am not able to change or view the SELinux labels of files / directories mounted on the client: > > > > > > > > ``` > > > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t > > > > /var/opt/gitlab/.ssh/authorized_keys > > > > chcon: failed to change context of > > > > '/var/opt/gitlab/.ssh/authorized_keys' to > > > > 'system_u:object_r:ssh_home_t:s0': Operation not supported > > > > [root@enfigitfront2-devel ~]# uname -r > > > > 3.10.0-693.2.2.el7.x86_64 > > > > ``` > > > > On the old kernel I am: > > > > > > > > ``` > > > > [root@enfigitfront1-devel ~]# chcon --recursive --type ssh_home_t > > > > /var/opt/gitlab/.ssh/authorized_keys > > > > [root@enfigitfront1-devel ~]# uname -r > > > > 3.10.0-327.36.2.el7.x86_64 > > > > ``` > > > > > > > > We can't keep using the old kernel forever so I'd like to get to the bottom of this - what could this be due to? How can I debug this further to understand where the "Operation not supported" is coming from? > > > > > > > > ## Server details > > > > Distro: CentOS 7.3 / 7.4 > > > > Kernel (`uname -r`): > > > > * 3.10.0-514.10.2.el7.x86_64 (server) > > > > * 3.10.0-693.2.2.el7.x86_64 (client - new) > > > > * 3.10.0-327.36.2.el7.x86_64 (client - old) > > > > nfs-utils: RPM package version 1.3.0 > > > > > > > > > > > > Server mount option example: > > > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash) > > > > 172.18.10.151(rw,sync,no_root_squash) > > > > > > Add "security_label" to the export options above. If you don't see "security_label" listed in the exports(5) man page then you need to upgrade your nfs-utils package. > > > > > > -Scott > > > > > > > > > > > Client mount options (/etc/fstab): > > > > enfigitback2-devel.datcon.co.uk:/export/.ssh /var/opt/gitlab/.ssh nfs defaults,soft,v4.2,rsize=1048576,wsize=1048576,noatime,_netdev,lookupcache=none 0 0 > > > > > > > > ## Debugging I've done > > > > > > > > ### Mounting by hand > > > > I tried to mount one of the exported mounts "by hand" using `mount` and found the following: > > > > * mounting the same export on a different mount point using the > > > > same options as in /etc/fstab yields a mount that has the same > > > > issue > > > > * mounting with `nosharecache` results in a mount that *does not* have the issue. > > > > > > > > > > > > > > > > > Hi Scott, > > > > > > Thank you for pointing out "security_label". I have applied the option... > > > > > > /export/.ssh 172.18.10.148(rw,sync,no_root_squash,security_label) > > > 172.18.10.151(rw,sync,no_root_squash,security_label) > > > > > > and rebooted both server and client (in that order), but I still see the same behaviour as before on the server with the uplevel kernel: > > > > > > [root@enfigitfront2-devel ~]# chcon --recursive --type ssh_home_t /var/opt/gitlab/.ssh/authorized_keys > > > chcon: failed to change context of > > > '/var/opt/gitlab/.ssh/authorized_keys' to > > > 'system_u:object_r:ssh_home_t:s0': Operation not supported > > > > > > I notice that the exports(5) man page mentions " This will only work if all clients use a consistent security policy." under security_label. I'm not sure what a "consistent security policy" means - what does this mean in terms of options/configuration? > > > > I'm assuming that means you don't want some clients using full > > labeled NFS, others mounting with the context= mount option, and > > others with SELinux completely disabled. With labeled NFS, the > > creation and enforcement of labels happens on the client side and the > > server just stores the labels. > > So also for example if the clients disagree about how to label files in your home directory, or something, then things will likely break. I don't know how big a problem that is in practice. > > --b. > > > > > Anyways, I missed the fact that your clients are using an earlier > > kernel. In order to get the desired behavior when mounting an NFS > > server that is using the "security_label" export option, you're pretty > > much going to need to run an updated kernel on the clients too... > > specifically one with commit 0b4d3452b "security/selinux: allow > > security_sb_clone_mnt_opts to enable/disable native labeling behavior". > > AFAIK CentOS 7.4 should have it (because RHEL 7.4 has it). > > > > -Scott > > > > > > > > > > Thanks for the help, > > > Alex > > > -- > > Hi, > > Thanks for the reply. Yes, I imagine there'd be problems if clients are confused about what labels are applied, but I just wanted to check if anyone knew of that actually preventing other clients from reading or setting labels at all (throwing "Operation not supported" errors). It sounds from what you are saying like that is _not_ the case. That's correct. > > Scott, I just want to clarify your comment about clients using an earlier kernel. Since my original message we now have the following kernels > > Server: 3.10.0-693.5.2.el7.x86_64 > Client (working): 3.10.0-327.36.2.el7.x86_64 > Client (non-working): 3.10.0-693.2.2.el7.x86_64 > > So it's the _working_ client which has the down-level kernel. That's the opposite from what I'm seeing if I install the RHEL kernels corresponding to the CentOS versions you have listed. > Are you saying it needs to be up-level also for this to work? Or do you mean that all of the versions are too old somehow? > This was working when all servers were down-level (CentOS 7.3 kernel so 3.10-327) _without_ the "security_label" exports option - did the new kernel tighten the security such that this is now required? Yes, I was saying that in order to use the "security_label" option, your NFS server and NFS clients need to be running 7.4 kernels. But it sounds like there's something else going on here that I'm not understanding. Here's what I see when I install the same kernel versions that you have. On my NFS server I have a single export with the "security_label" option: [root@nfsserver ~]# uname -r 3.10.0-693.5.2.el7.x86_64 [root@nfsserver ~]# cat /etc/exports /export *(rw,insecure,no_root_squash,security_label) [root@nfsserver ~]# exportfs -v /export <world>(rw,sync,wdelay,hide,no_subtree_check,security_label,sec=sys,insecure,no_root_squash,no_all_squash) If I mount using the older kernel, I can see the label but I can't change it: [root@rhel72 ~]# uname -r 3.10.0-327.36.2.el7.x86_64 [root@rhel72 ~]# mount -o v4.2 nfsserver:/export /mnt/t [root@rhel72 ~]# ls -Z /mnt/t/file -rw-r--r--. root root system_u:object_r:etc_t:s0 /mnt/t/file [root@rhel72 ~]# chcon -t usr_t /mnt/t/file chcon: failed to change context of ‘/mnt/t/file’ to ‘system_u:object_r:usr_t:s0’: Operation not supported If I mount using the newer kernel, I can see and change the label: [root@rhel74 ~]# uname -r 3.10.0-693.2.2.el7.x86_64 [root@rhel74 ~]# mount -o v4.2 nfsserver:/export /mnt/t [root@rhel74 ~]# ls -Z /mnt/t -rw-r--r--. root root system_u:object_r:etc_t:s0 file [root@rhel74 ~]# chcon -t usr_t /mnt/t/file [root@rhel74 ~]# ls -Z /mnt/t -rw-r--r--. root root system_u:object_r:usr_t:s0 file To answer your question, on the NFS server side the older kernel would always send the individual security labels and a change was made to make that behavior be opt-in because it was causing problems for some users (Bruce can correct me on that if I'm wrong). On the client side there was a problem with setting the appropriate flag on the superblock that had to do with the way NFSv4 mounts are done. The client mounts the NFSv4 root and then does a path walk to the real export. When it gets to the real export it clones the superblock from the NFSv4 root. The flag was not getting set on the clone. That's what the commit that I pointed out earlier was fixing. > > Separately, do either of you know of a sensible way I can debug the root cause for the issue further (to get a more detail why "Operation not supported" is thrown)? I don't know the kernel source at all so just reading the code is not viable for me (without some guidance), but is there some logging or more verbose output I can turn on? There isn't really any verbose logging that I can think of. When you get "Operation not supported" from chcon, it pretty much means that the mount doesn't have the SBLABEL_MNT flag set (RHEL uses an older flag SE_SBLABELSUPP but it's really the same thing). You can see whether the flag is set by looking for the text "seclabel" in the mount options for your mount in /proc/mounts. On the older kernel I see this: [root@rhel72 ~]# grep nfs4 /proc/mounts nfsserver:/export /mnt/t nfs4 rw,relatime,vers=4.2,rsize=524288,wsize=524288,... and on the newer kernel I see this: [root@rhel74 ~]# grep nfs4 /proc/mounts nfsserver:/export /mnt/t nfs4 rw,seclabel,relatime,vers=4.2,rsize=524288,wsize=524288,... ^^^^^^^^ The other thing you can look at is the caps field in /proc/self/mountstats. If the server has security labels enabled then the caps field will have NFS_CAP_SECURITY_LABEL set, which is defined as #define NFS_CAP_SECURITY_LABEL (1U << 18) You can take the value from the caps field and plug it into a bash printf [root@rhel74 ~]# grep caps /proc/self/mountstats caps: caps=0x1ffffdf,wtmult=512,dtsize=32768,bsize=0,namlen=255 [root@rhel74 ~]# printf "%x\n" $(( 0x1ffffdf & (1<<18) )) 40000 If you see 0 instead of 40000 then NFS_CAP_SECURITY_LABEL isn't set. On the older kernel I still see NFS_CAP_SECURITY_LABEL set: [root@rhel72 ~]# grep caps /proc/self/mountstats caps: caps=0x3fffff,wtmult=512,dtsize=32768,bsize=0,namlen=255 [root@rhel72 ~]# printf "%x\n" $(( 0x3fffff & (1<<18) )) 40000 So in my case the chcon is failing on the older kernel due to the absence of the SBLABEL_MNT/SE_SBLABELSUPP flag. -Scott > > Alex ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 2017-11-28 17:23 ` Scott Mayhew @ 2017-11-29 15:52 ` Alexander Hermes 0 siblings, 0 replies; 8+ messages in thread From: Alexander Hermes @ 2017-11-29 15:52 UTC (permalink / raw) To: Scott Mayhew; +Cc: J. Bruce Fields, linux-nfs PiA+IE9uIFR1ZSwgMjEgTm92IDIwMTcsIEFsZXhhbmRlciBIZXJtZXMgd3JvdGU6DQo+ID4gDQo+ ID4gPiA+IEZvbGtzLA0KPiA+ID4gPiANCj4gPiA+ID4gSSdtIGxvb2tpbmcgZm9yIHNvbWUgZ3Vp ZGFuY2Ugb24gaG93IHRvIHRyb3VibGVzaG9vdC9kZWJ1ZyBhbiBpc3N1ZSB3aXRoIChTRUxpbnV4 KSBsYWJlbHMgb3ZlciBORlMgdGhhdCB3ZSd2ZSBiZWVuIGhhdmluZyBhcyBhIHJlc3VsdCBvZiBh IGtlcm5lbCB1cGdyYWRlIC0gZGVzY3JpcHRpb24gYmVsb3cuDQo+ID4gPiA+IEkgbG9va2VkIGFy b3VuZCBvbiBodHRwOi8vbGludXgtbmZzLm9yZyBidXQgd2FzIG5vdCBhYmxlIHRvIGZpbmQgaG93 IHRvIGRlYnVnIHRoaXMga2luZCBvZiBpc3N1ZSB3aXRoIGxhYmVscyAtIGV2ZXJ5dGhpbmcgSSBm b3VuZCByZWxhdGVzIHRvIG1vcmUgZnVuZGFtZW50YWwgaXNzdWVzIGxpa2UgbW91bnRzIHBsYWlu IG5vdCB3b3JraW5nLiANCj4gPiA+ID4gDQo+ID4gPiA+IFdpdGggYXBvbG9naWVzIGZvciBzZW5k aW5nIHRoaXMgdG8gdGhlIGRldmVsIG1haWxpbmcgbGlzdCwgY291bGQgeW91IHBsZWFzZSBoZWxw IG1lIGdldCB0byB0aGUgYm90dG9tIG9mIHRoaXM/IE9yIHJlZGlyZWN0IG1lIHRvIHNvbWV3aGVy ZSAvIHNvbWVvbmUgdGhhdCBjYW4/DQo+ID4gPiA+IA0KPiA+ID4gPiBUaGFuayB5b3UgdmVyeSBt dWNoLA0KPiA+ID4gPiANCj4gPiA+ID4gQWxleGFuZGVyIEhlcm1lcw0KPiA+ID4gPiANCj4gPiA+ ID4gLS0tLQ0KPiA+ID4gPiANCj4gPiA+ID4gIyMgU3VtbWFyeQ0KPiA+ID4gPiANCj4gPiA+ID4g SW4gdXBncmFkaW5nIG91ciBzZXJ2ZXJzIGZyb20gQ2VudE9TIDcuMyB0byA3LjQgd2UgdXBncmFk ZWQgdGhlIGtlcm5lbCBmcm9tIDMuMTAuMC0zMjcuMzYuMi5lbDcueDg2XzY0IHRvIDMuMTAuMC02 OTMuMi4yLmVsNy54ODZfNjQuIEFzIGEgcmVzdWx0LCBORlMgdjQuMiBtb3VudHMgbW91bnRlZCB2 aWEgL2V0Yy9mc3RhYiBhdCBib290IGRvIG5vdCBoYXZlIHByb3BlciBTRWxpbnV4IGxhYmVsIHN1 cHBvcnQgLSBhdHRlbXB0aW5nIHRvIGNoYW5nZSBsYWJlbHMgb24gYSBtb3VudGVkIGZpbGUgbGVh ZHMgdG8gIk9wZXJhdGlvbiBOb3QgU3VwcG9ydGVkIi4gYGxzIC1sWmAgc2hvd3MgdGhlIGluY29y cmVjdCBsYWJlbHMuIFVwb24gcmVib290aW5nIHRvIHRoZSBlYXJsaWVyIGtlcm5lbCB2ZXJzaW9u IHRoZSBpc3N1ZSBnb2VzIGF3YXkuDQo+ID4gPiA+IA0KPiA+ID4gPiAjIyBCYWNrZ3JvdW5kDQo+ ID4gPiA+IA0KPiA+ID4gPiBBcyBwYXJ0IG9mIG91ciBnaXRsYWIgSEEgZGVwbG95bWVudCB3ZSB1 c2UgTkZTIHRvIGhvc3QgZGF0YSBvbiBhIGJhY2sgZW5kIHNlcnZlciB0aGF0IGlzIHRoZW4gbW91 bnRlZCBieSBhcHBsaWNhdGlvbiBzZXJ2ZXJzIChjZi4gaHR0cHM6Ly9kb2NzLmdpdGxhYi5jb20v Y2UvYWRtaW5pc3RyYXRpb24vaGlnaF9hdmFpbGFiaWxpdHkvbmZzLmh0bWwpLiBUbyBkbyB0aGlz IHdlIGhhdmUgYSBmYWlybHkgdHlwaWNhbCBzZXR1cCB3aGVyZSB0aGUgc2VydmVyIChpbiB0aGlz IGV4YW1wbGUgImVuZmlnaXRiYWNrMi1kZXZlbCIpIGV4cG9ydHMgYSBidW5jaCBvZiBtb3VudHMg dmlhIC9ldGMvZXhwb3J0cyB3aGljaCBhcmUgdGhlbiBtb3VudGVkIG9uIGEgY291cGxlIG9mIGFw cGxpY2F0aW9uIHNlcnZlcnMgKCJlbmZpZ2l0ZnJvbnQxLWRldmVsIiAvICJlbmZpZ2l0ZnJvbnQy LWRldmVsIikuDQo+ID4gPiA+IA0KPiA+ID4gPiAjIyBUaGUgaXNzdWUNCj4gPiA+ID4gDQo+ID4g PiA+IE9uIHRoZSBuZXcga2VybmVsIEkgYW0gbm90IGFibGUgdG8gY2hhbmdlIG9yIHZpZXcgdGhl IFNFTGludXggbGFiZWxzIG9mIGZpbGVzIC8gZGlyZWN0b3JpZXMgbW91bnRlZCBvbiB0aGUgY2xp ZW50Og0KPiA+ID4gPiANCj4gPiA+ID4gYGBgDQo+ID4gPiA+IFtyb290QGVuZmlnaXRmcm9udDIt ZGV2ZWwgfl0jIGNoY29uIC0tcmVjdXJzaXZlIC0tdHlwZSANCj4gPiA+ID4gc3NoX2hvbWVfdCAv dmFyL29wdC9naXRsYWIvLnNzaC9hdXRob3JpemVkX2tleXMNCj4gPiA+ID4gY2hjb246IGZhaWxl ZCB0byBjaGFuZ2UgY29udGV4dCBvZiANCj4gPiA+ID4gJy92YXIvb3B0L2dpdGxhYi8uc3NoL2F1 dGhvcml6ZWRfa2V5cycgdG8NCj4gPiA+ID4gJ3N5c3RlbV91Om9iamVjdF9yOnNzaF9ob21lX3Q6 czAnOiBPcGVyYXRpb24gbm90IHN1cHBvcnRlZCANCj4gPiA+ID4gW3Jvb3RAZW5maWdpdGZyb250 Mi1kZXZlbCB+XSMgdW5hbWUgLXINCj4gPiA+ID4gMy4xMC4wLTY5My4yLjIuZWw3Lng4Nl82NA0K PiA+ID4gPiBgYGANCj4gPiA+ID4gT24gdGhlIG9sZCBrZXJuZWwgSSBhbToNCj4gPiA+ID4gDQo+ ID4gPiA+IGBgYA0KPiA+ID4gPiBbcm9vdEBlbmZpZ2l0ZnJvbnQxLWRldmVsIH5dIyBjaGNvbiAt LXJlY3Vyc2l2ZSAtLXR5cGUgDQo+ID4gPiA+IHNzaF9ob21lX3QgL3Zhci9vcHQvZ2l0bGFiLy5z c2gvYXV0aG9yaXplZF9rZXlzDQo+ID4gPiA+IFtyb290QGVuZmlnaXRmcm9udDEtZGV2ZWwgfl0j IHVuYW1lIC1yDQo+ID4gPiA+IDMuMTAuMC0zMjcuMzYuMi5lbDcueDg2XzY0DQo+ID4gPiA+IGBg YA0KPiA+ID4gPiANCj4gPiA+ID4gV2UgY2FuJ3Qga2VlcCB1c2luZyB0aGUgb2xkIGtlcm5lbCBm b3JldmVyIHNvIEknZCBsaWtlIHRvIGdldCB0byB0aGUgYm90dG9tIG9mIHRoaXMgLSB3aGF0IGNv dWxkIHRoaXMgYmUgZHVlIHRvPyBIb3cgY2FuIEkgZGVidWcgdGhpcyBmdXJ0aGVyIHRvIHVuZGVy c3RhbmQgd2hlcmUgdGhlICJPcGVyYXRpb24gbm90IHN1cHBvcnRlZCIgaXMgY29taW5nIGZyb20/ DQo+ID4gPiA+IA0KPiA+ID4gPiAjIyBTZXJ2ZXIgZGV0YWlscw0KPiA+ID4gPiBEaXN0cm86IENl bnRPUyA3LjMgLyA3LjQNCj4gPiA+ID4gS2VybmVsIChgdW5hbWUgLXJgKTogDQo+ID4gPiA+ICAq IDMuMTAuMC01MTQuMTAuMi5lbDcueDg2XzY0IChzZXJ2ZXIpDQo+ID4gPiA+ICogMy4xMC4wLTY5 My4yLjIuZWw3Lng4Nl82NCAoY2xpZW50IC0gbmV3KQ0KPiA+ID4gPiAqIDMuMTAuMC0zMjcuMzYu Mi5lbDcueDg2XzY0IChjbGllbnQgLSBvbGQpDQo+ID4gPiA+IG5mcy11dGlsczogUlBNIHBhY2th Z2UgdmVyc2lvbiAxLjMuMA0KPiA+ID4gPiANCj4gPiA+ID4gIA0KPiA+ID4gPiBTZXJ2ZXIgbW91 bnQgb3B0aW9uIGV4YW1wbGU6DQo+ID4gPiA+IC9leHBvcnQvLnNzaCAxNzIuMTguMTAuMTQ4KHJ3 LHN5bmMsbm9fcm9vdF9zcXVhc2gpDQo+ID4gPiA+IDE3Mi4xOC4xMC4xNTEocncsc3luYyxub19y b290X3NxdWFzaCkNCj4gPiA+IA0KPiA+ID4gQWRkICJzZWN1cml0eV9sYWJlbCIgdG8gdGhlIGV4 cG9ydCBvcHRpb25zIGFib3ZlLiAgSWYgeW91IGRvbid0IHNlZSAic2VjdXJpdHlfbGFiZWwiIGxp c3RlZCBpbiB0aGUgZXhwb3J0cyg1KSBtYW4gcGFnZSB0aGVuIHlvdSBuZWVkIHRvIHVwZ3JhZGUg eW91ciBuZnMtdXRpbHMgcGFja2FnZS4NCj4gPiA+IA0KPiA+ID4gLVNjb3R0DQo+ID4gPiANCj4g PiA+ID4gDQo+ID4gPiA+IENsaWVudCBtb3VudCBvcHRpb25zICgvZXRjL2ZzdGFiKToNCj4gPiA+ ID4gZW5maWdpdGJhY2syLWRldmVsLmRhdGNvbi5jby51azovZXhwb3J0Ly5zc2ggICAgL3Zhci9v cHQvZ2l0bGFiLy5zc2ggICAgbmZzICAgICBkZWZhdWx0cyxzb2Z0LHY0LjIscnNpemU9MTA0ODU3 Nix3c2l6ZT0xMDQ4NTc2LG5vYXRpbWUsX25ldGRldixsb29rdXBjYWNoZT1ub25lIDAgICAgICAg MA0KPiA+ID4gPiANCj4gPiA+ID4gIyMgRGVidWdnaW5nIEkndmUgZG9uZQ0KPiA+ID4gPiANCj4g PiA+ID4gIyMjIE1vdW50aW5nIGJ5IGhhbmQNCj4gPiA+ID4gSSB0cmllZCB0byBtb3VudCBvbmUg b2YgdGhlIGV4cG9ydGVkIG1vdW50cyAiYnkgaGFuZCIgdXNpbmcgYG1vdW50YCBhbmQgZm91bmQg dGhlIGZvbGxvd2luZzoNCj4gPiA+ID4gKiBtb3VudGluZyB0aGUgc2FtZSBleHBvcnQgb24gYSBk aWZmZXJlbnQgbW91bnQgcG9pbnQgdXNpbmcgdGhlIA0KPiA+ID4gPiBzYW1lIG9wdGlvbnMgYXMg aW4gL2V0Yy9mc3RhYiB5aWVsZHMgYSBtb3VudCB0aGF0IGhhcyB0aGUgc2FtZSANCj4gPiA+ID4g aXNzdWUNCj4gPiA+ID4gKiBtb3VudGluZyB3aXRoIGBub3NoYXJlY2FjaGVgIHJlc3VsdHMgaW4g YSBtb3VudCB0aGF0ICpkb2VzIG5vdCogaGF2ZSB0aGUgaXNzdWUuDQo+ID4gPiA+IA0KPiA+ID4g PiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBIaSBTY290dCwNCj4gPiA+IA0KPiA+ID4gVGhhbmsg eW91IGZvciBwb2ludGluZyBvdXQgInNlY3VyaXR5X2xhYmVsIi4gSSBoYXZlIGFwcGxpZWQgdGhl IG9wdGlvbi4uLg0KPiA+ID4gDQo+ID4gPiAJL2V4cG9ydC8uc3NoIDE3Mi4xOC4xMC4xNDgocncs c3luYyxub19yb290X3NxdWFzaCxzZWN1cml0eV9sYWJlbCkNCj4gPiA+IDE3Mi4xOC4xMC4xNTEo cncsc3luYyxub19yb290X3NxdWFzaCxzZWN1cml0eV9sYWJlbCkNCj4gPiA+IA0KPiA+ID4gYW5k IHJlYm9vdGVkIGJvdGggc2VydmVyIGFuZCBjbGllbnQgKGluIHRoYXQgb3JkZXIpLCBidXQgSSBz dGlsbCBzZWUgdGhlIHNhbWUgYmVoYXZpb3VyIGFzIGJlZm9yZSBvbiB0aGUgc2VydmVyIHdpdGgg dGhlIHVwbGV2ZWwga2VybmVsOg0KPiA+ID4gDQo+ID4gPiAJW3Jvb3RAZW5maWdpdGZyb250Mi1k ZXZlbCB+XSMgY2hjb24gLS1yZWN1cnNpdmUgLS10eXBlIHNzaF9ob21lX3QgL3Zhci9vcHQvZ2l0 bGFiLy5zc2gvYXV0aG9yaXplZF9rZXlzDQo+ID4gPiAJY2hjb246IGZhaWxlZCB0byBjaGFuZ2Ug Y29udGV4dCBvZiANCj4gPiA+ICcvdmFyL29wdC9naXRsYWIvLnNzaC9hdXRob3JpemVkX2tleXMn IHRvDQo+ID4gPiAnc3lzdGVtX3U6b2JqZWN0X3I6c3NoX2hvbWVfdDpzMCc6IE9wZXJhdGlvbiBu b3Qgc3VwcG9ydGVkDQo+ID4gPiANCj4gPiA+IEkgbm90aWNlIHRoYXQgdGhlIGV4cG9ydHMoNSkg bWFuIHBhZ2UgbWVudGlvbnMgIiBUaGlzIHdpbGwgb25seSB3b3JrIGlmIGFsbCBjbGllbnRzIHVz ZSBhIGNvbnNpc3RlbnQgc2VjdXJpdHkgcG9saWN5LiIgdW5kZXIgc2VjdXJpdHlfbGFiZWwuIEkn bSBub3Qgc3VyZSB3aGF0IGEgImNvbnNpc3RlbnQgc2VjdXJpdHkgcG9saWN5IiBtZWFucyAtIHdo YXQgZG9lcyB0aGlzIG1lYW4gaW4gdGVybXMgb2Ygb3B0aW9ucy9jb25maWd1cmF0aW9uPyANCj4g PiANCj4gPiBJJ20gYXNzdW1pbmcgIHRoYXQgbWVhbnMgeW91IGRvbid0IHdhbnQgc29tZSBjbGll bnRzIHVzaW5nIGZ1bGwgDQo+ID4gbGFiZWxlZCBORlMsIG90aGVycyBtb3VudGluZyB3aXRoIHRo ZSBjb250ZXh0PSBtb3VudCBvcHRpb24sIGFuZCANCj4gPiBvdGhlcnMgd2l0aCBTRUxpbnV4IGNv bXBsZXRlbHkgZGlzYWJsZWQuICBXaXRoIGxhYmVsZWQgTkZTLCB0aGUgDQo+ID4gY3JlYXRpb24g YW5kIGVuZm9yY2VtZW50IG9mIGxhYmVscyBoYXBwZW5zIG9uIHRoZSBjbGllbnQgc2lkZSBhbmQg DQo+ID4gdGhlIHNlcnZlciBqdXN0IHN0b3JlcyB0aGUgbGFiZWxzLg0KPiANCj4gU28gYWxzbyBm b3IgZXhhbXBsZSBpZiB0aGUgY2xpZW50cyBkaXNhZ3JlZSBhYm91dCBob3cgdG8gbGFiZWwgZmls ZXMgaW4geW91ciBob21lIGRpcmVjdG9yeSwgb3Igc29tZXRoaW5nLCB0aGVuIHRoaW5ncyB3aWxs IGxpa2VseSBicmVhay4gIEkgZG9uJ3Qga25vdyBob3cgYmlnIGEgcHJvYmxlbSB0aGF0IGlzIGlu IHByYWN0aWNlLg0KPiANCj4gLS1iLg0KPiANCj4gPiANCj4gPiBBbnl3YXlzLCBJIG1pc3NlZCB0 aGUgZmFjdCB0aGF0IHlvdXIgY2xpZW50cyBhcmUgdXNpbmcgYW4gZWFybGllciANCj4gPiBrZXJu ZWwuICBJbiBvcmRlciB0byBnZXQgdGhlIGRlc2lyZWQgYmVoYXZpb3Igd2hlbiBtb3VudGluZyBh biBORlMgDQo+ID4gc2VydmVyIHRoYXQgaXMgdXNpbmcgdGhlICJzZWN1cml0eV9sYWJlbCIgZXhw b3J0IG9wdGlvbiwgeW91J3JlIA0KPiA+IHByZXR0eSBtdWNoIGdvaW5nIHRvIG5lZWQgdG8gcnVu IGFuIHVwZGF0ZWQga2VybmVsIG9uIHRoZSBjbGllbnRzIHRvby4uLg0KPiA+IHNwZWNpZmljYWxs eSBvbmUgd2l0aCBjb21taXQgMGI0ZDM0NTJiICJzZWN1cml0eS9zZWxpbnV4OiBhbGxvdyANCj4g PiBzZWN1cml0eV9zYl9jbG9uZV9tbnRfb3B0cyB0byBlbmFibGUvZGlzYWJsZSBuYXRpdmUgbGFi ZWxpbmcgYmVoYXZpb3IiLg0KPiA+IEFGQUlLIENlbnRPUyA3LjQgc2hvdWxkIGhhdmUgaXQgKGJl Y2F1c2UgUkhFTCA3LjQgaGFzIGl0KS4NCj4gPiANCj4gPiAtU2NvdHQNCj4gPiANCj4gPiANCj4g PiA+IA0KPiA+ID4gVGhhbmtzIGZvciB0aGUgaGVscCwNCj4gPiA+IEFsZXgNCj4gPiA+IC0tDQo+ IA0KPiBIaSwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHJlcGx5LiBZZXMsIEkgaW1hZ2luZSB0aGVy ZSdkIGJlIHByb2JsZW1zIGlmIGNsaWVudHMgYXJlIGNvbmZ1c2VkIGFib3V0IHdoYXQgbGFiZWxz IGFyZSBhcHBsaWVkLCBidXQgSSBqdXN0IHdhbnRlZCB0byBjaGVjayBpZiBhbnlvbmUga25ldyBv ZiB0aGF0IGFjdHVhbGx5IHByZXZlbnRpbmcgb3RoZXIgY2xpZW50cyBmcm9tIHJlYWRpbmcgb3Ig c2V0dGluZyBsYWJlbHMgYXQgYWxsICh0aHJvd2luZyAiT3BlcmF0aW9uIG5vdCBzdXBwb3J0ZWQi IGVycm9ycykuIEl0IHNvdW5kcyBmcm9tIHdoYXQgeW91IGFyZSBzYXlpbmcgbGlrZSB0aGF0IGlz IF9ub3RfIHRoZSBjYXNlLg0KDQpUaGF0J3MgY29ycmVjdC4NCg0KPiANCj4gU2NvdHQsIEkganVz dCB3YW50IHRvIGNsYXJpZnkgeW91ciBjb21tZW50IGFib3V0IGNsaWVudHMgdXNpbmcgYW4gDQo+ IGVhcmxpZXIga2VybmVsLiAgU2luY2UgbXkgb3JpZ2luYWwgbWVzc2FnZSB3ZSBub3cgaGF2ZSB0 aGUgZm9sbG93aW5nIA0KPiBrZXJuZWxzDQo+IA0KPiBTZXJ2ZXI6IAkJCTMuMTAuMC02OTMuNS4y LmVsNy54ODZfNjQNCj4gQ2xpZW50ICh3b3JraW5nKTogCTMuMTAuMC0zMjcuMzYuMi5lbDcueDg2 XzY0DQo+IENsaWVudCAobm9uLXdvcmtpbmcpOiAJMy4xMC4wLTY5My4yLjIuZWw3Lng4Nl82NA0K PiANCj4gU28gaXQncyB0aGUgX3dvcmtpbmdfIGNsaWVudCB3aGljaCBoYXMgdGhlIGRvd24tbGV2 ZWwga2VybmVsLg0KDQpUaGF0J3MgdGhlIG9wcG9zaXRlIGZyb20gd2hhdCBJJ20gc2VlaW5nIGlm IEkgaW5zdGFsbCB0aGUgUkhFTCBrZXJuZWxzIGNvcnJlc3BvbmRpbmcgdG8gdGhlIENlbnRPUyB2 ZXJzaW9ucyB5b3UgaGF2ZSBsaXN0ZWQuDQoNCj4gQXJlIHlvdSBzYXlpbmcgaXQgbmVlZHMgdG8g YmUgdXAtbGV2ZWwgYWxzbyBmb3IgdGhpcyB0byB3b3JrPyBPciBkbyB5b3UgbWVhbiB0aGF0IGFs bCBvZiB0aGUgdmVyc2lvbnMgYXJlIHRvbyBvbGQgc29tZWhvdz8gDQo+IFRoaXMgd2FzIHdvcmtp bmcgd2hlbiBhbGwgc2VydmVycyB3ZXJlIGRvd24tbGV2ZWwgKENlbnRPUyA3LjMga2VybmVsIHNv IDMuMTAtMzI3KSBfd2l0aG91dF8gdGhlICJzZWN1cml0eV9sYWJlbCIgZXhwb3J0cyBvcHRpb24g LSBkaWQgdGhlIG5ldyBrZXJuZWwgdGlnaHRlbiB0aGUgc2VjdXJpdHkgc3VjaCB0aGF0IHRoaXMg aXMgbm93IHJlcXVpcmVkPw0KDQpZZXMsIEkgd2FzIHNheWluZyB0aGF0IGluIG9yZGVyIHRvIHVz ZSB0aGUgInNlY3VyaXR5X2xhYmVsIiBvcHRpb24sIHlvdXIgTkZTIHNlcnZlciBhbmQgTkZTIGNs aWVudHMgbmVlZCB0byBiZSBydW5uaW5nIDcuNCBrZXJuZWxzLiAgQnV0IGl0IHNvdW5kcyBsaWtl IHRoZXJlJ3Mgc29tZXRoaW5nIGVsc2UgZ29pbmcgb24gaGVyZSB0aGF0IEknbSBub3QgdW5kZXJz dGFuZGluZy4gIEhlcmUncyB3aGF0IEkgc2VlIHdoZW4gSSBpbnN0YWxsIHRoZSBzYW1lIGtlcm5l bCB2ZXJzaW9ucyB0aGF0IHlvdSBoYXZlLg0KDQpPbiBteSBORlMgc2VydmVyIEkgaGF2ZSBhIHNp bmdsZSBleHBvcnQgd2l0aCB0aGUgInNlY3VyaXR5X2xhYmVsIg0Kb3B0aW9uOg0KDQpbcm9vdEBu ZnNzZXJ2ZXIgfl0jIHVuYW1lIC1yDQozLjEwLjAtNjkzLjUuMi5lbDcueDg2XzY0DQpbcm9vdEBu ZnNzZXJ2ZXIgfl0jIGNhdCAvZXRjL2V4cG9ydHMNCi9leHBvcnQgKihydyxpbnNlY3VyZSxub19y b290X3NxdWFzaCxzZWN1cml0eV9sYWJlbCkNCltyb290QG5mc3NlcnZlciB+XSMgZXhwb3J0ZnMg LXYNCi9leHBvcnQgICAgICAgICA8d29ybGQ+KHJ3LHN5bmMsd2RlbGF5LGhpZGUsbm9fc3VidHJl ZV9jaGVjayxzZWN1cml0eV9sYWJlbCxzZWM9c3lzLGluc2VjdXJlLG5vX3Jvb3Rfc3F1YXNoLG5v X2FsbF9zcXVhc2gpDQoNCklmIEkgbW91bnQgdXNpbmcgdGhlIG9sZGVyIGtlcm5lbCwgSSBjYW4g c2VlIHRoZSBsYWJlbCBidXQgSSBjYW4ndCBjaGFuZ2UgaXQ6DQoNCltyb290QHJoZWw3MiB+XSMg dW5hbWUgLXINCjMuMTAuMC0zMjcuMzYuMi5lbDcueDg2XzY0DQpbcm9vdEByaGVsNzIgfl0jIG1v dW50IC1vIHY0LjIgbmZzc2VydmVyOi9leHBvcnQgL21udC90DQpbcm9vdEByaGVsNzIgfl0jIGxz IC1aIC9tbnQvdC9maWxlDQotcnctci0tci0tLiByb290IHJvb3Qgc3lzdGVtX3U6b2JqZWN0X3I6 ZXRjX3Q6czAgICAgICAgL21udC90L2ZpbGUNCltyb290QHJoZWw3MiB+XSMgY2hjb24gLXQgdXNy X3QgL21udC90L2ZpbGUNCmNoY29uOiBmYWlsZWQgdG8gY2hhbmdlIGNvbnRleHQgb2Yg4oCYL21u dC90L2ZpbGXigJkgdG8g4oCYc3lzdGVtX3U6b2JqZWN0X3I6dXNyX3Q6czDigJk6IE9wZXJhdGlv biBub3Qgc3VwcG9ydGVkDQoNCklmIEkgbW91bnQgdXNpbmcgdGhlIG5ld2VyIGtlcm5lbCwgSSBj YW4gc2VlIGFuZCBjaGFuZ2UgdGhlIGxhYmVsOg0KDQpbcm9vdEByaGVsNzQgfl0jIHVuYW1lIC1y DQozLjEwLjAtNjkzLjIuMi5lbDcueDg2XzY0DQpbcm9vdEByaGVsNzQgfl0jIHY0LjIgDQpbcm9v dEByaGVsNzQgfl0jIGxzIC1aIC9tbnQvdA0KLXJ3LXItLXItLS4gcm9vdCByb290IHN5c3RlbV91 Om9iamVjdF9yOmV0Y190OnMwICAgICAgIGZpbGUNCltyb290QHJoZWw3NCB+XSMgY2hjb24gLXQg dXNyX3QgL21udC90L2ZpbGUNCltyb290QHJoZWw3NCB+XSMgbHMgLVogL21udC90DQotcnctci0t ci0tLiByb290IHJvb3Qgc3lzdGVtX3U6b2JqZWN0X3I6dXNyX3Q6czAgICAgICAgZmlsZQ0KDQpU byBhbnN3ZXIgeW91ciBxdWVzdGlvbiwgb24gdGhlIE5GUyBzZXJ2ZXIgc2lkZSB0aGUgb2xkZXIg a2VybmVsIHdvdWxkIGFsd2F5cyBzZW5kIHRoZSBpbmRpdmlkdWFsIHNlY3VyaXR5IGxhYmVscyBh bmQgYSBjaGFuZ2Ugd2FzIG1hZGUgdG8gbWFrZSB0aGF0IGJlaGF2aW9yIGJlIG9wdC1pbiBiZWNh dXNlIGl0IHdhcyBjYXVzaW5nIHByb2JsZW1zIGZvciBzb21lIHVzZXJzIChCcnVjZSBjYW4gY29y cmVjdCBtZSBvbiB0aGF0IGlmIEknbSB3cm9uZykuDQoNCk9uIHRoZSBjbGllbnQgc2lkZSB0aGVy ZSB3YXMgYSBwcm9ibGVtIHdpdGggc2V0dGluZyB0aGUgYXBwcm9wcmlhdGUgZmxhZyBvbiB0aGUg c3VwZXJibG9jayB0aGF0IGhhZCB0byBkbyB3aXRoIHRoZSB3YXkgTkZTdjQgbW91bnRzIGFyZSBk b25lLiBUaGUgY2xpZW50IG1vdW50cyB0aGUgTkZTdjQgcm9vdCBhbmQgdGhlbiBkb2VzIGEgcGF0 aCB3YWxrIHRvIHRoZSByZWFsIGV4cG9ydC4gIFdoZW4gaXQgZ2V0cyB0byB0aGUgcmVhbCBleHBv cnQgaXQgY2xvbmVzIHRoZSBzdXBlcmJsb2NrIGZyb20gdGhlIE5GU3Y0IHJvb3QuICBUaGUgZmxh ZyB3YXMgbm90IGdldHRpbmcgc2V0IG9uIHRoZSBjbG9uZS4gIFRoYXQncyB3aGF0IHRoZSBjb21t aXQgdGhhdCBJIHBvaW50ZWQgb3V0IGVhcmxpZXIgd2FzIGZpeGluZy4NCj4gDQo+IFNlcGFyYXRl bHksIGRvIGVpdGhlciBvZiB5b3Uga25vdyBvZiBhIHNlbnNpYmxlIHdheSBJIGNhbiBkZWJ1ZyB0 aGUgcm9vdCBjYXVzZSBmb3IgdGhlIGlzc3VlIGZ1cnRoZXIgKHRvIGdldCBhIG1vcmUgZGV0YWls IHdoeSAiT3BlcmF0aW9uIG5vdCBzdXBwb3J0ZWQiIGlzIHRocm93bik/IEkgZG9uJ3Qga25vdyB0 aGUga2VybmVsIHNvdXJjZSBhdCBhbGwgc28ganVzdCByZWFkaW5nIHRoZSBjb2RlIGlzIG5vdCB2 aWFibGUgZm9yIG1lICh3aXRob3V0IHNvbWUgZ3VpZGFuY2UpLCBidXQgaXMgdGhlcmUgc29tZSBs b2dnaW5nIG9yIG1vcmUgdmVyYm9zZSBvdXRwdXQgSSBjYW4gdHVybiBvbj8NCg0KVGhlcmUgaXNu J3QgcmVhbGx5IGFueSB2ZXJib3NlIGxvZ2dpbmcgdGhhdCBJIGNhbiB0aGluayBvZi4gIFdoZW4g eW91IGdldCAiT3BlcmF0aW9uIG5vdCBzdXBwb3J0ZWQiIGZyb20gY2hjb24sIGl0IHByZXR0eSBt dWNoIG1lYW5zIHRoYXQgdGhlIG1vdW50IGRvZXNuJ3QgaGF2ZSB0aGUgU0JMQUJFTF9NTlQgZmxh ZyBzZXQgKFJIRUwgdXNlcyBhbiBvbGRlciBmbGFnIFNFX1NCTEFCRUxTVVBQIGJ1dCBpdCdzIHJl YWxseSB0aGUgc2FtZSB0aGluZykuICBZb3UgY2FuIHNlZSB3aGV0aGVyIHRoZSBmbGFnIGlzIHNl dCBieSBsb29raW5nIGZvciB0aGUgdGV4dCAic2VjbGFiZWwiIGluIHRoZSBtb3VudCBvcHRpb25z IGZvciB5b3VyIG1vdW50IGluIC9wcm9jL21vdW50cy4gIE9uIHRoZSBvbGRlciBrZXJuZWwgSSBz ZWUgdGhpczoNCg0KW3Jvb3RAcmhlbDcyIH5dIyBncmVwIG5mczQgL3Byb2MvbW91bnRzDQpuZnNz ZXJ2ZXI6L2V4cG9ydCAvbW50L3QgbmZzNCBydyxyZWxhdGltZSx2ZXJzPTQuMixyc2l6ZT01MjQy ODgsd3NpemU9NTI0Mjg4LC4uLg0KDQphbmQgb24gdGhlIG5ld2VyIGtlcm5lbCBJIHNlZSB0aGlz Og0KDQpbcm9vdEByaGVsNzQgfl0jIGdyZXAgbmZzNCAvcHJvYy9tb3VudHMNCm5mc3NlcnZlcjov ZXhwb3J0IC9tbnQvdCBuZnM0IHJ3LHNlY2xhYmVsLHJlbGF0aW1lLHZlcnM9NC4yLHJzaXplPTUy NDI4OCx3c2l6ZT01MjQyODgsLi4uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBe Xl5eXl5eXg0KDQpUaGUgb3RoZXIgdGhpbmcgeW91IGNhbiBsb29rIGF0IGlzIHRoZSBjYXBzIGZp ZWxkIGluIC9wcm9jL3NlbGYvbW91bnRzdGF0cy4gIElmIHRoZSBzZXJ2ZXIgaGFzIHNlY3VyaXR5 IGxhYmVscyBlbmFibGVkIHRoZW4gdGhlIGNhcHMgZmllbGQgd2lsbCBoYXZlIE5GU19DQVBfU0VD VVJJVFlfTEFCRUwgc2V0LCB3aGljaCBpcyBkZWZpbmVkIGFzDQoNCiNkZWZpbmUgTkZTX0NBUF9T RUNVUklUWV9MQUJFTCAoMVUgPDwgMTgpDQoNCllvdSBjYW4gdGFrZSB0aGUgdmFsdWUgZnJvbSB0 aGUgY2FwcyBmaWVsZCBhbmQgcGx1ZyBpdCBpbnRvIGEgYmFzaCBwcmludGYNCg0KW3Jvb3RAcmhl bDc0IH5dIyBncmVwIGNhcHMgL3Byb2Mvc2VsZi9tb3VudHN0YXRzDQogICAgICAgIGNhcHM6ICAg Y2Fwcz0weDFmZmZmZGYsd3RtdWx0PTUxMixkdHNpemU9MzI3NjgsYnNpemU9MCxuYW1sZW49MjU1 DQpbcm9vdEByaGVsNzQgfl0jIHByaW50ZiAiJXhcbiIgJCgoIDB4MWZmZmZkZiAmICgxPDwxOCkg KSkNCjQwMDAwDQoNCklmIHlvdSBzZWUgMCBpbnN0ZWFkIG9mIDQwMDAwIHRoZW4gTkZTX0NBUF9T RUNVUklUWV9MQUJFTCBpc24ndCBzZXQuDQoNCk9uIHRoZSBvbGRlciBrZXJuZWwgSSBzdGlsbCBz ZWUgTkZTX0NBUF9TRUNVUklUWV9MQUJFTCBzZXQ6DQoNCltyb290QHJoZWw3MiB+XSMgZ3JlcCBj YXBzIC9wcm9jL3NlbGYvbW91bnRzdGF0cw0KICAgICAgICBjYXBzOiAgIGNhcHM9MHgzZmZmZmYs d3RtdWx0PTUxMixkdHNpemU9MzI3NjgsYnNpemU9MCxuYW1sZW49MjU1DQpbcm9vdEByaGVsNzIg fl0jIHByaW50ZiAiJXhcbiIgJCgoIDB4M2ZmZmZmICYgKDE8PDE4KSApKQ0KNDAwMDANCg0KU28g aW4gbXkgY2FzZSB0aGUgY2hjb24gaXMgZmFpbGluZyBvbiB0aGUgb2xkZXIga2VybmVsIGR1ZSB0 byB0aGUgYWJzZW5jZSBvZiB0aGUgU0JMQUJFTF9NTlQvU0VfU0JMQUJFTFNVUFAgZmxhZy4NCg0K LVNjb3R0DQo+IA0KPiBBbGV4DQoNCi0tLS0tLS0tLS0tLS0tLS0NCg0KU2NvdHQsDQoNClRoYW5r IHlvdS4gVXNpbmcgeW91ciBwb2ludGVycywgSSBkaWQgc29tZSBtb3JlIGRpZ2dpbmcgKGJlbG93 KS4gQmFzZWQgb24gdGhhdCBpdCBsb29rcyBsaWtlIE5GU19DQVBfU0VDVVJJVFlfTEFCRUwgaXNu J3QgYmVpbmcgc2V0IG9uIHRoZSB1cC1sZXZlbCBrZXJuZWwsIGJ1dCAqaXMqIGJlaW5nIHNldCBv biB0aGUgZG93bi1sZXZlbCBrZXJuZWwuIFRoZSBgc2VjbGFiZWxgIG9wdGlvbiBpcyBleGFjdGx5 IHJldmVyc2Ugb2Ygd2hhdCBpdCBzaG91bGQgYmUsIG5hbWVseSBpdCBhcHBlYXJzIG9uIHRoZSB1 cC1sZXZlbCAoZGVzcGl0ZSBubyBORlNfQ0FQKSENCg0KQXMgYSB0ZXN0LCBJIHRyaWVkIHRvIG1v dW50IG9uZSBvZiB0aGUgZXhwb3J0cyBhIHNlY29uZCB0aW1lIG9uIHRoZSB1cC1sZXZlbCBrZXJu ZWwuIEhlcmUgaXMgd2hhdCBJIGZvdW5kOg0KDQoqIG1vdW50aW5nIHZpYSBgbW91bnRgIHVzaW5n IHRoZSBzYW1lICJkZWZhdWx0cyxzb2Z0LGxvb2t1cGNhY2hlPW5vbmUiIGFzIGluIC9ldGMvZnN0 YWIgcmVwcm9kdWNlcyB0aGUgaXNzdWUNCltyb290QGVuZmlnaXRmcm9udDItZGV2ZWwgbW50XSMg bW91bnQgLW8gZGVmYXVsdHMsc29mdCx2NC4yLGxvb2t1cGNhY2hlPW5vbmUgZW5maWdpdGJhY2sy LWRldmVsLmRhdGNvbi5jby51azovZXhwb3J0Ly5zc2ggL21udC90ZXN0LXNzaC8NCltyb290QGVu ZmlnaXRmcm9udDItZGV2ZWwgbW50XSMgY2hjb24gLXQgdXNyX3QgL21udC90ZXN0LXNzaC9hdXRo b3JpemVkX2tleXMNCmNoY29uOiBmYWlsZWQgdG8gY2hhbmdlIGNvbnRleHQgb2Yg4oCYL21udC90 ZXN0LXNzaC9hdXRob3JpemVkX2tleXPigJkgdG8g4oCYc3lzdGVtX3U6b2JqZWN0X3I6dXNyX3Q6 czDigJk6IE9wZXJhdGlvbiBub3Qgc3VwcG9ydGVkDQpbcm9vdEBlbmZpZ2l0ZnJvbnQyLWRldmVs IG1udF0jIA0KDQoqIG1vdW50aW5nIHdpdGggZGVmYXVsdHMgZG9lcyBub3QNCltyb290QGVuZmln aXRmcm9udDItZGV2ZWwgbW50XSMgbW91bnQgLW8gdjQuMiBlbmZpZ2l0YmFjazItZGV2ZWwuZGF0 Y29uLmNvLnVrOi9leHBvcnQvLnNzaCAvbW50L3Rlc3Qtc3NoLw0KW3Jvb3RAZW5maWdpdGZyb250 Mi1kZXZlbCBtbnRdIyBjaGNvbiAtdCB1c3JfdCAvbW50L3Rlc3Qtc3NoL2F1dGhvcml6ZWRfa2V5 cw0KW3Jvb3RAZW5maWdpdGZyb250Mi1kZXZlbCBtbnRdIyBncmVwIGNhcHMgL3Byb2Mvc2VsZi9t b3VudHN0YXRzIA0KLi4uDQoJY2FwczoJY2Fwcz0weDFmZmZmZGYsd3RtdWx0PTUxMixkdHNpemU9 MzI3NjgsYnNpemU9MCxuYW1sZW49MjU1DQoNCkJhc2VkIG9uIHRoYXQgSSdtIHdvbmRlcmluZyBp ZiB0aGVyZSdzIHNvbWV0aGluZyBiYWQgaW50ZXJhY3Rpb24gd2l0aCB0aGUgbG9va3VwIGNhY2hl IGFuZC9vciBzb2Z0L2hhcmQgb3B0aW9uIC0gYW55IHdheSBJIGNhbiBkZWJ1ZyB0aGF0IGZ1cnRo ZXI/IEFsc28sIHdoYXQgZG8geW91IG1ha2Ugb2YgdGhlIHdlaXJkIE5GU19DQVAgc2V0IG9uIHRo ZSB1cC9kb3dubGV2ZWwga2VybmVscywgaXQgc2VlbXMgZXhhY3RseSByZXZlcnNlISANCg0KVGhh bmtzLCANCkFsZXggDQoNCg0KIyMjIE9uIHRoZSB1cC1sZXZlbCBrZXJuZWwNCg0KL3Byb2Mvc2Vs Zi9tb3VudHN0YXRzIHN1Z2dlc3RzIE5GU19DQVBfU0VDVVJJVFlfTEFCRUwgaXNuJ3Qgc2V0IC0g YnV0ICB3ZWlyZGx5IGBzZWNsYWJlbGAgaXMgcHJlc2VudCBpbiAvcHJvYy9tb3VudHMNCg0KW3Jv b3RAZW5maWdpdGZyb250Mi1kZXZlbCB+XSMgZ3JlcCBuZnMgL3Byb2MvbW91bnRzIA0KLi4uDQpl bmZpZ2l0YmFjazItZGV2ZWwuZGF0Y29uLmNvLnVrOi9leHBvcnQvc2hhcmVkIC92YXIvb3B0L2dp dGxhYi9naXRsYWItcmFpbHMvc2hhcmVkIG5mczQgcncsc2VjbGFiZWwsbm9hdGltZSx2ZXJzPTQu Mixyc2l6ZT0yNjIxNDQsd3NpemU9MjYyMTQ0LG5hbWxlbj0yNTUsc29mdCxwcm90bz10Y3AscG9y dD0wLHRpbWVvPTYwMCxyZXRyYW5zPTIsc2VjPXN5cyxjbGllbnRhZGRyPTE3Mi4xOC4xMC4xNTEs bG9va3VwY2FjaGU9bm9uZSxsb2NhbF9sb2NrPW5vbmUsYWRkcj0xNzIuMTguMTAuMTkzIDAgMA0K ZW5maWdpdGJhY2syLWRldmVsLmRhdGNvbi5jby51azovZXhwb3J0Ly5zc2ggL3Zhci9vcHQvZ2l0 bGFiLy5zc2ggbmZzNCBydyxzZWNsYWJlbCxub2F0aW1lLHZlcnM9NC4yLHJzaXplPTI2MjE0NCx3 c2l6ZT0yNjIxNDQsbmFtbGVuPTI1NSxzb2Z0LHByb3RvPXRjcCxwb3J0PTAsdGltZW89NjAwLHJl dHJhbnM9MixzZWM9c3lzLGNsaWVudGFkZHI9MTcyLjE4LjEwLjE1MSxsb29rdXBjYWNoZT1ub25l LGxvY2FsX2xvY2s9bm9uZSxhZGRyPTE3Mi4xOC4xMC4xOTMgMCAwDQouLi4NCltyb290QGVuZmln aXRmcm9udDItZGV2ZWwgfl0jIGdyZXAgY2FwcyAvcHJvYy9zZWxmL21vdW50c3RhdHMNCgljYXBz OgljYXBzPTB4MWZiZmZkZix3dG11bHQ9NTEyLGR0c2l6ZT0zMjc2OCxic2l6ZT0wLG5hbWxlbj0y NTUNCi4uLg0KW3Jvb3RAZW5maWdpdGZyb250Mi1kZXZlbCB+XSMgcHJpbnRmICIleFxuIiAkKCgg MHgxZmJmZmRmICYgKDE8PDE4KSApKQ0KMA0KW3Jvb3RAZW5maWdpdGZyb250Mi1kZXZlbCB+XSMg dW5hbWUgLXINCjMuMTAuMC02OTMuMi4yLmVsNy54ODZfNjQgDQoNCiMjIyBEb3duLWxldmVsDQpJ cyB0aGUgcmV2ZXJzZSBvZiB0aGUgYWJvdmU6IC9wcm9jL3NlbGYvbW91bnRzdGF0cyBzaG93cyBO RlNfQ0FQX1NFQ1VSSVRZX0xBQkVMICppcyogc2V0IGJ1dCBgc2VjbGFiZWxgIGlzbid0IHByZXNl bnQgKHdoaWNoIG1ha2VzIHNlbnNlIGJhc2VkIG9uIHdoYXQgeW91IGFyZSBzYXlpbmcpLg0KDQpl bmZpZ2l0YmFjazItZGV2ZWwuZGF0Y29uLmNvLnVrOi9leHBvcnQvLnNzaCAvdmFyL29wdC9naXRs YWIvLnNzaCBuZnM0IHJ3LG5vYXRpbWUsdmVycz00LjIscnNpemU9MjYyMTQ0LHdzaXplPTI2MjE0 NCxuYW1sZW49MjU1LHNvZnQscHJvdG89dGNwLHBvcnQ9MCx0aW1lbz02MDAscmV0cmFucz0yLHNl Yz1zeXMsY2xpZW50YWRkcj0xNzIuMTguMTAuMTQ4LGxvb2t1cGNhY2hlPW5vbmUsbG9jYWxfbG9j az1ub25lLGFkZHI9MTcyLjE4LjEwLjE5MyAwIDANCltyb290QGVuZmlnaXRmcm9udDEtZGV2ZWwg fl0jIGdyZXAgbmZzIC9wcm9jL21vdW50cyANCi4uLi4NCmVuZmlnaXRiYWNrMi1kZXZlbC5kYXRj b24uY28udWs6L2V4cG9ydC9wYWdlcy1kYXRhIC92YXIvb3B0L2dpdGxhYi9wYWdlcy1kYXRhIG5m czQgcncsbm9hdGltZSx2ZXJzPTQuMixyc2l6ZT0yNjIxNDQsd3NpemU9MjYyMTQ0LG5hbWxlbj0y NTUsc29mdCxwcm90bz10Y3AscG9ydD0wLHRpbWVvPTYwMCxyZXRyYW5zPTIsc2VjPXN5cyxjbGll bnRhZGRyPTE3Mi4xOC4xMC4xNDgsbG9va3VwY2FjaGU9bm9uZSxsb2NhbF9sb2NrPW5vbmUsYWRk cj0xNzIuMTguMTAuMTkzIDAgMA0KZW5maWdpdGJhY2syLWRldmVsLmRhdGNvbi5jby51azovZXhw b3J0Ly5zc2ggL3Zhci9vcHQvZ2l0bGFiLy5zc2ggbmZzNCBydyxub2F0aW1lLHZlcnM9NC4yLHJz aXplPTI2MjE0NCx3c2l6ZT0yNjIxNDQsbmFtbGVuPTI1NSxzb2Z0LHByb3RvPXRjcCxwb3J0PTAs dGltZW89NjAwLHJldHJhbnM9MixzZWM9c3lzLGNsaWVudGFkZHI9MTcyLjE4LjEwLjE0OCxsb29r dXBjYWNoZT1ub25lLGxvY2FsX2xvY2s9bm9uZSxhZGRyPTE3Mi4xOC4xMC4xOTMgMCAwDQouLi4u DQpbcm9vdEBlbmZpZ2l0ZnJvbnQxLWRldmVsIH5dIyBncmVwIGNhcHMgL3Byb2Mvc2VsZi9tb3Vu dHN0YXRzDQoJY2FwczoJY2Fwcz0weDNmZmZmZix3dG11bHQ9NTEyLGR0c2l6ZT0zMjc2OCxic2l6 ZT0wLG5hbWxlbj0yNTUNCi4uLi4NCltyb290QGVuZmlnaXRmcm9udDEtZGV2ZWwgfl0jIHByaW50 ZiAiJXhcbiIgJCgoIDB4M2ZmZmZmZiAmICgxPDwxOCkgKSkNCjQwMDAwDQpbcm9vdEBlbmZpZ2l0 ZnJvbnQxLWRldmVsIH5dIyB1bmFtZSAtcg0KMy4xMC4wLTMyNy4zNi4yLmVsNy54ODZfNjQNCg0K DQoNCiMjIyBTZXJ2ZXIsIGp1c3QgZm9yIGdvb2QgbWVhc3VyZQ0KDQpbcm9vdEBlbmZpZ2l0YmFj azItZGV2ZWwgfl0jIHVuYW1lIC1yDQozLjEwLjAtNjkzLjUuMi5lbDcueDg2XzY0DQpbcm9vdEBl bmZpZ2l0YmFjazItZGV2ZWwgfl0jIGNhdCAvZXRjL2V4cG9ydHMNCi4uLg0KL2V4cG9ydC8uc3No IDE3Mi4xOC4xMC4xNDgocncsc3luYyxub19yb290X3NxdWFzaCxzZWN1cml0eV9sYWJlbCkgMTcy LjE4LjEwLjE1MShydyxzeW5jLG5vX3Jvb3Rfc3F1YXNoLHNlY3VyaXR5X2xhYmVsKQ0KL2V4cG9y dC9zaGFyZWQgMTcyLjE4LjEwLjE0OChydyxzeW5jLG5vX3Jvb3Rfc3F1YXNoLHNlY3VyaXR5X2xh YmVsKSAxNzIuMTguMTAuMTUxKHJ3LHN5bmMsbm9fcm9vdF9zcXVhc2gsc2VjdXJpdHlfbGFiZWwp DQouLi4NCltyb290QGVuZmlnaXRiYWNrMi1kZXZlbCB+XSMgZXhwb3J0ZnMgLXYNCi9leHBvcnQv LnNzaCAgCTE3Mi4xOC4xMC4xNDgocncsc3luYyx3ZGVsYXksaGlkZSxub19zdWJ0cmVlX2NoZWNr LHNlY3VyaXR5X2xhYmVsLHNlYz1zeXMsc2VjdXJlLG5vX3Jvb3Rfc3F1YXNoLG5vX2FsbF9zcXVh c2gpDQovZXhwb3J0Ly5zc2ggIAkxNzIuMTguMTAuMTUxKHJ3LHN5bmMsd2RlbGF5LGhpZGUsbm9f c3VidHJlZV9jaGVjayxzZWN1cml0eV9sYWJlbCxzZWM9c3lzLHNlY3VyZSxub19yb290X3NxdWFz aCxub19hbGxfc3F1YXNoKQ0KLi4uLg0KDQo= ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-11-29 15:52 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-21 15:47 [Req for Help] Issues with SELinux (labelled) NFS after upgrading kernel 3.10.0-327 =>3.10.0-693 Alexander Hermes 2017-11-21 16:17 ` Scott Mayhew 2017-11-21 18:30 ` Alexander Hermes 2017-11-27 13:51 ` Scott Mayhew 2017-11-27 15:57 ` J. Bruce Fields 2017-11-28 10:09 ` Alexander Hermes 2017-11-28 17:23 ` Scott Mayhew 2017-11-29 15:52 ` Alexander Hermes
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.