Tag: fedora

  • Drivers and CUDA Toolkit Setup for Nvidia on Fedora 40

    Drivers and CUDA Toolkit Setup for Nvidia on Fedora 40

    First determine what driver is installed. Below we can see that we are running the “nouveau” driver and not the Nvidia proprietary driver.

    $ sudo lspci -n -n -k | grep -A 2 -e VGA -e 3D
    01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106 [GeForce RTX 3060 Lite Hash Rate] [10de:2504] (rev a1)
    	Subsystem: PNY Device [196e:138f]
    	Kernel driver in use: nouveau
    

    Add rpm fusion repos.

    $ sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

    Dnf update.

    $ sudo dnf update -y

    Install kernel-devel which provides kernel headers and makefiles required to build kernel modules.

    $ sudo dnf -y install kernel-devel

    Install akmod-nividia, which checks if there are any missing kernel mods at boot time and will if so, will build them.

    $ sudo dnf -y install akmod-nvidia 

    Now install the CUDA driver for xorg-x11-drv-nvidia.

    $ sudo dnf -y install xorg-x11-drv-nvidia-cuda

    Enable/start Nvidia nvidia-persistenced.service.

    sudo systemctl enable --now nvidia-persistenced.service

    Reboot.

    Now we check to make sure that the driver is loaded.

    $ sudo lspci -n -n -k | grep -A 2 -e VGA -e 3D
    [sudo] password for cpaquin: 
    01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106 [GeForce RTX 3060 Lite Hash Rate] [10de:2504] (rev a1)
    	Subsystem: PNY Device [196e:138f]
    	Kernel driver in use: nvidia
    

    Run “nvidia-smi” to show the exact driver revision. Below we have 565.77. And this driver is compatible with CUDA Version: 12.7.


    Nvidia Cuda Toolkit Install

    We now need to install the nvidia-cuda-toolkit. We will get this directly from nvidia. According to the driver/toolkit version matrix found here, we should install Cuda Toolkit 12.6.

    First install the following pre-req. Nvcc will not compile on gcc14 which is default for Fedora 40.

    # sudo dnf install gcc13-c++ -y

    Pull down the installer

    wget https://developer.download.nvidia.com/compute/cuda/12.6.2/local_installers/cuda_12.6.2_560.35.03_linux.run
    

    Make the file executable

    $ sudo chmod +x cuda_12.6.2_560.35.03_linux.run

    Now install. Since we already have drivers installed, make sure that you uncheck all install options except for the toolkit itself.

    sudo ./cuda_12.6.2_560.35.03_linux.run

    Add the following to your .bashrc. And if you intend to run/install anything as root, you may want to add it to root’s .bashrc as well.

    export PATH=/usr/local/cuda-12.6/bin:$PATH

    Next add “/usr/local/cuda-12.6/lib64” to “/etc/ld.so.conf” and run “ldconfig” as root. See example below

    # cat /etc/ld.so.conf
    include ld.so.conf.d/*.conf
    /usr/local/cuda-12.6/lib64

    Now run ldconfig

    # ldconfig

    Now test nvcc as shown below.

    $ nvcc --version
    nvcc: NVIDIA (R) Cuda compiler driver
    Copyright (c) 2005-2024 NVIDIA Corporation
    Built on Thu_Sep_12_02:18:05_PDT_2024
    Cuda compilation tools, release 12.6, V12.6.77
    Build cuda_12.6.r12.6/compiler.34841621_0
    

    Resources

    1. https://www.reddit.com/r/Fedora/comments/1gpp5a4/how_to_install_nvcc_on_fedora_41/
    2. https://rpmfusion.org/Howto/NVIDIA#Akmods
    3. https://packages.fedoraproject.org/pkgs/kernel/kernel-devel/
    4. https://rpmfusion.org/Configuration
    5. https://forums.developer.nvidia.com/t/cuda-toolkit-support-for-fedora-40/308193/2
    6. https://forums.developer.nvidia.com/t/cuda-toolkit-installation-problems-on-fedora-41-forty-one/317186/2
  • Fedora21 – Quick and Dirty with Firewalld

    firewall

    Hey, are you new to Firewalld like most of us?

    Unless you have been using Firewalld in the last few releases of Fedora, as some out there have, then you probably could probably use a few pointers to get you started on your way to configuring your Linux firewalls the “new-fangled fancy way”. This is especially the case if you plan on moving to RHEL7 anytime soon — as Firewalld is the default there. So put on your big boy (or girl) pants and say goodbye to your old friend IPTABLES.

    According to this page. Firewalld is…

    “The dynamic firewall daemon firewalld provides a dynamically managed firewall with support for network zones to assign a level of trust to a network and its associated connections and interfaces. It has support for IPv4 and IPv6 firewall settings. It supports Ethernet bridges and has a separation of runtime and permanent configuration options. It also has an interface for services or applications to add firewall rules directly”

    Wow, how fancy. So how do we use it? Well let’s take a stab at enabling HTTP access to our Fedora21 workstation.

    First thing first, lets figure out what our default done is on our workstation.

    $ sudo firewall-cmd –get-default-zone
    FedoraWorkstation

    Ok, thats a bit strange, in RHEL you should expect PUBLIC to be your default zone.  Now that we know what zone we need to mess with let’s make sure that its applied to the proper interfaces.

    $ sudo firewall-cmd –get-active-zone
    FedoraWorkstation
    interfaces: enp4s0 enp5s4 macvtap0 tun0 virbr0

    The first two interfaces above are our physical interfaces, so we are good here. Now lets apply the rule, and make sure its permanent.

    $ sudo firewall-cmd –permanent –zone=FedoraWorkstation –add-service http
    success

    Now lets check our rules. Note HTTP is missing.

    $ sudo firewall-cmd –list-services
    dhcpv6-client mdns samba-client ssh

    Since we have only applied this new rule to our permanent config and not to our running config, we need to restart firewalld to see the updated rule.

     $ sudo firewall-cmd –reload

    Now your can view the updated rules…

    $ sudo firewall-cmd –list-services
    dhcpv6-client http mdns samba-client ssh

  • Insync: The Powerful Google Drive Client For Linux

    Insync

    Insync is a very powerful and full featured Google Drive client for Windows, Mac, and Linux. I ran across Insync when I was looking for a Google Drive client for Linux after I kicked Dropbox to the curb and switching over to Google Drive for all my cloud storage needs.

    In all honesty, if it wasn’t for the Insync client I do not think that I would have made the switch at all, as Google does not even offer a basic GUI client for Linux. Really Google?

    PSA: The integration that Google Drive provides into Google Photos, Google Music, Google Docs, and Gmail is well worth the switch from Dropbox in my opinion, and 1TB for only 9 bucks a month is hard to beat (100GB is only $1.99 a month). Just having a Gmail account gives you access to 15GB of free space… so there is no reason not to give it a try.

    Ok now back to the topic at hand.

    Note that a personal license of the Insync Google Drive client is not free, rather it costs $15. However you can download and try it risk free and without entering any credit card info. This one time fee for a personal license allows you to run and install Insync on multiple machines. Currently I have it installed on 4 separate Linux workstations/laptops. Its well worth cash.

    Installing Insync is very easy and well documented so I am not going to go into that topic here. Rather lets talk about using Insync on Linux.

    (more…)

  • RHEL6: Cool PAM Tricks – Logging Terminal Keystokes

    Pam-original-cooking-spray-72450This is a neat and very useful trick that I learned today. Lets say that you want to be able to monitor and log all keystrokes that are typed as root. This is particularly useful as normally you can only log when a user uses sudo to run a command. If the user has the abilty to become root however,  then they have effectively eluded yourattempts to track their activity. Like Thomas Magnum shaking a tail, they are free to scoot around your island with the top down.

    So how do you stop this from occuring? How to you log all activity and keystrokes made by root without implementing a bloated 3rd party software that will probably cost and arm and a leg? You use PAM you dingbat.
     

    The secret sauce in this security burrito is the pam_tty_audit.so module. Here is how to use it,

    Below is my stock /etc/pam.d/system-auth file

    #%PAM-1.0
    # This file is auto-generated.
    # User changes will be destroyed the next time authconfig is run.
    auth        required      pam_env.so
    auth        sufficient    pam_fprintd.so
    auth        sufficient    pam_unix.so nullok try_first_pass
    auth        requisite     pam_succeed_if.so uid >= 500 quiet
    auth        required      pam_deny.so

    account     required      pam_unix.so
    account     sufficient    pam_localuser.so
    account     sufficient    pam_succeed_if.so uid < 500 quiet
    account     required      pam_permit.so

    password    requisite     pam_cracklib.so try_first_pass retry=3 type=
    password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
    password    required      pam_deny.so

    session     optional      pam_keyinit.so revoke
    session     required      pam_limits.so
    session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
    session     required      pam_unix.so

    Now look above and then look below at my modified system-auth file. Note the additonal session entry for pam_tty_audit.so.

    [root@ip-172-31-21-28 pam.d]# cat system-auth
    #%PAM-1.0
    # This file is auto-generated.
    # User changes will be destroyed the next time authconfig is run.
    auth        required      pam_env.so
    auth        sufficient    pam_fprintd.so
    auth        sufficient    pam_unix.so nullok try_first_pass
    auth        requisite     pam_succeed_if.so uid >= 500 quiet
    auth        required      pam_deny.so

    account     required      pam_unix.so
    account     sufficient    pam_localuser.so
    account     sufficient    pam_succeed_if.so uid < 500 quiet
    account     required      pam_permit.so

    password    requisite     pam_cracklib.so try_first_pass retry=3 type=
    password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
    password    required      pam_deny.so

    session     optional      pam_keyinit.so revoke
    session     required      pam_tty_audit.so enable=root
    session     required      pam_limits.so
    session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
    session     required      pam_unix.so

    Note that you will need to add the pam_tty_audit.so call to your /etc/pam.d/password-auth as well to ensure that you capture all of root's keystrokes, no matter how they log in.

     

    Related articles

    Much Todo About Linux/RHEL Passwords
    RHEL6 – How to Manually Logout of an Iscsi Disk
    Fun With PAM: Working with pam_cracklib and pam_tally2
  • Password Protecting Grub in RHEL 6

    19552780-illustration-of-cartoon-wormGrub, is the standard boot loader used by each and every Linux type operating system that I can think of. RHEL 6 uses what I guess we are now calling grub 1.o, since grub 2.0 has been released and in use by Fedora for the last few releases. You will also find that grub 2.0 has replaced grub 1.0 in RHEL 7. At some point I plan to explore grub 2 at lenght, but today is not that day (unless something strange happens before I go to bed tonight — you never know).

     

    Anyway – I digress. Below is an excerpt from the current grub.conf that is in use by my EC2 RHEL 6.5 instance. I've made it really tiny to save space.

    # grub.conf generated by anaconda
    #
    # Note that you do not have to rerun grub after making changes to this file
    # NOTICE:  You do not have a /boot partition.  This means that
    #          all kernel and initrd paths are relative to /, eg.
    #          root (hd0)
    #          kernel /boot/vmlinuz-version console=ttyS0 ro root=/dev/vda1
    #          initrd /boot/initrd-[generic-]version.img
    #boot=/dev/vda
    default=0
    timeout=1
    splashimage=(hd0)/boot/grub/splash.xpm.gz
    hiddenmenu
    title Red Hat Enterprise Linux Server (2.6.32-431.17.1.el6.x86_64)
            root (hd0)
            kernel /boot/vmlinuz-2.6.32-431.17.1.el6.x86_64 console=ttyS0 ro root=UUID=05e7b919-2577-40a7-91fb-1ccdede87fc4 rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 xen_blkfront.sda_is_xvda=1 console=ttyS0,115200n8 console=tty0 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM rhgb quiet
            initrd /boot/initramfs-2.6.32-431.17.1.el6.x86_64.img

    To configure a password to use for grub you need to use the grub-crypt command. as you can see in the example below, grub-crypt prompts you for your password, although you can also pass the password to grub-crypt in the inital command. Grub-crypt spits out your hashed and salted password.

    [root@ip-172-31-22-45 ~]# grub-crypt
    Password:
    Retype password:
    $6$V0qkcD4b/CouCY/L$.7vrHd.X6MZWzzDxvXdQn3avPwv2rUX80XKuS.Hvh1YqR11ZyINZszvJ/e0qH6VcsFMAVWAPWXtugHHYTzYj90

    Now stick this password in your grub.conf using the format below.

    password –encrypted $6$V0qkcD4b/CouCY/L$.7vrHd.X6MZWzzDxvXdQn3avPwv2rUX80XKuS.Hvh1YqR11ZyINZszvJ/e0qH6VcsFMAVWAPWXtugHHYTzYj90

    You have a couple of options when inserting the password into the grub.conf. You can either stick this entry near the top of the file, which protects each and every boot image that you might be configured to use, or you can stick the entry directly into a particular stanza to protect a specific boot image. For example, if you are building your servers with the option to pxe-boot from grub, or wipe the disk from grub, you might want to protect these options with a password.

    Also note that adding a password to grub does not keep an unauthorized user from being able to boot or reboot a server, rather what it does is protect the grub menu from being edited manually durring a reboot. This keeps nefarious users from being able to break the boot sequence and boot into single-user mode where they can compromise your system.

     
    Related articles

    RHEL6 – Restore Grub on MBR
    Grub
    RHEL6 – Mount: Could Not Find Any Free Loop Device
  • Fun With PAM: Working with pam_cracklib and pam_tally2

    Liberty-bell_13850_smPlugable Authentication Modules, or PAM, is the standard mechanism that most Unix and Linux Operatng Systems use for user credential authentication. By design, PAM is broken out into a number of files, each with a specific purpose. Before you can get started with PAM you need to understand a bit about how PAM configuration files are formatted.  So lets get into that first before we try to bite off anything more.

     

    PAM Config File Standards:

    PAM config files follow a standard format as shown below.

    Rule Types        Control        Module [module arguments]

     

    There are 4 Rule Types

    • auth – used to authenticate users/passwords
    • account – set properties for a user's account
    • password – controls password changes
    • session – sets and controls environmental variables

    And there are 5 Control Types

    • required – a module that a user is required to pass
    • sufficient – a user is not required to pass a sufficient module
    • optional – these modules do not have to be passed sucessfully
    • include – these rules reference other PAM config files
    • requisite – similar to required, but if failed, no further rules are checked

     

    Configuring pam_cracklib:

    Pam_cracklib is used to define password complexity. It has several module arguments that can be used to define password complexity and lenght. Its most common arguments are show below

    • ucredit – when used in the following format (ucredit=-n) requires the defined number of uppercase characters in a password
    • dcredit – when used in the following format (dcredit=-n) requires the defined number of digits in a password
    • ocredit – when used in the following format (ocredit=-n) requires the defined number of other (think symbols) type charaters in a password
    • lcredit – when used in the following format (lcredit=-n) requires the defined number of lower case letters  in a password
    • minclass – defines the minimum number of different character classes that must be present in a password.
    • minlen – defines the minimum required lenght of a password.

    Here's a usage example of the cracklib module from a /etc/pam.d/system-auth file. In this example try_first_pass tells pam to try to use any cached credentials, while retry allows a user to try their password 3 times before the fail this module.

    password    requisite     pam_cracklib.so minlen=8 ocredit=-1 ucredit=-1 try_first_pass retry=3

     

    Configuring pam_tally2:

    Pam_tally2 can be used to lock users after a defined number of failed login attempts. The example below, taken from the system-auth file will lock a user after 3 failed login attempts, will automatically unlock the user after 300 seconds, and will do so quietly, without any notification to the user.

    auth        required        pam_tally2.so deny=3 unlock_time=300 quiet

    The command pam_tally2 can be used to list users with failed logins and can also be used to reset a user's failed login count. See reset example below

    pam_tally2 –reset –u testuser

    Note that pam_tally2 deprecates the faillock module.

     

    Supplementary PAM Configuration Options:

    Want to limit a user to a particular number of concurrent ssh sessions? You can set this up in /etc/security/limits.conf if you are calling the pam_limits.so in your pam configs. Limits.conf provides the example below. Just copy the format and you are off to the races. Remember to remove the #.

    #@student        -       maxlogins       4

     

     
    Related articles

    How to enforce password complexity on Linux
    Secure Linux Servers
    You are not allowed to access to (crontab) because of pam configuration.
  • Introduction to AIDE – Advanced Intrusion Detection Environment

    Wally_Gator_PhotoEver heard of AIDE, neither had I. Apparently its a simple intrusion detection application that can be used to monitor file changes.  It can be confired to monitor permission, ownership, timestamp, or content changes.

    Lets install it. Its in the stock Redhat repos, so its a piece of cake to install via yum.

     

    [root@localhost ~]# yum -y install aide

    Once installed, you can tweak the config file (/etc/aide.conf) to your liking. The stock config is pretty robust, so I am going to trim it down a bit and just monitor /etc for permission changes, and /bin for what are defined as normal changes. Normal looks at file hashes to see if the files have been modified.

    /bin    NORMAL
    /etc    PERMS
     

    Now lets start aide

    [root@localhost ~]# aide –init

    AIDE, version 0.15.1

    ### AIDE database at /var/lib/aide/aide.db.new.gz initialized.

     

    Now this part is silly, we need to rename the database created above to the name that aide is configured to use.

    [root@localhost ~]# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

     

    Now lets check for changes.

    [root@localhost ~]# aide –check

    AIDE, version 0.15.1

    ### All files match AIDE database. Looks okay!

    Hey no changes. Now lets monkey with something and see if aide catches it. In this example we are creating a new file in /etc. As seen below aide catches the new file and reports on it.

     

    [root@localhost ~]# touch /etc/aide.test.change
    [root@localhost ~]# aide –check
    AIDE 0.15.1 found differences between database and filesystem!!
    Start timestamp: 2014-07-15 19:51:14

    Summary:
      Total number of files:        5054
      Added files:                  1
      Removed files:                0
      Changed files:                0

    —————————————————
    Added files:
    —————————————————

    added: /etc/aide.test.change

     

    So now lets re-initialize the database, which is pretty much a snapshot.

    [root@localhost ~]# aide –init

    AIDE, version 0.15.1

    ### AIDE database at /var/lib/aide/aide.db.new.gz initialized.

     

    Don't forget to overwrite the old database.

    [root@localhost ~]# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
    cp: overwrite ‘/var/lib/aide/aide.db.gz’? yes

    Now lets change the permissions on our test file and see if aide catches the change.  I'll spare you the suspense and let you know that aide did its job. See below.

     

    [root@localhost ~]# chmod 777 /etc/aide.test.change
    [root@localhost ~]# aide –check                    
    AIDE 0.15.1 found differences between database and filesystem!!
    Start timestamp: 2014-07-15 19:54:09

    Summary:
      Total number of files:        5054
      Added files:                  0
      Removed files:                0
      Changed files:                2

    —————————————————
    Changed files:
    —————————————————

    changed: /etc/aide.test.change
    changed: /root/.mozilla/firefox/8u03e3hs.default/sessionstore.js

    —————————————————
    Detailed information about changes:
    —————————————————

    File: /etc/aide.test.change
     Perm     : -rw-r–r–                       , -rwxrwxrwx
     ACL      : old = A:
    —-
    user::rw-
    group::r–
    other::r–
    —-
                      D: <NONE>
                new = A:
    —-
    user::rwx
    group::rwx
    other::rwx
    —-
                      D: <NONE>

    Now aide on its own is just a simple tool, but run via cron with a bit of tuning and a bit more logic behind it and I can see it being a very useful tool. Looking forward to playing with it more.
    Related articles

    How To Install Aide on a DigitalOcean VPS
    RHEL6 – How to Setup an Anonymous Download Only FTP Server