Re: Back UP

[Jon Pruente]

On Mon, Aug 9, 2021 at 3:36 PM Larry Linder <
0dea520dd180-dmarc-requ...@listserv.fnal.gov> wrote:

> Have friends and relatives buy a MAC.
>

I know this is a silly nit to pick in what you are posting about, but it
reminded me that I tend to see it most often from technical types. Why do
people use MAC when referring to a Macintosh? MAC should be for something
like a MAC address. We don't call people named Joseph JOE when their name
gets shortened. However, technical types seem to do it all the time for
Macs. Just a habit from dealing with MAC addresses all the time?

Re: Scientific Linux Advice

[Jon Pruente]

On Tue, Jun 29, 2021 at 11:32 AM Larry Linder <
0dea520dd180-dmarc-requ...@listserv.fnal.gov> wrote:

> We tried Alma, and Rock and they contain the fatel install flwas IBM
> invented with 7. and up.   Alma is just the same as RH 8.x complete with
> flaws and booby traps.  I pointed this out to the Alma people and thy
> shot the messenger.
>

You were barking up the wrong tree. Alma and Rocky are *supposed* to be
bug-for-bug compatible rebuilds of Red Hat. Complaining that they
replicated the bugs of Red Hat is actually a compliment.

Re: Rocky Linux 8.4 General Availability

[Jon Pruente]

On Tue, Jun 22, 2021 at 5:23 PM Dave Dykstra  wrote:

> CentOS 8.4 release notes says they fixed that issue in that release,
> after having resolved it in CentOS Stream 8.
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_Manuals_ReleaseNotes_CentOS8.2105-23Fully-5FFunctional-5FBoot-5FISO=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=X9IvmR0o7fmjMmy0QZhlH0vt2buTUoZNVMsuzJtMxck=FQivkZgxWQhjquM9obVjpYrDY3_zeTPenrAJnE1OG0Y=
>  
>
> I suggest reporting the problem to bugs.rocky.org.
>
> Dave
>

I had thought the issue was resolved long ago. I'm amazed it took them
almost 2 years and 4 more releases to actually fix it. Turns out that I've
been using the CentOS Minimal ISO this whole time. I have, however, filed a
bug with Rocky for it. Thanks for the link to the CentOS note, as I've
included that in the bug report.

Re: Rocky Linux 8.4 General Availability

[Jon Pruente]

On Tue, Jun 22, 2021 at 12:34 PM Teh, Kenneth M. <
0864eace5c83-dmarc-requ...@listserv.fnal.gov> wrote:

> I tried the boot iso but it does not have a built-in list of mirrors. I'm
> stuck at the installation source.  I need a url, either a specific repo or
> a url.  Please post if anyone knows one.
>

I had the same problem with the boot ISO. I used the minimal ISO to install
a VM with a plain base system with DHCP networking and
automatic partitioning. After rebooting into the installed OS everything
seemed fine. I refreshed repo data, installed epel-release, refreshed
again, then installed some basic tools from BaseOS and EPEL. For an
initial install it was fine.

ISTR it was CentOS that had a similar missing repo URL problem with their
first 8 release.

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_=DwIFaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=Qj430fRJhQliraWQvSyGNIbNV69G1LEOjeopOSl_fWg=fboWX70rtYW6R8B7_lDuCaMY3uSD4TB-tWL2IPhPThE=
>  
> 
> 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_=DwIFaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=Qj430fRJhQliraWQvSyGNIbNV69G1LEOjeopOSl_fWg=37_L6wQIh6-IPMaFQ4hntQaK7TyFw97YC6iCsCsDkig=
  is a
valid path.

Re: RockyEL list archives appear to be behind a paywall

[Jon Pruente]

RE: "paywall"

This is part of the Rocky team itself and their infrastructure being
literally in development. They know and understand these issues and are
working to overcome them. They are a team that is growing and overcoming
early mistakes and limitations, and admitting to them. That is admirable
for such a young project. From that "paywall"ed slack this morning:

> Rayzonic Today at 8:26 AM
> May I ask, any advantages on Mattermost over Slack? just curious. Thanks
in advance.

> neil  3 hours ago
> @Rayzonic Essentially slack is very expensive and not very well aligned
with our values about being open.
> Right now we're losing lots of messages because of the limit of 10,000 on
free plans.
> Something we didn't take into consideration, but should have, was the
accessibility of the platform we choose - but it looks like mattermost does
have good accessibility options. I'm looking forward to hearing your
thoughts on it when we get there!
> Have you used mattermost before?

> gmk  2 hours ago
> The 10k message limit means at our current churn rate messages are lost
in a matter of days not even weeks. Also, their sales team keeps talking to
me, and even though they apparently use CentOS, and seem to be planning on
using Rocky (from an internal unreliable source), they won’t help us with a
properly sponsored account. Mattermost on the other hand is very helpful to
us and open source.

Re: RockyEL list archives appear to be behind a paywall

[Jon Pruente]

On Wed, Dec 30, 2020 at 11:06 PM Yasha Karant  wrote:

> Beef:  Slang.   a complaint.
>  an argument or dispute.
>
> I do not have a complaint, argument, or dispute with Rocky EL or any
> other distro, enthusiast, "enterprise", or supported for fee.  The
> issues are suitability, currency, hardening, and support mechanisms.  I
> can elaborate on any of these if there is interest.  It is difficult,
> but not impossible, to have a distro that does not have computer science
> and engineering professionals (not in the sense of necessarily using
> this as in the sense of a significant source of gainful employment, nor
> in the sense of formal academic diplomata -- Heaviside had no such
> diplomata, but in the sense of knowledge, understanding, and skills, of
> which Heaviside had sufficient in all three of these areas) doing the
> implementation that is suitable for "hardened" production use, including
> converting a distribution source into a functioning alternately badged
> but otherwise identical "executable" distribution.
>

You do have a beef. You post item after item "exposing" how Rocky is not
suitable for prime professional use, while ignoring that the project is
still developing. You post complaint after complaint about how it's a
volunteer run affair while you can only stomach using something that people
are paid specifically to do. You have the take that volunteerism is bad for
serious use, yet the whole CentOS debacle is rooted around paid Red Hat
employees scuttling the distro. Stop being pedantic and just own up to the
behavior we can see in your posts.

Re: RockyEL list archives appear to be behind a paywall

[Jon Pruente]

On Tue, Dec 29, 2020 at 6:51 PM Yasha Karant  wrote:

>
> Thus, unlike either the Ubuntu (including LTS) Ask Ubuntu or this SL
> list that are available without any fee with full archive access, it
> appears that to get to the RockyEL "list" much older than one calendar
> week, one must subscribe for a fee.  Such a system makes archival
> information not generally available.  If other RockyEL (e.g., #rocky )
> readers do not see the paywall message and are not paying a fee (or have
> an institutional "subscription"), please comment as to how to get the
> "archives".
>

It's not a paywall for users. It's a limit of using a free Slack instance
vs paid. The Rocky Linux team is already in the process of moving to a
longer term system. The slack was never meant to be permanent, as it was
initially used for gmk's HPC company. It was the easiest and most expedient
place to send people at the sudden change from Red Hat. You seem to have
quite a beef against Rocky in principle, and choose to ignore that the
project is literally brand new and was started without any advance plans.

Re: SL compared to Ubuntu LTS major release upgrade

[Jon Pruente]

On Tue, Dec 22, 2020 at 4:45 PM Dave Dykstra  wrote:

> Fedora releases are much shorter life and I've heard there's a tool
> there to upgrade between releases more seamlessly, although I haven't
> used it myself.
>

Release upgrades of Fedora are fairly painless. I've got one server that I
inherited from a co-worker. It started life at Fedora 18, and it's been
iterated up to current Fedora 33. There were some config changes over the
years, but nothing that completely broke the whole system.

Re: Springdale Linux

[Jon Pruente]

On Mon, Dec 14, 2020 at 3:46 PM Konstantin Olchanski 
wrote:

> To followup on myself. Need a definition of "unsafe". Must make
> a distinction between "centos is unsafe" vs "redhat is unsafe" vs
> "linux is unsafe" vs "any use of computer is unsafe".
>
> ("safe as certified by recognized authority" need not apply,
> cars and airplanes are certified for safety, but still crash).
>

In the US FDA they use the phrasing "generally recognized as safe" for
things that aren't officially vetted.

Re: SL7 with security and bug fixes forever - how much work?

[Jon Pruente]

On Mon, Dec 14, 2020 at 2:54 PM Yasha Karant  wrote:

> I knew persons using the X86 Mac compatibility layer on PPC Macs, and
> was told that there was a noticeable performance hit because the
> emulator (more or less) functioned as an "inner interpreter" for a
> totally different ISA.  The same is true between X86-64 and the 64 bit
> ARM ISAs (along with other architectural differences).  Out of
> curiosity, how similar are the Apple Mac ARM CPUs to the CPU used in the
> Fujitsu Fugaku HPC machine (A64FX 48C 2.2GHz)?
>

The big difference is that Apple included, in hardware, the ability to set
the memory ordering to the model x86 uses. This way every translated
instruction doesn't have to move bytes around, which is why the x86
emulation of the recent Microsoft ARM hardware was so terrible. By all
accounts if the code runs in Rosetta 2, it runs very well.

Re: SL7 with security and bug fixes forever - how much work?

[Jon Pruente]

On Mon, Dec 14, 2020 at 2:07 PM Yasha Karant  wrote:

> For the Apple Mac community:  as is known, Apple is leaving the X86-64
> platform for an ARM platform.  Will older applications be updated, or
> will new (and in some cases, newly licensed-for-fee) applications be
> required?
>

The recent releases of macOS went 64-bit only, which cut out a lot of old
software. The most recent release that added support for ARM also includes
a binary compatibility layer to run x86-64 programs called Rosetta 2, after
the similar layer they used when they transitioned from PPC to x86.

Re: [SCIENTIFIC-LINUX-USERS] RedHat have broken Grub again

[Jon Pruente]

On Fri, Oct 16, 2020 at 4:10 PM Jose Marques <
0fd846b4f4be-dmarc-requ...@listserv.fnal.gov> wrote:

> Thank deity for that. :-)
>
> The other issue I was having is upgrading my RSS reader and having it show
> old articles as unread. Apologies for the wasted bandwidth.
>

No worries from me. I'm just glad there isn't a new one to be worried
about!

Re: RedHat have broken Grub again

[Jon Pruente]

On Fri, Oct 16, 2020 at 4:01 PM Jose Marques <
0fd846b4f4be-dmarc-requ...@listserv.fnal.gov> wrote:

> Another security fix has broken booting on RHEL derived systems.
>
> See:
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__arstechnica.com_gadgets_2020_07_red-2Dhat-2Dand-2Dcentos-2Dsystems-2Darent-2Dbooting-2Ddue-2Dto-2Dboothole-2Dpatches_=DwIFAg=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=TJWjp-avGU8vMQ-Cz7puFhJksH9yHPSeP-7LsyDXGVw=3GlI5YOjeFJVMA9ExwJIF7vixHz3hEwoVbLJn9J4i9Q=
>
> The University of St Andrews is a charity registered in Scotland, No.
> SC013532.
>

That article is from July. It's been fixed. Is there another issue you
are having?

Re: Recovering root password

[Jon Pruente]

On Tue, Jun 23, 2020 at 3:50 AM Elio Fabri  wrote:

> Hi all,
> I need help (at lest a link) as to how to recover my root password.
> I'm using SL6.2. The password I remember by heart is no longer accepted,
> neither for the su command nor for sudo.
> Thx
> --
> Elio Fabri
>

The password for sudo should be your user password, not root.

Re: off SL

[Jon Pruente]

On Tue, May 26, 2020 at 3:02 PM Alec Habig <
0eb51fd2fd31-dmarc-requ...@listserv.fnal.gov> wrote:

> Also worth noting that on Fedora, upgrades in place via the repository
> (it's a simple dnf plugin) work great, and has for a while.
>
> So, to the extent that Fedora developments often get rolled into RHEL
> once they mature, that's also a good sign.
>

I have a prod server that's been upgraded each release from Fedora Server
17 up to 32. We've been waiting a really long time for it to show up down
stream.

Re: Who Uses Scientific Linux, and How/Why?

[Jon Pruente]

>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nam01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fwww.cs.concordia.ca-5F-2D7Emokhov-2526d-253DDwIFaQ-2526c-253DgRgGjJ3BkIsb5y6s49QqsA-2526r-253Dgd8BzeSQcySVxr0gDWSEbN-2DP-2DpgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A-2526m-253DReXrKueW8ZKy6ZeDrhbuU0jFxocBkwAtzvgZ8Lw2ARo-2526s-253Dbe7he2wCrlv4hIwX-5Fh0scVYIki4Qb7seECAg7OOc-2DMY-2526e-26amp-3Bdata-3D02-257C01-257Crdt12-2540PSU.EDU-257C9fb96135f1114e1bf6b108d7b938cfd4-257C7cf48d453ddb4389a9c1c115526eb52e-257C0-257C0-257C637181525973769014-26amp-3Bsdata-3DefZ-252FN-252FksB4JxCeCgsEBmSkFNIfgbSPGAiP70rfaAVes-253D-26amp-3Breserved-3D0-3D=DwIF-g=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=8TdfyJ1u8MnWKcS6ydkH1brzzoEzq1IZRhMef5YNV1I=hPRLpwZu7HwRGmm7_TBUfJv0w0CSwjuGooVPdc6YHzI=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nam01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fcciff.ca-2526d-253DDwIFaQ-2526c-253DgRgGjJ3BkIsb5y6s49QqsA-2526r-253Dgd8BzeSQcySVxr0gDWSEbN-2DP-2DpgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A-2526m-253DReXrKueW8ZKy6ZeDrhbuU0jFxocBkwAtzvgZ8Lw2ARo-2526s-253Dr1CyWyPBkhOKlYHXLLBrBRzhyvOXZfdHagfuQ1DQWDk-2526e-26amp-3Bdata-3D02-257C01-257Crdt12-2540PSU.EDU-257C9fb96135f1114e1bf6b108d7b938cfd4-257C7cf48d453ddb4389a9c1c115526eb52e-257C0-257C0-257C637181525973769014-26amp-3Bsdata-3DvOC8W1XdAWbpKhU0ZWNK02OGyw1V4hUoT5gbdi0MMYM-253D-26amp-3Breserved-3D0-3D=DwIF-g=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=8TdfyJ1u8MnWKcS6ydkH1brzzoEzq1IZRhMef5YNV1I=AjMm_VAXOf28cikomJtmfuTunn_KhxlwZvjcCllMptM=
>  |
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nam01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fmdreams-2D2Dstage.com-2526d-253DDwIFaQ-2526c-253DgRgGjJ3BkIsb5y6s49QqsA-2526r-253Dgd8BzeSQcySVxr0gDWSEbN-2DP-2DpgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A-2526m-253DReXrKueW8ZKy6ZeDrhbuU0jFxocBkwAtzvgZ8Lw2ARo-2526s-253DGqE1OMX9RmXnxHlwLxQhCFqwgZdIh5nqA-2DPoNF1J30c-2526e-26amp-3Bdata-3D02-257C01-257Crdt12-2540PSU.EDU-257C9fb96135f1114e1bf6b108d7b938cfd4-257C7cf48d453ddb4389a9c1c115526eb52e-257C0-257C0-257C637181525973769014-26amp-3Bsdata-3Df7eYknsB-252Bt8OjVK3xMccqjRNCHHl4IXLwdLiS1e9vHM-253D-26amp-3Breserved-3D0-3D=DwIF-g=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=8TdfyJ1u8MnWKcS6ydkH1brzzoEzq1IZRhMef5YNV1I=94QdigvDN02IKw-od5I0IuFZZBYYFEI9pNQ5u8zTrrk=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nam01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fmarf.sf.net-2526d-253DDwIFaQ-2526c-253DgRgGjJ3BkIsb5y6s49QqsA-2526r-253Dgd8BzeSQcySVxr0gDWSEbN-2DP-2DpgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A-2526m-253DReXrKueW8ZKy6ZeDrhbuU0jFxocBkwAtzvgZ8Lw2ARo-2526s-253DAChVu3ppzcRMQhwedztVKVDCZpdn7eviggK3B8gom7Y-2526e-26amp-3Bdata-3D02-257C01-257Crdt12-2540PSU.EDU-257C9fb96135f1114e1bf6b108d7b938cfd4-257C7cf48d453ddb4389a9c1c115526eb52e-257C0-257C0-257C637181525973769014-26amp-3Bsdata-3DUjmIivP7v0xFqNejXm3OxtfLoslgQEQ7WBC561PcMxk-253D-26amp-3Breserved-3D0-3D=DwIF-g=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=8TdfyJ1u8MnWKcS6ydkH1brzzoEzq1IZRhMef5YNV1I=sZHCCLPdmrR44aL3uGjrjP-OFI4A3K3ueeogGyC62cs=
>  |
> https://urldefense.proofpoint.com/v2/url?u=https-3A__nam01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttp-2D3A-5F-5Fsf.net-5Fprojects-5Fmarf-2526d-253DDwIFaQ-2526c-253DgRgGjJ3BkIsb5y6s49QqsA-2526r-253Dgd8BzeSQcySVxr0gDWSEbN-2DP-2DpgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A-2526m-253DReXrKueW8ZKy6ZeDrhbuU0jFxocBkwAtzvgZ8Lw2ARo-2526s-253DlBCv7stSS6iCundVO4eoQ9BsgR8UV294lSmdDozJ8Q8-2526e-26amp-3Bdata-3D02-257C01-257Crdt12-2540PSU.EDU-257C9fb96135f1114e1bf6b108d7b938cfd4-257C7cf48d453ddb4389a9c1c115526eb52e-257C0-257C0-257C637181525973779008-26amp-3Bsdata-3Dr6As6zcECCxvWBJiNTBWBhB3jN-252FQ49cHPCI4u3O9R-252B8-253D-26amp-3Breserved-3D0-3D=DwIF-g=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=8TdfyJ1u8MnWKcS6ydkH1brzzoEzq1IZRhMef5YNV1I=fApZLkTeoBIxng-TxbjbW3zWef2iI1k3bMi-afkiJG0=
>

I'm curious how many levels deep the Proof Point URL Defense will
recontinue to re-encode its own encoded URLs. I thought t was silly when
that was added to the list infra, and this makes it even more so. URLs in
messages quoted backt to the list is hardly an edge case.

Re: Is Scientfic Linux Still Active as a Distribution?

[Jon Pruente]

On Fri, Feb 21, 2020 at 1:21 PM Yasha Karant  wrote:

> In the simplest terms. I trust IBM to maximize overall
> return-on-investment (e.g., profit), and a "free" CentOS that truly
> competes with licensed-for-fee products does not fit that for-profit model.
>

The amount of anti-IBM FUD in these kinds of threads is staggering. IBM has
supported Linux for literal decades, even on their mainframe hardware.

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_ibm_history_ibm100_us_en_icons_linux_=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=CVEqyWX2tM2UdAysPgM_G95hgpoVNM-YyXhIDY6lhCQ=2hr7BD-hdfyYkJk3dI3pBx7erjqgUanUk5wDUZ7FtRo=
 

Re: EL 8

[Jon Pruente]

On Sun, Feb 2, 2020 at 1:26 PM Pwillis  wrote:

> From my personal, outsider, view the ‘Distribution’ thing is a major
> bottleneck with the long term stability of Linux. Distributions dilute the
> focus on maintenence by dividing the available labour resource over a
> foolish duplication of tasks. This is usually a marketing thing of some
> kind (ie: Oracle Redhat fork, Ubuntu vs. Debian, Slack vs. Gentoo, CentOS
> vs. Redhat).
>

That point has been used for 25 years against Linux and 40+ against UNIX.
The worldwide dominance of UNIX and Linux says otherwise, as you mention in
your later reply. I'm surprised that with such a long history of being
nearly equivalent to "the sky is falling" it keeps being a point of
contention.

Re: EL 8

[Jon Pruente]

On Thu, Jan 30, 2020 at 7:58 PM Yasha Karant  wrote:

> soon to be forced to go to another Linux.  The options appear to be drop
> EL entirely and go to Ubuntu  LTS ("stable") current, or to stay with EL
> and use Springdale (Princeton) EL8 when (if?) it is available, or Oracle
> 8 EL.  Thus far, everyone I have contacted who did a clean install of
>

Is there a reason you have to avoid CentOS? The SL devs have stated that
they will not develop SL8 and instead put their resources into CentOS.

Re: Calibre current

[Jon Pruente]

On Thu, Jan 30, 2020 at 11:05 AM Yasha Karant  wrote:

> I attempted to upgrade Calibre to the current production release.  It
> fails to run (I can post my question) but the response given is:
>
>
I think they are just giving up on supporting anything older at all now
that they've moved from QT WebKit to QT WebEngine in Calibre 4 and also the
ongoing effort to move to Python 3.
https://urldefense.proofpoint.com/v2/url?u=https-3A__calibre-2Debook.com_new-2Din_thirteen=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=7QI6okusGGGNrCvuoD4tmh6ctqYIZM9p9rtMW2lRe74=L2hICLSVqaaSWWZvess69_aejmnXxlIGbHA4kg4NUQA=
  They have even dropped all
versions of macOS prior to 10.14 (released late 2018).
https://urldefense.proofpoint.com/v2/url?u=https-3A__calibre-2Debook.com_download-5Fosx=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=7QI6okusGGGNrCvuoD4tmh6ctqYIZM9p9rtMW2lRe74=JL_zDiQ9PoYqHhpumfC6Hn0eG1Sc46zSv50uhWJugSA=
  If you can't install the flatpak
your best bet is probably to stick with Calibre 3 if you want to keep using
it on anything they don't expressly support.

Re: centOS 8 ... Gnome 3, Mate

[Jon Pruente]

On Wed, Oct 9, 2019 at 2:15 PM Keith Lofstrom  wrote:

> That is nice to know, I'll find out how.  I presume Mate and
> Gnome3 can coexist on the same machine, perhaps with different
> logins to access them, so I can make the transition as Gnome3
> is adapted to my needs.

No need for separate logins. Just choose which environment you want from
the login manager.

Re: SL6 end of life

[Jon Pruente]

On Thu, Sep 5, 2019 at 9:47 AM Larry Linder 
wrote:

> It is interesting that there is a new "yum" as an RPM but do you need to
> install it to install the rest of the .rpm packages on the RHEL 8. RPM
> pile.
> This looks like the chicken / egg problem or can you install the RHEL
> rpms with the old yum?
>
> I have to admit that I did not read the fine print.
>

It's a newer package manager called dnf, not a new packaging format. dnf
was introduced in Fedora 18 in 2013, so over six years. It was made the
full replacement in Fedora 22. You can still call the yum command, it's
just a symlink to dnf. No worries.

https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_DNF-3Frd-3DDnf=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=SM6t1tQwJzgMMcNC1sBHJMyQ72nOFvL9qDSV-VnK6Vw=tMerSZ0hcHReQxeASxHwqOVdRoU_Ov5C7ZqdfPpCvqU=
 

On a RHEL 8 VM:
$ which yum
/usr/bin/yum
$ ls -l /usr/bin/yum
lrwxrwxrwx. 1 root root 5 Oct 15  2018 /usr/bin/yum -> dnf-3

Re: SP: proofpoint.com URLs in sl-users messages

[Jon Pruente]

On Tue, Jul 24, 2018 at 12:20 PM, Konstantin Olchanski
 wrote:
> On Tue, Jul 24, 2018 at 09:39:37AM -0500, Glenn Cooper wrote:
> Some people dislike these email manglers because they replace obviously
> safe URLs (://triumf.ca, 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bnl.gov=DwIBAg=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=9MsrWO_OsZsUg1N098OjP5FVq11d4xFs7FQSsO0fvOg=hNpBcmIgNIJC38WgFxk6q0e-BDk3eAeFQnaJXmIOK3Y=,
>  ://gnal.gov, etc)
> with magical "eat me" cookies.
>
> Maybe these manglers cut down on nigerian fishing, but I think there
> is a net decrease in security because everybody is forced
> to click links without knowing exactly where they go.

Another failure of using such a service is that the URLs are now
mangled inside the ProofPoint URL. When at some point in the future
the ProofPoint service is discontinued or is no longer used by
Fermilab (it will happen, some day, one way or another) the URLs that
were originally submitted are lost. A "safe" link and a
non-HTML-sanitized copy of the original URL would be a welcome
safeguard from being hostage to the service for a clean copy of the
URL for several reasons, even to just know what the URL is targeting
along with having the option to not follow the link through the URL
filtering service for tracking and privacy concerns. expressed by
Konsantin.

Re: System running SL 7 fails to update certain packages

[Jon Pruente]

On Tue, Jul 10, 2018 at 3:46 PM, Mark Stodola  wrote:
> On 07/10/2018 02:58 PM, Mark Stodola wrote:
>> Do you have yum-conf-sl7x installed?

I do. I did find that on the SL FAQ page earlier. (
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.scientificlinux.org_documentation_faq_faq-2Dreleases_-23update-2Dlatest-2Drelease=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=AVyza5gjVLj4FbiNcJFK3BBrXQF80QXNAdnC7uIYRIY=IQWUhCyOWbIhHkBj1gMUG0rrxrPb9mkC8n_AXf_JWKk=
)

>> What are the contents of:
>> /etc/yum/vars/releasever

7

>> /etc/yum/vars/slreleasever

7.3

>>
>> The newer kernels are generally available at each release version via the
>> sl-security repo, so it is not a good measure.

Ah, that's good to know. I had just assumed that the system always
tried to upgrade in sync.

> I forgot to provide a fix/solution for you...
>
> If you do not have yum-conf-sl7x install it.
> If it is installed, do a 'yum reinstall yum-conf-sl7x'.

This  reinstall seems to have been the fix. I had to spread checking
and updating/rebooting across two maintenance windows, but this is the
only actual change I made that hadn't been done before. After this I
did a 'yum clean all' and 'rm -rf /var/cache/yum' before another run
of 'yum check-update'. That time it found a list of 269 packages to be
updated and brought the system up to 7.5 when they were installed.

> yum-conf-sl7x and sl-release.  There is an rpm trigger to (hopefully) handle
> this gracefully.  See /var/libexec/sl-release/set-release.sh.

I didn't find that script on the system, or even that path. Some
poking with find and I came up with
/usr/libexec/sl-release/set-slrelease.sh which looks to do what you
describe.

Thank you very much for the help! I now have a fully updated and
patched server again.

System running SL 7 fails to update certain packages

[Jon Pruente]

I've got a server running SL 7.3 and while it has installed many
updates including recent ones under the 7.5 update, it is not
installing all updates to a full SL 7.5 system. I've tried 'yum clean
all' and 'rm -rf /var/cache/yum' and they didn't help. The only clue
is that 'yum check' returned an error, but I don't know if it is
enough to cause yum to just ignore updating seemingly unrelated
packages while allowing others. I would assume that a conflict with a
kmod would block a kernel update but it does not. What other steps can
I do to try to troubleshoot or fix this?

[root@Server log]# yum check
Loaded plugins: fastestmirror
kmod-redhat-mpt3sas-14.101.00.00-1.el7_3.x86_64 has installed
conflicts mpt3sas-kmod:
kmod-redhat-mpt3sas-14.101.00.00-1.el7_3.x86_64
Error: check all

It appears to be stuck at SL 7.3 according to:

[root@Server log]# yum info sl-release
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * epel: mirrors.syringanetworks.net
 * repos: ftp.scientificlinux.org
 * sl: ftp.scientificlinux.org
 * sl-extras: ftp.scientificlinux.org
 * sl-fastbugs: ftp.scientificlinux.org
 * sl-security: ftp.scientificlinux.org
Installed Packages
Name: sl-release
Arch: x86_64
Version : 7.3
Release : 4.sl7
Size: 69 k
Repo: installed
>From repo   : sl
Summary : Scientific Linux release file
License : GPLv2
Description : Scientific Linux release files

However, it has updated to and is running the kernel for the 7.5 release:

[root@Server log]# uname -a
Linux Server.Company.com 3.10.0-862.6.3.el7.x86_64 #1 SMP Tue Jun 26
12:13:22 CDT 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@Server log]# rpm -qa kernel
kernel-3.10.0-862.6.3.el7.x86_64
kernel-3.10.0-514.21.1.el7.x86_64
kernel-3.10.0-693.11.6.el7.x86_64

Thanks.