Announcement

Collapse
No announcement yet.

Red Hat Enterprise Linux 9.0 Beta Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jabberwocky
    replied
    Originally posted by mroche View Post
    Jabberwocky I do. Could you share an example link to something you're trying to access? Some of the trial stuff is a bit unclear, the program (to my knowledge) is supposed to supply 10 cores of OpenShift, but still makes you use a 60 day trial and the subscription to attach never showed up in my cloud console. I brought it up to some folks internally, haven't followed up though.

    Cheers,
    Mike
    Sorry for the Necro. You are welcome to PM me if you have any questions.

    I wasn't searching for Redhat content and found the page due to the high ranked search engine result. I tried logging in using my RedHat developer account but it still shows the "Subscriber exclusive content" wall.

    https://access.redhat.com/solutions/6194821

    Leave a comment:


  • mroche
    replied
    Jabberwocky I do. Could you share an example link to something you're trying to access? Some of the trial stuff is a bit unclear, the program (to my knowledge) is supposed to supply 10 cores of OpenShift, but still makes you use a 60 day trial and the subscription to attach never showed up in my cloud console. I brought it up to some folks internally, haven't followed up though.

    Cheers,
    Mike

    Leave a comment:


  • Jabberwocky
    replied
    Downloading RHEL 9 Beta does require a Red Hat account, which does include the no-cost Red Hat Developer program access
    Is anyone here using the RedHat Developer Program?

    I signed up but did not like the way that RedHat limits your account, for example you can't read support answers unless you get a paid subscription and you can't access specific packages without starting your trail period which lasts a few days. For me to effectively test RHEL I needed access to those. It was too limited so I ended up not using it at all. Perhaps there will be a reason for me to use it in the future...

    Leave a comment:


  • mroche
    replied
    Originally posted by Michael View Post

    Probably just a CloudFlare caching issue... Try again after some time.
    Gave it a few hours, looks good now! Sorry, did not mean for the previous post to come off accusatory (I know some of these platforms have built in features to reduce spam and help with moderation and wasn't sure if I was hitting such a limit).

    Cheers,
    Mike

    Leave a comment:


  • Michael
    replied
    Originally posted by mroche View Post
    It would seem that Phoronix has an edit limit/moderation/shadow system in place for older comments. I can see my edits just fine, but if I open them up in an private window they aren't there. Michael Any idea what that's about?

    Cheers,
    Mike
    Probably just a CloudFlare caching issue... Try again after some time.

    Leave a comment:


  • mroche
    replied
    It would seem that Phoronix has an edit limit/moderation/shadow system in place for older comments. I can see my edits just fine, but if I open them up in an private window they aren't there. Michael Any idea what that's about?

    Cheers,
    Mike

    Leave a comment:


  • BingoNightly
    replied
    Originally posted by mroche View Post
    kylew77 I should make an amendment to my statement earlier. From the docs:



    My understanding of this statement is that if you upgrade (through leapp) to RHEL 9, you won't need to make any modifications to your current workflow. However if you were to reprovision, I'm not sure it would bother reading those config files. I can try and dig up some extra information on this if desired.

    Cheers,
    Mike
    You can also change back to the old way relatively easily. On a new install a connection will be registered via /etc/NetworkManager/system-connections/<int>.nmconnection. You can just rip that out and recreate the old /etc/sysconfig/network-scripts/ifcfg-<int> files and reboot or restart networking and things should work as expected; at least they did for the Fedora Server 34 systems I've setup.

    Leave a comment:


  • mroche
    replied
    Thanks for hopping in there Chousuke and RahulSundaram. I corrected by information in my original post about network-scripts and configs (it's been a long week).

    kylew77 GraysonPeddie See the past page or so, TLDR ifcfg-<con> configs will continue to work with caveats noted, it's just the tooling from network-scripts you'll be losing.

    Cheers,
    Mike
    Last edited by mroche; 04 November 2021, 05:24 PM.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Chousuke View Post
    As far as I am concerned, nothing has changed except that instead of a bunch of scripts parsing the files and running commands, my configuration files are read by an actual daemon that is responsible for managing the system's network configuration; the fact that the centralized control also happens to enable fancy UIs is just a side-effect.
    Yes, this is exactly right. If you are using it in a server, there is no reason to be concerned about a gui (you could use cockpit web UI if you like), all of the functionality is in a daemon and exposed via a cli. Some background

    https://blogs.gnome.org/thaller/2021...nd-its-future/
    https://fedoraproject.org/wiki/Chang...ad_of_ifcfg_rh

    Leave a comment:


  • Chousuke
    replied
    Originally posted by pegasus View Post
    That's the whole point of it - NM brings all kinds of pain in this area and I hate it passionately.
    I need to check out .nmconnection files if they are sensible and figure out how to programatically create them and then see if any of the puppet modules already does this or if I have to handle it myself. When you have thousands of systems to manage, going for lowest common denominator is the way to go. Some fancy high level gui is useless ...
    NetworkManager's native configuration is just a bunch of ini files; they're not very troublesome if you want to manage them. However, since Red Hat chose to care about backwards compatibility, NM fully implements and supports the old configuration format and there's no reason or need to transition to the native INI files until you use some feature that only they can provide.

    Basically, it's doing backwards compatiblity the way it should be done: It provides support for 99% of what's out there in the old format, but doesn't bend over backwards and introduce crazy hacks to support accidentally working usage that relied on implementation details of the previous script mess.

    As far as I am concerned, nothing has changed except that instead of a bunch of scripts parsing the files and running commands, my configuration files are read by an actual daemon that is responsible for managing the system's network configuration; the fact that the centralized control also happens to enable fancy UIs is just a side-effect.

    Leave a comment:

Working...
X