After uploading/copying the files from the upload directory to a osTicket installation in order to upgrade it to osTicket 1.9.14, I got the error message ‘Access denied’ when trying to login as administrator to finalize the upgrade. Deleting the osTicket session cookie did not help either.
It turned out that the problem was that all files in the distribution ZIP-file had file permission ‘000’ causing the trouble. A ls -l looked like this:
---------- 1 webNNN clientX 5162 jun 11 18:22 login.php
---------- 1 webNNN clientX 980 jun 11 18:22 logo.php
---------- 1 webNNN clientX 714 jun 11 18:22 logout.php
---------- 1 webNNN clientX 1584 jun 11 18:22 main.inc.php
---------- 1 webNNN clientX 930 jun 11 18:22 offline.php
---------- 1 webNNN clientX 2830 jun 11 18:22 open.php
A simple fix was needed. Make sure you are in the upload folder of the unpacked distribution zip when you do this:
chmod 644 `find . -type f -print`
A Mac suddenly displayed the message “Your startup disk is almost full” to the user. However, there should be plenty of space left on the disk. Something was eating up the disk rapidly.
Some investigation using Activity Monitor showed that a process called fontworker was also eating a large chunk of the CPU as well. In the Terminal I entered the command:
sudo du -sm *
to find out what folder was using most space (the command requires admin privileges so it will prompt you for the administrator password). I then entered:
sudo du -sm *
to find out what was using most space in the largest folder (replaced by “the-folder-name” in the example above). I repead the steps until I found a large file containing the fonts database occupying about 85 GB which is way more than normal.
It turned out the fonts cache had become corrupt.
To rebuild the font cache was easy. By simply restarting the computer into Safe mode and then reboot it back into normal mode, the font cache was cleared and rebuilt, solving both the disc and CPU problem.
Problem with the fonts sometimes occurs after OSX reinstall which in this particular case had been performed about a week ago.
When working with template files like css in Joomla the codemirror editor is used. However, a great annoyance is that it is not possible to use the browser search (CTRL-F) to find code. When your css becomes large this can be really annoying.
There is a search addon available for codemirror however. This is how you add it to your codemirror editor in Joomla:
Download these files:
Upload the files into your Joomla and place them in the <Joomla root>/media/editors/codemirror/lib directory.
Edit the file <Joomla root>/plugins/editors/codemirror/layouts/editors/codemirror/init.php
Find the two lines (around line 19-20) looking like this:
JHtml::_('script', $basePath . 'lib/codemirror' . $extJS);
JHtml::_('script', $basePath . 'lib/addons' . $extJS);
After them, add the following lines:
JHtml::_('script', $basePath . 'lib/search.js');
JHtml::_('script', $basePath . 'lib/searchcursor.js');
Save the file and enjoy searching in codemirror using the commands described in the search addons page (like CTRL-F etc)!
Note: A future possible system update will however overwrite the changes made in init.php.
Solution by Stefan Helander, HelTech Communication AB.
To find all files modified on, for example, January 21 2013:
find . -newermt 2013-01-21 ! -newermt 2013-01-22
When you are dealing with a hacked or otherwise compromised website where someone has installed a backdoor or other kinds of malicious code you will often find php files with code packed into non-readable format using php eval, like
To find out what the code does, copy the entire eval code (including “eval(“) into this site: http://ddecode.com/phpdecoder/
You will in the end get a human readable version of the code. Usually nasty stuff.
USB memory sticks or external disks that has been formatted on a Mac might not be readable if you connect it to a Windows computer. The reason is that the Mac has formatted it using a file system unknown by Windows.
To read the disk you can use the free tool hfsexplorer.
If you have your contacts exported into .vcf files, they can easily be imported into for example iCloud, Google or your email program. However, if you have a couple of hundreds or thousands of contacts, and equally amount of .vcf files it will be very inefficient to import each contact one by one.
A solution is to combine all contacts into one single .vcf file. By importing the combined .vcf file all your contacts are imported at once.
To combine all .vcf files into a single one can easily be done using a Windows command prompt (cmd).
copy *.vcf allcontacts.vcf
Now import the file allcontacts.vcf into iCloud or similar.
When trying to upgrade Magento from 2.0.2 to 2.0.4 I got a windows saying Update in progress and the last line from the system log says “./composer.json has been updated” then nothing more happens for quite a long time. Finally an error screen displays “Error in Update!”.
To restart the update process while trying to figure out the error i had to manually delete the files var/.maintenance.flag and var/.update_in_progress.flag.
Magento System Upgrade error
To make Magento run in Apache we had set php.ini for the web user to memory_limit=1024M and according to instructions, the cron jobs should be called with the -c pointing to the php.ini used by the web server, in our case /etc/php5/fpm/php.ini.
No error message revealed why the update failed but I found out that the php.ini we used for cron (/etc/php5/fpm/php.ini) had a memory_limit=128M. By editing this file and increasing it to 1024M the update worked.
When running the Magento readiness test it failed with the message that always_populate_raw_post_data should be set to -1 since it is running under php 5.6. Even though I tried different methods of setting it to -1 and I could verify it by calling phpinfo(); Magento still complained.
The way I solved is a bit rough and it required that I had full system administrator access to the machine (which I had because it was a dedicated server). This is how I solved it:
echo "always_populate_raw_post_data=-1" > /etc/php5/mods-available/always_populate_raw_post_data.ini
service php5-fpm restart
service apache2 restart
First of all, check the Magento guide on this problem here.
In my case, at first I didn’t get any errors in the cron logs in <web-root>/var/log. When running the scripts by hand as the website user I got the not so informing “Cron readiness check failed” in the <web-root>/var/log/update.cron.log.
The reason the “Cron readiness failed” was actually due to some files in the file and directory structure in the web root that can not be written by the cron update script. In my case I used the AWstats package to create website statistics placed in a directory called /stats. This directory and it’s file was not writeable by the cron script, causing it to fail, even though the directory /stats and it’s files are not a part of Magento.
I discovered this by investigating the content of the file var/.update_cronjob_status. In this file you can find important information on why the cron update script is failing.