Add Gzip to Plesk Server

Instructions
Login to your Plesk server.
Select the domain you wish to enable gzip for from the left hand side.
Click in Apache and nginx settings:

Down the bottom, add the following to the “Additional nginx directives” field:


gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript application/javascript text/xml application/xml application/xml+rss text/javascript image/x-icon image/bmp image/svg+xml;
gzip_vary on;

Click OK to save.
Verify with GTMetrix.com .


			

Nmap Script to Test SSL Versions and Cipher Suites

Included in NMap is a script called ssl-enum-ciphers, which will let you scan a target and list all SSL protocols and ciphers that are available on that server. You can also narrow it down by specifying a port number with the -p option.

This tool comes in handy if you’re doing a vulnerability scan and you need to make some changes to a server and you want to test those changes. This will allow you to perform a quick scan without needing to do a complete vulnerability scan.

$ nmap --script ssl-enum-ciphers -p 443 testdomain.com

Starting Nmap 7.40 ( https://nmap.org ) at 2018-01-09 12:18 CST
Nmap scan report for testdomain.com (192.99.236.66)
Host is up (0.065s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

Error 401: Unauthorized: Access is denied due to invalid credentials

When getting an error in Windows 2008 R2, Error 401: Unauthorized: Access is denied due to invalid credentials

See – https://www.codeproject.com/Answers/418802/Unauthorized-Access-is-denied-due-to-invalid-c#answer1

Specifically Solution 6 with a minor adjustment.

Right click on the folder in Explorer and choose Properties.

In Security tab add ‘IIS_IUSRS’ and ‘NETWORK SERVICE’ and give full control to both user.

Also check Authentication. Set up the Anonymous Authentication to Application Pool Identity. Check others and disable as needed.

Fix the Spectre on a CentOS/RHEL/Fedora/Oracle/Scientific Linux

How to Fix the Spectre on a CentOS/RHEL/Fedora/Oracle/Scientific Linux
For Example, CentOS 7

Type the following yum command:

# uname -r
3.10.0-693.2.2.el7.x86_64

# sudo yum update

CentOS 7 output

====================================================================================================================================================================================================
 Package                                            Arch                                  Version                                                      Repository                               Size
=====================================================================================================================================================================================================
Installing:
 kernel                                             x86_64                                3.10.0-693.11.6.el7                                          updates                                  43 M
 kernel-devel                                       x86_64                                3.10.0-693.11.6.el7                                          updates                                  14 M
Updating:
 iwl100-firmware                                    noarch                                39.31.5.1-57.el7                                             updates                                 152 k
 iwl1000-firmware                                   noarch                                1:39.31.5.1-57.el7                                           updates                                 215 k
 iwl105-firmware                                    noarch                                18.168.6.1-57.el7                                            updates                                 236 k
 iwl135-firmware                                    noarch                                18.168.6.1-57.el7                                            updates                                 245 k
 iwl2000-firmware                                   noarch                                18.168.6.1-57.el7                                            updates                                 239 k
 iwl2030-firmware                                   noarch                                18.168.6.1-57.el7                                            updates                                 248 k
 iwl3160-firmware                                   noarch                                22.0.7.0-57.el7                                              updates                                 1.5 M
 iwl3945-firmware                                   noarch                                15.32.2.9-57.el7                                             updates                                  90 k
 iwl4965-firmware                                   noarch                                228.61.2.24-57.el7                                           updates                                 103 k
 iwl5000-firmware                                   noarch                                8.83.5.1_1-57.el7                                            updates                                 296 k
 iwl5150-firmware                                   noarch                                8.24.2.2-57.el7                                              updates                                 149 k
 iwl6000-firmware                                   noarch                                9.221.4.1-57.el7                                             updates                                 169 k
 iwl6000g2a-firmware                                noarch                                17.168.5.3-57.el7                                            updates                                 312 k
 iwl6000g2b-firmware                                noarch                                17.168.5.2-57.el7                                            updates                                 312 k
 iwl6050-firmware                                   noarch                                41.28.5.1-57.el7                                             updates                                 245 k
 iwl7260-firmware                                   noarch                                22.0.7.0-57.el7                                              updates                                 1.1 M
 kernel-headers                                     x86_64                                3.10.0-693.11.6.el7                                          updates                                 6.0 M
 kernel-tools                                       x86_64                                3.10.0-693.11.6.el7                                          updates                                 5.1 M
 kernel-tools-libs                                  x86_64                                3.10.0-693.11.6.el7                                          updates                                 5.1 M
 linux-firmware                                     noarch                                20170606-57.gitc990aae.el7                                   updates                                  35 M
 microcode_ctl                                      x86_64                                2:2.1-22.2.el7                                               updates                                 1.1 M
 python-perf                                        x86_64                                3.10.0-693.11.6.el7                                          updates                                 5.1 M
Removing:
 kernel                                             x86_64                                3.10.0-514.21.1.el7                                          @updates                                148 M

Transaction Summary
=====================================================================================================================================================================================================
Install   2 Packages
Upgrade  22 Packages
Remove    1 Package

Total download size: 120 M
Is this ok [y/d/N]:

You must reboot your Linux server using shutdown/reboot command:

$ sudo reboot

$ uname -r
3.10.0-693.11.6.el7.x86_64

Verify all 3 CVEs (you must see output:

$ rpm -q --changelog kernel | egrep 'CVE-2017-5715|CVE-2017-5753|CVE-2017-5754'

[root@webhost ~]# rpm -q --changelog kernel | egrep 'CVE-2017-5715|CVE-2017-5753|CVE-2017-5754'
- [x86] spec_ctrl: Eliminate redundant FEATURE Not Present messages (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] mm/kaiser: init_tss is supposed to go in the PAGE_ALIGNED per-cpu section (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: svm: spec_ctrl at vmexit needs per-cpu areas functional (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] kaiser/mm: skip IBRS/CR3 restore when paranoid exception returns to userland (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] kaiser/mm: consider the init_mm.pgd a kaiser pgd (Andrea Arcangeli) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: Prevent unwanted speculation without IBRS (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] entry: Remove trampoline check from paranoid entry path (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] entry: Fix paranoid_exit() trampoline clobber (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] entry: Simplify trampoline stack restore code (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715 CVE-2017-5754}
- [x86] spec_ctrl: remove SPEC_CTRL_DEBUG code (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: add noibrs noibpb boot options (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] entry: Use retpoline for syscall's indirect calls (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] syscall: Clear unused extra registers on 32-bit compatible syscall entrance (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: cleanup unnecessary ptregscall_common function (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: CLEAR_EXTRA_REGS and extra regs save/restore (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] syscall: Clear unused extra registers on syscall entrance (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: rescan cpuid after a late microcode update (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: add debugfs ibrs_enabled ibpb_enabled (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: consolidate the spec control boot detection (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] KVM/spec_ctrl: allow IBRS to stay enabled in host userland (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: add debug aid to test the entry code without microcode (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: move stuff_RSB in spec_ctrl.h (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] entry: Stuff RSB for entry to kernel for non-SMEP platform (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] mm: Only set IBPB when the new thread cannot ptrace current thread (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] mm: Set IBPB upon context switch (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] idle: Disable IBRS when offlining cpu and re-enable on wakeup (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] idle: Disable IBRS entering idle and enable it on wakeup (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: implement spec ctrl C methods (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: save IBRS MSR value in save_paranoid for NMI (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] enter: Use IBRS on syscall and interrupts (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: swap rdx with rsi for nmi nesting detection (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: spec_ctrl_pcp and kaiser_enabled_pcp in same cachline (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] spec_ctrl: use per-cpu knob instead of ALTERNATIVES for ibpb and ibrs (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] enter: MACROS to set/clear IBRS and set IBPB (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] x86: add SPEC_CTRL to MSR and CPUID lists (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] svm: add MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] svm: Set IBPB when running a different VCPU (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] vmx: add MSR_IA32_SPEC_CTRL and MSR_IA32_PRED_CMD (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] vmx: Set IBPB when running a different VCPU (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [kvm] x86: clear registers on VM exit (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] kvm: pad RSB on VM transition (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] cpu/AMD: Control indirect branch predictor when SPEC_CTRL not available (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] feature: Report presence of IBPB and IBRS control (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [x86] feature: Enable the x86 feature to control Speculation (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [tools] objtool: Don't print 'call dest' warnings for ignored functions (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}
- [misc] locking/barriers: prevent speculative execution based on Coverity scan results (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [fs] udf: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [fs] prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [kernel] userns: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [scsi] qla2xxx: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [netdrv] p54: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [netdrv] carl9170: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [media] uvcvideo: prevent speculative execution (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [x86] cpu/AMD: Remove now unused definition of MFENCE_RDTSC feature (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [x86] cpu/AMD: Make the LFENCE instruction serialized (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [misc] locking/barriers: introduce new memory barrier gmb() (Josh Poimboeuf) [1519788 1519786] {CVE-2017-5753}
- [x86] mm/kaiser: Replace kaiser with kpti to sync with upstream (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add "kaiser" and "nokaiser" boot options (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map the trace idt tables in userland shadow pgd (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: fix RESTORE_CR3 crash in kaiser_stop_machine (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use stop_machine for enable/disable knob (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use atomic ops to poison/unpoison user pagetables (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use invpcid to flush the two kaiser PCID AISD (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use two PCID ASIDs optimize the TLB during enter/exit kernel (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: stop patching flush_tlb_single (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: use PCID feature to make user and kernel switches faster (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: If INVPCID is available, use it to flush global mappings (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/64: Fix reboot interaction with CR4.PCIDE (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/64: Initialize CR4.PCIDE early (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: Add a 'noinvpcid' boot option to turn off INVPCID (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: Add the 'nopcid' boot option to turn off PCID (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: validate trampoline stack (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] entry: Move SYSENTER_stack to the beginning of struct tss_struct (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: isolate the user mapped per cpu areas (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: enable kaiser in build (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: selective boot time defaults (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: handle call to xen_pv_domain() on PREEMPT_RT (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser/xen: Dynamically disable KAISER when running under Xen PV (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add Kconfig (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: avoid false positives during non-kaiser pgd updates (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: Respect disabled CPU features (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: trampoline stack comments (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: stack trampoline (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: remove paravirt clock warning (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: re-enable vsyscalls (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: allow to build KAISER with KASRL (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: allow KAISER to be enabled/disabled at runtime (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: un-poison PGDs at runtime (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add a function to check for KAISER being enabled (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add debugfs file to turn KAISER on/off at runtime (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: disable native VSYSCALL (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map virtually-addressed performance monitoring buffers (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map debug IDT tables (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add kprobes text section (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map trace interrupt entry (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map entry stack per-cpu areas (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: map dynamically-allocated LDTs (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: make sure static PGDs are 8k in size (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: allow NX poison to be set in p4d/pgd (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: unmap kernel from userspace page tables (core patch) (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: mark per-cpu data structures required for entry/exit (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: introduce user-mapped per-cpu areas (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: add cr3 switches to entry code (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: remove scratch registers (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: prepare assembly for entry/exit CR3 switching (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/kaiser: Disable global pages by default with KAISER (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: Document X86_CR4_PGE toggling behavior (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm/tlb: Make CR4-based TLB flushes more robust (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] mm: Do not set _PAGE_USER for init_mm page tables (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [x86] increase robusteness of bad_iret fixup handler (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [perf] x86/intel/uncore: Fix memory leaks on allocation failures (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [mm] userfaultfd: hugetlbfs: prevent UFFDIO_COPY to fill beyond the end of i_size (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [fs] userfaultfd: non-cooperative: fix fork use after free (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [mm] userfaultfd: hugetlbfs: remove superfluous page unlock in VM_SHARED case (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}
- [mm] fix bad rss-counter if remap_file_pages raced migration (Josh Poimboeuf) [1519800 1519801] {CVE-2017-5754}

Run the following dnf command if you are using a Fedora Linux:

# sudo dnf --refresh update kernel

OR

# sudo dnf update

Reboot the Linux box:

$ sudo reboot

Fix the Meltdown on a CentOS/RHEL/Fedora/Oracle/Scientific Linux

How to Fix the Meltdown on a CentOS/RHEL/Fedora/Oracle/Scientific Linux

Always keep backups. So backup now to an offsite location.

Note the Linux kernel version running the following command:

# uname -r

Fix the Meltdown on a CentOS/RHEL/Fedora/Oracle/Scientific Linux
Type the following yum command:

# sudo yum update

You must reboot your Linux server using shutdown/reboot command:

# sudo reboot

Run the following dnf command if you are using a Fedora Linux:

# sudo dnf --refresh update kernel

OR

# sudo dnf update

Reboot the Linux box:

# sudo reboot

Meltdown And Spectre Security Flaws

Articles and Information regarding the Meltdown And Spectre Security Flaws

Links:
https://meltdownattack.com/
https://hothardware.com/news/researchers-disclose-meltdown-and-spectre-cpu-vulnerabilities
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Patches:

VMware
https://lists.vmware.com/pipermail/security-announce/2018/000397.html
https://esxi-patches.v-front.de/ESXi-5.5.0.html#2017-09-14

How To’s
Fix the Spectre on a CentOS/RHEL/Fedora/Oracle/Scientific Linux
Fix the Meltdown on a CentOS/RHEL/Fedora/Oracle/Scientific Linux

IPV6 Error Google Email

I recently received an error when sending an email to google:


2607:f8b0:4003:0c17:0000:0000:0000:001b failed after I sent the message.
Remote host said: 550-5.7.1 [2607:5201:1110:3110:ec4:7aff:fe7d:88f3] Our system has detected that
550-5.7.1 this message does not meet IPv6 sending guidelines regarding PTR
550-5.7.1 records and authentication. Please review
550-5.7.1 https://support.google.com/mail/?p=IPv6AuthError for more information
550 5.7.1 . t203si2123379oib.437 - gsmtp

The fix is to disable IPv6 in CentOS and postfix

Resources:
https://wiki.centos.org/FAQ/CentOS6#head-d47139912868bcb9d754441ecb6a8a10d41781df

CentOS / RHEL 7 : How to disable IPv6


https://serverfault.com/questions/732187/sendmail-can-not-deliver-to-gmail-ipv6-sending-guidelines-regarding-ptr-record

For Plesk:
https://support.plesk.com/hc/en-us/articles/115002922789-How-to-disable-IPv6-addresses-on-a-Plesk-server-

Diagnosing Network Issues with MTR

On CentOS and Fedora systems you will want to issue the following commands to update repositories, upgrade installed packages, and install the MTR program:


# yum update
# yum install mtr

To test the route and connection quality of traffic to the destination host example.com, run the following command from the desired source host:


# mtr -rw example.com

Reading MTR Reports
Because MTR reports contain a wealth of information, they may be difficult to interpret at first. Consider the following example from a local connection to google.com:


$ mtr --report google.com
HOST: example                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. inner-cake                    0.0%    10    2.8   2.1   1.9   2.8   0.3
  2. outer-cake                    0.0%    10    3.2   2.6   2.4   3.2   0.3
  3. 68.85.118.13                  0.0%    10    9.8  12.2   8.7  18.2   3.0
  4. po-20-ar01.absecon.nj.panjde  0.0%    10   10.2  10.4   8.9  14.2   1.6
  5. be-30-crs01.audubon.nj.panjd  0.0%    10   10.8  12.2  10.1  16.6   1.7
  6. pos-0-12-0-0-ar01.plainfield  0.0%    10   13.4  14.6  12.6  21.6   2.6
  7. pos-0-6-0-0-cr01.newyork.ny.  0.0%    10   15.2  15.3  13.9  18.2   1.3
  8. pos-0-4-0-0-pe01.111eighthav  0.0%    10   16.5  16.2  14.5  19.3   1.3
  9. as15169-3.111eighthave.ny.ib  0.0%    10   16.0  17.1  14.2  27.7   3.9
 10. 72.14.238.232                 0.0%    10   19.1  22.0  13.9  43.3  11.1
 11. 209.85.241.148                0.0%    10   15.1  16.2  14.8  20.2   1.6
 12. lga15s02-in-f104.1e100.net    0.0%    10   15.6  16.9  15.2  20.6   1.7


The command issued to generate the report is mtr –report google.com. This uses the report option which sends 10 packets to the host google.com and generates the output. Without the –report option, mtr will run continuously in an interactive environment. The interactive mode reflects current round trip times to each host. In most cases, the –report mode provides sufficient data in a useful format.

Following the command, MTR generates its output. Typically, MTR reports take a few seconds to generate. Do not be alarmed if it takes a few moments to complete the report. The report is comprised of a series of hops (12 in this case). “Hops” are the nodes, or routers, on the Internet that packets transverse to get to their destination. In the above example, packets travel through the “inner-cake” and “outer-cake” local network devices and then to “68.85.118.13”” followed by a series of named hosts. The names for the hosts are determined by reverse DNS lookups. If you want to omit the rDNS lookups you can use the –no-dns option, which would produce output similar to the following:


% mtr --no-dns --report google.com
HOST: deleuze                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                   0.0%    10    2.2   2.2   2.0   2.7   0.2
  2. 68.85.118.13                  0.0%    10    8.6  11.0   8.4  17.8   3.0
  3. 68.86.210.126                 0.0%    10    9.1  12.1   8.5  24.3   5.2
  4. 68.86.208.22                  0.0%    10   12.2  15.1  11.7  23.4   4.4
  5. 68.85.192.86                  0.0%    10   17.2  14.8  13.2  17.2   1.3
  6. 68.86.90.25                   0.0%    10   14.2  16.4  14.2  20.3   1.9
  7. 68.86.86.194                  0.0%    10   17.6  16.8  15.5  18.1   0.9
  8. 75.149.230.194                0.0%    10   15.0  20.1  15.0  33.8   5.6
  9. 72.14.238.232                 0.0%    10   15.6  18.7  14.1  32.8   5.9
 10. 209.85.241.148                0.0%    10   16.3  16.9  14.7  21.2   2.2
 11. 66.249.91.104                 0.0%    10   22.2  18.6  14.2  36.0   6.5

As a matter of best practice when discussing MTR reports, it is best to refer to any issue in terms of its hop number. Beyond simply seeing the path between servers that packets take to reach their host, MTR provides valuable statistics regarding the durability of that connection in the seven columns that follow. The Loss% column shows the percentage of packet loss at each hop. The Snt column counts the number of packets sent. The –report option will send 10 packets unless specified with –report-cycles=[number-of-packets], where [number-of-packets] represents the total number of packets that you want to send to the remote host.

The next four columns Last, Avg, Best, and Wrst are all measurements of latency in milliseconds (e.g. ms). Last is the latency of the last packet sent, Avg is average latency of all packets, while Best and Wrst display the best (shortest) and worst (longest) round trip time for a packet to this host. In most cases, the average (Avg) column should be the focus of your attention.

The final column, StDev, provides the standard deviation of the latencies to each host. The higher the standard deviation, the greater the difference is between measurements of latency. Standard deviation allows you to assess if the mean (average) provided represents the true center of the data set, or has been skewed by some sort of phenomena or measurement error. For example, if the standard deviation is high, the latency measurements were inconsistent. While some could have been low (i.e. 25ms), others may have been very high (i.e. 350ms). After averaging the latencies of the 10 packets sent, the average looks normal but may in fact not represent the data very well. If the standard deviation is high, take a look at the best and worst latency measurements to make sure the average is a good representation of the actual latency and not the result of too much fluctuation.

In most circumstances, you may think of the MTR output in three major sections. Depending on configurations, the first 2 or 3 hops often represent the source host’s ISP, while the last 2 or 3 hops represent the destination host’s ISP. The hops in between are the routers the packet traverses to reach its destination.

For example if MTR is run from your home PC to your Linode, the first 2 or 3 hops belong to your ISP. The last 3 hops belong to the datacenter where your Linode resides. Any hops in the middle are intermediate hops. When running MTR locally, if you see an abnormality in the first few hops near the source, contact your local service provider or investigate your local networking configuration. Conversely, if you see abnormalities near the destination you may want to contact the operator of the destination server or network support for that machine (e.g. Linode). Unfortunately, in cases where there are problems on the intermediate hops, both service providers will have limited ability to address those glitches.

Analyzing MTR Reports
Verifying Packet Loss
When analyzing MTR output, you are looking for two things: loss and latency. First, let’s talk about loss. If you see a percentage of loss at any particular hop, that may be an indication that there is a problem with that particular router. However, it is common practice among some service providers to rate limit the ICMP traffic that MTR uses. This can give the illusion of packet loss when there is in fact no loss. To determine if the loss you’re seeing is real or due to rate limiting, take a look at the subsequent hop. If that hop shows a loss of 0.0%, then you can be pretty sure that you’re seeing ICMP rate limiting and not actual loss. See below for an example:


root@localhost:~# mtr --report www.google.com
HOST: example               Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 63.247.64.157                50.0%    10    0.4   1.0   0.4   6.1   1.8
3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

In this case, the loss reported between hops 1 and 2 is likely due to rate limiting on the second hop. Although traffic to the remaining eight hops all touch the second hop, there is no packet loss. If the loss continues for more than one hop, than it is possible that there is some packet loss or routing issues. Remember that rate limiting and loss can happen concurrently. In this case, take the lowest percentage of loss in a sequence as the actual loss. For instance, consider the following output:


root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 63.247.74.43                   0.0%    10    0.3   0.6   0.3   1.2   0.3
2. 63.247.64.157                  0.0%    10    0.4   1.0   0.4   6.1   1.8
3. 209.51.130.213                60.0%    10    0.8   2.7   0.8  19.0   5.7
4. aix.pr1.atl.google.com        60.0%    10    6.7   6.8   6.7   6.9   0.1
5. 72.14.233.56                  50.0%   10    7.2   8.3   7.1  16.4   2.9
6. 209.85.254.247                40.0%   10   39.1  39.4  39.1  39.7   0.2
7. 64.233.174.46                 40.0%   10   39.6  40.4  39.4  46.9   2.3
8. gw-in-f147.1e100.net          40.0%   10   39.6  40.5  39.5  46.7   2.2

In this case, you see 60% loss between hops 2 and 3 as well as between hops 3 and 4. You can assume that the third and fourth hop is likely losing some amount of traffic because no subsequent host reports zero loss. However, some of the loss is due to rate limiting as several of the final hops are only experiencing 40% loss. When different amounts of loss are reported, always trust the reports from later hops.

Some loss can also be explained by problems in the return route. Packets will reach their destination without error, but have a hard time making the return trip. This will be apparent in the report, but may be difficult to deduce from the output of MTR. For this reason it is often best to collect MTR reports in both directions when you’re experiencing an issue.

Additionally, resist the temptation to investigate or report all incidences of packet loss in your connections. The Internet protocols are designed to be resilient to some network degradation, and the routes that data takes across the Internet can fluctuate in response to load, brief maintenance events, and other routing issues. If your MTR report shows small amounts of loss in the neighborhood of 10%, there is no cause for real concern as the application layer will compensate for the loss which is likely transient.

Understanding Network Latency
In addition to helping you assess packet loss, MTR will also help you assess the latency of a connection between your host and the target host. By virtue of physical constraints, latency always increases with the number of hops in a route. However, the increases should be consistent and linear. Unfortunately, latency is often relative and very dependent on the quality of both host’s connections and their physical distance. When evaluating MTR reports for potentially problematic connections, consider earlier fully functional reports as context in addition to known connection speeds between other hosts in a given area.

The connection quality may also affect the amount of latency you experience for a particular route. Predictably, dial-up connections will have much higher latency than cable modem connections to the same destination. Consider the following MTR report which shows a high latency:


root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10  388.0 360.4 342.1 396.7   0.2
  5. 72.14.233.56                  0.0%    10  390.6 360.4 342.1 396.7   0.2
  6. 209.85.254.247                0.0%    10  391.6 360.4 342.1 396.7   0.4
  7. 64.233.174.46                 0.0%    10  391.8 360.4 342.1 396.7   2.1
  8. gw-in-f147.1e100.net          0.0%    10  392.0 360.4 342.1 396.7   1.2

The amount of latency jumps significantly between hops 3 and 4 and remains high. This may point to a network latency issue as round trip times remain high after the fourth hop. From this report, it is impossible to determine the cause although a saturated peering session, a poorly configured router, or a congested link are frequent causes.

Unfortunately, high latency does not always mean a problem with the current route. A report like the one above means that despite some sort of issue with the 4th hop, traffic is still reaching the destination host and returning to the source host. Latency could be caused by a problem with the return route as well. The return route will not be seen in your MTR report, and packets can take completely different routes to and from a particular destination.

In the above example, while there is a large jump in latency between hosts 3 and 4 the latency does not increase unusually in any subsequent hops. From this it is logical to assume that there is some issue with the 4th router.

ICMP rate limiting can also create the appearance of latency, similar to the way that it can create the appearance of packet loss. Consider the following example:


root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  0.0%    10  254.2 250.3 230.1 263.4   2.9
  6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

At first glance, the latency between hops 4 and 5 draws attention. However after the fifth hop, the latency drops drastically. The actual latency measured here is about 40ms. In cases like this, MTR draws attention to an issue which does not affect the service. Consider the latency to the final hop when evaluating an MTR report.

Common MTR Reports
Some networking issues are novel and require escalation to the operators of the upstream networks. However, there are a selection of common MTR reports that describe common networking issues. If you’re experiencing some sort of networking issue and want to diagnose your problem, consider the following examples.

Destination Host Networking Improperly Configured
In the next example, it appears that there is 100% loss to a the destination host because of an incorrectly configured router. At first glance it appears that the packets are not reaching the host but this is not the case.


root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 72.14.233.56                  0.0%    10    7.2   8.3   7.1  16.4   2.9
  6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net         100.0    10    0.0   0.0   0.0   0.0   0.0

The traffic does reach the destination host however, the MTR report shows loss because the destination host is not sending a reply. This may be the result of improperly configured networking or firewall (iptables) rules that cause the host to drop ICMP packets.

The way you can tell that the loss is due to a misconfigured host is to look at the hop which shows 100% loss. From previous reports, you see that this is the final hop and that MTR does not try additional hops. While it is difficult to isolate this issue without a baseline measurement, these kinds of errors are quite common.

Residential or Business Router
Oftentimes residential gateways will cause MTR reports to look a little misleading.


% mtr --no-dns --report google.com
HOST: deleuze                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.1                   0.0%    10    2.2   2.2   2.0   2.7   0.2
  2. ???                          100.0    10    8.6  11.0   8.4  17.8   3.0
  3. 68.86.210.126                 0.0%    10    9.1  12.1   8.5  24.3   5.2
  4. 68.86.208.22                  0.0%    10   12.2  15.1  11.7  23.4   4.4
  5. 68.85.192.86                  0.0%    10   17.2  14.8  13.2  17.2   1.3
  6. 68.86.90.25                   0.0%    10   14.2  16.4  14.2  20.3   1.9
  7. 68.86.86.194                  0.0%    10   17.6  16.8  15.5  18.1   0.9
  8. 75.149.230.194                0.0%    10   15.0  20.1  15.0  33.8   5.6
  9. 72.14.238.232                 0.0%    10   15.6  18.7  14.1  32.8   5.9
 10. 209.85.241.148                0.0%    10   16.3  16.9  14.7  21.2   2.2
 11. 66.249.91.104                 0.0%    10   22.2  18.6  14.2  36.0   6.5

Do not be alarmed by the 100% loss reported. This does not indicate that there is a problem. You can see that there is no loss on subsequent hops.

An ISP Router Is Not Configured Properly
Sometimes a router on the route your packet takes is incorrectly configured and your packets may never reach their destination. Consider the following example:


root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  6. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  7. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  8. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
  9. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 10. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

The question marks appear when there is no additional route information. The following report displays the same issue:


root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
   1. 63.247.74.43                 0.0%    10    0.3   0.6   0.3   1.2   0.3
   2. 63.247.64.157                0.0%    10    0.4   1.0   0.4   6.1   1.8
   3. 209.51.130.213               0.0%    10    0.8   2.7   0.8  19.0   5.7
   4. aix.pr1.atl.google.com       0.0%    10    6.7   6.8   6.7   6.9   0.1
   5. 172.16.29.45                 0.0%    10    0.0   0.0   0.0   0.0   0.0
   6. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0 
   7. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
   8. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
   9. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0
  10. ???                          0.0%    10    0.0   0.0   0.0   0.0   0.0

Sometimes, a poorly configured router will send packets in a loop. You can see that in the following example:


root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  6. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  7. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  8. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
  9. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 10. 12.34.56.78                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 11. 12.34.56.79                   0.0%    10    0.0   0.0   0.0   0.0   0.0
 12. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 13. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0
 14. ???                           0.0%    10    0.0   0.0   0.0   0.0   0.0

All of these reports show that the router at hop 4 is not properly configured. When these situations happen, the only way to resolve the issue is to contact the network administrator’s team of operators at the source host.

ICMP Rate Limiting
ICMP rate limiting can cause apparent packet loss as described below. When there is packet loss to one hop that doesn’t persist to subsequent hops, the loss is caused by ICMP limiting. See the following example:


root@localhost:~# mtr --report www.google.com
 HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
   1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
   2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
   3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
   4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
   5. 72.14.233.56                 60.0%    10   27.2  25.3  23.1  26.4   2.9
   6. 209.85.254.247                0.0%    10   39.1  39.4  39.1  39.7   0.2
   7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
   8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

In situations like this there is no cause for concern. Rate limiting is a common practice and it reduces congestion to prioritizes more important traffic.

Timeouts
Timeouts can happen for various reasons. Some routers will discard ICMP and no replies will be shown on the output as timeouts (???). Alternatively there may be a problem with the return route:


root@localhost:~# mtr --report www.google.com
HOST: localhost                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 63.247.74.43                  0.0%    10    0.3   0.6   0.3   1.2   0.3
  2. 63.247.64.157                 0.0%    10    0.4   1.0   0.4   6.1   1.8
  3. 209.51.130.213                0.0%    10    0.8   2.7   0.8  19.0   5.7
  4. aix.pr1.atl.google.com        0.0%    10    6.7   6.8   6.7   6.9   0.1
  5. ???                           0.0%    10    7.2   8.3   7.1  16.4   2.9
  6. ???                           0.0%    10   39.1  39.4  39.1  39.7   0.2
  7. 64.233.174.46                 0.0%    10   39.6  40.4  39.4  46.9   2.3
  8. gw-in-f147.1e100.net          0.0%    10   39.6  40.5  39.5  46.7   2.2

Timeouts are not necessarily an indication of packet loss. Packets still reach their destination without significant packet loss or latency. Timeouts may be attributable to routers dropping packets for QoS (quality of service) purposes or there may be some issue with return routes causing the timeouts. This is another false positive.

Advanced MTR techniques
Newer versions of MTR are now capable of running in TCP mode on a specified TCP port, compared to the default use of the ICMP (ping) protocol. In some instances network degradation will only affect certain ports or misconfigured firewall rules on a router may block a certain protocol. Running MTR over a certain port can show packet loss where the default ICMP report may not.

Running MTR in TCP mode will require super-user privileges on most machines:


sudo mtr -P 80 -i 0.5 -rw50 example.com
sudo mtr -P 22 -i 0.5 -rw50 example.com

How To Install Linux, Apache, MySQL, PHP (LAMP) stack On CentOS 7

Update your system:

# sudo yum update

Install Apache Server with Basic Configurations

# sudo yum install httpd

Once it installs, you can start Apache:


# sudo systemctl start httpd.service

Check the installation:

http://your_server_IP_address/

You will see the default CentOS 7 Apache web page, which is there for informational and testing purposes. If you cannot load – see firewall info below. Also check selinux:

Selinux in CentOS7

For permanent disabling after reboot do:


# sudo nano /etc/selinux/config
SELINUX=permissive or disabled

# sudo setenforce 0

and check with


# sestatus

The last thing you will want to do is enable Apache to start on boot. Use the following command to do so:


# sudo systemctl enable httpd.service

For the database, I am installing Maria:

# sudo yum install mariadb-server mariadb

When the installation is complete, we need to start MariaDB with the following command:


# sudo systemctl start mariadb

Secure MySql

# sudo mysql_secure_installation

Enable it:

# sudo systemctl enable mariadb.service

Install PHP

# sudo yum install php php-mysql php-pdo php-gd php-mbstring
# sudo yum install php php-pear

Edit /etc/php.ini for better error messages and logs, and upgraded performance.


nano /etc/php.ini
error_reporting = E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR
error_log = /var/log/php/error.log
max_input_time = 30

Create the log directory for PHP and give the Apache user ownership:


# sudo mkdir /var/log/php
# sudo chown apache /var/log/php

Locate and change date.timezone line to look like this, using PHP Supported Timezones list.


date.timezone = Continent/City

Restart

# sudo systemctl restart httpd.service

Install PHP Modules

# yum search php
php-bcmath.x86_64 : A module for PHP applications for using the bcmath library
php-cli.x86_64 : Command-line interface for PHP
php-common.x86_64 : Common files for PHP
php-dba.x86_64 : A database abstraction layer module for PHP applications
php-devel.x86_64 : Files needed for building PHP extensions
php-embedded.x86_64 : PHP library for embedding in applications
php-enchant.x86_64 : Enchant spelling extension for PHP applications
php-fpm.x86_64 : PHP FastCGI Process Manager
php-gd.x86_64 : A module for PHP applications for using the gd graphics library
. . .

To get more information about what each module does, you can either search the internet, or you can look at the long description in the package by typing:


# sudo yum info package_name

If you are running a firewall, run the following commands to allow HTTP and HTTPS traffic:


sudo firewall-cmd --permanent --zone=public --add-service=http 
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

Other important Firewalld options are presented below:


# firewall-cmd --state
# firewall-cmd --list-all
# firewall-cmd --list-interfaces
# firewall-cmd --get-service
# firewall-cmd --query-service service_name
# firewall-cmd --add-port=8080/tcp