Re: Scientific Linux Advice
On Tue, Jun 29, 2021 at 2:36 PM Larry Linder <0dea520dd180-dmarc-requ...@listserv.fnal.gov> wrote: > > To support products for 22 years is difficult. > Using VMware is a good solution that we have been using for a long time. > I even use Win2000 pro for some applications and Dos all under VMWare. > The connection to the Linux file system is "samba". > > Everyone misses the point. The problem is setting up a system the way > we want it and the ability to do that after RH 7 is broken! and has some > land mines. A function that can wipe out a file system is flawed and > cannot be trusted. Permit me to look very innocent over here as the guy who packports recent Samba releases, with full domain controller options enabled, to RHEL and CentOs 7, and first started porting Samba to other operating systems releases shortly after it was first published 30 years ago. The connection is "CIFS". Samba provides CIFS, and can provide full domain controllers if the feature is not deliberately disabled as Red Hat has elected to do for various reasons. I support various tools that are that old. I'd encourage our hero to use the original SRPM and recompile the software using "mock" if possible, much as I compile RPMs for various RHEL based releases with various tools at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nkadel_=DwIFaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=rDW_UqoIMxVYdmM513fB7o4yVU2fpoug7cRbAg2rbwY=oLvvFN4VDsdcWaNJmCZHx34di9JabfnVLk_y1w5NDts= , including the "sambarepo" to build up all the dependencies for modern Samba releases. Gentlemen, which tools specifically do you need ported? Can I point you at reasonable examples of RPM updating setups? Nico Kadel-Garcia > Fortunately VMware works - we just bought a new VMWare version. Update > is painless. > > Larry Linder > > On Tue, 2021-06-29 at 09:48 -0700, Konstantin Olchanski wrote: > > On Tue, Jun 29, 2021 at 06:43:12AM +, Nick Matchett wrote: > > > I hope that someone could help me identify an individual or business that > > > would be able to help me with the following problem. > > > My business has some software that we acquired the responsibility to > > > maintain and support, and currently sits on Scientific Linux version 6.3. > > > Unfortunately, we are at a stage where our customers are asking to bring > > > the software onto a more current version of a Linux platform. > > > We would like to migrate to Red Hat or CentOS version 7.9 (or perhaps > > > version 8) > > > > > > Oh, boy! We are on the receiving end of such problem with Altera. Their > > latest fpga compiler > > does not support cyclone-1 FPGA, the last version that does still by a > > miracle > > runs on ubuntu and centos7, and of course Altera will never update it. As > > if nobody needs > > to compile cyclone-1 fpga code. > > > > If, like in this case, your application still does something useful and > > your customers still > > want to run it, perhaps simplest is not to monkey around with it, just > > package it > > as a VM container that runs on current-ish linuxes. > > > > > I hope that someone could help me identify an individual or business > > > > I wish you best luck with hiring the right staff, contractor or consultant > > to resolve your trouble. > > > > K.O. > > > > > > > > > > > > > > > > We have been working on a migration from Scientific Linux 6.3 to Redhat > > > 7.9. > > > > > > Unfortunately, we have limited Linux OS skills in our business, and we > > > have approached this with a fresh RH 7.9 install and then applying the > > > RPM of our software. There is a big mismatch between Scientific Linux > > > 6.3 to Redhat 7.9 in terms of libraries, file structure and type of > > > libraries between the software and we have not been able to reconcile > > > those. > > > > > > > > > > > > I would appreciate any suggestion or advice on the best upgrade path to > > > achieve this update and would be happy to take recommendations on > > > individuals or companies who might be interested in a professional > > > service engagement to help solve the problem. > > > > > > > > > > > > Thanks in advance > >
Re: Scientific Linux Advice
I will check out slackware. Thanks larry Linder On Tue, 2021-06-29 at 12:40 -0700, Bruce Ferrell wrote: > Larry, > > It's NOT difficult to support a distro for 22 years. Look at Slackware. > > It's difficult to keep up with shiny kewl new toys, many of which after > 15 years STILL don't work correctly (i.e. don't have serious regressions > that break running systems). > > The issue is that developers get kewl shiny new ideas (I won't name any > to forestall the usual religious/flame wars)... packagers weave those > into everything in the ecosystems without regard to end user needs... > Then a bug is found and all hell breaks loose. > > VMWare in and of itself does NOT run end user applications. When bugs > are found in the things the VMWare DOES run, the issue under discussion > STILL rears it's ugly head. > > I ran VMWare 1.x to 2.x... Then they took away the ability to run it on > a stock distro at 3.x AND took away the web UI (you had to have a > windows application to manage VMWare). I gave 'em the finger and moved > on... Now I support users of VMWare and several other versions of > virtualization in number of capacities. Things break there too, trust me. > > > > On 6/29/21 11:37 AM, Larry Linder wrote: > > To support products for 22 years is difficult. > > Using VMware is a good solution that we have been using for a long time. > > I even use Win2000 pro for some applications and Dos all under VMWare. > > The connection to the Linux file system is "samba". > > > > Everyone misses the point. The problem is setting up a system the way > > we want it and the ability to do that after RH 7 is broken! and has some > > land mines. A function that can wipe out a file system is flawed and > > cannot be trusted. > > > > Fortunately VMware works - we just bought a new VMWare version. Update > > is painless. > > > > Larry Linder > > > > On Tue, 2021-06-29 at 09:48 -0700, Konstantin Olchanski wrote: > >> On Tue, Jun 29, 2021 at 06:43:12AM +, Nick Matchett wrote: > >>> I hope that someone could help me identify an individual or business that > >>> would be able to help me with the following problem. > >>> My business has some software that we acquired the responsibility to > >>> maintain and support, and currently sits on Scientific Linux version 6.3. > >>> Unfortunately, we are at a stage where our customers are asking to bring > >>> the software onto a more current version of a Linux platform. > >>> We would like to migrate to Red Hat or CentOS version 7.9 (or perhaps > >>> version 8) > >> > >> Oh, boy! We are on the receiving end of such problem with Altera. Their > >> latest fpga compiler > >> does not support cyclone-1 FPGA, the last version that does still by a > >> miracle > >> runs on ubuntu and centos7, and of course Altera will never update it. As > >> if nobody needs > >> to compile cyclone-1 fpga code. > >> > >> If, like in this case, your application still does something useful and > >> your customers still > >> want to run it, perhaps simplest is not to monkey around with it, just > >> package it > >> as a VM container that runs on current-ish linuxes. > >> > >>> I hope that someone could help me identify an individual or business > >> I wish you best luck with hiring the right staff, contractor or consultant > >> to resolve your trouble. > >> > >> K.O. > >> > >> > >>> > >>> > >>> We have been working on a migration from Scientific Linux 6.3 to Redhat > >>> 7.9. > >>> > >>> Unfortunately, we have limited Linux OS skills in our business, and we > >>> have approached this with a fresh RH 7.9 install and then applying the > >>> RPM of our software. There is a big mismatch between Scientific Linux > >>> 6.3 to Redhat 7.9 in terms of libraries, file structure and type of > >>> libraries between the software and we have not been able to reconcile > >>> those. > >>> > >>> > >>> > >>> I would appreciate any suggestion or advice on the best upgrade path to > >>> achieve this update and would be happy to take recommendations on > >>> individuals or companies who might be interested in a professional > >>> service engagement to help solve the problem. > >>> > >>> > >>> > >>> Thanks in advance
Re: Scientific Linux Advice
Larry, It's NOT difficult to support a distro for 22 years. Look at Slackware. It's difficult to keep up with shiny kewl new toys, many of which after 15 years STILL don't work correctly (i.e. don't have serious regressions that break running systems). The issue is that developers get kewl shiny new ideas (I won't name any to forestall the usual religious/flame wars)... packagers weave those into everything in the ecosystems without regard to end user needs... Then a bug is found and all hell breaks loose. VMWare in and of itself does NOT run end user applications. When bugs are found in the things the VMWare DOES run, the issue under discussion STILL rears it's ugly head. I ran VMWare 1.x to 2.x... Then they took away the ability to run it on a stock distro at 3.x AND took away the web UI (you had to have a windows application to manage VMWare). I gave 'em the finger and moved on... Now I support users of VMWare and several other versions of virtualization in number of capacities. Things break there too, trust me. On 6/29/21 11:37 AM, Larry Linder wrote: To support products for 22 years is difficult. Using VMware is a good solution that we have been using for a long time. I even use Win2000 pro for some applications and Dos all under VMWare. The connection to the Linux file system is "samba". Everyone misses the point. The problem is setting up a system the way we want it and the ability to do that after RH 7 is broken! and has some land mines. A function that can wipe out a file system is flawed and cannot be trusted. Fortunately VMware works - we just bought a new VMWare version. Update is painless. Larry Linder On Tue, 2021-06-29 at 09:48 -0700, Konstantin Olchanski wrote: On Tue, Jun 29, 2021 at 06:43:12AM +, Nick Matchett wrote: I hope that someone could help me identify an individual or business that would be able to help me with the following problem. My business has some software that we acquired the responsibility to maintain and support, and currently sits on Scientific Linux version 6.3. Unfortunately, we are at a stage where our customers are asking to bring the software onto a more current version of a Linux platform. We would like to migrate to Red Hat or CentOS version 7.9 (or perhaps version 8) Oh, boy! We are on the receiving end of such problem with Altera. Their latest fpga compiler does not support cyclone-1 FPGA, the last version that does still by a miracle runs on ubuntu and centos7, and of course Altera will never update it. As if nobody needs to compile cyclone-1 fpga code. If, like in this case, your application still does something useful and your customers still want to run it, perhaps simplest is not to monkey around with it, just package it as a VM container that runs on current-ish linuxes. I hope that someone could help me identify an individual or business I wish you best luck with hiring the right staff, contractor or consultant to resolve your trouble. K.O. We have been working on a migration from Scientific Linux 6.3 to Redhat 7.9. Unfortunately, we have limited Linux OS skills in our business, and we have approached this with a fresh RH 7.9 install and then applying the RPM of our software. There is a big mismatch between Scientific Linux 6.3 to Redhat 7.9 in terms of libraries, file structure and type of libraries between the software and we have not been able to reconcile those. I would appreciate any suggestion or advice on the best upgrade path to achieve this update and would be happy to take recommendations on individuals or companies who might be interested in a professional service engagement to help solve the problem. Thanks in advance
Re: Scientific Linux Advice
To support products for 22 years is difficult. Using VMware is a good solution that we have been using for a long time. I even use Win2000 pro for some applications and Dos all under VMWare. The connection to the Linux file system is "samba". Everyone misses the point. The problem is setting up a system the way we want it and the ability to do that after RH 7 is broken! and has some land mines. A function that can wipe out a file system is flawed and cannot be trusted. Fortunately VMware works - we just bought a new VMWare version. Update is painless. Larry Linder On Tue, 2021-06-29 at 09:48 -0700, Konstantin Olchanski wrote: > On Tue, Jun 29, 2021 at 06:43:12AM +, Nick Matchett wrote: > > I hope that someone could help me identify an individual or business that > > would be able to help me with the following problem. > > My business has some software that we acquired the responsibility to > > maintain and support, and currently sits on Scientific Linux version 6.3. > > Unfortunately, we are at a stage where our customers are asking to bring > > the software onto a more current version of a Linux platform. > > We would like to migrate to Red Hat or CentOS version 7.9 (or perhaps > > version 8) > > > Oh, boy! We are on the receiving end of such problem with Altera. Their > latest fpga compiler > does not support cyclone-1 FPGA, the last version that does still by a miracle > runs on ubuntu and centos7, and of course Altera will never update it. As if > nobody needs > to compile cyclone-1 fpga code. > > If, like in this case, your application still does something useful and your > customers still > want to run it, perhaps simplest is not to monkey around with it, just > package it > as a VM container that runs on current-ish linuxes. > > > I hope that someone could help me identify an individual or business > > I wish you best luck with hiring the right staff, contractor or consultant to > resolve your trouble. > > K.O. > > > > > > > > > > We have been working on a migration from Scientific Linux 6.3 to Redhat 7.9. > > > > Unfortunately, we have limited Linux OS skills in our business, and we have > > approached this with a fresh RH 7.9 install and then applying the RPM of > > our software. There is a big mismatch between Scientific Linux 6.3 to > > Redhat 7.9 in terms of libraries, file structure and type of libraries > > between the software and we have not been able to reconcile those. > > > > > > > > I would appreciate any suggestion or advice on the best upgrade path to > > achieve this update and would be happy to take recommendations on > > individuals or companies who might be interested in a professional service > > engagement to help solve the problem. > > > > > > > > Thanks in advance >
Re: Scientific Linux Advice
Yes, for better or worse, that's part of "binary compatible". If you need bugs fixed faster than RedHat is fixing them, you need to fix them yourself, or get someone else to. Sometimes you can find newer versions with fixes in other public repos, but again, the onus is on you to provide the fix in your environment. That's true regardless of which RHEL-based distro you're using. From: owner-scientific-linux-us...@listserv.fnal.gov on behalf of Jon Pruente Sent: Tuesday, June 29, 2021 11:45 To: larry.lin...@micro-controls.com Cc: Nick Matchett ; scientific-linux-us...@listserv.fnal.gov ; Edmund Manabat Subject: Re: Scientific Linux Advice Caution: EXTERNAL email On Tue, Jun 29, 2021 at 11:32 AM Larry Linder <0dea520dd180-dmarc-requ...@listserv.fnal.gov<mailto: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: Scientific Linux Advice
On Tue, Jun 29, 2021 at 06:43:12AM +, Nick Matchett wrote: > I hope that someone could help me identify an individual or business that > would be able to help me with the following problem. > My business has some software that we acquired the responsibility to maintain > and support, and currently sits on Scientific Linux version 6.3. > Unfortunately, we are at a stage where our customers are asking to bring the > software onto a more current version of a Linux platform. > We would like to migrate to Red Hat or CentOS version 7.9 (or perhaps > version 8) Oh, boy! We are on the receiving end of such problem with Altera. Their latest fpga compiler does not support cyclone-1 FPGA, the last version that does still by a miracle runs on ubuntu and centos7, and of course Altera will never update it. As if nobody needs to compile cyclone-1 fpga code. If, like in this case, your application still does something useful and your customers still want to run it, perhaps simplest is not to monkey around with it, just package it as a VM container that runs on current-ish linuxes. > I hope that someone could help me identify an individual or business I wish you best luck with hiring the right staff, contractor or consultant to resolve your trouble. K.O. > > > > We have been working on a migration from Scientific Linux 6.3 to Redhat 7.9. > > Unfortunately, we have limited Linux OS skills in our business, and we have > approached this with a fresh RH 7.9 install and then applying the RPM of our > software. There is a big mismatch between Scientific Linux 6.3 to Redhat 7.9 > in terms of libraries, file structure and type of libraries between the > software and we have not been able to reconcile those. > > > > I would appreciate any suggestion or advice on the best upgrade path to > achieve this update and would be happy to take recommendations on > individuals or companies who might be interested in a professional service > engagement to help solve the problem. > > > > Thanks in advance -- 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 Linux Advice
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: Scientific Linux Advice
Because of vendor update situations and other causes I (and my grad students) have done what you require more than once. The easiest approach -- if you have adequate disk space, etc., it to use Virtual Box (licensed for free) or VMWare (variant depending upon what you need -- the only one that is licensed for free is VMWare Player) and create under a type 2 hypervisor a virtual machine an instance of the exact OS and related environment that you need. The other method is a merry chase, depending upon the situation. First, find all of the unresolved library and header files that the installable RPM needs. See if these are available from any reliable distro or source for the OS release you are using. This may take repeated iterations. Say, X is needed, and you find X (that supports exactly what you need, say blah.3.1-4 not blah.3.1-3 nor blah.3.1-5, unless you are very lucky and any blah.3 will suffice. After you have fixed the need for X, you may find a need for Y, etc., and then you continue. If you must build from source (say, a .SRPM), then the build environment must be the same, including the C/C++ compiler and the C/C++ library(ies), along with whatever other utilities are needed. If you are lucky, and the .SRPM wanted say libblah.4.2-1 but the current libblah.6.x back supports the older functionality, you may be able to build simply by doing a soft (false name) link between the current libblah and the libblah version you need. This sometimes works. If this does not work, and the libblah and other utilities are not available in the correct version for the environment (OS plus whatever) upon which the application is to be run, then you must modify the source code (after expanding the .SRPM to a full source) to use the current syntax and capabilities that are in use. This may require minor rewriting, or it may require significant re-design and re-implementation. Finally, once the desired application is built and runs (runs is critical -- it may build and install, but fail to run because of other dependencies), you must test that it still works to your needs, particularly on "edge" cases. Regrettably, this is not always a simple process and in some cases requires a major re-design. If you are not both knowledgeable and "skilled", this can be a learning experience and a large investment of time. Even if both conditions are met, it still can be a large investment of time. On 6/29/21 8:56 AM, Dave Dykstra wrote: Often an rpm from an older Linux OS will still work on a newer one, but it depends on how complicated it is. It would be best to recompile it from the source rpm and make a new binary rpm out of it based on RHEL7, although it is likely that some porting will also need to be done for that. An alternative is to install your SL6 rpm into a CentOS6 docker or singularity container, and run the docker or singularity application on the newer operating system. In any case, you probably are going to need some help, and I don't know if there is anybody on this mailing list that provides such professional services. I suggest googling for that. Dave On Tue, Jun 29, 2021 at 06:43:12AM +, Nick Matchett wrote: I hope that someone could help me identify an individual or business that would be able to help me with the following problem. My business has some software that we acquired the responsibility to maintain and support, and currently sits on Scientific Linux version 6.3. Unfortunately, we are at a stage where our customers are asking to bring the software onto a more current version of a Linux platform. We would like to migrate to Red Hat or CentOS version 7.9 (or perhaps version 8) We have been working on a migration from Scientific Linux 6.3 to Redhat 7.9. Unfortunately, we have limited Linux OS skills in our business, and we have approached this with a fresh RH 7.9 install and then applying the RPM of our software. There is a big mismatch between Scientific Linux 6.3 to Redhat 7.9 in terms of libraries, file structure and type of libraries between the software and we have not been able to reconcile those. I would appreciate any suggestion or advice on the best upgrade path to achieve this update and would be happy to take recommendations on individuals or companies who might be interested in a professional service engagement to help solve the problem. Thanks in advance
Re: Scientific Linux Advice
As a bunch of dirty finger engineers we have a serious problem with the the path that Linux has taken. Be forwarned that when you migrate to 7 and later the 32 libs are gone and most applications will not work or install. SL 6.9 is also missing a lot of the 32 bit libs and the graphics do not work. This is crude but effective. We have a SL 6.5 server that has been updated to SL 6.9 but still had the 32 bit libs we needed. We just crated a bastard version of 7.6 with 32 bit libs. We did it by the brail method. When the appication complained about a missing lib we added it. The list was initially long but on closer inspection a lot of the error messages are redundant. After a few hours of work our engineering applications installed and worked. This is a blind alley, but it gave us a few years to get a real solution to the problem. Reading between the lines - IBM & RedHat want the users who use independent installations to just go away. They wont say it but actions are pretty hard to gloss over. All you have to do is use Gnome for a while and your finger falls off due to terrible number of clicks to do something simple. 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. Never trust the install process in the "custom" world because it is hopelessly broken, it will erase any disk attached even if you tell it not to format it. Can you imagine a 40 Tera byte server - errased and the rebuild from back up. BEFORE you attempt to upgrade you system - YOU BETTER HAVE A BULLET PROOF BACKUP that is NOT Connected . - No BS. The Debian drivatives have a similar problem. If you remove an application for a second time. The C++ toss is never caught and remains active. The next removal it erases all disks attached. How about that for code testing - it compiles without errors - ship it. Damm glad these people never build bridges or control for Aircraft - opps the 737 max 8 is a victum of the sw people don't know how an airplane flys. The sad part is no one up stream gives a " " . Summary: We just updated a number of workstaitions to SL 6.5 and then to 6.9 so we can get our work done. We are evaluating other options, and just loaded a box with BSD to test. Regards Larry Linder On Tue, 2021-06-29 at 06:43 +, Nick Matchett wrote: > I hope that someone could help me identify an individual or business > that would be able to help me with the following problem. > > > > My business has some software that we acquired the responsibility to > maintain and support, and currently sits on Scientific Linux version > 6.3. Unfortunately, we are at a stage where our customers are asking > to bring the software onto a more current version of a Linux platform. > > > > We would like to migrate to Red Hat or CentOS version 7.9 (or perhaps > version 8) > > > > We have been working on a migration from Scientific Linux 6.3 to > Redhat 7.9. > > Unfortunately, we have limited Linux OS skills in our business, and we > have approached this with a fresh RH 7.9 install and then applying the > RPM of our software. There is a big mismatch between Scientific Linux > 6.3 to Redhat 7.9 in terms of libraries, file structure and type of > libraries between the software and we have not been able to reconcile > those. > > > > I would appreciate any suggestion or advice on the best upgrade path > to achieve this update and would be happy to take recommendations on > individuals or companies who might be interested in a professional > service engagement to help solve the problem. > > > > Thanks in advance > >
Re: Scientific Linux Advice
Often an rpm from an older Linux OS will still work on a newer one, but it depends on how complicated it is. It would be best to recompile it from the source rpm and make a new binary rpm out of it based on RHEL7, although it is likely that some porting will also need to be done for that. An alternative is to install your SL6 rpm into a CentOS6 docker or singularity container, and run the docker or singularity application on the newer operating system. In any case, you probably are going to need some help, and I don't know if there is anybody on this mailing list that provides such professional services. I suggest googling for that. Dave On Tue, Jun 29, 2021 at 06:43:12AM +, Nick Matchett wrote: > I hope that someone could help me identify an individual or business that > would be able to help me with the following problem. > > My business has some software that we acquired the responsibility to maintain > and support, and currently sits on Scientific Linux version 6.3. > Unfortunately, we are at a stage where our customers are asking to bring the > software onto a more current version of a Linux platform. > > We would like to migrate to Red Hat or CentOS version 7.9 (or perhaps > version 8) > > We have been working on a migration from Scientific Linux 6.3 to Redhat 7.9. > > Unfortunately, we have limited Linux OS skills in our business, and we have > approached this with a fresh RH 7.9 install and then applying the RPM of our > software. There is a big mismatch between Scientific Linux 6.3 to Redhat 7.9 > in terms of libraries, file structure and type of libraries between the > software and we have not been able to reconcile those. > > I would appreciate any suggestion or advice on the best upgrade path to > achieve this update and would be happy to take recommendations on > individuals or companies who might be interested in a professional service > engagement to help solve the problem. > > Thanks in advance
RE: Scientific Linux Advice
Hi, I think it would make sense to forklift upgrade it to EL8 rather than EL7 as you will have several more years of runway for your app. Depending on the language the application was written in, you will at least need to recompile it in a build environment that matches the target environment but I think this is what you implied that had been tried already. While a lot of libraries probably have changed in the years between, in general, library bugwards compatibility is pretty good. If libraries are missing completely they can probably be distributed on the side in separate packages (taking into account library licensing, etc.) like many do. Regarding file system structure, I've noticed that quite a lot of ISVs put everything in /opt and are done with it. Not sure what your customers' thoughts are about that. I think it's not the cleanest way to do it but it tends to avoid problems as there won't be a conflict between various files. EL8 can still use SysV initscripts, if necessary, but it is not very difficult to write a systemd service, either. Kaj From: owner-scientific-linux-us...@listserv.fnal.gov On Behalf Of Nick Matchett Sent: Tuesday, June 29, 2021 09:43 To: scientific-linux-us...@listserv.fnal.gov Cc: Edmund Manabat Subject: Scientific Linux Advice I hope that someone could help me identify an individual or business that would be able to help me with the following problem. My business has some software that we acquired the responsibility to maintain and support, and currently sits on Scientific Linux version 6.3. Unfortunately, we are at a stage where our customers are asking to bring the software onto a more current version of a Linux platform. We would like to migrate to Red Hat or CentOS version 7.9 (or perhaps version 8) We have been working on a migration from Scientific Linux 6.3 to Redhat 7.9. Unfortunately, we have limited Linux OS skills in our business, and we have approached this with a fresh RH 7.9 install and then applying the RPM of our software. There is a big mismatch between Scientific Linux 6.3 to Redhat 7.9 in terms of libraries, file structure and type of libraries between the software and we have not been able to reconcile those. I would appreciate any suggestion or advice on the best upgrade path to achieve this update and would be happy to take recommendations on individuals or companies who might be interested in a professional service engagement to help solve the problem. Thanks in advance
