Month: April 2023

Updating credentials to connect to a windows shared folder

We were unable to access to a sub-folder in a windows shared folder from one of the windows machines that are in different domains.

We still we can access to the windows shared folder but not navigating to the different folders in there.

The solution to this issue was to delete or cancel all the connections to that shared resource using command line in a windows command prompt:

net use \\remote-server\remote-folder /DEL

And repeat the same command for the other connections in that same resource.  You can find them running net use

When done with this task open the connection using the new credentials:

net use \\remote-server\remote-folder [PASSWORD] /USER:[DOMAIN\USERNAME]

And that should be it!

 

Good luck!

vsts agent offline on Ubuntu Server 22.04 LTS

In our in-premises Azure Devops pipelines we are adding a new agent with Ubuntu Server 22.04.

This agent was an Ubuntu Server 20.04 and was running without hiccups but new requirements came and we had to upgrade to the newer version of Ubuntu 22.04 LTS.

After upgraded, the agent went offline so let’s start the research online.

We found this discusion in github (https://github.com/microsoft/azure-pipelines-agent/issues/3834) and from there we applied the proposal workaround, at least until we upgrade the agent to a newer version supporting OpenSSL 3.0.  You can find more details in the link above.

 

wget http://security.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1f-1ubuntu2.17_amd64.deb && dpkg -i libssl1.1_1.1.1f-1ubuntu2.17_amd64.deb && rm libssl1.1_1.1.1f-1ubuntu2.17_amd64.deb

sed -i 's/openssl_conf = openssl_init/#openssl_conf = openssl_init/g' /etc/ssl/openssl.cnf

If you compare this commands with the one described there you will notice that I changed the version …16.. to …17… to make it works.

Also, it’s important to update ‘openssl.cnf’ otherwise we will get authentication errors when building.

 

Happy Building!

 

String concatenation doesn’t work in bash

CRLF vs LF (again)

This time I was pulling my hair for a weird behavior in bash when concatenating strings in a bash script.

#!/bin/bash

# Read the version numbers from the file
variable1=$(grep VERSION_MAJOR file.txt | cut -d' ' -f 2)
variable2=$(grep VERSION_MINOR file.txt | cut -d' ' -f 2)
result="${variable1}.${variable2}"

echo "${result}"

The intention of this script is to echo two concatenated strings coming from storing a command in those variables.  But echo was showing only the value or ‘variable2’.

After a couple of hours blaming bash version, OS version, and searching online I found this question/answer in stackoverflow blaming ‘carriage return’.

And then again, I remembered that this file I was trying to parse was coming from a windows environment. 

I checked with 

cat -A file.txt

and indeed it was containing the windows carriage return. 

So I removed the CRLF characters using the tool ‘dos2unix’ and after running the bash script it shows now the expected result.