1. change size of lv in proxmox
2. fdisk /dev/sdX
   1. expand
   2. partition
   3. size
   4. write
3. btrfs filesystem resize max /

if you don’t want to have /tmp as a mount of the memory via tmpfs, mask the systemd mount:

sudo systemctl mask tmp.mount

a long overdue migration has finally been done. here are some notes to remember

• for data export you need the opml file and the actual data dump
• opml export via web interface
• data dump via data_migration plugin
  • as the user owning ttrss, in the subfolder > plugins.local do git clone https://gitlab.tt-rss.org/tt-rss/plugins/ttrss-data-migration.git data_migration
  • add this to the host config file to allow the plugin: putenv('TTRSS_PLUGINS=auth_internal, data_migration');
  • then run `./update.php –data_user YOUR_TTRSS_USER –data_export FILENAME.zip
• set up new ttrss docker instance as you prefer
• first run with the updater container commented out
• import opml on web ui
• import data dump in container
  • docker exec -it your_cointainer /bin/sh
  • in /var/www/html/ttrss run as user app: `./update.php –data_user YOUR_TTRSS_USER –data_import FILENAME.zip
• ideally do this in a tmux session in case your connection dies

sudo -u postgres psql  
postgres=# create database mydb;  
postgres=# create user myuser with encrypted password 'mypass';  
postgres=# grant all privileges on database mydb to myuser;

and as of postgres 15 there’s a change to the public schema due to security considerations:

have to still research this.

Therefore, I seriously struggle to imagine Putinist municipal policy that would pose an immediate security threat if we do not limit voting rights. Esteemed proponents of revoking voting rights, please help me out! Help the public understand the real and tangible security threats you’re talking about. And do it in a way that avoids painting Estonia as hapless and incapable of enforcing its rules without stripping a tenth of the population of the right to vote.

Quickly check a host for its facts

ansible <host pattern> -m setup

and compiled runtime vars

ansible <host pattern> -m debug -a "var=hostvars[inventory_hostname]"

To four years of bully bullshit and handmaid agenda.

This is the relationship i have:

Portfolio.shares.coin.latest_value_snapshot.value_snapshot

I searched for a way when viewing a single portfolio to order shares by their latest value snapshot’s usdt value. This is the query i eventually came up with:

Portfolio
.includes(
{shares: {coin: {latest_value_snapshot: :value_snapshot}}},
{latest_value_snapshot: :value_snapshot},
{shares: {latest_value_snapshot: :value_snapshot}}
)
.joins(shares: {latest_value_snapshot: :value_snapshot})
.where(value_snapshots: {valueable_type: "Share"})
.order("value_snapshots.usdt_satoshis")
.find(params[:id])

For the polymorphic part, the key ingredient is .where(value_snapshots: {snapshotable_type: 'Share'}). This ensures that only the value_snapshots that are associated with Share are considered, filtering out those related to Portfolio or Coin. These have their own value snapshots.

The includes is related to eager loading, preventing N+1 query issues.

The explicit joins method helps creating the SQL join which help focusing the where condition and order method onto the value_snapshots table correctly.

The order method then applies to the usdt_satoshis table. Note that I am using the money gem to handle currencies, with USDT / Satoshis being a custom currency, hence the table name including the _satoshis prefix.

So it’ll be BalticRuby in June and RailsWorld (if i get a ticket) on fall some time :)

NB users with the same id on host and inside container share privileges on the host machine.

docker top <CONTAINER> -eo uid,gid,pid,cmd

this command will show a custom format output of the process list, starting with the uid

“A rapidly changing society failed to recognize the structural and systemic causes of poverty and decline. It was as if the victim was entirely to blame for his or her situation.”

“This allowed us, in Annist’s view, to paint a picture of the opposite of dysfunctional: the individualistic and successful achiever. People held up this imaginary figure as a standard for others, disregarding the fortunate circumstances and supportive environment that typically led these individuals to success.”

“The demonstration attempted to change the situation in which farmers were continually spilling milk. Usually, they only did it on their farms. The demonstration attempted to bring this painful requirement to the public’s attention, but it became bogged down in reflection and interpretation of the action.”

“comparing the success of the 1980s protest to the 2017 action against tree felling for a road repair project in a Tallinn suburb. On the one hand, the wider public debate did not address whether such a road widening was even essential. On the other hand, the demonstrators were mocked for concentrating on the protection of reed. ”The protest was described as a waste of time, for example, because a hard-working citizen cannot be involved in such ‘nonsense,’” Annist explained.”

“Since the 1990s, instead of showing solidarity, Estonians have been comparing themselves with others on the basis of material indicators, she suggested. “It’s as if everyone’s future is being sacrificed for the sake of material success and the approval of the richest. Such blinders did not limit our thinking in the 1980s; today, very few of us are free of them. Unfortunately, it is difficult for us and for those in power to step back and reflect on whether the goals set in the 1990s are all sustainable,” she said.”

This scenario describes a static site being built from two separate repositories, one containing a NextJS based source and a second content repository containing media files, text and necessary configuration / glue files.

A common use case is a static site being rebuilt based on content added through a repository interface like github or gitlab. this is a simpler equivalent to a full blown cms. like so the future content editor only needs to be trained to interface with a common and widely used and supported system.

Infrastructure parts

• client repository site
• client repository content
• mirror repository site
• mirror repository content
• ci system
• container registry
• web server

Deployment pipeline

App updates

1. commit is pushed to client app repo
2. client app repo is pushed to mirror app repo
3. ci executes pipeline on mirror app repo
   1. clones app code from mirror
   2. clones content from mirror
   3. builds container image with web server
      1. copy files into container
      2. builds site and merges content
      3. configures webserver
   4. pushes image to registry
   5. triggers deploy on infrastructure
      1. pulls container image
      2. restarts service

Content updates

1. commit is pushed to client content repo
2. client content repo is pushed to mirror content repo
3. ci executes pipeline on mirror content repo
   1. clones mirror app repo
   2. updates version file with commit hash (stage) or tag (prod) from content repo
   3. commits change and pushes to client app repo, thereby triggering a run of the App Update pipeline above

Configuration files

• ci pipeline .woodpecker.yml on the site repo
• example deploys the built artefact to a caprover-managed server and notifies via a telegram bot

steps:
  clone_content_repo:
    image: ubuntu
    secrets: [ssh_pubkey_with_read_access]
    commands:
      - apt-get update -y && apt-get install openssh-client git git-lfs -y
      - eval $(ssh-agent -s)
      - echo "$ssh_pubkey_with_read_access" | tr -d '\r' | ssh-add -
      - mkdir -p ~/.ssh
      - chmod 700 ~/.ssh
      - ssh-keyscan -p9235 git_server > ~/.ssh/known_hosts
      - env
      - git clone --depth=1 ssh://git@git_server/${CI_REPO}-content content
      - cd content
      - git lfs pull
      - rm -rf .git
      - cd ..
      - rm -rf .git
    when:
      - event: push
        branch: [master, main]
      - event: tag

  build_stage_image:
    image: woodpeckerci/plugin-docker-buildx
    settings:
      registry: package_server
      repo: git_server/${CI_REPO}
      tag: ${CI_COMMIT_SHA}
      username: wellhoster
      password:
        from_secret: gitea_pass
    when:
      - event: push
        branch: [master, main]
        status: success

  build_prod_image:
    image: woodpeckerci/plugin-docker-buildx
    settings:
      registry: package_server
      repo: git_server/${CI_REPO}
      tag: ${CI_COMMIT_TAG}
      username: wellhoster
      password:
        from_secret: gitea_pass
    when:
      - event: tag
        branch: [master, main]
        status: success

  deploy_prod_site:
    image: caprover/cli-caprover:v2.1.1
    environment:
      - CAPROVER_URL=https://caprover_domain
      - CAPROVER_APP=appname
      - "CONTAINER_FULL_IMAGE_NAME_WITH_TAG=package_server/${CI_REPO}:${CI_COMMIT_TAG}"
    secrets: [ caprover_pass ]
    commands:
      - caprover deploy --caproverUrl $CAPROVER_URL --caproverPassword $CAPROVER_PASS --caproverApp $CAPROVER_APP --imageName $CONTAINER_FULL_IMAGE_NAME_WITH_TAG
    when:
      - event: tag
        status: success

  deploy_stage_site:
    image: caprover/cli-caprover:v2.1.1
    environment:
      - CAPROVER_URL=https://caprover_domain
      - CAPROVER_APP=appname
      - "CONTAINER_FULL_IMAGE_NAME_WITH_TAG=package_server/${CI_REPO}:${CI_COMMIT_SHA}"
    secrets: [ caprover_pass ]
    commands:
      - caprover deploy --caproverUrl $CAPROVER_URL --caproverPassword $CAPROVER_PASS --caproverApp $CAPROVER_APP --imageName $CONTAINER_FULL_IMAGE_NAME_WITH_TAG
    when:
      - event: push
        branch: [master, main]
        status: success

  notify:
    image: appleboy/drone-telegram
    settings:
      token:
        from_secret: telegram_token
      to: 393273328
      message: >
        {{#success build.status}}
          ✅ Building `${CI_REPO_NAME}` triggered by `${CI_PIPELINE_EVENT}`
          {{#if build.tag }}

            This went to prod.
          {{/if}}

          📝 Commit by ${CI_COMMIT_AUTHOR} on `${CI_COMMIT_BRANCH}`:

          `${CI_COMMIT_MESSAGE}`
        {{else}}
          ❌ Build ${CI_PIPELINE_EVENT} of `${CI_REPO_NAME}` has status `${CI_PIPELINE_STATUS}`.
          {{#if build.tag }}

            This tried to go to prod.
          {{/if}}

          📝 Commit by ${CI_COMMIT_AUTHOR} on `${CI_COMMIT_BRANCH}`:

          `${CI_COMMIT_MESSAGE}`
        {{/success}}
      
    when:
      event:
        - tag
        - push
      status:
        - success
        - failure

This is a reminder for future me.

add PostCSS

group :jekyll_plugins do
  gem "jekyll-postcss"
end

edit _config.yml

plugins:
  - jekyll-postcss

postcss:
  cache: false

NB Disabling cache is needed for Tailwind CSS’s JIT engine.

create a postcss.config.js

module.exports = {
  plugins: [
    require('tailwindcss'),
    require('autoprefixer'),
    ...(process.env.JEKYLL_ENV == 'production'
      ? [require('cssnano')({ preset: 'default' })]
      : [])
  ]
}

NB Autoprefixer and cssnano packages are optional, but they are recommended for production builds.

install packages

yarn add postcss@latest tailwindcss@latest autoprefixer@latest cssnano@latest -D

create a tailwind.config.js

module.exports = {
  content: [
    './_drafts/**/*.html',
    './_includes/**/*.html',
    './_layouts/**/*.html',
    './_posts/*.md',
    './*.md',
    './*.html',
  ],
  theme: {
    theme: {
      extend: {},
    },
  },
  plugins: []
}

NB If you add new directories for your posts, pages, or partials, you will need to update the content array

install tailwind typography for better default display

yarn add@tailwindcss/typography

The irony that people whose only tools in a debate are deceit, sowing hatred, spreading misinformation and bashing their political opponents are using exactly the same methods when it helps them inside their own party… the irony seems lost on Helme.

This is a good reminder for other parties when planning to go into coalition with whatever comes out of this power struggle.

Turn off displays from shell in kde plasma 6 under wayland

sleep 0.5 && qdbus org.kde.kglobalaccel /component/org_kde_powerdevil invokeShortcut "Turn Off Screen"

It’s unfortunate how the article doesn’t try to get a critical view to the comments made by the producer or user side. The directive doesn’t state as its purpose to reduce plastic, but to lower its impact on the environment.

Leaving the producer’s strawman of “more plastic used” and the users anecdotal “i’m inconvenienced in my car” or sheer gutwrenching “I don’t believe the scientifical result of the impact of plastic in the environment” is just another example of EU-bashing and bad journalism.

It’s always a bit sad to see how complex issues (impact of single use products on garbage piles in the sea, complexity of maritime and fishing objectives as a main driver of EU policy, effect of consumer behavior in one part of the EU and their outcome and impact of other parts of the Union) are trivialized instead of explained.

Currently one can customize catch-all pages for caprover’s root domain under these values:

error_page 404 /index.html;
error_page 500 502 503 504 /error_generic_catch_all.html;

by overriding the configuration parameter “nginxDefaultHtmlDir’, setting this in the generated nginx config:

root   /usr/share/nginx/default;

from the template

root   <%-captain.defaultHtmlDir%>;

Because caprover has this default bind mount for the nginx container, this works:

{
        "Type": "bind",
        "Source": "/captain/generated/static",
        "Destination": "/usr/share/nginx",
        "Mode": "",
        "RW": true,
        "Propagation": "rprivate"
}

By setting “nginxDefaultHtmlDir” to /usr/share/nginx/default, one is able to create a persistable directory “default” under “/captain/generated/static” and reference it like mentioned above.

However, for the application-specific server block, the template looks like this:

error_page 502 /captain_502_custom_error_page.html;

location = /captain_502_custom_error_page.html {
        root <%-s.customErrorPagesDirectory%>;
        internal;
}

Currently, this writes out to

error_page 502 /captain_502_custom_error_page.html;

location = /captain_502_custom_error_page.html {
        root /usr/share/nginx/default;
        internal;
}

It’s defined here, a combination of “nginxStaticRootDir” + “nginxDefaultHtmlDir”

Since its initial release, Kamal (formerly mrsk) has emerged as the long-awaited facelift to Capistrano, while also making the us of Docker seem like a walk in the park. At its heart, Kamal taps into Docker, steering us away from the oftentimes bewildering saga of Ruby on Rails deployment. It transitions us from wrangling a mishmash of infrastructures—spanning development, testing, staging, to production across varied machines and operating systems with their own quirks in versions and package management—to the blissfully straightforward narrative of deploying with a single, neatly packaged container image.

At first glance, tools like Kamal are akin to a silver bullet for the solo developer, allowing for a breezy journey from code to production. This is crucial because it means you can focus on what truly matters: crafting solutions to business challenges with your code.

Post-deployment, the ‘state’ saga begins, ranging from the health of the operating system and network to the dynamics of application data.

However, what often goes unmentioned, similar to discussions about cloud computing: it’s all still running on someone else’s hardware. Beneath the surface, there lurks the ever-present need for handling ‘state, state, state’. And state is what comes after the deploy: starting from the state of the operating system, the network state, all the way up to the state of the application data.

So, after you deploy and then redeploy, it’s time to ponder over your next moves:

1. How do I maintain and update the operating system and essential services?
2. How can I monitor the current state of the operating system, services, and my application?
3. What strategies should I use for managing data storage, whether in short-term storage like Redis or long-term solutions like PostgreSQL and file systems?
4. How do I manage state stored in third-party applications, and apply the above considerations to them?

Server Options

When choosing a server, you would probably go for a virtual unmanaged instance from popular provider. They’re budget-friendly, and even the smaller offerings can comfortably support an app, a worker, a Redis instance, and a PostgreSQL instance. At the time of writing, Hetzner’s CX11, at 4.55 Euros, will fit the bill nicely. For a tad more, at 5.22 Euros, you get a boost with an extra thread and double the storage. Over at Digital Ocean, a comparable setup will cost you about 18 USD per month. AWS, with its notoriously cryptic pricing, offers something similar at a ballpark cost. Linode’s in the mix too, with options that might set you back somewhere between 12 to 24 USD.

What do you mean, unmanaged?

Mind you, all of these units are unmanaged, which means all responsibility lies with you as the contract partner to the hosting service. A server left to its own devices can quickly turn into a digital wasteland. Public-facing services are like open invitations for anyone with mischief in mind. Once compromised, it’s essential hot garbage. Best to scrap the server and start fresh.

Even if it’s “just a side project” or “not a top priority,” vigilance is non-negotiable. So, here are some high-level tips on how I keep things under control.

Tackling State

To keep the operating system and essential services in tip-top shape, I use Ansible playbooks, categorizing them by setup, service roles, and specific configurations for my setups — often CapRover on Docker Swarm or vanilla Ubuntu Server.

I organize tasks around the server’s life cycle—think “system upgrades,” “Docker cleanup,” “backup preparations,” “user and SSH key updates,” and so on.

For business processes, programmatic runbooks provide a blend of manual steps, scripts, and API requests (i.e. dns providers, git management, etc.), allowing for scalable and efficient project management. Their greatest strength lies in blending various layers of complexity: Beginning with a straightforward, step-by-step to-do list, you can incrementally incorporate external command calls or integrate comprehensive scripts to streamline and automate processes.

Gaining Insights

Gaining insight into the performance of your operating system, services, and applications is a crucial maintenance activity. There’s no one-size-fits-all solution; it’s all about the scope of your project and your personal preferences.

For a comprehensive overview at various levels, starting with an application monitoring tool like Honeybadger is wise for tracking errors, uptime, and job performance. It’s an excellent first step. As you become more acquainted with your application, developing custom metrics endpoints for specific features can be a beneficial next move.

Diving deeper, the management of services and the operating system necessitates centralized, indexed logging capable of generating actionable metrics. For a solo host, beginning with journald to capture all system logs is a practical choice. Given the diversity of the Linux logging landscape, setting this up can be complex. Selecting software or services that offer more than basic stdout or logfile outputs is crucial, though integrating such logs with journald can add complexity. The ability to live-tail journald, viewing all log outputs in real-time, greatly aids in understanding how different services interact on a server. For environments beyond a single host, integrating tools like Promtail, Loki, and Grafana can address journald’s limitations, especially for developing alerting rules based on incident experiences to improve oversight.

Monitoring the actual health of your host is also vital. Hosting providers may not alert you to issues like maxed-out threads, choked I/O, or full disks. Tools like Netdata as a starter, and the trifecta of Node Exporter, Prometheus, and Alertmanager later on are invaluable for these deeper diagnostics. When selecting tools or third-party services, consider the type of data access they provide and the flexibility for configuring custom metrics and alerts.

Backup Strategies

Many hosting providers offer daily snapshots of your system as part of their service, often costing you 10-20% of your monthly server fees. Generally, this seems adequate until a snapshot coincides with a crucial database transaction or file write, potentially leading to data inconsistencies or corruption. The process for creating snapshots isn’t always transparent, and the common advice to shut down your server for a manual snapshot highlights its limitations.

My approach prioritizes data over the operating system’s state, focusing on database content and important application files — like media or client products — which are irreplaceable and costly to recreate. For everything else, tools like Ansible can rebuild the system from scratch.

Restic in conjunction with Autorestic is my preferred backup solution. It supports a wide range of storage backends and secures backups with encryption, offering differential backups and the option for full backups at specific intervals. The downside is its recovery process, which requires navigating through Restic, but the trade-off for secure, manageable backups is worth it. Adhering to the 3-2-1 backup strategy — three total backups on two different media types, with one stored offsite — provides a robust safety net. Thus, combining provider snapshots with Restic backups across various platforms, like B2 Backblaze and Hetzner storage boxes, ensures comprehensive coverage. While daily backups are standard, timing them to capture the day’s significant work can further safeguard your data.

Conclusion

Managing an application’s lifecycle is a complex task that can’t be fully covered in just one article. I plan to dive deeper into the topics discussed here, sharing more of my experiences and insights. This will allow me to explore these concepts in a more practical, detailed manner, moving beyond theoretical discussions to real-world applications.

Therefore, feel free to leverage Kamal for streamlining your deployment process, but remember, deployment is just one phase in the broader journey of an application’s life.

References

Kamal

Hosting Providers

• Hetzner
• Linode
• Digital Ocean
• AWS

Management Tools

• Ansible
• Runbook
• Ubuntu
• CapRover
• Docker Swarm

Insights Tools

• Honeybadger
• journald
• PromTail
• Grafana
• Netdata
• NodeExporter
• Prometheus
• Alertmanager

Backup Tools

• Restic
• Autorestic
• Backblaze B2

Show run time variable values for host

- name: display all variables and facts known for a host
  ansible.builtin.debug:
    var: hostvars[inventory_hostname]

Correct way of registering change on shelled out commands

- name: Handle shell output with return code
  ansible.builtin.command: cat 
  register: my_output # <- Registers the command output.
  changed_when: my_output.rc != 0

conditional when changed

- name: create systemd unit file
  ansible.builtin.template:
  dest: /path/to/foo
  src: foo.j2
  register: unit_file

- name: reload systemd daemon when unit file changed
  ansible.builtin.systemd:
  daemon_reload: true
  when: unit_file.changed

As an inhabitant of Uus Maailm, a father, walker, biker, driver, and someone with an interest in urban issues, I have been eagerly anticipating the results of this competition with high expectations and hopes. The redesign of Koidu Street on this side of the Endla / Suur-Ameerika “maantee” will have a major impact on how we, as citizens, will be able to live in and utilize our neighbourhood, Uus Maailm, far more than any other recent projects or street renovations, and likely for the next couple of decades.

The short version

1. Thoroughly alter the traffic pattern by
   1. uniting school space and Koidu park,
   2. creating a recognizable Koidu 80 plats with minimal traffic,
   3. breaking up all the residential streets leading into Koidu, allowing pedestrians but restricting cars from passing into or over Koidu,
   4. honoring the ideas of the Liikuvusagentuur T-Model for the Liivalaia-Kristiine tram line.
2. Avoid artificial branding through material gloss, historicizing street decor, and coerced street branding. Instead, make the space more flexible for the residents to define their own brand through usage patterns and emerging lifestyle and urban culture, then make this coherent through later redesign.

The slightly longer version

When I look at the street, I see three major centers that require special consideration: the Suur Ameerika Entrance, the Koidu 80 plats, and the Humanitaargümnaasium / Koidu Park complex.

These three areas require a fundamental rethinking of how we consider public space. For me, this mainly means pushing further towards a car-free city (car-free not in the often misunderstood sense of forbidding cars, but in the sense of not depending on them).

As I understand, the brief asks for an urban space that prioritizes pedestrians/people above all modes of transport. For this reason, these three areas should go even further and fundamentally alter the traffic pattern by reducing through traffic to pedestrians and small vehicles, particularly in the school/park complex.

But also, to a degree, at the Koidu 80 plats, and (considering the proposed tram stop and the overall atmosphere setting character of an area entry) the Suur Ameerika Entrance. All the necessary functions of the street can be relocated elsewhere in the vicinity (parking, drop-off/pick-up around the school, utility vehicles).

The opportunity to combine school space and park space into one unit, uninterrupted unit by car traffic, is an amazing chance to create a truly free room for people to enjoy, reducing stress and noise.

Videviku can easily be restricted to pedestrian and small vehicle traffic at both ends, ending in Koidu, leaving access for residents, utilities, and emergency vehicles. This will create a real plats around Koidu 80 that can be traversed with vehicles along Koidu but does not become a transit thoroughfare between Luha and Tehnika. This should also be considered for Planeedi, Virmalise, Kiire, Videviku, Saturni, and Komeedi. None of the streets need to be traversable over Koidu.

Regarding the Suur Ameerika Entrance, the proposal from the Liikuvusagentuur T-Model 2022 should form the basis for any long-term considerations of how Koidu gets connected. It reasonably demands the reduction of the crossroads to a city- and human-sized dimension without losing any access opportunities. There is also a long-term vision to establish a good public space with facilities for the residents on the plot of the current gas station, another foundational entrance lighthouse project to mark the urban space as Uus Maailm. One could even dream of a proper connection between Kassisaba and Uus Maailm following this current project, and a further reduction of the Endla/Luise Autobahn.

These three outstanding areas will provide ample opportunity for the residents and the city to give purpose to the newly created urban space. Over time, given a certain flexibility and adaptability of people and administration, the newly emerging use patterns will offer “branding” opportunities for the area. And as we are looking at a decade-long development of urban character, we should reject any kind of preconceived branding that the proposals provide. Uus Maailm does not need marketing decoration or glossed-over historicized lamp posts, etc. Sensible preservation of historical details is, of course, preferable.

We need to be given the opportunity to properly use our urban space, and have an open ear and a long-term participatory vision following the much-welcomed redesign of Koidu Street.

Just testing static cms with jekyll

For example, we have TV “seasons” somewhere from about January 10 to Midsummer, or 22 weeks, followed by 11 weeks of summer, then 16 weeks for the fall season, and three weeks of Christmas and New Year.

Assuming some client for AUR

1. Install packages

    yay -S qdigidoc4 ccid pcsclite web-eid-firefox
   

2. services

    sudo systemctl start pcscd.service && sudo systemctl enable pcscd.service
   

Maybe there’s an alternative to web-eid-firefox, but only after installing it, the error ‘PKCS#11 cannot be loaded’ in digidoc4client disappeared

Test it under https://web-eid.eu

If you don’t want your indentation get messed up for example in a docker-compose file, add this to the very first line.

#jinja2: lstrip_blocks: "true", trim_blocks: "false"

It will prevent any simple or nested if/for statements to interfere with the layout.