One of the machines will be co-located at FS Data and run ownCloud. I’m currently running three Raspberry Pi projects, with Raspbian as my choice of distribution. Now my web server should work much better! But the upside is that I could just disable FeedWordPress and delete all syndication_item_hash entries from the wp_postmeta table. Unfortunately is quite low priority for me, and the blogs I have been syndicating seem quite dead. These are added by the FeedWordPress plugin. A quick check revealed that it contained thousands of syndication_item_hash entries. In the database I found the wp_postmeta table. What’s that? Well, had a look in the database. So, it fails when updating the postmeta cache. In WP_Query::query called at /usr/share/wordpress/wp-includes/query.php (2791) In WP_Query::get_posts called at /usr/share/wordpress/wp-includes/query.php (2695) In update_post_caches called at /usr/share/wordpress/wp-includes/query.php (2534) In update_postmeta_cache called at /usr/share/wordpress/wp-includes/post.php (4113) In update_meta_cache called at /usr/share/wordpress/wp-includes/post.php (4133) In wpdb::get_results called at /usr/share/wordpress/wp-includes/meta.php (295) In wpdb::get_results called at /usr/share/wordpress/wp-includes/wp-db.php (1413) New Relic shows the stack trace, with the failing line on top: One of my WordPress sites, has been suffering from this out-of-memory error for quite some time now and I finally tracked it down.
MOSH SERVER UPNP FREE
Here's a ~/.I’m a very happy user of New Relic for my websites, even if I’m only leeching on the free tier. However, in this case, I have my ~/.zshenv on those hosts configured to override this variable by substituting that component with the machine's public IPv4 address, which we can easily obtain from OpenDNS: dig -4 +short ( Google Public DNS has a similar feature: dig -4 TXT +short. | tr -d\") Said server IP is whatever IP address that sshd answered on – so it will be the behind-NAT address (e.g. But it also supports a flag that will make it read the remote IP of the server from the SSH_CONNECTION environment variable, which is usually set by sshd before spawning a shell. mosh-client needs to know where to send its packets, and since usually you're simply giving it a hostname, it just resolves that and goes off on its merry way. The second piece combines an experimental mosh feature with a kludge of my own. I tweaked it to reference /usr/bin/mosh-server directly, so that you can just save the script as ~/bin/mosh-server on your machines that need ports forwarded and it'll happen automatically no extra client-side configuration needed. The original was posted to years ago now, but requires you to provide a -server mosh-server-upnp argument to each of your mosh client invocations. The first piece is well-known in the mosh user community: a script that wraps mosh-server and invokes upnpc to ask your home router to expose a UDP port to the world. Doing so requires two extra moving parts. But, what you can do is use those techniques as a sort of rendezvous to authenticate and establish a direct mosh session. But since mosh uses UDP, of course it can't traverse neither Tor nor sidedoor's SSH tunnelling. I've long been a fan of mosh for minimizing SSH latency it works incredibly well even over a crappy mobile connection. Tor in particular is pretty miserable to use for an interactive SSH session it's more of a last-resort thing. However, both of these approaches add latency. I added convenient Host aliases for both of those methods to my ~/.ssh/config file, so for instance ssh foo.sidedoor is enough to connect to foo via its sidedoor. (If you aren't familiar with them, both of these approaches work by opening TCP client connections to Somewhere Else, whether that be a remote sshd or a remote Tor relay, and then allowing traffic to flow ‘backwards’ along the connection.)
The sidedoor package, which I tweaked some to work as a templatized systemd unit, so I could have one sidedoor via a VPS host, and one via my home Raspberry Pi.So, to ensure I could do all that, I set up two fairly standard ways of traversing NAT to get remote SSH access: But, pi-hole needs reconfiguration once you assign it an IP address - which I couldn't exactly do for them ahead of time - and, I wanted to be able to fix the devices should something go wrong (as well as ensure they stay patched and secure, even though I set up the usual stuff like unattended-upgrades). I recently gifted two Raspberry Pis preconfigured with the Pi-Hole DNS adblocker to family members to run on their home networks.
0 kommentar(er)
