antipaucity

We raise chickens.

For the last few years, we’ve only had layers – and they’ve all been full-grown by the time they arrived at our home.

This year, we decided to buy some chicks because our layers are starting to age-out of being able to lay, and we’re interested in trying our hand at raising a few birds for butchering ourselves.

Since you need to wait to add new birds to your flock until the birds are 6+ weeks old, we need a place for them to grow (they were ~8 days old when I bought them).

Here are some pictures of the first collapsible coopette for your viewing pleasure – after which I’ll describe how I put these things together ?

The first one (shown above) was the initial implementation of my idea…in which we decided hinging the access door on the top is less than ideal, and we discovered we need 3 hasps to hold the ends on rather than 2.

Materials used:

• Pressure treated 1x6x8 fence pickets (bought 29 for both coopettes, ended-up with about 3.5 left over – the second coopette is sturdier (and a little prettier)
• Half-inch opening, 36″ wide hardware cloth (need ~22′ per coopette; ~30′ if you choose to make bottoms (I opted to not make coopette bottoms this time around)
• Quarter-inch opening, 24″ wide hardware cloth (happened to have a perfectly-sized piece left from another project I could use on the second coopette door)
• Staples
• 1 1/4″ ceramic-coated deck screws
• 2.5″ hinges (5 per coopette … though I wish I’d gone with 3″ hinges instead)
• 3″ hasps (7 per coopette)

When folded-up, the sides collapse to ~3″ thick. The ends are about 2″ thick, too.

Total space needed against the side of your garage/shed/etc to store the coopette when you aren’t actively using it is ~3′ x 8′ x 6″, or slightly more than a folding table ?

Construction was very simple – I made the sides a smidge over 36″ wide so that I could attach the hardware cloth without trimming for more than length ?

The ends have a pair of 36″ long boards cut into trapezoids with 30° ends, and a butted ~30″ trapezoid, again with 30° ends (see photo for detail). The butt joint is secured via stapled hardware cloth (wrapped around from the outside to the inside (see photo), and a small covering inside screwed into both upright pieces. I used various pieces of scrap for those butt joint covers

Wrapping the hardware cloth around the ends was the single most time-consuming (and painful!) aspects of construction. Start with a 36″x36″ piece, laid-out square to the bottom of the end. Clamp in place (these 3″ spring clamps from Harbor Freight were a true godsend), and staple as desired … I may have gone a little overboard on the stapling front ?. On the second coopette, I relied more on sandwiching a little extra fence picket material to capture the hardware cloth, and a little less on staples.

Lessons Learned

Prototype 1 was quick-and-dirty – too much stapling, shouldn’t have had the door hinge at the top, needed to be more stable (sandwich the hardware cloth better)

And two hasps holding the ends on is not sufficient – you need three (one more-or-less at each corner) to really keep the end locked well, and to enable easy movement

Prototype 2 was not as dirty … but moving from fence pickets to 5/4 would be preferable

Likewise, wish I had put enough support at the bottom to be able to put some casters on at least one end to facilitate moving around the yard (to prevent killing-out the grass underneath)

What would I do differently in the future?

• Make them longer than 8 feet (if you use 5/4 deck boards, buy the 10, 12, or 16 foot variety)
• Make the sides slightly higher than 36″ to reduce the need for cutting hardware cloth (a very time-consuming task!)
• Add wheels to one end for easy movement
• Plan for an suspended waterer (the gap at the top happened to be wide enough to sling on up using a little rope and a couple carabiners – but it easily could not have been)
• Hard-roof one end instead of using a tarp … or use a slightly larger tarp that would cover multiple coopettes at once instead of small ones that cover one at a time

I’ve recently been asked by several people to investigate websites (especially e-commerce ones) for reliability/legitimateness.

Thought someone else may find my process useful, and/or have some ideas on how to improve it ?

So here goes:

1. Pop a terminal window (I’m on a Mac, so I open Terminal – feel free to use your terminal emulator of choice (on Windows, you’ll need to have the Subsystem for Linux or Cygwin installed))
   1. Type whois <domain.tld> | less
      • I’ll use this domain (antipaucity.com) for an example
      • you may be able to use whois.com (eg whois.com/whois/antipaucity.com)
   2. Look at all of the following:
      • Creation (Creation Date: 2006-02-22T01:12:10Z)
      • Expiration (Registry Expiry Date: 2023-02-22T01:12:10Z)
      • Name server(s) (NS3.PAIRNIC.COM)
      • Registral URL (http://www.pairdomains.com)
      • Registrar (Pair Domains)
      • Contact info (should [generally] be anonymized in some manner)
   3. Possible flags:
      • If the domain’s under 2 years old, and/or the registration period is less than a year (we can talk about when short registrations may make sense in the comments)
      • If the name servers are “out of the country” (which, of course, will vary based on where you are)
      • If the contact info isn’t anonymized
2. Load the website in question in a browser (use an ingonito and/or proxied tab, if you like) and review the following types of pages:
   • Contact Us
     • Where are they located?
     • Does the location stated match what you expect based on the whois response?
   • About Us
     • Does it read “naturally” in the language it purports to be written in?
       • Ie, does it sound like a native speaker wrote it, or does it sound stiltedly/mechanically translated?
   • Does it match what is in the whois record and the Contact Us page?
   • Do they provide social media links (Twitter, Facebook, LinkedIn, Instagram, etc)?
     • What do their social media presence(s) say about them?
   • Return/Refund Policy (for ecommerce sites only)
     • What is the return window?
     • How much will be charged to send it back and/or restorck it?
   • Shipping Policy (for ecommerce sites only)
     • How long from submitting an order to when it ships to when it arrives?
     • Where is it shipping from?
   • Privacy Policy (only applies if you may be sharing data with them (ecommerce, creating accounts, etc)
     • What do they claim they will (and will not) do with your private information?
3. Is the site running over TLS/SSL?
   • You should see a little padlock icon in your browser’s address bar
   • Click that icon, and read what the browser reports about the SSL certificate used
   • Given that running over TLS is 100% free, there is absolutely NO reason for a site to NOT use SSL (double especially if they’re purporting to be an ecommerce site)

Reviewing these items usually takes me about 2-3 minutes.

It’s not foolproof (after all, better fools are invented every day), but it can give you a good overview and relative confidence level in the site in question.

Via the rands-leadership Slack (in the #i-wrote-something channel), I found an article written on ChealseaTroy.com that was [the last?] in her series on course design.

While I found part 9 interesting, I was bummed there were no internal links to the other parts of the series (at least to previous parts (even if there may be future parts not linked in a given post)).

To rectify that for my 6 readers, and as a resource for myself, here is a table of contents for her series:

1. What will students learn?
2. How will the sessions go?
3. What will we do in a session?
4. Teaching methods for remoteness
5. Why use group work?
6. Dividing students into groups
7. Planning collaborative activities
8. Use of surveys
9. Iterating on the course

She also has some other related, though not part of the “series”, posts I found interesting:

1. Learning to teach a course
2. Planning and surviving a 3-hour lecture
3. Resources for programming instructors
4. Syllabus design

If you notice future entries to this series (before I do), please comment below so I can add them 🤓

I found out about sshuttle from a random tweet that happened to catch my eye.

Here’s the skinny (from the readme):

• Your client machine (or router) is Linux, FreeBSD, or MacOS.
• You have access to a remote network via ssh.
• You don’t necessarily have admin access on the remote network.
• The remote network has no VPN, or only stupid/complex VPN protocols (IPsec, PPTP, etc). Or maybe you are the admin and you just got frustrated with the awful state of VPN tools.
• You don’t want to create an ssh port forward for every single host/port on the remote network.
• You hate openssh’s port forwarding because it’s randomly slow and/or stupid.
• You can’t use openssh’s PermitTunnel feature because it’s disabled by default on openssh servers; plus it does TCP-over-TCP, which has terrible performance.

Here’s how I set it up on my Mac

Install homebrew:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Install sshuttle (as a regular user):

brew install sshuttle

Test the connection to a server you have:

sudo sshuttle -r <user>@host.tld -x host.tld 0/0 -vv

I also made sure that my target server could be connected-to via certificate for my local root user – but you can use a password if you prefer.

Check your IP address:

curl https://ipv4.cf

Once you make sure the connection works, Ctrl-C to end the session.

Then setup an alias in your shell’s .profile (for me, it’s .bash_profile):

alias vpn='sudo sshuttle -r <user>@domain.tld -x domain.tld 0/0'

Other things you can do

According to the full docs, there are a lot more things you can do with sshuttle – including running it on your router, thereby VPN’ing your whole LAN through an endpoint! You can also run it in server mode.

This is a super useful little utility!

After a friend of mine told me he wanted to deploy Jitsi on my main webserver, and me saying “sure”, I decided I wanted to get it up and running on a new server both so I knew how to do it, and to avoid the latency issues of videoconferencing from central North America to Germany and back.

Before I go into how I got it working, let me say that the official Quick Start guide is good – but it doesn’t cover anything but itself.

Here’s the basic setup:

• CentOS 7
• Docker
• Apache 2.4

What To Do:

Once you have your new CentOS instance up and running (I used Vultr), here’s everything you need to install:

yum -y install epel-release && yum -y upgrade && yum -y install httpd docker docker-compose screen bind-utils certbot git haveged net-tools mod_ssl

I also installed a few other things, but that’s because I’m multi-purposing this server for Squid, and other things, too.

Enable Apache, firewalld, & Docker:

systemctl enable httpd && systemctl enable docker && systemctl enable firewalld

Now get your swap space setup:

fallocate -l 4G /swapfile && chmod 0600 /swapfile && mkswap /swapfile && swapon /swapfile

Add the following line to the bottom of your /etc/fstab:

/swapfile swap swap default 0 0

Restart your VPS:

shutdown -r now

Get your cert from Let’s Encrypt (make sure you’ve already setup appropriate CAA & A records for your domain and any subdomains you want to use):

certbot -t -n --agree-tos --keep --expand --standalone certonly --must-staple --rsa-key-size 4096 --preferred-challenges dns-01,http-01 -m <user>@<domain.tld> -d <jitsi.yourdomain.tld>

Create a root crontab entry to run certbot frequently (I do @weekly ~/renew-le.sh)

Go to the home directory of whatever user you plan to run Jitsi as:

su - <jitsi-user>

Begin the Quick Start directions:

• git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet
• mv env.example .env
• Change the timezone in .env from Europe/Amsterdam if you want it to show up in a sane timezone (like Etc/UTC)
• mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb}
• docker-compose up -d

Now configure Apache for SSL. Start with this reference I posted.

But in the [sub]domain-specific conf file z-[sub]domain-tld.conf, add proxy and authentication lines (so that only people you allow to use your video conference can actually use it):

ProxyPreserveHost on
ProxyPass / http://localhost:8000/ nocanon
ProxyPassReverse / http://localhost:8000/
ProxyRequests       off
ServerAdmin warren@warrenmyers.com
AllowEncodedSlashes NoDecode
<Proxy http://localhost:8000/*>
    Order deny,allow
    Allow from all
    Authtype Basic
    Authname "Password Required"
    AuthUserFile /etc/httpd/.htpasswd
    Require valid-user
</Proxy>
RewriteEngine       on
RewriteRule        ^/meetwith/(.*)$ http://%{HTTP_HOST}/$1 [P]
ProxyPassReverseCookiePath /meetwith /

Reload your configs, and make sure they’re happy, fixing any errors that may exist:

apachectl graceful

Setup at least one user who’ll be able to access the site:

htpasswd -B -c /etc/httpd/.htpasswd <user>

You should also configure firewalld to allow only what you want (http, https, ssh):

firewall-cmd --zone=public --add-service=http && firewall-cmd --zone=public --add-service=https && firewall-cmd --zone=public --add-service=ssh

With any luck, when you now navigate to https://[sub.]domain.tld in your web browser, and enter your username and password you created with htpasswd, you’ll get the Jitsi welcome page!

Other Resources:

• Check out the Jitsi subreddit – r/jitsi
• Jitsi on Twitter: @jitsinews

I want to backup all of the MySQL databases on my server on a routine basis.

As I started asking how to get a list of all databases in MySQL on Stack Overflow, I came across this previous SO question, entitled, “Drop All Databases in MySQL” (the best answer for which, in turn, republished the kernel from this blog post). Thinking that sounded promising, I opened it and found this little gem:

mysql -uroot -ppassword -e "show databases" | grep -v Database | grep -v mysql| grep -v information_schema| |gawk '{print "drop database " $1 ";select sleep(0.1);"}' | mysql -uroot -ppassword

That will drop all databases. No doubt about it. But that’s not what I want to so, so I edited the leading command down to this:

`mysql -uroot -e "show databases" | grep -v Database | grep -v mysql| grep -v information_schema| grep -v test | grep -v OLD | grep -v performance_schema


Which gives back a list of all the databases created by a user.

Now I need a place to keep the dumps .. /tmp sounded good.

And each database should be in its own file, for I need mysqldump $db.identifier.extension

Made the ‘identifier’ the output of date +%s to get seconds since the Unix epoch (which is plenty unique enough for me).

All of which adds up to this one-liner:

for db in `mysql -uroot -e "show databases" | grep -v Database | grep -v mysql| grep -v information_schema| grep -v test | grep -v OLD | grep -v performance_schema`; do mysqldump $db > /tmp/$db.dump.`date +%s`.sql; done

Plop that puppy in root’s crontab on a good schedule for you, and you have a hand-free method to backup databases.

Thought about using xargs, but I couldn’t come up with a quick/easy way to uniquely identify each file in the corresponding output.

Might consider adding some compression and/or a better place for dumps to live and/or cleaning-up ‘old’ ones (however you want to determine that), but it’s a healthy start.

You can also do mysqldump --all-databases if you think you want to restore all of them simultaneously … I like the idea of individually dumping them for individual restoration / migration / etc.

The full script I am using (which does include backups, etc):

############################
#!/bin/bash

date


Starting from a tutorial I found recently, I want to share how to change your default font in Windows 10 – but in a shorter edition than that long one (and in, I think, a less-confusing way).

Back in the Good Ole Daysâ„¢, you could easily change system font preferences by right-clicking on your desktop, and going into the themes and personalization tab to set whatever you wanted however you wanted (this is also where you could turn off (or back on) icons on your desktop (like My Documents), set window border widths, colors for everything, etc).

Windows 10 doesn’t let you do that through any form of Control Panel anymore, so you need to break-out the Registry Editor^*.

0^th, Start regedit

WindowsKey-R brings up the Run dialog – type regedit to start the Registry Editor

NOTE: you should back-up any keys you plan to edit, just in case you forget what you did, want to revert, or make a mistake.

1^st, Navigate to the right key area

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes

&&

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts

Are where you’ll need to be to make these changes.

2^nd, Blank entries for Segoe UI

For all of the “Segoe UI” entries in Fonts, change their Data field to blank (“”)

3^rd, Add a Segoe UI substitute font

In FontSubstitutes, click Edit->String Value. Name it “Segoe UI” (without the quotes). In the “Value data” field, enter your preferred font name. I used Lucida Console.

4^th, Logout, or reboot, and login again to see your changes take effect.

^{* _{You can also download my registry keys, which have the substitution already done here. And you can pick any other font instead of Lucida Console you like – just edit the key file in your favorite text editor (I like TextPad) before merging into your Registry.}}