Archy's Blog

I've encountered this error in a FreeIPA - AD Trust environment along with this error: "pam_sss(sshd_auth): received for user: 6 (Permission denied)" where users could log in using ssh with GSSAPIAuthentication and PubkeyAuthentication but logins with passwords were rejected. I've found that removing the dynamic-db files, clearing the cache, and restarting sssd worked for me: [root@server ~]# systemctl stop sssd.service [root@server ~]# rm -rf /var/lib/sss/db/* [root@server ~]# sss_cache -E [root@server ~]# systemctl start sssd.service I'm not really sure what exactly is causing this error but I think it might have to do with password-changes and therefore invalid caches but this is just a wild guess to the best of my knowledge. Feel free to comment and / or suggest a topic.

 I've seen this frequently now that the restore process is being killed for, from the first glance at it, no apparent reason. Checking journalctl, the problem becomes obvious: Out of memory: Killed process $PID (mongorestore) ... So the restore process requires huge amounts of memory in order to restore the Database. I've had the same problem with mongoimport and I found the solution to be either add more RAM to the machine add a large swap partition / file to the system Since RAM is probably more 'expensive' I'd suggest going with the second option and just adding another disk if necessary. In my case, the total size of the database was ~5G and after some experimenting I found out that I had to have atleast 18G of RAM available for the mongorestore / mongoimport to go through. Let's add a disk to the server on the hypervisor [root@hyv01 ~]# virsh vol-create-as --pool vm-data --name test.qcow2 --capacity 32G --format qcow2 --prealloc-metadata [root@hyv01

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

Usually, sshfp records are being generated if the host is being joined to the ipa-domain either by hand or by a provisioning workflow provided by foreman for example. If you have to regenerate them, however, they won't match and you'll get the warning that the keys don't match, rightfully so.  In order to fix this, you just need to modify the host with the current public keys and pass the '--updatedns'-option to the ipa command. First, let's make sure that all the ssh-host keys are newly generated: [root@server ~]# find /etc/ssh/ -type f -name '*ssh_host_*_key.pub' -delete [root@server ~]# ssh-keygen -A The keys won't match now and if you log out and in again, you'll get the warning I mentioned earlier. Now, let's regenerate the records. The ssh-keygen will also create a DSA key which is strongly advised against using since they're mathematically broken. So, we're just going to print out the ECDSA, ED25519, and RSA keys: [root@