Archy's Blog

OEMs can sometimes ship very flakey RPMs when it comes to installing some servicing software and they won't install correctly. I've recently had this experience on a centos host running some OEM-Specific software. First, inspect the installer script for the rpm. Usually, it's fairly obvious why any error is returned: [root@server ~]# rpm -qp --scripts RepServer-2.01.03.x86_64.rpm | less In my case, the script was failing due to some specific versions of the libcurl, libcrypto and libssl libraries not being present. So, ln to the rescue? [root@server ~]# ln -s /usr/lib64/libssl.so.1.1.1g /usr/lib64/libssl.so.10 [root@server ~]# ln -s /usr/lib64/libssl.so.1.1.1g /usr/lib64/libssl.so.1.0.1e [root@server ~]# ln -s /usr/lib64/libcrypto.so.1.1.1g /usr/lib64/libcrypto.so.10 [root@server ~]# ln -s /usr/lib64/libcrypto.so.1.1.1g /usr/lib64/libcrypto.so.1.0.1e [root@server ~]# ln -s /usr/lib64/libcurl.so.4.5.0 /usr/lib64/libcurl.so.4.1.1 Now, let's try to instal...

A neat little snippet when migrating datasets between servers or creating archives to remote servers when disk space is limited. Here are some examples I've used extensively when migrating some RHEL7 Servers to RHEL8: Creating archive locally and push to remote server: [root@kvm ~]# tar -cvpJf - /srv/kvm/vm-images | ssh root@nas.archyslife.lan 'cat > /var/backup/vm-images.tar.xz' Create archive remotely and pull to local server: [root@nas ~]# ssh archy@kvm.archyslife.lan 'tar -cvpJf - /srv/kvm/vm-images' > /var/backup/vm-images.tar.xz Pull archive from remote server and extract locally: [archy@kvm ~]$ ssh archy@nas.archyslife.lan 'cat /var/backup/vm-images.tar.xz' | tar -xvJf - -C / Push archive from local server to  [archy@nas ~]$ cat /var/backup/vm-images.tar.xz | ssh archy@kvm.archyslife.lan 'tar -xvpJf - -C /' Feel free to comment and / or suggest a topic.

With tmux you can easily share a session between mutliple users. This is very handy when debugging a problem for example or 'working with 4 eyes' on something. In order to do that, first launch tmux with specifying a socket (-S) and give the session a name: [root@server ~]# tmux -S /tmp/shared new -s shared_session In order to make it so that anyone else can connect, make sure the permissions are rw for both members: [root@server ~]# chmod 666 /tmp/shared As the second user, attach to tmux specifying the socket and the session name: [archy@server ~]$ tmux -S /tmp/shared attach -t shared_session The output and input are now shared between both users. Feel free to comment and / or suggest a topic.

If there's some problem regarding any network-facing services, it can be useful to capture the traffic of the server's interfaces. A nice graphical environment for analyzing these traffic-dumps is Wireshark. First, make sure tcpdump is installed on your server: Note: yum is symlinked on CentOS 8 so this command will work. [archy@server ~]$ sudo yum -y install tcpdump Now that tcpdump is installed, you can start capturing traffic. [archy@server ~]$ sudo tcpdump -i eth0 -nn -c 10000 -Z $(whoami) -w tcpdump_$(date +%Y-%m-%d).pcapng 'dst net 172.31.10.0/24' -i the interface of the server from which to capture traffic -nn disables name resolution for ip addresses and ports -c specifies the number of packages before the capture is stopped automatically -Z specifies the user which will be the owner of the captured file -w specifies the file to which the capture should be written The last argument will be the filter expression, in my case 'dst net 172.31.10.0/24' ...

Since I use SSH relatively frequently for remote connections as well as configuration management (Ansible), I prefer to secure it as well as I can.  Securing SSH might be a topic for another day. This time I'll only go into ensuring that only selected Ciphers, MACs, and Algorithms are allowed and how to verify that changes are successful. First of all, let's build up a small inventory using nmap: [23:07:36 - archy@stealth-falcon ~]$ nmap -sV -p 22 -open 172.31.10.0/24 A brief explanation of the arguments: -sV: will probe open ports and try to determine the service's version. -p: This specifies the port or port range to scan. I'll be going for one port only. --open: This will only print out hosts where the port is actually open. Now that we know what we're working with, let's configure the Ciphers, Algorithms, and MACs to lock down ssh. Depending on the number of servers you have, I recommend using the config management tool of your choice, be it ansible, pupp...

GPG is a suite of tools for encrypting and signing messages and files. Working with it on the cli is fairly forward if you get behind it once and of course, it features completion on the command line. NOTE: This is more of a personal cheatsheet which I think might be useful for other people as well. Generate Key $ gpg --gen-key Generate Revocation Cert $ gpg --gen-revoke Export Public Keys $ gpg --export --armor archy@archyslife.lan > archy.archyslife.lan.asc Export Secret Keys $ gpg --export-secret-keys --armor archy@archyslife.lan > archy.archyslife.lan.secret Export Ownertrust $ gpg --export-ownertrust > ownertrust.txt Import Public Keys $ gpg --import archy.archyslife.lan.asc Import Secret Keys $ gpg --import archy.archyslife.lan.secret Import Ownertrust $ gpg --import-ownertrust ownertrust.txt Show fingerprint of a key $ gpg --fingerprint archy@archyslife.lan Upload a key to a keyserver $ gpg --keyserver keys.gnupg.net --send-keys archy@archysli...

When working with offsite backups and cloud storage, it's highly recommended to encrypt your data. While encryption can be done with GPG and OpenSSL, I'll be using OpenSSL in this example. First, let's create a unique random 64-character password which will be used to encrypt the files. $ < /dev/urandom tr -dc A-Z-a-z-0-9 | head -c ${1:-64} > key.txt I'd recommend to also save this key to your password manager (assuming you use one) just in case. Files can be encrypted using this syntax. $ openssl enc -e -aes256 -iter 8 -pass file:key.txt -in workingdir.tar.xz -out workingdir.tar.xz.enc -e will encrypt  -d will decrypt -aes256 is the encryption algorithm -iter 8 means 8 iterations will be done -pass file:key.txt will read the password from the file 'key.txt' -in is the file currently residing on the system that should be encrypted -out is the encrypted -in-file When working with archives, the content that is supposed to be archived can be piped to Ope...

This is more of a fun thing I've done recently to send and receive files from Windows, macOS or Linux directly without the need for a Samba or NFS share. I'll be using Linux on both ends but none of the hosts is running sshd (or rsyncd for that matter), so no scp or rsync will work. Another option is to use netcat (nc) to listen to one port and send the file from your client. On the receiving side, set up netcat to listen to a specific port and redirect the output to a file. $ nc -l -p 8443 > archive.tar.xz On the sender side, create a connection to the receiver and read the input from a file. $ nc stealth-falcon.archyslife.lan 8443 < archive.tar.xz Keep in mind that this communication is not encrypted by default but can be encrypted using these options '--ssl', '--ssl-cert' and '--ssl-key' with appropriate path arguments. Feel free to comment and / or suggest a topic.

This is fairly simple to happen to your daily workflow. If you reboot a server or disconnect your laptop from the current network (say ethernet and switch to wireless) it may occur that your ssh session is not reconnecting automatically and appears to be 'stuck'. The proper escape sequence to disconnect the client would be '~.' Here's an example: [archy@castle-bravo ~]$ ssh archy@example.archyslife.lan Last login: Sat Dec 21 18:40:04 2019 from castle-bravo.archyslife.lan [archy@example ~]$ reboot well, it's stuck ... time to disconnect Connection to example.archyslife.lan closed. [archy@castle-bravo ~]$ What happened here is that by rebooting the server the ssh-server did not have time to appropriately disconnect all sessions and so the client appears to be 'stuck'. In order to disconnect the client, I sent the escape sequence '~.' and drop to my local terminal again. Feel free to comment and / or suggest a topic....