Linux Tips, Tricks, Tutorials & Fixes

Symptom: Connection is refused when attempted to access applications that are encrypted with SSL. Error: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Diagnosis: Use SSLPoke to verify the connectivity (you will have to download SSLPoke.class using the following link: https://confluence.atlassian.com/kb/files/779355358/779355357/1/1441897666313/SSLPoke.class) # /apps/java/latest/bin/java -classpath /apps/java/latest SSLPoke <hostname> <Port> # /apps/java/latest/bin/java -classpath /apps/java/latest -Djavax.net.ssl.trustStore=/apps/java/latest/lib/security/cacerts SSLPoke <hostname> <Port> # curl -X POST -d @Test.xml https://<endpoint url> -H "Content-Type:application/xml" **add some xml code in Test.xml If the above command is showing "Successfully

Kill Hung Puppet process . kill -9 `ps -ef |grep "puppet agent: applying configurat" |grep -ve grep |awk '{print $2}'` /etc/init.d/puppet restart ps -ef |grep -i puppet | grep -v grep

In the context of a route entry, it usually means the default route. In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs.

On a Linux server, when it loses connectivity to underlying storage (even briefly), the server doesn’t typically crash. It keeps running, but switches all the storage to read-only. Most of the OS and applications are running in RAM, so you don’t necessarily see any issues right away. The main issue we see is the OS and applications hold things in the disk-write queues. When you force the reboot after the storage outage, the kernel gets out-of-whack because that disk queue couldn’t clear properly and now doesn’t match the disks. So, we have to reboot and log in with root password under maintenance mode and force a disk check on the root and app file-systems. Once that is done, the host comes back online without issue.

Recently, I came across the situation where my CentOS server was not booting and displaying Kernel panic error. I have followed the steps mentioned below to make the server online: I spawned the init as bash. This can be done by giving the following boot parameter.   Init=/bin/bash   Once we have the bash prompt we can remount the root partition in read write mode.   Mount –o remount,rw /   Then change the password:   Password root   Once the password is changed reboot the system. It will ask for the fsck and maintenance password. Enter newly changed maintenance password.

20 FTP data (File Transfer Protocol)  21 FTP (File Transfer Protocol)  22 SSH (Secure Shell)  23 Telnet  25 SMTP (Send Mail Transfer Protocol)  43 whois  53 DNS (Domain Name Service)  68 DHCP (Dynamic Host Control Protocol)  79 Finger  80 HTTP (HyperText Transfer Protocol)  110 POP3 (Post Office Protocol, version 3)  115 SFTP (Secure File Transfer Protocol)  119 NNTP (Network New Transfer Protocol)  123 NTP (Network Time Protocol)  137 NetBIOS-ns  138 NetBIOS-dgm  139 NetBIOS  143 IMAP (Internet Message Access Protocol)  161 SNMP (Simple Network Management Protocol)  194 IRC (Internet Relay Chat)  220 IMAP3 (Internet Message Access Protocol 3)  389 LDAP (Lightweight Directory Access Protocol)  443 SSL (Secure Socket Layer)  445 SMB (NetBIOS over TCP)  666 Doom  993 SIMAP (Secure Internet Message Access Protocol)  995 SPOP (Secure Post Office Protocol) 

• Find all files of a given type from current directory on down: find ./ -name "*.conf" -print • Find all user files larger than 5Mb: find /home -size +5000000c -print • Find all files owned by a user (defined by user id number. see /etc/passwd) on the system: (could take a very long time) find / -user 501 -print • Find all files created or updated in the last five minutes: (Great for finding effects of make install) find / -cmin -5 • Find all users in group 20 and change them to group 102: (execute as root) find / -group 20 -exec chown :102 {} \; • Find all suid and setgid executables: find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -ldb {} \; find / -type f -perm +6000 -ls Note: suid executable binaries are programs which switch to root privileges to perform their tasks. These are created by applying a "sticky" bit: chmod +s. These programs should be watched as they are often the first point of entry for hackers. Thus it is prud