SCIENTIFIC-LINUX-USERS Archives

May 2021

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"~Stack~" <[log in to unmask]>
Reply To:
~Stack~
Date:
Thu, 6 May 2021 19:15:33 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (80 lines)
On 5/6/21 7:02 PM, Nico Kadel-Garcia wrote:
> On Thu, May 6, 2021 at 5:10 PM ~Stack~ <[log in to unmask]> wrote:
>>
>> On 5/6/21 3:21 PM, Yasha Karant wrote:
>>> Excerpt from a previous post on this matter:
>>>
>>> On Thu, 2021-05-06 at 02:43 -0400, Nico Kadel-Garcia wrote:
>>> The misfeatures you've groused about are not due to AlmaLinux, they're
>>> straight RHEL problems. Let's assign blame and credit where they are
>>> due.
>>> End excerpt.
>>>
>>> Presumably, Rocky Linux (IBM RHEL "clone") does have the same
>>> "misfeatures"?  Would one of the after-EL repos (ElRepo et al.) be
>>> willing to produce an alternative set of RPMs to address the
>>> "misfeatures"?  Would Alma or Rocky or ... ?  No point in mentioning
>>> Fermilab/CERN -- SL8 will never exist.
>>
>> Since Rocky is aiming for exact 1:1 compatibility then I would say that
>> there won't be much deviation there.
> 
> Yeah. One big issue right now is anaconda, the installer suite, which
> is vulnerable to feature creep at the cost of useful options. It's no
> longer possible in the GUI to pick and choose individual packages or
> bundles of software, and the lack of a default mirror for network
> based installation is just plain stupid.


No argument from me there. I'm not a fan of anaconda. But I rarely use 
that for installing these days anyway. Even my home lab is kickstarted.
  > Unless you're a weasel like
> me, you're unlikely to deduce that a working URL for CentOS
> installation these days isis:
> 
>        https://urldefense.proofpoint.com/v2/url?u=https-3A__mirrors.edge.kernel.org_centos_8.3.2011_BaseOS_x86-5F64_os_&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=CTZq3-snhnq7A-XxoSrTrqRFjeCB_15gt967vVnnavQ&s=Qobxq5QzLlehm36QMC_hvjGC8txbB1gyj7FkCaW1_XI&e= 
> 
> Notice the "BasOS", then architecture, then "os", instead of the older:
> 
>       https://urldefense.proofpoint.com/v2/url?u=https-3A__mirrors.edge.kernel.org_centos_7.9.2009_os_x86-5F64_&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=CTZq3-snhnq7A-XxoSrTrqRFjeCB_15gt967vVnnavQ&s=b4D24OBMzTPw_Q5_uK8zk9cZhLt3p42h7s5WWyRMVfA&e= 
> 
> Notice that "BaseOS" is now considered more important than the
> architecture or the OS, even though the channel only really makes
> sense as part of the "os". Every RHEL 8 fork is going to have to deal
> with this unwelcome segregation of paritally overlapping channels, all
> of which are needed for a pretty basic server grade OS installation.


Again. No argument from me there. It still annoys me too.


> I think the theory was to split the load at Red Hat, to reduce the
> metadata burden of having a single channel and reduce the load on
> their servers. It's not helpful.

Actually, it is because of how they wanted to split out certain modules 
for certain groups and activities. It would make sense that if a certain 
module had conflicting packages that it would be segregated and those 
that need it would know how to use it. At least in theory. There's 
plenty of people who will argue the pros and cons of this modularity. It 
used to annoy me but once I realized how to get what I need, I scripted 
it and don't really care that much these days. YMMV.


> Anaconda has other issues: the difficulty of scripting and making its
> behavior consistent isn't burdensome if you're, well, *me* and you can
> handwrite ks.cfg files. But the kickstart GUI is pretty bad, and has
> no options to include muliple '%pre' or '%post' scripts, it erases
> multiple such scripts that may be read from a reference ks.cfg.
> 

Creating Kickstarts isn't that bad. Once you do a install with the GUI, 
you are given the /root/anaconda.ks file which serves as a base. And I 
know it is dry reading, especially for those that aren't SysAdmin Nerds 
but RH does provide good documentation for it:
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2Dus_red-5Fhat-5Fenterprise-5Flinux_8_html-2Dsingle_performing-5Fan-5Fadvanced-5Frhel-5Finstallation_index&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=CTZq3-snhnq7A-XxoSrTrqRFjeCB_15gt967vVnnavQ&s=qPZLgW8wrzJijssESVieCcywSrMdI0_9PhpLmKQkrHQ&e= 

I've never used a gui for the kickstarts so I can't comment there.

~Stack~

ATOM RSS1 RSS2