Producing a file C.txt that contains common lines between A.txt B.txt using grep

Problem

You have two files (A.txt, B.txt) that contain records (one line each), and you want to find out the common lines between the two.

For example you have the following two files.

A.txt

one
two
three

and B.txt

two
six
seven

and you want to find or produce a new file (C.txt) that contains only the common record (two) from the two files.

Solution

You can use grep with the -Fx options like

grep -Fxf A.txt B.txt > C.txt

that will produce file C.txt that contains the common line (two) from the two files.

The options for grep have the following meaning:

  • -F: Interpret the pattern as a list of fixed strings (instead of regular expressions).
  • -x: Only match whole lines.
  • -f fileA.txt: Read the patterns from fileA.txt.

Changing mail sending from command line from mail(x) to s-nail

Problem

It seems that the default email client in Fedora 40 is s-nail instead of mailx in Fedora 39, and trying to send an email from the command line does not work anymore.

Solution

The two changes required in order for the command to work with s-nail are:

  • Use spaces instead of commas in the recipients, and/or in the cc_recipients lists
  • When you use attachments (-a flag) and cc_recipients (-c flag), the -a flag should be before the -c flag, otherwise:
s-nail: -a is an invalid alias name

So the full command can be like the following:

echo $body | mail -s "Reports for $yesterday" -a $report_path_a -a $report_path_b -c $cc_recipients $recipients

Key is stored in legacy trusted.gpg keyring

As described in the post [here](https://itsfoss.com/key-is-stored-in-legacy-trusted-gpg/) you would need to export the key to its own file under the trusted.gpg.d directory.

So for example if the warning is for something like forticlient, first find the key using sudo apt-key gpg list and then taking the last eight characters and removing the space, export the key to its file (ie forticlient.gpg)

sudo apt-key export 5E54716D | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/forticlient.gpg 

PostgreSQL upgrading from 9.6 to 15.3 has authentication failed (PG::ConnectionBad)

After upgrading a PostgreSQL instance from version 9.6 to the currently latest version 15.3, your application cannot connect to the server, giving an authentication error even if the user/password used is still the same.

This seems to be the result of a change in the method used in the pg_hba.conf file.

Version 9.6 uses md5 but version 15.3 uses scram-sha-256

Changing this in the file pg_hba.conf file from scram-sha-256 to md5 and reloading the configuration file from inside the database with select pg_reload_conf(); , results in the application being able to connect to the database server again.

Update: It is possible to use the recommended scram-sha-256 hash, by doing the following:

  • Uncomment the line with #password_encryption = scram-sha-256 # scram-sha-256 or md5 in file /var/lib/postgresql/data/pgdata/postgresql.conf
  • reload the configuration in the database select pg_reload_conf();
  • recreate the password with the new encryption production=# alter user user_name with password 'password';

failed to create fsnotify watcher: too many open files

This is quite possibly caused by one of the limits set too low. It is common when using promtail (with Loki for example) to tail log files.

One of the ways to get over this is to increase the value (in this example max_user_instances) either for the session or by making the change permanent by adding to a file (/etc/sysctl.conf).

For testing and doing it for the session, login to the affected server and do the following

ubuntu@server:~$ cat /proc/sys/fs/inotify/max_user_instances 
128
ubuntu@server:~$ sudo sysctl fs.inotify.max_user_instances=8192
fs.inotify.max_user_instances = 8192
ubuntu@server:~$ cat /proc/sys/fs/inotify/max_user_instances 
8192