scientific.org

[Werf, C.G. van der (Carel)]

Is there any reason why website 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.scientificlinux.org_&d=DwIFAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=zfxxlyxwKTMzHuFsAqjcjLqvtv-NB0CBLcHRNZAUi_U&s=C8FS3pxU3u7rrTEdxKMNz1kKPUTTOK8DBummnftsY20&e=
  is not being updated anymore ?

e.g.

"List of SL Security Errata" ends on Feb 26.
Version list is not updated with SL 7.8

Regards,
Carel van der Werf

RE: scientific.org

[Werf, C.G. van der (Carel)]

Seems a recurring issue ...

Any reason why 
https://urldefense.proofpoint.com/v2/url?u=https-3A__scientificlinux.org_downloads_sl-2Dversions_sl7_&d=DwIFAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=nEeasGDyrz3eUOJ5xUIuiRNtOGxxQff35FHsbdVeFiA&s=Nje4ZMZn7kVgNkS1OOTJsoZx71EW-GJwb-LWj3JlQrw&e=
   is stuck in 2019 ?

It shows SL 7.9 is "NA".

Also information on recent Security Updates is not published anymore... Is this 
on purpose ?

Regards,
Carel

From: owner-scientific-linux-us...@listserv.fnal.gov 
 On Behalf Of Werf, C.G. van 
der (Carel)
Sent: Thursday, 11 June, 2020 12:19
To: 'scientific-linux-users@fnal.gov' 
Subject: scientific.org

Is there any reason why website 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.scientificlinux.org_&d=DwIFAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=nEeasGDyrz3eUOJ5xUIuiRNtOGxxQff35FHsbdVeFiA&s=j9lAlD9jiJ97RZg8Yl5YrXDT_z0WtQ88cTucrDHQCKU&e=
 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.scientificlinux.org_&d=DwMFAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=zfxxlyxwKTMzHuFsAqjcjLqvtv-NB0CBLcHRNZAUi_U&s=C8FS3pxU3u7rrTEdxKMNz1kKPUTTOK8DBummnftsY20&e=>
 is not being updated anymore ?

e.g.

"List of SL Security Errata" ends on Feb 26.
Version list is not updated with SL 7.8

Regards,
Carel van der Werf

Re: scientific.org

[Nico Kadel-Garcia]

On Thu, Mar 4, 2021 at 4:23 AM Werf, C.G. van der (Carel)
<135eeb68b6b6-dmarc-requ...@listserv.fnal.gov> wrote:
>
> Seems a recurring issue ...
>
>
>
> Any reason why 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__scientificlinux.org_downloads_sl-2Dversions_sl7_&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=5JGkD-uMMCMgsNk_UitM_d3rjThRycW4r9KnT4g5QcA&s=qdOGXKb37rG3sm-a42srP2DQtZCSrnpkYoN6CMTmojo&e=
>is stuck in 2019 ?
>
>
>
> It shows SL 7.9 is “NA”.

Isn't that about when Scientific Linux admins deferred to CentOS and
encouraged people to migrate to CentOS? That seemed a very positive
move at the time. Sadly, the decision by RHEL and CentOS to stop
publishing point releases of CentOS 8 and support only "CentOS 8
Stream" has lead to a number of discussions and colorful metaphors
about exactly what stream we're supposed to be dipping from, and has
lead to many developers and places refusing to use CentOS 8 or, in
turn RHEL 8.

Re: scientific.org

[Yasha Karant]

Has anyone tried the Institute for Advanced Study Springdale (IAS) EL 8 
distro?  Is this in fact a complete distro that uses Epel and ElRepo as 
did SL? Does it install and boot as did SL?  Supposedly, Springdale can 
replace SL, although unlike SL that was "supported" by professional 
employed and compensated Staff for Fermilab/CERN for which it was a 
"standard", the IAS evidently has less professional staff allocation to 
Springdale than did the HEP community (mostly through Fermilab/CERN).


On 3/4/21 5:38 PM, Nico Kadel-Garcia wrote:

On Thu, Mar 4, 2021 at 4:23 AM Werf, C.G. van der (Carel)
<135eeb68b6b6-dmarc-requ...@listserv.fnal.gov> wrote:


Seems a recurring issue ...



Any reason why 
https://urldefense.proofpoint.com/v2/url?u=https-3A__scientificlinux.org_downloads_sl-2Dversions_sl7_&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=5JGkD-uMMCMgsNk_UitM_d3rjThRycW4r9KnT4g5QcA&s=qdOGXKb37rG3sm-a42srP2DQtZCSrnpkYoN6CMTmojo&e=
   is stuck in 2019 ?



It shows SL 7.9 is “NA”.


Isn't that about when Scientific Linux admins deferred to CentOS and
encouraged people to migrate to CentOS? That seemed a very positive
move at the time. Sadly, the decision by RHEL and CentOS to stop
publishing point releases of CentOS 8 and support only "CentOS 8
Stream" has lead to a number of discussions and colorful metaphors
about exactly what stream we're supposed to be dipping from, and has
lead to many developers and places refusing to use CentOS 8 or, in
turn RHEL 8.

Re: scientific.org

[Jon Pruente]

On Thu, Mar 4, 2021 at 3:23 AM Werf, C.G. van der (Carel) <
135eeb68b6b6-dmarc-requ...@listserv.fnal.gov> wrote:

> Seems a recurring issue ...
>
>
>
> Any reason why 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__scientificlinux.org_downloads_sl-2Dversions_sl7_&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=Qj430fRJhQliraWQvSyGNIbNV69G1LEOjeopOSl_fWg&s=fboWX70rtYW6R8B7_lDuCaMY3uSD4TB-tWL2IPhPThE&e=
>  
> 
> is stuck in 2019 ?
>
>
>
> It shows SL 7.9 is “NA”.
>
>
>
> Also information on recent Security Updates is not published anymore... Is
> this on purpose ?
>

I got Security Errata emails for SL literally yesterday. And, looking at
the site, that Security Errata is published on the sidebar of the site, as
well, per usual. I don't know why everyone seems to be calling this a lack
of updates. The only thing out of date is the update to link SL 7.9, of
which 
https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_linux_scientific_7.9_x86-5F64_iso_&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=Qj430fRJhQliraWQvSyGNIbNV69G1LEOjeopOSl_fWg&s=37_L6wQIh6-IPMaFQ4hntQaK7TyFw97YC6iCsCsDkig&e=
  is a
valid path.

Re: scientific.org

[Konstantin Olchanski]

On Thu, Mar 04, 2021 at 06:27:07PM -0800, Yasha Karant wrote:
>
> Has anyone tried the Institute for Advanced Study Springdale (IAS)
> EL 8 distro?
>

What for? I have my "16 free RHEL subscriptions" to run my 1 el8 machine
for developing and supporting the MIDAS data acquisition package.

As for everything else, at this very moment, I am:

a) converting all our RaspberyPi and FPGA SoC machines (about 10 of them) from 
CentOS-7.3 to Raspbian (ARM Debian)
b) converting our VME processors to Ubuntu and 32-bit Debian (and updating the 
VME kernel drivers to linux-5.8)
c) telling everybody to install Ubuntu or wait for CERN ("We will keep you 
informed about
any developments in this area during Q1 2021." with Q1 ending in 25 days or so).

If RHEL8 (or clone) for 32-bit ARM and 32-bit x86 did exist... but... I think...

The ship has sailed.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: scientific.org

[Yasha Karant]

I too am suggesting one switches to Ubuntu LTS current production 
(20.4.x for all production x).  The one issue that I have not been able 
to resolve:  what is the installed base of LTS for real world production 
use?  I know of several "smallish" list servers that are using LTS.  Are 
others using production VME machines also considering LTS?


At some point, unless IBM business plans / management preclude this, 
there will be an IBM RHEL 9.  By that point, it may well be too late for 
the HEP community assuming CERN/Fermilab wants to have some "common" 
base available to the HEP community (presumably, beyond the immediate 
NDA collaboration contracts that exist for the various CERN/Fermilab 
experiments).  Several correspondents to this list have felt that this 
discussion does not apply to the SL community, a point of view with 
which I disagree in that it is an essential part of software and systems 
engineering to include future planning, both for deployment and support. 
 With the evident demise of SL 8 and beyond (and evidently some issues 
with the maintenance of SL 7.9 if I have not misread postings to this 
list), SL will not be the way forward.  Your observations on RHEL 
indicate that except for those who license RHEL for fee with an IBM RH 
support contract, RHEL is not an viable stable long-term (nor immediate) 
alternative.



On 3/5/21 1:09 PM, Konstantin Olchanski wrote:

On Thu, Mar 04, 2021 at 06:27:07PM -0800, Yasha Karant wrote:


Has anyone tried the Institute for Advanced Study Springdale (IAS)
EL 8 distro?



What for? I have my "16 free RHEL subscriptions" to run my 1 el8 machine
for developing and supporting the MIDAS data acquisition package.

As for everything else, at this very moment, I am:

a) converting all our RaspberyPi and FPGA SoC machines (about 10 of them) from 
CentOS-7.3 to Raspbian (ARM Debian)
b) converting our VME processors to Ubuntu and 32-bit Debian (and updating the 
VME kernel drivers to linux-5.8)
c) telling everybody to install Ubuntu or wait for CERN ("We will keep you 
informed about
any developments in this area during Q1 2021." with Q1 ending in 25 days or so).

If RHEL8 (or clone) for 32-bit ARM and 32-bit x86 did exist... but... I think...

The ship has sailed.

Re: scientific.org

[Konstantin Olchanski]

> At some point ...

Yasha you are writing some very strange stuff.

> NDA collaboration contracts that exist for the various
> CERN/Fermilab experiments ...

if your NDA stands for "non-disclosure ...", then I must say that
I do not believe there are any secret agreements between experiments
and linux vendors. We do have NDAs with hardware vendors for
access to secret documentation and secret firmware source code,
but I never heard of any special agreements with any Linux vendors.

if you know something we do not know, please tell us more.

> ... Your observations on RHEL indicate that except for those
> who license RHEL for fee with an IBM RH support contract, RHEL is
> not an viable stable long-term (nor immediate) alternative.

I must put it on record that I did not say any such thing.

I say:

a) RHEL8 is here and you can use it free of charge (16 free subscriptions)
b) you can upgrade your CentOS-8 machine to RHEL8 with minimum trouble (I 
posted instructions on this list here)
c) Red Hat made a serious mistake back in December by announcing "the end of 
CentOS as we know it" without providing (a) and (b) ahead of time
d) by not providing 32-bit x86 and 32-bit ARM versions of RHEL they are at a 
severe disadvantage in places like a typical Physics lab (CentOS used to 
provide both, but they killed it).

So there. There is nothing wrong with RHEL8. If it works for you, use it!

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: scientific.org

[Nico Kadel-Garcia]

On Fri, Mar 5, 2021 at 4:09 PM Konstantin Olchanski  wrote:
>
> On Thu, Mar 04, 2021 at 06:27:07PM -0800, Yasha Karant wrote:
> >
> > Has anyone tried the Institute for Advanced Study Springdale (IAS)
> > EL 8 distro?
> >
>
> What for? I have my "16 free RHEL subscriptions" to run my 1 el8 machine
> for developing and supporting the MIDAS data acquisition package.

I do some larger scale work, and the licensing for these includes a
lot of handwaving that makes corporate lawyers very, very nervous
about allowing it inside their networks. Coupled with the uncertainty
of CentOS 8 Stream components being compatible with RHEL 8, whether
EPEL can or will use CentOS Stream or RHEL 8 for building binary
compatible requirements, the thoughtful delight that is "Modularity",
and at least 7 distinct, overlapping poorly distinguished and
partially overlapping software channels for no published or useful
reason, and the unwelcome and unnecessary segregation of specific
"devel" packages into the "Devel" channel which is not available in
CentOS 8 Stream,  and I'm seriously discouraged from pushing RHEL 8
and CentOs 8 for any projects whatsoever.

Hopefully by the time RHEL 9 rolls around, Red Hat will have let go
bright eyed architects who failed to learn the lessons of Red Hat 9
trying to be a "point release free" version of an operating system and
learned, the hard way, that point releases are something people rely
on and recovered with RHEL 2.x and RHEL 3.x shortly therafter back
around 2003.

> As for everything else, at this very moment, I am:
>
> a) converting all our RaspberyPi and FPGA SoC machines (about 10 of them) 
> from CentOS-7.3 to Raspbian (ARM Debian)

Are you? How's that working out?

Re: scientific.org

[Yasha Karant]

Most HEP (and sometimes other) "academic" collaborations have 
collaboration agreements for all member institutions (or groups or 
individuals) that no work done by the collaboration may be published or 
discussed without permission from the collaboration, typically a set of 
PIs (often not a democratic vote -- one person whose name may appear on 
the published papers or public presentations, one vote -- but rather 
some of the "group leaders" or the like).  These limitations not only 
apply to announcement of research results, but (often) deep details of 
the apparatus, that these days, can include software, applications, and 
perhaps computer environments (e.g., modifications to an OS, special OS 
drivers for specific hardware, etc.).  Once it has been decided that 
something can be released, then it is -- equivalent to a NDA.  Typically 
again under this sort of NDA, all of these details may be revealed to 
the funding agency/ies (those who "pay the bills") but the agency has 
agreed not to release this in public.  In the USA, save for classified 
(weapons, clandestine services, etc.) material, those things developed 
by Federal Government agencies are "public".


That was my meaning of NDA.

On 3/5/21 4:02 PM, Konstantin Olchanski wrote:

At some point ...


Yasha you are writing some very strange stuff.


NDA collaboration contracts that exist for the various
CERN/Fermilab experiments ...


if your NDA stands for "non-disclosure ...", then I must say that
I do not believe there are any secret agreements between experiments
and linux vendors. We do have NDAs with hardware vendors for
access to secret documentation and secret firmware source code,
but I never heard of any special agreements with any Linux vendors.

if you know something we do not know, please tell us more.


... Your observations on RHEL indicate that except for those
who license RHEL for fee with an IBM RH support contract, RHEL is
not an viable stable long-term (nor immediate) alternative.


I must put it on record that I did not say any such thing.

I say:

a) RHEL8 is here and you can use it free of charge (16 free subscriptions)
b) you can upgrade your CentOS-8 machine to RHEL8 with minimum trouble (I 
posted instructions on this list here)
c) Red Hat made a serious mistake back in December by announcing "the end of CentOS 
as we know it" without providing (a) and (b) ahead of time
d) by not providing 32-bit x86 and 32-bit ARM versions of RHEL they are at a 
severe disadvantage in places like a typical Physics lab (CentOS used to 
provide both, but they killed it).

So there. There is nothing wrong with RHEL8. If it works for you, use it!

Re: scientific.org

[Konstantin Olchanski]

To add. all official published results must be done using "official analysis",
and for the purposes of this discussion, said "official analysis"
often runs exclusively on RedHat-flavour linuxes.

> 
> Most HEP (and sometimes other) "academic" collaborations have
> collaboration agreements for all member institutions (or groups or ...
>
> That was my meaning of NDA.
> 

That has nothing to do with Linux and Red Hat. I do not know
why you bring it up. And you did not get it completely
right, either. In Physics, we do not have to sign legal NDAs
to participate in experiments and projects. It is basically
an honor system, and everybody plays by the rules
and/or breaks the rules per basic human nature. Books have
been written about this stuff.

K.O.

On Fri, Mar 05, 2021 at 04:30:13PM -0800, Yasha Karant wrote:
> Most HEP (and sometimes other) "academic" collaborations have
> collaboration agreements for all member institutions (or groups or
> individuals) that no work done by the collaboration may be published
> or discussed without permission from the collaboration, typically a
> set of PIs (often not a democratic vote -- one person whose name may
> appear on the published papers or public presentations, one vote --
> but rather some of the "group leaders" or the like).  These
> limitations not only apply to announcement of research results, but
> (often) deep details of the apparatus, that these days, can include
> software, applications, and perhaps computer environments (e.g.,
> modifications to an OS, special OS drivers for specific hardware,
> etc.).  Once it has been decided that something can be released,
> then it is -- equivalent to a NDA.  Typically again under this sort
> of NDA, all of these details may be revealed to the funding
> agency/ies (those who "pay the bills") but the agency has agreed not
> to release this in public.  In the USA, save for classified
> (weapons, clandestine services, etc.) material, those things
> developed by Federal Government agencies are "public".
> 
> That was my meaning of NDA.
> 
> On 3/5/21 4:02 PM, Konstantin Olchanski wrote:
> >>At some point ...
> >
> >Yasha you are writing some very strange stuff.
> >
> >>NDA collaboration contracts that exist for the various
> >>CERN/Fermilab experiments ...
> >
> >if your NDA stands for "non-disclosure ...", then I must say that
> >I do not believe there are any secret agreements between experiments
> >and linux vendors. We do have NDAs with hardware vendors for
> >access to secret documentation and secret firmware source code,
> >but I never heard of any special agreements with any Linux vendors.
> >
> >if you know something we do not know, please tell us more.
> >
> >>... Your observations on RHEL indicate that except for those
> >>who license RHEL for fee with an IBM RH support contract, RHEL is
> >>not an viable stable long-term (nor immediate) alternative.
> >
> >I must put it on record that I did not say any such thing.
> >
> >I say:
> >
> >a) RHEL8 is here and you can use it free of charge (16 free subscriptions)
> >b) you can upgrade your CentOS-8 machine to RHEL8 with minimum trouble (I 
> >posted instructions on this list here)
> >c) Red Hat made a serious mistake back in December by announcing "the end of 
> >CentOS as we know it" without providing (a) and (b) ahead of time
> >d) by not providing 32-bit x86 and 32-bit ARM versions of RHEL they are at a 
> >severe disadvantage in places like a typical Physics lab (CentOS used to 
> >provide both, but they killed it).
> >
> >So there. There is nothing wrong with RHEL8. If it works for you, use it!
> >

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: scientific.org

[Yasha Karant]

As for whether or not "legally binding" contracts/NDAs are used (that 
depends in part upon the nation under which legal system the 
collaborator may reside and/or that is providing the funding), the 
system is quite "political" and "power based", as indeed has appeared in 
a number of books.  For those who violate the rules, future funding is 
endangered, and for those who are post-docs or non-tenured "permanent" 
Faculty, the future "employment" in HEP greatly may be endangered. 
Shall I continue with the realities of the actual current HEP system 
(that has been in place since at least the Carlo Rubbia epoch).


As for the official analysis, my understanding is that the comment below 
is a reference to the specific, and possibly not fully released, 
software application program/s, utilities, and environment (e.g., RH 
linuxes) that is required by the rules of the collaboration.  Part of 
this requirement is proper software engineering to avoid (minimise) 
software defects.  However, even if the software source is released, the 
detailed data upon which the applications perform the "official 
analysis" typically is not available -- making "debugging" and 
verification outside the collaboration rather problematic.


On 3/5/21 5:31 PM, Konstantin Olchanski wrote:


To add. all official published results must be done using "official analysis",
and for the purposes of this discussion, said "official analysis"
often runs exclusively on RedHat-flavour linuxes.



Most HEP (and sometimes other) "academic" collaborations have
collaboration agreements for all member institutions (or groups or ...

That was my meaning of NDA.



That has nothing to do with Linux and Red Hat. I do not know
why you bring it up. And you did not get it completely
right, either. In Physics, we do not have to sign legal NDAs
to participate in experiments and projects. It is basically
an honor system, and everybody plays by the rules
and/or breaks the rules per basic human nature. Books have
been written about this stuff.

K.O.

On Fri, Mar 05, 2021 at 04:30:13PM -0800, Yasha Karant wrote:

Most HEP (and sometimes other) "academic" collaborations have
collaboration agreements for all member institutions (or groups or
individuals) that no work done by the collaboration may be published
or discussed without permission from the collaboration, typically a
set of PIs (often not a democratic vote -- one person whose name may
appear on the published papers or public presentations, one vote --
but rather some of the "group leaders" or the like).  These
limitations not only apply to announcement of research results, but
(often) deep details of the apparatus, that these days, can include
software, applications, and perhaps computer environments (e.g.,
modifications to an OS, special OS drivers for specific hardware,
etc.).  Once it has been decided that something can be released,
then it is -- equivalent to a NDA.  Typically again under this sort
of NDA, all of these details may be revealed to the funding
agency/ies (those who "pay the bills") but the agency has agreed not
to release this in public.  In the USA, save for classified
(weapons, clandestine services, etc.) material, those things
developed by Federal Government agencies are "public".

That was my meaning of NDA.

On 3/5/21 4:02 PM, Konstantin Olchanski wrote:

At some point ...


Yasha you are writing some very strange stuff.


NDA collaboration contracts that exist for the various
CERN/Fermilab experiments ...


if your NDA stands for "non-disclosure ...", then I must say that
I do not believe there are any secret agreements between experiments
and linux vendors. We do have NDAs with hardware vendors for
access to secret documentation and secret firmware source code,
but I never heard of any special agreements with any Linux vendors.

if you know something we do not know, please tell us more.


... Your observations on RHEL indicate that except for those
who license RHEL for fee with an IBM RH support contract, RHEL is
not an viable stable long-term (nor immediate) alternative.


I must put it on record that I did not say any such thing.

I say:

a) RHEL8 is here and you can use it free of charge (16 free subscriptions)
b) you can upgrade your CentOS-8 machine to RHEL8 with minimum trouble (I 
posted instructions on this list here)
c) Red Hat made a serious mistake back in December by announcing "the end of CentOS 
as we know it" without providing (a) and (b) ahead of time
d) by not providing 32-bit x86 and 32-bit ARM versions of RHEL they are at a 
severe disadvantage in places like a typical Physics lab (CentOS used to 
provide both, but they killed it).

So there. There is nothing wrong with RHEL8. If it works for you, use it!

Re: scientific.org

[Nico Kadel-Garcia]

On Fri, Mar 5, 2021 at 8:31 PM Konstantin Olchanski  wrote:
>
> To add. all official published results must be done using "official analysis",
> and for the purposes of this discussion, said "official analysis"
> often runs exclusively on RedHat-flavour linuxes.
>
> >
> > Most HEP (and sometimes other) "academic" collaborations have
> > collaboration agreements for all member institutions (or groups or ...
> >
> > That was my meaning of NDA.
> >
>
> That has nothing to do with Linux and Red Hat. I do not know
> why you bring it up. And you did not get it completely
> right, either. In Physics, we do not have to sign legal NDAs
> to participate in experiments and projects. It is basically
> an honor system, and everybody plays by the rules
> and/or breaks the rules per basic human nature. Books have
> been written about this stuff.

There are often quite potent contracts, with universities, private and
public funding agencies, and your agreements with whoever gives you
office space to work in, maybe a salary, and maybe a computer account
or library privileges. Human nature is devious, duplicitous, and
deceitful, it's at the core of how we manage the world.It is human
nature that we create agreements, sometimes quite elaborate and
complex, to manage the deceit and theft and abuse that are so often
part of human nature. It's why we, and yes, I'll include myself as a
physicist from my work with building the first safe cochlear
stimulators for use in MRI's, have peer review.   We weren't trusted,
that involved a great deal of deep suspicion, and some department
heads having to recuse themselves because they had a stake in the
experiment. It worked *very* well, by he way. We got great images of
how sound perception actually propagates through the human brain from
only one ear, fascinating stuff that you cannot normally do with an
MRI because they go "PING! PING! PING! PING! PING! PING!" and
overwhelm hearing in both ears.

Re: scientific.org

[Yasha Karant]

You state:

That has nothing to do with Linux and Red Hat. I do not know
why you bring it up.

End excerpt.

I respectfully disagree in so far as the issue concerns the future of 
whatever Linux (or other environment) that Fermilab/CERN and the 
"official" collaborations thereof use, and the HEP community in general. 
 If Fermilab/CERN, etc., under restrictive covenant license 
substantially different from the GPL and/or Linux licenses, deploys an 
internal FCSL X, for some X, say, there is no guarantee that such an 
internal deployment would be released the same as the current SL or IAS 
Springdale.  It might be released evidently as required by the GPL, 
etc., in source code, but in such a way as to making the building of a 
full executable environment ("OS") therefrom a very onerous task that 
highly under-provisioned academic research groups simply cannot 
undertake.  Moreover, under whatever restrictive covenants the 
collaborations have (by any terms for such covenants that you wish), 
there thus would be no assurance that any of the collaborators could 
release such an "OS" were it come into internal existence.  Clearly, 
Fermilab/CERN need to come to some sort of decision as to the path 
forward, as, save for licensing for fee, IBM RHEL 8 does not appear to 
be viable for the myriad uses in a HEP or similar environment.  The 
fruits of that decision may not be made generally available, unlike SL.


As has been pointed out on this list, systems engineering requires 
planning and a planned path forward (with contingency plans, of course, 
for disaster recovery and the like), and a major issue many of us 
confront is what is the path forward?  Such a path is vital, and has 
appeared without planning incident (but with a number of implementation 
and deployment issues, the typical discussion on this list) for the SLN 
to SLN+1 migrations prior to the demise of SL8. It is that demise that 
puts this sort of planning discussion onto this list.  Alternatives, 
such as Ubuntu LTS have been discussed.


On 3/6/21 5:16 AM, Nico Kadel-Garcia wrote:

On Fri, Mar 5, 2021 at 8:31 PM Konstantin Olchanski  wrote:


To add. all official published results must be done using "official analysis",
and for the purposes of this discussion, said "official analysis"
often runs exclusively on RedHat-flavour linuxes.



Most HEP (and sometimes other) "academic" collaborations have
collaboration agreements for all member institutions (or groups or ...

That was my meaning of NDA.



That has nothing to do with Linux and Red Hat. I do not know
why you bring it up. And you did not get it completely
right, either. In Physics, we do not have to sign legal NDAs
to participate in experiments and projects. It is basically
an honor system, and everybody plays by the rules
and/or breaks the rules per basic human nature. Books have
been written about this stuff.


There are often quite potent contracts, with universities, private and
public funding agencies, and your agreements with whoever gives you
office space to work in, maybe a salary, and maybe a computer account
or library privileges. Human nature is devious, duplicitous, and
deceitful, it's at the core of how we manage the world.It is human
nature that we create agreements, sometimes quite elaborate and
complex, to manage the deceit and theft and abuse that are so often
part of human nature. It's why we, and yes, I'll include myself as a
physicist from my work with building the first safe cochlear
stimulators for use in MRI's, have peer review.   We weren't trusted,
that involved a great deal of deep suspicion, and some department
heads having to recuse themselves because they had a stake in the
experiment. It worked *very* well, by he way. We got great images of
how sound perception actually propagates through the human brain from
only one ear, fascinating stuff that you cannot normally do with an
MRI because they go "PING! PING! PING! PING! PING! PING!" and
overwhelm hearing in both ears.

Re: [SCIENTIFIC-LINUX-USERS] scientific.org

[Patrick Riehecky]

Hi Carel,

Thanks for the report!  We will need to look into what is going on there.  This 
is unexpected.

Pat

On Thu, 2020-06-11 at 10:19 +, Werf, C.G. van der (Carel) wrote:
Is there any reason why website 
https://www.scientificlinux.org/
 is not being updated anymore ?

e.g.

“List of SL Security Errata” ends on Feb 26.
Version list is not updated with SL 7.8

Regards,
Carel van der Werf

Re: [SCIENTIFIC-LINUX-USERS] scientific.org

[Larry Linder]

What we did.
We commisioned a number of new boxes to Sl 6.10.  We also updated our
server over the weekend.  When we found out the server could not see
other boxes on our network.  We used yum to upgrade sama and smbserver
and that did not fix problem.

When I did a search on the internet for the problem.  There were a
number of reports from other distributions of linux 6.10 with the same
problem.

I tried their recommended fix but did not work.
They added aline into smb.conf.
   client max protocol = NT1  

They also indicated that windows 10 had an issue with samba.  Several of
our laptops running a stripped Windows 10 can see the server but not
now.

My problem goes deeper than just samba.
On sel 6.8 server we were able to see all of the workgroops and all of
the Linux boxes running 6.8 and 7.6 and able to connect.
Now the server only sees its self and no windows "workgroup" systems.

Our UPS shipping box used to show up on the server and other linux boxes
but no more.

ssh and scp all work and recognize each other.

Our decision just to update SL to 6.10 was due to a group decision.
Collectively they did not like the sl 7.6 desktop and a number of
needles changes that did not improve their ability to work.  We tried
Cent 8.0 on a test box and it was a worthless - a video game but nothing
worked behind it.

We looked at the end of life for sl 6 as 2024 and thought it gave us a
lot of time to find another linux or BSD that we could use.
The problem with the developers is that they never use it, run an
engineering shop and small factory that generates a good revenue stream.
They move the frunature around and change the "eye candy" but basically
do not fix operability issues  and connectivity.
Marketing is busy selling a Cloud applications and databases driven by a
quadraplegic desktop.  You move the problem from a local server to the
great server in the sky "Cloud". Wooppee.

In years past I had a Convex 64 bit system running BSD 4.2 and I could
link C, Fortran, ADA and other applications without a problem.  It had
an incredible rev control package that allows users to check out files
or view or edit or make various simulations.  One gate keeper was
required to run it.  It had 64 parocessors running in parallel and 5
disk controller in parallel driving a large Raid 5 disk array.  It ran
flawlessly for many years.  We kept it in lock step with a SUN server a
1000 miles away without a problem.
In a few years the powers to be thought it too expensive compared to a
flock of IBM desktops that could do nothing but word smithing.  When
they made their decision - I just packed up my desk drawer, removed my
name tag from the office wall and wished them well.

Larry Linder

On Thu, 2020-06-11 at 13:23 +, Patrick Riehecky wrote:
> Hi Carel,
> 
> 
> Thanks for the report!  We will need to look into what is going on
> there.  This is unexpected.
> 
> 
> Pat
> 
> 
> On Thu, 2020-06-11 at 10:19 +, Werf, C.G. van der (Carel) wrote:
> > Is there any reason why website 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.scientificlinux.org_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=k0X7sGQQ8m0rUsj7iWpOwhLHxk6NOVanwu-sWq63Yjw&s=MIngPRLbQZCa06VDiDy3WaxaW5YPigXrBGyyPeIhfcM&e=
> >   is
> > not being updated anymore ?
> > 
> >  
> > 
> > e.g.
> > 
> >  
> > 
> > “List of SL Security Errata” ends on Feb 26.
> > 
> > Version list is not updated with SL 7.8
> > 
> >  
> > 
> > Regards,
> > 
> > Carel van der Werf
> > 
> > 

Re: [SCIENTIFIC-LINUX-USERS] scientific.org

[Mark Rousell]

(I've been forced to post this via the Outlook.com web UI. It's vile. Sorry.)

On 11/06/2020 15:34, Larry Linder wrote:
> When I did a search on the internet for the problem.  There were a
> number of reports from other distributions of linux 6.10 with the same
> problem.
>
> I tried their recommended fix but did not work.
> They added aline into smb.conf.
>client max protocol = NT1  
>
> They also indicated that windows 10 had an issue with samba.  Several of
> our laptops running a stripped Windows 10 can see the server but not
> now.

I don't know if this will be helpful to you here and now but here goes. I 
believe that the "client max protocol = NT1" line limits the SMB version to 1. 
However, SMB1 is now deprecated in Windows 10[1]. So, with a current default 
Windows 10 configuration combined with "client max protocol = NT1" in your 
smb.conf files, your Linux and Windows boxes won't be able to talk to each 
other. Furthermore, Samba itself is in the process of deprecating SMB1 with a 
view to removing it entirely in due course, if I remember correctly.

Ideally you should force a higher version of SMB in Samba such as SMB2 or SMB3 
(as long as all your Linuxes have an up to date Samba).

Alternatively you can force install SMB1 in your Windows 10 boxes but this is 
definitely not recommended[2].

To re-enable SMB1 in Windows 10, use the 'Turn Windows features on or off' tool 
to re-enable it. You can separately enable or disable SMB1 client and server 
modes in W10. You can also do it at the command line via PowerShell if you wish 
(Google for instructions).




Footnotes:-
1: 'SMBv1 is not installed by default in Windows 10 version 1709, Windows 
Server version 1709 and later versions' 


2: 'Stop using SMB1' 

Re: [SCIENTIFIC-LINUX-USERS] scientific.org

[Larry Linder]

Thank You for the expert analysis of the problem.
One of the problems with searching the net is that most of time there is
advice that is correct but out of date or wrong OS etc. and they are not
clearly labeled.

We have downloaded the most current copy of Sama-* and all boxes are up
to date.
I will remove the statement form the smb.conf.  When we tested it there
was no differences on the network picture.

WE took down the fire wall on all boxes and after a reboot it made no
difference.  In the Firewall The samba box was checked and the required
ports were enabled.

We have one system still running SL 5.10 because it has a "mongrel" set
of libs so we can run spice, a filter design program and other
applications. It uses VMware and we have a lot of olders OS to allow us
to support projects that are 0ver 20 years old.  It uses samba to
communicate from the old windows OS to the SL 5.10.  This has worked
well for a long time.

What on the network controls the samba server vers a samba client.  The
documentation on this is sparse.

Larry Linder

On Thu, 2020-06-11 at 20:52 +, Mark Rousell wrote:
> (I've been forced to post this via the Outlook.com web UI. It's vile. Sorry.)
> 
> On 11/06/2020 15:34, Larry Linder wrote:
> > When I did a search on the internet for the problem.  There were a
> > number of reports from other distributions of linux 6.10 with the same
> > problem.
> >
> > I tried their recommended fix but did not work.
> > They added aline into smb.conf.
> >client max protocol = NT1  
> >
> > They also indicated that windows 10 had an issue with samba.  Several of
> > our laptops running a stripped Windows 10 can see the server but not
> > now.
> 
> I don't know if this will be helpful to you here and now but here goes. I 
> believe that the "client max protocol = NT1" line limits the SMB version to 
> 1. However, SMB1 is now deprecated in Windows 10[1]. So, with a current 
> default Windows 10 configuration combined with "client max protocol = NT1" in 
> your smb.conf files, your Linux and Windows boxes won't be able to talk to 
> each other. Furthermore, Samba itself is in the process of deprecating SMB1 
> with a view to removing it entirely in due course, if I remember correctly.
> 
> Ideally you should force a higher version of SMB in Samba such as SMB2 or 
> SMB3 (as long as all your Linuxes have an up to date Samba).
> 
> Alternatively you can force install SMB1 in your Windows 10 boxes but this is 
> definitely not recommended[2].
> 
> To re-enable SMB1 in Windows 10, use the 'Turn Windows features on or off' 
> tool to re-enable it. You can separately enable or disable SMB1 client and 
> server modes in W10. You can also do it at the command line via PowerShell if 
> you wish (Google for instructions).
> 
> 
> 
> 
> Footnotes:-
> 1: 'SMBv1 is not installed by default in Windows 10 version 1709, Windows 
> Server version 1709 and later versions' 
>   >
> 
> 2: 'Stop using SMB1' 
>   >

Re: [SCIENTIFIC-LINUX-USERS] scientific.org

[Nico Kadel-Garcia]

On Thu, Jun 11, 2020 at 10:48 AM Larry Linder
<0dea520dd180-dmarc-requ...@listserv.fnal.gov> wrote:
>
> What we did.
> We commisioned a number of new boxes to Sl 6.10.  We also updated our
> server over the weekend.  When we found out the server could not see
> other boxes on our network.  We used yum to upgrade sama and smbserver
> and that did not fix problem.

*Wh???*RHEL 6, which was released in 2010, is 10 years old. When you
try to deal with powerful, complex, evolving tools like everything
based on Samba, it gets more and more difficult to backport and keep
things compatible.

I publish backports o the current Samba releases to CentOS 7. I'd jump
over the waste of time on SL 6.

Re: [SCIENTIFIC-LINUX-USERS] scientific.org

[Patrick Riehecky]

Everything should be up to data again on the website.

Thanks for the report!

Pat

On Thu, 2020-06-11 at 13:23 +, Patrick Riehecky wrote:
> Hi Carel,
> 
> Thanks for the report!  We will need to look into what is going on
> there.  This is unexpected.
> 
> Pat
> 
> On Thu, 2020-06-11 at 10:19 +, Werf, C.G. van der (Carel) wrote:
> > Is there any reason why website https://www.scientificlinux.org/ is
> > not being updated anymore ?
> >  
> > e.g.
> >  
> > “List of SL Security Errata” ends on Feb 26.
> > Version list is not updated with SL 7.8
> >  
> > Regards,
> > Carel van der Werf