When I use Google Meet through the Chrome browser, screen sharing doesn't work. The audio works and I can see the other person's screen but I couldn't share mine.

It was working well in the past. Anyone facing this?

Someone told me RHEL 9 ships with ssh's PasswordAuthentication disabled by default. I checked the default sshd_config for Almalinux 9 and it has everything commented out, so the defaults for ssh are used, which is to allow PasswordAuthentication.

It doesn't really matter as users would want to secure ssh and other services anyway, but I was wondering why it's different from RHEL 9. I would think AlmaLinux defaults to RHEL's defaults for the most part. Does this mean AlmaLinux is less opinionated (i.e. respecting upstream choices) even at the expense of more secure defaults like in RHEL 9?

Again, simply talking about defaults, which probably shouldn't be used. Just curious design choices and what can be expected.

I've installed Alma 9.3 on new hardware. Minimal Installation & CIS Level 2 Workstation

It appears that I have massive connectivity problems.

During dnf -y groupinstall workstation the download stalls and reports something like this.

(30/856): avahi-tools-0.8-20.el9.x86_64.rpm      67 kB/s |  38 kB     00:00
(31/856): baobab-40.0-3.el9.x86_64.rpm           65 kB/s | 379 kB     00:05
[MIRROR] adwaita-icon-theme-40.1.1-3.el9.noarch.rpm: Curl error (28): Timeout was reached for https://mirror.alpha-labs.net/almalinux/9.4/AppStream/x86_64/os/Packages/adwaita-icon-theme-40.1.1-3.el9.noarch.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
[MIRROR] almalinux-backgrounds-90.5.1-1.1.el9.noarch.rpm: Curl error (28): Timeout was reached for https://mirror.alpha-labs.net/almalinux/9.4/AppStream/x86_64/os/Packages/almalinux-backgrounds-90.5.1-1.1.el9.noarch.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
[MIRROR] bind-libs-9.16.23-18.el9_4.6.x86_64.rpm: Curl error (28): Timeout was reached for https://mirror.alpha-labs.net/almalinux/9.4/AppStream/x86_64/os/Packages/bind-libs-9.16.23-18.el9_4.6.x86_64.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
(32/856): bind-libs-9.16.23-18.el9_4.6.x86_64.r  21 kB/s | 1.2 MB     01:00
(33/856): bind-license-9.16.23-18.el9_4.6.noarc 678 kB/s |  12 kB     00:00
(34/856): bind-utils-9.16.23-18.el9_4.6.x86_64.  55 kB/s | 201 kB     00:03
(35/856): blktrace-1.2.0-19.el9.x86_64.rpm      500 kB/s | 143 kB     00:00
(36/856): bluez-obexd-5.64-2.el9.x86_64.rpm     541 kB/s | 227 kB     00:00
(37/856): brlapi-0.8.2-4.el9.x86_64.rpm         707 kB/s | 173 kB     00:00
[MIRROR] almalinux-backgrounds-90.5.1-1.1.el9.noarch.rpm: Curl error (28): Timeout was reached for https://mirror.alpha-labs.net/almalinux/9.4/AppStream/x86_64/os/Packages/almalinux-backgrounds-90.5.1-1.1.el9.noarch.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
[MIRROR] adwaita-icon-theme-40.1.1-3.el9.noarch.rpm: Curl error (28): Timeout was reached for http://ftp.halifax.rwth-aachen.de/almalinux/9.4/AppStream/x86_64/os/Packages/adwaita-icon-theme-40.1.1-3.el9.noarch.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
[MIRROR] brltty-6.3-4.el9.x86_64.rpm: Curl error (28): Timeout was reached for http://ftp.fau.de/almalinux/9.4/AppStream/x86_64/os/Packages/brltty-6.3-4.el9.x86_64.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
[MIRROR] adwaita-icon-theme-40.1.1-3.el9.noarch.rpm: Curl error (28): Timeout was reached for https://mirror.alpha-labs.net/almalinux/9.4/AppStream/x86_64/os/Packages/adwaita-icon-theme-40.1.1-3.el9.noarch.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
(38/856): brltty-6.3-4.el9.x86_64.rpm            21 kB/s | 1.5 MB     01:12
(39/856): cairo-1.17.4-7.el9.x86_64.rpm         180 kB/s | 659 kB     00:03
(40/856): cairo-gobject-1.17.4-7.el9.x86_64.rpm 620 kB/s |  18 kB     00:00
(41/856): cairomm-1.14.2-10.el9.x86_64.rpm      906 kB/s |  62 kB     00:00
[MIRROR] almalinux-backgrounds-90.5.1-1.1.el9.noarch.rpm: Curl error (28): Timeout was reached for http://ftp.halifax.rwth-aachen.de/almalinux/9.4/AppStream/x86_64/os/Packages/almalinux-backgrounds-90.5.1-1.1.el9.noarch.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
(42/856): checkpolicy-3.6-1.el9.x86_64.rpm       12 kB/s | 351 kB     00:29
(43/856): cheese-3.38.0-6.el9.x86_64.rpm        135 kB/s |  94 kB     00:00
[MIRROR] cheese-libs-3.38.0-6.el9.x86_64.rpm: Curl error (28): Timeout was reached for http://ftp.uni-bayreuth.de/linux/almalinux/9.4/AppStream/x86_64/os/Packages/cheese-libs-3.38.0-6.el9.x86_64.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
[MIRROR] cheese-libs-3.38.0-6.el9.x86_64.rpm: Curl error (28): Timeout was reached for https://mirror.alpha-labs.net/almalinux/9.4/AppStream/x86_64/os/Packages/cheese-libs-3.38.0-6.el9.x86_64.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
(44/856): cheese-libs-3.38.0-6.el9.x86_64.rpm    10 kB/s | 829 kB     01:22
(45/856): chrome-gnome-shell-42.1-1.el9.x86_64. 1.8 MB/s |  50 kB     00:00
[MIRROR] almalinux-backgrounds-90.5.1-1.1.el9.noarch.rpm: Curl error (28): Timeout was reached for http://ftp.uni-bayreuth.de/linux/almalinux/9.4/AppStream/x86_64/os/Packages/almalinux-backgrounds-90.5.1-1.1.el9.noarch.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
[MIRROR] adwaita-icon-theme-40.1.1-3.el9.noarch.rpm: Curl error (28): Timeout was reached for http://ftp.uni-bayreuth.de/linux/almalinux/9.4/AppStream/x86_64/os/Packages/adwaita-icon-theme-40.1.1-3.el9.noarch.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]
[MIRROR] cldr-emoji-annotation-39-2.el9.noarch.rpm: Curl error (28): Timeout was reached for http://ftp.fau.de/almalinux/9.4/AppStream/x86_64/os/Packages/cldr-emoji-annotation-39-2.el9.noarch.rpm [Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds]

Then it ends.

Since I have installed other machines in a similar way I don't think that it is a general network problem.

Is there a way to check the hardware (e.g. network interface card) with my current installation?

Now that Alma Linux is no longer 1to1 with RHEL, I'm thinking about migrating my Alma Linux 9 sever to RHEL 9. I have a developer license with Red Hat so it would be free.

Does anyone have an opinion on if this would be a good move or not?

Hello, before me is upgrade OS. I am looking for manual or …. how to do it. Unfortunately OS is on physical HW. I am writing step by step procedure and now i have: 1/ change repo to Alma 2/ run upgrade 3/ change network script to NetworkManager 4/ reboot to new OS

On second point will be necessary, maybe, make transaction in yum/dnf shell. Do you have anybody better manual/procedure/...?

Does anyone know a wat to migrate Alma Linux 9 to RHEL?

Hello I am using the following command to update the system (almalinux kde 9.4). Recently I am getting the following and it is not updating the flatpak.

[abc@pc ~]$ sudo dnf update -y && sudo flatpak update -y
[sudo] password for abc:    
Dependencies resolved.
Nothing to do.
Complete!
Looking for updates…
Info: org.kde.Platform//6.6 is end-of-life, with reason:
  We strongly recommend moving to the latest stable version of the Platform and SDK
Applications using this runtime:
  com.github.quaternion, com.obsproject.Studio
Nothing to do.

Please advise me and thank you.

EDIT: I believe %post runs in a chroot, maybe that's why?

In my minimal kickstart config for AlmaLinux 9 where I do as much of it as possible in Ansible, setting the interface to autoconnect does not workin %post but when the same command is run again when I boot up the system for the first time, it works. Any ideas?

In the kickstart file I have:

# Commented out, the defaults work fine
# network --device=enp1s0 --bootproto=dhcp --gateway=192.168.1.1 --ipv6=auto

%post
# TODO On booting the system for the first time, the interface is not
# enabled and in the NetworkManager config for the interface, it remains
# `autconnect=false`. Running this command manually will then apply the
# change as expected and the interface starts along with internet
# connection
nmcli con mod enp1s0 connection.autoconnect yes
%end

Does this mean on initial boot of the system there is still some one-time init going on that somehow negates the %post nmcli con mod enp1s0 connection.autoconnect yes %end that was presumably applied right after install but before system shuts down/reboots?

P.S. Unrelated, but I noticed the default sshd_config had everything commented out so it's using SSH defaults and allows PasswordAuthentication. I was told in RHEL 9 their default is this disable this. Is the differences in default config purely a subjective choice by AlmaLinux (perhaps following some kind of philosophy like respecting upstream app configs)? I'm new to Linux/RHEL and kind of just assumed AlmaLinux is basically RHEL with communit instead of commercial support.

Trying to upgrade CentOS 7.9 to Alma I get preupgrade errors about /boot/grub2/grub.cfg missing.

I try to run grub2-mkconfig/grub-mkconfig to generate this file and the command is not found.

I searched the whole machine for those binaries and they don't exist.

The directory /boot/grub/ exists but not /boot/grub2/.

Is the issue due to the fact that this server is a VPS?

I should explain that I know nothing about grub whatsoever.

EDIT 11/9/24 SOLVED:
My host was using OpenVZ which means my VPS wasn't truly under my control like I was led to believe by their advertising. Under OpenVZ end users have no kernel access. Had to move to a KVM VPS which has true full control. Would be nice if Alma could have been upgraded to without updating the kernel but then again the V3.10.0 kernel went EOL in 2017, 3 years before CentOS 7.9 even came out, so I decided it was probably time to move on lol.

I'm trying to build a forward proxy in Linode VPC. So that I can download and install packages on other instances in VPC.

I added proxy, proxy_username and proxy_password to /etc/dnf/dnf.conf

When running 'dnf update' I get:

[root@localhost ~]# dnf update AlmaLinux 8 - BaseOS 0.0 B/s | 0 B 00:00

Errors during downloading metadata for repository 'baseos':

Curl error (56): Failure when receiving data from the peer for https://mirrors.almalinux.org/mirrorlist/8/baseos [Received HTTP code 503 from proxy after CONNECT] Error: Failed to download metadata for repo 'baseos': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.almalinux.org/mirrorlist/8/baseos [Received HTTP code 503 from proxy after CONNECT]

What is that I'm missing?

Configs:

[1] /etc/httpd/conf.d/fwd-proxy.conf

Listen <forward-instance-ip>:8080 
<VirtualHost :8080> 
  ServerAdmin webmaster@localhost 
  DocumentRoot /var/www/html 
  ErrorLog /etc/httpd/logs/fwd-proxy-error.log 
  CustomLog /etc/httpd/logs/fwd-proxy-access.log combined 
  ProxyRequests On 
  ProxyVia On 
  <Proxy ""> 
    Require ip  
  </Proxy> 
</VirtualHost>10.0.0.0/24

[2] /etc/dnf/dnf.conf

[main] 
gpgcheck=1 
installonly_limit=3 
clean_requirements_on_remove=True 
best=True 
skip_if_unavailable=False 
proxy=<forward-instance-ip>:8080 
proxy_username=<username> 
proxy_password=<password> 
proxy_sslverify=False

Notes: All instances can ping each other. Firewall settings are good. httpd is used in the forward-proxy instance on port 8080. The forward-proxy instance is connected to internet.

SOLUTION:

Running `setsebool -P httpd_can_network_connect 1` in the proxy server fixed the issue.

It was 'Permission denied' error caused by SELinux.

Does anyone have this working for the X1 gen 12 laptops? We can get PXE to load the install environment but then that environment fails to curl the kickstart file. I presume the Alma 9 default pxe environment is missing the wifi drivers for Gen12? Does anyone know what those might be? - Or maybe a kernel release? Some redditing searches imply Kernel 6.6 drivers may be needed at a minimum for WiFi to work in Alma Linux, others report that 6.8.11 under Fedora made wifi work. My guess is the failure is that the installer kernel can't use the wifi...

Note, we've successfully done this on gen9 and earlier X1s, but the gen12 is failing.

After kickstart install on a virtual (qemu/kvm), I am encountering several expected issues:

virt-viewer shows systemd messages with the last one seemingly stuck at received client request to flush runtime journal. Is this normal? When I reboot, I do get a login prompt. A reboot is required (I see services like included firewalld and chronyd not available until a reboot and root login) but it's not clear if it's ready to be rebooted at this point (i.e. whether the complete was complete).

I don't want to use virt-viewer though and prefer everything CLI and ideally automatically. How can I be sure an installation is complete so that it's ready to be rebooted? virt-install is stuck at Waiting for the installation to complete.

Basically, how can I be confident there were no errors with the installation and that it was complete? Can I review some log of the installation process or systemd messages during boot to confirm this? Preferably in a CLI way with libvirt.

This is my kickstart file and currently I currently run virt-install like this.

Hi, I am trying to do the in-place upgrade of my system, RHEL 7 to Alma Linux 8 and getting issues with dependency checks. Below are what I did so far;

[root@Rhel79-30-135 yum.repos.d]# yum install leapp-upgrade leapp-data-almalinux 
Loaded plugins: langpacks, product-id, search-disabled-repos 
Package leapp-data-almalinux-0.4-7.el7.20240827.noarch already installed and latest version 
Resolving Dependencies 
--> Running transaction check 
---> Package leapp-upgrade-el7toel8.noarch 1:0.21.0-2.el7.elevate.3 will be installed 
--> Processing Dependency: leapp-repository-dependencies = 10 for package: 1:leapp-upgrade-el7toel8-0.21.0-2.el7.elevate.3.noarch 
--> Processing Dependency: leapp-framework >= 5.0 for package: 1:leapp-upgrade-el7toel8-0.21.0-2.el7.elevate.3.noarch 
--> Processing Dependency: leapp for package: 1:leapp-upgrade-el7toel8-0.21.0-2.el7.elevate.3.noarch
--> Processing Dependency: python2-leapp for package: 1:leapp-upgrade-el7toel8-0.21.0-2.el7.elevate.3.noarch 
--> Running transaction check 
---> Package leapp.noarch 0:0.18.0-1.el7 will be installed 
---> Package leapp-upgrade-el7toel8-deps.noarch 1:0.21.0-2.el7.elevate.3 will be installed 
--> Processing Dependency: dnf >= 4 for package: 1:leapp-upgrade-el7toel8-deps-0.21.0-2.el7.elevate.3.noarch 
--> Processing Dependency: python-requests for package: 1:leapp-upgrade-el7toel8-deps-0.21.0-2.el7.elevate.3.noarch 
---> Package python2-leapp.noarch 0:0.18.0-1.el7 will be installed 
--> Processing Dependency: leapp-framework-dependencies = 5 for package: python2-leapp-0.18.0-1.el7.noarch 
--> Running transaction check 
---> Package leapp-deps.noarch 0:0.18.0-1.el7 will be installed 
---> Package leapp-upgrade-el7toel8-deps.noarch 1:0.21.0-2.el7.elevate.3 will be installed 
--> Processing Dependency: dnf >= 4 for package: 1:leapp-upgrade-el7toel8-deps-0.21.0-2.el7.elevate.3.noarch 
---> Package python-requests.noarch 0:2.6.0-10.el7 will be installed 
--> Processing Dependency: python-urllib3 >= 1.10.2-1 for package: python-requests-2.6.0-10.el7.noarch 
--> Running transaction check 
---> Package leapp-upgrade-el7toel8-deps.noarch 1:0.21.0-2.el7.elevate.3 will be installed 
--> Processing Dependency: dnf >= 4 for package: 1:leapp-upgrade-el7toel8-deps-0.21.0-2.el7.elevate.3.noarch 
---> Package python-urllib3.noarch 0:1.10.2-7.el7 will be installed 
--> Finished Dependency Resolution 
Error: Package: 1:leapp-upgrade-el7toel8-deps-0.21.0-2.el7.elevate.3.noarch (elevate) 
Requires: dnf >= 4 
You could try using --skip-broken to work around the problem 
You could try running: rpm -Va --nofiles --nodigest 
[root@Rhel79-30-135 yum.repos.d]# uname -a Linux Rhel79-30-135 3.10.0-1160.el7.x86_64 #1 SMP Tue Aug 18 14:50:17 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux

Now, when I run it again with " --skip-broken" to work around the problem, I got this;

Packages skipped because of dependency problems: 
  leapp-0.18.0-1.el7.noarch from elevate 
  leapp-deps-0.18.0-1.el7.noarch from elevate 
  1:leapp-upgrade-el7toel8-0.21.0-2.el7.elevate.3.noarch from elevate 
  1:leapp-upgrade-el7toel8-deps-0.21.0-2.el7.elevate.3.noarch from elevate 
  python-requests-2.6.0-10.el7.noarch from LocalRepo 
  python-urllib3-1.10.2-7.el7.noarch from LocalRepo 
  python2-leapp-0.18.0-1.el7.noarch from elevate 
Dependencies Resolved.

Now still cannot do the 'leapp' command and upgrade my server. Appreciate all the help.

BTW, I am using a local repository via the cdrom and I have three repos

-rw-r--r--. 1 root root 379 Mar 17  2023 ELevate.repo
-rw-r--r--. 1 root root 129 Oct 31 09:43 local.repo 
-rw-r--r--. 1 root root 358 Oct 30 16:38 redhat.repo

Thanks,

I have a couple vps with a small ssd (8 to 20gb) for os and a bigger hdd for storage. (2tb or more)

I usually install AlmaLinux 9 with LUKS FDE via the graphical installer. When storage comes i select both disks and select automatic partitioning.

Installer creates lvm which spreads across both disks

Like /boot on ssd for 1gb / for 35gb spread between remaining ssd and some hdd. /home on hdd

Is this ok or should I do manual partition on ssd and hdd? If later what should be the recommended partitioning strategy?

I prefer luks based full disk encryption on whole storage.

Whats the best approach?

Thanks

Quick noob questions, is there a changelog of versions of the distro and a way to track history of RHEL documentation?

I want to track what changes could potentially require manual adjustments for my system and also it serves as an overview with the development/trend of the distro which is just good knowledge in general (without digging for dev mailing lists).

Also I've been using https://docs.redhat.com/en/documentation/ as primary reference from googling, but it often points me to pages written for older RHEL versions. I then need to google to see if there's a newer version of the same page (example url: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/using-and-configuring-firewalld_configuring-and-managing-networking), there doesn't seem to be an obvious way to jump to version 9 of this page trying to search it from scratch and changing 8 to 9 in the URL doesn't work either.

If e.g. AlmaLinux updates to version 10, I don't want to check documentation for potential changes--I could just look at the diff to see if anything relevant applies and not have to parse through the same info again. From an Arch Wiki page the diff is easily accessible by clicking on "View history".

Another example: if I rely on kickstart script and intend to use it on a new release, I would like to know beforehand if there's any change in syntax or new features without just trying and if it works it works. I don't need to check the full documentation for potential updates again, right?

Any tips much appreciated.

If I try updating glibc to version 2.34-100.el9_4.4 I get the following error:

 Problem: package nss_db-2.34-100.el9_4.3.x86_64 from @System requires glibc(x86-64) = 2.34-100.el9_4.3, but none of the providers can be installed
  - cannot install both glibc-2.34-100.el9_4.4.x86_64 from baseos and glibc-2.34-100.el9_4.3.x86_64 from @System
  - cannot install both glibc-2.34-100.el9_4.4.x86_64 from baseos and glibc-2.34-100.el9_4.3.x86_64 from baseos
  - cannot install the best update candidate for package glibc-2.34-100.el9_4.3.x86_64
  - problem with installed package nss_db-2.34-100.el9_4.3.x86_64

It seems nss_db has a hard dependency on glibc version 2.34-100.el9_4.3 and hasn’t been rebuilt for the updated version of glibc. Are there plans to resolve this?

This system has been migrated from CentOS 7 up to AlmaLinux 9. Is nss_db no longer recommended when using local files for users, groups, etc.?

Hello. You guys are probably aware that RHEL have an AI version. And I am aware that it is all about the application that you download and install to enable something similar to this.

Any information or a guide about this?

Is it possible to expect an AlmaLinux version of AI since the SIG is established?

Thanks,

Curious if AlmaLinux 9.5 going to be a thing, or is 9.x being abandoned for AlmaLinux 10?

I would like to know how to find a server that allows me to install a Python application that needs to open the Chrome browser to open my website and perform some daily tests as if I were a user browsing it.

I have the entire system running locally, but whenever my connection drops or the power goes out, the system crashes and when I'm not at home I can't restart it and the computer slows down so I can't do other tasks. So I want to move this to an online server but I don't know the requirements to research.

I know it needs to be Linux Ubuntu, with PHP and Python 3.11, but it needs this user interface that when I start talking to support no one understands what I'm talking about or when I read about the server's resources I can't find anything about it.

I have the instructions on what needs to be done to install locally (command line), so I believe it is the same as installing on the server, but the normal server for my website (Hostgator doesn't have this).

I found some tutorials, but I'm not sure yet which server to choose that allows me to activate this, or if there is one that already comes with this enabled to make my work easier, as I'm inexperienced with this, but I'm trying to learn because I can't afford to hire a professional to do this. I'm familiar with the classic Linux XAMP apache/php/mysql/wordpress server, with cPanel, and even with WHM (multiple cPanel accounts), root and command line, but Python and GUI are new to me.

https://serverspace.io/support/help/almalinux-install-gnome/

I don't know if it's allowed here, but if anyone can directly indicate the name of 1 or 2 servers that have this so I can compare and choose the best cost-benefit, I'd be very grateful.

I intend to use AlmaLinux for server--it defaults to NetworkManager. My understanding is that systemd-networkd is more straightforward and appropriate for server use, while NetworkManager is desktop-friendly. Is it recommended to then try to make NetworkManager work for everything or just uninstall and switch to systemd-networkd? I'm curious why the latter is not the default at least if the distro is more appropriate for server use. Also, is such decisions dependent on RHEL's defaults and does AlmaLinux have freedom to decide otherwise? Nothing against NetworkManager, just curious.

On my laptop, I'm using NetworkManager exclusively. How to set static IP address for wifi network so that my server can use it as a filter to allow access to select devices on the network? The router for the network does not support DHCP reservation. I see examples documented for a ethernet connetions which seems more straightforward, but not for wifi.

Thanks.

Hi, I'm exploring moving away from RHEL on about 400 VMs because it's too expensive for the value we get (not using Satellite, hardly use Support, costs increase as we move to public clouds). I've researched both Alma Linux and Rocky Linux as possible candidates and given that Rocky Linux is based on RHEL source code from UBI images and RHEL cloud instances, I'm concerned about Red (Purple) Hat potentially dealing them another blow! I know that Alma Linux builds from CentOS Stream and plays nice with Red Hat. Now, apart from these differences in build sources, can you please enlighten me on reasons why picking Alma Linux over Rocky Linux would be a good, strategic choice?

Hello. I am planning to learn rust and I was thinking that it is better to target the LTS release that comes with AL9 (With version 9.4, Rust Toolset is version 1.75.1) other than the latest release 1.82 at the time of this post.

Just wondering if anyone had any experience in using this version with any tool like VS Code or Jetbrains RustRover? Also, if someone can guide me on the file path in the system.

Thanks,

Gave a try upgrading my NAS from CentOS 7 to Alma 8 using Elevate and I'm absolutely stuck on several key utilities I use for file synchronization.

I used Trickle to limit bandwidth of unison...and I found source I can build but then I don't want to randomly have the makefiles write to random places so I would want to make a RPM but the source I found doesn't do that. I believe these used to both be in EPEL on CentOS 7 but seems to not be there for 8.

I could live with newer versions as I'm ultimately updating all my machines but I can't find any versions.

I used to use `checkinstall` to make packages for things which don't have them but I can't find a version of checkinstall for EL8 either.

At this point I've spent my whole day and my only option seems to be restoring from backups so I can have it operational and try again another weekend...but I have to overcome these issues because those utilities are essential to keeping my NAS synchronized with offsite storage and backups.

Here's the old CentOS 7 package information if that helps someone understand what I'm trying to find an Alma 8 compatible package for:

# yum whatprovides unison
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * epel: 
unison240-gtk-2.40.128-5.el7.x86_64 : Multi-master File synchronization tool - gtk interface
Repo        : epel
Matched from:
Provides    : unison = 2.40.128-5.el7

unison240-gtk-2.40.128-5.el7.x86_64 : Multi-master File synchronization tool - gtk interface
Repo        : u/epel
Matched from:
Provides    : unison = 2.40.128-5.el7

# rpm -q -i unison240
Name        : unison240
Version     : 2.40.128
Release     : 5.el7
Architecture: x86_64
Install Date: Sun 01 Sep 2019 09:04:29 PM EDT
Group       : Applications/File
Size        : 399353
License     : GPLv3+
Signature   : RSA/SHA256, Thu 22 Sep 2016 11:03:49 AM EDT, Key ID 6a2faea2352c64e5
Source RPM  : unison240-2.40.128-5.el7.src.rpm
Build Date  : Thu 22 Sep 2016 09:03:36 AM EDT
Build Host  : buildvm-18.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://www.cis.upenn.edu/~bcpierce/unison
Summary     : Multi-master File synchronization tool
Description :

# yum whatprovides trickle
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
 * epel: d2lzkl7pfhq30w.cloudfront.net
trickle-1.07-19.el7.x86_64 : Portable lightweight userspace bandwidth shaper
Repo        : epel
trickle-1.07-19.el7.x86_64 : Portable lightweight userspace bandwidth shaper
Repo        : @epel

# rpm -q -i trickle
Name        : trickle
Version     : 1.07
Release     : 19.el7
Architecture: x86_64
Install Date: Thu 04 Feb 2021 02:26:54 PM EST
Group       : Applications/System
Size        : 105148
License     : BSD with advertising
Signature   : RSA/SHA256, Tue 07 Oct 2014 04:04:06 PM EDT, Key ID 6a2faea2352c64e5
Source RPM  : trickle-1.07-19.el7.src.rpm
Build Date  : Mon 06 Oct 2014 05:44:28 AM EDT
Build Host  : buildvm-05.phx2.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : http://monkey.org/~marius/pages/?page=trickle
Summary     : Portable lightweight userspace bandwidth shaper
d2lzkl7pfhq30w.cloudfront.net

I have a fairly busy server thats logging tons of systemd noise at what appears to be the default info or debug level.

How can I persistently reduce the log level of systemd itself to something like "warning" or even error? I don't want to affect logging of other processes, just systemd ...

Is there a default kickstart file for AlmaLinux available to the public? I don't want to register for a RHEL account for this (it requires address and other info and I'm not even sure if getting the kickstart file is free this way) or create a VM to generate one each time it should be updated.

Also, can I can bake this along with an SSH key into an ISO? I want to install it on a Pi server headlessly--kickstart sets up bare minimum for a working install and configures SSH securely, then I can use Ansible to configure the rest of the system.

Any tips are much appreciated.

P.S. Would AlmaLinux install on an Orange Pi 5? I don't see something specific for it. It's ARM so it should work, right? And on a Raspberry Pi 4 B, is an SD card required or can I install on a flash drive or external disk? IIRC I had to jump through some hoops to install Rasbian Pi on a flash drive. I find SD cards unreliable for server use .