Creative Productions, Arrangements and Operations • Art, Technology and Amusements. Software Engineer and certified FileMaker Pro developer and full-stack web developer by day, https//www.kupietz.com
N8n by default binds to localhost, and even binding it to listen on all interfaces, it still by default listens only for IPv6. You also may want to tell it to not use the Secure Cookie if you don't want to set up an SSL certificate or sign up for their cloud service. Make sure you only have it reachable on the local network if you do this, you don't want to open your instance to the entire world.
I had a truly maddening problem where my /embed/ functionality was sometimes returning full pages to CURL commands and online services like redirect-checker.org, etc.
It turned out, it was Yoast's URL parameter stripping. I had failed to update Yoast's settings with some new parameters I was using, and what Yyoast never tells you is that when you're logged in, it lets everything work fine, and only strips parameters for non-logged in users. It just lets you proceed on your way thinking everything is working fine until you can't figure out why curl -I https://mysite.com/blah?param1¶m2 is getting a 301 redirect while https://mysite.com/blah?param1¶m2 is loading fine in your browser. This is especially fun on sites like mine where things like /embed/ and ?embed get written back and forth to each other internally.
I lost several hours to this.
Yoast's docs say there's a way of registering parameters but,…
The problem was, I needed to make some changes to how that code functioned, and I couldn't find where I had added the script that did that.
Long story short: I temporarily added this script to the head of the page, and then reloaded it with an #anchor added to the URL, in this case [code]https://michaelkupietz.com/literally-hundreds-capsule-reviews/#puzzlehead[/code]:
[code] // Override the open property setter to catch when…
Here's the SQL query to get all post revisions, which I do prior to cleaning them out of the database, which seems to make it much faster:
SELECT p.* FROM [posts table name] p WHERE (p.post_type = 'post' OR p.post_type = 'page') -- Include posts/pages AND (p.post_date BETWEEN '2020-01-01' AND '2029-07-01') -- Adjust date range OR (p.post_type = 'revision' AND p.post_parent IN ( SELECT ID FROM [posts table name] WHERE post_date BETWEEN '2024-01-01' AND '2024-07-01' ));
To get just a count of revisions, change SELECT p.* to SELECT count(*).
I removed a bunch of wildcard paths from rsnapshot.conf's exclude, and suddenly tonight my backup ran in a few minutes instead of taking over a day like it usually does.
Interesting, I've been looking off and on for at least the better part of a year for ways to lighten the load of rsnapshot's under-the-hood rsync backup commands, which reliably took up about half my CPU power almost continuously, and never found this tip before. You can see, plenty of wildcard paths removed, plus a few other things.
Here's a diff, rsnapshot.conf before changes (<) vs after (>): < verbose 1 --- > verbose 4 120c120 < loglevel 2 --- > loglevel 4 143a144,146 > rsync_short_args -Wa > #-W is transfer whole files without prescan, recommended for performance by https://serverfault.com/questions/639458/rsync-taking-100-of-cpu-and-hours-to-complete > #NOTE: if you set the above short…
I had an interesting problem where I set an image's CSS rules to display:fixed and it still scrolled with the page. Here's what I discovered:
In CSS, display:fixed means fixed with regard to the nearest ancestor stacking context, not necessarily to the page coordinates. You can reset the stacking context by adding a transform, will-change, or other attributes (list provided below) to an element. If an ancestor element resets the stacking context, any descendant of it with display:fixed will stay fixed with regard to it, but if it scrolls with the page, will scroll too.
Ditto for the CSS attribute z-index. A higher z-index is only in front of objects in its stacking context. A new stacking context, lower down on the page, can contain elements with a lower z-index but that nonetheless appear in front of it visually, because they're not in the same stacking context.
- added var_dump(opcache_get_status()) to php status page to be able to monitor opcache usage
- changed warning logs from E_ALL & ~E_DEPRECATED & ~E_STRICT to ---- noticed contained a LOT of processes being stopped for tracing turned off request_slowlog_timeout by setting to 0s in had been 4s --- I had turned on lightspeed at 1:45 am est , aug 26. Seems like more problems since then.
None of the above seem to help, still getting freezes maybe every 30 minutes. Next…
I discovered rsnapshot hadn't run in a few days. Checking /etc/rsnapshot.log, I found every recent day had this:
rsync: --delete does not work without --recursive (-r) or --dirs (-d). rsync error: syntax or usage error (code 1) at main.c(1795) [client=3.2.7]
A few days ago I had added the line rsync_short_args -W to /etc/rsnapshot.conf in an effort to get rsync to run without putting such a load on my system. Removing this and running rsnapshot -v hourly from the command line shows that without it, the first line of the rsync command was /usr/bin/rsync -ax --delete --numeric-ids --relative --delete-excluded \, but with it, the first line was /usr/bin/rsync -Wx --delete --numeric-ids --relative --delete-excluded \.
Changing the line rsync_short_args -W to rsync_short_args -Wa, with an a flag explicitly included, solved the problem. Apparently specifying custom short flags overrides at least one of the default flags.
There are intentionally vague broad steps, here just as a reminder to myself; best to look specific instructions for each of these steps up at restore time for the particular system you're restoring to.
A.) Backups should include all user data. Depending on who you ask, that's either: 1.) The entire filesystem except /dev/*, /proc/*, /sys/*, /tmp/*, /run/*, /mnt/*, /media/*, /lost+found (which can be pulled from a complete filesystem backup with rsync -avhP --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt/olddrive/ /mnt/netdrive/) 2.)/home, /etc (except /etc/passwd and /etc/groups, these have useful information to back up but may conflict if written to a new install), /usr/local, /opt, /root, /var (exluding /var/tmp, /var/run/, /var/lock, or /var/spool except you DO want /var/spool/cron/crontabs/)
B.) After copying all the above to the new or restored disk, you need to update /etc/fstab with the new disk UUIDs.
Per numerous references around the web, to delete /path/to/directory-to-delete/:
cd /path/to/ mkdir empty_dir rsync -a --delete empty_dir/ directory-to-delete/ rm -r empty_dir rm -r directory-to-delete
Disclaimer: this is for my own reference, not recommended for your use. Use it at your own risk. If I am wrong—and I may be—these commands can do tremendous damage to your system.
My VWWare VM lost internet connectivity after a reboot. Even the host machine could not access any service on it. Http/https got 523 errors.
I powered down the VM, changed the networking to NAT, powered it back up, shut it down again, changed the networking back to Autodetect, booted it again, and everything seemed fine.
I've had sporadic problems with clearing the WP cache causing the server to return 520 errors for a few minutes. Usually other sites on the same server are fine, it's specific to this vhost. Logging in via SSH, checking with htop, rsync is usually hogging most of the cpu. Restarting the fpm and then restarting Apache restores the website.
According to https://www.claudiokuenzler.com/blog/361/rsnapshot-backup-reduce-high-load-with-ionice, the big bottleneck with rsync, which rsnaphot runs on, is i/o, not cpu, and rsync can actually tie up i/o such that a web server won't respond to http requests. This can be solved by making the rsnapshot command in crontab ionice -c 3 [rsnapshot command] instead of just the rsnapshot command, which tells rsync not to wait until the disk is idle before trying to access it. So I did. In fact, I made it nice -n 19 ionice -c 3 [rsnapshot command] although…
Use code you find here at your own risk! I am not responsible if you damage your data or system by following any instructions you find here.
Navigate to your plugin's root directory:
Bash
cd /home/kupietzc/public_html/kartscode/wp-content/plugins/ktwp-draggable-elements
Fetch the latest changes from GitHub: Bash
git fetch origin
Perform a hard reset to match GitHub's main branch (assuming main is your branch):
Bash git reset --hard origin/main
WARNING: This command is destructive. It will discard all local changes to tracked files and make your local repository exactly match your GitHub repository. Ensure you have a backup of any local modifications you wish to preserve that are NOT on GitHub before running this.
Clean up any untracked files or directories (remnants from manual copying): …
I don't know if this affects other versions of Photoshop, but on MacOS Photoshop CC 2017 frequently starts unexpectedly graying out all save buttons when you have made changes to your file and should be able to save.
The secret is to resize and move around the dialog. Drag the lower right corner to make it bigger and smaller a few times, and try dragging the whole dialog to the upper left corner of the screen and making it small.
I installed the WordPress plugin LWS Optimize, which turned out to be unusably broken (which is the reason I'm not linking to it) and made my site unusable. To make matters worse, when I tried to deactivate it, it told me it deactivated... and was still active. I went in through FTP and deleted the plugin folder entirely, and then WordPress said it had been deactivated because it couldn't be found... and it still showed as present and activated in the plugin list.
Had a weird one today. Last one website of the several of on this server suddenly started returning 503 (service unavailable) errors. There was nothing in the PHP error log or Apache error log. All server configs are already thoroughly optimized for performance. Other websites on the same server were functioning normally.
I didn't notice this at the time, but my uptime monitor didn't report an outage. When I used redirect-checker.com to check the status code, it returned 200, which should have been a clue, also.
Next time, before doing all sorts of arcane troubleshooting: 1. Try with a different browser 2. Is there a CDN? Try bypassing it. 3. Are you using a VPN? Try selecting a different endpoint (VPN server) if it will let you, or turning it off.
I use the NordVPN plugin in Firefox, and quic.cloud is my…
This command shows your system's total, used, and free memory in a human-readable format.
Key metrics:
total: Total RAM.
used: RAM currently in use.
free: Unused RAM.
buff/cache: RAM used for file system buffers and page cache. This is good; Linux uses free RAM for this and frees it when applications need it.
available: The most important metric. This estimates how much memory is available for starting new applications without swapping.
Run it before and after: Run free -hbefore you increase max_children and then after your server has been running for a while under typical load with the new settings. Compare the available memory.
Add or change /etc/cron.d/sysstat to this. This creates a cron jobe to write file /tmp/outage_resource_log.txt that keeps minute-by-minute stats, sometimes useful in troubleshooting slowdowns. However, it's not a great way to do things, it create a small, constant resource drag, so disable it when done troubleshooting.
# The first element of the path is a directory where the debian-sa1 # script is located PATH=/usr/lib/sysstat:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin
# Activity reports every 10 minutes everyday #ORIGINAL DEFAULT WAS 5-55/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1 #uncomment above line and comment out /tmp/outage_resource_log.txt lines to restore original functionality * * * * * root date +"%Y-%m-%d %H:%M:%S" >> /tmp/outage_resource_log.txt * * * * * root sar -u 1 1 >> /tmp/outage_resource_log.txt 2>&1 * * * * * root sar -r 1 1 >> /tmp/outage_resource_log.txt 2>&1 * * *…
This was a system service that ren every time the CPU spiked and logged what was running. Mostly it showed that php-fpm was what spiked the CPU. Fascinating.
daemon was at /etc/systemd/system/mk-cpu-watcher.service [Unit] Description=CPU Usage Watcher After=network.target
For confused first-time visitors and other people still acclimating, here is a description of these little tabs to the left, as well as some other features of the site.
Open "Expert Mode" CLI Navigation - this give you the option to switch your browser's display to an old-fashioned terminal mode where you may browse this site, view pages and images by typing text commands. Just like how we used to browse the web back in 1978!
Open Visual Settings - This gives you controls to customize the visual display of this website to your liking: turn up or down the brightness, contrast, color temperature, hue, saturation, dark mode, and earthquake. Settings are saved per browser tab, so they will be remembered for your whole visit.
Open My Eyes - Have you ever been engrossed in your work, when you suddenly realize someone is staring at your screen, watching everything you do over your shoulder? If not, this simulates the experience.
Open Help - This help popup, silly! You just clicked it! Do you not remember?
New - Draggable elements! Several elements on this website, including these tabs, this popup message, and the "Hire Mike" badge in the lower right, can be dragged around with your mouse, to avoid them blocking content. Positions are remembered per tab, so as you navigate around the site, they will stay in the same place for your whole visit.
Enjoy!
CLI Website Navigation
Are you sure you want to switch to viewing this website in the "expert mode" command-line interface?
This will switch to a terminal emulator, load this page, and allow you to browse this website and view its contents by typing text commands.
Plus there might be, y'know, some fun stuff hidden in there. Just for geeks.
