[HN Gopher] Rocky Linux releases its first release candidate
___________________________________________________________________
Rocky Linux releases its first release candidate
Author : sparcpile
Score : 136 points
Date : 2021-05-27 15:07 UTC (7 hours ago)
(HTM) web link (rockylinux.org)
(TXT) w3m dump (rockylinux.org)
| portmanteaufu wrote:
| The home page[1] bends over backwards not to use the name "Red
| Hat", which renders the FAQ weirdly obtuse.
|
| CentOS, which used to be downstream of Red Hat, has changed its
| strategy. Rocky Linux is looking to replace CentOS.
|
| [1] https://rockylinux.org/
| fipar wrote:
| That's to avoid trademark infringement. It used to be the same
| case with CentOS early on. Check out the "CentOS Overview"
| section in this version, with references to "a prominent North
| American Enterprise Linux vendor":
| https://web.archive.org/web/20050322010830/https://www.cento...
| user3939382 wrote:
| IMHO the proper purpose of trademarks should be to prevent
| consumer confusion. From that perspective, it's absurd to
| have to dance around mentioning a trademark in a context
| where you're explicitly stating that your product is
| different from it.
| 0xcde4c3db wrote:
| Tell that to Red Hat's lawyers [1]
|
| [1] https://web.archive.org/web/20071114044958/http://www.c
| entos...
| protomyth wrote:
| I rather doubt IBM's lawyers are more friendly about
| trademark use.
| selectodude wrote:
| Better safe than to wake up the Nazgul.
| phkahler wrote:
| >> From that perspective, it's absurd to have to dance
| around mentioning a trademark in a context where you're
| explicitly stating that your product is different from it.
|
| I don't think being a downstream release of RedHat very
| different from it. In fact, that's kind of the point.
| [deleted]
| sneak wrote:
| "Changed its strategy" is such a weird euphemism. Why does the
| founder of a project feel obligated to repeat the ass-covering
| euphemism of the corporation that fucked up his last project?
| tux1968 wrote:
| Suspect he's just being prudent. No reason to have any
| interaction at all with the IBM legal team.
| jb1991 wrote:
| let's hope the release isn't rocky
| jorl17 wrote:
| One of our clients pushed us toward AlmaLinux instead of CentOS
| 7. At the time, we vaguely suggested Rocky Linux, but noted we
| were kind of still waiting for the future (hence our suggestion
| of going with CentOS 7 and migrating later to the "true
| successor" of CentOS).
|
| What is the HN community's perception of this? Is AlmaLinux a
| good choice? Do you believe Rocky Linux will succeed?
| mrweasel wrote:
| I'd say "neither". CentOS would have fail had Redhat not taken
| over. My guess is that supporting all the companies who do not
| want to pay Redhat, for free, is going to push developers way
| pretty quickly.
|
| Even if I'm wrong I'd still want to see at least two or three
| solid release before using either in production.
|
| Just use Redhat or switch to Ubuntu. Then you can re-evaluate
| in five tears time.
| bayindirh wrote:
| > CentOS would have fail had Redhat not taken over...
|
| CentOS had a great backing from supercomputing centers at
| least (I work for one of them). We'd have supported it with
| no problems whatsoever if they needed any help.
|
| They're in a pretty good shape even before acquisition. Even
| CERN has decided to migrate (which is a big deal), as
| mentioned elsewhere.
| kbenson wrote:
| > I'd say "neither". CentOS would have fail had Redhat not
| taken over.
|
| While it's _possible_ that CentOS would have failed (I 'm not
| sure slow initial releases actually indicate that), it also
| wasn't the only popular clone of RHEL in popular use.
| Scientific Linux (developed by FermiLab) was also popular and
| in fairly wide use. I doubt Red Hat would have made the
| change to CentOS that spurred all this if Scientific Linux
| hadn't decided not to continue and just use CentOS instead in
| 2019, because instead of a "crap, we have to start a new
| distro to provide what CentOS did" movement there would have
| been a much quicker and easier mass exodus to Scientific
| Linux.
| mrweasel wrote:
| You might be right, there was not stopping Redhat from
| effectively killing CentOS anymore.
|
| I still don't want to build anything new on an distro that
| have still to prove they can maintain the project for two
| or three release.
| CaliforniaKarl wrote:
| The Scientific Linux team decided to not make a Scientific
| Linux 8, and instead switch over to CentOS 8[0]. Note this
| was announced prior to the announcement about CentOS 8
| going away.
|
| CERN et al are still deciding what to do[1].
|
| [0]:
| https://listserv.fnal.gov/scripts/wa.exe?A2=SCIENTIFIC-
| LINUX...
|
| [1]: https://linux.web.cern.ch/#update-on-centos-linux-
| strategy
| westurner wrote:
| Would Rocky Linux be an option for CERN?
|
| I'm assuming the Centos 8 install instructions for e.g.
| GitLab also work with Rocky Linux? Conda/Micromamba
| definitely should.
| Nux wrote:
| Ubuntu LTS popularity suggests 5 year timeframe is long enough.
| If people are happy with that, then why not be happy with
| Centos Stream which is also supported 5 years?
|
| In all likelihood it'll be as solid as it's ever been.
| derekp7 wrote:
| The problem isn't the 5 years. It is the fact that Stream
| will have packages more towards the leading edge and
| potentially have more bugs. Then, when a bug is found in a
| package, RHEL gets the patch first, but then the patch needs
| to be re-worked to get it to apply against the newer version
| of the package that is in Stream. I don't know if the wall
| will still exist between CentOS and RHEL teams, where CentOS
| won't know of a(n) (embargoed) patch that RHEL has prior to
| public release. If they don't, then potentially something
| like Rocky will get the patch before Stream (due to the above
| mentioned re-working of the patch).
|
| Now if that firewall between the two groups gets some holes
| poked in it, where Stream can start working with the patch
| sets prior to release on RHEL, then it may not be such an
| issue.
| bayindirh wrote:
| > (if) Stream can start working with the patch sets prior
| to release on RHEL, then it may not be such an issue...
|
| From the chats I had with people who work either on RH or
| Fedora, CentOS Stream is actually RHEL's next point
| release's candidate version.
|
| In practicality, CentOS will move from RHEL-1 to RHEL+1
| with security patches included.
|
| We're one of the parties get pretty burned by this, but
| things look better than the start. We'll see.
| [deleted]
| 123123as1asd12 wrote:
| Nothing wrong with debian minimal. things a beast.
| Tsiklon wrote:
| Congratulations to the Rocky Linux team. I hope this is a sign of
| things to come
| Tepix wrote:
| In terms of speed it looks as if Oracle was the first to get 8.4
| of their RHEL clone out of the door, Alma Linux came second and
| RockyLinux is still at 8.3 I'm optimistic that they will get
| faster!
| throwawaaarrgh wrote:
| If I was starting "another CentOS" I would ensure that companies
| above a certain amount of revenue had to pay (either in licensing
| fees or in engineer time). Non-corporate and FOSS uses should
| remain free. The reason I suggest this is differences in user
| engagement.
|
| It's hard to get community support for projects that are
| business-focused. A project that is very general-purpose can get
| quite a few volunteers or donations. But if businesses are the
| primary users, the project often gets little to no support from
| those businesses, and very infrequently any contributed code or
| support. Getting my own company to donate to an OSS project that
| they heavily depend on is like pulling teeth. Which is
| ridiculous, because without that project they'd be paying a lot
| more for proprietary software!
| throwslkjlkja wrote:
| I mean that kind of defeats the point of the effort and FOSS in
| general.
|
| If you need to pay you just buy RedHat.
|
| CentOS reached ubiquity by being free. Many large corporations
| already have competent system admins managing large
| installations/clusters that RedHat offered nothing worth
| purchasing over CentOS.
|
| Another approach to support is probably better rather than
| becoming RedHat 0.1
| throwawaaarrgh wrote:
| I used to support a corporate CentOS fork for years. I think
| I built something like 10,000 custom packages over several
| releases. If I found a bug and wanted to submit a code fix, I
| couldn't just submit it, because corporate wouldn't allow us
| to "release intellectual property". If I wanted to donate
| money I had to do it from my own wallet, because the company
| wouldn't approve the expense.
|
| But if our only legal option (given our size) was to pay one
| flat fee for infinite installs, or one flat fee per N nodes
| or something, the company would have approved that, because
| we needed to use something RHEL-like. If it's totally free,
| the company won't help at all. I think a few large companies
| could probably provide most of the funding necessary for the
| project, and still be ridiculously cheaper than RHEL.
|
| I'd only do this for _business-focused_ projects, because of
| the tendency for those "users" not to contribute anything
| back. FOSS only thrives when people contribute. Otherwise
| you're a one-man software welfare program.
| yjftsjthsd-h wrote:
| > If I was starting "another CentOS" I would ensure that
| companies above a certain amount of revenue had to pay (either
| in licensing fees or in engineer time). Non-corporate and FOSS
| uses should remain free. The reason I suggest this is
| differences in user engagement.
|
| That's just RHEL; https://www.redhat.com/en/blog/extending-no-
| cost-red-hat-ent... for FOSS and
| https://developers.redhat.com/blog/2021/02/10/how-to-activat...
| for non-corporate users.
| GNOMES wrote:
| I understand the desire to stick with the 10yrs of updates model,
| but it seems outdated with how fast things evolve. I am still
| waiting for Redhat to bring some details on how Stream will work
| long term.
|
| We need to know what packages will be unstable. People seem to be
| held up that Redhat releases will be taken from Stream, making it
| a "beta" of things to come instead of a free RH. I personally see
| this no different than Fedora > CentOS release cycle. I welcome
| newer features hitting our enterprise boxes sooner than later.
|
| I have read that it's also not a true rolling release, and
| instead will have minor stop gap channel releases along the way.
| Unless there is another big shake up like init vs systemD, it
| will be excellent to have an enterprise grade rolling release
| option for long lived (non-cattle) servers. Updating our fleet
| from 5 to 6, 6 to 7 was painful...
|
| Currently moved most of my Dev servers to Stream, and I am
| excluding a few packages from rolling with DNF-Automatic. Will
| this stay supported?
| dralley wrote:
| CentOS Stream is rolling between minor releases, not between
| major releases. So e.g. a CentOS Stream 8 system won't roll
| over to CentOS Stream 9.
|
| I do believe they're working on making major version upgrades
| easier, but they would still not be automatic.
|
| None of the packages should be "unstable" barring any major
| bugs, (or maybe proprietary kernel modules that expect a very
| specific kernel version).
| cpach wrote:
| IMHO: For those who want more frequent upgrades, then I would
| say a container-based solution is a good fit. Then the
| container don't need to care if the underlying host has very
| old packages.
| forvelin wrote:
| We jumped off the CentOS boat after their statement and switched
| to OpenSuSe, no regrets so far, smooth sailing.
| xaduha wrote:
| ISOs are a bare minimum of course, but what about official
| container images? Personally I'd like to see how it works with
| existing package repos that are out there.
|
| EDIT: tried unofficial image and it seems you can use stuff from
| mirror.centos.org if you mimic Centos by modifying
| /etc/dnf/vars/contentdir and /etc/dnf/vars/cloudsigdist. Use
| --nogpgcheck if necessary.
| rockii2 wrote:
| This was released back at the end of April.
|
| https://rockylinux.org/news/rocky-linux-8-3-rc1-release/
| germ wrote:
| Good to see this project moving along, and if the team is
| monitoring this, give Brian a smack from me :P
| INTPenis wrote:
| I'm responsible for fairly critical infrastructure and I've been
| putting all my bets on RHEL/CentOS these last 7 years.
|
| So my plan is to just sit back and watch how all this develops
| until 2023. Use RHEL when possible, Fedora or CentOS 7. Worst
| case maybe CentOS Stream.
|
| But there is no rush. Just sit back and let time decide which of
| these new contenders looks the best after 2 years.
| stinkytaco wrote:
| Is RHEL compatibility a must? At this point it feels like the
| only community solution that has a long term track record is
| Debian.
| indigodaddy wrote:
| There is a whole smorgasbord of entrenched application
| servers/software that are targeted mainly at the RHEL
| ecosystem. These would have a very difficult time
| transitioning to non-RHEL.
| protomyth wrote:
| I have government contractors specify versions of Red Hat and
| they will not support other distributions. Of course, these
| vendors also specify versions of Windows Server that
| Microsoft recommends you no longer run.
| indigodaddy wrote:
| How do updates/security updates look on C7/C8 until then?
| Assuming you don't have any C8? Otherwise, stable updates are
| going to be problematic converting those to Stream, no? Also, I
| wouldn't myself count on Red Hat not welching on that C7 2024
| EOL date. I can't see them not pushing that up honestly.
|
| As far as whether CentOS was a success or not, of course it was
| a massive success. The circumstances of its unnaturally
| accelerated death don't change its wild
| popularity/usage/prevalence.
| yjftsjthsd-h wrote:
| > How do updates/security updates look on C7/C8 until then?
| Assuming you don't have any C8? Otherwise, stable updates are
| going to be problematic converting those to Stream, no? Also,
| I wouldn't myself count on Red Hat not welching on that C7
| 2024 EOL date. I can't see them not pushing that up honestly.
|
| Given that C8 was supposed to be supported into 2029[0] and
| then they cut it to 2021, that does seem plausible enough...
|
| [0] https://web.archive.org/web/20201101131417/https://wiki.c
| ent...
| FooBarWidget wrote:
| I don't get it. CentOS "failed" because there were not enough
| community resources to sustain it. Rocky Linux is founded by the
| CentOS founder. Why will Rocky Linux succeed where CentOS
| "failed"? How would Rocky Linux get resources to sustain it?
| orev wrote:
| The "failure" of the CentOS community is really related to the
| nature of the distro. As they aimed to be a fully compatible
| clone of RHEL, there's not much you can allow in terms of
| community contribution to packages, etc,. Those kind of
| restrictions don't lend themselves well to forming a vibrant
| group of contributors.
|
| The main area that was lacking are the other resources, like
| wiki, forums, and other docs. That's one area where criticism
| is warranted. I always wince when I have to go to the Arch wiki
| to figure out how to set something up in CentOS.
| GNOMES wrote:
| Only issue I have with using the Arch wiki (really the best
| Nix only wiki) to troubleshoot CentOS is due old versions in
| CentOS. CentOS seemed to mainly backport security fixes to
| older versions, so often flags or features of commands don't
| apply.
| yjftsjthsd-h wrote:
| > CentOS seemed to mainly backport security fixes to older
| versions, so often flags or features of commands don't
| apply.
|
| In fairness, that's kind of the _point_ of CentOS et al.
| hollerith wrote:
| Your use of "Nix" to mean Unix (if that is what you are
| doing) is confusing!
|
| (Nix is a package manager for Linux.)
| kodah wrote:
| Nix is also code for Linux and Unix when speaking
| broadly. It's a nebulous term.
| hollerith wrote:
| If he/she had written, "*nix", then I would have caught
| his/her meaning right away.
| kodah wrote:
| Fair enough
| Tijdreiziger wrote:
| > The main area that was lacking are the other resources,
| like wiki, forums, and other docs. That's one area where
| criticism is warranted. I always wince when I have to go to
| the Arch wiki to figure out how to set something up in
| CentOS.
|
| Same story as an Ubuntu user. Actually, doesn't everyone go
| to the Arch wiki? :D
| sparc24 wrote:
| You can just go to the RHEL docs.
| https://access.redhat.com/documentation/en-
| us/red_hat_enterp...
| nickysielicki wrote:
| There are plenty of RHEL docs that will show up in a search
| but are inaccessible because it's hidden behind a login.
| sparc24 wrote:
| That's not documentation that's support knowledgebase.
| You can just pay for a single subscription at 349$/yr and
| get access to it. It's worth it if you are running a
| large fleet.
| mjw1007 wrote:
| Seven years is quite a long time in this area. It's possible
| that running exactly the CentOS-in-2014 model would work now
| even if it didn't then.
|
| It's also possible that in 2014 CentOS would have found other
| ways to remain viable if Red Hat hadn't stepped in.
| beermonster wrote:
| > I don't get it. CentOS "failed" because there were not enough
| community resources to sustain it
|
| CentOS was a success story and that's not why it "failed".
|
| I wish Rocky Linux the same success!
| mrweasel wrote:
| How was it a success story? Sure many used it, but the
| project wasn't successful in terms of long term survival.
|
| I think CentOS had failed had Redhat not maintained it.
|
| Hopefully Rocky Linux will have better luck and more
| community involvement. It is likely, given the number of
| companies that have come to depend on CentOS, but I would not
| use Rocky Linux in production for critical system in the next
| two to five years.
| spinax wrote:
| > How was it a success story? Sure many used it, but the
| project wasn't successful in terms of long term survival.
|
| CentOS 3, 4, 5, 6 and now 7 have all fulfilled their
| mission to be bit-clones of RHEL since 2004. As a CentOS
| user of every single one of them, they were a success and
| satisfied the needs of the community for 17 years. The
| first version of Ubuntu was released 6 months after CentOS
| 3.
| macksd wrote:
| Rocky Linux seems to have made a bigger deal of getting and
| advertising sponsors than I remember from CentOS. CentOS
| had a subtle link to donate, but that was it. Right off the
| bat, Rocky Linux had a nicer looking landing page and BIG
| sponsor logos. And I would absolutely have thrown $100 at
| CentOS to keep existing, it just never occurred to me that
| it was needed or would make a difference.
|
| It's not the I just want something for nothing. I'll pay
| for good tools, but my time is money too and if I feel
| myself going down a high-touch sales process with stuff
| that feels like lock-in and DRM, I'm gonna check out and go
| for an alternative pretty quick. I used CentOS all the time
| because I was in the position of trying to support people
| running my software on Red Hat. And I never had to worry
| about talking to a sales person, or making sure my keys for
| the repository were everywhere they needed to be. I would
| have still used it, even if I had to enter my personal
| credit card to get an official ISO. Even once my company
| had a proper agreement and partnership with Red Hat, it was
| still a pain for me to get a system up and running without
| talking to IT, etc.
|
| Red Hat seems to have lighter-weight licensing for such use
| cases now, so we'll see. But at this point I've already
| switched over to Ubuntu and I doubt Red Hat or Red Hat
| clones will ever fully recover to their former glory.
| beermonster wrote:
| CentOS was huge in the cloud. Run by admins that want to
| config and forget. That 10 years support is nice. Boring
| and bullet proof is a feature (look at Debian). RedHat were
| a large contributor and also provided funding. When they
| pulled the plug the project didn't survive and admins
| around the world cried.
|
| Hopefully Rocky wont suffer the same fate being supported
| by the community from the outset.
|
| But I might wait a bit before trying it :)
| mrweasel wrote:
| > CentOS was huge in the cloud
|
| There's no question about that, but I just don't equate a
| large install base with being successful. Had CentOS been
| successful, there would have been no Redhat involvement.
| CentOS failed the day Redhat took control of the project.
| After that it was just an version of RHEL without the
| subscription.
|
| Companies wanted RHEL, but not pay for the development
| and maintenance. If this changes, and more companies are
| will to either donate to pay developers, or hire Rocky
| Linux develops, then maybe it will be successful. If it's
| just a few people slaving away in their free time, trying
| to maintain a parallel RHEL build, then I kinda doubt
| it's longevity.
| orev wrote:
| CentOS is used on a huge number of severs. That success
| became a threat the RedHat/IBM, as they were not getting
| customers signing up for their paid offerings. Hence,
| CentOS was killed off.
| dralley wrote:
| MoviePass had a large number of subscribers. It's very
| easy to be successful if you're giving something away for
| free and ignore sustainability.
| indymike wrote:
| CentOS failed because it's sponsor willed it to do so. When
| it went from being focused on long term stability to a
| rolling release, it was no longer in alignment with the
| reason it's users selected it. Since Rocky is being
| developed by some of the same people that did CentOS, I
| suspect that things will be just fine... after all, they
| benefit from being a downstream distribution.
| marmaduke wrote:
| Didn't it fail because RH chose so? C8 certainly works fine, if
| boring.
| bombcar wrote:
| Before RH took over CentOS it was pretty much dying on the
| vine, releases were getting VERY slow, etc.
|
| It remains to be seen if the cloud companies will find a
| CentOS-like OS important enough to fund the development of
| things like Rocky.
| kbenson wrote:
| > Before RH took over CentOS it was pretty much dying on
| the vine, releases were getting VERY slow, etc.
|
| A slow initial release and dying on the vine are two
| completely separate things. There's _significant_ overlap
| in time between major distro releases, and while many users
| of CentOS were _excited_ about getting newer versions, it
| was usually not imperative and all involved would likely
| agree that making sure existing releases continue to have
| timely updates for security and other things was more
| important.
|
| > It remains to be seen if the cloud companies will find a
| CentOS-like OS important enough to fund the development of
| things like Rocky.
|
| Whether cloud companies or not, there are a few ways
| forward now that weren't really considered previously.
| CentOS always had a somewhat tacit agreement with Red Hat
| to not overtly compete with Red Hat's revenue stream. i.e.
| Don't sell support, if advanced help is needed refer them
| to Red Hat for a license and support.
|
| I would say the relationships now are a tad more
| adversarial. Asking for money in more direct manners may
| now be more feasible. Even without that, I do think the
| cloud providers can easily fund one or more of these
| projects enough. The amount of money even one could spend
| to ensure the staffing of one of these projects is less
| than a rounding error in their operating budget, and given
| how often I suspect CentOS was chosen as the deployed OS in
| a way that makes their total cost numbers reflected back to
| a CTO look less, a very good investment for them.
| mhitza wrote:
| > Before RH took over CentOS it was pretty much dying on
| the vine, releases were getting VERY slow, etc.
|
| Remind me again, how long did it take RedHat to publish
| CentOS 8 images out to cloud providers or virtualbox? I
| think it was the very least 6 months behind the RedHat 8
| release.
|
| Only started using CentOS at 7, so not sure how much they
| used to lag behind releases beforehand.
|
| But I've also had a dozen quality issues with RedHat
| software and services since they've been assimilated by
| IBM; so there's room for plenty of surprises.
| Tsiklon wrote:
| Amazon Linux 2 is built on CentOS 7.
|
| AWS are a sponsor of Rocky Linux
| mrweasel wrote:
| I guess they're kinda forced to. Switch to Ubuntu or
| Debian for Amazon Linux 3 would be weird, but perhaps a
| smart choice.
| jacobr1 wrote:
| The could just do their own RHEL fork, which would make
| Amazon Linux a peer to rocky instead of a downstream.
| mrweasel wrote:
| They could have done that from the start, like Oracle,
| but they choose not to for a reason, most likely to save
| money.
|
| So now they either have to support Rocky Linux, and hope
| others do to, or pay the full cost of maintaining a RHEL
| compatible distro.
| sparc24 wrote:
| Looking at all your comments in this thread and you
| really don't know what you are talking about. Just
| spreading FUD.
|
| RHEL7 is the upstream for AL2 and there is a LOT of heavy
| lifting done by AWS. Newer kernel, newer toolchain, newer
| glibc. They do live patching. They actually test all
| sorts of workloads before even a minor errata update.
| They took OpenSSL 1.0.2 through FIPS validation with
| NIST.
|
| Just stop talking.
| yjftsjthsd-h wrote:
| They could do their own Fedora downstream, or jump to
| openSUSE for a different stable RPM distro.
| chessmango wrote:
| Don't think this is the case. It's downstream of RHEL but
| with a bunch of liberties, so CentOS/Rocky doesn't change
| much there
| marmaduke wrote:
| We run an HPC cluster on CentOS 8 and looking at moving to Rocky
| but I wonder if we shouldn't just jump to Ubuntu or OpenSUSE. The
| main thing keeping us is that kickstart works pretty well over
| PXE with dnsmasq and I never found good docs for the equivalents
| elsewhere.
| bombcar wrote:
| If you're tied to software that is used on RHEL or release in
| sync with RHEL I'd say stick with CentOS-like distributions -
| but if you're not I'd say that moving to Ubuntu LTS doesn't
| seem that bad of an option.
| Dah00n wrote:
| If you need LTS would Debian not be a better choice for
| servers?
| dralley wrote:
| Debian and Ubuntu have the same LTS policies, but Ubuntu
| has the option of paid "extended LTS".
|
| I won't comment on the experience of using Ubuntu vs.
| Debian on servers because I don't have any
| dnautics wrote:
| PXE for Ubuntu is a nightmare compared to centos, but it is
| doable. It took me about four months (on and off with other
| responsibilities) to figure it out... It's been a while but
| iirc the biggest trick is to use the "legacy" installer iso.
| secabeen wrote:
| Yeah, I have a PXE install system for Ubuntu too, built on
| the text mode installer. They are really pushing people to
| use MAAS, for a while the legacy installer for 20.04 wasn't
| released, and I thought I'd have to change, but it's out now.
| We'll see if they still have it for 22.04. :fingers crossed:
| dnautics wrote:
| I _really_ wantedan excuse to PXE alpine Linux, but I
| couldn 't figure out how to bootstrap a post-pxe script.
| Which I'm sure is super easy and I just missed a really
| obvious strategy about Linux sysadminning, the docs anyway
| do not provide easy to understand guidance on that,
| unfortunately, and I have no idea where to go to get
| community support for quick one-off questions.
| throwawaaarrgh wrote:
| I expect PXE booting hasn't changed much in 15 years, so
| you can go find The Linux Documentation Project's HOWTOs
| on PXE and network booting and it should be about the
| same now. After that you just need to learn how to
| extract and create an initrd, and how the init system
| works to trace the execution of your network boot system.
|
| This is also where shell script-based init systems rock.
| It's pretty easy to figure out how things get executed in
| an unusual environment like a network-installer because
| you can just open up the files used by your installer and
| follow them. To figure out how systemd might work in a
| PXE environment you'll need to find the version of
| systemd and then go download the source code and start
| reading... Might want to keep a notebook as you go.
| dnautics wrote:
| Hell, I wrote my own PXE server (from scratch, starting
| with UDP primitives for DHCP and TFTP) that could PXE
| boot and track/log the status of several concurrently PXE
| booting servers in a rack. That sounds crazy, but its'
| surprisingly easy in Elixir. It was arguably easier (and
| more reproducible) to do this than to figure out how to
| configure, say, isc-dhcpd to give out specific ip
| addresses based on a mac-ip lookup table you put on s3,
| log the progress of each client, and then ninja out isc-
| dhcpcd to not exist anymore once you've provisioned the
| rack (and then figure out what to do if you had an
| error)... you can imagine the nightmarish statefulness
| problems with system config files all over the place.
|
| > learn how to extract and create an initrd
|
| that was the hard part. CentOS and Ubuntu (poorly
| documented) give you a specific bootstrapping pathway
| that would kick in the initial installer, and at the
| other end you would have the system as you wanted it. The
| PXE instructions for alpine drops you into a shell. I
| couldn't figure out how to create and launch a "script"
| that would kick off the software installation beyond the
| basics. Like I said, it's probably easy, just not my
| wheelhouse.
| gertrunde wrote:
| Ah, nice. The installer mess was one of the reasons I
| steered clear of 20.04. (Along with the netplan vs
| cloudinit dumpster fire, and Canonical's rabid pro-snap
| stance).
|
| Might be worth taking another look if the old installer is
| back again.
| secabeen wrote:
| It is, here: http://archive.ubuntu.com/ubuntu/dists/focal
| /main/installer-...
| phkahler wrote:
| >> We run an HPC cluster on CentOS 8 and looking at moving to
| Rocky but I wonder if we shouldn't just jump to Ubuntu or
| OpenSUSE.
|
| Sounds like an installation that might be able to afford
| RedHat. In fact, had that been the case already there would be
| no need to change anything now.
| HeadlessChild wrote:
| Check out FAI [0] (Fully Automatic Installation) for something
| similar to kickstart but for Debian/Ubuntu. When you get into
| it, it is quite nice to configure.
|
| [0] https://fai-project.org/
| cpach wrote:
| I would stay away from Ubuntu. IMHO, Canonical has too much of
| a "throw everything at the wall to see if it sticks" approach.
| znpy wrote:
| i want to second this.
|
| ubuntu has this horrible habit of re-inventing stuff that
| works well and then push it to users and customer, only to
| deprecate that in the next release.
| settrans wrote:
| This looks awesome -- congrats to the team on the landmark
| milestone. I've been eagerly anticipating the release since their
| initial announcement.
|
| I am left to wonder how seamless this migration will be in
| practice. I'm a heavy user of, for example, zfs-kmod, and would
| be thrilled to learn that I won't suddenly be on the hook for
| coordinating dkms build shenanigans across my ZoL machines.
|
| Bonus points if they offer a direct upgrade path from CentOS --
| although I'm not holding my breath on this one.
| mijoharas wrote:
| For anyone else that was missing context, there is an about
| section on the wiki[0]
|
| > Rocky Linux is a community enterprise Operating System designed
| to be 100% bug-for-bug compatible with Enterprise Linux, now that
| CentOS has shifted direction.
|
| [0] https://wiki.rockylinux.org/
| Jellyspice wrote:
| What is enterprise operating system anyway?
| mrweasel wrote:
| In my world: Something that comes with and 24/7 support
| contract.
| Tsiklon wrote:
| For the purposes of avoiding trademark infringement all RHEL
| clones go out of their way to avoid mentioning Red Hat,
| thusly Red Hat Enterprise Linux and all derived from its
| sources tend to get lumped together as "Enterprise Linux"
| mimsee wrote:
| Sure, but what makes Rocky "enterprise"? Is it just
| marketing or can everything be "enterprise"? Is Windows not
| "enterprise"?
| kingaillas wrote:
| To me, being "enterprise" means shipping/supporting
| running enterprise functions on the OS. So things like
| network information services, databases, perhaps giving
| options of filesystems that can handle extremely large
| sizes, cluster support, added support from the vendor,
| etc.
|
| Stuff that a typical desktop user probably won't run or
| use. Maybe they can if they really wanted to, but not the
| common use case.
|
| >Is Windows not "enterprise"?
|
| Funny you ask when Microsoft literally sells a version of
| Windows called "Windows Enterprise".
| https://www.microsoft.com/en-
| us/windowsforbusiness/compare
|
| Find the differences between Windows 10 Home and Windows
| 10 Enterprise and that may help you understand what makes
| Rocky Linux also enterprise.
| Tsiklon wrote:
| Rocky aim for "bug for bug" compatibility with RHEL.
|
| Red Hat target RHEL to a conservative, enterprise
| audience who look for a long lived well supported
| operating system, Rocky (and CentOS before it) court the
| same audience.
|
| The primary difference being that RHEL is a premium
| product differentiated by the Red Hat support, training
| and documentation offering.
|
| Support in so far as Red Hat will work with you to
| troubleshoot your OS issues, and issue custom patches to
| the packages they supply that you're encountering issues
| with etc etc.
|
| Training in that Red Hat offer many training courses and
| certifications in the usage and deployment of their many
| software packages and collections (System Administration,
| Troubleshooting & Diagnosis, High Availability Cluster
| administration etc etc)
|
| If you look at Microsoft's offering for Windows server
| you'll see many parallels in the offerings that Red Hat
| present.
| Karunamon wrote:
| Being based on Red Hat by way of CentOS, who's full name
| initial-ized as RHEL is "Red Hat Enterprise Linux"
| rsj_hn wrote:
| * long term support (e.g. don't EOL something just because
| it's 5 years old, etc)
|
| * immediate support (have someone you can call 24/7 if your
| system blows up)
|
| * responsive support (have engineers on staff to close
| support tickets fairly quickly. This applies especially to
| bugfixes)
|
| * good QA process so that you do not use your enterprise
| customers as free QA but pay people to test the product
| thoroughly before releasing it. This ties into the notion of
| long term support as something that stays in the QA matrix
| and receives bugfixes/updates.
|
| * good documentation, in multiple languages
|
| * A supporting ecosystem of certifications/training
| materials, so a business can hire people qualified to use the
| product
|
| All of the above boils down to having people on staff doing
| all the boring, costly things that reduce the pain of
| companies using the software. Those things are not fun, so
| they tend not to happen consistently by open source
| volunteers, so they have to be paid for, hence "enterprise",
| as end users don't value these enough to pay for them over
| free but big businesses do.
| dralley wrote:
| * Long-term stability and ABI guarantees. A software /
| hardware stack for a platform that isn't going to change or
| break underneath your feet while still receiving bugfixes and
| security updates for multiple years.
|
| * A software stack that large third-party vendors of software
| and hardware are willing to certify their products against,
| e.g. SAP, databases, etc.
|
| * Support contracts
| ForHackernews wrote:
| RedHat
| djhaskin987 wrote:
| Frankly, since my company is pushing hard for a move away from
| the data center, we're really not talking about moving from
| CentOS 7 to e.g. Rocky any more anyway; we're talking about
| moving from CentOS 7 to Amazon Linux 2.
___________________________________________________________________
(page generated 2021-05-27 23:02 UTC)