Jump to content
Sunday Monday Tuesday Wednesday Thursday Friday Saturday
       
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
  • Latest Blog Posts

  • Blog Entries

    • By rev.dennis in K8 Strong the Jouney
         0
      We tried so many mattresses.  Donating our old mattress that isn't worn out to someone who needs it.
      Donation Centers:
      (Salvation Army) - www.satruck.org (Goodwill) - http://www.goodwill.org/ (Donation Town) - http://www.donationtown.org/donation-pick-up.html (Habitat for Humanity) - http://www.habitat.org/restores (Bye Bye Mattress Recycling) - www.byebyemattress.com  
    • By rev.dennis in Linux Help Blog
         0
      This has been a straight up nightmare.  My CentOS 7 server has been updating just fine via yum through our proxy and all of a sudden it stopped working.  This blog is some troubleshooting I've done to try and figure out the issue.
      FIRST, validate your repos are correct.  This is what I have on my server
      /etc/yum.repos.d/
      -rw-r--r-- 1 root root  191 Sep 15  2015 endpoint.repo
      -rw-r--r-- 1 root root  152 May 22  2018 Tuleap.repo
      -rw-r--r-- 1 root root 1062 Jun 19  2018 rpmfusion-free-updates-testing.repo
      -rw-r--r-- 1 root root 1002 Jun 19  2018 rpmfusion-free-updates.repo
      -rw-r--r-- 1 root root  159 Aug  1  2018 cwp.repo
      -rw-r--r-- 1 root root  139 Aug  1  2018 mariadb.repo
      -rw-r--r-- 1 root root    0 Aug 16  2018 openproject-ce.repo
      -rw-r--r-- 1 root root  971 Oct 29  2018 CentOS-SCLo-scl-rh.repo.OLD
      -rw-r--r-- 1 root root  998 Dec 11  2018 CentOS-SCLo-scl.repo.OLD
      -rw-r--r-- 1 root root  633 Oct  7  2019 zabbix.repo
      -rw-r--r-- 1 root root  750 Mar 18  2020 remi-safe.repo.rpmsave
      -rw-r--r-- 1 root root  228 Mar 18  2020 webmin.repo
      -rw-r--r-- 1 root root 1062 Apr 24  2020 epel.repo
      -rw-r--r-- 1 root root  750 Aug 17  2020 remi-safe.repo
      -rw-r--r-- 1 root root 2605 Aug 17  2020 remi.repo
      -rw-r--r-- 1 root root 1314 Aug 17  2020 remi-php80.repo
      -rw-r--r-- 1 root root 1314 Aug 17  2020 remi-php74.repo
      -rw-r--r-- 1 root root 1314 Aug 17  2020 remi-php73.repo
      -rw-r--r-- 1 root root 1314 Aug 17  2020 remi-php71.repo
      -rw-r--r-- 1 root root 1314 Aug 17  2020 remi-php70.repo
      -rw-r--r-- 1 root root  456 Aug 17  2020 remi-php54.repo
      -rw-r--r-- 1 root root  855 Aug 17  2020 remi-modular.repo
      -rw-r--r-- 1 root root  446 Aug 17  2020 remi-glpi94.repo
      -rw-r--r-- 1 root root  446 Aug 17  2020 remi-glpi93.repo
      -rw-r--r-- 1 root root  446 Aug 17  2020 remi-glpi92.repo
      -rw-r--r-- 1 root root  446 Aug 17  2020 remi-glpi91.repo
      -rw-r--r-- 1 root root  616 Oct 23 10:53 CentOS-x86_64-kernel.repo
      -rw-r--r-- 1 root root 8515 Oct 23 10:53 CentOS-Vault.repo
      -rw-r--r-- 1 root root 1331 Oct 23 10:53 CentOS-Sources.repo
      -rw-r--r-- 1 root root  630 Oct 23 10:53 CentOS-Media.repo
      -rw-r--r-- 1 root root  314 Oct 23 10:53 CentOS-fasttrack.repo
      -rw-r--r-- 1 root root  649 Oct 23 10:53 CentOS-Debuginfo.repo
      -rw-r--r-- 1 root root 1309 Oct 23 10:53 CentOS-CR.repo
      -rw-r--r-- 1 root root 1149 Oct 31 16:33 epel-testing.repo
      -rw-r--r-- 1 root root 1314 Nov  3 17:50 remi-php72.repo
      -rw-r--r-- 1 root root 1862 Feb  4 11:54 CentOS-Base.repo.OLD
      -rw-r--r-- 1 root root 1062 Feb  4 15:50 epel.repo.OLD
      -rw-r--r-- 1 root root 1501 Feb 26 12:14 CentOS-Base.repo
      I built a brand new CentOS 7 2019 version and this is what I have
       
      yum.repos.d.tar.gz
    • By rev.dennis in K8 Strong the Jouney
         0
      So Kate received a phone call from her onacologist Dr. Yang mentioning that her Bone Marrow Biopsy and MRD test have come back negative so not finding any sign of cancer but he is still concerned why Kate's body isn't healing.  Her platelets are not increasing as they should which is making it difficult to continue the necessary aggressive treatment keeping the cancer dead and gone.  He has requested Kate talk to a bone marrow transplant representative to discuss options.
      Obviously this has Kate very scared and nervous since finding a bone marrow match is very very difficult since many people don't want to go through the pain but roughly 20 days of pain to donate bone marrow could and does save someone's life.  Unfortunately the cut off for donating bone marrow is the age of 44.
      PLEASE PLEASE Consider donating bone marrow and save someone's life.  Check out the process by clicking here
      If you are between the ages of 18 and 44 patients especially need you (some like Kate or even Kate herself). Research shows that cells from younger donors lead to more successful transplants. Doctors request donors in the 18-44 age group 86% of the time for successful transplant.
      BE A HERO to someone who needs you save their life.  Only costs to you is your time and possibly 20 days of discomfort.
      Learn more at BeTheMatch.org
      Finding a match is only part of the battle, then you have the cost.  A 2012 study that examined the overall costs of bone marrow transplantation including donor search and costs during the first year post-transplantation found the overall cost to be between $35,000-$780,000.
    • By rev.dennis in AMERICAS
         0
      This map shows where Anguilla is 

    • By wildweaselmi in Linux Help Blog
         1
      In the environment I work in we have multiple firewalls in a path so the likely of your traffic being blocked is high.  Most of us use to troubleshoot using telnet which has many many flaws and not a great method of testing but it was all we had.
      Here is an example of testing using telnet
      telnet 10.11.24.11:80 telnet: 10.11.24.11:80: Name or service not known 10.11.24.11:80: Unknown host The telnet results don't really give you anything to tell you if its successful or not. 
      Then I discovered at a young age the power of nmap (which is probably why it was quickly blocked in most companys)
      Here is an example of testing using nmap
      nmap -p 80 10.11.24.11 Starting Nmap 6.40 ( http://nmap.org ) at 2019-07-10 10:58 EDT Nmap scan report for wildweaselmi.thezah.com (10.11.24.11) Host is up (0.000053s latency). PORT   STATE SERVICE 80/tcp open  http Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds Just so you can see what it looks like to see a closed port
      nmap -p 443 10.11.24.11 Starting Nmap 6.40 ( http://nmap.org ) at 2019-07-10 11:04 EDT Nmap scan report for wildweaselmi.thezah.com (10.11.24.11) Host is up (0.000047s latency). PORT    STATE  SERVICE 443/tcp closed https Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds nmap is super quick and very easy to use to get accurate results but it was quickly blocked by corporate security and is no longer an acceptable tool.
       
      In researching I discovered what most people use which is netcat.
      Here is an example of the same test using netcat
      nc -zv 10.11.24.11 80 Connection to 10.11.24.11 80 port [tcp/http] succeeded! Its very clear that port 80 is open on 10.11.24.11
      And for clarity sake, here is an example testing a closed port using netcat
      nc -zv 10.11.24.11 443 nc: connect to 10.11.24.11 port 443 (tcp) failed: Connection refused Yet again, its very clear that port 443 is not open on 10.11.24.11 or its being blocked along the path by a firewall or some other device.
      As with just about any corporation, you find tools that work and they get taken away.  Our company is now blocking the use of netcat due to security risks associated with the tool but not offering any other tool as a replacement.
       
      Now I can use bash as a testing tool and here is that example
      cat < /dev/tcp/127.0.0.1/22 SSH-2.0-OpenSSH_7.7 here is a test using bash for the successful connection shown above. It just comes back to the command line with no messages which means success
      cat < /dev/tcp/10.11.24.11/80 Here is the other test we did above with netcat that failed so you can see the message bash will show.
      cat < /dev/tcp/10.11.24.11/443 -bash: connect: Connection refused -bash: /dev/tcp/10.11.24.11/443: Connection refused NOTE: using bash is very slow and not always reliable but it appears to be more reliable than telnet but not as good as netcat
       
      I'm having to now test using tcpdump which is a very very painful way for me to test but security doesn't give a dang about how easy or difficult it is for you or me.
      As a test scenario I can open a port up on a destination box using netcat while we still have it by running
      nc -l 5678 Now on my source box I'll confirm that 5678 is open for testing
      nc -zv 10.11.24.11 5678 Before we just jump into troubleshooting connection issues with tcpdump its important to understand the three way handshake needed for communication (SYN, SYN/ACK, ACK)

      As long as the ports your client are trying to communicate are turned on and listening on the server its very easy and not complicated.
      Below you will see two examples of the above. Client being 10.11.24.12 and Server being 10.11.24.11
      First tcpdump is capturing the open port 80 on the server.  You can see the entire SYN, SYN/ACK, ACK cycle in this successful communication.

      Now let's look at a scenario where the port is just not turned on (or listening) on the server.  In this case 10.11.24.11 does not have 443 on so what do we capture if we attempt to communicate to that port.

      You can see you don't have the complete 3 way handshake. You see the SYN coming from the client but you don't get a SYN/ACK back but instead a RST/ACK from the server telling you that the port isn't listening.
      Now let's try the same test but to a different server that is behind a firewall (10.47.208.46) using the same client (10.11.24.12).
      First you can see a success capture going through the firewall over port 443

      Now here is a capture of the same client to the same server over 9300 which is on the server and listening which you can confirm by logging onto the server and running a quick netstat command
      netstat -anp | grep "9300" Now we perform a capture and see the communication doesn't get any further than a SYN, RST/ACK (no difference than above without a Firewall)

      Hope this helps you.
       
       
×
×
  • Create New...