Re: [gpfsug-discuss] 5.0.1.0 Update issue with python dependencies

2018-05-17 Thread Grunenberg, Renar 
Hallo Smita,

I checks these  now, today there are no real way to get these package from a 
rhel channel. All are on 0.13.1. I checked the pike repository and see that 
following packages are available:
python2-pyOpenSSL-16.2.0-3.el7.noarch.rpm
python2-cryptography-1.7.2-1.el7.x86_64.rpm
python2-urllib3-1.21.1-1.el7.noarch.rpm

My Request and question here. Why are these packages are not in the 
pike-release that IBM shipped. Is it possible to implement and test these 
package for the next ptf 5.0.1.1.
Regards Renar.





Renar Grunenberg
Abteilung Informatik – Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon:09561 96-44110
Telefax:09561 96-44104
E-Mail: renar.grunenb...@huk-coburg.de
Internet:   www.huk.de

HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands 
a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav 
Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas.

Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte 
Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich 
erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist 
nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in 
error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this 
information is strictly forbidden.

Von: gpfsug-discuss-boun...@spectrumscale.org 
[mailto:gpfsug-discuss-boun...@spectrumscale.org] Im Auftrag von Smita J Raut
Gesendet: Mittwoch, 16. Mai 2018 12:23
An: gpfsug main discussion list 
Betreff: Re: [gpfsug-discuss] 5.0.1.0 Update issue with python dependencies

You are right Simon, that rpm comes from object. Below two are the new 
dependencies that were added with Pike support in 5.0.1
pyOpenSSL-0.14-1.ibm.el7.noarch.rpm
python2-urllib3-1.21.1-1.ibm.el7.noarch.rpm

From RHEL 7.0 to 7.5 the pyOpenSSL package included in the ISO is 
pyOpenSSL-0.13.1-3.el7.x86_64.rpm , but Pike needs >=0.14, hence pyOpenSSL-0.14 
was packaged since it was not available.

One possible cause of the problem could be that the yum certs may have Unicode 
characters.  If so, then the SSL code may be rendering the cert as chars 
instead of bytes. And there seem to be issues in pyOpenSSL-0.14 related to 
unicode handling that are fixed in 0.15. Renar, could you try upgrading this 
package to 0.15?

Thanks,
Smita



From:"Simon Thompson (IT Research Support)" 
>
To:gpfsug main discussion list 
>
Date:05/16/2018 01:44 PM
Subject:Re: [gpfsug-discuss] 5.0.1.0 Update issue with python 
dependencies
Sent by:
gpfsug-discuss-boun...@spectrumscale.org




I wondered if it came from the object RPMs maybe… I haven’t actually checked, 
but I recall that it was mentioned 5.0.1 was bumping to Pike swift stack (I 
think!) and that typically requires newer RPMs if using RDO packages so maybe 
it came that route?

Simon

From: 
>
 on behalf of "olaf.wei...@de.ibm.com" 
>
Reply-To: 
"gpfsug-discuss@spectrumscale.org" 
>
Date: Tuesday, 15 May 2018 at 08:10
To: "gpfsug-discuss@spectrumscale.org" 
>
Subject: Re: [gpfsug-discuss] 5.0.1.0 Update issue with python dependencies

Renar,
can you share , what gpfs packages you tried to install
I just did a fresh 5.0.1 install and it works fine for me... even though, I 
don't see this ibm python rpm

[root@tlinc04 ~]# rpm -qa | grep -i openssl
openssl-1.0.2k-12.el7.x86_64
openssl-libs-1.0.2k-12.el7.x86_64
pyOpenSSL-0.13.1-3.el7.x86_64
openssl-devel-1.0.2k-12.el7.x86_64
xmlsec1-openssl-1.2.20-7.el7_4.x86_64

So I assume, you installed GUI, or scale mgmt .. let us know -
thx




From:"Grunenberg, Renar" 
>
To:"'gpfsug-discuss@spectrumscale.org'"

Re: [gpfsug-discuss] SMB server on GPFS clients and Followsymlinks

2018-05-17 Thread Jonathan Buzzard 
On Wed, 2018-05-16 at 12:37 +, Daniel Kidger wrote:
> Jonathan,
>  
> Are you suggesting that a SMB exported symlink to /etc/shadow is
> somehow a bad thing ? :-)
> 

The irony is that people are busy complaining about not being able to
update their kernels for security reasons while someone else is
complaining about not being able to do what can only be described in
2018 as very bad practice.

The right answer IMHO is to forget about symlinks being followed server
side and take the opportunity that migrating it all to GPFS gives you
to re-architect your storage so they are no longer needed.

JAB.

-- 
Jonathan A. Buzzard Tel: +44141-5483420
HPC System Administrator, ARCHIE-WeSt.
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG


___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

[gpfsug-discuss] —subblocks-per-full-block in 5.0.1

2018-05-17 Thread Barry Evans 
Slight wonkiness in mmcrfs script that spits this out —subblocks-per-full-block 
as an invalid option.

No worky:

    777         subblocks-per-full-block )
    778           if [[ -z $optArg ]]
    779           then
    780             # The expected argument is not in the same string as its
    781             # option name.  Get it from the next token.
    782             eval optArg="\${$OPTIND}"
    783             [[ -z $optArg ]] &&  \
    784               syntaxError "missingValue" $noUsageMsg "--$optName_lc"
    785             shift 1
    786           fi
    787           [[ -n $subblocksPerFullBlockOpt ]] &&  \
    788             syntaxError "multiple" $noUsageMsg "--$optName_lc"
    789           subblocksPerFullBlockOpt="--$optName_lc"
    790
    791           nSubblocksArg=$(checkIntRange --subblocks-per-full-block 
$optArg 32 8192)
    792           [[ $? -ne 0 ]] && syntaxError nomsg $noUsageMsg
    793           tscrfsParms="$tscrfsParms --subblocks-per-full-block 
$nSubblocksArg"
    794           ;;

Worky:


    777         subblocks-per-full-block )
    778           if [[ -z $optArg ]]
    779           then
    780             # The expected argument is not in the same string as its
    781             # option name.  Get it from the next token.
    782             eval optArg="\${$OPTIND}"
    783             [[ -z $optArg ]] &&  \
    784               syntaxError "missingValue" $noUsageMsg "--$optName_lc"
    785             shift 1
    786           fi
    787           #[[ -n $subblocksPerFullBlockOpt ]] &&  \
    788           [[ -n $nSubblocksArg  ]] &&  \
    789             syntaxError "multiple" $noUsageMsg "--$optName_lc"
    790           #subblocksPerFullBlockOpt="--$optName_lc"
    791           nSubblocksArg="--$optName_lc"
    792
    793           nSubblocksArg=$(checkIntRange --subblocks-per-full-block 
$optArg 32 8192)
    794           [[ $? -ne 0 ]] && syntaxError nomsg $noUsageMsg
    795           tscrfsParms="$tscrfsParms --subblocks-per-full-block 
$nSubblocksArg"
    796           ;;

Looks like someone got halfway through the variable change 
“subblocksPerFullBlockOpt" is referenced elsewhere in the script:

if [[ -z $forceOption ]]
then
  [[ -n $fflag ]] &&  \
    syntaxError "invalidOption" $usageMsg "$fflag"
  [[ -n $subblocksPerFullBlockOpt ]] &&  \
    syntaxError "invalidOption" $usageMsg "$subblocksPerFullBlockOpt"
fi

...so this is probably naughty on my behalf.



Kind Regards,
Barry Evans
CTO/Co-Founder
Pixit Media Ltd
+44 7950 666 248
bev...@pixitmedia.com



-- 
 
This email is confidential in that it is intended 
for the exclusive attention of the addressee(s) indicated. If you are not 
the intended recipient, this email should not be read or disclosed to any 
other person. Please notify the sender immediately and delete this email 
from your computer system. Any opinions expressed are not necessarily those 
of the company from which this email was sent and, whilst to the best of 
our knowledge no viruses or defects exist, no responsibility can be 
accepted for any loss or damage arising from its receipt or subsequent use 
of this email.
___
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss