So today I used a mysql replication check found here:
But I couldn’t get it to work. I created the /usr/lib/check_mk_agent/local/ folder that all of the documentation says you need to put the script into. I reinventoried, and did everything. It wasn’t being found. Then after an hour of searching I came across this gem:
check_mk_agent | head | grep Local
It told me that my local folder was in a different spot:
[root@web2 check_mk_agent]# check_mk_agent | head | grep Local
I moved the script there and wham! It worked!
So we’ve recently worked on converting Debragga.com into a Magento site from a very uncommon platform called vsadmin. It’s been absolutely stellar. The design and everything else transferred over, so it was mainly just a back end conversion. But we’ve seen seo rankings increase, ease of updating products and descriptions, and the availability of all the opportunities that the magento eco system has to offer.
We’ve configured everything as bundled products since everything in the warehouse is a single “part”. Everything on the site is then broken down into a package containing the sku’s of all the parts that make up the package. This has helped simplify the pick and pack process tremendously and allowed for quicker training and the allowance of seasonal pickers and packers to assist during busy times.
WHen greeted by the error message:
Attribute 'setup_version' is missing for module
This is because the attribute schema_version has changed to setup_version at some point in the M2 development cycle.
Should now be:
Magento 2 Recoverable Error: Argument 1 passed to Training\Test\Controller\Action\Config::__construct() must be an instance of Magento\Framework\App\Action\Context
I’m creating the test module form the Magento 2 Development Fundamentals course from Magento and ran accross the below error:
Recoverable Error: Argument 1 passed to Training\Test\Controller\Action\Config::__construct() must be an instance of Magento\Framework\App\Action\Context
I found out that the example they gave, they omitted the constructor in the Config.php controller. So let’s add that in:
public function __construct(
$this->resultPageFactory = $resultPageFactory;
Then lastly, since I already tried to run it, I had to clear out some of my var folders and then recompile:
[bessig@dev htdocs]$ sudo rm -Rf var/generation/*
[bessig@dev htdocs]$ sudo rm -Rf var/di
[bessig@dev htdocs]$ sudo rm -Rf var/cache/*
[bessig@dev htdocs]$ sudo rm -Rf var/page_cache/*
[bessig@dev htdocs]$ bin/magento setup:di:compile
Hopefully this helps someone.
Also they did not supply a routes.xml The one I used is as follows:
The page you will call using this route will be:
Hopefully this saves someone some time! Let me know if your one of the people it helped!
So we use check_mk pretty extensively for all of our servers for health monitoring. Today we added a brand new bare metal centos 7 minimal install on-sit test server to nagios.
We were getting this strange service when we added the box to be invetnoried:
CRITICAL 06-29-2015 13:43:49 3d 5h 14m 51s 3/3 CRIT - mathias-kettner.de could not be resolved
I couldn’t figure out what this check does so I took a peak at the git repo, and saw that its doing a nslooup. Well my box didn’t have nslookup installed, so a quick
sudo yum install bind-utils -y
seem to do the trick!
After changing a magento store to run on ssl in development we found ourselves facing redirect issues. This is most likely because of the way we are doing ssl on our local development environment.
In order to fix, add this:
SetEnv HTTPS on
to the bottom of .htaccess Case is sensitive in Magento so make sure on is “on” NOT “On” or ON.
run: svn propedit svn:ignore .
Then paste below.
So we had a customer call in today saying that order notification emails for their site were not going out. They run on Magento 1.9.1 which has implemented a new email queue system for magento. They receive about 100-1,000 orders a day, which can mean several thousand emails, since each order gets several emails post order (order confirmation, order update, order shipping/tracking number, follow up email).
So the first thing I did was place a test order on production. I did not receive the email. I looked in the /var/log/messages for the server and searched for my email address. It was not in there. I did notice other email’s in there, including the account creation email, which I almost dismissed to the client as the order email. This email is not queued like the order emails so it immediately gets sent out.
So this was a bit scary, not seeing the email in the system /var/log/messages then I remembered about the queuing Magento has, and that it runs from cron. I looked for a locked up cron by doing ps aux |grep cron but nothing came up. It looked like no cron was locked. I then remembered the client had AOE Scheduler installed. I browsed to system->scheduler->list view.
In the table we had to select core_email_queue_send_all and click on the search button. This limits the table view to this value. I had something like 28 results found, but my view filter was set to show 25 at a time. So I could not see the trouble 3 at the end. I switched to show the view at 50 which showed me all of my results and I noticed the last item was a “RUNNING” process from several days ago. There were a few “MISSED” processes before it.
I then selected the RUNNING row and selected “kill” from the actions window. It then said it would kill on the next cron run. This meant that I had to wait two minutes to check back. I checked back and it was still there. I then selected the row and clicked on “delete” from the action drop down and this immediately removed the row. I waited two minutes and refreshed the page and it was now running. I also started noticing through mailgun that the emails were sending but I didn’t get mine. This is because the most emails magento will process in one cron is 100. This means if you have 3,000 in queue, it will take 30 minutes to get them all out.
You may also need to do this with newsletter_send_all.
Delete the last commit
Deleting the last commit is the easiest case. Let’s say we have a remote mathnet with branch master that currently points to commit dd61ab32. We want to remove the top commit. Translated to git terminology, we want to force the master branch of the mathnet remote repository to the parent of dd61ab32:
$ git push mathnet +dd61ab32^:master
Where git interprets x^ as the parent of x and + as a forced non-fastforward push. If you have the master branch checked out locally, you can also do it in two simpler steps: First reset the branch to the parent of the current commit, then force-push it to the remote.
$ git reset HEAD^ --hard
$ git push mathnet -f
Originally taken from Christoph Copied here for reference.
For NYC Web Design check out the link.
I saw the check_mk added the ability to monitor the qmail mail queue, so I wanted to get that setup on a few plesk servers. The auto inventory wasn’t seeing the qmail and therefore wasn’t adding the check. It turns out that two things were wrong:
- I updated the check_mk agent on the plesk server, but didn’t update the check_mk software on the nagios host. I needed to install the latest version in BOTH places to get it working.
- Plesk uses its own paths, so we had to symlink /var/qmail/bin/qmail-qstat to /bin/qmail-qstat
ln -s /var/qmail/bin/qmail-qstat /bin/qmail-qstat
I spent way too much time figuring that out. Hopefully this post will help the next poor soul!