Adding Arch Support

[Derrekito]

I don't think this is quite ready and I'm looking for feedback. If we come to an agreement I'll remove the extraneous files and squash the commits so it won't pollute the history.

[ddschmitz]

Would the intention of this be that there would be a bash script for each distro?

I use Debian and was looking into the script myself to see if it will run on my setup. Did you notice any issues with the script since Debian uses firefox-esr? I'm looking into it now and wondering if that name difference would cause any issues.

I also see you made your changes off of main. I saw in the development branch that there was some effort made to support opensc as opposed to cackey I think. There might be value in considering if you should add that to this PR. Other people more familiar with the project might have better thoughts on that.

[Derrekito]

I'd like to create one monolithic script. Perhaps distro-specific functions would be worth considering. The separate scripts are just in case you want to take development in another direction. I'm happy to keep collaborating until we have something more robust and mature.

I know the method used to get the CAC working properly is compatible with Firefox-esr (I have another machine where we did this by hand). But I didn't try on a vanilla Debian distro. Another issue worth considering is Ubuntu (which is Debian-based), which now uses a snap to install Firefox, which I've been unsuccessful at getting the CAC working. I had to uninstall the snap version and install it again from the official Mozilla repo. So, if we want this script to be more versatile, we must understand the environment more fully.

Regarding OpenSC, I had trouble getting cackey to work on Arch. I didn't try too hard and found this to be a workaround.

Here's how I see this project possibly progressing.

Our main script first checks our distribution and how the browsers are installed first. Based on that, we import distro-specific helper functions. These helper function files generally have the same named functions but are only included by the main function using that filer.

So the project hierarchy looks something similar to this

├── cac_setup.sh
└── helper
    ├── arch_helper.sh
    ├── debian_helper.sh
    └── global_helper.sh

where cac_setup.sh begins with something like

#!/bin/bash

# Capture script directory path
DIR="$( cd "$( dirname "${BASH_SOURCE[0]-$0}" )" && pwd )"

# Source universal helper functions
source $DIR/helper/global_helper.sh

# Determine the Linux distribution by checking the release information
if grep -qi "Debian" /etc/os-release; then
    # Source the Debian-specific helper script if Debian is detected
    source $DIR/helper/debian_helper.sh
elif grep -qi "Arch" /etc/os-release; then
    # Source the Arch-specific helper script if Arch Linux is detected
    source $DIR/helper/arch_helper.sh
else
    echo "Unsupported Linux distribution."
fi

# Continue installation

This way, we can make the same calls in the main script while ensuring distro-specific support.

Thoughts?

[bengooch7]

The script should work fine with Ubuntu. It was our main testing environment when we originally developed the script. When Unbuntu moved to Snap, we added in the option to try to uninstall the snap version and force the apt version (by way of a new repo added to apt) then reinstall the apt version. I even built in profile migration and re-adding the FF icon to the dock. When you ran the script on the machine which was unsuccessful, did it prompt for you to choose whether or not to attempt the swap from snap to apt?

…

On Sat, Apr 20, 2024, 12:10 Derrek Landauer ***@***.***> wrote: I'd like to create one monolithic script. Perhaps distro-specific functions would be worth considering. The separate scripts are just in case you want to take development in another direction. I'm happy to keep collaborating until we have something more robust and mature. I know the method used to get the CAC working properly is compatible with Firefox-esr (I have another machine where we did this by hand). But I doubt this script works out of the box for that configuration. Another issue worth considering is Ubuntu (which is Debian-based), which now uses a snap to install Firefox, which I've been unsuccessful at getting the CAC working. So, if we want this script to be more versatile, we need to understand the environment in which we're working better. — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLSFW652TQ4KH5W3GUMIH3Y6KHO7AVCNFSM6AAAAABE6ENF4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXG4YTQMJTGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Derrekito]

Nothing like that I can recall. The scripts just powered through. Something may have changed with how Debian uses snap.

if snap list | grep -q "^firefox"; then
    snap_ff=true
    print_err "This version of Firefox was installed as a snap package."
fi

I don't use Debian/Ubuntu or snap, but maybe the above will work?

[bengooch7]

Line 31 calls the function browser_check, which is defined on line 217.
It then calls check_for_firefox on line 220, which is defined on line 353.
It checks the system for an install of FF, then if that install is from snap. Both of these set a different flag. The flags are checked upon return to browser_check on line 231 and line 233. This is where the prompt comes. It prints the following:

********************${ERR_COLOR}[ WARNING ]${NO_COLOR}********************
            * The version of Firefox you have installed       *
            * currently was installed via snap.               *
            * This version of Firefox is not currently        *
            * compatible with the method used to enable CAC   *
            * support in browsers.                            *
            *                                                 *
            * As a work-around, this script can automatically *
            * remove the snap version and reinstall via apt.  *
            *                                                 *
            * The option to attempt to migrate all of your    *
            * personalizations will be given if you choose to *
            * replace Firefox via this script. Your Firefox   *
            * profile will be saved to a temp location, then  *
            * will overwrite the default profile once the apt *
            * version of Firefox has been installed.          *
            *                                                 *
            ********************${ERR_COLOR}[ WARNING ]${NO_COLOR}********************\n"

Backing up the user's FF profile is done in backup_ff_profile defined on line 282, then migrated on line 312`.

The check for FF pinned to the dock is done on line 454 and restored on line 474.

[bengooch7]

command -v firefox >/dev/null just returns the path of where firefox is installed, or nothing if it isn't. If the install path contains snap when running command -v firefox | grep snap >/dev/null, it means it was installed in a snap directory, which means it was MOST LIKELY installed via snap (unless some psychopath is out here manually installing packages into snap directories).

[Derrekito]

Yeah, I noticed all that. I can only speculate why the script wasn't firing off the expected logic on my intern's laptop. After some digging into forums, I figured out Snap doesn't like to allow users to add security devices. So, we proceeded with that updated knowledge. I'm fairly sure it was just Ubuntu, too, but it's possible it was PopOS.

[bengooch7]

I use Pop_OS as my daily driver and I haven't had any issues with it so far, knock on wood. Jeremy tested everything in regular Ubuntu and I tested it in Pop. We can track down the issue if you would be able to repeat the process on your coworker's machine, taking note of all messages presented to you so we can see the flow of logic. I don't believe System76 are fans of snap, and don't use it for package management. So you probably didn't get a prompt asking to replace FF because it wasn't installed via snap.

…

On Sat, Apr 20, 2024, 16:10 Derrek Landauer ***@***.***> wrote: Yeah, I noticed all that. I can only speculate why the script wasn't firing off the expected logic on my intern's laptop. After some digging into forums, I figured out Snap doesn't like to allow users to add security devices. So, we proceeded with that updated knowledge. I'm fairly sure it was just Ubuntu, too, but it's possible it was PopOS. — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLSFW423ZJEIWVWAGC3K4LY6LDR5AVCNFSM6AAAAABE6ENF4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXG43TANBZGI> . You are receiving this because you commented.Message ID: ***@***.***>

[Derrekito]

Yeah it's a System76 machine running ubuntu instead of Pop OS. I'll ask him next week to replay the script and see what happens... but I might need to do it in a virtual machine instead. I'll let you know if I learn more.

[bengooch7]

I think you already know this, but just in case you didn't, so we're all on the same page, System 76 computers come with Pop_OS installed by default because it's their proprietary flavor of Ubuntu. Though while it's Ubuntu based, it doesn't use snap, which Ubuntu started doing a couple of major versions ago. If it's still running Pop_OS, you won't see the prompt about removing the snap version of Firefox, because Pop_OS doesn't have snap. If the machine is actually running Ubuntu, you should be prompted during running of the script, to remove the snap version of Firefox and replace it with the apt version automatically.

…

On Sat, Apr 20, 2024, 16:41 Derrek Landauer ***@***.***> wrote: Yeah it's a System76 machine running ubuntu instead of Pop OS. I'll ask him next week to replay the script and see what happens... but I might need to do it in a virtual machine instead. I'll let you know if I learn more. — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLSFWZTQBIRRCQIQKAFY5LY6LHHXAVCNFSM6AAAAABE6ENF4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXG43TMNZQGM> . You are receiving this because you commented.Message ID: ***@***.***>

[Derrekito]

When configuring the specs of your System76 machine you can select to have Ubuntu installed at the factory. My intern's machine is one such laptop.

[jdjaxon]

I'd like to create one monolithic script. Perhaps distro-specific functions would be worth considering. The separate scripts are just in case you want to take development in another direction. I'm happy to keep collaborating until we have something more robust and mature.

I know the method used to get the CAC working properly is compatible with Firefox-esr (I have another machine where we did this by hand). But I didn't try on a vanilla Debian distro. Another issue worth considering is Ubuntu (which is Debian-based), which now uses a snap to install Firefox, which I've been unsuccessful at getting the CAC working. I had to uninstall the snap version and install it again from the official Mozilla repo. So, if we want this script to be more versatile, we must understand the environment more fully.

Regarding OpenSC, I had trouble getting cackey to work on Arch. I didn't try too hard and found this to be a workaround.

Here's how I see this project possibly progressing.

Our main script first checks our distribution and how the browsers are installed first. Based on that, we import distro-specific helper functions. These helper function files generally have the same named functions but are only included by the main function using that filer.

So the project hierarchy looks something similar to this

├── cac_setup.sh
└── helper
    ├── arch_helper.sh
    ├── debian_helper.sh
    └── global_helper.sh

where cac_setup.sh begins with something like

#!/bin/bash

# Capture script directory path
DIR="$( cd "$( dirname "${BASH_SOURCE[0]-$0}" )" && pwd )"

# Source universal helper functions
source $DIR/helper/global_helper.sh

# Determine the Linux distribution by checking the release information
if grep -qi "Debian" /etc/os-release; then
    # Source the Debian-specific helper script if Debian is detected
    source $DIR/helper/debian_helper.sh
elif grep -qi "Arch" /etc/os-release; then
    # Source the Arch-specific helper script if Arch Linux is detected
    source $DIR/helper/arch_helper.sh
else
    echo "Unsupported Linux distribution."
fi

# Continue installation

This way, we can make the same calls in the main script while ensuring distro-specific support.

Thoughts?

@Derrekito, I appreciate all of your contributions! I'm going to try to cover most of the major issues that have been mentioned in this thread.

As Ben previously mentioned, the original script was designed to handle the nuance of snap within Ubuntu. Recently, I ran the script on a VM with a fresh install of Ubuntu 22.04, and it did not behave as expected. I'm afraid there is some logical error in the control flow while checking for browsers. Dealing with Snap only complicates this more. I am not a fan of how Canonical makes Snap hijack the install from apt by default. The user has to take additional steps to force the installation to behave as expected when attempting to reinstall Firefox with apt. The production version of the script that rests in main was built to handle all of these issues.

In my spare time, I have been working to refactor, simplify the process, and transition to OpenSC with help from @malvidin's contributions. Currently, the OpenSC implementation is functional but requires a reboot. While trivial, I don't think a reboot should be necessary, but when running pkcs11-register in the script, it doesn't want to write to the PKCS files as expected and still requires a reboot.

On a separate note, I like the modularity of the individual files that you have implemented so far. That being said, I have kept the script monolithic to keep the footprint minimal. That's the same reason I have kept the script as Bash. I have often debated transitioning to either Ansible or Python. In the project's readme, you'll see the simplified methods for running the script: sudo bash -c "$(wget https://raw.githubusercontent.com/jdjaxon/linux_cac/main/cac_setup.sh -O -)". The intent of this is to prevent the user from having to clone the repository. Using any of those methods doesn't even copy the base script to the host machine. The only components that generate any footprint are the dependencies to run a CAC (middleware), downloading dependencies (wget), and any writing to config files. If I ignore this footprint issue, shifting to Python or Ansible is a much more modular and extensible approach.

I am also attempting to implement some CI with the automated shellcheck workflow. I am open to any suggestions you have for improving the project, such as minimizing the footprint, ignoring the footprint while increasing functionality, modularity, and extensibility, or additional automated testing.

[jdjaxon]

@Derrekito, I reconfigured the shellcheck workflow to use the -x option. That change is on main. If you would like, you can pull over that change, and the workflow should succeed for your pull request.

[Derrekito]

@Derrekito, I appreciate all of your contributions! I'm going to try to cover most of the major issues that have been mentioned in this thread.

As Ben previously mentioned, the original script was designed to handle the nuance of snap within Ubuntu. Recently, I ran the script on a VM with a fresh install of Ubuntu 22.04, and it did not behave as expected. I'm afraid there is some logical error in the control flow while checking for browsers. Dealing with Snap only complicates this more. I am not a fan of how Canonical makes Snap hijack the install from apt by default. The user has to take additional steps to force the installation to behave as expected when attempting to reinstall Firefox with apt. The production version of the script that rests in main was built to handle all of these issues.

In my spare time, I have been working to refactor, simplify the process, and transition to OpenSC with help from @malvidin's contributions. Currently, the OpenSC implementation is functional but requires a reboot. While trivial, I don't think a reboot should be necessary, but when running pkcs11-register in the script, it doesn't want to write to the PKCS files as expected and still requires a reboot.

On a separate note, I like the modularity of the individual files that you have implemented so far. That being said, I have kept the script monolithic to keep the footprint minimal. That's the same reason I have kept the script as Bash. I have often debated transitioning to either Ansible or Python. In the project's readme, you'll see the simplified methods for running the script: sudo bash -c "$(wget https://raw.githubusercontent.com/jdjaxon/linux_cac/main/cac_setup.sh -O -)". The intent of this is to prevent the user from having to clone the repository. Using any of those methods doesn't even copy the base script to the host machine. The only components that generate any footprint are the dependencies to run a CAC (middleware), downloading dependencies (wget), and any writing to config files. If I ignore this footprint issue, shifting to Python or Ansible is a much more modular and extensible approach.

I am also attempting to implement some CI with the automated shellcheck workflow. I am open to any suggestions you have for improving the project, such as minimizing the footprint, ignoring the footprint while increasing functionality, modularity, and extensibility, or additional automated testing.

I understand your point. I'm happy to try and contribute in other ways if needed. Just keep me in mind. I like the idea of running the script using one line using bash and wget. It would make things simpler. Perhaps one monolithic script is maintainable. I like to go nuts when making bash functions. It helps me understand what my script is doing a year down the road. Maybe we can have distro-specific functions with a trailing _deb or _arch and build in the logic to know which to execute. Or the main function calls something like build_for_deb and build_for_arch (I'm terrible at naming things), and those functions somewhat duplicate the install process but call the distro-specific functions. Lots of ways to go about this.

[bengooch7]

I like the idea of a monolithic script with distro specific functions, but only at the lowest possible level for each distro. That is to say: if the process for Distro_A and Distro_B are nearly identical over the course of a 500 line script with the exception of lines 202-208 and 411-423, those two sections of code with get distro specific functions, and the remainder of the script would not need to be duplicated. I also really strived to keep the whole "You're FF is crappy snap, do you want to fix that?" Section as simple and user-friendly, guided, if you will, as much as possible. The more of the heavy lifting the script can do for the end user, the more valuable it becomes.

…

On Fri, Apr 26, 2024, 15:18 Derrek Landauer ***@***.***> wrote: I'd like to create one monolithic script. Perhaps distro-specific functions would be worth considering. The separate scripts are just in case you want to take development in another direction. I'm happy to keep collaborating until we have something more robust and mature. I know the method used to get the CAC working properly is compatible with Firefox-esr (I have another machine where we did this by hand). But I didn't try on a vanilla Debian distro. Another issue worth considering is Ubuntu (which is Debian-based), which now uses a snap to install Firefox, which I've been unsuccessful at getting the CAC working. I had to uninstall the snap version and install it again from the official Mozilla repo. So, if we want this script to be more versatile, we must understand the environment more fully. Regarding OpenSC, I had trouble getting cackey to work on Arch. I didn't try too hard and found this to be a workaround. Here's how I see this project possibly progressing. Our main script first checks our distribution and how the browsers are installed first. Based on that, we import distro-specific helper functions. These helper function files generally have the same named functions but are only included by the main function using that filer. So the project hierarchy looks something similar to this ├── cac_setup.sh └── helper ├── arch_helper.sh ├── debian_helper.sh └── global_helper.sh where cac_setup.sh begins with something like #!/bin/bash # Capture script directory path DIR="$( cd "$( dirname "${BASH_SOURCE[0]-$0}" )" && pwd )" # Source universal helper functionssource $DIR/helper/global_helper.sh # Determine the Linux distribution by checking the release informationif grep -qi "Debian" /etc/os-release; then # Source the Debian-specific helper script if Debian is detected source $DIR/helper/debian_helper.shelif grep -qi "Arch" /etc/os-release; then # Source the Arch-specific helper script if Arch Linux is detected source $DIR/helper/arch_helper.shelse echo "Unsupported Linux distribution."fi # Continue installation This way, we can make the same calls in the main script while ensuring distro-specific support. Thoughts? @Derrekito <https://github.com/Derrekito>, I appreciate all of your contributions! I'm going to try to cover most of the major issues that have been mentioned in this thread. As Ben previously mentioned, the original script was designed to handle the nuance of snap within Ubuntu. Recently, I ran the script on a VM with a fresh install of Ubuntu 22.04, and it did not behave as expected. I'm afraid there is some logical error in the control flow while checking for browsers. Dealing with Snap only complicates this more. I am not a fan of how Canonical makes Snap hijack the install from apt by default. The user has to take additional steps to *force* the installation to behave as expected when attempting to reinstall Firefox with apt. The production version of the script that rests in main was built to handle all of these issues. In my spare time, I have been working to refactor, simplify the process, and transition to OpenSC with help from @malvidin <https://github.com/malvidin>'s contributions. Currently, the OpenSC implementation is functional but requires a reboot. While trivial, I don't think a reboot should be necessary, but when running pkcs11-register in the script, it doesn't want to write to the PKCS files as expected and still requires a reboot. On a separate note, I like the modularity of the individual files that you have implemented so far. That being said, I have kept the script monolithic to keep the footprint minimal. That's the same reason I have kept the script as Bash. I have often debated transitioning to either Ansible or Python. In the project's readme, you'll see the simplified methods for running the script: sudo bash -c "$(wget https://raw.githubusercontent.com/jdjaxon/linux_cac/main/cac_setup.sh -O -)". The intent of this is to prevent the user from having to clone the repository. Using any of those methods doesn't even copy the base script to the host machine. The only components that generate any footprint are the dependencies to run a CAC (middleware), downloading dependencies (wget), and any writing to config files. If I ignore this footprint issue, shifting to Python or Ansible is a much more modular and extensible approach. I am also attempting to implement some CI with the automated shellcheck workflow. I am open to any suggestions you have for improving the project, such as minimizing the footprint, ignoring the footprint while increasing functionality, modularity, and extensibility, or additional automated testing. I understand your point. I'm happy to try and contribute in other ways if needed. Just keep me in mind. I like the idea of running the script using one line using bash and wget. It would make things simpler. Perhaps one monolithic script is maintainable. I like to go nuts when making bash functions. It helps me understand what my script is doing a year down the road. Maybe we can have distro-specific functions with a trailing _deb or _arch and build in the logic to know which to execute. Or the main function calls something like build_for_deb and build_for_arch` (I'm terrible at naming things), and those functions somewhat duplicate the install process but call the distro-specific functions. Lots of ways to go about this. — Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLSFW3D5NMQAUFE5ZE7C7DY7KSBVAVCNFSM6AAAAABE6ENF4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZZHE4DSNBRGU> . You are receiving this because you commented.Message ID: ***@***.***>