To process an integrity check on an SQLite database:
$ sqlite3 database.sqlite 'pragma integrity_check'
Author Archives: Jay Jay
mb_strimwidth
Today I learned about mb_strimwidth, very handy in a tight spot. It’s worth a review of the sidebar for other multibyte string options.
Apache2 RewriteCond %{REQUEST_FILENAME} !-f not working
I was having an issue with my Apache2 config not matching files with:
RewriteCond %{REQUEST_FILENAME} !-f
I didn’t really get to the bottom of the problem, but I found that prefixing with the document root solved my issue:
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
I have no idea why Apache wasn’t resolving %{REQUEST_FILENAME} relative to the project root, but I have a solution, so I have moved on.
PHP Security Best Practices
I found an interesting article: Linux 25 PHP Security Best Practices For Sys Admins
php -d xdebug.profiler_enable=1
So to enable profiling on the command line run your script in PHP like this:
php -d xdebug.profiler_enable=1 /path/to/script.php
You need to have configured xdebug in php.ini, I do it with a file in /etc/php/7.2/cli/conf.d/xdebug.ini that looks like this:
;xdebug.profiler_enable = 0 xdebug.profiler_output_dir = "/tmp/xdebug" xdebug.profiler_output_name = "cachegrind.out.%p"
Note: you can enable profiling for all scripts with xdebug.profiler_enable = 1
How to use Keji Flat File A4 Report Covers
So I purchased a Keji Flat File A4 Assorted Colours 6 Pack from Officeworks but when they arrived I wasn’t sure how to use the fasteners.
I searched for how to use keji flat file but didn’t turn up much.
Reading about Keji Flat File Report Covers on eBay I learned that the correct term for the fasteners is “prong fastening system”.
So I searched for how to use prong fastening system and found what I was looking for!
Configuring PowerShield DEFENDER UPS batteries
So today I added a Power section to John’s Linux page.
Particularly some notes on using the ‘upsc’ and ‘upscmd’ commands in Reporting on PowerShield DEFENDER UPS status and Run commands on PowerShield DEFENDER UPS batteries sections.
GRUB_CMDLINE_LINUX_DEFAULT
I had a system which failed to boot. The last lines printed to the screen, which were not relevant to the problem, were:
[19.957783] async_tx: api initialized (async) [20.899732] Btrfs loaded, crc32c=crc32c-intel
Then a little bit later:
[32.469926] random: crng init done [32.470551] random: 7 urandom warning(s) missed due to ratelimiting
The full problem description is here. And the solution is here (careful about the typo on that page, the only relevant setting is GRUB_CMDLINE_LINUX_DEFAULT).
Basically the problem was a bogus GRUB_CMDLINE_LINUX_DEFAULT setting in /etc/default/grub applied by my salt config. I fixed the setting which fixed the issue.
ata5: SATA link down (SStatus 1 SControl 300)
So I was getting error messages like this:
Jun 15 02:56:45 trust kernel: [ 127.165096] ata5: SATA link down (SStatus 1 SControl 300)
Jun 15 02:56:45 trust kernel: [ 127.165105] ata5: EH complete
Jun 15 02:56:45 trust kernel: [ 127.174488] ata5: exception Emask 0x10 SAct 0x0 SErr 0x4040000 action 0xe frozen
Jun 15 02:56:45 trust kernel: [ 127.178637] ata5: irq_stat 0x00000040, connection status changed
Jun 15 02:56:45 trust kernel: [ 127.182700] ata5: SError: { CommWake DevExch }
Jun 15 02:56:45 trust kernel: [ 127.186842] ata5: hard resetting link
The ‘ata5’ indicated SATA disk 5, being /dev/sde. Depending on which disk is affected you might see ‘ata1’, ‘ata2’, ‘ata3’, ‘ata4’, etc.
The problem seemed to be a loose cable. I have removed that drive (and its cables) and the problem has gone away.
Omitting date completed from MySQL dump file
By default when you run a dump with ‘mysqldump’ the date of the dump is appended to the file, e.g.:
jj5@love:~/desktop/experiment$ udiff * --- dbt__jj_dev_1__svn_jdrepo.1.sql 2019-06-11 18:11:13.267758230 +1000 +++ dbt__jj_dev_1__svn_jdrepo.2.sql 2019-06-11 18:12:03.856075974 +1000 @@ -32,4 +32,4 @@ /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */; /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */; --- Dump completed on 2019-06-10 21:59:44 +-- Dump completed on 2019-06-10 12:06:49
This causes dumps for a single database that has not changed to have two dumps which differ. It’s better to have dumps from the same unchanged database to be the same. To facilitate that add the –skip-dump-date option when running ‘mysqldump’.
See here for the back-story.