rev.dennis

I use to get this cool message of the day (motd) when I logged into by Ubuntu box and since upgrading I don't get it anymore. I use to get this: Now I get this: To get back the great motd I just had to run the following command: sudo run-parts /etc/update-motd.d/ | sudo tee /etc/motd

this is a great tool that I highly recommend using when troubleshooting. Most importantly its reliable. Here is an example of being able to test a https URL redirect curl -ksI https://zahsystems.com -k = process https (443). (SSL) This option explicitly allows curl to perform "insecure" SSL connections and transfers. All SSL connections are attempted to be made secure by using the CA certificate bundle installed by default. This makes all connections considered "insecure" fail unless -k, --insecure is used. -s = Silent or quiet mode. Don't show progress meter or error messages. Makes Curl mute. It will still output the data you ask for, potentially even to the terminal/stdout unless you redirect it. -I = (HTTP/FTP/FILE) Fetch the HTTP-header only! HTTP-servers feature the command HEAD which this uses to get nothing but the header of a document. When used on an FTP or FILE file, curl displays the file size and last modification time only. The results HTTP/1.0 302 FoundLocation: https://dj-direct.int.zahsystems.com/consumerdirectadmin/home.actionServer: BigIPConnection: Keep-AliveContent-Length: 0

this is a great tool that I highly recommend using when troubleshooting. Most importantly its reliable. Here is an example of being able to test a https URL redirect curl -ksI https://zahsystems.com -k = process https (443). (SSL) This option explicitly allows curl to perform "insecure" SSL connections and transfers. All SSL connections are attempted to be made secure by using the CA certificate bundle installed by default. This makes all connections considered "insecure" fail unless -k, --insecure is used. -s = Silent or quiet mode. Don't show progress meter or error messages. Makes Curl mute. It will still output the data you ask for, potentially even to the terminal/stdout unless you redirect it. -I = (HTTP/FTP/FILE) Fetch the HTTP-header only! HTTP-servers feature the command HEAD which this uses to get nothing but the header of a document. When used on an FTP or FILE file, curl displays the file size and last modification time only. The results HTTP/1.0 302 FoundLocation: https://dj-direct.int.zahsystems.com/consumerdirectadmin/home.actionServer: BigIPConnection: Keep-AliveContent-Length: 0

For us what you need to do is Find what VRF USZAH-001# show vrf [offtopic]VRF-Name VRF-ID State Reason FCR 3 Up -- default 1 Up -- management 2 Up --[/offtopic] the command works is [offtopic]show ip arp vlan 102 vrf FCR[/offtopic]

For us what you need to do is Find what VRF USZAH-001# show vrf [offtopic]VRF-Name VRF-ID State Reason FCR 3 Up -- default 1 Up -- management 2 Up --[/offtopic] the command works is [offtopic]show ip arp vlan 102 vrf FCR[/offtopic]

Here is the script backup.sh #!/bin/bash#Created by Dennis Hosang 20130812#day of week variableDOW=$(date +%A)#username variableUSERNAME="netadm1n"#hostname variableHOST=$(hostname|cut -f1 -d.)#backup /homesudo rsync --delete -azvv --exclude-from '/backups/home_exclude' --log-file=/backups/${DOW}/rsync_log /home/ 10.6.56.244:/backups/${HOST}/${DOW}/home/#backup /bootsudo rsync --delete -azvv --log-file=/backups/${DOW}/rsync_log /boot/ 10.6.56.244:/backups/${HOST}/${DOW}/boot/#empty trashrm -rf /home/${USERNAME}/.local/share/Trash/Files/*#backup /rootsudo rsync -avz --delete --exclude-from '/backups/root_exclude' --log-file=/backups/${DOW}/rsync_log / 10.6.56.244:/backups/${HOST}/${DOW}/root/#backup /home#sudo rsync --delete -azvv --exclude-from '/backups/home_exclude' --log-file=/backups/${DOW}/rsync_log /home/ 10.6.56.244:/backups/${HOST}/${DOW}/home/ Just added it to my crontab # /etc/crontab: system-wide crontab# Unlike any other crontab you don't have to run the `crontab'# command to install the new version when you edit this file# and files in /etc/cron.d. These files also have username fields,# that none of the other crontabs do.SHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin# m h dom mon dow user command#37 14 * * * root sh /backups/backup.sh

This script shows what you have scheduled via cron #!/bin/bash# System-wide crontab file and cron job directory. Change these for your system.CRONTAB='/etc/crontab'CRONDIR='/etc/cron.d'# Single tab character. Annoyingly necessary.tab=$(echo -en "\t")# Given a stream of crontab lines, exclude non-cron job lines, replace# whitespace characters with a single space, and remove any spaces from the# beginning of each line.function clean_cron_lines() { while read line ; do echo "${line}" | egrep --invert-match '^($|\s*#|\s*[[:alnum:]_]+=)' | sed --regexp-extended "s/\s+/ /g" | sed --regexp-extended "s/^ //" done;}# Given a stream of cleaned crontab lines, echo any that don't include the# run-parts command, and for those that do, show each job file in the run-parts# directory as if it were scheduled explicitly.function lookup_run_parts() { while read line ; do match=$(echo "${line}" | egrep -o 'run-parts (-{1,2}\S+ )*\S+') if [[ -z "${match}" ]] ; then echo "${line}" else cron_fields=$(echo "${line}" | cut -f1-6 -d' ') cron_job_dir=$(echo "${match}" | awk '{print $NF}') if [[ -d "${cron_job_dir}" ]] ; then for cron_job_file in "${cron_job_dir}"/* ; do # */ [[ -f "${cron_job_file}" ]] && echo "${cron_fields} ${cron_job_file}" done fi fi done;}# Temporary file for crontab lines.temp=$(mktemp) || exit 1# Add all of the jobs from the system-wide crontab file.cat "${CRONTAB}" | clean_cron_lines | lookup_run_parts >"${temp}" # Add all of the jobs from the system-wide cron directory.cat "${CRONDIR}"/* | clean_cron_lines >>"${temp}" # */ # Add each user's crontab (if it exists). Insert the user's name between the# five time fields and the command.while read user ; do crontab -l -u "${user}" 2>/dev/null | clean_cron_lines | sed --regexp-extended "s/^((\S+ +){5})(.+)$/\1${user} \3/" >>"${temp}"done < <(cut --fields=1 --delimiter=: /etc/passwd)# Output the collected crontab lines. Replace the single spaces between the# fields with tab characters, sort the lines by hour and minute, insert the# header line, and format the results as a table.cat "${temp}" | sed --regexp-extended "s/^(\S+) +(\S+) +(\S+) +(\S+) +(\S+) +(\S+) +(.*)$/\1\t\2\t\3\t\4\t\5\t\6\t\7/" | sort --numeric-sort --field-separator="${tab}" --key=2,1 | sed "1i\mi\th\td\tm\tw\tuser\tcommand" | column -s"${tab}" -trm --force "${temp}"

This is what I have working at the moment. All the remote devices just point to ubuntu box that is running syslog-ng $ cat /etc/syslog-ng/syslog-ng.conf@version: 3.5@include "scl.conf"@include "`scl-root`/system/tty10.conf"# Syslog-ng configuration file, compatible with default Debian syslogd# installation.# First, set some global options.options { flush_lines(0); use_dns(persist_only); use_fqdn(yes); owner(root); group(adm); perm(0640); stats_freq(0); bad_hostname("^gconfd$"); normalize_hostnames(yes); keep_hostname(yes); create_dirs(yes); };######################### Sources########################source s_local { system(); internal(); };source s_stunnel {# tcp(ip("127.0.0.1") tcp( port(1000) max-connections(100)); };source s_udp { udp(); };######################### Filters########################filter f_emerg { level (emerg); };filter f_alert { level (alert .. emerg); };filter f_crit { level (crit .. emerg); };filter f_err { level (err .. emerg); };filter f_warning { level (warning .. emerg); };filter f_notice { level (notice .. emerg); };filter f_info { level (info .. emerg); };filter f_debug { level (debug .. emerg); };# Facility Filtersfilter f_kern { facility (kern); };filter f_user { facility (user); };filter f_mail { facility (mail); };filter f_daemon { facility (daemon); };filter f_auth { facility (auth); };filter f_syslog { facility (syslog); };filter f_lpr { facility (lpr); };filter f_news { facility (news); };filter f_uucp { facility (uucp); };filter f_cron { facility (cron); };filter f_local0 { facility (local0); };filter f_local1 { facility (local1); };filter f_local2 { facility (local2); };filter f_local3 { facility (local3); };filter f_local4 { facility (local4); };filter f_local5 { facility (local5); };filter f_local6 { facility (local6); };filter f_local7 { facility (local7); };# Custom Filtersfilter f_user_none { not facility (user); };filter f_kern_debug { filter (f_kern) and filter (f_debug); };filter f_daemon_notice { filter (f_daemon) and filter (f_notice); };filter f_mail_crit { filter (f_mail) and filter (f_crit); };filter f_mesg { filter (f_kern_debug) or filter (f_daemon_notice) or filter (f_mail_crit); };filter f_authinfo { filter (f_auth) or program (sudo); };######################### Destinations########################destination l_authlog { file ("/var/log/authlog"); };destination l_messages { file ("/var/log/messages"); };destination l_maillog { file ("/var/log/maillog"); };destination l_info { file ("/var/log/info"); };destination l_ipflog { file ("/var/log/ipflog"); };#destination l_debug { file ("/var/log/debug"); };destination l_imaplog { file ("/var/log/imaplog"); };destination l_syslog { file ("/var/log/syslog"); };destination l_console { file ("/dev/console"); };destination r_authlog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/authlog"); };destination r_messages { file ("/var/log/clients/$YEAR/$MONTH/$HOST/messages"); };destination r_maillog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/maillog"); };destination r_info { file ("/var/log/clients/$YEAR/$MONTH/$HOST/info"); };destination r_ipflog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/ipflog"); };#destination r_debug { file# ("/var/log/clients/$YEAR/$MONTH/$HOST/debug"); };destination r_imaplog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/imaplog"); };destination r_console { file ("/var/log/clients/$YEAR/$MONTH/$HOST/consolelog"); };destination r_syslog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/syslog"); };destination r_fallback { file ("/var/log/clients/$YEAR/$MONTH/$HOST/$FACILITY-$LEVEL"); };######################### Log paths######################### Local sourceslog { source (s_local); filter (f_authinfo); destination (l_authlog); };log { source (s_local); filter (f_mail); destination (l_maillog); };log { source (s_local); filter (f_info); destination (l_info); };log { source (s_local); filter (f_local0); destination (l_ipflog); };#log { source (s_local); filter (f_debug); destination (l_debug); };log { source (s_local); filter (f_local1); destination (l_imaplog); };log { source (s_local); filter (f_syslog); destination (l_syslog); };log { source (s_local); filter (f_emerg); filter (f_user_none); destination (l_console); };log { source (s_local); filter (f_mesg); filter (f_user_none); destination (l_messages); };# All sources, since we want to archive local and remote logslog { source (s_local); source (s_stunnel); filter (f_authinfo); destination (r_authlog); };log { source (s_local); source (s_stunnel); filter (f_mail); destination (r_maillog); };log { source (s_local); source (s_stunnel); filter (f_info); destination (r_info); };log { source (s_local); source (s_stunnel); filter (f_local0); destination (r_ipflog); };#log { source (s_local); source (s_stunnel); filter (f_debug);# destination (r_debug); };log { source (s_local); source (s_stunnel); filter (f_local1); destination (r_imaplog); };log { source (s_local); source (s_stunnel); filter (f_syslog); destination (r_syslog); };log { source (s_local); source (s_stunnel); filter (f_emerg); filter (f_user_none); destination (l_console); };log { source (s_local); source (s_stunnel); filter (f_mesg); filter (f_user_none); destination (l_messages); };#### Include all config files in /etc/syslog-ng/conf.d/###@include "/etc/syslog-ng/conf.d/*.conf"

This is what I have working at the moment. All the remote devices just point to ubuntu box that is running syslog-ng $ cat /etc/syslog-ng/syslog-ng.conf@version: 3.5@include "scl.conf"@include "`scl-root`/system/tty10.conf"# Syslog-ng configuration file, compatible with default Debian syslogd# installation.# First, set some global options.options { flush_lines(0); use_dns(persist_only); use_fqdn(yes); owner(root); group(adm); perm(0640); stats_freq(0); bad_hostname("^gconfd$"); normalize_hostnames(yes); keep_hostname(yes); create_dirs(yes); };######################### Sources########################source s_local { system(); internal(); };source s_stunnel {# tcp(ip("127.0.0.1") tcp( port(1000) max-connections(100)); };source s_udp { udp(); };######################### Filters########################filter f_emerg { level (emerg); };filter f_alert { level (alert .. emerg); };filter f_crit { level (crit .. emerg); };filter f_err { level (err .. emerg); };filter f_warning { level (warning .. emerg); };filter f_notice { level (notice .. emerg); };filter f_info { level (info .. emerg); };filter f_debug { level (debug .. emerg); };# Facility Filtersfilter f_kern { facility (kern); };filter f_user { facility (user); };filter f_mail { facility (mail); };filter f_daemon { facility (daemon); };filter f_auth { facility (auth); };filter f_syslog { facility (syslog); };filter f_lpr { facility (lpr); };filter f_news { facility (news); };filter f_uucp { facility (uucp); };filter f_cron { facility (cron); };filter f_local0 { facility (local0); };filter f_local1 { facility (local1); };filter f_local2 { facility (local2); };filter f_local3 { facility (local3); };filter f_local4 { facility (local4); };filter f_local5 { facility (local5); };filter f_local6 { facility (local6); };filter f_local7 { facility (local7); };# Custom Filtersfilter f_user_none { not facility (user); };filter f_kern_debug { filter (f_kern) and filter (f_debug); };filter f_daemon_notice { filter (f_daemon) and filter (f_notice); };filter f_mail_crit { filter (f_mail) and filter (f_crit); };filter f_mesg { filter (f_kern_debug) or filter (f_daemon_notice) or filter (f_mail_crit); };filter f_authinfo { filter (f_auth) or program (sudo); };######################### Destinations########################destination l_authlog { file ("/var/log/authlog"); };destination l_messages { file ("/var/log/messages"); };destination l_maillog { file ("/var/log/maillog"); };destination l_info { file ("/var/log/info"); };destination l_ipflog { file ("/var/log/ipflog"); };#destination l_debug { file ("/var/log/debug"); };destination l_imaplog { file ("/var/log/imaplog"); };destination l_syslog { file ("/var/log/syslog"); };destination l_console { file ("/dev/console"); };destination r_authlog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/authlog"); };destination r_messages { file ("/var/log/clients/$YEAR/$MONTH/$HOST/messages"); };destination r_maillog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/maillog"); };destination r_info { file ("/var/log/clients/$YEAR/$MONTH/$HOST/info"); };destination r_ipflog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/ipflog"); };#destination r_debug { file# ("/var/log/clients/$YEAR/$MONTH/$HOST/debug"); };destination r_imaplog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/imaplog"); };destination r_console { file ("/var/log/clients/$YEAR/$MONTH/$HOST/consolelog"); };destination r_syslog { file ("/var/log/clients/$YEAR/$MONTH/$HOST/syslog"); };destination r_fallback { file ("/var/log/clients/$YEAR/$MONTH/$HOST/$FACILITY-$LEVEL"); };######################### Log paths######################### Local sourceslog { source (s_local); filter (f_authinfo); destination (l_authlog); };log { source (s_local); filter (f_mail); destination (l_maillog); };log { source (s_local); filter (f_info); destination (l_info); };log { source (s_local); filter (f_local0); destination (l_ipflog); };#log { source (s_local); filter (f_debug); destination (l_debug); };log { source (s_local); filter (f_local1); destination (l_imaplog); };log { source (s_local); filter (f_syslog); destination (l_syslog); };log { source (s_local); filter (f_emerg); filter (f_user_none); destination (l_console); };log { source (s_local); filter (f_mesg); filter (f_user_none); destination (l_messages); };# All sources, since we want to archive local and remote logslog { source (s_local); source (s_stunnel); filter (f_authinfo); destination (r_authlog); };log { source (s_local); source (s_stunnel); filter (f_mail); destination (r_maillog); };log { source (s_local); source (s_stunnel); filter (f_info); destination (r_info); };log { source (s_local); source (s_stunnel); filter (f_local0); destination (r_ipflog); };#log { source (s_local); source (s_stunnel); filter (f_debug);# destination (r_debug); };log { source (s_local); source (s_stunnel); filter (f_local1); destination (r_imaplog); };log { source (s_local); source (s_stunnel); filter (f_syslog); destination (r_syslog); };log { source (s_local); source (s_stunnel); filter (f_emerg); filter (f_user_none); destination (l_console); };log { source (s_local); source (s_stunnel); filter (f_mesg); filter (f_user_none); destination (l_messages); };#### Include all config files in /etc/syslog-ng/conf.d/###@include "/etc/syslog-ng/conf.d/*.conf"

I just had an issue where only one intranet user could connect at a time. If another laptop/user logged on it would kick out the one that was already there. I have tried changing, clearing cookies. In the end, it was because IPS Connect was enabled and it should be the Internal Database only.

I just had an issue where only one intranet user could connect at a time. If another laptop/user logged on it would kick out the one that was already there. I have tried changing, clearing cookies. In the end, it was because IPS Connect was enabled and it should be the Internal Database only.

Moving from Invision Power Board (IP.Board) to Joomla mainly because IP.Board doesn't support printing of forums or articles. This is a pretty big deal for me and also I pay a subscription to IP.Board and not sure I get what I pay for when I can just about duplicate what I'm paying for with Joomla and phpbb. I'll create a test.zahsystems.com and load joomla up on it and create a /forum under that for the phpbb install and utilize p8bb bridge by alterbrains. Will keep you posted. Need to see how the migration of all my forum data and gallery photos and then linking everything

Moving from Invision Power Board (IP.Board) to Joomla mainly because IP.Board doesn't support printing of forums or articles. This is a pretty big deal for me and also I pay a subscription to IP.Board and not sure I get what I pay for when I can just about duplicate what I'm paying for with Joomla and phpbb. I'll create a test.zahsystems.com and load joomla up on it and create a /forum under that for the phpbb install and utilize p8bb bridge by alterbrains. Will keep you posted. Need to see how the migration of all my forum data and gallery photos and then linking everything

It sure would be helpful to find out what actual network/bandwidth speed is versus relying on other tools. Utilize Wireshark to monitor your network card to get an accurate representation of your bandwidth. If you have a trace running as you download a file go to Statistics - IO Graph draw a graph in the outbound direction only. Change the Y-axis to bits/tick if you want to see bandwidth. Maybe you are using a Linux system or just like using tcpdump. TCPdump doesn't give you the real-time stats but you can feed it's output to something that does. You'd need to add a suitable filter expression at the end of the tcpdump command to only include the traffic generated by your app (e.g. port 80) The program netbps is this: It's just an example, adjust to taste.

It sure would be helpful to find out what actual network/bandwidth speed is versus relying on other tools. Utilize Wireshark to monitor your network card to get an accurate representation of your bandwidth. If you have a trace running as you download a file go to Statistics - IO Graph draw a graph in the outbound direction only. Change the Y-axis to bits/tick if you want to see bandwidth. Maybe you are using a Linux system or just like using tcpdump. TCPdump doesn't give you the real-time stats but you can feed it's output to something that does. You'd need to add a suitable filter expression at the end of the tcpdump command to only include the traffic generated by your app (e.g. port 80) The program netbps is this: It's just an example, adjust to taste.

A very helpful command that is good to know $ sudo route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.6.0.129 0.0.0.0 UG 0 0 0 eth0 10.6.0.128 0.0.0.0 255.255.255.224 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 -n option means that you want numerical IP addresses displayed, instead of the corresponding host names. $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.6.0.129 0.0.0.0 UG 0 0 0 eth0 10.6.0.128 0.0.0.0 255.255.255.224 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 -r option specifies that you want the routing table -n option is similar to that of the route command $ ip route list default via 10.6.0.129 dev eth0 10.6.0.128/27 dev eth0 proto kernel scope link src 10.6.0.136 169.254.0.0/16 dev eth0 scope link metric 1000 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1

A very helpful command that is good to know $ sudo route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.6.0.129 0.0.0.0 UG 0 0 0 eth0 10.6.0.128 0.0.0.0 255.255.255.224 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 -n option means that you want numerical IP addresses displayed, instead of the corresponding host names. $ netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.6.0.129 0.0.0.0 UG 0 0 0 eth0 10.6.0.128 0.0.0.0 255.255.255.224 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 -r option specifies that you want the routing table -n option is similar to that of the route command $ ip route list default via 10.6.0.129 dev eth0 10.6.0.128/27 dev eth0 proto kernel scope link src 10.6.0.136 169.254.0.0/16 dev eth0 scope link metric 1000 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1

What causes this error? This error can occur due to a few different causes, each one is described along with recommended solution. Incorrect connection parameters By far the most common, having incorrect connection credentials will cause the error. These credentials are located in the wp-config.php file found in the root folder for your WordPress installation. There are three credentials: database name, database user, and password. Make sure these match the information located in your cPanel. If you know the current database user password, you can reset it. If you do not know it, you will not be able to view the current password, so you will need to delete and then recreate the database user, giving it the password found in the wp-config.php file. If this is the issue, then the problem should be solved and the site should display normally Corrupted database tables If you have confirmed the credentials are correct and still get the error, the issue could be caused by corrupted database tables. Database tables can be checked and repaired from within the cPanel. How to check your tables Log into your cPanel Click the phpMyAdmin icon Choose the database you are working with by clicking on it in the left menu On the right side of the page, you will see a listing of your tables. Click "Check All" and then from the drop down choose "Check Table" The page will refresh and give you a summary of table that may be corrupted. As you can see from the screenshot below, all the tables are OK. If you receive any errors, you can continue reading to find how to repair your tables after checking tables in phpMyAdmin How to repair your tables Log into your cPanel Click the phpMyAdmin icon Choose the database you are working with by clicking on it in the left menu On the right side of the page, you will see a listing of your tables. Click "Check All" and then from the drop down choose "Repair Table" The page will refresh and give you a summary of the tables that were repaired. Too many concurrent database connections The error can also occur if there are too many connections to your database at once. Currently, the default limit for our servers is 30 connections at once. If this is your issue, you can certainly curb it by enabling caching plugins on your website. This will limit the overall number of database interactions your Wordpress site performs. Optimizing WordPress with W3 Total Cache plugin By default WordPress is a dynamic CMS (Content Management System). This means that for every visitor request that WordPress has to process, it must first connect to the database to see if the requested page even exists. In a lot of cases this might not be problematic on a site that doesn't receive much traffic. However a sudden surge in traffic caused by search engine bots, or just a general increase in normal traffic can quickly cause your WordPress site to use up a lot of CPU resources from the server while trying to fulfill needless duplicate requests again and again. You can counter this increase in CPU usage by implementing a caching plugin. What these do is cache the first visitor's request of a new page to a plain HTML file on the server, then when another visitor comes through and requests the same page, so long as the page wasn't updated in your administration section, or updated by a comment, the cached HTML page will be served. This can greatly reduce CPU usage of your WordPress site very easily. As an example let's say you had 100 views of your front page, without caching that would require the same database query to have to run 100 times and every time it's just getting back the exact same data anyways. With a caching plugin only the first user would have the database query run to generate the cached HTML file, then the next 99 visitors would get that cached HTML served to them right away, without having to wait for any database activity to complete. This is just about always a win-win, because your visitors don't have to wait as long for your pages to load, and you're reducing the impact of WordPress's requests on the server's performance. One of the simplest WordPress caching plugins to setup is WP Super Cache which is discussed in a previous article of ours. However if you need more advanced caching options such as the ability to serve a static 404 error page the steps below will walk you through installing and configuring the W3 Total Cache plugin for WordPress. **Note: This will not work with Wordpress Multisites. Hover over Plugins in the left-hand menu, then click Add New. In the Search box, type in w3 total cache and click on Search Plugins. Under W3 Total Cache click on Install Now. Click OK in the installation pop-up. Click Activate Plugin. You should now see Plugin activated. From the left-hand menu, you should now have a new Performance section, hover over this and click on General Settings. Scroll down the general settings page ensuring that each main section is enabled. Hover over Performance again in the left-hand menu, and click on Page Cache. Ensure that these options have a checkmark beside them, then click on Save all settings: Finally to confirm that you've setup everything correctly, in your web-browser open up your site and hit (Ctrl-U), or go to View -> Page source to view the source of the page. Scroll to the very bottom of the page and you should see the W3 Total Cache banner letting you know the page has been optimized. w3tc-confirm-page-source Once you've confirmed that W3 Total Cache is up and running properly on your website you're done. Now you can enjoy quicker page loads, and reduced resource usage from your WordPress site! Below #8 Page Cache Minify NOTE: If you are using minify, make sure to enable the option, save it and then immediately look at your WordPress site to make sure that the site looks normal. If you see problems with formatting, then it's possible that a theme or plugin is causing issues due to the minification. You should then disable minification and not use this option with your website. Database Cache Object Cache Browser Cache, after enabling this option click on Save all settings Below #10 Cache home page Cache feeds: site, categories, tags, comments Cache 404 (not found) pages Cache requests only for yourdomain.com hostname Don't cache pages for logged in users Optimizing WordPress with WP Super Cache Plugin WP Super Cache can help optimize your WordPress website. WP Super Cache will enable your website to load faster and use less server resources. You can install WP Super Cache by first logging into your WordPress Dashboard. Once you have logged into your WordPress Dashboard, click on Plugins on the left menu pane. Then click Add New. Use the search box, and search for "super cache". After the search is finished, you can locate the plugin and click "Install Now" Once the plugin installation is complete, click on "activate Plugin" You will see a "red box" to remind you to enable WP Super Cache. click on the "Plugin Admin Page". Enable caching by clicking on the button next to "Caching On" and then click "Update Status" On the same screen as above, click on the "advanced" tab. Please select the "Use mod_rewrite to serve cache files" option and click "update status" Next you should receive this message below. Scroll down the page and you will will a large yellow box. Click on the button labeled "Update Mod_Rewrite Rules" at the bottom of the box. Once you click the box in the above screenshot it will change to green and be labeled "Mod rewrite rules updated". You have two different options to verify that WP Super Cache is installed correctly. The first way is to look at the source code of your website. The source code will show that the webpage was successfully cached. In most web browsers you can right click within the WordPress website and select "View Page Source". Look at the bottom of the page The second way to verify if super cache is working correctly and installed is checking the ,htaccess file. You can access the .htaccess file using a FTP client or through file manager in cPanel. In the same folder that contains your WordPress site, look for the .htaccess file and open it. In the .htaccess file Once you have confirmed that WP Super Cache is installed and functioning correctly, you're done! Additionally, there can be other causes for extraneous database interaction. These can be prevented by logging out of WordPress admin dashboard when not in use, disabling the WordPress autosave, and limiting or disabling WordPress revisions.

What causes this error? This error can occur due to a few different causes, each one is described along with recommended solution. Incorrect connection parameters By far the most common, having incorrect connection credentials will cause the error. These credentials are located in the wp-config.php file found in the root folder for your WordPress installation. There are three credentials: database name, database user, and password. Make sure these match the information located in your cPanel. If you know the current database user password, you can reset it. If you do not know it, you will not be able to view the current password, so you will need to delete and then recreate the database user, giving it the password found in the wp-config.php file. If this is the issue, then the problem should be solved and the site should display normally Corrupted database tables If you have confirmed the credentials are correct and still get the error, the issue could be caused by corrupted database tables. Database tables can be checked and repaired from within the cPanel. How to check your tables Log into your cPanel Click the phpMyAdmin icon Choose the database you are working with by clicking on it in the left menu On the right side of the page, you will see a listing of your tables. Click "Check All" and then from the drop down choose "Check Table" The page will refresh and give you a summary of table that may be corrupted. As you can see from the screenshot below, all the tables are OK. If you receive any errors, you can continue reading to find how to repair your tables after checking tables in phpMyAdmin How to repair your tables Log into your cPanel Click the phpMyAdmin icon Choose the database you are working with by clicking on it in the left menu On the right side of the page, you will see a listing of your tables. Click "Check All" and then from the drop down choose "Repair Table" The page will refresh and give you a summary of the tables that were repaired. Too many concurrent database connections The error can also occur if there are too many connections to your database at once. Currently, the default limit for our servers is 30 connections at once. If this is your issue, you can certainly curb it by enabling caching plugins on your website. This will limit the overall number of database interactions your Wordpress site performs. Optimizing WordPress with W3 Total Cache plugin By default WordPress is a dynamic CMS (Content Management System). This means that for every visitor request that WordPress has to process, it must first connect to the database to see if the requested page even exists. In a lot of cases this might not be problematic on a site that doesn't receive much traffic. However a sudden surge in traffic caused by search engine bots, or just a general increase in normal traffic can quickly cause your WordPress site to use up a lot of CPU resources from the server while trying to fulfill needless duplicate requests again and again. You can counter this increase in CPU usage by implementing a caching plugin. What these do is cache the first visitor's request of a new page to a plain HTML file on the server, then when another visitor comes through and requests the same page, so long as the page wasn't updated in your administration section, or updated by a comment, the cached HTML page will be served. This can greatly reduce CPU usage of your WordPress site very easily. As an example let's say you had 100 views of your front page, without caching that would require the same database query to have to run 100 times and every time it's just getting back the exact same data anyways. With a caching plugin only the first user would have the database query run to generate the cached HTML file, then the next 99 visitors would get that cached HTML served to them right away, without having to wait for any database activity to complete. This is just about always a win-win, because your visitors don't have to wait as long for your pages to load, and you're reducing the impact of WordPress's requests on the server's performance. One of the simplest WordPress caching plugins to setup is WP Super Cache which is discussed in a previous article of ours. However if you need more advanced caching options such as the ability to serve a static 404 error page the steps below will walk you through installing and configuring the W3 Total Cache plugin for WordPress. **Note: This will not work with Wordpress Multisites. Hover over Plugins in the left-hand menu, then click Add New. In the Search box, type in w3 total cache and click on Search Plugins. Under W3 Total Cache click on Install Now. Click OK in the installation pop-up. Click Activate Plugin. You should now see Plugin activated. From the left-hand menu, you should now have a new Performance section, hover over this and click on General Settings. Scroll down the general settings page ensuring that each main section is enabled. Hover over Performance again in the left-hand menu, and click on Page Cache. Ensure that these options have a checkmark beside them, then click on Save all settings: Finally to confirm that you've setup everything correctly, in your web-browser open up your site and hit (Ctrl-U), or go to View -> Page source to view the source of the page. Scroll to the very bottom of the page and you should see the W3 Total Cache banner letting you know the page has been optimized. w3tc-confirm-page-source Once you've confirmed that W3 Total Cache is up and running properly on your website you're done. Now you can enjoy quicker page loads, and reduced resource usage from your WordPress site! Below #8 Page Cache Minify NOTE: If you are using minify, make sure to enable the option, save it and then immediately look at your WordPress site to make sure that the site looks normal. If you see problems with formatting, then it's possible that a theme or plugin is causing issues due to the minification. You should then disable minification and not use this option with your website. Database Cache Object Cache Browser Cache, after enabling this option click on Save all settings Below #10 Cache home page Cache feeds: site, categories, tags, comments Cache 404 (not found) pages Cache requests only for yourdomain.com hostname Don't cache pages for logged in users Optimizing WordPress with WP Super Cache Plugin WP Super Cache can help optimize your WordPress website. WP Super Cache will enable your website to load faster and use less server resources. You can install WP Super Cache by first logging into your WordPress Dashboard. Once you have logged into your WordPress Dashboard, click on Plugins on the left menu pane. Then click Add New. Use the search box, and search for "super cache". After the search is finished, you can locate the plugin and click "Install Now" Once the plugin installation is complete, click on "activate Plugin" You will see a "red box" to remind you to enable WP Super Cache. click on the "Plugin Admin Page". Enable caching by clicking on the button next to "Caching On" and then click "Update Status" On the same screen as above, click on the "advanced" tab. Please select the "Use mod_rewrite to serve cache files" option and click "update status" Next you should receive this message below. Scroll down the page and you will will a large yellow box. Click on the button labeled "Update Mod_Rewrite Rules" at the bottom of the box. Once you click the box in the above screenshot it will change to green and be labeled "Mod rewrite rules updated". You have two different options to verify that WP Super Cache is installed correctly. The first way is to look at the source code of your website. The source code will show that the webpage was successfully cached. In most web browsers you can right click within the WordPress website and select "View Page Source". Look at the bottom of the page The second way to verify if super cache is working correctly and installed is checking the ,htaccess file. You can access the .htaccess file using a FTP client or through file manager in cPanel. In the same folder that contains your WordPress site, look for the .htaccess file and open it. In the .htaccess file Once you have confirmed that WP Super Cache is installed and functioning correctly, you're done! Additionally, there can be other causes for extraneous database interaction. These can be prevented by logging out of WordPress admin dashboard when not in use, disabling the WordPress autosave, and limiting or disabling WordPress revisions.

What I found out to test oracle connectivity you would do the following from a machine that has Oracle loaded. The three main things to check for when diagnosing remote database connection issues are the machine, the listener, and the database. The utilities that can be used to test each one of these include ping, tnsping, and a database connection. The ping utility is used to test the connectivity to a remote machine. ping will indicate whether a remote server is accessible and responding. If the ping command indicates that a machine cannot be accessed, the other connectivity tests will also fail. D:> ping asgard Pinging asgard.zahsystems.com with 32 bytes of data: Reply from 198.64.245.67: bytes=32 time<10ms TTL=254 Reply from 198.64.245.67: bytes=32 time<10ms TTL=254 Reply from 198.64.245.67: bytes=32 time<10ms TTL=254 Reply from 198.64.245.67: bytes=32 time<10ms TTL=254 Once connectivity to the host is confirmed with ping, the next connection to test is the listener. The tnsping utility is used to determine whether or not an Oracle service can be successfully reached. If a connection can be established from a client to a server (or server to server), tnsping will report the number of milliseconds it took to reach the remote service. If unsuccessful, a network error will be displayed. However, tnsping will only report if the listener process is up and provides no indication of the state of the database. D:> tnsping The “net service name” must exist in the tnsnames.ora file (In the example below GRACELANV8_GRA901m is the hostname in tnsnames.ora) D:> tnsping GRACELANV8_GRA901m 5 Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=gracelan) (PORT=1525)) (CONNECT_DATA= (SID=GRA901m))) OK (80 msec) OK (10 msec) OK (10 msec) OK (0 msec) OK (10 msec) The result from the tnsping command above shows 80 milliseconds (ms) were required for the first “ping”. During this time period, the alias GRACELANV8_GRA901m from the local tnsnames.ora file was retrieved, a DNS of the host “gracelan” was resolved, and the TNS connect and refuse packets were transported. The second trip took only 10 ms because all of the connection information was already cached. Here is a link to a nice free scanning tool that allows scanning a remote machine for open TCP and UDP ports (no installation required, just launch the .exe)

What I found out to test oracle connectivity you would do the following from a machine that has Oracle loaded. The three main things to check for when diagnosing remote database connection issues are the machine, the listener, and the database. The utilities that can be used to test each one of these include ping, tnsping, and a database connection. The ping utility is used to test the connectivity to a remote machine. ping will indicate whether a remote server is accessible and responding. If the ping command indicates that a machine cannot be accessed, the other connectivity tests will also fail. D:> ping asgard Pinging asgard.zahsystems.com with 32 bytes of data: Reply from 198.64.245.67: bytes=32 time<10ms TTL=254 Reply from 198.64.245.67: bytes=32 time<10ms TTL=254 Reply from 198.64.245.67: bytes=32 time<10ms TTL=254 Reply from 198.64.245.67: bytes=32 time<10ms TTL=254 Once connectivity to the host is confirmed with ping, the next connection to test is the listener. The tnsping utility is used to determine whether or not an Oracle service can be successfully reached. If a connection can be established from a client to a server (or server to server), tnsping will report the number of milliseconds it took to reach the remote service. If unsuccessful, a network error will be displayed. However, tnsping will only report if the listener process is up and provides no indication of the state of the database. D:> tnsping The “net service name” must exist in the tnsnames.ora file (In the example below GRACELANV8_GRA901m is the hostname in tnsnames.ora) D:> tnsping GRACELANV8_GRA901m 5 Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=gracelan) (PORT=1525)) (CONNECT_DATA= (SID=GRA901m))) OK (80 msec) OK (10 msec) OK (10 msec) OK (0 msec) OK (10 msec) The result from the tnsping command above shows 80 milliseconds (ms) were required for the first “ping”. During this time period, the alias GRACELANV8_GRA901m from the local tnsnames.ora file was retrieved, a DNS of the host “gracelan” was resolved, and the TNS connect and refuse packets were transported. The second trip took only 10 ms because all of the connection information was already cached. Here is a link to a nice free scanning tool that allows scanning a remote machine for open TCP and UDP ports (no installation required, just launch the .exe)

When someone complains of having a network issue, it would be helpful if they run the following commands and supply the person troubleshooting the network the output of these commands. UNIX/Linux Environment : ifconfig -anetstat -rn netstat -v Windows Environment: ipconfig /allnetstat -r netstat -e netstat -s

When someone complains of having a network issue, it would be helpful if they run the following commands and supply the person troubleshooting the network the output of these commands. UNIX/Linux Environment : ifconfig -anetstat -rn netstat -v Windows Environment: ipconfig /allnetstat -r netstat -e netstat -s

A Cat6513 with dual sup720-3Bs, 11 6548-GE-45AF blades, and assuming 5W PoE per port (I've been told that the Avaya 4621SW phone typically takes 4.9W) times 432 ports (2 of the 6548s don't have PoE devices connected), the total power draw will be 4749.57W. How long a UPS can sustain delivery of this amount of power is something I can't answer. As for the Cat6509, the only change is that the PoE ports go down to 240 (5 x 48 = 240). The total power draw is 2992.19W. As for the 4507R, I'll assume dual 4516 sups, five 4548-GB-RJ45V blades (is that right?), plus 144 PoE devices. The total power draw is 1465.99W. P.S. BTW, if you had a CCO ID, this is one of the tools you'd have access to directly. http://tools.cisco.com/cpc/

A Cat6513 with dual sup720-3Bs, 11 6548-GE-45AF blades, and assuming 5W PoE per port (I've been told that the Avaya 4621SW phone typically takes 4.9W) times 432 ports (2 of the 6548s don't have PoE devices connected), the total power draw will be 4749.57W. How long a UPS can sustain delivery of this amount of power is something I can't answer. As for the Cat6509, the only change is that the PoE ports go down to 240 (5 x 48 = 240). The total power draw is 2992.19W. As for the 4507R, I'll assume dual 4516 sups, five 4548-GB-RJ45V blades (is that right?), plus 144 PoE devices. The total power draw is 1465.99W. P.S. BTW, if you had a CCO ID, this is one of the tools you'd have access to directly. http://tools.cisco.com/cpc/