[CentOS] Which bug tracker should I use to report things to CentOS ? (recap)

[Fabian Arrotin]

With some moving parts within the CentOS Project, some people are now
confused about where to report things, as https://bugs.centos.org isn't
the only bugs/tickets  tracker, so let's just have a quick recap so that
people aren't confused anymore ? :)


# CentOS Stream (all kind of tickets)
see https://wiki.centos.org/FAQ/CentOSStream#Where_do_I_report_bugs.3F

So basically
https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208=CentOS%20Stream

# CentOS Infra, CBS, SIGs, mirror, CI, etc
see previous mail :
https://lists.centos.org/pipermail/centos-devel/2020-August/055980.html

# All the rest (CentOS Linux pkgs, etc)
https://bugs.centos.org

Hope that it helps , as we have people asking on irc the status of a
ticket that was filed in wrong tracker (and so also not correct category
as for example infra categories were removed/archived on
https://bugs.centos.org) and not reviewed.

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Filesystem choice for BackupPC extrenal drive

[Gionatan Danti]

Il 2021-02-05 01:41 Kenneth Porter ha scritto:

I'm setting up a CentOS 7 box as a BackupPC 4 server to back up
Windows boxes on my LAN. I'm using an external 1.5 TB USB drive for
the "pool". BackupPC deduplicates by saving all files in a pool, a
directory hiearchy with each file named for the checksum of the file,
and the directories acting as a hash tree to reach each pool file. A
backup for a specific workstation is a directory tree of checksums and
metadata that point into the pool for the actual file data.
Incremental backups are reverse deltas from periodic "filled" backups
of all files. I'm using rsyncd to pull changed files from the
workstations.

I'm deciding which filesystem to use for my external drive. I'm
thinking the main candidates are ext4 and xfs. What's the best
filesystem for this application?


While being a fan of XFS, for an external drive I would use EXT4. My 
(anectodal) experience is that EXT3/4 is more resilient to flacky 
hardware/connection as the one provided my many USB adapters.


Regards.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Filesystem choice for BackupPC extrenal drive

[Strahil Nikolov via CentOS]

XFS is suitable for parallel workload, so I would pick ext4 for this case.
Here is a quote from https://access.redhat.com/articles/3129891 :
Another way to characterize this is that the Ext4 file system variants tend to 
perform better on systems that have limited I/O capability. Ext3 and Ext4 
perform better on limited bandwidth (< 200MB/s) and up to ~1,000 IOPS 
capability. For anything with higher capability, XFS tends to be faster. 


Best Regards,Strahil Nikolov

Sent from Yahoo Mail on Android 
 
  On Fri, Feb 5, 2021 at 2:42, Kenneth Porter wrote:   
I'm setting up a CentOS 7 box as a BackupPC 4 server to back up Windows 
boxes on my LAN. I'm using an external 1.5 TB USB drive for the "pool". 
BackupPC deduplicates by saving all files in a pool, a directory hiearchy 
with each file named for the checksum of the file, and the directories 
acting as a hash tree to reach each pool file. A backup for a specific 
workstation is a directory tree of checksums and metadata that point into 
the pool for the actual file data. Incremental backups are reverse deltas 
from periodic "filled" backups of all files. I'm using rsyncd to pull 
changed files from the workstations.

I'm deciding which filesystem to use for my external drive. I'm thinking 
the main candidates are ext4 and xfs. What's the best filesystem for this 
application?



Repo for CentOS 7 users:




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
  
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Filesystem choice for BackupPC extrenal drive

[Kenneth Porter]

I'm setting up a CentOS 7 box as a BackupPC 4 server to back up Windows 
boxes on my LAN. I'm using an external 1.5 TB USB drive for the "pool". 
BackupPC deduplicates by saving all files in a pool, a directory hiearchy 
with each file named for the checksum of the file, and the directories 
acting as a hash tree to reach each pool file. A backup for a specific 
workstation is a directory tree of checksums and metadata that point into 
the pool for the actual file data. Incremental backups are reverse deltas 
from periodic "filled" backups of all files. I'm using rsyncd to pull 
changed files from the workstations.


I'm deciding which filesystem to use for my external drive. I'm thinking 
the main candidates are ext4 and xfs. What's the best filesystem for this 
application?




Repo for CentOS 7 users:




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] letsencrypt error

[Alexandre Leonenko]

>certbot-auto is no longer available.
It still getting updates
https://github.com/certbot/certbot/blob/master/certbot-auto
>   Forbidden\n\nForbidden\nhttp://mydomain/.well-known/acme-challenge/i_fU1bFrQZzgfVI2FtWo8Ov0ITjplCcPjXdK61Fwa-w
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Transition test report going from CentOS8 to Debian 10.

[Simon Matter]

> On Feb 4, 2021, at 8:39 AM, Lamar Owen  wrote:
>>
>> I posted a pretty complete rundown on the scientific linux users mailing
>> list, so I won't recap it all here.
>
> Link?
>
>> the transition was not any more difficult, really, than moving from
>> CentOS 7 to CentOS 8.
>
> That’s not my experience.
>
> I keep several of my packages running on CentOS and Debian (and more) and
> I keep running into several common problems:
>
> 1. The package names are often different, and not always differing by an
> obvious translation rule.  For instance, it’s “openldap-devel” on CentOS
> but “libldap2-dev” on Debian, where the normal rule would make it
> “libopenldap-dev”.  Why the difference?  Dunno, but I have to track such
> things down when setting up scripts that do cross-distro builds.  If I
> automate that translation, now I’m setting myself up for a future breakage
> when the package names change again.  (libldap3-dev?)
>
> 2. Some packages simply won’t be available.  Most often this happens in
> the Debian → CentOS direction, but I’ve run into cases going the other
> way.  Just for one, I currently have to install NPM from source on Debian
> because the platform version won’t work properly with the platform version
> of Node, last time I tested it.  Why?  Same answer as above.
>
> 3. Debian adopted systemd, but it didn’t adopt the rest of the Red Hat
> userland tooling.  For instance, it’s firewalld on CentOS, UFW on Ubuntu,
> and raw kernel firewall manipulation on Debian unless you install one of
> those two.  And then, which?
>
> 4. Network configuration is almost entirely different unless you turn off
> all the automation on all platforms, in which case you might as well
> switch to macOS or FreeBSD for all the good your muscle memory and
> training will do you.
>
> I’m not saying “don’t do it,” but to say it’s as smooth as from CentOS 7
> to 8?  Hard sell.
>
> I’ll give you one mulligan: the changes to the security rules in CentOS 8
> caused a huge upheaval for one of my applications, since it basically
> stopped it from running, being naughty in Red Hat’s omnisciently
> beneficent eyes.  We spent about a year fixing breakages due to 25 years
> of built-up assumptions about what was correct and sensible, which don’t
> affect us on other Linuxes because they didn’t implement the same SELinux
> rules.
>
> The details aren’t super-important, because the real take-away is this:
> it’s always *something.*
>
> (For those that must know, the biggie was that our systemd-based service
> used to run from /home/$APPNAME but that’s a no-no on C8 now.  Moving it
> all under /opt/$APPNAME and rearranging it all according to LFS rules,
> then finding and fixing all the places we depended on such paths was
> *painful*.)

Thanks for the big fat warning, now I know exactly what I'll have to do
sooner or later :)

Part of the problem is this: there was FHS 2.x and all was good. Then some
devs started with new tools like systemd and didn't care about FHS and
reinvented some new wheels. Later, after the new facts were established,
the FHS was adjusted to the new taste of things and people like you and me
were left with the mess :)

Simon

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Transition test report going from CentOS8 to Debian 10.

[Valeri Galtsev]

> On Feb 4, 2021, at 12:56 PM, mailist  wrote:
> 
> If you primarily use CentOS for web hosting with Apache, the Apache 
> configuration
> for Debian is a whole new world.  You will not be able to just copy the 
> CentOS config
> to Debian.
> 

It is different, but whoever ever configured apache web server will easily port 
configuration files. Simple copy and paste task. I just moved two web servers 
(with couple of virtual hosts == cnames each) from CentOS to Debian, no sweat. 
Takes much shorter ride than when you configure apache for the first time in 
your life.

Just my $0.02

Valeri

> Todd Merriman
> Software Toolz, Inc.
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Transition test report going from CentOS8 to Debian 10.

[mailist]

If you primarily use CentOS for web hosting with Apache, the Apache 
configuration
for Debian is a whole new world.  You will not be able to just copy the 
CentOS config

to Debian.

Todd Merriman
Software Toolz, Inc.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Transition test report going from CentOS8 to Debian 10.

[Akemi Yagi]

On Thu, Feb 4, 2021 at 10:23 AM Warren Young  wrote:
>
> On Feb 4, 2021, at 8:39 AM, Lamar Owen  wrote:
> >
> > I posted a pretty complete rundown on the scientific linux users mailing 
> > list, so I won't recap it all here.
>
> Link?

https://listserv.fnal.gov/scripts/wa.exe?A2=ind2102=SCIENTIFIC-LINUX-USERS=5275

Akemi
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Transition test report going from CentOS8 to Debian 10.

[Warren Young]

On Feb 4, 2021, at 8:39 AM, Lamar Owen  wrote:
> 
> I posted a pretty complete rundown on the scientific linux users mailing 
> list, so I won't recap it all here.

Link?

> the transition was not any more difficult, really, than moving from CentOS 7 
> to CentOS 8.

That’s not my experience.

I keep several of my packages running on CentOS and Debian (and more) and I 
keep running into several common problems:

1. The package names are often different, and not always differing by an 
obvious translation rule.  For instance, it’s “openldap-devel” on CentOS but 
“libldap2-dev” on Debian, where the normal rule would make it 
“libopenldap-dev”.  Why the difference?  Dunno, but I have to track such things 
down when setting up scripts that do cross-distro builds.  If I automate that 
translation, now I’m setting myself up for a future breakage when the package 
names change again.  (libldap3-dev?)

2. Some packages simply won’t be available.  Most often this happens in the 
Debian → CentOS direction, but I’ve run into cases going the other way.  Just 
for one, I currently have to install NPM from source on Debian because the 
platform version won’t work properly with the platform version of Node, last 
time I tested it.  Why?  Same answer as above.

3. Debian adopted systemd, but it didn’t adopt the rest of the Red Hat userland 
tooling.  For instance, it’s firewalld on CentOS, UFW on Ubuntu, and raw kernel 
firewall manipulation on Debian unless you install one of those two.  And then, 
which?

4. Network configuration is almost entirely different unless you turn off all 
the automation on all platforms, in which case you might as well switch to 
macOS or FreeBSD for all the good your muscle memory and training will do you.

I’m not saying “don’t do it,” but to say it’s as smooth as from CentOS 7 to 8?  
Hard sell.

I’ll give you one mulligan: the changes to the security rules in CentOS 8 
caused a huge upheaval for one of my applications, since it basically stopped 
it from running, being naughty in Red Hat’s omnisciently beneficent eyes.  We 
spent about a year fixing breakages due to 25 years of built-up assumptions 
about what was correct and sensible, which don’t affect us on other Linuxes 
because they didn’t implement the same SELinux rules.

The details aren’t super-important, because the real take-away is this: it’s 
always *something.*

(For those that must know, the biggie was that our systemd-based service used 
to run from /home/$APPNAME but that’s a no-no on C8 now.  Moving it all under 
/opt/$APPNAME and rearranging it all according to LFS rules, then finding and 
fixing all the places we depended on such paths was *painful*.)
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Intel/64 CentOS VM running on a Mac M1?

[Warren Young]

On Feb 3, 2021, at 5:28 PM, Lists  wrote:
> 
> I had the impression that MacOS' Rosetta II might do what I need

That’s rather difficult when the x86 code in question is on the other side of a 
virtualized CPU.  It’s a double translation, you see: real x86 code run on a 
virtual x86 CPU under your CPU’s virtualization extensions (e.g. Intel VT-x) 
under an Apple M1 ARM64 variant.

That’s not an impossible dance to pull off, but you’ll need three parties 
coordinating the dance steps if you want a high-fidelity CentOS-on-bare-metal 
emulation: Intel, Apple, and your VM technology provider of choice.

If you’re willing to drop one of those three parties out of the equation, you 
have alternatives:

1. Full CPU simulation, as with QEMU.  This should be able to run x86_64 CentOS 
on an M1, but it’ll be like the bad old days of software virtualization, back 
around 2000, where every instruction inside the VM had to be translated into 
native instructions.

2. Cross-compilation to x86 code under macOS, which allows Rosetta II to take 
effect, but now you aren’t running under CentOS proper any more.  Even if you 
port over the whole userland you depend on, you’ve still got the macOS kernel 
under your app, which may differ in significant areas that matter.

> I need to have access to a VM that's binary-compatible 
> with production so that I can make sure it "really really works" before 
> pushing stuff out. 

If “really really works” is defined in terms of automated testing — and if not, 
why not? — then it sounds like you want a CI system, though probably not a 
CI/CD system, if I read your intent properly.

That is, you build and test on macOS with ARM code, commit your changes to 
whatever release repository you maintain now, the CI system picks that up, 
tries to build it, runs the tests, and notifies you if anything fails.  The 
resulting binary packages can then be manually pushed to deployment.

(It’s that last difference that makes this something other than CI/CD.)

Making your code work across CPU types is more work, but it can point out 
hidden assumptions that are better off excised.

For instance, this line of C code has a data race in a multithreaded 
application:

 ++i;

…even though it compiles to a single Intel CPU instruction, even when ‘i’ is 
guaranteed to be stored in a register!

Whether it bites you on Intel gets you way down into niggly implementation 
details, but it’s *statistically guaranteed* to bite you on ARM due to its RISC 
nature, because it’s an explicit load-modify-store sequence requiring 3 or 4 
CPU instructions, and that few only if you don’t add write barriers to fix the 
problem.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Challenging times in trying to access oracle Linux documentation

[Shamim Shahriar]

Thank you so for your kind response, very much appreciated.

I was trying to access
https://support.oracle.com/knowledge/Oracle%20Linux%20and%20Virtualization/2644753_1.html
which, I understand if under support, but seems to be the only FreeIPA
documentation I found on my search.

Thank you all once again.

Best regards
Shamim

On Thu, 4 Feb 2021, 16:24 Frank Cox,  wrote:

> On Thu, 4 Feb 2021 12:03:30 +
> Shamim Shahriar wrote:
>
> > Apologies if this is considered unwelcome -- asking oracle question in
> > centos group -- but a lot of centos Vs oracle is going on here so hoping
> > this will not be shot down.
>
> Speaking for myself only, I have no problem with anyone posting Oracle
> Linux questions, answers or solutions in this mailing list.  I think that
> as time goes on, OL and Rocky Linux will start to get more discussion and
> coverage here.  Since they are all very similar to each other, most of the
> solutions for one will likely be applicable to all anyway and if there's a
> better alternative offered on one of the others, then that's worth knowing
> as well.
>
> --
> MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Challenging times in trying to access oracle Linux documentation

[Frank Cox]

On Thu, 4 Feb 2021 12:03:30 +
Shamim Shahriar wrote:

> Apologies if this is considered unwelcome -- asking oracle question in
> centos group -- but a lot of centos Vs oracle is going on here so hoping
> this will not be shot down.

Speaking for myself only, I have no problem with anyone posting Oracle Linux 
questions, answers or solutions in this mailing list.  I think that as time 
goes on, OL and Rocky Linux will start to get more discussion and coverage 
here.  Since they are all very similar to each other, most of the solutions for 
one will likely be applicable to all anyway and if there's a better alternative 
offered on one of the others, then that's worth knowing as well.

-- 
MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Transition test report going from CentOS8 to Debian 10.

[Valeri Galtsev]

On 2/4/21 9:39 AM, Lamar Owen wrote:

Sorry for the length


I'm posting this here since this particular transition has been 
mentioned on-list as one possibility for a path forward for current 
CentOS Linux users.  AlmaLinux, the Developer Subscription RHEL, Rocky, 
CentOS Stream, Springdale, upgrading to full RHEL; all these are also 
possibilities, too, and all have different strengths and weaknesses. The 
transition to Debian has a lot of strengths, including a long 
track-record of support (even if the support time for a particular 
release is shorter), a fully-open development model with no 'corporate 
overlord' that I know of, a large set of supported packages, and a huge 
community of developers and users.  For the CentOS user the main 
weakness is having to learn a few areas of difference in the way the 
system is setup and maintained; of course, if a ten-year 'stable' 
timeframe is really that important to you the lack of that is also a 
weakness.




Thank you, Lamar, for your post. I second what you said about strengths. 
I converted a few machines to Debian myself (number cruncher that is wen 
server and samba file server simultaneously, and a couple of 
workstations). Oh, I forgot this: laptop I set up for my wife quite a 
wile ago also runs Debian. I would add one thing (some may consider it 
extra strength, others may think otherwise). Debian doesn't make any 
decisions for you, so you really have to do your own thinking and 
decide, say, which firewall to install. And choices are plentiful.


And as Lamar said, you will have some learning curve with which commands 
to use, several will be different commands from what usually are in rpm 
based distro. But that is minor thing IMHO.


And while they tolerate it, I will once again mention: Consider FreeBSD 
(or any of BSD descendants) for servers. Once you are there, you will 
never regret that. I do not.


Thanks again, Lamar, for detailed and very encouraging post!

Valeri



So, last week I transitioned, as a test of sorts, my working CentOS 8 
main laptop to Debian 10.  I kept a complete backup of the C8 install 
should I wish to go back to it, and installed Buster to a new mSATA SSD, 
but ported the two SATA drives (Dell Precision M6700 - has an mSATA slot 
plus two SATA bays) straight over after making full backups.



I posted a pretty complete rundown on the scientific linux users mailing 
list, so I won't recap it all here.  The bottom line was the the 
transition was not any more difficult, really, than moving from CentOS 7 
to CentOS 8.  The software versions in Buster are pretty close to what 
is in CentOS 8, although I have yet to need any third-party repository 
(PPA) for anything I've needed to install.



All the packages I have worked with so far have worked fine with a 
little bit of massaging.  These include commercial (and costly) software 
such as Harrison Consoles' Mixbus32C, Qoppa's PDFStudio2019 
Professional, and others.


So if you were to decide that this is the route for you to take, it does 
work and I found it to be not nearly as hard as I had thought it might 
be.  If you install GNOME 3 you get GNOME 3; it feels pretty much the 
same as a non-Classic CentOS GNOME 3, just with a different set of 
extensions installed by default.


That's on the workstation.

On the server side, I'm evaluating Proxmox for the virtualization 
solution, and so far I'm finding it to be a pretty easy migration.  I'm 
using the 'non-subscription' repository, so this is a no-cost option. 
Even getting the box registered to our EMC Clariion SAN was relatively 
easy; EMC provides the Unisphere Server Utility for Linux x64 in RPM 
form; the latest I have is 
"ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm" (which is 
fairly old, but I did say Clariion arrays, so they're pretty old, too). 
Debian has provided the 'alien' tool for some time; after installing 
alien, a simple 'alien -i 
ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm' installed the 
EMC RPM in the correct place.  Proxmox already included everything that 
serverutilcli requires; on a plain Buster install I had to install 
dm-multipath and the device mapper libraries and tools before 
serverutilcli would find the arrays; but it ran just like it did on 
CentOS 8 (and 7).


I haven't decided whether to stay on Debian or not; too early to tell. I 
have time to test and evaluate.  My CentOS 7 installs aren't goin 
anywhere, though, at least until late 2023.  And I've registered for a 
Developer subscription of RHEL so that I can properly evaluate that 
option, too.


This is the beauty of open source: we have OPTIONS.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos


--

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

[CentOS] Transition test report going from CentOS8 to Debian 10.

[Lamar Owen]

Sorry for the length


I'm posting this here since this particular transition has been 
mentioned on-list as one possibility for a path forward for current 
CentOS Linux users.  AlmaLinux, the Developer Subscription RHEL, Rocky, 
CentOS Stream, Springdale, upgrading to full RHEL; all these are also 
possibilities, too, and all have different strengths and weaknesses.  
The transition to Debian has a lot of strengths, including a long 
track-record of support (even if the support time for a particular 
release is shorter), a fully-open development model with no 'corporate 
overlord' that I know of, a large set of supported packages, and a huge 
community of developers and users.  For the CentOS user the main 
weakness is having to learn a few areas of difference in the way the 
system is setup and maintained; of course, if a ten-year 'stable' 
timeframe is really that important to you the lack of that is also a 
weakness.



So, last week I transitioned, as a test of sorts, my working CentOS 8 
main laptop to Debian 10.  I kept a complete backup of the C8 install 
should I wish to go back to it, and installed Buster to a new mSATA SSD, 
but ported the two SATA drives (Dell Precision M6700 - has an mSATA slot 
plus two SATA bays) straight over after making full backups.



I posted a pretty complete rundown on the scientific linux users mailing 
list, so I won't recap it all here.  The bottom line was the the 
transition was not any more difficult, really, than moving from CentOS 7 
to CentOS 8.  The software versions in Buster are pretty close to what 
is in CentOS 8, although I have yet to need any third-party repository 
(PPA) for anything I've needed to install.



All the packages I have worked with so far have worked fine with a 
little bit of massaging.  These include commercial (and costly) software 
such as Harrison Consoles' Mixbus32C, Qoppa's PDFStudio2019 
Professional, and others.


So if you were to decide that this is the route for you to take, it does 
work and I found it to be not nearly as hard as I had thought it might 
be.  If you install GNOME 3 you get GNOME 3; it feels pretty much the 
same as a non-Classic CentOS GNOME 3, just with a different set of 
extensions installed by default.


That's on the workstation.

On the server side, I'm evaluating Proxmox for the virtualization 
solution, and so far I'm finding it to be a pretty easy migration.  I'm 
using the 'non-subscription' repository, so this is a no-cost option.  
Even getting the box registered to our EMC Clariion SAN was relatively 
easy; EMC provides the Unisphere Server Utility for Linux x64 in RPM 
form; the latest I have is 
"ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm" (which is 
fairly old, but I did say Clariion arrays, so they're pretty old, too).  
Debian has provided the 'alien' tool for some time; after installing 
alien, a simple 'alien -i 
ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm' installed the 
EMC RPM in the correct place.  Proxmox already included everything that 
serverutilcli requires; on a plain Buster install I had to install 
dm-multipath and the device mapper libraries and tools before 
serverutilcli would find the arrays; but it ran just like it did on 
CentOS 8 (and 7).


I haven't decided whether to stay on Debian or not; too early to tell.  
I have time to test and evaluate.  My CentOS 7 installs aren't goin 
anywhere, though, at least until late 2023.  And I've registered for a 
Developer subscription of RHEL so that I can properly evaluate that 
option, too.


This is the beauty of open source: we have OPTIONS.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Challenging times in trying to access oracle Linux documentation

[Nicolas Kovacs]

Le 04/02/2021 à 13:03, Shamim Shahriar a écrit :
> I am unable to access any of the oracle documentation I need, as it keeps
> on asking for support identifier number, which, as far as I can tell, is
> only available if I purchase an expensive support subscription.

Everything in Oracle is free as in beer. No subscription needed.

https://www.oracle.com/linux/technologies/

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Challenging times in trying to access oracle Linux documentation

[Gianluca Cecchi]

On Thu, Feb 4, 2021 at 1:04 PM Shamim Shahriar 
wrote:

>
>
> Has anyone experienced that or is it me having the issue? If I have to pay
> subscription, why not continue with RHEL subscription anyway?
>
> Would appreciate if someone could please confirm.


Do you have a link that doesn't work?
It seems I'm able to go here without any login authentication:
https://docs.oracle.com/en/operating-systems/oracle-linux/8/install/

and in general (for 6 and 7 too) here:
https://docs.oracle.com/en/operating-systems/oracle-linux/

Gianluca
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Challenging times in trying to access oracle Linux documentation

[Shamim Shahriar]

Good afternoon everyone, hope you all are well.

Apologies if this is considered unwelcome -- asking oracle question in
centos group -- but a lot of centos Vs oracle is going on here so hoping
this will not be shot down.

I am unable to access any of the oracle documentation I need, as it keeps
on asking for support identifier number, which, as far as I can tell, is
only available if I purchase an expensive support subscription. Even
obtaining a free oracle cloud account does not give you any access. I was
trying to access oracle FreeIPA setup how to documentation, and even after
many emails work oracle support over several weeks -- no resolution! They
are not even clear as to what I need to do to obtain access -- all they are
saying is I need a SI number!!!

Has anyone experienced that or is it me having the issue? If I have to pay
subscription, why not continue with RHEL subscription anyway?

Would appreciate if someone could please confirm.

Best regards
Shamim
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos