365 Days of Code - Day 003

Day 3 was a little less productive for coding. I mostly did administrative work to start the day. Working with docker, working with shells, updating PCs, synchronizing files, etc. I wanted to add another project to my Laravel (opens in a new tab) tutorial. I have been wanting a personal management system for a long time. The only one I know of that exists is called Monica (opens in a new tab). It was ok, and did what I needed it to do on a basic level. However, I was not a fan of the interface. The developers were also not working on the application full-time, while trying to migrate the entire system over to a new version called Chandler. They have put in a tremendous effort, but I think I can make one on my own.

I successfully containerized my PHP Time Tracker today, transforming it from a simple local script into a portable Docker application. The process involved more than just writing a Dockerfile; I had to solve a common persistence challenge where the container’s web user (www-data) lacked permission to write to the SQLite database on my host machine. Instead of using an insecure workaround like chmod 777, I re-architected the deployment to separate code from data. I modified the PHP connection logic to respect environment variables and configured docker-compose to store the database in a dedicated, named volume. This approach allowed me to mount the application code as read-only for better security while ensuring my data persists safely in a managed volume with the correct ownership permissions. There still exists a bug in the Unraid (opens in a new tab) docker configuration which will delete the database if the container is updated. This is due to the database not being stored in a persistent share, but inside the container itself. I’ll have to fix it later, as it works for now.

When I switched my Debian default shell from bash to zsh, I discovered my old .bashrc script that started the ssh-agent and then ran ssh-add didn’t behave the same in .zshrc. Zsh would finish drawing the prompt and then ask for the key passphrase a moment later, but the passphrase would consistently fail even though it worked fine if I skipped it and ran ssh-add manually afterward (or via bash). The root cause is timing/TTY handling. .zshrc runs during interactive shell initialization, and ssh-add can end up reading from a non-TTY or otherwise confused stdin while zsh is setting up the prompt, so the passphrase input isn’t captured correctly. The fix is to move agent/key setup out of .zshrc and into .zprofile (login-shell init for SSH sessions), and explicitly force ssh-add to read from the real terminal (e.g., ssh-add ~/.ssh/id_rsa > /dev/tty) after ensuring an agent exists, which makes the passphrase prompt immediate and reliable again. But, that ended up breaking VS Code when using Remote-SSH. I removed the .zprofile file. Another thing to fix later.

Looking at my Personal Relationship Manager (opens in a new tab) web application, this is going to take a bit more thought. With my client website, I know what I want to build because they already have a website. The PRM site is something novel and new. I should spend a little bit of time designing what I want. This is why I want to self-host a Monica instance, so I could get a better idea of what I might need in my own application.