Commit 54339a23f5
Verified · cmc
Layout: unified · split
content/blog/2026-02-02-emacs-carnival-2026-02-completion.org +5 −4
| @@ -5,7 +5,7 @@ | ||
| 5 | 5 | #+filetags: :emacs:personal: |
| 6 | 6 | |
| 7 | 7 | I'm having a great time with the Emacs Carnival, as it has inspired me to write |
| 8 | two posts in such a short time. It's been a much needed inspiration to write | |
| 8 | two posts in such a short time. It's been a much-needed inspiration to write | |
| 9 | 9 | during my busy season at work. |
| 10 | 10 | |
| 11 | 11 | Anyway, let's get to it. The topic today is [[https://www.emacswiki.org/emacs/CategoryCompletion][Completion]]: the magical thing that |
| @@ -45,8 +45,8 @@ time string, like so: ~2026-02-02 21:52:55~. | ||
| 45 | 45 | ~¯\_(ツ)_/¯~ |
| 46 | 46 | |
| 47 | 47 | This comes in handy most at work, where I need to constantly use acronyms and |
| 48 | take shorthand notes to fill-out phrases that I'm, unfortunately, required to | |
| 49 | re-use constantly. Looking at you, "completeness and accuracy of the data". | |
| 48 | take shorthand notes to fill out phrases that I'm, unfortunately, required to | |
| 49 | reuse constantly. Looking at you, "completeness and accuracy of the data". | |
| 50 | 50 | |
| 51 | 51 | * Doom Configuration |
| 52 | 52 | |
| @@ -67,6 +67,7 @@ Here is how I have my ~:completion~, ~:tools~, and ~:lang~ modules toggled in | ||
| 67 | 67 | (spell +flyspell) ; tasing you for misspelling mispelling |
| 68 | 68 | grammar ; tasing grammar mistake every you make |
| 69 | 69 | |
| 70 | ||
| 70 | 71 | :tools |
| 71 | 72 | (lsp +eglot) ; M-x vscode |
| 72 | 73 | |
| @@ -133,7 +134,7 @@ workflows. | ||
| 133 | 134 | ** [[https://github.com/leotaku/flycheck-aspell?tab=readme-ov-file][flyspell]] |
| 134 | 135 | |
| 135 | 136 | Flyspell is the last piece to my puzzle, as it allows for easy help in |
| 136 | correcting grammar errors within the buffer. I combine ~flypell~ + ~syntax~ + | |
| 137 | correcting grammar errors within the buffer. I combine ~flyspell~ + ~syntax~ + | |
| 137 | 138 | ~grammar~ for ultimate writing guidance. Whether or not I choose to follow that |
| 138 | 139 | guidance is another story entirely. |
| 139 | 140 | |
content/blog/2026-02-12-automating-weblorg-deployments.org +1 −1
| @@ -166,7 +166,7 @@ However, that's way too manual for me. Let's be lazy and take it even further. | ||
| 166 | 166 | |
| 167 | 167 | * GitHub Actions |
| 168 | 168 | |
| 169 | So, how do we push it further. By removing the need to run a command (outside of | |
| 169 | So, how do we push it further? By removing the need to run a command (outside of | |
| 170 | 170 | ~git~) at all! |
| 171 | 171 | |
| 172 | 172 | This process will: |
content/blog/2026-02-21-auditing-aws-iam.org +2 −2
| @@ -115,7 +115,7 @@ individual accounts and provides centralized access management across all of | ||
| 115 | 115 | them from a single place. |
| 116 | 116 | |
| 117 | 117 | It connects to an identity source, such as AWS's own directory, Active |
| 118 | Directory, or an externali identity provider (IdP) like Okta or Entra ID, and | |
| 118 | Directory, or an external identity provider (IdP) like Okta or Entra ID, and | |
| 119 | 119 | uses that as the source of truth for users and groups. Access is configured |
| 120 | 120 | within Identity Center itself, not inside individual accounts. |
| 121 | 121 | |
| @@ -295,7 +295,7 @@ exception, here's how to frame it: | ||
| 295 | 295 | - *Deficiency:* User ~iamtestuser1~ is directly assigned the ~AdministratorAccess~ |
| 296 | 296 | permission set in account ~cmc~, rather than receiving access through a group |
| 297 | 297 | assignment. |
| 298 | - *Root Cause:* Due to {{ root cuase }}, the user ~iamtestuser1~ was inappropriately | |
| 298 | - *Root Cause:* Due to {{ root cause }}, the user ~iamtestuser1~ was inappropriately | |
| 299 | 299 | provisioned the ~AdministratorAccess~ permission directly rather than through a |
| 300 | 300 | group assignment. |
| 301 | 301 | - *Risk:* Direct user assignments increase the likelihood of orphaned access |
content/blog/2026-02-21-auditing-aws-passwords.org +1 −1
| @@ -13,7 +13,7 @@ The scripts are available at [[https://github.com/audit-labs/audit-tools/tree/ma | ||
| 13 | 13 | |
| 14 | 14 | * Scoping |
| 15 | 15 | |
| 16 | First thing's first: scoping. To audit AWS passwords, we need to understand that | |
| 16 | First thing first: scoping. To audit AWS passwords, we need to understand that | |
| 17 | 17 | AWS IAM password policies only apply to users with console access. This isn't |
| 18 | 18 | the same as the password policy for an application built on top of AWS. It also |
| 19 | 19 | has no effect on users who authenticate through IAM Identity Center, which |
content/blog/2026-04-22-self-hosting-zerobyte.org +3 −3
| @@ -7,7 +7,7 @@ | ||
| 7 | 7 | [[https://zerobyte.app][Zerobyte]] is a slick backup solution you can self host. It's one of the easiest |
| 8 | 8 | apps I've self hosted and the backup jobs are running smoothly. |
| 9 | 9 | |
| 10 | In this post, I will show you how I've configured backups on my server to backup | |
| 10 | In this post, I will show you how I've configured backups on my server to back up | |
| 11 | 11 | data to Cloudflare R2. |
| 12 | 12 | |
| 13 | 13 | * Installation |
| @@ -157,7 +157,7 @@ cron pattern). This allows you to specify: | ||
| 157 | 157 | - The volume to be backed up |
| 158 | 158 | - The repository to back up to |
| 159 | 159 | - The schedule |
| 160 | - The files to backup (all will be backed up if nothing is specifically selected) | |
| 160 | - The files to back up (all will be backed up if nothing is specifically selected) | |
| 161 | 161 | - Include/exclude patterns |
| 162 | 162 | - Retention policies |
| 163 | 163 | - Custom restic patterns |
| @@ -166,7 +166,7 @@ cron pattern). This allows you to specify: | ||
| 166 | 166 | [[https://img.cleberg.net/blog/20260422-self-hosting-zerobyte/backups_01.webp]] |
| 167 | 167 | |
| 168 | 168 | Within a backup job, you can configure the related notifications, snapshots, or |
| 169 | backup/edit/cleanup the job. | |
| 169 | back up, edit, or clean up the job. | |
| 170 | 170 | |
| 171 | 171 | #+CAPTION: Backup Job Details |
| 172 | 172 | [[https://img.cleberg.net/blog/20260422-self-hosting-zerobyte/backups_02.webp]] |
content/blog/2026-05-20-git-is-not-github.org +8 −8
| @@ -87,7 +87,7 @@ For example, I can create a local Git repository, expose it through the Git | ||
| 87 | 87 | protocol, and share this info with a friend or coworker. Then, they can clone my |
| 88 | 88 | repository and we can collaborate by making changes independently and using |
| 89 | 89 | commits, branches, etc. to push changes back and forth with each other. In this |
| 90 | scenrio, there is *no* host and we are essentially a distributed network of our | |
| 90 | scenario, there is *no* host and we are essentially a distributed network of our | |
| 91 | 91 | own. |
| 92 | 92 | |
| 93 | 93 | At its core, Git answers technical history questions: |
| @@ -100,7 +100,7 @@ At its core, Git answers technical history questions: | ||
| 100 | 100 | - How did this branch differ from that branch? |
| 101 | 101 | |
| 102 | 102 | That is valuable, but it is not the whole development process. This is where Git |
| 103 | hosts introduce useful, addition features on top of Git. | |
| 103 | hosts introduce useful, additional features on top of Git. | |
| 104 | 104 | |
| 105 | 105 | * Git Hosts Add the Workflow |
| 106 | 106 | |
| @@ -145,7 +145,7 @@ First, here are some common controls: | ||
| 145 | 145 | - The repository is configured to: |
| 146 | 146 | - prevent force pushes; |
| 147 | 147 | - require X approvals; |
| 148 | - prevent approvals from the author or a person who can committed within the | |
| 148 | - prevent approvals from the author or a person who committed within the | |
| 149 | 149 | pull request; |
| 150 | 150 | - require testing to pass prior to merging; |
| 151 | 151 | - include the relevant change ticket(s)/documentation. |
| @@ -158,26 +158,26 @@ First, here are some common controls: | ||
| 158 | 158 | |
| 159 | 159 | Now, where can we find this evidence? Let's step through each |
| 160 | 160 | - Normally, reviews and approvals can be found directly within the pull/merge |
| 161 | request. For platforms such as Github, this platform enables code reviews, | |
| 161 | request. For platforms such as GitHub, this platform enables code reviews, | |
| 162 | 162 | comments, feedback, and checks directly within the PR flow. In certain cases, |
| 163 | 163 | this may be documented in a change ticket system and the ticket is referenced |
| 164 | 164 | within the PR to prove that the PR was tested, reviewed, and approved prior to |
| 165 | 165 | merging. |
| 166 | - For configurations, GitHub supports both [[https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule][classic branch protections rules]] and | |
| 166 | - For configurations, GitHub supports both [[https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule][classic branch protection rules]] and | |
| 167 | 167 | [[https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets][rulesets]], which can enforce all of the checks I mentioned above. |
| 168 | 168 | - For access, it depends on the company's setup. They may be using GitHub |
| 169 | 169 | Enterprise, which offers them more control over access, and teams can inspect |
| 170 | the access inheritence through those Enterprise settings. Otherwise, | |
| 170 | the access inheritance through those Enterprise settings. Otherwise, | |
| 171 | 171 | non-enterprise GitHub organizations can show evidence of access at both the |
| 172 | 172 | organization level and the repository level. Auditors can inspect the levels |
| 173 | of access and inheritence to ensure that no users have the ability to develop | |
| 173 | of access and inheritance to ensure that no users have the ability to develop | |
| 174 | 174 | changes, manage branch protections, approve changes, and deploy changes. |
| 175 | 175 | - For branch protection settings, management can provide auditors with an export |
| 176 | 176 | of the audit logs relevant to the in-scope repositories. This will show you if |
| 177 | 177 | any events occurred that would have disabled or modified the branch |
| 178 | 178 | protections in place. |
| 179 | 179 | |
| 180 | If your inspecting a project where CI/CD pipelines matter, you can also dive | |
| 180 | If you're inspecting a project where CI/CD pipelines matter, you can also dive | |
| 181 | 181 | into the team's configuration of their pipeline in terms of the logic, access to |
| 182 | 182 | modify, and any relevant schedules or triggers. |
| 183 | 183 | |
content/blog/2026-06-01-macos-motd.org +1 −1
| @@ -116,7 +116,7 @@ chmod +x ~/.motd.sh | ||
| 116 | 116 | At this point, the script is ready. We simply need to tell macOS to execute it |
| 117 | 117 | whenever the user launches a new shell. |
| 118 | 118 | |
| 119 | To do this, open the =.zprofile= file add a line referencing the script: | |
| 119 | To do this, open the =.zprofile= file and add a line referencing the script: | |
| 120 | 120 | |
| 121 | 121 | #+begin_src shell |
| 122 | 122 | nano ~/.zprofile |