Thursday, April 30, 2020

Google Chrome Asks Password to Unlock Login Keyring - A BASH Scripting Tutorial

Should you be using Chrome, it seems to have a "flaw" where it asks you for a password along with the follwing error message: "Enter Password to Unlock Your Login Keyring". A solution for how to overcome that "flaw" is located here:
Google Chrome Asks Password to Unlock Login Keyring. This fix, however, is temporary from the perspective that whenever Chrome issues an update, the new version wipes out the fix. After doing this manually, several times, I decided to create a BASH script to automate the installation of the "fix".

As is usual there were a number of unexpected problems. I also wanted a script that was a bit more than a simple dumb one liner as a learning experience.
  1. Non-standard ASCII characters. The first problem faced was getting the correct line identified for editing. Seems that the character string "%U" in the Chrome file cannot be identified by using the expected "%U".  The regex solution was to use three "." to represent the intervening space and the the "%U".
  2. Unique string. The string "Exec=/usr/bin/google-chrome-stable" appears three times in the file. Fortunately being able to use the three "." addressed that problem by making that string unique.
  3. Verifying that the string to be modified is unique. Technically, the code for doing that was not really that necessary, but then I was doing this to make the code a bit smarter.
  4. Has the "fix" already been applied? Technically, the code for doing that was not really that necessary, but then I was doing this to make the code a bit smarter.
  5. How to actually modify the line that needed to be changed. At first, I was considering a process of concatenating strings. But as I researched the issue, the simplest approach appeared to be to a) identify the line number that had to be changed and then b) overwrite that line.
  6. Escaping Special Characters. This proved to be a major stumbling block. What happened is that I did not recognize that the "\" character had to be escaped with "\/". After doing a bunch of internet searching it finally dawned on me that the "/" was sort-of a special character in that it was a SED delimiter!!! As such it needed to be escaped. 
  7.  If Statement. I did not attempt to use nested if statements. Consequently the program progressive from one if statement to the next and fails if any one of them do.

Code Below.
# Google Chrome Asks Password to Unlock Login Keyring
# This script must be run using sudo. "sudo bash"
# April 28, 2020
# Check how to use regex in Linux
# ^ needed to limit search to string at begging of line.
# $ End of line anchor
# . Any one intervening characters
# Note the %U in the string "Exec=/usr/bin/google-chrome-stable %U". Does not appear to be normal ASCII characters
# Substituting ... for the space plus %U
# The / need to be escaped with \ result -> \/
# Exec=/usr/bin/google-chrome-stable --password-store=basic %U
string_new='Exec=\/usr\/bin\/google-chrome-stable --password-store=basic %U'
# Move to the Directory the Chrome file is located in.
cd ${chrome_dir}

# Check if file exists
if [ -f ${chrome_filename} ]
        printf "\nFile Exists"
        printf "\nFile Does NOT Exist. Is Chrome installed? Program terminated\n"
        exit 1

# Verify whether google-chrome.desktop has or has not been already inserted
if grep -qw ${string_to_insert} ${chrome_filename}
        printf "\n${string_to_insert} string found. Nothing needs to be done. Already fixed.\n"
        exit 1

# Check if there is a unique occurrence of the string-to-find.
num_found=$(grep -c  ${string_to_find} ${chrome_filename})
if [ $num_found -eq 1 ]
        printf "\nUnique occurance found.\n"
        line_number=$(grep -n  ${string_to_find} ${chrome_filename} |  cut -f1 -d: )
        printf "Line Number: ${line_number}\n"
        printf "\nFAILED. A total of ${num_found} occurrence were found. Must have only one unique occurrence. Program terminated.\n"
        exit 1

# Make Modification to file
sed -i "${line_number}s/.*/${string_new}/" "${chrome_filename}"
    if [ $? -eq 0 ]
            echo "Success. Correction Made."
            echo "FAILED to update"


Wednesday, April 15, 2020

An Unexpected Consequence of the COVID-19 Pandemic

Black Swan events, such as the COVID-19, have numerous unexpected consequences. One such observation, a shortage of COBOL programmers. There have been a series of recent newspaper articles concerning this shortage, now implying that this shortage is a crises. Actually, this shortage has been widely known for many years; but because we were not suffering from a black swan event at the time, the issue was largely ignored.

What captured my attention, was the Verge COVID-19 related article: "Unemployment checks are being held up by a coding language almost nobody knows". In that article, the vacuous statement is made: "States have been starved of modernization funding for years". 

Regretfully, "starving" programs with little public visibility is what governments do, as there is minimal interest in helping them until there is a crisis. This is similar to what happened to the US Army Corps of Engineers with its levee maintenance programs. Funds (over the years) were reallocated to other (manufactured) "crises" that would provide government leaders with media coverage and high visibility. That was until, Hurricane Katrina occurred. Then the hysterical hyperbolic finger-pointing began, demanding to know why the allocated funds "disappeared".

The Verge article goes on to whimsically state: "Without additional funding from the federal government, it’s difficult for states to modernize their COBOL code and invest in hardware that can withstand the mounting number of unemployment requests they’re receiving this year.". Missing from the Verge's article is an acknowledgement that it is the obligation of state governors to provide adequate funding for state programs, such as maintaining COBOL dependent systems. Consequently, the Verge should be pointing the finger-of-blame at the state governors for not providing adequate resources.

Monday, January 13, 2020

Bash Script Runs From Terminal But Fails When Run From Anacrontab

The quick answer: Do not use an environmental variable in a bash script run from either cron or anacrontab.

I was developing a bash script to use tar to backup my files. In researching this, I ran across using the Linux environmental variable $SECONDS. Seemed pretty nifty as I could then get the elapsed time for the operation of the backup program.  My program worked well, as expected, when executed from the terminal, but failed when executed by anacrontab. In researching how to solve this problem, I ran across an old post that stated "If you run a script from cron make sure the script doesn't use any environment variables. Those variables are present when you are logged in as user X, but are not present when running from cron." This immediately  answered the question.

I was surprised though, at the number of posts asking for advise on how to resolve this type of problem but who did not not receive the answer above.

 I solved this issue by using the date command to set the start and end times. Then subtracting the values to get the elapsed time for the backup operation.
Also, I am sure that there are ways to use an environmental variable in either cron or anacrontab, but I did not want to delve into the issue further.

Saturday, November 23, 2019

Can't Access a Windows 10 Share From a Linux Computer Using Samba

I'm currently using Linux (Ubuntu 16.04) as my principle operating system. I also have one dual boot computer that can boot into Windows 10. Over the years, upgrades to both Linux and Windows have resulted in an inability to view shares and/or transfer between Linux and Windows. I've pretty much stamped-out any issues with accessing the computers running Linux from my computers when using Windows 10. However, on this last round of upgrades, I was unable to login to the computer operating under Windows 10 from my Linux computer. I was able to easily transfer files from the computer operating Windows to to the Linux computers. Today, I had some free time for looking into this issue. I believe that I have resolved it.
The solution is to set one of the Local Computer Policies to "Guest Only". See the image below. This solution found through trial and error. Note the line highlighted in blue.

 Note the text below (emphasis added):
"This security setting determines how network logons that use local accounts are authenticated. If this setting is set to Classic, network logons that use local account credentials authenticate by using those credentials. The Classic model allows fine control over access to resources. By using the Classic model, you can grant different types of access to different users for the same resource.
If this setting is set to Guest only, network logons that use local accounts are automatically mapped to the Guest account. By using the Guest model, you can have all users treated equally. All users authenticate as Guest, and they all receive the same level of access to a given resource, which can be either Read-only or Modify.

Default on domain computers: Classic.
Default on stand-alone computers: Guest only"
I do not have a local account credential (in short, no password). Once I switched "Network access: Sharing and security model for local account" to "Guest only", I was able to login to my computer running Windows 10.

Related to this is the fact that Microsoft depreciated SMBv1. This was not an issue related to my current post, but was an issue a while back, so I am posting the solution for how to restore  SMBv1. The following post by Microsoft was a useless dead-end, but it does provide some gobbledygook context. SMBv1 is not installed by default in Windows 10 Fall Creators Update and Windows Server, version 1709 and later versions.
The following post provides a solution on how to reactivate SMBv1 so that your Linux computer can access Samba shares on a Windows 10 computer. How to access files on network devices using SMBv1 on Windows 10.