Dr Fragen in the operating room


  • GitHub Updater and Gitea

    Gitea is the new kid on the block for creating a self-hosted git server. Gitea is written in Go and is highly performant with very low overhead. In fact, Gitea is so efficient you can run it on a Raspberry Pi. There鈥檚 another post coming about that. 馃槈

    As with most integrations of new git servers into GitHub Updater it all starts with an issue and a user willing to help. In this case, the user was Marco Berchart.

    Over the years, I鈥檝e continued to refactor GitHub Updater to become more OOP based and adding Gitea support definitely shows that this was the way to go. Adding support for Gitea was far and away the simplest integration yet. Much of this has to do with API closely following the GitHub API.

    Marco was kind enough to start by creating 聽a PR and we were able to work on a branch until it was complete and able to be merged. There is a demo site at https://try.gitea.io where a test account can be created. There is no guarantee any sort of persistence and don鈥檛 expect your data, or possibly even your user, to be around long term. Marco was able to provide an account on his Gitea instance for me to test. I couldn鈥檛 have finished the integration with this access.

    Since then I have figured out how to install Gitea on a Raspberry Pi. I’ve actually done the process several times and even updated both Go and Gitea. It makes testing much easier for me and it makes setting up your own local git server for less than $100 simple.

  • Local by Flywheel (Pressmatic) and Symlinks

    I’ve changed development environments a couple of times. I started out using DesktopServer, a wonderful app. Gradually I grew disappointed with their update schedule and v4.0 ever on the horizon. One of the things I didn’t like was my inability to choose the PHP version I was developing in. I know there must be a way but it wasn’t obvious.

    Feeling like I needed a challenge, I set out to learn how to use Vagrant and VVV cause all the cool kids were using it. Once I got it up and running it worked well. There were a number of quirky things that I needed to figure out for my workflow.

    From my initial time with DesktopServer I was using GitHub and local git on my MacBook Air, using Tower, for version control. Currently I鈥檓 using GitKraken, but that鈥檚 another post. I kept all my local repos synced on GitHub. When using DesktopServer I would create a symlink to the /wp-content/plugins or /wp-content/themes folder of the local environment from my local repo.

    This didn’t quite work in VVV as symlinks don’t work in Vagrant. Vagrant requires creating a synced folder which is similar, but not the same. I was able to create a Customfile, custom config file, for my VVV installation that would create synced folders at each vagrant up. This synced folder appeared on the desktop as an empty folder but in the site it ran perfectly. The problem was that in my IDE, PhpStorm, there was nothing in the folder to edit. I found that removing this synced folder and replacing it with an actual symlink made everything work in both my IDE and on the site. Perfect, I was back to my usual workflow.

    The issue I had was that every time I did a vagrant up or a vagrant reprovision, Vagrant would destroy my synced folder and I would have to run the Customfile again to recreate it. As many know, Vagrant isn’t a speed demon during a vagrant up and the additional code of creating multiple synced folders was considerable. Add to that the extra step of creating the symlinks each time, then I was set.

    When Pressmatic came on the scene I was already considering dipping my hand into Docker, but was slightly intimidated. Pressmatic made all of that so much simpler. Pressmatic was purchase by Flywheel, rebranded and released as a free tool, Local by Flywheel. OK so the name is kinda blah and the really cool Pressmatic logo is no more, but it works great! Local soon developed an add-on that created shared/synced volumes which pretty much was the same result as my Customfile in VVV. The only problem was I couldn’t find any simple way to re-create my experience of switching to a symlink. Part of the problem was that I was very dissatisfied with amount of time required at provisioning in Vagrant and the thought of having to do this multiple times a day was daunting.

    I changed my workflow to use an small app that synced folders in the background. It worked, but was clearly a kludge. Out of curiousity I created a synced folder using the Local by Flywheel Volumes Addon and then changed this folder to a symlink. Instantly I was back in business when using my IDE. The best part was that the symlink persisted through the Local Machine restarts and re-provisioning the individual sites.

    Since then I’ve created a bash script to automatically create the symlinks after the Volumes have been added. I can now effectly re-create my normal workflow and even better as in Docker, synced folders seem to be persistent.

    I鈥檓 sure my understanding of synced folders was probably incorrect and they were persistent all along. I just didn鈥檛 see it at the time.

    As of this writing both Local by Flywheel and the Volumes addon have been updated several times. The current versions are completely compatible and functional.

    This setup may not be for everyone, but I鈥檝e found it allows me to develop locally and continue to use git for version control.

  • Dreamhost, WordPress and WebDAV

    So next on my list was figuring out how to create a nested group of password protected directories with different users accessing various sub-directories. It’s much simpler than it sounds. The only caveat was that the main domain is running WordPress.
    As such I had to tweak the .htaccess file. Fortunately the instructions were simple.
    Then I created a series of nested WebDAV directories in the Dreamhost Panel and assigned user accounts as needed. Every user needing WebDAV access got it for the primary WebDAV directory and then each sub-directory had only the user accounts as needed.
    Surprisingly this worked great. I may need to get an SSL certificate for the domain if I want to have the WebDAV encrypted but that should be very doable.

  • Transferring WordPress

    So the benefit of having many domains to play with is that I get to test things out before I put them on a live site.
    I was able to successfully transfer a multisite WordPress installation to @Dreamhost. Here’s what I did.

    1. Use 1-click installer to create base site @Dreamhost.
    2. Make site a multisite installation.
    3. Use SFTP to copy existing plugins/themes.
    4. Use WP Migrate DB Pro to push existing database to new database.
    5. Create mirrored subdomain in @Dreamhost panel for subdomains.
    6. Remember to check Remove WWW from the main domain.

    Shout out to @Dreamhost support for pushing me in the right direction.
    Next up, tackling IMAP email transfer.

  • Not Running a Server

    I’ve been running my own server for over 5 years now. It has been a great and sometimes frustrating experience. I think I’ve finally decided to let the pros do the server administration and just focus on the other stuff. The other stuff being coding, writing, and playing with technology.
    I’m looking into @Dreamhost. They seem to offer a wealth of features at a reasonable price. Honestly what gives me the most anxiety is transferring all the old IMAP email over to the new host. There’s a wiki entry about transferring email and using imapsync. I really need to investigate this.
    Wish me luck. Updates to follow.

  • Fail2ban and OS X Server, Part Deux

    As some of you might know I run my own installation of OS X Server. I’ve since updated it to Snow Leopard Server and I think I’ve got most of it running well. As I check my server logs frequently I find that there are all sorts of script kiddies attempting to log in to my server in various ways.
    The traditional method was to simply try an ssh session with a username and password combination. Unfortunately now I see more attempts to log in via VNC or in attempts to check or send email. It’s amazing to see 10 – 15 login attempts in a second. There’s a real motivating force to stop that kind of attention my poor little server is getting.
    As I’ve written before, I’ve found the Fail2ban scripts to to be a perfect solution. I have had to make a number of additions and improvements along the way and now I thought I’d share.
    I’ve created a couple of new jails and improved upon a couple of the distribution jails so they work better with Snow Leopard. I’ve packaged up all my modifications. Here’s how to install them for yourself.
    Download the modifications tarbell.
    Then you’ll need to issue the following commands from Terminal.

    sudo tar xzf install_fail2ban_mods.tar.gz

    This will create a folder containing all the modifications. At this point you can manually put all the files in the proper folders or you can use my installation script. The installation script, install_fail2ban_mod.sh shouldn’t delete anything. I only use the cp command. If you already have a jail.local file that is backed up. You may also need to modify the jail.local file that I have.
    Additionally, I’ve found that sometimes the fail2ban server might have hung or its process has stopped. I’ve also written a script and a couple of plists for /Library/LaunchDaemons/ that periodically check to make sure fail2ban continues to hum along. You’ll have to load these plists manually or simply restart.
    The jails that I’ve added check for SMTP, POP, IMAP, VNC and non-existant web pages. These, in addition to monitoring SSH, seem to cover most of it. Please remember that some of these filters are somewhat specific to Snow Leopard so they check against a Dovecot mail server.
    So far my only problem has been when a user has changed their password but not correctly transferred these changes to Mail.app. What happens is fail2ban sees them as a break-in attempt and bans their IP for 10 minutes or so. I’m sure it can be frustrating. Sorry, I’m doing my best to fix it for you.
    By all means, let me know how you’ve improved Fail2ban for your server.